* Tarun Kanti DebBarma tarun.ka...@ti.com [100622 12:35]:
+/**
+ * omap_dm_timer_ms_correction - hardware correction for millisecond timer
+ * @timer: GPTIMER on which the correction support is to be applied
+ * @load: timer load value, used here to extract the expiry count
+ */
+static void
--- On Wed, 7/7/10, Tony Lindgren t...@atomide.com wrote:
Or can we somehow calculate this drift once during init?
If it's set up in the gentime framework, yes; very
standard. AT91 is one model (they all have
32K clocks used to generate the system tick).
--
To unsubscribe from this list:
* David Brownell davi...@pacbell.net [100707 15:26]:
--- On Wed, 7/7/10, Tony Lindgren t...@atomide.com wrote:
Or can we somehow calculate this drift once during init?
If it's set up in the gentime framework, yes; very
standard. AT91 is one model (they all have
32K clocks used to
Tony,
Thanks for the comments! Please see my response.
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, July 07, 2010 5:30 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; R, Sricharan
Subject: Re: [PATCH v3]OMAP:GPTIMER:1ms tick
Generation of 1ms granular GPTIMER events using 32KHz or system
clocks as inputs does not have whole number count value to load
into the register. This inaccurate count value with respect to 1ms
period leads to time drift subsequently. OMAP3 and later silicons
have dedicated registers for
