ACPI Operation Overview

The way ACPI works is that the firmware creates a hierarchical set of objects that define system capabilities and methods to control system hardware. The APCI objects are then passed to the operating system in a well defined handshake during OS boot. The OS loads the ACPI objects into its kernel and then uses the information along with OS level system drivers to define and execute dynamic hardware configuration, thermal management control policies, and power management control policies.

Before OS boot, the firmware places a series of pointers and table arrays in memory for the OS to locate. During boot the OS searches for a signature indicating presence of a root system description pointer (RSDP). The pointer is found either by scanning predefined memory space for the signature, "RSD PTR" or through and Extensible Firmware Interface (EFI) protocol. In the case of an EFI-compliant system, the RSDP is detected through the presence of a unique GUID in the EFI System Table, which specifies the location of the RSDP.

Root System Description Pointer (RSDP)

The RSDP contains a 32-bit pointer to the Root System Description Table (RSDT) and/or a 64-bit pointer to the Extended System Description Table (XSDT). The RSDT and the XSDT hold equivalent data, one for 32-bit systems and the other for 64-bit systems respectively. In this way a single firmware image can support both 32- and 64-bit operating systems.

Root System Description Table (RSDT)

The RSDT/XSDT tables point to platform-specific table headers, which in turn contain platform-specific ACPI objects. The ACPI firmware table structure is illustrated in Figure 5. One such table is the Fixed ACPI Description Table (FADT) which contains the Firmware ACPI Control Structure (FACS) and pointer to the Differentiated System Description Table (DSDT).

Figure 5: ACPI firmware table structure (Source: Intel Corporation, 2009)

Differentiated System Description Table (DSDT)

The DSDT contains information for base support of the platform including objects, data, and methods that define the platform hardware and how to work with it including power state transitions. The DSDT is unique and always loaded in the OS kernel and once loaded cannot be unloaded during the runtime cycle of the system. Secondary System Description Tables (SSDTs) can be included to augment the DSDT or differentiate between platform SKUs. The SSDTs cannot replace the DSDT or override its functionality.

The ACPI Name Space

Using the table data, the OS creates what is known as the "ACPI namespace", which becomes part of the runtime kernel. The ACPI namespace is a hierarchical tree structure of named objects and data used to manage dynamic hardware configuration and to create and execute power and thermal management policies.

The information in the ACPI namespace comes from the DSDT, which contains the Differentiated Definition Block, and one or more other definition blocks. A definition block contains information about the hardware in the form of data and control methods encoded in ACPI Machine Language (AML). A control method is a definition of how the OS can perform hardware related tasks. The firmware author writes control methods using ACPI Source Language (ASL) which is then compiled to AML using an Intel ASL compiler.

ASL Programming Language

ACPI Source Language (ASL) is a language for defining ACPI objects especially for writing ACPI control methods. Firmware developers define objects and write control methods in ASL and then compile them into ACPI Machine Language (AML) using a translator tool commonly known as a compiler. For a complete description of ASL, refer to Chapter 17 of the ACPI Specification revision 3.0b. The following code provides an example of basic ASL code used to define and APCI definition block and some basic control methods.

// ACPI Control Method Source Language (ASL) Example
DefinitionBlock (
	"forbook.aml",		// Output Filename
	"DSDT",			// Signature
	0x02,				// DSDT Compliance Revision
	"OEM",			// OEMID
	"forbook",			// TABLE ID
	0x1000			// OEM Revision
)
{	// start of definition block
	OperationRegion(\GIO, SystemIO, 0x125, 0x1)
	Field(\GIO, ByteAcc, NoLock, Preserve)	{
		CT01, 1,
	}
	Scope(\_SB) {						// start of scope
		Device(PCI0) {					// start of device
			PowerResource(FET0, 0, 0) {		// start of pwr
				Method (_ON) {
					Store (Ones, CT01)	// assert power
					Sleep (30)			// wait 30m
				}
				Method (_OFF) {
					Store (Zero, CT01)	// assert reset#
				}
				Method (_STA) {
					Return (CT01)
				}
			} // end of power
		} // end of device
	} // end of scope
} // end of definition block

CPU Power and Thermal Management

