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@xxxxxxxxxx/ 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@xxxxxxxxx/T/ -- Regards, Laurent Pinchart
