From: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Doug Anderson <dianders@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Jonathan Austin <jonathan.austin@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
Michael Turquette <mturquette@baylibre.com>,
Nicolas Pitre <nico@linaro.org>,
Stephen Boyd <sboyd@codeaurora.org>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Kevin Hilman <khilman@kernel.org>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Mason <slash.tmp@free.fr>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible
Date: Wed, 1 Nov 2017 20:28:18 +0100 [thread overview]
Message-ID: <475b9543-cc97-41b3-2924-0724fddee392@free.fr> (raw)
In-Reply-To: <20171101092618.GN9463@n2100.armlinux.org.uk>
On 01/11/2017 10:26, Russell King - ARM Linux wrote:
> On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
>
>> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds wrote:
>>
>>> So I'm very much open to udelay improvements, and if somebody sends
>>> patches for particular platforms to do particularly well on that
>>> platform, I think we should merge them. But ...
>>
>> If I'm reading this all correctly, this sounds like you'd be willing
>> to merge <https://patchwork.kernel.org/patch/9429841/>. This makes
>> udelay() guaranteed not to underrun on arm32 platforms.
>
> That's a mis-representation again. It stops a timer-based udelay()
> possibly underrunning by one tick if we are close to the start of
> a count increment. However, it does nothing for the loops_per_jiffy
> udelay(), which can still underrun.
It is correct that improving the clock-based implementation does strictly
nothing for the loop-based implementation.
Is it possible to derive a higher bound on the amount of under-run when
using the loop-based delay on arm32?
> My argument against merging that patch is that with it merged, we get
> (as you say) a udelay() that doesn't underrun _when using a timer_
> but when we end up using the loops_per_jiffy udelay(), we're back to
> the old problem.
>
> My opinion is that's bad, because it encourages people to write drivers
> that rely on udelay() having "good" behaviour, which it is not guaranteed
> to have. So, they'll specify a delay period of exactly what they want,
> and their drivers will then fail when running on systems that aren't
> using a timer-based udelay().
>
> If we want udelay() to have this behaviour, it needs to _always_ have
> this behaviour irrespective of the implementation. So that means
> the loops_per_jiffy version also needs to be fixed in the same way,
> which IMHO is impossible.
Let's say some piece of HW absolutely, positively, unequivocally,
uncompromisingly, requires a strict minimum of 10 microseconds
elapsing between operations A and B.
You say a driver writer must not write udelay(10);
They have to take into account the possibility of under-delay.
How much additional delay should they add?
10%? 20%? 50%? A percentage + a fixed quantity?
If there is an actual rule, then it could be incorporated in the
loop-based implementation?
If it is impossible to say (as Linus hinted for some platforms)
then this means there is no way to guarantee a minimal delay?
Regards.
next prev parent reply other threads:[~2017-11-01 19:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 16:15 [RFC] Improving udelay/ndelay on platforms where that is possible Marc Gonzalez
2017-10-31 16:44 ` Linus Torvalds
2017-10-31 16:56 ` Russell King - ARM Linux
2017-10-31 17:45 ` Linus Torvalds
2017-10-31 17:58 ` Linus Torvalds
2017-11-01 0:23 ` Doug Anderson
2017-11-01 9:26 ` Russell King - ARM Linux
2017-11-01 15:53 ` Doug Anderson
2017-12-07 12:31 ` Pavel Machek
2017-11-01 19:28 ` Marc Gonzalez [this message]
2017-11-01 20:30 ` Russell King - ARM Linux
2017-10-31 16:46 ` Russell King - ARM Linux
2017-11-01 17:53 ` Alan Cox
2017-11-01 19:03 ` Marc Gonzalez
2017-11-01 19:09 ` Linus Torvalds
2017-11-01 19:17 ` Linus Torvalds
2017-11-01 19:38 ` Marc Gonzalez
2017-11-15 12:51 ` Marc Gonzalez
2017-11-15 13:13 ` Russell King - ARM Linux
2017-11-16 15:26 ` Marc Gonzalez
2017-11-16 15:36 ` Russell King - ARM Linux
2017-11-16 15:47 ` Marc Gonzalez
2017-11-16 16:08 ` Nicolas Pitre
2017-11-16 16:26 ` Marc Gonzalez
2017-11-16 16:32 ` Russell King - ARM Linux
2017-11-16 16:42 ` Marc Gonzalez
2017-11-16 17:05 ` Russell King - ARM Linux
2017-11-16 21:05 ` Marc Gonzalez
2017-11-16 22:15 ` Doug Anderson
2017-11-16 23:22 ` Russell King - ARM Linux
2017-11-20 17:38 ` Doug Anderson
2017-11-20 18:31 ` Russell King - ARM Linux
2017-11-16 16:47 ` Nicolas Pitre
2017-11-16 16:51 ` Marc Gonzalez
2017-11-16 17:00 ` Nicolas Pitre
2017-12-07 12:43 ` Pavel Machek
2017-11-15 18:45 ` Doug Anderson
2017-11-01 19:36 ` Alan Cox
2017-11-01 19:39 ` Thomas Gleixner
2017-11-01 19:48 ` Baruch Siach
2017-11-02 16:12 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=475b9543-cc97-41b3-2924-0724fddee392@free.fr \
--to=marc_gonzalez@sigmadesigns.com \
--cc=arnd@arndb.de \
--cc=dianders@chromium.org \
--cc=john.stultz@linaro.org \
--cc=jonathan.austin@arm.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mturquette@baylibre.com \
--cc=nico@linaro.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sboyd@codeaurora.org \
--cc=slash.tmp@free.fr \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).