From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Liu, Chuansheng" <chuansheng.liu@intel.com>
Cc: "sameo@linux.intel.com" <sameo@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>
Subject: Re: mfd, arizona: Fix the deadlock between interrupt handler and dpm_suspend
Date: Wed, 10 Apr 2013 13:52:32 +0100 [thread overview]
Message-ID: <20130410125232.GA9243@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <27240C0AC20F114CBF8149A2696CBE4AC114FF@SHSMSX101.ccr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
On Wed, Apr 10, 2013 at 12:46:55PM +0000, Liu, Chuansheng wrote:
> Hi Mark,
> > > Here the arizona irq is not NOSUSPEND irq, so when doing device suspend,
> > > we can disable the arizona irq, and enable it until devices resuming finished.
> > Hrm, well - actually the primary IRQ probably ought to be a nosuspend in
> Could we set the irq as NOSUSPEND directly?
Worth checking, yes.
> > +static int arizona_suspend_late(struct device *dev)
> > +{
> > + struct arizona *arizona = dev_get_drvdata(dev);
> > +
> > + dev_dbg(arizona->dev, "Late suspend, reenabling IRQ\n");
> > + enable_irq(arizona->irq);
> Here, after later suspending, is it possible the irq coming again?
No, by the time late suspend happens all interrupts ought to be off.
> and one more question, why the irq is needed to be enabled even after suspended?
We want interrupts to function as wake sources and want to minimise the
risk of confusing things - the enable/disable ought to nest with what
the core is doing.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2013-04-10 12:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 12:39 mfd, arizona: Fix the deadlock between interrupt handler and dpm_suspend Chuansheng Liu
2013-04-10 12:30 ` Mark Brown
2013-04-10 12:46 ` Liu, Chuansheng
2013-04-10 12:52 ` Mark Brown [this message]
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=20130410125232.GA9243@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=chuansheng.liu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=sameo@linux.intel.com \
/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