public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kim Kyuwon <q1.kim@samsung.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Kim Kyuwon <chammoru@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-pm@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Kevin Hilman <khilman@deeprootsystems.com>
Subject: Re: [PATCH] PM: suspend_device_irqs(): don't disable wakeup IRQs
Date: Mon, 25 May 2009 16:02:47 +0900	[thread overview]
Message-ID: <4A1A4297.50809@samsung.com> (raw)
In-Reply-To: <200905232214.57186.rjw@sisk.pl>

Rafael J. Wysocki wrote:
> On Saturday 23 May 2009, Kim Kyuwon wrote:
>> On Sat, May 23, 2009 at 7:29 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> On Saturday 23 May 2009, Kim Kyuwon wrote:
> [--snip--]
>>>> You changed the really important part of Linux, which may affect most
>>>> processor architectures. I think you should be careful. If some of
>>>> architectures can't take care of it (they can implement
>>>> disable_irq_wake correctly in H/W level, will you revert your changes?
>>> No, the changes are not going to be reverted.  In fact things should have been
>>> done like this already much earlier.
>>>
>>> Now, do you have any particular example of a problem related to these changes
>>> or is it only a theoretical issue?
>> I'd CCing you when I'm sending a mail for this particular example of a example.
>> http://markmail.org/thread/fvt7d62arofon5xx
> 
> Well, as I said above, reverting the changes that introduced
> [suspend|resume]_device_irqs() is not an option, becuase it was the only sane
> way to achieve the goal they were added for.  So, we need to fix the wake-up
> problem on your platform with the assumption that
> [suspend|resume]_device_irqs() are going to stay.
> 
> For starters, would it be possible to teach the 'disable' hook of your
> platform's interrupt controller not to mask the IRQs that have both
> IRQ_WAKEUP and IRQ_SUSPENDED set?  That apparently would work around the
> wake-up interrupts problem.

Thank you for considering this issue and spending your time. In order to 
make your idea work, we need to add a dummy 'set_wake' hook which 
returns always zero. Anyway, IMO, I think your idea is good to work 
around this problem. But Kevin Hilman(OMAP PM Maintainer) would make 
final decision.

Buy the way, how can you handle the problem that a few interrupt are 
discarded in a small window? I can be sure they are discarded, because I 
have debugged defects which generate in sleep/resume state hundreds of 
times on ARM Processors(PXA310, S3C6410, OMAP3430). Wake-up interrupts 
are generated as soon as arch_suspend_enable_irqs() invoked.

Regards,
Kyuwon

  reply	other threads:[~2009-05-25  7:03 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
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 [this message]
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=4A1A4297.50809@samsung.com \
    --to=q1.kim@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=chammoru@gmail.com \
    --cc=khilman@deeprootsystems.com \
    --cc=kyungmin.park@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox