aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/driver-model
diff options
context:
space:
mode:
authorLen Brown <len.brown@intel.com>2005-12-06 17:31:30 -0500
committerLen Brown <len.brown@intel.com>2005-12-06 17:31:30 -0500
commit3d5271f9883cba7b54762bc4fe027d4172f06db7 (patch)
treeab8a881a14478598a0c8bda0d26c62cdccfffd6d /Documentation/driver-model
parent378b2556f4e09fa6f87ff0cb5c4395ff28257d02 (diff)
parent9115a6c787596e687df03010d97fccc5e0762506 (diff)
Pull release into acpica branch
Diffstat (limited to 'Documentation/driver-model')
-rw-r--r--Documentation/driver-model/driver.txt68
-rw-r--r--Documentation/driver-model/porting.txt2
2 files changed, 7 insertions, 63 deletions
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index fabaca1ab1b0..59806c9761f7 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -14,8 +14,8 @@ struct device_driver {
14 int (*probe) (struct device * dev); 14 int (*probe) (struct device * dev);
15 int (*remove) (struct device * dev); 15 int (*remove) (struct device * dev);
16 16
17 int (*suspend) (struct device * dev, pm_message_t state, u32 level); 17 int (*suspend) (struct device * dev, pm_message_t state);
18 int (*resume) (struct device * dev, u32 level); 18 int (*resume) (struct device * dev);
19}; 19};
20 20
21 21
@@ -194,69 +194,13 @@ device; i.e. anything in the device's driver_data field.
194If the device is still present, it should quiesce the device and place 194If the device is still present, it should quiesce the device and place
195it into a supported low-power state. 195it 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);
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 200
206SUSPEND_NOTIFY notifies the device that a suspend transition is about 201 int (*resume) (struct device * dev);
207to happen. This happens on system power state transitions to verify
208that all devices can successfully suspend.
209 202
210A driver may choose to fail on this call, which should cause the 203Resume is used to bring a device back from a low power state.
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
238 int (*resume) (struct device * dev, u32 level);
239
240Resume is used to bring a device back from a low power state. Like the
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
diff --git a/Documentation/driver-model/porting.txt b/Documentation/driver-model/porting.txt
index ff2fef2107f0..98b233cb8b36 100644
--- a/Documentation/driver-model/porting.txt
+++ b/Documentation/driver-model/porting.txt
@@ -350,7 +350,7 @@ When a driver is registered, the bus's list of devices is iterated
350over. bus->match() is called for each device that is not already 350over. bus->match() is called for each device that is not already
351claimed by a driver. 351claimed by a driver.
352 352
353When a device is successfully bound to a device, device->driver is 353When a device is successfully bound to a driver, device->driver is
354set, the device is added to a per-driver list of devices, and a 354set, the device is added to a per-driver list of devices, and a
355symlink is created in the driver's sysfs directory that points to the 355symlink is created in the driver's sysfs directory that points to the
356device's physical directory: 356device's physical directory: