This patch (as1361) changes the runtime PM interface slightly; it
allows suspend requests to be scheduled while the runtime_suspend
method is running.  If the method succeeds then the scheduled request
is cancelled, whereas if the method fails then an idle notification is
sent only if no request was scheduled.

Being able to schedule suspend requests from within a runtime_suspend
method is useful for drivers that need to test for idleness and
suspend the device all while holding a single spinlock, or for drivers
that want to check for idleness by polling.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The new-style dev_pm_ops provide callbacks for both IRQs enabled
and disabled. However, the _noirq variants were only called for
buses registered with a device, not for classes and types.

In order to properly use dev_pm_ops in class pcmcia_socket_class,
support _noirq actions also on classes and types.
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>

In the future, we are going to be changing the lock type for struct
device (once we get the lockdep infrastructure properly worked out)  To
make that changeover easier, and to possibly burry the lock in a
different part of struct device, let's create some functions to lock and
unlock a device so that no out-of-core code needs to be changed in the
future.

This patch creates the device_lock/unlock/trylock() functions, and
converts all in-tree users to them.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Magnus Damm <damm@igel.co.jp>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Alex Chiang <achiang@hp.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: CHENG Renquan <rqcheng@smu.edu.sg>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Frans Pop <elendil@planet.nl>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are subsystems whose power management callbacks only need to
invoke the callbacks provided by device drivers.  Still, their system
sleep PM callbacks should play well with the runtime PM callbacks,
so that devices suspended at run time can be left in that state for
a system sleep transition.

Provide a set of generic PM callbacks for such subsystems and
define convenience macros for populating dev_pm_ops structures.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

There are some dependencies between devices (in particular, between
EHCI USB controllers and their OHCI/UHCI siblings) which are not
reflected by the structure of the device tree.  With synchronous
suspend and resume these dependencies are taken into accout
automatically, because the devices in question are always registered
in the right order, but to meet these constraints with asynchronous
suspend and resume the drivers of these devices will need to use
dpm_wait() in their suspend/resume routines, so introduce a helper
function allowing them to do that.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

It has been shown by testing that total device resume time can be
reduced significantly (by as much as 50% or more) if the async
threads executing some devices' resume routines are all started
before the main resume thread starts to handle the "synchronous"
devices.

This is a consequence of the fact that the slowest devices tend to be
located at the end of dpm_list, so their resume routines are started
very late.  Consequently, they have to wait for all the preceding
"synchronous" devices before their resume routines can be started
by the main resume thread, even if they are "asynchronous".  By
starting their async threads upfront we effectively move those
devices towards the beginning of dpm_list, without breaking their
ordering with respect to their parents and children.  As a result,
their resume routines are started much earlier and we are able to
save much more device resume time this way.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Add configuration switch CONFIG_PM_ADVANCED_DEBUG for compiling in
extra PM debugging/testing code allowing one to access some
PM-related attributes of devices from the user space via sysfs.

If CONFIG_PM_ADVANCED_DEBUG is set, add sysfs attribute power/async
for every device allowing the user space to access the device's
power.async_suspend flag and modify it, if desired.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Add sysfs attribute /sys/power/pm_async allowing the user space to
disable/enable asynchronous suspend/resume of devices.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other.  However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself.  Analogously, we're not allowed to resume a device before
resuming its parent.

The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.

For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices).  For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.

The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
    for the device or, in the case of devices with the
    power.async_suspend flags unset, before executing the device's
    suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
    and device class suspend callbacks for the device, the PM core
    waits for the completions of all the device's children to be
    completed.
(4) During resume, right before running the bus type, device type and
    device class resume callbacks for the device, the PM core waits
    for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
    after the bus type, device type and device class suspend (or
    resume) callbacks executed for the device have returned.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Add parent information to the messages printed by the suspend/resume
core when initcall_debug is set.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Add new device sysfs attribute, power/control, allowing the user
space to block the run-time power management of the devices.  If this
attribute is set to "on", the driver of the device won't be able to power
manage it at run time (without breaking the rules) and the device will
always be in the full power state (except when the entire system goes
into a sleep state).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

Warning(drivers/base/power/main.c:453): No description found for parameter 'dev'
Warning(drivers/base/power/main.c:453): No description found for parameter 'cb'
Warning(drivers/base/power/main.c:719): No description found for parameter 'dev'
Warning(drivers/base/power/main.c:719): No description found for parameter 'state'
Warning(drivers/base/power/main.c:719): No description found for parameter 'cb'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The power management of some devices is handled through device types
and device classes rather than through bus types.  Since these
devices may also benefit from using the run-time power management
core, extend it so that the device type and device class run-time PM
callbacks can be taken into consideration by it if the bus type
callback is not defined.

