From: Shawn Guo <shawnguo@kernel.org>
To: Dong Aisheng <dongas86@gmail.com>
Cc: Stefan Agner <stefan@agner.ch>,
kernel@pengutronix.de, mturquette@baylibre.com,
sboyd@codeaurora.org, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
mingo@redhat.com, tglx@linutronix.de
Subject: Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled
Date: Tue, 26 Apr 2016 09:23:41 +0800 [thread overview]
Message-ID: <20160426012341.GB8870@tiger> (raw)
In-Reply-To: <20160421034520.GA19965@shlinux2.ap.freescale.net>
On Thu, Apr 21, 2016 at 11:45:20AM +0800, Dong Aisheng wrote:
> On Fri, Jan 29, 2016 at 02:49:23PM -0800, Stefan Agner wrote:
> > If a clock gets enabled early during boot time, it can lead to a PLL
> > startup. The wait_lock function makes sure that the PLL is really
> > stareted up before it gets used. However, the function sleeps which
> > leads to scheduling and an error:
> > bad: scheduling from the idle thread!
> > ...
> >
> > Use udelay in case IRQ's are still disabled.
> >
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > ---
> > drivers/clk/imx/clk-pllv3.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> > index c05c43d..b5ff561 100644
> > --- a/drivers/clk/imx/clk-pllv3.c
> > +++ b/drivers/clk/imx/clk-pllv3.c
> > @@ -63,7 +63,10 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
> > break;
> > if (time_after(jiffies, timeout))
> > break;
> > - usleep_range(50, 500);
> > + if (unlikely(irqs_disabled()))
>
> This causes a bit confusion that clk_pllv3_prepare is sleepable.
> But this line indicates it's possible to be called in irq context.
> Although it's only happened during kernel boot phase where irq is
> still not enabled.
> It seems schedule_debug() somehow did not catch it during early boot
> phase. Maybe schedule guys can help explain.
>
> My question is if it's really worthy to introduce this confusion
> to fix the issue since the delay is minor?
I do not understand why it's confusing. The code already obviously
indicates this is a special handling for cases where irq is still not
enabled, rather than for irq context.
The patch is to fix the "bad: scheduling from the idle thread!" warning
rather than minimize the delay. Do you have an opinion on how to fix
the warning?
> Furthermore, shouldn't it be udelay(500)?
500 is for the worst case of sleep, and 50 is good enough for delay.
Shawn
WARNING: multiple messages have this Message-ID (diff)
From: shawnguo@kernel.org (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled
Date: Tue, 26 Apr 2016 09:23:41 +0800 [thread overview]
Message-ID: <20160426012341.GB8870@tiger> (raw)
In-Reply-To: <20160421034520.GA19965@shlinux2.ap.freescale.net>
On Thu, Apr 21, 2016 at 11:45:20AM +0800, Dong Aisheng wrote:
> On Fri, Jan 29, 2016 at 02:49:23PM -0800, Stefan Agner wrote:
> > If a clock gets enabled early during boot time, it can lead to a PLL
> > startup. The wait_lock function makes sure that the PLL is really
> > stareted up before it gets used. However, the function sleeps which
> > leads to scheduling and an error:
> > bad: scheduling from the idle thread!
> > ...
> >
> > Use udelay in case IRQ's are still disabled.
> >
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > ---
> > drivers/clk/imx/clk-pllv3.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> > index c05c43d..b5ff561 100644
> > --- a/drivers/clk/imx/clk-pllv3.c
> > +++ b/drivers/clk/imx/clk-pllv3.c
> > @@ -63,7 +63,10 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
> > break;
> > if (time_after(jiffies, timeout))
> > break;
> > - usleep_range(50, 500);
> > + if (unlikely(irqs_disabled()))
>
> This causes a bit confusion that clk_pllv3_prepare is sleepable.
> But this line indicates it's possible to be called in irq context.
> Although it's only happened during kernel boot phase where irq is
> still not enabled.
> It seems schedule_debug() somehow did not catch it during early boot
> phase. Maybe schedule guys can help explain.
>
> My question is if it's really worthy to introduce this confusion
> to fix the issue since the delay is minor?
I do not understand why it's confusing. The code already obviously
indicates this is a special handling for cases where irq is still not
enabled, rather than for irq context.
The patch is to fix the "bad: scheduling from the idle thread!" warning
rather than minimize the delay. Do you have an opinion on how to fix
the warning?
> Furthermore, shouldn't it be udelay(500)?
500 is for the worst case of sleep, and 50 is good enough for delay.
Shawn
next prev parent reply other threads:[~2016-04-26 1:23 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 22:49 [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled Stefan Agner
2016-01-29 22:49 ` Stefan Agner
2016-01-29 22:49 ` [PATCH 2/2] clk: imx: return correct frequency for Ethernet PLL Stefan Agner
2016-01-29 22:49 ` Stefan Agner
2016-01-29 23:35 ` [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled Joshua Clayton
2016-01-29 23:35 ` Joshua Clayton
2016-01-30 1:16 ` Stephen Boyd
2016-01-30 1:16 ` Stephen Boyd
2016-04-26 17:04 ` Stefan Agner
2016-04-26 17:04 ` Stefan Agner
2016-04-16 1:00 ` Stephen Boyd
2016-04-16 1:00 ` Stephen Boyd
2016-04-18 1:58 ` Shawn Guo
2016-04-18 1:58 ` Shawn Guo
2016-04-21 3:45 ` Dong Aisheng
2016-04-21 3:45 ` Dong Aisheng
2016-04-26 1:23 ` Shawn Guo [this message]
2016-04-26 1:23 ` Shawn Guo
2016-04-26 5:51 ` Dong Aisheng
2016-04-26 5:51 ` Dong Aisheng
2016-04-26 9:24 ` Shawn Guo
2016-04-26 9:24 ` Shawn Guo
2016-04-26 9:31 ` Lucas Stach
2016-04-26 9:31 ` Lucas Stach
2016-04-26 11:16 ` Dong Aisheng
2016-04-26 11:16 ` Dong Aisheng
2016-04-26 11:27 ` Dong Aisheng
2016-04-26 11:27 ` Dong Aisheng
2016-04-27 1:58 ` Shawn Guo
2016-04-27 1:58 ` Shawn Guo
2016-04-27 2:45 ` Dong Aisheng
2016-04-27 2:45 ` Dong Aisheng
2016-04-27 2:56 ` Fabio Estevam
2016-04-27 2:56 ` Fabio Estevam
2016-04-27 7:28 ` Stefan Agner
2016-04-27 7:28 ` Stefan Agner
2016-04-27 8:53 ` Dong Aisheng
2016-04-27 8:53 ` Dong Aisheng
2016-04-27 2:57 ` Dong Aisheng
2016-04-27 2:57 ` Dong Aisheng
2016-04-27 7:24 ` Shawn Guo
2016-04-27 7:24 ` Shawn Guo
2016-04-27 7:26 ` Stefan Agner
2016-04-27 7:26 ` Stefan Agner
2016-04-27 8:48 ` Dong Aisheng
2016-04-27 8:48 ` Dong Aisheng
2016-04-27 7:34 ` Stefan Agner
2016-04-27 7:34 ` Stefan Agner
2016-04-27 8:57 ` Dong Aisheng
2016-04-27 8:57 ` Dong Aisheng
2016-04-27 10:15 ` Thomas Gleixner
2016-04-27 10:15 ` Thomas Gleixner
2016-04-29 9:45 ` [RFC PATCH 1/1] clk: imx7d: move clk setting out of imx7d_clocks_init Dong Aisheng
2016-04-29 9:45 ` Dong Aisheng
2016-04-29 9:55 ` Dong Aisheng
2016-04-29 9:55 ` Dong Aisheng
2016-04-29 12:31 ` Lucas Stach
2016-04-29 12:31 ` Lucas Stach
2016-04-30 2:04 ` Stefan Agner
2016-04-30 2:04 ` Stefan Agner
2016-06-02 15:19 ` Dong Aisheng
2016-06-02 15:19 ` Dong Aisheng
2016-05-25 21:54 ` [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled Stefan Agner
2016-05-25 21:54 ` Stefan Agner
2016-06-02 14:59 ` Dong Aisheng
2016-06-02 14:59 ` Dong Aisheng
2016-06-06 13:20 ` Thomas Gleixner
2016-06-06 13:20 ` Thomas Gleixner
2016-06-07 7:04 ` Dong Aisheng
2016-06-07 7:04 ` Dong Aisheng
2016-06-09 20:08 ` Thomas Gleixner
2016-06-09 20:08 ` Thomas Gleixner
2016-06-09 22:14 ` Stefan Agner
2016-06-09 22:14 ` Stefan Agner
2016-06-09 22:55 ` Thomas Gleixner
2016-06-09 22:55 ` Thomas Gleixner
2016-06-12 12:24 ` Dong Aisheng
2016-06-12 12:24 ` Dong Aisheng
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=20160426012341.GB8870@tiger \
--to=shawnguo@kernel.org \
--cc=dongas86@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
--cc=stefan@agner.ch \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.