On Tue, Nov 5, 2019 at 6:41 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
