FIELD OF THE INVENTION

The present invention is related to computing systems, and more particularly to a system and method for adjusting to changes in processor performance.

BACKGROUND INFORMATION

Designers of mobile computing platforms are faced with a delicate balance. They seek to increase performance of the CPU but at the same time limit the power consumed in order to conserve battery life and limit the heat generated by the system. As part of this balancing act mobile systems often rely on software-controlled thermal management systems in order to operate efficiently within a varying group of thermal constraints. For instance, a specification may define two or more thresholds that indicate temperatures at which different forms of software-controlled thermal management are activated. Active objects may be used to define a temperature threshold for a given thermal zone. When this threshold is exceeded, the operating system activates an active device (e.g., a fan or a remote heat exchanger), or reduces the battery charge current.

Historically, CPUs have had a discrete operating point, characterized by a given frequency and power. The frequency is typically some multiple of the external clock delivered to the CPU; the power dissipated by the CPU is a function of the core frequency and voltage applied to the CPU. As the applied voltage level is increased, advanced processing technologies allow for the core frequency to be increased, resulting in a nonlinear increase in power consumption.

Mobile systems typically operate at the lowest voltage and frequency pair required to keep the typical dissipated power below mobile battery-powered limits. Because voltage can be increased to deliver higher performance for a given component, desktop CPUs typically deliver higher performance than their mobile counterparts at any given point in time.

Systems have been proposed which use passive thresholds to define a temperature at which the power of one or more CPUs should be reduced in order to cool a given thermal zone. In the Advanced Configuration and Power Interface (ACPI) model, the operating system varies the CPU duty cycle so the power dissipation of the CPU matches the power dissipation capabilities of the system. See,?Advanced Configuration and Power Interface (ACPI) Specification, Revision 1.0., published by Intel, Microsoft and Toshiba in 1997. This type of thermal management is termed "throttling" or "passive cooling. To support throttling, the ACPI model defines registers that allow the operating system to control the duty cycle of the CPU.

Throttling reduces the heat generated by the mobile computing platform but does so without regard for processing efficiency. What is needed is a system and method for reducing power generation without throttling the CPU.

SUMMARY OF THE INVENTION

In a computer system having a processor capable of operating at a plurality of performance states, including a first and a second performance state, wherein while the processor operates in any of the performance states it executes tasks at an expected processing performance, a system and method is described for dynamically adjusting to transitions between the first and second performance states. A determination is made that a performance state change is needed and a transition is initiated. The system halts task scheduling, measures CPU performance at the new performance state and resumes task scheduling within the constraints of the new performance state. The system also adjusts tasks as a function of CPU performance within the new performance state, wherein adjusting includes notifying each task of the transition between performance states.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

A computer system?10?with enhanced thermal management characteristics is shown in FIG.?1. System?10?includes a processor?12?connected to a memory?14?and to performance control logic?16. In one embodiment, performance control logic?16?places processor?12?in one of a plurality of discrete performance states by manipulating performance control input?18. Each of the performance states provides a certain level of processor performance while executing user threads.

The presence of a plurality of performance states allows a given processor?12?to operate at increased performance levels in mobile systems when additional active cooling can be provided by the system. A CPU with performance state transition support is capable of dynamically switching between two or more discrete operating points (voltage/frequency pairs) by altering the bus ratio multiplier or the core voltage. The operating system is responsible for managing these transitions to deliver the maximum performance possible while ensuring that battery life, thermal constraints and system integrity are not compromised.

To ensure stable transitions, in one embodiment, performance state transitions can only occur across resets. In another embodiment, however, performance state transitions are permitted to occur on either reset or by entering a quiescent state such as deep sleep. In yet another embodiment, performance control logic?16?is designed to permit transitions while the CPU is running. Such an approach may require additional logic to prevent race conditions and other sources of instability.

In one embodiment, as is shown in?FIG. 2a, processor?12?shifts between performance states as a function of a voltage level applied to the power input (V_cc) of processor?12. In another embodiment, as is shown in?FIG. 2b, processor?12?shifts between performance states as a function of the frequency of a periodic waveform applied to the clock input (CLK) of processor?12.

In a third embodiment, processor?12?shifts between performance states both as a function of a voltage level applied to the power input of processor?12and as a function of the frequency of a periodic waveform applied to the clock input of processor?12. One such embodiment is shown in?FIG. 2c. In the third embodiment, performance states are defined as core frequency and voltage pairs, and are made possible through the use of voltage reduction technology. By increasing the core voltage, a processor?12?can operate at higher frequencies. In one such embodiment, the performance state of processor?12?can be increased to desktop levels of performance (and power consumption). Such platforms therefore must be equipped with enhanced thermal capabilities in order to dissipate power generated at the highest performance states. At the same time, system?10?also requires enhanced power supply capabilities in order to effectively move between power supply voltages.

In another embodiment, performance control logic?16?provides a continuous range of voltage levels and adjusts the performance level of processor?12as a function of a voltage level or a clock frequency supplied by performance control logic?16.

Finally, in one embodiment, performance control logic?16?simply modifies the core frequency to bus frequency ratio seen by processor?12, in order to move to a different performance state.

In one embodiment, performance control logic?16?includes circuitry that allows the CPU performance to be altered while the computer is functioning. In one such embodiment, logic?16?alters the performance of the CPU by changing the bus to core ratio that is latched from signals IGGNE#, A20M#, LINTO#, LINT1# during a hard processor reset. This allows the processor to run at different core frequencies depending upon the available system power in a mobile computer depending upon the amount of active cooling that can be accommodated given the system power constraints. Note that the external bus frequency is not altered, simply the internal core frequency is changed. In addition, in order to run at faster speeds (essentially above 100%), the voltage is altered in addition to the bus ratio. This works in accordance with voltage reduction technology that allows a given processor to run at higher frequency when a higher voltage is applied. The side result, is that the power dissipated increase in a roughly cube-law fashion with increases in performance.

For example, a mobile system might run at 300/100 (CPU core frequency/frontside bus frequency) while on battery, at 350/100 while the AC adapter is inserted, and at 400/100 while docked. This allows the notebook computer to operate at desktop performance levels when it is connected to a docking station that can provide the additional cooling needed to dissipate the additional CPU power.

