public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

      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