Davicom 9102[A] support from *tulip* Driver ?

[Donald Becker]

On Fri, 12 Nov 1999, Keith Owens wrote:

> Interesting the way that Davicom handle changes to CSR6.  All changes
> are done via
> 
> /*
>   Update CR6 vaule
>   Firstly stop DM910X , then written value and start
> */
> static void update_cr6(u32 cr6_data, u32 ioaddr)
>  {
>   u32 cr6_tmp;
>   
>   cr6_tmp=cr6_data & ~0x2002;           /* stop Tx/Rx */
>   outl(cr6_tmp, ioaddr+DCR6);
>   DELAY_5US;
>   outl(cr6_data, ioaddr+DCR6);
>   cr6_tmp=inl(ioaddr+DCR6);
>   /* printk("CR6 update %x ", cr6_tmp); */
>  }
> 
> Rather like the kludge I had to put into the Xircom Cardbus driver.
> Without some delay, the MAC setup frame was being lost.

This is either superstition, or points out a horrible timing flaw in the
chip.

In the real Tulip and most work-alike chips there are some CSR6 settings
that only take _effect_ after the transmitter or receiver has
stopped/paused, and some that may only be _changed_ with the relavent unit
stopped (Note 1).  Typically it is apparent (I initially wrote "obvious",
but perhaps it's not *that* clear) why the "changed" restriction exists.  An
example is the transmit threshold setting.  If you change this while a
packet is being loaded into the Tx FIFO, you might get a glitch that
triggers an early Tx.  This specific restriction is not a problem in the
current driver because we only change the threshold while the transmitter is
stopped due to a Tx underrun error.

The Xircom documentation states (Note 2) that the Rx and Tx
start bits may only be set when they are cleared.  That means to change any
setting requires shutting down both Rx and Tx, and waiting for the chip
sections to actually stop.  That could take quite a long time, since the
current reception or transmission must complete.

Note that the code above is *not* implementing this restriction, it's just
wasting a few microseconds, not the milliseconds that it might take to
finish a packet.  It might appear to work, since since the chip usually
stops quickly, but it is just programming by superstition.

Note1: For instance the Rx mode bits don't take effect until the next Rx
packet.  They can actually be changed at any time, but should only be
changed while the Rx unit is stopped if you care about precise filtering.
We don't care about this since the kernel is sleazy about the mode
synchronization anyway.  The only case where this really matters is
switching out of promiscuous mode, where there might be a few dribble
packets when the protocol stack isn't expecting them.

Note 2: The Xircom documentation likely incorrect on this point.  Most tulip
clones have obviously cribbed from the Digital manual.  Sometimes the
phrases are identical, which is especially bad because the Tulip manual
is sometimes imprecise or even misleading about some details (especially
CSR6 and CSR9 settings).

Donald Becker
Scyld Computing Corporation, and
USRA-CESDIS,   becker@cesdis.gsfc.nasa.gov