aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/driver-model/driver.txt
diff options
context:
space:
mode:
authorRussell King <rmk@arm.linux.org.uk>2005-10-28 12:52:56 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2005-10-28 12:52:56 -0400
commit9480e307cd88ef09ec9294c7d97ebec18e6d2221 (patch)
tree967e26d3a23c24dd52b114d672312c207714308c /Documentation/driver-model/driver.txt
parenta3a3395e487abc4c1371fe319a8ecbb3913a70a4 (diff)
[PATCH] DRIVER MODEL: Get rid of the obsolete tri-level suspend/resume callbacks
In PM v1, all devices were called at SUSPEND_DISABLE level. Then all devices were called at SUSPEND_SAVE_STATE level, and finally SUSPEND_POWER_DOWN level. However, with PM v2, to maintain compatibility for platform devices, I arranged for the PM v2 suspend/resume callbacks to call the old PM v1 suspend/resume callbacks three times with each level in order so that existing drivers continued to work. Since this is obsolete infrastructure which is no longer necessary, we can remove it. Here's an (untested) patch to do exactly that. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/driver-model/driver.txt')
-rw-r--r--Documentation/driver-model/driver.txt60
1 files changed, 2 insertions, 58 deletions
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index fabaca1ab1b0..7c26bfae4ba0 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -196,67 +196,11 @@ it into a supported low-power state.
196 196
197 int (*suspend) (struct device * dev, pm_message_t state, u32 level); 197 int (*suspend) (struct device * dev, pm_message_t state, u32 level);
198 198
199suspend is called to put the device in a low power state. There are 199suspend is called to put the device in a low power state.
200several stages to successfully suspending a device, which is denoted in
201the @level parameter. Breaking the suspend transition into several
202stages affords the platform flexibility in performing device power
203management based on the requirements of the system and the
204user-defined policy.
205
206SUSPEND_NOTIFY notifies the device that a suspend transition is about
207to happen. This happens on system power state transitions to verify
208that all devices can successfully suspend.
209
210A driver may choose to fail on this call, which should cause the
211entire suspend transition to fail. A driver should fail only if it
212knows that the device will not be able to be resumed properly when the
213system wakes up again. It could also fail if it somehow determines it
214is in the middle of an operation too important to stop.
215
216SUSPEND_DISABLE tells the device to stop I/O transactions. When it
217stops transactions, or what it should do with unfinished transactions
218is a policy of the driver. After this call, the driver should not
219accept any other I/O requests.
220
221SUSPEND_SAVE_STATE tells the device to save the context of the
222hardware. This includes any bus-specific hardware state and
223device-specific hardware state. A pointer to this saved state can be
224stored in the device's saved_state field.
225
226SUSPEND_POWER_DOWN tells the driver to place the device in the low
227power state requested.
228
229Whether suspend is called with a given level is a policy of the
230platform. Some levels may be omitted; drivers must not assume the
231reception of any level. However, all levels must be called in the
232order above; i.e. notification will always come before disabling;
233disabling the device will come before suspending the device.
234
235All calls are made with interrupts enabled, except for the
236SUSPEND_POWER_DOWN level.
237 200
238 int (*resume) (struct device * dev, u32 level); 201 int (*resume) (struct device * dev, u32 level);
239 202
240Resume is used to bring a device back from a low power state. Like the 203Resume is used to bring a device back from a low power state.
241suspend transition, it happens in several stages.
242
243RESUME_POWER_ON tells the driver to set the power state to the state
244before the suspend call (The device could have already been in a low
245power state before the suspend call to put in a lower power state).
246
247RESUME_RESTORE_STATE tells the driver to restore the state saved by
248the SUSPEND_SAVE_STATE suspend call.
249
250RESUME_ENABLE tells the driver to start accepting I/O transactions
251again. Depending on driver policy, the device may already have pending
252I/O requests.
253
254RESUME_POWER_ON is called with interrupts disabled. The other resume
255levels are called with interrupts enabled.
256
257As with the various suspend stages, the driver must not assume that
258any other resume calls have been or will be made. Each call should be
259self-contained and not dependent on any external state.
260 204
261 205
262Attributes 206Attributes