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

J. William Campbell
2011-05-26T18:52:21Z

On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4DDE8639.3090909@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
>