On 2/27/19 3:55 PM, John Stultz wrote: > On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis <a...@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.stu...@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 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel