| commit | a6a80e1d8cf82b46a69f88e659da02749231eb36 | |
| author | Linus Torvalds <torvalds@linux-foundation.org> | |
| Tue, 17 Mar 2009 14:58:26 +0000 (17 07:58 -0700) | ||
| committer | Linus Torvalds <torvalds@linux-foundation.org> | |
| Tue, 17 Mar 2009 14:58:26 +0000 (17 07:58 -0700) | ||
| tree | 307db5dba0a4217e9e3298d74b16593b3674a02e | treesnapshot (tar.gz zip) |
| parent | 19695ec03d492f1eeb760727d3bd10c7d2f31c1d | commitdiff |
Fix potential fast PIT TSC calibration startup glitch
During bootup, when we reprogram the PIT (programmable interval timer)
to start counting down from 0xffff in order to use it for the fast TSC
calibration, we should also make sure to delay a bit afterwards to allow
the PIT hardware to actually start counting with the new value.
That will happens at the next CLK pulse (1.193182 MHz), so the easiest
way to do that is to just wait at least one microsecond after
programming the new PIT counter value. We do that by just reading the
counter value back once - which will take about 2us on PC hardware.
Reported-and-tested-by: john stultz <johnstul@us.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During bootup, when we reprogram the PIT (programmable interval timer)
to start counting down from 0xffff in order to use it for the fast TSC
calibration, we should also make sure to delay a bit afterwards to allow
the PIT hardware to actually start counting with the new value.
That will happens at the next CLK pulse (1.193182 MHz), so the easiest
way to do that is to just wait at least one microsecond after
programming the new PIT counter value. We do that by just reading the
counter value back once - which will take about 2us on PC hardware.
Reported-and-tested-by: john stultz <johnstul@us.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| arch/x86/kernel/tsc.c | diffblobblamehistory |