[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

[J. William Campbell]

On 5/26/2011 12:16 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4DDEA165.9010403 at comcast.net>  you wrote:
>>>> I think it is the task of get_ticks to return the hardware tick counter
>>>> as an  increasing counter, period.  The counter may wrap at some final
>>>> count that is not all ones. That is ok. Sync_timebase deals with the
>>> NO!  We want to be able to compute time differences using simple
>>> unsigned arithmentics, even after a rollover of the counter.  For this
>>> it is mandatory that the counter always gets only incremented until it
>>> wraps around at te end of it's number range, and never gets reset
>>        I agree that that is what must happen, but it should happen inside
>> sync_timebase. Sync_timebase does what is needed to convert the
>> less-than-fully capable counters into a fully capable one. You could
> I think you also want this behaviour for get_ticks().
Hi Wolfgang,
     I understand why that might be nice. But to do that with common 
code would require get_ticks to call a generic routine (say sync_ticks) 
that would expand the counter to 64 bits. Note that this is not always 
totally trivial, as the timer may roll over at 10 ms or some other 
not-so-nice number. Then sync_timer would convert the 64 bit number to 
milliseconds. That approach will work. However, I think that is 
overkill, as we really want the result in milliseconds. If you look at 
the prototype sync_timer routine, you can see an example of how this is 
possible without resorting to 64 bit math. I think that avoiding the 64 
bit math on processors that don't have a 64 bit tick counter (and are 
therefore probably less capable) is worthwhile. I also think that the 
purpose of the get_time routine abstracting the time into milliseconds 
is to avoid dealing with ticks anywhere except in the timer routines. 
Presumably, nobody but sync_timer would ever have reason to call 
get_ticks. If that is not your thinking,  fine, we just disagree on that 
point, and having a sync_ticks to expand the tick counter certainly can 
be done.
>> To date, it has been shown conclusively that this process cannot be
>> relied upon, or we wouldn't be having this discussion.  If we put that
>> functionality inside sync_timebase, it is in one place and debuggable
>> once. All sync_timebase requires to do this is ticks per second and
>> maximum tick value. I do request that counters that decrement be negated
>> in the get_ticks routine, but beyond that, it should be a simple read of
>> the tick register(s).
> I think using ticks per second is not a good idea. It may exceed
> ULONG_MAX, and having to use 64 bit for all calculations is probably
> overkill.  The existing ticks2usec/usec2ticks work fine so far.
I certainly agree using 64 bits for all calculations is vast overkill. 
In fact, I think using 64 bit calculations on systems that have only a 
32 bit or less timer register is probably overkill. :-) However, to 
date,AFAIK,  no processor has exceeded the u32 in ticks per second. As I 
pointed out in a previous e-mail, if they ever do this, we can just drop 
one or 2 bits off the 64 bit counter and in millisecond resolution, 
nobody will ever know.  Also as previously pointed out, usec2ticks is 
not present yet in lots of implementations. Also, if the fundamental 
clock frequency is 32 kHz  (or anything less than 1 MHz), usec2ticks is 
0! This probably rules out using it to get ticks per millisec or ticks 
per sec.

Best Regards,
Bill Campbell

> Best regards,
>
> Wolfgang Denk
>