[PATCH v2 2/4] zynq: move static peripheral mappings
josh.cartwright at ni.com
Tue Oct 23 17:24:19 EDT 2012
On Tue, Oct 23, 2012 at 05:17:42PM -0400, Nick Bowler wrote:
> On 2012-10-23 15:53 -0500, Josh Cartwright wrote:
> > On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote:
> > > On 10/23/2012 09:50 AM, Arnd Bergmann wrote:
> > > > On Monday 22 October 2012, Josh Cartwright wrote:
> > > >> -#define SCU_PERIPH_PHYS 0xF8F00000
> > > >> -#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS
> > > >> +#define SCU_PERIPH_PHYS 0xF8F00000
> > > >> +#define SCU_PERIPH_SIZE SZ_8K
> > > >> +#define SCU_PERIPH_VIRT (PL310_L2CC_VIRT - SCU_PERIPH_SIZE)
> > > >
> > > > And your patch 3 already obsoletes this mapping.
> > >
> > > Actually, it's probably still needed. The smp platform code typically
> > > reads the number of cores from the SCU and the mapping has to be in
> > > place before ioremap is up. I don't think there is an architected way to
> > > get the number of cores, but it would be nice to avoid this early SCU
> > > access. We could also mandate getting the core count from DT instead.
> > >
> > > Also, the physical address can be read with this on A9's:
> > >
> > > asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
> > For the sake of the zynq cleanups, I think it may still make sense to
> > remove the SCU peripheral mappings for now. By the time we're ready to
> > push in SMP support for zynq, maybe we can tackle the problem of how to
> > solve the SCU mapping problem generically.
> Then the static mapping can be removed if and when the we "solve the SCU
> mapping problem generically". There's no point in removing it until
> then since it doesn't cause any actual problems, does it?
That's also fine with me as well. I'm not strongly opinionated, and not
convinced it really matters much.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the linux-arm-kernel