[PATCH 0/3] PM / sleep: Make it possible to change the labeling of sleep states

[PATCH 0/3] PM / sleep: Make it possible to change the labeling of sleep states

[Rafael J. Wysocki]

Hi,

In accordance with the changelog of patch [3/3], there are systems where the
only available sleep state is PM_SUSPEND_FREEZE, so neither "mem" nor "standby"
are present in /sys/power/state.  As a result, some user space frameworks are
unable to use suspend on those systems even though the "freeze" sleep state
is there to use.

To address this issue, patch [3/3] adds a command line argument to switch the
behavior so that sleep states are enumerated from the deepest to the shallowest
available and the deepest one is always "mem".  The default is the current
behavior, of course.

Patches [1-2/3] do some preparatory modifications that I think are better done
separately.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH 1/3] PM / sleep: Add state field to pm_states[] entries

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

To allow sleep states corresponding to the "mem", "standby" and
"freeze" lables to be different from the pm_states[] indexes of
those strings, introduce struct pm_sleep_state, consisting of
a string label and a state number, and turn pm_states[] into an
array of objects of that type.

This modification should not lead to any functional changes.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 kernel/power/main.c         |   14 +++++++-------
 kernel/power/power.h        |    7 ++++++-
 kernel/power/suspend.c      |   12 ++++++------
 kernel/power/suspend_test.c |   20 +++++++++-----------
 4 files changed, 28 insertions(+), 25 deletions(-)

Index: linux-pm/kernel/power/power.h
===================================================================
--- linux-pm.orig/kernel/power/power.h
+++ linux-pm/kernel/power/power.h
@@ -178,8 +178,13 @@ extern void swsusp_show_speed(struct tim
 				unsigned int, char *);
 
 #ifdef CONFIG_SUSPEND
+struct pm_sleep_state {
+	const char *label;
+	suspend_state_t state;
+};
+
 /* kernel/power/suspend.c */
-extern const char *const pm_states[];
+extern struct pm_sleep_state pm_states[];
 
 extern bool valid_state(suspend_state_t state);
 extern int suspend_devices_and_enter(suspend_state_t state);
Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -31,10 +31,10 @@
 
 #include "power.h"
 
-const char *const pm_states[PM_SUSPEND_MAX] = {
-	[PM_SUSPEND_FREEZE]	= "freeze",
-	[PM_SUSPEND_STANDBY]	= "standby",
-	[PM_SUSPEND_MEM]	= "mem",
+struct pm_sleep_state pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_FREEZE] = { "freeze", PM_SUSPEND_FREEZE },
+	[PM_SUSPEND_STANDBY] = { "standby", PM_SUSPEND_STANDBY },
+	[PM_SUSPEND_MEM] = { "mem", PM_SUSPEND_MEM },
 };
 
 static const struct platform_suspend_ops *suspend_ops;
