[EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

Andrew F. Davis afd at ti.com
Tue Feb 26 14:28:19 UTC 2019


On 2/25/19 9:53 PM, Sumit Semwal wrote:
> On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis <afd at ti.com> wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
>>
>> Each heap is given its own device node, which a user can allocate
>> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>>
>> Signed-off-by: Andrew F. Davis <afd at ti.com>
>> ---
>>
>> Hello all,
>>
>> I had a little less time over the weekend than I thought I would to
>> clean this up more and finish the first set of user heaps, but wanted
>> to get this out anyway.
>>
>> ION in its current form assumes a lot about the memory it exports and
>> these assumptions lead to restrictions on the full range of operations
>> dma-buf's can produce. Due to this if we are to add this as an extension
>> of the core dma-buf then it should only be the user-space advertisement
>> and allocation front-end. All dma-buf exporting and operation need to be
>> placed in the control of the exporting heap. The core becomes rather
>> small, just a few hundred lines you see here. This is not to say we
>> should not provide helpers to make the heap exporters more simple, but
>> they should only be helpers and not enforced by the core framework.
> 
> As an idea, I really like the direction for this. It gives a good
> amount of flexibilty for exporters. So definitely thanks to John and
> you for taking the plunge there :)
> 
>>
>> Basic use model here is an exporter (dedicated heap memory driver, CMA,
>> System, etc.) registers with the framework by providing a struct
>> dma_heap_info which gives us the needed info to export this heap to
>> userspace as a device node. Next a user will request an allocation,
>> the IOCTL is parsed and the request made to a heap provided alloc() op.
>> The heap should return the filled out struct dma_heap_buffer, including
>> exporting the buffer as a dma-buf. This dma-buf we then return to the
>> user as a fd. Buffer free is still a bit open as we need to update some
>> stats and free some memory, but the release operation is controlled by
>> the heap exporter, so some hook will have to be created.
>>
>> It all needs a bit more work, and I'm sure I'll find missing parts when
>> I add some more heaps, but hopefully this framework is simple enough that
>> it does not impede the implementation of all functionality once provided
>> by ION (shrinker, delayed free), nor any new functionality needed for
>> future heap exporting devices.
>>
> Other than current heaps, the secure heaps have been talked about
> quite a bit in the past, so I will check with Linaro's security group
> on them trying out the next version as well.

As I also moonlight as a Linaro member engineer as part of SWG
(andrew.davis at linaro.org) I've talked with Joakim and Etienne about the
secure (unmapped) heaps, adding those are already baked into my plans
here :)

Andrew

> We also would need to do a performance comparison, so that's another
> activity to be added.
>> Thanks,
>> Andrew
> Best,
> Sumit.
>>


More information about the dri-devel mailing list