Dear "J. William Campbell", In message <4ddea165.9010...@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: w...@denx.de As of 1992, they're called European Economic Community fries. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
