From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
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>
Subject: Re: [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC
Date: Wed, 29 Jan 2020 15:03:50 +0200 [thread overview]
Message-ID: <20200129130350.GD32742@smile.fi.intel.com> (raw)
In-Reply-To: <87sgjz434v.fsf@nanos.tec.linutronix.de>
On Tue, Jan 28, 2020 at 11:39:28PM +0100, Thomas Gleixner wrote:
> Hans de Goede <hdegoede@redhat.com> writes:
> > Ok, I have been testing this on various devices and I'm pretty sure now
> > that my initial hunch is correct. The problem is that the accuracy of
> > the FSB frequency as listed in the Intel docs is not so great:
>
> Thanks for doing that.
+1!
> > The "Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 4:
> > Model-Specific Registers" has the following table for the values from
> > freq_desc_byt:
> >
> > 000B: 083.3 MHz
> > 001B: 100.0 MHz
> > 010B: 133.3 MHz
> > 011B: 116.7 MHz
> > 100B: 080.0 MHz
> >
> > Notice how for e.g the 83.3 MHz value there are 3 significant digits,
> > which translates to an accuracy of a 1000 ppm, where as your typical
> > crystal oscillator is 20 - 100 ppm, so the accuracy of the frequency
> > format used in the Software Developer’s Manual is not really helpful.
>
> The SDM is not always helpful :)
>
> > So the 00 part of 83300 which I'm suggesting to replace with 33 in
> > essence is not specified and when the tsc_msr.c code was written /
> > Bay Trail support was added the value from the datasheet was simply
> > padded with zeros.
> >
> > There is already a hint that that likely is not correct in the values
> > from the Software Developer’s Manual, we have values ending at 3.3,
> > but also at 6.7, which to me feels like it is 6.66666666666667 rounded
> > up and thus the 3.3 likely is 3.33333333333333.
> >
> > Test 1: Intel(R) Celeron(R) CPU N2840 @ 2.16GHz"
> > --------------------------------------------------
> >
> > As said I've also ran some tests. The first device I have tested is
> > a HP stream 11 x360 with an "Intel(R) Celeron(R) CPU N2840 @ 2.16GHz"
> > (from /proc/cpuinfo) this is the "laptop' version of Bay Trail rather
> > then the tablet version, so like Vipul's case I can comment out the 2
> > lines setting the TSC_KNOWN_FREQ and TSC_RELIABLE flags and get
> > "Refined TSC clocksource calibration". I've also added the changes with
> > the extra pr_info calls which you requested. Here is the relevant output
> > from a kernel with the 2 flags commented out + your pr_info changes,
> > note I changed the REF_CLOCK format from %x to %d as that seems easier
> > to interpret to me.
> >
> > [ 0.000000] MSR_PINFO: 0000060000001a00 -> 26
> > [ 0.000000] MSR_FSBF: 0000000000000000
> > [ 0.000000] REF_CLOCK: 83000
> > [ 0.000000] tsc: Detected 2165.800 MHz processor
> > [ 3.586805] tsc: Refined TSC clocksource calibration: 2166.666 MHz
> >
> > And with my suggested change:
> >
> > [ 0.000000] MSR_PINFO: 0000060000001a00 -> 26
> > [ 0.000000] MSR_FSBF: 0000000000000000
> > [ 0.000000] REF_CLOCK: 83333
> > [ 0.000000] tsc: Detected 2166.658 MHz processor
> > [ 3.587326] tsc: Refined TSC clocksource calibration: 2166.667 MHz
> >
> > Note we are still 0.009 MHz of from the refined calibration, so my
> > suggestion to really fix this would be to change the freqs part
> > of struct freq_desc to be in Hz rather then KHz and then calculate
> > res as:
> >
> > res = DIV_ROUND_CLOSEST(freq * ratio, 1000); /* res is in KHz */
>
> That makes a log of sense.
...
> Looking at the table again:
>
> > 000B: 083.3 MHz
> > 001B: 100.0 MHz
> > 010B: 133.3 MHz
> > 011B: 116.7 MHz
> > 100B: 080.0 MHz
>
> I don't know what the crystal frequency of this CPU is, but usually the
> frequencies are the same accross a SoC family. The E3800 baytrail
> definitely runs with a 25Mhz crystal.
>
> So using 25MHz as crystal frequency;
>
> 000: 25 * 20 / 6 = 83.3333
> 001: 25 * 4 / 1 = 100.0000
> 010: 25 * 16 / 3 = 133.3333
> 011: 25 * 28 / 6 = 116.6666
> 100: 25 * 16 / 5 = 80.0000
>
> So the tables for the various SoCs should have the crystal frequency and
> the multiplier / divider pairs for each step. That makes the math simple
> and accurate.
Completely agree here. I used to fix magic tables [1] when product engineers
considers data in the documentation like carved in stone. So, I'm not surprised
we have one here.
> Typical crystal frequencies are 19.2, 24 and 25Mhz.
Hans, I think Cherrytrail may be affected by this as the others.
CHT AFAIK uses 19.2MHz xtal.
> And if you look at CPUID 15H, it provides the crystal frequency and the
> crystal to TSC ratio with a nominator / denominator pair. IOW a proper
> description of the PLL.
[1]: 9df461eca18f ("spi: pxa2xx: replace ugly table by approximation")
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-01-29 13:03 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 [this message]
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
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=20200129130350.GD32742@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=Cedric_Hombourger@mentor.com \
--cc=Srikanth_Krishnakar@mentor.com \
--cc=daniel.lezcano@linaro.org \
--cc=hdegoede@redhat.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).