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

[Wolfgang Denk]

Dear Graeme Russ,

In message <4DDA5334.4060308 at gmail.com> you wrote:
>
> >>  - 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

Indeed.  I guess most of them do not.

> 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

What are "raw" ticks?  And what are "cooked" ticks, then?

> so that if the architecture can provide a free running 1ms counter, there
> is no (code size) penalty

Why do we need a free running 1ms counter at all?  Any free running
counter of at least millisecoind resolution should be good enough.

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

Did you have a look at the PowerPC implementation?  I'd like to see
this used as reference.

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

We already have this nightmare of code for triggering the watchdog on
systems that use it.

Assuming there are places in the main loop that get executed often
enough is a broken concept, and I will not accept any such code.

> over the time period you are measuring (i.e. two independent 5s delays 2
> hours apart will not be a problem)

What is the practical purpose of get_timer()?  What is the longest
interval we have to cover?  And what is the problem with a rollover?

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

Of making any calls in the main loop.

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

It may not be needed on some systems, but may be needed on others
where 32 bit is too short.  Let's use the common base that is know to
work on all systems, even if it's not strictly needed on all of them.

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

This is what PPC is doing. And I understand that Reinhard did the same
in software for AT91.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Alles Gescheite ist schon gedacht worden, man muß nur versuchen,
es noch einmal zu denken.          -- Goethe, Maximen und Reflexionen