From: Timur Tabi <timur@freescale.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, rdreier@cisco.com, jirislaby@gmail.com
Subject: Re: [PATCH v2] add function spin_event_timeout()
Date: Mon, 09 Mar 2009 13:16:48 -0500 [thread overview]
Message-ID: <49B55D10.7060707@freescale.com> (raw)
In-Reply-To: <1236614775.8389.692.camel@laptop>
Peter Zijlstra wrote:
> This changelog utterly fails to justify this interface. And to me it
> seems a rather bad one.
I'll update the commit to include a justification, but in the meantime,
let me answer your question.
The primary purpose of this macro is to provide a way for drivers to
poll a status register waiting for a bit to change. In most cases, this
bit should change very quickly, even within a few cycles. The timeout
is used as a way to easily deal with situations where the hardware is
misprogrammed such that the bit never changes.
Too often, developers do something like this:
while (!(in_be32(&ssi->sisr) & CCSR_SSI_SISR_RFF0));
If something goes wrong and RFF0 never gets set, then this loop will
never exit. So to encourage developers to do it the right way, and to
make it simpler to identify code which does this sort of thing, I'm
introducing spin_event_timeout().
> Why would we ever be wanting to spin in order of
> jiffies?
I picked jiffies because it seems straightforward, but I think I see
your point. It has two drawbacks:
1) It's too coarse of a time measurement. Most people will probably use
a value of 1 or 2.
2) It can't be used if interrupts are disabled, because then jiffies
won't be updated.
So I can switch that to using ndelay().
--
Timur Tabi
Linux kernel developer at Freescale
prev parent reply other threads:[~2009-03-09 18:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-09 15:18 [PATCH v2] add function spin_event_timeout() Timur Tabi
2009-03-09 15:31 ` Will Newton
2009-03-09 15:34 ` Timur Tabi
2009-03-09 16:06 ` Peter Zijlstra
2009-03-09 18:16 ` Timur Tabi [this message]
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=49B55D10.7060707@freescale.com \
--to=timur@freescale.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rdreier@cisco.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