linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: "Li, Aubrey" <aubrey.li@linux.intel.com>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"sachin.kamat@linaro.org" <sachin.kamat@linaro.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [patch]GPIO button is supposed to wake the system up if the wakeup attribute is set
Date: Wed, 16 Apr 2014 18:05:26 +0530	[thread overview]
Message-ID: <534E790E.2040401@nvidia.com> (raw)
In-Reply-To: <534D5BEA.30906@linux.intel.com>

On Tuesday 15 April 2014 09:48 PM, Li, Aubrey wrote:
> On 2014/4/15 20:38, Laxman Dewangan wrote:
>> On Monday 14 April 2014 09:12 PM, Li, Aubrey wrote:
>>> ping...
>>>
>>> On 2014/4/10 18:48, One Thousand Gnomes wrote:
>>>>
>> I think when we say irq_wake_enable() then based on underlying HW, it
>> should not turn off the irq if it is require for the wakeup. I mean it
>> need to be handle in the hw specific callbacks to keep enabling the
>> wakeup irq on suspend also.
> I failed to see why this can't be generic to all of the GPIO buttons for
> suspend wakeup. Do you see any cases broken by this proposal?

My point here is that if underlying HW needs to have irq enabled for 
wakup then it need to handle in centralized location i.e. the driver 
which is implementing it for the irq callbacks.
Otherwise, we need to change this on multiple places who needs wakeups 
which is vast in nature like sd driver for sdcard insert/remove etc. 
almost all drivers which need wakeups through GPIOs.

>> For me, I have key which is interrupt based from PMIC, not based on GPIO
>> and on that if I set it to IRQF_EARLY_RESUME then it works fine.
>>
> IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
> IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
> resume time.
>
> IRQF_NO_SUSPEND is exactly what I want, instead of IRQF_EARLY_RESUME.
> Can you please send your proposal/code to help me understand why this
> has to hw specific and why IRQF_EARLY_RESUME is better than IRQF_NO_SUSPEND?

IRQF_EARLY_RESUME helps to re-enable mask or irq before parent interrupt 
resume and so parent isr handler sees the irq flag enabled when it try 
to scan source of interrupt. Otherwise parent isr handler treat this as 
spurious interrupt and does not call handler as irq flag disabled for that.

This only happen when on resume, parent inettrupt enabled before the 
child interrupt on irq resume. Because as soon as parent isr re-enabled 
on resume, its hadnler get called before actually child interrupt 
enabled. This is what I observed mainly on PMIC and its sub irq. Not 
observed on SoC level of interrupts.


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

  reply	other threads:[~2014-04-16 12:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10  2:11 [patch]GPIO button is supposed to wake the system up if the wakeup attribute is set Li, Aubrey
2014-04-10 10:48 ` One Thousand Gnomes
2014-04-14 15:42   ` Li, Aubrey
2014-04-15 12:38     ` Laxman Dewangan
2014-04-15 16:18       ` Li, Aubrey
2014-04-16 12:35         ` Laxman Dewangan [this message]
2014-04-17 16:42           ` Li, Aubrey
2014-04-17 17:18             ` Laxman Dewangan
2014-04-17 17:48               ` Li, Aubrey
2014-04-17 23:54             ` Dmitry Torokhov
2014-04-18  5:23               ` Li, Aubrey
2014-04-20 19:39                 ` Dmitry Torokhov
2014-04-21  1:34                   ` Li, Aubrey
2014-04-21 15:55                     ` Dmitry Torokhov
2014-04-21 16:16                       ` Li, Aubrey
2014-04-21 16:26                         ` Dmitry Torokhov

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=534E790E.2040401@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-input@vger.kernel.org \
    --cc=sachin.kamat@linaro.org \
    /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).