On Thu, 16 Nov 2017, Marc Gonzalez wrote:

On 16/11/2017 17:47, Nicolas Pitre wrote:

quoted

Look at cpufreq_callback() in arch/arm/kernel/smp.c.

Are you pointing at the scaling of loops_per_jiffy done in that function?

As I wrote earlier:

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.

The callback is invoked with CPUFREQ_PRECHANGE before the actual 
frequency increase. If your CPU clock is per core, then you won't be in 
the middle of the delay loop when this happens, unless you change your 
core clock from an interrupt handler.

If your CPU clock is common to all cores then you are screwed. In that 
case the only way out is a hardware timer based delay.


Nicolas