In one embodiment, processor?12?includes a hard reset capability used to perform state transitions. This means that for this embodiment, the entire processor state and L1/L2 cache state is lost. In order to accommodate dynamic performance state transitions, for one such embodiment, the system firmware makes this reset and all of its associated side effects transparent to the operating system.

In one embodiment, performance transitions are governed by a cache protection mechanism and by a transition control/status mechanism. The cache protection mechanism is used by the operating system to protect the CPU‘s caches during a performance state transition. The transition control/status mechanism includes a set of registers used to initiate transitions between different performance states, as well as to determine the current CPU performance state. In addition, in one embodiment, a separate voltage control is provided for moving between voltage levels at the processor. In one such embodiment, the voltage control includes separate voltage sequencing which operates under control of the operating system.

To operate correctly in systems having performance state transition capability, the operating system must deal with the changes in processor performance. In situations where the operating system uses an internal time-stamp counter to implement software delays for device drivers, changes in the CPU core frequency may cause proportionate charges in the time-stamp counter, thereby altering the delay generated by the operating system function, and possibly causing device driver failure due to timing parameter violation. The operating system should take this into account when performing a performance state transaction.

In addition, allowing performance state transitions drastically alters the CPU performance (i.e. MIPS). This is not a problem for normal applications, where a task will simply take less or more time depending upon the amount of CPU bandwidth. It is, however, a problem for real-time applications. Real-time applications typically have a requirement of a certain amount of instruction throughput per time quantum (i.e. MIPS/millisecond). As a result, technology will alter the MIPS of the processor. In one embodiment, therefore, a mechanism is defined to notify each process using real-time threads to adjust to the new processor performance.

In one embodiment, processor?12?is limited to switching performance states only during relatively quiescent states. In one such embodiment, as can be seen in?FIG. 3, at?30?a determination is made as to whether a performance state change is needed. If not, control remains at?30. If, however, a determination is made that a performance state change is needed, control moves to?32?and system?10?waits for processor?12?to enter a quiescent state. When the processor enters a quiescent state, control moves to?34?and performance control logic?16?moves processor?12?to a new performance state. In one embodiment, performance control logic?16?ensures that processor?12?is in a relatively quiescent state by intercepting all interrupts. In another embodiment, processor?12?is taken into a Deep Sleep state to ensure that it is quiescent.

In one embodiment, performance control logic?16?and processor?12?cooperate to provide a plurality of performance states. In one embodiment, system10?includes a low power state and a high performance state. Low power state is used to conserve battery power and reduce heat generated by system10. High performance state provides the highest processing state possible given the power supply and thermal capabilities of system?10. In another embodiment, system?10?includes a plurality of high performance states covering a range of processing performance.

Performance state transitions introduce three potential software issues that must be addressed. The first issue is that these transitions dramatically change the performance of the CPU, which requires an accurate implementation of software timing methodologies. The second issue is that these transitions affect the ability of the system to accurately execute real time threads. The third issue is that these transitions induce additional latency into the operating system transition.

Software Timing Issues

As noted above, the fact that a processor?12?has a plurality of performance states does not necessarily give rise to software timing issues. If, for example, the performance level is set at boot time and never changed, there will be no software timing problems due to the fact that processor?12?has a plurality of performance states, as this is no different than booting the system with a different performance CPU. However, when the CPU performance level is increased or decreased while the system is running (e.g., during AC insertion or removal), several operating system and application software issues must be considered.

Software timing is critical for many operations, particularly when the software communicates directly with the hardware (e.g., device drivers, SMI code, BIOS). For these cases, timeouts are typically needed to guarantee that the minimum time constraints are met. In other words, the delay is expected to be at least some specified minimum value (it could be more). In order to implement delays of this nature, poorly written software may rely upon sections of code that have been timed either at boot time or (even worse) during the software development cycle. These sorts of timing loops are extremely primitive and can exhibit wildly varying actual timing values depending upon CPU performance, CPU throttling, background task execution requirements, and interrupt handler CPU demands. This type of code uses the following algorithm to calibrate a timing loop:

1) Read and save CPU speed independent timer (e.g., 8254 PIT timer zero)

2) Loop a fixed number of times on a delay code fragment (same code fragment as used in delay routine)

3) Read CPU speed independent timer

4) Subtract timer read of #1 from timer read of #3 to indicate elapsed time

5) Divide elapsed times by number of loops to indicate time per loop

6) Store time per loop in memory for later use

A delay routine such as above calculates the number of loops required to implement the requested timing delay values by dividing the time requested by the time per loop. Although primitive, this delay provides a minimum constrained delay in non-performance-state-enabled systems. However, this type of delay poses a problem for performance-state-enabled systems because the system may be calibrated at the low power performance level, and then transition to a higher performance state during runtime. Because the software is not notified of the CPU performance change, it does not get a chance to recalibrate, and as a result the delays could be shortened below some minimum timeout value. This situation can result in failure if the minimum timing (e.g., a timeout used for a hardware device to become ready) causes device failure. Clearly, this sort of timing delay methodology should be discouraged.

The next type of timing delay is accomplished by reading a hardware register directly and calculating the elapsed time between successive reads. This delay is calibrated by calculating the known frequency of the timer. The code then performs reads of the current time to delay some predetermined amount of time (TimePerTick×NumberOfTicks=TotalTime). The following sequence of the steps is performed to generate a delay using this technique (assuming count up timer):

1) Read and save initial timer value

2) Divide requested time delay by timer tick granularity

3) Add timer ticks of step 2 to initial timer value of step 1

4) Read timer value until timer value of step 4 is above or equal to timer value needed of step 3

This type of timing mechanism can generate CPU-speed independent delays if the timer itself is CPU speed independent. One system timer that is not CPU speed independent is the CPU Time Stamp Counter, which is incremented at the internal core clock frequency. If operation of the CPU Time Stamp Counter is modified as a function of performance state, this type of timing delay implementation is not recommended for Performance-state-enabled systems.

Computer systems have been designed using architectures that provide one or more CPU-speed independent mechanisms for implementing timing delays in software. The operating system should use one of these CPU-speed independent mechanisms in order to provide robust APIs with solid timing services for performance-state-enabled platforms. Some examples of CPU-speed independent mechanisms available in, for instance, architectures designed by Intel Corporation are as follows:

Programmable Interval Timer?0?(IRQ0)

Real-Time Clock Periodic Rate Interrupt (IRQ8)

ACPI Power Management Timer (SCI)

