[PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK tospeed-up boot

[santosh.shilimkar@ti.com (Santosh Shilimkar)]

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of Russell King -
> ARM Linux
> Sent: Friday, January 21, 2011 10:46 PM
> To: Rob Herring
> Cc: linux-omap at vger.kernel.org; Santosh Shilimkar; Linus Walleij;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK
> tospeed-up boot
>
[...]

>
> That means cpufreq scaling on SMP is broken then...  Why isn't
> cpufreq
> marked with a !SMP dependence or something similar (eg, depends on
> !SMP || CPU_INDEPENDENT_UDELAY)...  Maybe it should be.
>
Actually it's not broken but documented to use arch specific
per-cpu lpj with cpufreq scaling. And that update cab be
managed by arch specific cpufreq code based on the way
CPUs scale. That's how other arch including x86 doing it.
And global lpj can be update as well there which is not
done at this moment.

> > And delay.S uses the global loops_per_jiffy, not the per cpu
> value. The
> > only place I see the per cpu value get used is /proc/cpuinfo.
> >
> > Consider the following sequence:
> >
> > - scale down the cpu freq
> > - hot unplug a core
> > - hot plug a core
> >   - calls calibrate_delay and update the global loops_per_jiffy
> > - scale up the cpu freq
> > - udelay time is now much too short!!!
> >
> > So for that reason, I would just remove calibrate_delay
> unconditionally.
> > Better to have the 1% inaccuracy and longer delays at low
> frequency than
> > to have too short of a delay at high freq.
>
> As you've shown above, it makes not a blind bit of difference
> whether
> calibrate_delay() is called... on SMP the loops_per_jiffy will be
> wrong
> as soon as you start scaling no matter what.
>
Surely whichever way we should remove the recalibration otherwise
every time secondary cpus spend ~ 200 ms there.

Russell,
How do you like to address this?

Regards,
Santosh