aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2007-05-08 03:24:07 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 14:14:59 -0400
commit5b7952021289b6d04d8c62c0f13acce570730dcd (patch)
tree57bb1363826b41bb2809a0a980f2bf78555bbf73 /Documentation
parent8e2c20023f34b652605a5fb7c68bb843d2b100a8 (diff)
Documentation: Ask driver writers to provide PM support
Add a paragraph in Documentation/SubmittingDrivers requesting that the basic PM support be provided by new device drivers. Add two new documents in Documentation/power/ giving general instructions on debugging the suspend/resume functionality and testing the suspend and resume support in device drivers. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Cc: David Brownell <david-b@pacbell.net> Cc: Nigel Cunningham <ncunningham@linuxmail.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/SubmittingDrivers15
-rw-r--r--Documentation/power/basic-pm-debugging.txt106
-rw-r--r--Documentation/power/drivers-testing.txt42
3 files changed, 163 insertions, 0 deletions
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
index 58bead05eabb..d7e26427e426 100644
--- a/Documentation/SubmittingDrivers
+++ b/Documentation/SubmittingDrivers
@@ -87,6 +87,21 @@ Clarity: It helps if anyone can see how to fix the driver. It helps
87 driver that intentionally obfuscates how the hardware works 87 driver that intentionally obfuscates how the hardware works
88 it will go in the bitbucket. 88 it will go in the bitbucket.
89 89
90PM support: Since Linux is used on many portable and desktop systems, your
91 driver is likely to be used on such a system and therefore it
92 should support basic power management by implementing, if
93 necessary, the .suspend and .resume methods used during the
94 system-wide suspend and resume transitions. You should verify
95 that your driver correctly handles the suspend and resume, but
96 if you are unable to ensure that, please at least define the
97 .suspend method returning the -ENOSYS ("Function not
98 implemented") error. You should also try to make sure that your
99 driver uses as little power as possible when it's not doing
100 anything. For the driver testing instructions see
101 Documentation/power/drivers-testing.txt and for a relatively
102 complete overview of the power management issues related to
103 drivers see Documentation/power/devices.txt .
104
90Control: In general if there is active maintainance of a driver by 105Control: In general if there is active maintainance of a driver by
91 the author then patches will be redirected to them unless 106 the author then patches will be redirected to them unless
92 they are totally obvious and without need of checking. 107 they are totally obvious and without need of checking.
diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt
new file mode 100644
index 000000000000..1a85e2b964dc
--- /dev/null
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -0,0 +1,106 @@
1Debugging suspend and resume
2 (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
3
41. Testing suspend to disk (STD)
5
6To verify that the STD works, you can try to suspend in the "reboot" mode:
7
8# echo reboot > /sys/power/disk
9# echo disk > /sys/power/state
10
11and the system should suspend, reboot, resume and get back to the command prompt
12where you have started the transition. If that happens, the STD is most likely
13to work correctly, but you need to repeat the test at least a couple of times in
14a row for confidence. This is necessary, because some problems only show up on
15a second attempt at suspending and resuming the system. You should also test
16the "platform" and "shutdown" modes of suspend:
17
18# echo platform > /sys/power/disk
19# echo disk > /sys/power/state
20
21or
22
23# echo shutdown > /sys/power/disk
24# echo disk > /sys/power/state
25
26in which cases you will have to press the power button to make the system
27resume. If that does not work, you will need to identify what goes wrong.
28
29a) Test mode of STD
30
31To verify if there are any drivers that cause problems you can run the STD
32in the test mode:
33
34# echo test > /sys/power/disk
35# echo disk > /sys/power/state
36
37in which case the system should freeze tasks, suspend devices, disable nonboot
38CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw
39tasks and return to your command prompt. If that fails, most likely there is
40a driver that fails to either suspend or resume (in the latter case the system
41may hang or be unstable after the test, so please take that into consideration).
42To find this driver, you can carry out a binary search according to the rules:
43- if the test fails, unload a half of the drivers currently loaded and repeat
44(that would probably involve rebooting the system, so always note what drivers
45have been loaded before the test),
46- if the test succeeds, load a half of the drivers you have unloaded most
47recently and repeat.
48
49Once you have found the failing driver (there can be more than just one of
50them), you have to unload it every time before the STD transition. In that case
51please make sure to report the problem with the driver.
52
53It is also possible that a cycle can still fail after you have unloaded
54all modules. In that case, you would want to look in your kernel configuration
55for the drivers that can be compiled as modules (testing again with them as
56modules), and possibly also try boot time options such as "noapic" or "noacpi".
57
58b) Testing minimal configuration
59
60If the test mode of STD works, you can boot the system with "init=/bin/bash"
61and attempt to suspend in the "reboot", "shutdown" and "platform" modes. If
62that does not work, there probably is a problem with a driver statically
63compiled into the kernel and you can try to compile more drivers as modules,
64so that they can be tested individually. Otherwise, there is a problem with a
65modular driver and you can find it by loading a half of the modules you normally
66use and binary searching in accordance with the algorithm:
67- if there are n modules loaded and the attempt to suspend and resume fails,
68unload n/2 of the modules and try again (that would probably involve rebooting
69the system),
70- if there are n modules loaded and the attempt to suspend and resume succeeds,
71load n/2 modules more and try again.
72
73Again, if you find the offending module(s), it(they) must be unloaded every time
74before the STD transition, and please report the problem with it(them).
75
76c) Advanced debugging
77
78In case the STD does not work on your system even in the minimal configuration
79and compiling more drivers as modules is not practical or some modules cannot
80be unloaded, you can use one of the more advanced debugging techniques to find
81the problem. First, if there is a serial port in your box, you can set the
82CONFIG_DISABLE_CONSOLE_SUSPEND kernel configuration option and try to log kernel
83messages using the serial console. This may provide you with some information
84about the reasons of the suspend (resume) failure. Alternatively, it may be
85possible to use a FireWire port for debugging with firescope
86(ftp://ftp.firstfloor.org/pub/ak/firescope/). On i386 it is also possible to
87use the PM_TRACE mechanism documented in Documentation/s2ram.txt .
88
892. Testing suspend to RAM (STR)
90
91To verify that the STR works, it is generally more convenient to use the s2ram
92tool available from http://suspend.sf.net and documented at
93http://en.opensuse.org/s2ram . However, before doing that it is recommended to
94carry out the procedure described in section 1.
95
96Assume you have resolved the problems with the STD and you have found some
97failing drivers. These drivers are also likely to fail during the STR or
98during the resume, so it is better to unload them every time before the STR
99transition. Now, you can follow the instructions at
100http://en.opensuse.org/s2ram to test the system, but if it does not work
101"out of the box", you may need to boot it with "init=/bin/bash" and test
102s2ram in the minimal configuration. In that case, you may be able to search
103for failing drivers by following the procedure analogous to the one described in
1041b). If you find some failing drivers, you will have to unload them every time
105before the STR transition (ie. before you run s2ram), and please report the
106problems with them.
diff --git a/Documentation/power/drivers-testing.txt b/Documentation/power/drivers-testing.txt
new file mode 100644
index 000000000000..33016c2f18dd
--- /dev/null
+++ b/Documentation/power/drivers-testing.txt
@@ -0,0 +1,42 @@
1Testing suspend and resume support in device drivers
2 (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
3
41. Preparing the test system
5
6Unfortunately, to effectively test the support for the system-wide suspend and
7resume transitions in a driver, it is necessary to suspend and resume a fully
8functional system with this driver loaded. Moreover, that should be done
9several times, preferably several times in a row, and separately for the suspend
10to disk (STD) and the suspend to RAM (STR) transitions, because each of these
11cases involves different ordering of operations and different interactions with
12the machine's BIOS.
13
14Of course, for this purpose the test system has to be known to suspend and
15resume without the driver being tested. Thus, if possible, you should first
16resolve all suspend/resume-related problems in the test system before you start
17testing the new driver. Please see Documents/power/basic-pm-debugging.txt for
18more information about the debugging of suspend/resume functionality.
19
202. Testing the driver
21
22Once you have resolved the suspend/resume-related problems with your test system
23without the new driver, you are ready to test it:
24
25a) Build the driver as a module, load it and try the STD in the test mode (see:
26Documents/power/basic-pm-debugging.txt, 1a)).
27
28b) Load the driver and attempt to suspend to disk in the "reboot", "shutdown"
29and "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
30
31c) Compile the driver directly into the kernel and try the STD in the test mode.
32
33d) Attempt to suspend to disk with the driver compiled directly into the kernel
34in the "reboot", "shutdown" and "platform" modes.
35
36e) Attempt to suspend to RAM using the s2ram tool with the driver loaded (see:
37Documents/power/basic-pm-debugging.txt, 2). As far as the STR tests are
38concerned, it should not matter whether or not the driver is built as a module.
39
40Each of the above tests should be repeated several times and the STD tests
41should be mixed with the STR tests. If any of them fails, the driver cannot be
42regarded as suspend/resume-safe.