APCI is used to help implement CPU controls for both thermal and power management. Clock throttling for example is commonly used for passive thermal control, meaning without turning on fans. The CPU dissipates less heat when it is actively throttled. Switching CPU power states, known as Cx states, is commonly used to save power when the full performance capabilities of the CPU are not required.

Processor Control Block. CPU control can be done through ACPI standard hardware using the processor control block registers named P_CNT, P_LVL2 and P_LVL3.

Processor Control (P_CNT) - The CLK_VAL field is where the duty setting of the throttling hardware is programmed as described by the DUTY_WIDTH and DUTY_OFFSET values in the FADT. Table 1 lists the processor control register bits.

Table 1: Processor control register bits Source: Advanced Configuration and Power Interface Specification; Revision 3.0b (2006)

Table 2 shows CPU clock throttling information. Writes to the control registers allow for programming the clock throttling duty cycle.

Table 2: FADT processor throttle control information Source: Advanced Configuration and Power Interface Specification; Revision 3.0b (2006)

Processor LVL2 Register (P_LVL2) - The P_PVL2 register is used to transition the CPU into the C2 low power state. Similarly the P_PVL3 register is used to transition the CPU to the C3 low power state and so on. In general, a higher number means more power savings at the expense of conversely longer wake time latency. Table 3 describes the P_LVL2 control for invoking the C2 state.

Table 3: Processor LVL2 register bits Source: Advanced Configuration and Power Interface Specification; Revision 3.0b (2006)

CPU Throttling Control through Software. CPU throttling control can be directed through software using CPU control methods written in ASL and passed to the operating system through the DSDT or SSDT. Primary control methods include the following:

_PTC (Processor Throttling Control) - Defines throttling control and status registers. This is an example usage of the _PTC object in a Processor object list:

Processor (
	\_SB.CPU0, 		// Processor Name
	3, 				// ACPI Processor number
	0x120,			// PBlk system IO address
	6 )				// PBlkLen
{ //Object List

	Name(_PTC, Package () 	// Processor Throttling Control object
	{
		// Throttling_CTRL
		ResourceTemplate(){Register(FFixedHW, 0, 0, 0)},
		// Trottling_STATUS
		ResourceTemplate(){Register(FFixedHW, 0, 0, 0)}
	}) // End of _PTC object
} // End of Object List

_TSS (Throttling Supported States) – Defines a table of throttling states and control/status values. This is an example usage of the _TSS object in a Processor objectlist:

Name (_TSS, Package()
{ 	Field				// Field Name 
	Type
	Package ()
	// Throttle State 0 Definition – T0
	{
		FreqPercentageOfMaximum,	//%CPU core freq in T0 state
		Power,				//Max Power dissipation in mW for T0
		TransitionLatency,		//Worst case transition latency Tx->T0
		Control, 				//Value to be written to CPU Ctrl register
		Status				//Status register value after transition
	},
	.
	.
	.
	Package ()
	// Throttle State n Definition – Tn
	{
		FreqPercentageOfMaximum,	//%CPU core freq in Tn state
		Power,				//Max Power dissipation in mW for Tn
		TransitionLatency,		//Worst case transition latency Tx->Tn
		Control,				//Value to be written to CPU Ctrl register
		Status 				// Status register value after transition
	}
}) // End of _TSS object

_TPC (Throttling Present Capabilities) - Specifies the number of currently available throttling states. Platform notification signals re-evaluation. This is an example usage of the _TPC object in a Processor object list:

Method (_TPC, 0)			// Throttling Present Capabilities method
	{
		If (\_SB.AC)
		{
			Return(0)		// All Throttle States are available for use.
		}
		Else
		{
			Return(2)		// Throttle States 0 and 1 won't be used.
		}
	} // End of _TPC method

Conclusion

Today's embedded systems built on Intel architecture have distinctly different requirements from the standard PC BIOS. For embedded systems requiring power management, an ACPI based model is recommended. ACPI includes well defined limits of firmware functionality that help yield high quality firmware while keeping production costs downs and time to market fast. At the same time ACPI can enable very flexible and efficient power management. It is encouraged that embedded firmware or boot loader developers work closely with embedded OS/RTOS designers to understand and build fully optimized boot loader to OS protocols and interfaces.

This article and more on similar subjects may be found in the Intel Technology Journal, March 2009 Edition, "Advances in Embedded Systems Technology". More information can be found at http://intel.com/technology/itj.