All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: balbi@ti.com
Cc: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Tarun Kanti DebBarma <tarun.kanti@ti.com>,
	Kevin Hilman <khilman@ti.com>, Tony Lindgren <tony@atomide.com>,
	Benoit <b-cousson@ti.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	linux-omap@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
	Jon Hunter <jon-hunter@ti.com>
Subject: Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Date: Mon, 10 Sep 2012 16:58:56 +1000	[thread overview]
Message-ID: <20120910165856.715f0702@notabene.brown> (raw)
In-Reply-To: <20120906132604.GM29202@arwen.pp.htv.fi>

[-- Attachment #1: Type: text/plain, Size: 6175 bytes --]

On Thu, 6 Sep 2012 16:26:06 +0300 Felipe Balbi <balbi@ti.com> wrote:

> Hi,
> 
> On Thu, Sep 06, 2012 at 05:02:45PM +1000, NeilBrown wrote:
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > <santosh.shilimkar@ti.com> wrote:
> > 
> > > On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown <neilb@suse.de> wrote:
> > > > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> > > > <santosh.shilimkar@ti.com> wrote:
> > 
> > > >> After thinking bit more on this, the problem seems to be coming
> > > >> mainly because the gpio device is runtime suspended bit early than
> > > >> it should be. Similar issue seen with i2c driver as well. The i2c issue
> > > >> was discussed with Rafael at LPC last week. The idea is to move
> > > >> the pm_runtime_enable/disable() calls entirely up to the
> > > >> _late/_early stage of device suspend/resume.
> > > >> Will update this thread once I have further update.
> > > >
> > > > This won't be late enough.  IRQCHIP_MASK_ON_SUSPEND takes effect after all
> > > > the _late callbacks have been called.
> > > > I, too, spoke to Rafael about this in San Diego.  He seemed to agree with me
> > > > that the interrupt needs to be masked in the ->suspend callback.  any later
> > > > is too late.
> > > >
> > > Thanks for information about your discussion. Will wait for the patch then.
> > > 
> > > Regards
> > > santosh
> > 
> > I already sent a patch - that is what started this thread :-)
> > 
> > I include it below.
> > You said "The patch doesn't seems to be correct" but didn't expand on why.
> > Do you still think it is not correct?  I wouldn't be surprised if there is
> > some case that it doesn't handle quite right, but it seems right to me.
> > 
> > Thanks,
> > NeilBrown
> > 
> > 
> > From: NeilBrown <neilb@suse.de>
> > Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
> > 
> > Current kernel will wake from suspend on an event on any active
> > GPIO even if enable_irq_wake() wasn't called.
> > 
> > There are two reasons that the hardware wake-enable bit should be set:
> > 
> > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> >   in which the wake-enable bit is needed for an interrupt to be
> >   recognised.
> > 2/ while suspended the GPIO interrupt should wake from suspend if and
> >    only if irq_wake as been enabled.
> > 
> > The code currently doesn't keep these two reasons separate so they get
> > confused and sometimes the wakeup flags is set incorrectly.
> > 
> > This patch reverts:
> >  commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> >     gpio/omap: remove suspend/resume callbacks
> > and
> >  commit 0aa2727399c0b78225021413022c164cb99fbc5e
> >     gpio/omap: remove suspend_wakeup field from struct gpio_bank
> > 
> > and makes some minor changes so that we have separate flags for "GPIO
> > should wake from deep idle" and "GPIO should wake from suspend".
> > 
> > With this patch, the GPIO from my touch screen doesn't wake my device
> > any more, which is what I want.
> > 
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Cousson Benoit <b-cousson@ti.com>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Govindraj.R <govindraj.raja@ti.com>
> > 
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > 
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index 4fbc208..fdbad70 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -57,6 +57,7 @@ struct gpio_bank {
> >  	u16 irq;
> >  	int irq_base;
> >  	struct irq_domain *domain;
> > +	u32 suspend_wakeup;
> >  	u32 non_wakeup_gpios;
> >  	u32 enabled_non_wakeup_gpios;
> >  	struct gpio_regs context;
> > @@ -522,11 +523,12 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
> >  
> >  	spin_lock_irqsave(&bank->lock, flags);
> >  	if (enable)
> > -		bank->context.wake_en |= gpio_bit;
> > +		bank->suspend_wakeup |= gpio_bit;
> >  	else
> > -		bank->context.wake_en &= ~gpio_bit;
> > +		bank->suspend_wakeup &= ~gpio_bit;
> >  
> > -	__raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
> > +	if (!bank->loses_context)
> > +		__raw_writel(bank->suspend_wakeup, bank->base + bank->regs->wkup_en);
> >  	spin_unlock_irqrestore(&bank->lock, flags);
> >  
> >  	return 0;
> > @@ -1157,6 +1159,51 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> >  #ifdef CONFIG_ARCH_OMAP2PLUS
> >  
> >  #if defined(CONFIG_PM_RUNTIME)
> > +
> > +#if defined(CONFIG_PM_SLEEP)
> > +static int omap_gpio_suspend(struct device *dev)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct gpio_bank *bank = platform_get_drvdata(pdev);
> > +	void __iomem *base = bank->base;
> > +	unsigned long flags;
> > +
> > +	if (!bank->mod_usage || !bank->loses_context)
> > +		return 0;
> > +
> > +	if (!bank->regs->wkup_en || !bank->context.wake_en)
> > +		return 0;
> > +
> > +	spin_lock_irqsave(&bank->lock, flags);
> 
> shouldn't you be using _noirq methods instead ? Then this would become a
> normal spin_lock()/spin_unlock().
> 

I don't think it is appropriate to move functionality between the different
suspend call-backs just because it seems to make the code easier.  Each
callback has a purpose and we should stick to that purpose.
The 'suspend' callback should transition the device to  a quiescent state,
and I think that includes ensuring that unwanted interrupts won't fire.
'suspend_late' should almost always be the same as runtime_suspend - it
should power-off the device.
'suspend_noirq' ... doesn't seem to have a clear role any more since the
introduction of suspend_late.  Hopefully everything will transition over and
suspend_noirq can disappear.

More pragmatically:  By the time we get to suspend_noirq, I think the  iclk
will have been turned off and so it is too late to try to clear the wkup
flags.

Thanks,
NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-09-10  6:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120825214459.7333a376@notabene.brown>
2012-08-26  4:17 ` [PATCH] OMAP GPIO - don't wake from suspend unless requested Shilimkar, Santosh
2012-08-26 22:53   ` NeilBrown
2012-08-27  1:29     ` Shilimkar, Santosh
2012-09-04  5:59       ` Shilimkar, Santosh
2012-09-06  3:05         ` NeilBrown
2012-09-06  5:48           ` Shilimkar, Santosh
2012-09-06  7:02             ` NeilBrown
2012-09-06  7:27               ` Shilimkar, Santosh
2012-09-06  7:51                 ` NeilBrown
2012-09-06  8:43                   ` Shilimkar, Santosh
2012-09-06 13:26               ` Felipe Balbi
2012-09-10  6:58                 ` NeilBrown [this message]
2012-09-06 14:11               ` Shubhrajyoti
2012-09-07 21:37               ` Kevin Hilman
2012-09-07 21:37                 ` Kevin Hilman
2012-09-08  7:55                 ` Shilimkar, Santosh
2012-09-10 17:57                   ` Kevin Hilman
2012-09-10 17:57                     ` Kevin Hilman
2012-12-14  7:05                     ` NeilBrown
2012-12-14  9:04                       ` anish kumar
2012-12-19 22:20                       ` Grant Likely
2013-02-05 19:47                         ` Kevin Hilman
2013-02-05 19:47                           ` Kevin Hilman
2012-09-10  4:10                 ` NeilBrown
2012-09-10 18:17                   ` Kevin Hilman
2012-09-10 18:17                     ` Kevin Hilman

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=20120910165856.715f0702@notabene.brown \
    --to=neilb@suse.de \
    --cc=b-cousson@ti.com \
    --cc=balbi@ti.com \
    --cc=grant.likely@secretlab.ca \
    --cc=jon-hunter@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=santosh.shilimkar@ti.com \
    --cc=tarun.kanti@ti.com \
    --cc=tony@atomide.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 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.