On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis <afd@xxxxxx> wrote: > On 10/17/19 3:14 PM, John Stultz wrote: > > But if the objection stands, do you have a proposal for an alternative > > way to enumerate a subset of CMA heaps? > > > When in staging ION had to reach into the CMA framework as the other > direction would not be allowed, so cma_for_each_area() was added. If > DMA-BUF heaps is not in staging then we can do the opposite, and have > the CMA framework register heaps itself using our framework. That way > the CMA system could decide what areas to export or not (maybe based on > a DT property or similar). Ok. Though the CMA core doesn't have much sense of DT details either, so it would probably have to be done in the reserved_mem logic, which doesn't feel right to me. I'd probably guess we should have some sort of dt binding to describe a dmabuf cma heap and from that node link to a CMA node via a memory-region phandle. Along with maybe the default heap as well? Not eager to get into another binding review cycle, and I'm not sure what non-DT systems will do yet, but I'll take a shot at it and iterate. > The end result is the same so we can make this change later (it has to > come after DMA-BUF heaps is in anyway). Well, I'm hesitant to merge code that exposes all the CMA heaps and then add patches that becomes more selective, should anyone depend on the initial behavior. :/ So, <sigh>, I'll start on the rework for the CMA bits. That said, I'm definitely wanting to make some progress on this patch series, so maybe we can still merge the core/helpers/system heap and just hold the cma heap for a rework on the enumeration bits. That way we can at least get other folks working on switching their vendor heaps from ION. Sumit: Does that sound ok? Assuming no other objections, can you take the v11 set minus the CMA heap patch? thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
