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

[Graeme Russ]

Hi Wolfgang,

On 30/05/11 22:31, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4DE383D3.7020008 at 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