[U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

On 23/05/11 22:09, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> sorry for jumping in late here (was busy with the ELDK 5.0 release).

I thought you were a bit quite on such a 'touchy' subject ;)

> 
> In message <BANLkTimqGpnsbRSF1hwmjJaaMxV3M_K8gg at mail.gmail.com> you wrote:
>> OK, so in summary, we can (in theory) have:
>>  - A timer API in /lib/ with a single u32 get_timer(u32 base) function
>>  - A HAL with two functions
>>    - u32 get_raw_ticks()
> 
> What des this provide?
> 
>>    - u32 get_raw_tick_rate() which returns the tick rate in kHz (which
>>      max's out at just after 4GHz)
> 
> Can we please omit the _raw part in these names?
> 
>>  - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
>>    and get_tick_rate() to correctly maintain the ms counter used by
>>    get_timer() - This function can be weak (so next point)
> 
> Ditto.  What would that do?  If it gets milliseconds as the name
> suggest, that's already the function needed for get_timer()?

OK, there appears to be a consensus that not all hardware actually supports
a free-running timer with 1ms resolution. To overcome this, the idea is to
create a common library function which maintains the free running counter.
The library function acts as a pre-scaler using a 'raw tick counter' and a
'raw tick rate' supplied by the low level architecture. We define this weak
so that if the architecture can provide a free running 1ms counter, there
is no (code size) penalty

This approach eliminates all the existing per-arch code which (attempts) to
manage the time base behind get time. So we simplify each arch down to it's
bare essentials - Provide a counter which increments at a natural fixed
rate and what the rate is - Let common library code deal with the rest.

>>  - If the hardware supports a native 32-bit ms counter, get_raw_ms()
>>    can be overridden to simply return the hardware counter. In this case,
>>    get_raw_ticks() would return 1
> 
> I don't think this is possible on may systems, so I doubt if this is
> auseful approach.

x86 does as it implements a 1ms interrupt (I know other systems do as well)

>>  - Calling of get_raw_ticks() regularly in the main loop (how ofter will
>>    depend on the raw tick rate, but I image it will never be necessary
>>    to call more often than once every few minutes)
> 
> NAK. This concept is fundamentally broken.  I will not accept it.

Some existing timers are fundamentally broken - The glitch at the
0xffffffff to 0x00000000 rollover or rollover early - The method discussed
in this thread eliminates all such glitches. Provided pre-scaler in /lib/
(triggered by get_timer() usually) is called often enough (71 minutes for a
32-bit 1MHz counter) then there is no need. Even then, it is only important
over the time period you are measuring (i.e. two independent 5s delays 2
hours apart will not be a problem)

Kicking the pre-scaler (like kicking the watchdog) eliminates the problem
entirely.

> 
>>  - If the hardware implements a native 32-bit 1ms counter, no call in
>>    the main loop is required
> 
> We should make no such requirements.

No such requirement of what?

>>  - An optional HAL function u32 get_raw_us() which can be used for
>>    performance profiling (must wrap correctly)
> 
> Sorry for rewinding the thread.
> 
> Can we not start simple, say by a plain free-runnign 64 bit counter,
> be it implemented in hardwar eor in software?  On PowerPC, we have

That's exactly what we are suggesting - Let the hardware be free to
implement the counter at whatever frequency suits it. 64-bit is not needed
in reality

> this immediately in form of the time base register (or more precisely
> in form of the two 32 bit registers tbu and tbl representing time base
> upper and time base lower).
> 
> Modelling a similar interface using _any_ kind of timer service should
> be trivial.  And from there, we can just use the existing code again.

Yes, have the library function manage the actual '1ms' aspect

Regards,

Graeme