[U-Boot] [RFC] Review of U-Boot timer API

[Scott McNutt]

Graeme Russ wrote:
> Hi Scott,
> 
> On Wednesday, May 25, 2011, Scott McNutt <smcnutt at psyent.com> wrote:
>> Graeme Russ wrote:
>>
>> Hi Scott,
>>
>> On 25/05/11 22:36, Scott McNutt wrote:
>>
>> Graeme Russ wrote:
>>
>> OK, let's wind back - My original suggestion made no claim towards changing
>> what the API is used for, or how it looks to those who use it (for all
>> practical intents and purposes). I suggested:
>>  - Removing set_timer() and reset_timer()
>>  - Implement get_timer() as a platform independent function
>>
>> Why do you suggest removing set_timer() and reset_timer() ?
>>
>>
>>
>> Because if the timer API is done right, they are not needed
>>
>>
>> To continue the wind back ...
>>
>> In several implementations, reset_timer() actually reloads
>> or re-initializes the hardware timer. This has the effect of
>> synchronizing get_timer() calls with subsequent interrupts.
>> This prevents the early timeouts if the implementer chooses
>> to use an interrupt rate less than 1 ms.
>>
>> So my original question was, how do we address this issue?
> 
> We fix them dear Liza dear Liza ;)
> 
> That is what this thread is trying to figure out

I'm getting a bit frustrated here as I can see we're going
in circles. So I'll just make a few statements a leave well
enough alone.

- I'm not convinced that reset_timer() and set_timer() should be
removed simply because you state that "if the timer API is done
right, they are not needed."

- If an implementation can't use interrupts that occur less
frequently than 1 msec to satisfy the prevailing use of
get_timer(), without breaking existing capability, I consider
the interface that "is done right" to be wrong.

Best Regards,
--Scott