Re: DMA-heap driver hints

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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@nvidia.com/

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/

-- 
Regards,

Laurent Pinchart