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