[PATCH 01/16] ARM: b.L: secondary kernel entry code

[Dave Martin]

On Fri, Jan 11, 2013 at 11:45:53AM +0000, Catalin Marinas wrote:
> On Thu, Jan 10, 2013 at 04:47:09PM +0000, Nicolas Pitre wrote:
> > On Thu, 10 Jan 2013, Catalin Marinas wrote:
> > > On 10 January 2013 00:20, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm/common/bL_entry.c
> > > ...
> > > > +extern volatile unsigned long bL_entry_vectors[BL_NR_CLUSTERS][BL_CPUS_PER_CLUSTER];
> > > 
> > > IMHO, we should keep this array linear and ignore the cluster grouping
> > > at this stage. This information could be added to latter patches that
> > > actually need to know about the b.L topology.
> > 
> > That's virtually all of them.  Everything b.L related is always 
> > expressed in terms of a cpu,cluster tuple at the low level.
> > 
> > > This would also imply that we treat the MPIDR just as an ID without 
> > > digging into its bit layout.
> > 
> > That makes for too large an index space.  We always end up needing to 
> > break the MPIDR into a cpu,cluster thing as the MPIDR bits are too 
> > sparse.
> 
> You could find a way to compress this with some mask and shifts. We can
> look at this later if we are to generalise this to non-b.L systems.

The b.L cluster handling code has multiple instances of this issue.
We should either try to fix them all, or defer them all as being
overkill for the foreseeable future.

For current platforms, the space saved in unlikely to be larger than
the amount of code required to implement the optimisation.

I do think we need a good, generic way to map sparesely-populated,
multidimensional topological node IDs to/from a linear space, but
we should avoid reinventing that too many times.

I think Lorenzo was already potentially looking at this issue in
relation to managing cpu_logical_map.

Cheers
---Dave