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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux