[PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCKtospeed-up boot

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Sunday, January 23, 2011 2:50 AM
> To: Santosh Shilimkar
> Cc: Rob Herring; linux-omap at vger.kernel.org; Linus Walleij; linux-
> arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] ARM: smp: Introduce
> ARCH_HAS_COMMON_CORES_CLOCKtospeed-up boot
>
> On Sat, Jan 22, 2011 at 01:14:21PM +0530, Santosh Shilimkar wrote:
> > 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?
>
> Well, the last piece of the puzzle which needs consideration is that
> omitting the calibration means that it produces user-visible
> /proc/cpuinfo changes.  I can't say what effect that has.  So, I
> think we need to do something about that to ensure that userspace
> won't be impacted should they be using the information in there.
>
Ok. /proc/cpuinfo uses the per-cpu lpj which gets updated as mentioned
as part of the arch cpufreq drivers. So this not seems to be the
problem.

> Maybe we need to initialize the secondary CPU bogomips values
> accordingly?  Maybe zero is acceptable to mark that the calculation
> hasn't been done?  Dunno.
The only issue is global lpj not getting updated as part of CPU
scaling. This is anyway broken today on SMP machines even without
cpufreq. It's getting corrected as part of the hotplug path if
recalibration is carried out. And same value gets copied to
per-cpu lpj for the secondary cores.

The above gets completely wrong if the individual CPUs can
scale with different speed.

Since per-cpu lpj is suppose to be taken care by scaling
Code, /proc/cpuinfo will get updated with right information.

With this, I think we could safely skip secondary cpu
calibration.

Regards,
Santosh