From patchwork Sun Mar 10 00:46:31 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Grazvydas Ignotas X-Patchwork-Id: 2242751 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id 05CE43FCF6 for ; Sun, 10 Mar 2013 00:50:40 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UEUPl-0002hm-BN; Sun, 10 Mar 2013 00:47:01 +0000 Received: from mail-ee0-f51.google.com ([74.125.83.51]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UEUPg-0002Ra-G7 for linux-arm-kernel@lists.infradead.org; Sun, 10 Mar 2013 00:46:57 +0000 Received: by mail-ee0-f51.google.com with SMTP id d17so1605424eek.10 for ; Sat, 09 Mar 2013 16:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:x-mailer; bh=7HqC96OdKn1ppjWPP6ZzSYP0wISpyvdPk97cD9gJluc=; b=v3aD7ipijcYF27nORmmB+TsR3+8MWDWnD+KYf9uYQ5hdjsNiqFOiNL2tryHiEc4ukr dBTeqgIFL9/VetXRli97f0GJiDmiGdzQBJTR3Ztq1tmL4Z+SjGDi+29gfFerzyYmuMJY ymk1MWr4FnKof7/U53UtJJmbR40gw6djVJmT/ecCxSJp8wuxNR/ztbSn+XJipZLlFIKB XsipQMiU6eAxTwK24c2/Whci2xkqb9ugtd/qLG5lTn7IcdFLiUIR1YUMBcBzKXhw8D9Y sXSWhdYdmr7rlVm6CNwaX1uMxgQVie/ZdNcNdeZLiAjfED9/IvCmj6zMRgIwWgM3sd0g BAwQ== X-Received: by 10.14.211.65 with SMTP id v41mr20678669eeo.33.1362876414130; Sat, 09 Mar 2013 16:46:54 -0800 (PST) Received: from localhost.localdomain (ip-88-119-226-136.static.b4net.lt. [88.119.226.136]) by mx.google.com with ESMTPS id z45sm15662460eeu.10.2013.03.09.16.46.51 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 16:46:52 -0800 (PST) From: Grazvydas Ignotas To: linux-omap@vger.kernel.org Subject: [PATCH] ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb Date: Sun, 10 Mar 2013 02:46:31 +0200 Message-Id: <1362876391-6801-1-git-send-email-notasas@gmail.com> X-Mailer: git-send-email 1.7.9.5 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130309_194656_964121_BD8A2B81 X-CRM114-Status: GOOD ( 11.90 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (notasas[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.83.51 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Tony Lindgren , Paul Walmsley , Grazvydas Ignotas , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org For some unknown reason, allowing hwmod to control MIDLEMODE causes core_pwrdm to not hit idle states for musb in DM3730 at least. I've verified that setting any MIDLEMODE value other than "force standby" before enabling the device causes subsequent suspend attempts to fail with core_pwrdm not entering idle states, even if the driver is unloaded and "force standby" is restored before suspend attempt. Keeping the register set at force standby (reset value) makes it work and device still functions properly. musb has driver-controlled OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps MIDLEMODE is not even needed? Note that TI PSP kernels also have similar workarounds. Signed-off-by: Grazvydas Ignotas --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index ac7e03e..0388bba 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -1666,11 +1666,15 @@ static struct omap_hwmod_class_sysconfig omap3xxx_usbhsotg_sysc = { .rev_offs = 0x0400, .sysc_offs = 0x0404, .syss_offs = 0x0408, - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE| - SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | - SYSC_HAS_AUTOIDLE), - .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | - MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART), + /* + * musb has MMIDLEMODE, but if we ever enable the device not in force + * idle mode, core_pwrdm does not enter idle states at least on 36xx. + * Note that musb also has OTG_FORCESTDBY register that the driver + * uses to control MSTANDBY signal manually. + */ + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP | + SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), .sysc_fields = &omap_hwmod_sysc_type1, };