[EARLY RFC][PATCH 0/4] dmabuf pools infrastructure (destaging ION)

John Stultz john.stultz at linaro.org
Fri Feb 22 07:19:24 UTC 2019


On Wed, Feb 20, 2019 at 11:40 PM John Stultz <john.stultz at linaro.org> wrote:
>
> Here is a very early peek at my dmabuf pools patchset, which
> tries to destage a fair chunk of ION functionality.
>
> This build and boots, but I've not gotten to testing the actual
> pool devices yet (need to write some kselftests)! I just wanted
> some early feedback on the overall direction.
>
> The patchset implements per-pool devices (extending my ion
> per-heap devices patchset from last week), which can be opened
> directly and then an ioctl is used to allocate a dmabuf from the
> pool.
>
> The interface is similar, but simpler then IONs, only providing
> an ALLOC ioctl.
>
> Also, I've only destaged the system/system-contig and cma pools,
> since the ION carveout and chunk heaps depended on out of tree
> board files to initialize those heaps. I'll leave that to folks
> who are actually using those heaps.
>
> Let me know what you think!

I also managed to get this validated under AOSP w/ HiKey960 today.

There were some bugs, so I've got updated patches here (on top of
HiKey960 kernel changes - even includes the beginnings of a
kselftest):
   https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-pools

And the userland changes HiKey960's gralloc (so it can dynamically
support legacy ion, modern ion and dmabuf pools) are here:
  https://android-review.googlesource.com/c/device/linaro/hikey/+/909436

I still need to flesh out the kselftest code some more to actually do
some validation and error testing, and do a bunch of cleanups (and I'm
sure find a few more bugs), but hopefully this can now be considered
viable.

thanks
-john


More information about the dri-devel mailing list