[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzy9=RtFRuJhFbF+PL_PCrkZsKtAKrq6WJo1z9eW9gLSA@mail.gmail.com>
Date: Tue, 31 Oct 2017 09:44:20 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Marc Gonzalez <marc_gonzalez@...madesigns.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
John Stultz <john.stultz@...aro.org>,
Douglas Anderson <dianders@...omium.org>,
Nicolas Pitre <nico@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Will Deacon <will.deacon@....com>,
Jonathan Austin <jonathan.austin@....com>,
Arnd Bergmann <arnd@...db.de>,
Kevin Hilman <khilman@...nel.org>,
Russell King <linux@....linux.org.uk>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...eaurora.org>, Mason <slash.tmp@...e.fr>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible
On Tue, Oct 31, 2017 at 9:15 AM, Marc Gonzalez
<marc_gonzalez@...madesigns.com> wrote:
>
> On arm32, it is possible to set up udelay() to be clock-based.
I'm not sure why this is discussed as some kind of generic problem.
Just do what x86-64 already does. We use the TSC, and ndelay() does
the right thing too.
I've not checked precision, but it should be close to the TSC update
frequency. So we're talking tens of megahertz.
Does it work on all PC's? No. It's only half-way reliable on the ones
where the TSC frequency doesn't change. So there are no *guarantees*.
Linus
Powered by blists - more mailing lists