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

[Graeme Russ]

Dear Reinhard,

On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
<u-boot at emk-elektronik.de> wrote:
> I know its futile to repeat what I suggested about 9 months ago...
>
> Since get_timer() is only used (to my knowledge) to break out of
> loops that do not terminate normally because an expected event does
> not occur, the following API would be simpler and take less time per
> loop:
>
> (I use the names A and B to avoid nitpicking on real function names
> which can be later chosen arbitrarily if this idea prevails...)
>
> uint timeout = A(timeout_in_ms);
>
> do {...} while (!B(timeout));
>
> OR
>
> for (;;) {
>  dowhatever...
>  if (B(timeout)) {
>    error_handling...
>    break;
>  }
> }
>
> Internally both functions would be rather trival:
>
> uint A(uint timeout_in_ms):
>
> return current_tick + timeout_in_ms * ticks_per_ms;
>
> or - for better precision if ticks_per_ms is not a whole number:
>
> return current_tick + (timeout_in_ms * ticks_per_second) / 1000;
>
> or any fractional method to more exactly calculate that equation
> without needing a 64 bit divide.
>
> bool B(uint end_tick):
>
> a simple unsigned subtraction of end_tick minus current_tick,
> evaluating the carry flag. Since we don't get a carry flag in C
> a simple methods will do:
> return ((int)(end_tick - current_tick)) < 0;
>

Elegant and simple but precludes using get_timer() to perform any
meaningful time measurement - However this can be resolved by
doing

	start = get_current_tick();
	...
	duration = get_elapsed_ms(start);

get_elapsed_ms() converts (current_tick - start) to ms. It can still be
a common library routine which calls a HAL function get_tick_frequency()

> options:
> current_tick needs only to be uint32, to get to the largest possible timeout
> any 64 bit tick counter can be right shifted to get a 32 bit value that
> increments just faster than 1ms.
>
> features:
> the only complicated calculation is done before the loop starts, the loop
> itself is not made significantly slower since only a subtraction (and maybe
> shift to scale down a high speed tick) is required.
>

But we run into problems when the tick counter is only 32-bit and the tick
frequency very fast so we would need to extend the tick counter to 64-bit
and have to periodically update it.

Nevertheless, I think we have two very viable options :)

Regards,

Graeme