On Wed, Oct 9, 2019 at 10:38 AM Ayan Halder <Ayan.Halder@xxxxxxx> 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@xxxxxxxxxx> 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-heap > > > > > > > > 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-buf-heap&id=00538fe70e17acf07fdcbc441816d91cdd227207 thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
