All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: "Arve Hjønnevåg" <arve@android.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-pm@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Ingo Molnar" <mingo@elte.hu>
Subject: Re: [PATCH] PM: suspend_device_irqs(): don't disable wakeup IRQs
Date: Tue, 05 May 2009 17:45:29 -0700	[thread overview]
Message-ID: <873abj3vpy.fsf@deeprootsystems.com> (raw)
In-Reply-To: <878wlb3w18.fsf@deeprootsystems.com> (Kevin Hilman's message of "Tue\, 05 May 2009 17\:38\:43 -0700")

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>>> On Wednesday 06 May 2009, Kevin Hilman wrote:
>>>> 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.
>>>
>>> That depends on whether or not they are used for anything else than wake-up.
>>>
>>>> 
>>>> [...]
>>>> 
>>>> >>>
>>>> >>> 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.
>>>
>>> My understanding of __disable_irq() was that it didn't actually disable the
>>> IRQ at the hardware level, allowing the CPU to actually receive the interrupt
>>> and acknowledge it, but preventing the device driver for receiving it.  
>>
>> Hmm, that's not normally what I think of as disabled.  ;)
>>
>>> Does it work differently on the affected systems?
>>
>> Yes.
>>
>> __disable_irq() calls the irq_chip's disable method which is platform
>> specific.  On OMAP, this masks the IRQ at the hardware level
>> preventing the CPU from seeing the interrupt.
>
> So just as a test, I just removed the 'disable' hook from my platforms
> irq_chip and this allows me to wakeup without using my proposed patch,
> although I'm not sure it is the right behavior either.
>
> The 'struct irq_chip' comments are a bit misleading here as it says
>
>  * @disable:		disable the interrupt (defaults to chip->mask if NULL)
>
> And since my irq_chip->disable was doing basically the same thing as
> my irq_chip->mask, I didn't expect it to change behavior.  But in
> kernel/irq/chip.c, disable gets set to an empty default_disable if the
> irq_chip's version is NULL.
>
> The result is that if irq_chip->disable == NULL, suspend_device_irqs() is a 
> big NOP, albiet one that does lots of locking. :)
>
> So, should the irq_chip code be fixed to match the comment?  Something
> like the patch below?  If I fix the IRQ chip code, then I'm back to
> needing my patch since my irq_chip mask function still masks the IRQ
> at the hardware.

Please ignore my suggested patch.  I just saw Ingo's commit that
modified the default_disable().

Kevin

>
> Kevin
>
>
> commit f9b534f23ac7835eead99fb0a9cec7c505fe1e85
> Author: Kevin Hilman <khilman@deeprootsystems.com>
> Date:   Tue May 5 17:32:59 2009 -0700
>
>     IRQ: chip->disable should default to chip->mask if NULL
>     
>     The struct irq_chip comments in <linux/irq.h> state:
>     
>      * @disable:	disable the interrupt (defaults to chip->mask if NULL)
>     
>     However, the code in kernel/irq/chip.c does otherwise by setting
>     a NULL disable hook to an empty default_disable function.
>     
>     This patch makes the default_disable function call the ->mask hook
>     to match the comments.
>     
>     Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index c687ba4..0fb690a 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -238,6 +238,10 @@ static void default_enable(unsigned int irq)
>   */
>  static void default_disable(unsigned int irq)
>  {
> +	struct irq_desc *desc = irq_to_desc(irq);
> +
> +	desc->chip->mask(irq);
> +	desc->status |= IRQ_MASKED;
>  }
>  
>  /*

  parent reply	other threads:[~2009-05-06  0:45 UTC|newest]

Thread overview: 80+ 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  0:27 ` Kevin Hilman
2009-05-05  6:54 ` Andrew Morton
2009-05-05  6:54 ` Andrew Morton
2009-05-05 14:11   ` Vitaly Wool
2009-05-05 14:11   ` [linux-pm] " Vitaly Wool
2009-05-05 15:56     ` Kevin Hilman
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 20:58     ` Arve Hjønnevåg
2009-05-05 23:15       ` Kevin Hilman
2009-05-05 23:15       ` Kevin Hilman
2009-05-05 23:27         ` Rafael J. Wysocki
2009-05-05 23:27         ` Rafael J. Wysocki
2009-05-05 23:51           ` Arve Hjønnevåg
2009-05-05 23:51           ` Arve Hjønnevåg
2009-05-06  0:13           ` Kevin Hilman
2009-05-06  0:13           ` Kevin Hilman
2009-05-06  0:38             ` Kevin Hilman
2009-05-06  0:45               ` Kevin Hilman
2009-05-06  0:45               ` Kevin Hilman [this message]
2009-05-06  0:38             ` Kevin Hilman
2009-05-06 14:04             ` Kevin Hilman
2009-05-06 21:18               ` Rafael J. Wysocki
2009-05-06 21:18               ` Rafael J. Wysocki
2009-05-07  0:16                 ` Kevin Hilman
2009-05-07  0:16                 ` Kevin Hilman
2009-05-07  1:18                   ` Arve Hjønnevåg
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  2:04                           ` Kim Kyuwon
2009-05-07 14:13                           ` Kevin Hilman
2009-05-07 14:13                           ` Kevin Hilman
2009-05-07 14:13                             ` Kevin Hilman
2009-05-07  2:04                         ` Kim Kyuwon
2009-05-07  1:44                       ` Arve Hjønnevåg
2009-05-07  1:28                     ` Kim Kyuwon
2009-05-07 11:54                   ` Rafael J. Wysocki
2009-05-07 11:54                   ` Rafael J. Wysocki
2009-05-06 14:04             ` Kevin Hilman
2009-05-06  0:20           ` Kim Kyuwon
2009-05-06  0:20           ` Kim Kyuwon
2009-05-22  2:53           ` Kim Kyuwon
2009-05-22  2:53             ` Kim Kyuwon
2009-05-22 16:04             ` Kim Kyuwon
2009-05-22 16:04             ` Kim Kyuwon
2009-05-22 21:25               ` Rafael J. Wysocki
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-23  0:42                     ` Kim Kyuwon
2009-05-22 23:47                   ` Rafael J. Wysocki
2009-05-22 22:32                 ` Kim Kyuwon
2009-05-22 21:23             ` Rafael J. Wysocki
2009-05-22 21:23             ` Rafael J. Wysocki
2009-05-22 22:24               ` Kim Kyuwon
2009-05-22 22:24               ` Kim Kyuwon
2009-05-22 22:29                 ` Rafael J. Wysocki
2009-05-22 22:29                 ` Rafael J. Wysocki
2009-05-22 23:03                   ` Kim Kyuwon
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-29 23:35                           ` Rafael J. Wysocki
2009-05-30  7:34                           ` Kim Kyuwon
2009-05-30  7:40                             ` Kim Kyuwon
2009-05-30  7:40                             ` Kim Kyuwon
2009-05-30 21:00                             ` Rafael J. Wysocki
2009-05-30 21:00                               ` Rafael J. Wysocki
2009-05-30  7:34                           ` Kim Kyuwon
2009-05-25  7:02                       ` Kim Kyuwon
2009-05-23 20:14                     ` Rafael J. Wysocki
2009-05-05 23:57         ` Arve Hjønnevåg
2009-05-05 23:57         ` Arve Hjønnevåg
2009-05-05 15:52   ` 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=873abj3vpy.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 \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=torvalds@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 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.