A computer system typically may be in one of many standby states, including “sleeping” states. An open industry specification called Advanced Configuration and Power Interface (ACPI) establishes industry-standard interfaces for configuration and power management directed by computer operating systems. The ACPI establishes system sleeping states, commonly designated, “S1,” “S2,” “S3,” and “S4,” with each sleeping state defined to allow implementations that can tradeoff cost, power, and wake latencies. Additionally, the ACPI specification defines the sleeping states such that a system can support multiple sleeping states, allowing the system to transition into a particular sleeping state for a predefined period of time and then transition to a lower power/higher wake latency sleeping state.
The S1 sleeping state is a low wake latency sleeping state, and in this state no system context is lost and hardware maintains all system context. System context generally is the volatile data in the system that is not saved by a device driver. The S2 sleeping state is a low wake latency sleeping state similar to the S1 sleeping state except that a state of a central processing unit (CPU) and system cache typically are lost and control starts from the CPU's reset vector after a wake event. The S3 sleeping state is another low wake latency sleeping state where typically all system context, CPU state, cache, and chip set context are lost, and only system memory is maintained. During the S3 sleeping state, hardware maintains memory context and restores some CPU configuration context. Control starts from the CPU's reset vector after a wake event.
During the S1, S2, and S3 sleeping states, power to RAM is maintained, and therefore, each of these sleeping states may be referred to as “suspend to RAM” sleeping states. The S4 sleeping state is the lowest power, longest wake latency sleeping state supported by the ACPI. To reduce power to a minimum, it is assumed that the hardware platform has powered off all devices, and the platform context is maintained. In the S4 sleeping state, power to RAM may be eliminated, and the system context is stored to disc or other non-volatile storage. Therefore, the S4 sleeping state may be referred to as a “suspend to disc” sleeping state. The ACPI also defines a system state S0, which is a system working state.
The latency period for waking a system in a suspend to RAM sleeping state, such as the S1, S2, or S3 sleeping state, is shorter than for a system in the suspend to disc sleeping state, such as the S4 sleeping state. The delay involved in transitioning to a working state from a suspend to disc state may create a disincentive to placing a computer in the suspend to disc state. The user, for example, may prefer a suspend to RAM sleeping state so that resuming to a working state may occur more rapidly than from a suspend to disc sleeping state.
A problem with choosing a suspend to RAM sleeping state over a suspend to disc sleeping state, however, arises if power to the system is lost. Because the system context is written to RAM for the suspend to RAM sleeping states, power is needed to maintain the system context in RAM. If power is lost while a system is in the, for example, S3 sleeping state, the context will be lost, and a full or lengthy boot process may be required. Moreover, any work in progress may be lost.
If, however, a system in the suspend to disc sleeping state (e.g., the S4 state) loses power, upon regaining power, the system wakes normally. This is because the system context was previously written to non-volatile storage. FIG. 1 depicts a flow diagram of a typical method 10 for transitioning from a working state such as the S0 state to a suspend to disc state, such as the S4 sleeping state. The method 10 includes transitioning to the suspend to disc state in a system that subsequently loses power. The loss of power is indicated by the dashed line 15. The method 10 also includes transitioning to the working state after regaining power, shown as the steps below the dotted line 15.
At step 11, device drivers or components in a system are notified that the system will be transitioning to the S4 sleeping state. This step may occur after the operating system queries application programs and device drivers of the viability of transitioning to a sleep state and after the operating system receives indications that the applications and drivers are ready for the transition. Alternatively, the operating system may tell the applications and/or the device drivers of the transition without first asking. At step 11, each device driver saves its state. At step 12, a context file comprising the context of the system may be written. The operating system may write the context file. At step 13, the operating system may communicate with firmware containing basic routines that help to transfer information between elements within the computer during, for example, start-up, sleep, or shut-down operations. The firmware may be a basic input/output system (BIOS). The operating system may direct the BIOS or other firmware or hardware to transition to the S4 sleeping state. At step 14, power to the system is lost.
At step 16, power is regained. Upon regaining power, the system reads the context file at step 17. At step 18, the operating system may restore the system to the working state it was in before entering the S4 sleeping state (i.e., before step 11).
In some systems, when a BIOS is notified of a transition to a suspend to RAM state, such as the S1, S2, or S3 states, the BIOS may write a system context file to non-volatile storage even if another entity, such as an operating system, has saved state to RAM. If the BIOS writes this file and, while in the suspend to RAM state, power is lost, the BIOS file may be used to wake the system when power is regained. Problems may arise, however, with attempting to wake the system with the BIOS context file because the BIOS may not have been aware of the current state of the system when creating the file. The system context that the BIOS saves to disc thus may not be reliable and may not reflect a current state of the system.
Therefore, there is a need for systems and methods for providing a reliable capability of a computer system to wake to a working state from a suspend to RAM sleeping state while safeguarding context information and work in progress in the event that the computer loses power while in the suspend to RAM state.