[PATCH v6 2/2] dma-buf: heaps: cma: Create CMA heap for each CMA reserved region

[Maxime Ripard]

On Thu, Jul 10, 2025 at 09:46:56AM -0500, Andrew Davis wrote:
> 
> 
> On 7/10/25 2:44 AM, Maxime Ripard wrote:
> > On Wed, Jul 09, 2025 at 11:14:37AM -0500, Andrew Davis wrote:
> > > On 7/9/25 7:44 AM, Maxime Ripard wrote:
> > > > Aside from the main CMA region, it can be useful to allow userspace to
> > > > allocate from the other CMA reserved regions.
> > > > 
> > > > Indeed, those regions can have specific properties that can be useful to
> > > > a specific us-case.
> > > > 
> > > > For example, one of them platform I've been with has ECC enabled on the
> > > > entire memory but for a specific region. Using that region to allocate
> > > > framebuffers can be particular beneficial because enabling the ECC has a
> > > > performance and memory footprint cost.
> > > > 
> > > > Thus, exposing these regions as heaps user-space can allocate from and
> > > > import wherever needed allows to cover that use-case.
> > > > 
> > > > For now, only shared-dma-pools regions with the reusable property (ie,
> > > > backed by CMA) are supported, but eventually we'll want to support other
> > > > DMA pools types.
> > > > 
> > > > Signed-off-by: Maxime Ripard <mripard at kernel.org>
> > > > ---
> > > >    drivers/dma-buf/heaps/cma_heap.c | 52 +++++++++++++++++++++++++++++++++++++++-
> > > >    1 file changed, 51 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
> > > > index 0df007111975447d555714d61ead9699287fd65a..31a18683ee25788a800f3f878fd958718a930ff7 100644
> > > > --- a/drivers/dma-buf/heaps/cma_heap.c
> > > > +++ b/drivers/dma-buf/heaps/cma_heap.c
> > > > @@ -19,10 +19,12 @@
> > > >    #include <linux/err.h>
> > > >    #include <linux/highmem.h>
> > > >    #include <linux/io.h>
> > > >    #include <linux/mm.h>
> > > >    #include <linux/module.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/of_reserved_mem.h>
> > > >    #include <linux/scatterlist.h>
> > > >    #include <linux/slab.h>
> > > >    #include <linux/vmalloc.h>
> > > >    #define DEFAULT_CMA_NAME "default_cma_region"
> > > > @@ -421,7 +423,55 @@ static int __init add_default_cma_heap(void)
> > > >    				ERR_PTR(ret));
> > > >    	}
> > > >    	return 0;
> > > >    }
> > > > -module_init(add_default_cma_heap);
> > > > +
> > > > +static int __init add_cma_heaps(void)
> > > > +{
> > > > +	struct device_node *rmem_node;
> > > > +	struct device_node *node;
> > > > +	int ret;
> > > > +
> > > > +	ret = add_default_cma_heap();
> > > 
> > > Will this double add the default CMA region if it was declared
> > > using DT (reserved-memory) when all those nodes are again scanned
> > > through below? Might need a check in that loop for linux,cma-default.
> > 
> > Yeah, but we probably should anyway. Otherwise, if linux,cma-default
> > ever change on a platform, we would get heaps appearing/disappearing as
> > we reboot, which doesn't sound great from a regression perspective.
> > 
> > Both would allocate from the same pool though, so we don't risk stepping
> > into each others toes. Or am I missing something?
>
> You are not missing anything, having both wouldn't cause anything to break,
> but would cause heaps to appear/disappear based on how the CMA region was
> defined (DT vs kernel cmd line) which we should avoid.

I'm sorry I guess I don't follow you then. It looked like you were
arguing for avoiding double registration (under the CMA default name,
and the region specific name).

I'm arguing that we should always double register to avoid
linux,cma-default having any effect on the userspace.

In the latter, even if linux,cma-default isn't set at all, then the
default CMA heap would still be registered from the command line CMA
region.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250710/e1919e79/attachment-0001.sig>