[U-Boot] Timer implementations

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Wolfgang Denk schrieb:
> Dear Reinhard Meyer,
> 
> In message <4CC67CA1.9090302@emk-elektronik.de> you wrote:
>> If implemented with true 64 bits for get_ticks() that function is useable
>> for timeout programming:
>>
>> 	ulong timeval = get_timer (0);
>>
>> 	do {
>> 		...
>> 	} while (get_timer (timeval) < TIMEOUT);
>>
>> It appears that the "base" parameter and return value is in CONFIG_SYS_HZ
>> units, and not in native ticks. That causes 64 bit mul/div every
>> time get_timer() is called. Won't hurt in a timeout loop, though.
> 
> But it will hurt in othe rplaces.
> 
> Also, this code _is_ a bit different, as "get_timer(0)" makes sure
> the counter starts ticking again at 0

Nope, it does not reset the counter itself. It returns the current
counter value (recalculated into CONFIG_SYS_HZ units).
Maybe you mean reset_timer() instead?

In arm9226ejs/omap/timer.c udelay() is implemented with reset_timer()
and get_timer(). Since those functions are inherently not nestable,
beware of base=get_timer(0); do { ... udelay(xx); ... } while (get_timer(base) < TIMEOUT);
constructs!

> , and get_timer() is defined to
> have millisecond resolution.

Actually CONFIG_SYS_HZ (whatever that is).

> So you have a guaranteed 2^32
> milliseconds or 4294967 seconds or about 3.3 years available which
> indeed should be sufficient to implement standard timeouts.

I think it is necessary to summarize all implicit or explicit documented
"defined to have's" regarding the timer and then to verify that all
implementations adhere to them.

Reinhard