On Fri, Mar 15, 2019 at 4:15 PM Jerome Glisse <jgli...@redhat.com> wrote: > On Tue, Mar 05, 2019 at 12:54:28PM -0800, John Stultz wrote: > > Here is a initial RFC of 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 simple system and cma heaps. The system > > heap in particular is missing the page-pool optimizations ION > > had, but works well enough to validate the interface. > > > > 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 > > What upstream driver will use this eventualy ? And why is it > needed ?
So, its sort of a complicated answer, as we don't have a fully open pipeline just yet. The HiKey board's upstream kirin drm driver uses this, as it needs contiguous buffers for its framebuffers. So in Android the HiKey gralloc (opensource userspace) allocates the HW_FB buffers from the CMA heap. Other graphics buffers are then allocated by gralloc out of the system heap and SurfaceFlinger and drm_hwc (both also opensource userspace) coordinate squashing those other buffers down through the mali utgard gpu (proprietary GL blob) onto the target HW_FB buffer. (All of the above is the same for the HiKey960, but we're still working the drm driver into shape for upstreaming). That said, I know the Lima driver is starting to shape up, and I'm hoping to give it a whirl to replace the proprietary utgard driver. Everything else would stay the same, which would give us a fully open pipeline. I know for other dev boards like the db410c w/ freedreno, the Android pipeline gets away with using the gbmgralloc implementation, but my understanding in that case is the rendering/display pipeline doesn't require contiguous buffers, so the allocation logic can be simpler, and doesn't use ION heaps. But its possible a gralloc could be implemented to use the system heap for allocations on that device. thanks -john _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
