[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANDhNCqfsUbN3aavAH5hi4wdcKuUkjLX4jqhKzy-q+jCEqpoow@mail.gmail.com>
Date: Thu, 24 Apr 2025 17:13:47 -0700
From: John Stultz <jstultz@...gle.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Jared Kangas <jkangas@...hat.com>, sumit.semwal@...aro.org,
benjamin.gaignard@...labora.com, Brian.Starkey@....com, tjmercier@...gle.com,
christian.koenig@....com, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] dma-buf: heaps: Give default CMA heap a fixed name
On Thu, Apr 24, 2025 at 1:34 AM Maxime Ripard <mripard@...nel.org> wrote:
> On Tue, Apr 22, 2025 at 12:19:39PM -0700, Jared Kangas wrote:
> > @@ -22,6 +22,7 @@
> > #include <linux/slab.h>
> > #include <linux/vmalloc.h>
> >
> > +#define DEFAULT_CMA_NAME "default_cma"
>
> I appreciate this is kind of bikeshed-color territory, but I think "cma"
> would be a better option here. There's nothing "default" about it.
I disagree. It very much is "default" as it's returning the
dma_contiguous_default_area.
There can be multiple CMA areas, and out of tree, vendors do reserve
separate areas for specific purposes, exposing multiple CMA dmabuf
heaps.
There have been patches to expose multiple CMA heaps, but with no
upstream drivers using those purpose specific regions, we haven't
taken them yet.
I do hope as the drivers that utilize these purpose focused heaps go
upstream, we can add that logic, so I think being specific that this
is default CMA is a good idea.
thanks
-john
Powered by blists - more mailing lists