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

[Graeme Russ <graeme.russ@gmail.com>]

On 25/05/11 18:06, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <BANLkTi==emvE+2Xu-R=hzh3TgFJXs9DnmA@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.

Thought so

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

I'm not really worrying about from the perspective of the new timer API,
it's idle curiosity and getting a better understanding

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

Yes, but you find that there is another level of simplification available...

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

3) Keep calling get_timer() (which you do when checking protocol time-outs)
- This keeps kicking the prescaler

Regards,

Graeme