aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/power/drivers-testing.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/power/drivers-testing.txt')
-rw-r--r--Documentation/power/drivers-testing.txt42
1 files changed, 42 insertions, 0 deletions
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.