[U-Boot] Timer implementations

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

Dear Wolfgang Denk,

>> Actually CONFIG_SYS_HZ (whatever that is).
> 
> It is defined to be 1000.

Ok, game with that.

Then the define CONFIG_SYS_HZ should not be in every <board>.h since that
suggests that a board developer has some freedom there...

>> I think it is necessary to summarize all implicit or explicit documented
>> "defined to have's" regarding the timer and then to verify that all
>> implementations adhere to them.
> 
> Indeed - documentation is an are where U-Boot has a serious lack.

OK, to summarize:

1. reset_timer(), get_timer(base) operate with 1ms granularity.
An implementation MUST make that close to 1ms.
On second thought, it might be valueable to be able to set
CONFIG_SYS_HZ to the exact value of the actual granularity.
(for example 1024, if a 32kHz based timer is used).

It should be pointed out, that the pair reset_timer()/get_timer()
cannot be used nested,

and MOST IMPORTANT that some implementations of udelay() might
call reset_timer() and therefore break an outer timeout loop !!!

It is also open if reset_timer() does actually reset the hardware timer
(e.g. tbu/tbl at PPC) - which would be messing up any time difference
calculation using get_ticks() - or does emulate that by remembering
the hardware value and subtracting it later in every subsequent
get_timer() call?

2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
Since they are defined as having 64 bits they MUST not wrap at 32 bits,
i.e. if the hardware provides only 32 bits, the upper 32 bits must be
emulated by software.
Otherwise we have to document that get_ticks() cannot be used to get
64 bit time differences.

OR fall back to a 32 bit get_ticks() that should perhaps increment at
a microsecond rate (see Bill Campbell's post).

If you really closely look at the various implementations of those
timers, you will easyly see the wide variations implemented there.

Best Regards,
Reinhard