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

[Daniel Vetter <daniel@ffwll.ch>]

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@ffwll.ch> wrote:
> > On Fri, Oct 25, 2019 at 11:48:32PM +0000, John Stultz wrote:
> > > Now that the DMA BUF heaps core code has been queued, I wanted
> > > to send out some of the pending changes that I've been working
> > > on.
> > >
> > > For use with Android and their GKI effort, it is desired that
> > > DMA BUF heaps are able to be loaded as modules. This is required
> > > for migrating vendors off of ION which was also recently changed
> > > to support modules.
> > >
> > > So this patch series simply provides the necessary exported
> > > symbols and allows the system and CMA drivers to be built
> > > as modules.
> > >
> > > Due to the fact that dmabuf's allocated from a heap may
> > > be in use for quite some time, there isn't a way to safely
> > > unload the driver once it has been loaded. Thus these
> > > drivers do no implement module_exit() functions and will
> > > show up in lsmod as "[permanent]"
> > >
> > > Feedback and thoughts on this would be greatly appreciated!
> >
> > Do we actually want this?
> 
> I guess that always depends on the definition of "we" :)
> 
> > I figured if we just state that vendors should set up all the right
> > dma-buf heaps in dt, is that not enough?
> 
> 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?

> 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 :-)

> 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.

> > 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. 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 :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch