path: root/Documentation/power/drivers-testing.txt
diff options
authorRafael J. Wysocki <rjw@sisk.pl>2007-05-08 00:24:07 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 11:14:59 -0700
commit5b7952021289b6d04d8c62c0f13acce570730dcd (patch)
tree57bb1363826b41bb2809a0a980f2bf78555bbf73 /Documentation/power/drivers-testing.txt
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/power/drivers-testing.txt')
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 @@
+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
+functional system with this driver loaded. Moreover, that should be done
+several times, preferably several times in a row, and separately for the suspend
+to disk (STD) and the suspend to RAM (STR) transitions, because each of these
+cases involves different ordering of operations and different interactions with
+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 Documents/power/basic-pm-debugging.txt 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 STD in the test mode (see:
+Documents/power/basic-pm-debugging.txt, 1a)).
+b) Load the driver and attempt to suspend to disk in the "reboot", "shutdown"
+and "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
+c) Compile the driver directly into the kernel and try the STD in the test mode.
+d) Attempt to suspend to disk with the driver compiled directly into the kernel
+in the "reboot", "shutdown" and "platform" modes.
+e) Attempt to suspend to RAM using the s2ram tool with the driver loaded (see:
+Documents/power/basic-pm-debugging.txt, 2). As far as the STR tests are
+concerned, it should not matter whether or not the driver is built as a module.
+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
+regarded as suspend/resume-safe.