All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@amd.com>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Lin Ming <ming.m.lin@intel.com>, Len Brown <lenb@kernel.org>,
	"Rafeal J. Wysocki" <rjw@sisk.pl>,
	linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Andiry Xu <andiry.xu@amd.com>,
	Alex He <alex.he@amd.com>
Subject: Re: [PATCH] ACPI: evaluate _PS3 when entering D3 Cold
Date: Sun, 1 Apr 2012 23:34:35 +0800	[thread overview]
Message-ID: <20120401153434.GA3268@localhost.amd.com> (raw)
In-Reply-To: <1333263819.2387.94.camel@rui.sh.intel.com>

Hi,

On Sun, Apr 01, 2012 at 03:03:39PM +0800, Zhang Rui wrote:
> First of all, I agree that we must evaluate _PS3 when setting device to
> either D3_HOT or D3_COLD.
Good.

> 
> And here is my understanding about D3/D3_HOT/D3_COLD,
> 
> if _PR3 exists, it means the devices supports both D3_HOT and D3_COLD.
Agree.

> 
> if only _PS3 exists, we can only say that the state after evaluating
> _PS3 is D3, it could either be D3_HOT or D3_COLD, and this is device
> specific, which in your case, is D3_COLD.
I prefer Rafeal's definition, let's just *assume* the device is at D3
cold after its _PS3 is executed. Unless it has _PR3, in which case, we
have a chance to put the device into D3 hot instead.

> 
> BTW, here is the description of _S0W in ACPI spec,
> If OSPM has not indicated that it supports _PR3 through the OSPM
> Platform-Wide Capabilities (see Section 6.2.10.2), then the value "3"
> corresponds to D3. If it has indicated _PR3 support, the value "3"
> represents D3hot and the value "4" represents D3cold.
> 
> So IMO, the _S0W should return 3 in AMD's implementation as it does not
> have _PR3.
OK, sounds like a firmware bug.
Thanks for identifying this.

> 
> > And the ACPI does have some words like:
> > 
> > ------
> > Platform/drivers must assume that the device will have power completely
> > removed when the device is place into “D3” via _PS3
> > ------
> > 
> I think this means OS can not access device any more after evaluating
> _PS3, and it should re-enumerate the device when transiting back to D0.
> 
> > This is in section 7.2.11: _PR3.
> > 
> > > 
> > > Another problem:
> > > 
> > > With your patch, both D3hot and D3cold will evaluate _PS3, right?
> > > 
> > Yes.
> > 
> > > Will it have problem on AMD platform if you try to put ODD into D3hot
> > > state? _PS3 is evaluated, so it actually enters D3Cold state.
> > 
> > There is no D3 hot support for this device(from the firmware's
> > perspective), either it is at D0(via _PS0), or it will be at D3 cold(via
> > _PS3).
> > 
> I was trying to make a cleanup of the D3/D3_HOT/D3_COLD support in
> Linux, and this gives me some clue.
This is great, and I would like to help as much as I can.

> 
> How about this?
> 
> We should use the term "D3" in general in Linux.
> Without _PR3, OS should *assume* that the power is removed, although it
> may be not true.
> With _PR3, OS can *assure* that the power is removed, because it knows
> how to remove thw power (evaluating _PR3._OFF).
> 
> So the difference is that OS need to make sure whether to evaluate
> _PR3._OFF when _PR3 exists. For example, a device has _PR3, but _S0W
> returns 3, OS should not evaluate _PR3._OFF when the device sleeps with
> remote wakeup support.
> 
> what do you think?
I agree with Rafeal's ideas.

-Aaron

WARNING: multiple messages have this Message-ID (diff)
From: Aaron Lu <aaron.lu@amd.com>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Lin Ming <ming.m.lin@intel.com>, Len Brown <lenb@kernel.org>,
	"Rafeal J. Wysocki" <rjw@sisk.pl>, <linux-acpi@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Andiry Xu <andiry.xu@amd.com>, Alex He <alex.he@amd.com>
Subject: Re: [PATCH] ACPI: evaluate _PS3 when entering D3 Cold
Date: Sun, 1 Apr 2012 23:34:35 +0800	[thread overview]
Message-ID: <20120401153434.GA3268@localhost.amd.com> (raw)
In-Reply-To: <1333263819.2387.94.camel@rui.sh.intel.com>

Hi,

On Sun, Apr 01, 2012 at 03:03:39PM +0800, Zhang Rui wrote:
> First of all, I agree that we must evaluate _PS3 when setting device to
> either D3_HOT or D3_COLD.
Good.

> 
> And here is my understanding about D3/D3_HOT/D3_COLD,
> 
> if _PR3 exists, it means the devices supports both D3_HOT and D3_COLD.
Agree.

> 
> if only _PS3 exists, we can only say that the state after evaluating
> _PS3 is D3, it could either be D3_HOT or D3_COLD, and this is device
> specific, which in your case, is D3_COLD.
I prefer Rafeal's definition, let's just *assume* the device is at D3
cold after its _PS3 is executed. Unless it has _PR3, in which case, we
have a chance to put the device into D3 hot instead.

> 
> BTW, here is the description of _S0W in ACPI spec,
> If OSPM has not indicated that it supports _PR3 through the OSPM
> Platform-Wide Capabilities (see Section 6.2.10.2), then the value "3"
> corresponds to D3. If it has indicated _PR3 support, the value "3"
> represents D3hot and the value "4" represents D3cold.
> 
> So IMO, the _S0W should return 3 in AMD's implementation as it does not
> have _PR3.
OK, sounds like a firmware bug.
Thanks for identifying this.

