From patchwork Thu Jun 7 06:13:10 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paul Walmsley X-Patchwork-Id: 163486 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 557F0B6FC2 for ; Thu, 7 Jun 2012 16:26:33 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1ScW6s-0001VP-OL; Thu, 07 Jun 2012 06:22:18 +0000 Received: from utopia.booyaka.com ([72.9.107.138]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1ScW6D-0001MY-CR for linux-arm-kernel@lists.infradead.org; Thu, 07 Jun 2012 06:21:41 +0000 Received: (qmail 23469 invoked by uid 1019); 7 Jun 2012 06:21:36 -0000 MBOX-Line: From nobody Thu Jun 7 00:13:10 2012 Subject: [PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer To: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org From: Paul Walmsley Date: Thu, 07 Jun 2012 00:13:10 -0600 Message-ID: <20120607061309.25532.13430.stgit@dusk> In-Reply-To: <20120607060901.25532.68354.stgit@dusk> References: <20120607060901.25532.68354.stgit@dusk> User-Agent: StGit/0.16-37-g27ac3 MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Tony Lindgren , Kevin Hilman , =?utf-8?q?Beno=C3=AEt?= Cousson , Vaibhav Hiremath X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org 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-no-idle mode, even while we continue to access it. This workaround is implemented by programming the force-idle mode for any IP block that only supports the force-idle and no-idle modes. If an IP block is ever released that doesn't support smart-idle and requires no-idle mode to be programmed while it's in use, we'll have to change this behavior. 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 effectively a workaround for a hardware problem. A better hardware approach would have been to implement a smart-idle target idle mode for this IP block. The smart-idle mode in this case would behave identically to the force-idle mode. We consider the force-idle and no-idle target idle mode settings to be intended for debugging and automatic idle management bug workarounds only[4]. This patch is a collaboration between Kevin Hilman and Paul Walmsley . 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. 4. Section 3.1.1.1.2 "Module-Level Clock Management" of The OMAP4430 TRM Rev. vAA (SWPU231AA). Cc: Tony Lindgren Cc: Vaibhav Hiremath Cc: Benoît Cousson Tested-by: Kevin Hilman Signed-off-by: Kevin Hilman Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/omap_hwmod.c | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index b0d3064..6b4ae31 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1124,10 +1124,12 @@ static struct omap_hwmod_addr_space * __init _find_mpu_rt_addr_space(struct omap * _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG * @oh: struct omap_hwmod * * - * If module is marked as SWSUP_SIDLE, force the module out of slave - * idle; otherwise, configure it for smart-idle. If module is marked - * as SWSUP_MSUSPEND, force the module out of master standby; - * otherwise, configure it for smart-standby. No return value. + * Ensure that the OCP_SYSCONFIG register for the IP block represented + * by @oh is set to indicate to the PRCM that the IP block is active. + * Usually this means placing the module into smart-idle mode and + * smart-standby, but if there is a bug in the automatic idle handling + * for the IP block, it may need to be placed into the force-idle or + * no-idle variants of these modes. No return value. */ static void _enable_sysc(struct omap_hwmod *oh) { @@ -1141,8 +1143,26 @@ static void _enable_sysc(struct omap_hwmod *oh) sf = oh->class->sysc->sysc_flags; if (sf & SYSC_HAS_SIDLEMODE) { - idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ? - HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART; + if (oh->flags & HWMOD_SWSUP_SIDLE) { + /* + * IP blocks without smart idle should be left + * in force-idle. Currently this only applies + * to 32k sync "timer" which is guaranteed to + * be accessible when the kernel is running. + * HWMOD_SWSUP_IDLE must also be set on these + * IP blocks to indicate a hardware problem. + * XXX Not an ideal workaround. + */ + if (oh->class->sysc->idlemodes & + (SIDLE_NO | SIDLE_FORCE) && + !(oh->class->sysc->idlemodes & + (SIDLE_SMART || SIDLE_SMART_WKUP))) + idlemode = HWMOD_IDLEMODE_FORCE; + else + idlemode = HWMOD_IDLEMODE_NO; + } else { + idlemode = HWMOD_IDLEMODE_SMART; + } _set_slave_idlemode(oh, idlemode, &v); }