Wolfgang Denk wrote:
In message 265CBF1670611D47B47E67959D02EBE3C381D8@mngilex001.Jerusalem.mangodsp.com you wrote:
The get_timer() function in DaVinci's timer.c doesn't handle overflow -- it simply subtracts the "base" from the current time, but if the timer overflowed and the current time is smaller than base, a negative number results. The attached patch fixes that.
I think this is the wrong approach. get_timer() should not have to deal with wrap arounds, because get_timer_masked() is suppsoed to handle this internally. So please fix it there.
Just for my understanding:
In cpu/arm926ejs/davinci/timer.c the overflow of the timer itself is handled, but it is timestamp that overflows?
static ulong timestamp; ... ulong get_timer_raw(void) { ulong now = READ_TIMER;
if (now >= lastinc) { /* normal mode */ timestamp += now - lastinc; } else { /* overflow ... */ timestamp += now + TIMER_LOAD_VAL - lastinc; } lastinc = now; return timestamp; }
With READ_TIMER running at 27MHz and timestamp being 32bit timestamp overflows after ~159s?
Seems that code above is used in a lot timer modules, not only for DaVinci. Then, it depends on READ_TIMER frequency how fast timestamp overflows?
Best regards
Dirk