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

Graeme Russ
2011-05-23T12:29:40Z

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