TECHNICAL FIELD Embodiments of the present invention relate generally to computing devices and, more specifically, to handling of wake events while a computing device is in a reduced power consumption state.
BACKGROUND INFORMATION Various mechanisms exist for reducing power consumption of computing devices. Standard technology for power management is specified in, for example, Advanced Configuration and Power Interface (ACPI) version 2.0, published Jul. 27, 2000, (jointly developed by Hewlett-Packard, Intel, et al.). ACPI is the standard most computer systems currently use for power management and is used to describe how the system looks to the operating system. Power management capabilities enable a computing device, both at component and system level, to change its operating state to use less power and to resume normal operations. These modes of operation, for purposes of this description, will be called suspended and active states. A number of events (herein “sleep” events) may trigger a computing device to transition from an active higher power consumption state to an inactive lower power consumption state, while a number of other events (herein “wake” events) may trigger a computing device to transition from an inactive low power consumption state to a more active higher power consumption state. For instance, a sleep event may trigger a computing device to go into a suspended state. Such sleep events may be as a result of perhaps due to time, inactivity, or user selection. When a computing device goes into a suspended state, many of the device components (e.g., main processor such as the central processing unit (CPU), volatile memory, disk drives for mass storage, and so forth) may be placed into a non-functional or sleep mode. On the other hand, a wake event may occur when moving a mouse, pressing a key on the keyboard, receiving a message, or receiving a query from a remote system administrator may cause a computing device to transition to an active state from a sleep, or low-power, state.
Conventionally, computing devices must be in an active state to handle a wake event. This means that many or all of the device components must be functional or operational in order to handle the wake event.
BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:
FIG. 1 illustrates an overview of the invention, in accordance with various embodiments;
FIG. 2 illustrates the three ACPI operational states of the system ofFIG. 1, in accordance with some embodiments; and
FIGS. 3A and 3B illustrate an exemplary flow process that includes execution of a task in response to a wake event by a management controller in accordance with some embodiments.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS Illustrative embodiments of the present invention include but are not limited to methods for executing tasks in response to wake events in computing devices while the devices are in a reduced power consumption state, components contributing to the practice of these methods, in part or in whole, and devices endowed with such components.
Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.
Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.
The phrase “in one embodiment” is used repeatedly. The phrase generally does not refer to the same embodiment; however, it may. The terms “comprising”, “having”, and “including” are synonymous, unless the context dictates otherwise.
Referring now toFIG. 1, wherein an overview of the present invention, in accordance with various embodiments, is shown. As illustrated, for the embodiments,computing device100 includes processor(s)102,memory104, memory-bus controller114, andbuses112 and113, coupled to each other as shown. Additionally,computing device100 includesmass storage device106, input/output (I/O)devices108, andcommunication interfaces110 coupled to each other, and the earlier described elements as shown.
Memory104 andmass storage device106 include, in particular, temporal and persistent copies ofoperating system122, respectively. In various embodiments, I/O devices108 may include output devices, such as a monitor, for locally outputting data, and input devices, such as a keyboard or a mouse, for locally inputting data. Thecommunication interfaces110 may include a networking interface such as a network interface card (NIC)coupling computing device100 to a network, to facilitate reception of data such as e-mails, configuration directives and queries from, for example, a remote administrator, application patches, and so forth.
In various embodiments,operating system122 is adapted to operatecomputing device100 in one or more operational states, including one or more reduced power consumption states, wherein one or more ofprocessor102,memory104, and so forth, may be placed in a reduced power consumption state, including a power-off state. Various events, when occurred while the system is in one of the reduced power consumption state, may be considered wake events of the system. Examples of these may include an attempt by a user to input via an input device while the system is in a reduced power consumption state, or the receipt of a data transmission bycommunication interface110 while the system is in a reduced power consumption state.
Further,computing device100 is endowed withmanagement controller116 andnonvolatile storage118, coupled to each other and the earlier described elements as shown. For the embodiments,nonvolatile storage118 includes one or more policy information specifying handling of various wake events, including handling of various wake events whilecomputing device100 remains in a reduced power consumption state. In various embodiments, the handling of the various wake events may include execution of one or more tasks withcomputing device100 remaining in a reduced power consumption state. In various embodiments,non-volatile storage118 may include these tasks for implementing the policies therein. Alternatively, the tasks for implementing the policies, and optionally including even the policies may be integrated into themanagement controller116.
As will be described in more detail below,management controller116 is adapted to execute one or more tasks forcomputing device100 in response to a detection of an occurrence of a wake event while thecomputing device100 is in a reduced power consumption state, thereby handling the wake events without causing thecomputing device100 to come out of the reduced power consumption state. Themanagement controller116 may execute the task or tasks, in some embodiments, independent of theoperating system122 and/or the processor(s)102, that is, irrespective of their availability or operational state. More specifically, for the embodiments,management controller116 is adapted to use the data/information stored innonvolatile storage118, in handling the wake events while thecomputing device100 is in a suspended state. Recall in the prior art, a wake event would normally require a conventional computing device to return to a higher power consumption state, rather than remaining in a lower power consumption state, to handle the wake event.
In various embodiments,management controller116 includes an input/output (I/O) interface (not shown) for interfacing with memory-bus controller114, enabling it, among other things, to be operatively coupled toprocessor102,communication interfaces110, and so forth. In other embodiments,management controller116 may be coupled toprocessor102 and/orcommunication interfaces110 directly, without going through memory-bus controller114. Although themanagement controller116 is depicted as being a discrete component relative to the memory-bus controller114, in other embodiments,management controller116 may be integrated with memory-bus controller114 and/or other components.
As will be described in more detail below,management controller116 is adapted to execute one or more tasks in response to a detection of an occurrence of one of one or more particular wake events while the computing device is in a reduced power consumption state without waking all or most of the other components (e.g., processor(s)102 and memory104) or only waking up selective components.
Thenonvolatile storage118, in some instances, may be flash memory. The policy or policies may be stored in thenonvolatile storage118 by the computing device's firmware, e.g., basic input/output system (BIOS). The policy or policies (herein “policy”) may identify at least the wake event or events to be handled by themanagement controller116. The policy may further define the task or tasks (herein “task”) that need to be executed for each wake event identified in the policy. The task to be performed in response to a wake event may call for all or most of the device components to be awakened, selective device component(s) to be awakened, or none of the device components to be awakened. Similarly, the task may be stored intononvolatile storage118 by the computing device's firmware, e.g. the BIOS. Because thenonvolatile storage118 contains the policy and the logic to implement the policy, themanagement controller116 can determine and execute a task in response to a detected occurrence of a wake event without the operating system (OS)122 or the processor(s)102 in a functional status. That is, themanagement controller116, in various embodiments, may be a component that may operate independently from the processor(s)102 and/or theOS122.
Except for themanagement controller116, and the data/information and/or instructions stored innonvolatile storage118, each of the earlier described elements represents a broad range of the corresponding elements known in the art or to be designed consistent with the teachings of the present invention. They perform their conventional functions, i.e. processing, storage, and so forth. For example,OS122 is adapted to perform its conventional function of managing the resources ofcomputing device100.
In various embodiments,computing device100 may have more or less elements, and/or different architectures. In various embodiments,computing device100 may be a desktop computer, a tablet computer, a palm-sized computing device, a set-top box, or a media player (e.g., a CD or DVD player).
FIG. 2 illustrates one embodiment of the operational states ofcomputing device100. For ease of understanding, the operational states will be described assumingcomputing device100 also includes implementation of ACPI, and mapped to the ACPI states. For the embodiment, the operational states ofcomputing device100 includes three major operational states, active state (e.g., ACPI S0)202, suspended state (e.g., ACPI S1 to S4)204 and unpowered state (i.e., ACPI G3)206. However, alternate embodiments may be practiced without mapping to ACPI states or implementation of ACPI. For further information these ACPI states, see ACPI Specification, Revision 2.0b.
In terms of power consumption, the active state202 represents the highest or near highest power consumption states of thecomputing device100, theunpowered state206 represents the lowest power consumption state (i.e., unplugged device), and the suspendedstate204 represents various power consumption states between the active andunpowered states202 and206. Within the active state202, thecomputing device100 may be fully or nearly fully powered. For example, in the active state202, all or vast majority of the system components such as the processor(s)102, thememory104, disk drive(s), and other devices, may be fully or nearly fully powered and thecomputing device100 is at or near maximum power consumption. Note, however, that thecomputing device100 may still be in the active state202 if a selected one or more of the device components such as a monitor is nonfunctional. In the suspendedstate204, many of the device components such as processor(s)102,memory104,memory storage device106 including disk drives, I/O devices108 such as a monitor, and other components may be non-functional. As defined here, the term “non-functional” may be broadly defined such that a non-functional component may be consuming some low level of power or no power at all. Within the suspendedstate204, there may be different states of power consumption depending upon whether, if at all, selected device components are functional or running. Current ACPI standards do not particularly address different power consumption levels within, for example, the suspendedstate204. Thus within the suspendedstate204, such as ACPI S3 state, there may be different levels of power consumption. Further, in theunpowered state206, thecomputing device100 is not powered or, in essence, unplugged. Thus, althoughFIG. 2 depicts three major operational states, in actuality, there may be many more different power consumption states than the three major operational states depicted.
According to various embodiments, once a wake event occurs while thecomputing device100 is in a suspendedstate204, thecomputing device100 may be transitioned into the active state202 as depicted by208, or the wake event can be handled entirely within the suspendedstate204 as indicated by210. For instance, when a wake event occurs, themanagement controller116 may make the determination as to which task needs to be executed in response to the wake event. The task that needs to be executed may require that thecomputing device100 be in the active state202 or high power consumption state where most or all of the device components are running, or require selected additional device components to be running, in which case thecomputing device100 goes into a higher power consumption state but still within the suspendedstate204, or require no additional device components to be running in which case thecomputing device100 stays at the same power consumption state but still within the suspendedstate204. In any event, when the task is executed, thecomputer device100 may or may not be at a higher power consumption state and may or may not remain in the suspendedstate204.
Wake events, in some embodiments, may originate from an I/O device108 or a network via acommunication interface110 such as a network interface card (NIC). At least three types of wake events can be identified, those that require tasks that need all or most device components to be running in order to execute the tasks, those that require tasks that need only one or few device components to be running in order to execute the tasks, and those that require tasks that need no device components to be running in order to execute the tasks. Examples of wake events include receipt of e-mail, receipt of other messages or network transmission, remote system administrator queries, application patches, mouse movement, keyboard activity, periodic wake, and so forth.
FIGS. 3A and 3B depict an exemplary process that includes execution of a task by a management controller in response to a wake event during a suspended state in accordance with some embodiments. The task may be executed without waking the main processor(s) and/or independent of the operating system (OS). In these figures, blocks outlined by a solid line may be performed by the system firmware, in particular, the basic input/output system or BIOS. Note that in addition to the BIOS, the computing device may also include wake policy or policies and, in some instances, logic for executing the policy or policies. Blocks outlined with large broken lines may be performed by the OS and the main processor(s). Blocks outlined by dots may be performed by the management controller and system firmware without the processor(s) and/or the OS. It will be apparent to one of ordinary skill in the art that the term “performed by the firmware” is shorthand for a more complex computing device interaction. For instance, in a typical single processor system, instruction execution may be performed by the main processor, or CPU, involving executions of multiple tasks.
The main processor(s)102 may have access to the firmware prior to loading the OS. Thus, boot instructions are typically stored in the firmware boot block. In some embodiments, the boot block resides remotely, and the “boot block” contains a pointer to the remote location. Note again that policy or policies (herein “policy”) and, in some instances, logic for executing the policy may also be included in the firmware. Further, when the computing device is in a low power consumption state, the main processor(s) may be essentially or completely shut down and the OS nonfunctional. Wake events that occur during low or reduced power consumption state, in various embodiments, may trigger the management controller to execute task or tasks based, at least in part, on the wake policy (or simply “policy”).
Referring now toFIG. 3A, a computing device or system implemented with an embodiment of the present invention is powered atblock301. The computer device is initialized by the boot block firmware inblock303. Other portions of the firmware, residing outside of the boot block, may play a role in initialization. The boot block may be responsible for early aspects of initialization such as early memory initialization and central processor initialization. Initialization may include identifying and resetting memory, identifying devices and components coupled to the computing device, and so forth.
In various embodiments, based on policy included in the firmware and ACPI table constructs, the firmware may establish a set of wake events to be handled accordingly by the management controller rather than the main processor at block305 (i.e. programming the management controller). The policy may be standard and shipped with the computing device, or may be determined by a system administrator or the like. Policy may be stored in a computing device's nonvolatile memory, for instance, flash memory. Wake events may be programmed by the firmware into the computing device's management controller. As described previously, events such as touching the keyboard, receiving a network packet of a certain type, and so forth could be programmed as wake events.
Wake events may be initiated by system management interrupts (SMIs), control line changes, register flags, or other constructs. In other cases, wake events may be initiated by the memory-bus controller (i.e., memory controller hub-input/output controller hub (MCH/ICH) conventionally known as north and south bridges) and cause an SMI. Some wake events may require that in order to properly handle the wake events the computing device is in an active state or high power consumption state, in which case the main processor (i.e., CPU) and/or the OS is made operational. Other wake events may be handled by the management controller and the firmware without the main processor and/or OS operational and while the computing device is still in a suspended state.
Once the wake events have been set, the firmware boots the OS atblock307. Normal operation of the computing device commences, under control of the OS. The OS continues normal operation until an SMI, or other event, has occurred. If an SMI has occurred, then a determination is made atblock311 whether the OS has initiated a power transition to a lower power consumption state such as suspended state.
If the OS has not initiated a transition to the suspended state, then OS operation continues as normal inblock315. If, on the other hand, the OS has initiated a suspension state transition, or transition to a reduced power consumption state, as determined atblock311, the appropriate command may then be written, for example, to a port to cause the transition atblock313. Power level transitioning may be defined by ACPI standards. The computing device may then remain in a suspended or reduced power consumption state with, in some instances, the main processor(s) and/or the OS nonoperational or nonfunctional atblock319 inFIG. 3B. In some embodiments, block319 represents the state in which the computing device is in a wait-loop, in which case the management controller is waiting for an alert or a wake event to occur.
When a wake event is detected, it is processed atblock321. A determination is made by the management controller based on the policy information whether the wake event corresponds to an event that the management controller can handle without waking all or most of computing device atblock323. If the event cannot be handled by the management controller without waking up the computing device, then the computing device resumes from the reduced power consumption state (e.g., suspended state) to an active state in block317 (seeFIG. 3A). This may include restoring power to most or all of the components of the computing device and/or restore system settings. The wake event may then be handled by the OS as a Common General Purpose Event. Normal OS polling of devices may ensue, e.g., retrieve e-mail, etc. Again, as previously described, a determination is then made as to whether the OS has initiated a power transition to sleep mode atblock311. Depending on the type of wake event received, the computing device may immediately transition back to a suspended state, or remain in active state, for instance, if the event was a keyboard event.
Returning toFIG. 3B, if the policy indicates that the management controller is to handle the event atblock323, then the event is handled by the management controller without waking the entire computing device. Based on the policy, a determination is made as to the appropriate task to be executed atblock325. In some embodiments, selected device component or components may be required to be powered up or functional in order to execute the task thus resulting in the computing device transitioning into a higher power consumption state, but the computing device is not brought to full active state. The task is then executed atblock327 using, if the task calls for it, selected device component or components. This means that selected device component or components are made functional before executing the task. Once the wake event has been handled (i.e., executing one or more tasks), the computing device may transition back into a reduced power consumption state if the computing device had to transition into higher power consumption state in order to execute the task or maintain the reduced power consumption state if no device components were activated in order to perform the task atblock329. In the case where the computing device is transitioned back into a reduced power consumption state, this may mean shutting down the device components or components that were powered up to handle the wake event. The computing device will then stay in the reduced power consumption state and may loop back to block319 at least until another wake event has been detected at which time the process depicted inFIG. 3B repeats itself.
Accordingly,management controller116 is able to execute a task in response to a wake event while thecomputing device100 is in a reduced power consumptions state. The execution of the task, in some instances, may mean that selected components be made functional resulting in thecomputing device100 transitioning into a higher power consumption state in order to execute the task but without transitioning thecomputing device100 from a suspendedstate204 to an active state202.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a wide variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described, without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that this invention be limited only by the claims and the equivalents thereof.