public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: David Brownell <david-b@pacbell.net>
Cc: Len Brown <len.brown@intel.com>,
	linux acpi <linux-acpi@vger.kernel.org>,
	Russell King <rmk@arm.linux.org.uk>, Pavel Machek <pavel@ucw.cz>,
	pm list <linux-pm@lists.linux-foundation.org>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC][PATCH -mm 2/9] ACPI: Add acpi_pm_device_sleep_state helper routine
Date: Tue, 3 Jul 2007 15:58:49 +0200	[thread overview]
Message-ID: <200707031558.50799.rjw@sisk.pl> (raw)
In-Reply-To: <200707022215.09354.rjw@sisk.pl>

On Monday, 2 July 2007 22:15, Rafael J. Wysocki wrote:
> On Monday, 2 July 2007 19:24, David Brownell wrote:
> > On Monday 02 July 2007, Rafael J. Wysocki wrote:
> > > On Monday, 2 July 2007 07:49, David Brownell wrote:
> > 
> > > > Also, recall that this was originally PCI-specific.  A generalized
> > > > approach would return a range of states, not a single state that
> > > > embeds a particular policy that may not be universally appropriate...
> > > 
> > > Via pointers and the return value equal to 0 on success?
> > 
> > It could as easily be one pointer:  "int minmax[2]".
> > Then min == minmax[0] and max == minmax[1], and the
> > ACPI calls could write the caller's data directly.
> > 
> > But in general, yes -- pointer, not single return value.
> > 
> > 
> > > > The logic was that PCI devices can all support PCI_D0 and PCI_D3.
> > > > For non-PCI devices we can't actually know that.  So "min" should
> > > > probably default to ACPI_STATE_D0.  If this returns a range, then
> > > > such issues can stay out of this code.
> > > 
> > > The ACPI spec says that all devices must support D0 and D3.
> > 
> > ISTR that it actually says they must "recognize" D3.  That's
> > not the same as actually implementing a software controllable
> > power-off state ... and not the same as imposing a "use the
> > biggest numbered D-state" policy at this level.
> 
> No, it literally says "All devices must support the D0 and D3 states" (that
> actually is stated in Appendix A, A.3.4 in the 3.0b specification).
> 
> Still, I think that the question really is what we should return if _SxD or
> _SxW are not present.
> 
> > > > > +	/*
> > > > > +	 * If _PRW says we can wake from the upcoming system state, the _SxD
> > > > > +	 * value can wake ... and we'll assume a wakeup-aware driver.  If _SxW
> > > > > +	 * methods exist (ACPI 3.x), they give the lowest power D-state that
> > > > > +	 * can also wake the system.  _S0W can be valid.
> > > > > +	 */
> > > > > +	if (acpi_target_sleep_state == ACPI_STATE_S0 ||
> > > > > +	    (dev->wakeup.state.enabled &&
> 
> These things are the result of the evaluation of _PRW for that device and
> we need to check them here (or evaluate _PRW ourselves, but that wouldn't make
> sense, since it's already been evaulated), unless the caller tells us not to
> bother (we should provide the caller with a means to do it, though).

I looked at the ACPI spec again and updated the patch (please see below).

Greetings,
Rafael


---
From: Shaohua Li <shaohua.li@intel.com>, Rafael J. Wysocki <rjw@sisk.pl>

Based on the David Brownell's patch at
http://marc.info/?l=linux-acpi&m=117873972806360&w=2

Add a helper routine returning the lowest power (highest number) ACPI device
power state that given device can be in while the system is in the sleep state
indicated by acpi_target_sleep_state .

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep/main.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++
 include/acpi/acpi_bus.h   |    2 +
 2 files changed, 74 insertions(+)

Index: linux-2.6.22-rc7/drivers/acpi/sleep/main.c
===================================================================
--- linux-2.6.22-rc7.orig/drivers/acpi/sleep/main.c	2007-07-02 22:38:34.000000000 +0200
+++ linux-2.6.22-rc7/drivers/acpi/sleep/main.c	2007-07-03 11:57:27.000000000 +0200
@@ -269,6 +269,78 @@ static struct platform_hibernation_ops a
 };
 #endif				/* CONFIG_SOFTWARE_SUSPEND */
 
+/**
+ *	acpi_pm_device_sleep_state - return preferred power state of ACPI device
+ *		in the system sleep state given by %acpi_target_sleep_state
+ *	@dev: device to examine
+ *	@wake: if set, the device should be able to wake up the system
+ *	@d_min_p: used to store the upper limit of allowed states range
+ *	Return value: preferred power state of the device on success, -ENODEV on
+ *		failure (ie. if there's no 'struct acpi_device' for @dev)
+ *
+ *	Find the lowest power (highest number) ACPI device power state that
+ *	device @dev can be in while the system is in the sleep state represented
+ *	by %acpi_target_sleep_state.  If @wake is nonzero, the device should be
+ *	able to wake up the system from this sleep state.  If @d_min_p is set,
+ *	the highest power (lowest number) device power state of @dev allowed
+ *	in this system sleep state is stored at the location pointed to by it.
+ *
+ *	The caller must ensure that @dev is valid before using this function.
+ */
+
+int acpi_pm_device_sleep_state(struct device *dev, int wake, int *d_min_p)
+{
+	acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
+	struct acpi_device *adev;
+	char acpi_method[] = "_SxD";
+	unsigned long d_min, d_max;
+
+	if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+		printk(KERN_ERR "ACPI handle has no context!\n");
+		return -ENODEV;
+	}
+
+	acpi_method[2] = '0' + acpi_target_sleep_state;
+	/*
+	 * If the sleep state is S0, we will return D3, but if the device has
+	 * _S0W, we will use the value from _S0W
+	 */
+	d_min = ACPI_STATE_D0;
+	d_max = ACPI_STATE_D3;
+
+	/*
+	 * If present, _SxD methods return the minimum D-state (highest power
+	 * state) we can use for the corresponding S-states.  Otherwise, the
+	 * minimum D-state is D0 (ACPI 3.x).
+	 *
+	 * NOTE: We rely on acpi_evaluate_integer() not clobbering the integer
+	 * provided -- that's our fault recovery, we ignore retval.
+	 */
+	if (acpi_target_sleep_state > ACPI_STATE_S0)
+		acpi_evaluate_integer(handle, acpi_method, NULL, &d_min);
+
+	/*
+	 * If _PRW says we can wake up the system from the target sleep state,
+	 * the D-state returned by _SxD is sufficient for that (we assume a
+	 * wakeup-aware driver if wake is set).  Still, if _SxW exists
+	 * (ACPI 3.x), it should return the maximum (lowest power) D-state that
+	 * can wake the system.  _S0W may be valid, too.
+	 */
+	if (acpi_target_sleep_state == ACPI_STATE_S0 ||
+	    (wake && adev->wakeup.state.enabled &&
+	     adev->wakeup.sleep_state <= acpi_target_sleep_state)) {
+		acpi_method[3] = 'W';
+		acpi_evaluate_integer(handle, acpi_method, NULL, &d_max);
+		/* Sanity check */
+		if (d_max < d_min)
+			d_min = d_max;
+	}
+
+	if (d_min_p)
+		*d_min_p = d_min;
+	return d_max;
+}
+
 /*
  * Toshiba fails to preserve interrupts over S1, reinitialization
  * of 8259 is needed after S1 resume.
Index: linux-2.6.22-rc7/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.22-rc7.orig/include/acpi/acpi_bus.h	2007-07-02 22:36:30.000000000 +0200
+++ linux-2.6.22-rc7/include/acpi/acpi_bus.h	2007-07-02 23:06:34.000000000 +0200
@@ -364,6 +364,8 @@ acpi_handle acpi_get_child(acpi_handle, 
 acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
 #define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->archdata.acpi_handle))
 
+int acpi_pm_device_sleep_state(struct device *, int, int *);
+
 #endif				/* CONFIG_ACPI */
 
 #endif /*__ACPI_BUS_H__*/

  parent reply	other threads:[~2007-07-03 13:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200706302257.17556.rjw@sisk.pl>
2007-06-30 20:58 ` [RFC][PATCH -mm 1/9] ACPI: Implement the set_target() callback from pm_ops Rafael J. Wysocki
2007-06-30 20:59 ` [RFC][PATCH -mm 2/9] ACPI: Add acpi_pm_device_sleep_state helper routine Rafael J. Wysocki
2007-06-30 21:01 ` [RFC][PATCH -mm 3/9] PM: Move definition of struct pm_ops to suspend.h Rafael J. Wysocki
2007-06-30 21:03 ` [RFC][PATCH -mm 4/9] PM: Rename struct pm_ops and related things Rafael J. Wysocki
2007-06-30 21:07 ` [RFC][PATCH -mm 5/9] PM: Rework struct platform_suspend_ops Rafael J. Wysocki
2007-06-30 21:08 ` [RFC][PATCH -mm 6/9] PM: Fix compilation of suspend code if CONFIG_PM is unset Rafael J. Wysocki
2007-06-30 21:09 ` [RFC][PATCH -mm 7/9] PM: Make suspend_ops static Rafael J. Wysocki
2007-06-30 21:10 ` [RFC][PATCH -mm 8/9] PM: Rework struct hibernation_ops Rafael J. Wysocki
2007-06-30 21:11 ` [RFC][PATCH -mm 9/9] PM: Rename hibernation_ops to platform_hibernation_ops Rafael J. Wysocki
     [not found] ` <200706302301.57528.rjw@sisk.pl>
2007-06-30 23:04   ` [RFC][PATCH -mm 3/9] PM: Move definition of struct pm_ops to suspend.h Pavel Machek
     [not found] ` <200706302303.59457.rjw@sisk.pl>
2007-06-30 23:04   ` [RFC][PATCH -mm 4/9] PM: Rename struct pm_ops and related things Pavel Machek
     [not found] ` <200706302309.58612.rjw@sisk.pl>
2007-06-30 23:06   ` [RFC][PATCH -mm 7/9] PM: Make suspend_ops static Pavel Machek
     [not found] ` <200706302311.59630.rjw@sisk.pl>
2007-06-30 23:06   ` [RFC][PATCH -mm 9/9] PM: Rename hibernation_ops to platform_hibernation_ops Pavel Machek
2007-06-30 23:22 ` [RFC][PATCH -mm 0/9] PM: Update global suspend and hibernation operations framework Russell King
     [not found] ` <20070630232222.GA8100@flint.arm.linux.org.uk>
2007-07-01 10:01   ` Rafael J. Wysocki
2007-07-02  4:28 ` David Brownell
     [not found] ` <200706302259.48700.rjw@sisk.pl>
2007-07-02  5:49   ` [RFC][PATCH -mm 2/9] ACPI: Add acpi_pm_device_sleep_state helper routine David Brownell
     [not found]   ` <200707012249.14143.david-b@pacbell.net>
2007-07-02  8:17     ` Rafael J. Wysocki
     [not found]     ` <200707021017.01295.rjw@sisk.pl>
2007-07-02 17:24       ` David Brownell
     [not found]       ` <200707021024.58693.david-b@pacbell.net>
2007-07-02 20:15         ` Rafael J. Wysocki
     [not found]         ` <200707022215.09354.rjw@sisk.pl>
2007-07-03 13:58           ` Rafael J. Wysocki [this message]
     [not found] ` <200707012128.41742.david-b@pacbell.net>
2007-07-02 14:28   ` [RFC][PATCH -mm 0/9] PM: Update global suspend and hibernation operations framework Rafael J. Wysocki
     [not found]   ` <200707021628.27139.rjw@sisk.pl>
2007-07-02 14:36     ` Russell King
     [not found]     ` <20070702143632.GC32096@flint.arm.linux.org.uk>
2007-07-02 20:17       ` Rafael J. Wysocki
2007-07-11 10:53 ` Pavel Machek
     [not found] ` <20070711105334.GH7091@elf.ucw.cz>
2007-07-11 11:16   ` Rafael J. Wysocki
     [not found]   ` <200707111316.08388.rjw@sisk.pl>
2007-07-11 20:04     ` Russell King

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=200707031558.50799.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=david-b@pacbell.net \
    --cc=johannes@sipsolutions.net \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --cc=rmk@arm.linux.org.uk \
    /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