Messages in this thread | | | Subject | Re: [PATCH] Re: time() glitch on 2.4.18: solved | From | Alan Cox <> | Date | 06 Nov 2002 13:25:24 +0000 |
| |
On Wed, 2002-11-06 at 12:47, Richard B. Johnson wrote: > udelay() would work memory/read/write is entirely different from I/O > port read/write even though PWB traces are shared. But that might > result in wasted CPU cycles.
udelay actually makes a lot lot more sense than the current _p stuff. Legacy-free hardware might not do what is expected with port 0x80 eventually and still have stuff using _p > > This works in all cases in machines I have tested. I can't test everything > but, depending upon whether or not the forces a cache-line refill, the > delay can be from 200 ns to over 800 ns. I have a single instance of this, > and call it, rather than doing in-line. This adds a further delay.
Thats a call/return stack break. That does delay damage in excess of what you actually want and the wrong places. udelay does the right thing
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |