On 5/25/2011 9:19 PM, Reinhard Meyer wrote: > Dear Graeme Russ, >> On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2) >> do. at91 is odd - It looks like it uses interrupts, but get_timer() and >> udelay() both end up calling get_timer_raw() (with udelay only having >> millisecond resolution it seems). Some others can be configured to >> increment the timer using an interrupt. ARM is, quite frankly, a >> complete >> mess - It has a mass of *_timer_masked() functions which the core timer >> functions are 'wafer thin' wrapper around, udelay() silently resets >> the timebase trashing get_timer() loops etc. > > Please look at current master for at91. > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/at91/timer.c;h=a0876879d3907af553d832bea187a062a22b9bd4;hb=5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3 > > > > AT91 uses a 32 bit hardware register that by means of a prescaler is made > to increment at a rate in the low megahertz range. > > This results in a wrap approximately every 1000 seconds. > > Actually this would be sufficient for all known uses of udelay() and > get_timer() Hi All Yes, you are correct. It would be sufficient for all known uses of udelay and get_timer(). However, Wolfgang has indicated a strong desire that the performance of the new API work properly over the full 32 bit range of the millisecond delay time. That has been the basic issue for some time here. > timeout loops. However, this hardware register is extended to 64 bits > by software > every time it is read (by detecting rollovers). Yes, but this extension ONLY happens if get_ticks is called via udelay or get_timer. It doesn't happen if you are sitting at the command prompt or off executing a downloaded stand alone program. You might ask "who cares", and I would answer that Wolfgang cares, at least to some level. If the timer overflow triggered an interrupt, we could call get_ticks to update the extended time inside the interrupt routine. But, as far as I know, it doesn't. There are some other ARM processors that have a 32 bit clock derived from a 32 kHz crystal, The will work much as you example does up to 134217 seconds, in fact much longer than your AT91 example does. However, that doesn't touch the 4294967 seconds that the PPC can manage. Without interrupts, the 32 bit (or smaller) counters will NEVER get to the PPC standard if their tick rate exceeds 1 msec. It may be that we need a lower standard, perhaps saying 1000 seconds is enough. But that is not my decision to make. > > Since a wrap of that 64 bit "tick" would occur after the earth has ended, > it is simple to obtain milliseconds from it by doing a 64 bit division. True, but moot because of the above. Best Regards, Bill Campbell > > Best Regards, > Reinhard > >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
