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

[Bin Meng]

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.

Regards,
Bin