Date:	Mon, 26 May 2014 14:01:14 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument
 for sleep state enumeration

On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.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@...el.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@...ysocki.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@...el.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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists