[PATCH 1/6] ARM: Add inline function smp_cpu() for early init testing
Tony Lindgren
tony at atomide.com
Thu Sep 2 20:08:18 EDT 2010
* Tony Lindgren <tony at atomide.com> [100902 12:20]:
> * Tony Lindgren <tony at atomide.com> [100902 10:35]:
> > * Russell King - ARM Linux <linux at arm.linux.org.uk> [100902 10:00]:
> > > On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
> > >
> > > > --- a/arch/arm/include/asm/smp_plat.h
> > > > +++ b/arch/arm/include/asm/smp_plat.h
> > > > @@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
> > > > #define UP(instr...) _str(instr)
> > > > #endif
> > > >
> > > > +static inline int smp_on_up(void)
> > > > +{
> > > > +#ifdef CONFIG_SMP_ON_UP
> > > > + int smp_on_up;
> > > > +
> > > > + asm( \
> > > > + SMP(mov %0, #0) \
> > > > + UP(mov %0, #1) \
> > > > + : "=r" (smp_on_up));
> > > > +
> > > > + return smp_on_up;
> > > > +#else
> > > > + return 0;
> > > > +#endif
> > >
> > > I think this is the wrong approach - rather than a function which tells us
> > > just if we are a SMP kernel running on UP, why not something which returns
> > > whether we're running on SMP and use that to eliminate some of these ifdefs?
> >
> > Sure. Will has something like this in his patches:
> >
> > static inline int cpu_is_part_of_mp_system(void)
> > {
> > u32 mpidr;
> > asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
> > return (mpidr >> 31) ? !(mpidr >> 30) : 0;
> > }
> >
> > BTW, so far looks like we should only need this during init to set up things.
>
> Here's this one updated to replace smp_cpu() instead of smp_on_up().
Heh, turns out there's a bit of a bug in the code snippet above :) It should
be !((mpidr >> 30) & 1) instead, otherwise it always returns 0.
Regards,
Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smp-cpu.patch
Type: text/x-diff
Size: 2048 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100902/08f99cc9/attachment.bin>
More information about the linux-arm-kernel
mailing list