udelay() broken for SMP cores?

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

On Wed, Apr 21, 2010 at 11:00:08AM +0100, Jamie Lokier wrote:
> Russell King - ARM Linux wrote:
> > 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.
> 
> That's an interesting and not altogether reliable assumption.

That depends which bit you're talking about.  udelay() must give you the
delay you asked for, or a longer delay.  If it gives you a shorter delay,
it's buggy plain and simple.

> On a device I'm working with, we just read a fixed-speed clock
> register in a loop.  It's slower than the CPU register loop, but given
> udelay counts in great big slow _microsecond_ delays (how quaint! ;-)
> that's fine.

We could go to ns delays, but then we have a big problem - the cost of
calculating the number of loops starts to become significant compared to
the delays - and that's a quality of implementation factor.  In fact,
the existing cost has always been significant for short delays for
slower (sub-100MHz) ARMs.