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@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
