diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/DocBook/device-drivers.tmpl | 5 | ||||
| -rw-r--r-- | Documentation/DocBook/deviceiobook.tmpl | 2 | ||||
| -rw-r--r-- | Documentation/power/basic-pm-debugging.txt | 2 | ||||
| -rw-r--r-- | Documentation/power/freezing-of-tasks.txt | 8 | ||||
| -rw-r--r-- | Documentation/thermal/sysfs-api.txt | 2 |
5 files changed, 10 insertions, 9 deletions
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index b638e50cf8f..2f7fd436084 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -50,7 +50,9 @@ <sect1><title>Delaying, scheduling, and timer routines</title> !Iinclude/linux/sched.h -!Ekernel/sched.c +!Ekernel/sched/core.c +!Ikernel/sched/cpupri.c +!Ikernel/sched/fair.c !Iinclude/linux/completion.h !Ekernel/timer.c </sect1> @@ -216,7 +218,6 @@ X!Isound/sound_firmware.c <chapter id="uart16x50"> <title>16x50 UART Driver</title> -!Iinclude/linux/serial_core.h !Edrivers/tty/serial/serial_core.c !Edrivers/tty/serial/8250.c </chapter> diff --git a/Documentation/DocBook/deviceiobook.tmpl b/Documentation/DocBook/deviceiobook.tmpl index c1ed6a49e59..54199a0dcf9 100644 --- a/Documentation/DocBook/deviceiobook.tmpl +++ b/Documentation/DocBook/deviceiobook.tmpl @@ -317,7 +317,7 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags) <chapter id="pubfunctions"> <title>Public Functions Provided</title> !Iarch/x86/include/asm/io.h -!Elib/iomap.c +!Elib/pci_iomap.c </chapter> </book> diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index 40a4c65f380..262acf56fa7 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -15,7 +15,7 @@ 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 you machine fails +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 diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index 6ccb68f68da..ebd7490ef1d 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt @@ -120,10 +120,10 @@ So in practice, the 'at all' may become a 'why freeze kernel threads?' and freezing user threads I don't find really objectionable." Still, there are kernel threads that may want to be freezable. For example, if -a kernel that belongs to a device driver accesses the device directly, it in -principle needs to know when the device is suspended, so that it doesn't try to -access it at that time. However, if the kernel thread is freezable, it will be -frozen before the driver's .suspend() callback is executed and it will be +a kernel thread that belongs to a device driver accesses the device directly, it +in principle needs to know when the device is suspended, so that it doesn't try +to access it at that time. However, if the kernel thread is freezable, it will +be frozen before the driver's .suspend() callback is executed and it will be thawed after the driver's .resume() callback has run, so it won't be accessing the device while it's suspended. diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index b61e46f449a..1733ab947a9 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -284,7 +284,7 @@ method, the sys I/F structure will be built like this: The framework includes a simple notification mechanism, in the form of a netlink event. Netlink socket initialization is done during the _init_ of the framework. Drivers which intend to use the notification mechanism -just need to call generate_netlink_event() with two arguments viz +just need to call thermal_generate_netlink_event() with two arguments viz (originator, event). Typically the originator will be an integer assigned to a thermal_zone_device when it registers itself with the framework. The event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL, |