Timing services based upon these or other CPU-speed independent mechanisms will not become inaccurate as a result of transitions between performance states.

Real Time Threads

Multitasking operating systems work by dividing the bandwidth of the processor across one or more threads of execution. Preemptive multitasking allows each thread to execute for some amount of time, and then the operating system moves onto to some other thread waiting to be executed. Typically, threads of execution are scheduled by means of a priority-based scheme, and typically, real-time threads receive nearly the highest priority. Because of their nature, real-time threads cannot afford to be delayed or interrupted for any length of time without losing data, dropping frames, or performing poorly (depends upon application). In addition, real-time threads must have a means for determining the available system bandwidth at boot, in order to gauge the amount of processing they can safely perform during each iteration of their execution. The diagram shown in?FIG. 4a?depicts a simple round-robin execution scheme where kernel?40?simply divides the available performance (minus some percentage for overhead) across the number of real-time threads (42.0-42.n) to be scheduled.

For example, if there were ten threads and processor had a sustained bandwidth of 100 MIPs with a scheduling interrupt of 1ms, the kernel could allocate approximately 0.1 MIPS per millisecond, with a 10 ms interval.

Performance state transition technology requires that the operating system define a communication mechanism between threads to communicate the available bandwidth at any given time. This method requires that a software notification mechanism be defined by the operating system. In one embodiment, this is implemented as a Notify0 operation in an ACPI-compliant operating system, such that it can easily be called under system firmware‘s control. Upon invocation of this method, in one embodiment the operating system performs the following actions shown in?FIG. 4b.

At?45, the operating systems halts task scheduling. Control then moves to?46, where the operating system measures CPU performance. In one embodiment, CPU performance is a function of CPU internal frequency and the effective CPU bandwidth (i.e. MIPS). Control then moves to?47, where the operating system resumes task scheduling. Control then moves to?48, where the operating system adjusts software delay routines to new CPU internal frequency, and to?49, where the operating system calculates an allotted bandwidth per unit time and notifies each process of the performance change.

By using this process, the operating system can dynamically adjust to changes in processor performance resulting from threads being created or destroyed, or by actual changes in performance resulting from thermal throttling, performance state transition, or other means. In order for this approach to be effective real-time threads should have the ability to rescale dynamically. The block diagram shown in?FIG. 4b?depicts the paths that each of the three different usage models use.

This method allows an operating system to dynamically adjust to changing CPU performance, and provides support for performance state transition technology.

Latency Due to Performance State Transitions

Another software visible impact of a performance-state-enabled approach is that transitions between performance states hold off CPU operation for the duration of time it takes to switch between the performance states. This induces additional latency into the operating system transition that, if of long enough duration, could cause operating system failure. Care must therefore be taken to limit the latency due to performance state transitions.

In one embodiment, the latency due to performance state transitions is limited to no more than approximately two hundred microseconds. Since operating systems currently operate with latencies which approach or even exceed this amount of performance state transition latency, such latency should not cause any appreciable problems for today‘s operating systems and peripheral demands. (The following events can induce latencies that may approach or even exceed the duration of performance state transition latencies: shared interrupt processing (e.g., PCI interrupt determination), coincident interrupt processing (probable net sum of masked ISR service time), CPU throttling (e.g., 244 microseconds), C2 State Exit Latency (e.g., 50 microseconds), C3 State Exit Latency (e.g., 1 millisecond) and SMI Event Processing (e.g., 500 microseconds).)

Managing Multiple Performance States

In one embodiment, processor?12?includes configuration control. In one such embodiment, objects are added to a configuration specification in order to allow for operating system control of processor performance states. For example, objects can be added to the ACPI specification described above.

In yet another embodiment, transitions between performance states is controlled via a separate driver added to an existing operating system. In one WINDOWS 98? embodiment, the driver operates processor?12?in the most desirable processor state based on, for instance, receipt of WINDOWS 98? operating system WDM power state messages.

In yet another embodiment, transitions between performance states are managed by means of the system management interrupt (SMI) handler. This embodiment will be discussed in more detail below.

Finally, in one embodiment, the system BIOS sets the proper performance state during the power on self-test (POST). In one such embodiment, the proper performance state is selected based on user setup options. In another such embodiment, the proper state is a function of an external parameter (such as the state of the AC adapter or detection of the docking station).

A method of shifting between performance states under operating system control is described next. In order to transition between CPU states, the system firmware must determine if system?10?does, in fact, have a plurality of performance states. In one embodiment, this is determined by reading a model-specific register. In one embodiment, the model-specific register includes a transition enable bit used to indicate if processor?12?is able to switch between performance states and a state bit indicating which of two performance states processor?12?will boot into.

In another embodiment, the single state bit is replaced by a state field having two or more state bits encoding three or more states into which processor12?can transition. In one such embodiment, the state field values are indices into a table incorporated into system ROM, such that the system BIOS can determine the actual CPU speed based on these values.

In one embodiment the transition enable bit indicates whether the CPU will switch between two internal bus core ratios upon exit from a quiescent or a Deep Sleep state based upon an input selection signal labeled HI/LO#.

In order to provide maximum flexibility and allow for easy rectification of any potential end-user problems, in one embodiment system?10?includes two BIOS setup options for processor performance configuration: Static Performance State Transition (SPST) Enable/Disable and Dynamic Performance State Transition (DPST) Enable/Disable. Static Performance State Transition Enable/Disable allows an end user to completely disable performance state transitions if any problems are experienced or if additional power dissipation is not desired, even when connected to the AC adapter. This setup option, therefore, transforms a performance-state-enabled system into a normal mobile system. (In other words, the platform should boot in the Low Power State, should not report performance state transition capabilities to the operating system (either through ACPI or other means), and should return a performance state transition disable code to the operating system.

In one embodiment, a Dynamic Performance State Transition Enable/Disable is provided for problem resolution purposes only. This allows an end-user to turn off dynamic switching between performance states in the event that the software and/or hardware configuration experiences abnormalities or failures as a result of performance state transitions. In one embodiment, when Dynamic Performance State Transition is enabled, the system BIOS loads the performance state transition ACPI objects into the ACPI tables, and enables the system SMI-handler to dynamically switch between performance states.

If this option is set to disabled, but performance state transitions are still enabled by the end user, in one embodiment the system BIOS performs a static assignment of the state. In one such embodiment, the system BIOS samples the system state and places the CPU into the appropriate state just prior to boot. In this case, system?10?boots in the Low Power State or the High Performance State, and returns a transition-disabled code to the driver. In addition, system?10?may suppress reporting of performance transition capabilities to the operating system (either through ACPI or by any other means).

In addition to evaluating the CPU‘s capabilities as well as the user‘s preferences, in one embodiment the system BIOS determines if the platform is capable of supporting performance state transitions. Whatever method the OEM chooses to determine this, it is critical that it be fail-safe. Attempting a performance state transition without the appropriate system electronics hardware in place can result in operating system failure. In one embodiment, when the system BIOS determines that both the CPU and system electronics can support performance state transitions, it can proceed with one of several possible sequences:

First, if performance state transitions are disabled, the system BIOS defaults to the disabled state, i.e., no action is required. This means that all system firmware components can assume that the system is a mobile system without performance state transition enhancements. These components include, but are not limited to, the following components: a) system BIOS firmware that performs a static performance state transition; b) system BIOS firmware that loads ACPI tables into memory; c) system management firmware that manages performance state transitions when not in ACPI mode; d) embedded controller firmware that assists with performance state transitions; and e) system management firmware that communicates with the operating system performance state transitions drivers (if any).

