On Fri, May 27, 2011 at 4:52 AM, J. William Campbell <jwilliamcampb...@comcast.net> wrote: > On 5/26/2011 10:53 AM, Wolfgang Denk wrote: >> >> Dear "J. William Campbell", >> >> In message<4dde8639.3090...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
