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

Bin Meng bmeng.cn at gmail.com
Sat Oct 13 16:50:02 UTC 2018


Hi Heinrich,

On Sun, Oct 14, 2018 at 12:44 AM Heinrich Schuchardt <xypron.glpk at 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.cn at 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


More information about the U-Boot mailing list