linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Cc: 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>,
	Russell King <linux@arm.linux.org.uk>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>, Mason <slash.tmp@free.fr>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible
Date: Wed, 1 Nov 2017 12:17:55 -0700	[thread overview]
Message-ID: <CA+55aFx86WR3wFibq6MUtSCvVG9Ty-m=tAFh0XHSfu192fFeiA@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFxxH0HE9SfUoLVqsvDKO0PfeM+vSoDmbXQv85yJcPZoPQ@mail.gmail.com>

On Wed, Nov 1, 2017 at 12:09 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Yes, there is a *fallback* for when somebody doesn't do ndelay() at
> all, but that doesn't make it the default.
>
> It's just a "the architecture didn't implement ndelay at all, we'll
> work around it".

Side  note: I will continue to claim that anybody who thinks they need
ndelay() needs to rethink their position anyway, due to all the issues
I did already bring up.

So I'd say that pretty much 100% of all ndelay() users are just wrong.
If you are doing a driver that needs that kind of delay granularity,
you had better already know exactly how long it takes to read the
status register, and just do that instead.

And if you don't know how long it takes to read a status register, you
have no business thinking that you need ndelay(). You probably ended
up reading one piece of hardware doc ("the sample-and-hold register
takes 200ns to settle") without then reading the other low-level
hardware documentation that talks about the timings of the chip
accesses from the host side.

                 Linus

  reply	other threads:[~2017-11-01 19:17 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 [this message]
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='CA+55aFx86WR3wFibq6MUtSCvVG9Ty-m=tAFh0XHSfu192fFeiA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=arnd@arndb.de \
    --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@arm.linux.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=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).