Update the run-time PM core documentation to reflect this change.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch (as1317) fixes a bug in the PM core.  When a device is
resumed following a system sleep, the core decrements the device's
runtime PM usage counter but doesn't issue an idle notification if the
counter reaches 0.  This could prevent an otherwise unused device from
being runtime-suspended again after the system sleep.

The fix is to call pm_runtime_put_sync() instead of
pm_runtime_put_noidle().
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Measure and print the time of suspending and resuming all devices.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Commit f2511774
(PM: Add initcall_debug style timing for suspend/resume) introduced
basic timing instrumentation, needed for a scritps/bootgraph.pl
equivalent or humans, but it missed the fact that bus types and
device classes which haven't been switched to using struct dev_pm_ops
objects yet need special handling.  As a result, the suspend/resume
timing information is only available for devices whose bus types or
device classes use struct dev_pm_ops objects, so the majority of
devices is not covered.

Fix this by adding basic suspend/resume timing instrumentation for
devices whose bus types and device classes still don't use struct
dev_pm_ops objects for power management.  To reduce code duplication
move the timing code to helper functions.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

It is not necessary to include <linux/rwsem.h> into
drivers/base/power/main.c, so don't do that.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

In device_resume_noirq() there is the 'End' label and the associated
goto statement that aren't strictly necessary, so rework the code to
get rid of them.  Also modify device_suspend_noirq() so that it looks
completely analogous to device_resume_noirq().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

In order to diagnose overall suspend/resume times, we need
basic instrumentation to break down the total time into per
device timing, similar to initcall_debug.

This patch adds the basic timing instrumentation, needed
for a scritps/bootgraph.pl equivalent or humans.
The bootgraph.pl program is still a work in progress, but
is far enough along to know that this patch is sufficient.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch (as1308c) fixes __pm_runtime_get().  Currently the routine
will resume a device if the prior usage count was 0.  But this isn't
right; thanks to pm_runtime_get_noresume() the usage count can be
positive even while the device is suspended.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Some braces in __pm_runtime_set_status() are not necessary, so
remove them.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The runtime PM core code assumes that dev->power.timer_expires is
nonzero when the timer is scheduled, but it may become zero
incidentally in pm_schedule_suspend().  Prevent this from happening
by bumping dev->power.timer_expires up to 1 if it's 0 before calling
mod_timer().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NAlan Stern <stern@rowland.harvard.edu>

