udelay() broken for SMP cores?

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

On Wed, Apr 21, 2010 at 02:39:39AM -0700, skannan at codeaurora.org wrote:
> Is this an ARM specific decision? Cpufreq certainly supports per cpu scaling
> and x86 udelay uses per-CPU data. So your concern should apply for x86
> too. I had the same concern and was planning on bring it up in the cpufreq
> mailing list after I made sure I didn't misunderstand anything.

Well, x86 looks buggy in this regard as well - the loops_per_jiffy
value used is for a CPU which may not run the delay loop.

> Btw, your concern should apply for single core scaling too, right? Context
> switch can complete within max udelay (general - 5ms, ARM - 2ms) time and
> CPU could have jumped
> from lowest to highest speed in that time and mess up udelay. I didn't see
> any code in cpufreq that deferred scaling during udelay. So, that's something
> I plan to ask cpufreq folks too.

Well, the assumption is that the CPUs will be running at their fastest
speed at boot time, and therefore loops_per_jiffy will be calibrated
such that we guarantee _at least_ the asked-for delay - which is the
only guarantee udelay has.