2.2.11 and tulip.c issues

[Donald Becker]

On Thu, 19 Aug 1999, Aron Griffis wrote:

> On Thu, 19 Aug 1999, Robert G. Brown wrote:
> > Unfortunately, if the ioport doesn't shift I'm going to guess that the
> > patch doesn't help.  Its beginning to sound more like some kernel
> > resource is overlapping -- perhaps a memory-mapped region?  -- with the
...
> Thanks for the attention to the problem, Robert.  I consulted with the
> guy here that wrote the tulip driver for Tru64, and he made some
> recommendations, none of which changed the behavior I'd been seeing.

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.

[[ Please hold any follow-up discussions about Tulip or general driver
issues on linux-tulip@beowulf.gsfc.nasa.gov instead of on the linux-kernel
list. ]]

Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html