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

[Graeme Russ]

On Fri, May 27, 2011 at 4:52 AM, J. William Campbell
<jwilliamcampbell at comcast.net> wrote:
> 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

How will sync_timebase() know that a rollover has happened before all 1's?

We would then need to tell sync_timebase() what the maximum value returned
by get_ticks() is. Easier to do have get_ticks() handle it as that is a
platform specific detail

> 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

Correct - the tick counter is a platform specific implementation detail and
therefore the implementation of the HAL (get_ticks()) must also be platform
specific

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

But how do you handle cases like the sc520 - A microsecond counter which
counts 0-999, kicking a 16-bit millisecond counter on rollover. Reading of
the millisecond counter latches the microsecond counter and resets the
millsecond counter to zero

There is no uniform tick counter to read - It has to be fudged - in
get_ticks()

Regards,

Graeme