Second, if performance state transitions are enabled for static operation but disabled for dynamic operation, the system BIOS does not perform any performance state transition notifications to the aforementioned firmware components, but instead simply samples the system state and sets the proper CPU operating state during BIOS post. In one embodiment this operation is limited to being performed only on cold boots and not on wake (i.e., resume) events that issue a CPU reset.

Finally, if performance state transitions are enabled for dynamic operation, in one embodiment the system BIOS executes the following sequence:

Assigns initial speed at boot

Notifies system firmware components of performance state transition capability

(SMI handler, embedded controller, etc.)

Notifies system thermal management firmware of performance state transition

capability

Constructs ACPI Objects for performance state transitions

Adds the performance state transition ACPI Objects to Secondary System

Description Table (SSDT)

Adds a pointer to performance state transition SSDT to RSDT

The system is then bootstrapped as normal. For the situation where an ACPI-operating system is installed and a legacy solution is enabled, in one embodiment the SMI handler immediately ceases to manage performance state transitions after receiving the ACPI enable command from the operating system.?FIG. 5?illustrates one embodiment of a boot process which can be used in system having a plurality of performance states.

In the process of?FIG. 5, at?50?a cold reset event occurs (e.g., power on). Control moves to?52?where a check is made to determine if system?10?is capable of performance state transitions (PSTs). If not, control moves to?66?and system?10?boots up as a normal mobile system.

If, however, a determination is made at?52?that system?10?is capable of performance state transitions (PSTs), control moves to?54, where a check is made to determine if system?10?is configured for Static Performance State Transitions (SPSTs). If not, control moves to?66?and system?10?boots up as a normal mobile system.

If, however, a determination is made at?54?that system?10?is configured for Static Performance State Transitions (SPSTs), control moves to?56, where a check is made to determine if system?10?is configured for Dynamic Performance State Transitions (DPSTs). If not, control moves to?62.

If, however, a determination is made at?56?that system?10?is configured for Dynamic Performance State Transitions (DPSTs), control moves to?58, where a Performance State Transition SSDT is added to the ACPI tables. Control then moves to?60?where hardware and firmware components are notified that performance state transitions are enabled. Control then moves to?62.

At?62, a check is made to see if system?10?is connected to a power source other than its internal battery (e.g., an external AC or DC power supply). If not, control moves to?66?and system?10?boots up as in the low power performance state.

If, however, a determination is made at?62?that system?10?is connected to a power source other than its internal battery, control moves to?64?and system?10?is configured to boot into a high performance state. Control then moves to?66?and system?10?boots up as in the high performance state.

Regardless of the support model (ACPI, driver or SMI), the transition methodology between performance states remains the same. The following sequence of steps is required for the system firmware (SMI handler or system BIOS), operating system, or driver to perform a transition to another performance state: 1) Software determines that state change is required; 2) Software writes to performance control register state number for new CPU state; 3) Software enables transition events; 4) Software performs a transition event; 5) Hardware transitions CPU; 6) Software reads MSR register and determines if transition was successful; 7) Software repeats steps 1-6 until successful.

For a system?10?that incorporates two states (one Low Power State and one High Performance State), the performance control field can simply consist of one bit. In one embodiment, this is implemented as one general-purpose output connected to a memory- or I/O-mapped register in the CPU‘s address space. When changed, this output signal causes the performance control logic to initiate a performance state transition on the next level three (i.e., Deep Sleep state) entry. When the software performs this entry, the performance control logic delivers the appropriate signals to the CPU causing it to begin operating at the new performance level. In another embodiment, the performance control logic initiates a performance state transition when processor?12?enters a quiescent state. In yet another embodiment, the transition of one or more bits in the performance control field acts as an interrupt to processor?12. Processor?12?then moves to another performance state as part of the interrupt handling routine.

In another embodiment, a performance-state-enabled CPU changes performance states based upon the state of the LO_HI# input pin when exiting from a quiescent state. Based upon the state of this signal, the CPU selects a new bus ratio, which changes the internal core operating frequency of the CPU. A performance-state-enabled CPU always exits from a hard reset (CPURESET#) in the Low Power State.

In one embodiment, hardware performs the following transition sequence upon a transition event after the performance register value has changed:

1) The system core logic begins to transition the CPU to the quiescent state. (This includes the assertion of STPCLK#, followed by the CPU issuing a stop grant bus cycle, followed by the core logic stopping the CPU input clocks.) If a stop-break event happens to occur before the core logic begins to gate off the CPU clocks, the logic should abort the performance state transition request. This means that an interrupt has occurred nearly concurrently with the performance state transition level three read and should be serviced without adding the performance state transition latency overhead.

2) If a break event does not occur and the core logic successfully transitions the CPU to the quiescent state, the performance control logic takes over. Because the performance control logic changes CPU signals and power supply voltages that can only be changed while the CPU is not running, the control logic gates off critical signals to the CPU in order to ensure that an early break event does not prematurely wake the CPU before the performance state transition is complete.

3) After the CPU voltage and LO_HI# signal have been adjusted to their new levels and have stabilized, the performance control logic ungates the CPU‘s signals. In the event that an early transition event has occurred while the performance control logic was performing the performance state transition, the control logic ensures that the appropriate timings between the signal transitions are observed (i.e., the control logic ungates the CPU critical signals in a controlled fashion).

