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
