public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	vipul kumar <vipulk0511@gmail.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-kernel@vger.kernel.org, Stable <stable@vger.kernel.org>,
	Srikanth Krishnakar <Srikanth_Krishnakar@mentor.com>,
	Cedric Hombourger <Cedric_Hombourger@mentor.com>,
	x86@kernel.org, Len Brown <len.brown@intel.com>,
	Vipul Kumar <vipul_kumar@mentor.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC
Date: Wed, 29 Jan 2020 21:57:02 +0100	[thread overview]
Message-ID: <87a7662d7l.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200129155353.GI32742@smile.fi.intel.com>

Andy,

Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> On Wed, Jan 29, 2020 at 04:13:39PM +0100, Thomas Gleixner wrote:
>> Andy, can you please make sure that people inside Intel who can look
>> into the secrit documentation confirm what we are aiming for?
>> 
>> Ideally they should provide the X-tal frequency and the mult/div pair
>> themself :)
>
> So, I don't have access to the CPU core documentation (and may be will not be
> given), nevertheless I dug a bit to what I have for Cherrytrail. So, the XTAL
> is 19.2MHz, which becomes 100MHz and 1600MHz by some root PLL, then, the latter
> two frequencies are being used by another PLL to provide a reference clock (*)
> to PLL which derives CPU clock.
>
> *) According to colleagues of mine it's a fixed rate source.
>
> That's all what I have.

I'm surely not blaming you for this, you're just the messenger.

Just to make it entirely clear. We are wasting days already due to the
fact that Intel, who designs, specifies and most importantly sells these
CPUs is either unable or unwilling to provide accurate information about
the trivial and essential information to support these CPUs:

    1) The crystal frequency

    2) The nominator/denominator pair to calculate the TSC frequency
       from #1

The numbers which are in the kernel have been provided by Intel, but
they are inaccurate as we have proven.

Sure, we can reverse engineer the exact numbers assumed that we have
access to all variants of affected devices and enough spare time to
waste.

But why should we do that?

Intel has the exact numbers at their fingertip and is just not providing
them for whatever reasons (I really don't want to know).

So instead of wasting our precious time further, I'm going to apply the
patch below unless Intel comes forth with the information they should
have provided many years ago.

Thanks,

        tglx

8<--------------
 arch/x86/kernel/tsc_msr.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -73,6 +73,13 @@ static const struct x86_cpu_id tsc_msr_c
 	{}
 };
 
+static char msr_warning[] = \
+	"The TSC/APIC timer frequency for your CPU is guesswork.\n\n"	\
+	"It is derived from frequency tables provided by Intel.\n"	\
+	"These tables are demonstrably inaccurate, but Intel is\n"	\
+	"either unable or unwilling to provide the correct data.\n"	\
+	"Please report this to Intel and not on LKML.\n";
+
 /*
  * MSR-based CPU/TSC frequency discovery for certain CPUs.
  *
@@ -90,6 +97,8 @@ unsigned long cpu_khz_from_msr(void)
 	if (!id)
 		return 0;
 
+	WARN_ONCE(1, "%s\n", msr_warning);
+
 	freq_desc = (struct freq_desc *)id->driver_data;
 	if (freq_desc->msr_plat) {
 		rdmsr(MSR_PLATFORM_INFO, lo, hi);


  parent reply	other threads:[~2020-01-29 20:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 14:41 [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC Vipul Kumar
2020-01-21 15:24 ` Andy Shevchenko
2020-01-21 17:45 ` Thomas Gleixner
     [not found]   ` <CADdC98RJpsvu_zWehNGDDN=W11rD11NSPaodg-zuaXsHuOJYTQ@mail.gmail.com>
2020-01-22 14:45     ` Thomas Gleixner
     [not found]       ` <CADdC98TE4oNWZyEsqXzr+zJtfdTTOyeeuHqu1u04X_ktLHo-Hg@mail.gmail.com>
2020-01-23 14:12         ` Thomas Gleixner
2020-01-23 14:41         ` Andy Shevchenko
2020-01-23 21:18           ` Hans de Goede
2020-01-24  8:35             ` Thomas Gleixner
2020-01-24  9:11               ` Hans de Goede
2020-01-24 11:55                 ` Thomas Gleixner
2020-01-24 15:54                   ` Hans de Goede
     [not found]                     ` <CADdC98To8VKOUWnR+8zAJ04vgdc4vJoh2h96588+5XFer9YTJw@mail.gmail.com>
2020-01-28 14:23                       ` Hans de Goede
2020-01-28 14:39                         ` vipul kumar
2020-01-28 15:11                       ` Thomas Gleixner
2020-01-28 18:57                   ` Hans de Goede
2020-01-28 22:39                     ` Thomas Gleixner
2020-01-29 13:03                       ` Andy Shevchenko
2020-01-29 13:21                         ` Hans de Goede
2020-01-29 14:14                           ` Andy Shevchenko
2020-01-29 14:27                             ` Hans de Goede
2020-01-29 15:13                               ` Thomas Gleixner
2020-01-29 15:53                                 ` Andy Shevchenko
2020-01-29 15:59                                   ` Andy Shevchenko
2020-01-29 16:02                                     ` Andy Shevchenko
2020-01-29 20:57                                   ` Thomas Gleixner [this message]
2020-01-30  8:54                                     ` Hans de Goede
2020-02-13 18:32                                     ` Dave Hansen
2020-02-13 21:06                                       ` Thomas Gleixner
2020-01-29 15:14                               ` David Laight
2020-01-29 11:43             ` vipul kumar
2020-01-29  5:20       ` vipul kumar
     [not found] ` <20200122022619.B95C024655@mail.kernel.org>
2020-01-22  4:24   ` Kumar, Vipul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7662d7l.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=Cedric_Hombourger@mentor.com \
    --cc=Srikanth_Krishnakar@mentor.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vipul_kumar@mentor.com \
    --cc=vipulk0511@gmail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox