Main points (more details below):
- Tx underrun handling redone
- Give chip 10 us (instead of 10 ms) to reset
- Force a reset on VT6102 if necessary
Minor changes:
- use defined constants (especially MII), nuke mii_status_bits
- move clear_tally_counters() up so it can get inlined (pointed out by
Luca Barbieri)
- fix namespace pollution
According to the spec and my own tests, the flag previously labeled
IntrMIIChange in fact indicates a Tx (FIFO, desc, or buffer, the specs are
not quite sure about that) underrun. The flag we've been testing supposedly
indicates a Tx underrun, too, but I've never seen it trigger. -- The new
code tests for both. IntrMIIChange handling got dropped in the process.
Tx underrun is more difficult to trigger than the abort, but I have seen
the Tx threshold increase to 0x40 and then to 0x60. With 0x60, I have not
been able to produce any Tx underruns. The fact that increasing the
threshold fixes the error is another strong hint that the specs are correct
in this case.
The current driver will not only fail to recognize a Tx underrun, it will
actually treat it as an abort _and_ restart autonegotiation (the interrupt
status is 0208). Instead of testing for TxError (used to be called
TxAbort), the new driver now tests for TxAborted. The autonegotiation issue
was due to IntrMIIChange as discussed above.
For the first time ever, and only once, I have seen a Rhine-II that refused
to reset with the current driver. That was just enough to confirm that the
force reset flag actually works, so that's in now.
In the same function, I nuked the code that waited up to 10 ms for the chip
to reset. I have yet to see a chip reset in 10 ms after it had failed to
reset in 10 us. This change may cause a regression, but I doubt it. If you
know it does, holler.
I've got more changes in the works, this is a snapshot with some of the
better tested pieces.
Roger
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:29 EST