[RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules

[Daniel Vetter]

On Tue, Nov 5, 2019 at 6:41 PM John Stultz <john.stultz at linaro.org> wrote:
>
> On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote:
> > > On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > On Fri, Oct 25, 2019 at 11:48:32PM +0000, John Stultz wrote:
> > > So even if the heaps are configured via DT (which at the moment there
> > > is no such binding, so that's not really a valid method yet), there's
> > > still the question of if the heap is necessary/makes sense on the
> > > device. And the DT would only control the availability of the heap
> > > interface, not if the heap driver is loaded or not.
> >
> > Hm I thought the cma regions are configured in DT? How does that work if
> > it's not using DT?
>
> So yea, CMA regions are either configured by DT or setup at build time
> (I think there's a cmdline option to set it up as well).
>
> But the CMA regions and the dmabuf cma heap driver are separate
> things. The latter uses the former.

Huh, I assumed the plan is that whenever there's a cma region, we want
to instantiate a dma-buf heap for it? Why/when would we not want to do
that?

> > > On the HiKey/HiKey960 boards, we have to allocate contiguous buffers
> > > for the display framebuffer. So gralloc uses ION to allocate from the
> > > CMA heap. However on the db845c, it has no such restrictions, so the
> > > CMA heap isn't necessary.
> >
> > Why do you have a CMA region for the 2nd board if you don't need it?
> > _That_ sounds like some serious memory waster, not a few lines of code
> > loaded for nothing :-)
>
> ??? That's not what I said above.  If the db845c doesn't need CMA it
> won't have a CMA region.
>
> The issue at hand is that we may want to avoid loading the dmabuf CMA
> heap driver on a board that doesn't use CMA.

So the CMA core code is also a module, or how does that work? Not
loading the cma dma-buf heap, but keeping all the other cma code
around feels slightly silly. Do we have numbers that justify this
silliness?

> > > With Android's GKI effort, there needs to be one kernel that works on
> > > all the devices, and they are using modules to try to minimize the
> > > amount of memory spent on functionality that isn't universally needed.
> > > So on devices that don't need the CMA heap, they'd probably prefer not
> > > to load the CMA dmabuf heap driver, so it would be best if it could be
> > > built as a module.  If we want to build the CMA heap as a module, the
> > > symbols it uses need to be exported.
> >
> > Yeah, I guess I'm disagreeing on whether dma-buf heaps are core or not.
>
> That's fine to dispute. I'm not really in a place to assert one way or
> not, but the Android folks have made their ION system and CMA heaps
> loadable via a module, so it would seem like having the dmabuf system
> and CMA heaps be modular would be useful to properly replace that
> usage.
>
> For instance, the system heap as a module probably doesn't make much
> sense, as most boards that want to use the dmabuf heaps interface are
> likely to use that as well.  CMA is more optional as not all boards
> will use that one, so it might make sense to avoid loading it.
>
> Sandeep: Can you chime in here as to how critical having the system
> and cma heaps be modules are?
>
>
> > > > Exporting symbols for no real in-tree users feels fishy.
> > >
> > > I'm submitting an in-tree user here. So I'm not sure what you mean?  I
> > > suspect you're thinking there is some hidden/nefarious plan here, but
> > > really there isn't.
> >
> > I was working under the assumption that you're only exporting the symbols
> > for other heaps, and keep the current ones in-tree.
>
> No. I'm trying to allow the (hopefully-soon-to-be-in-tree) system and
> cma heap drivers to be loaded from a module.
> If other heaps need exports, they can submit their heaps upstream and
> argue for the exported symbols themselves.
>
> > Are there even any
> > out-of-tree dma-buf heaps still? out-of-tree and legit different use-case
> > I mean ofc, not just out-of-tree because inertia :-)
>
> So as Andrew mentioned, he has some dmabuf heaps he's working on at
> TI.  From what I've heard the qualcomm folks like the dmabuf heaps
> approach, but I'm not sure if they've taken a pass at converting their
> vendor ION heaps to it yet.
>
> The main reason I'm only submitting system and CMA is because those
> are the only two I personally have a user for (HiKey/HiKey960 boards).
> It's my hope that once we deprecate ION in Android, vendors will
> migrate and we'll be able to push them to upstream their heaps as
> well.

I think for upstream I'd want to see those other heaps first. If
they're mostly driver allocators exposed as heaps, then I think we
need something different than heap modules, maybe allow dma-buf to
allocate from drivers instead. But afaiui all such driver allocators
we have in upstream are cma regions only right now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch