471e5b852430fdc6ec99811e3ff9ee19294ce2284f72bcec3dc1866c.patch

From 1ce2c39029e1ace8691d5b2c2d7f4d5013313961 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki <biernacki@google.com>
Date: Thu, 23 Apr 2020 16:18:02 +0200
Subject: [PATCH] CHROMIUM: Use hardcoded crystal clock for Skylake instead of
 upstream estimation code

This commit restores the hard-coded crystal clock frequency for Skylake.
They were removed by upstream
commit b88a9bbcc80f ("UPSTREAM: x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency")

For platforms which does not return TSC/Crystal ratio by CPUID.0x15,
the mentioned patch removes hard coded crystal frequencies
and use estimation code based on crystal ratio and the CPU speed.
It turns out that for Skylake SKU used in Caroline (and followers) the
estimation code which use CPUID.0x16 gives gives ratio which is in ~1.5%
difference to actually used. This in turn forces the main clock event
source to generate too frequent interrupts and cause time differences for
syscalls like usleep()/clock_gettime().

All ChromeOs tests which base on time to measure count of frames/samples
per second will fail in this case. Also system time will be wrong but this
will be corrected by NTP.

BUG=b:148108096, b:154283905, b:146787525, b:153400677, b:148178929,
chromium:1031054
TEST=1. Deploy fix on DUT
2. Mesure real sleep time on DUT from other machine:
 $ time sshpass -p <pass> ssh root@<ip> 'sleep 300'
3. Bad: real ~ 4m56s
 Good: real > 5m

Change-Id: Ie4a441976adf9ec102ffe2372295f8feb0afbd95
Signed-off-by: Radoslaw Biernacki <biernacki@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2157038
Reviewed-by: Ross Zwisler <zwisler@google.com>
Commit-Queue: Ross Zwisler <zwisler@google.com>
(cherry picked from commit b323266634d3717da86499f1609a5de8c3242aaa)
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2170996
---
 arch/x86/kernel/tsc.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 06b170759e5bf581d78a0420ae887cf5d139d6d8..7e5e14bb91dbe199230dbe9ed0fa1578b46f527e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -680,10 +680,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_vfm == INTEL_ATOM_GOLDMONT_D)
-		crystal_khz = 25000;
+	if (crystal_khz == 0) {
+		switch (boot_cpu_data.x86_model) {
+			case INTEL_FAM6_SKYLAKE_L:
+			crystal_khz = 24000;	/* 24.0 MHz */
+			break;
+		case INTEL_FAM6_ATOM_GOLDMONT_D:
+			crystal_khz = 25000;	/* 25.0 MHz */
+			break;
+		}
+	}
 
 	/*
 	 * TSC frequency reported directly by CPUID is a "hardware reported"
-- 
2.45.1.288.g0e0cd299f1-goog