19 Jul, 2010
2 commits
-
In order for PowerTOP to be able to report how well the new runtime PM is
working for the various drivers, the kernel needs to export some basic
statistics in sysfs.This patch adds two sysfs files in the runtime PM domain that expose the
total time a device has been active, and the time a device has been
suspended.With this PowerTOP can compute the activity percentage
Active %age = 100 * (delta active) / (delta active + delta suspended)
and present the information to the user.
I've written the PowerTOP code (slated for version 1.12) already, and the
output looks like this:Runtime Device Power Management statistics
Active Device name
10.0% 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller[version 2: fix stat update bugs noticed by Alan Stern]
[version 3: rebase to -next and move the sysfs declaration]Signed-off-by: Arjan van de Ven
Signed-off-by: Rafael J. Wysocki -
One of the arguments during the suspend blockers discussion was that
the mainline kernel didn't contain any mechanisms making it possible
to avoid races between wakeup and system suspend.Generally, there are two problems in that area. First, if a wakeup
event occurs exactly when /sys/power/state is being written to, it
may be delivered to user space right before the freezer kicks in, so
the user space consumer of the event may not be able to process it
before the system is suspended. Second, if a wakeup event occurs
after user space has been frozen, it is not generally guaranteed that
the ongoing transition of the system into a sleep state will be
aborted.To address these issues introduce a new global sysfs attribute,
/sys/power/wakeup_count, associated with a running counter of wakeup
events and three helper functions, pm_stay_awake(), pm_relax(), and
pm_wakeup_event(), that may be used by kernel subsystems to control
the behavior of this attribute and to request the PM core to abort
system transitions into a sleep state already in progress.The /sys/power/wakeup_count file may be read from or written to by
user space. Reads will always succeed (unless interrupted by a
signal) and return the current value of the wakeup events counter.
Writes, however, will only succeed if the written number is equal to
the current value of the wakeup events counter. If a write is
successful, it will cause the kernel to save the current value of the
wakeup events counter and to abort the subsequent system transition
into a sleep state if any wakeup events are reported after the write
has returned.[The assumption is that before writing to /sys/power/state user space
will first read from /sys/power/wakeup_count. Next, user space
consumers of wakeup events will have a chance to acknowledge or
veto the upcoming system transition to a sleep state. Finally, if
the transition is allowed to proceed, /sys/power/wakeup_count will
be written to and if that succeeds, /sys/power/state will be written
to as well. Still, if any wakeup events are reported to the PM core
by kernel subsystems after that point, the transition will be
aborted.]Additionally, put a wakeup events counter into struct dev_pm_info and
make these per-device wakeup event counters available via sysfs,
so that it's possible to check the activity of various wakeup event
sources within the kernel.To illustrate how subsystems can use pm_wakeup_event(), make the
low-level PCI runtime PM wakeup-handling code use it.Signed-off-by: Rafael J. Wysocki
Acked-by: Jesse Barnes
Acked-by: Greg Kroah-Hartman
Acked-by: markgross
Reviewed-by: Alan Stern
07 Mar, 2010
1 commit
-
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: Rafael J. Wysocki
27 Feb, 2010
3 commits
-
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: Rafael J. Wysocki
-
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: Rafael J. Wysocki
-
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: Rafael J. Wysocki
Acked-by: Alan Stern
16 Dec, 2009
1 commit
-
Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Dec, 2009
1 commit
-
Apparently, there are devices that can wake up the system from sleep
states and yet are incapable of generating wake-up events at run
time. Thus, introduce a flag indicating if given device is capable
of generating run-time wake-up events.Signed-off-by: Rafael J. Wysocki
15 Sep, 2009
1 commit
-
In a number of cases, the .suspend, .freeze, .poweroff and .resume,
.thaw, .restore functions are identical. However, they all need to be
assigned to avoid regressionsm as the previous code called .suspend
resp. .resume in all those cases. SIMPLE_DEV_PM_OPS helps to deal
with this case.[rjw: Changed the name of the macro and added the comment explaining its
purpose.]Signed-off-by: Albin Tonnerre
Signed-off-by: Rafael J. Wysocki
23 Aug, 2009
1 commit
-
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: Rafael J. Wysocki
Acked-by: Magnus Damm
13 Jun, 2009
2 commits
-
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_preparein 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: Alan Stern
Acked-by: Magnus Damm
Signed-off-by: Rafael J. Wysocki -
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: Magnus Damm
Acked-by: Greg Kroah-Hartman
Acked-by: Len Brown
Signed-off-by: Rafael J. Wysocki
25 Mar, 2009
1 commit
-
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: Cornelia Huck
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
23 Feb, 2009
1 commit
-
Move the sysdev_suspend/resume from the callee to the callers, with
no real change in semantics, so that we can rework the disabling of
interrupts during suspend/hibernation.This is based on an earlier patch from Linus.
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Linus Torvalds
07 Jan, 2009
2 commits
-
This patch (as1167) fixes some misspellings in various recently-added
macros in pm.h. Fortunately these macros are not yet used anywhere.Signed-off-by: Alan Stern
Acked-by: Rafael J. Wysocki -
PM: Simplify the new suspend/hibernation framework for devices
Following the discussion at the Kernel Summit, simplify the new
device PM framework by merging 'struct pm_ops' and
'struct pm_ext_ops' and removing pointers to 'struct pm_ext_ops'
from 'struct platform_driver' and 'struct pci_driver'.After this change, the suspend/hibernation callbacks will only
reside in 'struct device_driver' as well as at the bus type/
device class/device type level. Accordingly, PCI and platform
device drivers are now expected to put their suspend/hibernation
callbacks into the 'struct device_driver' embedded in
'struct pci_driver' or 'struct platform_driver', respectively.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Cc: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman
17 Oct, 2008
1 commit
-
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jul, 2008
4 commits
-
This patch (as1112) adds some new PM_EVENT_* codes for use by kernel
subsystems. They describe runtime power-state transitions of the sort already
implemented by the USB subsystem.Signed-off-by: Alan Stern
Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Drop unnecessary includes from include/linux/pm.h .
Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Remove the remaining obsolete definitions from include/linux/pm.h and move
the definitions of PM_SUSPEND and PM_RESUME to the header of h3600 which
is the only user of them.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Remove the definition of 'struct pm_dev', which is not used any more,
along with some related stuff from include/linux/pm.h .Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jun, 2008
1 commit
-
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes
30 Apr, 2008
1 commit
-
Remove the "#ifdef __KERNEL__" tests from unexported header files in
linux/include whose entire contents are wrapped in that preprocessor
test.Signed-off-by: Robert P. J. Day
Cc: David Woodhouse
Cc: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Apr, 2008
3 commits
-
This patch (as1058) improves the wakeup macros in include/linux/pm.h.
All but the trivial ones are converted to inline routines, which
requires moving them to a separate header file since they depend on
the definition of struct device.Signed-off-by: Alan Stern
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
The various wakeup flags and their accessor macros in struct
dev_pm_info should be available whenever CONFIG_PM is enabled, not
just when CONFIG_PM_SLEEP is on. Otherwise remote wakeup won't always
be configurable for runtime power management. This patch (as1056b)
fixes the oversight.David Brownell adds:
More accurately, fixes the "regression" ... as noted sometime
last summer, after 296699de6bdc717189a331ab6bbe90e05c94db06
introduced CONFIG_SUSPEND. But that didn't make the regression
list for that kernel, ergo the delay in fixing it.[rjw: rebased]
Signed-off-by: Alan Stern
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
Modify the PM core to protect its data structures, specifically the
dpm_active list, from being corrupted if a child of the currently
suspending device is registered concurrently with its ->suspend()
callback. In that case, since the new device (the child) is added
to dpm_active after its parent, the PM core will attempt to
suspend it after the parent, which is wrong.Introduce a new member of struct dev_pm_info, called 'sleeping',
and use it to check if the parent of the device being added to
dpm_active has been suspended, in which case the device registration
fails. Also, use 'sleeping' for checking if the ordering of devices
on dpm_active is correct.Introduce variable 'all_sleeping' that will be set to 'true' once all
devices have been suspended and make new device registrations fail
until 'all_sleeping' is reset to 'false', in order to avoid having
unsuspended devices around while the system is going into a sleep state.Remove pm_sleep_rwsem which is not necessary any more.
Special thanks to Alan Stern for discussions and suggestions that
lead to the creation of this patch.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2008
1 commit
-
During the last step of hibernation in the "platform" mode (with the
help of ACPI) we use the suspend code, including the devices'
->suspend() methods, to prepare the system for entering the ACPI S4
system sleep state.But at least for some devices the operations performed by the
->suspend() callback in that case must be different from its operations
during regular suspend.For this reason, introduce the new PM event type PM_EVENT_HIBERNATE and
pass it to the device drivers' ->suspend() methods during the last phase
of hibernation, so that they can distinguish this case and handle it as
appropriate. Modify the drivers that handle PM_EVENT_SUSPEND in a
special way and need to handle PM_EVENT_HIBERNATE in the same way.These changes are necessary to fix a hibernation regression related
to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488).Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Tested-by: Jeff Chua
Signed-off-by: Linus Torvalds
03 Feb, 2008
1 commit
-
Signed-off-by: Joe Perches
Signed-off-by: Adrian Bunk
12 Jan, 2008
1 commit
-
ACPI and APM used "pm_active" to guarantee that
they would not be simultaneously active.But pm_active was recently moved under CONFIG_PM_LEGACY,
so that without CONFIG_PM_LEGACY, pm_active became a NOP --
allowing ACPI and APM to both be simultaneously enabled.
This caused unpredictable results, including boot hangs.Further, the code under CONFIG_PM_LEGACY is scheduled
for removal.So replace pm_active with pm_flags.
pm_flags depends only on CONFIG_PM,
which is present for both CONFIG_APM and CONFIG_ACPI.http://bugzilla.kernel.org/show_bug.cgi?id=9194
Signed-off-by: Len Brown
Signed-off-by: Rafael J. Wysocki
19 Oct, 2007
1 commit
-
Move the definition of 'struct pm_ops' and related functions from
to .There are, at least, the following reasons to do that:
* 'struct pm_ops' is specifically related to suspend and not to the power
management in general.
* As long as 'struct pm_ops' is defined in , any modification of it
causes the entire kernel to be recompiled, which is unnecessary and annoying.
* Some suspend-related features are already defined in , so it
is logical to move the definition of 'struct pm_ops' into there.
* 'struct hibernation_ops', being the hibernation-related counterpart of
'struct pm_ops', is defined in .Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Cc: Len Brown
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Jul, 2007
1 commit
-
While I was busy compile-testing my patch, ENOSYS sneaked into pm.h
leading to some compile-breakages mostly on ia64 and some mips configs.Signed-off-by: Alexey Dobriyan
Signed-off-by: Linus Torvalds
30 Jul, 2007
1 commit
-
Introduce CONFIG_SUSPEND representing the ability to enter system sleep
states, such as the ACPI S3 state, and allow the user to choose SUSPEND
and HIBERNATION independently of each other.Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has
been chosen and the kernel is intended for SMP systems.Also, introduce CONFIG_PM_SLEEP which is automatically selected if
CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the
code needed for both suspend and hibernation.The top-level power management headers and the ACPI code related to
suspend and hibernation are modified to use the new definitions (the
changes in drivers/acpi/sleep/main.c are, mostly, moving code to reduce
the number of ifdefs).There are many other files in which CONFIG_PM can be replaced with
CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in
the future.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Linus Torvalds
20 Jul, 2007
1 commit
-
Introduce the pm_power_off_prepare() callback that can be registered by the
interested platforms in analogy with pm_idle() and pm_power_off(), used for
preparing the system to power off (needed by ACPI).This allows us to drop acpi_sysclass and device_acpi that are only defined in
order to register the ACPI power off preparation callback, which is needed by
pm_power_off() registered in a much different way.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
19 Jul, 2007
1 commit
-
This patch (as933) removes the deprecated dpm_runtime_suspend() and
dpm_runtime_resume() routines from the PM core. The only user of
those routines is the PCMCIA ds driver; local replacements are added.Signed-off-by: Alan Stern
CC: Dominik Brodowski
Signed-off-by: Greg Kroah-Hartman
12 Jul, 2007
3 commits
-
The prev_state member of struct dev_pm_info (defined in include/linux/pm.h) is
only used during a resume to check if the device's state before the suspend was
'off', in which case the device is not resumed. However, in such cases the
decision whether or not to resume the device should be made on the driver level
and the resume callbacks from the device's bus and class should be executed
anyway (the may be needed for some things other than just powering on the
device).Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
The saved_state member of struct dev_pm_info, defined in include/linux/pm.h, is
not used anywhere, so it can be removed.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as well
with the help of the parent pointer in struct device, so pm_parent can be
removed along with some code that handles it.Signed-off-by: Rafael J. Wysocki
Acked-by: David Brownell
Signed-off-by: Greg Kroah-Hartman
02 Jul, 2007
1 commit
-
Commit 52ade9b3b97fd3bea42842a056fe0786c28d0555 changed the suspend code
ordering to execute pm_ops->prepare() after the device model per-device
.suspend() calls in order to fix some ACPI-related issues. Unfortunately, it
broke the at91 platform which assumed that pm_ops->prepare() would be called
before suspending devices.at91 used pm_ops->prepare() to get notified of the target system sleep state,
so that it could use this information while suspending devices. However, with
the current suspend code ordering pm_ops->prepare() is called too late for
this purpose. Thus, at91 needs an additional method in 'struct pm_ops' that
will be used for notifying the platform of the target system sleep state.
Moreover, in the future such a method will also be needed by ACPI.This patch adds the .set_target() method to 'struct pm_ops' and makes the
suspend code call it, if implemented, before executing the device model
per-device .suspend() calls. It also modifies the at91 code to use
pm_ops->set_target() instead of pm_ops->prepare().Signed-off-by: Rafael J. Wysocki
Acked-by: David Brownell
Cc: Pavel Machek
Cc: Johannes Berg
Cc: Len Brown
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 May, 2007
1 commit
-
[ With Johannes Berg ]
Separate the hibernation (aka suspend to disk code) from the other suspend
code. In particular:* Remove the definitions related to hibernation from include/linux/pm.h
* Introduce struct hibernation_ops and a new hibernate() function to hibernate
the system, defined in include/linux/suspend.h
* Separate suspend code in kernel/power/main.c from hibernation-related code
in kernel/power/disk.c and kernel/power/user.c (with the help of
hibernation_ops)
* Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_opsSigned-off-by: Rafael J. Wysocki
Cc: Greg KH
Cc: Pavel Machek
Cc: Nigel Cunningham
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 May, 2007
1 commit
-
For backwards compatibility, call_platform_enable_wakeup() can return 0
instead of -EIO since we aren't guaranteed to have errno defined.Cc: David Brownell
Signed-off-by: David Rientjes
Cc: "Randy.Dunlap"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
