Why call calibrate_delay() in smp.c: secondary_start_kernel()

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Tue, Jan 18, 2011 at 03:46:54PM +0530, Santosh Shilimkar wrote:
> I did send a patch on the same some time back but the conclusion
> was we still need to have calibration.
> 
> Have one more patch do deal with it so that platform can choose
> if they like to skip. My mailer might screw the patch hence attaching
> the same

Actually, the secondary cores probably get a far more accurate lpj
than the primary core as they don't have the interference from the
timer interrupt.  So - if we care - we probably want to update the
primary lpj with the secondary's calibration value at boot.

On the measurements I've made a couple of weeks ago, the lpj value
can be .7% too slow, resulting in udelay() giving shorter than
requested delays.  I asked Linus about that, and he's happy with
that figure.

So the myth which floats around on various lists about udelay() giving
at least the requested delay is just that - a myth.  It has always
given _approximately_ the requested delay on all architectures with
software loop based implementations (as well as, according to Linus,
some x86 tsc implementations of udelay.)