This patch (as1307) adds a small optimization to
__pm_request_resume().  If the device is currently being suspended,
there's no need to queue a work routine to resume it.  Setting the
deferred_resume flag will suffice.  (There's also a minor improvement
to the function's code layout: An unnecessary "else" is removed.)

Also, the patch clarifies the usage of the deferred_resume flag.  It
is meaningful only while a suspend is in progress, so it should be
cleared just before a suspend starts, not just after one ends.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Lockdep complains about taking the parent lock in
__pm_runtime_set_status(), so mark it as nested.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org

This patch (as1305) fixes a bug in the irq-enable settings and removes
some related overhead in the runtime PM code.

	In __pm_runtime_resume(), within the scope of the original
	spin_lock_irq(), we know that irqs are disabled.  There's no
	reason to go through a pair of enable/disable cycles when
	acquiring and releasing the parent's lock.

	In __pm_runtime_set_status(), irqs are already disabled when
	the parent's lock is acquired, and they must remain disabled
	when it is released.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

pm_runtime_idle() is somewhat noisy. Remove debug prints.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Fixes the point where we need to complete the power transition when
device suspend fails, so that we don't print warnings about devices
added to the device hierarchy after a failing suspend.

[rjw: Modified changelog.]
Signed-off-by: NRomit Dasgupta <romit@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

transition_started should be set once the preparation of devices for
a PM has started, reset before starting to resume devices. When
resuming devices, kernel calls dpm_resume_noirq then
dpm_resume_end(dpm_resume).  Thus we should reset transition_started
at dpm_resume_noirq.

This patch fixes ACPI warning when resuming from suspend/hibernate:

ACPI: \_SB_.PCI0.IDE1.PRI1.MAS1 - docking
------------[ cut here ]------------
WARNING: at drivers/base/power/main.c:87 device_pm_add+0x8b/0xcc()
Hardware name: OptiPlex 760
Device: acpi
Parentless device registered during a PM transaction

[rjw: Fixed up the changelog.]
Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The kerneldoc comments in drivers/base/power/main.c are generally
outdated and some of them don't describe the functions very
accurately.  Update them and standardize the format to use spaces
instead of tabs.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

Introduce a core framework for run-time power management of I/O
devices.  Add device run-time PM fields to 'struct dev_pm_info'
and device run-time PM callbacks to 'struct dev_pm_ops'.  Introduce
a run-time PM workqueue and define some device run-time PM helper
functions at the core level.  Document all these things.

Special thanks to Alan Stern for his help with the design and
multiple detailed reviews of the pereceding versions of this patch
and to Magnus Damm for testing feedback.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NMagnus Damm <damm@igel.co.jp>

They are not supposed to be modified by drivers, so make them const.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

They are not supposed to be modified by drivers, so make them const.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

When the last device in the dpm list is unregistered directly after its
prepare() callback returned with -EAGAIN, the return code is passed to
the calling function, resulting in a suspend failure. Prevent this by
clearing the return code after -EAGAIN.
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch removes the legacy callbacks ->suspend() and
->resume() from struct device_type. These callbacks seem
unused, and new code should instead make use of struct
dev_pm_ops.
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Remove the ->suspend_late() and ->resume_early() callbacks
from struct bus_type V2. These callbacks are legacy stuff
at this point and since there seem to be no in-tree users
we may as well remove them. New users should use dev_pm_ops.
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Acked-by: NPavel Machek <pavel@ucw.cz>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch (as1241) renames a bunch of functions in the PM core.
Rather than go through a boring list of name changes, suffice it to
say that in the end we have a bunch of pairs of functions:

	device_resume_noirq	dpm_resume_noirq
	device_resume		dpm_resume
	device_complete		dpm_complete
	device_suspend_noirq	dpm_suspend_noirq
	device_suspend		dpm_suspend
	device_prepare		dpm_prepare

in which device_X does the X operation on a single device and dpm_X
invokes device_X for all devices in the dpm_list.

In addition, the old dpm_power_up and device_resume_noirq have been
combined into a single function (dpm_resume_noirq).

Lastly, dpm_suspend_start and dpm_resume_end are the renamed versions
of the former top-level device_suspend and device_resume routines.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NMagnus Damm <damm@igel.co.jp>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Rename the functions performing "_noirq" dev_pm_ops
operations from device_power_down() and device_power_up()
to device_suspend_noirq() and device_resume_noirq().

The new function names are chosen to show that the functions
are responsible for calling the _noirq() versions to finalize
the suspend/resume operation. The current function names do
not perform power down/up anymore so the names may be misleading.

Global function renames:
- device_power_down() -> device_suspend_noirq()
- device_power_up() -> device_resume_noirq()

Static function renames:
- suspend_device_noirq() -> __device_suspend_noirq()
- resume_device_noirq() -> __device_resume_noirq()
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: NLen Brown <lenb@kernel.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

We shouldn't hold dpm_list_mtx while executing
[disable|enable]_nonboot_cpus(), because theoretically this may lead
to a deadlock as shown by the following example (provided by Johannes
Berg):

CPU 3       CPU 2                     CPU 1
                                      suspend/hibernate
            something:
            rtnl_lock()               device_pm_lock()
                                       -> mutex_lock(&dpm_list_mtx)

            mutex_lock(&dpm_list_mtx)

linkwatch_work
 -> rtnl_lock()
                                      disable_nonboot_cpus()
                                       -> flush CPU 3 workqueue

Fortunately, device drivers are supposed to stop any activities that
might lead to the registration of new device objects way before
disable_nonboot_cpus() is called, so it shouldn't be necessary to
hold dpm_list_mtx over the entire late part of device suspend and
early part of device resume.

Thus, during the late suspend and the early resume of devices acquire
dpm_list_mtx only when dpm_list is going to be traversed and release
it right after that.

This patch is reported to fix the regressions tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=13245.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NMiles Lane <miles.lane@gmail.com>
Tested-by: NMing Lei <tom.leiming@gmail.com>

Use the functions introduced in by the previous patch,
suspend_device_irqs(), resume_device_irqs() and check_wakeup_irqs(),
to rework the handling of interrupts during suspend (hibernation) and
resume.  Namely, interrupts will only be disabled on the CPU right
before suspending sysdevs, while device drivers will be prevented
from receiving interrupts, with the help of the new helper function,
before their "late" suspend callbacks run (and analogously during
resume).

In addition, since the device interrups are now disabled before the
CPU has turned all interrupts off and the CPU will ACK the interrupts
setting the IRQ_PENDING bit for them, check in sysdev_suspend() if
any wake-up interrupts are pending and abort suspend if that's the
case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NIngo Molnar <mingo@elte.hu>

dpm_list currently relies on the fact that child devices will
be registered after their parents to get a correct suspend
order. Using device_move() however destroys this assumption, as
an already registered device may be moved under a newly registered
one.

This patch adds a new argument to device_move(), allowing callers
to specify how dpm_list should be adapted.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>