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.
