I just had a look at other ARM implementations of timer.c.
Some have a colourful mix of 32 and 64 bits values, resulting
in some 64 bit timer functions returning the upper 32 bits always
cleared.
Some implement udelay() in the "while (xxxtime() < endtime);" variant.
I will fix this for at91 and submit a patch.
I also see that:
void reset_timer(void)
{
gd->timer_reset_value = get_ticks();
}
ulong get_timer(ulong base)
{
return tick_to_time(get_ticks() - gd->timer_reset_value) - base;
}
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.
I guess the theoretically unnecessary function reset_timer() might have been
invented to mask the issue of 32 bit wraparounds when get_timer() is not truly
64 bits???
Reinhard
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
