diff options
author | Mauro Carvalho Chehab <mchehab+samsung@kernel.org> | 2019-06-13 07:10:36 -0300 |
---|---|---|
committer | Bjorn Helgaas <bhelgaas@google.com> | 2019-06-14 16:08:36 -0500 |
commit | 151f4e2bdc7a04020ae5c533896fb91a16e1f501 (patch) | |
tree | 20c8504f4fea46bf421107074f511fd51acf44fc /Documentation/power | |
parent | 9595aee2a389be5dfa9a0121a14e8fba70f17278 (diff) |
docs: power: convert docs to ReST and rename to *.rst
Convert the PM documents to ReST, in order to allow them to
build with Sphinx.
The conversion is actually:
- add blank lines and indentation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
Diffstat (limited to 'Documentation/power')
-rw-r--r-- | Documentation/power/apm-acpi.rst (renamed from Documentation/power/apm-acpi.txt) | 10 | ||||
-rw-r--r-- | Documentation/power/basic-pm-debugging.rst (renamed from Documentation/power/basic-pm-debugging.txt) | 79 | ||||
-rw-r--r-- | Documentation/power/charger-manager.rst (renamed from Documentation/power/charger-manager.txt) | 105 | ||||
-rw-r--r-- | Documentation/power/drivers-testing.rst (renamed from Documentation/power/drivers-testing.txt) | 15 | ||||
-rw-r--r-- | Documentation/power/energy-model.rst (renamed from Documentation/power/energy-model.txt) | 105 | ||||
-rw-r--r-- | Documentation/power/freezing-of-tasks.rst (renamed from Documentation/power/freezing-of-tasks.txt) | 91 | ||||
-rw-r--r-- | Documentation/power/index.rst | 46 | ||||
-rw-r--r-- | Documentation/power/interface.rst (renamed from Documentation/power/interface.txt) | 24 | ||||
-rw-r--r-- | Documentation/power/opp.rst (renamed from Documentation/power/opp.txt) | 175 | ||||
-rw-r--r-- | Documentation/power/pci.rst (renamed from Documentation/power/pci.txt) | 87 | ||||
-rw-r--r-- | Documentation/power/pm_qos_interface.rst (renamed from Documentation/power/pm_qos_interface.txt) | 127 | ||||
-rw-r--r-- | Documentation/power/power_supply_class.rst | 282 | ||||
-rw-r--r-- | Documentation/power/power_supply_class.txt | 231 | ||||
-rw-r--r-- | Documentation/power/powercap/powercap.rst | 257 | ||||
-rw-r--r-- | Documentation/power/powercap/powercap.txt | 236 | ||||
-rw-r--r-- | Documentation/power/regulator/consumer.rst (renamed from Documentation/power/regulator/consumer.txt) | 141 | ||||
-rw-r--r-- | Documentation/power/regulator/design.rst (renamed from Documentation/power/regulator/design.txt) | 9 | ||||
-rw-r--r-- | Documentation/power/regulator/machine.rst (renamed from Documentation/power/regulator/machine.txt) | 47 | ||||
-rw-r--r-- | Documentation/power/regulator/overview.rst (renamed from Documentation/power/regulator/overview.txt) | 57 | ||||
-rw-r--r-- | Documentation/power/regulator/regulator.rst | 32 | ||||
-rw-r--r-- | Documentation/power/regulator/regulator.txt | 30 | ||||
-rw-r--r-- | Documentation/power/runtime_pm.rst (renamed from Documentation/power/runtime_pm.txt) | 234 | ||||
-rw-r--r-- | Documentation/power/s2ram.rst (renamed from Documentation/power/s2ram.txt) | 20 | ||||
-rw-r--r-- | Documentation/power/suspend-and-cpuhotplug.rst (renamed from Documentation/power/suspend-and-cpuhotplug.txt) | 42 | ||||
-rw-r--r-- | Documentation/power/suspend-and-interrupts.rst (renamed from Documentation/power/suspend-and-interrupts.txt) | 2 | ||||
-rw-r--r-- | Documentation/power/swsusp-and-swap-files.rst (renamed from Documentation/power/swsusp-and-swap-files.txt) | 17 | ||||
-rw-r--r-- | Documentation/power/swsusp-dmcrypt.rst (renamed from Documentation/power/swsusp-dmcrypt.txt) | 122 | ||||
-rw-r--r-- | Documentation/power/swsusp.rst | 501 | ||||
-rw-r--r-- | Documentation/power/swsusp.txt | 446 | ||||
-rw-r--r-- | Documentation/power/tricks.rst (renamed from Documentation/power/tricks.txt) | 6 | ||||
-rw-r--r-- | Documentation/power/userland-swsusp.rst (renamed from Documentation/power/userland-swsusp.txt) | 55 | ||||
-rw-r--r-- | Documentation/power/video.rst (renamed from Documentation/power/video.txt) | 156 |
32 files changed, 2104 insertions, 1683 deletions
diff --git a/Documentation/power/apm-acpi.txt b/Documentation/power/apm-acpi.rst index 6cc423d3662e..5b90d947126d 100644 --- a/Documentation/power/apm-acpi.txt +++ b/Documentation/power/apm-acpi.rst @@ -1,5 +1,7 @@ +============ APM or ACPI? ------------- +============ + If you have a relatively recent x86 mobile, desktop, or server system, odds are it supports either Advanced Power Management (APM) or Advanced Configuration and Power Interface (ACPI). ACPI is the newer @@ -28,5 +30,7 @@ and be sure that they are started sometime in the system boot process. Go ahead and start both. If ACPI or APM is not available on your system the associated daemon will exit gracefully. - apmd: http://ftp.debian.org/pool/main/a/apmd/ - acpid: http://acpid.sf.net/ + ===== ======================================= + apmd http://ftp.debian.org/pool/main/a/apmd/ + acpid http://acpid.sf.net/ + ===== ======================================= diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.rst index 708f87f78a75..69862e759c30 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.rst @@ -1,12 +1,16 @@ +================================= Debugging hibernation and suspend +================================= + (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL 1. Testing hibernation (aka suspend to disk or STD) +=================================================== -To check if hibernation works, you can try to hibernate in the "reboot" mode: +To check if hibernation works, you can try to hibernate in the "reboot" mode:: -# echo reboot > /sys/power/disk -# echo disk > /sys/power/state + # echo reboot > /sys/power/disk + # echo disk > /sys/power/state and the system should create a hibernation image, reboot, resume and get back to the command prompt where you have started the transition. If that happens, @@ -15,20 +19,21 @@ test at least a couple of times in a row for confidence. [This is necessary, because some problems only show up on a second attempt at suspending and resuming the system.] Moreover, hibernating in the "reboot" and "shutdown" modes causes the PM core to skip some platform-related callbacks which on ACPI -systems might be necessary to make hibernation work. Thus, if your machine fails -to hibernate or resume in the "reboot" mode, you should try the "platform" mode: +systems might be necessary to make hibernation work. Thus, if your machine +fails to hibernate or resume in the "reboot" mode, you should try the +"platform" mode:: -# echo platform > /sys/power/disk -# echo disk > /sys/power/state + # echo platform > /sys/power/disk + # echo disk > /sys/power/state which is the default and recommended mode of hibernation. Unfortunately, the "platform" mode of hibernation does not work on some systems with broken BIOSes. In such cases the "shutdown" mode of hibernation might -work: +work:: -# echo shutdown > /sys/power/disk -# echo disk > /sys/power/state + # echo shutdown > /sys/power/disk + # echo disk > /sys/power/state (it is similar to the "reboot" mode, but it requires you to press the power button to make the system resume). @@ -37,6 +42,7 @@ If neither "platform" nor "shutdown" hibernation mode works, you will need to identify what goes wrong. a) Test modes of hibernation +---------------------------- To find out why hibernation fails on your system, you can use a special testing facility available if the kernel is compiled with CONFIG_PM_DEBUG set. Then, @@ -44,36 +50,38 @@ there is the file /sys/power/pm_test that can be used to make the hibernation core run in a test mode. There are 5 test modes available: freezer -- test the freezing of processes + - test the freezing of processes devices -- test the freezing of processes and suspending of devices + - test the freezing of processes and suspending of devices platform -- test the freezing of processes, suspending of devices and platform - global control methods(*) + - test the freezing of processes, suspending of devices and platform + global control methods [1]_ processors -- test the freezing of processes, suspending of devices, platform - global control methods(*) and the disabling of nonboot CPUs + - test the freezing of processes, suspending of devices, platform + global control methods [1]_ and the disabling of nonboot CPUs core -- test the freezing of processes, suspending of devices, platform global - control methods(*), the disabling of nonboot CPUs and suspending of - platform/system devices + - test the freezing of processes, suspending of devices, platform global + control methods\ [1]_, the disabling of nonboot CPUs and suspending + of platform/system devices + +.. [1] -(*) the platform global control methods are only available on ACPI systems + the platform global control methods are only available on ACPI systems and are only tested if the hibernation mode is set to "platform" To use one of them it is necessary to write the corresponding string to /sys/power/pm_test (eg. "devices" to test the freezing of processes and suspending devices) and issue the standard hibernation commands. For example, to use the "devices" test mode along with the "platform" mode of hibernation, -you should do the following: +you should do the following:: -# echo devices > /sys/power/pm_test -# echo platform > /sys/power/disk -# echo disk > /sys/power/state + # echo devices > /sys/power/pm_test + # echo platform > /sys/power/disk + # echo disk > /sys/power/state Then, the kernel will try to freeze processes, suspend devices, wait a few seconds (5 by default, but configurable by the suspend.pm_test_delay module @@ -108,11 +116,12 @@ If the "devices" test fails, most likely there is a driver that cannot suspend or resume its device (in the latter case the system may hang or become unstable after the test, so please take that into consideration). To find this driver, you can carry out a binary search according to the rules: + - if the test fails, unload a half of the drivers currently loaded and repeat -(that would probably involve rebooting the system, so always note what drivers -have been loaded before the test), + (that would probably involve rebooting the system, so always note what drivers + have been loaded before the test), - if the test succeeds, load a half of the drivers you have unloaded most -recently and repeat. + recently and repeat. Once you have found the failing driver (there can be more than just one of them), you have to unload it every time before hibernation. In that case please @@ -146,6 +155,7 @@ indicates a serious problem that very well may be related to the hardware, but please report it anyway. b) Testing minimal configuration +-------------------------------- If all of the hibernation test modes work, you can boot the system with the "init=/bin/bash" command line parameter and attempt to hibernate in the @@ -165,14 +175,15 @@ Again, if you find the offending module(s), it(they) must be unloaded every time before hibernation, and please report the problem with it(them). c) Using the "test_resume" hibernation option +--------------------------------------------- /sys/power/disk generally tells the kernel what to do after creating a hibernation image. One of the available options is "test_resume" which causes the just created image to be used for immediate restoration. Namely, -after doing: +after doing:: -# echo test_resume > /sys/power/disk -# echo disk > /sys/power/state + # echo test_resume > /sys/power/disk + # echo disk > /sys/power/state a hibernation image will be created and a resume from it will be triggered immediately without involving the platform firmware in any way. @@ -190,6 +201,7 @@ to resume may be related to the differences between the restore and image kernels. d) Advanced debugging +--------------------- In case that hibernation does not work on your system even in the minimal configuration and compiling more drivers as modules is not practical or some @@ -200,9 +212,10 @@ kernel messages using the serial console. This may provide you with some information about the reasons of the suspend (resume) failure. Alternatively, it may be possible to use a FireWire port for debugging with firescope (http://v3.sk/~lkundrak/firescope/). On x86 it is also possible to -use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . +use the PM_TRACE mechanism documented in Documentation/power/s2ram.rst . 2. Testing suspend to RAM (STR) +=============================== To verify that the STR works, it is generally more convenient to use the s2ram tool available from http://suspend.sf.net and documented at @@ -230,7 +243,8 @@ you will have to unload them every time before an STR transition (ie. before you run s2ram), and please report the problems with them. There is a debugfs entry which shows the suspend to RAM statistics. Here is an -example of its output. +example of its output:: + # mount -t debugfs none /sys/kernel/debug # cat /sys/kernel/debug/suspend_stats success: 20 @@ -248,6 +262,7 @@ example of its output. -16 last_failed_step: suspend suspend + Field success means the success number of suspend to RAM, and field fail means the failure number. Others are the failure number of different steps of suspend to RAM. suspend_stats just lists the last 2 failed devices, error number and diff --git a/Documentation/power/charger-manager.txt b/Documentation/power/charger-manager.rst index 9ff1105e58d6..84fab9376792 100644 --- a/Documentation/power/charger-manager.txt +++ b/Documentation/power/charger-manager.rst @@ -1,4 +1,7 @@ +=============== Charger Manager +=============== + (C) 2011 MyungJoo Ham <myungjoo.ham@samsung.com>, GPL Charger Manager provides in-kernel battery charger management that @@ -55,41 +58,39 @@ Charger Manager supports the following: notification to users with UEVENT. 2. Global Charger-Manager Data related with suspend_again -======================================================== +========================================================= In order to setup Charger Manager with suspend-again feature (in-suspend monitoring), the user should provide charger_global_desc -with setup_charger_manager(struct charger_global_desc *). +with setup_charger_manager(`struct charger_global_desc *`). This charger_global_desc data for in-suspend monitoring is global as the name suggests. Thus, the user needs to provide only once even if there are multiple batteries. If there are multiple batteries, the multiple instances of Charger Manager share the same charger_global_desc and it will manage in-suspend monitoring for all instances of Charger Manager. -The user needs to provide all the three entries properly in order to activate -in-suspend monitoring: - -struct charger_global_desc { +The user needs to provide all the three entries to `struct charger_global_desc` +properly in order to activate in-suspend monitoring: -char *rtc_name; - : The name of rtc (e.g., "rtc0") used to wakeup the system from +`char *rtc_name;` + The name of rtc (e.g., "rtc0") used to wakeup the system from suspend for Charger Manager. The alarm interrupt (AIE) of the rtc should be able to wake up the system from suspend. Charger Manager saves and restores the alarm value and use the previously-defined alarm if it is going to go off earlier than Charger Manager so that Charger Manager does not interfere with previously-defined alarms. -bool (*rtc_only_wakeup)(void); - : This callback should let CM know whether +`bool (*rtc_only_wakeup)(void);` + This callback should let CM know whether the wakeup-from-suspend is caused only by the alarm of "rtc" in the same struct. If there is any other wakeup source triggered the wakeup, it should return false. If the "rtc" is the only wakeup reason, it should return true. -bool assume_timer_stops_in_suspend; - : if true, Charger Manager assumes that +`bool assume_timer_stops_in_suspend;` + if true, Charger Manager assumes that the timer (CM uses jiffies as timer) stops during suspend. Then, CM assumes that the suspend-duration is same as the alarm length. -}; + 3. How to setup suspend_again ============================= @@ -109,26 +110,28 @@ if the system was woken up by Charger Manager and the polling ============================================= For each battery charged independently from other batteries (if a series of batteries are charged by a single charger, they are counted as one independent -battery), an instance of Charger Manager is attached to it. +battery), an instance of Charger Manager is attached to it. The following -struct charger_desc { +struct charger_desc elements: -char *psy_name; - : The power-supply-class name of the battery. Default is +`char *psy_name;` + The power-supply-class name of the battery. Default is "battery" if psy_name is NULL. Users can access the psy entries at "/sys/class/power_supply/[psy_name]/". -enum polling_modes polling_mode; - : CM_POLL_DISABLE: do not poll this battery. - CM_POLL_ALWAYS: always poll this battery. - CM_POLL_EXTERNAL_POWER_ONLY: poll this battery if and only if - an external power source is attached. - CM_POLL_CHARGING_ONLY: poll this battery if and only if the - battery is being charged. - -unsigned int fullbatt_vchkdrop_ms; -unsigned int fullbatt_vchkdrop_uV; - : If both have non-zero values, Charger Manager will check the +`enum polling_modes polling_mode;` + CM_POLL_DISABLE: + do not poll this battery. + CM_POLL_ALWAYS: + always poll this battery. + CM_POLL_EXTERNAL_POWER_ONLY: + poll this battery if and only if an external power + source is attached. + CM_POLL_CHARGING_ONLY: + poll this battery if and only if the battery is being charged. + +`unsigned int fullbatt_vchkdrop_ms; / unsigned int fullbatt_vchkdrop_uV;` + If both have non-zero values, Charger Manager will check the battery voltage drop fullbatt_vchkdrop_ms after the battery is fully charged. If the voltage drop is over fullbatt_vchkdrop_uV, Charger Manager will try to recharge the battery by disabling and enabling @@ -136,50 +139,52 @@ unsigned int fullbatt_vchkdrop_uV; condition) is needed to be implemented with hardware interrupts from fuel gauges or charger devices/chips. -unsigned int fullbatt_uV; - : If specified with a non-zero value, Charger Manager assumes +`unsigned int fullbatt_uV;` + If specified with a non-zero value, Charger Manager assumes that the battery is full (capacity = 100) if the battery is not being charged and the battery voltage is equal to or greater than fullbatt_uV. -unsigned int polling_interval_ms; - : Required polling interval in ms. Charger Manager will poll +`unsigned int polling_interval_ms;` + Required polling interval in ms. Charger Manager will poll this battery every polling_interval_ms or more frequently. -enum data_source battery_present; - : CM_BATTERY_PRESENT: assume that the battery exists. - CM_NO_BATTERY: assume that the battery does not exists. - CM_FUEL_GAUGE: get battery presence information from fuel gauge. - CM_CHARGER_STAT: get battery presence from chargers. - -char **psy_charger_stat; - : An array ending with NULL that has power-supply-class names of +`enum data_source battery_present;` + CM_BATTERY_PRESENT: + assume that the battery exists. + CM_NO_BATTERY: + assume that the battery does not exists. + CM_FUEL_GAUGE: + get battery presence information from fuel gauge. + CM_CHARGER_STAT: + get battery presence from chargers. + +`char **psy_charger_stat;` + An array ending with NULL that has power-supply-class names of chargers. Each power-supply-class should provide "PRESENT" (if battery_present is "CM_CHARGER_STAT"), "ONLINE" (shows whether an external power source is attached or not), and "STATUS" (shows whether the battery is {"FULL" or not FULL} or {"FULL", "Charging", "Discharging", "NotCharging"}). -int num_charger_regulators; -struct regulator_bulk_data *charger_regulators; - : Regulators representing the chargers in the form for +`int num_charger_regulators; / struct regulator_bulk_data *charger_regulators;` + Regulators representing the chargers in the form for regulator framework's bulk functions. -char *psy_fuel_gauge; - : Power-supply-class name of the fuel gauge. +`char *psy_fuel_gauge;` + Power-supply-class name of the fuel gauge. -int (*temperature_out_of_range)(int *mC); -bool measure_battery_temp; - : This callback returns 0 if the temperature is safe for charging, +`int (*temperature_out_of_range)(int *mC); / bool measure_battery_temp;` + This callback returns 0 if the temperature is safe for charging, a positive number if it is too hot to charge, and a negative number if it is too cold to charge. With the variable mC, the callback returns the temperature in 1/1000 of centigrade. The source of temperature can be battery or ambient one according to the value of measure_battery_temp. -}; + 5. Notify Charger-Manager of charger events: cm_notify_event() -========================================================= +============================================================== If there is an charger event is required to notify Charger Manager, a charger device driver that triggers the event can call cm_notify_event(psy, type, msg) to notify the corresponding Charger Manager. diff --git a/Documentation/power/drivers-testing.txt b/Documentation/power/drivers-testing.rst index 638afdf4d6b8..e53f1999fc39 100644 --- a/Documentation/power/drivers-testing.txt +++ b/Documentation/power/drivers-testing.rst @@ -1,7 +1,11 @@ +==================================================== Testing suspend and resume support in device drivers +==================================================== + (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL 1. Preparing the test system +============================ Unfortunately, to effectively test the support for the system-wide suspend and resume transitions in a driver, it is necessary to suspend and resume a fully @@ -14,19 +18,20 @@ the machine's BIOS. Of course, for this purpose the test system has to be known to suspend and resume without the driver being tested. Thus, if possible, you should first resolve all suspend/resume-related problems in the test system before you start -testing the new driver. Please see Documentation/power/basic-pm-debugging.txt +testing the new driver. Please see Documentation/power/basic-pm-debugging.rst for more information about the debugging of suspend/resume functionality. 2. Testing the driver +===================== Once you have resolved the suspend/resume-related problems with your test system without the new driver, you are ready to test it: a) Build the driver as a module, load it and try the test modes of hibernation - (see: Documentation/power/basic-pm-debugging.txt, 1). + (see: Documentation/power/basic-pm-debugging.rst, 1). b) Load the driver and attempt to hibernate in the "reboot", "shutdown" and - "platform" modes (see: Documentation/power/basic-pm-debugging.txt, 1). + "platform" modes (see: Documentation/power/basic-pm-debugging.rst, 1). c) Compile the driver directly into the kernel and try the test modes of hibernation. @@ -34,12 +39,12 @@ c) Compile the driver directly into the kernel and try the test modes of d) Attempt to hibernate with the driver compiled directly into the kernel in the "reboot", "shutdown" and "platform" modes. -e) Try the test modes of suspend (see: Documentation/power/basic-pm-debugging.txt, +e) Try the test modes of suspend (see: Documentation/power/basic-pm-debugging.rst, 2). [As far as the STR tests are concerned, it should not matter whether or not the driver is built as a module.] f) Attempt to suspend to RAM using the s2ram tool with the driver loaded - (see: Documentation/power/basic-pm-debugging.txt, 2). + (see: Documentation/power/basic-pm-debugging.rst, 2). Each of the above tests should be repeated several times and the STD tests should be mixed with the STR tests. If any of them fails, the driver cannot be diff --git a/Documentation/power/energy-model.txt b/Documentation/power/energy-model.rst index a2b0ae4c76bd..90a345d57ae9 100644 --- a/Documentation/power/energy-model.txt +++ b/Documentation/power/energy-model.rst @@ -1,6 +1,6 @@ - ==================== - Energy Model of CPUs - ==================== +==================== +Energy Model of CPUs +==================== 1. Overview ----------- @@ -20,7 +20,7 @@ kernel, hence enabling to avoid redundant work. The figure below depicts an example of drivers (Arm-specific here, but the approach is applicable to any architecture) providing power costs to the EM -framework, and interested clients reading the data from it. +framework, and interested clients reading the data from it:: +---------------+ +-----------------+ +---------------+ | Thermal (IPA) | | Scheduler (EAS) | | Other | @@ -58,15 +58,17 @@ micro-architectures. 2. Core APIs ------------ - 2.1 Config options +2.1 Config options +^^^^^^^^^^^^^^^^^^ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. - 2.2 Registration of performance domains +2.2 Registration of performance domains +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Drivers are expected to register performance domains into the EM framework by -calling the following API: +calling the following API:: int em_register_perf_domain(cpumask_t *span, unsigned int nr_states, struct em_data_callback *cb); @@ -80,7 +82,8 @@ callback, and kernel/power/energy_model.c for further documentation on this API. - 2.3 Accessing performance domains +2.3 Accessing performance domains +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Subsystems interested in the energy model of a CPU can retrieve it using the em_cpu_get() API. The energy model tables are allocated once upon creation of @@ -99,46 +102,46 @@ More details about the above APIs can be found in include/linux/energy_model.h. This section provides a simple example of a CPUFreq driver registering a performance domain in the Energy Model framework using the (fake) 'foo' protocol. The driver implements an est_power() function to be provided to the -EM framework. - - -> drivers/cpufreq/foo_cpufreq.c - -01 static int est_power(unsigned long *mW, unsigned long *KHz, int cpu) -02 { -03 long freq, power; -04 -05 /* Use the 'foo' protocol to ceil the frequency */ -06 freq = foo_get_freq_ceil(cpu, *KHz); -07 if (freq < 0); -08 return freq; -09 -10 /* Estimate the power cost for the CPU at the relevant freq. */ -11 power = foo_estimate_power(cpu, freq); -12 if (power < 0); -13 return power; -14 -15 /* Return the values to the EM framework */ -16 *mW = power; -17 *KHz = freq; -18 -19 return 0; -20 } -21 -22 static int foo_cpufreq_init(struct cpufreq_policy *policy) -23 { -24 struct em_data_callback em_cb = EM_DATA_CB(est_power); -25 int nr_opp, ret; -26 -27 /* Do the actual CPUFreq init work ... */ -28 ret = do_foo_cpufreq_init(policy); -29 if (ret) -30 return ret; -31 -32 /* Find the number of OPPs for this policy */ -33 nr_opp = foo_get_nr_opp(policy); -34 -35 /* And register the new performance domain */ -36 em_register_perf_domain(policy->cpus, nr_opp, &em_cb); -37 -38 return 0; -39 } +EM framework:: + + -> drivers/cpufreq/foo_cpufreq.c + + 01 static int est_power(unsigned long *mW, unsigned long *KHz, int cpu) + 02 { + 03 long freq, power; + 04 + 05 /* Use the 'foo' protocol to ceil the frequency */ + 06 freq = foo_get_freq_ceil(cpu, *KHz); + 07 if (freq < 0); + 08 return freq; + 09 + 10 /* Estimate the power cost for the CPU at the relevant freq. */ + 11 power = foo_estimate_power(cpu, freq); + 12 if (power < 0); + 13 return power; + 14 + 15 /* Return the values to the EM framework */ + 16 *mW = power; + 17 *KHz = freq; + 18 + 19 return 0; + 20 } + 21 + 22 static int foo_cpufreq_init(struct cpufreq_policy *policy) + 23 { + 24 struct em_data_callback em_cb = EM_DATA_CB(est_power); + 25 int nr_opp, ret; + 26 + 27 /* Do the actual CPUFreq init work ... */ + 28 ret = do_foo_cpufreq_init(policy); + 29 if (ret) + 30 return ret; + 31 + 32 /* Find the number of OPPs for this policy */ + 33 nr_opp = foo_get_nr_opp(policy); + 34 + 35 /* And register the new performance domain */ + 36 em_register_perf_domain(policy->cpus, nr_opp, &em_cb); + 37 + 38 return 0; + 39 } diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.rst index cd283190855a..ef110fe55e82 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.rst @@ -1,13 +1,18 @@ +================= Freezing of tasks - (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL +================= + +(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL I. What is the freezing of tasks? +================================= The freezing of tasks is a mechanism by which user space processes and some kernel threads are controlled during hibernation or system-wide suspend (on some architectures). II. How does it work? +===================== There are three per-task flags used for that, PF_NOFREEZE, PF_FROZEN and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have @@ -41,7 +46,7 @@ explicitly in suitable places or use the wait_event_freezable() or wait_event_freezable_timeout() macros (defined in include/linux/freezer.h) that combine interruptible sleep with checking if the task is to be frozen and calling try_to_freeze(). The main loop of a freezable kernel thread may look -like the following one: +like the following one:: set_freezable(); do { @@ -65,7 +70,7 @@ order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that have been frozen leave __refrigerator() and continue running. -Rationale behind the functions dealing with freezing and thawing of tasks: +Rationale behind the functions dealing with freezing and thawing of tasks ------------------------------------------------------------------------- freeze_processes(): @@ -86,6 +91,7 @@ thaw_processes(): III. Which kernel threads are freezable? +======================================== Kernel threads are not freezable by default. However, a kernel thread may clear PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE @@ -93,37 +99,39 @@ directly is not allowed). From this point it is regarded as freezable and must call try_to_freeze() in a suitable place. IV. Why do we do that? +====================== Generally speaking, there is a couple of reasons to use the freezing of tasks: 1. The principal reason is to prevent filesystems from being damaged after -hibernation. At the moment we have no simple means of checkpointing -filesystems, so if there are any modifications made to filesystem data and/or -metadata on disks, we cannot bring them back to the state from before the -modifications. At the same time each hibernation image contains some -filesystem-related information that must be consistent with the state of the -on-disk data and metadata after the system memory state has been restored from -the image (otherwise the filesystems will be damaged in a nasty way, usually -making them almost impossible to repair). We therefore freeze tasks that might -cause the on-disk filesystems' data and metadata to be modified after the -hibernation image has been created and before the syst |