Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

["David P. Reed" <dpreed@reed.com>]

Alan -

I dug up a DP83901A SNIC datasheet in a quick Google search, while that 
wasn't the only such chip, it was one of them.  I can forward the PDF 
(the www.alldatasheet.com site dynamically creates the download URL), if 
anyone wants it.
The relevant passage says, in regard to delaying between checking the 
CRDA addresses to see if a dummy "remote read" has been executed., and 
in regard perhaps to other card IO register loops: 
                                                         

    TIME BETWEEN CHIP SELECTS
                                                                 
    The SNIC requires that successive chip selects be no
    closer                                                     
    than 4 bus clocks (BSCK) together. If the condition is
    violat-                                           
    ed the SNIC may glitch ACK. CPUs that operate from pipe-
    lined instructions (i e 386) or have a cache (i e 486) can
    execute consecutive I O cycles very quickly The solution is
    to delay the execution of consecutive I O cycles by either
    breaking the pipeline or forcing the CPU to access outside
    its cache.

The NE2000 as I recall had no special logic on the board to protect the 
chip from successive chip selects that were too close - which is the 
reason for the problem. Clearly an out to port 80 takes more than 4 ISA 
bus clocks, so that works if the NE2000 is on the ISA bus,   On the 
other hand, there are other ways to delay more than 4 ISA bus clocks.  
And as you say, one needs a delay for this chip that relates to the 
chip's card's bus's clock speed, not absolute time.

Alan Cox wrote:
>> As well you should. I am honestly curious (for my own satisfaction) as 
>> to what the natsemi docs say the delay code should do  (can't imagine 
>> they say "use io port 80 because it is unused").  I don't have any 
>>     
>
> They say you must allow 4 bus clocks for the address decode. They don't
> deal with the ISA side as the chip itself has no ISA glue.
>
>
>   
>> copies anymore. But mere curiosity on my part is not worth spending a 
>> lot of time on - I know you are super busy.   If there's a copy online 
>> at a URL ...
>>     
>
> Not that I know of. There may be. A good general source of info is Russ
> Nelson's old DOS packet driver collection.
>
>
>