2.2.11 and tulip.c issues

[Aron Griffis]

Donald,

I would be happy to try your test version and report if it fixes the
problem for me.  However if it's dependent on Linus' new resource
allocation, I will have to wait for 2.3.x to be able to compile on
Alpha.

I also forwarded your message to Kirt Gillum, the author of the Tru64
tulip driver.  I thought he might be interested in it, however he
might not have the time to comment.

Aron

On Fri, 20 Aug 1999, Donald Becker wrote:

> The current Tulip driver uses I/O space accesses to registers.  I've
> known for a while that using memory space would produce better code
> on machines like the Alpha and PPC that don't have native I/O space
> instructions.
> 
> It turns out that using memory space results in dramatically better
> performance on certain x86 SMP machines as well.  The trivial single
> processor performance improvement is multiplied because the tiny
> number of I/O writes occur in locked critical regions.  Using memory
> space allows the writes to "complete" into the write buffer
> immediately, instead of waiting until the PCI bus transaction has
> finished.
> 
> I have a test version of the Tulip driver that uses memory
> operations.  This might fix the problem above, and will likely avoid
> the need for udelay(2) on the PNIC to work around the
> write-buffer-delay bug.
> 
> This is a major change, and I'll have to test a lot of boards.  I
> expect the biggest issue to be timing changes for the serial bit
> streams used to read the EEPROM and MII registers.  I initially
> validated the original code by probing the traces on the circuit
> board and checking that actual bit rate was in-spec.  Since then
> I've used a software approach (reading a real-time counter) to
> verify that the bit rate hasn't changed.  The software method may no
> longer be accurate with the write buffers in the memory subsystem
> that arbitrarily changes the timing of writes.
> 
> A second issue is checking that all of the chips are reliable with
> memory operations.  Some chips, notably the VIA Rhine, were only
> design-tested with I/O operations.

-- 
Aron Griffis            Compaq Computer Corporation, ZKO3-3/T30
Tru64 Hardware Support  110 Spitbrook Rd, Nashua, NH  03062
603/884-1276            http://bigfoot.com/~agriffis/