Message ID | 20221018190124.v2.1.I918ccc908c5c836c1e21e01d2cf6f59b0157bcc3@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp2117948wrs; Tue, 18 Oct 2022 12:10:44 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4p8akF4znM8SFdgr3NmilQWVudhkx7/Nk5EQOUvzxB53tgVFpleLPKHfSk7qS+KFZziIbt X-Received: by 2002:a17:906:c152:b0:78d:9dbb:150b with SMTP id dp18-20020a170906c15200b0078d9dbb150bmr3523700ejc.542.1666120243925; Tue, 18 Oct 2022 12:10:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666120243; cv=none; d=google.com; s=arc-20160816; b=0FcmBrZwXZQ65bwlNaxDzZQyxItyyWdnu4wUL97H4h4oJDpN0KmnGPM9YY0NHPZ+uM 5Tg7J+5TjG5By//RcxQLbWD2Wzc1vsIZMzSwaDqeCGpnxbi+fp7Cp6ax2a+6C3JlDXOZ icN+j1TsZ6i9p/WTpWrLzBqhX8K5NhOl5AxqspN7v9xjFUCSE6OXZJPvsCQZRb215MGy gYBRz2MTcROlzP1OodxOuZ4+Y6ruE73doAw12hcJyRuioo+LSb1/sGUhgFmX6urc2hoQ dvakFtcM+XoD7jo5hWHKsMUTFI1Td2RdO2VXRTFKD3+zFSFbhchGH+ssBtEKzadv/zfJ /D7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=RrBZLYnCa4U73RZ7+IkOsQJp1B4oNHg37PxVo0ipMHk=; b=xNsHjN0BnrGBhSH4yrC2nMC0HJ158MWN8heh57+G0kRvtaIzAwxNf785wk/9zyKv0c v06m7Oy8vfQZGHKQnZAY6YILBzbu3h5tbRPIyhXdg0MdU6ArehA1dLkhruZIkepthCDP 5yvSDTbXnc5MTYE5yisrp3AqeMH4IHBVgzhprPreLl7jr81ZzoA8VyDdJ+W/OU/zdFK+ LHuh9ILQHRDyikFYzOuEi5mF4Ojd9MvT5O8qH67UkTyAve+Oo9OphFt84j5FPfQl8pka fIDutz/M3yqLzvdzQ2NPNmsfVxdd6Dut+JQsAHLmAu4JIu8Oq/EI5opyFib89dTWO6bp aQ/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=CDodwI1d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 30-20020a508e1e000000b00458b204f294si10692046edw.298.2022.10.18.12.10.18; Tue, 18 Oct 2022 12:10:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=CDodwI1d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbiJRTBz (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Tue, 18 Oct 2022 15:01:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbiJRTBm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Oct 2022 15:01:42 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D98BB5FF0 for <linux-kernel@vger.kernel.org>; Tue, 18 Oct 2022 12:01:40 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id bh13so14118038pgb.4 for <linux-kernel@vger.kernel.org>; Tue, 18 Oct 2022 12:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=RrBZLYnCa4U73RZ7+IkOsQJp1B4oNHg37PxVo0ipMHk=; b=CDodwI1d1Nfp8ue1Psca1kFKUqqynntNxl8Z4zwNUvPoeRrcDQAxG6Qa10JQWBT51P u6wJko/fLiJcGY3JOZT65vrBbXNbHh+Kbm40jsdi67K5pBfo5v2XkUrOYSInbWs8jr8P zUPwcT2J1mvcNJUGMQYBi9twA5YrWvGGeOgl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RrBZLYnCa4U73RZ7+IkOsQJp1B4oNHg37PxVo0ipMHk=; b=nn6IyYNDyqYfpCkBpZtLffxOszc1cMQfTyzsKVWhxcYuwDNvGXjHvRHxnZShqeOQGE 1am8m31rkFr0LZhHljKjM56V4Xdzd+Gr58dW7T2qwhIjemE5TZa243cJFNOgXMHyQgeI libDjQ1ziW/yAJc2KUrzl/uoOp8aewr5UEUti6LRuBE6wzhRvW6OEWo9lf2mRpwgjS6x 5rm009NhE6JvmShoVpGKhnslRI4Yf1V37d5L4caXDXB6jSPn/IkrFTwuT55ab7icgQV2 o9bFnvrlzeQrz866aE5hGH1uh/7veYsOG9IIuOzhZbByHj/O8wWWrwXKWs5AjWlkfOqJ b1Xw== X-Gm-Message-State: ACrzQf1vSYojxm27SZw1J3v6JUq0Y7E1aulAA4y5tvG49pa44SNnMajV HFR87nXFi33vzjXoSLJdjeU1JsvOoZfpiQ== X-Received: by 2002:a63:881:0:b0:43a:c80a:bea4 with SMTP id 123-20020a630881000000b0043ac80abea4mr3871144pgi.329.1666119699295; Tue, 18 Oct 2022 12:01:39 -0700 (PDT) Received: from arishabh.c.googlers.com.com (30.176.125.34.bc.googleusercontent.com. [34.125.176.30]) by smtp.gmail.com with ESMTPSA id h3-20020aa796c3000000b0055fc0a132aasm9863407pfq.92.2022.10.18.12.01.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 12:01:38 -0700 (PDT) From: Rishabh Agrawal <rishabhagr@chromium.org> To: LKML <linux-kernel@vger.kernel.org>, len.brown@intel.com, drake@endlessm.com, rafael.j.wysocki@intel.com, mingo@redhat.com, tglx@linutronix.de Cc: vaibhav.shankar@intel.com, biernacki@google.com, zwisler@google.com, mattedavis@google.com, Rishabh Agrawal <rishabhagr@chromium.org>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, Feng Tang <feng.tang@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "H. Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>, x86@kernel.org Subject: [PATCH v2] Add hardcoded crystal clock for KabyLake Date: Tue, 18 Oct 2022 19:01:32 +0000 Message-Id: <20221018190124.v2.1.I918ccc908c5c836c1e21e01d2cf6f59b0157bcc3@changeid> X-Mailer: git-send-email 2.38.0.413.g74048e4d9e-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747053701126162884?= X-GMAIL-MSGID: =?utf-8?q?1747053701126162884?= |
Series |
[v2] Add hardcoded crystal clock for KabyLake
|
|
Commit Message
Rishabh Agrawal
Oct. 18, 2022, 7:01 p.m. UTC
Set KabyLake crystal clock manually since the TSC calibration is off
by 0.5%. All the tests that are based on the timer/clock will fail in
this case.
The HPET has been disabled by upstream due to PC10 issue causing the
3 hatch devices, dratini, jinlon, and kohaku to not calibrate the clock
precisely. These 3 devices are KabyLake devices. Intel team has verified
that all KBL devices have 24.0 MHz clock frequency, therefore this
change is valid.
Signed-off-by: Rishabh Agrawal <rishabhagr@chromium.org>
---
Changes in v2:
- Adding Thomas Gleixner, Daniel Drake, Rafael Wysocki, Len brown and Ingo to review since you worked on this.
arch/x86/kernel/tsc.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
Comments
On Tue, Oct 18, 2022 at 07:01:32PM +0000, Rishabh Agrawal wrote: > Set KabyLake crystal clock manually since the TSC calibration is off > by 0.5%. All the tests that are based on the timer/clock will fail in > this case. > > The HPET has been disabled by upstream due to PC10 issue causing the > 3 hatch devices, dratini, jinlon, and kohaku to not calibrate the clock I have no idea what a hatch device is, nor what pokemon have anything to do with things. > precisely. These 3 devices are KabyLake devices. Intel team has verified But no actual Intel person with a Reviewed-by tag we can go pester if this turns out to be wrong. > that all KBL devices have 24.0 MHz clock frequency, therefore this > change is valid. And yet you only change KBL_L. And why, pray *WHY* can't Intel simply write the correct information in CPUID leaf 15h. I mean, they defined the leaf, might as well use it, no? > Signed-off-by: Rishabh Agrawal <rishabhagr@chromium.org> > --- > > Changes in v2: > - Adding Thomas Gleixner, Daniel Drake, Rafael Wysocki, Len brown and Ingo to review since you worked on this. > > arch/x86/kernel/tsc.c | 17 ++++++++++++++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > index cafacb2e58cc..63a06224fa48 100644 > --- a/arch/x86/kernel/tsc.c > +++ b/arch/x86/kernel/tsc.c > @@ -644,10 +644,21 @@ 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. > + * > + * Intel KabyLake devices' clocks are off by 0.5% when using the below > + * calculation, so hardcode 24.0 MHz crystal clock. > */ > - 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_ATOM_GOLDMONT_D: > + crystal_khz = 25000; > + break; > + case INTEL_FAM6_KABYLAKE_L: > + crystal_khz = 24000; > + break; > + } > + > + } > > /* > * TSC frequency reported directly by CPUID is a "hardware reported" > -- > 2.38.0.413.g74048e4d9e-goog >
On 10/20/22 10:13, Peter Zijlstra wrote: > And why, pray *WHY* can't Intel simply write the correct information in > CPUID leaf 15h. I mean, they defined the leaf, might as well use it, no? Is the data that's in the leaf just wrong? Doesn't that mean that the CPUID leaf on these models is violating the architecture contract? That sounds like something that deserves an erratum. Is there a documented erratum?
On Thu, Oct 20 2022 at 10:18, Dave Hansen wrote: > On 10/20/22 10:13, Peter Zijlstra wrote: >> And why, pray *WHY* can't Intel simply write the correct information in >> CPUID leaf 15h. I mean, they defined the leaf, might as well use it, no? > > Is the data that's in the leaf just wrong? Doesn't that mean that the > CPUID leaf on these models is violating the architecture contract? That > sounds like something that deserves an erratum. > > Is there a documented erratum? I don't know. The code has this comment: /* * Some Intel SoCs like Skylake and Kabylake don't report the crystal * clock, but we can easily calculate it to a high degree of accuracy * by considering the crystal ratio and the CPU speed. */ so those SoCs fail to expose clock in leaf 15h and then the information in leaf 16h is so inaccurate that the calculation is off. Sigh. It's 2022 and we are still relying on crystalball mechanisms to figure out the damned crystal frequency. The specification of leaf 15h is: 15H Time Stamp Counter and Nominal Core Crystal Clock Information Leaf NOTES: If EBX[31:0] is 0, the TSC/”core crystal clock” ratio is not enumerated. If ECX is 0, the nominal core crystal clock frequency is not enumerated. IOW, this CPUID leaf is defined to be useless and leaves it up to the SoC integration to provide this information or not. It needs even two fields to chose from to make it useless... I'm sure this took 10+ draft versions and consumed a non-quantifiable amount of work hours to come up with this joke. Thanks, tglx
Hi, On Mon, Nov 14, 2022 at 11:58:54PM +0100, Thomas Gleixner wrote: > On Thu, Oct 20 2022 at 10:18, Dave Hansen wrote: > > On 10/20/22 10:13, Peter Zijlstra wrote: > >> And why, pray *WHY* can't Intel simply write the correct information in > >> CPUID leaf 15h. I mean, they defined the leaf, might as well use it, no? > > > > Is the data that's in the leaf just wrong? Doesn't that mean that the > > CPUID leaf on these models is violating the architecture contract? That > > sounds like something that deserves an erratum. > > > > Is there a documented erratum? > > I don't know. The code has this comment: > > /* > * Some Intel SoCs like Skylake and Kabylake don't report the crystal > * clock, but we can easily calculate it to a high degree of accuracy > * by considering the crystal ratio and the CPU speed. > */ Latest (April 2022) version of the SDM clearly states that the above comment is wrong. CPUID.16h has the following note: | Data is returned from this interface in accordance with the processor's | specification and does not reflect actual values. Suitable use of this | data includes the display of processor information in like manner to the | processor brand string and for determining the appropriate range to use | when displaying processor information e.g. frequency history graphs. The | returned information should not be used for any other purpose as the | returned information does not accurately correlate to information / | counters returned by other processor interfaces. Thus using CPUID.16h to determine the crystal clock frequency is wrong. This difference is significant. I have one Kaby Lake latop where the CPUID.16h reported frequency is 1900MHz but the real frequency is only 1896MHz. This amounts to a time drift of about 8s/hour if the wrong TSC frequency is used for time keeping. Basically, I think this commit: 604dc9170 (x86/tsc: Use CPUID.0x16 to calculate ...) needs to be reverted. > so those SoCs fail to expose clock in leaf 15h and then the information > in leaf 16h is so inaccurate that the calculation is off. > > Sigh. It's 2022 and we are still relying on crystalball mechanisms to > figure out the damned crystal frequency. > > The specification of leaf 15h is: > > 15H Time Stamp Counter and Nominal Core Crystal Clock Information Leaf > NOTES: > If EBX[31:0] is 0, the TSC/”core crystal clock” ratio is not enumerated. > If ECX is 0, the nominal core crystal clock frequency is not enumerated. > > IOW, this CPUID leaf is defined to be useless and leaves it up to the > SoC integration to provide this information or not. It needs even two > fields to chose from to make it useless... The SDM (now?) has some hints on how to do this. This is hidden here: Vol.3 Chapter 19.7.3: Determining the Processor Base Frequency This chapter contains a table that lists the correct crystal clock frequencies for CPU models that do not enumerate it via CPUID.15h. regards Christian
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index cafacb2e58cc..63a06224fa48 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -644,10 +644,21 @@ 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. + * + * Intel KabyLake devices' clocks are off by 0.5% when using the below + * calculation, so hardcode 24.0 MHz crystal clock. */ - 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_ATOM_GOLDMONT_D: + crystal_khz = 25000; + break; + case INTEL_FAM6_KABYLAKE_L: + crystal_khz = 24000; + break; + } + + } /* * TSC frequency reported directly by CPUID is a "hardware reported"