Messages in this thread |  | | Subject | Re: [RFC] Improving udelay/ndelay on platforms where that is possible | | From | Marc Gonzalez <> | | Date | Thu, 16 Nov 2017 16:26:51 +0100 |
| |
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.
|  |