On 15-12-07 14:27, Ingo Molnar wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not
submitted, only for 32-bit and discussion) the idea of which might be
the best we can do?
how about doing a known-NOP chipset cycle? For example:
inb(PIC_SLAVE_IMR)
An inb is annoying in that it clobbers register al (well, with an inline
native_io_delay it is at least) and more importantly -- the timing of this
is going to vary wildly. We really want a register that is effectively
guaranteed to be unused so that it dies on ISA/LPC or we might get _much_
faster PCI only decodes. Even reading port 0x80 itself varies wildly:
http://lkml.org/lkml/2007/12/12/309
? I.e. instead of trying to find an unused port, lets try to find a
known-used platform register that has no side-effects if read. Use it
unconditionally during early bootup and change it to an udelay after
calibration. (or use it after early bootup too if a boot parameter has
been specified) Or something like this.
It's really going to have to be a known _un_used register and (the write
direction of) port 0x80 is used exactly for that reason. Port 0xed is a
known "alternate diagnostic port" used by Phoenix BIOSes at least but Peter
Anvin reported trouble with that one -- probably for the outb direction but
assuming that means something was in fact responding, we'd have the same
timing problem.
I believe we have two "good" options:
1) port 0xed was tested by the current reporter and found to be safe (and
provide slow enough timing). If DMI based quirk hacks are available soon
enough we can switch 0x80 to 0xed based on it. Are they?
2) the thing I posted in the message replied to where immediately after
tsc_init() (which is before the PIT init) we switch to udelay() if we have a
TSC which is ofcourse anything modern.
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/