As noted above, in one embodiment transitions between performance states are controlled through ACPI objects. In one such embodiment, the system BIOS determines at boot time if performance state transitions are enabled. If so, the system BIOS loads the tables that include the ACPI performance state transition control objects. These objects give the operating system all the information it needs to manage dynamic performance state transitions.

As noted above, the presence of a plurality of performance states allows a given processor?12?to operate at increased performance levels in mobile systems when additional active cooling can be provided by the system. A CPU with performance state transition support is capable of dynamically switching between two or more discrete operating points (voltage/frequency pairs) by altering the bus ratio multiplier and voltage while the CPU is momentarily placed into the quiescent state. In one embodiment the operating system is responsible for managing these transitions (via ACPI mechanisms) to deliver the maximum performance possible while ensuring that battery life and thermal constraints are not compromised. The next section describes the changes needed for the ACPI to properly manage these transitions.

In one embodiment, processor?12?reports its performance state transition capabilities in the ACPI name space and allows the OS to manage transitions between performance states. These transitions are initiated when dynamic insertion or removal events take place (AC, dock, etc.), as abnormal thermal conditions occur, or as other system requirements change. The ACPI name space objects listed below inform the OS of the system‘s capabilities. These include control mechanism access and system capabilities.

Transitions are controlled by the operating system. In order to perform a performance state transition, the OS first writes the next performance state (in the form of a number) to the Performance State Command Field. This prepares the hardware to perform a performance state transition on the next P_LVL3 read. The P_LVL3 places the CPU in a Deep Sleep state while appropriate logic and power supply changes are made to facilitate operation in the new state. The write to the Performance State Command Field further prepares the hardware to wake up the CPU immediately upon completing the performance state transition. However, the hardware will also wake up the CPU immediately upon any enabled interrupt or bus master request that occurs before the CPU has fully transitioned into the Deep Sleep state.

Once the CPU has transitioned into the Deep Sleep state, performance control logic?16?prevents the CPU from waking up on any bus master requests or interrupts until the transition is completed successfully. Because an early wake event can occur before the transition is complete, the OS must verify if the performance state transition request was successful by reading a CPU model-specific register. In the event that the performance state does not match the requested state, the OS should retry the operation as soon as possible.

In one embodiment three ACPI objects are added to system?10?to support performance state transitions. The three are: Presence Detect (_PD), Supported States (_SS) and Present Capabilities (_PC).

The Presence Detect (_PD) object resides under the processor object present in the ACPI namespace. This object includes the following two pieces of information: a descriptor for the performance control field and a pointer to a model-specific register (MSR) inside the processor?12. The descriptor for the performance control field points to a specific register in memory or I/O space that the OS writes in order to initiate a transition between different CPU states. In one embodiment, this consists simply of one bit (signifying two states) tied to a general-purpose output on the chipset. This object includes a bit field position and a bit field size that further define the exact operation region for the OS to write in order to configure the performance control logic properly. The OS should preserve all other bits within this field as they will be used for other critical system control and are likely to be manipulated by system ACPI Machine Language (AML) code. In one embodiment, the OS is responsible for synchronizing accesses to this region to ensure that coincident read/modify/write cycles from multiple threads of execution do not result in register corruption.

After the OS writes to the performance control field to prepare the system for a performance state transition, it then masks interrupts, enables bus master break events, and performs a level three read. The hardware detects that the CPU is in the Deep Sleep state, and transitions the CPU to the requested performance state.

In the event that an unmasked interrupt occurs coincident with the level three read, processor?12?does not transition to the Deep Sleep state, and the performance control logic does not perform the performance state transition. As a result, the operating system must read the CPU performance state after waking up from a performance state transition request to ensure that the transition was successful. The second piece of information in the Presence Detect object is used for exactly this purpose. It is a pointer to a model-specific register (MSR) inside the CPU that reflects the current operating point of the CPU. This pointer contains an index, bit offset, and bit field size values such that the OS can read and then isolate the region of interest within the MSR.

The Supported States (_SS) object resides under the processor object present in the ACPI namespace, and indicates the performance state transition capabilities of the system. Each _SS object present in the system is formatted as a package of packages. There can be any number of packages inside each _SS object, each of which corresponds to a particular CPU operating point. The _SS object lists all of the CPU performance states that a given platform is ever capable of entering. The _SS object does not indicate which objects are available at the current time. Each package contained within the _SS object lists at most one Low Power State, and at least one High Performance State. The Low Power State is defined to be the state with the lowest level of power consumption. Any other states listed within the _SS object are considered High Performance States.

In one embodiment, the packages within the _SS objects representing each processor state are ranked in descending order by power consumption. By using this convention, the OS can then assume that the first entry represents the highest-performing High Performance State, and the last entry represents the Low Power State. Any objects in between represent additional High Performance States.

Each internal package within the _SS object represents a different performance state and includes the following four pieces of information: the internal core frequency of the performance state, the typical power dissipation of the performance state, the value to write to the performance control field and the MSR data read value.

The first number in the _SS object is the internal core frequency of the performance state. Because the core frequency represents the internal CPU clock rate for each state, it indicates the theoretical maximum relative performance (based upon linear increase in performance with no external bus cycles) that can be achieved by switching between states. The base value of the number may or may not have any physical meaning, but the ratio of numbers between states indicates (on average) the relative performance difference between the two states being compared.

The second number in each package is the typical power dissipation of the performance state. This is the average power consumed only by processor12. One can also expect that the power consumption of the supporting components (e.g. graphics, memory controller) will increase as the CPU performance increases.

The third piece of information is the value to be written to the performance control field in order to facilitate a state transition on the next level three read. The OS performs a read/modify/write of the performance control field using this data pattern in order to attempt a transition to that particular performance state.

The last piece of information contained in each entry is the MSR data read value. This is the value that the OS compares against the value read from the CPU‘s MSR indicating the current performance state. This comparison allows the OS to determine if a transition was successful, as well as to determine what the initial CPU performance state is after the system is switched into ACPI mode. Note that the OS cannot assume anything about the initial performance state of the CPU. The system management handler manages each performance state transition until the OS issues the ACPI enable command to the ACPI command port. At this point, the SMI handler will cease all power management and thermal management activities, and will perform no further CPU performance transitions (CPU could be in either the Low Power State or a High Performance State). As a result of this, the OS should read the CPU‘s MSR value pointed to by the PD object after transitioning the system to ACPI mode and then compare it against the _SS CPU states in order to determine the initial boot speed.

