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@...
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