[PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps

Andrew F. Davis afd at ti.com
Thu Jul 25 13:31:50 UTC 2019


On 7/25/19 8:50 AM, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 11:46:01AM -0400, Andrew F. Davis wrote:
>> https://patchwork.kernel.org/patch/10863957/
>>
>> It's actually a more simple heap type IMHO, but the logic inside is
>> incompatible with the system/CMA heaps, if you move any of their code
>> into the core framework then this heap stops working. Leading to out of
>> tree hacks on the core to get it back functional. I see the same for the
>> "complex" heaps with ION.
> 
> Well, this mostly is just another allocator (gen_pool).  And given that
> the whole dma-buf infrastucture assumes things are backed by pages we
> really shouldn't need much more than an alloc and a free callback (and
> maybe the pgprot to map it) and handle the rest in common code.
> 

But that's just it, dma-buf does not assume buffers are backed by normal
kernel managed memory, it is up to the buffer exporter where and when to
allocate the memory. The memory backed by this SRAM buffer does not have
the normal struct page backing. So moving the map, sync, etc functions
to common code would fail for this and many other heap types. This was a
major problem with Ion that prompted this new design.

Each heap type may need to do something different depending on its
backing memory, moving everything to common code that is common to
System and CMA heaps is would lead those being the only upstreamable heaps.

Andrew


More information about the dri-devel mailing list