[U-Boot] [PATCH 1/2] common: Remove timer_init() call for x86

[Simon Glass]

Hi Bin,

On Dec 2, 2015 18:52, "Bin Meng" <bmeng.cn at gmail.com> wrote:
>
> Hi Simon,
>
> On Thu, Dec 3, 2015 at 5:06 AM, Simon Glass <sjg at chromium.org> wrote:
> > Hi Bin,
> >
> > On 2 December 2015 at 02:30, Bin Meng <bmeng.cn at gmail.com> wrote:
> >> With driver model timer support, there should not be an explict
> >> call to timer_init(). Remove this call for x86.
> >>
> >> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
> >> ---
> >>
> >>  common/board_f.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/common/board_f.c b/common/board_f.c
> >> index b035c90..92c42c5 100644
> >> --- a/common/board_f.c
> >> +++ b/common/board_f.c
> >> @@ -807,7 +807,7 @@ static init_fnc_t init_sequence_f[] = {
> >>         /* TODO: can we rename this to timer_init()? */
> >>         init_timebase,
> >>  #endif
> >> -#if defined(CONFIG_X86) || defined(CONFIG_ARM) ||
defined(CONFIG_MIPS) || \
> >> +#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \
> >>                 defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32)
> >>         timer_init,             /* initialize timer */
> >>  #endif
> >> --
> >> 1.8.2.1
> >>
> >
> > Acked-by: Simon Glass <sjg at chromium.org>
> >
> > I have two questions:
> >
> > 1. Should we define a point during boot where the timer becomes
> > available? I can't think of a good reason, but we should think about
> > it.
> >
>
> I would rather not create such a special point for timer, instead we
> just use the generic driver model limitations for the timer as well.
> That is, with dm timer support, these U-Boot timer APIs should only be
> available after driver model is initialized.
>
> > 2. Should we provide an 'early timer' before DM is ready, a bit like
> > we do with the UART?
> >
>
> I cannot think of a use case that uses timer in that early time.

I can thing of two.

Bootstage requires a timer and the earliest we can mark the start time, the
better.

In spl we may want to start DM after we have Sdram running, but Sdram may
need time delays to work.

Regards,
Simon