public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-pm@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PM: suspend_device_irqs(): don't disable wakeup IRQs
Date: Tue, 05 May 2009 16:15:37 -0700	[thread overview]
Message-ID: <87eiv35eg6.fsf@deeprootsystems.com> (raw)
In-Reply-To: <d6200be20905051358m34c2be02ped84ad4158cd9865@mail.gmail.com> ("Arve Hjønnevåg"'s message of "Tue\, 5 May 2009 13\:58\:36 -0700")

Arve Hjønnevåg <arve@android.com> writes:

> On Tue, May 5, 2009 at 8:52 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Mon,  4 May 2009 17:27:04 -0700 Kevin Hilman <khilman@deeprootsystems.com> wrote:
>>>
>>>> Interrupts that are flagged as wakeup sources via set_irq_wake()
>>>> should not be disabled for suspend.
>>>>
>>>
>>> Why not?
>>>
>>
>> If an interrupt is a wakeup source, and it is disabled at the chip
>> level, it will no longer generate interrupts, and thus no longer wake
>> up the system.
>>
>> I'd be interested in hearing why wakeup interrupts should be disabled
>> during suspend.
>>

[...]

>>>
>>> If this fixes some bug then please provide a description of that bug?
>>
>> The bug is that on TI OMAP, interrupts that are used for wakeup events
>> are disabled by this code causing the system to no longer wake up.
>
> What do you do if the interrupt triggers right after your driver has
> returned from its late suspend hook?  

If it's a wakeup IRQ, I assume you want it to prevent suspend.

But I don't see how that can happen in the current code. IIUC, by the
time your late suspend hook is run, your device IRQ is already
disabled, so it won't trigger an interrupt that will be caught by
check_wakeup_irqs() anyways.

> By leaving the interrupt enabled you prevent check_wakeup_irqs from
> aborting suspend.

Yes, but it doesn't prevent platform-specific code from aborting
suspend.  On OMAP, the platform-specific suspend enter hook does a
last check for pending enabled interrupts very late in the sequence.
It seems to me that the platform specific code is the best place to do
this.

On a related note, what happens if your device triggers an interrupt
between check_wakeup_irqs() and the actual suspend?  Since it is a
wakeup IRQ, wouldn't you want it to abort the suspend too?

But all this discussion still leaves the bigger question unanswered:

Without my patch, how do we expect wakeup-enabled device IRQs to:

1) abort a suspend between suspend_device_irqs() and actual HW suspend, and
2) wake up the system *after it is suspended*

Kevin

  reply	other threads:[~2009-05-05 23:15 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-05  0:27 [PATCH] PM: suspend_device_irqs(): don't disable wakeup IRQs Kevin Hilman
2009-05-05  6:54 ` Andrew Morton
2009-05-05 14:11   ` [linux-pm] " Vitaly Wool
2009-05-05 15:56     ` Kevin Hilman
2009-05-05 15:52   ` Kevin Hilman
2009-05-05 20:58     ` Arve Hjønnevåg
2009-05-05 23:15       ` Kevin Hilman [this message]
2009-05-05 23:27         ` Rafael J. Wysocki
2009-05-05 23:51           ` Arve Hjønnevåg
2009-05-06  0:13           ` Kevin Hilman
2009-05-06  0:38             ` Kevin Hilman
2009-05-06  0:45               ` Kevin Hilman
2009-05-06 14:04             ` Kevin Hilman
2009-05-06 21:18               ` Rafael J. Wysocki
2009-05-07  0:16                 ` Kevin Hilman
2009-05-07  1:18                   ` Arve Hjønnevåg
2009-05-07  1:28                     ` Kim Kyuwon
2009-05-07  1:44                       ` Arve Hjønnevåg
2009-05-07  2:04                         ` Kim Kyuwon
2009-05-07 14:13                           ` Kevin Hilman
2009-05-07 11:54                   ` Rafael J. Wysocki
2009-05-06  0:20           ` Kim Kyuwon
2009-05-22  2:53           ` Kim Kyuwon
2009-05-22 16:04             ` Kim Kyuwon
2009-05-22 21:25               ` Rafael J. Wysocki
2009-05-22 22:32                 ` Kim Kyuwon
2009-05-22 23:47                   ` Rafael J. Wysocki
2009-05-23  0:42                     ` Kim Kyuwon
2009-05-22 21:23             ` Rafael J. Wysocki
2009-05-22 22:24               ` Kim Kyuwon
2009-05-22 22:29                 ` Rafael J. Wysocki
2009-05-22 23:03                   ` Kim Kyuwon
2009-05-23 20:14                     ` Rafael J. Wysocki
2009-05-25  7:02                       ` Kim Kyuwon
2009-05-29 23:35                         ` Rafael J. Wysocki
2009-05-30  7:34                           ` Kim Kyuwon
2009-05-30  7:40                             ` Kim Kyuwon
2009-05-30 21:00                             ` Rafael J. Wysocki
2009-05-05 23:57         ` Arve Hjønnevåg

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=87eiv35eg6.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=akpm@linux-foundation.org \
    --cc=arve@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.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