summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-05-19 16:46:07 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-05-19 16:46:07 -0700
commit51509a283a908d73b20371addc67ee3ae7189934 (patch)
treebb920f09799cc47d496f26f7deb78a315351150d /Documentation
parent75f5076b12924f53340209d2cde73b98ed3b3095 (diff)
parent6538df80194e305f1b78cafb556f4bb442f808b3 (diff)
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6: (34 commits) PM: Introduce generic prepare and complete callbacks for subsystems PM: Allow drivers to allocate memory from .prepare() callbacks safely PM: Remove CONFIG_PM_VERBOSE Revert "PM / Hibernate: Reduce autotuned default image size" PM / Hibernate: Add sysfs knob to control size of memory for drivers PM / Wakeup: Remove useless synchronize_rcu() call kmod: always provide usermodehelper_disable() PM / ACPI: Remove acpi_sleep=s4_nonvs PM / Wakeup: Fix build warning related to the "wakeup" sysfs file PM: Print a warning if firmware is requested when tasks are frozen PM / Runtime: Rework runtime PM handling during driver removal Freezer: Use SMP barriers PM / Suspend: Do not ignore error codes returned by suspend_enter() PM: Fix build issue in clock_ops.c for CONFIG_PM_RUNTIME unset PM: Revert "driver core: platform_bus: allow runtime override of dev_pm_ops" OMAP1 / PM: Use generic clock manipulation routines for runtime PM PM: Remove sysdev suspend, resume and shutdown operations PM / PowerPC: Use struct syscore_ops instead of sysdevs for PM PM / UNICORE32: Use struct syscore_ops instead of sysdevs for PM PM / AVR32: Use struct syscore_ops instead of sysdevs for PM ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-power14
-rw-r--r--Documentation/feature-removal-schedule.txt8
-rw-r--r--Documentation/kernel-parameters.txt2
-rw-r--r--Documentation/power/devices.txt14
-rw-r--r--Documentation/power/notifiers.txt51
5 files changed, 47 insertions, 42 deletions
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 194ca446ac2..b464d12761b 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -158,3 +158,17 @@ Description:
successful, will make the kernel abort a subsequent transition
to a sleep state if any wakeup events are reported after the
write has returned.
+
+What: /sys/power/reserved_size
+Date: May 2011
+Contact: Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+ The /sys/power/reserved_size file allows user space to control
+ the amount of memory reserved for allocations made by device
+ drivers during the "device freeze" stage of hibernation. It can
+ be written a string representing a non-negative integer that
+ will be used as the amount of memory to reserve for allocations
+ made by device drivers' "freeze" callbacks, in bytes.
+
+ Reading from this file will display the current value, which is
+ set to 1 MB by default.
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 492e81df296..f6a24e8aa11 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -460,14 +460,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
----------------------------
-What: The acpi_sleep=s4_nonvs command line option
-When: 2.6.37
-Files: arch/x86/kernel/acpi/sleep.c
-Why: superseded by acpi_sleep=nonvs
-Who: Rafael J. Wysocki <rjw@sisk.pl>
-
-----------------------------
-
What: PCI DMA unmap state API
When: August 2012
Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index cc85a927819..259037b873b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -245,7 +245,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
acpi_sleep= [HW,ACPI] Sleep options
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
- old_ordering, s4_nonvs, sci_force_enable }
+ old_ordering, nonvs, sci_force_enable }
See Documentation/power/video.txt for information on
s3_bios and s3_mode.
s3_beep is for debugging; it makes the PC's speaker beep
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 1971bcf48a6..88880839ece 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -279,11 +279,15 @@ When the system goes into the standby or memory sleep state, the phases are:
time.) Unlike the other suspend-related phases, during the prepare
phase the device tree is traversed top-down.
- The prepare phase uses only a bus callback. After the callback method
- returns, no new children may be registered below the device. The method
- may also prepare the device or driver in some way for the upcoming
- system power transition, but it should not put the device into a
- low-power state.
+ In addition to that, if device drivers need to allocate additional
+ memory to be able to hadle device suspend correctly, that should be
+ done in the prepare phase.
+
+ After the prepare callback method returns, no new children may be
+ registered below the device. The method may also prepare the device or
+ driver in some way for the upcoming system power transition (for
+ example, by allocating additional memory required for this purpose), but
+ it should not put the device into a low-power state.
2. The suspend methods should quiesce the device to stop it from performing
I/O. They also may save the device registers and put it into the
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt
index cf980709122..c2a4a346c0d 100644
--- a/Documentation/power/notifiers.txt
+++ b/Documentation/power/notifiers.txt
@@ -1,46 +1,41 @@
Suspend notifiers
- (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
-
-There are some operations that device drivers may want to carry out in their
-.suspend() routines, but shouldn't, because they can cause the hibernation or
-suspend to fail. For example, a driver may want to allocate a substantial amount
-of memory (like 50 MB) in .suspend(), but that shouldn't be done after the
-swsusp's memory shrinker has run.
-
-Also, there may be some operations, that subsystems want to carry out before a
-hibernation/suspend or after a restore/resume, requiring the system to be fully
-functional, so the drivers' .suspend() and .resume() routines are not suitable
-for this purpose. For example, device drivers may want to upload firmware to
-their devices after a restore from a hibernation image, but they cannot do it by
-calling request_firmware() from their .resume() routines (user land processes
-are frozen at this point). The solution may be to load the firmware into
-memory before processes are frozen and upload it from there in the .resume()
-routine. Of course, a hibernation notifier may be used for this purpose.
-
-The subsystems that have such needs can register suspend notifiers that will be
-called upon the following events by the suspend core:
+ (C) 2007-2011 Rafael J. Wysocki <rjw@sisk.pl>, GPL
+
+There are some operations that subsystems or drivers may want to carry out
+before hibernation/suspend or after restore/resume, but they require the system
+to be fully functional, so the drivers' and subsystems' .suspend() and .resume()
+or even .prepare() and .complete() callbacks are not suitable for this purpose.
+For example, device drivers may want to upload firmware to their devices after
+resume/restore, but they cannot do it by calling request_firmware() from their
+.resume() or .complete() routines (user land processes are frozen at these
+points). The solution may be to load the firmware into memory before processes
+are frozen and upload it from there in the .resume() routine.
+A suspend/hibernation notifier may be used for this purpose.
+
+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_POST_HIBERNATION The system memory state has been restored from a
- hibernation image or an error occurred during the
- hibernation. Device drivers' .resume() callbacks have
+ hibernation image or an error occurred during
+ hibernation. Device drivers' restore callbacks have
been executed and tasks have been thawed.
PM_RESTORE_PREPARE The system is going to restore a hibernation image.
- If all goes well the restored kernel will issue a
+ If all goes well, the restored kernel will issue a
PM_POST_HIBERNATION notification.
-PM_POST_RESTORE An error occurred during the hibernation restore.
- Device drivers' .resume() callbacks have been executed
+PM_POST_RESTORE An error occurred during restore from hibernation.
+ Device drivers' restore callbacks have been executed
and tasks have been thawed.
-PM_SUSPEND_PREPARE The system is preparing for a suspend.
+PM_SUSPEND_PREPARE The system is preparing for suspend.
PM_POST_SUSPEND The system has just resumed or an error occurred during
- the suspend. Device drivers' .resume() callbacks have
- been executed and tasks have been thawed.
+ suspend. Device drivers' resume callbacks have been
+ executed and tasks have been thawed.
It is generally assumed that whatever the notifiers do for
PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION. Analogously,