Table 1 lists the processor drivers that are included in Windows 7.
Table 1. Windows 7 Processor Driver Support
CPU vendor
|
Supported processor model/family
|
Driver name
|
AMD
|
Opteron
Turion 64
Athlon 64
Sempron
Mobile Sempron
|
Amdk8.sys
|
AMD
|
Phenom
|
Amdppm.sys
|
Intel
|
Pentium 4
Mobile Pentium 4 processor that
supports Hyper-Threading Technology
Pentium M
Core family
Celeron family
Pentium family
Atom family
Xeon family
|
Intelppm.sys
|
VIA
|
C7-M processor
|
Viac7.sys
|
-
|
Any processor not listed above
|
Processr.sys
|
The Generic Processor Driver
Microsoft provides a generic processor driver, Processr.sys, that can be used on any Windows 7–compatible system or processor type, with the following requirements:
The ACPI 2.0 _PSS and _PCT processor objects must be present in the ACPI namespace.
The _PCT Performance Control object must describe the PERF_CTRL and PERF_STATUS control and status registers in system I/O space.
Optionally, the Microsoft-defined Extended PSS (XPSS) object can be used with the generic processor driver to enable the use of ACPI Functional Fixed Hardware (FFH) controls for the PERF_CTRL and PERF_STATUS registers. For more information about implementing XPSS, refer to the “Microsoft Extended PSS ACPI Method Specification” on the WHDC Web site.
Note: The processor drivers that provided native PPM support for AMD K7 family processors and Transmeta Crusoe family processors in earlier versions of Windows have been removed from Windows 7.
Implementing Processor Power Management for Windows 7
Windows 7 includes expanded support for the processor objects that are defined in the ACPI 2.0 and ACPI 3.0 specifications. Several of the processor objects are required for Windows 7 to support processor performance states, whereas other processor objects are optional and can be leveraged at the discretion of the system firmware engineer.
Table 0 lists the ACPI processor objects and indicates which of these objects are supported by the various versions of Windows.
Table 2. Windows ACPI Processor Object Support
Defined by
|
ACPI object
|
_____Windows Version____
Windows Windows Windows
XP1 Vista2 73
|
Comments
|
ACPI 1.0
|
FADT P_LVLx_LAT, P_LVL2, P_LVL3, P_CNT, P_BLK,
DUTY_OFFSET, DUTY_WIDTH
|
|
|
|
|
P_LVL2_UP
|
X
|
X
|
X
|
|
FADT PSTATE_CNT, CSTATE_CNT
|
|
|
|
|
ACPI 2.0
|
_PSS
|
|
|
|
Required for processor performance state control
|
_PCT
|
|
|
|
Required for processor performance state control
|
_PPC, Notify(CPU, 0X80)
|
|
|
|
Required for processor performance state control
|
_CST, Notify(CPU, 0X81)
|
|
|
|
Optional
|
_PTC
|
X
|
|
|
Optional
|
_PDC
|
|
|
|
Optional; _PDC use is vendor-specific (superseded by _OSC)
|
ACPI 3.0
|
_OSC
|
X
|
|
|
Optional; _OSC use is vendor-specific
|
_TSS
|
X
|
|
|
Optional
|
_TPC, Notify(CPU, 0X82)
|
X
|
|
|
Optional
|
_PSD
|
X
|
|
|
Optional
|
_TSD
|
X
|
|
|
Optional
|
_CSD
|
X
|
|
|
Optional
|
Microsoft
|
XPSS
|
X
|
|
|
Optional support that is used only by the generic processor driver
|
PCC
|
X
|
X
|
|
Windows Server 2008 R2 only
|
Legend:
= Supported
X = Not Supported
1 The ACPI support indicated in this column applies to both Windows XP and Windows Server 2003.
2 The ACPI support indicated in this column applies to both Windows Vista and Windows Server 2008.
3 The ACPI support indicated in this column applies to both Windows 7 and Windows Server 2008 R2.
Operating System Validation of ACPI Processor Objects
To increase platform reliability and to help OEMs and firmware developers discover and resolve problems, Windows performs validation checks on the ACPI processor objects that are defined in the system firmware during processor driver initialization. If errors, incorrect or ambiguous information, or other problems are detected, Windows disables the relevant PPM control. In this situation, the kernel power manager logs an error in the system event log that describes which processor control (performance states, idle states, or throttle states) were disabled.
Additionally, the results of this validation are made available through the PowerCfg utility when the /ENERGY parameter is specified. For more information about how to use the PowerCfg utility for energy efficiency analysis, see “Using PowerCfg to Evaluate System Energy Efficiency” on the WHDC Web site.
Declaring Processors
For each processor in the system, the ACPI namespace should declare a named processor object by using the Processor operator. Processor objects may appear anywhere under the \_SB scope or may appear under the \_PR scope to maintain compatibility with ACPI 1.0 operating systems. Processor objects must be in the \_SB or \_PR scope, but not in both.
The processor’s object list may optionally include any of the ACPI processor objects in Table 0, which appears earlier in this paper. The processor objects that are required to support PPM in Windows are described in the remainder of this paper.
Implementing BIOS Support for Processor Performance States
This section discusses the ACPI processor objects that are required to support ACPI processor performance states (P‑states). Systems that do not support processor performance states should not include these ACPI objects in the ACPI namespace.
Required Performance State ACPI Objects
Processor P‑states must be declared in the BIOS by using the ACPI 2.0 performance state objects in the processor’s object list.
The following ACPI objects are required to support processor performance states:
Optional Performance State ACPI Objects
The following ACPI objects are optional for Windows 7 and Windows Server 2008 R2 to support processor performance states:
Notify(CPU, 0x08)
_OSC, _PDC
_PSD
XPSS
Note: For more information about the Microsoft-defined XPSS method and the generic processor driver interface, see “The Generic Processor Driver” earlier in this paper and ”Microsoft Extended PSS ACPI Method Specification” on the WHDC Web site.
System firmware may optionally describe platform control dependencies for processor performance, throttle, or idle states by using the dependency objects that were introduced for this purpose in ACPI 3.0. If present, each dependency object must describe no more than one coordination domain. If the platform supports processor performance states and describes a domain dependency by using _PSD, the kernel power manager uses the P‑state domain dependency relationship information to control processor linear throttle states.
Artificial Processor Performance State Domains
When Windows Vista and Windows Server 2008 were developed, several dual-core and dual-logical processor designs were prevalent in the marketplace. These CPUs typically provide one set of performance state controls that are shared across both cores or both logical processors, which implies that a control dependency exists. However, the system firmware for systems that have these CPUs targets earlier operating systems or otherwise predates the release of Windows Vista and therefore generally does not provide the ACPI 3.0 dependency objects. To support these popular processors without first requiring a platform BIOS update, Windows 7 creates an “artificial” processor performance state dependency domain for the operating system to use. Windows synthesizes a dependency domain for all logical processors in the same physical package. This is the default behavior for Windows 7, and therefore the _PSD object is not required to be present in the ACPI namespace to realize multiprocessor performance states on systems that are equipped with these dual-core processors.
For future systems that might provide two processor cores that share the same physical package but that have independent PPM controls, the default behavior of creating an artificial control dependency domain can be overridden in the following two ways:
Include a _PSD object in the ACPI namespace that describes a separate dependency domain number for each logical processor or for each processor core.
Create a DWORD value that is named PerfEnablePackageIdle under the following registry key and set its value to 1:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Throttle
Implementing BIOS Support for Processor Idle States
This section discusses the ACPI processor objects that are required to support ACPI processor idle states (C‑states). Systems that do not support processor idle states should not include these ACPI objects in the ACPI namespace.
Processor C‑states can be declared in the BIOS by using either of the following ACPI processor idle state control interfaces:
The ACPI 2.0 _CST object in the processor’s object list.
The legacy ACPI 1.0 interface that uses the Processor Register Block (P_BLK) P_LVL2 and P_LVL3 registers and FADT P_LVLx_LAT values.
C‑state Enumeration
The processor driver first looks for support for ACPI 2.0 C‑states in the system firmware, as indicated by the presence of the _CST and _CSD objects in the ACPI namespace. If the system does not support ACPI 2.0 C‑states, the driver looks for support for ACPI 1.0 C‑states.
ACPI 2.0 C‑state Initialization
During initialization, the processor driver looks for and evaluates the _CST and _CSD ACPI objects. If the processor driver finds these objects, it performs validation checks to ensure that these objects are correctly populated and compatible with Windows C‑state support. The following validation checks are performed:
The _CSD object must report that the system supports hardware coordination of C‑states (CoordType = 0xFE, HW_ALL). If any other value is reported for CoordType, all C‑states other than C1 are disabled on the system.
The C-states that are listed in the _CST object must be ordered with increasing values for:
C‑state type (C1, C2, and so on)
Latency
Power
All C‑state control register addresses must be located in I/O space.
All entries must have valid addresses for the required ACPI BIOS interfaces:
The C2 state must have a valid address for the PM1a control block.
The C3 state must have valid addresses for the:
PM2 control block
PM1a control block
PM1a event block
ACPI 1.0 C‑state Initialization
If support for ACPI 2.0 C‑states is not present in the system firmware, the processor driver attempts to initialize ACPI 1.0 C‑states. The following validation checks are performed:
C1 is enabled on all systems by default.
The P_LVL2_LAT value that is reported in the FADT must be below 100 µs.
There must be a valid address for the PM1a control block.
There must be a valid P_BLK address.
The system must be a uniprocessor system. C2 is not supported on multiprocessor systems by default, unless the processor driver explicitly enables this based on known capabilities of the system.
The P_LVL3_LAT value that is reported in the FADT must be below 1000 µs.
There must be a valid address for the PM2 control block.
There must be a valid address for the PM1a control block.
There must be a valid address for the PM1a event block.
There must be a valid P_BLK address.
The system must be a uniprocessor system. C3 is not supported on multiprocessor systems by default, unless the processor driver explicitly enables this based on known capabilities of the system.
Implementing BIOS Support for Processor Clock Throttling
This section discusses the ACPI processor objects that are required to support ACPI processor linear stop clock throttle states (T‑states). Systems that do not support processor T‑states should not include these ACPI objects in the ACPI namespace.
Processor T‑states can be declared in the BIOS by using either of the following ACPI processor throttling control interfaces:
The ACPI 2.0 and 3.0 _PTC, _TSS, and _TPC objects in the processor’s object list.
The legacy ACPI 1.0 interface that uses the Processor Register Block (P_BLK) P_CNT register.
T‑state Enumeration
The processor driver first looks for support for ACPI 3.0 T‑states in the system firmware, as indicated by the presence of the _PTC, _TSS, and _TPC objects in the ACPI namespace. If the system does not support ACPI 3.0 T‑states, the driver looks for support for ACPI 1.0 T‑states.
ACPI 3.0 T‑state Initialization
During initialization, the processor driver looks for and evaluates the _PTC, _TSS, and _TSD ACPI objects. If the processor driver finds these objects, it performs validation checks to ensure that these objects are correctly populated and compatible with Windows T‑state support. The following validation checks are performed:
The _PTC must use either I/O mapped or FFH controls.
The _TSS entries must be ordered in descending order of T-state and power.
The first _TSS entry must be 100 percent (no throttle).
The _TSD object, if present, must describe only one coordination domain.
The _TSD object must contain no more than five fields.
The _TSD coordination type must be one of the three coordination types that are defined by ACPI 3.0.
The _TSD domain must contain at least one member, and the member count must not be greater than the total number of processors that are declared in the ACPI namespace.
ACPI 1.0 T‑state Initialization
If support for ACPI 3.0 T‑states is not present in the system firmware, the processor driver attempts to initialize ACPI 1.0 T‑states. The following validation checks are performed:
T-states on multiprocessor systems
The system must be a uniprocessor system. ACPI 1.0 T-states are not supported on multiprocessor systems, unless the processor driver for the system’s specific processor explicitly supports and enables the multiprocessor T‑state capability that is based on known capabilities of the system.
Processor Register Block address
The Processor Register Block (P_BLK) address must be located in I/O space.
The FADT DUTY_WIDTH value must be >0 and ≤4.
The sum of the FADT DUTY_OFFSET and DUTY_WIDTH values must be ≤32.
|
