Hi Heinrich,
On Sun, Oct 14, 2018 at 12:44 AM Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> 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...@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/
Will fix in v2.
>
> > + 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;
>
Ah, yes! This is simpler.
> Why shouldn't we use the default value if early = false and
> configuration fails?
>
if (early = false) that means it is not used as early timer, instead
the normal timer, see tsc_timer_probe(). The normal timer will read
the frequency from device tree instead.
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
