Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

Rene Herman
2007-12-11T09:52:10Z

On 11-12-07 08:40, Paul Rolland wrote:

> Well, if the delay is so much unspecified, what about _reading_ port 0x80 ?
> Will the delay be shorter ?

The delay is completely and fully specified in terms of the ISA/LPC clock
which certainly for anything modern means a fixed, unchanging value
(something very close to 1 us) and even on older PCs that allow some
tweaking just means a delay synced to the actual bus clock which is what the
_p variants should normally want to accomplish.

Yes, as far as I'm aware, an inb() means the same delay but clobbers
register al meaning you need a bloating save/restore sequence around it.

> And if so, what about reading port 0x80 and writing the value back ? inb
> al,0x80 outb 0x80,al

See? Moreover, this also only makes sense if there's in fact something
responding to reads at 0x80 and with port 0x80 being a well-known legacy PC
port, a POST monitor would be just about that and writing to _that_ would
seem unlikely to have any ill effects other than turning your POST board LED
display into a christmas tree. The problem more likely is some piece of
hardware getting upset at LPC bus aborts and your suggestion wouldn't fix that.

In earlier incarnations of this thread it's been reported that various
implementations of the legacy PC timer, DMA controller and PIC needed the
delay but just replacing the outb with a udelay(1) would seem very likely to
have the desired effect also for those.

The only problem with _that_ is that you need a calibrated timing loop first
which means not-very-early boot (ie, not while you try to program the timer
to calibrate the loop for example). Pavel Machek already posted a patch,
although with an overly pessimistic delay value.

The problem here is with an x86-64 machine that very likely does not need
any delay at all in fact. One thing to do would be to make _any_ delay
dependent on 32-bit but given that 64-bit machines can run 32-bit kernels
this doesn't fix things fully, although it probably does in practice.

Keying of DMI for any delay could be possible. But if the simple udelay(1)
just works, all the better.

Rene.