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

[Andrew F. Davis]

On 2/27/19 3:55 PM, John Stultz wrote:
> On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis <afd at ti.com> wrote:
>>
>> On 2/26/19 5:40 PM, John Stultz wrote:
>>> On Tue, Feb 26, 2019 at 11:21 AM John Stultz <john.stultz at linaro.org> wrote:
>>> I've updated the patches here:
>>> kernel: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
>>> userland: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
>>>
>>>
>>>> I also realized some of Benajmin's error path improvements are going
>>>> to be hard to fix w/ my current code, specifically having the allocate
>>>> op do the allocation of the dma_heap_buffer (since we don't have a
>>>> free op, if something fails creating the dmabuf fd in the core, we
>>>> don't have a hook to release the dma_heap_buffer and heap private
>>>> data).
>>>
>>
>> We can always add back the free op, the alternative is to have the heap
>> export the fd.
>>
>> I'm not sure either is needed though, when we
>> dma_buf_put(buffer->dmabuf) on the error path it should trigger the
>> release op, and that can cleanup the allocations in the heap.
> 
> Good point, but I worry that's a bit subtle.
> 
> Also doing the stuff with the helpers where we have to register a free
> callback is kind of ugly, and I personally like the symmetry of having
> free hooks if we have allocation hooks (even if the dmabuf release
> hook initiates the free call).
> 

I do like the symmetry of a free op, just not sure how or what should be
done in it that couldn't be taken care of in the dmabuf.release op..

>>> I also realized doing my development and testing against my
>>> hikey960-mainline-WIP branch, I accidentally folded in an ion hack I
>>> was using to reduce cache operations, so I'll need to undo that in the
>>> heap-helpers.c.  But at least we have a rough validation point for the
>>> design.
>>>
>>
>> Great! The details of the heap-helpers can always get fixed up at a
>> later point, validation of the core working is really good to hear.
>>
> 
> Let me know if you have any further feedback or changes to integrate.
> I've got to get back to some other work, but will try to take a
> cleanup pass in the next few days.
> 

I've got no other feedback right now. I'm guessing we will try a first
non-RFC sometime in the next couple weeks for the sake of getting Greg's
eyes on this, can see where it goes from there.

Thanks,
Andrew

> thanks
> -john
>