Merge tag 'pm+acpi-3.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

System Power Management Phases

------------------------------

Suspending or resuming the system is done in several phases.  Different phases

are used for standby or memory sleep states ("suspend-to-RAM") and the

are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the

hibernation state ("suspend-to-disk").  Each phase involves executing callbacks

for every device before the next phase begins.  Not all busses or classes

support all these callbacks and not all drivers use all the callbacks.  The

Entering System Suspend

-----------------------

When the system goes into the standby or memory sleep state, the phases are:

When the system goes into the freeze, standby or memory sleep state,

the phases are:

		prepare, suspend, suspend_late, suspend_noirq.

Leaving System Suspend

----------------------

When resuming from standby or memory sleep, the phases are:

When resuming from freeze, standby or memory sleep, the phases are:

		resume_noirq, resume_early, resume, complete.

Entering Hibernation

--------------------

Hibernating the system is more complicated than putting it into the standby or

memory sleep state, because it involves creating and saving a system image.

Hibernating the system is more complicated than putting it into the other

sleep states, because it involves creating and saving a system image.

Therefore there are more phases for hibernation, with a different set of

callbacks.  These phases always run after tasks have been frozen and memory has

been freed.

At this point the system image is saved, and the devices then need to be

prepared for the upcoming system shutdown.  This is much like suspending them

before putting the system into the standby or memory sleep state, and the phases

are similar.

before putting the system into the freeze, standby or memory sleep state,

and the phases are similar.

    9.	The prepare phase is discussed above.

is mounted at /sys). 

/sys/power/state controls system power state. Reading from this file

returns what states are supported, which is hard-coded to 'standby'

(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'

returns what states are supported, which is hard-coded to 'freeze',

'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'

(Suspend-to-Disk). 

Writing to this file one of those strings causes the system to

The subsystems or drivers having such needs can register suspend notifiers that

will be called upon the following events by the PM core:

PM_HIBERNATION_PREPARE	The system is going to hibernate or suspend, tasks will

			be frozen immediately.

PM_HIBERNATION_PREPARE	The system is going to hibernate, tasks will be frozen

			immediately. This is different from PM_SUSPEND_PREPARE

			below because here we do additional work between notifiers

			and drivers freezing.

PM_POST_HIBERNATION	The system memory state has been restored from a

			hibernation image or an error occurred during

System Power Management States

The kernel supports three power management states generically, though

each is dependent on platform support code to implement the low-level

details for each state. This file describes each state, what they are

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

state:		Freeze / Low-Power Idle

ACPI state:	S0

String:		"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

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

support, or it can be used in addition to Suspend-to-RAM (memory sleep)

to provide reduced resume latency.

State:		Standby / Power-On Suspend

ACPI State:	S1

also offers low power savings, but low resume latency. Not all devices

support D1, and those that don't are left on. 

A transition from Standby to the On state should take about 1-2

seconds. 

State:		Suspend-to-RAM

ACPI State:	S3

For at least ACPI, STR requires some minimal boot-strapping code to

resume the system from STR. This may be true on other platforms. 

A transition from Suspend-to-RAM to the On state should take about

3-5 seconds. 

State:		Suspend-to-disk

ACPI State:	S4

down offers greater savings, and allows this mechanism to work on any

system. However, entering a real low-power state allows the user to

trigger wake up events (e.g. pressing a key or opening a laptop lid).

A transition from Suspend-to-Disk to the On state should take about 30

seconds, though it's typically a bit more with the current

implementation. 

#include <linux/slab.h>

#include <linux/init.h>

#include <linux/types.h>

#include <linux/dmi.h>

#include <linux/delay.h>

#ifdef CONFIG_ACPI_PROCFS_POWER

#include <linux/proc_fs.h>

#include <linux/seq_file.h>

#endif

static SIMPLE_DEV_PM_OPS(acpi_ac_pm, NULL, acpi_ac_resume);

static int ac_sleep_before_get_state_ms;

static struct acpi_driver acpi_ac_driver = {

	.name = "ac",

	.class = ACPI_AC_CLASS,

	case ACPI_AC_NOTIFY_STATUS:

	case ACPI_NOTIFY_BUS_CHECK:

	case ACPI_NOTIFY_DEVICE_CHECK:

		/*

		 * A buggy BIOS may notify AC first and then sleep for

		 * a specific time before doing actual operations in the

		 * EC event handler (_Qxx). This will cause the AC state

		 * reported by the ACPI event to be incorrect, so wait for a

		 * specific time for the EC event handler to make progress.

		 */

		if (ac_sleep_before_get_state_ms > 0)

			msleep(ac_sleep_before_get_state_ms);

		acpi_ac_get_state(ac);

		acpi_bus_generate_proc_event(device, event, (u32) ac->state);

		acpi_bus_generate_netlink_event(device->pnp.device_class,

	return;

}

static int thinkpad_e530_quirk(const struct dmi_system_id *d)

{

	ac_sleep_before_get_state_ms = 1000;

	return 0;

}

static struct dmi_system_id ac_dmi_table[] = {

	{

	.callback = thinkpad_e530_quirk,

	.ident = "thinkpad e530",

	.matches = {

		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),

		DMI_MATCH(DMI_PRODUCT_NAME, "32597CG"),

		},

	},

	{},

};

static int acpi_ac_add(struct acpi_device *device)

{

	int result = 0;

		kfree(ac);

	}

	dmi_check_system(ac_dmi_table);

	return result;

}