[PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

[PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

[Vipul Kumar]

From: Vipul Kumar <vipul_kumar@mentor.com>

'commit f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE
flags on Intel Atom SoCs")', causing time drift for Bay trail SoC.
These flags are set for SoCs having cpuid_level 0x15 or more.
Bay trail is having cpuid_level 0xb.

So, unset both flags to make sure the clocksource calibration can
be done.

Signed-off-by: Vipul Kumar <vipul_kumar@mentor.com>
---
 arch/x86/kernel/tsc_msr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index e0cbe4f2af49..1ca27c28db98 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -112,6 +112,9 @@ unsigned long cpu_khz_from_msr(void)
 	lapic_timer_period = (freq * 1000) / HZ;
 #endif
 
+	if (boot_cpu_data.cpuid_level < 0x15)
+		return res;
+
 	/*
 	 * TSC frequency determined by MSR is always considered "known"
 	 * because it is reported by HW.
-- 
2.20.1

Re: [PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

[Greg KH]

On Wed, Dec 18, 2019 at 09:00:39PM +0530, Vipul Kumar wrote:
> From: Vipul Kumar <vipul_kumar@mentor.com>
> 
> 'commit f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE
> flags on Intel Atom SoCs")', causing time drift for Bay trail SoC.
> These flags are set for SoCs having cpuid_level 0x15 or more.
> Bay trail is having cpuid_level 0xb.
> 
> So, unset both flags to make sure the clocksource calibration can
> be done.
> 
> Signed-off-by: Vipul Kumar <vipul_kumar@mentor.com>
> ---
>  arch/x86/kernel/tsc_msr.c | 3 +++
>  1 file changed, 3 insertions(+)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

Re: [PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

[Thomas Gleixner]

Vipul,

please always CC the relevant maintainers. Aside of that it's good
practice to CC the author of a particular commit you identified.

Vipul Kumar <vipulk0511@gmail.com> writes:

> From: Vipul Kumar <vipul_kumar@mentor.com>
>
> 'commit f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE
> flags on Intel Atom SoCs")', causing time drift for Bay trail SoC.
> These flags are set for SoCs having cpuid_level 0x15 or more.
> Bay trail is having cpuid_level 0xb.

Which is completely irrelevant. These CPUs read their frequency from
MSRs not from CPUID.

> So, unset both flags to make sure the clocksource calibration can
> be done.

That's going to break tons of ATOM SoC based systems which have neither
HPET not PIT.

Aside of that on some systems HPET/PIT based calibration is not really
more accurate than the MSR based frequency, quite the contrary.

Can you please provide detailed data about the problem you are trying to
solve? 'time drift' is pretty unspecific.

Thanks,

        tglx

Re: [PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

[Thomas Gleixner]

Vipul,

vipul kumar <vipulk0511@gmail.com> writes:
> On Fri, Jan 17, 2020 at 3:34 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>> Vipul Kumar <vipulk0511@gmail.com> writes:
>> Can you please provide detailed data about the problem you are trying to
>> solve? 'time drift' is pretty unspecific.
>
> After running board for some days without rebooting it, time drift is
> observed between system time and RTC time.
>
> SystemTime: 2019-11-08T15:48:46+00:00 RTC Time:   2019-11-08
> 15:44:35.976137+0000 Uptime: up 7 days 5 hours, 33 minutes
>
> This sample shows a difference of 4 minutes after 7 days.

Of course you fail to provide the data for the case where the frequency
is recalibrated, i.e. with your patch applied.

> To fix this drift issue, disable X86_FEATURE_TSC_KNOWN_FREQ flag for Soc's
> having  cpuid_level < 0x15.

Again, I explained you already that this does not work on SoCs which do
not expose HPET or PIT.

And again, it has absolutely nothing to do with the CPUID level because
these chips are not using CPUID to retrieve the frequency
information. They use cpu_khz_from_msr() which only depends on the CPU
model/family.

So if you want to enforce refined calibration on such systems, then you
need to do it in a way which does not break the world.

Thanks,

        tglx