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

[Wolfgang Denk]

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

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