Patent Application
20110131427
The present invention relates generally to power management and in particular to managing power in response to decoding software-based power management states of an electronic system.
As digital electronic processing systems trend toward higher operating frequencies and smaller device geometries, power management has become increasingly important to prevent thermal overload while maintaining system performance and prolonging battery life in portable systems.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:
In the following description, numerous specific details are set forth such as examples of specific components, devices, methods, etc., in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art that these specific details need not be employed to practice embodiments of the present invention. In other instances, well-known materials or methods have not been described in detail in order to avoid unnecessarily obscuring embodiments of the present invention. It should be noted that the “line” or “lines” discussed herein, that connect elements, may be single lines or multiple lines. It will also be understood by one having ordinary skill in the art that lines and/or other coupling elements may be identified by the nature of the signals they carry (e.g., a “clock line” may implicitly carry a “clock signal”) and that input and output ports may be identified by the nature of the signals they receive or transmit (e.g., “clock input” may implicitly receive a “clock signal”). Reference in the description to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.
The two principal sources of power dissipation in digital logic circuits are static power dissipation and dynamic power dissipation. Static power dissipation is dependent on temperature, device technology, and processing variables, and is composed primarily of leakage currents. Dynamic power dissipation is the predominant loss factor in digital circuitry and is proportional to the operating clock frequency, the square of the operating voltage and the capacitive load. Capacitive load is highly dependent on device technology and processing variables, so most approaches to dynamic power management focus on frequency and voltage control.
In some data processing systems, processors within the systems execute software at the operating system (OS) level to perform power management for the processor itself. The processor core of a typical data processing system may use software-based power management states defined by standards. For example, the software-based power management standard may be the Advanced Configuration and Power Interface (ACPI) specification. The ACPI specification is an open standard for unified operating systems-centric device configuration and power management. ACPI, first released in December 1996, defines platform-independent interfaces for hardware discovery, configuration, power management, and monitoring. The specification is central to Operating System-directed configuration and Power Management (OSPM); a term used to describe a system implementing ACPI, which therefore removes device management responsibilities from legacy firmware interfaces. Intel, Microsoft, and Toshiba originally developed the standard. Current developers of the standard also include HP and Phoenix and the specification was last published as “Revision 4.0a,” on Apr. 5, 2010.
The ACPI specification contains numerous related components, for hardware and software programming, as well as a unified standard for device power interaction and bus configuration. As a document that unifies many previous standards, it covers many areas, for system and device builders as well as system programmers. Some software developers have trouble implementing ACPI and express concerns about the requirements that bytecode from an external source must be run by the system with full privileges.
It should be noted that although various embodiments may be described hereinafter in regards to the ACPI specification, in alternative embodiments, other software based standard protocols may be used.
In one embodiment, the state information that is developed as part of the ACPI specification may be used by a power management system that provides a hardware-based system-wide power management solution. The specific Performance states (P0-Pn), Device states (D0-D3), Processor states (C0-C3), and sleeping states (S0-S5) may be used as part of the detection mechanism of an On-Demand Power, power management controller that detects changes in the application demand and generates changes in system signals to provide just-in-time, just-enough energy delivery. The ACPI states are defined and managed by the operating system, and is largely concentrated on the dynamic power management within a central processing unit (CPU). Nevertheless, the same ACPI states, if brought externally from the CPU, may be detected by a power management controller (PMC) to dynamically adjust the energy to be delivered (e.g., supply voltages and clock frequencies) to the electronic system without interrupting the system. Such is a point-of-source approach to dynamic power management. The electronic system may be, for example but not limited to, a portable electronic system, such as a radio, a phone, a camera, a sensor, etc., laptop computer, or a non-portable electronic system, such as a desktop computer, a server, etc.
In one embodiment, the PMC 110 includes an ACPI state decoder 112 that decodes the ACPI specific states 143, including the performance states (P0-Pn), device power states (D0-D3), processor power states (C0-C3), and sleeping states (S0-S5) which are sleeping within a global sleeping state G1 of global system states (G0-G1). It should be noted that although processor power states may have additional manufactured-specific states that are larger than C3. Definitions for the various different states may be found in Table 1-1 provided below at the end of the detailed description section.
The PMC 110 then dynamically adjusts the energy to be delivered (e.g., supply voltages and clock frequencies from the voltage sources 102 and clock sources 104, respectively) to the electronic system 130 via the PMU 120 without interrupting the CPU 140. In one embodiment, for example, the power management algorithm 114 may be a power management algorithm as described in U.S. Patent Publication No. 2009/0158061 may be used, the entire content of which is incorporated herein by reference. In such an embodiment, the states described therein may be replaced with the decoded ACPI states from the ACPI state decoder 112. In particular, the states described therein are based on sensed inputs from the electronic system 130, whereas the states described herein are software-based power management states that are defined in software of the electronic system 130. It should be noted that some of the embodiments described herein, however, uses the sensed inputs to determine or infer the software-defined states. Also, for a given power domain controlled by the PMU 120, the Lower Envelope Algorithm (LEA) described therein may select between different energy levels to provide to the electronic system 130 depending on the ACPI states 143 received from the CPU 140 and decoded by the ACPI state decoder 112 as described below. For example, in one embodiment, the PMC 110 can use an existing dynamic voltage scaling (DVS) of a processor core to gain knowledge of the CPU's ACPI state to user for the PMA 114. In general, the power consumption of a processor core is proportional to NCfV2, where N is the number of switching gates, C is the capacitance of a gate, f is the frequency of gate switching, and V is the core voltage. Scaling the frequency based on the workload of the processor core may reduce power consumption of the processor core Likewise, the core voltage can be scaled in relation to the frequency to further reduce power. A processor core typically includes complementary metal oxide semiconductor (CMOS) circuits. Due to the nature of CMOS circuits, as the switching frequency increases, the core voltage has to be increased also to ensure proper operation. Conversely, as the switching frequency decreases, the core voltage may be decreased. Note that when the switching frequency is increased, the voltage has to be increased in advance. Likewise, when the switching frequency is decreased, the voltage has to be decreased afterwards. Thus, by using the ACPI state of the processor core, the PMA can adjust the energy to be delivered to the electronic system 130, such as the energy to be delivered to one or more peripheral devices 144.
In one embodiment, the PMC 110 monitors a processing demand in the electronic system 130 using the ACPI states 143. For example, the electronic system can be operating at a first one or more voltages and a first one or more clock frequencies phase-locked to a reference frequency in a first ACPI state. The PMC 110, based on detection of a change to the ACPI states 143, may generate a second one or more clock frequencies in response to the processing demand. The second one or more clock frequencies may be phase-locked to the reference frequency and phase-matched to the first one or more clock frequencies. The PMC 110 may also switch from the first one or more clock frequencies to the second one or more clock frequencies without halting the electronic system 130. The PMC 110, based on a change to the ACPI state 143, may also generate a second one or more voltages in response to the processing demand, and may switch from the first one or more voltages to the second one or more voltages without halting the electronic system 130.
The diagram 200 includes multiple Global system states (Gx states), Device power states (Dx states), Sleeping states (Sx states), Processor power states (Cx states), and Device and Processor performance states (Px states). The Global system states (Gx states) apply to the entire electronic system 130. These states may be visible to the user of the electronic system 130. Device power states (Dx states) represent the states of particular devices, such as a modem, a hard drive (HDD), and CDROM, although other states of other types of devices may be used. These state may not be visible to the user. For example, some devices may be in the Off state even though the system 130 as a whole is in the Working state. Device states apply to any device on any bus. The device power states are defined below, although very generically because, as would be appreciated by one of ordinary skill in the art having the benefit of this disclosure, the embodiments described herein may be used for various software-based power management states. It should also be noted that although the device states show four power states, in other embodiments, less than or more than four states may be used, and some of the devices may not have all of the power states defined. Devices may be capable of several different low-power modes, but if there is no user-perceptible difference between the modes, only the lowest power mode may be used, for example. Sleeping states (Sx states) are types of sleeping states within the global sleeping state, G1. Processor power states (Cx states) are processor power consumption and thermal management states within the global working state, G0. Device and Processor performance states (Px states) are power consumption and capability states within the active/executing states, C0 for processors and D0 for devices. Table 1-1 included below provides provide a brief description of the global system states, the device power states, sleeping states processor power states, and device and processor performance states.
Alternatively, in other embodiments, the PMC 110 can monitor for changes in other types of software-based power management states, and instruct the PMU 120 to change states in order to change the energy delivered to the electronic system 130 in response to the changes in software-based power management states.
In some embodiments, the PMU 120 provides power to the electronic system 130, whereas the PMC 110 controls the operating states of the PMU 120 in response to the state decoder 112 decoding the software-based power management states of the electronic system 130. Using one or more signals received on sense inputs 532 and/or a communication bus 535, the PMC 110 may decode the particular software-based power management states to determine a processing demand of the electronic system 130. In one embodiment, based on the processing demand of the electronic system 130, the PMC 110 may autonomously execute a power management algorithm (PMA) (illustrated in
The voltage domain outputs 534, clock domains output 2126, and control outputs 536 of the PMU 120 are adjusted by the PMU 120 to correlate with the operating states received by the PMU 120 from the PMC 110. The voltage domain outputs 534 may be used to supply voltage to one or more voltage domains in the electronic system 130. The clock domains output 538 may be used to supply a clock to one or more clock domains in the electronic system 130. The voltage domains outputs 534 and clock domains output 538 of the PMU 120 may be derived from voltage sources 102 and clock sources 104 coupled to the PMU 120, respectively. The control outputs 536 of the PMU 120 may be used to control the operating states of sub-systems and/or peripherals in the electronic system 130. For instance, one of the control outputs 536 may be a digital signal used to enable and/or disable peripherals in the electronic system 130.
In another embodiment, the PMC 110 implements a state machine (illustrated in
In one embodiment, the state decoder 112 receives an indication of the software-based power management state of the electronic system 130, such as an indication that the processor is in a particular C state, or a peripheral device is in a particular D state, for example. The processor and/or device may output a signal on a particular pin to notify other devices that it is in a particular software-based power management state. Alternatively, the processor and/or device may store the particular software-based power management state in a register to be read when requested. Alternatively, software executing on the processor and/or device may output a message periodically, or when requested, to notify other devices that it is in a particular software-based power management state. In some embodiments, the state decoder 112 can decode the signal or message directly. In other embodiments, the processor and/or devices of the electronic system 130 may not output the software-based power management states, and the state decoder 515 can determine the software-based power management state using other indications received from the electronic system 130. For example, in one embodiment, the state decoder 112 decodes the software-based power management states using one or more hardware signals received on the communication bus 535 (or via sense inputs 532) from the electronic system 130, such as one or more hardware signals measured on one or more pins on a processor of the electronic system 130. In another embodiment, the state decoder 112 decodes the software-based power management states using one or more signals indicative of the system's energy consumption or peripheral energy consumption via the sense inputs 532 (or via the communication bus 535) from the electronic system 130. In another embodiment, the state decoder 112 can logically combine multiple signals received from the electronic system 130 in order to decode the software-based power management states.
In one embodiment, the sense inputs 532 may be analog signals, digital signals, or mixed signals. In one embodiment, the state of the sense inputs 532 may be correlated to the software-based power management states of the electronic system 130. For example, the sense inputs 532 may be signals that are indicative of changes in the software-based power management states. Alternatively, the sense inputs 532 may be signals that are indicative of operating parameters of the electronic system 130 that can be used to infer the software-based power management states. In addition to receiving signals for decoding the software-based power management states, the power manager 500 may receive other sense inputs, such as, for example, chip selects, enable signals, or communication buses of peripherals in the electronic system 130. These other sense inputs 532 may also be used in connection with the state decoder 112 when determining the software-based power management state of the electronic system 130. Alternatively, the sense inputs 532 may be used to monitor the temperatures, voltages, and/or currents in the electronic system 130 for related and non-related purposes.
The state decoder 112 may be implemented in connection with a power management algorithm (PMA). In some embodiments, the PMA is implemented using hardware, such as a state machine, as illustrated in
The bus interfaces 606 and 608 communicate with the electronic system 130 and the PMU 120, respectively. Specifically, the bus interface 608 communicates with the PMU 120 over the communication bus 515. This allows the PMC 600 to control the operating states of the PMU 120. The communication bus 515 may include a serial bus or a parallel bus. The communication bus 515 may reside only on a single IC substrate that includes both the PMC 600 and the PMU 120. Alternatively, the communication bus 515 may communicatively couple two different IC substrates on which the PMC 600 and the PMU 120 reside.
In some embodiments, the bus interface 606 communicatively couples the PMC 600 with the electronic system 130 via the communication bus 535. This allows the electronic system 130 to control the operating parameters of the PMC 600, the operating states of the PMU 120, etc. The communication bus 535 may include a serial bus or a parallel bus.
The PMA that is implemented by the state machine 602 determines the operating states of the PMU 120 dynamically based on the software-based power management states in the electronic system 130 (such as the ACPI states). The software-based power management states of the electronic system 130 may be monitored through the sense inputs signals 314 and/or signals on the communication bus 535.
Each power domain controlled by the PMU 120 through voltage, clock, and/or control output changes may have multiple operating states, including active states and standby states. Furthermore, each power domain may have more than one active states, such as a fast state, a slow state, or other types of active states. In addition, each power domain may have more than one standby states, including an idle state, a power-down state, or other types of standby states.
Depending on the software-based power management states decoded by the state decoder 112, the PMA implemented by the state machine 602 may select from active or standby operating states for each power domain in the electronic system 130. For each power domain, the PMA may select from one active state and one standby state, one active state and multiple standby states, multiple active states and one standby state, multiple active and multiple standby states, or multiple active states.
One example of the PMA that may be implemented by the state machine 602 is Lower Envelope Algorithm (LEA). For a given power domain controlled by the PMU 120, the LEA selects between one active state and one or more standby states depending on the decoded software-based power management state that indicates if the power domain under control has to be in the active state. If the power domain is not in the active state, the LEA may control the PMU 120 through the bus interface 608 in the PMC 600 to transition the power domain from a non-active state to the active state with little latency. As long as the current software-based power management state identifies that the power domain under control has to be in the active state and the power domain is currently in the active state, the LEA does not transition the power domain to a standby state.
When the decoded software-based power management state no longer indicates that the power domain has to be in the active state, then the LEA may transition the power domain to a standby state after some predetermined criteria have been met. For instance, the criteria may include a time period of non-activity as determined using the decoded software-based power management state. The time delay to wait before transitioning from the active state to the standby state may be calculated based on the amount of power consumed while operating in the standby state, the amount of power consumed while transitioning from the standby state to the active state, and the time latency induced by transitioning from the standby state to the active state. Alternatively, the time delay between transitions can be programmed.
Furthermore, the LEA may transition the power domain from one standby state to another standby state based on another time period that may be calculated based on the power consumed while operating in the next standby state, the amount of power consumed while transitioning from the next standby state to the active state, and the time latency induced by transitioning from the next standby state to the active state. The length of these time periods may be stored in the programmable memory 304 in the PMC 600 and may be modified by the electronic system 130 via the communication bus 535. Alternatively, the time periods may be stored in the programmable memory 304 and can be used when transitioning from one particular software-based power management state to another.
As discussed above, the PMA may be implemented using only hardware, such as the state machine 602 in the PMC 600 in
In some embodiments, the processor 702 is a dedicated hardware controller separate from other system processor(s) that may exist in the PMC 700. For instance, the processor 702 may include one or more programmable logic devices (PLDs). While PLDs are suitable for executing the PMA, the general programmable nature of the platform may require more silicon area and more power consumption by the PMC 700. Alternatively, an application specific integrated circuit (ASIC) designed specifically for executing the PMA 114 (or a set of PMAs) may be used instead to more fully exploit the benefit of the PMA 114. Such an implementation generally results in a PMC 700 with a smaller footprint and lower power consumption.
The programmable memory 704 may include non-volatile memory (e.g., flash memory, etc.), volatile memory (e.g., dynamic random access memory (DRAM), etc.), or both. Non-volatile memory may store default operating parameters for the PMC 700 after power up of the PMC 700. In addition, the non-volatile memory may store initial operating states for the PMU 120 after power up of the PMU 120. The use of programmable non-volatile memory in the PMC 700 allows the PMU 120 to generate programmable default voltage, clock, and control outputs after power up of the PMU 120 and/or the PMC 700 independent of the sense inputs signals 314 and signals on the communication bus 535 from the electronic system 130. Furthermore, the use of programmable non-volatile memory in the PMC 700 allows the PMC 700, the electronic system 130, and/or the PMU 120 to update programmable settings and/or values in the PMC 700 during runtime of the PMC 700. As such, the PMC 700 may accept and store operating parameters that may change after power up of the electronic system 130, the PMC 700, and/or the PMU 120.
The bus interfaces 706 and 708 communicate with the electronic system 130 and the PMU 120, respectively. Specifically, the bus interface 708 communicates with the PMU 120 over the communication bus 515. This allows the PMC 700 to control the operating states of the PMU 120, as well as any other operating parameters. The communication bus 515 may include a serial bus or a parallel bus. The communication bus 515 may reside only on a single IC substrate that includes both the PMC 700 and the PMU 120. Alternatively, the communication bus 515 may communicatively couple different IC substrates on which the PMC 700 and the PMU 120 reside.
In some embodiments, the bus interface 706 allows the PMC 700 to communicate with the electronic system 130 via the communication bus 535. The communication bus 535 may include a serial bus or a parallel bus.
The PMA 114 may include a LEA, such as the exemplary embodiment illustrated in
In another embodiment, the PMC performs a method in which processing logic (e.g., hardware, software, or any combination thereof) receives an indication of one or more software-based power management states of the electronic system 130, and decodes the one or more software-based power management states. The processing logic generates a change in energy to be delivered to the electronic system 130 in response to the decoding. The processing logic generates the change, for example, by executing a PMA to dynamically adjust one or more voltages and/or one or more clock frequencies to be provided to the electronic system 130 in response to the decoding. In one embodiment, the indication is a hardware signal that is correlated to the one or more software-based power management states, and the processing logic decodes the software-based power management states using the hardware signal. In one embodiment, the hardware signal correlates to at least one of the G states, P states, D states, or C states as defined by the ACPI specification. For example, the current Intel platform implements Mobile Voltage Positioning 6.5, which defines two signals: 1) the DPRSLPVR signal that indicates that the processor is in a deeper sleep state (deeper than a normal state); and 2) the PSI# indicates that the processor is in a low current state (lower than a normal state). By monitoring one or both of these signals, processing logic can see when the processor is an active or idle ACPI state. In some cases, the processing logic can monitor status signals from the peripherals with the assumption that when the peripheral status changes, there must be a corresponding change in ACPI state. In another embodiment, the processing logic could decode CPU core regulator Voltage ID (VID) codes, since the VID codes could be correlated to the processing power states (C states). Alternatively, the hardware signal may correlate to other types of software-based power management states.
In another embodiment, the processing logic receives multiple hardware signals, such as both the PSI# and DPRSLPVR signals, as the indication, and logically combines the two signals to decode the software-based power management states. In this case, the logical combination of the multiple hardware signals correlates to the one or more software-based power management states, such as the ACPI states.
In another embodiment, the processing logic receives one or more signals indicative of system energy consumption, or indicative of peripheral energy consumption. The system or peripheral energy consumption indicates the system activity or peripheral activity. By monitoring changes in the peripheral energy consumption, processing logic can estimate when the system (or peripheral) is in an active or idle ACPI state. In one embodiment, the processing logic can use a threshold, and if the activity is above the threshold, the processing logic determines that the ACPI state is active, and if the activity is below the threshold, the processing logic determines that the ACPI states is inactive. In other embodiments, the processing logic may use multiple thresholds. In more complex systems, the processing logic can calculate the rate of change of the energy consumption, as well as the amplitude of the change, to isolate different activity types, allows the processing logic to more precisely identify the ACPI state. Alternatively, the processing logic can estimate the ACPI state using other methods as would be appreciated by one of ordinary skill in the art having the benefit of this disclosure. In these embodiments, the system or peripheral energy consumption correlates to the one or more software-based power management states.
In one embodiment, the electronic system 130 includes the processor and one or more peripherals, such as a HDD or an ODD. The processing logic measures the current for HDD or ODD activity for the peripheral energy consumption, and based on changes to the peripheral energy consumption, the processing logic determines the appropriate ACPI state. In another embodiment, the processing logic measures a combined Universal Serial Bus (USB) device current at a point on the electronic system (e.g., at a point on the motherboard). The processing logic filters the signal at one or more cutoff frequencies (e.g., using one or more low pass filters). The processing logic can substract the different filtered signals to get corresponding activity signals that are proportional to the rate of change and magnitude of the device current demand. The rate of change and magnitude of the current demand can be correlated to the one or more software-bases power management states. Alternatively, this method of measuring energy consumption may be used for other peripheral devices than USB devices. For example, the processing logic can measure the supply current being provided to any peripheral device, and can determine the ACPI state based on this measurement.
In another embodiment, the processing logic receives one or more signals indicative of system (or peripheral) energy consumption, as well as one or more hardware signals as described above. The processing logic logically combines the hardware signals and the energy consumption signals (e.g., consumption measurements) for decoding the software-based power management states.
In another embodiment, the processing logic detects changes in the one or more software-based power management states that correspond to changes in a processing demand of the electronic system, and generates changes in energy to be delivered to the electronic system based on the changes in the processing demand.
As described herein, in some embodiments, the software-based power management state (e.g., ACPI state) of a processor is held in software, and thus, may be directly observable outside of the processor on some current hardware platforms. Thus, the software-based power management states may need to be estimated, or otherwise inferred from other indications of the state, as described herein.
Based on the input to the state decoder 912, the state decoder 912 outputs an ACPI state estimate to the PMA 114 to change the operating state of the PMU 120. In the case of the PMA being implemented in hardware, the decoded ACPI states can be directly mapped to the PMA states in the hardware state machine, such as illustrated in
The exemplary computing system 1100 includes a processing device 1102, a main memory 1104 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), a static memory 1106 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1116, each of which communicate with each other via a bus 1130.
Processing device 1102 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 1102 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 1102 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 1102 is configured to execute the processing logic (e.g., software-based power management state decoding 1126) for performing the operations and steps discussed herein.
The computing system 1100 may further include a network interface device 1122. The computing system 1100 also may include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1112 (e.g., a keyboard), a cursor control device 1114 (e.g., a mouse), and a signal generation device 1120 (e.g., a speaker).
The data storage device 1116 may include a computer-readable storage medium 1124 on which is stored one or more sets of instructions (e.g., software-based power management state decoding 1126) embodying any one or more of the methodologies or functions described herein. The software-based power management state decoding 1126 may also reside, completely or at least partially, within the main memory 1104 and/or within the processing device 1102 during execution thereof by the computing system 1100, the main memory 1104 and the processing device 1102 also constituting computer-readable storage media. The software-based power management state decoding 1126 may further be transmitted or received over a network via the network interface device 1122.
While the computer-readable storage medium 1124 is shown in an exemplary embodiment to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present embodiments. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, magnetic media, or other types of mediums for storing the instructions. The term “computer-readable transmission medium” shall be taken to include any medium that is capable of transmitting a set of instructions for execution by the machine to cause the machine to perform any one or more of the methodologies of the present embodiments.
The software-based power management states decoding module 1132, components, and other features described herein (for example in relation to
In other embodiments, the mapping between the software-based power management states of the electronic system 130 and the operating states of the PMU 120 may be done in a software-like manner, such as using a table. In these embodiments, the table could have, for each ACPI state, the voltage, frequency, and timeout values for each of the PMA states. Upon detecting a change in ACPI state, the corresponding table entry would be loaded into the PMA state machine. This wouldn't necessarily have to take place in software, it could be done with table lookups in hardware or by using the decoded ACPI state as an index to a multiplexer to select different values for the PMA.
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to utilize the invention and various embodiments with various modifications as may be suited to the particular use contemplated.
This application claims the benefit of U.S. Provisional Patent Application No. 61/266,079, filed on Dec. 2, 2009, the contents of which are incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61266079 | Dec 2009 | US |
