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

[Rene Herman <rene.herman@keyaccess.nl>]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/