Hi Christian,
CC'ing James as I think this is related to his work on the unix device memory allocator ([1]).
[1] https://lore.kernel.org/dri-devel/8b555674-1c5b-c791-4547-2ea7c16aee6c@nvidi...
On Mon, Jan 23, 2023 at 01:37:54PM +0100, Christian König wrote:
Hi guys,
this is just an RFC! The last time we discussed the DMA-buf coherency problem [1] we concluded that DMA-heap first needs a better way to communicate to userspace which heap to use for a certain device.
As far as I know userspace currently just hard codes that information which is certainly not desirable considering that we should have this inside the kernel as well.
So what those two patches here do is to first add some dma_heap_create_device_link() and dma_heap_remove_device_link() function and then demonstrating the functionality with uvcvideo driver.
The preferred DMA-heap is represented with a symlink in sysfs between the device and the virtual DMA-heap device node.
I'll start with a few high-level comments/questions:
- Instead of tying drivers to heaps, have you considered a system where a driver would expose constraints, and a heap would then be selected based on those constraints ? A tight coupling between heaps and drivers means downstream patches to drivers in order to use vendor-specific heaps, that sounds painful.
A constraint-based system would also, I think, be easier to extend with additional constraints in the future.
- I assume some drivers will be able to support multiple heaps. How do you envision this being implemented ?
- Devices could have different constraints based on particular configurations. For instance, a device may require specific memory layout for multi-planar YUV formats only (as in allocating the Y and C planes of NV12 from different memory banks). A dynamic API may thus be needed (but may also be very painful to use from userspace).
What's still missing is certainly matching userspace for this since I wanted to discuss the initial kernel approach first.
https://git.libcamera.org/libcamera/libcamera.git/ would be a good place to prototype userspace support :-)
Please take a look and comment.
Thanks, Christian.
[1] https://lore.kernel.org/all/11a6f97c-e45f-f24b-8a73-48d5a388a2cc@gmail.com/T...