The PCI post card doesn't snag the address.  It just passively
listens, and latches whatever data comes down the wire after a
write to port 0x80.  So it *always* terminates on ISA.

No ISA?  that's a ways off, boards without the slot still
have LPC bus, which is just ISA with a few pins left off.

By that time you can count on P4's hyperthreading
pause instruction, maybe. I wonder if it's going to be possible 
forever to have a one-size-fits-all time delay function, from 
i386-16MHz to P4 and beyond?

If i'm not mistaken, the real magic is that the IO space isn't
cacheable, so you can count on 1 bus cycle per io instruction.

Question: why couldn't a (well known) PCI port be used?  It's
bus cycle would terminate faster than ISA, but should be constant as the
PCI bus speed, and the devsel timing of the addressed device?

(even crazier)  why not use the PCI config register(s)?  They're 
always there, and only vary by the fsb speed?

Jeremy

----- Original Message ----- 
From: "Christopher Stutts" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 11, 2002 11:37 AM
Subject: Re: IDE spinup....


> On Thu, 2002-04-11 at 13:47, Eric W. Biederman wrote:
> 
> > 
> > And this is what really worries me about it.  Will this continue
> > to work.  Will this really reach the ISA bus.  If it doesn't
> > reach the ISA bus how will the timing change?
> > 
> > I don't have a problem with a udelay() that just does an inb/outb for
> > timing reasons but...
> > 
> > Eric
> 
> On Intel PIIX4s, I/O to port 80 will go to the ISA bus, eat up time, and
> pound on a benign (POST) port.  But what if you don't have an ISA bridge
> or PCI POST card which snags that address?  
> 
> 
> 
> 

Reply via email to