Messages in this thread | | | Date | Tue, 10 Mar 2009 10:50:15 -0500 | From | Timur Tabi <> | Subject | Re: [PATCH v4] introduce macro spin_event_timeout() |
| |
Alan Cox wrote:
> NAK this - on a lot of platforms 1uS is the wrong timescale. Also we > shouldn't be encouraging this kind of polling by making it very easy to > write.
Well, I can agree that the time scale might be wrong on some platforms. The original version of spin_event_timeout() used jiffies, but some people said that a jiffy is too long of a timescale, so I changed it to udelay.
However, I disagree about the encouragement part. Polling a register until a status bit changes is a common task that cannot be handled any other way. If the status bit change does not generate an interrupt, but the wait for the change takes a few microseconds, what else are you going to do?
The way I see it, I'm just extending the idea behind cpu_relax(). Just doing a search for cpu_relax shows dozens, maybe hundreds, of drivers doing stuff like this:
while((inb(ioaddr+DAYNA_CARD_STATUS)&DAYNA_TX_READY)==0) cpu_relax();
This code doesn't even have a timeout! In fact, I'd say that at least 90% of all uses of cpu_relax() are in a while loop reading some register without a timeout.
Ironically, in the situations where there is a timeout, the drivers use jiffies, not a delay.
Frankly, I just don't see how spin_event_timeout() is not an improvement over the current code that drivers use.
-- Timur Tabi Linux kernel developer at Freescale
| |