On Mon, 22 May 2000, Dragan Stancevic wrote:
> On Fri, May 19, 2000, Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> ; 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 think that inw there is just for timing purposes since the
> card/eeprom specification doesnt require anything else than a delay.
>
> I don't think using inw for timing is a good idea especially
> now that the driver tries to use MMIO and inw is redefined in the
> driver to use memory instead of io ports, the timing frequency
> changes so you might not satisfy the minimal clock frequency
> specification.
The very old code used eeprom_delay(100), which mean 100ns, *not* 100usec.
The 33Mhz PCI read alone was more than enough delay. Adding an extra read
assured that it would still with 66Mhz chips, and it insured that
both memory and I/O operations would have a bus arbitration cycle.
Donald Becker becker@scyld.com
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403
-
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:22 EST