2019-05-19 19:08:55 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-05-22 09:50:07 +07:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2008-07-02 01:43:24 +07:00
|
|
|
#include <linux/kernel.h>
|
2008-07-02 01:43:18 +07:00
|
|
|
#include <linux/sched.h>
|
2017-02-01 22:36:40 +07:00
|
|
|
#include <linux/sched/clock.h>
|
2008-07-02 01:43:18 +07:00
|
|
|
#include <linux/init.h>
|
2016-07-14 07:18:56 +07:00
|
|
|
#include <linux/export.h>
|
2008-07-02 01:43:18 +07:00
|
|
|
#include <linux/timer.h>
|
2008-07-02 01:43:24 +07:00
|
|
|
#include <linux/acpi_pmtmr.h>
|
2008-07-02 01:43:31 +07:00
|
|
|
#include <linux/cpufreq.h>
|
2008-07-02 01:43:34 +07:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/clocksource.h>
|
|
|
|
#include <linux/percpu.h>
|
2009-06-17 05:31:12 +07:00
|
|
|
#include <linux/timex.h>
|
2013-11-29 01:01:40 +07:00
|
|
|
#include <linux/static_key.h>
|
2008-07-02 01:43:24 +07:00
|
|
|
|
|
|
|
#include <asm/hpet.h>
|
2008-07-02 01:43:34 +07:00
|
|
|
#include <asm/timer.h>
|
|
|
|
#include <asm/vgtod.h>
|
|
|
|
#include <asm/time.h>
|
|
|
|
#include <asm/delay.h>
|
2008-10-28 00:41:46 +07:00
|
|
|
#include <asm/hypervisor.h>
|
2009-08-20 21:27:41 +07:00
|
|
|
#include <asm/nmi.h>
|
2009-08-20 22:06:25 +07:00
|
|
|
#include <asm/x86_init.h>
|
2015-09-16 20:10:03 +07:00
|
|
|
#include <asm/geode.h>
|
2016-07-14 22:22:55 +07:00
|
|
|
#include <asm/apic.h>
|
2016-09-19 19:51:40 +07:00
|
|
|
#include <asm/intel-family.h>
|
2017-12-22 16:20:11 +07:00
|
|
|
#include <asm/i8259.h>
|
2018-10-03 01:01:46 +07:00
|
|
|
#include <asm/uv/uv.h>
|
2008-07-02 01:43:18 +07:00
|
|
|
|
2009-03-11 01:02:30 +07:00
|
|
|
unsigned int __read_mostly cpu_khz; /* TSC clocks / usec, not used here */
|
2008-07-02 01:43:18 +07:00
|
|
|
EXPORT_SYMBOL(cpu_khz);
|
2009-03-11 01:02:30 +07:00
|
|
|
|
|
|
|
unsigned int __read_mostly tsc_khz;
|
2008-07-02 01:43:18 +07:00
|
|
|
EXPORT_SYMBOL(tsc_khz);
|
|
|
|
|
2018-07-20 03:55:38 +07:00
|
|
|
#define KHZ 1000
|
|
|
|
|
2008-07-02 01:43:18 +07:00
|
|
|
/*
|
|
|
|
* TSC can be unstable due to cpufreq or due to unsynced TSCs
|
|
|
|
*/
|
2009-03-11 01:02:30 +07:00
|
|
|
static int __read_mostly tsc_unstable;
|
2008-07-02 01:43:18 +07:00
|
|
|
|
2015-07-24 21:34:32 +07:00
|
|
|
static DEFINE_STATIC_KEY_FALSE(__use_tsc);
|
2013-11-29 01:01:40 +07:00
|
|
|
|
2011-11-05 05:42:17 +07:00
|
|
|
int tsc_clocksource_reliable;
|
2013-11-29 21:39:25 +07:00
|
|
|
|
2016-02-29 21:33:47 +07:00
|
|
|
static u32 art_to_tsc_numerator;
|
|
|
|
static u32 art_to_tsc_denominator;
|
|
|
|
static u64 art_to_tsc_offset;
|
|
|
|
struct clocksource *art_related_clocksource;
|
|
|
|
|
2013-11-29 21:40:29 +07:00
|
|
|
struct cyc2ns {
|
2017-05-02 18:22:07 +07:00
|
|
|
struct cyc2ns_data data[2]; /* 0 + 2*16 = 32 */
|
|
|
|
seqcount_t seq; /* 32 + 4 = 36 */
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
}; /* fits one cacheline */
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
static DEFINE_PER_CPU_ALIGNED(struct cyc2ns, cyc2ns);
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2019-05-24 17:32:51 +07:00
|
|
|
__always_inline void cyc2ns_read_begin(struct cyc2ns_data *data)
|
2013-11-29 21:40:29 +07:00
|
|
|
{
|
2017-05-02 18:22:07 +07:00
|
|
|
int seq, idx;
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
preempt_disable_notrace();
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
do {
|
|
|
|
seq = this_cpu_read(cyc2ns.seq.sequence);
|
|
|
|
idx = seq & 1;
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
data->cyc2ns_offset = this_cpu_read(cyc2ns.data[idx].cyc2ns_offset);
|
|
|
|
data->cyc2ns_mul = this_cpu_read(cyc2ns.data[idx].cyc2ns_mul);
|
|
|
|
data->cyc2ns_shift = this_cpu_read(cyc2ns.data[idx].cyc2ns_shift);
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
} while (unlikely(seq != this_cpu_read(cyc2ns.seq.sequence)));
|
2013-11-29 21:40:29 +07:00
|
|
|
}
|
|
|
|
|
2019-05-24 17:32:51 +07:00
|
|
|
__always_inline void cyc2ns_read_end(void)
|
2013-11-29 21:40:29 +07:00
|
|
|
{
|
2017-05-02 18:22:07 +07:00
|
|
|
preempt_enable_notrace();
|
2013-11-29 21:40:29 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Accelerators for sched_clock()
|
2013-11-29 21:39:25 +07:00
|
|
|
* convert from cycles(64bits) => nanoseconds (64bits)
|
|
|
|
* basic equation:
|
|
|
|
* ns = cycles / (freq / ns_per_sec)
|
|
|
|
* ns = cycles * (ns_per_sec / freq)
|
|
|
|
* ns = cycles * (10^9 / (cpu_khz * 10^3))
|
|
|
|
* ns = cycles * (10^6 / cpu_khz)
|
|
|
|
*
|
|
|
|
* Then we use scaling math (suggested by george@mvista.com) to get:
|
|
|
|
* ns = cycles * (10^6 * SC / cpu_khz) / SC
|
|
|
|
* ns = cycles * cyc2ns_scale / SC
|
|
|
|
*
|
|
|
|
* And since SC is a constant power of two, we can convert the div
|
2015-08-21 16:05:18 +07:00
|
|
|
* into a shift. The larger SC is, the more accurate the conversion, but
|
|
|
|
* cyc2ns_scale needs to be a 32-bit value so that 32-bit multiplication
|
|
|
|
* (64-bit result) can be used.
|
2013-11-29 21:39:25 +07:00
|
|
|
*
|
2015-08-21 16:05:18 +07:00
|
|
|
* We can use khz divisor instead of mhz to keep a better precision.
|
2013-11-29 21:39:25 +07:00
|
|
|
* (mathieu.desnoyers@polymtl.ca)
|
|
|
|
*
|
|
|
|
* -johnstul@us.ibm.com "math is hard, lets go shopping!"
|
|
|
|
*/
|
|
|
|
|
2018-10-11 17:38:26 +07:00
|
|
|
static __always_inline unsigned long long cycles_2_ns(unsigned long long cyc)
|
2013-11-29 21:39:25 +07:00
|
|
|
{
|
2017-05-02 18:22:07 +07:00
|
|
|
struct cyc2ns_data data;
|
2013-11-29 21:40:29 +07:00
|
|
|
unsigned long long ns;
|
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
cyc2ns_read_begin(&data);
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
ns = data.cyc2ns_offset;
|
|
|
|
ns += mul_u64_u32_shr(cyc, data.cyc2ns_mul, data.cyc2ns_shift);
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
cyc2ns_read_end();
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2013-11-29 21:39:25 +07:00
|
|
|
return ns;
|
|
|
|
}
|
|
|
|
|
2018-07-20 03:55:39 +07:00
|
|
|
static void __set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_now)
|
2013-11-29 21:39:25 +07:00
|
|
|
{
|
2017-05-05 14:55:01 +07:00
|
|
|
unsigned long long ns_now;
|
2017-05-02 18:22:07 +07:00
|
|
|
struct cyc2ns_data data;
|
|
|
|
struct cyc2ns *c2n;
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2013-11-29 21:39:25 +07:00
|
|
|
ns_now = cycles_2_ns(tsc_now);
|
|
|
|
|
2013-11-29 21:40:29 +07:00
|
|
|
/*
|
|
|
|
* Compute a new multiplier as per the above comment and ensure our
|
|
|
|
* time function is continuous; see the comment near struct
|
|
|
|
* cyc2ns_data.
|
|
|
|
*/
|
2017-05-02 18:22:07 +07:00
|
|
|
clocks_calc_mult_shift(&data.cyc2ns_mul, &data.cyc2ns_shift, khz,
|
2015-08-21 16:05:18 +07:00
|
|
|
NSEC_PER_MSEC, 0);
|
|
|
|
|
2015-10-16 20:24:05 +07:00
|
|
|
/*
|
|
|
|
* cyc2ns_shift is exported via arch_perf_update_userpage() where it is
|
|
|
|
* not expected to be greater than 31 due to the original published
|
|
|
|
* conversion algorithm shifting a 32-bit value (now specifies a 64-bit
|
|
|
|
* value) - refer perf_event_mmap_page documentation in perf_event.h.
|
|
|
|
*/
|
2017-05-02 18:22:07 +07:00
|
|
|
if (data.cyc2ns_shift == 32) {
|
|
|
|
data.cyc2ns_shift = 31;
|
|
|
|
data.cyc2ns_mul >>= 1;
|
2015-10-16 20:24:05 +07:00
|
|
|
}
|
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
data.cyc2ns_offset = ns_now -
|
|
|
|
mul_u64_u32_shr(tsc_now, data.cyc2ns_mul, data.cyc2ns_shift);
|
|
|
|
|
|
|
|
c2n = per_cpu_ptr(&cyc2ns, cpu);
|
2013-11-29 21:40:29 +07:00
|
|
|
|
2017-05-02 18:22:07 +07:00
|
|
|
raw_write_seqcount_latch(&c2n->seq);
|
|
|
|
c2n->data[0] = data;
|
|
|
|
raw_write_seqcount_latch(&c2n->seq);
|
|
|
|
c2n->data[1] = data;
|
2018-07-20 03:55:39 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_now)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
sched_clock_idle_sleep_event();
|
|
|
|
|
|
|
|
if (khz)
|
|
|
|
__set_cyc2ns_scale(khz, cpu, tsc_now);
|
2013-11-29 21:39:25 +07:00
|
|
|
|
2017-04-21 17:26:23 +07:00
|
|
|
sched_clock_idle_wakeup_event();
|
2013-11-29 21:39:25 +07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
2017-05-05 14:55:01 +07:00
|
|
|
|
2018-07-20 03:55:39 +07:00
|
|
|
/*
|
|
|
|
* Initialize cyc2ns for boot cpu
|
|
|
|
*/
|
|
|
|
static void __init cyc2ns_init_boot_cpu(void)
|
|
|
|
{
|
|
|
|
struct cyc2ns *c2n = this_cpu_ptr(&cyc2ns);
|
|
|
|
|
|
|
|
seqcount_init(&c2n->seq);
|
|
|
|
__set_cyc2ns_scale(tsc_khz, smp_processor_id(), rdtsc());
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-07-30 14:54:20 +07:00
|
|
|
* Secondary CPUs do not run through tsc_init(), so set up
|
2018-07-20 03:55:39 +07:00
|
|
|
* all the scale factors for all CPUs, assuming the same
|
2019-04-18 21:11:37 +07:00
|
|
|
* speed as the bootup CPU.
|
2018-07-20 03:55:39 +07:00
|
|
|
*/
|
|
|
|
static void __init cyc2ns_init_secondary_cpus(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu, this_cpu = smp_processor_id();
|
|
|
|
struct cyc2ns *c2n = this_cpu_ptr(&cyc2ns);
|
|
|
|
struct cyc2ns_data *data = c2n->data;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
if (cpu != this_cpu) {
|
|
|
|
seqcount_init(&c2n->seq);
|
|
|
|
c2n = per_cpu_ptr(&cyc2ns, cpu);
|
|
|
|
c2n->data[0] = data[0];
|
|
|
|
c2n->data[1] = data[1];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-07-02 01:43:18 +07:00
|
|
|
/*
|
|
|
|
* Scheduler clock - returns current time in nanosec units.
|
|
|
|
*/
|
|
|
|
u64 native_sched_clock(void)
|
|
|
|
{
|
2015-07-24 21:34:32 +07:00
|
|
|
if (static_branch_likely(&__use_tsc)) {
|
|
|
|
u64 tsc_now = rdtsc();
|
|
|
|
|
|
|
|
/* return the value in ns */
|
|
|
|
return cycles_2_ns(tsc_now);
|
|
|
|
}
|
2008-07-02 01:43:18 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Fall back to jiffies if there's no TSC available:
|
|
|
|
* ( But note that we still use it if the TSC is marked
|
|
|
|
* unstable. We do this because unlike Time Of Day,
|
|
|
|
* the scheduler clock tolerates small errors and it's
|
|
|
|
* very important for it to be as fast as the platform
|
tree-wide: Assorted spelling fixes
In particular, several occurances of funny versions of 'success',
'unknown', 'therefore', 'acknowledge', 'argument', 'achieve', 'address',
'beginning', 'desirable', 'separate' and 'necessary' are fixed.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Joe Perches <joe@perches.com>
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-02-03 07:01:28 +07:00
|
|
|
* can achieve it. )
|
2008-07-02 01:43:18 +07:00
|
|
|
*/
|
|
|
|
|
2015-07-24 21:34:32 +07:00
|
|
|
/* No locking but a rare wrong value is not a big deal: */
|
|
|
|
return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
|
2008-07-02 01:43:18 +07:00
|
|
|
}
|
|
|
|
|
2015-05-11 02:22:39 +07:00
|
|
|
/*
|
|
|
|
* Generate a sched_clock if you already have a TSC value.
|
|
|
|
*/
|
|
|
|
u64 native_sched_clock_from_tsc(u64 tsc)
|
|
|
|
{
|
|
|
|
return cycles_2_ns(tsc);
|
|
|
|
}
|
|
|
|
|
2008-07-02 01:43:18 +07:00
|
|
|
/* We need to define a real function for sched_clock, to override the
|
|
|
|
weak default version */
|
|
|
|
#ifdef CONFIG_PARAVIRT
|
|
|
|
unsigned long long sched_clock(void)
|
|
|
|
{
|
|
|
|
return paravirt_sched_clock();
|
|
|
|
}
|
2017-03-01 21:53:38 +07:00
|
|
|
|
2017-03-17 18:48:18 +07:00
|
|
|
bool using_native_sched_clock(void)
|
2017-03-01 21:53:38 +07:00
|
|
|
{
|
2018-08-28 14:40:19 +07:00
|
|
|
return pv_ops.time.sched_clock == native_sched_clock;
|
2017-03-01 21:53:38 +07:00
|
|
|
}
|
2008-07-02 01:43:18 +07:00
|
|
|
#else
|
|
|
|
unsigned long long
|
|
|
|
sched_clock(void) __attribute__((alias("native_sched_clock")));
|
2017-03-01 21:53:38 +07:00
|
|
|
|
2017-03-17 18:48:18 +07:00
|
|
|
bool using_native_sched_clock(void) { return true; }
|
2008-07-02 01:43:18 +07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
int check_tsc_unstable(void)
|
|
|
|
{
|
|
|
|
return tsc_unstable;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(check_tsc_unstable);
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_TSC
|
|
|
|
int __init notsc_setup(char *str)
|
|
|
|
{
|
2018-07-20 03:55:30 +07:00
|
|
|
mark_tsc_unstable("boot parameter notsc");
|
2008-07-02 01:43:18 +07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* disable flag for tsc. Takes effect by clearing the TSC cpu flag
|
|
|
|
* in cpu/common.c
|
|
|
|
*/
|
|
|
|
int __init notsc_setup(char *str)
|
|
|
|
{
|
|
|
|
setup_clear_cpu_cap(X86_FEATURE_TSC);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
__setup("notsc", notsc_setup);
|
2008-07-02 01:43:24 +07:00
|
|
|
|
2010-10-05 07:03:20 +07:00
|
|
|
static int no_sched_irq_time;
|
2019-03-07 19:09:13 +07:00
|
|
|
static int no_tsc_watchdog;
|
2010-10-05 07:03:20 +07:00
|
|
|
|
2008-10-25 07:22:01 +07:00
|
|
|
static int __init tsc_setup(char *str)
|
|
|
|
{
|
|
|
|
if (!strcmp(str, "reliable"))
|
|
|
|
tsc_clocksource_reliable = 1;
|
2010-10-05 07:03:20 +07:00
|
|
|
if (!strncmp(str, "noirqtime", 9))
|
|
|
|
no_sched_irq_time = 1;
|
2017-04-13 19:56:44 +07:00
|
|
|
if (!strcmp(str, "unstable"))
|
|
|
|
mark_tsc_unstable("boot parameter");
|
2019-03-07 19:09:13 +07:00
|
|
|
if (!strcmp(str, "nowatchdog"))
|
|
|
|
no_tsc_watchdog = 1;
|
2008-10-25 07:22:01 +07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("tsc=", tsc_setup);
|
|
|
|
|
2018-11-06 00:10:40 +07:00
|
|
|
#define MAX_RETRIES 5
|
|
|
|
#define TSC_DEFAULT_THRESHOLD 0x20000
|
2008-07-02 01:43:24 +07:00
|
|
|
|
|
|
|
/*
|
2018-11-06 00:10:40 +07:00
|
|
|
* Read TSC and the reference counters. Take care of any disturbances
|
2008-07-02 01:43:24 +07:00
|
|
|
*/
|
2008-09-04 22:18:53 +07:00
|
|
|
static u64 tsc_read_refs(u64 *p, int hpet)
|
2008-07-02 01:43:24 +07:00
|
|
|
{
|
|
|
|
u64 t1, t2;
|
2018-11-06 00:10:40 +07:00
|
|
|
u64 thresh = tsc_khz ? tsc_khz >> 5 : TSC_DEFAULT_THRESHOLD;
|
2008-07-02 01:43:24 +07:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < MAX_RETRIES; i++) {
|
|
|
|
t1 = get_cycles();
|
|
|
|
if (hpet)
|
2008-09-04 22:18:53 +07:00
|
|
|
*p = hpet_readl(HPET_COUNTER) & 0xFFFFFFFF;
|
2008-07-02 01:43:24 +07:00
|
|
|
else
|
2008-09-04 22:18:53 +07:00
|
|
|
*p = acpi_pm_read_early();
|
2008-07-02 01:43:24 +07:00
|
|
|
t2 = get_cycles();
|
2018-11-06 00:10:40 +07:00
|
|
|
if ((t2 - t1) < thresh)
|
2008-07-02 01:43:24 +07:00
|
|
|
return t2;
|
|
|
|
}
|
|
|
|
return ULLONG_MAX;
|
|
|
|
}
|
|
|
|
|
2008-09-04 22:18:48 +07:00
|
|
|
/*
|
|
|
|
* Calculate the TSC frequency from HPET reference
|
2008-07-02 01:43:24 +07:00
|
|
|
*/
|
2008-09-04 22:18:48 +07:00
|
|
|
static unsigned long calc_hpet_ref(u64 deltatsc, u64 hpet1, u64 hpet2)
|
2008-07-02 01:43:24 +07:00
|
|
|
{
|
2008-09-04 22:18:48 +07:00
|
|
|
u64 tmp;
|
2008-07-02 01:43:24 +07:00
|
|
|
|
2008-09-04 22:18:48 +07:00
|
|
|
if (hpet2 < hpet1)
|
|
|
|
hpet2 += 0x100000000ULL;
|
|
|
|
hpet2 -= hpet1;
|
|
|
|
tmp = ((u64)hpet2 * hpet_readl(HPET_PERIOD));
|
|
|
|
do_div(tmp, 1000000);
|
2018-04-13 16:48:08 +07:00
|
|
|
deltatsc = div64_u64(deltatsc, tmp);
|
2008-09-04 22:18:48 +07:00
|
|
|
|
|
|
|
return (unsigned long) deltatsc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the TSC frequency from PMTimer reference
|
|
|
|
*/
|
|
|
|
static unsigned long calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2)
|
|
|
|
{
|
|
|
|
u64 tmp;
|
2008-07-02 01:43:24 +07:00
|
|
|
|
2008-09-04 22:18:48 +07:00
|
|
|
if (!pm1 && !pm2)
|
|
|
|
return ULONG_MAX;
|
|
|
|
|
|
|
|
if (pm2 < pm1)
|
|
|
|
pm2 += (u64)ACPI_PM_OVRRUN;
|
|
|
|
pm2 -= pm1;
|
|
|
|
tmp = pm2 * 1000000000LL;
|
|
|
|
do_div(tmp, PMTMR_TICKS_PER_SEC);
|
|
|
|
do_div(deltatsc, tmp);
|
|
|
|
|
|
|
|
return (unsigned long) deltatsc;
|
|
|
|
}
|
|
|
|
|
2008-09-04 22:18:59 +07:00
|
|
|
#define CAL_MS 10
|
2011-11-02 04:25:07 +07:00
|
|
|
#define CAL_LATCH (PIT_TICK_RATE / (1000 / CAL_MS))
|
2008-09-04 22:18:59 +07:00
|
|
|
#define CAL_PIT_LOOPS 1000
|
|
|
|
|
|
|
|
#define CAL2_MS 50
|
2011-11-02 04:25:07 +07:00
|
|
|
#define CAL2_LATCH (PIT_TICK_RATE / (1000 / CAL2_MS))
|
2008-09-04 22:18:59 +07:00
|
|
|
#define CAL2_PIT_LOOPS 5000
|
|
|
|
|
2008-09-04 22:18:44 +07:00
|
|
|
|
2008-09-03 21:30:13 +07:00
|
|
|
/*
|
|
|
|
* Try to calibrate the TSC against the Programmable
|
|
|
|
* Interrupt Timer and return the frequency of the TSC
|
|
|
|
* in kHz.
|
|
|
|
*
|
|
|
|
* Return ULONG_MAX on failure to calibrate.
|
|
|
|
*/
|
2008-09-04 22:18:59 +07:00
|
|
|
static unsigned long pit_calibrate_tsc(u32 latch, unsigned long ms, int loopmin)
|
2008-09-03 21:30:13 +07:00
|
|
|
{
|
|
|
|
u64 tsc, t1, t2, delta;
|
|
|
|
unsigned long tscmin, tscmax;
|
|
|
|
int pitcnt;
|
|
|
|
|
2017-12-22 16:20:11 +07:00
|
|
|
if (!has_legacy_pic()) {
|
|
|
|
/*
|
|
|
|
* Relies on tsc_early_delay_calibrate() to have given us semi
|
|
|
|
* usable udelay(), wait for the same 50ms we would have with
|
|
|
|
* the PIT loop below.
|
|
|
|
*/
|
|
|
|
udelay(10 * USEC_PER_MSEC);
|
|
|
|
udelay(10 * USEC_PER_MSEC);
|
|
|
|
udelay(10 * USEC_PER_MSEC);
|
|
|
|
udelay(10 * USEC_PER_MSEC);
|
|
|
|
udelay(10 * USEC_PER_MSEC);
|
|
|
|
return ULONG_MAX;
|
|
|
|
}
|
|
|
|
|
2008-09-03 21:30:13 +07:00
|
|
|
/* Set the Gate high, disable speaker */
|
|
|
|
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Setup CTC channel 2* for mode 0, (interrupt on terminal
|
|
|
|
* count mode), binary count. Set the latch register to 50ms
|
|
|
|
* (LSB then MSB) to begin countdown.
|
|
|
|
*/
|
|
|
|
outb(0xb0, 0x43);
|
2008-09-04 22:18:59 +07:00
|
|
|
outb(latch & 0xff, 0x42);
|
|
|
|
outb(latch >> 8, 0x42);
|
2008-09-03 21:30:13 +07:00
|
|
|
|
|
|
|
tsc = t1 = t2 = get_cycles();
|
|
|
|
|
|
|
|
pitcnt = 0;
|
|
|
|
tscmax = 0;
|
|
|
|
tscmin = ULONG_MAX;
|
|
|
|
while ((inb(0x61) & 0x20) == 0) {
|
|
|
|
t2 = get_cycles();
|
|
|
|
delta = t2 - tsc;
|
|
|
|
tsc = t2;
|
|
|
|
if ((unsigned long) delta < tscmin)
|
|
|
|
tscmin = (unsigned int) delta;
|
|
|
|
if ((unsigned long) delta > tscmax)
|
|
|
|
tscmax = (unsigned int) delta;
|
|
|
|
pitcnt++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sanity checks:
|
|
|
|
*
|
2008-09-04 22:18:59 +07:00
|
|
|
* If we were not able to read the PIT more than loopmin
|
2008-09-03 21:30:13 +07:00
|
|
|
* times, then we have been hit by a massive SMI
|
|
|
|
*
|
|
|
|
* If the maximum is 10 times larger than the minimum,
|
|
|
|
* then we got hit by an SMI as well.
|
|
|
|
*/
|
2008-09-04 22:18:59 +07:00
|
|
|
if (pitcnt < loopmin || tscmax > 10 * tscmin)
|
2008-09-03 21:30:13 +07:00
|
|
|
return ULONG_MAX;
|
|
|
|
|
|
|
|
/* Calculate the PIT value */
|
|
|
|
delta = t2 - t1;
|
2008-09-04 22:18:59 +07:00
|
|
|
do_div(delta, ms);
|
2008-09-03 21:30:13 +07:00
|
|
|
return delta;
|
|
|
|
}
|
|
|
|
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
/*
|
|
|
|
* This reads the current MSB of the PIT counter, and
|
|
|
|
* checks if we are running on sufficiently fast and
|
|
|
|
* non-virtualized hardware.
|
|
|
|
*
|
|
|
|
* Our expectations are:
|
|
|
|
*
|
|
|
|
* - the PIT is running at roughly 1.19MHz
|
|
|
|
*
|
|
|
|
* - each IO is going to take about 1us on real hardware,
|
|
|
|
* but we allow it to be much faster (by a factor of 10) or
|
|
|
|
* _slightly_ slower (ie we allow up to a 2us read+counter
|
|
|
|
* update - anything else implies a unacceptably slow CPU
|
|
|
|
* or PIT for the fast calibration to work.
|
|
|
|
*
|
|
|
|
* - with 256 PIT ticks to read the value, we have 214us to
|
|
|
|
* see the same MSB (and overhead like doing a single TSC
|
|
|
|
* read per MSB value etc).
|
|
|
|
*
|
|
|
|
* - We're doing 2 reads per loop (LSB, MSB), and we expect
|
|
|
|
* them each to take about a microsecond on real hardware.
|
|
|
|
* So we expect a count value of around 100. But we'll be
|
|
|
|
* generous, and accept anything over 50.
|
|
|
|
*
|
|
|
|
* - if the PIT is stuck, and we see *many* more reads, we
|
|
|
|
* return early (and the next caller of pit_expect_msb()
|
|
|
|
* then consider it a failure when they don't see the
|
|
|
|
* next expected value).
|
|
|
|
*
|
|
|
|
* These expectations mean that we know that we have seen the
|
|
|
|
* transition from one expected value to another with a fairly
|
|
|
|
* high accuracy, and we didn't miss any events. We can thus
|
|
|
|
* use the TSC value at the transitions to calculate a pretty
|
|
|
|
* good value for the TSC frequencty.
|
|
|
|
*/
|
2009-08-01 02:45:41 +07:00
|
|
|
static inline int pit_verify_msb(unsigned char val)
|
|
|
|
{
|
|
|
|
/* Ignore LSB */
|
|
|
|
inb(0x42);
|
|
|
|
return inb(0x42) == val;
|
|
|
|
}
|
|
|
|
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
static inline int pit_expect_msb(unsigned char val, u64 *tscp, unsigned long *deltap)
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
{
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
int count;
|
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-01-18 06:35:37 +07:00
|
|
|
u64 tsc = 0, prev_tsc = 0;
|
2008-07-02 01:43:24 +07:00
|
|
|
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
for (count = 0; count < 50000; count++) {
|
2009-08-01 02:45:41 +07:00
|
|
|
if (!pit_verify_msb(val))
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
break;
|
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-01-18 06:35:37 +07:00
|
|
|
prev_tsc = tsc;
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
tsc = get_cycles();
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
}
|
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-01-18 06:35:37 +07:00
|
|
|
*deltap = get_cycles() - prev_tsc;
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
*tscp = tsc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We require _some_ success, but the quality control
|
|
|
|
* will be based on the error terms on the TSC values.
|
|
|
|
*/
|
|
|
|
return count > 5;
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
* How many MSB values do we want to see? We aim for
|
|
|
|
* a maximum error rate of 500ppm (in practice the
|
|
|
|
* real error is much smaller), but refuse to spend
|
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-01-18 06:35:37 +07:00
|
|
|
* more than 50ms on it.
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
*/
|
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-01-18 06:35:37 +07:00
|
|
|
#define MAX_QUICK_PIT_MS 50
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
#define MAX_QUICK_PIT_ITERATIONS (MAX_QUICK_PIT_MS * PIT_TICK_RATE / 1000 / 256)
|
2008-07-02 01:43:24 +07:00
|
|
|
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
static unsigned long quick_pit_calibrate(void)
|
|
|
|
{
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
int i;
|
|
|
|
u64 tsc, delta;
|
|
|
|
unsigned long d1, d2;
|
|
|
|
|
2017-12-22 16:20:11 +07:00
|
|
|
if (!has_legacy_pic())
|
|
|
|
return 0;
|
|
|
|
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
/* Set the Gate high, disable speaker */
|
2008-07-02 01:43:24 +07:00
|
|
|
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
|
|
|
|
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
/*
|
|
|
|
* Counter 2, mode 0 (one-shot), binary count
|
|
|
|
*
|
|
|
|
* NOTE! Mode 2 decrements by two (and then the
|
|
|
|
* output is flipped each time, giving the same
|
|
|
|
* final output frequency as a decrement-by-one),
|
|
|
|
* so mode 0 is much better when looking at the
|
|
|
|
* individual counts.
|
|
|
|
*/
|
2008-07-02 01:43:24 +07:00
|
|
|
outb(0xb0, 0x43);
|
|
|
|
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
/* Start at 0xffff */
|
|
|
|
outb(0xff, 0x42);
|
|
|
|
outb(0xff, 0x42);
|
|
|
|
|
2009-03-17 21:58:26 +07:00
|
|
|
/*
|
|
|
|
* The PIT starts counting at the next edge, so we
|
|
|
|
* need to delay for a microsecond. The easiest way
|
|
|
|
* to do that is to just read back the 16-bit counter
|
|
|
|
* once from the PIT.
|
|
|
|
*/
|
2009-08-01 02:45:41 +07:00
|
|
|
pit_verify_msb(0);
|
2009-03-17 21:58:26 +07:00
|
|
|
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
if (pit_expect_msb(0xff, &tsc, &d1)) {
|
|
|
|
for (i = 1; i <= MAX_QUICK_PIT_ITERATIONS; i++) {
|
|
|
|
if (!pit_expect_msb(0xff-i, &delta, &d2))
|
|
|
|
break;
|
|
|
|
|
2015-06-03 14:39:46 +07:00
|
|
|
delta -= tsc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Extrapolate the error and fail fast if the error will
|
|
|
|
* never be below 500 ppm.
|
|
|
|
*/
|
|
|
|
if (i == 1 &&
|
|
|
|
d1 + d2 >= (delta * MAX_QUICK_PIT_ITERATIONS) >> 11)
|
|
|
|
return 0;
|
|
|
|
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
/*
|
|
|
|
* Iterate until the error is less than 500 ppm
|
|
|
|
*/
|
2009-08-01 02:45:41 +07:00
|
|
|
if (d1+d2 >= delta >> 11)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check the PIT one more time to verify that
|
|
|
|
* all TSC reads were stable wrt the PIT.
|
|
|
|
*
|
|
|
|
* This also guarantees serialization of the
|
|
|
|
* last cycle read ('d2') in pit_expect_msb.
|
|
|
|
*/
|
|
|
|
if (!pit_verify_msb(0xfe - i))
|
|
|
|
break;
|
|
|
|
goto success;
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
}
|
|
|
|
}
|
2014-12-09 13:27:50 +07:00
|
|
|
pr_info("Fast TSC calibration failed\n");
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
return 0;
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
|
|
|
|
success:
|
|
|
|
/*
|
|
|
|
* Ok, if we get here, then we've seen the
|
|
|
|
* MSB of the PIT decrement 'i' times, and the
|
|
|
|
* error has shrunk to less than 500 ppm.
|
|
|
|
*
|
|
|
|
* As a result, we can depend on there not being
|
|
|
|
* any odd delays anywhere, and the TSC reads are
|
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-01-18 06:35:37 +07:00
|
|
|
* reliable (within the error).
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
*
|
|
|
|
* kHz = ticks / time-in-seconds / 1000;
|
|
|
|
* kHz = (t2 - t1) / (I * 256 / PIT_TICK_RATE) / 1000
|
|
|
|
* kHz = ((t2 - t1) * PIT_TICK_RATE) / (I * 256 * 1000)
|
|
|
|
*/
|
|
|
|
delta *= PIT_TICK_RATE;
|
|
|
|
do_div(delta, i*256*1000);
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("Fast TSC calibration using PIT\n");
|
Fast TSC calibration: calculate proper frequency error bounds
In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.
The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).
However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.
So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly. We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.
In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: Jesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-17 22:13:17 +07:00
|
|
|
return delta;
|
x86: quick TSC calibration
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/tsc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 110 insertions(+), 1 deletions(-)
2008-09-05 00:41:22 +07:00
|
|
|
}
|
2008-09-03 21:30:13 +07:00
|
|
|
|
2008-07-02 01:43:24 +07:00
|
|
|
/**
|
2016-06-17 12:22:51 +07:00
|
|
|
* native_calibrate_tsc
|
|
|
|
* Determine TSC frequency via CPUID, else return 0.
|
2008-07-02 01:43:24 +07:00
|
|
|
*/
|
2008-07-02 01:43:36 +07:00
|
|
|
unsigned long native_calibrate_tsc(void)
|
2016-06-17 12:22:51 +07:00
|
|
|
{
|
|
|
|
unsigned int eax_denominator, ebx_numerator, ecx_hz, edx;
|
|
|
|
unsigned int crystal_khz;
|
|
|
|
|
|
|
|
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (boot_cpu_data.cpuid_level < 0x15)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
eax_denominator = ebx_numerator = ecx_hz = edx = 0;
|
|
|
|
|
|
|
|
/* CPUID 15H TSC/Crystal ratio, plus optionally Crystal Hz */
|
|
|
|
cpuid(0x15, &eax_denominator, &ebx_numerator, &ecx_hz, &edx);
|
|
|
|
|
|
|
|
if (ebx_numerator == 0 || eax_denominator == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
crystal_khz = ecx_hz / 1000;
|
|
|
|
|
x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency
native_calibrate_tsc() had a data mapping Intel CPU families
and crystal clock speed, but hardcoded tables are not ideal, and this
approach was already problematic at least in the Skylake X case, as
seen in commit:
b51120309348 ("x86/tsc: Fix erroneous TSC rate on Skylake Xeon")
By examining CPUID data from http://instlatx64.atw.hu/ and units
in the lab, we have found that 3 different scenarios need to be dealt
with, and we can eliminate most of the hardcoded data using an approach a
little more advanced than before:
1. ApolloLake, GeminiLake, CannonLake (and presumably all new chipsets
from this point) report the crystal frequency directly via CPUID.0x15.
That's definitive data that we can rely upon.
2. Skylake, Kabylake and all variants of those two chipsets report a
crystal frequency of zero, however we can calculate the crystal clock
speed by condidering data from CPUID.0x16.
This method correctly distinguishes between the two crystal clock
frequencies present on different Skylake X variants that caused
headaches before.
As the calculations do not quite match the previously-hardcoded values
in some cases (e.g. 23913043Hz instead of 24MHz), TSC refinement is
enabled on all platforms where we had to calculate the crystal
frequency in this way.
3. Denverton (GOLDMONT_X) reports a crystal frequency of zero and does
not support CPUID.0x16, so we leave this entry hardcoded.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: len.brown@intel.com
Cc: linux@endlessm.com
Cc: rafael.j.wysocki@intel.com
Link: http://lkml.kernel.org/r/20190509055417.13152-1-drake@endlessm.com
Link: https://lkml.kernel.org/r/20190419083533.32388-1-drake@endlessm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-05-09 12:54:15 +07:00
|
|
|
/*
|
|
|
|
* Denverton SoCs don't report crystal clock, and also don't support
|
|
|
|
* CPUID.0x16 for the calculation below, so hardcode the 25MHz crystal
|
|
|
|
* clock.
|
|
|
|
*/
|
|
|
|
if (crystal_khz == 0 &&
|
2019-08-28 02:48:24 +07:00
|
|
|
boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT_D)
|
x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency
native_calibrate_tsc() had a data mapping Intel CPU families
and crystal clock speed, but hardcoded tables are not ideal, and this
approach was already problematic at least in the Skylake X case, as
seen in commit:
b51120309348 ("x86/tsc: Fix erroneous TSC rate on Skylake Xeon")
By examining CPUID data from http://instlatx64.atw.hu/ and units
in the lab, we have found that 3 different scenarios need to be dealt
with, and we can eliminate most of the hardcoded data using an approach a
little more advanced than before:
1. ApolloLake, GeminiLake, CannonLake (and presumably all new chipsets
from this point) report the crystal frequency directly via CPUID.0x15.
That's definitive data that we can rely upon.
2. Skylake, Kabylake and all variants of those two chipsets report a
crystal frequency of zero, however we can calculate the crystal clock
speed by condidering data from CPUID.0x16.
This method correctly distinguishes between the two crystal clock
frequencies present on different Skylake X variants that caused
headaches before.
As the calculations do not quite match the previously-hardcoded values
in some cases (e.g. 23913043Hz instead of 24MHz), TSC refinement is
enabled on all platforms where we had to calculate the crystal
frequency in this way.
3. Denverton (GOLDMONT_X) reports a crystal frequency of zero and does
not support CPUID.0x16, so we leave this entry hardcoded.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: len.brown@intel.com
Cc: linux@endlessm.com
Cc: rafael.j.wysocki@intel.com
Link: http://lkml.kernel.org/r/20190509055417.13152-1-drake@endlessm.com
Link: https://lkml.kernel.org/r/20190419083533.32388-1-drake@endlessm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-05-09 12:54:15 +07:00
|
|
|
crystal_khz = 25000;
|
2016-06-17 12:22:51 +07:00
|
|
|
|
2016-11-16 03:27:22 +07:00
|
|
|
/*
|
x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency
native_calibrate_tsc() had a data mapping Intel CPU families
and crystal clock speed, but hardcoded tables are not ideal, and this
approach was already problematic at least in the Skylake X case, as
seen in commit:
b51120309348 ("x86/tsc: Fix erroneous TSC rate on Skylake Xeon")
By examining CPUID data from http://instlatx64.atw.hu/ and units
in the lab, we have found that 3 different scenarios need to be dealt
with, and we can eliminate most of the hardcoded data using an approach a
little more advanced than before:
1. ApolloLake, GeminiLake, CannonLake (and presumably all new chipsets
from this point) report the crystal frequency directly via CPUID.0x15.
That's definitive data that we can rely upon.
2. Skylake, Kabylake and all variants of those two chipsets report a
crystal frequency of zero, however we can calculate the crystal clock
speed by condidering data from CPUID.0x16.
This method correctly distinguishes between the two crystal clock
frequencies present on different Skylake X variants that caused
headaches before.
As the calculations do not quite match the previously-hardcoded values
in some cases (e.g. 23913043Hz instead of 24MHz), TSC refinement is
enabled on all platforms where we had to calculate the crystal
frequency in this way.
3. Denverton (GOLDMONT_X) reports a crystal frequency of zero and does
not support CPUID.0x16, so we leave this entry hardcoded.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: len.brown@intel.com
Cc: linux@endlessm.com
Cc: rafael.j.wysocki@intel.com
Link: http://lkml.kernel.org/r/20190509055417.13152-1-drake@endlessm.com
Link: https://lkml.kernel.org/r/20190419083533.32388-1-drake@endlessm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-05-09 12:54:15 +07:00
|
|
|
* TSC frequency reported directly by CPUID is a "hardware reported"
|
2016-11-16 03:27:22 +07:00
|
|
|
* frequency and is the most accurate one so far we have. This
|
|
|
|
* is considered a known frequency.
|
|
|
|
*/
|
x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency
native_calibrate_tsc() had a data mapping Intel CPU families
and crystal clock speed, but hardcoded tables are not ideal, and this
approach was already problematic at least in the Skylake X case, as
seen in commit:
b51120309348 ("x86/tsc: Fix erroneous TSC rate on Skylake Xeon")
By examining CPUID data from http://instlatx64.atw.hu/ and units
in the lab, we have found that 3 different scenarios need to be dealt
with, and we can eliminate most of the hardcoded data using an approach a
little more advanced than before:
1. ApolloLake, GeminiLake, CannonLake (and presumably all new chipsets
from this point) report the crystal frequency directly via CPUID.0x15.
That's definitive data that we can rely upon.
2. Skylake, Kabylake and all variants of those two chipsets report a
crystal frequency of zero, however we can calculate the crystal clock
speed by condidering data from CPUID.0x16.
This method correctly distinguishes between the two crystal clock
frequencies present on different Skylake X variants that caused
headaches before.
As the calculations do not quite match the previously-hardcoded values
in some cases (e.g. 23913043Hz instead of 24MHz), TSC refinement is
enabled on all platforms where we had to calculate the crystal
frequency in this way.
3. Denverton (GOLDMONT_X) reports a crystal frequency of zero and does
not support CPUID.0x16, so we leave this entry hardcoded.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: len.brown@intel.com
Cc: linux@endlessm.com
Cc: rafael.j.wysocki@intel.com
Link: http://lkml.kernel.org/r/20190509055417.13152-1-drake@endlessm.com
Link: https://lkml.kernel.org/r/20190419083533.32388-1-drake@endlessm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-05-09 12:54:15 +07:00
|
|
|
if (crystal_khz != 0)
|
|
|
|
setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
if (crystal_khz == 0 && boot_cpu_data.cpuid_level >= 0x16) {
|
|
|
|
unsigned int eax_base_mhz, ebx, ecx, edx;
|
|
|
|
|
|
|
|
cpuid(0x16, &eax_base_mhz, &ebx, &ecx, &edx);
|
|
|
|
crystal_khz = eax_base_mhz * 1000 *
|
|
|
|
eax_denominator / ebx_numerator;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (crystal_khz == 0)
|
|
|
|
return 0;
|
2016-11-16 03:27:22 +07:00
|
|
|
|
2016-11-16 03:27:23 +07:00
|
|
|
/*
|
|
|
|
* For Atom SoCs TSC is the only reliable clocksource.
|
|
|
|
* Mark TSC reliable so no watchdog on it.
|
|
|
|
*/
|
|
|
|
if (boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT)
|
|
|
|
setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
|
|
|
|
|
x86/tsc: Set LAPIC timer period to crystal clock frequency
The APIC timer calibration (calibrate_APIC_timer()) can be skipped
in cases where we know the APIC timer frequency. On Intel SoCs,
we believe that the APIC is fed by the crystal clock; this would make
sense, and the crystal clock frequency has been verified against the
APIC timer calibration result on ApolloLake, GeminiLake, Kabylake,
CoffeeLake, WhiskeyLake and AmberLake.
Set lapic_timer_period based on the crystal clock frequency
accordingly.
APIC timer calibration would normally be skipped on modern CPUs
by nature of the TSC deadline timer being used instead,
however this change is still potentially useful, e.g. if the
TSC deadline timer has been disabled with a kernel parameter.
calibrate_APIC_timer() uses the legacy timer, but we are seeing
new platforms that omit such legacy functionality, so avoiding
such codepaths is becoming more important.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: len.brown@intel.com
Cc: linux@endlessm.com
Cc: rafael.j.wysocki@intel.com
Link: http://lkml.kernel.org/r/20190509055417.13152-3-drake@endlessm.com
Link: https://lkml.kernel.org/r/20190419083533.32388-1-drake@endlessm.com
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1904031206440.1967@nanos.tec.linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-05-09 12:54:17 +07:00
|
|
|
#ifdef CONFIG_X86_LOCAL_APIC
|
|
|
|
/*
|
|
|
|
* The local APIC appears to be fed by the core crystal clock
|
|
|
|
* (which sounds entirely sensible). We can set the global
|
|
|
|
* lapic_timer_period here to avoid having to calibrate the APIC
|
|
|
|
* timer later.
|
|
|
|
*/
|
|
|
|
lapic_timer_period = crystal_khz * 1000 / HZ;
|
|
|
|
#endif
|
|
|
|
|
2016-06-17 12:22:51 +07:00
|
|
|
return crystal_khz * ebx_numerator / eax_denominator;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long cpu_khz_from_cpuid(void)
|
|
|
|
{
|
|
|
|
unsigned int eax_base_mhz, ebx_max_mhz, ecx_bus_mhz, edx;
|
|
|
|
|
|
|
|
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (boot_cpu_data.cpuid_level < 0x16)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
eax_base_mhz = ebx_max_mhz = ecx_bus_mhz = edx = 0;
|
|
|
|
|
|
|
|
cpuid(0x16, &eax_base_mhz, &ebx_max_mhz, &ecx_bus_mhz, &edx);
|
|
|
|
|
|
|
|
return eax_base_mhz * 1000;
|
|
|
|
}
|
|
|
|
|
2018-07-20 03:55:44 +07:00
|
|
|
/*
|
|
|
|
* calibrate cpu using pit, hpet, and ptimer methods. They are available
|
|
|
|
* later in boot after acpi is initialized.
|
2016-06-17 12:22:51 +07:00
|
|
|
*/
|
2018-07-20 03:55:44 +07:00
|
|
|
static unsigned long pit_hpet_ptimer_calibrate_cpu(void)
|
2008-07-02 01:43:24 +07:00
|
|
|
{
|
2008-09-04 22:18:53 +07:00
|
|
|
u64 tsc1, tsc2, delta, ref1, ref2;
|
2008-09-03 05:54:47 +07:00
|
|
|
unsigned long tsc_pit_min = ULONG_MAX, tsc_ref_min = ULONG_MAX;
|
2018-07-20 03:55:44 +07:00
|
|
|
unsigned long flags, latch, ms;
|
2008-09-04 22:18:59 +07:00
|
|
|
int hpet = is_hpet_enabled(), i, loopmin;
|
2008-07-02 01:43:24 +07:00
|
|
|
|
2008-09-03 05:54:47 +07:00
|
|
|
/*
|
|
|
|
* Run 5 calibration loops to get the lowest frequency value
|
|
|
|
* (the best estimate). We use two different calibration modes
|
|
|
|
* here:
|
|
|
|
*
|
|
|
|
* 1) PIT loop. We set the PIT Channel 2 to oneshot mode and
|
|
|
|
* load a timeout of 50ms. We read the time right after we
|
|
|
|
* started the timer and wait until the PIT count down reaches
|
|
|
|
* zero. In each wait loop iteration we read the TSC and check
|
|
|
|
* the delta to the previous read. We keep track of the min
|
|
|
|
* and max values of that delta. The delta is mostly defined
|
2018-11-06 00:10:40 +07:00
|
|
|
* by the IO time of the PIT access, so we can detect when
|
|
|
|
* any disturbance happened between the two reads. If the
|
2008-09-03 05:54:47 +07:00
|
|
|
* maximum time is significantly larger than the minimum time,
|
|
|
|
* then we discard the result and have another try.
|
|
|
|
*
|
|
|
|
* 2) Reference counter. If available we use the HPET or the
|
|
|
|
* PMTIMER as a reference to check the sanity of that value.
|
|
|
|
* We use separate TSC readouts and check inside of the
|
2018-11-06 00:10:40 +07:00
|
|
|
* reference read for any possible disturbance. We dicard
|
2008-09-03 05:54:47 +07:00
|
|
|
* disturbed values here as well. We do that around the PIT
|
|
|
|
* calibration delay loop as we have to wait for a certain
|
|
|
|
* amount of time anyway.
|
|
|
|
*/
|
2008-09-04 22:18:59 +07:00
|
|
|
|
|
|
|
/* Preset PIT loop values */
|
|
|
|
latch = CAL_LATCH;
|
|
|
|
ms = CAL_MS;
|
|
|
|
loopmin = CAL_PIT_LOOPS;
|
|
|
|
|
|
|
|
for (i = 0; i < 3; i++) {
|
2008-09-03 21:30:13 +07:00
|
|
|
unsigned long tsc_pit_khz;
|
2008-09-03 05:54:47 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the start value and the reference count of
|
2008-09-03 21:30:13 +07:00
|
|
|
* hpet/pmtimer when available. Then do the PIT
|
|
|
|
* calibration, which will take at least 50ms, and
|
|
|
|
* read the end value.
|
2008-09-03 05:54:47 +07:00
|
|
|
*/
|
2008-09-03 21:30:13 +07:00
|
|
|
local_irq_save(flags);
|
2008-09-04 22:18:53 +07:00
|
|
|
tsc1 = tsc_read_refs(&ref1, hpet);
|
2008-09-04 22:18:59 +07:00
|
|
|
tsc_pit_khz = pit_calibrate_tsc(latch, ms, loopmin);
|
2008-09-04 22:18:53 +07:00
|
|
|
tsc2 = tsc_read_refs(&ref2, hpet);
|
2008-09-03 05:54:47 +07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
|
2008-09-03 21:30:13 +07:00
|
|
|
/* Pick the lowest PIT TSC calibration so far */
|
|
|
|
tsc_pit_min = min(tsc_pit_min, tsc_pit_khz);
|
2008-09-03 05:54:47 +07:00
|
|
|
|
|
|
|
/* hpet or pmtimer available ? */
|
2011-01-15 00:06:28 +07:00
|
|
|
if (ref1 == ref2)
|
2008-09-03 05:54:47 +07:00
|
|
|
continue;
|
|
|
|
|
2018-11-06 00:10:40 +07:00
|
|
|
/* Check, whether the sampling was disturbed */
|
2008-09-03 05:54:47 +07:00
|
|
|
if (tsc1 == ULLONG_MAX || tsc2 == ULLONG_MAX)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
tsc2 = (tsc2 - tsc1) * 1000000LL;
|
2008-09-04 22:18:48 +07:00
|
|
|
if (hpet)
|
2008-09-04 22:18:53 +07:00
|
|
|
tsc2 = calc_hpet_ref(tsc2, ref1, ref2);
|
2008-09-04 22:18:48 +07:00
|
|
|
else
|
2008-09-04 22:18:53 +07:00
|
|
|
tsc2 = calc_pmtimer_ref(tsc2, ref1, ref2);
|
2008-09-03 05:54:47 +07:00
|
|
|
|
|
|
|
tsc_ref_min = min(tsc_ref_min, (unsigned long) tsc2);
|
2008-09-04 22:18:59 +07:00
|
|
|
|
|
|
|
/* Check the reference deviation */
|
|
|
|
delta = ((u64) tsc_pit_min) * 100;
|
|
|
|
do_div(delta, tsc_ref_min);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If both calibration results are inside a 10% window
|
|
|
|
* then we can be sure, that the calibration
|
|
|
|
* succeeded. We break out of the loop right away. We
|
|
|
|
* use the reference value, as it is more precise.
|
|
|
|
*/
|
|
|
|
if (delta >= 90 && delta <= 110) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("PIT calibration matches %s. %d loops\n",
|
|
|
|
hpet ? "HPET" : "PMTIMER", i + 1);
|
2008-09-04 22:18:59 +07:00
|
|
|
return tsc_ref_min;
|
2008-09-03 05:54:47 +07:00
|
|
|
}
|
|
|
|
|
2008-09-04 22:18:59 +07:00
|
|
|
/*
|
|
|
|
* Check whether PIT failed more than once. This
|
|
|
|
* happens in virtualized environments. We need to
|
|
|
|
* give the virtual PC a slightly longer timeframe for
|
|
|
|
* the HPET/PMTIMER to make the result precise.
|
|
|
|
*/
|
|
|
|
if (i == 1 && tsc_pit_min == ULONG_MAX) {
|
|
|
|
latch = CAL2_LATCH;
|
|
|
|
ms = CAL2_MS;
|
|
|
|
loopmin = CAL2_PIT_LOOPS;
|
|
|
|
}
|
2008-09-03 05:54:47 +07:00
|
|
|
}
|
2008-07-02 01:43:24 +07:00
|
|
|
|
|
|
|
/*
|
2008-09-03 05:54:47 +07:00
|
|
|
* Now check the results.
|
2008-07-02 01:43:24 +07:00
|
|
|
*/
|
2008-09-03 05:54:47 +07:00
|
|
|
if (tsc_pit_min == ULONG_MAX) {
|
|
|
|
/* PIT gave no useful value */
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_warn("Unable to calibrate against PIT\n");
|
2008-09-03 05:54:47 +07:00
|
|
|
|
|
|
|
/* We don't have an alternative source, disable TSC */
|
2008-09-04 22:18:53 +07:00
|
|
|
if (!hpet && !ref1 && !ref2) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_notice("No reference (HPET/PMTIMER) available\n");
|
2008-09-03 05:54:47 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The alternative source failed as well, disable TSC */
|
|
|
|
if (tsc_ref_min == ULONG_MAX) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_warn("HPET/PMTIMER calibration failed\n");
|
2008-09-03 05:54:47 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Use the alternative source */
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("using %s reference calibration\n",
|
|
|
|
hpet ? "HPET" : "PMTIMER");
|
2008-09-03 05:54:47 +07:00
|
|
|
|
|
|
|
return tsc_ref_min;
|
|
|
|
}
|
2008-07-02 01:43:24 +07:00
|
|
|
|
2008-09-03 05:54:47 +07:00
|
|
|
/* We don't have an alternative source, use the PIT calibration value */
|
2008-09-04 22:18:53 +07:00
|
|
|
if (!hpet && !ref1 && !ref2) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("Using PIT calibration value\n");
|
2008-09-03 05:54:47 +07:00
|
|
|
return tsc_pit_min;
|
2008-07-02 01:43:24 +07:00
|
|
|
}
|
|
|
|
|
2008-09-03 05:54:47 +07:00
|
|
|
/* The alternative source failed, use the PIT calibration value */
|
|
|
|
if (tsc_ref_min == ULONG_MAX) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_warn("HPET/PMTIMER calibration failed. Using PIT calibration.\n");
|
2008-09-03 05:54:47 +07:00
|
|
|
return tsc_pit_min;
|
2008-07-02 01:43:24 +07:00
|
|
|
}
|
|
|
|
|
2008-09-03 05:54:47 +07:00
|
|
|
/*
|
|
|
|
* The calibration values differ too much. In doubt, we use
|
|
|
|
* the PIT value as we know that there are PMTIMERs around
|
2008-09-04 22:18:59 +07:00
|
|
|
* running at double speed. At least we let the user know:
|
2008-09-03 05:54:47 +07:00
|
|
|
*/
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_warn("PIT calibration deviates from %s: %lu %lu\n",
|
|
|
|
hpet ? "HPET" : "PMTIMER", tsc_pit_min, tsc_ref_min);
|
|
|
|
pr_info("Using PIT calibration value\n");
|
2008-09-03 05:54:47 +07:00
|
|
|
return tsc_pit_min;
|
2008-07-02 01:43:24 +07:00
|
|
|
}
|
|
|
|
|
2018-07-20 03:55:44 +07:00
|
|
|
/**
|
|
|
|
* native_calibrate_cpu_early - can calibrate the cpu early in boot
|
|
|
|
*/
|
|
|
|
unsigned long native_calibrate_cpu_early(void)
|
|
|
|
{
|
|
|
|
unsigned long flags, fast_calibrate = cpu_khz_from_cpuid();
|
|
|
|
|
|
|
|
if (!fast_calibrate)
|
|
|
|
fast_calibrate = cpu_khz_from_msr();
|
|
|
|
if (!fast_calibrate) {
|
|
|
|
local_irq_save(flags);
|
|
|
|
fast_calibrate = quick_pit_calibrate();
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
return fast_calibrate;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* native_calibrate_cpu - calibrate the cpu
|
|
|
|
*/
|
2018-07-20 03:55:45 +07:00
|
|
|
static unsigned long native_calibrate_cpu(void)
|
2018-07-20 03:55:44 +07:00
|
|
|
{
|
|
|
|
unsigned long tsc_freq = native_calibrate_cpu_early();
|
|
|
|
|
|
|
|
if (!tsc_freq)
|
|
|
|
tsc_freq = pit_hpet_ptimer_calibrate_cpu();
|
|
|
|
|
|
|
|
return tsc_freq;
|
|
|
|
}
|
|
|
|
|
2017-07-14 10:34:07 +07:00
|
|
|
void recalibrate_cpu_khz(void)
|
2008-07-02 01:43:24 +07:00
|
|
|
{
|
|
|
|
#ifndef CONFIG_SMP
|
|
|
|
unsigned long cpu_khz_old = cpu_khz;
|
|
|
|
|
2016-04-05 13:29:53 +07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_TSC))
|
2017-07-14 10:34:07 +07:00
|
|
|
return;
|
2016-04-05 13:29:53 +07:00
|
|
|
|
2016-06-17 12:22:51 +07:00
|
|
|
cpu_khz = x86_platform.calibrate_cpu();
|
2016-04-05 13:29:53 +07:00
|
|
|
tsc_khz = x86_platform.calibrate_tsc();
|
2016-06-17 12:22:51 +07:00
|
|
|
if (tsc_khz == 0)
|
|
|
|
tsc_khz = cpu_khz;
|
2016-06-17 12:22:52 +07:00
|
|
|
else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
|
|
|
|
cpu_khz = tsc_khz;
|
2016-04-05 13:29:53 +07:00
|
|
|
cpu_data(0).loops_per_jiffy = cpufreq_scale(cpu_data(0).loops_per_jiffy,
|
|
|
|
cpu_khz_old, cpu_khz);
|
2008-07-02 01:43:24 +07:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(recalibrate_cpu_khz);
|
|
|
|
|
2008-07-02 01:43:31 +07:00
|
|
|
|
2010-08-20 07:03:38 +07:00
|
|
|
static unsigned long long cyc2ns_suspend;
|
|
|
|
|
2012-02-13 20:07:27 +07:00
|
|
|
void tsc_save_sched_clock_state(void)
|
2010-08-20 07:03:38 +07:00
|
|
|
{
|
2013-11-29 01:38:42 +07:00
|
|
|
if (!sched_clock_stable())
|
2010-08-20 07:03:38 +07:00
|
|
|
return;
|
|
|
|
|
|
|
|
cyc2ns_suspend = sched_clock();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Even on processors with invariant TSC, TSC gets reset in some the
|
|
|
|
* ACPI system sleep states. And in some systems BIOS seem to reinit TSC to
|
|
|
|
* arbitrary value (still sync'd across cpu's) during resume from such sleep
|
|
|
|
* states. To cope up with this, recompute the cyc2ns_offset for each cpu so
|
|
|
|
* that sched_clock() continues from the point where it was left off during
|
|
|
|
* suspend.
|
|
|
|
*/
|
2012-02-13 20:07:27 +07:00
|
|
|
void tsc_restore_sched_clock_state(void)
|
2010-08-20 07:03:38 +07:00
|
|
|
{
|
|
|
|
unsigned long long offset;
|
|
|
|
unsigned long flags;
|
|
|
|
int cpu;
|
|
|
|
|
2013-11-29 01:38:42 +07:00
|
|
|
if (!sched_clock_stable())
|
2010-08-20 07:03:38 +07:00
|
|
|
return;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
|
2013-11-29 21:40:29 +07:00
|
|
|
/*
|
2016-02-24 06:34:30 +07:00
|
|
|
* We're coming out of suspend, there's no concurrency yet; don't
|
2013-11-29 21:40:29 +07:00
|
|
|
* bother being nice about the RCU stuff, just write to both
|
|
|
|
* data fields.
|
|
|
|
*/
|
|
|
|
|
|
|
|
this_cpu_write(cyc2ns.data[0].cyc2ns_offset, 0);
|
|
|
|
this_cpu_write(cyc2ns.data[1].cyc2ns_offset, 0);
|
|
|
|
|
2010-08-20 07:03:38 +07:00
|
|
|
offset = cyc2ns_suspend - sched_clock();
|
|
|
|
|
2013-11-29 21:40:29 +07:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
per_cpu(cyc2ns.data[0].cyc2ns_offset, cpu) = offset;
|
|
|
|
per_cpu(cyc2ns.data[1].cyc2ns_offset, cpu) = offset;
|
|
|
|
}
|
2010-08-20 07:03:38 +07:00
|
|
|
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
2008-07-02 01:43:31 +07:00
|
|
|
#ifdef CONFIG_CPU_FREQ
|
2019-04-18 21:11:37 +07:00
|
|
|
/*
|
|
|
|
* Frequency scaling support. Adjust the TSC based timer when the CPU frequency
|
2008-07-02 01:43:31 +07:00
|
|
|
* changes.
|
|
|
|
*
|
2019-04-18 21:11:37 +07:00
|
|
|
* NOTE: On SMP the situation is not fixable in general, so simply mark the TSC
|
|
|
|
* as unstable and give up in those cases.
|
2008-07-02 01:43:31 +07:00
|
|
|
*
|
|
|
|
* Should fix up last_tsc too. Currently gettimeofday in the
|
|
|
|
* first tick after the change will be slightly wrong.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static unsigned int ref_freq;
|
|
|
|
static unsigned long loops_per_jiffy_ref;
|
|
|
|
static unsigned long tsc_khz_ref;
|
|
|
|
|
|
|
|
static int time_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct cpufreq_freqs *freq = data;
|
|
|
|
|
2019-04-18 21:11:37 +07:00
|
|
|
if (num_online_cpus() > 1) {
|
|
|
|
mark_tsc_unstable("cpufreq changes on SMP");
|
|
|
|
return 0;
|
|
|
|
}
|
2008-07-02 01:43:31 +07:00
|
|
|
|
|
|
|
if (!ref_freq) {
|
|
|
|
ref_freq = freq->old;
|
2019-04-18 21:11:37 +07:00
|
|
|
loops_per_jiffy_ref = boot_cpu_data.loops_per_jiffy;
|
2008-07-02 01:43:31 +07:00
|
|
|
tsc_khz_ref = tsc_khz;
|
|
|
|
}
|
2019-04-18 21:11:37 +07:00
|
|
|
|
2008-07-02 01:43:31 +07:00
|
|
|
if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
|
2019-04-18 21:11:37 +07:00
|
|
|
(val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
|
|
|
|
boot_cpu_data.loops_per_jiffy =
|
|
|
|
cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
|
2008-07-02 01:43:31 +07:00
|
|
|
|
|
|
|
tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
|
|
|
|
if (!(freq->flags & CPUFREQ_CONST_LOOPS))
|
|
|
|
mark_tsc_unstable("cpufreq changes");
|
|
|
|
|
2019-04-29 16:33:58 +07:00
|
|
|
set_cyc2ns_scale(tsc_khz, freq->policy->cpu, rdtsc());
|
2014-06-24 19:48:19 +07:00
|
|
|
}
|
2008-07-02 01:43:31 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block time_cpufreq_notifier_block = {
|
|
|
|
.notifier_call = time_cpufreq_notifier
|
|
|
|
};
|
|
|
|
|
2016-04-05 13:29:52 +07:00
|
|
|
static int __init cpufreq_register_tsc_scaling(void)
|
2008-07-02 01:43:31 +07:00
|
|
|
{
|
2016-04-05 03:24:59 +07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_TSC))
|
2008-08-25 01:52:06 +07:00
|
|
|
return 0;
|
|
|
|
if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
|
|
|
|
return 0;
|
2008-07-02 01:43:31 +07:00
|
|
|
cpufreq_register_notifier(&time_cpufreq_notifier_block,
|
|
|
|
CPUFREQ_TRANSITION_NOTIFIER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-05 13:29:52 +07:00
|
|
|
core_initcall(cpufreq_register_tsc_scaling);
|
2008-07-02 01:43:31 +07:00
|
|
|
|
|
|
|
#endif /* CONFIG_CPU_FREQ */
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2016-02-29 21:33:47 +07:00
|
|
|
#define ART_CPUID_LEAF (0x15)
|
|
|
|
#define ART_MIN_DENOMINATOR (1)
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If ART is present detect the numerator:denominator to convert to TSC
|
|
|
|
*/
|
2017-11-08 17:09:52 +07:00
|
|
|
static void __init detect_art(void)
|
2016-02-29 21:33:47 +07:00
|
|
|
{
|
|
|
|
unsigned int unused[2];
|
|
|
|
|
|
|
|
if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF)
|
|
|
|
return;
|
|
|
|
|
2017-10-12 23:32:05 +07:00
|
|
|
/*
|
|
|
|
* Don't enable ART in a VM, non-stop TSC and TSC_ADJUST required,
|
|
|
|
* and the TSC counter resets must not occur asynchronously.
|
|
|
|
*/
|
2016-02-29 21:33:47 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
|
|
|
|
!boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ||
|
2017-10-12 23:32:05 +07:00
|
|
|
!boot_cpu_has(X86_FEATURE_TSC_ADJUST) ||
|
|
|
|
tsc_async_resets)
|
2016-02-29 21:33:47 +07:00
|
|
|
return;
|
|
|
|
|
2016-11-19 20:47:33 +07:00
|
|
|
cpuid(ART_CPUID_LEAF, &art_to_tsc_denominator,
|
|
|
|
&art_to_tsc_numerator, unused, unused+1);
|
|
|
|
|
|
|
|
if (art_to_tsc_denominator < ART_MIN_DENOMINATOR)
|
2016-02-29 21:33:47 +07:00
|
|
|
return;
|
|
|
|
|
2016-11-19 20:47:33 +07:00
|
|
|
rdmsrl(MSR_IA32_TSC_ADJUST, art_to_tsc_offset);
|
|
|
|
|
2016-02-29 21:33:47 +07:00
|
|
|
/* Make this sticky over multiple CPU init calls */
|
|
|
|
setup_force_cpu_cap(X86_FEATURE_ART);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-07-02 01:43:34 +07:00
|
|
|
/* clocksource code */
|
|
|
|
|
2016-12-13 20:14:17 +07:00
|
|
|
static void tsc_resume(struct clocksource *cs)
|
|
|
|
{
|
|
|
|
tsc_verify_tsc_adjust(true);
|
|
|
|
}
|
|
|
|
|
2008-07-02 01:43:34 +07:00
|
|
|
/*
|
2014-07-17 04:05:12 +07:00
|
|
|
* We used to compare the TSC to the cycle_last value in the clocksource
|
2008-07-02 01:43:34 +07:00
|
|
|
* structure to avoid a nasty time-warp. This can be observed in a
|
|
|
|
* very small window right after one CPU updated cycle_last under
|
|
|
|
* xtime/vsyscall_gtod lock and the other CPU reads a TSC value which
|
|
|
|
* is smaller than the cycle_last reference value due to a TSC which
|
|
|
|
* is slighty behind. This delta is nowhere else observable, but in
|
|
|
|
* that case it results in a forward time jump in the range of hours
|
|
|
|
* due to the unsigned delta calculation of the time keeping core
|
|
|
|
* code, which is necessary to support wrapping clocksources like pm
|
|
|
|
* timer.
|
2014-07-17 04:05:12 +07:00
|
|
|
*
|
|
|
|
* This sanity check is now done in the core timekeeping code.
|
|
|
|
* checking the result of read_tsc() - cycle_last for being negative.
|
|
|
|
* That works because CLOCKSOURCE_MASK(64) does not mask out any bit.
|
2008-07-02 01:43:34 +07:00
|
|
|
*/
|
2016-12-22 02:32:01 +07:00
|
|
|
static u64 read_tsc(struct clocksource *cs)
|
2008-07-02 01:43:34 +07:00
|
|
|
{
|
2016-12-22 02:32:01 +07:00
|
|
|
return (u64)rdtsc_ordered();
|
2009-08-14 20:47:20 +07:00
|
|
|
}
|
|
|
|
|
2016-12-15 17:44:28 +07:00
|
|
|
static void tsc_cs_mark_unstable(struct clocksource *cs)
|
|
|
|
{
|
|
|
|
if (tsc_unstable)
|
|
|
|
return;
|
2017-03-01 21:53:38 +07:00
|
|
|
|
2016-12-15 17:44:28 +07:00
|
|
|
tsc_unstable = 1;
|
2017-03-01 21:53:38 +07:00
|
|
|
if (using_native_sched_clock())
|
|
|
|
clear_sched_clock_stable();
|
2016-12-15 17:44:28 +07:00
|
|
|
disable_sched_clock_irqtime();
|
|
|
|
pr_info("Marking TSC unstable due to clocksource watchdog\n");
|
|
|
|
}
|
|
|
|
|
2017-04-21 17:14:13 +07:00
|
|
|
static void tsc_cs_tick_stable(struct clocksource *cs)
|
|
|
|
{
|
|
|
|
if (tsc_unstable)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (using_native_sched_clock())
|
|
|
|
sched_clock_tick_stable();
|
|
|
|
}
|
|
|
|
|
2014-07-17 04:05:12 +07:00
|
|
|
/*
|
|
|
|
* .mask MUST be CLOCKSOURCE_MASK(64). See comment above read_tsc()
|
|
|
|
*/
|
2017-12-22 16:20:13 +07:00
|
|
|
static struct clocksource clocksource_tsc_early = {
|
|
|
|
.name = "tsc-early",
|
|
|
|
.rating = 299,
|
|
|
|
.read = read_tsc,
|
|
|
|
.mask = CLOCKSOURCE_MASK(64),
|
|
|
|
.flags = CLOCK_SOURCE_IS_CONTINUOUS |
|
|
|
|
CLOCK_SOURCE_MUST_VERIFY,
|
|
|
|
.archdata = { .vclock_mode = VCLOCK_TSC },
|
|
|
|
.resume = tsc_resume,
|
|
|
|
.mark_unstable = tsc_cs_mark_unstable,
|
|
|
|
.tick_stable = tsc_cs_tick_stable,
|
2018-04-30 17:00:12 +07:00
|
|
|
.list = LIST_HEAD_INIT(clocksource_tsc_early.list),
|
2017-12-22 16:20:13 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Must mark VALID_FOR_HRES early such that when we unregister tsc_early
|
|
|
|
* this one will immediately take over. We will only register if TSC has
|
|
|
|
* been found good.
|
|
|
|
*/
|
2008-07-02 01:43:34 +07:00
|
|
|
static struct clocksource clocksource_tsc = {
|
|
|
|
.name = "tsc",
|
|
|
|
.rating = 300,
|
|
|
|
.read = read_tsc,
|
|
|
|
.mask = CLOCKSOURCE_MASK(64),
|
|
|
|
.flags = CLOCK_SOURCE_IS_CONTINUOUS |
|
2017-12-22 16:20:13 +07:00
|
|
|
CLOCK_SOURCE_VALID_FOR_HRES |
|
2008-07-02 01:43:34 +07:00
|
|
|
CLOCK_SOURCE_MUST_VERIFY,
|
2011-07-14 17:47:22 +07:00
|
|
|
.archdata = { .vclock_mode = VCLOCK_TSC },
|
2016-12-13 20:14:17 +07:00
|
|
|
.resume = tsc_resume,
|
2016-12-15 17:44:28 +07:00
|
|
|
.mark_unstable = tsc_cs_mark_unstable,
|
2017-04-21 17:14:13 +07:00
|
|
|
.tick_stable = tsc_cs_tick_stable,
|
2018-04-30 17:00:12 +07:00
|
|
|
.list = LIST_HEAD_INIT(clocksource_tsc.list),
|
2008-07-02 01:43:34 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
void mark_tsc_unstable(char *reason)
|
|
|
|
{
|
2017-03-01 21:53:38 +07:00
|
|
|
if (tsc_unstable)
|
|
|
|
return;
|
|
|
|
|
|
|
|
tsc_unstable = 1;
|
|
|
|
if (using_native_sched_clock())
|
2013-11-29 01:38:42 +07:00
|
|
|
clear_sched_clock_stable();
|
2017-03-01 21:53:38 +07:00
|
|
|
disable_sched_clock_irqtime();
|
|
|
|
pr_info("Marking TSC unstable due to %s\n", reason);
|
2018-04-30 17:00:12 +07:00
|
|
|
|
|
|
|
clocksource_mark_unstable(&clocksource_tsc_early);
|
|
|
|
clocksource_mark_unstable(&clocksource_tsc);
|
2008-07-02 01:43:34 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(mark_tsc_unstable);
|
|
|
|
|
2008-10-25 07:22:01 +07:00
|
|
|
static void __init check_system_tsc_reliable(void)
|
|
|
|
{
|
2015-09-16 20:10:03 +07:00
|
|
|
#if defined(CONFIG_MGEODEGX1) || defined(CONFIG_MGEODE_LX) || defined(CONFIG_X86_GENERIC)
|
|
|
|
if (is_geode_lx()) {
|
|
|
|
/* RTSC counts during suspend */
|
2008-07-02 01:43:34 +07:00
|
|
|
#define RTSC_SUSP 0x100
|
2015-09-16 20:10:03 +07:00
|
|
|
unsigned long res_low, res_high;
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2015-09-16 20:10:03 +07:00
|
|
|
rdmsr_safe(MSR_GEODE_BUSCONT_CONF0, &res_low, &res_high);
|
|
|
|
/* Geode_LX - the OLPC CPU has a very reliable TSC */
|
|
|
|
if (res_low & RTSC_SUSP)
|
|
|
|
tsc_clocksource_reliable = 1;
|
|
|
|
}
|
2008-07-02 01:43:34 +07:00
|
|
|
#endif
|
2008-10-25 07:22:01 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE))
|
|
|
|
tsc_clocksource_reliable = 1;
|
|
|
|
}
|
2008-07-02 01:43:34 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make an educated guess if the TSC is trustworthy and synchronized
|
|
|
|
* over all CPUs.
|
|
|
|
*/
|
x86: delete __cpuinit usage from all x86 files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings. In any case, they are temporary and harmless.
This removes all the arch/x86 uses of the __cpuinit macros from
all C files. x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-06-19 05:23:59 +07:00
|
|
|
int unsynchronized_tsc(void)
|
2008-07-02 01:43:34 +07:00
|
|
|
{
|
2016-04-05 03:24:59 +07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_TSC) || tsc_unstable)
|
2008-07-02 01:43:34 +07:00
|
|
|
return 1;
|
|
|
|
|
2009-01-27 23:07:08 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-07-02 01:43:34 +07:00
|
|
|
if (apic_is_clustered_box())
|
|
|
|
return 1;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
|
|
|
|
return 0;
|
2009-08-18 06:40:47 +07:00
|
|
|
|
|
|
|
if (tsc_clocksource_reliable)
|
|
|
|
return 0;
|
2008-07-02 01:43:34 +07:00
|
|
|
/*
|
|
|
|
* Intel systems are normally all synchronized.
|
|
|
|
* Exceptions must mark TSC as unstable:
|
|
|
|
*/
|
|
|
|
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
|
|
|
|
/* assume multi socket systems are not synchronized: */
|
|
|
|
if (num_possible_cpus() > 1)
|
2009-08-18 06:40:47 +07:00
|
|
|
return 1;
|
2008-07-02 01:43:34 +07:00
|
|
|
}
|
|
|
|
|
2009-08-18 06:40:47 +07:00
|
|
|
return 0;
|
2008-07-02 01:43:34 +07:00
|
|
|
}
|
|
|
|
|
2016-02-29 21:33:47 +07:00
|
|
|
/*
|
|
|
|
* Convert ART to TSC given numerator/denominator found in detect_art()
|
|
|
|
*/
|
2016-12-22 02:32:01 +07:00
|
|
|
struct system_counterval_t convert_art_to_tsc(u64 art)
|
2016-02-29 21:33:47 +07:00
|
|
|
{
|
|
|
|
u64 tmp, res, rem;
|
|
|
|
|
|
|
|
rem = do_div(art, art_to_tsc_denominator);
|
|
|
|
|
|
|
|
res = art * art_to_tsc_numerator;
|
|
|
|
tmp = rem * art_to_tsc_numerator;
|
|
|
|
|
|
|
|
do_div(tmp, art_to_tsc_denominator);
|
|
|
|
res += tmp + art_to_tsc_offset;
|
|
|
|
|
|
|
|
return (struct system_counterval_t) {.cs = art_related_clocksource,
|
|
|
|
.cycles = res};
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(convert_art_to_tsc);
|
2010-07-28 07:00:00 +07:00
|
|
|
|
2018-03-09 00:28:36 +07:00
|
|
|
/**
|
|
|
|
* convert_art_ns_to_tsc() - Convert ART in nanoseconds to TSC.
|
|
|
|
* @art_ns: ART (Always Running Timer) in unit of nanoseconds
|
|
|
|
*
|
|
|
|
* PTM requires all timestamps to be in units of nanoseconds. When user
|
|
|
|
* software requests a cross-timestamp, this function converts system timestamp
|
|
|
|
* to TSC.
|
|
|
|
*
|
|
|
|
* This is valid when CPU feature flag X86_FEATURE_TSC_KNOWN_FREQ is set
|
|
|
|
* indicating the tsc_khz is derived from CPUID[15H]. Drivers should check
|
|
|
|
* that this flag is set before conversion to TSC is attempted.
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* struct system_counterval_t - system counter value with the pointer to the
|
|
|
|
* corresponding clocksource
|
|
|
|
* @cycles: System counter value
|
|
|
|
* @cs: Clocksource corresponding to system counter value. Used
|
|
|
|
* by timekeeping code to verify comparibility of two cycle
|
|
|
|
* values.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct system_counterval_t convert_art_ns_to_tsc(u64 art_ns)
|
|
|
|
{
|
|
|
|
u64 tmp, res, rem;
|
|
|
|
|
|
|
|
rem = do_div(art_ns, USEC_PER_SEC);
|
|
|
|
|
|
|
|
res = art_ns * tsc_khz;
|
|
|
|
tmp = rem * tsc_khz;
|
|
|
|
|
|
|
|
do_div(tmp, USEC_PER_SEC);
|
|
|
|
res += tmp;
|
|
|
|
|
|
|
|
return (struct system_counterval_t) { .cs = art_related_clocksource,
|
|
|
|
.cycles = res};
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(convert_art_ns_to_tsc);
|
|
|
|
|
|
|
|
|
2010-07-28 07:00:00 +07:00
|
|
|
static void tsc_refine_calibration_work(struct work_struct *work);
|
|
|
|
static DECLARE_DELAYED_WORK(tsc_irqwork, tsc_refine_calibration_work);
|
|
|
|
/**
|
|
|
|
* tsc_refine_calibration_work - Further refine tsc freq calibration
|
|
|
|
* @work - ignored.
|
|
|
|
*
|
|
|
|
* This functions uses delayed work over a period of a
|
|
|
|
* second to further refine the TSC freq value. Since this is
|
|
|
|
* timer based, instead of loop based, we don't block the boot
|
|
|
|
* process while this longer calibration is done.
|
|
|
|
*
|
2011-03-18 02:24:16 +07:00
|
|
|
* If there are any calibration anomalies (too many SMIs, etc),
|
2010-07-28 07:00:00 +07:00
|
|
|
* or the refined calibration is off by 1% of the fast early
|
|
|
|
* calibration, we throw out the new calibration and use the
|
|
|
|
* early calibration.
|
|
|
|
*/
|
|
|
|
static void tsc_refine_calibration_work(struct work_struct *work)
|
|
|
|
{
|
2018-11-06 00:10:40 +07:00
|
|
|
static u64 tsc_start = ULLONG_MAX, ref_start;
|
2010-07-28 07:00:00 +07:00
|
|
|
static int hpet;
|
|
|
|
u64 tsc_stop, ref_stop, delta;
|
|
|
|
unsigned long freq;
|
2017-04-21 16:32:46 +07:00
|
|
|
int cpu;
|
2010-07-28 07:00:00 +07:00
|
|
|
|
|
|
|
/* Don't bother refining TSC on unstable systems */
|
2017-12-22 16:20:13 +07:00
|
|
|
if (tsc_unstable)
|
2018-04-30 17:00:09 +07:00
|
|
|
goto unreg;
|
2010-07-28 07:00:00 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since the work is started early in boot, we may be
|
|
|
|
* delayed the first time we expire. So set the workqueue
|
|
|
|
* again once we know timers are working.
|
|
|
|
*/
|
2018-11-06 00:10:40 +07:00
|
|
|
if (tsc_start == ULLONG_MAX) {
|
|
|
|
restart:
|
2010-07-28 07:00:00 +07:00
|
|
|
/*
|
|
|
|
* Only set hpet once, to avoid mixing hardware
|
|
|
|
* if the hpet becomes enabled later.
|
|
|
|
*/
|
|
|
|
hpet = is_hpet_enabled();
|
|
|
|
tsc_start = tsc_read_refs(&ref_start, hpet);
|
2018-11-06 00:10:40 +07:00
|
|
|
schedule_delayed_work(&tsc_irqwork, HZ);
|
2010-07-28 07:00:00 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
tsc_stop = tsc_read_refs(&ref_stop, hpet);
|
|
|
|
|
|
|
|
/* hpet or pmtimer available ? */
|
2011-01-15 00:06:28 +07:00
|
|
|
if (ref_start == ref_stop)
|
2010-07-28 07:00:00 +07:00
|
|
|
goto out;
|
|
|
|
|
2018-11-06 00:10:40 +07:00
|
|
|
/* Check, whether the sampling was disturbed */
|
|
|
|
if (tsc_stop == ULLONG_MAX)
|
|
|
|
goto restart;
|
2010-07-28 07:00:00 +07:00
|
|
|
|
|
|
|
delta = tsc_stop - tsc_start;
|
|
|
|
delta *= 1000000LL;
|
|
|
|
if (hpet)
|
|
|
|
freq = calc_hpet_ref(delta, ref_start, ref_stop);
|
|
|
|
else
|
|
|
|
freq = calc_pmtimer_ref(delta, ref_start, ref_stop);
|
|
|
|
|
|
|
|
/* Make sure we're within 1% */
|
|
|
|
if (abs(tsc_khz - freq) > tsc_khz/100)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
tsc_khz = freq;
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("Refined TSC clocksource calibration: %lu.%03lu MHz\n",
|
|
|
|
(unsigned long)tsc_khz / 1000,
|
|
|
|
(unsigned long)tsc_khz % 1000);
|
2010-07-28 07:00:00 +07:00
|
|
|
|
2016-07-14 22:22:55 +07:00
|
|
|
/* Inform the TSC deadline clockevent devices about the recalibration */
|
|
|
|
lapic_update_tsc_freq();
|
|
|
|
|
2017-04-21 16:32:46 +07:00
|
|
|
/* Update the sched_clock() rate to match the clocksource one */
|
|
|
|
for_each_possible_cpu(cpu)
|
2017-05-18 03:39:24 +07:00
|
|
|
set_cyc2ns_scale(tsc_khz, cpu, tsc_stop);
|
2017-04-21 16:32:46 +07:00
|
|
|
|
2010-07-28 07:00:00 +07:00
|
|
|
out:
|
2017-12-22 16:20:13 +07:00
|
|
|
if (tsc_unstable)
|
2018-04-30 17:00:09 +07:00
|
|
|
goto unreg;
|
2017-12-22 16:20:13 +07:00
|
|
|
|
2016-02-29 21:33:47 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_ART))
|
|
|
|
art_related_clocksource = &clocksource_tsc;
|
2010-07-28 07:00:00 +07:00
|
|
|
clocksource_register_khz(&clocksource_tsc, tsc_khz);
|
2018-04-30 17:00:09 +07:00
|
|
|
unreg:
|
2017-12-22 16:20:13 +07:00
|
|
|
clocksource_unregister(&clocksource_tsc_early);
|
2010-07-28 07:00:00 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int __init init_tsc_clocksource(void)
|
2008-07-02 01:43:34 +07:00
|
|
|
{
|
2018-07-20 03:55:30 +07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_TSC) || !tsc_khz)
|
2010-12-13 17:28:02 +07:00
|
|
|
return 0;
|
|
|
|
|
2018-04-30 17:00:09 +07:00
|
|
|
if (tsc_unstable)
|
|
|
|
goto unreg;
|
2017-12-22 16:20:13 +07:00
|
|
|
|
2019-03-07 19:09:13 +07:00
|
|
|
if (tsc_clocksource_reliable || no_tsc_watchdog)
|
2008-10-25 07:22:01 +07:00
|
|
|
clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY;
|
2012-02-22 09:19:55 +07:00
|
|
|
|
2013-03-12 10:56:47 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_NONSTOP_TSC_S3))
|
|
|
|
clocksource_tsc.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
|
|
|
|
|
2012-02-22 09:19:55 +07:00
|
|
|
/*
|
2016-11-16 03:27:21 +07:00
|
|
|
* When TSC frequency is known (retrieved via MSR or CPUID), we skip
|
|
|
|
* the refined calibration and directly register it as a clocksource.
|
2012-02-22 09:19:55 +07:00
|
|
|
*/
|
2016-11-18 16:38:09 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) {
|
2017-03-13 21:57:12 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_ART))
|
|
|
|
art_related_clocksource = &clocksource_tsc;
|
2012-02-22 09:19:55 +07:00
|
|
|
clocksource_register_khz(&clocksource_tsc, tsc_khz);
|
2018-04-30 17:00:09 +07:00
|
|
|
unreg:
|
2017-12-22 16:20:13 +07:00
|
|
|
clocksource_unregister(&clocksource_tsc_early);
|
2012-02-22 09:19:55 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-07-28 07:00:00 +07:00
|
|
|
schedule_delayed_work(&tsc_irqwork, 0);
|
|
|
|
return 0;
|
2008-07-02 01:43:34 +07:00
|
|
|
}
|
2010-07-28 07:00:00 +07:00
|
|
|
/*
|
|
|
|
* We use device_initcall here, to ensure we run after the hpet
|
|
|
|
* is fully initialized, which may occur at fs_initcall time.
|
|
|
|
*/
|
|
|
|
device_initcall(init_tsc_clocksource);
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2018-07-20 03:55:45 +07:00
|
|
|
static bool __init determine_cpu_tsc_frequencies(bool early)
|
2008-07-02 01:43:34 +07:00
|
|
|
{
|
2018-07-20 03:55:38 +07:00
|
|
|
/* Make sure that cpu and tsc are not already calibrated */
|
|
|
|
WARN_ON(cpu_khz || tsc_khz);
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2018-07-20 03:55:45 +07:00
|
|
|
if (early) {
|
|
|
|
cpu_khz = x86_platform.calibrate_cpu();
|
|
|
|
tsc_khz = x86_platform.calibrate_tsc();
|
|
|
|
} else {
|
|
|
|
/* We should not be here with non-native cpu calibration */
|
|
|
|
WARN_ON(x86_platform.calibrate_cpu != native_calibrate_cpu);
|
|
|
|
cpu_khz = pit_hpet_ptimer_calibrate_cpu();
|
|
|
|
}
|
2016-06-17 12:22:52 +07:00
|
|
|
|
|
|
|
/*
|
2018-07-30 14:54:20 +07:00
|
|
|
* Trust non-zero tsc_khz as authoritative,
|
2016-06-17 12:22:52 +07:00
|
|
|
* and use it to sanity check cpu_khz,
|
|
|
|
* which will be off if system timer is off.
|
|
|
|
*/
|
2016-06-17 12:22:51 +07:00
|
|
|
if (tsc_khz == 0)
|
|
|
|
tsc_khz = cpu_khz;
|
2016-06-17 12:22:52 +07:00
|
|
|
else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
|
|
|
|
cpu_khz = tsc_khz;
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2018-07-20 03:55:38 +07:00
|
|
|
if (tsc_khz == 0)
|
|
|
|
return false;
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("Detected %lu.%03lu MHz processor\n",
|
2018-07-20 03:55:38 +07:00
|
|
|
(unsigned long)cpu_khz / KHZ,
|
|
|
|
(unsigned long)cpu_khz % KHZ);
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2017-12-22 12:27:56 +07:00
|
|
|
if (cpu_khz != tsc_khz) {
|
|
|
|
pr_info("Detected %lu.%03lu MHz TSC",
|
2018-07-20 03:55:38 +07:00
|
|
|
(unsigned long)tsc_khz / KHZ,
|
|
|
|
(unsigned long)tsc_khz % KHZ);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long __init get_loops_per_jiffy(void)
|
|
|
|
{
|
2018-09-06 17:03:23 +07:00
|
|
|
u64 lpj = (u64)tsc_khz * KHZ;
|
2018-07-20 03:55:38 +07:00
|
|
|
|
|
|
|
do_div(lpj, HZ);
|
|
|
|
return lpj;
|
|
|
|
}
|
|
|
|
|
2018-07-30 14:54:20 +07:00
|
|
|
static void __init tsc_enable_sched_clock(void)
|
|
|
|
{
|
|
|
|
/* Sanitize TSC ADJUST before cyc2ns gets initialized */
|
|
|
|
tsc_store_and_check_tsc_adjust(true);
|
|
|
|
cyc2ns_init_boot_cpu();
|
|
|
|
static_branch_enable(&__use_tsc);
|
|
|
|
}
|
|
|
|
|
2018-07-20 03:55:38 +07:00
|
|
|
void __init tsc_early_init(void)
|
|
|
|
{
|
|
|
|
if (!boot_cpu_has(X86_FEATURE_TSC))
|
|
|
|
return;
|
2018-10-03 01:01:46 +07:00
|
|
|
/* Don't change UV TSC multi-chassis synchronization */
|
|
|
|
if (is_early_uv_system())
|
|
|
|
return;
|
2018-07-20 03:55:45 +07:00
|
|
|
if (!determine_cpu_tsc_frequencies(true))
|
2018-07-20 03:55:38 +07:00
|
|
|
return;
|
|
|
|
loops_per_jiffy = get_loops_per_jiffy();
|
2018-07-20 03:55:39 +07:00
|
|
|
|
2018-07-30 14:54:20 +07:00
|
|
|
tsc_enable_sched_clock();
|
2018-07-20 03:55:38 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void __init tsc_init(void)
|
|
|
|
{
|
2018-07-20 03:55:45 +07:00
|
|
|
/*
|
|
|
|
* native_calibrate_cpu_early can only calibrate using methods that are
|
|
|
|
* available early in boot.
|
|
|
|
*/
|
|
|
|
if (x86_platform.calibrate_cpu == native_calibrate_cpu_early)
|
|
|
|
x86_platform.calibrate_cpu = native_calibrate_cpu;
|
|
|
|
|
2018-07-20 03:55:38 +07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_TSC)) {
|
|
|
|
setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!tsc_khz) {
|
|
|
|
/* We failed to determine frequencies earlier, try again */
|
2018-07-20 03:55:45 +07:00
|
|
|
if (!determine_cpu_tsc_frequencies(false)) {
|
2018-07-20 03:55:38 +07:00
|
|
|
mark_tsc_unstable("could not calculate TSC khz");
|
|
|
|
setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
|
|
|
|
return;
|
|
|
|
}
|
2018-07-30 14:54:20 +07:00
|
|
|
tsc_enable_sched_clock();
|
2017-12-22 12:27:56 +07:00
|
|
|
}
|
|
|
|
|
2018-07-20 03:55:39 +07:00
|
|
|
cyc2ns_init_secondary_cpus();
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2010-10-05 07:03:20 +07:00
|
|
|
if (!no_sched_irq_time)
|
|
|
|
enable_sched_clock_irqtime();
|
|
|
|
|
2018-07-20 03:55:38 +07:00
|
|
|
lpj_fine = get_loops_per_jiffy();
|
2008-07-02 01:43:34 +07:00
|
|
|
use_tsc_delay();
|
|
|
|
|
2017-06-21 15:23:37 +07:00
|
|
|
check_system_tsc_reliable();
|
|
|
|
|
2017-12-22 16:20:13 +07:00
|
|
|
if (unsynchronized_tsc()) {
|
2008-07-02 01:43:34 +07:00
|
|
|
mark_tsc_unstable("TSCs unsynchronized");
|
2017-12-22 16:20:13 +07:00
|
|
|
return;
|
|
|
|
}
|
2008-07-02 01:43:34 +07:00
|
|
|
|
2019-10-25 00:59:45 +07:00
|
|
|
if (tsc_clocksource_reliable || no_tsc_watchdog)
|
|
|
|
clocksource_tsc_early.flags &= ~CLOCK_SOURCE_MUST_VERIFY;
|
|
|
|
|
2017-12-22 16:20:13 +07:00
|
|
|
clocksource_register_khz(&clocksource_tsc_early, tsc_khz);
|
2016-02-29 21:33:47 +07:00
|
|
|
detect_art();
|
2008-07-02 01:43:34 +07:00
|
|
|
}
|
|
|
|
|
2011-11-16 06:33:56 +07:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/*
|
|
|
|
* If we have a constant TSC and are using the TSC for the delay loop,
|
|
|
|
* we can skip clock calibration if another cpu in the same socket has already
|
|
|
|
* been calibrated. This assumes that CONSTANT_TSC applies to all
|
|
|
|
* cpus in the socket - this should be a safe assumption.
|
|
|
|
*/
|
x86: delete __cpuinit usage from all x86 files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings. In any case, they are temporary and harmless.
This removes all the arch/x86 uses of the __cpuinit macros from
all C files. x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-06-19 05:23:59 +07:00
|
|
|
unsigned long calibrate_delay_is_known(void)
|
2011-11-16 06:33:56 +07:00
|
|
|
{
|
2016-02-19 02:53:43 +07:00
|
|
|
int sibling, cpu = smp_processor_id();
|
2017-10-28 07:11:00 +07:00
|
|
|
int constant_tsc = cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC);
|
|
|
|
const struct cpumask *mask = topology_core_cpumask(cpu);
|
2011-11-16 06:33:56 +07:00
|
|
|
|
2018-07-20 03:55:30 +07:00
|
|
|
if (!constant_tsc || !mask)
|
2016-03-18 14:35:29 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
sibling = cpumask_any_but(mask, cpu);
|
2016-02-19 02:53:43 +07:00
|
|
|
if (sibling < nr_cpu_ids)
|
|
|
|
return cpu_data(sibling).loops_per_jiffy;
|
2011-11-16 06:33:56 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|