Hi Simon, On Thu, Dec 3, 2015 at 5:06 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 2 December 2015 at 02:30, Bin Meng <bmeng...@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...@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 <s...@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. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot