[U-Boot] [RFC] ARM timing code refactoring

[Albert ARIBAUD <albert.aribaud@free.fr>]

Hi Andreas,

Le 24/01/2011 09:25, Andreas Bie?mann a ?crit :

>> That's where I come back to one point of my proposal: if we can get a
>> general framework for get_timer() to return a 64-bit free-running tick
>> value, then we might not need a ms-based get_time() at all, because we
>> could use get_timer() as well for ms timings, provided we can convert
>> our timeout from ms to ticks, i.e.
>>
>> 	/* let's wait 200 milliseconds */
>> 	/* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
>> 	timeout = ms_to_ticks(200);
>> 	u32 start = get_timer(); /* start time, in ticks */
>> 	do {
>> 		...
>> 	} while ( (get_timer() -start)<  timeout);
>
> You may think about the following change to this proposal:
>
> /* lets wait 200 ms */
> /* get the end point of our timeout in ticks */
> u64 timeout_end = get_timer() + ms_to_ticks(200);
> do {
>   ...
> } while ( get_timer()<  timeout_end);

The problem here is that in the loop exit condition you replace a 
difference between two unsigned times (which always yields the correct 
duration) with a comparison of two dates (which does not).

For instance, if at loop entry get_timer() was, say, 10 ticks to 
rollover and the loop timing was 12 ticks, you end up with an end date 
of 2. If your loop body runs long enough, get_timer() may already have 
gone past this and will this stay greater than timeout_end for a very 
long time.

OTOH, using get_timer() on entry of loop and subtracting it from 
get_timer()@each loop iteration always yields the time elapsed, 
unaffected by rollover. You can then safely compare this elapsed time 
with the time-out value.

Amicalement,
-- 
Albert.