Dear Thomas,
Thank you for the quick reply.
Am 11.05.20 um 09:17 schrieb Thomas Gleixner:
Paul Menzel <[email protected]> writes:
please send patches to LKML and not offlist.
Sorry about that. From `MAINTAINERS` I thought [email protected] is wanted.
Other subsystems list LKML explicitly there.
From: Radoslaw Biernacki <[email protected]>
@@ -636,10 +636,24 @@ unsigned long native_calibrate_tsc(void)
* Denverton SoCs don't report crystal clock, and also don't support
* CPUID.0x16 for the calculation below, so hardcode the 25MHz crystal
* clock.
+ * Also estimation code is not reliable and gives 1.5% difference for
+ * tsc/clock ratio on Skylake mobile. Therefore below is a hardcoded
+ * crystal frequency for Skylake which was removed by upstream commit
+ * "x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency"
+ * This is temporary workaround for bugs:
+ * b/148108096, b/154283905, b/146787525, b/153400677, b/148178929
+ * chromium/1031054
*/
- if (crystal_khz == 0 &&
- boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT_D)
- crystal_khz = 25000;
+ if (crystal_khz == 0) {
+ switch (boot_cpu_data.x86_model) {
+ case INTEL_FAM6_SKYLAKE_MOBILE:
+ crystal_khz = 24000; /* 24.0 MHz */
+ break;
+ case INTEL_FAM6_ATOM_GOLDMONT_X:
+ crystal_khz = 25000; /* 25.0 MHz */
+ break;
+ }
Aside of being a workaround for Google issues which are probably caused > by
broken BIOSes
Even if it was caused by broken firmware, wouldn’t Linux’ no regression
policy still consider this a regression as user should be able to the
Linux kernel “no matter what”?
that patch is broken.
INTEL_FAM6_ATOM_GOLDMONT_D != INTEL_FAM6_ATOM_GOLDMONT_X
Good catch. The commit didn’t apply cleanly to the master branch, and I
missed this.
I’ll wait for Radoslaw to comment before proceeding further with this.
Kind regards,
Paul
