> -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > Sent: Sunday, January 23, 2011 2:50 AM > To: Santosh Shilimkar > Cc: Rob Herring; linux-omap@xxxxxxxxxxxxxxx; Linus Walleij; linux- > arm-kernel@xxxxxxxxxxxxxxxxxxx > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