> 
> > And the ACPI does have some words like:
> > 
> > ------
> > Platform/drivers must assume that the device will have power completely
> > removed when the device is place into “D3” via _PS3
> > ------
> > 
> I think this means OS can not access device any more after evaluating
> _PS3, and it should re-enumerate the device when transiting back to D0.
> 
> > This is in section 7.2.11: _PR3.
> > 
> > > 
> > > Another problem:
> > > 
> > > With your patch, both D3hot and D3cold will evaluate _PS3, right?
> > > 
> > Yes.
> > 
> > > Will it have problem on AMD platform if you try to put ODD into D3hot
> > > state? _PS3 is evaluated, so it actually enters D3Cold state.
> > 
> > There is no D3 hot support for this device(from the firmware's
> > perspective), either it is at D0(via _PS0), or it will be at D3 cold(via
> > _PS3).
> > 
> I was trying to make a cleanup of the D3/D3_HOT/D3_COLD support in
> Linux, and this gives me some clue.
This is great, and I would like to help as much as I can.

> 
> How about this?
> 
> We should use the term "D3" in general in Linux.
> Without _PR3, OS should *assume* that the power is removed, although it
> may be not true.
> With _PR3, OS can *assure* that the power is removed, because it knows
> how to remove thw power (evaluating _PR3._OFF).
> 
> So the difference is that OS need to make sure whether to evaluate
> _PR3._OFF when _PR3 exists. For example, a device has _PR3, but _S0W
> returns 3, OS should not evaluate _PR3._OFF when the device sleeps with
> remote wakeup support.
> 
> what do you think?
I agree with Rafeal's ideas.

-Aaron



  parent reply	other threads:[~2012-04-01 15:34 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-31 18:18 [PATCH] ACPI: evaluate _PS3 when entering D3 Cold Aaron Lu
2012-03-31 18:18 ` Aaron Lu
2012-04-01  5:27 ` Lin Ming
2012-04-01  5:56   ` Aaron Lu
2012-04-01  5:56     ` Aaron Lu
2012-04-01  6:28     ` Lin Ming
2012-04-01  6:28       ` Lin Ming
2012-04-01  7:23       ` Rafael J. Wysocki
2012-04-01  7:23         ` Rafael J. Wysocki
2012-04-01  7:45         ` Zhang Rui
2012-04-01  7:45           ` Zhang Rui
2012-04-01  8:49           ` Rafael J. Wysocki
2012-04-01  8:49             ` Rafael J. Wysocki
2012-04-05  3:20             ` huang ying
2012-04-05  3:20               ` huang ying
2012-04-08 23:41               ` Rafael J. Wysocki
2012-04-08 23:41                 ` Rafael J. Wysocki
2012-04-09  2:24                 ` Huang Ying
2012-04-09 21:24                   ` Rafael J. Wysocki
2012-04-05  2:31         ` Lin Ming
2012-04-05  2:31           ` Lin Ming
2012-04-05  2:56           ` Aaron Lu
2012-04-05  2:56             ` Aaron Lu
2012-04-05  3:01             ` Lin Ming
2012-04-08 23:54               ` Rafael J. Wysocki
2012-04-09  1:38                 ` Lin Ming
2012-04-09 21:25                   ` Rafael J. Wysocki
2012-04-08 23:53             ` Rafael J. Wysocki
2012-04-08 23:47           ` Rafael J. Wysocki
2012-04-08 23:47             ` Rafael J. Wysocki
2012-04-05  2:38         ` Lin Ming
2012-04-05  2:38           ` Lin Ming
2012-04-09  0:02           ` Rafael J. Wysocki
2012-04-09  0:02             ` Rafael J. Wysocki
2012-04-01 14:41       ` Aaron Lu
2012-04-01 14:41         ` Aaron Lu
2012-04-01  7:03     ` Zhang Rui
2012-04-01  7:03       ` Zhang Rui
2012-04-01  7:29       ` Rafael J. Wysocki
2012-04-01 15:34       ` Aaron Lu [this message]
2012-04-01 15:34         ` Aaron Lu
2012-04-01  7:47         ` Rafael J. Wysocki
2012-04-01  7:47           ` Rafael J. Wysocki
2012-04-01  8:01           ` Zhang Rui
2012-04-01  8:55             ` Rafael J. Wysocki
2012-04-01  8:55               ` Rafael J. Wysocki
2012-04-23  1:09 ` Aaron Lu
2012-04-23  1:09   ` Aaron Lu
2012-04-23 11:43   ` Rafael J. Wysocki
2012-04-23 15:13     ` Aaron Lu
2012-04-23 19:50       ` Rafael J. Wysocki
2012-04-24  2:07         ` Aaron Lu
2012-04-24  2:07           ` Aaron Lu
2012-04-24  2:29           ` Lin Ming
2012-04-24  3:10             ` Aaron Lu
2012-04-24  3:10               ` Aaron Lu
2012-04-24 13:15               ` Lin Ming
2012-04-24 14:24                 ` Aaron Lu
2012-04-24 21:15                   ` Rafael J. Wysocki
2012-04-26  8:55                     ` huang ying
2012-04-26 20:04                       ` 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=20120401153434.GA3268@localhost.amd.com \
    --to=aaron.lu@amd.com \
    --cc=alex.he@amd.com \
    --cc=andiry.xu@amd.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=rjw@sisk.pl \
    --cc=rui.zhang@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.