Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6

		"disabled" to it.

		For the devices that are not capable of generating system wakeup

		events this file contains "\n".  In that cases the user space

		cannot modify the contents of this file and the device cannot be

		enabled to wake up the system.

		events this file is not present.  In that case the device cannot

		be enabled to wake up the system from sleep states.

What:		/sys/devices/.../power/control

Date:		January 2009

		The /sys/devices/.../wakeup_count attribute contains the number

		of signaled wakeup events associated with the device.  This

		attribute is read-only.  If the device is not enabled to wake up

		the system from sleep states, this attribute is empty.

		the system from sleep states, this attribute is not present.

What:		/sys/devices/.../power/wakeup_active_count

Date:		September 2010

		number of times the processing of wakeup events associated with

		the device was completed (at the kernel level).  This attribute

		is read-only.  If the device is not enabled to wake up the

		system from sleep states, this attribute is empty.

		system from sleep states, this attribute is not present.

What:		/sys/devices/.../power/wakeup_hit_count

Date:		September 2010

		number of times the processing of a wakeup event associated with

		the device might prevent the system from entering a sleep state.

		This attribute is read-only.  If the device is not enabled to

		wake up the system from sleep states, this attribute is empty.

		wake up the system from sleep states, this attribute is not

		present.

What:		/sys/devices/.../power/wakeup_active

Date:		September 2010

		or 0, depending on whether or not a wakeup event associated with

		the device is being processed (1).  This attribute is read-only.

		If the device is not enabled to wake up the system from sleep

		states, this attribute is empty.

		states, this attribute is not present.

What:		/sys/devices/.../power/wakeup_total_time_ms

Date:		September 2010

		the total time of processing wakeup events associated with the

		device, in milliseconds.  This attribute is read-only.  If the

		device is not enabled to wake up the system from sleep states,

		this attribute is empty.

		this attribute is not present.

What:		/sys/devices/.../power/wakeup_max_time_ms

Date:		September 2010

		the maximum time of processing a single wakeup event associated

		with the device, in milliseconds.  This attribute is read-only.

		If the device is not enabled to wake up the system from sleep

		states, this attribute is empty.

		states, this attribute is not present.

What:		/sys/devices/.../power/wakeup_last_time_ms

Date:		September 2010

		signaling the last wakeup event associated with the device, in

		milliseconds.  This attribute is read-only.  If the device is

		not enabled to wake up the system from sleep states, this

		attribute is empty.

		attribute is not present.

What:		/sys/devices/.../power/autosuspend_delay_ms

Date:		September 2010

Device Power Management

Copyright (c) 2010 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.

Copyright (c) 2010-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.

Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu>

whether or not a wakeup-capable device should issue wakeup events is a policy

decision, and it is managed by user space through a sysfs attribute: the

power/wakeup file.  User space can write the strings "enabled" or "disabled" to

set or clear the should_wakeup flag, respectively.  Reads from the file will

return the corresponding string if can_wakeup is true, but if can_wakeup is

false then reads will return an empty string, to indicate that the device

doesn't support wakeup events.  (But even though the file appears empty, writes

will still affect the should_wakeup flag.)

set or clear the "should_wakeup" flag, respectively.  This file is only present

for wakeup-capable devices (i.e. devices whose "can_wakeup" flags are set)

and is created (or removed) by device_set_wakeup_capable().  Reads from the

file will return the corresponding string.

The device_may_wakeup() routine returns true only if both flags are set.

Drivers should check this routine when putting devices in a low-power state

during a system sleep transition, to see whether or not to enable the devices'

wakeup mechanisms.  However for runtime power management, wakeup events should

be enabled whenever the device and driver both support them, regardless of the

should_wakeup flag.

This information is used by subsystems, like the PCI bus type code, to see

whether or not to enable the devices' wakeup mechanisms.  If device wakeup

mechanisms are enabled or disabled directly by drivers, they also should use

device_may_wakeup() to decide what to do during a system sleep transition.

However for runtime power management, wakeup events should be enabled whenever

the device and driver both support them, regardless of the should_wakeup flag.

/sys/devices/.../power/control files

unfrozen.  Furthermore, the *_noirq phases run at a time when IRQ handlers have

been disabled (except for those marked with the IRQ_WAKEUP flag).

Most phases use bus, type, and class callbacks (that is, methods defined in

dev->bus->pm, dev->type->pm, and dev->class->pm).  The prepare and complete

phases are exceptions; they use only bus callbacks.  When multiple callbacks

are used in a phase, they are invoked in the order: <class, type, bus> during

power-down transitions and in the opposite order during power-up transitions.

For example, during the suspend phase the PM core invokes

	dev->class->pm.suspend(dev);

	dev->type->pm.suspend(dev);

	dev->bus->pm.suspend(dev);

before moving on to the next device, whereas during the resume phase the core

invokes

	dev->bus->pm.resume(dev);

	dev->type->pm.resume(dev);

	dev->class->pm.resume(dev);

All phases use bus, type, or class callbacks (that is, methods defined in

dev->bus->pm, dev->type->pm, or dev->class->pm).  These callbacks are mutually

exclusive, so if the device type provides a struct dev_pm_ops object pointed to

by its pm field (i.e. both dev->type and dev->type->pm are defined), the

