From patchwork Thu Jun 6 12:16:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 249422 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 8618B2C0099 for ; Thu, 6 Jun 2013 23:43:28 +1000 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UkZ8r-0008MN-7g; Thu, 06 Jun 2013 12:18:09 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UkZ84-0006y9-ME; Thu, 06 Jun 2013 12:17:20 +0000 Received: from metis.ext.pengutronix.de ([2001:6f8:1178:4:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UkZ81-0006xY-55 for linux-arm-kernel@lists.infradead.org; Thu, 06 Jun 2013 12:17:18 +0000 Received: from dude.hi.pengutronix.de ([2001:6f8:1178:2:21e:67ff:fe11:9c5c]) by metis.ext.pengutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1UkZ7Y-00055T-5b; Thu, 06 Jun 2013 14:16:48 +0200 Received: from ukl by dude.hi.pengutronix.de with local (Exim 4.80) (envelope-from ) id 1UkZ7X-0004Rh-AY; Thu, 06 Jun 2013 14:16:47 +0200 Date: Thu, 6 Jun 2013 14:16:47 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Peter Chen Subject: Re: [PATCH 1/1] ARM: imx: clk-pllv3: change wait method for PLL lock Message-ID: <20130606121647.GR23140@pengutronix.de> References: <1370501726-7421-1-git-send-email-peter.chen@freescale.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1370501726-7421-1-git-send-email-peter.chen@freescale.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 2001:6f8:1178:2:21e:67ff:fe11:9c5c X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130606_081717_617674_6D2E9442 X-CRM114-Status: GOOD ( 25.24 ) X-Spam-Score: -2.4 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: shawn.guo@linaro.org, John Stultz , linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org Hello [added jstultz to Cc:] On Thu, Jun 06, 2013 at 02:55:26PM +0800, Peter Chen wrote: > For tickless system, the jiffies may be updated long time (>20ms). ... may not be updated for a long time ... ? > At high loading system, the current waiting method will cause waiting > timeout, and cause a kernel dump at below case. > After timeout = jiffies + msecs_to_jiffies(10), > the timer interrupt occurs, it updates jiffies (eg, + 2 jiffies), > then return back from interrupt, the time between above operations > are tiny, the PLL is still not locked, but the timeout condition is satisfied. Hmm, I admit I didn't follow the tickless stuff, but still I wonder if the analysis is right. I thought on tickless jiffies are updated as before by the boot cpu that cannot run in tickless mode? Anyhow, this only affects the commit log, not the problem. > Signed-off-by: Peter Chen > --- > arch/arm/mach-imx/clk-pllv3.c | 9 ++++++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c > index 36aac94..eefc6c2 100644 > --- a/arch/arm/mach-imx/clk-pllv3.c > +++ b/arch/arm/mach-imx/clk-pllv3.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include "clk.h" > > #define PLL_NUM_OFFSET 0x10 > @@ -50,7 +51,7 @@ struct clk_pllv3 { > static int clk_pllv3_prepare(struct clk_hw *hw) > { > struct clk_pllv3 *pll = to_clk_pllv3(hw); > - unsigned long timeout = jiffies + msecs_to_jiffies(10); > + int count = 100; > u32 val; > > val = readl_relaxed(pll->base); > @@ -62,9 +63,11 @@ static int clk_pllv3_prepare(struct clk_hw *hw) > writel_relaxed(val, pll->base); > > /* Wait for PLL to lock */ > - while (!(readl_relaxed(pll->base) & BM_PLL_LOCK)) > - if (time_after(jiffies, timeout)) > + while (!(readl_relaxed(pll->base) & BM_PLL_LOCK)) { > + udelay(100); > + if (--count == 0) > return -ETIMEDOUT; > + } Maybe it's enough to do timeout = jiffies + msecs_to_jiffies(10); just after the pll is reprogrammed? i.e. Then at least the pll tries to look while the process is interrupted. What is msecs_to_jiffies(10) for you? John, would you expect the problem here that Peter describes? Best regards Uwe diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c index d09bc3d..37f734e 100644 --- a/arch/arm/mach-imx/clk-pllv3.c +++ b/arch/arm/mach-imx/clk-pllv3.c @@ -48,7 +48,7 @@ struct clk_pllv3 { static int clk_pllv3_prepare(struct clk_hw *hw) { struct clk_pllv3 *pll = to_clk_pllv3(hw); - unsigned long timeout = jiffies + msecs_to_jiffies(10); + unsigned long timeout; u32 val; val = readl_relaxed(pll->base); @@ -59,6 +59,8 @@ static int clk_pllv3_prepare(struct clk_hw *hw) val &= ~BM_PLL_POWER; writel_relaxed(val, pll->base); + timeout = jiffies + msecs_to_jiffies(10); + /* Wait for PLL to lock */ while (!(readl_relaxed(pll->base) & BM_PLL_LOCK)) if (time_after(jiffies, timeout))