From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Doug Anderson <dianders@chromium.org>
Cc: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
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>,
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 23:22:07 +0000 [thread overview]
Message-ID: <20171116232206.GM31757@n2100.armlinux.org.uk> (raw)
In-Reply-To: <CAD=FV=U1FYVS34BYrSTV+0mP6ERhD=MBJGt8ni1bS2-r__Ta4A@mail.gmail.com>
On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez
> <marc_gonzalez@sigmadesigns.com> wrote:
> > On 16/11/2017 18:05, Russell King - ARM Linux wrote:
> >
> >> On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote:
> >>
> >>> Requesting 100 µs and spinning only 25 µs is still a problem,
> >>> don't you agree?
> >>
> >> Which is why, as I've said *many* times already, that drivers are written
> >> with leaway on the delays.
> >
> > A delay 75% too short is possible. Roger that.
> >
> >> I get the impression that we're just going around in circles, and what
> >> you're trying to do is to get me to agree with your point of view.
> >> That's not going to happen, because I know the history over about the
> >> last /24/ years of kernel development (which is how long I've been
> >> involved with the kernel.) That's almost a quarter of a century!
> >>
> >> I know how things were done years ago (which is relevant because we
> >> still have support in the kernel for these systems), and I also know the
> >> history of facilities like cpufreq - I was the one who took the work
> >> that Erik Mouw and others involved with the LART project, and turned it
> >> into something a little more generic. The idea of dynamically scaling
> >> the CPU frequency on ARM SoCs was something that the SoC manufacturer
> >> had not even considered - it was innovative.
> >>
> >> I know that udelay() can return short delays when used in a kernel with
> >> cpufreq enabled, and I also know that's almost an impossible problem to
> >> solve without going to a timer-based delay.
> >>
> >> So, when you think that sending an email about a udelay() that can be
> >> 10x shorter might be somehow new information, and might convince people
> >> that there's a problem, I'm afraid that it isn't really new information.
> >> The SA1110 cpufreq driver is dated 2001, and carries my copyright, and
> >> has the ability to make udelay()s 4x shorter or 4x longer depending on
> >> the direction of change.
> >>
> >> We've discussed solutions in the past (probably 10 years ago) about
> >> this, and what can be done, and the conclusion to that was, as Nicolas
> >> has said, to switch to using a timer-based delay mechanism where
> >> possible. Where this is not possible, the platform is stuck with the
> >> loops based delays, and their inherent variability and inaccuracy.
> >>
> >> These platforms have been tested with such a setup over many years.
> >> They work even with udelay() having this behaviour, because it's a
> >> known issue and drivers cater for it in ways that I've already covered
> >> in my many previous emails to you.
> >>
> >> These issues are known. They've been known for the last 15 odd years.
> >
> > So you've known for umpteen years that fixing loop-based delays is
> > intractable, yet you 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.
> >
> > In other words, "I'll consider your patch as soon as Hell freezes over".
> >
> > Roger that. I'll drop the subject then.
>
> Presumably, though, you could introduce a new API like:
>
> udelay_atleast()
>
> That was guaranteed to delay at least the given number of
> microseconds. Unlike the current udelay(), the new udelay_atleast()
> wouldn't really try that hard to get a delay that's approximately the
> one requested, it would just guarantee not to ever delay _less_ than
> the amount requested.
I look forward to reviewing your implementation.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
next prev parent reply other threads:[~2017-11-16 23:22 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 [this message]
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=20171116232206.GM31757@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--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=marc_gonzalez@sigmadesigns.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mturquette@baylibre.com \
--cc=nicolas.pitre@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).