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

Reinhard Meyer u-boot at emk-elektronik.de
Thu May 26 08:36:38 CEST 2011


Dear Albert ARIBAUD,
> Le 26/05/2011 07:25, Graeme Russ a écrit :
> 
>> I think we can still rationalise the timer API as suggested which, as
>> a minimum will:
>>
>>   - Not diminish current functionality for any platform
>>   - Will dramatically reduce the current amount of code duplication
>>   - Improve functionality on some platforms
>>   - Simplify the whole API
>>
>> and then start banging on arch maintainers heads to implement the trivial
>> ISR to kick the prescaler:
> 
> I personally am in favor of cooperation rather than coercion, so please, 
> ask before banging on heads. :)
> 
>> void timer_isr(void *unused)
>> {
>> 	prescaler();
>> }
>>
>> Regards,
>>
>> Graeme
> 
> Seems like we're asymptotically getting to some kind of agreement. For 
> the sake of clarity, could someone summarize what the expected API would 
> be, so that I save my scalp and start looking as the order in which 
> changes should be done on ARM?

No, I don't think so. We currently have and need only two timer API functions
which are used in u-boot:

(1) void udelay(u32 microseconds)

and

(2) u32 get_timer(u32 base)

******************************************
I think we do not need to change that API.
******************************************

(maybe rename get_timer to get_timer_ms, but really why??)

What needs to be done is to eliminate all other timer functions that are
still used in some places (outside the timer domain) like get_ticks(),
set/reset_timer() and maybe other exotic ones.

And what needs to be fixed is all broken implementations of above TWO
functions.

Exactly how that fixing is done, and maybe generalized, factorized,
needlessly complicazed;), awkwardized;) should be another thread!

What should be specified for thsi API is in what time ranges above
functions MUST work, example: udelay() upto 1 second, get_timer
upto 1 year ;), and for reasons of implementation the maximum time
between two "related" get_timer calls.

Related in that sense means calls that are used to calculate a time difference
between them. Consider the following example:

since_epoch = get_timer(0);
while (get_timer(since_epoch) < timeout1)
	/* whatever1 */

/* other actions */

since_epoch = get_timer(0);
while (get_timer(since_epoch) < timeout2)
	/* whatever2 */

It does not matter whether the internal timer has had any wraps that
went undetected while "other actions" were executed.

And clearly, in all sane case, the "whatever" execution part cannot take
many seconds, so it is futile to think about any undetected wraps that need
tens of seconds or more to occur.

Best Regards,

Reinhard


More information about the U-Boot mailing list