From: imre.deak@solidboot.com
To: tony@atomide.com
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: [PATCH] ARM: OMAP: timer32k: fix tick count calculation when reprogramming
Date: Wed, 5 Jul 2006 18:58:02 +0300 [thread overview]
Message-ID: <20060705155802.GA32203@localdomain> (raw)
In-Reply-To: <20060705085059.GC4546@atomide.com>
On Wed, Jul 05, 2006 at 01:51:04AM -0700, tony@atomide.com wrote:
> * imre.deak@solidboot.com <imre.deak@solidboot.com> [060703 08:51]:
> > Reprogramming takes places before putting the CPU into idle mode if
> > the dynamic tick option is enabled. The timer is then set to expire
> > at the next pending timer event. Because some time has already passed
> > since the last reported jiffy we have to wait less than the time
> > specified in jiffies.
>
> Looks good to me. This patch seems to need an update though.
Sorry, the patch was against an older commit.. The updated one:
diff --git a/arch/arm/plat-omap/timer32k.c b/arch/arm/plat-omap/timer32k.c
index b0119f1..eba5946 100644
--- a/arch/arm/plat-omap/timer32k.c
+++ b/arch/arm/plat-omap/timer32k.c
@@ -106,6 +106,8 @@ static inline unsigned long omap_32k_tim
static inline void omap_32k_timer_start(unsigned long load_val)
{
+ if (!load_val)
+ load_val = 1;
omap_32k_timer_write(load_val, OMAP1_32K_TIMER_TVR);
omap_32k_timer_write(0x0f, OMAP1_32K_TIMER_CR);
}
@@ -230,7 +232,15 @@ static irqreturn_t omap_32k_timer_interr
*/
void omap_32k_timer_reprogram(unsigned long next_tick)
{
- omap_32k_timer_start(JIFFIES_TO_HW_TICKS(next_tick, 32768) + 1);
+ unsigned long ticks = JIFFIES_TO_HW_TICKS(next_tick, 32768) + 1;
+ unsigned long now = omap_32k_sync_timer_read();
+ unsigned long idled = now - omap_32k_last_tick;
+
+ if (idled + 1 < ticks)
+ ticks -= idled;
+ else
+ ticks = 1;
+ omap_32k_timer_start(ticks);
}
static struct irqaction omap_32k_timer_irq;
>
> Did you do this to fix some specific problem, or just to improve timer
> accuracy?
It's about timer accuracy. Currently we are using the system timer
through the hrtimer API and need a 1 jiffy resolution.
--Imre
>
> > Also make sure we don't set a load value of 0 whose outcome is
> > unspecified according to the TRM.
>
> OK
>
> Tony
prev parent reply other threads:[~2006-07-05 15:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-03 15:51 [PATCH] ARM: OMAP: timer32k: fix tick count calculation when reprogramming imre.deak
2006-07-05 8:51 ` tony
2006-07-05 15:58 ` imre.deak [this message]
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=20060705155802.GA32203@localdomain \
--to=imre.deak@solidboot.com \
--cc=linux-omap-open-source@linux.omap.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox