Wolfgang Denk schrieb:
> Dear Reinhard Meyer,
>
> In message <4cc67ca1.9090...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
