All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Len Brown <lenb@kernel.org>, Huang Ying <ying.huang@intel.com>,
	Zhang Rui <rui.zhang@intel.com>,
	linux-acpi@vger.kernel.org, Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: Discussion on device's runtime wake capability
Date: Wed, 10 Oct 2012 08:53:32 +0800	[thread overview]
Message-ID: <5074C70C.9090704@intel.com> (raw)
In-Reply-To: <9718124.Sj45DoTPo2@vostro.rjw.lan>

On 10/10/2012 04:48 AM, Rafael J. Wysocki wrote:
> On Tuesday 09 of October 2012 14:23:12 Aaron Lu wrote:
>> 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.
> 
> Why not?

Section 7.2.13 of ACPI spec has words like this:
_PRW is only required for devices that have the ability to wake the
system from a system sleeping state.

This is why I don't think _PRW is necessary for run wake as we are still
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,
> 
> Why do you think so?  How can you be sure that those resources are not needed
> to provide wakeup power to the device (or whatever generates the wakeup signal
> on its behalf))?

The same reason as above, the power resources are needed to arm the
device to wake the system from a sleeping state, not S0.

But it's really good to know if there are systems that has a requirement
for _PRW to be on for the device to wake itself up when system is at S0.

> 
>> 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.
> 
> Where did you get this idea from?

Section 7.2.13 of ACPI spec.

> 
>> 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.
> 
> Yes, you do.  For example, _PRW gives us the number of the GPE to use for
> signalling wakeup, right?

Yes, but I think this is a separate story.
The GPE will still be needed, but the power resources may not.

> 
>> BTW, _S0W seems to be a good hint whether the device supports run wake
>> from ACPI's perspective.
> 
> Yes, it is a _hint_.

And I think it is a better hint than _PRW.
I've seen a ACPI table that uses something like this to express the run
wake of the device:
- It has _S0W;
- It has _DSW;
- No _PRW;
- It has a _CRS method to describe an interrupt resource.

And I've tested with a device which is able to both run wake and system
wake. If I do not power those _PRW power resources, there is no problem
for it to generate wake signal when system is at S0, and it even takes
care of the GPE thing in ASL code. But this may be special cases, so I
want to have a discussion on this.

So I hope we can refresh the way we check if the device is able to run
wake. And if possible, we can change the way we do to arm the device for
run wake by not powering those _PRW power resources.

Thanks,
Aaron


  parent reply	other threads:[~2012-10-10  0:53 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
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 [this message]
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=5074C70C.9090704@intel.com \
    --to=aaron.lu@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=rjw@sisk.pl \
    --cc=rui.zhang@intel.com \
    --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.