All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] PATCH: fix timer overflow in DaVinci
Date: Wed, 17 Oct 2007 18:49:12 +0200	[thread overview]
Message-ID: <47163D08.8050402@googlemail.com> (raw)
In-Reply-To: <20071016204633.8DA23242E9@gemini.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

  reply	other threads:[~2007-10-17 16:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-16 20:06 [U-Boot-Users] PATCH: fix timer overflow in DaVinci Alex Shnitman
2007-10-16 20:46 ` Wolfgang Denk
2007-10-17 16:49   ` Dirk Behme [this message]
2007-10-17 18:25     ` Wolfgang Denk
2007-10-20  6:24   ` Dirk Behme
     [not found] <000001c85dc8$e5b3d730$9a4d010a@Emea.Arm.com>
2008-01-24 18:12 ` Dirk Behme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47163D08.8050402@googlemail.com \
    --to=dirk.behme@googlemail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.