From patchwork Tue Jun 7 21:17:49 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Hilman X-Patchwork-Id: 859702 Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p57LK0CA025353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jun 2011 21:20:27 GMT Received: from daredevil.linux-foundation.org (localhost [127.0.0.1]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p57LHudw013492; Tue, 7 Jun 2011 14:17:57 -0700 Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with SMTP id p57LHqqA013471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jun 2011 14:17:54 -0700 Received: from mail-px0-f177.google.com ([209.85.212.177]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTe6VgBws7LJ1Q35atRLjZbEt81rH5YGr@postini.com; Tue, 07 Jun 2011 14:17:54 PDT Received: by mail-px0-f177.google.com with SMTP id 10so3086735pxi.36 for ; Tue, 07 Jun 2011 14:17:52 -0700 (PDT) Received: by 10.68.2.1 with SMTP id 1mr534068pbq.102.1307481472090; Tue, 07 Jun 2011 14:17:52 -0700 (PDT) Received: from localhost (c-24-19-7-36.hsd1.wa.comcast.net [24.19.7.36]) by mx.google.com with ESMTPS id k9sm394556pbc.54.2011.06.07.14.17.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2011 14:17:51 -0700 (PDT) From: Kevin Hilman To: Janusz Krzysztofik Organization: Texas Instruments, Inc. References: <201106072118.33632.jkrzyszt@tis.icnet.pl> Date: Tue, 07 Jun 2011 14:17:49 -0700 In-Reply-To: <201106072118.33632.jkrzyszt@tis.icnet.pl> (Janusz Krzysztofik's message of "Tue, 7 Jun 2011 21:18:33 +0200") Message-ID: <87pqmpnxxe.fsf@ti.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Received-SPF: pass (localhost is always allowed.) X-Spam-Status: No, hits=-104.247 required=5 tests=AWL, BAYES_00, OSDL_HEADER_SPF_PASS, OSDL_HEADER_SUBJECT_BRACKETED, USER_IN_WHITELIST X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.21 Cc: linux-pm@lists.linux-foundation.org, "linux-omap@vger.kernel.org" Subject: Re: [linux-pm] [RFC] OMAP: McBSP not working if CONFIG_PM_RUNTIME not set X-BeenThere: linux-pm@lists.linux-foundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Linux power management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Tue, 07 Jun 2011 21:20:27 +0000 (UTC) Janusz Krzysztofik writes: > Hi, > > While solving this problem: > http://www.spinics.net/lists/linux-omap/msg52011.html, > I found that since commit e95496d4acadd0b72c4947be61e8d44700fdaae7, > "OMAP: McBSP: Add pm runtime support", McBSP ports, or at least McBSP1 > on my Amstrad Delta, no longer work when CONFIG_PM_RUNTIME is not set. > Even if I don't use such setup and always select CONFIG_PM_RUNTIME, I > think current behaviour is wrong and should be corrected. > > Before I come out with a patch, please advise if and how you think this > should be solved. Should CONFIG_OMAP_MCBSP depend on CONFIG_PM_RUNTIME? > Or should it select CONFIG_PM_RUNTIME? Or maybe an old code which > manipulated clocks directly should be restored for no CONFIG_PM_RUNTIME > case? Or should arch/arm/mach-omap1/pm_bus.c be always built in and > pm_runtime_clk_add_notifier() called from there in order to enable > clocks on device initialization even if CONFIG_PM_RUNTIME is not set? Or > still a better solution? You're on the right track already. Yes, the notifier init should be done even on the !PM_RUNTIME case so that clocks are enabled when the device is added and disabled when the device is removed. Can you try the patch below (only compile tested) If it works, and with your Tested-by, I'll queue this as a fix for v3.0-rc. Thanks, Kevin From 971a6b1ba5cbca7b38fb14ae834b124c6e7bf9b5 Mon Sep 17 00:00:00 2001 From: Kevin Hilman Date: Tue, 7 Jun 2011 14:13:33 -0700 Subject: [PATCH] OMAP1: PM: register notifiers with generic clock ops even when !PM_RUNTIME When runtime PM is disabled, device clocks need to be enabled on device add and disabled on device remove. This currently is not happening because in the !PM_RUNTIME case, no notifiers are registered for OMAP1 devices. Fix this by ensuring notifiers are registered, even in the !PM_RUNTIME case. Reported-by: Janusz Krzysztofik Signed-off-by: Kevin Hilman --- arch/arm/mach-omap1/pm_bus.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c index fe31d93..334fb88 100644 --- a/arch/arm/mach-omap1/pm_bus.c +++ b/arch/arm/mach-omap1/pm_bus.c @@ -56,9 +56,13 @@ static struct dev_power_domain default_power_domain = { USE_PLATFORM_PM_SLEEP_OPS }, }; +#define OMAP1_PWR_DOMAIN (&default_power_domain) +#else +#define OMAP1_PWR_DOMAIN NULL +#endif /* CONFIG_PM_RUNTIME */ static struct pm_clk_notifier_block platform_bus_notifier = { - .pwr_domain = &default_power_domain, + .pwr_domain = OMAP1_PWR_DOMAIN, .con_ids = { "ick", "fck", NULL, }, }; @@ -72,4 +76,4 @@ static int __init omap1_pm_runtime_init(void) return 0; } core_initcall(omap1_pm_runtime_init); -#endif /* CONFIG_PM_RUNTIME */ +