From: Pavel Machek <pavel@ucw.cz>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>,
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, 7 Dec 2017 13:43:26 +0100 [thread overview]
Message-ID: <20171207124326.GC24547@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20171115131351.GE31757@n2100.armlinux.org.uk>
> On Wed, Nov 15, 2017 at 01:51:54PM +0100, Marc Gonzalez wrote:
> > On 01/11/2017 20:38, Marc Gonzalez wrote:
> >
> > > OK, I'll just send my patch, and then crawl back under my rock.
> >
> > Linus,
> >
> > As promised, the patch is provided below. And as promised, I will
> > no longer bring this up on LKML.
> >
> > FWIW, I have checked that the computed value matches the expected
> > value for all HZ and delay_us, and for a few clock frequencies,
> > using the following program:
> >
> > $ cat delays.c
> > #include <stdio.h>
> > #define MEGA 1000000u
> > typedef unsigned int uint;
> > typedef unsigned long long u64;
> > #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
> >
> > static const uint HZ_tab[] = { 100, 250, 300, 1000 };
> >
> > static void check_cycle_count(uint freq, uint HZ, uint delay_us)
> > {
> > uint UDELAY_MULT = (2147 * HZ) + (483648 * HZ / MEGA);
> > uint lpj = DIV_ROUND_UP(freq, HZ);
> > uint computed = ((u64)lpj * delay_us * UDELAY_MULT >> 31) + 1;
> > uint expected = DIV_ROUND_UP((u64)delay_us * freq, MEGA);
> >
> > if (computed != expected)
> > printf("freq=%u HZ=%u delay_us=%u comp=%u exp=%u\n", freq, HZ, delay_us, computed, expected);
> > }
> >
> > int main(void)
> > {
> > uint idx, delay_us, freq;
> >
> > for (freq = 3*MEGA; freq <= 100*MEGA; freq += 3*MEGA)
> > for (idx = 0; idx < sizeof HZ_tab / sizeof *HZ_tab; ++idx)
> > for (delay_us = 1; delay_us <= 2000; ++delay_us)
> > check_cycle_count(freq, HZ_tab[idx], delay_us);
> >
> > return 0;
> > }
> >
> >
> >
> > -- >8 --
> > Subject: [PATCH] ARM: Tweak clock-based udelay implementation
> >
> > In 9f8197980d87a ("delay: Add explanation of udelay() inaccuracy")
> > Russell pointed out that loop-based delays may return early.
> >
> > On the arm platform, delays may be either loop-based or clock-based.
> >
> > This patch tweaks the clock-based implementation so that udelay(N)
> > is guaranteed to spin at least N microseconds.
>
> As I've already said, I don't want this, because it encourages people
> to use too-small delays in driver code, and if we merge it then you
> will look at your data sheet, decide it says "you need to wait 10us"
> and write in your driver "udelay(10)" which will break on the loops
> based delay.
>
> 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.
udelay() needs to be consistent across platforms, and yes, udelay(10)
is expected to delay at least 10usec.
If that is not true on your platform, _fix your platform_. But it is
not valid to reject patches fixing other platforms, just because your
platform is broken.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2017-12-07 12:43 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
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 [this message]
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=20171207124326.GC24547@atrey.karlin.mff.cuni.cz \
--to=pavel@ucw.cz \
--cc=arnd@arndb.de \
--cc=boris.brezillon@free-electrons.com \
--cc=dianders@chromium.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--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=marc_gonzalez@sigmadesigns.com \
--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=thibaud_cornic@sigmadesigns.com \
--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).