[RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)

[John Stultz]

On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis <afd at ti.com> 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