The Present Capabilities (_PC) method dynamically reports the number of High Performance States that the system can support at any given time. This is accomplished by referring to the numbering scheme used by the _SS object. The High Performance State (with the highest power dissipation) is assigned number zero, while each additional High Performance State (ranked in descending order by power dissipation) is assigned a higher number until reaching the Low Power State which is given the number ‘n‘. The _PC method simply returns the number of the state that is currently available, which allows the OS to use the highest performance state that is indicated by _PC, as well as any higher numbered (lower power) state. In order to indicate to the OS that the _PC returned value has changed, AML code in the system will be responsible for issuing a Notify event to the _PC object.

The following sequence shows the steps required to change between performance states:

1) OS reads register defined by Command Field Resource Descriptor

2) OS clears read value starting at bit offset for bit field size

3) OS performs logical OR of desired new state value at bit offset for bit field size

4) OS writes modified value to register defined by Command Field Resource Descriptor

5) OS performs P_LVL3?read

6) CPU enters Deep Sleep state

7) Performance control logic immediately wakes up CPU upon transition completion, interrupt, or bus master request

8) OS reads MSR (64-bits) indicated by _PD

9) OS compares value at MSR bit offset for MSR bit field size to expected value (from _SS)

10) OS determines if transition was successful and repeats steps 5-9 if not.

The flowchart in?FIG. 6?illustrates an example operating system policy scheme for managing performance state transitions under the ACPI model. As can be seen in?FIG. 6?at?70, a pertinent event occurs such as connecting to an AC power supply, docking, passive thermal threshold, busy, idle. Control then moves to?72?where processor?12?evaluates the number of performance states available. Control then moves to?74?where a determination is made whether the temperature of system?10?is below a passive threshold. If so, control moves to?76?and throttling is disengaged. Control then moves to?80.

If at?74, a determination is made that the temperature is not below the passive threshold, control moves to?78?and a determination is made whether the CPU is in a high performance state. If so, control moves to?80. If not, however, control moves to?82?and the heat generated by the CPU is reduced through throttling.

At?80, a determination is made whether the operating system is busy. If not, the operating system at?84, transitions the CPU to the lowest power state.

If, at?80, a determination is made that the operating system is busy, control moves to?86?and a determination is made as to whether high performance states are available. If not, control moves to?84?and the operating system transitions the CPU to the lowest power state. If, however, a determination is made at?86?that high performance states are available, control moves to?88?and the CPU transitions to one of the higher performance states.

In an alternate embodiment, system?10?implements three registers that allow the OS to perform transitions between different performance states: Performance Control Registers #1 and 2 (PERF_CNT1?and PERF_CNT2) and a Performance Status (PERF_STS) register.

In one such embodiment, Performance Control Register #1 is a write-able register which allows the OS to write the desired next state to the hardware control mechanism. The next state value is then latched by the hardware until software performs a read of Performance Control Register #2 (PERF_CNT2) in order to initiate the transition to the requested state. The Performance Status register is a read-only register that returns the current CPU performance state.

In one embodiment, system?10?provides information to the OS indicating the cache protection mechanism to be used. In some designs, it is necessary to momentarily place the CPU in a non-operational state while the performance transition occurs. In this case, it might be that the processor is unable to respond to cache snoop cycles from external agents or other CPUs. To protect the integrity of the cache, in one embodiment the processor performance transition can optionally be protected by a cache flush and disable operation, or by a disable of the bus master arbiter. If the cache flush and disable mechanism is used, the OS first disables the cache (through a CPU specific mechanism), writes back and invalidates the contents, performs the transition, and enables the cache once the transition has completed. If the bus master arbiter mechanism is used, the OS first disables the bus master arbiter by setting the ACPI-defined PM2_CNT.ARB_DIS bit, performs the transition, and then clears the PM2_CNT.ARB_DIS bit.

In one embodiment, system?10?includes separate voltage controls which operate under control of the operating system. In one such embodiment, the operating system initiates voltage transitions as a separate operation in order to support changing the CPU‘s voltage while the system is running. Such an approach can potentially allow the duration of the actual transition sequence to be reduced. In one such embodiment, system?10?includes a write-able Performance Voltage Control Register (PERF_VCNT) and a readable Performance Voltage Status Register (PERF_VSTS). The Performance Voltage Status Register indicates when the voltage regulator has adjusted the voltage to the new target voltage. Because in such an embodiment the CPU is operational as the voltage changes, it will be necessary to sequence voltage transitions very carefully. Therefore, in one embodiment the OS initiates a voltage transition prior to a transition to a higher performance state, and initiates a voltage transition after a transition to a lower performance state. (This is because it is expected that the CPU cannot operate at a higher performance state without the higher voltage applied for that state.) In an embodiment having the registers discussed above, the OS first writes to the PERF_VCNT register to select the new voltage level and then wait for the voltage level to stabilize as indicated by a read of the PERF_VSTS register.

In one such embodiment, six ACPI objects are associated with processor performance control. Such an approach provides more flexibility than the three object embodiment described above. In one embodiment, the six objects are located under the processor object (\_PR) in system?10. In one multiprocessor embodiment, each processor has dedicated processor performance control registers, and corresponding, dedicated, processor performance control objects, in order for processor performance management to be enabled by the operating system.

In one embodiment, the Performance Cache Control (_PCC) object is a named object that indicates the type of cache protection that is required by the platform design. The Performance Cache control object includes three possible values to be reported: no cache protection required, bus master arbiter disable, and cache flush/disable. Under no cache protection required, the OS simply performs a transition while hardware ensures the transition does not effect cache coherency. Under bus master arbiter disable, the OS uses the ACPI-defined arbiter disable bit to turn off external bus masters while the performance transition is performed. (NOTE: This cannot be used in a multi-processor environment.) Under cache flush/disable, the OS disables the CPU‘s caches, writes back any dirty lines, and invalidates all lines prior to performing the transition. After completing the transition, the OS re-enables the CPU‘s caches.

