[RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
Laura Abbott
labbott at redhat.com
Fri Mar 15 20:34:32 UTC 2019
On 3/5/19 12:54 PM, 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
>
>
> 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 for now, since it should
> be implemented by the heaps themselves.
>
> Eventual TODOS:
> * Reimplement page-pool for system heap (working on this)
> * Add stats accounting to system/cma heaps
> * Make the kselftest actually useful
> * Add other heaps folks see as useful (would love to get
> some help from actual carveout/chunk users)!
>
> That said, the main user-interface is shaping up and I wanted
> to get some input on the device model (particularly from GreKH)
> and any other API/ABI specific input.
>
> thanks
> -john
>
> Cc: Laura Abbott <labbott at redhat.com>
> Cc: Benjamin Gaignard <benjamin.gaignard at linaro.org>
> Cc: Greg KH <gregkh at linuxfoundation.org>
> Cc: Sumit Semwal <sumit.semwal at linaro.org>
> Cc: Liam Mark <lmark at codeaurora.org>
> Cc: Brian Starkey <Brian.Starkey at arm.com>
> Cc: Andrew F. Davis <afd at ti.com>
> Cc: Chenbo Feng <fengc at google.com>
> Cc: Alistair Strachan <astrachan at google.com>
> Cc: dri-devel at lists.freedesktop.org
>
> Andrew F. Davis (1):
> dma-buf: Add dma-buf heaps framework
>
> John Stultz (4):
> dma-buf: heaps: Add heap helpers
> dma-buf: heaps: Add system heap to dmabuf heaps
> dma-buf: heaps: Add CMA heap to dmabuf heapss
> kselftests: Add dma-heap test
>
> MAINTAINERS | 16 +
> drivers/dma-buf/Kconfig | 10 +
> drivers/dma-buf/Makefile | 2 +
> drivers/dma-buf/dma-heap.c | 191 ++++++++++++
> drivers/dma-buf/heaps/Kconfig | 14 +
> drivers/dma-buf/heaps/Makefile | 4 +
> drivers/dma-buf/heaps/cma_heap.c | 164 ++++++++++
> drivers/dma-buf/heaps/heap-helpers.c | 335 +++++++++++++++++++++
> drivers/dma-buf/heaps/heap-helpers.h | 48 +++
> drivers/dma-buf/heaps/system_heap.c | 132 ++++++++
> include/linux/dma-heap.h | 65 ++++
> include/uapi/linux/dma-heap.h | 52 ++++
> tools/testing/selftests/dmabuf-heaps/Makefile | 11 +
> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96 ++++++
> 14 files changed, 1140 insertions(+)
> create mode 100644 drivers/dma-buf/dma-heap.c
> create mode 100644 drivers/dma-buf/heaps/Kconfig
> create mode 100644 drivers/dma-buf/heaps/Makefile
> create mode 100644 drivers/dma-buf/heaps/cma_heap.c
> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
> create mode 100644 drivers/dma-buf/heaps/system_heap.c
> create mode 100644 include/linux/dma-heap.h
> create mode 100644 include/uapi/linux/dma-heap.h
> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>
This is looking really great. Thanks for doing the work to
push this forward. It seems like we're in general agreement
about much of this. Which of the issues that have come up
do you think are a "hard no" to keeping this from going in?
Thanks,
Laura
More information about the dri-devel
mailing list