From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc_gonzalez@sigmadesigns.com (Marc Gonzalez) Date: Thu, 16 Nov 2017 16:26:51 +0100 Subject: [RFC] Improving udelay/ndelay on platforms where that is possible In-Reply-To: <20171115131351.GE31757@n2100.armlinux.org.uk> References: <20171101175325.2557ce85@alans-desktop> <4b707ce0-6067-ab36-e167-1acf348d26bf@free.fr> <11393e07-b042-180c-3bcd-484bf51eada6@sigmadesigns.com> <20171115131351.GE31757@n2100.armlinux.org.uk> Message-ID: <1fa81694-7bd2-564b-e5b9-ae53b9ea6620@sigmadesigns.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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.