The Performance Control Registers (_PCR) object includes pointers to the three registers directly involved with controlling a performance transition. These registers (PERF_CNT1, PERF_CNT2, and PERF_STS) are described within the -PCR object in the form of ACPI descriptors. PERF_CNT1?and PERF_CNT2?may or may not be at the same physical location. The OS uses these registers to control the actual performance transition.

The Performance Voltage Control Registers (_PVR) object includes pointers to the two registers involved with separate voltage control. In one embodiment, this object is optional; including it, however, indicates to the OS that separate voltage control is required. The two registers (PERF_VCNT and PERF_VSTS) are described within the _PVR object in the form of ACPI descriptors.

The Performance Supported States (_PSS) object is a package of packages describing all of the processor performance states that the given platform can support at any point in time. Each package within the object describes a particular performance state and contains six parameters: frequency, power, performance control value, voltage control value and voltage status value.

Frequency is the core frequency of the processor performance state in megahertz (MHZ). The OS uses this value to determine the relative performance difference between this and other performance states.

Power is the typical power dissipation of the processor performance state in milliwatts (mW). The OS uses this value to determine the efficiency of each state in order to adjust the demand threshold for making a transition to higher or lower performance states.

Performance Control Value is a value to write to the Performance Control Register #1 (PERF_CNT1) to initiate a transition to a particular performance state. The OS uses this value to prepare the hardware to perform a transition to a different performance state.

Performance Status Value is the value returned in the Performance Status Register (PERF_STS) to determine if the processor is in this particular performance state. The OS uses this value at initialization time to determine the initial processor performance state, and at runtime after transitions in order to verify that a performance transition was successful.

Voltage Control Value is the value to write to the Performance Voltage Control Register (PERF_VCNT) to initiate a transition to this voltage setting. When separate voltage control is required, the OS uses this value to write to the voltage control register in order to initiate a voltage transition.

Voltage Status Value is the value returned in the Performance Voltage Status Register (PERF_VSTS) to determine if the processor is at this particular voltage setting. The OS uses this value in order to ensure that the voltage is stable before initiating an actual performance transition.

The Performance Transition Latency (_PTL) object indicates to the OS the maximum amount of time that a performance transition requires on the given platform design. This value indicates the amount of time the processor is unavailable after initiating the performance transition sequence. Latency is not reported for separate voltage controls (if so equipped), because the processor is available during separate voltage control transitions. A time larger than 500-microseconds effectively disables processor performance control functionality.

The Performance Present Capabilities (_PPC) object is a method that dynamically returns the number of performance states that the platform is capable of supporting at any given time. This allows the platform to reduce or increase the number of available performance states based upon critical hardware dependencies. The OS immediately transitions out of a performance state that becomes unavailable as indicated by the _PPC method.

In one embodiment, when the OS desires to perform a transition to a new power state, it must first evaluate the system‘s present capabilities via the _PPC object. This tells the OS how many of the possible states are available at the present time. The OS then chooses the appropriate state based upon many factors, including system workload, thermal conditions, user preference, user cooling policy, and bandwidth requirements.

Once the OS has decided to initiate a performance transition, the OS protects the processor‘s caches, if needed, by disabling the bus master arbiter, or by disabling, writing back, and invalidating the processor‘s caches. The OS then retrieves the object in the _PSS package that describes that state, and writes the control value to the PERF_CNT1?register. The OS then performs a read of the PERF_CNT2?register to initiate the transition. Upon resuming instruction execution, the OS then reads the PERF_STS register and compares it to the status field in the PSS object for that state in order to determine if the transition was successful. If the operation was unsuccessful, the OS will retry the operation at a later time.

In addition, if a _PVR method is present, the OS manages separate CPU voltage controls. For instance, the OS increases the voltage prior to initiate a change to a higher performance state, and reduces the voltage only after performing a change to a lower performance state. This ensures that the CPU never runs at voltage that is lower than specified for a given frequency.

Each of these ACPI objects is described in more detail below.

The Performance Cache Control (_PCC) Object describes the cache control mechanism that is to be used by the operating system surrounding a performance transition. The object is a method that returns the type of cache protection mechanism that should be used by the OS. It has the format:

If the method returns a value of zero, it indicates that the platform does not need the OS to initiate any form of cache protection mechanism. No cache protection mechanism is required if the CPU is able to respond to cache snoop cycles while the transition is occurring.

If the method returns a value of one, it indicates that the OS should use the bus master arbiter bit to protect the CPU‘s caches. The bus master arbiter bit (ARB_DIS) is located in the least-significant bit of the PM2_CNT register. The OS will set this bit to one, thereby preventing any bus master traffic from occurring prior to initiating a performance transition. The OS will clear this bit immediately after completing a performance transition to allow bus masters to once again receive bus ownership.

If the method returns a value of two, it indicates that the OS should use the cache flush/disable method to protect the CPU‘s caches. In this case, the OS will disable, write-back and invalidate all lines in the CPU‘s caches (in a processor architecture specific manner) prior to initiating a performance transition. In this manner, the CPU‘s caches are kept coherent by ensuring that they are completely invalid after completing the transition. The OS will immediately re-enable the CPU‘s caches after completing a performance transition.

The Performance Control Register (_PCR) Object describes the registers used to initiate a performance transition. This object contains descriptors that describe the three registers (PERF_CNT1, PERF_CNT2, PERF_STS) directly involved with controlling the CPU performance state.

The OS writes to the PERF_CNT1?register to prepare the hardware for a performance transition. The value written to this register is encoded for each state supported by the platform, and is reported in the _PSS object as the PerfControl value. Once PERF_CNT1?is setup, the OS reads from the PERF_CNT2?register to initiate the actual transition. Lastly, the OS will read the PERF_STS register to determine if the transition was successful. The value returned in the PERF_STS register is also encoded and is reported in the _PSS object as the PerfStatus value.

The Performance Voltage Control Register (_PVR) Object is used to optionally describe the registers used to initiate separate voltage transitions. This object contains descriptors that describe the two registers (PERF_VCNT, PERF_VSTS) directly involved with controlling the CPU voltage.

The OS writes to the PERF_VCNT register to initiate the voltage transition. Voltage transitions are optional, and are only performed when a _PVR object is included in the ACPI tables. By definition, voltage transitions occur prior to transitions to higher performance states, and after transitions to lower performance states. This is done to ensure that the processor never operates at a voltage that is lower than that required for a given operating point. If this object is not included, the OS will assume that the hardware controls the voltage as part of the actual transition itself.

