Messages in this thread | | | Date | Thu, 16 Nov 2017 12:00:01 -0500 (EST) | From | Nicolas Pitre <> | Subject | Re: [RFC] Improving udelay/ndelay on platforms where that is possible |
| |
On Thu, 16 Nov 2017, Marc Gonzalez wrote:
> On 16/11/2017 17:47, Nicolas Pitre wrote: > > > 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
| |