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

Wolfgang Denk
2011-05-26T19:16:42Z

Dear "J. William Campbell",

In message <4DDEA165.9010403@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().

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

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As of 1992, they're called European Economic Community fries.