From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Drake <drake@endlessm.com>
Cc: Len Brown <lenb@kernel.org>,
x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux@endlessm.com, rjw@rjwysocki.net,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: Detecting x86 LAPIC timer frequency from CPUID data
Date: Fri, 19 Apr 2019 10:57:10 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1904191042180.3174@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20190419083533.32388-1-drake@endlessm.com>
On Fri, 19 Apr 2019, Daniel Drake wrote:
> On Fri, Apr 19, 2019 at 6:30 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> > Time Stamp Counter/Core Crystal Clock Information (0x15):
> > TSC/clock ratio = 168/2
> > nominal core crystal clock = 0 Hz
> >
> > Processor Frequency Information (0x16):
> > Core Base Frequency (MHz) = 0x834 (2100)
> > Core Maximum Frequency (MHz) = 0xed8 (3800)
> > Bus (Reference) Frequency (MHz) = 0x64 (100)
> >
> > Assuming that TSC and local APIC timer run from the same frequency on these
> > modern machines.
> >
> > 2100MHz * 2 / 168 = 25MHz
> >
> > and disabling the tsc deadline timer tells me:
> >
> > ..... calibration result: 24999
> >
> > Close enough.
>
> I tested all the Intel SoC generations we have on hand. The assumption that
> the core crystal clock feeds the APIC seems to be consistently true.
>
> (Please note that all the following results are done with CONFIG_HZ=250,
> which is why the "calibration result" is 4x higher than HZ=1000 as used
> in previous mails)
>
> In the easy case, the low cost platforms do not support CPUID.0x16 (so no
> CPU frequency reporting), but they do tell us the core crystal clock, which
> is consistent with the APIC calibration result:
...
> And the 4 higher-end SoCs that we have available for testing all report
> crystal clock 0Hz from CPUID 0x15, but by combining the CPUID.0x16 base
> frequency with the CPUID.0x15 TSC/clock ratio, the crystal frequency can
> be calculated as you describe, and it consistently matches the APIC timer
> calibration result.
...
> Is this data convincing enough or should we additionally wait for some
> comments from Intel?
For me it's pretty convincing, but having some confirmation from Intel
wouldn't be a bad thing.
> I came up with the patch below. However, upon testing, I realised that, at
> least for the platforms I have in hand, only the first hunk is really needed.
> We don't need to use your magic calculation to find the crystal frequency
> because Intel already told us! native_calibrate_tsc() already hardcodes the
> crystal frequency for Kabylake, and Amber/Whiskey/Coffee also report the
> 0x8e/0x9e Kabylake model codes.
I'd rather replace these model checks with math. These tables are horrible
to maintain.
> Plus ApolloLake/GeminiLake do report the crystal frequency in CPUID.0x15
> so that is covered too.
> While looking around this code I also spotted something curious.
> In calibrate_APIC_clock() for the case where lapic_timer_frequency has been
> externally provided, we have:
> lapic_clockevent.max_delta_ns =
> clockevent_delta2ns(0x7FFFFF, &lapic_clockevent);
> lapic_clockevent.max_delta_ticks = 0x7FFFFF;
>
> But in the case where we calibrate, we have:
> lapic_clockevent.max_delta_ns =
> clockevent_delta2ns(0x7FFFFFFF, &lapic_clockevent);
> lapic_clockevent.max_delta_ticks = 0x7FFFFFFF;
>
> 0x7FFFFF vs 0x7FFFFFFF, is that intentional?
I don't think so. Looks like a failed copy and paste. Cc'ed Jacob, he might
know.
Thanks,
tglx
next prev parent reply other threads:[~2019-04-19 19:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 5:28 Detecting x86 LAPIC timer frequency from CPUID data Daniel Drake
2019-04-18 13:12 ` Thomas Gleixner
2019-04-18 22:30 ` Thomas Gleixner
2019-04-19 8:35 ` Daniel Drake
2019-04-19 8:57 ` Thomas Gleixner [this message]
2019-04-19 20:50 ` Jacob Pan
2019-04-19 20:52 ` Thomas Gleixner
2019-04-19 23:09 ` Jacob Pan
2019-05-09 10:34 ` [tip:x86/apic] x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency tip-bot for Daniel Drake
-- strict thread matches above, loose matches on Subject: below --
2019-05-09 5:54 [PATCH v2 1/3] x86/tsc: use " Daniel Drake
2019-05-09 5:54 ` [PATCH v2 2/3] x86/apic: rename lapic_timer_frequency to lapic_timer_period Daniel Drake
2019-05-09 10:34 ` [tip:x86/apic] x86/apic: Rename 'lapic_timer_frequency' to 'lapic_timer_period' tip-bot for Daniel Drake
2019-05-09 5:54 ` [PATCH v2 3/3] x86/tsc: set LAPIC timer period to crystal clock frequency Daniel Drake
2019-05-09 7:25 ` [PATCH v2 1/3] x86/tsc: use CPUID.0x16 to calculate missing crystal frequency Thomas Gleixner
2019-05-09 9:07 ` Ingo Molnar
2019-04-03 7:49 No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot Daniel Drake
2019-04-03 11:21 ` Thomas Gleixner
2019-04-03 12:01 ` Thomas Gleixner
2019-04-09 5:43 ` Daniel Drake
2019-04-10 12:54 ` Thomas Gleixner
2019-04-16 5:21 ` Daniel Drake
2019-05-09 10:35 ` [tip:x86/apic] x86/tsc: Set LAPIC timer period to crystal clock frequency tip-bot for Daniel Drake
2019-06-27 8:54 ` No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot Daniel Drake
2019-06-27 14:06 ` Thomas Gleixner
2019-06-28 3:33 ` Daniel Drake
2019-06-28 5:07 ` Thomas Gleixner
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=alpine.DEB.2.21.1904191042180.3174@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=drake@endlessm.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@endlessm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--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).