[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

[J. William Campbell]

On 7/12/2011 6:10 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
<snip>
> Do we?  What exactly is the needed resolution of the underlying
> hardware timer?  So far, it appears sufficient to have it ticking with
> 1000 Hz or more.  Are there really systems that cannot provide that?
> The only architecture I remember that seemed prolematic was NIOS - but
> then the NIOS documentation suggests that this might actually be
Hi All,
       The NIOS2 "systems" are a FPGA based architecture ("soft" core). 
They CAN have all different kinds of timers. However, there are many 
already out in the world that were built (generated) with a timer that 
has 10 ms resolution. We can't retro-actively change these. We can 
declare them not supported in future releases, but we can't fix the 
resolution problem retroactively.
       I have two comments regarding this discussion so far. First, I 
think using the "time" function name at all is a VERY BAD idea. People 
will confuse it with the "normal" c library function that returns the 
time of day since the epoch. One may say that they should RTFM, but it 
is lots easier to just use another name and avoid all such confusion. 
Second, I think forcing all systems to use 64 bit time stamps is not a 
good idea. The main purpose of the timer API is to provide hardware 
timeouts. 64 bits is vast overkill for such a purpose. Mandating 64 bit 
capability for all u-boots is I think counter-productive. A 32 bit 
timestamp in millisecond resolution plus udelay covers all practical 
cases. The 1 ms resolution is probably inadequate for performance 
measurement, but for every u-boot system that is sometimes used for 
performance measurement, there are 100 (probably even more, like 1000, 
but I don't really have the figures) systems that are just used to boot 
Linux or another stand alone program. So we may need a different API for 
performance measurement that uses higher resolution. On most "larger" 
CPUs, there are hardware timers that can already do this with minimal 
work. On some less-capable CPUs, it may be lots harder, but if you 
aren't doing performance measurement, you don't need it. So I suggest 
that mandating a 64 bit API for some of the processors (68K comes to 
mind) is not really a good idea. It seems counter to the elegant  
simplicity of the rest of u-boot to stick a 64 bit requirement on 
timestamps used to determine if the boot delay is expired.

Best Regards,
J. William Campbell

>   Best regards,
>
>
> Wolfgang Denk
>