From: peter.chen@freescale.com (Peter Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] ARM: imx: clk-pllv3: change wait method for PLL lock
Date: Fri, 7 Jun 2013 11:28:46 +0800 [thread overview]
Message-ID: <20130607032845.GB21641@nchen-desktop> (raw)
In-Reply-To: <20130606092156.GL18614@n2100.arm.linux.org.uk>
On Thu, Jun 06, 2013 at 10:21:56AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 06, 2013 at 02:55:26PM +0800, Peter Chen wrote:
> > @@ -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;
> > + }
>
> This is still buggy in the ways you describe above.
>
> do {
> if (readl_relaxed(pll->base) & BM_PLL_LOCK)
> break;
> udelay(100);
> } while (--count);
>
> if (count == 0 && !(readl_relaxed(pll->base) & BM_PLL_LOCK))
> return -ETIMEDOUT;
>
> Notice - we only return -ETIMEDOUT if the condition we're waiting for
> has not been satisfied _after_ the loop terminates, specifically, if
> this happens during the last 100us of our wait.
Thanks for your comments, it can make code be more reasonable.
>
> You can apply the same fix to your original; you don't need to move
> to using udelay() and a counter if you can tolerate some noise in
> the waiting time.
>
> The lesson here is: if you're waiting for any kind of an event, then
> be very careful how you code the failure path so you don't miss a
> success coincident with the timeout condition becoming true.
>
--
Best Regards,
Peter Chen
next prev parent reply other threads:[~2013-06-07 3:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 6:55 [PATCH 1/1] ARM: imx: clk-pllv3: change wait method for PLL lock Peter Chen
2013-06-06 9:21 ` Russell King - ARM Linux
2013-06-07 3:28 ` Peter Chen [this message]
2013-06-06 12:16 ` Uwe Kleine-König
2013-06-07 2:53 ` Peter Chen
2013-06-07 3:33 ` Peter Chen
2013-06-07 7:49 ` Uwe Kleine-König
2013-06-07 16:47 ` John Stultz
2013-06-13 13:32 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130607032845.GB21641@nchen-desktop \
--to=peter.chen@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox