udelay() broken for SMP cores?
Russell King - ARM Linux
linux at arm.linux.org.uk
Wed Apr 21 15:29:11 EDT 2010
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.
More information about the linux-arm-kernel
mailing list