On Wed, Oct 9, 2019 at 10:38 AM Ayan Halder Ayan.Halder@arm.com wrote:
On Tue, Sep 24, 2019 at 04:22:18PM +0000, Ayan Halder wrote:
On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
Hello Christoph, everyone,
On Sat, 7 Sep 2019 at 00:17, John Stultz john.stultz@linaro.org wrote:
Here is yet another pass at the dma-buf heaps patchset Andrew and I have been working on which tries to destage a fair chunk of ION functionality.
The patchset implements per-heap devices which can be opened directly and then an ioctl is used to allocate a dmabuf from the heap.
The interface is similar, but much simpler then IONs, only providing an ALLOC ioctl.
Also, I've provided relatively simple system and cma heaps.
I've booted and tested these patches with AOSP on the HiKey960 using the kernel tree here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf...
And the userspace changes here: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
Compared to ION, this patchset is missing the system-contig, carveout and chunk heaps, as I don't have a device that uses those, so I'm unable to do much useful validation there. Additionally we have no upstream users of chunk or carveout, and the system-contig has been deprecated in the common/andoid-* kernels, so this should be ok.
I've also removed the stats accounting, since any such accounting should be implemented by dma-buf core or the heaps themselves.
Most of the changes in this revision are adddressing the more concrete feedback from Christoph (many thanks!). Though I'm not sure if some of the less specific feedback was completely resolved in discussion last time around. Please let me know!
It looks like most of the feedback has been taken care of. If there's no more objection to this series, I'd like to merge it in soon.
If there are any more review comments, may I request you to please provide them?
I tested these patches using our internal test suite with Arm,komeda driver and the following node in dts
reserved-memory { #address-cells = <0x2>; #size-cells = <0x2>; ranges; framebuffer@60000000 { compatible = "shared-dma-pool"; linux,cma-default; reg = <0x0 0x60000000 0x0 0x8000000>; }; }Apologies for the confusion, this dts node is irrelevant as our tests were using the cma heap (via /dev/dma_heap/reserved).
That raises a question. How do we represent the reserved-memory nodes (as shown above) via the dma-buf heaps framework ?
(Apologies I didn't initially see this as you somehow left me off the reply list)
So yea, as Brian mentioned, we'll generate a heap for each cma area. So the above should generate a heap named "framebuffer".
For example, on HiKey960 the following patch adds (originally for ION, but the same dt node will work for dmabuf heaps) the cma heap "linux,cma" https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/dma-...
thanks -john