[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130410125232.GA9243@opensource.wolfsonmicro.com>
Date: Wed, 10 Apr 2013 13:52:32 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: "Liu, Chuansheng" <chuansheng.liu@...el.com>
Cc: "sameo@...ux.intel.com" <sameo@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"patches@...nsource.wolfsonmicro.com"
<patches@...nsource.wolfsonmicro.com>
Subject: Re: mfd, arizona: Fix the deadlock between interrupt handler and
dpm_suspend
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.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists