From mboxrd@z Thu Jan  1 00:00:00 1970
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
Date: Sat, 13 Oct 2018 18:44:11 +0200
Subject: [U-Boot] [PATCH 10/12] x86: tsc: Introduce config option for
 early timer frequency
In-Reply-To: <1539443214-19048-11-git-send-email-bmeng.cn@gmail.com>
References: <1539443214-19048-1-git-send-email-bmeng.cn@gmail.com>
 <1539443214-19048-11-git-send-email-bmeng.cn@gmail.com>
Message-ID: <1235757e-9d2f-840f-5e7a-52acdc0e6bf1@gmx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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