If separate voltage control is indicated (via the presence of the _PVR object), the OS first writes to the PERF_VCNT register to begin the voltage transition. Once this value is written, in one embodiment the hardware immediately begins changing the voltage to the new operating point. The value written to this register is encoded for each state supported by the platform, and is reported in the _PSS object as the VoltControl value. Once PERF_VCNT is setup, the OS will wait for the voltage to settle as indicated by the PERF_VSTS register. The value returned in the PERF_VSTS register is also encoded and is reported in the _PSS object as the VoltStatus value.

The Performance Supported States (_PSS) Object indicates to the OS the number of supported performance states that any given system can support. This object resides underneath all processor objects in an enabled system, and indicates the number of states supported by the platform. This object is a packaged list of information about available performance states, including internal CPU core frequency, typical power dissipation, control register values needed to transition between performance and voltage states, and status register values that allow the OS to verify performance transition and voltage status. The list is sorted in descending order by typical power dissipation. As a result, the ‘zeroth‘ entry describes the highest performance state and the ‘nth‘ entry describes the lowest performance state.

Each entry contains six pieces of data. CoreFreqI indicates the core CPU operating frequency (in MHZ) for state I. PowerI indicates the typical power dissipation (in miliwatts) for state I. PerfControlI indicates the value to be written to the Performance Control Register One (PERF_CNT1) in order to initiate a transition to performance state I. PerfStatusI indicates the value that the OS will read from the Performance Status Register (PERF_STS) and compare against to ensure that the performance transition to state I was successful. VoltControl indicates the voltage value to be written to the Performance Voltage Control Register (PERF_VCNT) in order to initiate a transition to voltage state I. VoltStatusI indicates the value the OS will read from the Performance Voltage Status Register (PERF_VSTS) and compare against to ensure that the voltage transition to state I was successful. If separate voltage control is not needed, the VoltControl and VoltStatus entries can be omitted.

The Performance Transition Latency (_PTL) Object indicates to the OS the maximum amount of time that a performance transition can require. The time indicates the maximum amount of time that the processor is unavailable, as measured from the point at which the OS initiates the performance transition (via a write to the PERF_CNT1?register, followed by a read of the PERF_CNT2?register), until the point at which the processor resumes instruction execution. The value is returned in microsecond units and must be less than 500 in order for the OS to enable processor performance control functionality.

This value does not indicate the time required for optional voltage transitions, as separate voltage transitions (by definition), do not halt instruction execution. As a result, the OS is free to schedule other tasks and handle processor interrupts while a separate voltage transition is in progress.

The Performance Present Capabilities (_PPC) Object is a method that dynamically indicates to the OS the highest performance state that is currently supported by the platform. This object resides under each processor object in an enabled system. In one embodiment, this method returns a number that indicates the number of the highest performance state that the OS can use at a given time. The OS may choose the state returned by the _PPC method or any lower power (higher numbered) state. As dynamic events occur, the platform can use the ACPI machine language notify operator pointed to system processor object to cause the OS to reevaluate the number of states available and take action.

In order to support dynamic changes of (_PPC object, processor objects in such an embodiment should support Notify events of type 0x80. Notify events of type 0x80 should cause the OS to reevaluate any _PPC objects residing under that particular processor object. This allows AML code to notify the OS when the number of supported states has changed as a result of an asynchronous event (power source change, thermal condition, dock event, etc.).

The sequence shown in?FIGS. 7a?and?b?describes one approach to a performance transition sequence. Some of the steps are conditionally executed depending upon the type of transition indicated by the objects. (NOTE: The term ‘I‘ is used to represent the number of the state to which the process is changing.)

In?FIG. 7a, at?300, a check is made to see if a separate voltage control is needed. If not, control moves to?308. If, however, a separate voltage control is needed, control moves to?302?and a check is made to determine if the transition is to a lower performance state. If so, control moves to?308.

If, however, the transition is to a lower performance state, control moves to?304?and a voltage control value is written to initiate the voltage transition. (For instance, one could write VoltControlI value to the PERF_VCNT register.) Control then moves to?306?and a check is made (e.g., read PERF_VSTS register) to determine if the voltage transition is finished (e.g., compare the value read from the PERF_VSTS register to the VoltStatusI value). If not, control remains at?306?(i.e., in one embodiment, system?10?waits for PERF_VSTS to be equal to VoltStatusI). If, however, the voltage transition is determined at?306?to be finished, control moves to?308.

At?308, a check is made to determine if bus master cache control is needed. If bus master cache control is not needed, control moves to?312.

If, however, bus master cache control is needed, control moves to?310?and system?10?disables the bus master arbiter (e.g., sets PM2_CNT.ARB_DIS). Control then moves to?312.

At?312, a check is made to determine if cache flush/disable cache control is needed. If not, control moves to?318. If, however, cache flush/disable cache control is needed, control moves to?314?and system?10?disables CPU caches and to?316?where system?10?writes-back and invalidates CPU caches. Control then moves to?318.

At?318, system?10?prepares the hardware for the next state transition (e.g., writes a PerfControlI value to the PERF_CNT1 register. Control then moves to?320, where performance transition is initiated (by, e.g., reading the PERF_CNT2 register). Control then moves to?322, where system?10?checks to determine if the performance transition is complete (by, e.g., comparing the value read to a PerfStatusI value). If not, control moves to?318?and system10?once again prepares the hardware for the next state transition (i.e., repeat until PERF_STS is equal to PerfStatusI).

Control then moves to?324. At?324, if bus master cache control is not needed, control moves to?328. Otherwise, control moves to?326, where system10?enables the bus master arbiter (e.g., clears PM2_CNT.ARB_DIS). Control then moves to?328.

At?328, if cache flush/disable cache control is not needed, control moves to?332. Otherwise, control moves to?330, where system?10?enables CPU caches. Control then moves to?332.

At?332, if separate voltage control is not needed (_PVR not present), control moves to?340. Otherwise, control moves to?334, where a determination is made as to whether the transition was to a higher performance state. If so, control moves to?340. If not, however, control moves to?336?and system?10initiates a voltage transition (e.g., writes the VoltControlI value to PERF_VCNT register). Control then moves to?338?where system?10?checks voltage status (read PERF_VSTS register) and compares the value read to a VoltStatusI value. Control remains at?338?until the transition is finished. Control then moves to?340.