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

[J. William Campbell]

On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4DDE8639.3090909 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
Hi All,
      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 
move that functionality down into get_ticks, but if you do, you end up 
much like the present scheme where the multiple different get_ticks 
routines expected to cope with expanding the hardware counter properly.  
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).

Best Regards,
Bill Campbell

> before.
>
>> You will have to call the routine that initializes sync_timebase. This
>> routine should have a name, like void init_sync_timebase(void)?
> init_timebase().
>
>
> Best regards,
>
> Wolfgang Denk
>