On Thu, May 26, 2011 at 10:15 AM, J. William Campbell <jwilliamcampb...@comcast.net> wrote: > On 5/25/2011 4:13 PM, Graeme Russ wrote: >> >> Hi Wolfgang >> >> On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk<w...@denx.de> wrote: >>> >>> Dear Graeme Russ, >>> >>> In message<4ddd7066.4000...@gmail.com> you wrote: >>>>>
[snip] >>>> _exactly_ what I am suggesting we do (and what does already happen on >>>> ARM). >>> >>> I don't think so. > > Hi All, > Just to be clear, while ARMv7 has a 64 bit performance counter, it is > not presently used by get_time. This is a change we want to make correct? If it is a constant time-base then yes, that would be preferable - But I doubt all ARM CPUs have these, so these need to be enabled on a case by case basis - get_ticks() can then use them trivially >> >> 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). > > I am not sure why you say at91 appears to use interrupts. There is a comment > in arch/arm/cpu/arm930t/at91/timer.c that says "timer without interrupts" > (line 73). There is the same comment in > arch/arm/cpu/arm930t/at91rm9200/timer.c Nothing in either routine refers to > interrupts, so I would say the timer doesn't use them. I could be wrong of > course. You are correct [snip] >> 6) A 32-bit micro-second tick counter >> - No prescaler needed[6] >> - Max 'glitch free' duration is 71 minutes >> - ISR needed to kick prescaler if events longer than 71 minutes need >> to be timed >> - Can be used by get_timer() trivially > > I think this should be "Can be used by udelay and get_timer trivially" Yes, you are again correct Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
