[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

Graeme Russ
2011-05-30T12:46:38Z

Hi Wolfgang,

On 30/05/11 22:31, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4DE383D3.7020008@gmail.com> you wrote:
>>
>> Some platforms are _way_ worse than this - I am sure I have seen a udelay()
>> done with the millisecond time - So udelay(100) could be closer to
>> udelay(1000) - So your above 5 second delay could take as long as 50 seconds!!!
>
> That should show up quickly as soon as you run a "sleep 5" command on
> the console (which is implemented like that).
>
>>> while (test_for_event() == 0) {
>>> now = get_timer(0);
>>> if ((now - start) > timeout)
>>> handle_timeout();
>>>
>>> udelay(100);
>>> }
>>>
>>> Here the loop overhead caused by short delay which may result in a
>>> high number of calls to test_for_event() gets eliminated because
>>> the time reference is independet of the delay.
>>
>> I personally think _any_ timeout greater than 1s (maybe even >500ms) should
>> be done this way
>
> Agreed. As soon as the timeout is >> the interval size of the
> underlying timer service this is the best we can do.
>
>>> start = get_timer(0);
>>>
>>> do_something_complicated();
>>>
>>> now = get_timer(0);
>>>
>>> printf("execution time: %ld millisec\n", now - start);
>>
>> Currently fails spectacularly if do_something_complicated() involves a
>> delay loop which calls reset_timer()
>
> Note that I (intentionally) always used argument 0 in the calls to
> get_timer(). I think we really should get rid of this argument.
>

Agreed - I am more than willing to update all existing timer usages to a
completely new set of timer API functions. I think suffering the pain of
moving to a more well defined API would be better than trying to clunk
around the existing one.

I think we all fairly well agree on how U-Boot will maintain a millisecond
(and possibly microsecond) timer in a platform independent manner using a
platform defined tick counter. Defining a timer API around that is simply a
matter of taste - particularly when it comes to dealing with precision
issues. I think your delta function is a good start - However maybe
something more like ms_delta(u32 from, u32 to) would be a more appropriate
name as it clears the way for us_delta()

Regards,

Graeme