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

[Wolfgang Denk]

Dear Graeme Russ,

In message <BANLkTi==emvE+2Xu-R=hzh3TgFJXs9DnmA at mail.gmail.com> you wrote:
> 
> Well, I think we can leave NTP out of the picture for U-Boot - What I am
> really getting at is are the time bases for udelay() and get_timer() the
> same, and are they always the most accurate which is readily available
> to U-Boot.

Please assume "no" to both questions.

Even more important: stop worrying about this.  The implementation is
noit supposed to make ANY such assumptions.

> I mean udelay() clocked by a tick counter and get_timer() clocked by
> an interrupt versus both being clocked by the same phyiscal tick counter
> (even though both are clocked by the same on-board xtal)

You really should not care about those low-level details.  They can
and shall be ignored.

> > There are counters of many different sizes around. You cannot squeeze
> > a bigger counter into a smaller data ubit, but you can easily stick
> > smaller data into a bigger container. So it seems most natural to me
> > to chose that data type that fits all, i. e. a bigger one.
> 
> Putting the smaller counter into a larger bit space causes problems because
> it wraps to "All 0's" before it gets to "All 1's" - This makes a simple
> unsigned 'current - last' calculation fail at the rollover point. The same
> problem does not occur if you truncate a larger counter into a smaller bit
> space

But then you may significantly reduce the available time-span; you may
see the counter wrapping around every few seconds. You will not be
able to implement - say - a 10 second delay because you cannot know if
there were 1, 2, or more rollovers inbetween.


I see two options:

1) either we can have some signal when the timer wrapes around (like
   an interrupt); in this case it does not matter how big the counter
   itself is, we just increment our own local 64 bit timestamp.

2) Alternatively, I could imagine we use a 64 bit container plus a
   mask which specifiec how many bits are actually used - then we can 
   accommodate counters with any numbers of valid bits.



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
PUBLIC NOTICE AS REQUIRED BY LAW:  Any Use of This  Product,  in  Any
Manner  Whatsoever,  Will  Increase  the  Amount  of  Disorder in the
Universe. Although No Liability Is Implied Herein,  the  Consumer  Is
Warned  That  This  Process Will Ultimately Lead to the Heat Death of
the Universe.