|
@@ -196,67 +196,11 @@ it into a supported low-power state.
|
|
|
|
|
|
int (*suspend) (struct device * dev, pm_message_t state, u32 level);
|
|
|
|
|
|
-suspend is called to put the device in a low power state. There are
|
|
|
-several stages to successfully suspending a device, which is denoted in
|
|
|
-the @level parameter. Breaking the suspend transition into several
|
|
|
-stages affords the platform flexibility in performing device power
|
|
|
-management based on the requirements of the system and the
|
|
|
-user-defined policy.
|
|
|
-
|
|
|
-SUSPEND_NOTIFY notifies the device that a suspend transition is about
|
|
|
-to happen. This happens on system power state transitions to verify
|
|
|
-that all devices can successfully suspend.
|
|
|
-
|
|
|
-A driver may choose to fail on this call, which should cause the
|
|
|
-entire suspend transition to fail. A driver should fail only if it
|
|
|
-knows that the device will not be able to be resumed properly when the
|
|
|
-system wakes up again. It could also fail if it somehow determines it
|
|
|
-is in the middle of an operation too important to stop.
|
|
|
-
|
|
|
-SUSPEND_DISABLE tells the device to stop I/O transactions. When it
|
|
|
-stops transactions, or what it should do with unfinished transactions
|
|
|
-is a policy of the driver. After this call, the driver should not
|
|
|
-accept any other I/O requests.
|
|
|
-
|
|
|
-SUSPEND_SAVE_STATE tells the device to save the context of the
|
|
|
-hardware. This includes any bus-specific hardware state and
|
|
|
-device-specific hardware state. A pointer to this saved state can be
|
|
|
-stored in the device's saved_state field.
|
|
|
-
|
|
|
-SUSPEND_POWER_DOWN tells the driver to place the device in the low
|
|
|
-power state requested.
|
|
|
-
|
|
|
-Whether suspend is called with a given level is a policy of the
|
|
|
-platform. Some levels may be omitted; drivers must not assume the
|
|
|
-reception of any level. However, all levels must be called in the
|
|
|
-order above; i.e. notification will always come before disabling;
|
|
|
-disabling the device will come before suspending the device.
|
|
|
-
|
|
|
-All calls are made with interrupts enabled, except for the
|
|
|
-SUSPEND_POWER_DOWN level.
|
|
|
+suspend is called to put the device in a low power state.
|
|
|
|
|
|
int (*resume) (struct device * dev, u32 level);
|
|
|
|
|
|
-Resume is used to bring a device back from a low power state. Like the
|
|
|
-suspend transition, it happens in several stages.
|
|
|
-
|
|
|
-RESUME_POWER_ON tells the driver to set the power state to the state
|
|
|
-before the suspend call (The device could have already been in a low
|
|
|
-power state before the suspend call to put in a lower power state).
|
|
|
-
|
|
|
-RESUME_RESTORE_STATE tells the driver to restore the state saved by
|
|
|
-the SUSPEND_SAVE_STATE suspend call.
|
|
|
-
|
|
|
-RESUME_ENABLE tells the driver to start accepting I/O transactions
|
|
|
-again. Depending on driver policy, the device may already have pending
|
|
|
-I/O requests.
|
|
|
-
|
|
|
-RESUME_POWER_ON is called with interrupts disabled. The other resume
|
|
|
-levels are called with interrupts enabled.
|
|
|
-
|
|
|
-As with the various suspend stages, the driver must not assume that
|
|
|
-any other resume calls have been or will be made. Each call should be
|
|
|
-self-contained and not dependent on any external state.
|
|
|
+Resume is used to bring a device back from a low power state.
|
|
|
|
|
|
|
|
|
Attributes
|