Re: [U-Boot] [PATCH 10/12] x86: tsc: Introduce config option for early timer frequency

On 10/13/2018 05:06 PM, Bin Meng wrote:

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 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

drivers/timer/Kconfig | 10 ++++++++++ drivers/timer/tsc_timer.c | 10 ++++++---- 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index 45a256a..f300f87 100644 --- a/drivers/timer/Kconfig +++ b/drivers/timer/Kconfig @@ -82,6 +82,16 @@ config X86_TSC_TIMER help Select this to enable Time-Stamp Counter (TSC) timer for x86.

+config X86_TSC_TIMER_EARLY_FREQ

• int "x86 TSC timer frequency when it is used as the early timer"
• depends on X86_TSC_TIMER
• default 1000000000

default 1000

see suggested code simplification below

• help

•  Sets the TSC timer frequency when TSC is used as the ealy timer
  

Sets the estimated CPU frequency in MHz ...

%s/ealy/early/

•  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 diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c index 6473de2..5dc6f9e 100644 --- a/drivers/timer/tsc_timer.c +++ b/drivers/timer/tsc_timer.c @@ -341,7 +341,7 @@ static int tsc_timer_get_count(struct udevice *dev, u64 *count) return 0; }

-static void tsc_timer_ensure_setup(bool stop) +static void tsc_timer_ensure_setup(bool early) { if (gd->arch.tsc_base) return; @@ -362,10 +362,12 @@ static void tsc_timer_ensure_setup(bool stop) if (fast_calibrate) goto done;

• if (stop)
  

• 	panic("TSC frequency is ZERO");
  

• else
  

• if (early) {
  

• 	gd->arch.clock_rate = CONFIG_X86_TSC_TIMER_EARLY_FREQ;
  

• 	return;
  

• } else {
  return;
  

• }
  

This can be simplified to one line, letting us use values in MHz instead of Hz in Kconfig:

fast_calibrate = CONFIG_X86_TSC_TIMER_EARLY_FREQ;

Why shouldn't we use the default value if early = false and configuration fails?

done: gd->arch.clock_rate = fast_calibrate * 1000000;

Regards

Heinrich