From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: Tony Lindgren <tony@atomide.com>, Kevin Hilman <khilman@ti.com>,
Paul Walmsley <paul@pwsan.com>,
linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
Date: Wed, 7 Nov 2012 16:14:00 -0600 [thread overview]
Message-ID: <509ADD28.20707@ti.com> (raw)
In-Reply-To: <1352314890-22224-4-git-send-email-jon-hunter@ti.com>
On Wednesday 07 November 2012 01:01 PM, Jon Hunter wrote:
> Errata Titles:
> i103: Delay needed to read some GP timer, WD timer and sync timer registers
> after wakeup (OMAP3/4)
> i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
>
> Description (i103/i767):
> If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1),
> due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
> registers right after the timer interface clock (L4) goes from stopped to
> active may not return the expected values. The most common event leading to
> this situation occurs upon wake up from idle.
>
> GPTimer non-posted synchronization mode is not impacted by this limitation.
>
> Workarounds:
> 1). Disable posted mode
> 2). Use static dependency between timer clock domain and MPUSS clock domain
> 3). Use no-idle mode when the timer is active
>
> Workarounds #2 and #3 are not pratical from a power standpoint and so
> workaround #1 has been implemented. Disabling posted mode adds some CPU overhead
> for configuring the timers as the CPU has to wait for the write to complete.
> However, disabling posted mode guarantees correct operation.
>
> Please note that it is safe to use posted mode for timers if the counter (TCRR)
> and capture (TCARx) registers will never be read. An example of this is the
> clock-event system timer. This is used by the kernel to schedule events however,
> the timers counter is never read and capture registers are not used. Given that
> the kernel configures this timer often yet never reads the counter register it
> is safe to enable posted mode in this case. Hence, for the timer used for kernel
> clock-events, posted mode is enabled by overriding the errata for devices that
> are impacted by this defect.
>
> For drivers using the timers that do not read the counter or capture registers
> and wish to use posted mode, can override the errata and enable posted mode by
> making the following function calls.
>
> omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
> omap_dm_timer_enable_posted(timer);
>
> Both dmtimers and watchdogs are impacted by this defect this patch only
> implements the workaround for the dmtimer. Currently the watchdog driver does
> not read the counter register and so no workaround is necessary.
>
> Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
>
> Please note that now calls to omap_dm_timer_enable_posted() may not able posted
> mode if the device is impacted by this errata. Therefore, for system-timers
> check to see if the intended posted mode matches the actual. If it does not then
> there is a configuration error in the system timers posted configuration.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
Looks sensible considering alternative WAs.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
Date: Wed, 7 Nov 2012 16:14:00 -0600 [thread overview]
Message-ID: <509ADD28.20707@ti.com> (raw)
In-Reply-To: <1352314890-22224-4-git-send-email-jon-hunter@ti.com>
On Wednesday 07 November 2012 01:01 PM, Jon Hunter wrote:
> Errata Titles:
> i103: Delay needed to read some GP timer, WD timer and sync timer registers
> after wakeup (OMAP3/4)
> i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
>
> Description (i103/i767):
> If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1),
> due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
> registers right after the timer interface clock (L4) goes from stopped to
> active may not return the expected values. The most common event leading to
> this situation occurs upon wake up from idle.
>
> GPTimer non-posted synchronization mode is not impacted by this limitation.
>
> Workarounds:
> 1). Disable posted mode
> 2). Use static dependency between timer clock domain and MPUSS clock domain
> 3). Use no-idle mode when the timer is active
>
> Workarounds #2 and #3 are not pratical from a power standpoint and so
> workaround #1 has been implemented. Disabling posted mode adds some CPU overhead
> for configuring the timers as the CPU has to wait for the write to complete.
> However, disabling posted mode guarantees correct operation.
>
> Please note that it is safe to use posted mode for timers if the counter (TCRR)
> and capture (TCARx) registers will never be read. An example of this is the
> clock-event system timer. This is used by the kernel to schedule events however,
> the timers counter is never read and capture registers are not used. Given that
> the kernel configures this timer often yet never reads the counter register it
> is safe to enable posted mode in this case. Hence, for the timer used for kernel
> clock-events, posted mode is enabled by overriding the errata for devices that
> are impacted by this defect.
>
> For drivers using the timers that do not read the counter or capture registers
> and wish to use posted mode, can override the errata and enable posted mode by
> making the following function calls.
>
> omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
> omap_dm_timer_enable_posted(timer);
>
> Both dmtimers and watchdogs are impacted by this defect this patch only
> implements the workaround for the dmtimer. Currently the watchdog driver does
> not read the counter register and so no workaround is necessary.
>
> Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
>
> Please note that now calls to omap_dm_timer_enable_posted() may not able posted
> mode if the device is impacted by this errata. Therefore, for system-timers
> check to see if the intended posted mode matches the actual. If it does not then
> there is a configuration error in the system timers posted configuration.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
Looks sensible considering alternative WAs.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
next prev parent reply other threads:[~2012-11-07 22:14 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-07 19:01 [PATCH V2 00/14] ARM: OMAP: DMTIMER fixes Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 01/14] ARM: OMAP: Add DMTIMER definitions for posted mode Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 22:04 ` Santosh Shilimkar
2012-11-07 22:04 ` Santosh Shilimkar
2012-11-07 22:11 ` Jon Hunter
2012-11-07 22:11 ` Jon Hunter
2012-11-07 22:18 ` Santosh Shilimkar
2012-11-07 22:18 ` Santosh Shilimkar
2012-11-07 22:47 ` Jon Hunter
2012-11-07 22:47 ` Jon Hunter
2012-11-08 16:52 ` Jon Hunter
2012-11-08 16:52 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 02/14] ARM: OMAP2+: Disable posted mode for the clocksource timer Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 22:10 ` Santosh Shilimkar
2012-11-07 22:10 ` Santosh Shilimkar
2012-11-07 22:41 ` Jon Hunter
2012-11-07 22:41 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 03/14] ARM: OMAP3+: Implement timer workaround for errata i103 and i767 Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 22:14 ` Santosh Shilimkar [this message]
2012-11-07 22:14 ` Santosh Shilimkar
2012-11-07 23:28 ` Jon Hunter
2012-11-07 23:28 ` Jon Hunter
2012-11-07 23:43 ` Santosh Shilimkar
2012-11-07 23:43 ` Santosh Shilimkar
2012-11-08 16:55 ` Jon Hunter
2012-11-08 16:55 ` Jon Hunter
2012-11-09 19:41 ` Jon Hunter
2012-11-09 19:41 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 04/14] ARM: OMAP: Fix timer posted mode support Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 22:21 ` Santosh Shilimkar
2012-11-07 22:21 ` Santosh Shilimkar
2012-11-07 19:01 ` [PATCH V2 05/14] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 06/14] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 07/14] ARM: OMAP2+: Don't use __omap_dm_timer_reset() Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 08/14] ARM: OMAP: Fix dmtimer reset for timer1 Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 09/14] ARM: OMAP: Don't restore of DMTIMER TISTAT register Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 10/14] ARM: OMAP: Don't restore DMTIMER interrupt status register Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 11/14] ARM: OMAP: Fix spurious interrupts when using timer match feature Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 12/14] ARM: OMAP: Add dmtimer interrupt disable function Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 13/14] ARM: OMAP: Remove unnecessary call to clk_get() Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 19:01 ` [PATCH V2 14/14] ARM: OMAP: Remove __omap_dm_timer_set_source function Jon Hunter
2012-11-07 19:01 ` Jon Hunter
2012-11-07 21:22 ` [PATCH V2 00/14] ARM: OMAP: DMTIMER fixes Tony Lindgren
2012-11-07 21:22 ` Tony Lindgren
2012-11-07 21:44 ` Jon Hunter
2012-11-07 21:44 ` Jon Hunter
2012-11-07 21:52 ` Tony Lindgren
2012-11-07 21:52 ` Tony Lindgren
2012-11-07 22:27 ` Santosh Shilimkar
2012-11-07 22:27 ` Santosh Shilimkar
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=509ADD28.20707@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=jon-hunter@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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 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.