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
next prev parent 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.