All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Rui" <rui.zhang@intel.com>
To: "Lu, Aaron" <aaron.lu@intel.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Len Brown <lenb@kernel.org>
Cc: "Huang, Ying" <ying.huang@intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: RE: Discussion on device's runtime wake capability
Date: Tue, 9 Oct 2012 06:39:08 +0000	[thread overview]
Message-ID: <744357E9AAD1214791ACBA4B0B90926322FF88@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <5073C2D0.1080900@intel.com>



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Aaron Lu
> Sent: Tuesday, October 09, 2012 2:23 PM
> To: Rafael J. Wysocki; Len Brown
> Cc: Huang, Ying; Zhang, Rui; linux-acpi@vger.kernel.org
> Subject: Discussion on device's runtime wake capability
> Importance: High
> 
> Hi all,
> 
> We are using _PRW as a hint to see if a device supports wakeup, this is
> fine for device which is able to wake the system in a sleep state, but
> not to wake itself when system is at S0.
> 
> Moreover, when we are to arm the device runtime wake, I think there is
> no need to power on the power resources referenced in _PRW, those power
> resources should be used to give the device ability to wake the system
> from a sleep state, not to wake itself when system is at S0, so
> powering thoses power resources on for run wake is a waste.
> 
Sounds reasonable to me.
To do runtime wake, we only need to power on the resources in _PR0.

> But I may miss something, so it would be very kind of you to point it
> out if things are not like what I've thought, thanks.
> 
> BTW, _S0W seems to be a good hint whether the device supports run wake
> from ACPI's perspective.
>
Agreed.

 
> -Aaron
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09  6:23 Discussion on device's runtime wake capability Aaron Lu
2012-10-09  6:39 ` Zhang, Rui [this message]
2012-10-09 14:44   ` Aaron Lu
2012-10-09 20:51     ` Rafael J. Wysocki
2012-10-09 20:50   ` Rafael J. Wysocki
2012-10-09 20:48 ` Rafael J. Wysocki
2012-10-09 20:57   ` Matthew Garrett
2012-10-10  0:55     ` Aaron Lu
2012-10-10  0:53   ` Aaron Lu
2012-10-10  7:54     ` Aaron Lu
2012-10-10 22:59     ` Rafael J. Wysocki
2012-10-11  0:47       ` Aaron Lu
2012-10-11 17:18         ` Rafael J. Wysocki
2012-10-12 14:15           ` Aaron Lu
2012-10-13 17:13             ` Rafael J. Wysocki

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=744357E9AAD1214791ACBA4B0B90926322FF88@SHSMSX101.ccr.corp.intel.com \
    --to=rui.zhang@intel.com \
    --cc=aaron.lu@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=ying.huang@intel.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.