From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Date: Wed, 04 Jul 2012 07:27:06 -0700 [thread overview]
Message-ID: <87mx3f38lh.fsf@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207040652240.6760@utopia.booyaka.com> (Paul Walmsley's message of "Wed, 4 Jul 2012 06:53:30 -0600 (MDT)")
Paul Walmsley <paul@pwsan•com> writes:
> On Wed, 4 Jul 2012, Paul Walmsley wrote:
>
>> So the updated patch below uses a clockdomain data flag for this
>> instead.
>
> Here's a version that's a little cleaner. No functional changes.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan•com>
> Date: Wed, 4 Jul 2012 05:22:53 -0600
> Subject: [PATCH] ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
>
> Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
> ("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
> database") broke CORE idle on OMAP3. This prevents device low power
> states.
>
> The root cause is that the 32K sync timer IP block does not support
> smart-idle mode[1], and so the hwmod code keeps the IP block in
> no-idle mode while it is active. This in turn prevents the WKUP
> clockdomain from transitioning to idle. There is a hardcoded sleep
> dependency that prevents the CORE_L3 and CORE_CM clockdomains from
> transitioning to idle when the WKUP clockdomain is active[2], so the
> chip cannot enter any device low power states.
>
> It turns out that there is no need to take the 32k sync timer out of
> idle. The IP block itself probably does not have any native idle
> handling at all, due to its simplicity. Furthermore, the PRCM will
> never request target idle for this IP block while the kernel is
> running, due to the sleep dependency that prevents the WKUP
> clockdomain from idling while the CORE_L3 clockdomain is active. So
> we can safely leave the 32k sync timer in target-force-idle mode, even
> while we continue to access it.
>
> This workaround is implemented by defining a new clockdomain flag,
> CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
> guaranteed to be active whenever the MPU is inactive. If an IP
> block's main functional clock exists inside this clockdomain, and the
> IP block does not support smart-idle modes, then the hwmod code will
> place the IP block into target force-idle mode even when enabled. The
> WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
> no OCP header existed on the 32k sync timer.) Other clockdomains also
> should be marked with this flag, but those changes are deferred until
> a later merge window, to create a minimal fix.
>
> Another theoretically clean fix for this problem would be to implement
> PM runtime-based control for 32k sync timer accesses. These PM
> runtime calls would need to located in a custom clocksource, since the
> 32k sync timer is currently used as an MMIO clocksource. But in
> practice, there would be little benefit to doing so; and there would
> be some cost, due to the addition of unnecessary lines of code and the
> additional CPU overhead of the PM runtime and hwmod code - unnecessary
> in this case.
>
> Another possible fix would have been to modify the pm34xx.c code to
> force the IP block idle before entering WFI. But this would not have
> been an acceptable approach: we are trying to remove this type of
> centralized IP block idle control from the PM code.
>
> This patch is a collaboration between Kevin Hilman <khilman@ti•com>
> and Paul Walmsley <paul@pwsan•com>.
>
> Thanks to Vaibhav Hiremath <hvaibhav@ti•com> for providing comments on
> an earlier version of this patch. Thanks to Tero Kristo
> <t-kristo@ti•com> for identifying a bug in an earlier version of this
> patch. Thanks to Beno?t Cousson <b-cousson@ti•com> for identifying some
> bugs in an earlier version of this patch and for implementation comments.
>
> References:
>
> 1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
> (SWPU223U), available from:
> http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
>
> 2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
> (SWPU223U)
>
> 3. ibid.
>
> Cc: Tony Lindgren <tony@atomide•com>
> Cc: Vaibhav Hiremath <hvaibhav@ti•com>
> Cc: Beno?t Cousson <b-cousson@ti•com>
> Cc: Tero Kristo <t-kristo@ti•com>
> Cc: Kevin Hilman <khilman@ti•com>
> Signed-off-by: Paul Walmsley <paul@pwsan•com>
Tested-by: Kevin Hilman <khilman@ti•com>
I confirm this version is now allowing CORE to hit retention during
suspend.
Benoit, I hope this is OK with you. We need a fix for this in v3.5
since this is last core bug preventing CORE retention in v3.5.
Kevin
next prev parent reply other threads:[~2012-07-04 14:27 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 0:45 [PATCHv2 00/12] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc Paul Walmsley
2012-06-11 0:45 ` [PATCHv2 01/12] ARM: OMAP: PM: Lock clocks list while generating summary Paul Walmsley
2012-06-11 0:45 ` [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer Paul Walmsley
2012-06-14 16:47 ` Cousson, Benoit
2012-06-14 18:04 ` Paul Walmsley
2012-06-14 20:13 ` Cousson, Benoit
2012-06-15 0:18 ` Paul Walmsley
2012-06-15 13:28 ` Cousson, Benoit
2012-07-04 12:48 ` Paul Walmsley
2012-07-04 12:53 ` Paul Walmsley
2012-07-04 14:27 ` Kevin Hilman [this message]
2012-07-04 14:53 ` Paul Walmsley
2012-07-04 16:14 ` Benoit Cousson
2012-07-04 16:41 ` Tero Kristo
2012-07-04 16:43 ` Benoit Cousson
2012-07-04 19:02 ` Paul Walmsley
2012-07-04 16:57 ` Benoit Cousson
2012-07-04 18:59 ` Paul Walmsley
2012-07-05 22:06 ` Kevin Hilman
2012-07-04 16:01 ` Benoit Cousson
2012-07-04 19:05 ` Paul Walmsley
2012-06-11 0:46 ` [PATCHv2 03/12] ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby Paul Walmsley
2012-06-11 0:46 ` [PATCHv2 04/12] ARM: OMAP4: hwmod data: fix 32k sync timer idle modes Paul Walmsley
2012-06-11 9:31 ` Cousson, Benoit
2012-06-13 17:22 ` Paul Walmsley
2012-06-11 0:46 ` [PATCHv2 05/12] ARM: OMAP2+: hwmod: add setup_preprogram hook Paul Walmsley
2012-06-11 0:46 ` [PATCHv2 06/12] ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init Paul Walmsley
2012-06-11 0:46 ` [PATCHv2 07/12] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup Paul Walmsley
2012-06-11 6:29 ` Tony Lindgren
2012-06-14 9:49 ` Paul Walmsley
2012-06-14 9:59 ` Tony Lindgren
2012-06-11 0:46 ` [PATCHv2 08/12] ARM: OMAP4: hwmod data: add SL2IF hardreset line Paul Walmsley
2012-06-14 12:55 ` Cousson, Benoit
2012-06-14 17:09 ` Paul Walmsley
2012-06-14 21:07 ` Cousson, Benoit
2012-06-14 23:02 ` Paul Walmsley
2012-06-15 9:11 ` Cousson, Benoit
2012-06-11 0:46 ` [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb) Paul Walmsley
2012-06-11 6:34 ` Tony Lindgren
2012-06-11 7:13 ` Felipe Balbi
2012-06-11 7:41 ` Tony Lindgren
2012-06-11 7:48 ` Felipe Balbi
2012-06-11 8:03 ` Tony Lindgren
2012-06-11 9:12 ` Felipe Balbi
2012-06-11 0:46 ` [PATCHv2 10/12] ARM: OMAP2+: CM: increase the module disable timeout Paul Walmsley
2012-06-11 0:46 ` [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks Paul Walmsley
2012-06-11 16:28 ` Cousson, Benoit
2012-06-11 16:59 ` Paul Walmsley
2012-06-11 20:15 ` Cousson, Benoit
2012-06-11 0:46 ` [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init Paul Walmsley
2012-06-11 9:54 ` Cousson, Benoit
2012-10-30 4:05 ` Paul Walmsley
2012-10-30 7:41 ` Péter Ujfalusi
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=87mx3f38lh.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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