linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dong Aisheng <dongas86@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>,
	Lucas Stach <l.stach@pengutronix.de>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefan Agner <stefan@agner.ch>,
	mingo@redhat.com, "kernel@pengutronix.de" <kernel@pengutronix.de>,
	linux-clk@vger.kernel.org,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled
Date: Thu, 2 Jun 2016 22:59:15 +0800	[thread overview]
Message-ID: <20160602145915.GA31124@shlinux2> (raw)
In-Reply-To: <alpine.DEB.2.11.1604271212290.3941@nanos>

Hi Thomas,

On Wed, Apr 27, 2016 at 12:15:00PM +0200, Thomas Gleixner wrote:
> On Wed, 27 Apr 2016, Dong Aisheng wrote:
> > On Wed, Apr 27, 2016 at 9:58 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> > > On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote:
> > >> Shawn,
> > >> What's your suggestion?
> > >
> > > I think this needs more discussion, and I just dropped Stefan's patch
> > > from my tree.
> > >
> > > We need to firstly understand why this is happening.  The .prepare hook
> > > is defined to be non-atomic context, and so that we call sleep function
> > > in there.  We did everything right.  Why are we getting the warning?  If
> > > I'm correct, this warning only happens on i.MX7D.  Why is that?
> > >
> > 
> > Why Stefan's patch works (checking irqs_disabled()) is because during kernel
> > time init, the irq is still not enabled. It fixes the issue indirectly.
> > See:
> > asmlinkage __visible void __init start_kernel(void)
> > {
> >         /*
> >          * Set up the scheduler prior starting any interrupts (such as the
> >          * timer interrupt). Full topology setup happens at smp_init()
> >          * time - but meanwhile we still have a functioning scheduler.
> >          */
> >         sched_init();
> >         .............
> >         time_init();
> >         ..............
> >         WARN(!irqs_disabled(), "Interrupts were enabled early\n");
> >         early_boot_irqs_disabled = false;
> >         local_irq_enable();
> > }
> > 
> > The issue can only happen when PLL enable causes a schedule during
> > imx_clock_init().
> 
> Calling a function which might sleep _BEFORE_ kernel_init() is wrong. Don't
> try to work around such an issue by doing magic irq_disabled() checks and busy
> loops. Fix the call site and be done with it.
> 

IRQ chip and clocksource are also initialised before kernel_init()
which may call clk APIs like clk_prepare_enable().
We may not be able to guarantee those clocks are unsleepable.

e.g.
For IRQ chip, the arm,gic documents the optional clocks property in
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt.
Although there seems no user currently, not sure there might be
a exception in the future.

For clocksource driver, it's quite common to call clk APIs to
enable and get clock rate which may also cause sleep.
e.g. ARM twd clock in arch/arm/kernel/smp_twd.c.

If we have to avoid the possible sleep caused by these clocks,
we may need to manually check it and change the related clocks
(e.g PLLs) from sleepable to busy loops.
But that is not a good solution and may also not stable when
clock varies.

It looks like not easy to find a generic solution for them.
What's your suggestion?

And Stephen,

Besides above possible sleep, the clk framework itself may also
cause unexpected sleep before kernel_init().
1) clk framework now supports CLK_IS_CRITICAL flag which allows to
enable the clock during register in __clk_core_init(), it usually
can happen in time_init()->of_clk_init();

2) clk framework also support set default configuration like set_parent
and set_rate during register clk providers which also happens in
time_init()->of_clk_init().

Any ideas?
Do you think if we should move them onto a bit later stage after
kernel_init()?

Regards
Dong Aisheng

> Thanks,
> 
> 	tglx
> 
> 

  parent reply	other threads:[~2016-06-02 15:04 UTC|newest]

Thread overview: 39+ 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 ` [PATCH 2/2] clk: imx: return correct frequency for Ethernet PLL 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-30  1:16 ` Stephen Boyd
2016-04-26 17:04   ` Stefan Agner
2016-04-16  1:00 ` Stephen Boyd
2016-04-18  1:58   ` Shawn Guo
2016-04-21  3:45 ` Dong Aisheng
2016-04-26  1:23   ` Shawn Guo
2016-04-26  5:51     ` Dong Aisheng
2016-04-26  9:24       ` Shawn Guo
2016-04-26  9:31       ` Lucas Stach
2016-04-26 11:16         ` Dong Aisheng
2016-04-26 11:27           ` Dong Aisheng
2016-04-27  1:58             ` Shawn Guo
2016-04-27  2:45               ` Dong Aisheng
2016-04-27  2:56                 ` Fabio Estevam
2016-04-27  7:28                   ` Stefan Agner
2016-04-27  8:53                     ` Dong Aisheng
2016-04-27  2:57               ` Dong Aisheng
2016-04-27  7:24                 ` Shawn Guo
2016-04-27  7:26                   ` Stefan Agner
2016-04-27  8:48                   ` Dong Aisheng
2016-04-27  7:34                 ` Stefan Agner
2016-04-27  8:57                   ` Dong Aisheng
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:55                     ` Dong Aisheng
2016-04-29 12:31                       ` Lucas Stach
2016-04-30  2:04                     ` Stefan Agner
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-06-02 14:59                   ` Dong Aisheng [this message]
2016-06-06 13:20                     ` Thomas Gleixner
2016-06-07  7:04                       ` Dong Aisheng
2016-06-09 20:08                         ` Thomas Gleixner
2016-06-09 22:14                           ` Stefan Agner
2016-06-09 22:55                             ` Thomas Gleixner
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=20160602145915.GA31124@shlinux2 \
    --to=dongas86@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@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=shawnguo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).