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

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear J. William Campbell, All

>        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.

I can only FULLY agree here !!!

Lets just keep the current functions udelay(us) and u32 get_timer(), the
latter maybe without parameter. Remove all *masked() and *reset() functions
and lets change the timeout values used in code that also NIOS uses to
be 20ms more than the hardware requires. It does not really matter if a
*timeout* of 20ms is blown up to 40ms.

Reinhard