Re: [RFC] Improving udelay/ndelay on platforms where that is possible

[Marc Gonzalez]

On 15/11/2017 14:13, Russell King - ARM Linux wrote:

> udelay() needs to offer a consistent interface so that drivers know
> what to expect no matter what the implementation is.  Making one
> implementation conform to your ideas while leaving the other
> implementations with other expectations is a recipe for bugs.
> 
> If you really want to do this, fix the loops_per_jiffy implementation
> as well so that the consistency is maintained.

Hello Russell,

It seems to me that, when using DFS, there's a serious issue with loop-based
delays. (IIRC, it was you who pointed this out a few years ago.)

If I'm reading arch/arm/kernel/smp.c correctly, loops_per_jiffy is scaled
when the frequency changes.

But arch/arm/lib/delay-loop.S starts by loading the current value of
loops_per_jiffy, computes the number of times to loop, and then loops.
If the frequency increases when the core is in __loop_delay, the
delay will be much shorter than requested.

Is this a correct assessment of the situation?

(BTW, does arch/arm/lib/delay-loop.S load the per_cpu loops_per_jiffy
or the system-wide variable?)

Should loop-based delays be disabled when CPUFREQ is enabled?

Regards.