From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Santosh Shilimkar) Date: Sun, 23 Jan 2011 12:55:25 +0530 Subject: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCKtospeed-up boot In-Reply-To: <20110122212017.GA17725@n2100.arm.linux.org.uk> References: <1295516579-10225-1-git-send-email-santosh.shilimkar@ti.com> <4D385155.4050301@gmail.com> <43c027bd53818ab19bdc1c823aa21ea4@mail.gmail.com> <4D38641E.2000301@gmail.com> <4D399F74.9050302@gmail.com> <20110121171555.GB30823@n2100.arm.linux.org.uk> <20110122212017.GA17725@n2100.arm.linux.org.uk> Message-ID: <8d59200413b98810a4e7c2039ffb9a77@mail.gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > -----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