diff options
author | Thomas Gleixner <tglx@linutronix.de> | 2010-12-13 12:43:23 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2010-12-13 13:42:44 +0100 |
commit | f1c18071ad70e2a78ab31fc26a18fcfa954a05c6 (patch) | |
tree | f2dcc61137171da3cffe2ca392bb694cacb65cb4 /arch/x86/vdso | |
parent | 4720dd1b3858f0da2593188cb1e57eb0d3bc4af2 (diff) | |
download | op-kernel-dev-f1c18071ad70e2a78ab31fc26a18fcfa954a05c6.zip op-kernel-dev-f1c18071ad70e2a78ab31fc26a18fcfa954a05c6.tar.gz |
x86: HPET: Chose a paranoid safe value for the ETIME check
commit 995bd3bb5 (x86: Hpet: Avoid the comparator readback penalty)
chose 8 HPET cycles as a safe value for the ETIME check, as we had the
confirmation that the posted write to the comparator register is
delayed by two HPET clock cycles on Intel chipsets which showed
readback problems.
After that patch hit mainline we got reports from machines with newer
AMD chipsets which seem to have an even longer delay. See
http://thread.gmane.org/gmane.linux.kernel/1054283 and
http://thread.gmane.org/gmane.linux.kernel/1069458 for further
information.
Boris tried to come up with an ACPI based selection of the minimum
HPET cycles, but this failed on a couple of test machines. And of
course we did not get any useful information from the hardware folks.
For now our only option is to chose a paranoid high and safe value for
the minimum HPET cycles used by the ETIME check. Adjust the minimum ns
value for the HPET clockevent accordingly.
Reported-Bistected-and-Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
LKML-Reference: <alpine.LFD.2.00.1012131222420.2653@localhost6.localdomain6>
Cc: Simon Kirby <sim@hostway.ca>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andreas Herrmann <Andreas.Herrmann3@amd.com>
Cc: John Stultz <johnstul@us.ibm.com>
Diffstat (limited to 'arch/x86/vdso')
0 files changed, 0 insertions, 0 deletions