[PATCH 2/2] powerpc/mpc85xx: Add DPAA Q/BMan support to device tree(s)

[Scott Wood]

On Mon, 2014-11-17 at 04:31 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 11/13/2014 03:42 PM, Scott Wood wrote:
> > On Thu, 2014-11-13 at 03:21 -0600, Emil Medve wrote:
> >> From: Kumar Gala <galak at kernel.crashing.org>
> >>
> >> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> >> Signed-off-by: Geoff Thorpe <Geoff.Thorpe at freescale.com>
> >> Signed-off-by: Hai-Ying Wang <Haiying.Wang at freescale.com>
> >> Signed-off-by: Chunhe Lan <Chunhe.Lan at freescale.com>
> >> Signed-off-by: Poonam Aggrwal <poonam.aggrwal at freescale.com>
> >> Signed-off-by: Emil Medve <Emilian.Medve at Freescale.com>
> >> Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760
> > 
> > I suspect these patches are changed quite a bit from Kumar's version...
> 
> Across SDK releases I've been trying retain the authors names and the
> 'Signed-off-by' list is the only place that can accommodate them all.
> Kumar is the first author, and besides this exercise the most significant
> 
> > It's good to note changes after the listed author has stopped being
> > involved, so they don't get the blame for anything they wouldn't have
> > put in there.
> 
> Bah. Most of the sordid history is lost

You don't need the full history.  If Kumar wrote most of it then he
should stay as the From: line, but maybe put a line before your signoff,
something like:
[Emil: various updates]
to indicate it wasn't passed on as is, as is recommended in
Documentation/SubmittingPatches.

> > no-map and reusable don't make sense together.  How can the OS reuse the
> > memory if it can't map it?
> 
> Perhaps I've been reading/speculating(?) too much about it. Now granted
> the code is still young (?), but in between "under the control of the
> device driver using the region" and "the device driver(s) owning the
> region need to be able to reclaim it back" it sort of made sense

No-map says to never map the region except under control of the driver.
Reusable says it's ok to use the region (which implies mapping) outside
the control of the driver, except when the driver claims the region via
some unspecified mechanism.

FWIW, the one place I can find in the code that currently insists on
"reusable" rejects regions with "no-map" (rmem_cma_setup), and the one
place I can find that currently insists on "no-map" rejects regions with
"reusable" (rmem_dma_setup).

> > no-map is burdensome (and I believe not yet implemented) on mpc85xx,
> > where we want to use huge TLB entries to cover all of (low) memory.  Is
> > it really needed?
> 
> I'm thinking no-map would be part of having/making this reserved memory
> into a different coherency domain then the... everything else

OK, but it's not actually required to use a different coherency domain.
You're putting configuration into the device tree, and it's a
particularly burdensome bit of configuration on mpc85xx due to the way
the TLB works (it also doesn't currently work as advertised on PPC).
Have you benchmarked to see what the benefit is of using a separate
coherence domain?

> > What do we gain from specifying reusable here?
> 
> I guess the obvious of having this memory usable for something else when
> the B/QMan drivers don't use it

When would they not use it?

> > How is it actually supposed to work?
> 
> You mean how should one implement 'reusable'?

Yes.

-Scott