From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Lin Ming <ming.m.lin@intel.com>, Jeff Garzik <jgarzik@pobox.com>,
Tejun Heo <tj@kernel.org>, Len Brown <lenb@kernel.org>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [RFC PATCH 4/6] PM / Runtime: Introduce flag can_power_off
Date: Tue, 21 Feb 2012 22:43:52 +0100 [thread overview]
Message-ID: <201202212243.52788.rjw@sisk.pl> (raw)
In-Reply-To: <1329786806.1511.54.camel@rui.sh.intel.com>
On Tuesday, February 21, 2012, Zhang Rui wrote:
> On 二, 2012-02-21 at 00:13 +0100, Rafael J. Wysocki wrote:
> > > So how to handle this case, say, for a device in the generic PM domain
> > > that supports 2 different low power state, D1 and D2.
> > > D2 is deeper than D1, and it is kind of cold power off with remote
> > > wakeup disabled. If the driver needs to runtime suspend the device with
> > > remote wakeup enabled, it should set the device to D1, but it can not
> > > set the RPM_SUSPEND?
> >
> > The device is regarded as "suspended" if its bus type's (or PM domain's)
> > .runtime_suspend() callback has been executed and has returned 0 (success).
> > What the callback has actually done is not of any interest to the core.
> >
> right.
>
> > Now, the D1 and D2 case has to be handled by the bus (PM domain) and
> > driver. In both cases the device will be regarded as "suspended" and the
> > core doesn't track the actual device state.
> >
>
>
> > I think the problem here is that the PCI bus type's runtime PM callbacks
> > aren't very sophisticated (they just choose the lowest possible low-power
> > state and attempt to put the device into it) and I can see two possible
> > ways to address that.
> >
> > First, you can modify pci_pm_runtime_suspend/_resume() to handle multiple
> > states (for example, to choose the target low-power state more intelligently
> > than they do right now). Second, you can add a PM domain that will do what
> > you want from pci_pm_runtime_suspend/_resume() for a specific set of devices.
> >
> But RPM_SUSPENDED is set by PM core after .runtime_suspend() being
> invoked, even if device is in D1 instead of D2, right?
>
> So the problem is that, if a device in a generic power domain supports
> two low power state, one is compatible with generic power domain power
> off and another is not, how can the device driver pass this information
> to the generic power domain, i.e. how to runtime suspend a device while
> keep the generic power domain always on?
There are two "low-power" levels in the generic PM domains framework. The
first one is the per-device low-power in which devices are put into their
individual (programmable) low-power states by the domain .dev_ops->stop()
callback. The second one is when .stop() has been called for all devices,
so presumably all of them are in programmable low-power states and it's
possible to switch the entire domain off. This is done by the domain
.power_off() callback.
It seems that the trick might be to make .dev_ops->stop() avoid turning off
power resources for the last suspending device in the domain and leave that
to domain .power_off().
Thanks,
Rafael
next prev parent reply other threads:[~2012-02-21 21:40 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 9:11 [RFC] ACPI D3Cold state and SATA ZPODD support Lin Ming
2012-02-13 9:11 ` [RFC PATCH 1/6] ACPI: Introduce ACPI D3_COLD state support Lin Ming
2012-02-13 20:25 ` Rafael J. Wysocki
2012-02-14 7:07 ` Zhang Rui
2012-02-14 22:29 ` Rafael J. Wysocki
2012-02-16 7:08 ` Zhang Rui
2012-02-17 22:23 ` Rafael J. Wysocki
2012-02-20 5:39 ` Zhang Rui
2012-02-13 9:11 ` [RFC PATCH 2/6] ACPI: Reference devices in ACPI Power Resource Lin Ming
2012-02-13 20:48 ` Rafael J. Wysocki
2012-02-14 7:59 ` Zhang Rui
2012-02-14 22:36 ` Rafael J. Wysocki
2012-02-16 7:18 ` Zhang Rui
2012-02-16 15:13 ` Alan Stern
2012-02-17 1:12 ` Lin Ming
2012-02-17 22:37 ` Rafael J. Wysocki
2012-02-17 7:05 ` Zhang, Rui
2012-02-17 15:07 ` Alan Stern
2012-02-21 14:07 ` Lin Ming
2012-02-21 16:06 ` Alan Stern
2012-02-23 13:41 ` Lin Ming
2012-02-23 18:10 ` Alan Stern
2012-02-17 22:34 ` Rafael J. Wysocki
2012-02-20 5:43 ` Zhang Rui
2012-02-13 9:11 ` [RFC PATCH 3/6] ACPI: Runtime resume all devices covered by a power resource Lin Ming
2012-02-13 9:11 ` [RFC PATCH 4/6] PM / Runtime: Introduce flag can_power_off Lin Ming
2012-02-13 15:01 ` Alan Stern
2012-02-13 19:38 ` Rafael J. Wysocki
2012-02-13 20:41 ` Alan Stern
2012-02-13 20:50 ` Rafael J. Wysocki
2012-02-14 7:11 ` Zhang Rui
2012-02-14 22:38 ` Rafael J. Wysocki
2012-02-14 6:17 ` Zhang Rui
2012-02-14 22:39 ` Rafael J. Wysocki
2012-02-16 7:41 ` Zhang Rui
2012-02-17 23:54 ` Rafael J. Wysocki
2012-02-18 12:54 ` huang ying
2012-02-18 20:35 ` Rafael J. Wysocki
2012-02-20 3:23 ` Zhang Rui
2012-02-20 23:13 ` Rafael J. Wysocki
2012-02-21 1:13 ` Zhang Rui
2012-02-21 21:43 ` Rafael J. Wysocki [this message]
2012-02-22 0:57 ` Zhang Rui
2012-02-14 6:07 ` Zhang Rui
2012-02-13 9:11 ` [RFC PATCH 5/6] PCI: Move acpi_dev_run_wake to acpi core Lin Ming
2012-02-13 20:49 ` Rafael J. Wysocki
2012-02-13 9:11 ` [RFC PATCH 6/6] libata: add ZPODD support Lin Ming
2012-02-15 6:06 ` Aaron Lu
2012-02-15 6:46 ` Lin Ming
2012-02-15 7:18 ` Aaron Lu
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=201202212243.52788.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=jgarzik@pobox.com \
--cc=lenb@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=rui.zhang@intel.com \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.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;
as well as URLs for NNTP newsgroup(s).