aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorTakashi Iwai <tiwai@suse.de>2009-12-25 08:15:31 -0500
committerTakashi Iwai <tiwai@suse.de>2009-12-25 08:15:31 -0500
commit52e04ea89da57274f0313d2bd73ba02f686cfdeb (patch)
tree6ce5d086bcaea4cb534b3fcf6ba736eb48d582a4 /Documentation
parent41116e926cb92292fa4fcbe888ae8133fa0038e6 (diff)
parent8b90ca08821fee79e181bfcbc3bbd41ef5637136 (diff)
Merge branch 'fix/misc' into topic/misc
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-bus-usb18
-rw-r--r--Documentation/cpu-hotplug.txt49
-rw-r--r--Documentation/dontdiff1
-rw-r--r--Documentation/driver-model/driver.txt4
-rw-r--r--Documentation/filesystems/sysfs.txt12
-rw-r--r--Documentation/hwmon/k10temp60
-rw-r--r--Documentation/kbuild/kbuild.txt14
-rw-r--r--Documentation/kbuild/kconfig.txt8
-rw-r--r--Documentation/power/runtime_pm.txt223
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/mpic.txt42
-rw-r--r--Documentation/sound/alsa/HD-Audio-Models.txt1
-rw-r--r--Documentation/stable_kernel_rules.txt24
-rw-r--r--Documentation/trace/events-kmem.txt14
-rw-r--r--Documentation/usb/power-management.txt41
14 files changed, 341 insertions, 170 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index deb6b489e4e5..a07c0f366f91 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -21,25 +21,27 @@ Contact: Alan Stern <stern@rowland.harvard.edu>
21Description: 21Description:
22 Each USB device directory will contain a file named 22 Each USB device directory will contain a file named
23 power/level. This file holds a power-level setting for 23 power/level. This file holds a power-level setting for
24 the device, one of "on", "auto", or "suspend". 24 the device, either "on" or "auto".
25 25
26 "on" means that the device is not allowed to autosuspend, 26 "on" means that the device is not allowed to autosuspend,
27 although normal suspends for system sleep will still 27 although normal suspends for system sleep will still
28 be honored. "auto" means the device will autosuspend 28 be honored. "auto" means the device will autosuspend
29 and autoresume in the usual manner, according to the 29 and autoresume in the usual manner, according to the
30 capabilities of its driver. "suspend" means the device 30 capabilities of its driver.
31 is forced into a suspended state and it will not autoresume
32 in response to I/O requests. However remote-wakeup requests
33 from the device may still be enabled (the remote-wakeup
34 setting is controlled separately by the power/wakeup
35 attribute).
36 31
37 During normal use, devices should be left in the "auto" 32 During normal use, devices should be left in the "auto"
38 level. The other levels are meant for administrative uses. 33 level. The "on" level is meant for administrative uses.
39 If you want to suspend a device immediately but leave it 34 If you want to suspend a device immediately but leave it
40 free to wake up in response to I/O requests, you should 35 free to wake up in response to I/O requests, you should
41 write "0" to power/autosuspend. 36 write "0" to power/autosuspend.
42 37
38 Device not capable of proper suspend and resume should be
39 left in the "on" level. Although the USB spec requires
40 devices to support suspend/resume, many of them do not.
41 In fact so many don't that by default, the USB core
42 initializes all non-hub devices in the "on" level. Some
43 drivers may change this setting when they are bound.
44
43What: /sys/bus/usb/devices/.../power/persist 45What: /sys/bus/usb/devices/.../power/persist
44Date: May 2007 46Date: May 2007
45KernelVersion: 2.6.23 47KernelVersion: 2.6.23
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 4d4a644b505e..a99d7031cdf9 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -315,41 +315,26 @@ A: The following are what is required for CPU hotplug infrastructure to work
315 315
316Q: I need to ensure that a particular cpu is not removed when there is some 316Q: I need to ensure that a particular cpu is not removed when there is some
317 work specific to this cpu is in progress. 317 work specific to this cpu is in progress.
318A: First switch the current thread context to preferred cpu 318A: There are two ways. If your code can be run in interrupt context, use
319 smp_call_function_single(), otherwise use work_on_cpu(). Note that
320 work_on_cpu() is slow, and can fail due to out of memory:
319 321
320 int my_func_on_cpu(int cpu) 322 int my_func_on_cpu(int cpu)
321 { 323 {
322 cpumask_t saved_mask, new_mask = CPU_MASK_NONE; 324 int err;
323 int curr_cpu, err = 0; 325 get_online_cpus();
324 326 if (!cpu_online(cpu))
325 saved_mask = current->cpus_allowed; 327 err = -EINVAL;
326 cpu_set(cpu, new_mask); 328 else
327 err = set_cpus_allowed(current, new_mask); 329#if NEEDS_BLOCKING
328 330 err = work_on_cpu(cpu, __my_func_on_cpu, NULL);
329 if (err) 331#else
330 return err; 332 smp_call_function_single(cpu, __my_func_on_cpu, &err,
331 333 true);
332 /* 334#endif
333 * If we got scheduled out just after the return from 335 put_online_cpus();
334 * set_cpus_allowed() before running the work, this ensures 336 return err;
335 * we stay locked. 337 }
336 */
337 curr_cpu = get_cpu();
338
339 if (curr_cpu != cpu) {
340 err = -EAGAIN;
341 goto ret;
342 } else {
343 /*
344 * Do work : But cant sleep, since get_cpu() disables preempt
345 */
346 }
347 ret:
348 put_cpu();
349 set_cpus_allowed(current, saved_mask);
350 return err;
351 }
352
353 338
354Q: How do we determine how many CPUs are available for hotplug. 339Q: How do we determine how many CPUs are available for hotplug.
355A: There is no clear spec defined way from ACPI that can give us that 340A: There is no clear spec defined way from ACPI that can give us that
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index e151b2a36267..3ad6acead949 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -103,6 +103,7 @@ gconf
103gen-devlist 103gen-devlist
104gen_crc32table 104gen_crc32table
105gen_init_cpio 105gen_init_cpio
106generated
106genheaders 107genheaders
107genksyms 108genksyms
108*_gray256.c 109*_gray256.c
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index 60120fb3b961..d2cd6fb8ba9e 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -226,5 +226,5 @@ struct driver_attribute driver_attr_debug;
226This can then be used to add and remove the attribute from the 226This can then be used to add and remove the attribute from the
227driver's directory using: 227driver's directory using:
228 228
229int driver_create_file(struct device_driver *, struct driver_attribute *); 229int driver_create_file(struct device_driver *, const struct driver_attribute *);
230void driver_remove_file(struct device_driver *, struct driver_attribute *); 230void driver_remove_file(struct device_driver *, const struct driver_attribute *);
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index b245d524d568..931c806642c5 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -91,8 +91,8 @@ struct device_attribute {
91 const char *buf, size_t count); 91 const char *buf, size_t count);
92}; 92};
93 93
94int device_create_file(struct device *, struct device_attribute *); 94int device_create_file(struct device *, const struct device_attribute *);
95void device_remove_file(struct device *, struct device_attribute *); 95void device_remove_file(struct device *, const struct device_attribute *);
96 96
97It also defines this helper for defining device attributes: 97It also defines this helper for defining device attributes:
98 98
@@ -316,8 +316,8 @@ DEVICE_ATTR(_name, _mode, _show, _store);
316 316
317Creation/Removal: 317Creation/Removal:
318 318
319int device_create_file(struct device *device, struct device_attribute * attr); 319int device_create_file(struct device *dev, const struct device_attribute * attr);
320void device_remove_file(struct device * dev, struct device_attribute * attr); 320void device_remove_file(struct device *dev, const struct device_attribute * attr);
321 321
322 322
323- bus drivers (include/linux/device.h) 323- bus drivers (include/linux/device.h)
@@ -358,7 +358,7 @@ DRIVER_ATTR(_name, _mode, _show, _store)
358 358
359Creation/Removal: 359Creation/Removal:
360 360
361int driver_create_file(struct device_driver *, struct driver_attribute *); 361int driver_create_file(struct device_driver *, const struct driver_attribute *);
362void driver_remove_file(struct device_driver *, struct driver_attribute *); 362void driver_remove_file(struct device_driver *, const struct driver_attribute *);
363 363
364 364
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
new file mode 100644
index 000000000000..a7a18d453a51
--- /dev/null
+++ b/Documentation/hwmon/k10temp
@@ -0,0 +1,60 @@
1Kernel driver k10temp
2=====================
3
4Supported chips:
5* AMD Family 10h processors:
6 Socket F: Quad-Core/Six-Core/Embedded Opteron
7 Socket AM2+: Opteron, Phenom (II) X3/X4
8 Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II
9 Socket S1G3: Athlon II, Sempron, Turion II
10* AMD Family 11h processors:
11 Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
12
13 Prefix: 'k10temp'
14 Addresses scanned: PCI space
15 Datasheets:
16 BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors:
17 http://support.amd.com/us/Processor_TechDocs/31116.pdf
18 BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors:
19 http://support.amd.com/us/Processor_TechDocs/41256.pdf
20 Revision Guide for AMD Family 10h Processors:
21 http://support.amd.com/us/Processor_TechDocs/41322.pdf
22 Revision Guide for AMD Family 11h Processors:
23 http://support.amd.com/us/Processor_TechDocs/41788.pdf
24 AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks:
25 http://support.amd.com/us/Processor_TechDocs/43373.pdf
26 AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet:
27 http://support.amd.com/us/Processor_TechDocs/43374.pdf
28 AMD Family 10h Desktop Processor Power and Thermal Data Sheet:
29 http://support.amd.com/us/Processor_TechDocs/43375.pdf
30
31Author: Clemens Ladisch <clemens@ladisch.de>
32
33Description
34-----------
35
36This driver permits reading of the internal temperature sensor of AMD
37Family 10h and 11h processors.
38
39All these processors have a sensor, but on older revisions of Family 10h
40processors, the sensor may return inconsistent values (erratum 319). The
41driver will refuse to load on these revisions unless you specify the
42"force=1" module parameter.
43
44There is one temperature measurement value, available as temp1_input in
45sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree.
46Please note that it is defined as a relative value; to quote the AMD manual:
47
48 Tctl is the processor temperature control value, used by the platform to
49 control cooling systems. Tctl is a non-physical temperature on an
50 arbitrary scale measured in degrees. It does _not_ represent an actual
51 physical temperature like die or case temperature. Instead, it specifies
52 the processor temperature relative to the point at which the system must
53 supply the maximum cooling for the processor's specified maximum case
54 temperature and maximum thermal power dissipation.
55
56The maximum value for Tctl is available in the file temp1_max.
57
58If the BIOS has enabled hardware temperature control, the threshold at
59which the processor will throttle itself to avoid damage is available in
60temp1_crit and temp1_crit_hyst.
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index bb3bf38f03da..6f8c1cabbc5d 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -1,3 +1,17 @@
1Output files
2
3modules.order
4--------------------------------------------------
5This file records the order in which modules appear in Makefiles. This
6is used by modprobe to deterministically resolve aliases that match
7multiple modules.
8
9modules.builtin
10--------------------------------------------------
11This file lists all modules that are built into the kernel. This is used
12by modprobe to not fail when trying to load something builtin.
13
14
1Environment variables 15Environment variables
2 16
3KCPPFLAGS 17KCPPFLAGS
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 849b5e56d06f..49efae703979 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -103,10 +103,16 @@ KCONFIG_AUTOCONFIG
103This environment variable can be set to specify the path & name of the 103This environment variable can be set to specify the path & name of the
104"auto.conf" file. Its default value is "include/config/auto.conf". 104"auto.conf" file. Its default value is "include/config/auto.conf".
105 105
106KCONFIG_TRISTATE
107--------------------------------------------------
108This environment variable can be set to specify the path & name of the
109"tristate.conf" file. Its default value is "include/config/tristate.conf".
110
106KCONFIG_AUTOHEADER 111KCONFIG_AUTOHEADER
107-------------------------------------------------- 112--------------------------------------------------
108This environment variable can be set to specify the path & name of the 113This environment variable can be set to specify the path & name of the
109"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h". 114"autoconf.h" (header) file.
115Its default value is "include/generated/autoconf.h".
110 116
111 117
112====================================================================== 118======================================================================
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 4a3109b28847..356fd86f4ea8 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -42,80 +42,81 @@ struct dev_pm_ops {
42 ... 42 ...
43}; 43};
44 44
45The ->runtime_suspend() callback is executed by the PM core for the bus type of 45The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are
46the device being suspended. The bus type's callback is then _entirely_ 46executed by the PM core for either the bus type, or device type (if the bus
47_responsible_ for handling the device as appropriate, which may, but need not 47type's callback is not defined), or device class (if the bus type's and device
48include executing the device driver's own ->runtime_suspend() callback (from the 48type's callbacks are not defined) of given device. The bus type, device type
49and device class callbacks are referred to as subsystem-level callbacks in what
50follows.
51
52The subsystem-level suspend callback is _entirely_ _responsible_ for handling
53the suspend of the device as appropriate, which may, but need not include
54executing the device driver's own ->runtime_suspend() callback (from the
49PM core's point of view it is not necessary to implement a ->runtime_suspend() 55PM core's point of view it is not necessary to implement a ->runtime_suspend()
50callback in a device driver as long as the bus type's ->runtime_suspend() knows 56callback in a device driver as long as the subsystem-level suspend callback
51what to do to handle the device). 57knows what to do to handle the device).
52 58
53 * Once the bus type's ->runtime_suspend() callback has completed successfully 59 * Once the subsystem-level suspend callback has completed successfully
54 for given device, the PM core regards the device as suspended, which need 60 for given device, the PM core regards the device as suspended, which need
55 not mean that the device has been put into a low power state. It is 61 not mean that the device has been put into a low power state. It is
56 supposed to mean, however, that the device will not process data and will 62 supposed to mean, however, that the device will not process data and will
57 not communicate with the CPU(s) and RAM until its bus type's 63 not communicate with the CPU(s) and RAM until the subsystem-level resume
58 ->runtime_resume() callback is executed for it. The run-time PM status of 64 callback is executed for it. The run-time PM status of a device after
59 a device after successful execution of its bus type's ->runtime_suspend() 65 successful execution of the subsystem-level suspend callback is 'suspended'.
60 callback is 'suspended'. 66
61 67 * If the subsystem-level suspend callback returns -EBUSY or -EAGAIN,
62 * If the bus type's ->runtime_suspend() callback returns -EBUSY or -EAGAIN, 68 the device's run-time PM status is 'active', which means that the device
63 the device's run-time PM status is supposed to be 'active', which means that 69 _must_ be fully operational afterwards.
64 the device _must_ be fully operational afterwards. 70
65 71 * If the subsystem-level suspend callback returns an error code different
66 * If the bus type's ->runtime_suspend() callback returns an error code 72 from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will
67 different from -EBUSY or -EAGAIN, the PM core regards this as a fatal 73 refuse to run the helper functions described in Section 4 for the device,
68 error and will refuse to run the helper functions described in Section 4 74 until the status of it is directly set either to 'active', or to 'suspended'
69 for the device, until the status of it is directly set either to 'active' 75 (the PM core provides special helper functions for this purpose).
70 or to 'suspended' (the PM core provides special helper functions for this 76
71 purpose). 77In particular, if the driver requires remote wake-up capability (i.e. hardware
72 78mechanism allowing the device to request a change of its power state, such as
73In particular, if the driver requires remote wakeup capability for proper 79PCI PME) for proper functioning and device_run_wake() returns 'false' for the
74functioning and device_run_wake() returns 'false' for the device, then 80device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
75->runtime_suspend() should return -EBUSY. On the other hand, if 81device_run_wake() returns 'true' for the device and the device is put into a low
76device_run_wake() returns 'true' for the device and the device is put 82power state during the execution of the subsystem-level suspend callback, it is
77into a low power state during the execution of its bus type's 83expected that remote wake-up will be enabled for the device. Generally, remote
78->runtime_suspend(), it is expected that remote wake-up (i.e. hardware mechanism 84wake-up should be enabled for all input devices put into a low power state at
79allowing the device to request a change of its power state, such as PCI PME) 85run time.
80will be enabled for the device. Generally, remote wake-up should be enabled 86
81for all input devices put into a low power state at run time. 87The subsystem-level resume callback is _entirely_ _responsible_ for handling the
82 88resume of the device as appropriate, which may, but need not include executing
83The ->runtime_resume() callback is executed by the PM core for the bus type of 89the device driver's own ->runtime_resume() callback (from the PM core's point of
84the device being woken up. The bus type's callback is then _entirely_ 90view it is not necessary to implement a ->runtime_resume() callback in a device
85_responsible_ for handling the device as appropriate, which may, but need not 91driver as long as the subsystem-level resume callback knows what to do to handle
86include executing the device driver's own ->runtime_resume() callback (from the 92the device).
87PM core's point of view it is not necessary to implement a ->runtime_resume() 93
88callback in a device driver as long as the bus type's ->runtime_resume() knows 94 * Once the subsystem-level resume callback has completed successfully, the PM
89what to do to handle the device). 95 core regards the device as fully operational, which means that the device
90 96 _must_ be able to complete I/O operations as needed. The run-time PM status
91 * Once the bus type's ->runtime_resume() callback has completed successfully, 97 of the device is then 'active'.
92 the PM core regards the device as fully operational, which means that the 98
93 device _must_ be able to complete I/O operations as needed. The run-time 99 * If the subsystem-level resume callback returns an error code, the PM core
94 PM status of the device is then 'active'. 100 regards this as a fatal error and will refuse to run the helper functions
95 101 described in Section 4 for the device, until its status is directly set
96 * If the bus type's ->runtime_resume() callback returns an error code, the PM 102 either to 'active' or to 'suspended' (the PM core provides special helper
97 core regards this as a fatal error and will refuse to run the helper 103 functions for this purpose).
98 functions described in Section 4 for the device, until its status is 104
99 directly set either to 'active' or to 'suspended' (the PM core provides 105The subsystem-level idle callback is executed by the PM core whenever the device
100 special helper functions for this purpose). 106appears to be idle, which is indicated to the PM core by two counters, the
101 107device's usage counter and the counter of 'active' children of the device.
102The ->runtime_idle() callback is executed by the PM core for the bus type of
103given device whenever the device appears to be idle, which is indicated to the
104PM core by two counters, the device's usage counter and the counter of 'active'
105children of the device.
106 108
107 * If any of these counters is decreased using a helper function provided by 109 * If any of these counters is decreased using a helper function provided by
108 the PM core and it turns out to be equal to zero, the other counter is 110 the PM core and it turns out to be equal to zero, the other counter is
109 checked. If that counter also is equal to zero, the PM core executes the 111 checked. If that counter also is equal to zero, the PM core executes the
110 device bus type's ->runtime_idle() callback (with the device as an 112 subsystem-level idle callback with the device as an argument.
111 argument).
112 113
113The action performed by a bus type's ->runtime_idle() callback is totally 114The action performed by a subsystem-level idle callback is totally dependent on
114dependent on the bus type in question, but the expected and recommended action 115the subsystem in question, but the expected and recommended action is to check
115is to check if the device can be suspended (i.e. if all of the conditions 116if the device can be suspended (i.e. if all of the conditions necessary for
116necessary for suspending the device are satisfied) and to queue up a suspend 117suspending the device are satisfied) and to queue up a suspend request for the
117request for the device in that case. The value returned by this callback is 118device in that case. The value returned by this callback is ignored by the PM
118ignored by the PM core. 119core.
119 120
120The helper functions provided by the PM core, described in Section 4, guarantee 121The helper functions provided by the PM core, described in Section 4, guarantee
121that the following constraints are met with respect to the bus type's run-time 122that the following constraints are met with respect to the bus type's run-time
@@ -238,41 +239,41 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
238 removing the device from device hierarchy 239 removing the device from device hierarchy
239 240
240 int pm_runtime_idle(struct device *dev); 241 int pm_runtime_idle(struct device *dev);
241 - execute ->runtime_idle() for the device's bus type; returns 0 on success 242 - execute the subsystem-level idle callback for the device; returns 0 on
242 or error code on failure, where -EINPROGRESS means that ->runtime_idle() 243 success or error code on failure, where -EINPROGRESS means that
243 is already being executed 244 ->runtime_idle() is already being executed
244 245
245 int pm_runtime_suspend(struct device *dev); 246 int pm_runtime_suspend(struct device *dev);
246 - execute ->runtime_suspend() for the device's bus type; returns 0 on 247 - execute the subsystem-level suspend callback for the device; returns 0 on
247 success, 1 if the device's run-time PM status was already 'suspended', or 248 success, 1 if the device's run-time PM status was already 'suspended', or
248 error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt 249 error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt
249 to suspend the device again in future 250 to suspend the device again in future
250 251
251 int pm_runtime_resume(struct device *dev); 252 int pm_runtime_resume(struct device *dev);
252 - execute ->runtime_resume() for the device's bus type; returns 0 on 253 - execute the subsystem-leve resume callback for the device; returns 0 on
253 success, 1 if the device's run-time PM status was already 'active' or 254 success, 1 if the device's run-time PM status was already 'active' or
254 error code on failure, where -EAGAIN means it may be safe to attempt to 255 error code on failure, where -EAGAIN means it may be safe to attempt to
255 resume the device again in future, but 'power.runtime_error' should be 256 resume the device again in future, but 'power.runtime_error' should be
256 checked additionally 257 checked additionally
257 258
258 int pm_request_idle(struct device *dev); 259 int pm_request_idle(struct device *dev);
259 - submit a request to execute ->runtime_idle() for the device's bus type 260 - submit a request to execute the subsystem-level idle callback for the
260 (the request is represented by a work item in pm_wq); returns 0 on success 261 device (the request is represented by a work item in pm_wq); returns 0 on
261 or error code if the request has not been queued up 262 success or error code if the request has not been queued up
262 263
263 int pm_schedule_suspend(struct device *dev, unsigned int delay); 264 int pm_schedule_suspend(struct device *dev, unsigned int delay);
264 - schedule the execution of ->runtime_suspend() for the device's bus type 265 - schedule the execution of the subsystem-level suspend callback for the
265 in future, where 'delay' is the time to wait before queuing up a suspend 266 device in future, where 'delay' is the time to wait before queuing up a
266 work item in pm_wq, in milliseconds (if 'delay' is zero, the work item is 267 suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work
267 queued up immediately); returns 0 on success, 1 if the device's PM 268 item is queued up immediately); returns 0 on success, 1 if the device's PM
268 run-time status was already 'suspended', or error code if the request 269 run-time status was already 'suspended', or error code if the request
269 hasn't been scheduled (or queued up if 'delay' is 0); if the execution of 270 hasn't been scheduled (or queued up if 'delay' is 0); if the execution of
270 ->runtime_suspend() is already scheduled and not yet expired, the new 271 ->runtime_suspend() is already scheduled and not yet expired, the new
271 value of 'delay' will be used as the time to wait 272 value of 'delay' will be used as the time to wait
272 273
273 int pm_request_resume(struct device *dev); 274 int pm_request_resume(struct device *dev);
274 - submit a request to execute ->runtime_resume() for the device's bus type 275 - submit a request to execute the subsystem-level resume callback for the
275 (the request is represented by a work item in pm_wq); returns 0 on 276 device (the request is represented by a work item in pm_wq); returns 0 on
276 success, 1 if the device's run-time PM status was already 'active', or 277 success, 1 if the device's run-time PM status was already 'active', or
277 error code if the request hasn't been queued up 278 error code if the request hasn't been queued up
278 279
@@ -303,12 +304,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
303 run-time PM callbacks described in Section 2 304 run-time PM callbacks described in Section 2
304 305
305 int pm_runtime_disable(struct device *dev); 306 int pm_runtime_disable(struct device *dev);
306 - prevent the run-time PM helper functions from running the device bus 307 - prevent the run-time PM helper functions from running subsystem-level
307 type's run-time PM callbacks, make sure that all of the pending run-time 308 run-time PM callbacks for the device, make sure that all of the pending
308 PM operations on the device are either completed or canceled; returns 309 run-time PM operations on the device are either completed or canceled;
309 1 if there was a resume request pending and it was necessary to execute 310 returns 1 if there was a resume request pending and it was necessary to
310 ->runtime_resume() for the device's bus type to satisfy that request, 311 execute the subsystem-level resume callback for the device to satisfy that
311 otherwise 0 is returned 312 request, otherwise 0 is returned
312 313
313 void pm_suspend_ignore_children(struct device *dev, bool enable); 314 void pm_suspend_ignore_children(struct device *dev, bool enable);
314 - set/unset the power.ignore_children flag of the device 315 - set/unset the power.ignore_children flag of the device
@@ -378,5 +379,55 @@ pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,
378they will fail returning -EAGAIN, because the device's usage counter is 379they will fail returning -EAGAIN, because the device's usage counter is
379incremented by the core before executing ->probe() and ->remove(). Still, it 380incremented by the core before executing ->probe() and ->remove(). Still, it
380may be desirable to suspend the device as soon as ->probe() or ->remove() has 381may be desirable to suspend the device as soon as ->probe() or ->remove() has
381finished, so the PM core uses pm_runtime_idle_sync() to invoke the device bus 382finished, so the PM core uses pm_runtime_idle_sync() to invoke the
382type's ->runtime_idle() callback at that time. 383subsystem-level idle callback for the device at that time.
384
3856. Run-time PM and System Sleep
386
387Run-time PM and system sleep (i.e., system suspend and hibernation, also known
388as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
389ways. If a device is active when a system sleep starts, everything is
390straightforward. But what should happen if the device is already suspended?
391
392The device may have different wake-up settings for run-time PM and system sleep.
393For example, remote wake-up may be enabled for run-time suspend but disallowed
394for system sleep (device_may_wakeup(dev) returns 'false'). When this happens,
395the subsystem-level system suspend callback is responsible for changing the
396device's wake-up setting (it may leave that to the device driver's system
397suspend routine). It may be necessary to resume the device and suspend it again
398in order to do so. The same is true if the driver uses different power levels
399or other settings for run-time suspend and system sleep.
400
401During system resume, devices generally should be brought back to full power,
402even if they were suspended before the system sleep began. There are several
403reasons for this, including:
404
405 * The device might need to switch power levels, wake-up settings, etc.
406
407 * Remote wake-up events might have been lost by the firmware.
408
409 * The device's children may need the device to be at full power in order
410 to resume themselves.
411
412 * The driver's idea of the device state may not agree with the device's
413 physical state. This can happen during resume from hibernation.
414
415 * The device might need to be reset.
416
417 * Even though the device was suspended, if its usage counter was > 0 then most
418 likely it would need a run-time resume in the near future anyway.
419
420 * Always going back to full power is simplest.
421
422If the device was suspended before the sleep began, then its run-time PM status
423will have to be updated to reflect the actual post-system sleep status. The way
424to do this is:
425
426 pm_runtime_disable(dev);
427 pm_runtime_set_active(dev);
428 pm_runtime_enable(dev);
429
430The PM core always increments the run-time usage counter before calling the
431->prepare() callback and decrements it after calling the ->complete() callback.
432Hence disabling run-time PM temporarily like this will not cause any run-time
433suspend callbacks to be lost.
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
new file mode 100644
index 000000000000..71e39cf3215b
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
@@ -0,0 +1,42 @@
1* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
2
3The OpenPIC specification does not specify which interrupt source has to
4become which interrupt number. This is up to the software implementation
5of the interrupt controller. The only requirement is that every
6interrupt source has to have an unique interrupt number / vector number.
7To accomplish this the current implementation assigns the number zero to
8the first source, the number one to the second source and so on until
9all interrupt sources have their unique number.
10Usually the assigned vector number equals the interrupt number mentioned
11in the documentation for a given core / CPU. This is however not true
12for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
13between internal and external interrupt sources and starts counting at
14zero for both of them.
15
16So what to write for external interrupt source X or internal interrupt
17source Y into the device tree? Here is an example:
18
19The memory map for the interrupt controller in the MPC8544[0] shows,
20that the first interrupt source starts at 0x5_0000 (PIC Register Address
21Map-Interrupt Source Configuration Registers). This source becomes the
22number zero therefore:
23 External interrupt 0 = interrupt number 0
24 External interrupt 1 = interrupt number 1
25 External interrupt 2 = interrupt number 2
26 ...
27Every interrupt number allocates 0x20 bytes register space. So to get
28its number it is sufficient to shift the lower 16bits to right by five.
29So for the external interrupt 10 we have:
30 0x0140 >> 5 = 10
31
32After the external sources, the internal sources follow. The in core I2C
33controller on the MPC8544 for instance has the internal source number
3427. Oo obtain its interrupt number we take the lower 16bits of its memory
35address (0x5_0560) and shift it right:
36 0x0560 >> 5 = 43
37
38Therefore the I2C device node for the MPC8544 CPU has to have the
39interrupt number 43 specified in the device tree.
40
41[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
42 MPC8544ERM Rev. 1 10/2007
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index e93affff3af8..e72cee9e2a71 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -403,4 +403,5 @@ STAC9872
403Cirrus Logic CS4206/4207 403Cirrus Logic CS4206/4207
404======================== 404========================
405 mbp55 MacBook Pro 5,5 405 mbp55 MacBook Pro 5,5
406 imac27 IMac 27 Inch
406 auto BIOS setup (default) 407 auto BIOS setup (default)
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index a452227361b1..5effa5bd993b 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -26,13 +26,33 @@ Procedure for submitting patches to the -stable tree:
26 26
27 - Send the patch, after verifying that it follows the above rules, to 27 - Send the patch, after verifying that it follows the above rules, to
28 stable@kernel.org. 28 stable@kernel.org.
29 - To have the patch automatically included in the stable tree, add the
30 the tag
31 Cc: stable@kernel.org
32 in the sign-off area. Once the patch is merged it will be applied to
33 the stable tree without anything else needing to be done by the author
34 or subsystem maintainer.
35 - If the patch requires other patches as prerequisites which can be
36 cherry-picked than this can be specified in the following format in
37 the sign-off area:
38
39 Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle
40 Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
41 Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic
42 Cc: <stable@kernel.org> # .32.x
43 Signed-off-by: Ingo Molnar <mingo@elte.hu>
44
45 The tag sequence has the meaning of:
46 git cherry-pick a1f84a3
47 git cherry-pick 1b9508f
48 git cherry-pick fd21073
49 git cherry-pick <this commit>
50
29 - The sender will receive an ACK when the patch has been accepted into the 51 - The sender will receive an ACK when the patch has been accepted into the
30 queue, or a NAK if the patch is rejected. This response might take a few 52 queue, or a NAK if the patch is rejected. This response might take a few
31 days, according to the developer's schedules. 53 days, according to the developer's schedules.
32 - If accepted, the patch will be added to the -stable queue, for review by 54 - If accepted, the patch will be added to the -stable queue, for review by
33 other developers and by the relevant subsystem maintainer. 55 other developers and by the relevant subsystem maintainer.
34 - If the stable@kernel.org address is added to a patch, when it goes into
35 Linus's tree it will automatically be emailed to the stable team.
36 - Security patches should not be sent to this alias, but instead to the 56 - Security patches should not be sent to this alias, but instead to the
37 documented security@kernel.org address. 57 documented security@kernel.org address.
38 58
diff --git a/Documentation/trace/events-kmem.txt b/Documentation/trace/events-kmem.txt
index 6ef2a8652e17..aa82ee4a5a87 100644
--- a/Documentation/trace/events-kmem.txt
+++ b/Documentation/trace/events-kmem.txt
@@ -1,7 +1,7 @@
1 Subsystem Trace Points: kmem 1 Subsystem Trace Points: kmem
2 2
3The tracing system kmem captures events related to object and page allocation 3The kmem tracing system captures events related to object and page allocation
4within the kernel. Broadly speaking there are four major subheadings. 4within the kernel. Broadly speaking there are five major subheadings.
5 5
6 o Slab allocation of small objects of unknown type (kmalloc) 6 o Slab allocation of small objects of unknown type (kmalloc)
7 o Slab allocation of small objects of known type 7 o Slab allocation of small objects of known type
@@ -9,7 +9,7 @@ within the kernel. Broadly speaking there are four major subheadings.
9 o Per-CPU Allocator Activity 9 o Per-CPU Allocator Activity
10 o External Fragmentation 10 o External Fragmentation
11 11
12This document will describe what each of the tracepoints are and why they 12This document describes what each of the tracepoints is and why they
13might be useful. 13might be useful.
14 14
151. Slab allocation of small objects of unknown type 151. Slab allocation of small objects of unknown type
@@ -34,7 +34,7 @@ kmem_cache_free call_site=%lx ptr=%p
34These events are similar in usage to the kmalloc-related events except that 34These events are similar in usage to the kmalloc-related events except that
35it is likely easier to pin the event down to a specific cache. At the time 35it is likely easier to pin the event down to a specific cache. At the time
36of writing, no information is available on what slab is being allocated from, 36of writing, no information is available on what slab is being allocated from,
37but the call_site can usually be used to extrapolate that information 37but the call_site can usually be used to extrapolate that information.
38 38
393. Page allocation 393. Page allocation
40================== 40==================
@@ -80,9 +80,9 @@ event indicating whether it is for a percpu_refill or not.
80When the per-CPU list is too full, a number of pages are freed, each one 80When the per-CPU list is too full, a number of pages are freed, each one
81which triggers a mm_page_pcpu_drain event. 81which triggers a mm_page_pcpu_drain event.
82 82
83The individual nature of the events are so that pages can be tracked 83The individual nature of the events is so that pages can be tracked
84between allocation and freeing. A number of drain or refill pages that occur 84between allocation and freeing. A number of drain or refill pages that occur
85consecutively imply the zone->lock being taken once. Large amounts of PCP 85consecutively imply the zone->lock being taken once. Large amounts of per-CPU
86refills and drains could imply an imbalance between CPUs where too much work 86refills and drains could imply an imbalance between CPUs where too much work
87is being concentrated in one place. It could also indicate that the per-CPU 87is being concentrated in one place. It could also indicate that the per-CPU
88lists should be a larger size. Finally, large amounts of refills on one CPU 88lists should be a larger size. Finally, large amounts of refills on one CPU
@@ -102,6 +102,6 @@ is important.
102 102
103Large numbers of this event implies that memory is fragmenting and 103Large numbers of this event implies that memory is fragmenting and
104high-order allocations will start failing at some time in the future. One 104high-order allocations will start failing at some time in the future. One
105means of reducing the occurange of this event is to increase the size of 105means of reducing the occurrence of this event is to increase the size of
106min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where 106min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where
107pageblock_size is usually the size of the default hugepage size. 107pageblock_size is usually the size of the default hugepage size.
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index c7c1dc2f8017..3bf6818c8cf5 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -71,12 +71,10 @@ being accessed through sysfs, then it definitely is idle.
71 Forms of dynamic PM 71 Forms of dynamic PM
72 ------------------- 72 -------------------
73 73
74Dynamic suspends can occur in two ways: manual and automatic. 74Dynamic suspends occur when the kernel decides to suspend an idle
75"Manual" means that the user has told the kernel to suspend a device, 75device. This is called "autosuspend" for short. In general, a device
76whereas "automatic" means that the kernel has decided all by itself to 76won't be autosuspended unless it has been idle for some minimum period
77suspend a device. Automatic suspend is called "autosuspend" for 77of time, the so-called idle-delay time.
78short. In general, a device won't be autosuspended unless it has been
79idle for some minimum period of time, the so-called idle-delay time.
80 78
81Of course, nothing the kernel does on its own initiative should 79Of course, nothing the kernel does on its own initiative should
82prevent the computer or its devices from working properly. If a 80prevent the computer or its devices from working properly. If a
@@ -96,10 +94,11 @@ idle.
96We can categorize power management events in two broad classes: 94We can categorize power management events in two broad classes:
97external and internal. External events are those triggered by some 95external and internal. External events are those triggered by some
98agent outside the USB stack: system suspend/resume (triggered by 96agent outside the USB stack: system suspend/resume (triggered by
99userspace), manual dynamic suspend/resume (also triggered by 97userspace), manual dynamic resume (also triggered by userspace), and
100userspace), and remote wakeup (triggered by the device). Internal 98remote wakeup (triggered by the device). Internal events are those
101events are those triggered within the USB stack: autosuspend and 99triggered within the USB stack: autosuspend and autoresume. Note that
102autoresume. 100all dynamic suspend events are internal; external agents are not
101allowed to issue dynamic suspends.
103 102
104 103
105 The user interface for dynamic PM 104 The user interface for dynamic PM
@@ -145,9 +144,9 @@ relevant attribute files are: wakeup, level, and autosuspend.
145 number of seconds the device should remain idle before 144 number of seconds the device should remain idle before
146 the kernel will autosuspend it (the idle-delay time). 145 the kernel will autosuspend it (the idle-delay time).
147 The default is 2. 0 means to autosuspend as soon as 146 The default is 2. 0 means to autosuspend as soon as
148 the device becomes idle, and -1 means never to 147 the device becomes idle, and negative values mean
149 autosuspend. You can write a number to the file to 148 never to autosuspend. You can write a number to the
150 change the autosuspend idle-delay time. 149 file to change the autosuspend idle-delay time.
151 150
152Writing "-1" to power/autosuspend and writing "on" to power/level do 151Writing "-1" to power/autosuspend and writing "on" to power/level do
153essentially the same thing -- they both prevent the device from being 152essentially the same thing -- they both prevent the device from being
@@ -377,9 +376,9 @@ the device hasn't been idle for long enough, a delayed workqueue
377routine is automatically set up to carry out the operation when the 376routine is automatically set up to carry out the operation when the
378autosuspend idle-delay has expired. 377autosuspend idle-delay has expired.
379 378
380Autoresume attempts also can fail. This will happen if power/level is 379Autoresume attempts also can fail, although failure would mean that
381set to "suspend" or if the device doesn't manage to resume properly. 380the device is no longer present or operating properly. Unlike
382Unlike autosuspend, there's no delay for an autoresume. 381autosuspend, there's no delay for an autoresume.
383 382
384 383
385 Other parts of the driver interface 384 Other parts of the driver interface
@@ -527,13 +526,3 @@ succeed, it may still remain active and thus cause the system to
527resume as soon as the system suspend is complete. Or the remote 526resume as soon as the system suspend is complete. Or the remote
528wakeup may fail and get lost. Which outcome occurs depends on timing 527wakeup may fail and get lost. Which outcome occurs depends on timing
529and on the hardware and firmware design. 528and on the hardware and firmware design.
530
531More interestingly, a device might undergo a manual resume or
532autoresume during system suspend. With current kernels this shouldn't
533happen, because manual resumes must be initiated by userspace and
534autoresumes happen in response to I/O requests, but all user processes
535and I/O should be quiescent during a system suspend -- thanks to the
536freezer. However there are plans to do away with the freezer, which
537would mean these things would become possible. If and when this comes
538about, the USB core will carefully arrange matters so that either type
539of resume will block until the entire system has resumed.