Hello,
On Fri, May 19, 2000 at 05:31:37PM -0400, Jeff Garzik wrote:
> Andrey Savochkin wrote:
> > Original Donald's driver worked with udelay(100) until Donald himself
> > replaced the udelay by a delay implemented as a single inw()!
> > The available Intel's driver uses udelay(100).
> > NetBSD uses udelay(1).
First of all, I want to clarify the delay in Donald's version.
It was "eeprom_delay(100)" which was translated into "udelay(1)".
So, the udelay(1) is commonly used among drivers, whereas Intel's driver
really uses udelay(100)!
>
> Think about what Donald is doing, and remember that inw() is not really
> inw() here!
>
> Remember first that eepro100 is generally MMIO, so you the following is
> in effect:
> #define inw writew
>
> So, by replacing the udelay() with writew(), Donald not only introduces
> a small delay, but also posts any pending PCI writes. That may be
> important, may be nothing...
I see.
> In any case, if you were thinking about it, I wouldn't blindly replace
> writew() with udelay() or anything like that -- leave the writew() in
> there, and add an additional udelay() if the circumstances call for it.
> Excluding the writew() increases the potential for seeming EEPROM code
> flakiness, because few drivers have thus far been completely audited,
> updated, and tested for correct MMIO flush semantics.
I do not do it blindly! :-)
I've checked different available drivers, and all of them uses udelay()
without any readw(), except only one which uses inw() and is proven to have
problems. And some of these drivers have been working for years.
So, I feel quite confidential in removing readw() altogether and implementing
eeprom_delay via just udelay(1).
Best regards
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:18 EST