On Thu, Jan 22, 2026 at 05:10:03PM +0100, Thierry Reding wrote:
From: Thierry Reding treding@nvidia.com
There is no technical reason why there should be a limited number of CMA regions, so extract some code into helpers and use them to create extra functions (cma_create() and cma_free()) that allow creating and freeing, respectively, CMA regions dynamically at runtime.
The static array of CMA areas cannot be replaced by dynamically created areas because for many of them, allocation must not fail and some cases may need to initialize them before the slab allocator is even available. To account for this, keep these "early" areas in a separate list and track the dynamic areas in a separate list.
Signed-off-by: Thierry Reding treding@nvidia.com
AFAIU, this won't create a new cma heap when registering. This goes against the recent work we did to create one for every cma region.
I guess, since you have a driver that would explicitly handle that region, we should create some kind of opt-out mechanism, but by default, we should still create such a heap.
That being said, it's not clear to me why the heap driver uses CMA in the first place.
Maxime