Hi Ezequiel, On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > which will allocate memory suitable for the given device. > > The implementation is mostly a port of the Contiguous Videobuf2 > memory allocator (see videobuf2/videobuf2-dma-contig.c) > over to the DMA-BUF Heap interface. > > The intention of this allocator is to provide applications > with a more system-agnostic API: the only thing the application > needs to know is which device to get the buffer for. > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > is unknown to the application. > > I'm not really expecting this patch to be correct or even > a good idea, but just submitting it to start a discussion on DMA-BUF > heap discovery and negotiation. > My initial reaction is that I thought dmabuf heaps are meant for use to allocate buffers for sharing across devices, which doesn't fit very well with having per-device heaps. For single-device allocations, would using the buffer allocation functionality of that device's native API be better in most cases? (Some other possibly relevant discussion at [1]) I can see that this can save some boilerplate for devices that want to expose private chunks of memory, but might it also lead to 100 aliases for the system's generic coherent memory pool? I wonder if a set of helpers to allow devices to expose whatever they want with minimal effort would be better. Cheers, -Brian 1. https://lore.kernel.org/dri-devel/57062477-30e7-a3de-6723-a50d03a402c4@xxxxxxxx/ > Given Plumbers is just a couple weeks from now, I've submitted > a BoF proposal to discuss this, as perhaps it would make > sense to discuss this live? > > Not-signed-off-by: Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx>