@@ -358,7 +358,7 @@ static int enter_state(suspend_state_t s
 	sys_sync();
 	printk("done.\n");
 
-	pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
+	pr_debug("PM: Preparing system for %s sleep\n", pm_states[state].label);
 	error = suspend_prepare(state);
 	if (error)
 		goto Unlock;
@@ -366,7 +366,7 @@ static int enter_state(suspend_state_t s
 	if (suspend_test(TEST_FREEZER))
 		goto Finish;
 
-	pr_debug("PM: Entering %s sleep\n", pm_states[state]);
+	pr_debug("PM: Entering %s sleep\n", pm_states[state].label);
 	pm_restrict_gfp_mask();
 	error = suspend_devices_and_enter(state);
 	pm_restore_gfp_mask();
Index: linux-pm/kernel/power/suspend_test.c
===================================================================
--- linux-pm.orig/kernel/power/suspend_test.c
+++ linux-pm/kernel/power/suspend_test.c
@@ -92,13 +92,13 @@ static void __init test_wakealarm(struct
 	}
 
 	if (state == PM_SUSPEND_MEM) {
-		printk(info_test, pm_states[state]);
+		printk(info_test, pm_states[state].label);
 		status = pm_suspend(state);
 		if (status == -ENODEV)
 			state = PM_SUSPEND_STANDBY;
 	}
 	if (state == PM_SUSPEND_STANDBY) {
-		printk(info_test, pm_states[state]);
+		printk(info_test, pm_states[state].label);
 		status = pm_suspend(state);
 	}
 	if (status < 0)
@@ -140,14 +140,12 @@ static int __init setup_test_suspend(cha
 
 	/* "=mem" ==> "mem" */
 	value++;
-	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (!pm_states[i])
-			continue;
-		if (strcmp(pm_states[i], value) != 0)
-			continue;
-		test_state = (__force suspend_state_t) i;
-		return 0;
-	}
+	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
+		if (!strcmp(pm_states[i].label, value)) {
+			test_state = pm_states[i].state;
+			return 0;
+		}
+
 	printk(warn_bad_state, value);
 	return 0;
 }
@@ -165,7 +163,7 @@ static int __init test_suspend(void)
 	if (test_state == PM_SUSPEND_ON)
 		goto done;
 	if (!valid_state(test_state)) {
-		printk(warn_bad_state, pm_states[test_state]);
+		printk(warn_bad_state, pm_states[test_state].label);
 		goto done;
 	}
 
Index: linux-pm/kernel/power/main.c
===================================================================
--- linux-pm.orig/kernel/power/main.c
+++ linux-pm/kernel/power/main.c
@@ -295,10 +295,10 @@ static ssize_t state_show(struct kobject
 #ifdef CONFIG_SUSPEND
 	int i;
 
-	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (pm_states[i] && valid_state(i))
-			s += sprintf(s,"%s ", pm_states[i]);
-	}
+	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
+		if (valid_state(i))
+			s += sprintf(s,"%s ", pm_states[i].label);
+
 #endif
 #ifdef CONFIG_HIBERNATION
 	s += sprintf(s, "%s\n", "disk");
@@ -314,7 +314,7 @@ static suspend_state_t decode_state(cons
 {
 #ifdef CONFIG_SUSPEND
 	suspend_state_t state = PM_SUSPEND_MIN;
-	const char * const *s;
+	struct pm_sleep_state *s;
 #endif
 	char *p;
 	int len;
@@ -328,7 +328,7 @@ static suspend_state_t decode_state(cons
 
 #ifdef CONFIG_SUSPEND
 	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++)
-		if (*s && len == strlen(*s) && !strncmp(buf, *s, len))
+		if (len == strlen(s->label) && !strncmp(buf, s->label, len))
 			return state;
 #endif
 
@@ -448,7 +448,7 @@ static ssize_t autosleep_show(struct kob
 #ifdef CONFIG_SUSPEND
 	if (state < PM_SUSPEND_MAX)
 		return sprintf(buf, "%s\n", valid_state(state) ?
-						pm_states[state] : "error");
+					pm_states[state].label : "error");
 #endif
 #ifdef CONFIG_HIBERNATION
 	return sprintf(buf, "disk\n");

[PATCH 2/3] PM / sleep: Use valid_state() for platform-dependent sleep states only

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Use the observation that, for platform-dependent sleep states
(PM_SUSPEND_STANDBY, PM_SUSPEND_MEM), a given state is either
always supported or always unsupported and store that information
in pm_states[] instead of calling valid_state() every time we
need to check it.

Also do not use valid_state() for PM_SUSPEND_FREEZE, which is always
valid, and move the pm_test_level validity check for PM_SUSPEND_FREEZE
directly into enter_state().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 kernel/power/main.c         |    9 ++++----
 kernel/power/power.h        |    2 -
 kernel/power/suspend.c      |   46 ++++++++++++++++++++++++--------------------
 kernel/power/suspend_test.c |    2 -
 4 files changed, 32 insertions(+), 27 deletions(-)

Index: linux-pm/kernel/power/main.c
===================================================================
--- linux-pm.orig/kernel/power/main.c
+++ linux-pm/kernel/power/main.c
@@ -296,7 +296,7 @@ static ssize_t state_show(struct kobject
 	int i;
 
 	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
-		if (valid_state(i))
+		if (pm_states[i].state)
 			s += sprintf(s,"%s ", pm_states[i].label);
 
 #endif
@@ -328,8 +328,9 @@ static suspend_state_t decode_state(cons
 
 #ifdef CONFIG_SUSPEND
 	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++)
-		if (len == strlen(s->label) && !strncmp(buf, s->label, len))
-			return state;
+		if (s->state && len == strlen(s->label)
+		    && !strncmp(buf, s->label, len))
+			return s->state;
 #endif
 
 	return PM_SUSPEND_ON;
@@ -447,7 +448,7 @@ static ssize_t autosleep_show(struct kob
 
 #ifdef CONFIG_SUSPEND
 	if (state < PM_SUSPEND_MAX)
-		return sprintf(buf, "%s\n", valid_state(state) ?
+		return sprintf(buf, "%s\n", pm_states[state].state ?
 					pm_states[state].label : "error");
 #endif
 #ifdef CONFIG_HIBERNATION
Index: linux-pm/kernel/power/power.h
===================================================================
--- linux-pm.orig/kernel/power/power.h
+++ linux-pm/kernel/power/power.h
@@ -186,14 +186,12 @@ struct pm_sleep_state {
 /* kernel/power/suspend.c */
 extern struct pm_sleep_state pm_states[];
 
-extern bool valid_state(suspend_state_t state);
 extern int suspend_devices_and_enter(suspend_state_t state);
 #else /* !CONFIG_SUSPEND */
 static inline int suspend_devices_and_enter(suspend_state_t state)
 {
 	return -ENOSYS;
 }
-static inline bool valid_state(suspend_state_t state) { return false; }
 #endif /* !CONFIG_SUSPEND */
 
 #ifdef CONFIG_PM_TEST_SUSPEND
Index: linux-pm/kernel/power/suspend_test.c
===================================================================
--- linux-pm.orig/kernel/power/suspend_test.c
+++ linux-pm/kernel/power/suspend_test.c
@@ -162,7 +162,7 @@ static int __init test_suspend(void)
 	/* PM is initialized by now; is that state testable? */
 	if (test_state == PM_SUSPEND_ON)
 		goto done;
-	if (!valid_state(test_state)) {
+	if (!pm_states[test_state].state) {
 		printk(warn_bad_state, pm_states[test_state].label);
 		goto done;
 	}
Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -88,30 +88,28 @@ void suspend_set_ops(const struct platfo
 }
 EXPORT_SYMBOL_GPL(suspend_set_ops);
 
-bool valid_state(suspend_state_t state)
+static bool valid_state(suspend_state_t state)
 {
-	if (state == PM_SUSPEND_FREEZE) {
-#ifdef CONFIG_PM_DEBUG
-		if (pm_test_level != TEST_NONE &&
-		    pm_test_level != TEST_FREEZER &&
-		    pm_test_level != TEST_DEVICES &&
-		    pm_test_level != TEST_PLATFORM) {
-			printk(KERN_WARNING "Unsupported pm_test mode for "
-					"freeze state, please choose "
-					"none/freezer/devices/platform.\n");
-			return false;
-		}
-#endif
-			return true;
-	}
 	/*
-	 * PM_SUSPEND_STANDBY and PM_SUSPEND_MEMORY states need lowlevel
-	 * support and need to be valid to the lowlevel
+	 * PM_SUSPEND_STANDBY and PM_SUSPEND_MEM states need low level
+	 * support and need to be valid to the low level
 	 * implementation, no valid callback implies that none are valid.
 	 */
 	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
 }
 
+static int __init pm_suspend_states_init(void)
+{
+	suspend_state_t i;
+
+	for (i = PM_SUSPEND_STANDBY; i <= PM_SUSPEND_MEM; i++)
+		if (!valid_state(i))
+			pm_states[i].state = 0;
+
+	return 0;
+}
+fs_initcall(pm_suspend_states_init);
+
 /**
  * suspend_valid_only_mem - Generic memory-only valid callback.
  *
@@ -345,9 +343,17 @@ static int enter_state(suspend_state_t s
 {
 	int error;
 
-	if (!valid_state(state))
-		return -ENODEV;
-
+	if (state == PM_SUSPEND_FREEZE) {
+#ifdef CONFIG_PM_DEBUG
+		if (pm_test_level != TEST_NONE && pm_test_level <= TEST_CPUS) {
+			pr_warning("PM: Unsupported test mode for freeze state,"
+				   "please choose none/freezer/devices/platform.\n");
+			return -EAGAIN;
+		}
+#endif
+	} else if (!valid_state(state)) {
+		return -EINVAL;
+	}
 	if (!mutex_trylock(&pm_mutex))
 		return -EBUSY;
 

[PATCH 3/3] PM / sleep: Introduce command line argument for sleep states enumeration

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

On some systems the platform doesn't support neither
PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
only available system sleep state.  However, some user space frameworks
only use the "mem" and (sometimes) "standby" sleep state labels, so
the users of those systems need to modify user space in order to be
able to use system suspend at all and that is not always possible.

For this reason, add a new kernel command line argument,
relative_sleep_states, allowing the users of those systems to change
the way in which the kernel assigns labels to system sleep states.
Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze"
labels will enumerate the available system sleem states from the
deepest to the shallowest, respectively, so that "mem" is always
present in /sys/power/state and the other state strings may or may
not be presend depending on what is supported by the platform.

Update system sleep states documentation to reflect this change.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 Documentation/ABI/testing/sysfs-power |   29 +++++++----
 Documentation/kernel-parameters.txt   |    7 ++
 Documentation/power/states.txt        |   89 +++++++++++++++++++++-------------
 kernel/power/main.c                   |   12 ++--
 kernel/power/suspend.c                |   34 ++++++++++--
 5 files changed, 118 insertions(+), 53 deletions(-)

Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -32,9 +32,9 @@
 #include "power.h"
 
 struct pm_sleep_state pm_states[PM_SUSPEND_MAX] = {
-	[PM_SUSPEND_FREEZE] = { "freeze", PM_SUSPEND_FREEZE },
-	[PM_SUSPEND_STANDBY] = { "standby", PM_SUSPEND_STANDBY },
-	[PM_SUSPEND_MEM] = { "mem", PM_SUSPEND_MEM },
+	[PM_SUSPEND_FREEZE] = { .label = "freeze", },
+	[PM_SUSPEND_STANDBY] = { .label = "standby", },
+	[PM_SUSPEND_MEM] = { .label = "mem", },
 };
 
 static const struct platform_suspend_ops *suspend_ops;
@@ -98,18 +98,40 @@ static bool valid_state(suspend_state_t
 	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
 }
 
+/*
+ * If this is set, the "mem" label always corresponds to the deepest sleep state
+ * available, the "standby" label corresponds to the second deepest sleep state
+ * available (if any), and the "freeze" label corresponds to the remaining
+ * available sleep state (if there is one).
+ */
+static bool relative_states;
+
 static int __init pm_suspend_states_init(void)
 {
 	suspend_state_t i;
+	int j = PM_SUSPEND_MAX - 1;
 
-	for (i = PM_SUSPEND_STANDBY; i <= PM_SUSPEND_MEM; i++)
-		if (!valid_state(i))
-			pm_states[i].state = 0;
+	for (i = PM_SUSPEND_MEM; i >= PM_SUSPEND_STANDBY; i--)
+		if (valid_state(i)) {
+			pm_states[j].state = i;
+			j--;
+		} else if (!relative_states) {
+			j--;
+		}
 
+	pm_states[j].state = PM_SUSPEND_FREEZE;
 	return 0;
 }
 fs_initcall(pm_suspend_states_init);
 
+static int __init sleep_states_setup(char *str)
+{
+	relative_states = !strncmp(str, "1", 1);
+	return 1;
+}
+
+__setup("relative_sleep_states=", sleep_states_setup);
+
 /**
  * suspend_valid_only_mem - Generic memory-only valid callback.
  *
Index: linux-pm/Documentation/kernel-parameters.txt
===================================================================
--- linux-pm.orig/Documentation/kernel-parameters.txt
+++ linux-pm/Documentation/kernel-parameters.txt
@@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes
 			[KNL, SMP] Set scheduler's default relax_domain_level.
 			See Documentation/cgroups/cpusets.txt.
 
+	relative_sleep_states=
+			[SUSPEND] Use sleep state labeling where the deepest
+			state available other than hibernation is always "mem".
+			Format: { "0" | "1" }
+			0 -- Traditional sleep state labels.
+			1 -- Relative sleep state labels.
+
 	reserve=	[KNL,BUGS] Force the kernel to ignore some iomem area
 
 	reservetop=	[X86-32]
Index: linux-pm/kernel/power/main.c
===================================================================
--- linux-pm.orig/kernel/power/main.c
+++ linux-pm/kernel/power/main.c
@@ -279,14 +279,14 @@ static inline void pm_print_times_init(v
 struct kobject *power_kobj;
 
 /**
- *	state - control system power state.
+ * state - control system sleep states.
  *
- *	show() returns what states are supported, which is hard-coded to
- *	'freeze' (Low-Power Idle), 'standby' (Power-On Suspend),
- *	'mem' (Suspend-to-RAM), and 'disk' (Suspend-to-Disk).
+ * show() returns available sleep state labels, which may be "mem", "standby",
+ * "freeze" and "disk" (hibernation).  See Documentation/power/states.txt for a
+ * description of what they mean.
  *
- *	store() accepts one of those strings, translates it into the
- *	proper enumerated value, and initiates a suspend transition.
+ * store() accepts one of those strings, translates it into the proper
+ * enumerated value, and initiates a suspend transition.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
Index: linux-pm/Documentation/ABI/testing/sysfs-power
===================================================================
--- linux-pm.orig/Documentation/ABI/testing/sysfs-power
+++ linux-pm/Documentation/ABI/testing/sysfs-power
@@ -7,19 +7,30 @@ Description:
 		subsystem.
 
 What:		/sys/power/state
-Date:		August 2006
+Date:		May 2014
 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
-		The /sys/power/state file controls the system power state.
-		Reading from this file returns what states are supported,
-		which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
-		(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
-		(Suspend-to-Disk).
+		The /sys/power/state file controls system sleep states.
+		Reading from this file returns the available sleep state
+		labels, which may be "mem", "standby", "freeze" and "disk"
+		(hibernation).  The meanings of the first three labels depend on
+		the relative_sleep_states command line argument as follows:
+		 1) relative_sleep_states = 1
+		    "mem", "standby", "freeze" represent non-hibernation sleep
+		    states from the deepest ("mem", always present) to the
+		    shallowest ("freeze").  "standby" and "freeze" may or may
+		    not be present depending on the capabilities of the
+		    platform.  "freeze" can only be present if "standby" is
+		    present.
+		 2) relative_sleep_states = 0 (default)
+		    "mem" - "suspend-to-RAM", present if supported.
+		    "standby" - "power-on suspend", present if supported.
+		    "freeze" - "suspend-to-idle", always present.
 
 		Writing to this file one of these strings causes the system to
-		transition into that state. Please see the file
-		Documentation/power/states.txt for a description of each of
-		these states.
+		transition into the corresponding state, if available.  See
+		Documentation/power/states.txt for a description of what
+		"suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean.
 
 What:		/sys/power/disk
 Date:		September 2006
Index: linux-pm/Documentation/power/states.txt
===================================================================
--- linux-pm.orig/Documentation/power/states.txt
+++ linux-pm/Documentation/power/states.txt
@@ -1,62 +1,87 @@
+System Power Management Sleep States
 
-System Power Management States
+(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
+The kernel supports up to four system sleep states generically, although three
+of them depend on the platform support code to implement the low-level details
+for each state.
+
+The states are represented by strings that can be read or written to the
+/sys/power/state file.  Those strings may be "mem", "standby", "freeze" and
+"disk", where the last one always represents hibernation (Suspend-To-Disk) and
+the meaning of the remaining ones depends on the relative_sleep_states command
+line argument.
+
+For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the
+available non-hibernation sleep states from the deepest to the shallowest,
+respectively.  In that case, "mem" is always present in /sys/power/state,
+because there is at least one non-hibernation sleep state in every system.  If
+the given system supports two non-hibernation sleep states, "standby" is present
+in /sys/power/state in addition to "mem".  If the system supports three
+non-hibernation sleep states, "freeze" will be present in /sys/power/state in
+addition to "mem" and "standby".
 
-The kernel supports four power management states generically, though
-one is generic and the other three are dependent on platform support
-code to implement the low-level details for each state.
-This file describes each state, what they are
-commonly called, what ACPI state they map to, and what string to write
-to /sys/power/state to enter that state
+For relative_sleep_states=0, which is the default, the following descriptions
+apply.
 
-state:		Freeze / Low-Power Idle
+state:		Suspend-To-Idle
 ACPI state:	S0
-String:		"freeze"
+Label:		"freeze"
 
-This state is a generic, pure software, light-weight, low-power state.
-It allows more energy to be saved relative to idle by freezing user
+This state is a generic, pure software, light-weight, system sleep state.
+It allows more energy to be saved relative to runtime idle by freezing user
 space and putting all I/O devices into low-power states (possibly
 lower-power than available at run time), such that the processors can
 spend more time in their idle states.
-This state can be used for platforms without Standby/Suspend-to-RAM
+
+This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
 support, or it can be used in addition to Suspend-to-RAM (memory sleep)
-to provide reduced resume latency.
+to provide reduced resume latency.  It is always supported.
 
 
 State:		Standby / Power-On Suspend
 ACPI State:	S1
-String:		"standby"
+Label:		"standby"
 
-This state offers minimal, though real, power savings, while providing
-a very low-latency transition back to a working system. No operating
-state is lost (the CPU retains power), so the system easily starts up
+This state, if supported, offers moderate, though real, power savings, while
+providing a relatively low-latency transition back to a working system.  No
+operating state is lost (the CPU retains power), so the system easily starts up
 again where it left off. 
 
-We try to put devices in a low-power state equivalent to D1, which
-also offers low power savings, but low resume latency. Not all devices
-support D1, and those that don't are left on. 
+In addition to freezing user space and putting all I/O devices into low-power
+states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline
+and all low-level system functions are suspended during transitions into this
+state.  For this reason, it should allow more energy to be saved relative to
+Suspend-To-Idle, but the resume latency will generally be greater than for that
+state.
 
 
 State:		Suspend-to-RAM
 ACPI State:	S3
-String:		"mem"
+Label:		"mem"
 
-This state offers significant power savings as everything in the
-system is put into a low-power state, except for memory, which is
-placed in self-refresh mode to retain its contents. 
-
-System and device state is saved and kept in memory. All devices are
-suspended and put into D3. In many cases, all peripheral buses lose
-power when entering STR, so devices must be able to handle the
-transition back to the On state. 
+This state, if supported, offers significant power savings as everything in the
+system is put into a low-power state, except for memory, which should be placed
+into the self-refresh mode to retain its contents.  All of the steps carried out
+when entering Power-On Suspend are also carried out during transitions to STR.
+Additional operations may take place depending on the platform capabilities.  In
+particular, on ACPI systems the kernel passes control to the BIOS (platform
+firmware) as the last step during STR transitions and that usually results in
+powering down some more low-level components that aren't directly controlled by
+the kernel.
+
+System and device state is saved and kept in memory.  All devices are suspended
+and put into low-power states.  In many cases, all peripheral buses lose power
+when entering STR, so devices must be able to handle the transition back to the
+"on" state.
 
-For at least ACPI, STR requires some minimal boot-strapping code to
-resume the system from STR. This may be true on other platforms. 
+For at least ACPI, STR requires some minimal boot-strapping code to resume the
+system from it.  This may be the case on other platforms too.
 
 
 State:		Suspend-to-disk
 ACPI State:	S4
-String:		"disk"
+Label:		"disk"
 
 This state offers the greatest power savings, and can be used even in
 the absence of low-level platform support for power management. This

[PATCH 2/3][update] PM / sleep: Use valid_state() for platform-dependent sleep states only

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Use the observation that, for platform-dependent sleep states
(PM_SUSPEND_STANDBY, PM_SUSPEND_MEM), a given state is either
always supported or always unsupported and store that information
in pm_states[] instead of calling valid_state() every time we
need to check it.

Also do not use valid_state() for PM_SUSPEND_FREEZE, which is always
valid, and move the pm_test_level validity check for PM_SUSPEND_FREEZE
directly into enter_state().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

In the meantime I realized that whether or not the given sleep state is
supported only changes when the new suspend ops are set, so instead of
adding a new fs_initcall, it is better to populate pm_states[i].state
in suspend_set_ops().

Thanks!

---
 kernel/power/main.c         |    9 +++---
 kernel/power/power.h        |    2 -
 kernel/power/suspend.c      |   60 ++++++++++++++++++++++----------------------
 kernel/power/suspend_test.c |    2 -
 4 files changed, 36 insertions(+), 37 deletions(-)

Index: linux-pm/kernel/power/main.c
===================================================================
--- linux-pm.orig/kernel/power/main.c
+++ linux-pm/kernel/power/main.c
@@ -296,7 +296,7 @@ static ssize_t state_show(struct kobject
 	int i;
 
 	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
-		if (valid_state(i))
+		if (pm_states[i].state)
 			s += sprintf(s,"%s ", pm_states[i].label);
 
 #endif
@@ -328,8 +328,9 @@ static suspend_state_t decode_state(cons
 
 #ifdef CONFIG_SUSPEND
 	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++)
-		if (len == strlen(s->label) && !strncmp(buf, s->label, len))
-			return state;
+		if (s->state && len == strlen(s->label)
+		    && !strncmp(buf, s->label, len))
+			return s->state;
 #endif
 
 	return PM_SUSPEND_ON;
@@ -447,7 +448,7 @@ static ssize_t autosleep_show(struct kob
 
 #ifdef CONFIG_SUSPEND
 	if (state < PM_SUSPEND_MAX)
-		return sprintf(buf, "%s\n", valid_state(state) ?
+		return sprintf(buf, "%s\n", pm_states[state].state ?
 					pm_states[state].label : "error");
 #endif
 #ifdef CONFIG_HIBERNATION
Index: linux-pm/kernel/power/power.h
===================================================================
--- linux-pm.orig/kernel/power/power.h
+++ linux-pm/kernel/power/power.h
@@ -186,14 +186,12 @@ struct pm_sleep_state {
 /* kernel/power/suspend.c */
 extern struct pm_sleep_state pm_states[];
 
-extern bool valid_state(suspend_state_t state);
 extern int suspend_devices_and_enter(suspend_state_t state);
 #else /* !CONFIG_SUSPEND */
 static inline int suspend_devices_and_enter(suspend_state_t state)
 {
 	return -ENOSYS;
 }
-static inline bool valid_state(suspend_state_t state) { return false; }
 #endif /* !CONFIG_SUSPEND */
 
 #ifdef CONFIG_PM_TEST_SUSPEND
Index: linux-pm/kernel/power/suspend_test.c
===================================================================
--- linux-pm.orig/kernel/power/suspend_test.c
+++ linux-pm/kernel/power/suspend_test.c
@@ -162,7 +162,7 @@ static int __init test_suspend(void)
 	/* PM is initialized by now; is that state testable? */
 	if (test_state == PM_SUSPEND_ON)
 		goto done;
-	if (!valid_state(test_state)) {
+	if (!pm_states[test_state].state) {
 		printk(warn_bad_state, pm_states[test_state].label);
 		goto done;
 	}
Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -32,9 +32,9 @@
 #include "power.h"
 
 struct pm_sleep_state pm_states[PM_SUSPEND_MAX] = {
-	[PM_SUSPEND_FREEZE] = { "freeze", PM_SUSPEND_FREEZE },
-	[PM_SUSPEND_STANDBY] = { "standby", PM_SUSPEND_STANDBY },
-	[PM_SUSPEND_MEM] = { "mem", PM_SUSPEND_MEM },
+	[PM_SUSPEND_FREEZE] = { .label = "freeze", .state = PM_SUSPEND_FREEZE },
+	[PM_SUSPEND_STANDBY] = { .label = "standby", },
+	[PM_SUSPEND_MEM] = { .label = "mem", },
 };
 
 static const struct platform_suspend_ops *suspend_ops;
@@ -76,42 +76,34 @@ void freeze_wake(void)
 }
 EXPORT_SYMBOL_GPL(freeze_wake);
 
+static bool valid_state(suspend_state_t state)
+{
+	/*
+	 * PM_SUSPEND_STANDBY and PM_SUSPEND_MEM states need low level
+	 * support and need to be valid to the low level
+	 * implementation, no valid callback implies that none are valid.
+	 */
+	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
+}
+
 /**
  * suspend_set_ops - Set the global suspend method table.
  * @ops: Suspend operations to use.
  */
 void suspend_set_ops(const struct platform_suspend_ops *ops)
 {
+	suspend_state_t i;
+
 	lock_system_sleep();
+
 	suspend_ops = ops;
+	for (i = PM_SUSPEND_STANDBY; i <= PM_SUSPEND_MEM; i++)
+		pm_states[i].state = valid_state(i) ? i : 0;
+
 	unlock_system_sleep();
 }
 EXPORT_SYMBOL_GPL(suspend_set_ops);
 
-bool valid_state(suspend_state_t state)
-{
-	if (state == PM_SUSPEND_FREEZE) {
-#ifdef CONFIG_PM_DEBUG
-		if (pm_test_level != TEST_NONE &&
-		    pm_test_level != TEST_FREEZER &&
-		    pm_test_level != TEST_DEVICES &&
-		    pm_test_level != TEST_PLATFORM) {
-			printk(KERN_WARNING "Unsupported pm_test mode for "
-					"freeze state, please choose "
-					"none/freezer/devices/platform.\n");
-			return false;
-		}
-#endif
-			return true;
-	}
-	/*
-	 * PM_SUSPEND_STANDBY and PM_SUSPEND_MEMORY states need lowlevel
-	 * support and need to be valid to the lowlevel
-	 * implementation, no valid callback implies that none are valid.
-	 */
-	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
-}
-
 /**
  * suspend_valid_only_mem - Generic memory-only valid callback.
  *
@@ -345,9 +337,17 @@ static int enter_state(suspend_state_t s
 {
 	int error;
 
-	if (!valid_state(state))
-		return -ENODEV;
-
+	if (state == PM_SUSPEND_FREEZE) {
+#ifdef CONFIG_PM_DEBUG
+		if (pm_test_level != TEST_NONE && pm_test_level <= TEST_CPUS) {
+			pr_warning("PM: Unsupported test mode for freeze state,"
+				   "please choose none/freezer/devices/platform.\n");
+			return -EAGAIN;
+		}
+#endif
+	} else if (!valid_state(state)) {
+		return -EINVAL;
+	}
 	if (!mutex_trylock(&pm_mutex))
 		return -EBUSY;
 

[PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

On some systems the platform doesn't support neither
PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
only available system sleep state.  However, some user space frameworks
only use the "mem" and (sometimes) "standby" sleep state labels, so
the users of those systems need to modify user space in order to be
able to use system suspend at all and that is not always possible.

For this reason, add a new kernel command line argument,
relative_sleep_states, allowing the users of those systems to change
the way in which the kernel assigns labels to system sleep states.
Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze"
labels will enumerate the available system sleem states from the
deepest to the shallowest, respectively, so that "mem" is always
present in /sys/power/state and the other state strings may or may
not be presend depending on what is supported by the platform.

Update system sleep states documentation to reflect this change.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

This update is needed after patch [2/3] has been updated.

Thanks!

---
 Documentation/ABI/testing/sysfs-power |   29 +++++++----
 Documentation/kernel-parameters.txt   |    7 ++
 Documentation/power/states.txt        |   89 +++++++++++++++++++++-------------
 kernel/power/main.c                   |   12 ++--
 kernel/power/suspend.c                |   33 +++++++++++-
 5 files changed, 120 insertions(+), 50 deletions(-)

Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -86,19 +86,46 @@ static bool valid_state(suspend_state_t
 	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
 }
 
+/*
+ * If this is set, the "mem" label always corresponds to the deepest sleep state
+ * available, the "standby" label corresponds to the second deepest sleep state
+ * available (if any), and the "freeze" label corresponds to the remaining
+ * available sleep state (if there is one).
+ */
+static bool relative_states;
+
+static int __init sleep_states_setup(char *str)
+{
+	relative_states = !strncmp(str, "1", 1);
+	if (relative_states) {
+		pm_states[PM_SUSPEND_MEM].state = PM_SUSPEND_FREEZE;
+		pm_states[PM_SUSPEND_FREEZE].state = 0;
+	}
+	return 1;
+}
+
+__setup("relative_sleep_states=", sleep_states_setup);
+
 /**
  * suspend_set_ops - Set the global suspend method table.
  * @ops: Suspend operations to use.
  */
 void suspend_set_ops(const struct platform_suspend_ops *ops)
 {
-	suspend_state_t i;
+	suspend_state_t i, j = PM_SUSPEND_MAX - 1;
 
 	lock_system_sleep();
 
 	suspend_ops = ops;
-	for (i = PM_SUSPEND_STANDBY; i <= PM_SUSPEND_MEM; i++)
-		pm_states[i].state = valid_state(i) ? i : 0;
+	for (i = PM_SUSPEND_MEM; i >= PM_SUSPEND_STANDBY; i--)
+		if (valid_state(i))
+			pm_states[j--].state = i;
+		else if (!relative_states)
+			pm_states[j--].state = 0;
+
+	pm_states[j--].state = PM_SUSPEND_FREEZE;
+	while (j >= PM_SUSPEND_MIN)
+		pm_states[j--].state = 0;
 
 	unlock_system_sleep();
 }
Index: linux-pm/Documentation/kernel-parameters.txt
===================================================================
--- linux-pm.orig/Documentation/kernel-parameters.txt
+++ linux-pm/Documentation/kernel-parameters.txt
@@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes
 			[KNL, SMP] Set scheduler's default relax_domain_level.
 			See Documentation/cgroups/cpusets.txt.
 
+	relative_sleep_states=
+			[SUSPEND] Use sleep state labeling where the deepest
+			state available other than hibernation is always "mem".
+			Format: { "0" | "1" }
+			0 -- Traditional sleep state labels.
+			1 -- Relative sleep state labels.
+
 	reserve=	[KNL,BUGS] Force the kernel to ignore some iomem area
 
 	reservetop=	[X86-32]
Index: linux-pm/kernel/power/main.c
===================================================================
--- linux-pm.orig/kernel/power/main.c
+++ linux-pm/kernel/power/main.c
@@ -279,14 +279,14 @@ static inline void pm_print_times_init(v
 struct kobject *power_kobj;
 
 /**
- *	state - control system power state.
+ * state - control system sleep states.
  *
- *	show() returns what states are supported, which is hard-coded to
- *	'freeze' (Low-Power Idle), 'standby' (Power-On Suspend),
- *	'mem' (Suspend-to-RAM), and 'disk' (Suspend-to-Disk).
+ * show() returns available sleep state labels, which may be "mem", "standby",
+ * "freeze" and "disk" (hibernation).  See Documentation/power/states.txt for a
+ * description of what they mean.
  *
- *	store() accepts one of those strings, translates it into the
- *	proper enumerated value, and initiates a suspend transition.
+ * store() accepts one of those strings, translates it into the proper
+ * enumerated value, and initiates a suspend transition.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
Index: linux-pm/Documentation/ABI/testing/sysfs-power
===================================================================
--- linux-pm.orig/Documentation/ABI/testing/sysfs-power
+++ linux-pm/Documentation/ABI/testing/sysfs-power
@@ -7,19 +7,30 @@ Description:
 		subsystem.
 
 What:		/sys/power/state
-Date:		August 2006
+Date:		May 2014
 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
-		The /sys/power/state file controls the system power state.
-		Reading from this file returns what states are supported,
-		which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
-		(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
-		(Suspend-to-Disk).
+		The /sys/power/state file controls system sleep states.
+		Reading from this file returns the available sleep state
+		labels, which may be "mem", "standby", "freeze" and "disk"
+		(hibernation).  The meanings of the first three labels depend on
+		the relative_sleep_states command line argument as follows:
+		 1) relative_sleep_states = 1
+		    "mem", "standby", "freeze" represent non-hibernation sleep
+		    states from the deepest ("mem", always present) to the
+		    shallowest ("freeze").  "standby" and "freeze" may or may
+		    not be present depending on the capabilities of the
+		    platform.  "freeze" can only be present if "standby" is
+		    present.
+		 2) relative_sleep_states = 0 (default)
+		    "mem" - "suspend-to-RAM", present if supported.
+		    "standby" - "power-on suspend", present if supported.
+		    "freeze" - "suspend-to-idle", always present.
 
 		Writing to this file one of these strings causes the system to
-		transition into that state. Please see the file
-		Documentation/power/states.txt for a description of each of
-		these states.
+		transition into the corresponding state, if available.  See
+		Documentation/power/states.txt for a description of what
+		"suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean.
 
 What:		/sys/power/disk
 Date:		September 2006
Index: linux-pm/Documentation/power/states.txt
===================================================================
--- linux-pm.orig/Documentation/power/states.txt
+++ linux-pm/Documentation/power/states.txt
@@ -1,62 +1,87 @@
+System Power Management Sleep States
 
-System Power Management States
+(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
+The kernel supports up to four system sleep states generically, although three
+of them depend on the platform support code to implement the low-level details
+for each state.
+
+The states are represented by strings that can be read or written to the
+/sys/power/state file.  Those strings may be "mem", "standby", "freeze" and
+"disk", where the last one always represents hibernation (Suspend-To-Disk) and
+the meaning of the remaining ones depends on the relative_sleep_states command
+line argument.
+
+For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the
+available non-hibernation sleep states from the deepest to the shallowest,
+respectively.  In that case, "mem" is always present in /sys/power/state,
+because there is at least one non-hibernation sleep state in every system.  If
+the given system supports two non-hibernation sleep states, "standby" is present
+in /sys/power/state in addition to "mem".  If the system supports three
+non-hibernation sleep states, "freeze" will be present in /sys/power/state in
+addition to "mem" and "standby".
 
-The kernel supports four power management states generically, though
-one is generic and the other three are dependent on platform support
-code to implement the low-level details for each state.
-This file describes each state, what they are
-commonly called, what ACPI state they map to, and what string to write
-to /sys/power/state to enter that state
+For relative_sleep_states=0, which is the default, the following descriptions
+apply.
 
-state:		Freeze / Low-Power Idle
+state:		Suspend-To-Idle
 ACPI state:	S0
-String:		"freeze"
+Label:		"freeze"
 
-This state is a generic, pure software, light-weight, low-power state.
-It allows more energy to be saved relative to idle by freezing user
+This state is a generic, pure software, light-weight, system sleep state.
+It allows more energy to be saved relative to runtime idle by freezing user
 space and putting all I/O devices into low-power states (possibly
 lower-power than available at run time), such that the processors can
 spend more time in their idle states.
-This state can be used for platforms without Standby/Suspend-to-RAM
+
+This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
 support, or it can be used in addition to Suspend-to-RAM (memory sleep)
-to provide reduced resume latency.
+to provide reduced resume latency.  It is always supported.
 
 
 State:		Standby / Power-On Suspend
 ACPI State:	S1
-String:		"standby"
+Label:		"standby"
 
-This state offers minimal, though real, power savings, while providing
-a very low-latency transition back to a working system. No operating
-state is lost (the CPU retains power), so the system easily starts up
+This state, if supported, offers moderate, though real, power savings, while
+providing a relatively low-latency transition back to a working system.  No
+operating state is lost (the CPU retains power), so the system easily starts up
 again where it left off. 
 
-We try to put devices in a low-power state equivalent to D1, which
-also offers low power savings, but low resume latency. Not all devices
-support D1, and those that don't are left on. 
+In addition to freezing user space and putting all I/O devices into low-power
+states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline
+and all low-level system functions are suspended during transitions into this
+state.  For this reason, it should allow more energy to be saved relative to
+Suspend-To-Idle, but the resume latency will generally be greater than for that
+state.
 
 
 State:		Suspend-to-RAM
 ACPI State:	S3
-String:		"mem"
+Label:		"mem"
 
-This state offers significant power savings as everything in the
-system is put into a low-power state, except for memory, which is
-placed in self-refresh mode to retain its contents. 
-
-System and device state is saved and kept in memory. All devices are
-suspended and put into D3. In many cases, all peripheral buses lose
-power when entering STR, so devices must be able to handle the
-transition back to the On state. 
+This state, if supported, offers significant power savings as everything in the
+system is put into a low-power state, except for memory, which should be placed
+into the self-refresh mode to retain its contents.  All of the steps carried out
+when entering Power-On Suspend are also carried out during transitions to STR.
+Additional operations may take place depending on the platform capabilities.  In
+particular, on ACPI systems the kernel passes control to the BIOS (platform
+firmware) as the last step during STR transitions and that usually results in
+powering down some more low-level components that aren't directly controlled by
+the kernel.
+
+System and device state is saved and kept in memory.  All devices are suspended
+and put into low-power states.  In many cases, all peripheral buses lose power
+when entering STR, so devices must be able to handle the transition back to the
+"on" state.
 
-For at least ACPI, STR requires some minimal boot-strapping code to
-resume the system from STR. This may be true on other platforms. 
+For at least ACPI, STR requires some minimal boot-strapping code to resume the
+system from it.  This may be the case on other platforms too.
 
 
 State:		Suspend-to-disk
 ACPI State:	S4
-String:		"disk"
+Label:		"disk"
 
 This state offers the greatest power savings, and can be used even in
 the absence of low-level platform support for power management. This

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Srivatsa S. Bhat]

On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> On some systems the platform doesn't support neither
> PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> only available system sleep state.  However, some user space frameworks
> only use the "mem" and (sometimes) "standby" sleep state labels, so
> the users of those systems need to modify user space in order to be
> able to use system suspend at all and that is not always possible.
>

So, is this going to be a temporary solution until all the user-space
frameworks have been fixed? I certainly hope so, because this clearly looks
like a bug (or a lack of feature) in user-space to me... in the sense that
those user-space frameworks don't have support for (i.e., don't know how to
deal with) freeze-only systems yet.

The more elegant long term solution would have been to teach the kernel to
export *truly* relative names such as SUSPEND_DEEP, SUSPEND_SHALLOW,
and SUSPEND_LIGHT or something like that (of course, we can debate on what
naming would suit best).

But this patch continues to keep the names 'SUSPEND_MEM' ("mem") etc., which
still implies that we are doing Suspend-to-RAM, because the name itself betrays
that info. So IMHO it doesn't really match what the command-line-switch
'relative_sleep_states' says.

But I understand that this is a quick hack to make existing user-space work
with systems that support only the freeze state. However, for the reasons
mentioned above, I hope that this is a temporary solution and we can remove
or enhance this once all those user-space frameworks have been fixed.

Regards,
Srivatsa S. Bhat
 
> For this reason, add a new kernel command line argument,
> relative_sleep_states, allowing the users of those systems to change
> the way in which the kernel assigns labels to system sleep states.
> Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze"
> labels will enumerate the available system sleem states from the
> deepest to the shallowest, respectively, so that "mem" is always
> present in /sys/power/state and the other state strings may or may
> not be presend depending on what is supported by the platform.
> 
> Update system sleep states documentation to reflect this change.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> 
> This update is needed after patch [2/3] has been updated.
> 
> Thanks!
> 
> ---
>  Documentation/ABI/testing/sysfs-power |   29 +++++++----
>  Documentation/kernel-parameters.txt   |    7 ++
>  Documentation/power/states.txt        |   89 +++++++++++++++++++++-------------
>  kernel/power/main.c                   |   12 ++--
>  kernel/power/suspend.c                |   33 +++++++++++-
>  5 files changed, 120 insertions(+), 50 deletions(-)
> 
> Index: linux-pm/kernel/power/suspend.c
> ===================================================================
> --- linux-pm.orig/kernel/power/suspend.c
> +++ linux-pm/kernel/power/suspend.c
> @@ -86,19 +86,46 @@ static bool valid_state(suspend_state_t
>  	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
>  }
> 
> +/*
> + * If this is set, the "mem" label always corresponds to the deepest sleep state
> + * available, the "standby" label corresponds to the second deepest sleep state
> + * available (if any), and the "freeze" label corresponds to the remaining
> + * available sleep state (if there is one).
> + */
> +static bool relative_states;
> +
> +static int __init sleep_states_setup(char *str)
> +{
> +	relative_states = !strncmp(str, "1", 1);
> +	if (relative_states) {
> +		pm_states[PM_SUSPEND_MEM].state = PM_SUSPEND_FREEZE;
> +		pm_states[PM_SUSPEND_FREEZE].state = 0;
> +	}
> +	return 1;
> +}
> +
> +__setup("relative_sleep_states=", sleep_states_setup);
> +
>  /**
>   * suspend_set_ops - Set the global suspend method table.
>   * @ops: Suspend operations to use.
>   */
>  void suspend_set_ops(const struct platform_suspend_ops *ops)
>  {
> -	suspend_state_t i;
> +	suspend_state_t i, j = PM_SUSPEND_MAX - 1;
> 
>  	lock_system_sleep();
> 
>  	suspend_ops = ops;
> -	for (i = PM_SUSPEND_STANDBY; i <= PM_SUSPEND_MEM; i++)
> -		pm_states[i].state = valid_state(i) ? i : 0;
> +	for (i = PM_SUSPEND_MEM; i >= PM_SUSPEND_STANDBY; i--)
> +		if (valid_state(i))
> +			pm_states[j--].state = i;
> +		else if (!relative_states)
> +			pm_states[j--].state = 0;
> +
> +	pm_states[j--].state = PM_SUSPEND_FREEZE;
> +	while (j >= PM_SUSPEND_MIN)
> +		pm_states[j--].state = 0;
> 
>  	unlock_system_sleep();
>  }
> Index: linux-pm/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-pm.orig/Documentation/kernel-parameters.txt
> +++ linux-pm/Documentation/kernel-parameters.txt
> @@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes
>  			[KNL, SMP] Set scheduler's default relax_domain_level.
>  			See Documentation/cgroups/cpusets.txt.
> 
> +	relative_sleep_states=
> +			[SUSPEND] Use sleep state labeling where the deepest
> +			state available other than hibernation is always "mem".
> +			Format: { "0" | "1" }
> +			0 -- Traditional sleep state labels.
> +			1 -- Relative sleep state labels.
> +
>  	reserve=	[KNL,BUGS] Force the kernel to ignore some iomem area
> 
>  	reservetop=	[X86-32]
> Index: linux-pm/kernel/power/main.c
> ===================================================================
> --- linux-pm.orig/kernel/power/main.c
> +++ linux-pm/kernel/power/main.c
> @@ -279,14 +279,14 @@ static inline void pm_print_times_init(v
>  struct kobject *power_kobj;
> 
>  /**
> - *	state - control system power state.
> + * state - control system sleep states.
>   *
> - *	show() returns what states are supported, which is hard-coded to
> - *	'freeze' (Low-Power Idle), 'standby' (Power-On Suspend),
> - *	'mem' (Suspend-to-RAM), and 'disk' (Suspend-to-Disk).
> + * show() returns available sleep state labels, which may be "mem", "standby",
> + * "freeze" and "disk" (hibernation).  See Documentation/power/states.txt for a
> + * description of what they mean.
>   *
> - *	store() accepts one of those strings, translates it into the
> - *	proper enumerated value, and initiates a suspend transition.
> + * store() accepts one of those strings, translates it into the proper
> + * enumerated value, and initiates a suspend transition.
>   */
>  static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			  char *buf)
> Index: linux-pm/Documentation/ABI/testing/sysfs-power
> ===================================================================
> --- linux-pm.orig/Documentation/ABI/testing/sysfs-power
> +++ linux-pm/Documentation/ABI/testing/sysfs-power
> @@ -7,19 +7,30 @@ Description:
>  		subsystem.
> 
>  What:		/sys/power/state
> -Date:		August 2006
> +Date:		May 2014
>  Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
>  Description:
> -		The /sys/power/state file controls the system power state.
> -		Reading from this file returns what states are supported,
> -		which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
> -		(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
> -		(Suspend-to-Disk).
> +		The /sys/power/state file controls system sleep states.
> +		Reading from this file returns the available sleep state
> +		labels, which may be "mem", "standby", "freeze" and "disk"
> +		(hibernation).  The meanings of the first three labels depend on
> +		the relative_sleep_states command line argument as follows:
> +		 1) relative_sleep_states = 1
> +		    "mem", "standby", "freeze" represent non-hibernation sleep
> +		    states from the deepest ("mem", always present) to the
> +		    shallowest ("freeze").  "standby" and "freeze" may or may
> +		    not be present depending on the capabilities of the
> +		    platform.  "freeze" can only be present if "standby" is
> +		    present.
> +		 2) relative_sleep_states = 0 (default)
> +		    "mem" - "suspend-to-RAM", present if supported.
> +		    "standby" - "power-on suspend", present if supported.
> +		    "freeze" - "suspend-to-idle", always present.
> 
>  		Writing to this file one of these strings causes the system to
> -		transition into that state. Please see the file
> -		Documentation/power/states.txt for a description of each of
> -		these states.
> +		transition into the corresponding state, if available.  See
> +		Documentation/power/states.txt for a description of what
> +		"suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean.
> 
>  What:		/sys/power/disk
>  Date:		September 2006
> Index: linux-pm/Documentation/power/states.txt
> ===================================================================
> --- linux-pm.orig/Documentation/power/states.txt
> +++ linux-pm/Documentation/power/states.txt
> @@ -1,62 +1,87 @@
> +System Power Management Sleep States
> 
> -System Power Management States
> +(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> +The kernel supports up to four system sleep states generically, although three
> +of them depend on the platform support code to implement the low-level details
> +for each state.
> +
> +The states are represented by strings that can be read or written to the
> +/sys/power/state file.  Those strings may be "mem", "standby", "freeze" and
> +"disk", where the last one always represents hibernation (Suspend-To-Disk) and
> +the meaning of the remaining ones depends on the relative_sleep_states command
> +line argument.
> +
> +For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the
> +available non-hibernation sleep states from the deepest to the shallowest,
> +respectively.  In that case, "mem" is always present in /sys/power/state,
> +because there is at least one non-hibernation sleep state in every system.  If
> +the given system supports two non-hibernation sleep states, "standby" is present
> +in /sys/power/state in addition to "mem".  If the system supports three
> +non-hibernation sleep states, "freeze" will be present in /sys/power/state in
> +addition to "mem" and "standby".
> 
> -The kernel supports four power management states generically, though
> -one is generic and the other three are dependent on platform support
> -code to implement the low-level details for each state.
> -This file describes each state, what they are
> -commonly called, what ACPI state they map to, and what string to write
> -to /sys/power/state to enter that state
> +For relative_sleep_states=0, which is the default, the following descriptions
> +apply.
> 
> -state:		Freeze / Low-Power Idle
> +state:		Suspend-To-Idle
>  ACPI state:	S0
> -String:		"freeze"
> +Label:		"freeze"
> 
> -This state is a generic, pure software, light-weight, low-power state.
> -It allows more energy to be saved relative to idle by freezing user
> +This state is a generic, pure software, light-weight, system sleep state.
> +It allows more energy to be saved relative to runtime idle by freezing user
>  space and putting all I/O devices into low-power states (possibly
>  lower-power than available at run time), such that the processors can
>  spend more time in their idle states.
> -This state can be used for platforms without Standby/Suspend-to-RAM
> +
> +This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
>  support, or it can be used in addition to Suspend-to-RAM (memory sleep)
> -to provide reduced resume latency.
> +to provide reduced resume latency.  It is always supported.
> 
> 
>  State:		Standby / Power-On Suspend
>  ACPI State:	S1
> -String:		"standby"
> +Label:		"standby"
> 
> -This state offers minimal, though real, power savings, while providing
> -a very low-latency transition back to a working system. No operating
> -state is lost (the CPU retains power), so the system easily starts up
> +This state, if supported, offers moderate, though real, power savings, while
> +providing a relatively low-latency transition back to a working system.  No
> +operating state is lost (the CPU retains power), so the system easily starts up
>  again where it left off. 
> 
> -We try to put devices in a low-power state equivalent to D1, which
> -also offers low power savings, but low resume latency. Not all devices
> -support D1, and those that don't are left on. 
> +In addition to freezing user space and putting all I/O devices into low-power
> +states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline
> +and all low-level system functions are suspended during transitions into this
> +state.  For this reason, it should allow more energy to be saved relative to
> +Suspend-To-Idle, but the resume latency will generally be greater than for that
> +state.
> 
> 
>  State:		Suspend-to-RAM
>  ACPI State:	S3
> -String:		"mem"
> +Label:		"mem"
> 
> -This state offers significant power savings as everything in the
> -system is put into a low-power state, except for memory, which is
> -placed in self-refresh mode to retain its contents. 
> -
> -System and device state is saved and kept in memory. All devices are
> -suspended and put into D3. In many cases, all peripheral buses lose
> -power when entering STR, so devices must be able to handle the
> -transition back to the On state. 
> +This state, if supported, offers significant power savings as everything in the
> +system is put into a low-power state, except for memory, which should be placed
> +into the self-refresh mode to retain its contents.  All of the steps carried out
> +when entering Power-On Suspend are also carried out during transitions to STR.
> +Additional operations may take place depending on the platform capabilities.  In
> +particular, on ACPI systems the kernel passes control to the BIOS (platform
> +firmware) as the last step during STR transitions and that usually results in
> +powering down some more low-level components that aren't directly controlled by
> +the kernel.
> +
> +System and device state is saved and kept in memory.  All devices are suspended
> +and put into low-power states.  In many cases, all peripheral buses lose power
> +when entering STR, so devices must be able to handle the transition back to the
> +"on" state.
> 
> -For at least ACPI, STR requires some minimal boot-strapping code to
> -resume the system from STR. This may be true on other platforms. 
> +For at least ACPI, STR requires some minimal boot-strapping code to resume the
> +system from it.  This may be the case on other platforms too.
> 
> 
>  State:		Suspend-to-disk
>  ACPI State:	S4
> -String:		"disk"
> +Label:		"disk"
> 
>  This state offers the greatest power savings, and can be used even in
>  the absence of low-level platform support for power management. This
> 

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Srivatsa S. Bhat]

On 05/26/2014 04:30 PM, Rafael J. Wysocki wrote:
> On Monday, May 26, 2014 02:01:14 PM Srivatsa S. Bhat wrote:
>> On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>
>>> On some systems the platform doesn't support neither
>>> PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
>>> only available system sleep state.  However, some user space frameworks
>>> only use the "mem" and (sometimes) "standby" sleep state labels, so
>>> the users of those systems need to modify user space in order to be
>>> able to use system suspend at all and that is not always possible.
>>>
>>
>> So, is this going to be a temporary solution until all the user-space
>> frameworks have been fixed? I certainly hope so, because this clearly looks
>> like a bug (or a lack of feature) in user-space to me... in the sense that
>> those user-space frameworks don't have support for (i.e., don't know how to
>> deal with) freeze-only systems yet.
>>
>> The more elegant long term solution would have been to teach the kernel to
>> export *truly* relative names such as SUSPEND_DEEP, SUSPEND_SHALLOW,
>> and SUSPEND_LIGHT or something like that (of course, we can debate on what
>> naming would suit best).
> 
> I agree and that's a logical next step, so I have a plan to rename the kernel
> symbols corresponding to each state so that they reflect the code more closely
> (for example, the current PM_SUSPEND_MEM and PM_SUSPEND_STANDBY depend on the
> platform to support them, but that is not clear from the symbol naming, and on
> many platforms _MEM doesn't mean "suspend-to-RAM" anyway).
> 

Ok..

> The strings in the interface are a somewhat different matter, because user
> space already depends on them (which is the source of the problem here), so we
> may need to keep them or at least respond to them as expected when written to
> /sys/power/state.
>

Right, I see your point..
 
> I personally think that we should use "sleep", "snooze" and "pause" to reflect
> the "sleep depth".  And possibly "hibernate" instead of "disk".
> 

Yeah, that sounds good.

>> But this patch continues to keep the names 'SUSPEND_MEM' ("mem") etc., which
>> still implies that we are doing Suspend-to-RAM, because the name itself betrays
>> that info. So IMHO it doesn't really match what the command-line-switch
>> 'relative_sleep_states' says.
>>
>> But I understand that this is a quick hack to make existing user-space work
>> with systems that support only the freeze state. However, for the reasons
>> mentioned above, I hope that this is a temporary solution and we can remove
>> or enhance this once all those user-space frameworks have been fixed.
> 
> Well, it is supposed to be temporary, but I'm not sure if we can count on all
> user space to be fixed in any reasonable time frame (think about Android, for
> example).
> 

Hmm, that's sad. But anyway, I just wanted to point out issues with this patch
and suggest possible enhancements. But since you seem to have already thought
through all of this, I have no objections to this patch.

Thank you!
 
Regards,
Srivatsa S. Bhat

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Monday, May 26, 2014 02:01:14 PM Srivatsa S. Bhat wrote:
> On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > 
> > On some systems the platform doesn't support neither
> > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > only available system sleep state.  However, some user space frameworks
> > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > the users of those systems need to modify user space in order to be
> > able to use system suspend at all and that is not always possible.
> >
> 
> So, is this going to be a temporary solution until all the user-space
> frameworks have been fixed? I certainly hope so, because this clearly looks
> like a bug (or a lack of feature) in user-space to me... in the sense that
> those user-space frameworks don't have support for (i.e., don't know how to
> deal with) freeze-only systems yet.
> 
> The more elegant long term solution would have been to teach the kernel to
> export *truly* relative names such as SUSPEND_DEEP, SUSPEND_SHALLOW,
> and SUSPEND_LIGHT or something like that (of course, we can debate on what
> naming would suit best).

I agree and that's a logical next step, so I have a plan to rename the kernel
symbols corresponding to each state so that they reflect the code more closely
(for example, the current PM_SUSPEND_MEM and PM_SUSPEND_STANDBY depend on the
platform to support them, but that is not clear from the symbol naming, and on
many platforms _MEM doesn't mean "suspend-to-RAM" anyway).

The strings in the interface are a somewhat different matter, because user
space already depends on them (which is the source of the problem here), so we
may need to keep them or at least respond to them as expected when written to
/sys/power/state.

I personally think that we should use "sleep", "snooze" and "pause" to reflect
the "sleep depth".  And possibly "hibernate" instead of "disk".

> But this patch continues to keep the names 'SUSPEND_MEM' ("mem") etc., which
> still implies that we are doing Suspend-to-RAM, because the name itself betrays
> that info. So IMHO it doesn't really match what the command-line-switch
> 'relative_sleep_states' says.
> 
> But I understand that this is a quick hack to make existing user-space work
> with systems that support only the freeze state. However, for the reasons
> mentioned above, I hope that this is a temporary solution and we can remove
> or enhance this once all those user-space frameworks have been fixed.

Well, it is supposed to be temporary, but I'm not sure if we can count on all
user space to be fixed in any reasonable time frame (think about Android, for
example).

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Pavel Machek]

Hi!

> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> On some systems the platform doesn't support neither
> PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> only available system sleep state.  However, some user space frameworks
> only use the "mem" and (sometimes) "standby" sleep state labels, so
> the users of those systems need to modify user space in order to be
> able to use system suspend at all and that is not always possible.

I'd say we should fix the frameworks, not add option to change kernel
interfaces.

Because, as you mentioned, if we add this, we are probably going to
get stuck with it forever :-(.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Tuesday, June 10, 2014 03:12:06 PM Pavel Machek wrote:
> Hi!
> 
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > 
> > On some systems the platform doesn't support neither
> > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > only available system sleep state.  However, some user space frameworks
> > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > the users of those systems need to modify user space in order to be
> > able to use system suspend at all and that is not always possible.
> 
> I'd say we should fix the frameworks, not add option to change kernel
> interfaces.
> 
> Because, as you mentioned, if we add this, we are probably going to
> get stuck with it forever :-(.

Unfortunately, fixing the frameworks is rather less than realistic in any
reasonable time frame, since  Android. :-)

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Tuesday, June 10, 2014 05:23:24 PM Rafael J. Wysocki wrote:
> On Tuesday, June 10, 2014 03:12:06 PM Pavel Machek wrote:
> > Hi!
> > 
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > 
> > > On some systems the platform doesn't support neither
> > > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > > only available system sleep state.  However, some user space frameworks
> > > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > > the users of those systems need to modify user space in order to be
> > > able to use system suspend at all and that is not always possible.
> > 
> > I'd say we should fix the frameworks, not add option to change kernel
> > interfaces.
> > 
> > Because, as you mentioned, if we add this, we are probably going to
> > get stuck with it forever :-(.
> 
> Unfortunately, fixing the frameworks is rather less than realistic in any
> reasonable time frame, since  Android. :-)

Android is one of them.  (sorry for sending prematurely).

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Pavel Machek]

On Tue 2014-06-10 17:23:24, Rafael J. Wysocki wrote:
> On Tuesday, June 10, 2014 03:12:06 PM Pavel Machek wrote:
> > Hi!
> > 
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > 
> > > On some systems the platform doesn't support neither
> > > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > > only available system sleep state.  However, some user space frameworks
> > > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > > the users of those systems need to modify user space in order to be
> > > able to use system suspend at all and that is not always possible.
> > 
> > I'd say we should fix the frameworks, not add option to change kernel
> > interfaces.
> > 
> > Because, as you mentioned, if we add this, we are probably going to
> > get stuck with it forever :-(.
> 
> Unfortunately, fixing the frameworks is rather less than realistic in any
> reasonable time frame, since  Android. :-)

Actually, you still have the sources from android, and this issue
sounds almost simple enough for binary patch.

Android misuses /proc/sys/vm/drop_caches, too, IIRC. Are we going to
change interface to match their expectations? They have binder and
wakelocks. Are we going to apply those patches just because Android
wants that?

Android people usually patch their kernels, anyway, so why not add
this one, too?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Tuesday, June 10, 2014 09:59:05 PM Pavel Machek wrote:
> On Tue 2014-06-10 17:23:24, Rafael J. Wysocki wrote:
> > On Tuesday, June 10, 2014 03:12:06 PM Pavel Machek wrote:
> > > Hi!
> > > 
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > 
> > > > On some systems the platform doesn't support neither
> > > > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > > > only available system sleep state.  However, some user space frameworks
> > > > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > > > the users of those systems need to modify user space in order to be
> > > > able to use system suspend at all and that is not always possible.
> > > 
> > > I'd say we should fix the frameworks, not add option to change kernel
> > > interfaces.
> > > 
> > > Because, as you mentioned, if we add this, we are probably going to
> > > get stuck with it forever :-(.
> > 
> > Unfortunately, fixing the frameworks is rather less than realistic in any
> > reasonable time frame, since  Android. :-)
> 
> Actually, you still have the sources from android, and this issue
> sounds almost simple enough for binary patch.
> 
> Android misuses /proc/sys/vm/drop_caches, too, IIRC. Are we going to
> change interface to match their expectations? They have binder and
> wakelocks. Are we going to apply those patches just because Android
> wants that?

That depends on which versions of Android you're talking about.  The
newest ones use the power management interfaces we have upstream.

> Android people usually patch their kernels, anyway, so why not add
> this one, too?

I'm not talking about Android kernels, but about Android user space.

And this is not only about Android, other distros also have user space that
uses "mem" only, because nobody has used anything else for a long time anyway.
For the users of those distros, if they don't want to modify user space,
having a kernel command line like this is actually helpful.

So I'm really not sure what's the problem?  Do you think it's wrong to be
helpful to users or something?

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Pavel Machek]

Hi!

> > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > > 
> > > > > On some systems the platform doesn't support neither
> > > > > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > > > > only available system sleep state.  However, some user space frameworks
> > > > > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > > > > the users of those systems need to modify user space in order to be
> > > > > able to use system suspend at all and that is not always possible.
> > > > 
> > > > I'd say we should fix the frameworks, not add option to change kernel
> > > > interfaces.
> > > > 
> > > > Because, as you mentioned, if we add this, we are probably going to
> > > > get stuck with it forever :-(.
> > > 
> > > Unfortunately, fixing the frameworks is rather less than realistic in any
> > > reasonable time frame, since  Android. :-)
> > 
> > Actually, you still have the sources from android, and this issue
> > sounds almost simple enough for binary patch.
> > 
> > Android misuses /proc/sys/vm/drop_caches, too, IIRC. Are we going to
> > change interface to match their expectations? They have binder and
> > wakelocks. Are we going to apply those patches just because Android
> > wants that?
> 
> That depends on which versions of Android you're talking about.  The
> newest ones use the power management interfaces we have upstream.

Ok, good, so they can fix their code.

What problem are you solving? Do you have some weird hardware where
suspend to memory is impossible? 

> > Android people usually patch their kernels, anyway, so why not add
> > this one, too?
> 
> I'm not talking about Android kernels, but about Android user space.

I know. Android userspace usually runs on modified kernel, so you can
simply add your patch. But I don't think its suitable for mainline.  

> And this is not only about Android, other distros also have user space that
> uses "mem" only, because nobody has used anything else for a long time anyway.
> For the users of those distros, if they don't want to modify user space,
> having a kernel command line like this is actually helpful.

Yes, still its wrong place to fix it...

> So I'm really not sure what's the problem?  Do you think it's wrong to be
> helpful to users or something?

It is not wrong to be helpful, but messed up interface is too big a
price.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Friday, June 13, 2014 11:46:12 PM Pavel Machek wrote:
> Hi!
> 
> > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > > > 
> > > > > > On some systems the platform doesn't support neither
> > > > > > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > > > > > only available system sleep state.  However, some user space frameworks
> > > > > > only use the "mem" and (sometimes) "standby" sleep state labels, so
> > > > > > the users of those systems need to modify user space in order to be
> > > > > > able to use system suspend at all and that is not always possible.
> > > > > 
> > > > > I'd say we should fix the frameworks, not add option to change kernel
> > > > > interfaces.
> > > > > 
> > > > > Because, as you mentioned, if we add this, we are probably going to
> > > > > get stuck with it forever :-(.
> > > > 
> > > > Unfortunately, fixing the frameworks is rather less than realistic in any
> > > > reasonable time frame, since  Android. :-)
> > > 
> > > Actually, you still have the sources from android, and this issue
> > > sounds almost simple enough for binary patch.
> > > 
> > > Android misuses /proc/sys/vm/drop_caches, too, IIRC. Are we going to
> > > change interface to match their expectations? They have binder and
> > > wakelocks. Are we going to apply those patches just because Android
> > > wants that?
> > 
> > That depends on which versions of Android you're talking about.  The
> > newest ones use the power management interfaces we have upstream.
> 
> Ok, good, so they can fix their code.
> 
> What problem are you solving? Do you have some weird hardware where
> suspend to memory is impossible? 
> 
> > > Android people usually patch their kernels, anyway, so why not add
> > > this one, too?
> > 
> > I'm not talking about Android kernels, but about Android user space.
> 
> I know. Android userspace usually runs on modified kernel, so you can
> simply add your patch. But I don't think its suitable for mainline.  
> 
> > And this is not only about Android, other distros also have user space that
> > uses "mem" only, because nobody has used anything else for a long time anyway.
> > For the users of those distros, if they don't want to modify user space,
> > having a kernel command line like this is actually helpful.
> 
> Yes, still its wrong place to fix it...

This isn't a fix.  It's a workaround.

> > So I'm really not sure what's the problem?  Do you think it's wrong to be
> > helpful to users or something?
> 
> It is not wrong to be helpful, but messed up interface is too big a
> price.

Why?  I will have to maintain it after all, right?

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Saturday, June 14, 2014 12:16:26 AM Rafael J. Wysocki wrote:
> On Friday, June 13, 2014 11:46:12 PM Pavel Machek wrote:

[...]

> > > So I'm really not sure what's the problem?  Do you think it's wrong to be
> > > helpful to users or something?
> > 
> > It is not wrong to be helpful, but messed up interface is too big a
> > price.
> 
> Why?  I will have to maintain it after all, right?

And by the way, the very fact that this workaround is even useful in some cases
indicates that the interface that we've invented originally is not particularly
useful to user space.  The reason why is because user space is supposed to
enumerate the sleep states and then present the ones that are present in a
consistent way to the user.  It basically has to do "Is 'mem' present"?  Use it
if so, but if not is 'standby' present?  Use it if so etc." every time or
squirrel that information somewhere which isn't particularly straightforward.

So perhaps we should change the interface entirely?

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Saturday, June 14, 2014 12:23:15 AM Rafael J. Wysocki wrote:
> On Saturday, June 14, 2014 12:16:26 AM Rafael J. Wysocki wrote:
> > On Friday, June 13, 2014 11:46:12 PM Pavel Machek wrote:
> 
> [...]
> 
> > > > So I'm really not sure what's the problem?  Do you think it's wrong to be
> > > > helpful to users or something?
> > > 
> > > It is not wrong to be helpful, but messed up interface is too big a
> > > price.
> > 
> > Why?  I will have to maintain it after all, right?
> 
> And by the way, the very fact that this workaround is even useful in some cases
> indicates that the interface that we've invented originally is not particularly
> useful to user space.  The reason why is because user space is supposed to
> enumerate the sleep states and then present the ones that are present in a
> consistent way to the user.  It basically has to do "Is 'mem' present"?  Use it
> if so, but if not is 'standby' present?  Use it if so etc." every time or
> squirrel that information somewhere which isn't particularly straightforward.

Moreover, the "mem" and "standby" states are not really well defined on anything
different from ACPI, so "mem" is used by everybody having just one platform-supported
state.  That's why user space doesn't bother to check the other ones in many
cases and it is not really their problem.  It is the problem of our existing
interface that wasn't designed correctly.

My first reaction to this issue was pretty much the same as yours, but when I started
to think more about it, I've realized that we messed up things to start with and now
we're just having to deal with the consequences.  So yes, we can put our heads in
the ground and say "that's not our problem, it has to be addressed in user space",
but quite frankly I'm not seeing how we can persuade user space developers address
it given that the vast majority of systems use "mem" only anyway and that they don't
really understand where the problem is.

For this reason I'm considering changing the defaul behavior going forward (so
that "mem" is always present and means "the deepest sleep state available other
than hibernation"), but I don't want to do that in one go.

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Pavel Machek]

Hi!

> For this reason I'm considering changing the defaul behavior going forward (so
> that "mem" is always present and means "the deepest sleep state available other
> than hibernation"), but I don't want to do that in one go.

Actually, I don't think that's good idea, at least on PC.

The way to wake up from S3 is power button. The way to wake up from
"echo freeze > state" is going to be different, right?

If I disable S3 in the BIOS and get different result from "echo mem >
state", that will be confusing.

Similar (but less severe) problem is there with S1, as it will
probably power down USB ports, etc.

So for example if I have system with S1, learn to do "echo mem >
state" and that it still charges my phone, then ACPI updates come and
"echo mem > state" now puts it in S3 and not charging my phone -- that
would be confusing.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Wednesday, July 30, 2014 12:55:29 PM Pavel Machek wrote:
> Hi!
> 
> > For this reason I'm considering changing the defaul behavior going forward (so
> > that "mem" is always present and means "the deepest sleep state available other
> > than hibernation"), but I don't want to do that in one go.
> 
> Actually, I don't think that's good idea, at least on PC.
> 
> The way to wake up from S3 is power button. The way to wake up from
> "echo freeze > state" is going to be different, right?

No, it isn't.  That's the point among other things.

> If I disable S3 in the BIOS and get different result from "echo mem >
> state", that will be confusing.

It may or may not be, depending on how different the handling of the states
is.  It shouldn't be much different.

> Similar (but less severe) problem is there with S1, as it will
> probably power down USB ports, etc.

Hmm.  S1 is implemented very rarely AFAICS and usually it works in analogy
with suspend-to-idle, but in the firmware.

> So for example if I have system with S1, learn to do "echo mem >
> state" and that it still charges my phone, then ACPI updates come and
> "echo mem > state" now puts it in S3 and not charging my phone -- that
> would be confusing.

Yes, it would.

Rafael

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Pavel Machek]

On Fri 2014-08-01 15:54:32, Rafael J. Wysocki wrote:
> On Wednesday, July 30, 2014 12:55:29 PM Pavel Machek wrote:
> > 
> > > For this reason I'm considering changing the defaul behavior going forward (so
> > > that "mem" is always present and means "the deepest sleep state available other
> > > than hibernation"), but I don't want to do that in one go.
> > 
> > Actually, I don't think that's good idea, at least on PC.
> > 
> > The way to wake up from S3 is power button. The way to wake up from
> > "echo freeze > state" is going to be different, right?
> 
> No, it isn't.  That's the point among other things.

There's difference, actually.

>From S3, power button event is consumed.

>From freeze, after resume, "what you want to do? power off,
suspend, hibernate" dialog appears.

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Rafael J. Wysocki]

On Sat, Aug 16, 2014 at 10:10 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2014-08-01 15:54:32, Rafael J. Wysocki wrote:
>> On Wednesday, July 30, 2014 12:55:29 PM Pavel Machek wrote:
>> >
>> > > For this reason I'm considering changing the defaul behavior going forward (so
>> > > that "mem" is always present and means "the deepest sleep state available other
>> > > than hibernation"), but I don't want to do that in one go.
>> >
>> > Actually, I don't think that's good idea, at least on PC.
>> >
>> > The way to wake up from S3 is power button. The way to wake up from
>> > "echo freeze > state" is going to be different, right?
>>
>> No, it isn't.  That's the point among other things.
>
> There's difference, actually.
>
> From S3, power button event is consumed.
>
> From freeze, after resume, "what you want to do? power off,
> suspend, hibernate" dialog appears.

In 3.17-rc1 it shouldn't.  Have you tested this one?

Rafael