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

[Nicolas Dufresne]

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.

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 ?

Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250710/1a298eae/attachment.sig>