So far the TSC timer driver supports trying hardware calibration first
and using device tree as last resort for its running frequency as the
normal timer.
However when it is used as the early timer, it only supports hardware
calibration and if it fails, the driver just panics. This introduces
a new config option to specify the early timer frequency in MHz and
it should be equal to the value described in the device tree.
Without this patch, the travis-ci testing on QEMU x86_64 target fails
each time after it finishes the 'bootefi selftest' as the test.py see
an error was emitted on the console like this:
TSC frequency is ZERO
resetting ...
### ERROR ### Please RESET the board ###
It's strange that this error is consistently seen on the travis-ci
machine, but only occasionally seen on my local machine (maybe 1 out
of 10). Since QEMU x86_64 target enables BOOTSTAGE support which uses
early timer, with this fix it should work without any failure.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
help
Select this to enable Time-Stamp Counter (TSC) timer for x86.
+config X86_TSC_TIMER_EARLY_FREQ
+ int "x86 TSC timer frequency in MHz when used as the early timer"
+ depends on X86_TSC_TIMER
+ default 1000
+ help
+ Sets the estimated CPU frequency in MHz when TSC is used as the
+ early timer and the frequency can neither be calibrated via some
+ hardware ways, nor got from device tree at the time when device
+ tree is not available yet.
+
config OMAP_TIMER
bool "Omap timer support"
depends on TIMER
return 0;
}
-static void tsc_timer_ensure_setup(bool stop)
+static void tsc_timer_ensure_setup(bool early)
{
if (gd->arch.tsc_base)
return;
if (fast_calibrate)
goto done;
- if (stop)
- panic("TSC frequency is ZERO");
+ if (early)
+ fast_calibrate = CONFIG_X86_TSC_TIMER_EARLY_FREQ;
else
return;