Dear J. William Campbell, All
I have two comments regarding this discussion so far. First, Ithink 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