On Tue, Nov 5, 2019 at 8:48 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Tue, Nov 5, 2019 at 11:19 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > 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? > > Not quite. Andrew noted that we may not want to expose all CMA regions > via dmabuf heaps, so right now we only expose the default region. I > have follow on patches that I sent out earlier (which requires a > to-be-finalized DT binding) which allows us to specify which other CMA > regions to expose. Why do we not want to expose them all? I figured if there's a cma heap, then a device you have needs it, and if that's the case you might want to allocate for that device from the heap? Maybe link to the discussion? > > > > > 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 > > No. CMA core isn't available as a module. > > > 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? > > I agree that is maybe not the most critical item on the list, but its > one of many that do add up over time. > > Again, I'll defer to Sandeep or other folks on the Google side to help > with the importance here. Mostly I'm trying to ensure there is > functional parity to ION so we don't give folks any reason they could > object to deprecating it. > > > > 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. > > I'm sorry, I'm not sure I understand what you mean here (I'm not sure > what action I should be taking). Could you clarify this point? I'm not sold on the use-case for this, but maybe if I see the actual use-cases I might be swayed. A very basic/minimal "register a new dma-buf heap" function should be all that's really needed for android, so maybe we can start with that? -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
