Re: [PATCH v13 0/5] DMA-BUF Heaps (destaging ION)
From: Sumit Semwal
Date: Fri Oct 25 2019 - 01:57:03 EST
On Tue, 22 Oct 2019 at 00:33, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> Lucky number 13! :)
> Last week in v12 I had re-added some symbol exports to support
> later patches I have pending to enable loading heaps from
> modules. He reminded me that back around v3 (its been awhile!) I
> had removed those exports due to concerns about the fact that we
> don't support module removal.
> So I'm respinning the patches, removing the exports again. I'll
> submit a patch to re-add them in a later series enabling moduels
> which can be reviewed indepently.
This looks good to me, and hasn't seen any more comments, so I am
going to merge it via drm-misc-next today.
> With that done, lets get on to the boilerplate!
> The patchset implements per-heap devices which can be opened
> directly and then an ioctl is used to allocate a dmabuf from the
> 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:
> And the userspace changes here:
> 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
> New in v13:
> * Re-remove symbol exports, per discussion with Brian. I'll
> resubmit these separately in a later patch so they can be
> independently reviewed