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

[Maxime Ripard]

On Thu, Jul 10, 2025 at 11:21:02AM -0400, Nicolas Dufresne wrote:
> Hi,
> 
> Le mercredi 09 juillet 2025 à 15:38 +0200, Maxime Ripard a écrit :
> > > Will there be a generic way to find out which driver/device this carveout
> > > belongs to ? In V4L2, only complex cameras have userspace drivers,
> > > everything
> > > else is generic code.
> > 
> > I believe it's a separate discussion, but the current stance is that the
> > heap name is enough to identify in a platform-specific way where you
> > allocate from. I've worked on documenting what a good name is so
> > userspace can pick it up more easily here:
> > 
> > https://lore.kernel.org/r/20250616-dma-buf-heap-names-doc-v2-1-8ae43174cdbf@kernel.org
> > 
> > But it's not really what you expected
> 
> From a dma-heap API, the naming rules seems necessary, but suggesting generic
> code to use "grep" style of search to match a heap is extremely fragile. The
> documentation you propose is (intentionally?) vague. For me, the naming is more
> like giving proper names to your function calls do devs can make sense out of
> it.

I agree, and made a proposal to implement some kind of heap capabilities
discovery ioctl. The main concern at the time was that Android tried
that with ION and it lead to a proliferation of poorly defined flags,
and that names were enough to do so.

I still think that at some point we will need this, but I also don't
have a good idea to address these concerns.

> Stepping back a little, we already opened the door for in-driver use of heaps.
> So perhaps the way forward is to have V4L2 drivers utilize heaps from inside the
> kernel. Once driver are fully ported, additional APIs could be added so that
> userspace can read which heap(s) is going to be used for the active
> configuration, and which other heaps are known usable (enumerate them). There is
> no need to add properties in that context, since these will derives from the
> driver configuration you picked. If you told you driver you doing secure memory
> playback, the driver will filter-out what can't be used.
> 
> Examples out there often express simplified view of the problem. Your ECC video
> playback case is a good one. Let's say you have performance issue in both
> decoder and display due to ECC. You may think that you just allocate from a non-
> ECC heap, import these into the decoder, and once filled, import these into the
> display driver and you won.
> 
> But in reality, your display buffer might not be the reference buffers, and most
> of the memory bandwidth in a modern decoder goes into reading reference frames
> and the attached metadata (the later which may or may not be in the same
> allocation block).
> 
> Even once the reference frames get exposed to userspace (which is a long term
> goal), there will still be couple of buffers that just simply don't fit and must
> be kept hidden inside the driver.
> 
> My general conclusion is that once these heap exists, and that we guarantee
> platform specific unique names, we should probably build on top. Both userspace
> and driver become consumers of the heap. And for the case where the platform-
> specific knowledge lives inside the kernel, then heaps are selected by the
> kernel. Also, very little per-driver duplication will be needed, since 90% of
> the V4L2 driver share the allocator implementation.
> 
> Does that makes any sense to anyone ?

It does, and it's roughly what we have in mind for the cgroups support
in KMS and v4l2. The main issue with it is that knowing if you allocate
from a dedicated pool (which would use the dmem cgroup controller) or
the main memory pool (which would use memcg) wasn't deterministic and
thus you couldn't properly account.

The solution we have in mind right now is indeed to switch everyone to
using heaps, and then exposing which cgroup that heap allocates from.

Your proposal here has a few extra steps, but the main idea is there
still.

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/20250711/7f014331/attachment.sig>