Re: [RFC] Improving udelay/ndelay on platforms where that is possible

From: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	John Stultz <john.stultz@linaro.org>,
	Douglas Anderson <dianders@chromium.org>,
	Nicolas Pitre <nico@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Jonathan Austin <jonathan.austin@arm.com>,
	Arnd Bergmann <arnd@arndb.de>, Kevin Hilman <khilman@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Thibaud Cornic <thibaud_cornic@sigmadesigns.com>,
	Mason <slash.tmp@free.fr>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible
Date: Thu, 16 Nov 2017 16:26:51 +0100	[thread overview]
Message-ID: <1fa81694-7bd2-564b-e5b9-ae53b9ea6620@sigmadesigns.com> (raw)
In-Reply-To: <20171115131351.GE31757@n2100.armlinux.org.uk>

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.