From patchwork Tue Jun 28 00:11:53 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Hilman X-Patchwork-Id: 922792 X-Patchwork-Delegate: paul@pwsan.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5S0G7Ym010059 for ; Tue, 28 Jun 2011 00:16:07 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754534Ab1F1AM4 (ORCPT ); Mon, 27 Jun 2011 20:12:56 -0400 Received: from na3sys009aog116.obsmtp.com ([74.125.149.240]:57416 "EHLO na3sys009aog116.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755002Ab1F1AL7 (ORCPT ); Mon, 27 Jun 2011 20:11:59 -0400 Received: from mail-pv0-f182.google.com ([74.125.83.182]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTgkcTrcwYgXAY6wyYFzx14UiN/qx4LyB@postini.com; Mon, 27 Jun 2011 17:11:59 PDT Received: by mail-pv0-f182.google.com with SMTP id 11so4119618pvg.41 for ; Mon, 27 Jun 2011 17:11:58 -0700 (PDT) Received: by 10.142.135.4 with SMTP id i4mr1231943wfd.34.1309219918406; Mon, 27 Jun 2011 17:11:58 -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 u6sm4666408pbh.80.2011.06.27.17.11.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 17:11:56 -0700 (PDT) From: Kevin Hilman To: Benoit Cousson Cc: , , santosh.shilimkar@ti.com, linux-omap@vger.kernel.org, toddpoynor@google.com Subject: Re: [PATCH v3 8/8] OMAP2+: hwmod: Follow the recommended PRCM module enable sequence Organization: Texas Instruments, Inc. References: <1309191103-8817-1-git-send-email-b-cousson@ti.com> <1309191103-8817-9-git-send-email-b-cousson@ti.com> Date: Mon, 27 Jun 2011 17:11:53 -0700 In-Reply-To: <1309191103-8817-9-git-send-email-b-cousson@ti.com> (Benoit Cousson's message of "Mon, 27 Jun 2011 18:11:43 +0200") Message-ID: <87iprq4xx2.fsf@ti.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.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, 28 Jun 2011 00:16:07 +0000 (UTC) Benoit Cousson writes: > From: Rajendra Nayak > > On OMAP4, the PRCM recommended sequence for enabling > a module after power-on-reset is: > -1- Force clkdm to SW_WKUP > -2- Enabling the clocks > -3- Configure desired module mode to "enable" or "auto" > -4- Wait for the desired module idle status to be FUNC > -5- Program clkdm in HW_AUTO(if supported) > > This sequence applies to all older OMAPs' as well, > however since they use autodeps, it makes sure that > no clkdm is in IDLE, and hence not requiring a force > SW_WKUP when a module is being enabled. > > OMAP4 does not need to support autodeps, because > of the dyanamic dependency feature, wherein > the HW takes care of waking up a clockdomain from > idle and hence the module, whenever an interconnect > access happens to the given module. > > Implementing the sequence for OMAP4 requires > the clockdomain handling that is currently done in > clock framework to be done as part of hwmod framework > since the step -4- above to "Wait for the desired > module idle status to be FUNC" is done as part of > hwmod framework. > > Signed-off-by: Rajendra Nayak > [b-cousson@ti.com: Adapt it to the new clkdm hwmod attribute and API] > Signed-off-by: Benoit Cousson > Cc: Paul Walmsley [...] > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c > index 3eef106..3538805 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.c > +++ b/arch/arm/mach-omap2/omap_hwmod.c > @@ -1360,6 +1360,7 @@ static int _reset(struct omap_hwmod *oh) > static int _enable(struct omap_hwmod *oh) > { > int r; > + int hwsup = 0; > > if (oh->_state != _HWMOD_STATE_INITIALIZED && > oh->_state != _HWMOD_STATE_IDLE && > @@ -1378,6 +1379,19 @@ static int _enable(struct omap_hwmod *oh) > omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED); > > _add_initiator_dep(oh, mpu_oh); > + > + /* > + * A clockdomain must be in SW_SUP before enabling completely the > + * module. The clockdomain can be set in HW_AUTO only when the module > + * become ready. > + */ > + hwsup = clkdm_allows_idle(oh->clkdm); > + r = clkdm_hwmod_enable(oh->clkdm, oh); > + if (r) { > + WARN(1, "omap_hwmod: %s: could not enable clockdomain %s: %d\n", > + oh->name, oh->clkdm->name, r); > + return r; > + } If oh->clkdm == NULL (as it is on OMAP3 since the hwmod data has no clkdms yet), this hangs trying to dereference oh->clkdm->name. Simple fix below, but probably better is to not call any of these functions if oh->clkdm == NULL, otherwise this is very noisy on OMAP3 since that WARN is printed for every hwmod. Is anyone planning to add the clkdms to OMAP3 hwmod data? Kevin --- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 51a13f3..4bcffca 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1391,9 +1391,10 @@ static int _enable(struct omap_hwmod *oh) r = clkdm_hwmod_enable(oh->clkdm, oh); if (r) { WARN(1, "omap_hwmod: %s: could not enable clockdomain %s: %d\n", - oh->name, oh->clkdm->name, r); + oh->name, oh->clkdm ? oh->clkdm->name : "none", r); return r; } + _enable_clocks(oh); _enable_module(oh);