X-Git-Url: http://pilppa.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=include%2Flinux%2Fpm.h;h=21db05ac7c0b3753bc8f0eafd4381cb30c84712c;hb=704232c2718c9d4b3375ec15a14fc0397970c449;hp=658c1b93d5bb22d4e8efbe30d299e06a2e4ba834;hpb=789e7dc8ee6cfb7928208b077d0799d81196e9bb;p=linux-2.6-omap-h63xx.git diff --git a/include/linux/pm.h b/include/linux/pm.h index 658c1b93d5b..21db05ac7c0 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -116,17 +116,52 @@ typedef int __bitwise suspend_disk_method_t; #define PM_DISK_PLATFORM ((__force suspend_disk_method_t) 2) #define PM_DISK_SHUTDOWN ((__force suspend_disk_method_t) 3) #define PM_DISK_REBOOT ((__force suspend_disk_method_t) 4) -#define PM_DISK_MAX ((__force suspend_disk_method_t) 5) - +#define PM_DISK_TEST ((__force suspend_disk_method_t) 5) +#define PM_DISK_TESTPROC ((__force suspend_disk_method_t) 6) +#define PM_DISK_MAX ((__force suspend_disk_method_t) 7) + +/** + * struct pm_ops - Callbacks for managing platform dependent suspend states. + * @valid: Callback to determine whether the given state can be entered. + * If %CONFIG_SOFTWARE_SUSPEND is set then %PM_SUSPEND_DISK is + * always valid and never passed to this call. + * If not assigned, all suspend states are advertised as valid + * in /sys/power/state (but can still be rejected by prepare or enter.) + * + * @prepare: Prepare the platform for the given suspend state. Can return a + * negative error code if necessary. + * + * @enter: Enter the given suspend state, must be assigned. Can return a + * negative error code if necessary. + * + * @finish: Called when the system has left the given state and all devices + * are resumed. The return value is ignored. + * + * @pm_disk_mode: Set to the disk method that the user should be able to + * configure for suspend-to-disk. Since %PM_DISK_SHUTDOWN, + * %PM_DISK_REBOOT, %PM_DISK_TEST and %PM_DISK_TESTPROC + * are always allowed, currently only %PM_DISK_PLATFORM + * makes sense. If the user then choses %PM_DISK_PLATFORM, + * the @prepare call will be called before suspending to disk + * (if present), the @enter call should be present and will + * be called after all state has been saved and the machine + * is ready to be shut down/suspended/..., and the @finish + * callback is called after state has been restored. All + * these calls are called with %PM_SUSPEND_DISK as the state. + */ struct pm_ops { - suspend_disk_method_t pm_disk_mode; int (*valid)(suspend_state_t state); int (*prepare)(suspend_state_t state); int (*enter)(suspend_state_t state); int (*finish)(suspend_state_t state); + suspend_disk_method_t pm_disk_mode; }; -extern void pm_set_ops(struct pm_ops *); +/** + * pm_set_ops - set platform dependent power management ops + * @pm_ops: The new power management operations to set. + */ +extern void pm_set_ops(struct pm_ops *pm_ops); extern struct pm_ops *pm_ops; extern int pm_suspend(suspend_state_t state); @@ -142,29 +177,61 @@ typedef struct pm_message { } pm_message_t; /* - * There are 4 important states driver can be in: - * ON -- driver is working - * FREEZE -- stop operations and apply whatever policy is applicable to a - * suspended driver of that class, freeze queues for block like IDE - * does, drop packets for ethernet, etc... stop DMA engine too etc... - * so a consistent image can be saved; but do not power any hardware - * down. - * SUSPEND - like FREEZE, but hardware is doing as much powersaving as - * possible. Roughly pci D3. - * - * Unfortunately, current drivers only recognize numeric values 0 (ON) and 3 - * (SUSPEND). We'll need to fix the drivers. So yes, putting 3 to all different - * defines is intentional, and will go away as soon as drivers are fixed. Also - * note that typedef is neccessary, we'll probably want to switch to - * typedef struct pm_message_t { int event; int flags; } pm_message_t - * or something similar soon. + * Several driver power state transitions are externally visible, affecting + * the state of pending I/O queues and (for drivers that touch hardware) + * interrupts, wakeups, DMA, and other hardware state. There may also be + * internal transitions to various low power modes, which are transparent + * to the rest of the driver stack (such as a driver that's ON gating off + * clocks which are not in active use). + * + * One transition is triggered by resume(), after a suspend() call; the + * message is implicit: + * + * ON Driver starts working again, responding to hardware events + * and software requests. The hardware may have gone through + * a power-off reset, or it may have maintained state from the + * previous suspend() which the driver will rely on while + * resuming. On most platforms, there are no restrictions on + * availability of resources like clocks during resume(). + * + * Other transitions are triggered by messages sent using suspend(). All + * these transitions quiesce the driver, so that I/O queues are inactive. + * That commonly entails turning off IRQs and DMA; there may be rules + * about how to quiesce that are specific to the bus or the device's type. + * (For example, network drivers mark the link state.) Other details may + * differ according to the message: + * + * SUSPEND Quiesce, enter a low power device state appropriate for + * the upcoming system state (such as PCI_D3hot), and enable + * wakeup events as appropriate. + * + * FREEZE Quiesce operations so that a consistent image can be saved; + * but do NOT otherwise enter a low power device state, and do + * NOT emit system wakeup events. + * + * PRETHAW Quiesce as if for FREEZE; additionally, prepare for restoring + * the system from a snapshot taken after an earlier FREEZE. + * Some drivers will need to reset their hardware state instead + * of preserving it, to ensure that it's never mistaken for the + * state which that earlier snapshot had set up. + * + * A minimally power-aware driver treats all messages as SUSPEND, fully + * reinitializes its device during resume() -- whether or not it was reset + * during the suspend/resume cycle -- and can't issue wakeup events. + * + * More power-aware drivers may also use low power states at runtime as + * well as during system sleep states like PM_SUSPEND_STANDBY. They may + * be able to use wakeup events to exit from runtime low-power states, + * or from system low-power states such as standby or suspend-to-RAM. */ #define PM_EVENT_ON 0 #define PM_EVENT_FREEZE 1 #define PM_EVENT_SUSPEND 2 +#define PM_EVENT_PRETHAW 3 #define PMSG_FREEZE ((struct pm_message){ .event = PM_EVENT_FREEZE, }) +#define PMSG_PRETHAW ((struct pm_message){ .event = PM_EVENT_PRETHAW, }) #define PMSG_SUSPEND ((struct pm_message){ .event = PM_EVENT_SUSPEND, }) #define PMSG_ON ((struct pm_message){ .event = PM_EVENT_ON, }) @@ -190,6 +257,7 @@ extern void device_resume(void); extern suspend_disk_method_t pm_disk_mode; extern int device_suspend(pm_message_t state); +extern int device_prepare_suspend(pm_message_t state); #define device_set_wakeup_enable(dev,val) \ ((dev)->power.should_wakeup = !!(val))