callbacks included in that object (i.e. dev->type->pm) will be used.  Otherwise,

if the class provides a struct dev_pm_ops object pointed to by its pm field

(i.e. both dev->class and dev->class->pm are defined), the PM core will use the

callbacks from that object (i.e. dev->class->pm).  Finally, if the pm fields of

both the device type and class objects are NULL (or those objects do not exist),

the callbacks provided by the bus (that is, the callbacks from dev->bus->pm)

will be used (this allows device types to override callbacks provided by bus

types or classes if necessary).

These callbacks may in turn invoke device- or driver-specific methods stored in

dev->driver->pm, but they don't have to.

situation where it actually matters.

Device Power Domains

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

Sometimes devices share reference clocks or other power resources.  In those

cases it generally is not possible to put devices into low-power states

individually.  Instead, a set of devices sharing a power resource can be put

into a low-power state together at the same time by turning off the shared

power resource.  Of course, they also need to be put into the full-power state

together, by turning the shared power resource on.  A set of devices with this

property is often referred to as a power domain.

Support for power domains is provided through the pwr_domain field of struct

device.  This field is a pointer to an object of type struct dev_power_domain,

defined in include/linux/pm.h, providing a set of power management callbacks

analogous to the subsystem-level and device driver callbacks that are executed

for the given device during all power transitions, in addition to the respective

subsystem-level callbacks.  Specifically, the power domain "suspend" callbacks

(i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are

executed after the analogous subsystem-level callbacks, while the power domain

"resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore,

etc.) are executed before the analogous subsystem-level callbacks.  Error codes

returned by the "suspend" and "resume" power domain callbacks are ignored.

Power domain ->runtime_idle() callback is executed before the subsystem-level

->runtime_idle() callback and the result returned by it is not ignored.  Namely,

if it returns error code, the subsystem-level ->runtime_idle() callback will not

be called and the helper function rpm_idle() executing it will return error

code.  This mechanism is intended to help platforms where saving device state

is a time consuming operation and should only be carried out if all devices

in the power domain are idle, before turning off the shared power resource(s).

Namely, the power domain ->runtime_idle() callback may return error code until

the pm_runtime_idle() helper (or its asychronous version) has been called for

all devices in the power domain (it is recommended that the returned error code

be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle()

callback from being run prematurely.

The support for device power domains is only relevant to platforms needing to

use the same subsystem-level (e.g. platform bus type) and device driver power

management callbacks in many different power domain configurations and wanting

to avoid incorporating the support for power domains into the subsystem-level

callbacks.  The other platforms need not implement it or take it into account

in any way.

System Devices

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

System devices (sysdevs) follow a slightly different API, which can be found in

Run-time Power Management Framework for I/O Devices

(C) 2009 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.

(C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.

(C) 2010 Alan Stern <stern@rowland.harvard.edu>

1. Introduction

};

The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are

executed by the PM core for either the bus type, or device type (if the bus

type's callback is not defined), or device class (if the bus type's and device

type's callbacks are not defined) of given device.  The bus type, device type

and device class callbacks are referred to as subsystem-level callbacks in what

follows.

executed by the PM core for either the device type, or the class (if the device

type's struct dev_pm_ops object does not exist), or the bus type (if the

device type's and class' struct dev_pm_ops objects do not exist) of the given

device (this allows device types to override callbacks provided by bus types or

classes if necessary).  The bus type, device type and class callbacks are

referred to as subsystem-level callbacks in what follows.

By default, the callbacks are always invoked in process context with interrupts

enabled.  However, subsystems can use the pm_runtime_irq_safe() helper function

inconvenience, this method requires minimal work by the kernel, since

the firmware will also handle restoring memory contents on resume. 

For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap

Suspend) is used to write memory contents to free swap space.

swsusp has some restrictive requirements, but should work in most

cases. Some, albeit outdated, documentation can be found in

Documentation/power/swsusp.txt. Alternatively, userspace can do most

of the actual suspend to disk work, see userland-swsusp.txt.

For suspend-to-disk, a mechanism called 'swsusp' (Swap Suspend) is used

to write memory contents to free swap space. swsusp has some restrictive

requirements, but should work in most cases. Some, albeit outdated,

documentation can be found in Documentation/power/swsusp.txt.

Alternatively, userspace can do most of the actual suspend to disk work,

see userland-swsusp.txt.

Once memory state is written to disk, the system may either enter a

low-power state (like ACPI S4), or it may simply power down. Powering

#include <linux/suspend.h>

#include <linux/kthread.h>

#include <linux/jiffies.h>

#include <linux/acpi.h>

#include <asm/system.h>

#include <asm/uaccess.h>

		apm_info.disabled = 1;

		return -ENODEV;

	}

	if (pm_flags & PM_ACPI) {

	if (!acpi_disabled) {

		printk(KERN_NOTICE "apm: overridden by ACPI.\n");

		apm_info.disabled = 1;

		return -ENODEV;

	}

	pm_flags |= PM_APM;

	/*

	 * Set up the long jump entry point to the APM BIOS, which is called

		kthread_stop(kapmd_task);

		kapmd_task = NULL;

	}

	pm_flags &= ~PM_APM;

}

module_init(apm_init);