From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dirk Behme <dirk.behme@googlemail.com>
Date: Wed, 17 Oct 2007 18:49:12 +0200
Subject: [U-Boot-Users] PATCH: fix timer overflow in DaVinci
In-Reply-To: <20071016204633.8DA23242E9@gemini.denx.de>
References: <20071016204633.8DA23242E9@gemini.denx.de>
Message-ID: <47163D08.8050402@googlemail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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