udelay() broken for SMP cores?
Jamie Lokier
jamie at shareable.org
Wed Apr 21 15:52:25 EDT 2010
Russell King - ARM Linux wrote:
> 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.
I'm surprised it makes much difference to, say, 20MHz ARMs because you
could structure it as a nested loop, the inner one executed once per
microsecond and calibrated to 1us. The delays don't have to be super
accurate.
With a fixed-speed clock register known at compile time, the
calculation tends to constant-fold nicely, even for ns delays. Not
suitable for multi-target kernels but good on single-target.
-- Jamie
More information about the linux-arm-kernel
mailing list