[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <27240C0AC20F114CBF8149A2696CBE4AC114FF@SHSMSX101.ccr.corp.intel.com>
Date: Wed, 10 Apr 2013 12:46:55 +0000
From: "Liu, Chuansheng" <chuansheng.liu@...el.com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.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
Hi Mark,
> -----Original Message-----
> From: Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
> Sent: Wednesday, April 10, 2013 8:30 PM
> To: Liu, Chuansheng
> Cc: sameo@...ux.intel.com; linux-kernel@...r.kernel.org;
> patches@...nsource.wolfsonmicro.com
> Subject: Re: mfd, arizona: Fix the deadlock between interrupt handler and
> dpm_suspend
>
> On Wed, Apr 10, 2013 at 08:39:09PM +0800, Chuansheng Liu wrote:
>
> > 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?
> the first place so this probably isn't what we want. Something like the
> below which does a similar thing to what we do on resume might help
> here... needs testing though.
We will take your patch to do the test, thanks.
>
> From 538e817db94dc0c689ecfea7151b1a3f86bb204a Mon Sep 17 00:00:00
> 2001
> From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> Date: Wed, 10 Apr 2013 12:40:26 +0100
> Subject: [PATCH] mfd: arizona: Disable interrupts during suspend
>
> We aren't able to handle interrupts after the device has suspended since
> we need to runtime resume it in order to do so but the controller may not
> be available any more. Handle this in the same way as we handle a similar
> issue on resume.
>
> Reported-by: Chuansheng Liu <chuansheng.liu@...el.com>
> Signed-off-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> ---
> drivers/mfd/arizona-core.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 98023d8..c6be1f6 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -399,6 +399,26 @@ static int arizona_runtime_suspend(struct device
> *dev)
> #endif
>
> #ifdef CONFIG_PM_SLEEP
> +static int arizona_suspend(struct device *dev)
> +{
> + struct arizona *arizona = dev_get_drvdata(dev);
> +
> + dev_dbg(arizona->dev, "Suspend, disabling IRQ\n");
> + disable_irq(arizona->irq);
> +
> + return 0;
> +}
> +
> +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?
and one more question, why the irq is needed to be enabled even after suspended?
> +
> + return 0;
> +}
> +
> static int arizona_resume_noirq(struct device *dev)
> {
> struct arizona *arizona = dev_get_drvdata(dev);
> @@ -424,8 +444,9 @@ const struct dev_pm_ops arizona_pm_ops = {
> SET_RUNTIME_PM_OPS(arizona_runtime_suspend,
> arizona_runtime_resume,
> NULL)
> - SET_SYSTEM_SLEEP_PM_OPS(NULL, arizona_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(arizona_suspend, arizona_resume)
> #ifdef CONFIG_PM_SLEEP
> + .suspend_late = arizona_suspend_late,
> .resume_noirq = arizona_resume_noirq,
> #endif
> };
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists