Professional Documents
Culture Documents
Compaq Computer Corporation Intel Corporation Microsoft Corporation Phoenix Technologies Ltd. Toshiba Corporation
ii
Copyright 1996, 1997, 1998, 1999, 2000 Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd., Toshiba Corporation All rights reserved.
INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. COMPAQ, INTEL, MICROSOFT, PHOENIX, AND TOSHIBA DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. COMPAQ, INTEL, MICROSOFT, PHOENIX, AND TOSHIBA DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS.
Microsoft, Win32, Windows, and Windows NT are registered trademarks of Microsoft Corporation. All other product names are trademarks, registered trademarks, or service marks of their respective owners.
iii
Change Description Major specification revision. 64-bit addressing support added. Processor and device performance state support added. Numerous multiprocessor workstation and server-related enhancements. Consistency and readability enhancements throughout. Fixed previous errata that deleted wrong paragraph in the RTC_EN description.
Affected Sections
4.7.3.1.2
Clarified P_BLK requirements on multiprocessor systems. Changed definition of SCI_INT pin in Table 5-5. Replaced section 5.2.8, adding new structures and clarifications to support multiprocessor configurations. Expanded Name Space descriptionclarified the name search rules, added Parent operator to operator list, described name padding. Expanded ASL definitiondefined global objects, clarification that OpRegion accesses may block, added description of the scope and life of variables in control methods. Changed notify values. Added \_PIC method to Table 5-33 and new section 5.8. Added USB _ADR values to Table 6-1. ACPI Control Method added for floppy enumeration (_FDE). ASL Grammar clarificationsinitial and default SyncLevel values, ObjectType behavior for specific objects, usage of the RefOf operator and behavior of nonpackage method evaluation. Added top-level AML definition. Changed concat arguments to be TermArgs resolving to data. Added the _GLK object and referenced it in the Smart Battery and the Control Method Battery sections.
16.2 16.2.4.4 6.5.6 & 11.1.4 & 11.2.2 & 13.8 & 13.9 &13.12 Appendix A 1.7 4.7.2.1 5.2.x 5.2.8
Added Video Extensions as an Appendix. 1.0a Added _PRT requirement for PCI root bridges. Clarification H/W behaviorPM timer may be stopped when not in the G0/S0 state, Lid Switch behavior and correction of the RTC_EN bit in Table 4-10. Clarification of tablestrailing blank required in signature in Table 5-1, FLUSH_SIZE and FLUSH_STRIDE clarification Table 5-5. Clarified placement of APIC-related structures and general clean up, added Interrupt source overrides. Various removals Figure 5-4, DCK_CAP flag from Table 5-6, _SBC and _SBS methods from Table 5-33.
Compaq/Intel/Microsoft/Phoenix/Toshiba
iv
(continued) Revision Change Description Various additionsAC device PnP ID to Table 5-32, _DDN (logical name association) to Table 6-1, _ADR values for floppy, _FDIfloppy configuration info, requirements for _CRS used with bus devices, battery presence bit to _STA definition, QWORD to La rge Resource data type, _INI Method. Wake/Sleep clarifications_PTS not executed for S5 and SCI cannot occur before enabled. Rewrote the IDE Controller Device section. Corrected the passive cooling equation for TC1 and TC2. Removed requirement that PRx contain numeric lowest state. Removed Duplicate Section General-Purpose Register Blocks. Clarified that C1 is required and C2 & C3 are optional and reiterate requirement for C1 processor state in Table 5-6. Clarified the Passive Cooling Equation. Numerous grammar updates and corrections. Added SxD objects. 1.0 Original Release. Affected Sections 5.6.4
9.1 & 9.3 10.8 12.3.7 (&8) 7.2.x (0-2) 4.7.4.3 4.7.2.6 & 5.2.5 12.1.5 15 & 16 7.2 &7.2.x
Contents
1 INTRODUCTION......................................................................................................................................................1 1.1 Principal Goals ...................................................................................................................................................1 1.2 Power Management Rationale .......................................................................................................................2 1.3 Legacy Support...................................................................................................................................................3 1.4 OEM Implementation Strategy......................................................................................................................3 1.5 Power and Sleep Buttons .................................................................................................................................3 1.6 ACPI Specification and the Structure Of ACPI........................................................................................4 1.7 OS and Platform Compliance.........................................................................................................................5 1.7.1 Platform Implementations of ACPI-defined Interfaces ......................................................................... 5 1.7.2 OSPM Implementations.............................................................................................................................. 9 1.7.3 OS Requirements........................................................................................................................................ 10 1.8 Target Audience ...............................................................................................................................................10 1.9 Document Organization .................................................................................................................................10 1.9.1 ACPI Overview .......................................................................................................................................... 11 1.9.2 Programming Models ................................................................................................................................ 11 1.9.3 Implementation Details ............................................................................................................................. 11 1.9.4 Technical Reference .................................................................................................................................. 12 1.10 Related Documents ........................................................................................................................................12 2 DEFINITION OF TERMS ....................................................................................................................................13 2.1 General ACPI Terminology..........................................................................................................................13 2.2 Global System State Definitions ...................................................................................................................19 2.3 Device Power State Definitions.....................................................................................................................21 2.4 Sleeping State Definitions ..............................................................................................................................22 2.5 Processor Power State Definitions...............................................................................................................23 2.6 Device and Processor Performance State Definitions ............................................................................23 3 OVERVIEW ..............................................................................................................................................................24 3.1 System Power Management..........................................................................................................................25 3.2 Power States ......................................................................................................................................................26 3.2.1 New Meanings for the Power Button ..................................................................................................... 27 3.2.2 Platform Power Management Characteristics ....................................................................................... 27 3.3 Device Power Management...........................................................................................................................28 3.3.1 Power Management Standards................................................................................................................. 29 3.3.2 Device Power States .................................................................................................................................. 29 3.3.3 Device Power State Definitions............................................................................................................... 29 3.4 Controlling Device Power ..............................................................................................................................30 3.4.1 Getting Device Power Capabilities ......................................................................................................... 30 3.4.2 Setting Device Power States .................................................................................................................... 30 3.4.3 Getting Device Power Status ................................................................................................................... 31 3.4.4 Waking the Computer ............................................................................................................................... 31 3.4.5 Example: Modem Device Power Management..................................................................................... 32 3.5 Processor Power Management .....................................................................................................................35 3.6 Device and Processor Performance States ................................................................................................35
Compaq/Intel/Microsoft/Phoenix/Toshiba
vi
3.7 Plug and Play.....................................................................................................................................................35 3.7.1 Example: Configuring the Modem.......................................................................................................... 36 3.8 System Events ...................................................................................................................................................36 3.9 Battery Management.......................................................................................................................................37 3.9.1 Battery Communications .......................................................................................................................... 37 3.9.2 Battery Capacity......................................................................................................................................... 38 3.9.3 Battery Gas Gauge ..................................................................................................................................... 38 3.9.4 Low Battery Levels .................................................................................................................................... 39 3.10 Thermal Management ..................................................................................................................................41 3.10.1 Active and Passive Cooling Modes ...................................................................................................... 42 3.10.2 Performance vs. Energy Conservation................................................................................................. 42 3.10.3 Acoustics ................................................................................................................................................... 42 3.10.4 Multiple Thermal Zones ......................................................................................................................... 42 4 ACPI HARDWARE SPECIFICATION............................................................................................................43 4.1 Fixed Hardware Programming Model.......................................................................................................43 4.1.1 Functional Fixed Hardware ...................................................................................................................... 44 4.2 Generic Hardware Programming Model ..................................................................................................45 4.3 Diagram Legends .............................................................................................................................................47 4.4 Register Bit Notation.......................................................................................................................................47 4.5 The ACPI Hardware Model..........................................................................................................................48 4.5.1 Hardware Reserved Bits............................................................................................................................ 51 4.5.2 Hardware Ignored Bits .............................................................................................................................. 52 4.5.3 Hardware Write-Only Bits........................................................................................................................ 52 4.5.4 Cross Device Dependencies ..................................................................................................................... 52 4.6 ACPI Hardware Features ..............................................................................................................................53 4.7 ACPI Register Model ......................................................................................................................................54 4.7.1 ACPI Register Summary........................................................................................................................... 57 4.7.2 Fixed Hardware Features .......................................................................................................................... 59 4.7.3 Fixed Hardware Registers......................................................................................................................... 70 4.7.4 Generic Hardware Registers..................................................................................................................... 77 5 ACPI SOFTWARE PROGRAMMING MODEL ...........................................................................................85 5.1 Overview of the System Description Table Architecture......................................................................85 5.1.1 Address Space Translation....................................................................................................................... 87 5.2 ACPI System Description Tables.................................................................................................................88 5.2.1 Reserved Bits and Fields........................................................................................................................... 88 5.2.2 Compatibility .............................................................................................................................................. 89 5.2.3 Address Format .......................................................................................................................................... 89 5.2.4 Root System Description Pointer (RSDP)............................................................................................. 90 5.2.5 System Description Table Header........................................................................................................... 92 5.2.6 Root System Description Table (RSDT)................................................................................................ 94 5.2.7 Extended System Description Table (XSDT) ....................................................................................... 95 5.2.8 Fixed ACPI Description Table (FADT) ................................................................................................. 96 5.2.9 Firmware ACPI Control Structure (FACS).........................................................................................106 5.2.10 Definition Blocks ...................................................................................................................................109
Compaq/Intel/Microsoft/Phoenix/Toshiba
vii
5.2.11 Global System Interrupts......................................................................................................................119 5.2.12 Smart Battery Table (SBST) ................................................................................................................120 5.2.13 Embedded Controller Boot Resources Table ....................................................................................121 5.3 ACPI NameSpace.......................................................................................................................................... 123 5.3.1 Defined Root Namespaces......................................................................................................................126 5.3.2 Objects .......................................................................................................................................................126 5.4 Definition Block Encoding .......................................................................................................................... 126 5.5 Using the ACPI Control Method Source Language ............................................................................ 128 5.5.1 ASL Statements........................................................................................................................................128 5.5.2 ASL Macros..............................................................................................................................................129 5.5.3 Control Method Execution .....................................................................................................................129 5.5.4 Control Method Arguments, Local Variables, and Return Values..................................................130 5.6 ACPI Event Programming Model............................................................................................................ 130 5.6.1 ACPI Event Programming Model Components..................................................................................131 5.6.2 Types of ACPI Events.............................................................................................................................132 5.6.3 Device Object Notifications...................................................................................................................136 5.6.4 Device Class-Specific Objects...............................................................................................................138 5.6.5 Defined Generic Objects and Control Methods..................................................................................139 5.7 Operating System-Defined Object Names.............................................................................................. 145 5.7.1 \_GL (Global Lock Mutex) ....................................................................................................................145 5.7.2 \_OS (OS Name Object) .........................................................................................................................145 5.7.3 \_REV (Revision Data Object) ..............................................................................................................145 5.8 System Configuration Objects................................................................................................................... 145 5.8.1 _PIC Method.............................................................................................................................................145 6 CONFIGURATION.............................................................................................................................................. 146 6.1 Device Identification Objects ..................................................................................................................... 146 6.1.1 _ADR (Address).......................................................................................................................................146 6.1.2 _CID (Compatible ID) ............................................................................................................................147 6.1.3 _DDN (Device Name).............................................................................................................................148 6.1.4 _HID (Hardware ID) ...............................................................................................................................148 6.1.5 _STR (String)............................................................................................................................................148 6.1.6 _SUN (Slot User Number) .....................................................................................................................148 6.1.7 _UID (Unique ID) ....................................................................................................................................148 6.2 Device Configuration Objects.................................................................................................................... 149 6.2.1 _CRS (Current Resource Settings)........................................................................................................150 6.2.2 _DIS (Disable)..........................................................................................................................................150 6.2.3 _DMA (Direct Memory Access)...........................................................................................................150 6.2.4 _FIX (Fixed Register Resource Provider) ...........................................................................................151 6.2.5 _HPP (Hot Plug Parameters)..................................................................................................................153 6.2.6 _MAT (Multiple APIC Table Entry)....................................................................................................155 6.2.7 _PRS (Possible Resource Settings).......................................................................................................156 6.2.8 _PRT (PCI Routing Table).....................................................................................................................157 6.2.9 _PXM (Proximity) ...................................................................................................................................159 6.2.10 _SRS (Set Resource Settings)..............................................................................................................159
Compaq/Intel/Microsoft/Phoenix/Toshiba
viii
6.3 Device Insertion and Removal Objects ................................................................................................... 159 6.3.1 _EDL (Eject Device List).......................................................................................................................161 6.3.2 _EJD (Ejection Dependent Device)......................................................................................................161 6.3.3 _EJx (Eject)...............................................................................................................................................162 6.3.4 _LCK (Lock).............................................................................................................................................163 6.3.5 _RMV (Remove)......................................................................................................................................163 6.3.6 _STA (Status)...........................................................................................................................................164 6.4 Resource Data Types for ACPI................................................................................................................. 164 6.4.1 ASL Macros for Resource Descriptors.................................................................................................164 6.4.2 Small Resource Data Type .....................................................................................................................164 6.4.3 Large Resource Data Type .....................................................................................................................171 6.5 Other Objects and Control Methods ....................................................................................................... 191 6.5.1 _INI (Init) ..................................................................................................................................................191 6.5.2 _DCK (Dock)............................................................................................................................................192 6.5.3 _BDN (BIOS Dock Name).....................................................................................................................192 6.5.4 _REG (Region).........................................................................................................................................192 6.5.5 _BBN (Base Bus Number) .....................................................................................................................194 6.5.6 _SEG (Segment).......................................................................................................................................195 6.5.7 _GLK (Global Lock) ...............................................................................................................................196 7 POWER AND PERFORMANCE MANAGEMENT.................................................................................. 197 7.1 Declaring a Power Resource Object ........................................................................................................ 197 7.1.1 Defined Child Objects for a Power Resource .....................................................................................198 7.1.2 _OFF...........................................................................................................................................................198 7.1.3 _ON ............................................................................................................................................................199 7.1.4 _STA (Status)...........................................................................................................................................199 7.2 Device Power Management Objects ........................................................................................................ 199 7.2.1 _PS0 (Power State 0)...............................................................................................................................201 7.2.2 _PS1 (Power State 1)...............................................................................................................................201 7.2.3 _PS2 (Power State 2)...............................................................................................................................201 7.2.4 _PS3 (Power State 3)...............................................................................................................................201 7.2.5 _PSC (Power State Current)...................................................................................................................202 7.2.6 _PR0 (Power Resources for D0) ...........................................................................................................202 7.2.7 _PR1 (Power Resources for D1) ...........................................................................................................202 7.2.8 _PR2 (Power Resources for D2) ...........................................................................................................203 7.2.9 _PRW (Power Resources for Wake).....................................................................................................203 7.2.10 _PSW (Power State Wake)..................................................................................................................204 7.2.11 _IRC (In Rush Current) ........................................................................................................................204 7.2.12 _S1D (S1 Device State)........................................................................................................................204 7.2.13 _S2D (S2 Device State)........................................................................................................................204 7.2.14 _S3D (S3 Device State)........................................................................................................................204 7.2.15 _S4D (S4 Device State)........................................................................................................................205 7.3 OEM-Supplied System-Level Control Methods ................................................................................... 205 7.3.1 \_BFS (Back From Sleep).......................................................................................................................205 7.3.2 \_PTS (Prepare To Sleep).......................................................................................................................205
Compaq/Intel/Microsoft/Phoenix/Toshiba
ix
7.3.3 \_GTS (Going To Sleep).........................................................................................................................206 7.3.4 System \_Sx states ....................................................................................................................................206 7.3.5 \_WAK (System Wake) ..........................................................................................................................210 8 PROCESSOR CONTROL.................................................................................................................................. 211 8.1 Processor Power States................................................................................................................................ 211 8.1.1 Processor Power State C0 .......................................................................................................................213 8.1.2 Processor Power State C1 .......................................................................................................................215 8.1.3 Processor Power State C2 .......................................................................................................................215 8.1.4 Processor Power State C3 .......................................................................................................................215 8.1.5 Additional Processor Power States .......................................................................................................216 8.2 Flushing Caches............................................................................................................................................. 216 8.3 Declaring a Processor Object..................................................................................................................... 217 8.3.1 _PTC (Processor Throttling Control) ...................................................................................................217 8.3.2 _CST (C States)........................................................................................................................................218 8.3.3 Processor Performance Control.............................................................................................................220 9 WAKING AND SLEEPING .............................................................................................................................. 225 9.1 Sleeping States ............................................................................................................................................... 226 9.1.1 S1 Sleeping State......................................................................................................................................228 9.1.2 S2 Sleeping State......................................................................................................................................228 9.1.3 S3 Sleeping State......................................................................................................................................229 9.1.4 S4 Sleeping State......................................................................................................................................229 9.1.5 S5 Soft Off State ......................................................................................................................................230 9.1.6 Transitioning from the Working to the Sleeping State......................................................................231 9.1.7 Transitioning from the Working to the Soft Off State.......................................................................231 9.2 Flushing Caches............................................................................................................................................. 232 9.3 Initialization.................................................................................................................................................... 232 9.3.1 Placing the System in ACPI Mode........................................................................................................234 9.3.2 BIOS Initialization of Memory ..............................................................................................................235 9.3.3 OS Loading ...............................................................................................................................................237 9.3.4 Exiting ACPI Mode .................................................................................................................................239 10 ACPI-SPECIFIC DEVICE OBJECTS ......................................................................................................... 240 10.1 \_SI System Indicators............................................................................................................................... 240 10.1.1 _SST (System Status)............................................................................................................................241 10.1.2 _MSG (Message)...................................................................................................................................241 10.2 Battery Device.............................................................................................................................................. 241 10.3 Control Method Lid Device...................................................................................................................... 241 10.3.1 _LID.........................................................................................................................................................241 10.4 Control Method Power and Sleep Button Devices............................................................................. 242 10.5 Embedded Controller Device .................................................................................................................. 242 10.6 Fan Device..................................................................................................................................................... 242 10.7 Generic ISA Bus Device ............................................................................................................................ 242 10.8 IDE Controller Device ............................................................................................................................... 243 10.8.1 _GTF (Get Task File)............................................................................................................................245 10.8.2 _GTM (Get Timing Mode) ..................................................................................................................246
Compaq/Intel/Microsoft/Phoenix/Toshiba
x
10.8.3 _STM (Set Timing Mode)....................................................................................................................247 10.9 Floppy Controller Device Objects .......................................................................................................... 247 10.9.1 _FDE (Floppy Disk Enumerate)..........................................................................................................247 10.9.2 _FDI (Floppy Disk Information).........................................................................................................248 10.9.3 _FDM (Floppy Disk Drive Mode)......................................................................................................249 10.10 GPE Block Device..................................................................................................................................... 249 10.10.1 Matching Control Methods for General-Purpose Events in a GPE Block Device ...................250 10.11 Module Device ........................................................................................................................................... 250 10.12 Memory Devices........................................................................................................................................ 252 10.12.1 Address Decoding................................................................................................................................252 10.12.2 Example: Memory Device .................................................................................................................252 11 POWER SOURCE DEVICES ......................................................................................................................... 253 11.1 Smart Battery Subsystems ....................................................................................................................... 253 11.1.1 ACPI Smart Battery Status Change Notification Requirements....................................................255 11.1.2 Smart Battery Objects ...........................................................................................................................257 11.1.3 Smart Battery Subsystem Control Methods ......................................................................................258 11.2 Control Method Batteries......................................................................................................................... 260 11.2.1 Battery Events ........................................................................................................................................260 11.2.2 Battery Control Methods......................................................................................................................261 11.3 AC Adapters and Power Source Objects ............................................................................................. 265 11.3.1 PSR (Power Source)..............................................................................................................................265 11.3.2 PCL (Power Consumer List)................................................................................................................265 11.4 Example: Power Source Name Space.................................................................................................... 266 12 THERMAL MANAGEMENT ........................................................................................................................ 267 12.1 Thermal Control ......................................................................................................................................... 267 12.1.1 Active, Passive, and Critical Policies .................................................................................................267 12.1.2 Dynamically Changing Cooling Temperatures ................................................................................268 12.1.3 Detecting Temperature Changes .........................................................................................................268 12.1.4 Active Cooling .......................................................................................................................................270 12.1.5 Passive Cooling......................................................................................................................................270 12.1.6 Critical Shutdown ..................................................................................................................................272 12.2 Cooling Preferences.................................................................................................................................... 272 12.2.1 Evaluating Thermal Device Lists........................................................................................................273 12.3 Thermal Objects.......................................................................................................................................... 274 12.3.1 ACx (Active Cooling) ...........................................................................................................................274 12.3.2 ALx (Active List)...................................................................................................................................275 12.3.3 CRT (Critical Temperature).................................................................................................................275 12.3.4 HOT (Hot Temperature).......................................................................................................................275 12.3.5 PSL (Passive List)..................................................................................................................................275 12.3.6 PSV (Passive) .........................................................................................................................................276 12.3.7 SCP (Set Cooling Policy) .....................................................................................................................276 12.3.8 TC1 (Thermal Constant 1) ...................................................................................................................276 12.3.9 TC2 (Thermal Constant 2) ...................................................................................................................276 12.3.10 TMP (Temperature).............................................................................................................................277
Compaq/Intel/Microsoft/Phoenix/Toshiba
xi
12.3.11 TSP (Thermal Sampling Period).......................................................................................................277 12.3.12 TZD (Thermal Zone Devices)...........................................................................................................277 12.3.13 TZP (Thermal Zone Polling) .............................................................................................................277 12.4 Thermal Zone Object Requirements..................................................................................................... 278 12.5 Thermal Zone Examples ........................................................................................................................... 278 12.5.1 Example: The Basic Thermal Zone ....................................................................................................278 12.5.2 Example: Multiple -Speed Fans ...........................................................................................................280 13 ACPI EMBEDDED CONTROLLER INTERFACE SPECIFICATION............................................ 282 13.1 Embedded Controller Interface Description....................................................................................... 282 13.2 Embedded Controller Register Descriptions ...................................................................................... 285 13.2.1 Embedded Controller Status, EC_SC (R)..........................................................................................286 13.2.2 Embedded Controller Command, EC_SC (W).................................................................................287 13.2.3 Embedded Controller Data, EC_DATA (R/W)................................................................................287 13.3 Embedded Controller Command Set.................................................................................................... 287 13.3.1 Read Embedded Controller, RD_EC (0x80) .....................................................................................287 13.3.2 Write Embedded Controller, WR_EC (0x81) ...................................................................................288 13.3.3 Burst Enable Embedded Controller, BE_EC (0x82) .......................................................................288 13.3.4 Burst Disable Embedded Controller, BD_EC (0x83)......................................................................288 13.3.5 Query Embedded Controller, QR_EC (0x84) ...................................................................................289 13.4 SMBus Host Controller Notification Header (Optional), OS_SMB_EVT.................................. 289 13.5 Embedded Controller Firmware ............................................................................................................ 289 13.6 Interrupt Model........................................................................................................................................... 290 13.6.1 Event Interrupt Model...........................................................................................................................290 13.6.2 Command Interrupt Model...................................................................................................................290 13.7 Embedded Controller Interfacing Algorithms ................................................................................... 291 13.8 Embedded Controller Description Information................................................................................. 291 13.9 SMBus Host Controller Interface via Embedded Controller......................................................... 292 13.9.1 Register Description ..............................................................................................................................292 13.9.2 Protocol Description ..............................................................................................................................296 13.9.3 SMBus Register Set...............................................................................................................................300 13.10 SMBus Devices .......................................................................................................................................... 301 13.10.1 SMBus Device Access Restrictions.................................................................................................302 13.10.2 SMBus Device Command Access Restriction................................................................................302 13.11 Defining an Embedded Controller Device in ACPI Namespace.................................................. 302 13.11.1 Example: EC Definition ASL Code .................................................................................................303 13.12 Defining an EC SMBus Host Controller in ACPI Namespace..................................................... 303 13.12.1 Example: EC SMBus Host Controller ASL-Code.........................................................................304 14 ACPI SYSTEM MANAGEMENT BUS INTERFACE SPECIFICATION........................................ 305 14.1 SMBus Overview......................................................................................................................................... 305 14.1.1 SMBus Slave Addresses .......................................................................................................................305 14.1.2 SMBus Protocols....................................................................................................................................305 14.1.3 SMBus Status Codes .............................................................................................................................306 14.1.4 SMBus Command Values ....................................................................................................................306 14.2 Declaring SMBus Host Controller Objects ......................................................................................... 307
Compaq/Intel/Microsoft/Phoenix/Toshiba
xii
14.3 Declaring SMBus Devices ......................................................................................................................... 307 14.4 Declaring SMBus Operation Regions ................................................................................................... 308 14.5 Declaring SMBus Fields ............................................................................................................................ 309 14.6 Declaring an SMBus Data Buffer........................................................................................................... 310 14.7 Using the SMBus Protocols ...................................................................................................................... 311 14.7.1 Read/Write Quick (SMBQuick) ..........................................................................................................311 14.7.2 Send/Receive Byte (SMBSendReceive)............................................................................................312 14.7.3 Read/Write Byte (SMBByte)...............................................................................................................313 14.7.4 Read/Write Word (SMBWord) ...........................................................................................................313 14.7.5 Read/Write Block (SMBBlock) ..........................................................................................................314 14.7.6 Process Call (SMBProcessCall) ..........................................................................................................314 14.7.7 Block Write-Read Block Process Call (SMBBlockProcessCall) ..................................................315 15 SYSTEM ADDRESS MAP INTERFACES ................................................................................................. 316 15.1 INT 15H, E820H - Query System Address Map................................................................................ 316 15.2 E820 Assumptions and Limitations ....................................................................................................... 318 15.3 EFI GetMemoryMap() Boot Services Function ................................................................................. 318 15.4 EFI Assumptions and Limitations ......................................................................................................... 320 15.5 Example Address Map.............................................................................................................................. 320 15.6 Example: Operating System Usage........................................................................................................ 321 16 ACPI SOURCE LANGUAGE (ASL) REFERENCE................................................................................ 322 16.1 ASL Language Grammar ......................................................................................................................... 322 16.1.1 ASL Grammar Notation........................................................................................................................322 16.1.2 ASL Names .............................................................................................................................................324 16.1.3 ASL Language and Terms ....................................................................................................................324 16.2 Full ASL Reference .................................................................................................................................... 341 16.2.1 ASL Names .............................................................................................................................................341 16.2.2 ASL Data Types.....................................................................................................................................342 16.2.3 ASL Terms ..............................................................................................................................................346 16.2.4 ASL Macros for Resource Descriptors ..............................................................................................390 17 ACPI MACHINE LANGUAGE (AML) SPECIFICATION .................................................................. 397 17.1 Notation Conventions ................................................................................................................................ 397 17.2 AML Grammar Definition ....................................................................................................................... 398 17.2.1 Name Objects Encoding .......................................................................................................................399 17.2.2 Data Objects Encoding..........................................................................................................................400 17.2.3 Package Length Encoding....................................................................................................................400 17.2.4 Term Objects Encoding ........................................................................................................................401 17.2.5 Miscellaneous Objects Encoding........................................................................................................407 17.3 AML Byte Stream Byte Values ............................................................................................................... 407 17.4 AML Encoding of Names in the Namespace ....................................................................................... 414 A DEVICE CLASS PM SPECIFICATIONS ................................................................................................. 416 A.1 Overview....................................................................................................................................................... 416 A.2 Device Power States................................................................................................................................... 416 A.2.1 Bus Power Management......................................................................................................................417 A.2.2 Display Power Management ...............................................................................................................417
Compaq/Intel/Microsoft/Phoenix/Toshiba
xiii
A.2.3 PCMCIA/PCCARD/CardBus Power Management ........................................................................417 A.2.4 PCI Power Management......................................................................................................................417 A.2.5 USB Power Management ....................................................................................................................418 A.2.6 Device Classes.......................................................................................................................................418 A.3 Default Device Class.................................................................................................................................. 418 A.3.1 Default Power State Definitions.........................................................................................................418 A.3.2 Default Power Management Policy ...................................................................................................419 A.3.3 Default Wake Events............................................................................................................................419 A.3.4 Minimum Power Capabilities .............................................................................................................419 A.4 Audio Device Class.................................................................................................................................... 419 A.4.1 Power State Definitions.......................................................................................................................419 A.4.2 Power Management Policy..................................................................................................................420 A.4.3 Wake Events ..........................................................................................................................................420 A.4.4 Minimum Power Capabilities .............................................................................................................420 A.5 COM Port Device Class ........................................................................................................................... 421 A.5.1 Power State Definitions.......................................................................................................................421 A.5.2 Power Management Policy..................................................................................................................421 A.5.3 Wake Events ..........................................................................................................................................421 A.5.4 Minimum Power Capabilities .............................................................................................................422 A.6 Display Device Class.................................................................................................................................. 422 A.6.1 Power State Definitions.......................................................................................................................422 A.6.2 Power Management Policy..................................................................................................................423 A.6.3 Wake Events ..........................................................................................................................................424 A.6.4 Minimum Power Capabilities .............................................................................................................424 A.7 Input Device Class..................................................................................................................................... 424 A.7.1 Power State Definitions.......................................................................................................................424 A.7.2 Power Management Policy..................................................................................................................425 A.7.3 Wake Events ..........................................................................................................................................425 A.7.4 Minimum Power Capabilities .............................................................................................................425 A.8 Mode m Device Class ................................................................................................................................. 426 A.8.1 Technology Overview..........................................................................................................................426 A.8.2 Power State Definitions.......................................................................................................................427 A.8.3 Power Management Policy..................................................................................................................427 A.8.4 Wake Events ..........................................................................................................................................427 A.8.5 Minimum Power Capabilities .............................................................................................................428 A.9 Network Device Class............................................................................................................................... 428 A.9.1 Power State Definitions.......................................................................................................................428 A.9.2 Power Management Policy..................................................................................................................429 A.9.3 Wake Events ..........................................................................................................................................429 A.9.4 Minimum Power Capabilities .............................................................................................................429 A.10 PC Card Controller Device Class........................................................................................................ 429 A.10.1 Power State Definitions.....................................................................................................................430 A.10.2 Power Management Policy ...............................................................................................................431 A.10.3 Wake Events........................................................................................................................................431
Compaq/Intel/Microsoft/Phoenix/Toshiba
xiv
A.10.4 Minimum Power Capabilities ...........................................................................................................431 A.11 Storage Device Class............................................................................................................................... 431 A.11.1 Power State Definitions.....................................................................................................................432 A.11.2 Power Management Policy ...............................................................................................................433 A.11.3 Wake Events........................................................................................................................................434 A.11.4 Minimum Power Capabilities ...........................................................................................................434 B ACPI EXTENSIONS FOR DISPLAY ADAPTERS ................................................................................. 435 B.1 Introduction................................................................................................................................................. 435 B.2 Definitions .................................................................................................................................................... 436 B.3 ACPI Namespace........................................................................................................................................ 436 B.4 Display-specific Methods ......................................................................................................................... 437 B.4.1 _DOS (Enable/Disable Output Switching) .......................................................................................437 B.4.2 _DOD (Enumerate All Devices Attached to the Display Adapter)..............................................438 B.4.3 _ROM (Get ROM Data) ......................................................................................................................439 B.4.4 _GPD (Get POST Device)...................................................................................................................440 B.4.5 _SPD (Set POST Device) ....................................................................................................................440 B.4.6 _VPO (Video POST Options).............................................................................................................441 B.5 Output Device-specific Methods ............................................................................................................ 441 B.5.1 _ADR (Return the Unique ID for this Device)................................................................................441 B.5.2 _BCL (Query List of Brightness Control Levels Supported)........................................................441 B.5.3 _BCM (Set the Brightness Level) ......................................................................................................442 B.5.4 _DDC (Return the EDID for this Device)........................................................................................442 B.5.5 _DCS (Return the Status of Output Device) ....................................................................................443 B.5.6 _DGS (Query Graphics State).............................................................................................................443 B.5.7 _DSS Device Set State......................................................................................................................444 B.6 Note on State Changes .............................................................................................................................. 445 INDEX ......................................................................................................................................................................... 446
Compaq/Intel/Microsoft/Phoenix/Toshiba
Introduction 1
1 Introduction
The Advanced Configuration and Power Interface (ACPI) specification was developed to establish industry common interfaces enabling robust operating system (OS)-directed motherboard device configuration and power management of both devices and entire systems. ACPI is the key element in Operating Systemdirected configuration and Power Management (OSPM). ACPI evolves the existing collection of power management BIOS code, Advanced Power Management (APM) application programming interfaces (APIs, PNPBIOS APIs, Multiprocessor Specification (MPS) tables and so on into a well-defined power management and configuration interface specification. ACPI provides the means for an orderly transition from existing (legacy) hardware to ACPI hardware, and it allows for both ACPI and legacy mechanisms to exist in a single machine and to be used as needed. Further, new system architectures are being built that stretch the limits of current Plug and Play interfaces. ACPI evolves the existing motherboard configuration interfaces to support these advanced architectures in a more robust, and potentially more efficient manner. The interfaces and OSPM concepts defined within this specification are suitable to all classes of computers including (but not limited to) desktop, mobile, workstation, and server machines. From a power management perspective, OSPM/ACPI promotes the concept that systems should conserve energy by transitioning unused devices into lower power states including placing the entire system in a low-power state (sleeping state) when possible. This document describes ACPI hardware interfaces, ACPI software interfaces and ACPI data structures that, when implemented, enable support for robust OS-directed configuration and power management (OSPM).
Compaq/Intel/Microsoft/Phoenix/Toshiba
2 Advanced Configuration and Power Interface Specification 3. Facilitate and accelerate industry-wide implementation of power management. OSPM and ACPI will reduce the amount of redundant investment in power management throughout the industry, as this investment and function will be gathered into the OS. This will allow industry participants to focus their efforts and investments on innovation rather than simple parity. The OS can evolve independently of the hardware, allowing all ACPI-compatible machines to gain the benefits of OS improvements and innovations. Create a robust interface for configuring motherboard devices. Enable new advanced designs not possible with existing interfaces.
4.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Introduction 3
The existing structure of the PC platform constrains OS and hardware designs. Because ACPI is abstract, the OS can evolve separately from the hardware and, likewise, the hardware from the OS. ACPI is by nature more portable across operating systems and processors. ACPI control methods allow for very flexible implementations of particular features.
ACPI-only hardware
Compaq/Intel/Microsoft/Phoenix/Toshiba
Applications
OS Dependent Application APIs OSPM System Code OS Specific technologies, interfaces, and code.
Kernel
Device Driver
Existing industry standard register interfaces to: CMOS, PIC, PITs, ...
ACPI Registers
ACPI BIOS
ACPI Tables
Platform Hardware
- ACPI Spec Covers this area. - OS specific technology, not part of ACPI. - Hardware/Platform specific technology, not part of ACPI.
Figure 1-1 OSPM/ACPI Global System Compaq/Intel/Microsoft/Phoenix/Toshiba
BIOS
Introduction 5
There are three run-time components to ACPI: ACPI System Description Tables. Describe the interfaces to the hardware. Some descriptions limit what can be built (for example, some controls are embedded in fixed blocks of registers and the table specifies the address of the register block). Most descriptions allow the hardware to be built in arbitrary ways and can describe arbitrary operation sequences needed to make the hardware function. ACPI Tables containing Definition Blocks can make use of a pseudocode type of language, the interpretation of which is performed by the OS. That is, OSPM contains and uses an interpreter that executes procedures encoded in the pseudocode language and stored in the ACPI tables containing Definition Blocks. The pseudocode language, known as ACPI Machine Language (AML), is a compact, tokenized, abstract type of machine language. ACPI Registers. The constrained part of the hardware interface, described (at least in location) by the ACPI System Description Tables. ACPI System Firmware. Refers to the portion of the firmware that is compatible with the ACPI specifications. Typically, this is the code that boots the machine (as legacy BIOSs have done) and implements interfaces for sleep, wake, and some restart operations. It is called rarely, compared to a legacy BIOS. The ACPI Description Tables are also provided by the ACPI System Firmware.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Introduction 7
ACPI-defined Generic Register Interfaces and object definitions in the ACPI Namespace (Section 4.2, Section 5.6.5): General-purpose event processing Motherboard device identification, configuration, and insertion/removal (Section 6) Thermal zones (Section 12) Power resource control (Section 7.1) Device power state control (Section 7.2) System power state control (Section 7.3) System indicators (Section 10.1) Devices and device controls (Section 10): Processor (Section 8) Control Method Battery (Section 11) Smart Battery Subsystem (Section 11) Mobile Lid Power or sleep button with S5 override (also possible in fixed space) Embedded controller (Section 13) Fan Generic Bus Bridge IDE Controller Floppy Controller GPE Block Module Memory Global Lock related interfaces ACPI Event programming model (Section 5.6) ACPI-defined System BIOS Responsibilities (Section 9) ACPI-defined State Definitions (Section 2): Global system power states (G-states, S0, S5) System sleeping states (S-states S1-S4) (Section 9) Device power states (D-states (Appendix B)) Processor power states (C-states) (Section 8) Device and processor performance states (P-states) (Section 3, Section 8)
Compaq/Intel/Microsoft/Phoenix/Toshiba
8 Advanced Configuration and Power Interface Specification Processor power state control (for C1) Global Lock control/status (if Global Lock interfaces are required by the system) ACPI-defined Generic Register Interfaces and object definitions in the ACPI Namespace: General-purpose event processing Motherboard device identification, configuration, and insertion/removal (ACPI 2.0 Section 6) System power state control (ACPI 2.0 Section 7.3) Devices and device controls: Processor Control Method Battery (or Smart Battery Subsystem on a mobile system) Smart Battery Subsystem (or Control Method Battery on a mobile system) Power or sleep button with S5 override (may also be implemented in fixed register space) Global Lock related interfaces when a logical register in the hardware is shared between OS and firmware environments ACPI Event programming model (ACPI 2.0 Section 5.6) ACPI-defined System BIOS Responsibilities (ACPI 2.0 Section 9) ACPI-defined State Definitions: System sleeping states (At least one system sleeping state, S1-S4, must be implemented) Device power states (D-states must be implemented in accordance with device class specifications) Processor power states (All processors must support the C1 Power State) The following provides an example of how a design guide for systems that execute multiple OS instances, whose goal is to require robust configuration and continuous availability for the system class, could use the recommended terminology to define ACPI related requirements. Important: This example is provided as a guideline for how ACPI terminology can be used. It should not be interpreted as a statement of ACPI requirements. Platforms compliant with this platform design guide must implement the following ACPI 2.0 defined system features and interfaces, along with their associated event models: System address map reporting interfaces ACPI System Description Tables provided in the system firmware ACPI-defined Fixed Registers Interfaces: Power management timer control/status General-purpose event control/status SCI /SMI routing control/status for Power Management and General-purpose events (control required only if system supports legacy mode) System power state controls (sleeping/wake control) Processor power state control (for C1) Global Lock control/status (if Global Lock interfaces are required by the system) ACPI-defined Generic Register Interfaces and object definitions in the ACPI Namespace: General-purpose event processing Motherboard device identification, configuration, and insertion/removal (ACPI 2.0 Section 6) System power state control (ACPI 2.0 Section 7.3) System indicators Devices and device controls: Processor Global Lock related interfaces when a logical register in the hardware is shared between OS and firmware environments ACPI Event programming model (ACPI 2.0 Section 5.6) ACPI-defined System BIOS Responsibilities (ACPI 2.0 Section 9) ACPI-defined State Definitions: Processor power states (All processors must support the C1 Power State) Compaq/Intel/Microsoft/Phoenix/Toshiba
Introduction 9
Compaq/Intel/Microsoft/Phoenix/Toshiba
1.7.3 OS Requirements
The following list describes the minimum requirements for an OSPM/ACPI-compatible OS: Use system address map reporting interfaces to get the system address map on Intel Architecture (IA) platforms: INT 15H, E820H - Query System Address Map interface (see section 15, System Address Map Interfaces) EFI GetMemoryMap() Boot Services Function (see section 15, System Address Map Interfaces) Find and consume the ACPI System Description Tables (see section 5, ACPI Software Programming Model). Implementation of an AML interpreter supporting all defined AML grammar elements (see section 17, ACPI Machine Language Specification). Support for the ACPI Event programming model including handling SCI interrupts, managing fixed events, general-purpose events, embedded controller interrupts, and dynamic device support. Enumerate and configure motherboard devices described in the ACPI Namespace. Implement support for the following ACPI devices defined within this specification: Embedded Controller Device (see section 13, ACPI Embedded Controller Interface Specification) GPE Block Device (see section 10.10, GPE Block Device) Module Device (see section 10.11, Module Device) Implementation of the ACPI thermal model (see section 12, Thermal Management). Support acquisition and release of the Global Lock. OS-directed power management support (device drivers are responsible for maintaining device context as described by the Device Power Management Class Specifications described in Appendix A).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Introduction 11
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Definition of Terms 13
2 Definition of Terms
This specification uses a particular set of terminology, defined in this section. This section has three parts: General ACPI terms are defined and presented alphabetically. The ACPI global system states (working, sleeping, soft off, and mechanical off) are defined. Global system states apply to the entire system, and are visible to the user. The ACPI device power states are defined. Device power states are states of particular devices; as such, they are generally not visible to the user. For example, some devices may be in the off state even though the system as a whole is in the working state. Device states apply to any device on any bus.
Compaq/Intel/Microsoft/Phoenix/Toshiba
14 Advanced Configuration and Power Interface Specification Control Method A control method is a definition of how the OS can perform a simple hardware task. For example, the OS invokes control methods to read the temperature of a thermal zone. Control methods are written in an encoded language called AML that can be interpreted and executed by the ACPI-compatible OS. An ACPI-compatible system must provide a minimal set of control methods in the ACPI tables. The OS provides a set of well-defined control methods that ACPI table developers can reference in their control methods. OEMs can support different revisions of chip sets with one BIOS by either including control methods in the BIOS that test configurations and respond as needed or including a different set of control methods for each chip set revision. Central Processing Unit (CPU) or processor The part of a platform that executes the instructions that do the work. An ACPI-compatible OS can balance processor performance against power consumption and thermal states by manipulating the processor performance controls. The ACPI specification defines a working state, labeled G0 (S0), in which the processor executes instructions. Processor sleeping states, labeled C1 through C3, are also defined. In the sleeping states, the processor executes no instructions, thus reducing power consumption and, potentially, operating temperatures. For more information, see section 8, Processor Control. Definition Block A definition block contains information about hardware implementation and configuration details in the form of data and control methods, encoded in AML. An OEM can provide one or more definition blocks in the ACPI Tables. One definition block must be provided: the Differentiated Definition Block, which describes the base system. Upon loading the Differentiated Definition Block, the OS inserts the contents of the Differentiated Definition Block into the ACPI Namespace. Other definition blocks, which the OS can dynamically insert and remove from the active ACPI Namespace, can contain references to the Differentiated Definition Block. For more information, see section 5.2.10, Device Power States. Device Hardware component outside the core chip set of a platform. Examples of devices are liquid crystal display (LCD) panels, video adapters, Intergrated Drive Electronics (IDE) CD-ROM and hard disk controllers, COM ports, and so on. In the ACPI scheme of power management, buses are devices. For more information, see section 3.3.2, Device Power States. Device Context The variable data held by the device; it is usually volatile. The device might forget this information when entering or leaving certain states (for more information, see section 2.3, Device Power State Definitions.), in which case the OS software is responsible for saving and restoring the information. Device Context refers to small amounts of information held in device peripherals. See System Context. Differentiated System Description Table (DSDT) An OEM must supply a DSDT to an ACPI-compatible OS. The DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system. The OS always inserts the DSDT information into the ACPI Namespace at system boot time and never removes it. Extensible Firmware Interface (EFI) An interface between the OS and the platform firmware, which is required on IA-64 platforms. The interface is in the form of data tables that contain platform related information, and boot and run-time service calls that are available to the OS and loader. Together, these provide a standard environment for booting an OS.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Definition of Terms 15
Embedded Controller The general class of microcontrollers used to support OEM-specific implementations, mainly in mobile environments. The ACPI specification supports embedded controllers in any platform design, as long as the microcontroller conforms to one of the models described in this section. The embedded controller performs complex low-level functions through a simple interface to the host microprocessor(s). Embedded Controller Interface A standard hardware and software communications interface between an OS driver and an embedded controller. This allows any OS to provide a standard driver that can directly communicate with an embedded controller in the system, thus allowing other drivers within the system to communicate with and use the resources of system embedded controllers (for example, Smart Battery and AML code). This in turn enables the OEM to provide platform features that the OS and applications can use. Firmware ACPI Control Structure (FACS) A structure in read/write memory that the BIOS uses for handshaking between the firmware and the OS. FACS is passed to an ACPI-compatible OS via the Fixed ACPI Description Table (FADT). The FACS contains the systems hardware signature at last boot, the firmware waking vector, and the Global Lock. Fixed ACPI Description Table (FADT) A table that contains the ACPI Hardware Register Block implementation and configuration details the OS needs to direct management of the ACPI Hardware Register Blocks, as well as the physical address of the DSDT that contains other platform implementation and configuration details. An OEM must provide an FADT to an ACPI-compatible OS in the RSDT/XSDT. The OS always inserts the namespace information defined in the Differentiated Definition Block in the DSDT into the ACPI Namespace at system boot time, and the OS never removes it. Fixed Features A set of features offered by an ACPI interface. The ACPI specification places restrictions on where and how the hardware programming model is generated. All fixed features, if used, are implemented as described in this specification so that OSPM can directly access the fixed feature registers. Fixed Feature Events A set of events that occur at the ACPI interface when a paired set of status and event bits in the fixed feature registers are set at the same time. When a fixed feature event occurs, a system control interrupt (SCI is raised. For ACPI fixed feature events, OSPM (or an ACPI-aware driver) acts as the event handler. Fixed Feature Registers A set of hardware registers in fixed feature register space at specific address locations in system I/O address space. ACPI defines register blocks for fixed features (each register block gets a separate pointer from the FADT). For more information, see section 4.6, ACPI Hardware Features. General-Purpose Event Registers The general-purpose event registers contain the event programming model for generic features. All generic events generate SCIs. Generic Feature A generic feature of a platform is value-added hardware implemented through control methods and general-purpose events.
Compaq/Intel/Microsoft/Phoenix/Toshiba
16 Advanced Configuration and Power Interface Specification Global System States Global system states apply to the entire system, and are visible to the user. The various global system states are labeled G0 through G3 in the ACPI specification. For more information, see section 2.2, Global System State Definitions. Ignored Bits Some unused bits in ACPI hardware registers are designated as ignored in the ACPI specification. Ignored bits are undefined and can return zero or one (in contrast to reserved bits, which always return zero). Software ignores ignored bits in ACPI hardware registers on reads and preserves ignored bits on writes. Intel Architecture-Personal Computer (IA-PC) A general descriptive term for computers built with processors conforming to the architecture defined by the Intel processor family based on the Intel Architecture instruction set and having an industrystandard PC architecture. I/O APIC An Input/Output Advanced Programmable Interrupt Controller routes interrupts from devices to the processors local APIC. I/O SAPIC An Input/Output Streamlined Advanced Programmable Interrupt Controller routes interrupts from devices to the processors local APIC. Legacy A computer state where power management policy decisions are made by the platform hardware/firmware shipped with the system. The legacy power management features found in todays systems are used to support power management in a system that uses a legacy OS that does not support the OS-directed power management architecture. Legacy Hardware A computer system that has no ACPI or OSPM power management support. Legacy OS An OS that is not aware of and does not direct the power management functions of the system. Included in this category are operating systems with APM 1.x support. Local APIC A local Advanced Programmable Interrupt Controller receives interrupts from the I/O APIC. Local SAPIC A local Streamlined Advanced Programmable Interrupt Controller receives interrupts from the I/O SAPIC. Multiple APIC Description Table (MADT) The Multiple APIC Description Table (MADT) is used on systems supporting the APIC and SAPIC to describe the APIC implementation. Following the MADT is a list of APIC/SAPIC structures that declare the APIC/SAPIC features of the machine. Object The nodes of the ACPI Namespace are objects inserted in the tree by the OS using the information in the system definition tables. These objects can be data objects, package objects, control method objects, and so on. Package objects refer to other objects. Objects also have type, size, and relative name. Object name Part of the ACPI Namespace. There is a set of rules for naming objects.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Definition of Terms 17
Operating System-directed Power Management (OSPM) A model of power (and system) management in which the OS plays a central role and uses global information to optimize system behavior for the task at hand. Package A set of objects. Power Button A user push button or other switch contact device that switches the system from the sleeping/soft off state to the working state, and signals the OS to transition to a sleeping/soft off state from the working state. Power Management Mechanisms in software and hardware to minimize system power consumption, manage system thermal limits, and maximize system battery life. Power management involves trade-offs among system speed, noise, battery life, processing speed, and alternating current (AC) power consumption. Power management is required for some system functions, such as appliance (for example, answering machine, furnace control) operations. Power Resources Resources (for example, power planes and clock sources) that a device requires to operate in a given power state. Power Sources The battery (including a UPS battery) and AC line powered adapters or power supplies that supply power to a platform. Register Grouping Consists of two register blocks (it has two pointers to two different blocks of registers). The fixedposition bits within a register grouping can be split between the two register blocks. This allows the bits within a register grouping to be split between two chips. Reserved Bits Some unused bits in ACPI hardware registers are designated as Reserved in the ACPI specification. For future extensibility, hardware -register reserved bits always return zero, and data writes to them have no side effects. OSPM implementations must write zeros to all reserved bits in enable and status registers and preserve bits in control registers. Root System Description Pointer (RSDP) An ACPI-compatible system must provide an RSDP in the systems low address space. This structures only purpose is to provide the physical address of the RSDT. Root System Description Table (RSDT) A table with the signature RSDT, followed by an array of physical pointers to other system description tables. The OS locates that RSDT by following the pointer in the RSDP structure. Secondary System Description Table (SSDT) SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables. Note: Additional tables can only add data; they cannot overwrite data from previous tables. Sleep Button A user push button that switches the system from the sleeping/soft off state to the working state, and signals the OS to transition to a sleeping state from the working state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
18 Advanced Configuration and Power Interface Specification Smart Battery Subsystem A battery subsystem that conforms to the following specifications: Smart Battery and either Smart Battery System Manager or Smart Battery Charger and Selectorand the additional ACPI requirements. Smart Battery Table An ACPI table used on platforms that have a Smart Battery subsystem. This table indicates the energylevel trip points that the platform requires for placing the system into different sleeping states and suggested energy levels for warning the user to transition the platform into a sleeping state. System Management Bus (SMBus) A two-wire interface based upon the IC protocol. The SMBus is a low-speed bus that provides positive addressing for devices, as well as bus arbitration. SMBus Interface A standard hardware and software communications interface between an OS bus driver and an SMBus controller. Streamlined Advanced Programmable Interrupt Controller (SAPIC) An advanced APIC commo nly found on Intel Architecture-based 64-bit systems. System Context The volatile data in the system that is not saved by a device driver. System Control Interrupt (SCI) A system interrupt used by hardware to notify the OS of ACPI events. The SCI is an active, low, shareable, level interrupt. System Management Interrupt (SMI) An OS-transparent interrupt generated by interrupt events on legacy systems. By contrast, on ACPI systems, interrupt events generate an OS-visible interrupt that is shareable (edge-style interrupts will not work). Hardware platforms that want to support both legacy operating systems and ACPI systems must support a way of re -mapping the interrupt events between SMIs and SCIs when switching between ACPI and legacy models. Thermal States Thermal states represent different operating environment temperatures within thermal zones of a system. A system can have one or more thermal zones; each thermal zone is the volume of space around a particular temperature-sensing device. The transitions from one thermal state to another are marked by trip points, which are implemented to generate an SCI when the temperature in a thermal zone moves above or below the trip point temperature. Extended Root System Description Table (XSDT) The XSDT provides identical functionality to the RSDT but accommodates physical addresses of DESCRIPTION HEADERs that are larger than 32-bits. Notice that both the XSDT and the RSDT can be pointed to by the RSDP structure.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Definition of Terms 19
Compaq/Intel/Microsoft/Phoenix/Toshiba
20 Advanced Configuration and Power Interface Specification S4 Non-Volatile Sleep A special global system state that allows system context to be saved and restored (relatively slowly) when power is lost to the motherboard. If the system has been commanded to enter S4, the OS will write all system context to a file on non-volatile storage media and leave appropriate context markers. The machine will then enter the S4 state. When the system leaves the Soft Off or Mechanical Off state, transitioning to Working (G0) and restarting the OS, a restore from a NVS file can occur. This will only happen if a valid non-volatile sleep data set is found, certain aspects of the configuration of the machine have not changed, and the user has not manually aborted the restore. If all these conditions are met, as part of the OS restarting, it will reload the system context and activate it. The net effect for the user is what looks like a resume from a Sleeping (G1) state (albeit slower). The aspects of the machine configuration that must not change include, but are not limited to, disk layout and memory size. It might be possible for the user to swap a PC Card or a Device Bay device, however. Notice that for the machine to transition directly from the Soft Off or Sleeping states to S4, the system context must be written to non-volatile storage by the hardware; entering the Working state first so that the OS or BIOS can save the system context takes too long from the users point of view. The transition from Mechanical Off to S4 is likely to be done when the user is not there to see it. Because the S4 state relies only on non-volatile storage, a machine can save its system context for an arbitrary period of time (on the order of many years). Table 2-1 Summary of Global Power States Power consumption Large Smaller OS restart required No No Safe to disassemble computer No No Exit state electronically Yes Yes
No No
Yes Yes
No Yes
Yes No
Compaq/Intel/Microsoft/Phoenix/Toshiba
Definition of Terms 21
Notice that the entries for G2/S5 and G3 in the Latency column of the above table are Long. This implies that a platform designed to give the user the appearance of instant-on, similar to a home appliance device, will use the G0 and G1 states almost exclusively (the G3 state may be used for moving the machine or repairing it).
Compaq/Intel/Microsoft/Phoenix/Toshiba
22 Advanced Configuration and Power Interface Specification Table 2-2 Summary of Device Power States Device State D0 - FullyOn D1 D2 D3 - Off Power Consumption As needed for operation D0>D1>D2>D3 D0>D1>D2>D3 0 Device Context Retained All >D2 <D1 None Driver Restoration None <D2 >D1 Full initialization and load
Note: Devices often have different power modes within a given state. Devices can use these modes as long as they can automatically transparently switch between these modes from the software, without violating the rules for the current Dx state the device is in. Low-power modes that adversely affect performance (in other words, low speed modes) or that are not transparent to software cannot be done automatically in hardware; the device driver must issue commands to use these modes.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Definition of Terms 23
Compaq/Intel/Microsoft/Phoenix/Toshiba
3 Overview
ACPI provides OSPM with direct and exclusive control over the power management and motherboard device configuration functions of a computer. When it starts, OSPM takes over these functions from legacy BIOS interfaces such as the APM BIOS and the PNPBIOS. Having done this, OSPM is responsible for handling motherboard device configuration events as well as controlling the power, performance, and thermal status of the system based on user preference and application requests. ACPI provides low-level interfaces that allow OSPM to perform these functions. The functional areas covered by the ACPI specification are: System power management. ACPI defines mechanisms for putting the computer as a whole in and out of system sleeping states. It also provides a general mechanism for any device to wake the computer. Device power management. ACPI tables describe motherboard devices, their power states, the power planes the devices are connected to, and controls for putting devices into different power states. This enables the OS to put devices into low-power states based on application usage. Processor power management. While the OS is idle but not sleeping, it will use commands described by ACPI to put processors in low-power states. Device and processor performance management. While the system is active, OSPM will transition devices and processors into different performance states, defined by ACPI, to achieve a desirable balance between performance and energy conservation goals as well as other environmental requirements (for example, visibility and acoustics). Plug and Play. ACPI specifies information used to enumerate and configure motherboard devices. This information is arranged hierarchically so when events such as docking and undocking take place, the OS has precise, a priori knowledge of which devices are affected by the event. System Events. ACPI provides a general event mechanism that can be used for system events such as thermal events, power management events, docking, device insertion and removal, and so on. This mechanism is very flexible in that it does not define specifically how events are routed to the core logic chip set. Battery management. Battery management policy moves from the APM BIOS to the ACPI OS. An ACPI-compatible battery device needs either a Smart Battery subsystem interface, which is controlled by the OS directly through the embedded controller interface, or a Control Method Battery interface. A Control Method Battery interface is completely defined by AML control methods, allowing an OEM to choose any type of the battery and any kind of communication interface supported by ACPI. The battery must comply with the requirements of its interface, as described either herein or in other applicable standards. The OS may choose to alter the behavior of the battery, for example, by adjusting the Low Battery or Battery Warning trip point. When there are multiple batteries present, the battery subsystem is not required to perform any synthesis of a composite battery from the data of the separate batteries. In cases where the battery subsystem does not synthesize a composite battery from the separate batterys data, the OS must provide that synthesis. Thermal management. Since the OS controls the power states of devices and processors, ACPI also addresses system thermal management. It provides a simple, scaleable model that allows OEMs to define thermal zones, thermal indicators, and methods for cooling thermal zones.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 25
Embedded Controller. ACPI defines a standard hardware and software communications interface between an OS bus enumerator and an embedded controller. This allows any OS to provide a standard bus enumerator that can directly communicate with an embedded controller in the system, thus allowing other drivers within the system to communicate with and use the resources of system embedded controllers. This in turn enables the OEM to provide platform features that the OS and applications can use. SMBus Controller. ACPI defines a standard hardware and software communications interface between an OS bus driver and an SMBus Controller. This allows any OS to provide a standard bus driver that can directly communicate with SMBus devices in the system. This in turn enables the OEM to provide platform features that the OS and applications can use.
Once in ACPI mode, system firmware or other software must not manipulate the platforms configuration, power, performance, and thermal control interfaces (if implemented) independently of OSPM. OSPM alone is responsible for coordinating the configuration, power management, performance management, and thermal control policy of the system. Manipulation of these interfaces independently of OSPM undermines the purpose of OSPM/ACPI and may adversely impact the systems configuration, power, performance, and thermal policy goals. However, in the case of the possibility of damage to system from excessive thermal conditions where OSPM latency is insufficient to remedy an adverse thermal condition, the platform may exercise a failsafe thermal control mechanism that reduces the performance of a system component to avoid damage. In this case, the platform should notify OSPM of the performance reduction if the reduction is of significant duration (in other words, if the duration of reduced performance could adversely impact OSPMs power or performance control policy).
Compaq/Intel/Microsoft/Phoenix/Toshiba
G3 -Mech Off
BIOS Routine
Legacy
G0 (S0) Working
Wake Event
S4 S3 S2 S1
G1 Sleeping
Performance State Px
Throttling
C0 C1
C2 CPU Cn
Figure 3-1 Global System Power States and Transitions See section 2.2, Global System State Definitions, for detailed definitions of these states. In general use, computers alternate between the Working and Sleeping states. In the Working state, the computer is used to doing work. User-mode application threads are dispatched and running. Individual devices can be in low-power (Dx) states and processors can be in low-power (Cx) states if they are not being used. Any device the system turns off because it is not actively in use can be turned on with short latency. (What short means depends on the device. An LCD display needs to come on in sub-second times, while it is generally acceptable to wait a few seconds for a printer to wake.) The net effect of this is that the entire machine is functional in the Working state. Various Working substates differ in speed of computation, power used, heat produced, and noise produced. Tuning within the Working state is largely about trade-offs among speed, power, heat, and noise.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 27
When the computer is idle or the user has pressed the power button, the OS will put the computer into one of the sleeping (Sx) states. No user-visible computation occurs in a sleeping state. The sleeping sub-states differ in what events can arouse the system to a Working state, and how long this takes. When the machine must awaken to all possible events or do so very quickly, it can enter only the sub-states that achieve a partial reduction of system power consumption. However, if the only event of interest is a user pushing on a switch and a latency of minutes is allowed, the OS could save all system context into an NVS file and transition the hardware into the S4 sleeping state. In this state, the machine draws almost zero power and retains system context for an arbitrary period of time (years or decades if needed). The other states are used less often. Computers that support legacy BIOS power management interfaces boot in the Legacy state and transition to the Working state when an ACPI OS loads. A system without legacy support (for example, a RISC system) transitions directly from the Mechanical Off state to the Working state. Users typically put computers into the Mechanical Off state by flipping the computers mechanical switch or by unplugging the computer.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 29
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 31
When a device is to be set in a particular power state using the ACPI interface, the OS first decides which power resources will be used and which can be turned off. The OS tracks all the devices on a given power resource. When all the devices on a resource have been turned off, the OS turns off that power resource by running a control method. If a power resource is turned off and one of the devices on that resource needs to be turned on, the OS first turns on the power resource using a control method and then signals the device to turn on. The time that the OS must wait for the power resource to stabilize after turning it on or off is described in the description table. The OS uses the time base provided by the Power Management Timer to measure these time intervals. Once the power resources have been switched, the OS executes the appropriate control method to put the device in that power state. Notice that this might not mean that power is removed from the device. If other active devices are sharing a power resource, the power resources will remain on.
Some OS policies may require the OS to put the machine into a global system state for which the device can no longer wake the system. Such as when a system has very low battery power.
Compaq/Intel/Microsoft/Phoenix/Toshiba
32 Advanced Configuration and Power Interface Specification When the computer is in the Sleeping state and a wake device decides to wake the machine, it signals to the ACPI chip set. The SCI status bit corresponding to the device waking the machine is set, and the ACPI chip set resumes the machine. After the OS is running again, it clears the bit and handles the event that caused the wake. The control method for this event then uses the Notify command to tell the OS which device caused the wake.
The wake policy for the modem is very simple: When the phone rings and wake is enabled, wake the machine.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 33
Based on that policy, the modem and the COM port to which it is attached can be implemented in hardware as shown in Figure 3-2. This is just an example for illustrating features of ACPI. This example is not intended to describe how OEMs should build hardware.
PWR1
Switched power
PWR2
Switched power
I/O I/O COM port (UART) I/O Modem controller Control RI Phone interface
Phone line
WAKE
Figure 3-2 Example Modem and COM Port Hardware Note: Although not shown above, each discrete part has some isolation logic so that the part is isolated when power is removed from it. Isolation logic controls are implemented as power resources in the ACPI Differentiated Description Block so that devices are isolated as power planes are sequenced off.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 35
Compaq/Intel/Microsoft/Phoenix/Toshiba
36 Advanced Configuration and Power Interface Specification ACPI is used only to enumerate and configure motherboard devices that do not have other hardware standards for enumeration and configuration. For example, PCI devices on the motherboard must not be enumerated by ACPI; therefore Plug and Play information for these devices is not included in the Differentiated Description Table. However, power management information for these devices can still appear in the table if the devices power management is to be controlled through ACPI. Note: When preparing to boot a computer, the BIOS only needs to configure boot devices. This includes boot devices described in the ACPI system description tables as well as devices that are controlled through other standards.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 37
Since the event model registers are generalized, they can describe many different platform implementations. The single pin model above is just one example. Another design might have Plug and Play, Thermal, and Power Management events wired to three different pins so there would be three status bits (and three enable bits). Yet another design might have every individual event wired to its own pin and status bit. This design, at the opposite extreme from the single pin design, allows very complex hardware, yet very simple control methods. Countless variations in wiring up events are possible.
Compaq/Intel/Microsoft/Phoenix/Toshiba
OEM designed initial capacity for warning OEM designed initial capacity for low
Battery Remaining Capacity [mAh/mWh] Remaining Battery Percentage[%] = Last Full Charged Capacity [mAh/mWh]
* 100
Control Method Battery also reports the Present Drain Rate [mA or mW] for calculating the remaining battery life. At the most basic level, Remaining Battery life is calculated by following formula:
Remaining Battery Life [h]= Battery Remaining Capacity [mAh/mWh] Battery Present Rate [mA/mW]
Smart Batteries also report the present rate of drain, but since they can directly report the estimated runtime, this function should be used instead as it can more accurately account for variations specific to the battery.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 39
Full
Warning
OEM-designed initial capacity for warning (minimum) OSPM-selected low battery capacity OEM-designed initial capacity for low (minimum) OEM-defined Battery Critical flag
Low Critical
Figure 3-4 Low Battery and Warning Each Control Method Battery in a system reports the OEM-designed initial warning capacity and OEM designed initial low capacity as well as a flag to report when that battery has reached or is below its critical energy level. Unlike Control Method Batteries, Smart Batteries are not necessarily specific to one particular machine type, so the OEM-designed warning, low, and critical levels are reported separately in a Smart Battery Table described in section 5.2.12.
Compaq/Intel/Microsoft/Phoenix/Toshiba
40 Advanced Configuration and Power Interface Specification Table 3-1 described how these values should be set by the OEM and interpreted by the OS. Table 3-1 Low Battery Levels Level Warning Description When the total available energy (mWh) or capacity (mAh) in the batteries falls below this level, the OS will notify the user through the UI. This value should allow for a few minutes of run-time before the Low level is encountered so the user has time to wrap up any important work, change the battery, or find a power outlet to plug the system in. This value is an estimation of the amount of energy or battery capacity required by the system to transition to any supported sleeping state. When the OS detects that the total available battery capacity is less than this value, it will transition the system to a user defined system state (S1-S5). In most situations this should be S4 so that system state is not lost if the battery eventually becomes completely empty. The design of the OS should consider that users of a multiple battery system may remove one or more of the batteries in an attempt replace or charge it. This might result in the remaining capacity falling below the Low level not leaving sufficient battery capacity for the OS to safely transition the system into the sleeping state. Therefore, if the batteries are discharging simultaneously, the action might need to be initiated at the point when both batteries reach this level. The Critical battery state indicates that all available batteries are discharged and do not appear to be able to supply power to run the system any longer. When this occurs, the OS must attempt to perform an emergency shutdown as described below. For a smart battery system, this would typically occur when all batteries reach a capacity of 0, but an OEM may choose to put a larger value in the Smart Battery Table to provide an extra margin of safely. For a Control Method Battery system with multiple batteries, the flag is reported per battery. If any battery in the system is in a critically low state and is still providing power to the system (in other words, the battery is discharging), the system is considered to be in a critical energy state. The _BST control method is required to return the Critical flag on a discharging battery only when all batteries have reached a critical state; the ACPI BIOS is otherwise required to switch to a non-critical battery.
Low
Critical
Compaq/Intel/Microsoft/Phoenix/Toshiba
Overview 41
D R A M
NVRAM
L A N
M P E G
PCI/PCI Bridge
LCD
Graphics
CRT USB Port 1
Docking
Momentary
Embedded Controller
HDD 1 DPR0
F1: BM IDE
EPROM
FDD
DPR1 COM LPT
Figure 3-5 Thermal Zone The following sections are an overview of the thermal control and cooling characteristics of a computer. For some thermal implementation examples on an ACPI platform, see section 12.4, Thermal Zone Object Requirements.
Compaq/Intel/Microsoft/Phoenix/Toshiba
3.10.3 Acoustics
Active cooling mode generally implies that fans will be used to cool the system and fans vary in their audible output. Fan noise can be quite undesirable given the loudness of the fan and the ambient noise environment. In this case, the end users physical requirement for fan silence may override the preference for either performance or energy conservation. A users desire for fan silence corresponds to the Passive cooling mode. Accordingly, a users desire for fan silence also means a preference for energy conservation. For more information on thermal management and examples of platform settings for active and passive cooling, see section 12, Thermal Management.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Rds AML
Compaq/Intel/Microsoft/Phoenix/Toshiba
46 Advanced Configuration and Power Interface Specification As an example of a generic hardware control feature, a platform might be designed such that the IDE HDDs D3 state has value-added hardware to remove power from the drive. The IDE drive would then have a reference to the AML PowerResource object (which controls the value added power plane) in its namespace, and associated with that object would be control methods that OSPM invokes to control the D3 state of the drive: _PS0. A control method to sequence the IDE drive to the D0 state. _PS3. A control method to sequence the IDE drive to the D3 state. _PSC. A control method that returns the status of the IDE drive (on or off). The control methods under this object provide an abstraction layer between OSPM and the hardware. OSPM understands how to control power planes (turn them on or off or to get their status) through its defined PowerResource object, while the hardware has platform-specific AML code (contained in the appropriate control methods) to perform the desired function. In this example, the platform would describe its hardware to the ACPI OS by writing and placing the AML code to turn the hardware off within the _PS3 control method. This enables the following sequence: When OSPM decides to place the IDE drive in the D3 state, it calls the IDE driver and tells it to place the drive into the D3 state (at which point the driver saves the devices context). When the IDE driver returns control, OSPM places the drive in the D3 state. OSPM finds the object associated with the HDD and then finds within that object any AML code associated with the D3 state. OSPM executes the appropriate _PS3 control method to control the value-added generic hardware to place the HDD into an even lower power state. As an example of a generic event feature, a platform might have a docking capability. In this case, it will want to generate an event. Notice that all ACPI events generate an SCI, which can be mapped to any shareable system interrupt. In the case of docking, the event is generated when a docking has been detected or when the user requests to undock the system. This enables the following sequence: OSPM responds to the SCI and calls the AML code event handler associated with that generic event. The ACPI table associates the hardware event with the AML code event handler. The AML-code event handler collects the appropriate information and then executes an AML Notify command to indicate to OSPM that a particular bus needs re-enumeration. The following sections describe the fixed and generic hardware feature set of ACPI. These sections enable a reader to understand the following: Which hardware registers are required or optional when an ACPI feature, concept or interface is required by a design guide for a platform class How to design fixed hardware features How to design generic hardware features The ACPI Event Model
Compaq/Intel/Microsoft/Phoenix/Toshiba
Query value
The half round symbol with an inverted V represents a write-only control bit. This bit has the behavior that it generates its control function when it is set. Reads to write-only bits are treated as ignore by software (the bit position is masked off and ignored). The round symbol with an X represents a programming bit. As an enable or control bit, software setting or clearing this bit will result in the bit being read as set or clear (unless otherwise noted). As a status bit it directly represents the value of the signal. The square symbol represents a sticky status bit. A sticky status bit is set by the level (not edge) of a hardware signal (active high or active low). The bit is only cleared by software writing a 1 to its bit position. The rectangular symbol represents a query value from the embedded controller. This is the value the embedded controller returns to the system software upon a query command in response to an SCI event. The query value is associated with the event control method that is scheduled to execute upon an embedded controller event.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
The G1 sleeping state is represented by five possible sleeping states that the hardware can support. Each sleeping state has different power and wake latency characteristics. The sleeping state differs from the working state in that the users operating environment is frozen in a low-power state until awakened by an enabled wake event. No work is performed in this state, that is, the processors are not executing instructions. Each system sleeping state has requirements about who is responsible for system context and wake sequences (for more information, see section 9, Waking and Sleeping). The G2 soft off state is an OS initiated system shutdown. This state is initiated similar to the sleeping state transition (SLP_TYPx is set to the S5 value and setting the SLP_EN bit initiates the sequence). Exiting the G2 soft-off state requires rebooting the system. In this case, an ACPI-only machine will re-enter the G0 state directly (hardware returns the SCI_EN bit set), while an ACPI/Legacy machine transitions to the Legacy state (SCI_EN bit is clear).
Power Failure Modem HDD CDROM D3 D3 D3 D2 D2 D2 D1 D1 D1 D0 D0 D0
ACPI Boot (SCI_EN=1)
G3 -Mech Off
C0
BIOS Routine
Legacy
ACPI_DISABLE (SCI_EN=0)
G0 (S0) Working
S4 S3 S2 S1
Wake Event ACPI Boot (SCI_EN=1) SLP_TYPx=S5 and SLP_EN or PWRBTN_OR Performance State Px
G1 Sleeping
Throttling
C0 C1 C2 CPU Cn
Figure 4-2 Global States and Their Transitions The ACPI architecture defines mechanisms for hardware to generate events and control logic to implement this behavior model. Events are used to notify OSPM that some action is needed, and control logic is used by OSPM to cause some state transition. ACPI-defined events are hardware or interrupt events. A hardware event is one that causes the hardware to unconditionally perform some operation. For example, any wake event will sequence the system from a sleeping state (S1, S2, S3, and S4 in the global G1 state) to the G0 working state (see Figure 9-1). An interrupt event causes the execution of an event handler (AML code or an ACPI-aware driver), which allows the software to ma ke a policy decision based on the event. For ACPI fixed-feature events, OSPM or an ACPI-aware driver acts as the event handler. For generic logic events OSPM will schedule the execution of an OEM-supplied AML control method associated with the event.
Compaq/Intel/Microsoft/Phoenix/Toshiba
50 Advanced Configuration and Power Interface Specification For legacy systems, an event normally generates an OS-transparent interrupt, such as a System Management Interrupt, or SMI. For ACPI systems the interrupt events need to generate an OS-visible interrupt that is shareable; edge-style interrupts will not work. Hardware platforms that want to support both legacy operating systems and ACPI systems support a way of re -mapping the interrupt events between SMIs and SCIs when switching between ACPI and legacy models. This is illustrated in the following block diagram.
Legacy Only Event Logic Device Idle Timers Device Traps GLBL STBY Timer PWRBTN LID THRM DOCK STS_CHG RI RTC PM Timer User Interface Thermal Logic Hardware Events ACPI/Legacy Event Logic ACPI Only Event Logic ACPI/Legacy Generic Control Features ACPI/Legacy Fixed Control Features
SCI_EN
SMI Arbiter
SMI#
0 Dec 1
SCI#
Figure 4-3 Example Event Structure for a Legacy/ACPI Compatible Event Model This example logic illustrates the event model for a sample platform that supports both legacy and ACPI event models. This example platform supports a number of external events that are power-related (power button, LID open/close, thermal, ring indicate) or Plug and Play-related (dock, status change). The logic represents the three different types of events: OS Transparent Events . These events represent OEM-specific functions that have no OS support and use software that can be operated in an OS-transparent fashion (that is, SMIs). Interrupt Events . These events represent features supported by ACPI-compatible operating systems, but are not supported by legacy operating systems. When a legacy OS is loaded, these events are mapped to the transparent interrupt (SMI# in this example), and when in ACPI mode they are mapped to an OS-visible shareable interrupt (SCI#). This logic is represented by routing the event logic through the decoder that routes the events to the SMI# arbiter when the SCI_EN bit is cleared, or to the SCI# arbiter when the SCI_EN bit is set. Hardware events . These events are used to trigger the hardware to initiate some hardware sequence such as waking, resetting, or putting the machine to sleep unconditionally. In this example, the legacy power management event logic is used to determine device/system activity or idleness based on device idle timers, device traps, and the global standby timer. Legacy power management models use the idle timers to determine when a device should be placed in a low-power state because it is idlethat is, the device has not been accessed for the programmed amount of time. The device traps are used to indicate when a device in a low-power state is being accessed by OSPM. The global standby timer is used to determine when the system should be allowed to go into a sleeping state because it is idlethat is, the user interface has not been used for the programmed amount of time.
Compaq/Intel/Microsoft/Phoenix/Toshiba
These legacy idle timers, trap monitors, and global standby timer are not used by OSPM in the ACPI mode. This work is now handled by different software structures in an ACPI-compatible OS. For example, the driver model of an ACPI-compatible OS is responsible for placing its device into a low-power state (D1, D2, or D3) and transitioning it back to the On state (D0) when needed. And OSPM is responsible for determining when the system is idle by profiling the system (using the PM Timer) and other knowledge it gains through its operating structure environment (which will vary from OS to OS). When the system is placed into the ACPI mode, these events no longer generate SMIs, as drivers now handle this function. These events are disabled through some OEM-proprietary method. On the other hand, many of the hardware events are shared between the ACPI and legacy models (docking, the power button, and so on) and this type of interrupt event changes to an SCI event when enabled for ACPI. The ACPI OS will generate a request to the platforms hardware (BIOS) to enter into the ACPI mode. The BIOS sets the SCI_EN bit to indicate that the system has successfully entered into the ACPI mode, so this is a convenient mechanism to map the desired interrupt (SMI or SCI) for these events (as shown in Figure 4-3). The ACPI architecture specifies some dedicated hardware not found in the legacy hardware model: the power management timer (PM Timer). This is a free running timer that the ACPI OS uses to profile system activity. The frequency of this timer is explicitly defined in this specification and must be implemented as described. Although the ACPI architecture reuses most legacy hardware as is, it does place restrictions on where and how the programming model is generated. If used, all fixed hardware features are implemented as described in this specification so that OSPM can directly access the fixed hardware feature registers. Generic hardware features are manipulated by ACPI control methods residing in the ACPI Namespace. These interfaces can be very flexible; however, their use is limited by the defined ACPI control methods (for more information, see section 10, ACPI-Specific Device Objects). Generic hardware usually controls power planes, buffer isolation, and device reset resources. Additionally, child interrupt status bits can be accessed via generic hardware interfaces; however, they have a parent interrupt status bit in the GP_STS register. ACPI defines five address spaces where generic hardware may exist. These include: System I/O space System memory space PCI configuration space Embedded controller space System Management Bus (SMBus) space Generic hardware power management features can be implemented using spare I/O ports residing in any of these I/O spaces. The ACPI specification defines an optional embedded controller and SMBus interfaces needed to communicate with these associated I/O spaces.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Sleep Button
RTC wakeup alarm is required, the fixed hardware feature status bit is optional.
Compaq/Intel/Microsoft/Phoenix/Toshiba
54 Advanced Configuration and Power Interface Specification Table 4-1 Feature/Programming Model Summary (continued) Feature Name Embedded Controller Interface Description ACPI Embedded Controller protocol and interface, as described in section 13, ACPI Embedded Controller Interface Specification. Status bit that indicates the system is using the legacy or ACPI power management model (SCI_EN). Button used to indicate whether the systems lid is open or closed (mobile systems only). Processor instruction to place the processor into a low-power state. Logic to place the processor into a C2 power state. Logic to place the processor into a C3 power state. Logic to generate thermal events at specified trip points. Programming Model Generic Hardware Event Logic, must reside in the general-purpose register block Fixed Hardware Control Logic
Legacy/ACPI Select
Lid switch
Processor ISA Fixed Hardware Control Logic Fixed Hardware Control Logic Generic Hardware Event and Control Logic (See description of thermal logic in section 3.9, Battery Management.) Generic Hardware control logic Generic Hardware event logic Generic Hardware event logic
Control logic for switching between different device power states. Logic to detect the insertion and removal of the AC adapter. Logic to detect device insertion and removal events.
Compaq/Intel/Microsoft/Phoenix/Toshiba
ACPI defines register blocks. An ACPI-compatible system provides an ACPI table (the FADT, built in memory at boot-up) that contains a list of pointers to the different fixed hardware register blocks used by OSPM. The bits within these registers have attributes defined for the given register block. The types of registers that ACPI defines are: Status/Enable Registers (for events) Control Registers If a register block is of the status/enable type, then it will contain a register with status bits, and a corresponding register with enable bits. The status and enable bits have an exact implementation definition that needs to be followed (unless otherwise noted), which is illustrated by the following diagram:
Status Bit Event Input Event Output
Enable Bit
Figure 4-4 Block Diagram of a Status/Enable Cell Notice that the status bit, which hardware sets by the Event Input being set in this example, can only be cleared by software writing a 1 to its bit position. Also, the enable bit has no effect on the setting or resetting of the status bit; it only determines if the SET status bit will generate an Event Output, which generates an SCI when set if its enable bit is set. ACPI also defines register groupings. A register grouping consists of two register blocks, with two pointers to two different blocks of registers, where each bit location within a register grouping is fixed and cannot be changed. The bits within a register grouping, which have fixed bit positions, can be split between the two register blocks. This allows the bits within a register grouping to reside in either or both register blocks, facilitating the ability to map bits within several different chips to the same register thus providing the programming model with a single register grouping bit structure. OSPM treats a register grouping as a single register; but located in multiple places. To read a register grouping, OSPM will read the A register block, followed by the B register block, and then will logically OR the two results together (the SLP_TYP field is an exception to this rule). Reserved bits, or unused bits within a register block always return zero for reads and have no side effects for writes (which is a requirement). The SLP_TYPx field can be different for each register grouping. The respective sleeping object \_Sx contains a SLP_TYPa and a SLP_TYPb field. That is, the object returns a package with two integer values of 0-7 in it. OSPM will always write the SLP_TYPa value to the A register block followed by the SLP_TYPb value within the field to the B register block. All other bit locations will be written with the same value. Also, OSPM does not read the SLP_TYPx value but throws it away.
e Bit
Register Block A
d Bit
c b Bit Bit
a Bit
Register Grouping
Register Block B
Figure 4-5 Example Fixed Hardware Feature Register Grouping As an example, the above diagram represents a register grouping consisting of register block A and register block b. Bits a and d are implemented in register block B and register block A returns a zero for these bit positions. Bits b, c and e are implemented in register block A and register block B returns a zero for these bit positions. All reserved or ignored bits return their defined ACPI values.
Compaq/Intel/Microsoft/Phoenix/Toshiba
56 Advanced Configuration and Power Interface Specification When accessing this register grouping, OSPM must read register block a, followed by reading register block b. OSPM then does a logical OR of the two registers and then operates on the results. When writing to this register grouping, OSPM will write the desired value to register group A followed by writing the same value to register group B. ACPI defines the following fixed hardware register blocks. Each register block gets a separate pointer from the FADT. These addresses are set by the OEM as static resources, so they are never changedthe Plug and Play driver cannot re-map ACPI resources. The following register blocks are defined:
Registers PM1a_STS PM1a_EN PM1b_STS PM1b_EN PM1a_CNT PM1b_CNT PM2_CNT Register Blocks PM1a_EVT_BLK PM1 EVT Grouping PM1b_EVT_BLK PM1a_CNT_BLK PM1 CNT Grouping PM1b_CNT_BLK PM2_CNT_BLK PM2 Control Block Register Groupings
PM_TMR_BLK
PM Timer Block
Processor Block General Purpose Event 0 Block General Purpose Event 1 Block
Figure 4-6 Register Blocks versus Register Groupings The PM1 EVT grouping consists of the PM1a_EVT and PM1b_EVT register blocks, which contain the fixed hardware feature event bits. Each event register block (if implemented) contains two registers: a status register and an enable register. Each register grouping has a defined bit position that cannot be changed; however, the bit can be implemented in either register block (A or B). The A and B register blocks for the events allow chipsets to vary the partitioning of events into two or more chips. For read operations, OSPM will generate a read to the associated A and B registers, OR the two values together, and then operate on this result. For write operations, OSPM will write the value to the associated register in both register blocks. Therefore, there are a number of rules to follow when implementing event registers: Reserved or unimplemented bits always return zero (control or enable). Writes to reserved or unimplemented bits have no affect. The PM1 CNT grouping contains the fixed hardware feature control bits and consists of the PM1a_CNT_BLK and PM1b_CNT_BLK register blocks. Each register block is associated with a single control register. Each register grouping has a defined bit position that cannot be changed; however, the bit can be implemented in either register block (A or B). There are a number of rules to follow when implementing CNT registers: Reserved or unimplemented bits always return zero (control or enable). Writes to reserved or unimplemented bits have no affect.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The PM2_CNT_BLK register block currently contains a single bit for the arbiter disable function. The general-purpose event register contains the event programming model for generic features. All generic events, just as fixed events, generate SCIs. Generic event status bits can reside anywhere; however, the toplevel generic event resides in one of the general-purpose register blocks. Any generic feature event status not in the general-purpose register space is considered a child or sibling status bit, whose parent status bit is in the general-purpose event register space. Notice that it is possible to have N levels of general-purpose events prior to hitting the GPE event status. General-purpose event registers are described by two register blocks: The GPE0_BLK or the GPE1_BLK. Each register block is pointed to separately from within the FADT. Each register block is further broken into two registers: GPEx_STS and GPEx_EN. The status and enable registers in the general-purpose event registers follow the event model for the fixed hardware event registers.
Table 4-3 PM1 Control Registers Register PM1_CNTa PM1_CNTb Size (Bytes) PM1_CNT_LEN PM1_CNT_LEN Address (relative to register block) <PM1a_CNT_BLK > <PM1b_CNT_BLK > Table 4-4 PM2 Control Register Register PM2_CNT Size (Bytes) PM2_CNT_LEN Address (relative to register block) <PM2_CNT_BLK > Table 4-5 PM Timer Register Register PM_TMR Size (Bytes) PM_TMR_LEN Address (relative to register block) <PM_TMR_BLK >
Table 4-6 Processor Control Registers Register P_CNT P_LVL2 P_LVL3 Size (Bytes) 4 1 1 Address (relative to register block) Either <P_BLK> or specified by the PTC object (See section 8.3.1, PTC [Processor Throttling Control].) <P_BLK>+4h <P_BLK>+5h
Compaq/Intel/Microsoft/Phoenix/Toshiba
58 Advanced Configuration and Power Interface Specification Table 4-7 General-Purpose Event Registers Register GPE0_STS GPE0_EN GPE1_STS GPE1_EN Size (Bytes) GPE0_LEN/2 GPE0_LEN/2 GPE1_LEN/2 GPE1_LEN/2 Address (relative to register block) <GPE0_BLK> <GPE0_BLK>+GPE0_LEN/2 <GPE1_BLK> <GPE1_BLK>+GPE1_LEN/2
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
3.579545 MHz
Figure 4-7 Power Management Timer The power management timer is a 24-bit or 32-bit fixed rate free running count-up timer that runs off a 3.579545 MHz clock. The ACPI OS checks the FADT to determine whether the PM Timer is a 32-bit or 24-bit timer. The programming model for the PM Timer consists of event logic, and a read port to the counter value. The event logic consists of an event status and enable bit. The status bit is set any time the last bit of the timer (bit 23 or bit 31) goes from set to clear or clear to set. If the TMR_EN bit is set, then the setting of the TMR_STS will generate an ACPI event in the PM1_EVT register grouping (referred to as PMTMR_PME in the diagram). The event logic is only used to emulate a larger timer. OSPM uses the read-only TMR_VAL field (in the PM TMR register grouping) to read the current value of the timer. OSPM never assumes an initial value of the TMR_VAL field; instead, it reads an initial TMR_VAL upon loading OSPM and assumes that the timer is counting. It is allowable to stop the Timer when the system transitions out of the working (G0/S0) state. The only timer reset requirement is that the timer functions while in the working state. The PM Timers programming model is implemented as a fixed hardware feature to increase the accuracy of reading the timer.
4.7.2.2 Buttons
ACPI defines user-initiated events to request OSPM to transition the platform between the G0 working state and the G1 sleeping, G2 soft off and G3 mechanical off states. ACPI also defines a recommended mechanism to unconditionally transition the platform from a hung G0 working state to the G2 soft-off state. ACPI operating systems use power button events to determine when the user is present. As such, these ACPI events are associated with buttons in the ACPI specification.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The ACPI specification supports two button models: A single-button model that generates an event for both sleeping and entering the soft-off state. The function of the button can be configured using OSPM UI. A dual-button model where the power button generates a soft-off transition request and a sleeping button generates a sleeping transition request. The type of button implies the function of the button. Control of these button events is either through the fixed hardware programming model or the generic hardware programming model (control method based). The fixed hardware programming model has the advantage that OSPM can access the button at any time, including when the system is crashed. In a crashed system with a fixed hardware power button, OSPM can make a best effort to determine whether the power button has been pressed to transition to the system to the soft-off state, because it doesnt require the AML interpreter to access the event bits.
The power button can also have an additional capability to unconditionally transition the system from a hung working state to the G2 soft-off state. In the case where OSPM event handler is no longer able to respond to power button events, the power button override feature provides a back-up mechanism to unconditionally transition the system to the soft-off state. This feature can be used when the platform doesnt have a mechanical off button, which can also provide this function. ACPI defines that holding the power button active for four seconds or longer will generate a power button override event.
Figure 4-8 Fixed Power Button Logic The fixed hardware power button has its event programming model in the PM1x_EVT_BLK. This logic consists of a single enable bit and sticky status bit. When the user presses the power button, the power button status bit (PWRBTN_STS) is unconditionally set. If the power button enable bit (PWRBTN_EN) is set and the power button status bit is set (PWRBTN_STS) due to a button press while the system is in the G0 state, then an SCI is generated. OSPM responds to the event by clearing the PWRBTN_STS bit. The power button logic provides debounce logic that sets the PWRBTN_STS bit on the button press edge.
Compaq/Intel/Microsoft/Phoenix/Toshiba
62 Advanced Configuration and Power Interface Specification While the system is in the G1 or G2 global states (S1, S2, S3, S4 or S5 states), any further power button press after the button press that transitioned the system into the sleeping state unconditionally sets the power button status bit and wakes the system, regardless of the value of the power button enable bit. OSPM responds by clearing the power button status bit and waking the system.
Compaq/Intel/Microsoft/Phoenix/Toshiba
This example ASL code performs the following: Creates a device named PWRB and associates the Plug and Play identifier (through the _HID object) of PNP0C0C. The Plug and Play identifier associates this device object with the power button driver. Creates an operational region for the control method power buttons programming model: System I/O space at 0x200. Fields are not accessed are written as zeros. These status bits clear upon writing a 1 to their bit position, therefore preserved would fail in this case. Creates a field within the operational region for the power button status bit (called PBP). In this case the power button status bit is a child of the general-purpose event status bit 0. When this bit is set, it is the responsibility of the ASL-code to clear it (OSPM clears the general-purpose status bits). The address of the status bit is 0x200.0 (bit 0 at address 0x200). Creates an additional status bit called PBW for the power button wake event. This is the next bit and its physical address would be 0x200.1 (bit 1 at address 0x200). Generates an event handler for the power button that is connected to bit 0 of the general-purpose event status register 0. The event handler does the following: Clears the power button status bit in hardware (writes a one to it). Notifies OSPM of the event by calling the Notify command passing the power button object and the device specific event indicator 0x80.
// Define a control method power button Device(\_SB.PWRB){ Name(_HID, EISAID(PNP0C0C)) Name(_PRW,Package(){0, 0x4}) } OperationRegion(\Pho, SystemIO, 0x200, 0x1) Field(\Pho, ByteAcc, NoLock, WriteAsZeros){ PBP, 1, // sleep/off request PBW, 1 // wakeup request } // end of power button device object Scope(\_GPE){ // Root level event handlers Method(_L00){ // uses bit 0 of GP0_STS register If(PBP){ Store(One, PBP) // clear power button status Notify(\_SB.PWRB, 0x80) // Notify OS of event } IF(PBW){ Store(One, PBW) Notify(\_SB.PWRB, 0x2) } } // end of _L00 handler } // end of \_GPE scope
Compaq/Intel/Microsoft/Phoenix/Toshiba
SLPBTN#
Debounce Logic
Figure 4-9 Fixed Hardware Sleep Button Logic The fixed hardware sleep button has its event programming model in the PM1x_EVT_BLK. This logic consists of a single enable bit and sticky status bit. When the user presses the sleep button, the sleep button status bit (SLPBTN_STS) is unconditionally set. Additionally, if the sleep button enable bit (SLPBTN_EN) is set, and the sleep button status bit is set (SLPBTN_STS, due to a button press) while the system is in the G0 state, then an SCI is generated. OSPM responds to the event by clearing the SLPBTN_STS bit. The sleep button logic provides debounce logic that sets the SLPBTN_STS bit on the button press edge. While the system is sleeping (in either the S0, S1, S2, S3 or S4 states), any further sleep button press (after the button press that caused the system transition into the sleeping state) sets the sleep button status bit (SLPBTN_STS) and wakes the system if the SLP_EN bit is set. OSPM responds by clearing the sleep button status bit and waking the system.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The sleep button device needs to be declared as a device within the ACPI Namespace for the platform and only requires an _HID. An example definition is shown below. The AML code below does the following: Creates a device named SLPB and associates the Plug and Play identifier (through the _HID object) of PNP0C0E. The Plug and Play identifier associates this device object with the sleep button driver. Creates an operational region for the control method sleep buttons programming model: System I/O space at 0x201. Fields that are not accessed are written as 1s (these status bits clear upon writing a 1 to their bit position, hence preserved would fail in this case). Creates a field within the operational region for the sleep button status bit (called PBP). In this case the sleep button status bit is a child of the general-purpose status bit 0. When this bit is set it is the responsibility of the AML code to clear it (OSPM clears the general-purpose status bits). The address of the status bit is 0x201.0 (bit 0 at address 0x201). Creates an additional status bit called PBW for the sleep button wake event. This is the next bit and its physical address would be 0x201.1 (bit 1 at address 0x201). Generates an event handler for the sleep button that is connected to bit 0 of the general-purpose status register 0. The event handler does the following: Clears the sleep button status bit in hardware (writes a 1 to it). Notifies OSPM of the event by calling the Notify command passing the sleep button object and the device specific event indicator 0x80.
// Define a control method sleep button Device(\_SB.SLPB){ Name(_HID, EISAID(PNP0C0E)) Name(_PRW, Package(){0x01, 0x04}) OperationRegion(\Boo, SystemIO, 0x201, 0x1) Field(\Boo, ByteAcc, NoLock, WriteAsZeros){ SBP, 1, // sleep request SBW, 1 // wakeup request } // end of field definition } Scope(\_GPE){ // Root level event handlers Method(_L01){ // uses bit 1 of GP0_STS register If(SBP){ Store(One, SBP) // clear sleep button status Notify(\_SB.SLPB, 0x80) // Notify OS of event } IF(SBW){ Store(One, SBW) Notify(\_SB.SLPB, 0x2) } } // end of _L01 handler } // end of \_GPE scope
Compaq/Intel/Microsoft/Phoenix/Toshiba
PWRBTN_OR
Figure 4-10 Sleeping/Wake Logic The logic is controlled via two bit fields: Sleep Enable (SLP_EN) and Sleep Type (SLP_TYPx). The type of sleep state desired is programmed into the SLP_TYPx field and upon assertion of the SLP_EN the hardware will sequence the system into the defined sleeping state. OSPM gets values for the SLP_TYPx field from the \_Sx objects defined in the static definition block. If the object is missing OSPM assumes the hardware does not support that sleeping state. Prior to entering the desired sleeping state, OSPM will read the designated \_Sx object and place this value in the SLP_TYP field. Additionally ACPI defines a fail-safe Off protocol called the power button override, which allows the user to initiate an Off sequence in the case where the system software is no longer able to recover the system (the system has hung). ACPI defines that this sequence be initiated by the user pressing the power button for over 4 seconds, at which point the hardware unconditionally sequences the system to the Off state. This logic is represented by the PWRBTN_OR signal coming into the sleep logic. While in any of the sleeping states (G1), an enabled Wake event will cause the hardware to sequence the system back to the working state (G0). The Wake Status bit (WAK_STS) is provided for OSPM to spinon after setting the SLP_EN/SLP_TYP bit fields. When waking from the S1 sleeping state, execution control is passed backed to OSPM immediately, whereas when waking from the S2-S5 states execution control is passed to the BIOS software (execution begins at the CPUs reset vector). The WAK_STS bit provides a mechanism to separate OSPMs sleeping and waking code during an S1 sequence. When the hardware has sequenced the system into the sleeping state (defined here as the processor is no longer able to execute instructions), any enabled wake event is allowed to set the WAK_STS bit and sequence the system back on (to the G0 state). If the system does not support the S1 sleeping state, the WAK_STS bit can always return zero. -If more than a single sleeping state is supported, then the sleeping/wake logic is required to be able to dynamically sequence between the different sleeping states. This is accomplished by waking the system; OSPM programs the new sleep state into the SLP_TYP field, and then sets the SLP_EN bitplacing the system again in the sleeping state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Figure 4-11 RTC Alarm The RTC wake event status and enable bits are an optional fixed hardware feature and a flag within the FADT (FIXED_RTC) indicates if the register bits are to be used by OSPM. If the RTC wake event status and enable bits are implemented in fixed hardware, OSPM can determine if the RTC was the source of the wake event without loading the entire OS. If the fixed hardware feature event bits are not supported, then OSPM will attempt to determine this by reading the RTCs status field. OSPM supports enhancements over the existing RTC device (which only supports a 99 year date and 24hour alarm). Optional extensions are provided for the following features: Day Alarm. The DAY_ALRM field points to an optional CMOS RAM location that selects the day within the month to generate an RTC alarm. Month Alarm. The MON_ALRM field points to an optional CMOS RAM location that selects the month within the year to generate an RTC alarm. Centenary Value. The CENT field points to an optional CMOS RAM location that represents the centenary value of the date (thousands and hundreds of years).
Notice that the G2/S5 soft off and the G3 mechanical off states are not sleeping states. The OS will disable the RTC_EN bit prior to entering the G2/S5 or G3 states regardless.
Compaq/Intel/Microsoft/Phoenix/Toshiba
68 Advanced Configuration and Power Interface Specification The RTC_STS bit is set through the RTC interrupt (IRQ8 in IA-PC architecture systems). OSPM will insure that the periodic and update interrupt sources are disabled prior to sleeping. This allows the RT Cs interrupt pin to serve as the source for the RTC_STS bit generation. Table 4-10 Alarm Field Decodings within the FADT Field DAY_ALRM Value Eight bit value that can represent 0x01-0x31 days in BCD or 0x010x1F days in binary. Bits 6 and 7 of this field are treated as Ignored by software. The RTC is initialized such that this field contains a dont care value when the BIOS switches from legacy to ACPI mode. A dont care value can be any unused value (not 0x1-0x31 BCD or 0x01-0x1F hex) that the RTC reverts back to a 24 hour alarm. Eight bit value that can represent 01-12 months in BCD or 0x01-0xC months in binary. The RTC is initialized such that this field contains a dont care value when the BIOS switches from legacy to ACPI mode. A dont care value can be any unused value (not 1-12 BCD or x01-xC hex) that the RTC reverts back to a 24 hour alarm and/or 31 day alarm). 8-bit BCD or binary value. This value indicates the thousand year and hundred year (Centenary) variables of the date in BCD (19 for this century, 20 for the next) or binary (x13 for this century, x14 for the next). Address (Location) in RTC CMOS RAM (Must be Bank 0) The DAY_ALRM field in the FADT will contain a non-zero value that represents an offset into the RTCs CMOS RAM area that contains the day alarm value. A value of zero in the DAY_ALRM field indicates that the day alarm feature is not supported.
MON_ALRM
The MON_ALRM field in the FADT will contain a non-zero value that represents an offset into the RTCs CMOS RAM area that contains the month alarm value. A value of zero in the MON_ALRM field indicates that the month alarm feature is not supported. If the month alarm is supported, the day alarm function must also be supported.
CENTURY
The CENTURY field in the FADT will contain a non-zero value that represents an offset into the RTCs CMOS RAM area that contains the Centenary value for the date. A value of zero in the CENTURY field indicates that the Centenary value is not supported by this RTC.
Compaq/Intel/Microsoft/Phoenix/Toshiba
0 Dec 1
Figure 4-12 Power Management Events to SMI/SCI Control Logic The interrupt events (those that generate SMIs in legacy mode and SCIs in ACPI mode) are sent through a decoder controlled by the SCI_EN bit. For legacy mode this bit is reset, which routes the interrupt events to the SMI interrupt logic. For ACPI mode this bit is set, which routes interrupt events to the SCI interrupt logic. This bit always returns set for ACPI-compatible hardware that does not support a legacy power management mode (in other words, the bit is wired to read as 1 and ignore writes). The SCI interrupt is defined to be a shareable interrupt and is connected to an OS visible interrupt that uses a shareable protocol. The FADT has an entry that indicates what interrupt the SCI interrupt is mapped to (see section 5.2.5, System Description Table Header). If the ACPI platform supports both legacy and ACPI modes, it has a register that generates a hardware event (for example, SMI for IA-PC processors). OSPM uses this register to make the hardware to switch in and out of ACPI mode. Within the FADT are three values that signify the address (SMI_CMD) of this port and the data value written to enable the ACPI state (ACPI_ENABLE), and to disable the ACPI state (ACPI_DISABLE). To transition an ACPI/Legacy platform from the Legacy mode to the ACPI mode the following would occur: ACPI driver checks that the SCI_EN bit is zero, and that it is in the Legacy mode. OSPM does an OUT to the SMI_CMD port with the data in the ACPI_ENABLE field of the FADT. OSPM polls the SCI_EN bit until it is sampled as SET. To transition an ACPI/Legacy platform from the ACPI mode to the Legacy mode the following would occur: ACPI driver checks that the SCI_EN bit is one, and that it is in the ACPI mode. OSPM does an OUT to the SMI_CMD port with the data in the ACPI_DISABLE field of the FADT. OSPM polls the SCI_EN bit until it is sampled as RESET. Platforms that only support ACPI always return a 1 for the SCI_EN bit. In this case OSPM skips the Legacy to ACPI transition stated above.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The PM1 status registers contain the fixed hardware feature status bits. The bits can be split between two registers: PM1a_STS or PM1b_STS. Each register grouping can be at a different 32-bit aligned address and is pointed to by the PM1a_EVT_BLK or PM1b_EVT_BLK. The values for these pointers to the register space are found in the FADT. Accesses to the PM1 status registers are done through byte or word accesses. For ACPI/legacy systems, when transitioning from the legacy to the G0 working state this register is cleared by BIOS prior to setting the SCI_EN bit (and thus passing control to OSPM). For ACPI only platforms (where SCI_EN is always set), when transitioning from either the mechanical off (G3) or soft-off state to the G0 working state this register is cleared prior to entering the G0 working state. This register contains optional features enabled or disabled within the FADT. If the FADT indicates that the feature is not supported as a fixed hardware feature, then software treats these bits as ignored. Table 4-11 PM1 Status Registers Fixed Hardware Feature Status Bits Bit 0 Name TMR_STS Description This is the timer carry status bit. This bit gets set any time the 23rd/31st bit of a 24/32-bit counter changes (whenever the MSB changes from clear to set or set to clear. While TMR_EN and TMR_STS are set, an interrupt event is raised. Reserved This is the bus master status bit. This bit is set any time a system bus master requests the system bus, and can only be cleared by writing a 1 to this bit position. Notice that this bit reflects bus master activity, not CPU activity (this bit monitors any bus master that can cause an incoherent cache for a processor in the C3 state when the bus master performs a memory transaction).
1-3 4
Reserved BM_STS
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 4-11 PM1 Status Registers Fixed Hardware Feature Status Bits (continued) Bit 5 Name GBL_STS Description This bit is set when an SCI is generated due to the BIOS wanting the attention of the SCI handler. BIOS will have a control bit (somewhere within its address space) that will raise an SCI and set this bit. This bit is set in response to the BIOS releasing control of the Global Lock and having seen the pending bit set. Reserved. These bits always return a value of zero. This optional bit is set when the Power Button is pressed. In the system working state, while PWRBTN_EN and PWRBTN_STS are both set, an interrupt event is raised. In the sleeping or softoff state, a wake event is generated when the power button is pressed (regardless of the PWRBTN_EN bit setting). This bit is only set by hardware and can only be reset by software writing a 1 to this bit position. ACPI defines an optional mechanism for unconditional transitioning a system that has stopped working from the G0 working state into the G2 soft-off state called the power button override. If the Power Button is held active for more than four seconds, this bit is cleared by hardware and the system transitions into the G2/S5 Soft Off state (unconditionally). Support for the power button is indicated by the PWR_BUTTON flag in the FADT being reset (zero). If the PWR_BUTTON flag is set or a power button device object is present in the ACPI Namespace, then this bit field is ignored by OSPM. If the power button was the cause of the wake (from an S1-S4 state), then this bit is set prior to returning control to OSPM. 9 SLPBTN_STS This optional bit is set when the sleep button is pressed. In the system working state, while SLPBTN_EN and SLPBTN_STS are both set, an interrupt event is raised. In the sleeping or softoff states a wake event is generated when the sleeping button is pressed and the SLPBTN_EN bit is set. This bit is only set by hardware and can only be reset by software writing a 1 to this bit position. Support for the sleep button is indicated by the SLP_BUTTON flag in the FADT being reset (zero). If the SLP_BUTTON flag is set or a sleep button device object is present in the ACPI Namespace, then this bit field is ignored by OSPM. If the sleep button was the cause of the wake (from an S1-S4 state), then this bit is set prior to returning control to OSPM.
6-7 8
Reserved PWRBTN_STS
Compaq/Intel/Microsoft/Phoenix/Toshiba
72 Advanced Configuration and Power Interface Specification Table 4-11 PM1 Status Registers Fixed Hardware Feature Status Bits (continued) Bit 10 Name RTC_STS Description This optional bit is set when the RTC generates an alarm (asserts the RTC IRQ signal). Additionally, if the RTC_EN bit is set then the setting of the RTC_STS bit will generate a power management event (an SCI, SMI, or resume event). This bit is only set by hardware and can only be reset by software writing a 1 to this bit position. If the RTC was the cause of the wake (from an S1-S3 state), then this bit is set prior to returning control to OSPM. If the RTC_S4 flag within the FADT is set, and the RTC was the cause of the wake from the S4 state), then this bit is set prior to returning control to OSPM. 11 12-14 15 Ignore Reserved WAK_STS This bit field is ignored by software. Reserved. These bits always return a value of zero. This bit is set when the system is in the sleeping state and an enabled wake event occurs. Upon setting this bit system will transition to the working state. This bit is set by hardware and can only be cleared by software writing a 1 to this bit position.
The PM1 enable registers contain the fixed hardware feature enable bits. The bits can be split between two registers: PM1a_EN or PM1b_EN. Each register grouping can be at a different 32-bit aligned address and is pointed to by the PM1a_EVT_BLK or PM1b_EVT_BLK. The values for these pointers to the register space are found in the FADT. Accesses to the PM1 Enable registers are done through byte or word accesses. For ACPI/legacy systems, when transitioning from the legacy to the G0 working state the enables are cleared by BIOS prior to setting the SCI_EN bit (and thus passing control to OSPM). For ACPI-only platforms (where SCI_EN is always set), when transitioning from either the mechanical off (G3) or soft-off state to the G0 working state this register is cleared prior to entering the G0 working state. This register contains optional features enabled or disabled within the FADT. If the FADT indicates that the feature is not supported as a fixed hardware feature, then software treats the enable bits as write as zero.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 4-12 PM1 Enable Registers Fixed Hardware Feature Enable Bits Bit 0 Name TMR_EN Description This is the timer carry interrupt enable bit. When this bit is set then an SCI event is generated anytime the TMR_STS bit is set. When this bit is reset then no interrupt is generated when the TMR_STS bit is set. Reserved. These bits always return a value of zero. The global enable bit. When both the GBL_EN bit and the GBL_STS bit are set, an SCI is raised. Reserved This optional bit is used to enable the setting of the PWRBTN_STS bit to generate a power management event (SCI or wake). The PWRBTN_STS bit is set anytime the power button is asserted. The enable bit does not have to be set to enable the setting of the PWRBTN_STS bit by the assertion of the power button (see description of the power button hardware). Support for the power button is indicated by the PWR_BUTTON flag in the FADT being reset (zero). If the PWR_BUTTON flag is set or a power button device object is present in the ACPI Namespace, then this bit field is ignored by OSPM. 9 SLPBTN_EN This optional bit is used to enable the setting of the SLPBTN_STS bit to generate a power management event (SCI or wake). The SLPBTN_STS bit is set anytime the sleep button is asserted. The enable bit does not have to be set to enable the setting of the SLPBTN_STS bit by the active assertion of the sleep button (see description of the sleep button hardware). Support for the sleep button is indicated by the SLP_BUTTON flag in the FADT being reset (zero). If the SLP_BUTTON flag is set or a sleep button device object is present in the ACPI Namespace, then this bit field is ignored by OSPM. 10 RTC_EN This optional bit is used to enable the setting of the RTC_STS bit to generate a wake event. The RTC_STS bit is set any time the RTC generates an alarm. Reserved. These bits always return a value of zero.
1-4 5 6-7 8
11-15
Reserved
Compaq/Intel/Microsoft/Phoenix/Toshiba
The PM1 control registers contain the fixed hardware feature control bits. These bits can be split between two regis ters: PM1a_CNT or PM1b_CNT. Each register grouping can be at a different 32-bit aligned address and is pointed to by the PM1a_CNT_BLK or PM1b_CNT_BLK. The values for these pointers to the register space are found in the FADT. Accesses to PM1 control regis ters are accessed through byte and word accesses. This register contains optional features enabled or disabled within the FADT. If the FADT indicates that the feature is not supported as a fixed hardware feature, then software treats these bits as ignored. Table 4-13 PM1 Control Registers Fixed Hardware Feature Control Bits Bit 0 Name SCI_EN Description Selects the power management event to be either an SCI or SMI interrupt for the following events. When this bit is set, then power management events will generate an SCI interrupt. When this bit is reset power management events will generate an SMI interrupt. It is the responsibility of the hardware to set or reset this bit. OSPM always preserves this bit position. When set, this bit allows the generation of a bus master request to cause any processor in the C3 state to transition to the C0 state. When this bit is reset, the generation of a bus master request does not affect any processor in the C3 state. This write-only bit is used by the ACPI software to raise an event to the BIOS software, that is, generates an SMI to pass execution control to the BIOS for IA-PC platforms. BIOS software has a corresponding enable and status bit to control its ability to receive ACPI events (for example, BIOS_EN and BIOS_STS). The GBL_RLS bit is set by OSPM to indicate a release of the Global Lock and the setting of the pending bit in the FACS memory structure. Reserved. These bits are reserved by OSPM. Software ignores this bit field. Defines the type of sleeping state the system enters when the SLP_EN bit is set to one. This 3-bit field defines the type of hardware sleep state the system enters when the SLP_EN bit is set. The \_Sx object contains 3-bit binary values associated with the respective sleeping state (as described by the object). OSPM takes the two values from the \_Sx object and programs each value into the respective SLP_TYPx field. This is a write-only bit and reads to it always return a zero. Setting this bit causes the system to sequence into the sleeping state associated with the SLP_TYPx fields programmed with the values from the \_Sx object. Reserved. This field always returns zero.
BM_RLD
GBL_RLS
3-8 9 10-12
13
SLP_EN
14-15
Reserved
Compaq/Intel/Microsoft/Phoenix/Toshiba
This read-only register returns the current value of the power management timer (PM timer). The FADT has a flag called TMR_ VAL_EXT that an OEM sets to indicate a 32-bit PM timer or reset to indicate a 24bit PM timer. When the last bit of the timer toggles the TMR_STS bit is set. This register is accessed as 32 bits. This register contains optional features enabled or disabled within the FADT. If the FADT indicates that the feature is not supported as a fixed hardware feature, then software treats these bits as ignored. Table 4-14 PM Timer Bits Bit 0-23 Name TMR_VAL Description This read-only field returns the running count of the power management timer. This is a 24-bit counter that runs off a 3.579545-MHz clock and counts while in the S0 working system state. The starting value of the timer is undefined, thus allowing the timer to be reset (or not) by any transition to the S0 state from any other state. The timer is reset (to any initial value), and then continues counting until the systems 14.31818 MHz clock is stopped upon entering its Sx state. If the clock is restarted without a reset, then the counter will continue counting from where it stopped. This read-only field returns the upper eight bits of a 32-bit power management timer. If the hardware supports a 32-bit timer, then this field will return the upper eight bits; if the hardware supports a 24-bit timer then this field returns all zeros.
24-31
E_TMR_VAL
This register block is naturally aligned and accessed based on its length. For ACPI 1.0 this register is byte aligned and accessed as a byte. This register contains optional features enabled or disabled within the FADT. If the FADT indicates that the feature is not supported as a fixed hardware feature, then software treats these bits as ignored. Table 4-15 PM2 Control Register Bits Bit 0 Name ARB_DIS Description This bit is used to enable and disable the system arbiter. When this bit is CLEAR the system arbiter is enabled and the arbiter can grant the bus to other bus masters. When this bit is SET the system arbiter is disabled and the default CPU has ownership of the system. OSPM clears this bit when using the C0, C1 and C2 power states. 1-7 Reserved Reserved
Compaq/Intel/Microsoft/Phoenix/Toshiba
This register is accessed as a DWORD. 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. Software treats all other CLK_VAL bits as ignored (those not used by the duty setting value). Table 4-16 Processor Control Register Bits Bit 0-3 4 Name CLK_VAL THT_EN Description Possible locations for the clock throttling value. This bit enables clock throttling of the clock as set in the CLK_VAL field. THT_EN bit must be reset LOW when changing the CLK_VAL field (changing the duty setting). Possible locations for the clock throttling value.
5-31
CLK_VAL
This register is accessed as a byte. Table 4-17 Processor LVL2 Register Bits Bit 0-7 Name P_LVL2 Description Reads to this register return all zeros; writes to this register have no effect. Reads to this register also generate an enter a C2 power state to the clock control logic.
Compaq/Intel/Microsoft/Phoenix/Toshiba
This register is accessed as a byte. Table 4-18 Processor LVL3 Register Bits Bit 0-7 Name P_LVL3 Description Reads to this register return all zeros; writes to this register have no effect. Reads to this register also generate an enter a C3 power state to the clock control logic.
Compaq/Intel/Microsoft/Phoenix/Toshiba
78 Advanced Configuration and Power Interface Specification The example below illustrates some of these concepts. The top diagram shows how the logic is partitioned into two chips: a chipset and an embedded controller. The chipset contains the interrupt logic, performs the power button (which is part of the fixed register space, and is not discussed here), the lid switch (used in portables to indicate when the clam shell lid is open or closed), and the RI# function (which can be used to wake a sleeping system). The embedded controller chip is used to perform the AC power detect and dock/undock event logic. Additionally, the embedded controller supports some system management functions using an OS-transparent interrupt in the embedded controller (represented by the EXTSMI# signal).
Momentary
Power Button
PWRBTN#
Embedded Controller
AC#
Docking Chip
LID Switch
LID#
RI#
GPx_REG Block
EC_STS GP_STS.0
EXTPME#
EXTPME#
EXTPME#
LID_POL S33.2
Figure 4-13 Example of General-Purpose vs. Generic Hardware Events At the top level, the generic events in the GPEx_STS register are the: Embedded controller interrupt, which contains two query events: one for AC detection and one for docking (the docking query event has a child interrupt status bit in the docking chip). Ring indicate status (used for waking the system). Lid status. The embedded controller event status bit (EC_STS) is used to indicate that one of two query events is active. A query event is generated when the AC# signal is asserted. The embedded controller returns a query value of 34 (any byte number can be used) upon a query command in response to this event; OSPM will then schedule for execution the control method associated with query value 34. Another query event is for the docking chip that generates a docking event. In this case, the embedded controller will return a query value of 35 upon a query command from system software responding to an SCI from the embedded controller. OSPM will then schedule the control method associated with the query value of 35 to be executed, which services the docking event.
Compaq/Intel/Microsoft/Phoenix/Toshiba
For each of the status bits in the GPEx_STS register, there is a corresponding enable bit in the GPEx_EN register. Notice that the child status bits do not necessarily need enable bits (see the DOCK_STS bit). The lid logic contains a control bit to determine if its status bit is set when the LID is open (LID_POL is and LID is) or closed (LID_POL is clear and LID is clear). This control bit resides in generic I/O space (in this case, bit 2 of system I/O space 33h) and would be manipulated with a control method associated with the lid object. As with fixed hardware events, OSPM will clear the status bits in the GPEx register blocks. However, AML code clears all sibling status bits in the generic hardware. Generic hardware features are controlled by OEM supplied control methods, encoded in AML. ACPI provides both an event and control model for development of these features. The ACPI specification also provides specific control methods for notifying OSPM of certain power management and Plug and Play events. Section 5, ACPI Software Programming Model, provides information on the types of hardware functionality that support the different types of subsystems. The following is a list of features supported by ACPI. The list is not intended to be complete or comprehensive. Device insertion/ejection (for example, docking, device bay, A/C adapter) Batteries 4 Platform thermal subsystem Turning on/off power resources Mobile lid Interface Embedded controller System indicators OEM-specific wake events Plug and Play configuration
ACPI operating systems assume the use of the Smart Battery System Implementers Forum defined standard for batteries, called the Smart Battery Specification (SBS). ACPI provides a set of control methods for use by OEMs that use a proprietary control method battery interface.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The general-purpose event 0 status register contains the general-purpose event status bits in bank zero of the general-purpose registers. Each available status bit in this register corresponds to the bit with the same bit position in the GPE0_EN register. Each available status bit in this register is set when the event is active, and can only be cleared by software writing a 1 to its respective bit position. For the generalpurpose event registers, unimplemented bits are ignored by OSPM. Each status bit can optionally wake the system if asserted when the system is in a sleeping state with its respective enable bit set. OSPM accesses GPE registers through byte accesses (regardless of their length).
The general-purpose event 0 enable register contains the general-purpose event enable bits. Each available enable bit in this register corresponds to the bit with the same bit position in the GPE0_STS register. The enable bits work similar to how the enable bits in the fixed-event registers are defined: When the enable bit is set, then a set status bit in the corresponding status bit will generate an SCI bit. OSPM accesses GPE registers through byte accesses (regardless of their length).
The general -purpose event 1 status register contains the general-purpose event status bits. Each available status bit in this register corresponds to the bit with the same bit position in the GPE1_EN register. Each available status bit in this register is set when the event is active, and can only be cleared by software writing a 1 to its respective bit position. For the general-purpose event registers, unimplemented bits are ignored by the operating system. Each status bit can optionally wake the system if asserted when the system is in a sleeping state with its respective enable bit set. OSPM accesses GPE registers through byte accesses (regardless of their length).
Compaq/Intel/Microsoft/Phoenix/Toshiba
The general-purpose event 1 enable register contains the general-purpose event enable. Each available enable bit in this register corresponds to the bit with the same bit position in the GPE1_STS register. The enable bits work similar to how the enable bits in the fixed-event registers are defined: When the enable bit is set, a set status bit in the corresponding status bit will generate an SCI bit. OSPM accesses GPE registers through byte accesses (regardless of their length).
8 ms Debounce
LID_STS
Figure 4-14 Example Generic Address Space Lid Switch Logic This logic will set the Lid status bit when the button is pressed or released (depending on the LID_POL bit). The ASL code defines the following: An operational region where the lid polarity resides in address space System address space in registers 0x201. A field operator to allow AML code to access this bit: Polarity control bit (LID_POL) is called LPOL and is accessed at 0x201.0. A device called \_SB.LID with the following: A Plug and Play identifier PNP0C0D that associates OSPM with this object. Defines an object that specifies a change in the lids status bit can wake the system from the S4 sleep state and from all higher sleep states (S1, S2, or S3).
Compaq/Intel/Microsoft/Phoenix/Toshiba
82 Advanced Configuration and Power Interface Specification The lid switch event handler that does the following: Defines the lids status bit (LID_STS) as a child of the general-purpose event 0 register bit 1. Defines the event handler for the lid (only event handler on this status bit) that does the following: Flips the polarity of the LPOL bit (to cause the event to be generated on the opposite condition). Generates a notify to the OS that does the following: Passes the \_SB.LID object. Indicates a device specific event (notify value 0x80).
// Define a Lid switch OperationRegion(\Pho, SystemIO, 0x201, 0x1) Field(\Pho, ByteAcc, NoLock, Preserve) { LPOL, 1 // Lid polarity control bit } Device(\_SB.LID){ Name(_HID, EISAID(PNP0C0D)) Method(_LID){Return(LPOL)} Name(_PRW, Package(2){ 1, // bit 1 of GPE to enable Lid wakeup 0x04} // can wakeup from S4 state ) } Scope(\_GPE){ // Root level event handlers Method(_L01){ // uses bit 1 of GP0_STS register Not(LPOL, LPOL) // Flip the lid polarity bit Notify(LID, 0x80) // Notify OS of event } }
At the top level, the generic events in the GPEx_STS register are: Embedded controller interrupt, which contains two query events: one for AC detection and one for docking (the docking query event has a child interrupt status bit in the docking chip) Ring indicate status (used for waking the system) Lid status The embedded controller event status bit (EC_STS) is used to indicate that one of two query events is active. A query event is generated when the AC# signal is asserted. The embedded controller returns a query value of 34 (any byte number can be used) upon a query command in response to this event; OSPM will then schedule for execution the control method associated with query value 34. Another query event is for the docking chip that generates a docking event. In this case, the embedded controller will return a query value of 35 upon a query command from system software responding to an SCI from the embedded controller. OSPM will then schedule the control method associated with the query value of 35 to be executed, which services the docking event. For each of the status bits in the GPEx_STS register, there is a corresponding enable bit in the GPEx_EN register. Notice that the child status bits do not necessarily need enable bits (see the DOCK_STS bit). The lid logic contains a control bit to determine if its status bit is set when the LID is open (LID_POL is set and LID is set) or closed (LID_POL is clear and LID is clear). This control bit resides in generic I/O space (in this case, bit 2 of system I/O space 33h) and would be manipulated with a control method associated with the lid object. As with fixed hardware events, OSPM will clear the status bits in the GPEx register blocks. However, AML code is required to clear all sibling status bits in generic space.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Generic hardware features are controlled by OEM supplied AML code. ACPI provides both an event and control model for development of these features. The ACPI specification also provides specific control methods for notifying OSPM of certain power management and Plug and Play events. Section 5, ACPI Software Programming Model, provides information on the types of hardware hooks required to support the different types of subsystems. The following is a list of features supported by ACPI, however the list is not intended to be complete or comprehensive Device insertion/ejection (for example, docking, device bay, A/C adapter) Batteries 5 Platform thermal subsystem Turning on/off power resources Mobile lid interface Embedded controller System indicators OEM-specific wake events Plug and Play configuration
ACPI OSs assume the use of the Duracell/Intel defined standard for batteries, called the Smart Battery Specification (SBS). ACPI provides a set of control methods for use by OEMs that use a proprietary control method battery interface.
Compaq/Intel/Microsoft/Phoenix/Toshiba
84 Advanced Configuration and Power Interface Specification Additionally the embedded controller can support up to 255 generic events per embedded controller, referred to as query events. These query event handles are defined within the embedded controllers device as control methods. An example of defining an embedded controller device is shown below:
Device(EC0) { // PnP ID Name(_HID, EISAID(PNP0C09)) // Returns the Current Resources of EC Name(_CRS, ResourceTemplate(){ IO(Decode16, 0x62, 0x62, 0, 1) IO(Decode16, 0x66, 0x66, 0, 1) }) // Define that the EC SCI is bit 0 of the GP_STS register Name(_GPE, 0) // embedded controller is wired to bit 0 of GPE OperationRegion(\EC0, EmbeddedControl, 0, 0xFF) Field(EC0, ByteAcc, Lock, Preserve) { // Field definitions } Method(Q00){..} Method(QFF){..} }
For more information on the embedded controller, see section 13, ACPI Embedded Controller Interface Specification.
4.7.4.2.3 Fan
ACPI has a device driver to control fans (active cooling devices) in platforms. A fan is defined as a device with the Plug and Play ID of PNP0C0B. It should then contain a list power resources used to control the fan. For more information, see section 10, ACPI-Specific Device Objects.
Compaq/Intel/Microsoft/Phoenix/Toshiba
XSDT
Header
Sig
Header
Sig
Header
Figure 5-1 Root System Description Pointer and Table All system description tables start with identical headers. The primary purpose of the system description tables is to define for OSPM various industry-standard implementation details. Such definitions enable various portions of these implementations to be flexible in hardware requirements and design, yet still provide OSPM with the knowledge it needs to control hardware directly.
Compaq/Intel/Microsoft/Phoenix/Toshiba
86 Advanced Configuration and Power Interface Specification The Root System Description Table (RSDT) points to other tables in memory. Always the first table, it points to the Fixed ACPI Description table (FADT). The data within this table includes various fixedlength entries that describe the fixed ACPI features of the hardware. The FADT table always refers to the Differentiated System Description Table (DSDT), which contains information and descriptions for various system features. The relationship between these tables is shown in Figure 5-2.
Firmware ACPI Control Structure
FACP
Header
DSDT
Header
FACS
Wake Vector Shared Lock
Software Hardware
...
GPx_BLK
OEM-Specific
PM2x_BLK PM1x_BLK
Located in port space
Figure 5-2 Description Table Structures OSPM searches the following physical ranges on 16-byte boundaries for a RSDP structure. This structure is located by searching the areas listed below for a valid signature and checksum match: The first 1 KB of the Extended BIOS Data Area (EBDA). For EISA or MCA systems, the EBDA can be found in the two-byte location 40:0Eh on the BIOS data area. In the BIOS read-only memory space between 0E0000h and 0FFFFFh. When OSPM locates the structure, it looks at the physical address for the Root System Description Table. The Root System Description Table starts with the signature RSDT and contains one or more physical pointers to other system description tables that provide various information about the system. As shown in Figure 5-1, there is always a physical address in the Root System Description Table for the Fixed ACPI Description table (FADT). When OSPM follows a physical pointer to another table, it examines each table for a known signature. Based on the signature, OSPM can then interpret the implementation-specific data within the description table. The purpose of the FADT is to define various static system information related to configuration and power management. The Fixed ACPI Description Table starts with the FACP signature. The FADT describes the implementation and configuration details of the ACPI hardware registers on the platform.
Compaq/Intel/Microsoft/Phoenix/Toshiba
For a specification of the ACPI Hardware Register Blocks (PM1a_EVT_BLK, PM1b_EVT_BLK, PM1a_CNT_BLK, PM1b_CNT_BLK, PM2_CNT_BLK, PM_TMR_BLK, GP0_BLK, GP1_BLK, and one or more P_BLKs), see section 4.7, ACPI Register Model. The PM1a_EVT_BLK, PM1b_EVT_BLK, PM1a_CNT_BLK, PM1b_CNT_BLK, PM2_CNT_BLK, and PM_TMR_BLK blocks are for controlling low-level ACPI system functions. The GPE0_BLK and GPE1_BLK blocks provide the foundation for an interrupt-processing model for Control Methods. The P_BLK blocks are for controlling processor features. Besides ACPI Hardware Register implementation information, the FADT also contains a physical pointer to the Differentiated System Description Table (DSDT). The DSDT contains a Definition Block named the Differentiated Definition Block for the DSDT that contains implementation and configuration information OSPM can use to perform power management, thermal management, or Plug and Play functionality that goes beyond the information described by the ACPI hardware registers. A Definition Block contains information about hardware implementation details in the form of a hierarchical namespace, data, and control methods encoded in AML. OSPM loads or unloads an entire definition block as a logical unit. The Differentiated Definition Block is always loaded by OSPM at boot time and cannot be unloaded. Definition Blocks can either define new system attributes or, in some cases, build on prior definitions. A Definition Block can be loaded from system memory address space. One use of a Definition Block is to describe and distribute platform version changes. Definition blocks enable wide variations of hardware platform implementations to be described to the ACPI-compatible OS while confining the variations to reasonable boundaries. Definition blocks enable simple platform implementations to be expressed by using a few well-defined object names. In theory, it might be possible to define a PCI configuration space-like access method within a Definition Block, by building it from I/O space, but that is not the goal of the Definition Block specification. Such a space is usually defined as a built in operator. Some operators perform simple functions and others encompass complex functions. The power of the Definition Block comes from its ability to allow these operations to be glued together in numerous ways, to provide functionality to OSPM. The operators present are intended to allow many useful hardware designs to be ACPI-expressed, not to allow all hardware designs to be expressed.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
5.2.2 Compatibility
All versions of the ACPI tables must maintain backward compatibility. To accomplish this, modifications of the tables consist of redefinition of previously reserved fields and values plus appending data to the 1.0 tables. Modifications of the ACPI tables require that the version numbers of the modified tables be incremented. The length field in the tables includes all additions and the checksum is maintained for the entire length of the table.
Field Address_Space_ID
Description The address space where the data structure or register exists. Defined values are: 0System Memory 1System I/O 2PCI Configuration Space 3Embedded Controller 4SMBus 0x7F Functional Fixed Hardware
Register_Bit_Width Register_Bit_Offset
1 1
1 2
The size in bits of the given register. When addressing a data structure, this field must be zero. The bit offset of the given register at the given address. When addressing a data structure, this field must be zero. Must be 0. The 64-bit address of the data structure or register in the given address space (relative to the processor). (See below for specific formats.)
Reserved Address
1 8
3 4
Compaq/Intel/Microsoft/Phoenix/Toshiba
90 Advanced Configuration and Power Interface Specification Table 5-2 Address Space Format Address Space 0System Memory 1System I/O 2PCI Configuration Space Format The 64-bit physical memory address (relative to the processor) of the register. 32bit platforms must have the high DWORD set to 0. The 64-bit I/O address (relative to the processor) of the register. 32-bit platforms must have the high DWORD set to 0. PCI Configuration space addresses must be confined to devices on PCI bus 0 segment 0. The format of addresses are defined as follows: WORD Location Highest WORD Lowest WORD Description Reserved (must be 0) PCI Device number on bus 0 PCI Function number Offset in the configuration space header
For example: Offset 23h of Function 2 on device 7 on bus 0 segment 0 would be represented as: 0x0000000700020023. 0x7F Functional Fixed Hardware All other fields in the GAS must be zero.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The OS loader for an ACPI 2.0-compatible OS will search for an RSDP structure pointer using the ACPI 2.0 GUID first and if it finds one, will use the corresponding RSDP structure pointer. If the GUID is not found then the OS loader will search for the RSDP structure pointer using the ACPI 1.0 GUID. The OS loader must retrieve the pointer to the RSDP structure from the EFI System Table before assuming platform control via the EFI ExitBootServices interface. See the EFI specification for more information.
Description RSD PTR (Notice that this signature must contain a trailing blank character.) This is the checksum of the fields defined in the ACPI 1.0 specification. This includes only the first 20 bytes of this table, bytes 0 to 19, including the checksum field. These bytes must sum to zero. An OEM -supplied string that identifies the OEM. The revision of this structure. Larger revision numbers are backward compatible to lower revision numbers. The ACPI version 1.0 revision number of this table is zero. The ACPI 2.0 value for this field is 2. 32 bit physical address of the RSDT. The length of the table, in bytes, including the header, starting from offset 0. This field is used to record the size of the entire table. 64 bit physical address of the XSDT. This is a checksum of the entire table, including both checksum fields. Reserved field
OEMID Revision
6 1
9 15
RsdtAddress Length
4 4
16 20
8 1 3
24 32 33
Compaq/Intel/Microsoft/Phoenix/Toshiba
Field Signature
Description The ASCII string representation of the table identifier. Notice that if OSPM finds a signature in a table that is not listed in Table 5-5, OSPM ignores the entire table (it is not loaded into ACPI namespace); OSPM ignores the table even though the values in the Length and Checksum fields are correct. The length of the table, in bytes, including the header, starting from offset 0. This field is used to record the size of the entire table. The revision of the structure corresponding to the signature field for this table. Larger revision numbers are backward compatible to lower revision numbers with the same signature. The entire table, including the checksum field, must add to zero to be considered valid. An OEM -supplied string that identifies the OEM. An OEM -supplied string that the OEM uses to identify the particular data table. This field is particularly useful when defining a definition block to distinguish definition block functions. The OEM assigns each dissimilar table a new OEM Table ID. An OEM -supplied revision number. Larger numbers are assumed to be newer revisions. Vendor ID of utility that created the table. For tables containing Definition Blocks, this is the ID for the ASL Compiler. Revision of utility that created the table. For tables containing Definition Blocks, this is the revision for the ASL Compiler.
Length
Revision
1 6 8
9 10 16
4 4 4
24 28 32
For OEMs, good design practices will ensure consistency when assigning OEMID and OEM Table ID fields in any table. The intent of these fields is to allow for a binary control system that support services can use. Because many support functions can be automated, it is useful when a tool can programmatically determine which table release is a compatible and more recent revision of a prior table on the same OEMID and OEM Table ID. Table 5-5 contains the system description table signatures defined by this specification. These system description tables may be defined by ACPI or reserved by ACPI and declared by other industry specifications. This allows OS and platform specific tables to be defined and pointed to by the RSDT/XSDT as needed. For tables defined by other industry specifications, the ACPI specification acts as gatekeeper to avoid collisions in table signatures. Table signatures will be reserved by the ACPI promoters and posted independently of this specification on the ACPI Web site between specification revisions with the goal of avoiding collisions.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-5 DESCRIPTION_HEADER Signatures Signature APIC BOOT Description Multiple APIC Description Table Simple Boot Flag Table Reference Section 5.2.10.4, Multiple APIC Description Table Microsoft Simple Boot Flag Specification http://www.microsoft.com/HWDEV/ desinit/simp_bios.htm Microsoft Debug Port Specification http://www.microsoft.com/hwdev/ newPC/debugspec.htm Section 5.2.10.1, Differentiated System Description Table Section 5.2.13, Embedded Controller Boot Resources Table IA-PC Multimedia Timers Specification http://developer.intel.com/ial/home/sp/ Section 5.2.8, Fixed ACPI Description Table Section 5.2.9, Firmware ACPI Control Structure OEM Specific tables. All table signatures starting with OEM are reserved for OEM use. Section 5.2.10.3, Persistent System Description Table Section 5.2.6, Root System Description Table Section 5.2 12, Smart Battery Table http://devresource.hp.com/devresource/Docs/ TechPapers/IA64/slit.pdf Microsoft Serial Port Console Redirection Table http://www.microsoft.com/hwdev/ download/SerialPortRedir.zip Interim processor-memory proximity table Section 5.2.10.2, Secondary System Description Table http://devresource.hp.com/devresource/Docs/ TechPapers/IA64/hpspmi.pdf Section 5.2.7, Extended System Description Table
DBGP
Differentiated System Description Table Embedded Controller Boot Resources Table Event Timer Description Table Fixed ACPI Description Table (FADT) Firmware ACPI Control Structure OEM Specific Information Tables
Persistent System Description Table Root System Description Table Smart Battery Specification Table System Locality Information Table Serial Port Console Redirection Table
Static Resource Affinity Table Secondary System Description Table Server Platform Management Interface Table Extended System Description Table
Compaq/Intel/Microsoft/Phoenix/Toshiba
Creator Revision
32
Entry
4* n
36
Compaq/Intel/Microsoft/Phoenix/Toshiba
Field Header Signature Length Revision Checksum OEMID OEM Table ID OEM Revision Creator ID
Description
4 4 1 1 6 8 4 4
0 4 8 9 10 16 24 28
XSDT. Signature for the Extended System Description Table. Length, in bytes, of the entire table. The length implies the number of Entry fields (n ) at the end of the table. 1 Entire table must sum to zero. OEM ID For the RSDTle, the table ID is the manufacture model ID. This field must match the OEM Table ID in the FADT. OEM revision of RSDT table for supplied OEM Table ID. Vendor ID of utility that created the table. For tables containing Definition Blocks, this is the ID for the ASL Compiler. Revision of utility that created the table. For tables containing Definition Blocks, this is the revision for the ASL Compiler. An array of 64-bit physical addresses that point to other DESCRIPTION_HEADERs. OSPM assumes at least the DESCRIPTION_HEADER is addressable, and then can further address the table based upon its Length field.
Creator Revision
32
Entry
8* n
36
Compaq/Intel/Microsoft/Phoenix/Toshiba
Creator Revision
32
FIRMWARE_CTRL
36
DSDT Reserved
4 1
40 44
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 1 Byte Offset 45
Field Preferred_PM_Profile
Description This field is set by the OEM to convey the preferred power management profile to OSPM. OSPM can use this field to set default power management policy parameters during OS installation. Field Values: 0Unspecified 1Desktop 2Mobile 3Workstation 4Enterprise Server 5SOHO Server 6Appliance PC >6 Reserved
SCI_INT
46
System vector the SCI interrupt is wired to in 8259 mode. OSPM is required to treat the ACPI SCI interrupt as a sharable, level, active low interrupt. System port address of the SMI Command Port. During ACPI OS initialization, OSPM can determine that the ACPI hardware registers are owned by SMI (by way of the SCI_EN bit), in which case the ACPI OS issues the ACPI_ENABLE command to the SMI_CMD port. The SCI_EN bit effectively tracks the ownership of the ACPI hardware registers. OSPM issues commands to the SMI_CMD port synchronously from the boot processor. This field is reserved and must be zero on system that does not support System Management mode. The value to write to SMI_CMD to disable SMI ownership of the ACPI hardware registers. The last action SMI does to relinquish ownership is to set the SCI_EN bit. During the OS initialization process, OSPM will synchronously wait for the transfer of SMI ownership to complete, so the ACPI system releases SMI ownership as quickly as possible. This field is reserved and must be zero on systems that do not support Legacy Mode.
SMI_CMD
48
ACPI_ENABLE
52
Compaq/Intel/Microsoft/Phoenix/Toshiba
98 Advanced Configuration and Power Interface Specification Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 1 Byte Offset 53
Field ACPI_DISABLE
Description The value to write to SMI_CMD to re-enable SMI ownership of the ACPI hardware registers. This can only be done when ownership was originally acquired from SMI by OSPM using ACPI_ENABLE. An OS can hand ownership back to SMI by relinquishing use to the ACPI hardware registers, masking off all SCI interrupts, clearing the SCI_EN bit and then writing ACPI_DISABLE to the SMI_CMD port from the boot processor. This field is reserved and must be zero on systems that do not support Legacy Mode. The value to write to SMI_ CMD to enter the S4BIOS state. The S4BIOS state provides an alternate way to enter the S4 state where the firmware saves and restores the memory context. A value of zero in S4BIOS_F indicates S4BIOS_REQ is not supported. (See Table 5-12.) The value OSPM writes to the SMI_CMD register to assume processor performance state control responsibility. System port address of the PM1a Event Register Block. See section 4.7.3.1, PM1 Event Grouping, for a hardware description layout of this register block. This is a required field. This field is superseded in ACPI 2.0 by the X_PM1a_EVT_BLK field. System port address of the PM1b Event Register Block. See section 4.7.3.1, PM1 Event Grouping, for a hardware description layout of this register block. This field is optional; if this register block is not supported, this field contains zero. This field is superseded in ACPI 2.0 by the X_PM1b_EVT_BLK field. System port address of the PM1a Control Register Block. See section 4.7.3.2, PM1 Control Grouping, for a hardware description layout of this register block. This is a required field. This field is superseded in ACPI 2.0 by the X_PM1a_CNT_BLK field. System port address of the PM1b Control Register Block. See section 4.7.3.2, PM1 Control Grouping, for a hardware description layout of this register block. This field is optional; if this register block is not supported, this field contains zero. This field is superseded in ACPI 2.0 by the X_PM1b_CNT_BLK field. System port address of the PM2 Control Register Block. See section 4.7.3.4, PM2 Control (PM2_CNT), for a hardware description layout of this register block. This field is optional; if this register block is not supported, this field contains zero. This field is superseded in ACPI 2.0 by the X_PM2_CNT_BLK field.
S4BIOS_REQ
54
PSTATE_CNT PM1a_EVT_BLK
1 4
55 56
PM1b_EVT_BLK
60
PM1a_CNT_BLK
64
PM1b_CNT_BLK
68
PM2_CNT_BLK
72
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 4 Byte Offset 76
Field PM_TMR_BLK
Description System port address of the Power Management Timer Control Register Block. See section 4.7.3.3, Power Management Timer (PM_TMR), for a hardware description layout of this register block. This is a required field. This field is superseded in ACPI 2.0 by the X_PM_TMR_BLK field. System port address of General-Purpose Event 0 Register Block. See section 5.2.8, Fixed ACPI Description Table, for a hardware description of this register block. This is an optional field; if this register block is not supported, this field contains zero. This field is superseded in ACPI 2.0 by the X_GPE0_BLK field. System port address of General-Purpose Event 1 Register Block. See section 5.2.8, Fixed ACPI Description Table, for a hardware description of this register block. This is an optional field; if this register block is not supported, this field contains zero. This field is superseded in ACPI 2.0 by the X_GPE1_BLK field. Number of bytes decoded by PM1a_EVT_BLK and, if supported, PM1b_ EVT_BLK. This value is 4. Number of bytes decoded by PM1a_CNT_BLK and, if supported, PM1b_CNT_BLK. This value is 1. Number of bytes decoded by PM2_CNT_BLK. Support for the PM2 register block is optional. If supported, this value is 1. If not supported, this field contains zero. Number of bytes decoded by PM_TMR_BLK. This fields value must be 4. Number of bytes decoded by GPE0_BLK. The value is a non-negative multiple of 2. Number of bytes decoded by GPE1_BLK. The value is a non-negative multiple of 2. Offset within the ACPI general-purpose event model where GPE1 based events start. The value OSPM writes to the SMI_CMD register to indicate OS support for the _CST object and C States Changed notification. The worst-case hardware latency, in microseconds, to enter and exit a C2 state. A value > 100 indicates the system does not support a C2 state. The worst-case hardware latency, in microseconds, to enter and exit a C3 state. A value > 1000 indicates the system does not support a C3 state.
GPE0_BLK
80
GPE1_BLK
84
1 1 1
88 89 90
1 1 1 1 1
91 92 93 94 95
P_LVL2_LAT
96
P_LVL3_LAT
98
Compaq/Intel/Microsoft/Phoenix/Toshiba
100 Advanced Configuration and Power Interface Specification Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 2 Byte Offset 100
Field FLUSH_SIZE
Description If WBINVD=0, the value of this field is the number of flush strides that need to be read (using cacheable addresses) to completely flush dirty lines from any processors memory caches. Notice that the value in FLUSH_STRIDE is typically the smallest cache line width on any of the processors caches (for more information, see the FLUSH_STRIDE field definition). If the system does not support a method for flushing the processors caches, then FLUSH_SIZE and WBINVD are set to zero. Notice that this method of flushing the processor caches has limitations, and WBINVD=1 is the preferred way to flush the processors caches. This value is typically at least 2 times the cache size. The maximum allowed value for FLUSH_SIZE multiplied by FLUSH_STRIDE is 2 MB for a typical maximum supported cache size of 1 MB. Larger cache sizes are supported using WBINVD=1. This value is ignored if WBINVD=1. This field is maintained for ACPI 1.0 processor compatibility on existing systems. Processors in new ACPI 2.0-compatible systems are required to support the WBINVD function and indicate this to OSPM by setting the WBINVD field = 1.
FLUSH_STRIDE
102
If WBINVD=0, the value of this field is the cache line width, in bytes, of the processors memory caches. This value is typically the smallest cache line width on any of the processors caches. For more information, see the description of the FLUSH_SIZE field. This value is ignored if WBINVD=1. This field is maintained for ACPI 1.0 processor compatibility on existing systems. Processors in new ACPI 2.0-compatible systems are required to support the WBINVD function and indicate this to OSPM by setting the WBINVD field = 1.
DUTY_OFFSET
104
The zero-based index of where the processors duty cycle setting is within the processors P_CNT register.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 1 Byte Offset 105
Field DUTY_WIDTH
Description The bit width of the processors duty cycle setting value in the P_CNT register. Each processors duty cycle setting allows the software to select a nominal processor frequency below its absolute frequency as defined by: THTL_EN = 1 BF * DC/(2DUTY_WIDTH ) Where: BF Base frequency DCDuty cycle setting When THTL_EN is 0, the processor runs at its absolute BF. A DUTY_WIDTH value of 0 indicates that processor duty cycle is not supported and the processor continuously runs at its base frequency.
DAY_ALRM
106
The RTC CMOS RAM index to the day-of-month alarm value. If this field contains a zero, then the RTC day of the month alarm feature is not supported. If this field has a nonzero value, then this field contains an index into RTC RAM space that OSPM can use to program the day of the month alarm. See section 4.7.2.4, Real Time Clock Alarm, for a description of how the hardware works. The RTC CMOS RAM index to the month of year alarm value. If this field contains a zero, then the RTC month of the year alarm feature is not supported. If this field has a non-zero value, then this field contains an index into RTC RAM space that OSPM can use to program the month of the year alarm. If this feature is supported, then the DAY_ALRM feature must be supported also. The RTC CMOS RAM index to the century of data value (hundred and thousand year decimals). If this field contains a zero, then the RTC centenary feature is not supported. If this field has a non-zero value, then this field contains an index into RTC RAM space that OSPM can use to program the centenary field. IA-PC Boot Architecture Flags. See Table 5-10 for a description of this field. Must be 0. Fixed feature flags. See Table 5-9 for a description of this field.
MON_ALRM
107
CENTURY
108
2 1 4
Compaq/Intel/Microsoft/Phoenix/Toshiba
102 Advanced Configuration and Power Interface Specification Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 12 Byte Offset 116
Field RESET_REG
Description The address of the reset register represented in Generic Address Structure format (See section 4.7.3.6, Reset Register, for a description of the reset mechanism.) Note : Only System I/O space, System Memory space and PCI Configuration space (bus #0) are valid for values for Address_Space_ID. Also, Register_Bit_Width must be 8 and Register_Bit_Offset must be 0.
RESET_VALUE
128
Indicates the value to write to the RESET_REG port to reset the system. (See section 4.7.3.6, Reset Register, for a description of the reset mechanism.) Must be 0. 64bit physical address of the FACS. 64bit physical address of the DSDT. Extended address of the PM1a Event Register Block, represented in Generic Address Structure format. See section 4.7.3.1, PM1 Event Grouping, for a hardware description layout of this register block. This is a required field. Extended address of the PM1b Event Register Block, represented in Generic Address Structure format. See section 4.7.3.1, PM1 Event Grouping, for a hardware description layout of this register block. This field is optional; if this register block is not supported, this field contains zero. Extended address of the PM1a Control Register Block, represented in Generic Address Structure format. See section 4.7.3.2, PM1 Control Grouping, for a hardware description layout of this register block. This is a required fie ld. Extended address of the PM1b Control Register Block, represented in Generic Address Structure format. See section 4.7.3.2, PM1 Control Grouping, for a hardware description layout of this register block. This field is optional; if this register block is not supported, this field contains zero. Extended address of the Power Management 2 Control Register Block, represented in Generic Address Structure format. See section 4.7.3.4, PM2 Control (PM2_CNT), for a hardware description layout of this register block. This field is optional; if this register block is not supported, this field contains zero.
3 8 8 12
X_PM1b_EVT_BLK
12
160
X_PM1a_CNT_BLK
12
172
X_PM1b_CNT_BLK
12
184
X_PM2_CNT_BLK
12
196
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-8 Fixed ACPI Description Table (FADT) Format (continued) Byte Length 12 Byte Offset 208
Field X_PM_TMR_BLK
Description Extended address of the Power Management Timer Control Register Block, represented in Generic Address Structure format. See section 4.7.3.3, Power Management Timer (PM_TMR), for a hardware description layout of this register block. This is a required field. Extended address of the General-Purpose Event 0 Register Block, represented in Generic Address Structure format. See section 5.2.8, Fixed ACPI Description Table, for a hardware description of this register block. This is an optional field; if this register block is not supported, this field contains zero. Extended address of the General-Purpose Event 1 Register Block, represented in Generic Address Structure format. See section 5.2.8, Fixed ACPI Description Table, for a hardware description of this register block. This is an optional field; if this register block is not supported, this field contains zero.
X_GPE0_BLK
12
220
X_GPE1_BLK
12
232
Table 5-9 Fixed ACPI Description Table Fixed Feature Flags FACP - Flag WBINVD Bit length 1 Bit offset 0 Description Processor properly implements a functional equivalent to the WBINVD IA-32 instruction. If set, signifies that the WBINVD instruction correctly flushes the processor caches, maintains memory coherency, and upon completion of the instruction, all caches for the current processor contain no cached data other than what OSPM references and allows to be cached. If this flag is not set, the ACPI OS is responsible for disabling all ACPI features that need this function. This field is maintained for ACPI 1.0 processor compatibility on existing systems. Processors in new ACPI 2.0-compatible systems are required to support this function and indicate this to OSPM by setting this field. WBINVD_FLUSH 1 1 If set, indicates that the hardware flushes all caches on the WBINVD instruction and maintains memory coherency, but does not guarantee the caches are invalidated. This provides the complete semantics of the WBINVD instruction, and provides enough to support the system sleeping states. If neither of the WBINVD flags is set, the system will require FLUSH_SIZE and FLUSH_STRIDE to support sleeping states. If the FLUSH parameters are also not supported, the machine cannot support sleeping states S1, S2, or S3.
Compaq/Intel/Microsoft/Phoenix/Toshiba
104 Advanced Configuration and Power Interface Specification Table 5-9 Fixed ACPI Description Table Fixed Feature Flags (continued) Bit length 1 1 Bit offset 2 3
Description A one indicates that the C1 power state is supported on all processors. A zero indicates that the C2 power state is configured to only work on a uniprocessor (UP) system. A one indicates that the C2 power state is configured to work on a UP or multiprocessor (MP) system. A zero indicates the power button is handled as a fixed feature programming model; a one indicates the power button is handled as a control method device. If the system does not have a power button, this value would be 1 and no sleep button device would be present. A zero indicates the sleep button is handled as a fixed feature programming model; a one indicates the sleep button is handled as a control method device. If the system does not have a sleep button, this value would be 1 and no sleep button device would be present.
PWR_BUTTON
SLP_BUTTON
FIX_RTC
A zero indicates the RTC wake status is supported in fixed register space; a one indicates the RTC wake status is not supported in fixed register space. Indicates whether the RTC alarm function can wake the system from the S4 state. The RTC must be able to wake the system from an S1, S2, or S3 sleep state. The RTC alarm can optionally support waking the system from the S4 state, as indicated by this value. A zero indicates TMR_VAL is implemented as a 24-bit value. A one indicates TMR_VAL is implemented as a 32bit value. The TMR_STS bit is set when the most significant bit of the TMR_VAL toggles. A zero indicates that the system cannot support docking. A one indicates that the system can support docking. Notice that this flag does not indicate whether or not a docking station is currently present; it only indicates that the system is capable of docking. If set, indicates the system supports system reset via the FADT RESET_REG as described in section 4.7. 3.6, Reset Register. System Type Attribute. If set indicates that the system has no internal expansion capabilities and the case is sealed. System Type Attribute. If set indicates the system does not have local video capabilities or local input devices. If set, indicates to OSPM that a processor native instruction must be executed after writing the SLP_TYPx register.
RTC_S4
TMR_VAL_EXT
DCK_CAP
RESET_REG_SUP
10
1 1 1 18
11 12 13 14
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
106 Advanced Configuration and Power Interface Specification Table 5-10 Fixed ACPI Description Table Boot Architecture Flags BOOT_ARCH LEGACY_DEVICES Bit length 1 Bit offset 0 Description If set, indicates that the motherboard supports user-visible devices on the LPC or ISA bus. User-visible devices are devices that have end-user accessible connectors (for example, LPT port), or devices for which the OS must load a device driver so that an end-user application can use a device. If clear, the OS may assume there are no such devices and that all devices in the system can be detected exclusively via industry standard device enumeration mechanisms (including the ACPI namespace). If set, indicates that the motherboard contains support for a port 60 and 64 based keyboard controller, usually implemented as an 8042 or equivalent micro-controller. Must be 0.
8042
Reserved
14
Description FACS Length, in bytes, of the entire Firmware ACPI Control Structure. This value is 64 bytes or larger. The value of the systems hardware signature at last boot. This value is calculated by the BIOS on a best effort basis to indicate the base hardware configuration of the system such that different base hardware configurations can have different hardware signature values. OSPM uses this information in waking from an S4 state, by comparing the current hardware signature to the signature values saved in the non-volatile sleep image. If the values are not the same, OSPM assumes that the saved non-volatile image is from a different hardware configuration and cannot be restored.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-11 Firmware ACPI Control Structure (FACS) (continued) Byte Length 4 Byte Offset 12
Description The 32-bit address field into which the ACPI OS puts its waking vector. Before transitioning the system into a global sleeping state, OSPM fills in this vector with the physical memory address of an OS-specific wake function. During POST, the BIOS checks this value and if it is non-zero, transfers control to the specified address. On PCs, the wake function address is in memory below 1 MB and the control is transferred wh ile in real mode. OSPMs wake function restores the processors context. For IA-PC platforms, the following example shows the relationship between the physical address in the Firmware Waking Vector and the real mode address the BIOS jumps to. If, for examp le, the physical address is 0x12345, then the BIOS must jump to real mode address 0x1234:0x0005. In general this relationship is Real-mode address = Physical address>>4 : Physical address and 0x000F Notice that on IA-PC platforms, A20 must be enabled when the BIOS jumps to the real mode address derived from the physical address stored in the Firmware Waking Vector. This field is superseded in ACPI 2.0 by the X_Firmware_Waking_Vector field.
Global_Lock
16
This field contains the Global Lock used to synchronize access to shared hardware resources between the OSPM environment and an external controller environment (for example, the SMI environment). This lock is owned exclusively by either OSPM or the firmware at any one time. When ownership of the lock is attempted, it might be busy, in which case the requesting environment exits and waits for the signal that the lock has been released. For example, the Global Lock can be used to protect an embedded controller interface such that only OSPM or the firmware will access the embedded controller interface at any one time. See section 5.2.9.1, Global Lock, for more information on acquiring and releasing the Global Lock. Firmware control structure flags. See Table 5-12 for a description of this field. 64bit physical address of the Firmware Waking Vector. 1 Version of this table This value is zero.
4 8 1 31
20 24 32 33
Compaq/Intel/Microsoft/Phoenix/Toshiba
108 Advanced Configuration and Power Interface Specification Table 5-12 Firmware Control Structure Feature Flags FACS - Flag S4BIOS_F Bit Length 1 Bit Offset 0 Description Indicates whether the platform supports S4BIOS_REQ. If S4BIOS_REQ is not supported, OSPM must be able to save and restore the memory state in order to use the S4 state. The value is zero.
Reserved
31
The following code sequence is used by both OSPM and the firmware to acquire ownership of the Global Lock. If non-zero is returned by the function, the caller has been granted ownership of the Global Lock and can proceed. If zero is returned by the function, the caller has not been granted ownership of the Global Lock, the pending bit has been set, and the caller must wait until it is signaled by an interrupt event that the lock is available before attempting to acquire access again.
AcquireGlobalLock: mov ecx, GlobalLock acq10: mov eax, [ecx] mov and bts adc edx, edx, edx, edx, eax not 1 1 0 ; ecx = address of Global Lock ; Value to compare against ; Clear pending bit ; Check and set owner bit ; if owned, set pending bit
; Attempt to set new value lock cmpxchg dword ptr[ecx], edx jnz short acq10 ; If not set, try again cmp sbb ret dl, 3 eax, eax ; Was it acquired or marked pending? ; acquired = -1, pending = 0
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following code sequence is used by OSPM and the firmware to release ownership of the Global Lock. If non-zero is returned, the caller must raise the appropriate event to the other environment to signal that the Global Lock is now free. Depending on the environment, this signaling is done by setting the either the GBL_RLS or BIOS_RLS within their respective hardware register spaces. This signal only occurs when the other environment attempted to acquire ownership while the lock was owned.
ReleaseGlobalLock: mov ecx, GlobalLock rel10: mov eax, [ecx] mov and edx, eax edx, not 03h ; ecx = address of Global Lock ; Value to compare against ; clear owner and pending field
; Attempt to set it lock cmpxchg dword ptr[ecx], edx jnz short rel10 ; If not set, try again and eax, 1 ; Was pending set?
; If one is returned (we were pending) the caller must signal that the ; lock has been released using either GBL_RLS or BIOS_RLS as appropriate ret
Although using the Global Lock allows various hardware resources to be shared, it is important to notice that its usage when there is ownership contention could entail a significant amount of system overhead as well as waits of an indeterminate amount of time to acquire ownership of the Global Lock. For this reason, implementations should try to design the hardware to keep the required usage of the Global Lock to a minimum. The Global Lock is required when a logical register in the hardware is shared. For example, if bit 0 is used by ACPI (OSPM) and bit 1 of the same register is used by SMI, then access to that register needs to be protected under the Global Lock, ensuring that the registers contents do not change from underneath one environment while the other is making changes to it. Similarly if the entire register is shared, as the case might be for the embedded controller interface, access to the register needs to be protected under the Global Lock.
Compaq/Intel/Microsoft/Phoenix/Toshiba
110 Advanced Configuration and Power Interface Specification Some AML operators perform simple functions, and others encompass complex functions. The power of the Definition block comes from its ability to allow these operations to be glued together in numerous ways, to provide functionality to OSPM. The AML operators defined in this specification are intended to allow many useful hardware designs to be easily expressed, not to allow all hardware designs to be expressed.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-14 Multiple APIC Description Table (MADT) Format Field Header Signature Length Revision Checksum OEMID OEM Table ID OEM Revision Creator ID 4 4 1 1 6 8 4 4 0 4 8 9 10 16 24 28 APIC. Signature for the Multiple APIC Description Table. Length, in bytes, of the entire MADT. 1 Entire table must sum to zero. OEM ID For the MADT, the table ID is the manufacturer model ID. OEM revision of MADTfo r supplied OEM Table ID. Vendor ID of utility that created the table. For tables containing Definition Blocks, this is the ID for the ASL Compiler. Revision of utility that created the table. For tables containing Definition Blocks, this is the revision for the ASL Compiler. The 32-bit physical address at which each processor can access its local APIC. Multiple APIC flags. See Table 5-15 for a description of this field. A list of APIC structures for this implementation. This list will contain all of the I/O APIC, I/O SAPIC, Local APIC, Local SAPIC, Interrupt Source Override, Non-maskable Interrupt Source, Local APIC NMI Source, Local APIC Address Override, and Platform Interrupt Sources structures needed to support this platform. These structures are described in the following sections. Byte Length Byte Offset Description
Creator Revision
32
4 4
36 40 44
Description A one indicates that the system also has a PC-ATcompatible dual-8259 setup. The 8259 vectors must be disabled (that is, masked) when enabling the ACPI APIC operation. This value is zero.
Reserved
31
Immediately after the Flags value in the MADTis a list of APIC structures that declare the APIC features of the machine. The first byte of each structure declares the type of that structure and the second byte declares the length of that structure.
Compaq/Intel/Microsoft/Phoenix/Toshiba
112 Advanced Configuration and Power Interface Specification Table 5-16 APIC Structure Types Value 0 1 2 3 4 5 6 7 8 >8 Description Processor Local APIC I/O APIC Interrupt Source Override Non-maskable Interrupt Source (NMI) Local APIC NMI Structure Local APIC Address Override Structure I/O SAPIC Local SAPIC Platform Interrupt Sources Reserved. OSPM skips structures of the reserved type.
APIC ID Flags
1 4
3 4
Description If zero, this processor is unusable, and the operating system support will not attempt to use it. Must be zero.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
114 Advanced Configuration and Power Interface Specification For example, if your machine has the ISA Programmable Interrupt Timer (PIT) connected to ISA IRQ 0, but in APIC mode, it is connected to I/O APIC interrupt input 2, then you would need an Interrupt Source Override where the source entry is 0 and the Global System Interrupt is 2. Table 5-20 Interrupt Source Override Structure Field Type Length Bus Source Global System Interrupt Flags Byte Length 1 1 1 1 4 2 Byte Offset 0 1 2 3 4 8 Description 2Interrupt Source Override 10 0Constant, meaning ISA Bus-relative interrupt source (IRQ) The Global System Interrupt that this bus-relative interrupt source will signal. MPS INTI flags. See Table 5-21 for a description of this field.
The MPS INTI flags listed in Table 5-21 are identical to the flags used in Table 4-10 of the MPS version 1.4 specifications. The Polarity flags are the PO bits and the Trigger Mode flags are the EL bits. Table 5-21 MPS INTI Flags Bit Length 2 Bit Offset 0
Description Polarity of the APIC I/O input signals: 00 Conforms to the specifications of the bus (For example, EISA is active-low for level-triggered interrupts) 01Active high 10 Reserved 11Active low
Trigger Mode
Trigger mode of the APIC I/O Input signals: 00 Conforms to specifications of the bus (For example, ISA is edge-triggered) 01 Edge-triggered 10 Reserved 11 Level-triggered
Reserved
12
Must be zero.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Interrupt Source Overrides are also necessary when an identity mapped interrupt input has a non-standard polarity. Note: You must have an interrupt source override entry for the IRQ mapped to the SCI interrupt if this IRQ is not identity mapped. This entry will override the value in SCI_INT in FADT. For example, if SCI is connected to IRQ 9 in PIC mode and IRQ 9 is connected to INTIN11 in APIC mode, you should have 9 in SCI_INT in the FADT and an interrupt source override entry mapping IRQ 9 to INTIN11.
2 1
3 5
Compaq/Intel/Microsoft/Phoenix/Toshiba
Field Type Length I/O APIC ID Reserved Global System Interrupt Base I/O SAPIC Address
Description 6I/O SAPIC Structure 20 I/O SAPIC ID Reserved (must be zero) Global System Interrupt Base Physical address for I/O SAPIC
If defined, OSPM must use the information contained in the I/O SAPIC structure instead of the information from the I/O APIC structure.
Compaq/Intel/Microsoft/Phoenix/Toshiba
If both I/O APIC and an I/O SAPIC structures exist in an MADT, the OEM/BIOS writer must prevent mixing I/O APIC and I/O SAPIC addresses. This is done by ensuring that there are at least as many I/O SAPIC structures as I/O APIC structures and that every I/O APIC structure has a corresponding I/O SAPIC structure (same APIC ID).
Flags
1 1
6 7
Compaq/Intel/Microsoft/Phoenix/Toshiba
118 Advanced Configuration and Power Interface Specification If a platform can generate an interrupt after correcting platform errors (e.g., single bit error correction), the interrupt input line used to signal such corrected errors is specified by the Global System Interrupt field in the following table. The firmware indicates the processor that can retrieve the corrected platform error information through the Processor ID and EID fields in the structure below. In some systems, retrieval of the error information may not be possible from other processors. OSPM is required to program the I/O SAPIC redirection table entries with the Processor ID, EID values specified by the ACPI system firmware. Refer to the IA-64 System Abstraction Layer (SAL) Specification for details on handling the Corrected Platform Error Interrupt. Table 5-27 Platform Interrupt Sources Structure Field Type Length Flags Interrupt Type Byte Length 1 1 2 1 Byte Offset 0 1 2 4 Description 8Platform Interrupt Source structure 16 MPS INTI flags. See Table 5-21 for a description of this field. 1PMI 2INIT 3Corrected Platform Error Interrupt All other values are reserved. Processor ID Processor EID I/O SAPIC Vector 1 1 1 5 6 7 Processor ID of destination. Processor EID of destination. Value that OSPM must use to program the vector field of the I/O SAPIC redirection table entry for entries with the PMI interrupt type. The Global System Interrupt that this platform interrupt will signal. Reserved, must be zero.
4 4
8 12
Compaq/Intel/Microsoft/Phoenix/Toshiba
24 input IOAPIC
0 . . . 23 24 . . . 39 40 . 51 . 55
INTI_0
INTI_23 INTI_0
16 input IOAPIC
24
24 input IOAPIC
40
Compaq/Intel/Microsoft/Phoenix/Toshiba
120 Advanced Configuration and Power Interface Specification There is exactly one I/O APIC structure per I/O APIC in the system.
Global System Interrupt Vector (ie ACPI PnP IRQ# ) 0 Master 8259 7 Slave 8259 8
15
Figure 5-4 8259Global System Interrupts The other interrupt model is the standard AT style mentioned above which uses ISA IRQs attached to a master slave pair of 8259 PICs. The system vectors correspond to the ISA IRQs. The ISA IRQs and their mappings to the 8259 pair are part of the AT standard and are well defined. This mapping is depicted in Figure 5-4.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-28 Smart Battery Description Table (SBST) Format Field Header Signature Length Revision Checksum OEMID OEM Table ID OEM Revision Creator ID 4 4 1 1 6 8 4 4 0 4 8 9 10 16 24 28 SBST. Signature for the Smart Battery Description Table (SBST). Length, in bytes, of the entire SBST 1 Entire table must sum to zero. OEM ID For the SBST, the table ID is the manufacturer model ID. OEM revision of SBST for supplied OEM Table ID. Vendor ID of utility that created the table. For tables containing Definition Blocks, this is the ID for the ASL Compiler. Revision of utility that created the table. For tables containing Definition Blocks, this is the revision for the ASL Compiler. OEM suggested energy level in milliWatt-hours (mWh) at which OSPM warns the user. OEM suggested platform energy level in mWh at which OSPM will transition the system to a sleeping state. OEM suggested platform energy level in mWh at which OSPM performs an emergency shutdown. Byte Length Byte Offset Description
Creator Revision
32
4 4 4
36 40 44
Compaq/Intel/Microsoft/Phoenix/Toshiba
122 Advanced Configuration and Power Interface Specification Table 5-29 Embedded Controller Boot Resources Table Format Field Header Signature Length Revision Checksum OEMID OEM Table ID OEM Revision Creator ID 4 4 1 1 6 8 4 4 0 4 8 9 10 16 24 28 ECDT. Signature for the Embedded Controller Table. Length, in bytes, of the entire Embedded Controller Table 1 Entire table must sum to zero. OEM ID For the Embedded Controller Table, the table ID is the manufacturer model ID. OEM revision of Embedded Controller Table for supplied OEM Table ID. Vendor ID of utility that created the table. For tables containing Definition Blocks, this is the ID for the ASL Compiler. Revision of utility that created the table. For tables containing Definition Blocks, this is the revision for the ASL Compiler. Contains the processor relative address, represented in Generic Address Structure format, of the Embedded Controller Command/Status register. Note : Only System I/O space and System Memory space are valid for values for Address_Space_ID. Contains the processor-relative address, represented in Generic Address Structure format, of the Embedded Controller Data register. Note : Only System I/O space and System Memory space are valid for values for Address_Space_ID. Unique IDSame as the value returned by the _UID under the device in the namespace that represents this embedded controller. The bit assignment of the SCI interrupt within the GPEx_STS register of a GPE block described in the FADT that the embedded controller triggers. ASCII, null terminated, string that contains a fully qualified reference to the name space object that is this embedded controller device (for example, \_SB.PCI0.ISA.EC). Quotes are omitted in the data field. Byte Length Byte Offset Description
Creator Revision
32
EC_CONTROL
12
36
EC_DATA
12
48
UID
60
GPE_BIT
64
EC_ID
Variable
65
Compaq/Intel/Microsoft/Phoenix/Toshiba
ACPI 2.0 OSPM implementations supporting Embedded Controller devices must also support the ECDT. ACPI 1.0 OSPM implementation will not recognize or make use of the ECDT. The following example code shows how to detect whether the Embedded Controller operation regions are available in a manner that is backward compatible with prior versions of ACPI/OSPM.
Device(EC0) { Name(REGC,Ones) Method(_REG,2) { If(Lequal(Arg0, 3)) { Store(Arg1, REGC) } } Method(ECAV,0) { If(Lequal(REGC,Ones)) { If(LgreaterEqual(_REV,2)) { Return(One) } Else { Return(Zero) } } Return(REGC) } }
To detect the availability of the region, call the ECAV method. For example:
If (\_SB.PCI0.EC0.ECAV()) { ...regions are available... } else { ...regions are not available... }
For the most part, since the name space is hierarchical, typically the bulk of a dynamic definition file will load into a different part of the hierarchy. In the root of the name space, and certain locations where interaction is being designed, will be the areas which extra care must be taken.
Compaq/Intel/Microsoft/Phoenix/Toshiba
124 Advanced Configuration and Power Interface Specification Except for names preceded with a \, the current namespace determines where in the namespace hierarchy a name being created goes and where a name being referenced is found. A name is located by finding the matching name in the current namespace, and then in the parent namespace. If the parent namespace does not contain the name, the search continues recursively upwards until either the name is found or the namespace does not have a parent (the root of the namespace). This indicates that the name is not found7 . An attempt to access names in the parent of the root will result in the name not being found. There are two types of namespace paths: an absolute namespace path (that is, one that starts with a \ prefix), and a relative namespace path (that is, one that is relative to the current namespace). The namespace search rules discussed above, only apply to single NameSeg paths, which is a relative namespace path. For those relative name paths that contain multiple NameSegs or Parent Prefixes, ^, the search rules do not apply. If the search rules do not apply to a relative namespace path, the namespace object is looked up relative to the current namespace. For example: ABCD ^ABCD XYZ.ABCD \XYZ.ABCD //search rules apply //search rules dont apply //search rules dont apply //search rules dont apply
All name references use a 32-bit fixed-length name or use a Name Extension prefix to concatenate multiple 32-bit fixed-length name components together. This is useful for referring to the name of an object, such as a control method, that is not in the scope of the current namespace.
Unless the operation being performed is explicitly prepared for failure in name resolution, this is considered an error andthe system to stop working.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Figure 5-5 shows a sample of the ACPI namespace after a Differentiated Definition Block has been loaded.
Root \_PR P R \PID0 _STA _ON _OFF \_SB d PCI0 _HID _CRS d IDE0 _ADR _PR0 \_GPE _L01 _E02 _L03 CPU0 Processor Tree Processor 0 object Power resource for IDE0 Method to return status of power resourse Method to turn on power resourse Method to turn off power resourse System bus tree PCI bus Device ID Current resources (PCI bus number) IDE0 device PCI device #, function # Power resource requirements for D0 General purpose events (GP_STS) Method to handle level GP_STS.1 Method to handle edge GP_STS.2 Method to handle level GP_STS.3 P R d
Key
Package Processor Object Power Resource Object Bus/Device Object Data Object Control Method (AML code)
Figure 5-5 Example ACPI NameSpace Care must be taken when accessing namespace objects using a relative single segment name because of the namespace search rules. An attempt to access a relative object recurses toward the root until the object is found or the root is encountered. This can cause unintentional results. For example, using the namespace described in Figure 5.5, attempting to access a _CRS named object from within the \_SB_.PCI0.IDE0 will have different results depending on if an absolute or relative path name is used. If an absolute pathname is specified (\_SB_.PCI0.IDE0._CRS) an error will result since the object does not exist. Access using a single segment name (_CRS) will actually access the \_SB_.PCI0._CRS object. Notice that the access will occur successfully with no errors.
Compaq/Intel/Microsoft/Phoenix/Toshiba
5.3.2 Objects
All objects, except locals, have a global scope. Local data objects have a per-invocation scope and lifetime and are used to process the current invocation from beginning to end. The contents of objects vary greatly. Nevertheless, most objects refer to data variables of any supported data type, a control method, or system software-provided functions.
Compaq/Intel/Microsoft/Phoenix/Toshiba
All encodings are such that the lead byte of an encoding signifies the type of declaration or reference being made. The type either has an implicit or explicit length in the stream. All explicit length declarations take the form shown below, where PkgLength is the length of the inclusive length of the data for the operation.
LeadByte ...
Encodings of implicit length objects either have fixed length encodings or allow for nested encodings that, at some point, either result in an explicit or implicit fixed length. The PkgLength is encoded as a series of 1 to 4 bytes in the stream with the most significant two bits of byte zero, indicating how many following bytes are in the PkgLength encoding. The next two bits are only used in one-byte encodings, which allows for one-byte encodings on a length up to 0x3F. Longer encodings, which do not use these two bits, have a maximum length of the following: two-byte encodings of 0x0FFF, three-byte encodings of 0x0FFFFF, and four-byte length encodings of 0x0FFFFFFFFF. It is fatal for a package length to not fall on a logical boundary. For example, if a package is contained in another package, then by definition its length must be contained within the outer package, and similarly for a datum of implicit length. At some point, the system software decides to load a Definition Block. Loading is accomplished when the system makes a pass over the data and populates the ACPI namespace and initializes objects accordingly. The namespace for which population occurs is either from the current namespace location, as defined by all nested packages or from the root if the name is preceded with \. The first object present in a Definition Block must be a named control method. This is the Definition Blocks initialization control. Packages are objects that contain an ordered reference to one or more objects. A package can also be considered a vertex of an array, and any object contained within a package can be another package. This permits multidimensional arrays of fixed or dynamic depths and vertices. Unnamed objects are used to populate the contents of named objects. Unnamed objects cannot be created in the root. Unnamed objects can be used as arguments in control methods. Control method execution may generate errors when creating objects. This can occur if a Method that creates named objects blocks and is reentered while blocked. This will happen because all named objects have an absolute path. This is true even if the object name specified is relative. For example, the following ASL code segments are functionally identical. Method (DEAD,) Scope (\_SB_.FOO) { Name (BAR,) // Run time definition } } Scope (\_SB_) {Name (\_SB_. FOO.BAR,) // Load time definition } Notice that in the above example the execution of the DEAD method will always fail because the object \_SB_.FOO.BAR is created at load time.
Compaq/Intel/Microsoft/Phoenix/Toshiba
FixedList refers to a list of known length that supplies data that all instances of a given ObjectType must have. It is written as (a, b, c,), where the number of arguments depends on the specific ObjectType, and some elements can be nested objects, that is (a, b, (q, r, s, t), d). Arguments to a FixedList can have default values, in which case they can be skipped. Some ObjectTypes can have a null FixedList. VariableList refers to a list, not of predetermined length, of child objects that help define the parent. It is written as {x, y, z, aa, bb, cc}, where any argument can be a nested object. ObjectType determines what terms are legal elements of the VariableList. Some ObjectTypes can have a null variable list. For a detailed specification of the ASL language, see section 16, ACPI Source Language Reference. For a detailed specification of the ACPI Control Method Machine Language (AML), upon which the output of the ASL translator is based, see section 17, ACPI Machine Language Specification.
Compaq/Intel/Microsoft/Phoenix/Toshiba
EISAID (Id )
ResourceTemplate ()
Unicode (string)
Compaq/Intel/Microsoft/Phoenix/Toshiba
The object \XYZ.BAR is a static object created when the table that contains the above ASL is loaded. The object \XYZ.FOO.BAR is a dynamic object that is created when the Name (BAR, 7) statement in the FOO method is executed. The object \XYZ.FOOB is a dynamic object created by the \XYZ.FOO method when the Name (\XYZ.FOOB, 3) statement is executed. Notice that the \XYZ.FOOB object is destroyed after the \XYZ.FOO method exits.
Compaq/Intel/Microsoft/Phoenix/Toshiba
FADT
SCI interrupt
Compaq/Intel/Microsoft/Phoenix/Toshiba
RTC alarm
Wake status
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-33 Fixed ACPI Events (continued) Event System bus master request Comment The bus-master status bit provides feedback from the hardware as to when a bus master cycle has occurred. This is necessary for supporting the processor C3 power savings state. For more information, see the description of the BM_STS bit of the PM1x fixed register block in section 4.7.3.1, PM1 Event Grouping. This status is raised as a result of the Global Lock protocol, and is handled by OSPM as part of Global Lock synchronization. For more information, see the description of the GBL_STS bit of the PM1x fixed register block in section 4.7.3.1, PM1 Event Grouping. For more information on Global Lock, see section 5.2.9.1, Global Lock.
Compaq/Intel/Microsoft/Phoenix/Toshiba
For example, suppose an OEM supplies a wake event for a communications port and uses bit 4 of the GPE0_STS bits to raise the wake event status. In an OEM -provided Definition Block, there must be a Method declaration that uses the name \_GPE._L04 or \ GPE._E04 to handle the event. An example of a control method declaration using such a name is the following:
Method (\_GPE._L04) { // GPE 4 level wake handler Notify (\_SB.PCIO.COM0, 2) }
The control method performs whatever action is appropriate for the event it handles. For example, if the event means that a device has appeared in a slot, the control method might acknowledge the event to some other hardware register and signal a change notify request of the appropriate device object. Or, the cause of the general-purpose event can result from more then one source, in which case the control method for that event determines the source and takes the appropriate action. When a general-purpose event is raised from the GPE bit tied to an embedded controller, the embedded controller driver uses another naming convention defined by ACPI for the embedded controller driver to determine which control method to queue for execution. The queries that the embedded controller driver exchanges with the embedded controller are numbered from 0 through FF, yielding event codes 01 through FF. (A query response of 0 from the embedded controller is reserved for no outstanding events.) The name of the control method to queue is always of the form _Qxx where xx is the number of the query acknowledged by the embedded controller. An example declaration for a control method that handles an embedded controller query is the following:
Method(_Q34) { // embedded controller event for thermal Notify (\_SB.TZ0.THM1, 0x80) }
Compaq/Intel/Microsoft/Phoenix/Toshiba
3 4
7 8-7F
Below are the notification values defined for specific ACPI devices. For more information concerning the object-specific notification, see the section on the corresponding device/object.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-35 Control Method Battery Device Notification Values Hex value 80 81 >81 Description Battery Status Changed. Used to notify OSPM that the Control Method Battery device status has changed. Battery Information Changed. Used to notify OSPM that the Control Method Battery device information has changed. This only occurs when a battery is replaced. Reserved. Table 5-36 Power Source Object Notification Values Hex value 80 >80 Description Power Source Status Changed. Used to notify OSPM that the power source status has changed. Reserved. Table 5-37 Thermal Zone Object Notification Values Hex value 80 81 82 >82 Description Thermal Zone Status Changed. Used to notify OSPM that the thermal zone temperature has changed. Thermal Zone Trip points Changed. Used to notify OSPM that the thermal zone trip points have changed. Device Lists Changed. Used to notify OSPM that the thermal zone device lists (_ALx, _PSL, _TZD) have changed. Reserved. Table 5-38 Control Method Power Button Notification Values Hex value 80 Description S0 Power Button Pressed. Used to notify OSPM that the power button has been pressed while the system is in the S0 state. Notice that when the button is pressed while the system is in the S1-S4 state, a Device Wake notification must be issued instead. Reserved. Table 5-39 Control Method Sleep Button Notification Values Hex value 80 Description S0 Sleep Button Pressed. Used to notify OSPM that the sleep button has been pressed while the system is in the S0 state. Notice that when the button is pressed while the system is in the S1-S4 state, a Device Wake notification must be issued instead. Reserved.
>80
>80
Compaq/Intel/Microsoft/Phoenix/Toshiba
138 Advanced Configuration and Power Interface Specification Table 5-40 Control Method Lid Notification Values Hex value 80 >80 Description Lid Status Changed. Used to notify OSPM that the control method lid device status has changed. Reserved. Table 5-41 Processor Device Notification Values Hex value 80 Description Performance Present Capabilities Changed. Used to notify OSPM that the number of supported processor performance states has changed. This notification causes OSPM to re-evaluate the _PPC object. See section 8, Processor Control, for more information. C States Changed. Used to notify OSPM that the number or type of supported processor C States has changed. This notification causes OSPM to re-evaluate the _CST object. See section 8, Processor Control, for more information. Reserved.
81
>81
PNP0A05
PNP0A06
PNP0C09 PNP0C0A
PNP0C0B
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-42 ACPI Device IDs (continued) Plug and Play ID PNP0C0C Description Power Button Device. A device controlled through an ACPI-aware driver that provides power button functionality. This device is only needed if the power button is not supported using the fixed register space. Lid Device. A device controlled through an ACPI-aware driver that provides lid status functionality. This device is only needed if the lid state is not supported using the fixed register space. Sleep Button Device. A device controlled through an ACPI-aware driver that provides power button functionality. This device is optional. PCI Interrupt Link Device. A device that allocates an interrupt connected to a PCI interrupt pin. See section 6., Configuration, for more details. Memory Device. This device is a memory subsystem. SMBus 1.0 Host Controller. An SMBus host controller (SMB-HC) compatible with the embedded controller-based SMB-HC interface (as specified in section 13.9, SMBus Host Controller Interface via Embedded Controller) and implementing the SMBus 1.0 Specification. Smart Battery Subsystem. The Smart battery Subsystem specified in section 11, Power Source Devices. AC Device. The AC adapter specified in section 11, Power Source Devices. Module Device. This device is a container object that acts as a bus node in a namespace. SMBus 2.0 Host Controller. An SMBus host controller (SMB-HC compatible with the embedded controller-based SMB-HC interface (as specified in section 13.9, SMBus Host Controller Interface via Embedded Controller) and implementing the SMBus 2.0 Specification. GPE Block Device. This device allows a system designer to describe GPE blocks beyond the two that are described in the FADT.
PNP0C0D
ACPI0006
Compaq/Intel/Microsoft/Phoenix/Toshiba
140 Advanced Configuration and Power Interface Specification Table 5-43 Defined Generic Object and Control Methods (continued) Object _BAS _BBN _BCL _BCM _BDN _BFS _BIF _BM _BST _BTP _CID _CRS _CRT _CST _DCK _DCS _DDC _DDN _DEC _DGS _DIS _DMA _DOD _DOS _DSS _Exx _EC _EDL _EJx Description Resource data type reserved field name PCI bus number setup by the BIOS Returns a buffer of bytes indicating list of brightness control levels supported. Sets the brightness level of the built -in display output device. Correlates a docking station between ACPI and legacy interfaces. Control method executed immediately following a wake event. Control Method Battery information object Resource data type reserved field name Control Method Battery status object Sets Control Method Battery trip point Device identification object that evaluates to a devices Plug and Play Compatible ID list. Device configuration object that specifies a devices current resource settings, or a control method that generates such an object. Thermal zone object that returns critical trip point in tenths of degrees Kelvin. Processor power state declaration object Indicates that the device is a docking station. Returns the status of the display output device. Returns the EDID for the display output device Object that associates a logical software name (for example, COM1) with a device. Resource data type reserved field name Control method used to query the state of the output device. Device configuration control method that disables a device. Object that specifies a devices current resources for DMA transactions. Control method used to enumerate devices attached to the display adapter. Control method used to enable/disable display output switching. Control method used to set display device state. Control method executed as a result of a general-purpose event. Control Method used to define the offset address and Query value of an SMB-HC defined within an embedded controller device. Device removal object that returns a packaged list of devices that are dependent on a device. Device insertion/removal control method that ejects a device. Reference 16.2.4 6.5.5 B.5.2 B.5.3 6.5.3 7.3.1 11.2.2.1 16.2.4 11.2.2.2 11.2.2.3 6.1.2 6.2.1 12.3.3 8.3.2 6.5.2 B.5.5 B.5.4 6.1.3 16.2.4 B.5.6 6.2.2 6.2.3 B.4.2 B.4.1 B.5.7 5.6.5.3 13.12 6.3.1 6.3.3
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-43 Defined Generic Object and Control Methods (continued) Object _EJD Description Device removal object that evaluates to the name of a device object upon which a device is dependent. Whenever the named device is ejected, the dependent device must receive an ejection notification. Object that indicates the presence or absence of floppy disks. Object that returns floppy drive information. Control method that changes the mode of floppy drives. Object used to provide correlation between the fixed hardware register blocks defined in the FADT and the devices that implement these fixed hardware registers. OS-defined Global Lock mutex object Indicates the need to acquire the Global Lock, must be acquired when accessing the device. Control method that returns which VGA device will be posted at boot 1. 2. General-Purpose Events root name space Object that returns the SCI interrupt within the GPx_STS register that is connected to the EC. Reference 6.3.2
5.7.1 6.5.7 B.4.4 5.3.4 13.11 16.2.4 10.8.1 10.8.2 7.3.3 16.2.4 6.1.4 6.2.5
Resource data type reserved field name. IDE device control method to get the Advanced Technology Attachement (ATA) task file needed to re-initialize the drive to bootup defaults. IDE device control method to get the IDE controller timing information. Control method executed just prior to setting the sleep enable (SLP_EN) bit. Resource data type reserved field name Device identification object that evaluates to a devices Plug and Play Hardware ID. An object that specifies the Cache-line size, Latency timer, SERR enable, and PERR enable values to be used when configuring a PCI device inserted into a hot-plug slot or initial configuration of a PCI device at system boot. Device initialization method that performs device specific initialization. Resource data type reserved field name Power management object that signifies the device has a significant inrush current draw. Control method executed as a result of a general-purpose event. Device insertion/removal control method that locks or unlocks a device. Resource data type reserved field name Object that returns the status of the Lid on a mobile system. Resource data type reserved field name
Compaq/Intel/Microsoft/Phoenix/Toshiba
142 Advanced Configuration and Power Interface Specification Table 5-43 Defined Generic Object and Control Methods (continued) Object _MAF _MAT _MAX _MEM _MIF _MIN _MSG _OFF _ON _OS _PCL _PCT _PIC _PPC _PR _PR0 _PR1 Description Resource data type reserved field name Object evaluates to a buffer of MADT APIC Structure entries. Resource data type reserved field name Resource data type reserved field name Resource data type reserved field name Resource data type reserved field name System indicator control that indicates messages are waiting. Power resource object that sets the resource off. Power resource object that sets the resource on. Object that evaluates to a string that identifies the operating system. Power source object that contains a list of devices powered by a power source. Processor performance control object Control method that conveys interrupt model in use to the system firmware. Control method used to determine number of performance states currently supported by the platform. ACPI 1.0 Processor Namespace Power management object that evaluates to the devices power requirements in the D0 device state (device fully on). Power management object that evaluates to the devices power requirements in the D1 device state. Only devices that can achieve the defined D1 device state according to its given device class would supply this level. Power management object that evaluates to the devices power requirements in the D2 device state. Only devices that can achieve the defined D2 device state according to its given device class would supply this level. Device configuration object that specifies a devices possible resource settings, or a control method that generates such an object. An object that specifies the PCI interrupt Routing Table. Power management object that evaluates to the devices power requirements in order to wake the system from a system sleeping state. Power management control method that puts the device in the D0 device state. (device fully on). Power management control method that puts the device in the D1 device state. Power management control method that puts the device in the D2 device state. Reference 16.2.4 6.2.6 16.2.4 16.2.4 16.2.4 16.2.4 10.1.2 7.1.2 7.1.3 5.7.2 11.3.2 8.3.3.1 5.8.1 8.3.3.3 5.3.1 7.2.6 7.2.7
_PR2
7.2.8
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 5-43 Defined Generic Object and Control Methods (continued) Object _PS3 _PSC _PSL _PSR _PSS _PSV _PSW _PTC _PTS _PXM _Qxx _RBO _RBW _REG _REV _RMV _RNG _ROM _RW _S0 _S1 _S2 _S3 _S4 _S5 _S1D _S2D _S3D _S4D _SB Description Power management control method that puts the device in the D3 device state (device off). Power management object that evaluates to the devices current power state. Thermal zone object that returns list of passive cooling device objects. Power source object that returns present power source device. Object indicates the number of supported processor performance states. Thermal zone object that returns Passive trip point in tenths of degrees Kelvin. Power management control method that enables or disables the devices wake function. Object used to define a processor throttling control register. Control method used to prepare to sleep. Object used to describe proximity domains within a machine. Embedded Controller Query control method Resource data type reserved field name Resource data type reserved field name Notifies AML code of a change in the availability of an operation region. Revision of the ACPI specification that OSPM implements. Device insertion/removal object that indicates that the given device is removable. Resource data type reserved field name Control method used to get a copy of the display devices ROM data. Resource data type reserved field name Power management package that defines system \_S0 state mode. Power management package that defines system \_S1 state mode. Power management package that defines system \_S2 state mode. Power management package that defines system \_S3 state mode. Power management package that defines system \_S4 state mode. Power management package that defines system \_S5 state mode. Highest D-state supported by the device in the S1 state. Highest D-state supported by the device in the S2 state. Highest D-state supported by the device in the S3 state. Highest D-state supported by the device in the S4 state. System bus scope Reference 7.2.4 7.2.5 12.3.4 11.3.1 8.3.3.2 12.3.5 7.2.10 8.3.1 7.3.2 6.2.9 5.6.2.2.3 16.2.4 16.2.4 6.5.4 5.7.3 6.3.5 16.2.4 B.4.3 16.2.4 7.3.4.1 7.3.4.2 7.3.4.3 7.3.4.4 7.3.4.5 7.3.4.6 7.2.12 7.2.13 7.2.14 7.2.15 5.3.1
Compaq/Intel/Microsoft/Phoenix/Toshiba
144 Advanced Configuration and Power Interface Specification Table 5-43 Defined Generic Object and Control Methods (continued) Object _SBS _SCP _SEG _SHR _SI _SIZ _SPD _SRS _SST _STA Description Smart Battery object that returns Smart Battery configuration. Thermal zone object that sets user cooling policy (Active or Passive). Bus identification object that evaluates to a buss segment number. Resource data type reserved field name System indicators scope Resource data type reserved field name Control method used to update which video device will be posted at boot. Device configuration control method that sets a devices settings. System indicator control method that indicates the system status. 1. Device insertion/removal control method that returns a devices status. 2. Power resource object that evaluates to the current on or off state of the Power Resource. IDE device control method used to set the IDE controller transfer timings. Object evaluates to a Unicode string to describe a device. Object that evaluates to the slot unique ID number for a slot. Reserved for use by the ASL compiler. Thermal zone object that contains thermal constant for Passive cooling. Thermal zone object that contains thermal constant for Passive cooling. Thermal zone object that returns current temperature in tenths of degrees Kelvin. Resource data type reserved field name Resource data type reserved field name Thermal zone object that contains thermal sampling period for Passive cooling. Resource data type reserved field name Resource data type reserved field name ACPI 1.0 thermal zone scope Object evaluates to a package of device names associated with a Thermal Zone. Thermal zone polling frequency in tenths of seconds. Device identification object that specifies a devices unique persistent ID, or a control method that generates it. Returns 32-bit integer indicating the video post options. Power management control method run once system is awakened. Reference 11.1.2 12.3.6 6.5.6 16.4.2 5.3.1 16.4.2 B.4.5 6.2.10 10.1.1 6.3.6 7.1.4 10.8.3 6.1.5 6.1.6 16.2.1.1 12.3.7 12.3.8 12.3.9 16.4.2 16.4.2 12.3.10 16.4.2 16.4.2 5.3.1 12.3.11 12.3.12 6.1.7 B.4.6 7.3.5
_STM _STR _SUN _T_x _TC1 _TC2 _TMP _TRA _TRS _TSP _TTP _TYP _TZ _TZD _TZP _UID _VPO _WAK
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
6 Configuration
This section specifies the objects OSPM expects to be used in control methods to configure devices. There are three types of configuration objects: Device identification objects associate platform devices with Plug and Play IDs. Device configuration objects declare and configure hardware resources and characteristics for devices enumerated via ACPI. Device insertion and removal objects provide mechanisms for handling dynamic insertion and removal of devices. This section also defines the ACPI deviceresource descriptor formats. Deviceresource descriptors are used as parameters by some of the device configuration control method objects.
For any device that is not on an enumerable type of bus (for example, an ISA bus), OSPM enumerates the devices Plug and Play ID(s) and the ACPI BIOS must supply an _HID object (plus an optional _CID object) for each device to enable OSPM to do that. For devices on an enumerable type of bus, such as a PCI bus, the ACPI system must identify which device on the enumerable bus is identified by a particular Plug and Play ID; the ACPI BIOS must supply an _ADR object for each device to enable this. A device object must contain either an _HID object or an _ADR object, but can contain both. If any of these objects are implemented as control methods, these methods may depend on operation regions. Since the control methods may be evaluated before an operation region provider becomes available, the control method must be structured to execute in the absence of the operation region provider. (_REG methods notify the BIOS of the presence of operation region providers.) When a control method cannot determine the current state of the hardware due to a lack of operation region provider, it is recommended that the control method should return the condition that was true at the time that control passed from the BIOS to the OS. (The control method should return a default, boot value).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 147
OSPM infers the parent bus from the location of the _ADR objects device package in the ACPI namespace. For more information about the positioning of device packages in the ACPI namespace, see section 16.2.3.3.1.9, DeviceDeclare Bus/Device Package. _ADR object information must be static and can be defined for the following bus types listed in Table 6-2. Table 6-2 _ADR Object Bus Types BUS EISA Floppy Bus Address encoding EISA slot number 0F Drive select values used for programming the floppy controller to access the specified INT13 unit number. The _ADR Objects should be sorted based on drive select encoding from 0-3. 0Primary Channel, 1 Secondary Channel 0Master drive, 1 Slave drive High wordDevice #, Low wordFunction #. (for example, device 3, function 2 is 0x00030002). To refer to all the functions on a device #, use a function number of FFFF). Socket #; 0First Socket Socket #; 0First Socket Lowest Slave Address Only one child of the host controller. It must have an _ADR of 0. No other children or values of _ADR are allowed. Port number
USB Ports
Compaq/Intel/Microsoft/Phoenix/Toshiba
Then, when all else fails, an OS can use the info included in the _STR object to describe the hardware to the user.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 149
Compaq/Intel/Microsoft/Phoenix/Toshiba
Plug and Play BIOS Specification Version 1.0A, May 5, 1994, Compaq Computer Corp., Intel Corp., Phoenix Technologies Ltd.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 151
A _DMA object is not meant to describe any map register hardware that is set up for each DMA transaction. It is meant only to describe the DMA properties of a bus that cannot be changed without reevaluating the _SRS method. Arguments: None Result Code: Byte stream
Compaq/Intel/Microsoft/Phoenix/Toshiba
152 Advanced Configuration and Power Interface Specification Example ASL for _FIX usage:
Scope(\_SB) { Device(PCI0) { // Root PCI Bus Name(_HID, EISAID("PNP0A03")) // Need _HID for root device Name(_ADR,0) // Device 0 on this bus Method (_CRS,0){ // Need current resources for root device // Return current resources for root bridge 0 } Name(_PRT, Package(){ // Need PCI IRQ routing for PCI bridge // Package with PCI IRQ routing table information }) Name(_FIX, Package(1) { EISAID("PNP0C25")} //PM2 control ID ) Device (PX40) { // ISA Name(_ADR,0x00070000) Name(_FIX, Package(1) { EISAID("PNP0C20")} //SMI command port ) Device (NS17) { // NS17 (Nat. Semi 317, an ACPI part) Name(_HID, EISAID("PNP0C02")) Name(_FIX, Package(3) { EISAID("PNP0C22"), //PM1b event ID EISAID("PNP0C24"), //PM1b control ID EISAID("PNP0C28")} //GPE1 ID } } // end PX40 Device (PX43) { // PM Control Name(_ADR,0x00070003) Name(_FIX, Package(4) { EISAID("PNP0C21"), //PM1a event ID EISAID("PNP0C23"), //PM1a control ID EISAID("PNP0C26"), //PM Timer ID EISAID("PNP0C27")} //GPE0 ID ) } // end PX43 } // end PCI0 } // end scope SB
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 153
Table 6-4 _HPP Field Cache-line size Latency timer Enable SERR Enable PERR Format INTEGER INTEGER INTEGER INTEGER Definition Cache-line size reported in number of DWORDs. Latency timer value reported in number of PCI clock cycles. When set to 1, indicates that action must be performed to enable SERR in the command register. When set to 1, indicates that action must be performed to enable PERR in the command register.
Compaq/Intel/Microsoft/Phoenix/Toshiba
P2P2
P2P2 } P2P2
P2P2
P2P2
P2P2
P2P2
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 155
// Device definitions for Slot 2- HOT PLUG SLOT Device (S2F0) { // Slot 2, Func#0 on bus Name(_ADR,0x00030000) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F1) { // Slot 2, Func#1 on bus Name(_ADR,0x00030001) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F2) { // Slot 2, Func#2 on bus Name(_ADR,0x00030002) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F3) { // Slot 2, Func#3 on bus Name(_ADR,0x00030003) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F4) { // Slot 2, Func#4 on bus Name(_ADR,0x00030004) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F5) { // Slot 2, Func#5 on bus Name(_ADR,0x00030005) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F6) { // Slot 2, Func#6 on bus Name(_ADR,0x00030006) Method(_EJ0, 1) { //Remove all power to device} } Device (S2F7) { // Slot 2, Func#7 on bus Name(_ADR,0x00030007) Method(_EJ0, 1) { //Remove all power to device} } } // end P2P2 } // end PCI0 // end Scope (\_SB)
P2P2
P2P2
P2P2
P2P2
P2P2
P2P2
P2P2
P2P2
OSPM will configure a PCI device on a card hot-plugged into slot 1 or slot 2, with a cache line size of 32 (Notice this field is in DWORDs), latency timer of 64, enable SERR, but leave PERR alone.
Compaq/Intel/Microsoft/Phoenix/Toshiba
156 Advanced Configuration and Power Interface Specification When _MAT appears under an I/O APIC, OSPM processes I/O APIC (section 5.2.10.6), I/O SAPIC (section 5.2.10.12, I/O SAPIC Structure), non-maskable interrupt sources (section 5.2.10.9, NonMaskable Interrupt Sources), interrupt source overrides (section 5.2.10.8, Interrupt Source Overrides), and platform interrupt source structure (section 5.2.10.14, Platform Interrupt Source Structure) entries returned from the objects evaluation. Other entry types are ignored by OSPM. Arguments: None Result Code: A buffer Example ASL for _MAT usage:
Scope(\_SB) { Device(PCI0) { // Root PCI Bus Name(_HID, EISAID("PNP0A03")) // Need _HID for root device Name(_ADR,0) // Device 0 on this bus Method (_CRS,0){ // Need current resources for root device // Return current resources for root bridge 0 } Name(_PRT, Package(){ // Need PCI IRQ routing for PCI bridge // Package with PCI IRQ routing table information }) Device (P64A) { // P64A ACPI Name(_ADR,0) OperationRegion(TABD, SystemMemory, //Physical address of first // data byte of multiple ACPI table, Length of tables) Field (TABD, ByteAcc, NoLock, Preserve){ MATD, Length of tables x 8 } Method(_MAT, 0){ return (MATD)} } // end P64A } // end PCI0 } // end scope SB
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 157
Source Index
DWORD
There are two ways that _PRT can be used. Typically, the interrupt input that a given PCI interrupt is on is configurable. For example, a given PCI interrupt might be configured for either IRQ 10 or 11 on an 8259 interrupt controller. In this model, each interrupt is represented in the ACPI namespace as a PCI Interrupt Link Device. These objects have _PRS, _CRS, _SRS, and _DIS control methods to allocate the interrupt. Then, OSPM handles the interrupts not as interrupt inputs on the interrupt controller, but as PCI interrupt pins. The driver looks up the devices pins in the _PRT to determine which device objects allocate the interrupts. To move the PCI interrupt to a different interrupt input on the interrupt controller, OSPM uses _PRS, _CRS, _SRS, and _DIS control methods for the PCI Interrupt Link Device. In the second model, the PCI interrupts are hardwired to specific interrupt inputs on the interrupt controller and are not configurable. In this case, the Source field in _PRT does not point to a device, but is null, and the Source Index field contains the global system interrupt to which the PCI interrupt is hardwired.
Compaq/Intel/Microsoft/Phoenix/Toshiba
link
link
link
link
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 159
Compaq/Intel/Microsoft/Phoenix/Toshiba
160 Advanced Configuration and Power Interface Specification In ACPI, the sequence of events for dynamically inserting a device follows the process below. Notice that this process supports hot, warm, and cold insertion of devices. 1. If the device is physically inserted while the computer is in the working state (in other words, hot insertion), the hardware generates a general-purpose event. 2. The control method servicing the event uses the Notify(device,0) command to inform OSPM of the bus that the new device is on or the device object for the new device. If the Notify command points to the device object for the new device, the control method must have changed the devices status returned by _STA to indicate that the device is now present. The performance of this process can be optimized by having the object of the Notify as close as possible, in the namespace hierarchy, to where the new device resides. The Notify command can also be used from the _WAK control method (for more information about _WAK, see section 7.3.5 \_WAK (System Wake)) to indicate device changes that may have occurred while the computer was sleeping. For more information about the Notify command, see section 5.6.3 Device Object Notification.. 3. OSPM uses the identification and configuration objects to identify, configure, and load a device driver for the new device and any devices found below the device in the hierarchy. 4. If the device has a _LCK control method, OSPM may later run this control method to lock the device. The new device referred to in step 2 need not be a single device, but could be a whole tree of devices. For example, it could point to the PCI-PCI bridge docking connector. OSPM will then load and configure all devices it found below that bridge. The control method can also point to several different devices in the hierarchy if the new devices do not all live under the same bus. (in other words, more than one bus goes through the connector). For removing devices, ACPI supports both hot removal (system is in the S0 state), and warm removal (system is in a sleep state: S1-S4). This is done using the _EJ x control methods. Devices that can be ejected include an _EJx control method for each sleeping state the device supports (a maximum of 2 _EJ x objects can be listed). For example, hot removal devices would supply an _EJ0; warm removal devices would use one of _EJ1-EJ4. These control methods are used to signal the hardware when an eject is to occur. The sequence of events for dynamically removing a device goes as follows: 1. The eject button is pressed and generates a general-purpose event. (If the system was in a sleeping state, it should wake the computer). 2. The control method for the event uses the Notify(device, 3) command to inform OSPM which specific device the user has requested to eject. Notify does not need to be called for every device that may be ejected, but for the top-level device. Any child devices in the hierarchy or any ejection-dependent devices on this device (as described by _EJD, below) are automatically removed. 3. The OS shuts down and unloads devices that will be removed. 4. If the device has a _LCK control method, OSPM runs this control method to unlock the device. 5. The OS looks to see what _EJ x control methods are present for the device. If the removal event will cause the system to switch to battery power (in other words, an undock) and the battery is low, dead, or not present, OSPM uses the lowest supported sleep state _EJ x listed; otherwise it uses the highest state _EJ x. Having made this decision, OSPM runs the appropriate _EJ x control method to prepare the hardware for eject. 6. Warm removal requires that the system be put in a sleep state. If the removal will be a warm removal, OSPM puts the system in the appropriate Sx state. If the removal will be a hot removal, OSPM skips to step 8, below. 7. For warm removal, the system is put in a sleep state. Hardware then uses any motors, and so on, to eject the device. Immediately after ejection, the hardware transitions the computer to S0. If the system was sleeping when the eject notification came in, the OS returns the computer to a sleeping state consistent with the users wake settings. 8. OSPM calls _STA to determine if the eject successfully occurred. (In this case, control methods do not need to use the Notify(device,3) command to tell OSPM of the change in _STA) If there were any mechanical failures, _STA returns 3: device present and not functioning, and OSPM informs the user of the problem. Note : This mechanism is the same for removing a single device and for removing several devices, as in an undock.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 161
ACPI does not disallow surprise-style removal of devices; however, this type of removal is not recommended because system and data integrity cannot be guaranteed when a surprise-style removal occurs. Because the OS is not informed, its device drivers cannot save data buffers and it cannot stop accesses to the device before the device is removed. To handle surprise-style removal, a general-purpose event must be raised. Its associated control method must use the Notify command to indicate which bus the device was removed from. The device insertion and removal objects are listed in Table 6-6. Table 6-6 Device Insertion and Removal Objects Object _EDL Description Object that evaluates to a package of namespace references of device objects that depend on the device containing _EDL. Whenever the named device is ejected, OSPM ejects all dependent devices. Object that evaluates to the name of a device object on which a device depends. Whenever the named device is ejected, the dependent device must receive an ejection notification. Control method that ejects a device. Control method that locks or unlocks a device. Object that indicates that the given device is removable. Control method that returns a devices status.
Compaq/Intel/Microsoft/Phoenix/Toshiba
162 Advanced Configuration and Power Interface Specification When describing a platform that includes a docking station, usually more than one _EJD object will be needed. For example, if a dock attaches both a PCI device and an ACPI-configured device to a mobile system, then both the PCI device description package and the ACPI-configured device description package must include an _EJD object that evaluates to the name of the docking station (the name specified in an _ADR or _HID object in the docking stations description package). Thus, when the docking connector signals an eject request, OSPM first attemp ts to disable and unload the drivers for both the PCI and ACPI configured devices. Note : An ACPI 1.0 OS evaluates the _EJD methods only once during the table load process. This greatly restricts a table designers freedom to describe dynamic dependencies s uch as those created in scenarios with multiple docking stations. This restriction is illustrated in the example below; the _EJD information supplied via and ACPI 1.0-compatible namespace omits the IDE2 device from DOCK2s list of ejection dependencies. In ACPI 2.0, OSPM will be presented with a more in-depth view of the ejection dependencies in a system by use of the _EDL methods. Example An example use of _EJD and _EDL is as follows:
Scope(\_SB.PCI0) { Device(DOCK1) { // Pass through dock DOCK1 Name(_ADR, ) Method(_EJ0, 0) {} Method(_DCK, 1) {} Name(_BDN, ) Method(_STA, 0) {0xF} Name(_EDL, Package( ) { // DOCK1 has two dependent devices IDE2 and CB2 \_SB.PCI0.IDE2, \_SB.PCI0.CB2}) } Device(DOCK2) { // Pass through dock DOCK2 Name(_ADR, ) Method(_EJ0, 0) {} Method(_DCK, 1) {} Name(_BDN, ) Method(_STA, 0) {0x0} Name(_EDL, Package( ) { // DOCK2 has one dependent device IDE2 \_SB.PCI0.IDE2}) } Device(IDE1) { Name(_ADR, ) } // IDE Drive1 not dependent on the dock
// Dependent on DOCK1
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 163
For hot removal, the device mu st be immediately ejected when OSPM calls the _EJ0 control method. The _EJ0 control method does not return until ejection is complete. After calling _EJ0, OSPM verifies the device no longer exists to determine if the eject succeeded. For _HID devices, OSPM evaluates the _STA method. For _ADR devices, OSPM checks with the bus driver for that device. For warm removal, the _EJ1_EJ4 control methods do not cause the device to be immediately ejected. Instead, they set proprietary registers to prepare the hardware to eject when the system goes into the given sleep state. The hardware ejects the device only after OSPM has put the system in a sleep state by writing to the SLP_EN register. After the system resumes, OSPM calls _STA to determine if the eject succeeded. The _EJ x control methods take one parameter to indicate whether eject should be enabled or disabled: 1Hot eject or mark for ejection 0Cancel mark for ejection (EJ0 will never be called with this value) A device object may have multiple _EJx control methods. First, it lists an EJx control method for the preferred sleeping state to eject the device. Optionally, the device may list an EJ4 control method to be used when the system has no power (for example, no battery) after the eject. For example, a hot-docking notebook might list _EJ0 and _EJ4.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 165
The following small information items are currently defined for Plug and Play devices: Table 6-8 Small Resource Items Small Item Name Reserved Reserved Reserved IRQ format DMA format Start dependent Function End dependent Function I/O port descriptor Fixed location I/O port descriptor Reserved Vendor defined End tag Value 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA0xD 0xE 0xF
Compaq/Intel/Microsoft/Phoenix/Toshiba
166 Advanced Configuration and Power Interface Specification Table 6-9 IRQ Descriptor Definition (continued) Offset Byte 3 Field Name IRQ Information. Each bit, when set, indicates this device is capable of driving a certain type of interrupt. (Optionalif not included then assume edge sensitive, high true interrupts) Note: These bits can be used both for reporting and setting IRQ resources. Note: This descriptor is meant for describing interrupts that are connected to PICcompatible interrupt controllers, which can only be programmed for Active-HighEdge-Triggered or Active-Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations. Bit[7:5] Reserved (must be 0) Bit[4] Interrupt is sharable, _SHR Bit[3] Interrupt Polarity, _LL 0: Active-HighThis interrupt is sampled when the signal is high, or true. 1: Active-LowThis interrupt is sampled when the signal is low, or false. Bit[2:1] Ignored Bit[0] Interrupt Mode, _HE 0: Level-TriggeredThis interrupt is triggered in response to the signal being in a low state. 1: Edge-TriggeredThis interrupt is triggered in response to a change in signal state from low to high. Note : Low true, level sensitive interrupts may be electrically shared, but the process of how this might work is beyond the scope of this specification. Note : If byte 3 is not included, High true, edge sensitive, non-shareable is assumed. See section 16.2.4.1, ASL Macro for IRQ Descriptor, for a description of the ASL macro that creates an IRQ descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 167
Bits[6:5] DMA channel speed supported, _TYP Status 00 Indicates compatibility mode 01 Indicates Type A DMA as described in the EISA Specification 10 Indicates Type B DMA 11 Indicates Type F Bit[4:3] Bit[2] Ignored Logical device bus master status, _BM Status 0 Logical device is not a bus master 1 Logical device is a bus master
Bits[1:0] DMA transfer type preference, _SIZ Status 00 8-bit only 01 8- and 16-bit 10 16-bit only 11 Reserved See section 16.2.4.2, ASL Macro for DMA Descriptor, for a description of the ASL macro that creates a DMA descriptor.
6.4.2.3 Start Dependent Functions (Type 0, Small Item Name 0x6, Length=0 or 1)
Each logical device requires a set of resources. This set of resources may have interdependencies that need to be expressed to allow arbitration software to make resource allocation decisions about the logical device. Dependent functions are used to exp ress these interdependencies. The data structure definitions for dependent functions are shown here. For a detailed description of the use of dependent functions refer to the next section. Table 6-11 Start Dependent Functions Offset Byte 0 Field Name Value = 0_0110_00nB (Type = 0, small item name = 0x6, length =(0 or 1))
Compaq/Intel/Microsoft/Phoenix/Toshiba
168 Advanced Configuration and Power Interface Specification Start Dependent Function fields may be of length 0 or 1 bytes. The extra byte is optionally used to denote the compatibility or performance/robustness priority for the resource group following the Start DF tag. The compatibility priority is a ranking of configurations for compatibility with legacy operating systems. This is the same as the priority used in the PNPBIOS interface. For example, for compatibility reasons, the preferred configuration for COM1 is IRQ4, I/O 3F8-3FF. The performance/robustness performance is a ranking of configurations for performance and robustness reasons. For example, a device may have a highperformance, bus mastering configuration that may not be supported by legacy operating systems. The busmastering configuration would have the highest performance/robustness priority while its polled I/O mode might have the highest compatibility priority. If the Priority byte is not included, this indicates the dependent function priority is acceptable. This byte is defined as: Table 6-12 Start Dependent Function Priority Byte Definition Bits 1:0 Definition Compatibility priority. Acceptable values are: 0 Good configuration: Highest Priority and preferred configuration 1Acceptable configuration: Lower Priority but acceptable configuration 2Sub-optimal configuration: Functional configuration but not optimal 3Reserved 3:2 Performance/robustness. Acceptable values are: 0 Good configuration: Highest Priority and preferred configuration 1Acceptable configuration: Lower Priority but acceptable configuration 2Sub-optimal configuration: Functional configuration but not optimal 3Reserved 7:4 Reserved (must be 0)
Notice that if multiple Dependent Functions have the same priority, they are further prioritized by the order in which they appear in the resource data structure. The Dependent Function that appears earliest (nearest the beginning) in the structure has the highest priority, and so on. See section 16.2.4.3, ASL Macro for Start-Dependent Function Descriptor, for a description of the ASL macro that creates a Start Dependent Function descriptor.
6.4.2.4 End Dependent Functions (Type 0, Small Item Name 0x7, Length=0)
Table 6-13 End Dependent Functions Offset Byte 0 Field Name Value = 0_0111_000B (Type = 0, small item name = 0x7 length =0)
Notice that only one End Dependent Function item is allowed per logical device. This enforces the fact that Dependent Functions cannot be nested. See section 16.2.4.4, ASL Macro for End-Dependent Functions Descriptor, for a description of the ASL macro that creates an End Dependent Functions descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 169
6.4.2.5 I/O Port Descriptor (Type 0, Small Item Name 0x8, Length=7)
There are two types of descriptors for I/O ranges. The first descriptor is a full function descriptor for programmable devices. The second descriptor is a minimal descriptor for old ISA cards with fixed I/O requirements that use a 10-bit ISA address decode. The first type descriptor can also be used to describe fixed I/O requirements for ISA cards that require a 16-bit address decode. This is accomplished by setting the range minimum base address and range maximum base address to the same fixed I/O value. Table 6-14 I/O Port Descriptor Definition Offset Byte 0 Byte 1 Field Name I/O port descriptor Information Definition Value = 01000111B (Type = 0, Small item name = 0x8, Length = 7) Bits[7:1] are reserved and must be 0 Bit[0] (_DEC) If set, indicates the logical device decodes 16-bit addresses. If bit[0] is not set, this indicates the logical device only decodes address bits[9:0].
Byte 2
Range minimum base address, _MIN bits[7:0] Range minimum base address, _MIN bits[15:8] Range maximum base address, _MAX bits[7:0] Range maximum base address, _MAX bits[15:8] Base alignment, _ALN Range length, _LEN
Address bits[7:0] of the minimum base I/O address that the card may be configured for. Address bits[15:8] of the minimum base I/O address that the card may be configured for. Address bits[7:0] of the maximum base I/O address that the card may be configured for. Address bits[15:8] of the maximum base I/O address that the card may be configured for. Alignment for minimum base address, increment in 1byte blocks. The number of contiguous I/O ports requested.
Byte 3
Byte 4
Byte 5
Byte 6 Byte 7
See section 16.2.4.5, ASL Macro for I/O Port Descriptor, for a description of the ASL macro that creates an I/O Port descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
6.4.2.6 Fixed Location I/O Port Descriptor (Type 0, Small Item Name 0x9, Length=3)
This descriptor is used to describe 10-bit I/O locations. Table 6-15 Fixed-Location I/O Port Descriptor Definition Offset Byte 0 Byte 1 Field Name Fixed Location I/O port descriptor Definition Value = 01001011B (Type = 0, Small item name = 0x9, Length = 3)
Range base address, _BAS Address bits[7:0] of the base I/O address that the card bits[7:0] may be configured for. This descriptor assumes a 10bit ISA address decode. Range base address, _BAS Address bits[9:8] of the base I/O address that the card bits[9:8] may be configured for. This descriptor assumes a 10bit ISA address decode. Range length, _LEN The number of contiguous I/O ports requested.
Byte 2
Byte 3
See section 16.2.4.6, ASL Macro for Fixed I/O Port Descriptor, for a description of the ASL macro that creates a Fixed I/O Port descriptor.
See section 16.2.4.7, ASL Macro for Short Vendor-Defined Descriptor, for a description of the ASL macro that creates a short Vendor Defined descriptor.
The End Tag is automatically generated by the ASL compiler at the end of the ResourceTemplate statement.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 171
The following large information items are currently defined for Plug and Play ISA devices: Table 6-19 Large Resource Items Large Item Name 24-bit memory range descriptor Generic register descriptor Reserved Vendor defined 32-bit memory range descriptor 32-bit fixed location memory range descriptor DWORD address space descriptor WORD address space descriptor Extended IRQ descriptor QWORD address space descriptor Reserved Value 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0x7F
6.4.3.1 24-Bit Memory Range Descriptor (Type 1, Large Item Name 0x1)
The 24-bit memory range descriptor describes a devices memory range resources within a 24-bit address space. Table 6-20 Large Memory Range Descriptor Definition Offset Byte 0 Byte 1 Byte 2 Field Name, ASL Field Name Definition Memory range descriptor Length, bits[7:0] Length, bits[15:8] Value = 10000001B (Type = 1, Large item name = 0x1) Value = 00001001B (9) Value = 00000000B (0)
Compaq/Intel/Microsoft/Phoenix/Toshiba
172 Advanced Configuration and Power Interface Specification Table 6-20 Large Memory Range Descriptor Definition (continued) Offset Byte 3 Field Name, ASL Field Name Definition Information This field provides extra information about this memory. Bit[7:1] Ignored Bit[0] Write status, _RW Status 1 writeable 0 non-writeable
(ROM) Byte 4 Range minimum base address, Address bits[15:8] of the minimum base memory _MIN address for which the card may be configured. bits[7:0] Range minimum base address, Address bits[23:16] of the minimum base memory _MIN address for which the card may be configured bits[15:8] Range maximum base address, Address bits[15:8] of the maximum base memory _MAX, address for which the card may be configured. bits[7:0] Range maximum base address, Address bits[23:16] of the maximum base memory _MAX, address for which the card may be configured bits[15:8] Base alignment, _ALN, bits[7:0] This field contains the lower eight bits of the base alignment. The base alignment provides the increment for the minimum base address. (0x0000 = 64 KB) This field contains the upper eight bits of the base alignment. The base alignment provides the increment for the minimum base address. (0x0000 = 64 KB) This field contains the lower eight bits of the memory range length. The range length provides the length of the memory range in 256 byte blocks.
Byte 5
Byte 6
Byte 7
Byte 8
Byte 9
Byte 10
Byte 11
Range length, _LEN, bits[15:8] This field contains the upper eight bits of the memory range length. The range length field provides the length of the memory range in 256 byte blocks.
Notes: Address bits [7:0] of memory base addresses are assumed to be 0. A Memory range descriptor can be used to describe a fixed memory address by setting the range minimum base address and the range maximum base address to the same value. 24-bit Memory Range descriptors are used for legacy devices. Mixing of 24-bit and 32-bit memory descriptors on the same device is not allowed. See section 16.2.4.8, ASL Macro for 24-Bit Memory Descriptor, for a description of the ASL macro that creates a 24-bit Memory descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 173
See section 16.2.4.9, ASL Macro for Long Vendor-Defined Descriptor, for a description of the ASL macro that creates a long Vendor Defined descriptor.
6.4.3.3 32-Bit Memory Range Descriptor (Type 1, Large Item Name 0x5)
This memory range descriptor describes a devices memory resources within a 32-bit address space. Table 6-22 Large 32-Bit Me mory Range Descriptor Definition Offset Byte 0 Byte 1 Byte 2 Byte 3 Field Name Memory range descriptor Length, bits[7:0] Length, bits[15:8] Information Definition Value = 10000101B (Type = 1, Large item name = 0x5) Value = 00010001B (17) Value = 00000000B (0) This field provides extra information about this memory. Bit[7:1] Ignored Bit[0] Write status, _RW Status 1 writeable 0 non-writeable
(ROM) Byte 4 Range minimum base address, _MIN bits[7:0] Range minimum base address, _MIN bits[15:8] Range minimum base address, _MIN bits[23:16] Range minimum base address, _MIN bits[31:24] Address bits[7:0] of the minimum base memory address for which the card may be configured. Address bits[15:8] of the minimum base memory address for which the card may be configured. Address bits [23:16] of the minimum base memory address for which the card may be configured. Address bits[31:24] of the minimum base memory address for which the card may be configured.
Byte 5
Byte 6
Byte 7
Compaq/Intel/Microsoft/Phoenix/Toshiba
174 Advanced Configuration and Power Interface Specification Table 6-22 Large 32-Bit Memory Range Descriptor Definition (continued) Offset Byte 8 Field Name Range maximum base address, _MAX bits[7:0] Range maximum base address, _MAX bits[15:8] Range maximum base address, _MAX bits[23:16] Range maximum base address, _MAX bits[31:24] Base alignment, _ALN bits[7:0] Base alignment, _ALN bits[15:8] Base alignment, _AL N bits[23:16] Base alignment, _ALN bits[31:24] Range length, _LEN bits[7:0] Range length, _LEN bits[15:8] Range length, _LEN bits[23:16] Range length, _LEN bits[31:24] Definition Address bits[7:0] of the maximum base memory address for which the card may be configured. Address bits[15:8] of the maximum base memory address for which the card may be configured. Address bits[23:16] of the maximum base memory address for which the card may be configured. Address bits[31:24] of the maximum base memory address for which the card may be configured. This field contains Bits[7:0] of the base alignment. The base alignment provides the increment for the minimum base address. This field contains Bits[15:8] of the base alignment. The base alignment provides the increment for the minimum base address. This field contains Bits[23:16] of the base alignment. The base alignment provides the increment for the minimum base address. This field contains Bits[31:24] of the base alignment. The base alignm ent provides the increment for the minimum base address. This field contains Bits[7:0] of the memory range length. The range length provides the length of the memory range in 1-byte blocks. This field contains Bits[15:8] of the memory range length. The range length provides the length of the memory range in 1-byte blocks. This field contains Bits[23:16] of the memory range length. The range length provides the length of the memory range in 1-byte blocks. This field contains Bits[31:24] of the memory range length. The range length provides the length of the memory range in 1-byte blocks.
Byte 9
Byte 10
Byte 11
Byte 12
Byte 13
Byte 14
Byte 15
Byte 16
Byte 17
Byte 18
Byte 19
Note: M ixing of 24-bit and 32-bit memory descriptors on the same device is not allowed. See section 16.2.4.10, ASL Macro for 32-Bit Memory Descriptor, for a description of the ASL macro that creates a 32-bit Memory descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 175
6.4.3.4 32-Bit Fixed Location Memory Range Descriptor (Type 1, Large Item Name 0x6)
This memory range descriptor describes a devices memory resources within a 32-bit address space. Table 6-23 Large Fixed-Location Memory Range Descriptor Definition Offset Byte 0 Byte 1 Byte 2 Byte 3 Field Name Memory range descriptor Length, bits[7:0] Length, bits[15:8] Information Definition Value = 10000110B (Type = 1, Large item name = 6) Value = 00001001B (9) Value = 00000000B (0) This field provides extra information about this memory. Bit[7:1] Ignored Bit[0] Write status, _RW Status 1 writeable 0 non-writeable (ROM) Byte 4 Byte 5 Byte 6 Byte 7 Range base address, _BAS Address bits[7:0] of the base memory address for which bits[7:0] the card may be configured. Range base address, _BAS Address bits[15:8] of the base memory address for which bits[15:8] the card may be configured. Range base address, _BAS Address bits[23:16] of the base memory address for bits[23:16] which the card may be configured. Range base address, _BAS Address bits[31:24] of the base memory address for bits[31:24] which the card may be configured. Range length, _LEN bits[7:0] Range length, _LEN bits[15:8] Range length, _LEN bits[23:16] Range length, _LEN bits[31:24] This field contains Bits[7:0] of the memory range length. The range length provides the length of the memory range in 1-byte blocks. This field contains Bits[15:8] of the memory range length. The range length provides the length of the memory range in 1-byte blocks. This field contains Bits[23:16] of the memory range length. The range length provides the length of the memory range in 1-byte blocks. This field contains Bits[31:24] of the memory range length. The range length provides the length of the memory range in 1-byte blocks.
Byte 8
Byte 9
Byte 10
Byte 11
Note: Mixing of 24-bit and 32-bit memory descriptors on the same device is not allowed. See section 16.2.4.11, ASL Macro for 32-Bit Fixed Memory Descriptor, for a description of the ASL macro that creates a 32-bit Fixed Memory descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
(Illegal combination) Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA+1). OS can pick the resource range that satisfies following conditions: Start address is a multiple of (_GRA+1) and greater or equal to _MIN. End address is (start address+_LEN -1) and less or equal to _MAX.
0 1 1
1 0 1
(Illegal combination) (Illegal combination) Fixed size, fixed location resource descriptor. _GRA must be 0 and _LEN must be (_MAX - _MIN +1).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 177
6.4.3.5.1 QWORD Address Space Descriptor (Type 1, Large Item Name 0xA)
The QWORD address space descriptor is used to report resource usage in a 64-bit address space (like memory and I/O). Table 6-25 QWORD Address Space Descriptor Definition Offset Byte 0 Byte 1 Byte 2 Byte 3 Field Name QWORD Address Space Descriptor Length, bits[7:0] Length, bits[15:8] Resource Type Definition Value=10001010B (Type = 1, Large item name = 0xA) Variable: Value = 43 (min imum) Variable: Value = 0 (minimum) Indicates which type of resource this descriptor describes. Defined values are: 0 1 2 3255 Byte 4 General Flags Memory range I/O range Bus number range Reserved
Flags that are common to all resource types: Bits[7:4] Reserved (must be 0) Bit[3] _MAF: 1The specified max address is fixed. 0The specified max address is not fixed and can be changed. Bit[2] _MIF: 1The specified min address is fixed. 0The specified min address is not fixed and can be changed. Bit[1] _DEC:
1This bridge subtractively decodes this address (top level bridges only). 0This bridge positively decodes this address. Bit[0]. 1This device consumes this resource. 0This device produces and consumes this resource. Byte 5 Type Specific Flags Flags that are specific to each resource type. The meaning of the flags in this field depends on the value of the Resource Type field (see above).
Compaq/Intel/Microsoft/Phoenix/Toshiba
178 Advanced Configuration and Power Interface Specification Table 6-25 QWORD Address Space Descriptor Definition (continued) Offset Byte 6 Field Name Address space granularity, _GRA bits[7:0] Address space granularity, _GRA bits[15:8] Address space granularity, _GRA bits[23:16] Address space granularity, _GRA bits[31:24] Address space granularity, _GRA bits[39:32] Address space granularity, _GRA bits[47:40] Address space granularity, _GRA bits[55:48] Address space granularity, _GRA bits[63:56] Address range minimum, _MIN bits[7:0] Address range minimum, _MIN bits[15:8] Address range minimum, _MIN bits[23:16] Address range minimum, _MIN bits[31:24] Address range minimum, _MIN bits[39:32] Address range minimum, _MIN bits[47:40] For bridges that translate addresses, this is the address space on the secondary side of the bridge. Definition A set bit in this mask means that this bit is decoded. All bits less significant than the most significant set bit must be set. That is, the value of the full Address Space Granularity field (all 32 bits) must be a number (2n -1).
Byte 7
Byte 8
Byte 9
Byte 10
Byte 11
Byte 12
Byte 13
Byte 14
Byte 15
Byte 16
Byte 17
Byte 18
Byte 19
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 179
Table 6-25 QWORD Address Space Descriptor Definition (continued) Offset Byte 20 Field Name Address range minimum, _MIN bits[55:48] Address range minimum, _MIN bits[63:56] Address range maximum, _MAX bits[7:0] Address range maximum, _MAX bits[15:8] Address range maximum, _MAX bits[23:16] Address range maximum, _MAX bits[31:24] Address range maximum, _MAX bits[39:32] Address range maximum, _MAX bits[47:40] Address range maximum, _MAX bits[55:48] Address range maximum, _MAX bits[63:56] Address Translation offset, _TRA bits[7:0] For bridges that translate addresses across the bridge, this is the offset that must be added to the address on the primary side to obtain the address on the secondary side. Non-bridge devices must list 0 for all Address Translation offset bits. For bridges that translate addresses, this is the address space on the secondary side of the bridge. For bridges that translate addresses, this is the address space on the secondary side of the bridge. Definition
Byte 21
Byte 22
Byte 23
Byte 24
Byte 25
Byte 26
Byte 27
Byte 28
Byte 29
Byte 30
Byte 31
Address Translation offset, _TRA bits[15:8] Address Translation offset, _TRA bits[23:16] Address Translation offset, _TRA bits[31:24]
Byte 32
Byte 33
Compaq/Intel/Microsoft/Phoenix/Toshiba
180 Advanced Configuration and Power Interface Specification Table 6-25 QWORD Address Space Descriptor Definition (continued) Offset Byte 34 Field Name Address Translation offset, _TRA bits[39:32] Address Translation offset, _TRA bits[47:40] Address Translation offset, _TRA bits[55:48] Address Translation offset, _TRA bits[63:56] Address length, _LEN bits[7:0] Address length, _LEN, bits[15:8] Address length, _LEN bits[23:16] Address length, _LEN bits[31:24] Address length, _LEN bits[39:32] Address length, _LEN bits[47:40] Address length, _LEN bits[55:48] Address length, _LEN bits[63:56] Resource Source Index (Optional) Only present if Resource Source (below) is present. This field gives an index to the specific resource descriptor that this device consumes from in the current resource template for the device object pointed to in Resource Source. (Optional) If present, the device that uses this descriptor consumes its resources from the resources produced by the named device object. If not present, the device consumes its resources out of a global pool. If not present, the device consumes this resource from its hierarchical parent. Definition
Byte 35
Byte 36
Byte 37
String
Resource Source
See section 16.2.4.12, ASL Macros for QWORD Address Space Descriptor, for a description of the ASL macro that creates a QWORD Address Space descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 181
6.4.3.5.2 DWORD Address Space Descriptor (Type 1, Large Item Name 0x7)
The DWORD address space descriptor is used to report resource usage in a 32-bit address space (like memory and I/O). Table 6-26 DWORD Address Space Descriptor Definition Offset Byte 0 Byte 1 Byte 2 Byte 3 Field Name DWORD Address Space Descriptor Length, bits[7:0] Length, bits[15:8] Resource Type Definition Value=10000111B (Type = 1, Large item name = 0x7) Variable: Value = 23 (minimum) Variable: Value = 0 (minimum) Indicates which type of resource this descriptor describes. Defined values are: 0 1 2 3-255 Byte 4 General Flags Memory range I/O range Bus number range Reserved
Flags that are common to all resource types: Bits[7:4] Reserved (must be 0) Bit[3] _MAF: 1The specified max address is fixed. 0The specified max address is not fixed and can be changed. Bit[2] _MIF: 1The specified min address is fixed. 0The specified min address is not fixed and can be changed. Bit[1] _DEC: 1This bridge subtractively decodes this address (top level bridges only). 0This bridge positively decodes this address. Bit[0] 1This device consumes this resource. 0This device produces and consumes this resource.
Byte 5
Flags that are specific to each resource type. The meaning of the flags in this field depends on the value of the Resource Type field (see above).
Compaq/Intel/Microsoft/Phoenix/Toshiba
182 Advanced Configuration and Power Interface Specification Table 6-26 DWORD Address Space Descriptor Definition (continued) Offset Byte 6 Field Name Address space granularity, _GRA bits[7:0] Definition A set bit in this mask means that this bit is decoded. All bits less significant than the most significant set bit must be set. (in other words, the value of the full Address Space Granularity field (all 32 bits) must be a number (2n -1).
Byte 7
Address space granularity, _GRA bits[15:8] Address space granularity, _GRA bits [23:16] Address space granularity, _GRA bits [31:24] Address range minimum, _MIN bits [7:0] Address range minimum, _MIN bits [15:8] Address range minimum, _MIN bits [23:16] Address range minimum, _MIN bits [31:24] Address range maximum, _MAX bits [7:0] Address range maximum, _MAX bits [15:8] Address range maximum, _MAX bits [23:16] Address range maximum, _MAX bits [31:24] Address Translation offset, _TRA bits [7:0] For bridges that translate addresses across the bridge, this is the offset that must be added to the address on the primary side to obtain the address on the secondary side. Non-bridge devices must list 0 for all Address Translation offset bits. For bridges that translate addresses, this is the address space on the secondary side of the bridge. For bridges that translate addresses, this is the address space on the secondary side of the bridge.
Byte 8
Byte 9
Byte 10
Byte 11
Byte 12
Byte 13
Byte 14
Byte 15
Byte 16
Byte 17
Byte 18
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 183
Table 6-26 DWORD Address Space Descriptor Definition (continued) Byte 19 Address Translation offset, _TRA bits [15:8] Address Translation offset, _TRA bits [23:16] Address Translation offset, _TRA bits [31:24] Address Length, _LEN, bits [7:0] Byte 23 Address Length, _LEN, bits [15:8] Byte 24 Address Length, _LEN, bits [23:16] Byte 25 Address Length, _LEN, bits [31:24] Byte 26 Resource Source Index (Optional) Only present if Resource Source (below) is present. This field gives an index to the specific resource descriptor that this device consumes from in the current resource template for the device object pointed to in Resource Source. (Optional) If present, the device that uses this descriptor consumes its resources from the resources produced by the named device object. If not present, the device consumes its resources out of a global pool. If not present, the device consumes this resource from its hierarchical parent. See section 16.2.4.13, ASL Macro for DWORD Address Space Descriptor, for a description of the ASL macro that creates a DWORD Address Space descriptor.
Byte 20
Byte 21
Byte 22
String
Resource Source
Compaq/Intel/Microsoft/Phoenix/Toshiba
6.4.3.5.3 WORD Address Space Descriptor (Type 1, Large Item Name 0x8)
The WORD address space descriptor is used to report resource usage in a 16-bit address space (like memory and I/O). Note: This descriptor is exactly the same as the DWORD descriptor specified in Table 6-23; the only difference is that the address fields are 16 bits wide rather than 32 bits wide. Table 6-27 WORD Address Space Descriptor Definition Offset Byte 0 Byte 1 Byte 2 Byte 3 Field Name WORD Address Space Descriptor Length, bits[7:0] Length, bits[15:8] Resource Type Definition Value=10001000B (Type = 1, Large item name = 0x8) Variable: Value = 13 (minimum) Variable: Value = 0 (minimum) Indicates which type of resource this descriptor describes. Defined values are: 0 1 2 3-255 Byte 4 General Flags Memory range I/O range Bus number range Reserved
Flags that are common to all resource types: Bits[7:4] Reserved (must be 0) Bit[3] _MAF: 1The specified max address is fixed. 0The specified max address is not fixed and can be changed. Bit[2] _MIF: 1The specified min address is fixed. 0The specified min address is not fixed and can be changed. Bit[1] _DEC: 1This bridge subtractively decodes this address (top level bridges only). 0This bridge positively decodes this address. Bit[0] 1This device consumes this resource. 0This device produces and consumes this resource.
Byte 5
Flags that are specific to each resource type. The meaning of the flags in this field depends on the value of the Resource Type field (see above).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 185
Table 6-27 WORD Address Space Descriptor Definition (continued) Offset Byte 6 Field Name Address space granularity, _GRA bits[7:0] Definition A set bit in this mask means that this bit is decoded. All bits less significant than the most significant set bit must be set. (in other words, the value of the full Address Space Granularity field (all 16 bits) must be a number (2n -1).
Byte 7
Address space granularity, _GRA bits[15:8] Address range minimum, _MIN bits [7:0] Address range minimum, _MIN bits [15:8] Address range maximum, _MAX bits [7:0] Address range maximum, _MAX bits [15:8] Address Translation offset, _TRA bits [7:0] For bridges that translate addresses across the bridge, this is the offset that must be added to the address on the primary side to obtain the address on the secondary side. Non-bridge devices must list 0 for all Address Translation offset bits. For bridges that translate addresses, this is the address space on the secondary side of the bridge. For bridges that translate addresses, this is the address space on the secondary side of the bridge.
Byte 8
Byte 9
Byte 10
Byte 11
Byte 12
Byte 13
Address Translation offset, _TRA bits [15:8] Address Length, _LEN, bits [7:0] Address Length, _LEN, bits [15:8]
Byte 14 Byte 15
Compaq/Intel/Microsoft/Phoenix/Toshiba
186 Advanced Configuration and Power Interface Specification Table 6-27 WORD Address Space Descriptor Definition (continued) Offset Byte 16 Field Name Resource Source Index Definition (Optional) Only present if Resource Source (below) is present. This field gives an index to the specific resource descriptor that this device consumes from in the current resource template for the device object pointed to in Resource Source. (Optional) If present, the device that uses this descriptor consumes its resources from the resources produced by the named device object. If not present, the device consumes its resources out of a global pool. If not present, the device consumes this resource from its hierarchical parent.
String
Resource Source
See section 16.2.4.14, ASL Macro for WORD Address Descriptor, for a description of the ASL macro that creates a WORD address descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 187
Table 6-28 Memory Resource Flag (Resource Type = 0) Definitions (continued) Bits Bits[2:1] Meaning Memory attributes, _MEM Value andMeaning 0 1 2 3 Bit[0] The memory is non-cacheable. The memory is cacheable. The memory is cacheable and supports write combining. The memory is cacheable and prefetchable.
Write status, _RW 1This memory range is read-write. 0This memory range is read-only. Table 6-29 I/O Resource Flag (Resource Type = 1) Definitions
Meaning Reserved (must be 0) Sparse Translation, _TRS. This bit is only meaningful if Bit[4] is set. 1SparseTranslation: The primary-side memory address of any specific I/O port within the secondary-side range can be found using the following function. address = (((port & 0xfffc) << 10) || (port & 0xfff)) + _TRA In the address used to access the I/O port, bits[11:2] must be identical to bits[21:12], this gives four bytes of I/O ports on each 4 KB page. 0DenseTranslation: The primary-side memory address of any specific I/O port within the secondary-side range can be found using the following function. address = port + _TRA
Bit[4]
I/O to Memory Translation, _TTP 1 - TypeTranslation: This resource, which is I/O on the secondary side of the bridge, is memory on the primary side of the bridge. 0TypeStatic: This resource, which is I/O on the secondary side of the bridge, is also I/O on the primary side of the bridge.
Bit[3:2]
Reserved (must be 0)
Compaq/Intel/Microsoft/Phoenix/Toshiba
188 Advanced Configuration and Power Interface Specification Table 6-29 I/O Resource Flag (Resource Type = 1) Definitions (continued) Bits Bit[1] Meaning _RNG This flag is for bridges on systems with multiple bridges. Setting this bit means the memory window specified in this descriptor is limited to the ISA I/O addresses that fall within the specified window. The ISA I/O ranges are: n000n0FF, n400-n4FF, n800-n8FF, nC00-nCFF. This bit can only be set for bridges entirely configured through ACPI namespace. _RNG This flag is for bridges on systems with multiple bridges. Setting this bit means the memory window specified in this descriptor is limited to the non-ISA I/O addresses that fall within the specified window. The non-ISA I/O ranges are: n100-n3FF, n500-n7FF, n900-nBFF, nD00-nFFF. This bit can only be set for bridges entirely configured through ACPI namespace. Table 6-30 Bus Number Range Resource Flag (Resource Type = 2) Definitions Bits Bit[7:0] Meaning Reserved (must be 0)
Bit[0]
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 189
Table 6-31 Extended Interrupt Descriptor Definition (continued) Offset Byte 3 Field Name Interrupt Vector Flags Definition Interrupt Vector Information. Bit[7:4] Reserved (must be 0) Bit[3] Bit[2] Interrupt is shareable, _SHR Interrupt Polarity, _LL 0Active-High: This interrupt is sampled when the signal is high, or true. 1Active-Low: This interrupt is sampled when the signal is low, or false. Bit[1] Interrupt Mode, _HE 0Level-Triggered: This interrupt is triggered in response to the signal being in either a high or low state. 1Edge-Triggered: This interrupt is triggered in response to a change in signal state, either high to low or low to high. Bit[0] 1This device consumes this resource. 0This device produces and consumes this resource. Byte 4 Interrupt table length Indicates the number of interrupt numbers that follow. When this descriptor is returned from _CRS, or when OSPM passes this descriptor to _SRS, this field must be set to 1. Interrupt number
Interrupt Number, _INT bits [7:0] Interrupt Number, _INT bits [15:8] Interrupt Number, _INT bits [23:16] Interrupt Number, _INT bits [31:24]
Compaq/Intel/Microsoft/Phoenix/Toshiba
190 Advanced Configuration and Power Interface Specification Table 6-31 Extended Interrupt Descriptor Definition (continued) Offset Byte x Field Name Resource Source Index Definition (Optional) Only present if Resource Source (below) is present. This field gives an index to the specific resource descriptor that this device consumes from in the current resource template for the device object pointed to in Resource Source. (Optional) If present, the device that uses this descriptor consumes its resources from the resources produces by the named device object. If not present, the device consumes its resources out of a global pool. If not present, the device consumes this resource from its hierarchical parent. Note: Low true, level sensitive interrupts may be electrically shared, the process of how this might work is beyond the scope of this specification. If the OS is running using the 8259 interrupt model, only interrupt number values of 0-15 will be used, and interrupt numbers greater than 15 will be ignored. See section 16.2.4.15, ASL Macro for Extended Interrupt Descriptor, for a description of the ASL macro that creates an Extended Interrupt descriptor.
String
Resource Source
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 191
Table 6-32 Generic Register Descriptor Definition (continued) Offset Byte 6 Byte 7 Byte 8 Byte 9 Byte 10 Byte 11 Byte 12 Byte 13 Field Name, ASL Field Name Definition Register Address, _ADR bits[7:0] Register Address, _ADR bits[15:8] Register Address, _ADR bits[23:16] Register Address, _ADR bits[31:24] Register Address, _ADR bits[39:32] Register Address, _ADR bits[47:40] Register Address, _ADR bits[55:48] Register Address, _ADR bits[63:56] Register Address
See section 16.2.4.16, ASL Macro for Generic Register Descriptor, for a description of the ASL macro that creates a Generic Register descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
192 Advanced Configuration and Power Interface Specification If the _STA method indicates that the device is present, OSPM will evaluate the __INI for the device (if the _INI method exists) and will examine each of the children of the device for _INI methods. If the _STA method indicates that the device is not present, OSPM will not run the _INI and will not examine the children of the device for _INI methods. If the device becomes present after the table has already been loaded, OSPM will not evaluate the _INI method, nor examine the children for _INI methods. The _INI control method is generally used to switch devices out of a legacy operating mode. For example, BIOSes often configure CardBus controllers in a legacy mode to support legacy operating systems. Before enumerating the device with an ACPI operating system, the CardBus controllers must be initialized to CardBus mode. For such systems, the vendor can include an _INI control method under the CardBus controller to switch the device into CardBus mode.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 193
For example, until the Embedded Controller driver is ready, the control methods cannot access the Embedded Controller. Once OSPM has run _REG(EmbeddedControl, 1), the control methods can then access operation regions in Embedded Controller address space. Furthermore, if OSPM executes _REG(EmbeddedControl, 0), control methods must stop accessing operation regions in the Embedded Controller address space. The exceptions for this rule are: 1. OSPM must guarantee that the following operation regions must always be accessible: PCI_Config operation regions on a PCI root bus containing a _BBN object. I/O operation regions. Memory operation regions when accessing memory returned by the System Address Map reporting interfaces. 2. OSPM must make Embedded Controller operation regions, accessed via the Embedded Controllers described in ECDT, available before executing any control method. These operation regions may become inaccessible after OSPM runs _REG(EmbeddedControl, 0). Place _REG in the same scope as operation region declarations. The OS will run the _REG in a given scope when the operation regions declared in that scope are available for use. For example:
Scope(\_SB.PCI0) { OperationRegion(OPR1, PCI_Config, ...) Method(_REG, 2) {...} // OSPM executes this when PCIO operation region handler // status changes Device(PCI1) { Method(_REG, 2) {...} Device(ETH0) { OperationRegion(OPR2, PCI_Config, ...) Method(_REG,2) {...} } } Device(ISA0) { OperationRegion(OPR3, I/O, ...) Method(_REG, 2) {...} // OSPM executes this when ISAO operation region handler // status changes Device(EC0) { Name(_HID, EISAID("PNP0C09")) OperationRegion(OPR4, EC, ...) Method(_REG, 2) {...} // OSPM executes this when EC operation region // handler status changes } } }
Compaq/Intel/Microsoft/Phoenix/Toshiba
194 Advanced Configuration and Power Interface Specification When the PCI0 operation region handler is ready, OSPM will run the _REG method declared in PCI0 scope to indicate that PCI Config space operation region access is available within the PCI0 scope (in other words, OPR1 access is allowed). When the ISA0 operation handler is ready, OSPM will run the _REG method in the ISA0 scope to indicate that the I/O space operation region access is available within that scope (in other words, OPR3 access is allowed). Finally, when the Embedded Controller operation region handler is ready, OSPM will run the _REG method in the EC0 scope to indicate that EC space operation region access is available within the EC0 scope (in other words, OPR4 access is allowed). It should be noted that PCI Config Space Operation Regions are ready as soon the host controller or bridge controller has been programmed with a bus number. PCI1s _REG method would not be run until the PCI-PCI bridge has been properly configured. At the same time, the OS will also run ETH0s _REG method since its PCI Config Space would be also available. The OS will again run ETH0s _REG method when the ETH0 device is started. Also, when the host controller or bridge controller is turned off or disabled, PCI Config Space Operation Regions for child devices are no longer available. As such, ETH0s _REG method will be run when it is turned off and will again be run when PCI1 is turned off. Note : The OS only runs _REG methods that appear in the same scope as operation region declarations that use the operation region type that has just been made available. For example, _REG in the EC device would not be run when the PCI bus driver is loaded since the operation regions declared under EC do not use any of the operation region types made available by the PCI driver (namely, config space, I/O, and memory). Arguments: Arg0: Integer: Operation region space: 0Memory 1I/O 2PCI_Config 3Embedded Controller 4SMBus 5CMOS 6PCIBARTarget 0x80-0xff OEM region space handler Arg1: Integer: 1 for connecting the handler, 0 for disconnecting the handler
Compaq/Intel/Microsoft/Phoenix/Toshiba
Configuration 195
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
198 Advanced Configuration and Power Interface Specification A Power Resource can have named objects under its Namespace location. For a description of the ACPIdefined named objects for a Power Resource, see section 7.2, Device Power Management Objects. The following block of ASL sample code shows a use of PowerResource.
PowerResource(PIDE, 0, 0) { Method(_STA) { Return (Xor (GIO.IDEI, One, Zero)) // inverse of isolation } Method(_ON) { Store (One, GIO.IDEP) // assert power Sleep (10) // wait 10ms Store (One, GIO.IDER) // de-assert reset# Stall (10) // wait 10us Store (Zero, GIO.IDEI) // de-assert isolation } Method(_OFF) { Store (One, GIO.IDEI) // assert isolation Store (Zero, GIO.IDER) // assert reset# Store (Zero, GIO.IDEP) // de-assert power } }
7.1.2 _OFF
This power resource control method puts the power resource into the OFF state. The control method does not complete until the power resource is off. OSPM only turns on or off one resource at a time, so the AML code can obtain the proper timing sequencing by using Stall or Sleep within the ON (or OFF) method to cause the proper sequencing delays between operations on power resources. Arguments: None Result Code: None
Compaq/Intel/Microsoft/Phoenix/Toshiba
7.1.3 _ON
This power resource control method puts the power resource into the ON state. The control method does not complete until the power resource is on. OSPM only turns on or off one resource at a time, so the AML code can obtain the proper timing sequencing by using Stall or Sleep within the ON (or OFF) method to cause the proper sequencing delays between operations on power resources. Arguments: None Result Code: None
Compaq/Intel/Microsoft/Phoenix/Toshiba
200 Advanced Configuration and Power Interface Specification For systems that do not control device power states through power plane management, but whose devices support multiple D-states, more information is required by the OS to determine the S-state to D-state mapping for the device. The ACPI BIOS can give this information to OSPM by way of the _SxD methods. These methods tell OSPM for S-state x, the highest D-state supported by the device is y. OSPM is allowed to pick a lower D-state for a given S-state, but OSPM is not allowed to exceed the given D-state. Further rules that apply to device power management objects are: For a given S-state, a device cannot be in a higher D-state than its parent device. If there exists an ACPI Object to turn on a device (either through _PSx or _PRx objects), then a corresponding object to turn the device off must also be declared and vice versa. If there exists an ACPI Object that controls power (_PSx or _PRx , where x =0, 1, 2, or 3), then methods to set the device into D0 and D3 device states must be present. If a mixture of _PSx and _PRx methods is declared for the device, then the device states supported through _PSx methods must be identical to the device states supported through _PRx methods. ACPI system firmware may enable device power state control exclusively through _PSx (or _PRx ) method declarations. Table 7-2 Device Power Management ChildObjects Object _PS0 _PS1 _PS2 _PS3 _PSC _PR0 _PR1 Description Control method that puts the device in the D0 device state (device fully on). Control method that puts the device in the D1 device state. Control method that puts the device in the D2 device state. Control method that puts the device in the D3 device state (device off). Object that evaluates to the devices current power state. Object that evaluates to the devices power requirements in the D0 device state (device fully on). Object that evaluates to the devices power requirements in the D1 device state. The only devices that supply this level are those that can achieve the defined D1 device state according to the related device class. Object that evaluates to the devices power requirements in the D2 device state. The only devices that supply this level are those that can achieve the defined D2 device state according to the related device class. Object that evaluates to the devices power requirements in order to wake the system from a system sleeping state. Control method that enables or disables the devices wake function. Object that signifies the device has a significant inrush current draw. Highest D-state supported by the device in the S1 state Highest D-state supported by the device in the S2 state Highest D-state supported by the device in the S3 state Highest D-state supported by the device in the S4 state
_PR2
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
For OSPM to put the device in the D0 device state, the following must occur: 1. All Power Resources referenced by elements 1 through N must be in the ON state. 2. All Power Resources no longer referenced by any device in the system must be in the OFF state. 3. If present, the _PS0 control method is executed to set the device into the D0 device state. _PR0 must return the same data each time it is evaluated. All power resources referenced must exist in the namespace.
Compaq/Intel/Microsoft/Phoenix/Toshiba
1 2 N
The lowest power system sleeping state that can be entered while still providing wake functionality. Reference to required Power Resource #0 Reference to required Power Resource #N
For OSPM to have the defined wake capability properly enabled for the device, the following must occur: 1. All Power Resources referenced by elements 2 through N are put into the ON state. 2. If present, the _PSW control method is executed to set the device-specific registers to enable the wake functionality of the device.
Compaq/Intel/Microsoft/Phoenix/Toshiba
204 Advanced Configuration and Power Interface Specification Then, if the system wants to enter a sleeping state: 1. Interrupts are disabled. 2. The sleeping state being entered must be greater or equal to the power state declared in element 1 of the _PRW object. 3. The proper general-purpose register bits are enabled. The system sleeping state specified must be a state that the system supports (in other words, a corresponding \_Sx object must exist in the namespace). _PRW must return the same data each time it is evaluated. All power resources referenced must exist in the namespace.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
206 Advanced Configuration and Power Interface Specification The _PTS control method cannot modify the current configuration or power state of any device in the system. For example, _PTS would simply store the sleep type in the embedded controller in sequencing the system into a sleep state when the SLP_EN bit is set. Arguments: 0: The value of the sleeping state (1 for S1, 2 for S2, and so on).
Description Value for PM1a_CNT.SLP_TYP register to enter this system state. Value for PM1b_CNT.SLP_TYP register to enter this system state. To enter any given state, OSPM must write the PM1a_CNT.SLP_TYP register before the PM1b_CNT.SLP_TYP register. Reserved
States S1S4 represent some system sleeping state. The S0 state is the system working state. Transition into the S0 state from some other system state (such as sleeping) is automatic, and, by virtue that instructions are being executed, OSPM assumes the system to be in the S0 state. Transition into any system sleeping state is only accomplished by the operating software directing the hardware to enter the appropriate state, and the operating software can only do this within the requirements defined in the Power Resource and Bus/Device Package objects.
Compaq/Intel/Microsoft/Phoenix/Toshiba
All run-time system state transitions (for example, to and from the S0 state), except S4 and S5, are done similarly such that the code sequence to do this is the following:
/* Intel Architecture SetSleepingState example */ ULONG SetSystemSleeping ( IN ULONG NewState ) { PROCESSOR_CONTEXT Context; ULONG PowerSeqeunce; BOOLEAN FlushCaches; USHORT SlpTyp; // // // // Required environment: Executing on the system boot processor. All other processors stopped. Interrupts disabled. All Power Resources (and devices) are in corresponding device state to support NewState. // Get h/w attributes for this system state FlushCaches = SleepType[NewState].FlushCache; SlpTyp = SleepType[NewState].SlpTyp & SLP_TYP_MASK; _asm { lea eax, OsResumeContext push eax push offset sp50 call SaveProcessorState mov mov mov mov out mov out and or or cmp jz call sp10: mov out mov out mov mov sp20: in xchg test jz
; Build real mode handler the resume ; context, with eip = sp50
eax, ResumeVector ; set firmwares resume vector [eax], offset OsRealModeResumeCode edx, PM1a_STS ax, WAK_STS dx, ax edx, PM1b_STS dx, ax ;Make sure wake status is clear ; (cleared by asserting the bit ; in the status register) ; ;
eax, not SLP_TYP_MASK eax, SlpTyp ; set SLP_TYP ax, SLP_EN ; set SLP_EN FlushCaches, 0 short sp10 FlushProcessorCaches edx, PM1a_SLP_TYP dx, ax edx, PM1b_SLP_TYP dx, ax edx, PM1a_STS ecx, PM1b_STS ax, dx edx, ecx ax, WAK_STS short sp20 ; If needed, ensure no dirty data in ; the caches while sleeping ; ; ; ; get address for PM1a_SLP_TYP start h/w sequencing get address for PM1b_SLP_TYP start h/w sequencing
Compaq/Intel/Microsoft/Phoenix/Toshiba
10
Or it is at least assumed to be in the D3 state by its device driver. For example, if the device doesnt explicitly describe how it can stay in some state non-off state while the system is in a sleeping state, the operating software must assume that the device can lose its power and state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
11
Only buses that support hardware-defined enumeration methods are done automatically at run-time. This would include ACPI-enumerated devices. Compaq/Intel/Microsoft/Phoenix/Toshiba
8 Processor Control
This section describes OSPM run-time aspects of managing the processors performance, power consumption, and other controls while the system is in the working state12 . The major controls over the processors are: Processor power states: C0, C1, C2, C3Cn Processor clock throttling Processor performance states: P0, P1, Pn These controls are used in combination by OSPM to achieve the desired balance of the following sometimes conflicting goals: Performance Power consumption and battery life Thermal requirements Noise-level requirements Because the goals interact with each other, the operating software needs to implement a policy as to when and where tradeoffs between the goals are to be made13 . For example, the operating software would determine when the audible noise of the fan is undesirable and would trade off that requirement for lower thermal requirements, which can lead to lower processing performance. Each processor control is discussed in the following sections along with how the control interacts with the various goals.
12
In any system sleeping state, the processors are not executing instructions (that is, they are not run-time), and the power consumption is fixed as a property of that system state.
13
A thermal warning leaves room for operating system tradeoffs to occur (to start the fan or to reduce performance), but a critical thermal alert does not occur.
14
Notice that these CPU states map into the G0 working state. The state of the CPU is undefined in the G3 sleeping state, the Cx states only apply to the G0 state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Performance State Px
C0
Throttling
C1
C2
C3
G0 Working
Figure 8-1 Processor Power States ACPI defines logic on a per-CPU basis that OSPM uses to transition between the different processor power states. This logic is optional, and is described through the FADT table and processor objects (contained in the hierarchical namespace). The fields and flags within the FADT table describe the symmetrical features of the hardware, and the processor object contains the location for the particular CPUs clock logic (described by the P_BLK register block and _CST objects). The P_LVL2 and P_LVL3 registers provide optional support for placing the system processors into the C2 or C3 states. The P_LVL2 register is used to sequence the selected processor into the C2 state, and the P_LVL3 register is used to sequence the selected processor into the C3 state. Additional support for the C3 state is provided through the bus master status and arbiter disable bits (BM_STS in the PM1_STS register and ARB_DIS in the PM2_CNT register). System software reads the P_LVL2 or P_LVL3 registers to enter the C2 or C3 power state. The Hardware must put the processor into the proper clock state precisely on the read operation to the appropriate P_LVLx register. Processor power state support is symmetric; OSPM assumes all processors in a system support the same power states. If processors have non-symmetric powe r state support, then the BIOS will choose and use the lowest common power states supported by all the processors in the system through the FADT table. For example, if the CPU0 processor supports all power states up to and including the C3 state, but the CPU1 processor only supports the C1 power state, then OSPM will only place idle processors into the C1 power state (CPU0 will never be put into the C2 or C3 power states). Notice that the C1 power state must be supported. The C2 and C3 power states are optional (see the PROC_C1 flag in the FADT table description in section 5.2.5, System Description Table Header). The following sections describe processor power states in detail.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Figure 8-2 Throttling Example The FADT contains the duty offset and duty width values. The duty offset value determines the offset within the P_CNT register of the duty value. The duty width value determines the number of bits used by the duty value (which determines the granularity of the throttling logic). The performance of the processor by the clock logic can be expressed with the following equation:
% Performance =
Nominal performance is defined as close as possible, but not below the indicated performance level. OSPM will use the duty offset and duty width to determine how to access the duty setting field. OSPM will then program the duty setting based on the thermal condition and desired power of the processor object. OSPM calculates the nominal performance of the processor using the equation expressed in Equation 1. Notice that a dutysetting of zero is reserved.
Compaq/Intel/Microsoft/Phoenix/Toshiba
214 Advanced Configuration and Power Interface Specification For example, the clock logic could use the stop grant cycle to emulate a divided processor clock frequency on an IA processor (through the use of the STPCLK# signal). This signal internally stops the processors clock when asserted LOW. To implement logic that provides eight levels of clock control, the STPCLK# pin could be asserted as follows (to emulate the different frequency settings):
Duty Width (3-bits)
0
dutysetting
0 - Reserved Value
STPCLK# Signal
1 2 3 4 5 6 7
Figure 8-3 Example Control for the STP CLK#
CPU Clock Running CPU Clock Stopped
To start the throttling logic OSPM sets the desired duty setting and then sets the THT_EN bit HIGH. To change the duty setting, OSPM will first reset the THT_EN bit LOW, then write another value to the duty setting field while preserving the other unused fields of this register, and then set the THT_EN bit HIGH again. The example logic model is shown below:
P_LVL3 Read P_LVL2 Read BM_RLD PM1x_CNT.1 ARB_DIS BM_STS PM2_CNT PM1x_STS.4
Clock Logic
THT_EN P_CNT.4
THTL_DTY P_CNT.x
Figure 8-4 ACPI Clock Logic (One per Processor) Implementation of the ACPI processor power state controls minimally requires the support a single CPU sleeping state (C1). All of the CPU power states occur in the G0/S0 system state; they have no meaning when the system transitions into the sleeping state(S1-S4). ACPI defines the attributes (semantics) of the different CPU states (defines four of them). It is up to the platform implementation to map an appropriate low-power CPU state to the defined ACPI CPU state. ACPI clock control is supported through the optional processor register block (P_BLK). ACPI requires that there be a unique processor register block for each CPU in the system. Additionally, ACPI requires that the clock logic for multiprocessor systems be symmetrical; if the P0 processor supports the C1, C2, and C3 states, but P1 only supports the C1 state, then OSPM will limit all processors to enter the C1 state when idle. The following sections define the different ACPI CPU sleeping states.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
216 Advanced Configuration and Power Interface Specification There are two mechanisms for supporting the C3 power state: Having OSPM flush and invalidate the caches prior to entering the C3 state. Providing hardware mechanisms to prevent masters from writing to memory (uniprocessor-only support). In the first case, OSPM will flush the system caches prior to entering the C3 state. As there is normally much latency associated with flushing processor caches, OSPM is likely to only support this in multiprocessor platforms for idle processors. Flushing of the cache is accomplished through one of the defined ACPI mechanisms (described below in section 8.2.4.1, Flushing Caches). In uniprocessor-only platforms that provide the needed hardware functionality (defined in this section), OSPM will attempt to place the platform into a mode that will prevent system bus masters from writing into memory while the processor is in the C3 state. This is accomplished by disabling bus masters prior to entering a C3 power state. Upon a bus master requesting an access, the CPU will awaken from the C3 state and re-enable bus master accesses. OSPM uses the BM_STS bit to determine the power state to enter when considering a transition to or from the C2/C3 power state. The BM_STS is an optional bit that indicates when bus masters are active. OSPM uses this bit to determine the policy between the C2 and C3 power states: alot of bus master activity demotes the CPU power state to the C2 (or C1 if C2 is not supported), no bus master activity promotes the CPU power state to the C3 power state. OSPM keeps a running history of the BM_STS bit to determine CPU power state policy. The last hardware feature used in the C3 power state is the BM_RLD bit. This bit determines if the Cx power state was exited as a result of bus master requests. If set, then the Cx power state was exited upon a request from a bus master. If reset, the power state was not exited upon bus master requests. In the C3 state, bus master requests need to transition the CPU back to the C0 state (as the system is capable of maintaining cache coherency), but such a transition is not needed for the C2 state. OSPM can optionally set this bit when using a C3 power state, and clear it when using a C1 or C2 power state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
If the platform supports neither of the first two flushing options, then OSPM can attempt to manually flush the cache if it meets the following criteria: A cache-enabled sequential read of contiguous physical memory of not more than 2 MB will flush the platform caches. There are two additional FADT fields needed to support manual flushing of the caches: FLUSH_SIZE, typically twice the size of the largest cache in the system. FLUSH_STRIDE, typically the smallest cache line size in the system.
Compaq/Intel/Microsoft/Phoenix/Toshiba
218 Advanced Configuration and Power Interface Specification Notice that if the _PTC object exists, the specified register is used instead of the P_CNT register specified in the Processor term. Also notice that if the _PTC object exists and the _CST object does not exist, OSPM will use the processor control register from the _PTC object and the P_LVLx registers from the P_BLK. EXAMPLE This is an example usage of the _PTC object in a Processor object list:
Processor ( \_SB.CPU0, 1, 0x120, 6 ) { //Object List // // // // Processor Name ACPI Processor number PBlk system IO address PBlkLen
EXAMPLE This is an example usage of the _PTC object using the values defined in ACPI 1.0. This is an illustrative example to demonstrate the mechanism with well-known values.
Processor ( \_SB.CPU0, 1, 0x120, 6 ) { // // // // Processor Name ACPI Processor number PBLK system IO address PBLK Len
//Object List Name(_PTC, // 32 bit wide IO space-based register at the <P_BLK> address ResourceTemplate() { Register(SystemIO, 32, 0, 0x120) } ) //End of _PTC Object
Compaq/Intel/Microsoft/Phoenix/Toshiba
The _CST object evaluates to a package that declares the available C-states as follows: Name (_CST, Package() {// Field Name C States_Defined, Field Type //ByteConst
// C State Definition - 0
// C State Definition - n
})
The C States_Defined field indicates the number of C state entries that follow. Each C State definition entry is a package that describes the C State. A read of the C State_Register places the CPU in the corresponding C State. The Generic Register Descriptor format is described in section 6.4.3.7, Generic Register Descriptor (Type 1, Large Item Name 0x2). The description of the remaining package fields is as follows: C State_Type . The C State type (for example, 0=C0, 1=C1, and so on).This field conveys the semantics used by OSPM when entering the C state. Latency. The worst-case latency in microseconds to enter and exit the C State. Power Consumption. Average power consumption in milliwatts when in the C State. Notice that if the _CST object exists, the power states specified in the _CST object are used in lieu of P_LVL2 and P_LVL3 registers defined in P_BLK and the P_LVLx_LAT values defined in the FADT. Also notice that if the _CST object exists and the _PTC object does not exist, OSPM will use the processor control register defined in P_BLK and the P_LVLx registers in the _CST object.
Compaq/Intel/Microsoft/Phoenix/Toshiba
220 Advanced Configuration and Power Interface Specification The number or type of available C States may change dynamically. As such, ACPI 2.0 supports Notify events on the processor object. Notify events of type 0x81 will cause OSPM to re-evaluate any _CST objects residing under the particular processor object notified. This allows AML code to notify OSPM when the number of supported C States may have changed as a result of an asynchronous event (AC insertion/removal, and so on).
The fields in the processor structure remain for backward compatibility.
EXAMPLE This is an example usage of the _CST structure using the values defined in ACPI 1.0.
Processor ( \_SB.CPU0, // Processor Name 1, // ACPI Processor number 0x120, // PBLK system IO address 6 ) // PBLK Len { Name(_CST, Package() { 2, // There are two C-states defined here C2 and C3 Package(){ResourceTemplate(){Register(SystemIO, 8, 0, 0x124)}, 2, 2, 750}, Package(){ResourceTemplate(){Register(SystemIO, 8, 0, 0x125)}, 3, 65, 500} }) }
The platform will issue a Notify (\_SB.CPU0, 0x81) to inform OSPM to re-evaluate this object when the number of available processor power states changes.
Compaq/Intel/Microsoft/Phoenix/Toshiba
In a multiprocessing environment, all CPUs must support the same number of performance states and each processor performance state must have identical performance and power-consumption parameters. Performance objects must be present under each processor object in the system for OSPM to utilize this feature. Processor performance control objects include the _PCT package, _PSS package, and the _PPC method as detailed below.
Compaq/Intel/Microsoft/Phoenix/Toshiba
TransitionLatency, BusMasterLatency, Control, Status }, . . . Package () { CoreFreq, Power, TransitionLatency, BusMasterLatency, Control, Status }
})
Compaq/Intel/Microsoft/Phoenix/Toshiba
Each performance state entry contains six data fields as follows: CoreFreq. Indicates the core CPU operating frequency (in MHz). Power. Indicates the typical power dissipation (in milliWatts). TransitionLatency. Indicates the worst-case latency in microseconds that the CPU is unavailable during a transition from any performance state to this performance state. BusMasterLatency. Indicates the worst-case latency in microseconds that Bus Masters are prevented from accessing memory during a transition from any performance state to this performance state. Control. Indicates the value to be written to the Performance Control Register (PERF_CTRL) in order to initiate a transition to the performance state. Status. Indicates the value that OSPM will compare to a value read from the Performance Status Register (PERF_STATUS) to ensure that the transition to the performance state was successful. OSPM may always place the CPU in the lowest power state, but additional states are only available when indicated by the _PPC method.
Compaq/Intel/Microsoft/Phoenix/Toshiba
224 Advanced Configuration and Power Interface Specification It takes no more than 500 microseconds to transition from one performance state to any other performance state. During a performance transition, bus masters are unable to access memory for a maximum of 300 microseconds. The PERF_CTRL and PERF_STATUS registers are implemented as Functional Fixed Hardware. The following ASL objects are implemented within the system: \_SB.DOCK: \_SB.AC: Evaluates to 1 if system is docked, zero otherwise. Evaluates to 1 if AC is connected, zero otherwise.
Processor ( \_SB.CPU0, // Processor Name 1, // ACPI Processor number 0x120, // PBlk system IO address 6 ) // PBlkLen { Name(_PCT, Package () // Performance Control object { ResourceTemplate(){Register(FFixedHW, 0, 0, 0)}, ResourceTemplate(){Register(FFixedHW, 0, 0, 0)} }) // End of _PCT object Name (_PSS, Package() { Package(){650, 21500, 500, 300, 0x00, 0x08}, Package(){600, 14900, 500, 300, 0x01, 0x05}, Package(){500, 8200, 500, 300, 0x02, 0x06} }) // End of _PSS object
// PERF_CTRL // PERF_STATUS
// Performance State zero (P0) // Performance State one (P1) // Performance State two (P2)
Method (_PPC, 0) // Performance Present Capabilities method { If (\_SB.DOCK) { Return(0) // All _PSS states available (650, 600, 500). } If (\_SB.AC) { Return(1) } Else { Return(2) // State 2 available (500) } // End of _PPC method
} }
The platform will issue a Notify (\_SB.CPU0, 0x80) to inform OSPM to re-evaluate this object when the number of available processor performance states changes.
Compaq/Intel/Microsoft/Phoenix/Toshiba
15
OSPM uses the RTC wakeup feature to program in the time transition delay. Prior to sleeping, OSPM will program the RTC alarm to the closest (in time) wakeup event: either a transition to a lower power sleeping state, or a calendar event (to run some application).
16
Notice that there can be two fixed PM1x_CNT registers, each pointing to a different system I/O space region. Normally a register grouping only allows a bit or bit field to reside in a single register group instance (a or b); however, each platform can have two instances of the SLP_TYP (one for each grouping register: a and b). The \_Sx control method gives a package with two values: the first is the SLP_TYPa value and the second is the SLP_TYPb value.
Compaq/Intel/Microsoft/Phoenix/Toshiba
226 Advanced Configuration and Power Interface Specification This section discusses the system initialization sequence of an ACPI-enabled platform. This includes the boot sequence, different wake scenarios, and an example to illustrate how to use the system address map reporting interfaces. This sequence is part of the ACPI event programming model. For detailed information on the power management control methods described above, see section 7, Power and Performance Management.
S1 Sleeping
Wake Event SLP_TYPx=S1 and SLP_EN SLP_TYPx=S2 and SLP_EN
S2 Sleeping G1 S3 Sleeping
G0 (S0) Working
SLP_TYPx=S5 and SLP_EN or PWRBTN_OR
S4BIOS_REQ to SMI_CMD
S4 Sleeping
SLP_TYPx=S4 and SLP_EN
Figure 9-1 Example Sleeping States ACPI defines distinct differences between the G0 and G1 system states. In the G0 state, work is being performed by the OS/application software and the hardware. The CPU or any particular hardware device could be in any one of the defined power states (C0-C3 or D0-D3); however, some work will be taking place in the system. In the G1 state, the system is assumed to be doing no work. Prior to entering the G1 state, OSPM will place devices in a device power state compatible with the system sleeping state to be entered; if a device is enabled to wake the system, then OSPM will place these devices into the lowest Dx state from which the device supports wake. This is defined in the power resource description of that device object. This definition of the G1 state implies: The CPUs execute no instructions in the G1 state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Hardware devices are not operating (except possibly to generate a wake event). ACPI registers are affected as follows: Wake event bits are enabled in the corresponding fixed or general-purpose registers according to enabled wake options. PM1 control register is programmed for the desired sleeping state. WAK_STS is set by hardware in the sleeping state.
All sleeping states have these specifications. ACPI defines additional attributes that allow an ACPI platform to have up to four different sleeping states, each of which has different attributes. The attributes were chosen to allow differentiation of sleeping states that vary in power, wake latency, and implementation cost tradeoffs. Running processors at reduced levels of performance is not an ACPI sleeping state (G1); this is a working (G0) statedefined event. The CPU cannot execute any instructions when in the sleeping state; OSPM relies on this fact. A platform designer might be tempted to support a sleeping system by reducing the clock frequency of the system, which allows the platform to maintain a low-power state while at the same time maintaining communication sessions that require constant interaction (as with some network environments). This is definitely a G0 activity where an OS policy decision has been made to turn off the user interface (screen) and run the processor in a reduced performance mode. This type of reduced performance state as a sleeping state is not defined by the ACPI specification; ACPI assumes no code execution during sleeping states. ACPI defines attributes for four sleeping states: S1, S2, S3 and S4. (Notice that S4 and S5 are very similar from a hardware standpoint.) At least one sleeping state, S1-S4, must be implemented by an ACPIcompatible system. Platforms can support multiple sleeping states. ACPI specifies that a 3-bit binary number be associated with each sleeping state (these numbers are given objects within ACPIs root namespace: \_S0, \_S1, \_S2, \_S3, \_S4 and \_S5). When entering a system sleeping state, OSPM will do the following: 1. Pick the deepest sleeping state supported by the platform and enabled waking devices. 2. Execute the _PTS control method (which passes the type of intended sleep state to OEM AML code) if it is an S1S4 sleeping state. 3. If OS policy decides to enter the S4 state and chooses to use the S4BIOS mechanism and S4BIOS is supported by the platform, OSPM will pass control to the BIOS software by writing the S4BIOS_REQ value to the SMI_CMD port. 4. If not using the S4BIOS mechanism, OSPM gets the SLP_TYPx value from the associated sleeping object (\_S1, \_S2, \_S3, \_S4 or \_S5). 5. Program the SLP_TYPx fields with the values contained in the selected sleeping object. 6. Execute the _GTS control method, passing an argument that indicates the sleeping state to be entered (1, 2, 3, or 4 representing S1, S2, S3, and S4). 7. If entering S1, S2, or S3, flush the processor caches. 8. If not entering S4BIOS, set the SLP_EN bit to start the sleeping sequence. (This actually occurs on the same write operation that programs the SLP_TYPx field in the PM1_CNT register.) If entering S4BIOS, write the S4BIOS_REQ value into the SMI_CMD port. 9. On systems containing processors without a hardware mechanism to place the processor in a lowpower state, execute appropriate native instructions to place the processor in a low-power state. The _PTS control method provides the BIOS a mechanism for performing some housekeeping, such as writing the sleep type value to the embedded controller, before entering the system sleeping state. Control method execution occurs just prior to entering the sleeping state and is not an event synchronized with the write to the PM1_CNT register. Execution can take place several seconds prior to the system actually entering the sleeping state. As such, no hardware power-plane sequencing takes place by execution of the _PTS control method. Upon waking, the _BFS control method is executed. OSPM then executes the _WAK control method. This control method executes OEM-specific ASL/AML code that can search for any devices that have been added or removed during the sleeping state. The following sections describe the sleeping state attributes.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
230 Advanced Configuration and Power Interface Specification In the BIOS-initiated S4 sleeping state, OSPM is responsible for the same system context as described in the S3 sleeping state (BIOS restores the memory and some chip set context). The S4BIOS transition transfers control to the BIOS, allowing it to save context to non-volatile memory (such as a disk partition).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
9.3 Initialization
This section covers the initialization sequences for an ACPI platform. After a reset or wake from an S2, S3, or S4 sleeping state (as defined by the ACPI sleeping state definitions), the CPU will start execution from its boot vector. At this point, the initialization software has many options, depending on what the hardware platform supports. This section describes at a high level what should be done for these different options. Figure 9-2 illustrates the flow of the boot-up software.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Boot Vector
SLP_TYP=S2 ?
No
Yes
Initialize CPU Init Memory Controller Enable Memory Configure Caches Enable Caches Initialize Chipset
SLP_TYP=S3 ?
Yes
No
SLP_TYP= S4BIOS ?
No
Yes
POST
Initialize Memory Image * System * Reserved * ACPI NVS * ACPI Reclaim * ACPI Tables * MPS Tables * ...
Boot OS Loader
Figure 9-2 BIOS Initialization
Compaq/Intel/Microsoft/Phoenix/Toshiba
234 Advanced Configuration and Power Interface Specification The processor will start executing at its power-on reset vector when waking from an S2, S3, or S4 sleeping state during a power-on sequence or during a hard or soft reset. The sleeping attributes are such that the power-on sequence (and hard and soft reset) is similar to waking from an S4 state, the system is configured to a boot configuration, and then OSPM loader is called. Waking in the S2, S3, or S4 states only requires a partial configuration by the hardware, followed by jumping to the firmware waking vector (found in the FACS). First, the BIOS determines whether this is a wake from S2 or S3 by examining the SLP_TYP register value, which is preserved between sleeping sessions. If this is an S2 or S3 wake, then the BIOS restores minimum context of the system before jumping to the waking vector. This includes: CPU configuration. BIOS restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, BIOS update, SMBase, and so on). Interrupts must be disabled (for IA-32 processors, disabled by CLI instruction). Memory controller configuration. If the configuration is lost during the sleeping state, the BIOS initializes the memory controller to its pre-sleep configuration or initial boot configuration. Cache memory configuration. If the configuration is lost during the sleeping state, the BIOS initializes the cache controller to its pre-sleep configuration or initial boot configuration. Functional device configuration. The BIOS doesnt need to configure/restore context of functional devices such as a network interface (even if it is physically included in chipset) or interrupt controller. OSPM is responsible for restoring all context of these devices. The only requirement for the hardware and BIOS is to ensure that interrupts are not asserted by devices when the control is passed to OS. ACPI registers. SCI_EN bit must be set. All event status/enable bits (PM1x_STS, PM1x_EN, GPEx_STS and GPEx_EN) must not be changed by BIOS. Note: The BIOS may reconfigure the CPU, memory controller and cache memory controller to either the pre-sleeping configuration or the initial boot configuration. OSPM must accommodate both configurations. When waking from an S4BIOS sleeping state, the BIOS initializes a minimum number of devices such as CPU, memory, cache, chipset and boot devices. After initializing these devices, the BIOS restores memory context from non-volatile memory such as hard disk, and jumps to waking vector. As mentioned previously, waking from an S4 state is treated the same as a cold boot: the BIOS runs POST and then initializes memory to contain the ACPI system description tables. After it has finished this, it can call OSPM loader, and control is passed to OSPM. When waking from S4 (either S4OS or S4BIOS), the BIOS may optionally set SCI_EN bit before passing control to OSPM. In this case, interrupts must be disabled (for IA-32 processors, disabled CLI instruction) until the control is passed to OSPM and the chipset must be configured in ACPI mode.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
236 Advanced Configuration and Power Interface Specification The names and attributes of the different memory regions are listed below: 0640 KB. Compatibility Memory. Application executable memory for an 8086 system. 640 KB1 MB. Compatibility Holes. Holes within memory space that allow accesses to be directed to the PC-compatible frame buffer (A0000h-BFFFFh), to adapter ROM space (C0000h-DFFFFh), and to system BIOS space (E0000h-FFFFFh). 1 MB8 MB. Contiguous RAM. An area of contiguous physical memory addresses. Operating systems may require this memory to be contiguous in order for its loader to load the OS properly on boot up. (No memory-mapped I/O devices should be mapped into this area.) 8 MBTop of Memory1. This area contains memory to the top of memory1 boundary. In this area, memory-mapped I/O blocks are possible. Boot Base4 GB. This area contains the bootstrap ROM. The BIOS should decide where the different memory structures belong, and then configure the E820 handler to return the appropriate values. For this example, the BIOS will report the system memory map by E820 as shown in Figure 9-4. Notice that the memory range from 1 MB to top of memory is marked as system memory, and then a small range is additionally marked as ACPI reclaim memory. A legacy OS that does not support the E820 extensions will ignore the extended memory range calls and correctly mark that memory as system memory.
Reserved Memory Available Address space Reserved Memory ACPI NVS Memory Reserved NVS Memory Top of Memory1 Above 8 Mbyte RAM ACPI Reclaim Memory ACPI Tables 8 MBytes System Memory Reserved Memory Available Address space Compatibility Memory 0 Contiguous RAM 1 MByte Compatibility Holes - System Memory (E820) - Reserved Memory (E820) - ACPI Reclaim Memory (E820) - ACPI NVS Memory (E820) Boot ROM No Memory Top of Memory2
640 KByte
System Memory
Figure 9-4 Memory as Configured after Boot Also, from the Top of Memory1 to the Top of Memory2, the BIOS has set aside some memory for its own use and has marked as reserved both ACPI NVS Memory and Reserved Memory. A legacy OS will throw out the ACPI NVS Memory and correctly mark this as reserved memory (thus preventing this memory range from being allocated to any add-in device).
Compaq/Intel/Microsoft/Phoenix/Toshiba
OSPM will call the _PTS control method prior to initiating a sleep (by programming the sleep type, followed by setting the SLP_EN bit). During a catastrophic failure (where the integrity of the AML code interpreter or driver structure is questionable), if OSPM decides to shut the system off, it will not issue a _PTS, but will immediately issue a SLP_TYP of soft off and then set the SLP_EN bit. Hence, the hardware should not rely solely on the _PTS control method to sequence the system to the soft off state. After waking from an S4 state, OSPM will restore the ACPI NVS memory image and then issue the _WAK control method that informs BIOS that its memory image is back.
9.3.3 OS Loading
At this point, the BIOS has passed control to OSPM, either by using OSPM boot loader (a result of waking from an S4/S5 or boot condition) or OSPM waking vector (a result of waking from an S2 or S3 state). For the Boot OS Loader path, OSPM will get the system address map via one of the mechanisms describe in section 15, System Address Map Interfaces. If OSPM is booting from an S4 state, it will then check the NVS image files hardware signature with the hardware signature within the FACS table (built by BIOS) to determine whether it has changed since entering the sleeping state (indicating that the platforms fundamental hardware configuration has changed during the current sleeping state). If the signature has changed, OSPM will not restore the system context and can boot from scratch (from the S4 state). Next, for an S4 wake, OSPM will check the NVS file to see whether it is valid. If valid, then OSPM will load the NVS image into system memory. Next, OSPM will check the SCI_EN bit and if it is not set, will write the ACPI_ENABLE value to the SMI_CMD register to switch into the system into ACPI mode and will then reload the memory image from the NVS file.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Get Memory Map (E820) * ACPI NVS * ACPI Reclaim * Reserved * System * Reserved
NVS File ?
No
Yes
Sanity Check
Compare memory and volume SSN No
Load OS Images
Yes
Memory Copy
SCI_EN set?
No
Yes
Turn on ACPI
Execute _BFS
Execute _WAK
Continue
Figure 9-5 OS Initialization If an NVS image file did not exist, then OSPM loader will load OSPM from scratch. At this point, OSPM will generate a _WAK call that indicates to the BIOS that its ACPI NVS memory image has been successfully and completely updated.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
10.3.1 _LID
Evaluates to the current status of the lid. Result Code: Zero: Non-zero: The lid is closed The lid is open
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
_GTM - Control method to get current IDE channel settings _STM _PR0 - Control method to set current IDE channel settings - Power resources needed for D0 power state DRV1 - Drive 0 _ADR _GTF DRV2 - Drive 1 _ADR _GTF IDE2 _ADR - Indicates address of slave IDE device - Control method to get task file - Indicates address of master IDE device - Control method to get task file
_GTM - Control method to get current IDE channel settings _STM - Control method to set current IDE channel settings
Compaq/Intel/Microsoft/Phoenix/Toshiba
244 Advanced Configuration and Power Interface Specification _PR0 - Power resources needed for D0 power state DRV1 - Drive 0 _ADR _GTF DRV2 - Drive 1 _ADR _GTF - Indicates address of slave IDE device - Control method to get task file - Indicates address of master IDE device - Control method to get task file
The sequential order of operations is as follows: Powering down : Call _GTM. Power down drive (calls _PS3 method and turns off power planes). Powering up: Power up drive (calls _PS0 method if present and turns on power planes). Call _STM passing info from _GTM (possibly modified), with ID data from each drive. Initialize the channel. May modify the results of _GTF. For each drive: Call _GTF. Execute task file (possibly modified).
Table 10-3 IDE Specific Controls Object _GTF _GTM _STM Description Optional control method to get the ATA task file needed to re-initialize the drive to boot up defaults. Optional control method to get the IDE controller timing information. Optional control method to set the IDE controllers transfer timing settings.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 10-4 _GTM Method Result Codes Field PIO Speed 0 Format DWORD Description The PIO bus-cycle timing for drive 0 in nanoseconds. 0xFFFFFFFF indicates that this mode is not supported by the channel. If the chipset cannot set timing parameters independently for each drive, this field represents the timing for both drives. The DMA bus-cycle for drive 0 timing in nanoseconds. If Bit 0 of the Flags register is set, this DMA timing is for UltraDMA mode, otherwise the timing is for multi-word DMA mode. 0xFFFFFFFF indicates that this mode is not supported by the channel. If the chipset cannot set timing parameters independently for each drive, this field represents the timing for both drives. The PIO bus-cycle timing for drive 1 in nanoseconds. 0xFFFFFFFF indicates that this mode is not supported by the channel. If the chipset cannot set timing parameters independently for each drive, this field must be 0xffffffff. The DMA bus-cycle timing for drive 1 in nanoseconds. If Bit 0 of the Flags register is set, this DMA timing is for UltraDMA mode, otherwise the timing is for multi-word DMA mode. 0xFFFFFFFF indicates that this mode is not supported by the channel. If the chipset cannot set timing parameters independently for each drive, this field must be 0xFFFFFFFF. Mode flags Bit[0]: 1 indicates using UltraDMA on drive 0 Bit[1]: 1 indicates IOChannelReady is used on drive 0 Bit[2]: 1 indicates using UltraDMA on drive 1 Bit[3]: 1 indicates IOChannelReady is used on drive 1 Bit[4]: 1 indicates chipset can set timing independently for each drive Bits[5-31]: reserved (must be 0)
DMA Speed 0
DWORD
PIO Speed 1
DWORD
DMA Speed 1
DWORD
Flags
DWORD
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 10-5 Tape Presence Value 0 1 2 >2 Description Unknown if device is present Device is present Device is never present Reserved
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 10-6 ACPI Floppy Drive Information Field Drive Number Device Type Maximum Cylinder Number Maximum Sector Number Maximum Head Number Disk_specify_1 Disk_specify_2 Disk_motor_wait Disk_sector_siz Disk_eot Disk_rw_gap Disk_dtl Disk_formt_gap Disk_fill Disk_head_sttl Disk_motor_strt Format BYTE BYTE WORD WORD WORD BYTE BYTE BYTE BYTE BYTE BYTE BYTE BYTE BYTE BYTE BYTE Definition As reported by _INT 13 Function 08H As reported by _INT 13 Function 08H As reported by _INT 13 Function 08H As reported by _INT 13 Function 08H As reported by _INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H As reported in ES:D1 from INT 13 Function 08H
Compaq/Intel/Microsoft/Phoenix/Toshiba
Notice that it is legal to replace the I/O descriptors with Memory descriptors if the register is memory mapped. If the system must run any GPEs to bootstrap the system (for example, when Embedded Controller events are required), the associated block of GPEs must be described in the FADT. This register block is not relocatable and will always be available for the life of the operating system boot. The GPE block associated with the ACPI0006 device can be stopped, ejected, reprogrammed, and so on. The system can also have multiple such GPE blocks.
Compaq/Intel/Microsoft/Phoenix/Toshiba
10.10.1 Matching Control Methods for General-Purpose Events in a GPE Block Device
When a GPE Device raises an interrupt, OSPM executes a corresponding control method (as described in section 5.6.2.2.3, Queuing the Matching Control Method for Execution). These control methods (of the form _Lxx and _Exx) for GPE Devices are not within the \_GPE namespace. They are children of the GPE Block device. For example:
Device(GPE5) { Name(_HID, ACPI0006) Method(_L02) { } Method(_E07) { } }
Compaq/Intel/Microsoft/Phoenix/Toshiba
Name(_PRS, ResourceTemplate() { DWordMemory(,,,, Cacheable, // _MEM ReadWrite, // _RW 0x0FFFFFFF, // _GRA 0x40000000, // _MIN 0x7FFFFFFF, // _MAX 0x0, // _TRA 0x10000000) // _LEN }) Method(_CRS, 0) { ... } Method(_SRS, 1) { ... } Method(_DIS, 0) { ... } } Device(MEM1) { // Main Memory (512MB module) Name(_HID, EISAID("PNP0C80")) Name(_UID, 1) Method(_STA, 0) { // If memory not present --> Return(0x00) // Else if memory is disabled --> Return(0x0D) // Else --> Return(0x0F) } Name(_PRS, ResourceTemplate() { DWordMemory(,,,, Cacheable, // _MEM ReadWrite, // _RW 0x1FFFFFFF, // _GRA 0x40000000, // _MIN 0x7FFFFFFF, // _MAX 0x0, // _TRA 0x20000000) // _LEN }) Method(_CRS, 0) { ... } Method(_SRS, 1) { ... } Method(_DIS, 0) { ... } } Device(PCI0) { // PCI Root Bridge Name(_HID, EISAID("PNP0A03")) Name(_UID, 0) Name(_BBN, 0x00) Name(_PRS, ResourceTemplate() { WordBusNumber(ResourceProducer, MinFixed, // _MIF MaxFixed,, // _MAF 0x00, // _GRA 0x00, // _MIN 0x7F, // _MAX 0x0, // _TRA 0x80) // _LEN WordIo(ResourceProducer, MinFixed, // _MIF MaxFixed,,, // _MAF 0x0000, // _GRA 0x0000, // _MIN 0x0CF7, // _MAX 0x0, // _TRA 0x0CF8) // _LEN WordIo(ResourceProducer, MinFixed, // _MIF MaxFixed,,, // _MAF 0x0000, // _GRA 0x0D00, // _MIN 0x7FFF, // _MAX 0x0, // _TRA 0x7300) // _LEN
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
SMBus
SBS Battery0
0xB
SMBus
SBS Battery1
0xB
Host Interface
SMBus
SMBus
SBS Battery2
0xB
SBS Charger
0x9
SMBus
SBS Battery3
0xB
Figure 11-1 Typical Smart Battery Subsystem (SBS) SMBus defines a fixed 7-bit slave address per device. This means that all batteries in the system have the same address (defined to be 0xB). The slave addresses associated with Smart Battery subsystem components are shown in the follo wing table. Table 11-1 Example SMBus Device Slave Addresses SMBus Device Description SMBus Host Slave Interface Smart Battery Charger/Charger Selector or Charger System Manager Smart Battery System Manager or Smart Battery Selector Smart Battery SMBus Slave Address (A0-A6) 0x8 0x9
0xA 0xB
Each SMBus device has up to 256 registers that are addressed through the SMBus protocols Command value. SMBus devices are addressed by providing the slave address with the desired registers Command value. Each SMBus register can have non-linear registers; that is, command register 1 can have a 32-byte string, while command register 2 can have a byte, and command register 3 can have a word. The SMBus host slave interface provides a standard mechanism for the host CPU to generate SMBus protocol commands that are required to communicate with SMBus devices (in other words, the Smart Battery components). ACPI defines such an SMB-HCthat resides in embedded controller address space; however, an OS can support any SMB-HCthat has a native SMB-HCdevice driver.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The Smart Battery System Manager provides a standard programming model to control multiple Smart Batteries in a Smart Battery subsystem. A Smart Battery System Manager provides the following types of battery management functions: Event notification for battery insertion and removal Event notification for AC power connected or disconnected Status of which Smart Battery is communicating with the SMB-HC Status of which Smart Battery(s) are powering the system Status of which Smart Battery(s) are connected to the charger Status of which Smart Batteries are present in the system Event notification when the Smart Battery System Manager switches from one power source to another Hardware-switching to an alternate Smart Battery when the Smart Battery supplying power runs low Hardware switching between battery-powered and AC-powered powered operation The Smart Battery System Manager function can reside in a standalone SMBus slave device (Smart Battery System Manager that responds to the 0xA slave address), may be present within a smart charger device (Smart Battery Charger that responds to the 0x9 slave address), or may be combined within the embedded controller (that responds to the 0xA slave address). If both a Smart Battery Charger and a standalone Smart Battery System Manager are present in the same Smart Battery subsystem, then the driver assumes that the standalone Smart Battery System Manager is wired to the batteries. The Smart Battery charger is an SMBus device that provides a standard programming model to control the charging of Smart Batteries present in a Smart Battery subsystem. For single battery systems, the Smart Battery Charger is also responsible for notifying the system of the battery and AC status. The Smart Battery provides intelligent chemistry-independent power to the system. The Smart Battery is capable of informing the Smart Battery charger of its charging requirements (which provides chemistry independence) and providing battery status and alarm features needed for platform battery management.
Compaq/Intel/Microsoft/Phoenix/Toshiba
17
Notice that the 1.0 SMBus protocol specification is ambiguous about the definition of the slave address written into the command field of the host controller. In this case, the slave address is actually the combination of the 7-bit slave address and the Write protocol bit. Therefore, bit 0 of the initiating devices slave address is aligned to bit 1 of the host controllers slave command register, bit 1 of the slave address is aligned to bit 2 of the controllers slave command register, and so on.
Compaq/Intel/Microsoft/Phoenix/Toshiba
_SBS
Compaq/Intel/Microsoft/Phoenix/Toshiba
SBS Battery
0xB
SMBus
Host Interface
SBS Charger
0x9
Figure 11-2 Single Smart Battery Subsystem In this example, the platform is using an SMB-HC that resides within the embedded controller and meets the ACPI standard for an embedded controller interface and SMB-HCinterface. The embedded controller interface sits at system I/O port addresses 0x62 and 0x66. The SMB-HCis at base address 0x80 within embedded controller address space (as defined by the ACPI embedded controller specification) and responds to events on query value 0x30.
Compaq/Intel/Microsoft/Phoenix/Toshiba
In this example the Smart Battery subsystem only supports a single Smart Battery. The ASL code for describing this interface is shown below:
Device(EC0) { Name(_HID, EISAID("PNP0C09")) Name(_CRS, ResourceTemplate(){ // port 0x62 and 0x66 IO(Decode16, 0x62, 0x62, 0, 1), IO(Decode16, 0x66, 0x66, 0, 1) } ) Name(_GPE, 0) Device (SMB0) { Name(_HID, "ACPI0001") // Smart Battery Host Controller Name(_EC, 0x8030) // EC offset (0x80), Query (0x30) Device(SBS0){ // Smart Battery Subsystem Name(_HID, "ACPI0002") // Smart Battery Subsystem ID Name(_SBS, 0x1) // Indicates support for one battery } // end of SBS0 } // end of SMB0 } // end of EC
SMBus
SBS Charger
0x9
SMBus
SBS Battery2
0xB
Figure 11-3 Smart Battery Subsystem In this example, the platform is using an SMB-HCthat resides within the embedded controller and meets the ACPI standard for an embedded controller interface and SMB-HCinterface. The embedded controller interface sits at system I/O port addresses 0x100 and 0x101. The SMB-HCresides at base address 0x90 within embedded controller address space (as defined by the ACPI embedded controller specification) and responds to events on query value 0x31. In this example the Smart Battery subsystem supports three Smart Batteries. The Smart Battery Charger and Smart Battery System Manager reside within the embedded controller, meet the Smart Battery System Manager and Smart Battery Charger interface specification, and respond to their 7-bit addresses (0xA and 0x9 respectively). The ASL code for describing this interface is shown below:
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
A Control Method Battery device declaration in the ACPI name space requires the _GLK object if potentially contentious accesses to device resources are performed by non-OS code. See section 6.5.7, _GLK (Global Lock), for details about the _GLK object.
Compaq/Intel/Microsoft/Phoenix/Toshiba
262 Advanced Configuration and Power Interface Specification Table 11-4 _BIF Method Result Codes Field Power Unit Format DWORD Description Indicates the units used by the battery to report its capacity and charge/discharge rate information to the OS. 0x00000000 Capacity information is reported in [mWh] and charge/discharge rate information in [mW]. 0x00000001 Capacity information is reported in [mAh] and charge/discharge rate information in [mA]. Design Capacity DWORD Batterys design capacity. Design Capacity is the nominal capacity of a new battery. The Design Capacity value is expressed as power [mWh] or current [mAh] depending on the Power Unit value. 0x000000000 0x7FFFFFFF (in [mWh] or [mAh] ) 0xFFFFFFFF Unknown design capacity Last Full Charge Capacity DWORD Predicted battery capacity when fully charged. The Last Full Charge Capacity value is expressed as power (mWh) or current (mAh) depending on the Power Unit value. 0x000000000h 0x7FFFFFFF (in [mWh] or [mAh] ) 0xFFFFFFFF Unknown last full charge capacity Battery Technology Design Voltage DWORD DWORD 0x00000000 Primary (for example, non-rechargeable) 0x00000001 Secondary (for example, rechargeable) Nominal voltage of a new battery. 0x000000000 0x7FFFFFFF in [mV] 0xFFFFFFFF Unknown design voltage Design capacity of Warning DWORD OEM-designed battery warning capacity. See section 3.9.4, Low Battery Levels. 0x000000000 0x7FFFFFFF in [mWh] or [mAh] Design Capacity of Low DWORD OEM-designed low battery capacity. See section 3.9.4, Low Battery Levels. 0x000000000 0x7FFFFFFF in [mWh] or [mAh] Battery Capacity Granularity 1 Battery Capacity Granularity 2 Model Number Serial Number Battery Type OEM Information DWORD DWORD ASCIIZ ASCIIZ ASCIIZ ASCIIZ Battery capacity granularity between low and warning in [mAh] or [mW h]. Battery capacity granularity between warning and Full in [mAh] or [mWh]. OEM-specific Control Method Battery model number OEM-specific Control Method Battery serial number The OEM-specific Control Method Battery type OEM-specific information for the battery that the UI uses to display the OEM information about the Battery. If the OEM does not support this information, this should be reserved as 0x00.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Notes: A secondary-type battery should report the corresponding capacity (except for Unknown). On a multiple -battery system, all batteries in the system should return the same granularity. Operating systems prefer these control methods to report data in terms of power (watts).
Table 11-5 _BST Method Result Codes Field Battery State Format DWORD Description Bit values. Notice that the Charging bit and the Discharging bit are mutually exclusive and must not both be set at the same time . Even in critical state, hardware should report the corresponding charging/discharging state. Bit0 1 indicates the battery is discharging. Bit1 1 indicates the battery is charging. Bit2 1 indicates the battery is in the critical energy state (see section 3.9.3, Low Battery Levels). This does not mean battery failure. Battery Present Rate DWORD Returns the power or current being supplied or accepted through the batterys terminals (direction depends on the Battery State value). The Battery Present Rate value is expressed as power [mWh] or current [mAh] depending on the Power Unit value. Batteries that are rechargeable and are in the discharging state are required to return a valid Battery Present Rate value. 0x00000000 0x7FFFFFFF in [mW] or [mA] 0xFFFFFFFF Unknown rate
Compaq/Intel/Microsoft/Phoenix/Toshiba
264 Advanced Configuration and Power Interface Specification Table 11-5 _BST Method Result Codes (continued) Field Battery Remaining Capacity Format DWORD Description Returns the estimated remaining battery capacity. The Battery Remaining Capacity value is expressed as power [mWh] or current [mAh] depending on the Power Unit value. Batteries that are rechargeable are required to return a valid Battery Remaining Capacity value. 0x00000000 0x7FFFFFFF in [mWh] or [mAh] 0xFFFFFFFF Unknown capacity
DWORD
Returns the voltage across the batterys terminals. Batteries that are rechargeable must report Battery Present Voltage . 0x000000000 0x7FFFFFFF in [mV] 0xFFFFFFFF Unknown voltage Note: Only a primary battery can report unknown voltage.
Notice that when the battery is a primary battery (a non-rechargeable battery such as an AlkalineManganese battery) and cannot provide accurate information about the battery to use in the calculation of the remaining battery life, the Control Method Battery can report the percentage directly to OS. It does so by reporting the Last Full Charged Capacity =100 and BatteryPresentRate=0xFFFFFFFF. This means that Battery Remaining Capacity directly reports the batterys remaining capacity [%] as a value in the range 0 through 100 as follows:
Battery Remaining Capacity [=0 ~ 100] Last Full Charged Capacity [=100] * 100
Battery Remaining Capacity [mAh/mWh] Remaining Battery Life [h] = Battery Present Rate [=0xFFFFFFFF]
= unknown
Compaq/Intel/Microsoft/Phoenix/Toshiba
If the battery does not support this function, the _BTP control method is not located in the name space. In this case, the OS must poll the Battery Remaining Capacity value. Arguments: Level at which to set the trip point: 0x00000001 0x7FFFFFFF (in units of mWh or mAh, depending on the Power Units value) 0x00000000 Clear the trip point Result Code: None
Compaq/Intel/Microsoft/Phoenix/Toshiba
System Bus AC Adapter1 Power Source Type Power Class List Battery 1 Plug and Play ID for the BAT1 Status of the BAT1 Object Battery1 Information Battery1 Status Battery1 Trip Point Power Class List Battery 2 Plug and Play ID for the BAT2 Status of the BAT2 Object Battery2 Information Battery2 Status Battery2 Trip Point Power Class List
BAT1 _HID _STA _BIF _BST _BTP _PCL BAT2 _HID _STA _BIF _BST _BTP _PCL PCI0
d d
DOCK ADP2 _PSR _PCL AC Adapter 2 Power Source Type Power Class List
Figure 11-4 Power Source Name Space Example that Includes a Docking Station
Compaq/Intel/Microsoft/Phoenix/Toshiba
12 Thermal Management
This section specifies the objects OSPM uses for thermal management of a platform.
Compaq/Intel/Microsoft/Phoenix/Toshiba
In each situation, the OEM -provided AML code must execute a Notify(thermal_zone, 0x81) statement to request OSPM to re-evaluate the policy thresholds by obtaining the current values for the _ACx and _PSV objects.
3.
Compaq/Intel/Microsoft/Phoenix/Toshiba
It is recognized that much of the hardware used to implement thermal zone functionality today is not capable of generating ACPI-visible notifications (SCIs) or only can do so with wide granularity (for example, only when the temperature crosses the critical threshold). In these environments, OSPM must poll the thermal zones temperature periodically to implement an effective policy. While ACPI specifies a mechanism that enables OSPM to poll thermal zone temperature, platform reliance on thermal zone polling is strongly discouraged by this specification. OEMs should design systems that asynchronously notify OSPM whenever a meaningful change in the zones temperature occurs relieving the OS of the overhead associated with polling. In some cases, embedded controller firmware can overcome limitations of existing thermal sensor capabilities to provide the desired asynchronous notification. Notice that the _TZP (thermal zone polling) object is used to indicate whether a thermal zone must be polled by OSPM, and if so, a recommended polling frequency. See section 12.3.13, _TZP, for more information.
95 90 85 80 75 70 65 60 55 50 45 40 35 30 25
_CRT: Critical shutdown threshold _AC0: Fan high speed threshold _AC1: Fan low speed threshold _PSV: Passive cooling threshold
Figure 12-1 SCI Events For example, the thermal zone illustrated above includes hardware that will generate a temperature change notification using a 5 Celsius granularity. All thresholds (_PSV, _AC1, _AC0, and _CRT) exist within the monitored range and fall on 5 boundaries. This granularity is appropriate for this system as it provides sufficient opportunity for OSPM to detect when a threshold is crossed as well as to understand the thermal zones basic characteristics (temperature trends). Note: The ACPI specification defines Kelvin as the standard unit for temperature. All thermal zone objects must report temperatures in Kelvin. All figures and examples in this section of the specification use Celsius for reasons of clarity. ACPI allows Kelvin to be declared in precision of 1/10th of a degree (for example, 310.5). Kelvin is expressed as /K = T/ C + 273.2.
Compaq/Intel/Microsoft/Phoenix/Toshiba
12.1.3.2 Polling
Platforms that are not capable of generating SCIs for thermal change events or that can only do so for a few thresholds should inform OSPM to implement a poll-based policy. OSPM does this to ensure that temperature changes across threshold boundaries are always detectable. Polling can be done in conjunction with hardware notifications. For example, thermal zone hardware that only supports a single threshold might be configured to use this threshold as the critical temperature trip point. Assuming that hardware monitors the temperature at a finer granularity than OSPM would, this environment has the benefit of being more responsive when the system is overheating. A thermal zone advertises the need to be polled by OSPM via the _TZP object. The absence of this control method informs OSPM to implement polling using an OS-provided default frequency. See section 12.3.13, _TZP, for more information.
For ASL coding examples that illustrate these points, see sections 12.4, Thermal Zone Object Requirements, and 12.5, Thermal Zone Examples.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Temperature
Tt
50% Time
Figure 12-2 Temperature and CPU Performance Versus Time The following equation should be used by OSPM to assess the optimum CPU performance change necessary to lower the thermal zones temperature: Equation #1: P [%] = _TC1 * ( Tn - Tn-1 ) + _TC2 * (Tn - Tt) Where: Tn = current temperature Tt = target temperature (_PSV) The two coefficients _TC1 and _TC2 and the sampling period _TSP are hardware -dependent constants the OEM must supply to OSPM (for more information, see section 12.3, Thermal Objects). The object _TSP contains a time interval that OSPM uses to poll the hardware to sample the temperature. Whenever _TSP time has elapsed, OSPM will run _TMP to sample the current temperature (shown as Tn in the above equation). Then OSPM will use the sampled temperature and _PSV (which is the target temperature Tt) to evaluate the equation for P. The granularity of P is determined by the CPU duty width of the system. Note : Equation #1 has an implied formula. Equation #2: Pn = Pn-1 + HW[- P ] where 0% <= Pn <= 100% For Equation #2, whenever Pn-1 + P lies outside the range 0-100%, then Pn will be truncated to 0-100%. For hardware that cannot assume all possible values of Pn between 0 and 100%, a hardware-specific mapping function HW is used. In addition, the hardware mapping function in Equation #2 should be interpreted as follows: 1. If the right hand side of Equation #1 is negative, HW[ P] is rounded to the next available higher setting of frequency. 2. If the right hand side of Equation #1 is positive, HW[P] is rounded to the next available lower setting of frequency. The calculated Pn becomes Pn-1 during the next sampling period. For more information about CPU throttling, see section 8.1.1, Processor Power State C0. A detailed explanation of this thermal feedback equation is beyond the scope of this specification.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
As illustrated in Figure 12-3, OEMs must choose the value for each threshold to instruct OSPM to initiate the cooling policies at the desired target temperatures. OEMs can emphasize active or passive cooling modes by assigning different threshold values. Generally, if _ACx is set lower than _PSV, then the system emphasizes active cooling. Conversely, if _PSV is set lower than _ACx, then the emphasis is placed on passive cooling. For example, a thermal zone that includes a processor and one single-speed fan may use _PSV to indicate the temperature value at which OSPM would enable passive cooling and _AC0 to indicate the temperature at which the fan would be turned on. If the value of _PSV is less than _AC0 then the system will favor passive cooling (for example, CPU clock throttling). On the other hand, if _AC0 is less than _PSV the system will favor active cooling (in other words, using the fan). See Figure 12-4 below.
_CRT _PSV
_CRT _AC0
_AC0
_PSV
Figure 12-4 Cooling Preferences The example on the left enables active cooling (for example, turn on a fan) when OSPM detects the temperature has risen above 50 . If for some reason the fan does not reduce the system temperature, then at 75 OSPM will initiate passive cooling (for example, CPU throttling) while still running the fan. If the temperature continues to climb, OSPM will quickly shut the system down when the temperature reaches 90 C. The example on the right is similar but the _AC0 and _PSV threshold values have been swapped to emphasize passive cooling. The ACPI thermal model allows flexibility in the thermal zone design. An OEM that needs a less elaborate thermal implementation may consider using only a single threshold (for example, _CRT). Complex thermal implementations can be modeled using multiple active cooling thresholds and devices, or through the use of additional thermal zones.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
278 Advanced Configuration and Power Interface Specification This value is specified as tenths of seconds with a 1 second granularity. A minimum value of 30 seconds (_TZP evaluates to 300) and a maximum value of 300 seconds (in other words, 5 minutes) (_TZP evaluates to 3000) may be specified. As this is a recommended value, OSPM will consider other factors when determining the actual polling frequency to use. Arguments: None Result Code: The recommended polling frequency, in tenths of seconds. A value of zero indicates that polling is not necessary.
12.5 Thermal Zone Examples 12.5.1 Example: The Basic Thermal Zone
The following ASL describes a basic configuration where the entire system is treated as a single thermal zone. Cooling devices for this thermal zone consist of a processor and one single-speed fan. This is an example only. Notice that this thermal zone object (TZ0) is defined in the \_SB scope. Thermal zone objects should appear in the namespace under the portion of the system that comprises the thermal zone. For example, a thermal zone that is isolated to a docking station should be defined within the scope of the docking station device. Besides providing for a well-organized namespace, this configuration allo ws OSPM to dynamically adjust its thermal policy as devices are added or removed from the system.
Scope(\_SB) { Processor( CPU0, 1, 0x110, 0x06 ) {}
// unique number for this processor // system IO address of Pblk Registers // length in bytes of PBlk
Compaq/Intel/Microsoft/Phoenix/Toshiba
Scope(\_SB.PCI0.ISA0) { Device(EC0) { Name(_HID, EISAID("PNP0C09")) // ID for this EC // current resource description for this EC Name(_CRS, ResourceTemplate() { IO(Decode16,0x62,0x62,0,1) IO(Decode16,0x66,0x66,0,1) }) Name(_GPE, 0) // GPE index for this EC // create EC's region and field for thermal support OperationRegion(EC0, EmbeddedControl, 0, 0xFF) Field(EC0, ByteAcc, Lock, Preserve) { MODE, 1, // thermal policy (quiet/perform) FAN, 1, // fan power (on/off) , 6, // reserved TMP, 8, // current temp AC0, 8, // active cooling temp (fan high) , 8, // reserved PSV, 8, // passive cooling temp CS4 8, // critical S4 temp CRT, 8 // critical temp } // following is a method that OSPM will schedule after // it receives an SCI and queries the EC to receive value 7 Method(_Q07) { Notify (\_SB.PCI0.ISA0.EC0.TZ0, 0x80) } // end of Notify method // fan cooling on/off - engaged at AC0 temp PowerResource(PFAN, 0, 0) { Method(_STA) { Return (\_SB.PCI0.ISA0.EC0.FAN) } // check power state Method(_ON) { Store (One, \_SB.PCI0.ISA0.EC0.FAN) } // turn on fan Method(_OFF) { Store ( Zero, \_SB.PCI0.ISA0.EC0.FAN) } // turn off fan } // Create FAN device object Device (FAN) { // Device ID for the FAN Name(_HID, EISAID("PNP0C0B")) // list power resource for the fan Name(_PR0, Package(){PFAN}) } // create a thermal zone ThermalZone (TZ0) { Method(_TMP) { Return (\_SB.PCI0.ISA0.EC0.TMP )} // get current temp Method(_AC0) { Return (\_SB.PCI0.ISA0.EC0.AC0) } // fan high temp Name(_AL0, Package(){\_SB.PCI0.ISA0.EC0.FAN}) // fan is act cool dev Method(_PSV) { Return (\_SB.PCI0.ISA0.EC0.PSV) } // passive cooling temp Name(_PSL, Package (){\_SB.CPU0}) // passive cooling devices Method(_CS4) { Return (\_SB.PCI0.ISA0.EC0.CS4) } // get critical S4 temp Method(_CRT) { Return (\_SB.PCI0.ISA0.EC0.CRT) } // get critical temp Method(_SCP, 1) { Store (Arg1, \_SB.PCI0.ISA0.EC0.MODE) } // set cooling mode Name(_TC1, 4) // bogus example constant Name(_TC2, 3) // bogus example constant Name(_TSP, 150) // passive sampling = 15 sec Name(_TZP, 0) // polling not required } // end of TZ0 } } // end of ECO // end of \_SB.PCI0.ISA0 scope-
Compaq/Intel/Microsoft/Phoenix/Toshiba
// unique number for this processor // system IO address of Pblk Registers // length in bytes of PBlk
Scope(\_SB.PCI0.ISA0) { Device(EC0) { Name(_HID, EISAID("PNP0C09")) // ID for this EC // current resource description for this EC Name(_CRS, ResourceTemplate() { IO(Decode16,0x62,0x62,0,1) IO(Decode16,0x66,0x66,0,1) }) Name(_GPE, 0) // GPE index for this EC // create EC's region and field for thermal support OperationRegion(EC0, EmbeddedControl, 0, 0xFF) Field(EC0, ByteAcc, Lock, Preserve) { MODE, 1, // thermal policy (quiet/perform) FAN0, 1, // fan strength high/off FAN1, 1, // fan strength low/off , 5, // reserved TMP, 8, // current temp AC0, 8, // active cooling temp (high) AC1, 8, // active cooling temp (low) PSV, 8, // passive cooling temp CS4 8, // critical S4 temp CRT, 8 // critical temp } // following is a method that OSPM will schedule after it // receives an SCI and queries the EC to receive value 7 Method(_Q07) { Notify (\_SB.PCI0.ISA0.EC0.TZ0, 0x80) } end of Notify method // fan cooling mode high/off - engaged at AC0 temp PowerResource(FN10, 0, 0) { Method(_STA) { Return (\_SB.PCI0.ISA0.EC0.FAN0) } // check power state Method(_ON) { Store (One, \_SB.PCI0.ISA0.EC0.FAN0) } // turn on fan at high Method(_OFF) { Store (Zero, \_SB.PCI0.ISA0.EC0.FAN0) }// turn off fan } // fan cooling mode low/off - engaged at AC1 temp PowerResource(FN11, 0, 0) { Method(_STA) { Return (\_SB.PCI0.ISA0.EC0.FAN1) } // check power state Method(_ON) { Store (One, \_SB.PCI0.ISA0.EC0.FAN1) } // turn on fan at low Method(_OFF) { Store (Zero, \_SB.PCI0.ISA0.EC0.FAN1) }// turn off fan }
Compaq/Intel/Microsoft/Phoenix/Toshiba
// Following is a single fan with two speeds. This is represented // by creating two logical fan devices. When FN2 is turned on then // the fan is at a low speed. When FN1 and FN2 are both on then // the fan is at high speed. // // Create FAN device object FN1 Device (FN1) { // Device ID for the FAN Name(_HID, EISAID("PNP0C0B")) Name(_PR0, Package(){FN10, FN11}) } // Create FAN device object FN2 Device (FN2) { // Device ID for the FAN Name(_HID, EISAID("PNP0C0B")) Name(_PR0, Package(){FN10}) } // create a thermal zone ThermalZone (TZ0) { Method(_TMP) { Return (\_SB.PCI0.ISA0.EC0.TMP )} // get current temp Method(_AC0) { Return (\_SB.PCI0.ISA0.EC0.AC0) } // fan high temp Method(_AC1) { Return (\_SB.PCI0.ISA0.EC0.AC1) } // fan low temp Name(_AL0, Package() {\_SB.PCI0.ISA0.EC0.FN1}) // active cooling (high) Name(_AL1, Package() {\_SB.PCI0.ISA0.EC0.FN2}) // active cooling (low) Method(_PSV) { Return (\_SB.PCI0.ISA0.EC0.PSV) } // passive cooling temp Name(_PSL, Package() {\_SB.CPU0}) // passive cooling devices Method(_CS4) { Return (\_SB.PCI0.ISA0.EC0.CS4) } // get critical S4 temp Method(_CRT) { Return (\_SB.PCI0.ISA0.EC0.CRT) } // get crit. temp Method(_SCP, 1) { Store (Arg1, \_SB.PCI0.ISA0.EC0.MODE) } // set cooling mode Name(_TC1, 4) // bogus example constant Name(_TC2, 3) // bogus example constant Name(_TSP, 150) // passive sampling = 15 sec Name(_TZP, 0) // polling not required } // end of TZ0 } } // end of ECO // end of \_SB.PCI0.ISA0 scope
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Currently, the most common host interface architecture incorporated into microcontrollers is modeled after the standard IA-PC architecture keyboard controller. This keyboard controller is accessed at 0x60 and 0x64 in system I/O space. Port 0x60 is termed the data register, and allows bi-directional data transfers to and from the host and embedded controller. Port 0x64 is termed the command/status register; it returns port status information upon a read, and generates a command sequence to the embedded controller upon a write. This same class of controllers also includes a second decode range that shares the same properties as the keyboard interface by having a command/status register and a data register. The following diagram graphically depicts this interface.
EC INPUT BUFFER
DATA WRITE (SMI/SCI) DATA READ (SMI/SCI)
SMI INTERFACE CODE INTERFACE ARBITRATION CODE SCI INTERFACE CODE MAIN FIRMWARE I/O
EC_SMI_STS EC_SMI
EC_SCI_EN
Figure 13-1 Shared Interface The diagram above depicts the general register model supported by the ACPI Embedded Controller Interface.
Compaq/Intel/Microsoft/Phoenix/Toshiba
284 Advanced Configuration and Power Interface Specification The first method uses an embedded controller interface shared between OSPM and the system management code, which requires the Global Lock semaphore overhead to arbitrate ownership. The second method is a dedicated embedded controller decode range for sole use by OSPM driver. The following diagram illustrates the embedded controller architecture that includes a dedicated ACPI interface.
EC_SMI_STS EC_SMI
EC_SMI_EN
MAIN FIRMWARE SCI INPUT BUFFER SCI OUTPUT BUFFER SCI STATUS REGISTER SCI INTERFACE CODE
I/O
EC_SCI_STS EC_SCI
EC_SCI_EN
Compaq/Intel/Microsoft/Phoenix/Toshiba
The private interface allows OSPM to communicate with the embedded controller without the additional software overhead associated with using the Global Lock. Several common system configurations can provide the additional embedded controller interfaces: Non-shared embedded controller. This will be the most common case where there is no need for the system management handler to communicate with the embedded controller when the system transitions to ACPI mode. OSPM processes all normal types of system management events, and the system management handler does not need to take any actions. Integrated keyboard controller and embedded controller. This provides three host interfaces as described earlier by including the standard keyboard controller in an existing component (chip set, I/O controller) and adding a discrete, standard embedded controller with two interfaces for system management activities. Standard keyboard controller and embedded controller.This provides three host interfaces by providing a keyboard controller as a distinct component, and two host interfaces are provided in the embedded controller for system management activities. Two embedded controllers. This provides up to four host interfaces by using two embedded controllers; one controller for system management activities providing up to two host interfaces, and one controller for keyboard controller functions providing up to two host interfaces. Embedded controller and no keyboard controller. Future platforms might provide keyboard functionality through an entirely different mechanism, which would allow for two host interfaces in an embedded controller for system management activities. To handle the general embedded controller interface (as opposed to a dedicated interface) model, a method is available to make the embedded controller a shareable resource between multiple tasks running under the operating systems control and the system management interrupt handler. This method, as described in this section, requires several changes: Additional external hardware Embedded controller firmware changes System management interrupt handler firmware changes Operating software changes Access to the shared embedded controller interface requires additional software to arbitrate between the operating systems use of the interface and the system management handlers use of the interface. This is done using the Global Lock as described in section 5.2.9.1, Global Lock. This interface sharing protocol also requires embedded controller firmware changes, in order to ensure that collisions do not occur at the interface. A collision could occur if a byte is placed in the system output buffer and an interrupt is then generated. There is a small window of time when the incorrect recipient could receive the data. This proble m is resolved by ensuring that the firmware in the embedded controller does not place any data in the output buffer until it is requested by OSPM or the system management handler. More detailed algorithms and descriptions are provided in the following sections.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
The SMI event (SMI_EVT) flag is set when the embedded controller has detected an internal event that requires the system management interrupt handlers attention. The embedded controller sets this bit in the status register before generating an SMI. The Burst (BURST) flag indicates that the embedded controller has received the burst enable command from the host, has halted normal processing, and is waiting for a series of commands to be sent from the host. This allows OSPM or system management handler to quickly read and write several bytes of data at a time without the overhead of SCIs between the commands.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Interrupt detected
HOLD
Write Command (3 Bytes) Byte #1 Byte #2 Byte #3 (Command byte Header) (Address byte to write) (Data to read ) Interrupt on IBF=0 Interrupt on IBF=0 Interrupt on IBF=0
Compaq/Intel/Microsoft/Phoenix/Toshiba
Query Command (2 Bytes) Byte #1 Byte #2 (Command byte Header) (Query value to host) No Interrupt Interrupt on OBF=1
Burst Enable Co mmand (2 Bytes) Byte #1 Byte #2 (Command byte Header) (Burst acknowledge byte) No Interrupt Interrupt on OBF=1
Burst Disable Command (1 Byte) Byte #1 (Command byte Header) Interrupt on IBF=0
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 13-3 SMBus Status Codes Status Code 00h 07h 10h 11h 12h Name SMBus OK SMBus Unknown Failure SMBus Device Address Not Acknowledged SMBus Device Error Detected SMBus Device Command Access Denied Description Indicates the transaction has been successfully completed. Indicates failure because of an unknown SMBus error. Indicates the transaction failed because the slave device address was not acknowledged. Indicates the transaction failed because the slave device signaled an error condition. Indicates the transaction failed because the SMBus host does not allow the specific command for the device being addressed. For example, the SMBus host might not allow a caller to adjust the Smart Battery Chargers output. Indicates the transaction failed because the SMBus host encountered an unknown error. Indicates the transaction failed because the SMBus host does not allow access to the device addressed. For example, the SMBus host might not allow a caller to directly communicate with an SMBus device that controls the systems power planes. Indicates the transaction failed because the SMBus host detected a timeout on the bus. Indicates the transaction failed because the SMBus host does not support the requested protocol. Indicates that the transaction failed because the SMBus host reports that the SMBus is presently busy with some other transaction. For example, the Smart Battery might be sending charging information to the Smart Battery Charger. Indicates that a Packet Error Checking (PEC) error occurred during the last transaction.
13h 17h
1Fh
PROTOCOL
Compaq/Intel/Microsoft/Phoenix/Toshiba
294 Advanced Configuration and Power Interface Specification Where: PROTOCOL: 0x00 Controller Not In Use 0x01 Reserved 0x02 Write Quick Command 0x03 Read Quick Command 0x04 Send Byte 0x05 Receive Byte 0x06 Write Byte 0x07 Read Byte 0x08 Write Word 0x09 Read Word 0x0A Write Block 0x0B Read Block 0x0C Process Call 0x0D Block Write-Block Read Process Call For example, the protocol value of 0x09 would be used to communicate to a device that supported the standard read word protocol. If this device also supported packet error checking for this protocol, a value of 0x89 ( read word with PEC) could optionally be used. See the SMBus specification for more information on packet error checking. When OSPM initiates a new command such as write to the SMB_PRTCL register, the SMBus controller first updates the SMB_STS register and then clears the SMB_PRTCL register. After the SMB_PRTCL register is cleared, the host controller query value is raised. All other protocol values are reserved.
7-bit SMBus address. This address is not zero aligned (in other words, it is only a 7bit address (A6:A0) that is aligned from bit 1-7).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Slave address (A6:A0) of the SMBus device that initiated the SMBus alarm message.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The alarm address and alarm data registers are not read by OSPM until the alarm status bit is set. OSPM driver then reads the 3 bytes, and clears the alarm status bit to indicate that the alarm registers are now available for the next event.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Note: The following restrictions apply: The aggregate data length of the write and read blocks must not exceed 32 bytes and each block (write and read) must contain at least 1 byte of data.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 13-4 SMB EC Interface (continued) BASE+16 BASE+17 BASE+18 BASE+19 BASE+20 BASE+21 BASE+22 BASE+23 BASE+24 BASE+25 BASE+26 BASE+27 BASE+28 BASE+29 BASE+30 BASE+31 BASE+32 BASE+33 BASE+34 BASE+35 BASE+36 BASE+37 BASE+38 BASE+39 SMB_DATA[12] SMB_DATA[13] SMB_DATA[14] SMB_DATA[15] SMB_DATA[16] SMB_DATA[17] SMB_DATA[18] SMB_DATA[19] SMB_DATA[20] SMB_DATA[21] SMB_DATA[22] SMB_DATA[23] SMB_DATA[24] SMB_DATA[25] SMB_DATA[26] SMB_DATA[27] SMB_DATA[28] SMB_DATA[29] SMB_DATA[30] SMB_DATA[31] SMB_BCNT SMB_ALRM_ADDR SMB_ALRM_DATA[0] SMB_ALRM_DATA[1] Data register twelve Data register thirteen Data register fourteen Data register fifteen Data register sixteen Data register seventeen Data register eighteen Data register nineteen Data register twenty Data register twenty-one Data register twenty-two Data register twenty-three Data register twenty-four Data register twenty-five Data register twenty-six Data register twenty-seven Data register twenty-eight Data register twenty-nine Data register thirty Data register thirty-one Block Count Register Alarm address Alarm data register zero Alarm data register one
Compaq/Intel/Microsoft/Phoenix/Toshiba
_HID
_GPE
Compaq/Intel/Microsoft/Phoenix/Toshiba
_EC
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
306 Advanced Configuration and Power Interface Specification Table 14-1 SMBus Protocol Types Value 0x02 0x04 0x06 0x08 0x0A 0x0C 0x0D Type SMBQuick SMBSendReceive SMBByte SMBWord SMBBlock SMBProcessCall SMBBlockProcessCall Description SMBus Read/Write Quick Protocol SMBus Send/Receive Byte Protocol SMBus Read/Write Byte Protocol SMBus Read/Write Word Protocol SMBus Read/Write Block Protocol SMBus Process Call Protocol SMBus Write Block-Read Block Process Call Protocol
All other protocol values are reserved. Notice that bit 7 of the protocol value is used by this interface to indicate to the SMB-HC whether or not packet error checking (PEC) should be employed for a transaction. Packet error checking is described in section 7.4 of the System Management Bus Specification, Version 1.1 . This highly desirable capability improves the reliability and robustness of SMBus communications. The bit encoding of the protocol value is shown below. For example, the value 0x86 would be used to specify the PEC version of the SMBus Read/Write Byte protocol.
Bits 6:0 = Protocol 7 6 5 4 3 2 1 0
Figure 14-1 Bit Encoding Example Notice that bit 0 of the protocol value is always zero (even number hexadecimal values). In a manner similar to the slave address, software that implements the SMBus interface is responsible for setting this bit to indicate whether the transaction is a read (for example, Read Byte) or write (for example, Write Byte) operation. For example, software implanting this interface for EC-SMBus segments would set bit 0 for read transactions. For the SMBByte protocol (0x06), this would result in the value 0x07 being placed into the SMB_PRTCL register (or 0x87 if PEC is requested).
Compaq/Intel/Microsoft/Phoenix/Toshiba
// EC-based SMBus 1.0 compatible Host Controller // EC offset 0x20, query bit 0x30
EC-based SMBus 2.0-compatible host controllers should be defined similarly in the name space as follows:
Device (SMB0) { Name(_HID, "ACPI0005") Name(_EC1, 0x2030) : }
// EC-based SMBus 2.0 compatible Host Controller // EC offset 0x20, query bit 0x30
NonEC-based SMB-HCs should be modeled in a manner similar to the EC-based SMBus HC. An example definition is given below. These devices use a vendor-specific hardware identifier (HID) to specify the type of SMB-HC (do not use ACPI0001 or ACPI0005). Using a vendor-specific HID allows the correct software to be loaded to service this segments SMBus address space.
Device(SMB0) { Name(_HID, "<Vendor-Specific HID>") : }
// Vendor-Specific HID
Regardless of the type of hardware, some OS software element (for example, the SMBus HC driver) must register with OSPM to support all SMBus operation regions defined for the segment. This software allows the generic SMBus interface defined in this section to be used on a specific hardware implementation by translating between the conceptual (for example, SMBus address space) and physical (for example, process of writing/reading registers) models. Because of this linkage, SMBus operation regions must be defined immediately within the scope of the corresponding SMBus device.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Where: RegionName specifies a name for this slave device (for example, SBD0). RegionSpace must be set to SMBus (operation region type value 0x04). Offset is a word -sized value specifying the slave address and initial command value offset for the target device. The slave address is stored in the high byte and the command value offset is stored in the low byte. For example, the value 0x4200 would be used for an SMBus device residing at slave address 0x42 with an initial command value offset of zero (0). Length is set to the 0x100 (256), representing the maximum number of possible command values, for regions with an initial command value offset of zero (0). The difference of these two values is used for regions with non-zero offsets. For example, a region with an Offset value of 0x4210 would have a corresponding Length of 0xF0 (0x100 minus 0x10). For example, the Smart Battery Subsystem (illustrated below) consists of the Smart Battery Charger at slave address 0x09, the Smart Battery System Manager at slave address 0x0A, and one or more batteries (multiplexed) at slave address 0x0B. (Notice that Figure 14-1 represents the logical connection of a Smart Battery Subsystem. The actual physical connections of the Smart Battery(s) and the Smart Battery Charger are made through the Smart Battery System Manager.) All devices support the Read/Write Word protocol. Batteries also support the Read/Write Block protocol.
EC
'SMB0'
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following ASL code shows the use of the OperationRegion term to describe these SMBus devices:
Device (SMB0) { Name(_HID, "ACPI0001") Name(_EC, 0x2030)
// EC-SMBus Host Controller // EC offset 0x20, query bit 0x30 // Smart Battery Charger // Smart Battery Selector // Smart Battery Device(s)
OperationRegion(SBC0, SMBus, 0x0900, 0x100) OperationRegion(SBS0, SMBus, 0x0A00, 0x100) OperationRegion(SBD0, SMBus, 0x0B00, 0x100) : }
Notice that these operation regions in this example are defined within the immediate context of the owning EC-SMBus device. Each definition corresponds to a separate slave address (device), and happens to use an initial command value offset of zero (0).
Where: RegionName specifies the operation region name previously defined for the device. AccessType must be set to BufferAcc. This indicates that access to field elements will be done using a region-specific data buffer. For this access type, the field handler is not aware of the data buffers contents and must copy the entire buffer bi-directionally (see section 14.6, Declaring an SMBus Data Buffer). LockRule indicates if access to this operation region requires acquisition of the Global Lock for synchronization. This field should be set to Lock on system with firmware that may access the SMBus, and NoLock otherwise. UpdateRule is not applicable to SMBus operation regions since each virtual register is accessed in its entirety. This field is omitted from all SMBus field definitions. SMBus operation regions require that all field elements be declared at command value granularity. This means that each virtual register cannot be broken down to its individual bits within the field definition. Access to sub-portions of virtual registers can be done only outside of the field definition. This limitation is imposed both to simplify the SMBus interface and to maintain consistency with the physical model defined by the SMBus specification. SMBus protocols are assigned to field elements using the AccessAs term within the field definition. The syntax for this term (from section 16.1.3, ASL Language and Terms) is described below.
AccessAs( AccessType, //AccessTypeKeyword AccessAttribute //Nothing | ByteConst | AccessAttribKeyword )
Where: AccessType must be set to BufferAcc. AccessAttribute indicates the SMBus protocol to assign to command values that follow this term. See section 14.1.2, SMBus Protocols, for a listing of the SMBus protocol types and values.
Compaq/Intel/Microsoft/Phoenix/Toshiba
310 Advanced Configuration and Power Interface Specification An AccessAs term must appear as the first entry in a field definition to set the initial SMBus protocol for the field elements that follow. A maximum of one SMBus protocol may be defined for each field element. Devices supporting multiple protocols for a single command value can be modeled by specifying multiple field elements with the same offset (command value), where each field element is preceded by an AccessAs term specifying an alternate protocol. For example, the register at command value 0x08 for a Smart Battery device (illustrated below) represents a word value specifying the battery temperature (in degrees Kelvin), while the register at command value 0x20 represents a variable-length (0 to 32 bytes) character string specifying the name of the company that manufactured the battery.
Smart Battery Device Command Value ManufacturerAccess() RemainingCapacityAlarm() 0x00 (Word) 0x01 (Word) Register Byte 0 Byte 0 Byte 1 Byte 1
:
Temperature() 0x08 (Word) Byte 0 Byte 1
:
ManufacturerName() DeviceName() 0x20 (Block) 0x21 (Block) Byte 0 Byte 0 ... ... Byte 31 Byte 31
:
Figure 14-3 Smart Battery Device Virtual Registers The following ASL code shows the use of the OperationRegion, Field, AccessAs , and Offset terms to represent these Smart Battery device virtual registers:
OperationRegion(SBD0, SMBus, 0x0B00, 0x0100) Field(SBD0, BufferAcc, NoLock) { AccessAs(BufferAcc, SMBWord) // Use the SMBWord protocol for the following MFGA, 8, // ManufacturerAccess() [command value 0x00] RCAP, 8, // RemainingCapacityAlarm() [command value 0x01] Offset(0x08) // Skip to command value 0x08 BTMP, 8, // Temperature() [command value 0x08] Offset(0x20) // Skip to command value 0x20 AccessAs(BufferAcc, SMBBlock) // Use the SMBBlock protocol for the following MFGN, 8, // ManufacturerName() [command value 0x20] DEVN, 8 // DeviceName() [command value 0x21] }
Notice that command values are equivalent to the field elements byte offset (for example, MFGA=0, RCAP=1, BTMP=8). The AccessAs term indicates which SMBus protocol to use for each command value.
Compaq/Intel/Microsoft/Phoenix/Toshiba
For SMBus operation regions, this data buffer is defined as a fixed-length 34-byte buffer that, if represented using a C-styled declaration, would be modeled as follows:
typedef struct { BYTE Status; BYTE Length; BYTE[32] Data; }
// Byte 0 of the data buffer // Byte 1 of the data buffer // Bytes 2 through 33 of the data buffer
Where: Status (byte 0) indicates the status code of a given SMBus transaction. See section 14.1.3, SMBus Status Code, for more information. Length (byte 1) specifies the number of bytes of valid data that exists in the data bufferUse of this field is only defined for the Read/Write Block protocol, where valid Length values are 0 through 32. For other protocols where the data length is implied by the protocolthis field is reserved. Data (bytes 2-33) represents a 32-byte buffer, and is the location where actual data is stored. For example, the following ASL shows the use of the SMBus data buffer for performing transactions to a Smart Battery device. This code is based on the example ASL presented in section 14.5, Declaring SMBus Fields, which lists the operation region and field definitions for the Smart Battery device.
/* Create the SMBus data buffer */ Name(BUFF, Buffer(34){}) CreateByteField(BUFF, 0x00, OB1) CreateByteField(BUFF, 0x01, OB2) CreateWordField(BUFF, 0x02, OB3) CreateField(BUFF, 0x16, 256, OB4) // // // // // Create SMBus data buffer as BUFF OB1 = Status (Byte) OB2 = Length (Byte) OB3 = Data (Word Bytes 2 & 3) OB4 = Data (Block Bytes 2-33)
/* Read the battery temperature */ Store(BTMP, BUFF) // Invoke Read Word transaction If(LEqual(OB1, 0x00)) // Successful? { // OB3 = Battery temperature in 1/10th degrees Kelvin } /* Read the battery manufacturer name */ Store(MFGN, BUFF) // Invoke Read Block transaction If(LEqual(OB1, 0x00)) // Successful? { // OB2 = Length of the manufacturer name // OB4 = Manufacturer name (as a counted string) }
Notice the use of the CreateFieldprimitives to access the data buffers sub-elements (Status, Length, and Data), where Data (bytes 2-33) is typecast as both word (OB3) and block (OB4) data.
Compaq/Intel/Microsoft/Phoenix/Toshiba
312 Advanced Configuration and Power Interface Specification The following ASL code illustrates how a device supporting the Read/Write Quick protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200, 0x100) // SMBus device at slave address 0x42 Field(SMBD, BufferAcc, NoLock) { AccessAs(BufferAcc, SMBQuick) // Use the SMBus Read/Write Quick protocol FLD0, 8 // Virtual register at command value 0. } /* Create the SMBus data buffer */ Name(BUFF, Buffer(34){}) CreateByteField(BUFF, 0x00, OB1) /* Signal device (e.g. OFF) */ Store(FLD0, BUFF) If(LEqual(OB1, 0x00)) {} /* Signal device (e.g. ON) */ Store(BUFF, FLD0) If(LEqual(OB1, 0x00)) {} // Create SMBus data buffer as BUFF // OB1 = Status (Byte) // Invoke Read Quick transaction // Successful? // Invoke Write Quick transaction // Successful?
In this example, a single field element (FLD0) at offset 0 is defined to represent the protocols read/write bit. Access to FLD0 will cause an SMBus transaction to occur to the device. Reading the field results in a Read Quick, and writing to the field results in a Write Quick. In either case data is not transferredaccess to the register is simply used as a mechanism to invoke the transaction.
/* Receive a byte of data from the device */ Store(FLD0, BUFF) // Invoke a Receive Byte transaction If(LEqual(STAT, 0x00)) // Successful? { // DATA = Received byte } /* Send the byte 0x16 to the device */ Store(0x16, DATA) // Save 0x16 into the data buffer Store(BUFF, FLD0) // Invoke a Send Byte transaction If(LEqual(STAT, 0x00)) {} // Successful?
In this example, a single field element (FLD0) at offset 0 is defined to represent the protocols data byte. Access to FLD0 will cause an SMBus transaction to occur to the device. Reading the field results in a Receive Byte, and writing to the field results in a Send Byte.
Compaq/Intel/Microsoft/Phoenix/Toshiba
// Create SMBus data buffer as BUFF // STAT = Status (Byte) // DATA = Data (Byte)
/* Read a byte of data from the device using command value 1 */ Store(FLD1, BUFF) // Invoke a Read Byte transaction If(LEqual(STAT, 0x00)) // Successful? { // DATA = Byte read from FLD1 } /* Write the byte 0x16 to the device using command value 2 */ Store(0x16, DATA) // Save 0x16 into the data buffer Store(BUFF, FLD2) // Invoke a Write Byte transaction If(LEqual(STAT, 0x00)) {} // Successful?
In this example, three field elements (FLD0, FLD1, and FLD2) are defined to represent the virtual registers for command values 0, 1, and 2. Access to any of the field elements will cause an SMBus transaction to occur to the device. Reading FLD1 results in a Read Byte with a command value of 1, and writing to FLD2 results in a Write Byte with command value 2.
/* Read two bytes of data from the device using command value 1 */ Store(FLD1, BUFF) // Invoke a Read Word transaction If(LEqual(STAT, 0x00)) // Successful? { // DATA = Word read from FLD1 }
Compaq/Intel/Microsoft/Phoenix/Toshiba
In this example, three field elements (FLD0, FLD1, and FLD2) are defined to represent the virtual registers for command values 0, 1, and 2. Access to any of the field elements will cause an SMBus transaction to occur to the device. Reading FLD1 results in a Read Word with a command value of 1, and writing to FLD2 results in a Write Word with command value 2. Notice that although accessing each field element transmits a word (16 bits) of data, the fields are listed as 8 bits each. The actual data size is determined by the protocol. Every field element is declared with a length of 8 bits so that command values and byte offsets are equivalent.
/* Read block data from the device using command value 1 */ Store(FLD1, BUFF) // Invoke a Read Block transaction If(LEqual(STAT, 0x00)) // Successful? { // SIZE = Size (number of bytes) of the block data read from FLD1 // DATA = Block data read from FLD1 } /* Write the block TEST to the device using command value 2 */ Store(TEST, DATA) // Save TEST into the data buffer Store(4, SIZE) // Length of valid data in the data buffer Store(BUFF, FLD2) // Invoke a Write Word transaction If(LEqual(STAT, 0x00)) {} // Successful?
In this example, three field elements (FLD0, FLD1, and FLD2) are defined to represent the virtual registers for command values 0, 1, and 2. Access to any of the field elements will cause an SMBus transaction to occur to the device. Reading FLD1 results in a Read Block with a command value of 1, and writing to FLD2 results in a Write Block with command value 2.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following ASL code illustrates how a device supporting the Process Call protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200, 0x100) Field(SMBD, BufferAcc, NoLock) { AccessAs(BufferAcc, SMBProcessCall) // FLD0, 8, // FLD1, 8, // FLD2, 8 // } /* Create the SMBus data buffer */ Name(BUFF, Buffer(34){}) CreateByteField(BUFF, 0x00, STAT) CreateWordField(BUFF, 0x02, DATA) // SMBus device at slave address 0x42
SMBus Process Call protocol register at command value 0. register at command value 1. register at command value 2.
// Create SMBus data buffer as BUFF // STAT = Status (Byte) // DATA = Data (Word)
/* Process Call with input value 0x5416 to the device using command value 1 */ Store(0x5416, DATA) // Save 0x5416 into the data buffer Store(BUFF, FLD1) // Invoke a Process Call transaction If(LEqual(STAT, 0x00)) // Successful? { // DATA = Word returned from FLD1 }
In this example, three field elements (FLD0, FLD1, and FLD2) are defined to represent the virtual registers for command values 0, 1, and 2. Access to any of the field elements will cause an SMBus transaction to occur to the device. Reading or writing FLD1 results in a Process Call with a command value of 1. Notice that unlike other protocols, Process Call involves both a write and read operation in a single atomic transaction. This means that the Data element of the SMBus data buffer is set with an input value before the transaction is invoked, and holds the output value following the successful completion of the transaction.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Other
Undefined
The BIOS can use the AddressRangeReserved address range type to block out various addresses as not suitable for use by a programmable device. Some of the reasons a BIOS would do this are: The address range contains system ROM. The address range contains RAM in use by the ROM. The address range is in use by a memory-mapped system device. The address range is, for whatever reason, unsuitable for a standard device to use as a device memo ry space. Note: OSPM will not save or restore memory reported as AddressRangeReserved when transitioning to or from the S4 sleeping state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The memory map conveyed by this interface is not required to reflect any changes in available physical memory that have occurred after the BIOS has initially passed control to the operating system. For example, if memory is added dynamically, this interface is not required to reflect the new system memory configuration. Table 15-2 Input EAX EBX Function Code Continuation E820h Contains the continuation value to get the next range of physical memory. This is the value returned by a previous call to this routine. If this is the first call, EBX must contain zero. Pointer to an Address Range Descriptor structure that the BIOS fills in. The length in bytes of the structure passed to the BIOS. The BIOS fills in the number of bytes of the structure indicated in the ECX register, maximum, or whatever amount of the structure the BIOS implements. The minimum size that must be supported by both the BIOS and the caller is 20 bytes. Future implementations might extend this structure. SMAP Used by the BIOS to verify the caller is requesting the system map information to be returned in ES:DI. Table 15-3 Output CF EAX ES:DI ECX EBX Carry Flag Signature Buffer Pointer Buffer Size Continuation Non-Carry Indicates No Error SMAP. Signature to verify correct BIOS revision. Returned Address Range Descriptor pointer. Same value as on input. Number of bytes returned by the BIOS in the address range descriptor. The minimum size structure returned by the BIOS is 20 bytes. Contains the continuation value to get the next address range descriptor. The actual significance of the continuation value is up to the discretion of the BIOS. The caller must pass the continuation value unchanged as input to the next iteration of the E820 call in order to get the next Address Range Descriptor. A return value of zero means that this is the last descriptor. Note: the BIOS can also indicate that the last descriptor has already been returned during previous iterations by returning the carry flag set. The caller will ignore any other information returned by the BIOS when the carry flag is set. Table 15-4 Address Range Descriptor Structure Offset in Bytes 0 4 8 12 16 Name BaseAddrLow BaseAddrHigh LengthLow LengthHigh Type Description Low 32 Bits of Base Address High 32 Bits of Base Address Low 32 Bits of Length in Bytes High 32 Bits of Length in Bytes Address type of this range
ES:DI ECX
EDX
Signature
Compaq/Intel/Microsoft/Phoenix/Toshiba
318 Advanced Configuration and Power Interface Specification The BaseAddrLow and BaseAddrHigh together are the 64-bit base address of this range. The base address is the physical address of the start of the range being specified. The LengthLow and LengthHigh together are the 64-bit length of this range. The length is the physical contiguous length in bytes of a range being specified. The Type field describes the usage of the described address range as defined in Table 15-1.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 15-5 EFI Memory Types and mapping to ACPI address range types (continued) Type 2 Mnemonic EfiLoaderData Description The Loader and/or OS may use this memory as they see fit. Note: the OS loader that called ExitBootServices() is utilizing out of one or more EfiLoaderData sections. 3 4 5 EfiBootServicesCode EfiBootServicesData EfiRuntimeServiceCode Memory available for general use. Memory available for general use. The OS and loader must preserve this memory range in the working and ACPI S1 S3 states. The OS and loader must preserve this memory range in the working and ACPI S1 S3 states. Memory available for general use. The memory is to be preserved by the loader and OS until ACPI in enabled. Once ACPI is enabled, the memory in this range is available for general use. The OS and loader must preserve this memory range in the working and ACPI S1 S3 states. The OS does not use this memory. All system memory-mapped I/O port space information should come from ACPI tables. The OS does not use this memory. All system memory-mapped I/O port space information should come from ACPI tables. The OS and loader must preserve this memory range in the working and ACPI S1 S3 states. Memory reserved by system firmware. AddressRangeMemory AddressRangeMemory AddressRangeReserved ACPI Address Range Type AddressRangeMemory
EfiRuntimeServicesData
AddressRangeReserved
7 8
EfiConventionalMemory EfiACPIReclainMemory
AddressRangeMemory AddressRangeACPI
EfiACPIMemoryNVS
AddressRangeNVS
10
EfiMemoryMappedIO
AddressRangeReserved
11
EfiMemoryMappedIOPor tSpace
AddressRangeReserved
12
EfiPalCode
AddressRangeReserved
13
EfiFirmwareReserved
AddressRangeReserved
Compaq/Intel/Microsoft/Phoenix/Toshiba
000F 0000 0010 0000 0080 0000 0100 0000 FEC0 0000 FEE0 0000 FFFF 0000
64 KB 7 MB 4 MB 120 MB 4 KB 4 KB 64 KB
Compaq/Intel/Microsoft/Phoenix/Toshiba
if (Regs.ecx < 20 || Reg.ecx > sizeof (Descriptor) ) { // bug in bios - all returned descriptors must be // at least 20 bytes long, and cannot be larger then // the input buffer. break; } E820Present = TRUE; . . . Add address range Descriptor.BaseAddress through Descriptor.BaseAddress + Descriptor.Length as type Descriptor.Type . . . } while (Regs.ebx != 0); if (!E820Present) { . . . call INT-15 88 and/or INT-15 E801 to obtain old style memory information . . . }
Compaq/Intel/Microsoft/Phoenix/Toshiba
FixedList refers to a list, of known length, that supplies data that all instances of a given ObjectType must have. A fixed list is written as ( a , b , c , ) where the number of arguments depends on the specific ObjectType , and some elements can be nested objects, that is (a, b, (q, r, s, t), d) . Arguments to a FixedList can have default values, in which case they can be skipped. Thus, (a,,c) will cause the default value for the second argument to be used. Some ObjectTypes can have a null FixedList, which is simply omitted. Trailing arguments of some object types can be left out of a fixed list, in which case the default value is used. VariableList refers to a list, not of predetermined length, of child objects that help define the parent. It is written as { x, y, z, aa, bb, cc } where any argument can be a nested object. ObjectType determines what terms are legal elements of the VariableList. Some ObjectTypes may have a null variable list, which is simply omitted. Other rules for writing ASL statements are the following: Multiple blanks are the same as one. Blank, (, ), , and newline are all token separators. // marks the beginning of a comment, which continues from the // to the end of the line. /* marks the beginning of a comment, which continues from the /* to the next */. surround an ASCII string. Numeric constants can be written in three ways: ordinary decimal, octal (using 0ddd ) or hexadecimal, using the notation 0xdd. Nothing indicates an empty item. For example, { Nothing } is equivalent to {}.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 16-1 ASL Grammar Notation Notation Convention Term := Term Term Description The term to the left of := can be expanded into the sequence of terms on the right. Used to group items. Example aterm := bterm cterm means that aterm can be expanded into the twoterm sequence of bterm followed by cterm. <a b> | <c d> means either a b or c d. Bar symbol ( | ) Separates alternatives. aterm := bterm | <cterm dterm> means the following constructs are possible: bterm cterm dterm aterm := <bterm | cterm> dterm means the following constructs are possible: bterm dterm cterm dterm Term Term Term Word in bold. Terms separated from each other by spaces form an ordered list. Denotes the name of a term in the ASL grammar, representing any instance of such a term. ASL terms are not case-sensitive. N/A In the following ASL term definition: ThermalZone ( ZoneName ) {ObjectList} the item in bold is the name of the term. Word in italics Names of arguments to objects that are replaced for a given instance. In the following ASL term definition: ThermalZone ( ZoneName ) {ObjectList} the italicized item is an argument. The item that is not bolded or italicized is defined elsewhere in the ASL grammar. Single quotes ( ) 0xdd Indicate constant characters. Refers to a byte value expressed as 2two hexadecimal digits. A 0x21 means a value of hexadecimal 21, or decimal 33. Notice that a value expressed in hexadecimal must start with a leading zero (0). 1-9 means a single digit in the range 1 to 9 inclusive.
Dash character ( - )
Indicates a range.
Compaq/Intel/Microsoft/Phoenix/Toshiba
:= := := := :=
TermList Term CompilerDirective ObjectList Object DataObject DataRefObject ComputationalData BufferData PackageData IntegerData StringData NamedObject
:= Nothing | <Term TermList> := Object | Type1Opcode | Type2Opcode := IncludeTerm | ExternalTerm := Nothing | <Object ObjectList> := CompilerDirective | NamedObject | NameSpaceModifier := BufferData | PackageData | IntegerData | StringData := DataObject | ObjectReference | DDBHandle := := := := := BufferData | IntegerData | StringData Type5Opcode | BufferTerm PackageTerm Type3Opcode | Integer | ConstTerm Type4Opcode | String
:= BankFieldTerm | CreateBitFieldTerm | CreateByteFieldTerm | CreateDWordFieldTerm | CreateFieldTerm | CreateQWordFieldTerm | CreateWordFieldTerm | DataRegionTerm | DeviceTerm | EventTerm | FieldTerm | IndexFieldTerm | MethodTerm | MutexTerm | OpRegionTerm | PowerResTerm | ProcessorTerm | ThermalZoneTerm := AliasTerm | NameTerm | ScopeTerm := NameString ( //NameString=>Method ArgList ) => Nothing | DataRefObject := Nothing | <TermArg ArgListTail> := Nothing | <, TermArg ArgListTail> := Type2Opcode | DataRefObject | ArgTerm | LocalTerm := Nothing | SuperName
Compaq/Intel/Microsoft/Phoenix/Toshiba
Type1Opcode
:= BreakTerm | BreakPointTerm | ContinueTerm | FatalTerm | IfElseTerm | LoadTerm | NoOpTerm | NotifyTerm | ReleaseTerm | ResetTerm | ReturnTerm | SignalTerm | SleepTerm | StallTerm | SwitchTerm | UnloadTerm | WhileTerm // A Type1OpCode term can only be used standing alone on a // line of ASL code; because these types of terms do not // return a value so they cannot be used as a term in an // expression. := AcquireTerm | AddTerm | AndTerm | BuffTerm | ConcatTerm | ConcatResTerm | CondRefOfTerm | CopyTerm | DecTerm | DecStrTerm | DerefOfTerm | DivideTerm | FindSetLeftBitTerm | FindSetRightBitTerm | FromBCDTerm | HexStrTerm | IncTerm | IndexTerm | IntTerm | LAndTerm | LEqualTerm | LGreaterTerm | LGreaterEqualTerm | LLessTerm | LLessEqualTerm | LNotTerm | LNotEqualTerm | LoadTableTerm | LOrTerm | MatchTerm | MidTerm | ModTerm | MultiplyTerm | NAndTerm | NOrTerm | NotTerm | ObjectTypeTerm | OrTerm | RefOfTerm | ShiftLeftTerm | ShiftRightTerm | SizeOfTerm | StoreTerm | StringTerm | SubtractTerm | ToBCDTerm | WaitTerm | XorTerm | UserTerm // A Type2Opcode term returns a value that can be used // inan expression. := AddTerm | AndTerm | DecTerm | DivideTerm | EISAIDTerm | FindSetLeftBitTerm | FindSetRightBitTerm | FromBCDTerm | IncTerm | IndexTerm | IntTerm | LAndTerm | LEqualTerm | LGreaterTerm | LGreaterEqualTerm | LLessTerm | LLessEqualTerm | LNotTerm | LNotEqualTerm | LOrTerm | MatchTerm | ModTerm | MultiplyTerm | NAndTerm | NOrTerm | NotTerm | OrTerm | ShiftLeftTerm | ShiftRightTerm | SubtractTerm | ToBCDTerm | XorTerm // A Type3Opcode evaluates to an Integer, cant have a // destination and must have either Type3Opcode, // Type4Opcode, Type5Opcode, ConstExprTerm, Integer, // BufferTerm, Package or String for all arguments. := ConcatTerm | DecStrTerm | HexStrTerm | MidTerm | StringTerm // A Type4Opcode evaluates to an String, cant have a // destination and must have either Type3Opcode, // Type4Opcode, Type5Opcode, ConstExprTerm, Integer, // BufferTerm, PackageTerm or String for all arguments. := BuffTerm | ConcatTerm | ConcatResTerm | MidTerm | ResourceTemplateTerm | UnicodeTerm // A Type5Opcode evaluates to a BufferTerm, cant // have a destination and must have either Type3Opcode, // Type4Opcode, Type5Opcode, ConstExprTerm, Integer, // BufferTerm, PackageTerm or String for all arguments. := RefOfTerm | DerefOfTerm | IndexTerm | UserTerm := Include( IncFilePathName ) := External( ObjName, ObjType ) //StringData
Type2Opcode
Type3Opcode
Type4Opcode
Type5Opcode
Type6Opcode IncludeTerm
ExternalTerm
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
:= Nothing | <FieldUnit FieldUnitListTail> := Nothing | <, FieldUnit FieldUnitListTail> := FieldUnitEntry | OffsetTerm | AccessAsTerm := <Nothing | NameSeg> , Integer := Offset( ByteOffset ) := AccessAs( AccessType, AccessAttribute ) //IntegerData
AccessAsTerm
CreateBitFieldTerm
:= CreateBitField( SourceBuffer, BitIndex, BitFieldName ) := CreateByteField( SourceBuffer, ByteIndex, ByteFieldName ) := CreateDWordField( SourceBuffer, ByteIndex, DWordFieldName ) := CreateField( SourceBuffer, BitIndex, NumBits, FieldName ) := CreateQWordField( SourceBuffer, ByteIndex, Q WordFieldName ) := CreateWordField( SourceBuffer, ByteIndex, WordFieldName ) := DataTableRegion( RegionName, SignatureString, OemIDString, OemTableIDString ) := Device( DeviceName ) { ObjectList } := Event( EventName )
CreateByteFieldTerm
CreateDWordFieldTerm
CreateFieldTerm
CreateQWordFieldTerm
CreateWordFieldTerm
DataRegionTerm
// // // //
DeviceTerm
//NameString
EventTerm
//NameString
Compaq/Intel/Microsoft/Phoenix/Toshiba
IndexFieldTerm
MethodTerm
//NameString //ByteConstExpr
OpRegionTerm
PowerResTerm
ProcessorTerm
ThermalZoneTerm
//NameString
AliasTerm
//NameString //NameString
NameTerm
//NameString //DataRefObject
ScopeTerm
//NameString
Compaq/Intel/Microsoft/Phoenix/Toshiba
FatalTerm
IfElseTerm IfTerm
//TermArg=>Integer
ElseTerm LoadTerm
:= Nothing | <Else {TermList }> | <ElseIf {TermList } ElseTerm> := Load( Object, DDBHandle ) := Noop := Notify( Object, //SuperName=>ThermalZone|Processor|Device NotificationValue //TermArg=>Integer ) := Release( SyncObject ) := Reset( SyncObject ) := Return( Arg ) := Signal( SyncObject ) := Sleep( MilliSecs ) := Stall( MicroSecs ) //SuperName //NameString //SuperName
NoOpTerm NotifyTerm
ReleaseTerm
ResetTerm
//SuperName
ReturnTerm
//TermArg=>DataRefObject
SignalTerm
//SuperName
SleepTerm
//TermArg=>Integer
StallTerm
//TermArg=>Integer
SwitchTerm
:= Switch( Predicate //TermArg=>ComputationalData ) { CaseTermList} := Nothing | CaseTerm | DefaultTerm DefaultTermList | CaseTerm CaseTermList := Nothing | CaseTerm | CaseTerm DefaultTermList := Case( Value //DataObject ) { TermList } := Default {TermList} := Unload( DDBHandle ) := While( Predicate ) { TermList } //SuperName
WhileTerm
//TermArg=>Integer
Compaq/Intel/Microsoft/Phoenix/Toshiba
AddTerm
//TermArg=>ComputationalData //Target
ConcatTerm
ConcatResTerm
CondRefOfTerm
//SuperName //Target
CopyTerm
DecStrTerm
//TermArg=>ComputationalData //Target
DerefOfTerm
//TermArg=>ObjectReference //ObjectReference is an
Compaq/Intel/Microsoft/Phoenix/Toshiba
FindSetLeftBitTerm
:= FindSetLeftBit( Source, Result ) => Integer := FindSetRightBit( Source, Result ) => Integer := FromBCD( BCDValue, Result ) => Integer := HexStr( Data, Result ) => String := Increment( Addend ) => Integer := Index( Source, PackageTerm> Index, Destination ) => ObjectReference
//TermArg=>Integer //Target
FindSetRightBitTerm
//TermArg=>Integer //Target
FromBCDTerm
//TermArg=>Integer //Target
HexStrTerm
//TermArg=>ComputationalData //Target
IncTerm
//SuperName
IndexTerm
IntTerm
LAndTerm
:= LAnd( Source1, Source2 ) => Boolean := LEqual( Source1, Source2 ) => Boolean := LGreater( Source1, Source2 ) => Boolean := LGreaterEqual( Source1, Source2 ) => Boolean := LLess( Source1, Source2 ) => Boolean := LLessEqual( Source1, Source2 ) => Boolean := LNot( Source, ) => Boolean
//TermArg=>Integer //TermArg=>Integer
LEqualTerm
//TermArg=>ComputationalData //TermArg=>ComputationalData
LGreaterTerm
//TermArg=>ComputationalData //TermArg=>ComputationalData
LGreaterEqualTerm
//TermArg=>ComputationalData //TermArg=>ComputationalData
LLessTerm
//TermArg=>ComputationalData //TermArg=>ComputationalData
LLessEqualTerm
//TermArg=>ComputationalData //TermArg=>ComputationalData
LNotTerm
//TermArg=>ComputationalData
Compaq/Intel/Microsoft/Phoenix/Toshiba
//TermArg=>ComputationalData //TermArg=>ComputationalData
LoadTableTerm
// // // // // //
LOrTerm
MidTerm
MultiplyTerm
:= Multiply( Multiplicand, Multiplier, Result ) => Integer := NAnd( Source1, Source2 Result ) => Integer := NOr( Source1, Source2 Result ) => Integer
NAndTerm
NOrTerm
NotTerm
ObjectTypeTerm
//SuperName
Compaq/Intel/Microsoft/Phoenix/Toshiba
OrTerm
RefOfTerm
:= RefOf( Object ) => ObjectReference := ShiftLeft( Source, ShiftCount Result ) => Integer := ShiftRight( Source, ShiftCount Result ) => Integer
//SuperName
ShiftLeftTerm
ShiftRightTerm
SizeOfTerm
:= SizeOf( DataObject //SuperName=>String|Buffer|Package ) => Integer := Store( Source, Destination ) => DataRefObject := String( Source, Length, Result ) => String := Subtract( Addend1, Addend2, Result ) => Integer := ToBCD( Value, Result ) => Integer := Wait( SyncObject, TimeoutValue ) => Boolean := XOr( Source1, Source2 Result ) => Integer //TermArg=>Integer //TermArg=>Integer //Target //TermArg=>DataRefObject //SuperName
StoreTerm
StringTerm
SubtractTerm
ToBCDTerm
//TermArg=>Integer //Target
WaitTerm
XOrTerm
ObjectTypeKeyword
:= UnknownObj | IntObj | StrObj | BuffObj | PkgObj | FieldUnitObj | DeviceObj | EventObj | MethodObj | MutexObj | OpRegionObj | PowerResObj | ThermalZoneObj | BuffFieldObj | DDBHandleObj := AnyAcc | ByteAcc | WordAcc | DWordAcc | QWordAcc | BufferAcc := SMBQuick | SMBSendReceive | SMBByte | SMBWord | SMBBlock | SMBProcessCall // Note: AccessAttribKeywords are for SMBus BufferAcc only.
AccessTypeKeyword AccessAttribKeyword
Compaq/Intel/Microsoft/Phoenix/Toshiba
AddressSpaceKeyword UserDefRegionSpace SerializeRuleKeyword MatchOpKeyword DMATypeKeyword BusMasterKeyword XferTypeKeyword ResourceTypeKeyword MinKeyword MaxKeyword DecodeKeyword RangeTypeKeyword MemTypeKeyword ReadWriteKeyword InterruptTypeKeyword InterruptLevel ShareTypeKeyword IODecodeKeyword TypeKeyword TranslationKeyword AddressKeyword SuperName ArgTerm LocalTerm DebugTerm LeadDigitChar OctalDigitChar HexDigitChar Integer DecimalConst OctalConst HexConst ByteConst WordConst DWordConst QWordConst String AsciiCharList AsciiChar EscapeSeq SimpleEscapeSeq OctalEscapeSeq OctalDigitChar HexEscapeSeq NullChar ConstTerm Boolean True
:= NameString | ArgTerm | LocalTerm | DebugTerm | Type6Opcode | UserTerm := Arg0 | Arg1 | Arg2 | Arg3 | Arg4 | Arg5 | Arg6 := Local0 | Local1 | Local2 | Local3 | Local4 | Local5 | Local6 | Local7 := Debug := 1- 9 := 0- 7 := DigitChar | A-F | a- f := := := := := := := := DecimalConst | OctalConst | HexConst LeadDigitChar | <DecimalConst DigitChar> 0 | <OctalConst OctalDigitChar> <0x HexDigitChar> | <0X HexDigitChar> | <HexConst HexDigitChar> Integer=>0x00-0xff Integer=>0x0000-0xffff Integer=>0x00000000-0xffffffff Integer=>0x0000000000000000-0xffffffffffffffff
:= AsciiCharList := Nothing | <EscapeSeq AsciiCharList> | <AsciiChar AsciiCharList> := 0x01-0x21 | 0x23-0x5B | 0x5D-0x7F := SimpleEscapeSeq | OctalEscapeSeq | HexEscapeSeq := \' | \" | \a | \b | \f | \n | \r | \t | \v | \\ := \ OctalDigit | \ OctalDigit OctalDigit | \ OctalDigit OctalDigit OctalDigit := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 := \x HexDigitChar | \x HexDigitChar HexDigitChar := 0x00 := Zero | One | Ones | Revision := True | False := Ones
Compaq/Intel/Microsoft/Phoenix/Toshiba
False
:= Zero
Compaq/Intel/Microsoft/Phoenix/Toshiba
BufferTerm
//Nothing | //TermArg=>Integer
:= Nothing | <ByteConstExpr ByteListTail> := Nothing | <, ByteConstExpr ByteListTail> := Nothing | <DWordConstExpr DWordListTail> := Nothing | <, DWordConstExpr DWordListTail> := Package( NumElements //Nothing | //ByteConstExpr | //TermArg=>Integer
) { PackageList} PackageList PackageListTail PackageElement EISAIDTerm := Nothing | <PackageElement PackageListTail> := Nothing | <, PackageElement PackageListTail> := DataObject | NameString := EISAID( EISAIDString ) => DWordConst //StringData
ResourceTemplateTerm UnicodeTerm
ResourceMacroList ResourceMacroTerm
:= Nothing | <ResourceMacroTerm ResourceMacroList> := DMATerm | DWordIOTerm | DWordMemoryTerm | EndDependentFnTerm | FixedIOTerm | InterruptTerm | IOTerm | IRQNoFlagsTerm | IRQTerm | Memory24Term | Memory32FixedTerm | Memory32Term | QWordIOTerm | QWordMemoryTerm | RegisterTerm | StartDependentFnTerm | StartDependentFnNoPriTerm | VendorLongTerm | VendorShortTerm | WordBusNumberTerm | WordIOTerm := DMA( DMAType, BusMaster, XferType, ResourceTag ) { ByteList } //DMATypeKeyword (_TYP) //BusMasterKeyword (_BM) //XferTypeKeyword (_SIZ) //Nothing | NameString //List of channels (0-7)
DMATerm
Compaq/Intel/Microsoft/Phoenix/Toshiba
DWordIOTerm
:= DWordIO( ResourceType, MinType, MaxType, Decode, RangeType, AddressGranularity, MinAddress, MaxAddress, Translation, AddressLen, ResSourceIndex, ResSource, ResourceTag Type TranslationType
//Nothing (ResourceConsumer)| //ResourceTypeKeyword //Nothing (MinNotFixed) | //MinKeyword (_MIF) //Nothing (MaxNotFixed) | //MaxKeyword (_MAF) //Nothing (PosDecode) | //DecodeKeyword (_DEC) //Nothing (EntireRange) | //RangeTypeKeyword (_RNG) //DWordConstExpr (_GRA) //DWordConstExpr (_MIN) //DWordConstExpr (_MAX) //DWordConstExpr (_TRA) //DWordConstExpr (_LEN) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString //Nothing | TypeKeyword //Nothing | TranslationKeyword )
DWordMemoryTerm
:= DWordMemory( ResourceType, Decode, MinType, MaxType, MemType, ReadWriteType, AddressGranularity, MinAddress, MaxAddress, Translation, AddressLen, ResSourceIndex, ResSource, ResourceTag AddressRange TranslationType
//Nothing (ResourceConsumer)| //ResourceTypeKeyword //Nothing (PosDecode) | //DecodeKeyword (_DEC) //Nothing (MinNotFixed) | //MinKeyword (_MIF) //Nothing (MaxNotFixed) | //MaxKeyword (_MAF) //Nothing (NonCacheable) | //MemTypeKeyword (_MEM) //ReadWriteKeyword (_RW) //DWordConstExpr (_GRA) //DWordConstExpr (_MIN) //DWordConstExpr (_MAX) //DWordConstExpr (_TRA) //DWordConstExpr (_LEN) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString //Nothing | AddressKeyword //Nothing | TranslationKeyword
) EndDependentFnTerm FixedIOTerm := EndDependentFn() := FixedIO( AddressBase, RangeLen, ResourceTag ) //WordConstExpr (_BAS) //ByteConstExpr (_LEN) //Nothing | NameString
Compaq/Intel/Microsoft/Phoenix/Toshiba
//Nothing (ResourceConsumer)| //ResourceTypeKeyword //InterruptTypeKeyword //(_LL, _HE) //InterruptLevelKeyword //(_LL, _HE) //Nothing (Exclusive) //ShareTypeKeyword (_SHR) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString //list of interrupts (_INT)
Compaq/Intel/Microsoft/Phoenix/Toshiba
IOTerm
:= IO( IODecode, MinAddress, MaxAddress, Alignment, RangeLen, ResourceTag ) //IODecodeKeyword (_DEC) //WordConstExpr (_MIN) //WordConstExpr (_MAX) //ByteConstExpr (_ALN) //ByteConstExpr (_LEN) //Nothing | NameString
IRQNoFlagsTerm
//Nothing | NameString //list of interrupts (0-15) //InterruptTypeKeyword //(_LL, _HE) //InterruptLevelKeyword //(_LL, _HE) //Nothing (Exclusive) //ShareTypeKeyword (_SHR) //Nothing | NameString //list of interrupts (0-15) //ReadWriteKeyword (_RW) //WordConstExpr (_MIN) //WordConstExpr (_MAX) //WordConstExpr (_ALN) //WordConstExpr (_LEN) //Nothing | NameString
IRQTerm
Memory24Term
:= Memory24( ReadWriteType, MinAddress[23:8], MaxAddress[23:8], Alignment, RangeLen, ResourceTag ) := Memory32Fixed( ReadWriteType, AddressBase, RangeLen, ResourceTag ) := Memory32( ReadWriteType, MinAddress, MaxAddress, Alignment, RangeLen, ResourceTag ) := QWordIO( ResourceType, MinType, MaxType, Decode, RangeType, AddressGranularity, MinAddress, MaxAddress, Translation, AddressLen, ResSourceIndex, ResSource, ResourceTag Type TranslationType
Memory32FixedTerm
Memory32Term
//ReadWriteKeyword (_RW) //DWordConstExpr (_MIN) //DWordConstExpr (_MAX) //DWordConstExpr (_ALN) //DWordConstExpr (_LEN) //Nothing | NameString
QWordIOTerm
//Nothing (ResourceConsumer)| //ResourceTypeKeyword //Nothing (MinNotFixed) | //MinKeyword (_MIF) //Nothing (MaxNotFixed) | //MaxKeyword (_MAF) //Nothing (PosDecode) | //DecodeKeyword (_DEC) //Nothing (EntireRange) | //RangeTypeKeyword (_RNG) //QWordConstExpr (_GRA) //QWordConstExpr (_MIN) //QWordConstExpr (_MAX) //QWordConstExpr (_TRA) //QWordConstExpr (_LEN) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString //Nothing | TypeKeyword //Nothing | TranslationKeyword )
Compaq/Intel/Microsoft/Phoenix/Toshiba
//Nothing (ResourceConsumer)| //ResourceTypeKeyword //Nothing (PosDecode) | //DecodeKeyword (_DEC) //Nothing (MinNotFixed) | //MinKeyword (_MIF) //Nothing (MaxNotFixed) | //MaxKeyword (_MAF) //Nothing (NonCacheable) | //MemTypeKeyword (_MEM) //ReadWriteKeyword (_RW) //QWordConstExpr (_GRA) //QWordConstExpr (_MIN) //QWordConstExpr (_MAX) //QWordConstExpr (_TRA) //QWordConstExpr (_LEN) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString //Nothing | AddressKeyword //Nothing | TranslationKeyword
StartDependentFnTerm
StartDependentFnNoPriTerm VendorLongTerm
:=StartDependentFnNoPri() {ResourceMacroList} := VendorLong( ResourceTag ) { ByteList } := VendorShort( ResourceTag ) { ByteList } := WordBusNumber( ResourceType, MinType, MaxType, Decode, AddressGranularity, MinAddress, MaxAddress, Translation, AddressLen, ResSourceIndex, ResSource, ResourceTag ) //Nothing | NameString
VendorShortTerm
//Nothing | NameString //up to 7 bytes //Nothing (ResourceConsumer)| //ResourceTypeKeyword //Nothing (MinNotFixed) | //MinKeyword (_MIF) //Nothing (MaxNotFixed) | //MaxKeyword (_MAF) //Nothing (PosDecode) | //DecodeKeyword (_DEC) //WordConstExpr (_GRA) //WordConstExpr (_MIN) //WordConstExpr (_MAX) //WordConstExpr (_TRA) //WordConstExpr (_LEN) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString
WordBusNumberTerm
Compaq/Intel/Microsoft/Phoenix/Toshiba
WordIOTerm
:= WordIO( ResourceType, MinType, MaxType, Decode, RangeType, AddressGranularity, MinAddress, MaxAddress, Translation, AddressLen, ResSourceIndex, ResSource, ResourceTag Type TranslationType )
//Nothing (ResourceConsumer)| //ResourceTypeKeyword //Nothing (MinNotFixed) | //MinKeyword (_MIF) //Nothing (MaxNotFixed) | //MaxKeyword (_MAF) //Nothing (PosDecode) | //DecodeKeyword (_DEC) //Nothing (EntireRange) | //RangeTypeKeyword (_RNG) //WordConstExpr _GRA) //WordConstExpr (_MIN) //WordConstExpr (_MAX) //WordConstExpr (_TRA) //WordConstExpr (_LEN) //Nothing | ByteConstExpr //Nothing | StringData //Nothing | NameString //Nothing | TypeKeyword //Nothing | TranslationKeyword
The following table lists the name modifiers that can be prefixed to an ASL name. Table 16-3 Definition Block Name Modifier Encodings Description 5C 5E Namespace root (\) Parent namespace (^) NamePrefix := RootPrefix ParentPrefix Followed by Name ParentPrefix or Name
Compaq/Intel/Microsoft/Phoenix/Toshiba
In this case, the Add operator converts the first two operands (Local0 and 5) to Integers. Then the result of the operation (15) is converted into a String, since this is the type of Local1. In some cases, the operator may take more than one type of operand (such as Integer and String). In this case, depending on the type of the operand, the highest priority conversion is applied. Table 16-4, column describes the source operand conversions available. For example:
Store(Buffer(1){},Local0) Name(ABCD, Buffer(10) {1,2,3,4,5,6,7,8,9,0}) CreateDWordField(ABCD,2,XYZ) Name(MNOP,1234) Concatenate(XYZ,MNOP,Local0)
Concatenate can take an Integer, Buffer or String for its first two parameters and the type of the first parameter determines how the second parameter will be converted. In this example, the first parameter is of type Buffer Field (from the CreateDWordField operator). What should it be converted to: Integer, Buffer or String? According to Table 16-4, the highest priority conversion is to Integer. So XYZ (0x05040302) and MNOP (0x31,0x32,0x33,0x34) will be converted to Integers, joined together and the resulting type will be Buffer (0x02,0x03,0x04,0x05,0x31,0x32,0x33,0x34). The following table describes the default source and destination conversions. If a particular conversion is not described, then it will generate a fatal error at run-time. Table 16-4 ASL Data Types Default Source Conversion (Operand) Nothing. Generates a fatal error when used as an operand. Destination Conversion From Integer String Buffer Package DDB Handle Object Reference
Description No assigned type. The type of all Localx variables at the beginning of a Methods execution and uninitialized Package elements.
What Happens Integer String Buffer Package DDB Handle Object Reference
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 16-4 ASL Data Types (continued) Default Source Conve rsion (Operand) Integer Buffer String DDB Handle Buffer
Description An n -bit little-endian, unsigned integer. In ACPI 1.0 this was at least 32bits. In ACPI 2.0 this is at least 64.bits.
What Happens The ASCII string is interpreted as a hexadecimal content. Starts with the first hexadecimal ASCII character (0-9, AF, a, f) and ends with the first non-hexadecimal character. The contents of the buffer, starting with the least significant bit and continuing through the minimum of the most significant bit number (in other words, # of bytes * 8) in the buffer or the number of bits in an Integer (at least 64 in ACPI 2.0) are copied as an Integer. Creates an ASCII hexadecimal string. Converted to a string of twocharacter hexadecimal numbers, separated by a space. Fatal error if greater than two hundred ASCII characters generated. Generates an error. If the integer requires more bits than the size of the Buffer, then the integer is truncated before being copied to the Buffer. If the integer contains fewer significant bits than the size of the buffer, then the Integer is zero-extended to fill the entire buffer. The string is treated as a Buffer, with each ASCII character making one Buffer byte.
String
Integer Buffer
Compaq/Intel/Microsoft/Phoenix/Toshiba
344 Advanced Configuration and Power Interface Specification Table 16-4 ASL Data Types (continued) Default Source Conversion (Operand) Package
Description Collection of ASL objects with a fixed number of members (up to 255). Bit-aligned variable in an address space.
What Happens All contents of the package are removed. Contents of the source are copied into the package. If the integer requires more bits than the size of the Field Unit, it is broken into pieces and written to the Field Unit, least significant bits first. If the integer (or the last piece of the integer, if broken up) is smaller or equal in size to the Field Unit, then it is zero extended before being written. Each character of the string is written, starting with the first, to the Field Unit. If the Field Unit is less than eight bits, then the upper bits of each character is lost. If the Field Unit is greater than eight bits, then the additional bits are zeroed. If the buffer requires more bits than the size of the Field Unit, it is broken into pieces and written to the Field Unit, lower chunks first. If the integer (or the last piece of the integer, if broken up) is smaller or equal in size to the Field Unit, then it is zero extended before being written.
Integer
If the Field Unit is larger than the size of an Integer, it will be treated as a Buffer.
String
Buffer
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 16-4 ASL Data Types (continued) Default Source Conversion (Operand) Integer Buffer String
Description Piece of a buffer created using CreateBitField, CreateByteField, CreateWordField, CreateQWordField, CreateField or returned by the Index command.
What Happens If the integer is smaller than the size of the buffer field, it is zero extended. If the integer is larger than the size of the buffer field, the upper bits are truncated. Compatibility Note: New in ACPI 2.0. The behavior in ACPI 1.0 was undefined.
String
The string is treated as a buffer. If this buffer is smaller than the size of the buffer field, it is zero extended. If the buffer is larger than the size of the buffer field, the upper bits are truncated. Compatibility Note: New in ACPI 2.0. The behavior in ACPI 1.0 was undefined.
Buffer
If this buffer is smaller than the size of the buffer field, it is zero extended. If the buffer is larger than the size of the buffer field, the upper bits are truncated. Compatibility Note: New in ACPI 2.0. The behavior in ACPI 1.0 was undefined.
DDB Handle Device Event Method Mutex Operation Region Power Resource Processor Thermal Zone
Integer
DDB Handle
Device or bus Event Method (function) Mutex Operation Region Power Resource Processor Thermal Zone
Generates an error. Generates an error. Generates an error. Generates an error. Generates an error. Generates an error. Generates an error. Generates an error.
Compaq/Intel/Microsoft/Phoenix/Toshiba
346 Advanced Configuration and Power Interface Specification Table 16-4 ASL Data Types (continued) Default Source Conversion (Operand) Nothing. Will generate an error when used as a source.
Destination Conversion From Integer String Buffer Package Operation Region Field Unit Buffer Field DDB Handle
What Happens Displayed as hexadecimal integer. Display as ASCII characters. Each byte displayed as hexadecimal integer , delimited. Each element of the package displayed based on its type. Displayed as hexadecimal integer (if less than or equal to the size of an integer). Otherwise displayed as a buffer. Displayed as a hexadecimal integer. Displayed including information about the DDB. Cannot be a destination. Object Reference
Many of the ASL operators can store their result optionally into an object specified by the last parameter. In these operators, if the destination is specified, the action is exactly as if a Store operator had been used to place the result in the destination. Compatibility Note: The ability to store and manipulate object references is new in ACPI 2.0. In ACPI 1.0 references could not be stored in variables, passed as parameters or returned from functions.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The DefinitionBlock term specifies the unit of data and/or AML code that the OS will load as part of the Differentiated Definition Block or as part of an additional Definition Block. This unit of data and/or AML code describes either the base system or some large extension (such as a docking station). The entire DefinitionBlock will be loaded and compiled by the OS as a single unit, and can be unloaded by the OS as a single unit.
IncFilePathname is the full OS file system path to another file that contains ASL terms to be included in the current file of ASL terms.
The External compiler directive is to let the assembler know that the object is declared external to this table so that the assembler will not complain about the undeclared object. During compiling, the assembler will create the external object at the specified place in the namespace (if a full path of the object is specified), or the object will be created at the current scope of the External term. ObjType is optional. If not specified, UnknownObj type is assumed.
Compaq/Intel/Microsoft/Phoenix/Toshiba
This statement creates data field objects. The contents of the created objects are obtained by a reference to a bank selection register. This encoding is used to define named data field objects whose data values are fields within a larger object selected by a bank-selected register. Accessing the contents of a banked field data object will occur automatically through the proper bank setting, with synchronization occurring on the operation region that contains the BankName data variable, and on the Global Lock if specified by the LockRule. The AccessType, LockRule, UpdateRule, and FieldUnitList are the same format as the Field operator.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following is a block of ASL sample code using BankField: Creates a 4-bit bank-selected register in system I/O space. Creates overlapping fields in the same system I/O space that are selected via the bank register.
// define 256-byte operational region in SystemIO space // and name it GIO0 OperationRegion (GIO0, SystemIO, 0x125, 0x100) // create some field in GIO including a 4-bit bank select register Field (GIO0, ByteAcc, NoLock, Preserve) { GLB1, 1, GLB2, 1, Offset(1), // move to offset for byte 1 BNK1, 4 } // Create FET0 & FET1 in bank 0 at byte offset 0x30 BankField (GIO0, BNK1, 0, ByteAcc, NoLock, Preserve) { Offset (0x30), FET0, 1, FET1, 1 } // Create BLVL & BAC in bank 1 at the same offset BankField (GIO0, BNK1, 1, ByteAcc, NoLock, Preserve) { Offset (0x30), BLVL, 7, BAC, 1 }
16.2.3.3.1.2 CreateBitField
CreateBitFieldTerm := CreateBitField( SourceBuffer, BitIndex, BitFieldName ) //TermArg=>Buffer //TermArg=>Integer //NameString
SourceBuffer is evaluated as a buffer. BitIndex is evaluated as an integer. A new buffer field object BitFieldName is created for the bit of SourceBuffer at the bit index of BitIndex. The bit-defined field within SourceBuffer must exist.
16.2.3.3.1.3 CreateByteField
CreateByteFieldTerm := CreateByteField( SourceBuffer, ByteIndex, ByteFieldName ) //TermArg=>Buffer //TermArg=>Integer //NameString
SourceBuffer is evaluated as a buffer. ByteIndex is evaluated as an integer. A new buffer field object ByteFieldName is created for the byte of SourceBuffer at the byte index of ByteIndex. The byte-defined field within SourceBuffer must exist.
16.2.3.3.1.4 CreateDWordField
CreateDWordFieldTerm := CreateDWordField( SourceBuffer, ByteIndex, DWordFieldName ) //TermArg=>Buffer //TermArg=>Integer //NameString
SourceBuffer is evaluated as a buffer. ByteIndex is evaluated as an integer. A new buffer field object DWordFieldName is created for the DWord of SourceBuffer at the byte index of ByteIndex. The DWorddefined field within SourceBuffer must exist.
Compaq/Intel/Microsoft/Phoenix/Toshiba
SourceBuffer is evaluated as a buffer. BitIndex and NumBits are evaluated as integers. A new buffer field object FieldName is created for the bits of SourceBuffer at BitIndex for NumBits. The entire bit range of the defined field within SourceBuffer must exist.
16.2.3.3.1.6 CreateQWordField
CreateQWordFieldTerm := CreateQWordField( SourceBuffer, ByteIndex, QWordFieldName ) //TermArg=>Buffer //TermArg=>Integer //NameString
SourceBuffer is evaluated as a buffer. ByteIndex is evaluated as an integer. A new buffer field object QWordFieldName is created for the QWord of SourceBuffer at the byte index of ByteIndex. The QWorddefined field within SourceBuffer must exist.
16.2.3.3.1.7 CreateWordField
CreateWordFieldTerm := CreateWordField( SourceBuffer, ByteIndex, WordFieldName ) //TermArg=>Buffer //TermArg=>Integer //NameString
SourceBuffer is evaluated as a buffer. ByteIndex is evaluated as an integer. A new bufferfield object WordFieldName is created for the word of SourceBuffer at the byte index of ByteIndex. The word-defined field within SourceBuffer must exist.
16.2.3.3.1.8 DataTableRegion
DataRegionTerm := DataTableRegion ( RegionName, SignatureString, OemIDString, OemTableIDString ) // // // // NameString TermArg=>String TermArg=>String TermArg=>String
A Data Table Region is a special Operation Region. Its region space is always memory. The memory referred to by the Data Table Region is the memory that is occupied by the table referenced in XSDT that is identified by SignatureString, OemIDString and OemTableIDString. Any Field object can reference RegionName The base address of a Data Table region is the address of the first byte of the header of the table identified by SignatureString, OemIDString and OemTableIDString. The length of the region is the length of the table. Any table referenced by a Data Table Region must be in memory marked by AddressRangeReserved or AddressRangeNVS.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Creates a Device object, which represents either a bus or a device or any other such entity of use. Device opens a name scope. A Bus/Device Package is one of the basic ways the Differentiated Definition Block describes the hardware devices in the system to the operating software. Each Bus/Device Package is defined somewhere in the hierarchical namespace corresponding to that devices location in the system. Within the namespace of the device are other names that provide information and control of the device, along with any sub-devices that in turn describe sub-devices, and so on. For any device, the BIOS provides only information that is added to the device in a non-hardware standard manner. This type of value-added function is expressible in the ACPI Definition Block such that operating software can use the function. The BIOS supplies Device Objects only for devices that are obtaining some system-added function outside the devices normal capabilities and for any Device Object required to fill in the tree for such a device. For example, if the system includes a PCI device (integrated or otherwise) with no additional functions such as power management, the BIOS would not report such a device; however, if the system included an integrated ISA device below the integrated PCI device (device is an ISA bridge), then the system would include a Device Package for the ISA device with the minimum feature being added being the ISA devices ID and configuration information and the parent PCI device, because it is required to get the ISA Device Package placement in the namespace correct. The following block of ASL sample code shows a nested use of Device objects to describe an IDE controller connected to the root PCI bus.
Device (IDE0) { Name(_ADR, 0) // primary controller // put PCI Address (device/function) here
// define region for IDE mode register OperationRegion (PCIC, PCI_Config, 0x50, 0x10) Field (PCIC, AnyAcc, NoLock, Preserve) { } Device(PRIM) { //Primary adapter Name(_ADR, 0) //Primary adapter = 0 Method(_STM, 2){ } Method(_GTM){ } Device(MSTR) { // master channel Name(_ADR, 0) Name(_PR0, Package(){0, PIDE}) Name(_GTF){ } } Device(SLAV) { Name(_ADR, 1) Name(_PR0, Package(){0, PIDE}) Name(_GTF){ } } } }
Compaq/Intel/Microsoft/Phoenix/Toshiba
Creates an event synchronization object named EventName . For more information about the uses of an event synchronization object, see the ASL definitions for the Wait, Signal, and Reset function operators.
Declares a series of named data objects whose data values are fields within a larger object. The fields are parts of the object named by RegionName , but their names appear in the same scope as the Field term. For example, the field operator allows a larger operation region that represents a hardware register to be broken down into individual bit fields that can then be accessed by the bit field names. Extracting and combining the component field from its parent is done automatically when the field is accessed. Accessing the contents of a field data object provides access to the corresponding field within the parent object. If the parent object supports Mutex synchronization, accesses to modify the component data objects will acquire and release ownership of the parent object around the modification. In general, accesses within the parent object are performed naturally aligned. If desired, AccessType set to a value other than AnyAcc can be used to force minimum access width. Notice that the parent object must be able to accommodate the AccessType width. For example, an access type of WordAcc cannot read the last byte of an odd-length operation region. The ex ceptions to natural alignment are the access types used for a non-linear SMBus device. These will be discussed in detail below. Not all access types are meaningful for every type of operational region. The following table relates region types declared with an OperationRegion term to the different access types supported for each region.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 16-6 OperationRegion Region Types and Access Types Region Types SystemMemory Access Type ByteAcc WordAcc DWordAcc QWordAcc AnyAcc SystemIO ByteAcc WordAcc DWordAcc QWordAcc AnyAcc PCI_Config ByteAcc WordAcc DWordAcc QWordAcc AnyAcc EmbeddedControl SMBus ByteAcc BufferAcc Reads and writes to this operation region involve the use of a region specific data buffer. See section 14, ACPI System Management Bus Interface Specification, for more information. Read/Write Byte, Word, DWord, QWord access Read/Write Byte, Word, DWord, QWord access Read/Write Byte, Word, DWord, QWord access Description
CMOS PciBarTarget
ByteAcc ByteAcc WordAcc DWordAcc QWordAcc AnyAcc Read/Write Byte, Word, DWord, QWord access
Compaq/Intel/Microsoft/Phoenix/Toshiba
354 Advanced Configuration and Power Interface Specification If LockRule is set to Lock , accesses to modify the component data objects will acquire and release the Global Lock. If both types of locking occur, the Global Lock is acquired after the parent object Mutex. UpdateRule is used to specify how the unmodified bits of a field are treated. For example, if a field defines a component data object of 4 bits in the middle of a WordAcc region, when those 4 bits are modified the UpdateRule specifies how the other 12 bits are treated. The named data objects are provided in FieldList as a series of names and bit widths. Bits assigned no name (or NULL) are skipped. The ASL compiler supports an Offset(ByteOffset) macro within a FieldList to skip to the bit position of the supplied byte offset. SMBus regions are inherently non-linear, where each offset within an SMBus address space represents a variable sized (0 to 32 bytes) field. Given this uniqueness, SMBus operation regions include restrictions on their field definitions and require the use of an SMBus-specific data buffer when initiating transactions. See section 14, ACPI System Management Bus Interface Specification, for more information.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Any platform containing this device or one that is compatible with it may use the PNP ID PNP0B01. This will allow an ACPI-compatible OS to recognize the RTC/CMOS device as using the programming interface of the PIIX4. Thus, the array of bytes that ASL can read and write with this device is 256 bytes long. Note: This also means that the CENTURY field in the Fixed ACPI Description Table may contain values between 0 and 255. This is an example of how this device could be described:
Device (RTC0) { Name(_HID, EISAID("PNP0B01")) Name(_CRS, ResourceTemplate() { IO(Decode16, 0x70, 0x70, 0x1, 0x2) IO(Decode16, 0x72, 0x72, 0x1, 0x2) } OperationRegion(CMS1, CMOS, 0, 0x100) Field(CMS1, ByteAcc, NoLock, Preserve) { AccessAs(ByteAcc, 0), CM00, 8, ,256, CM01, 8, CM02, 16, , 224, CM03, 8, , 184, CENT, 8 }
Compaq/Intel/Microsoft/Phoenix/Toshiba
356 Advanced Configuration and Power Interface Specification If a platform uses a PCI BAR Target operation region, an ACPI OS will not load a native device driver for the associated PCI function. For example, if any of the BARs in a PCI function are associated with a PCI BAR Target operation region, then the OS will assume that the PCI function is to be entirely under the control of the ACPI BIOS. No driver will be loaded. Thus, a PCI function can be used as a platform controller for some task (hot-plug PCI, and so on) that the ACPI BIOS performs.
16.2.3.3.1.11.2.2 PCI Header Types and PCI BAR Target Operation Regions
PCI BAR Target operation regions may only be declared in the scope of PCI devices that have a PCI Header Type of 0. PCI devices with other header types are bridges. The control of PCI bridges is beyond the scope of ASL.
Creates a series of named data objects whose data values are fields within a larger object accessed by an index/data-style reference to IndexName and DataName . This encoding is used to define named data objects whose data values are fields within an index/data register pair. This provides a simple way to declare register variables that occur behind a typical index and data register pair. Accessing the contents of an indexed field data object will automatically occur through the DataName object by using an IndexName object aligned on an AccessType boundary, with synchronization occurring on the operation region that contains the index data variable, and on the Global Lock if specified by LockRule. AccessType, LockRule, UpdateRule, and FieldList are the same format as the Field term.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following is a block of ASL sample code using IndexField: Creates an index/data register in system I/O space made up of 8-bit registers. Creates a FET0 field within the indexed range.
Method(EX1){ // define 256-byte operational region in SystemIO space // and name it GIO0 OperationRegion (GIO0, 1, 0x125, 0x100) // create field named Preserve structured as a sequence // of index and data bytes Field (GIO0, ByteAcc, NoLock, WriteAsZeros) { IDX0, 8, DAT0, 8, . . . } // Create an IndexField within IDX0 & DAT0 which has // FETs in the first two bits of indexed offset 0, // and another 2 FETs in the high bit on indexed // 2f and the low bit of indexed offset 30 IndexField (IDX0, DAT0, ByteAcc, NoLock, Preserve) { FET0, 1, FET1, 1, Offset(0x2f), // skip to byte offset 2f , 7, // skip another 7 bits FET3, 1, FET4, 1 } // Clear FET3 (index 2f, bit 7) Store (Zero, FET3) } // End EX1
Declares a named package containing a series of object references that collectively represent a control method, which is a procedure that can be invoked to perform computation. Method opens a name scope. System software executes a control method by referencing the objects in the package in order. For more information on control method execution, see section 5.5.3, Control Method Execution. The current namespace location used during name creation is adjusted to be the current location on the namespace tree. Any names created within this scope are below the name of this package. The current namespace location is assigned to the method package, and all namespace references that occur during control method execution for this package are relative to that location. If a method is declared as Serialized, an implicit mutex associated with the method object is acquired at the specified SyncLevel. If no SyncLevel is specified, SyncLevel 0 is assumed. The serialize rule can be used to prevent reentering of a method. This is especially useful if the method creates namespace objects. Without the serialize rule, the reentering of a method will fail when it attempts to create the same namespace object. Also notice that all namespace objects created by a method have temporary lifetime. When method execution exits, the created objects will be destroyed.
Compaq/Intel/Microsoft/Phoenix/Toshiba
358 Advanced Configuration and Power Interface Specification The following block of ASL sample code shows a use of Method for defining a control method that turns on a power resource.
Method(_ON) { Store (One, GIO.IDEP) Sleep (10) Store (One, GIO.IDER) Stall (10) Store (Zero, GIO.IDEI) } // // // // // assert power wait 10ms de-assert reset# wait 10us de-assert isolation
Creates a data mutex synchronization object named MutexName , with level from 0 to 15 specified by SyncLevel. A SyncLevel of n allows n +1 mutex owners A synchronization object provides a control method with a mechanism for waiting for certain events. To prevent deadlocks, wherever more than one synchronization object must be owned, the synchronization objects must always be released in the order opposite the order in which they were acquired. The SyncLevel parameter declares the logical nesting level of the synchronization object. All Acquire terms must refer to a synchronization object with an equal or greater SyncLevel to current level, and all Release terms must refer to a synchronization object with equal or lower SyncLevel to the current level. Mutex synchronization provides the means for mutually exclusive ownership. Ownership is acquired using an Acquire term and is released using a Release term. Ownership of a Mutex must be relinquished before completion of any invocation. For example, the top-level control method cannot exit while still holding ownership of a Mutex. Acquiring ownership of a Mutex can be nested. The SyncLevel check is not performed on a Mutex when the ownership count is nesting. The SyncLevel of a thread before acquiring any mutexes is zero. The SyncLevel of the Global Lock (\_GL) is zero. A method marked serialized has an inherent mutex of SyncLevel 0 unless SyncLevel is explicitly specified.
Declares an operation region. Offset is the offset within the selected RegionSpace at which the region starts (byte-granular), and Length is the length of the region in bytes. An Operation Region is a type of data object where read or write operations to the data object are performed in some hardware space. For example, the Definition Block can define an Operation Region within a bus, or system I/O space. Any reads or writes to the named object will result in accesses to the I/O space. Operation regions are regions in some space that contain hardware registers for exclusive use by ACPI control methods. In general, no hardware register (at least byte-granular) within the operation region accessed by an ACPI control method can be shared with any accesses from any other source, with the exception of using the Global Lock to share a region with the firmware. The entire Operation Region can be allocated for exclusive use to the ACPI subsystem in the host OS.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Operation Regions that are defined within the scope of a method are the exception to this rule. These Operation Regions are known as Dynamic since the OS has no idea that they exist or what registers they use until the control method is executed. Using a Dynamic SystemIO or SystemMemory Operation Region is not recommended since the OS cannot guarantee exclusive access. All other types of Operation Regions may be Dynamic. Operation Regions have virtual content and are only accessible via Field objects Operation Region objects may be defined down to actual bit controls using Field data object definitions. The actual bit content of a Field is comprised of bits from within a larger Buffer that are normalized for that field (in other words, shifted down and masked to the proper length), and as such the data type of a Field is Buffer. Therefore fields that are 32 bits or less in size may be read and stored as Integers. An Operation Region object implicitly supports Mutex synchronization. Updates to the object, or a Field data object for the region, will automatically synchronize on the Operation Region object; however, a control method may also explicitly synchronize to a region to prevent other accesses to the region (from other control methods). Notice that, according to the control method execution model, control method execution is non-preemptive. Because of this, explicit synchronization to an Operation Region needs to be done only in cases where a control method blocks or yields execution and where the type of register usage requires such synchronization. There are seven predefined Operation Region types specified in ACPI: 0 SystemMemory 1 SystemIO 2 PCI_Config 3 EmbeddedControl 4 SMBus 5 CMOS 6 PCIBARTarget In addition, OEMs may define Operation Regions types 0x80 to 0xFF. The following example ASL code shows the use of OperationRegion combined with Field to describe IDE 0 and 1 controlled through general I/O space, using one FET.
OperationRegion (GIO, SystemIO, 0x125, 0x1) Field (GIO, ByteAcc, NoLock, Preserve) { IDEI, 1, // IDEISO_EN - isolation buffer IDEP, 1, // IDE_PWR_EN - power IDER, 1 // IDERST#_EN - reset# }
Declares a power resource. PowerResource opens a name scope. For a definition of the PowerResource term, see section 7.1, Declaring a Power Resource Object.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Declares a named processor object. Processor opens a name scope. Each processor is required to have a unique ProcessorID value that is unique from any other ProcessorID value. For each processor in the system, the ACPI BIOS declares one processor object in the namespace anywhere within the \_SB scope. For compatibility with operating systems implementing ACPI 1.0, the processor object may also be declared under the \_PR scope. An ACPI 2.0-compatible namespace may define Processor objects in either the \_SB or \_PR scope but not both. PBlockAddress provides the system I/O address for the processors register block. Each processor can supply a different such address. PBlockLength is the length of the processor register block, in bytes and is either 0 (for no P_BLK) or 6. With one exception, all processors are required to have the same PBlockLength. The exception is that the boot processor can have a non-zero PBlockLength when all other processors have a zero PBlockLength. The following block of ASL sample code shows a use of the Processor term.
Processor( \_PR.CPU0, // namespace name 1, 0x120, // PBlk system IO address 6 // PBlkLen ) {ObjectList}
The ObjectList is an optional list that may contain an arbitrary number of ASL Objects. Processor-specific objects that may be included in the ObjectList include _PTC, _CST, _PCT, _PSS, and _PPC. These processor-specific objects can only be specified when the processor object is declared within the \_SB scope. For a full definition of these objects, see section 8, Processor Control.
Declares a named Thermal Zone object. ThermalZone opens a name scope. Each use of a ThermalZone term declares one thermal zone in the system. Each thermal zone in a system is required to have a unique ThermalZoneName . A therma l zone may be declared in the namespace anywhere within the \_SB scope. For compatibility with operating systems implementing ACPI 1.0, a thermal zone may also be declared under the \_TZ scope. An ACPI 2.0-compatible namespace may define Thermal Zone objects in either the \_SB or \_TZ scope but not both. For sample ASL code that uses a ThermalZone statement, see section 12, Thermal Management.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Creates a new name, AliasObject, which refers to and acts exactly the same as SourceObject. AliasObject is created as an alias of SourceObject in the namespace. The SourceObject name must already exis t in the namespace. If the alias is to a name within the same definition block, the SourceObject name must be logically ahead of this definition in the block. The following example shows use of an Alias term:
Alias(\SUS.SET.EVEN, SSE)
Attaches Object to ObjectName in the Global ACPI namespace. This encoding is to create ObjectName in the namespace, which references the Object. The following example creates the name PTTX in the root of the namespace that references a package.
Name(\PTTX, // Port to Port Translate Table Package() { Package() { 0x43, 0x59 }, Package() { 0x90, 0xff }} )
The following example creates the name CNT in the root of the namespace that references an integer data object with the value 5.
Name(\CNT, 5)
Compaq/Intel/Microsoft/Phoenix/Toshiba
Gives a base scope to a collection of objects. All object names defined within the scope act relative to Location . Notice that Location does not have to be below the surrounding scope. Notice also that the Scope term does not create objects, but only locates objects in the namespace; the located objects are created by other ASL terms. The Scope term alters the current namespace location to Location. This causes the defined objects within TermList to occur relative to the new location in the namespace. The following example ASL code places the defined objects in the ACPI namespace as shown:
Scope(\PCI0) { Name(X, 3) Scope(\) { Method(RQ) { Return(0) } } Name(^Y, 4) }
Compaq/Intel/Microsoft/Phoenix/Toshiba
The Type 1 opcodes are listed in the following table. Table 16-8 Type 1 Opcodes ASL Statement Break BreakPoint Continue Else ElseIf Fatal If Load Noop Notify Release Reset Return Signal Sleep Stall Switch Unload While Description Continue immediately following the innermost enclosing While scope Used for debugging. Stops execution in the debugger. Continue innermost enclosing While loop where condition is evaluated Else ElseIf Fatal check If Load differentiating definition block No operation Notify the OS that the specified notification event occurred for the specified object. Release a synchronization object Reset a synchronization object Return from a control method, optionally setting a return value Signal a synchronization object Sleep n milliseconds (yields the processor) Delay n microseconds (does not yield the processor) Select code to execute based on expression value Unload differentiating definition block While
Break causes execution to continue immediately following the innermost enclosing While scope, in the current Method. If there is no enclosing While within the current Method, a fatal error is generated. Compatibility Note: In ACPI 1.0, the Break command continued immediately following the innermost code package. In ACPI 2.0, the Break command has been changed to exit the innermost While package. This should have no impact on existing code, since the ACPI 1.0 definition was, in practice, useless.
Used for debugging, the Breakpoint opcode stops the execution and enters the AML debugger. In the retail version of the interpreter, BreakPoint is equivalent to Noop.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Continue causes execution to continue at the start of the innermost enclosing While scope, in the current Method, at the point where the condition is evaluated. If there is no enclosing While within the current Method, a fatal error is generated.
If Predicate evaluates to 0 in an If statement, then control is transferred to the Else portion, which can consist of zero or more ElseIf statements followed by zero or one Else statements. If the Predicate of any ElseIf statement evaluates to non-zero, the statements in its term list are executed and then control is transferred past the end of the final Else term. If no Predicate evaluates to non-zero, then the statements in the Else term list are executed. The following example checks Local0 to be zero or non-zero. On non-zero, CNT is incremented; otherwise, CNT is decremented.
If (LGreater(Local0,5) { Increment (CNT) } Else If (Local0) { Add(CNT,5,CNT) } Else { Decrement (CNT) }
Compatibility Note: The ElseIf operator is new in ACPI 2.0, but is backward compatible with the ACPI 1.0 specification. The ACPI 2.0 compiler must synthesize ElseIf from the If..Else opcodes available in 1.0. For example:
If (predicate1) { statements1 } ElseIf (predicate2) { statements2 } Else { statements3 }
Compaq/Intel/Microsoft/Phoenix/Toshiba
This operation is used to inform the OS that there has been an OEM-defined fatal error. In response, the OS must log the fatal event and perform a controlled OS shutdown in a timely fashion.
Predicate is evaluated as an integer. If the integer is non-zero, the term list of the If term is executed. The following examples all check for bit 3 in Local0 being set, and clear it if set.
// example 1 If (And(Local0, 4)) { XOr (Local0, 4, Local0) } // example 2 Store(4, Local2) If (And(Local0, Local2)) { XOr (Local0, Local2, Local0) }
Performs a run-time load of a Definition Block. The Object parameter can either refer to an operation region field or an operation region directly. If the object is an operation region, the operation region must be in SystemMemory space. The Definition Block should contain a DESCRIPTION_HEADER of type SSDT or PSDT. The Definition Block must be totally contained within the supplied operation region or operation region field. This table is read into memory, the checksum is verified, and then it is loaded into the ACPI namespace. The DDBHandle parameter is the handle to the Differentiating Definition Block that can be used to unload the Definition Block at a future time. The OS can also check the OEM Table ID and Revision ID against a database for a newer revision Definition Block of the same OEM Table ID and load it instead. The default namespace location to load the Definition Block is relative to the current namespace. The new Definition Block can override this by specifying absolute names or by adjusting the namespace location using the Scope operator. Loading a Definition Block is a synchronous operation. Upon completion of the operation, the Definition Block has been loaded. The control methods defined in the Definition Block are not executed during load time.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Notifies the OS that the NotificationValue for the Object has occurred. Object must be a reference to a device or thermal zone object. Object type determines the notification values. For example, the notification values for a thermal zone object are different from the notification values used for a device object. Undefined notification values are treated as reserved and are ignored by the OS. For lists of defined Notification values, see section 5.6.3, Device Object Notifications.
SynchObject must be a mutex synchronization object. If the mutex object is owned by the current invocation, ownership for the Mutex is released once. It is fatal to release ownership on a Mutex unless it is currently owned. A Mutex must be totally released before an invocation completes.
SynchObject must be an Event synchronization object. This encoding is used to reset an event synchronization object to a non-signaled state. See also the Wait and Signal function operator definitions.
Returns control to the invoking control method, optionally returning a copy of the object named in Arg .
SynchObject must be an Event synchronization object. The Event object is signaled once, allowing one invocation to acquire the event.
The Sleep term is used to implement long-term timing requirements. Execution is delayed for at least the required number of milliseconds. The implementation of Sleep is to round the request up to the closest sleep time supported by the OS and relinquish the processor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The Stall term is used to implement short-term timing requirements. Execution is delayed for at least the required number of microseconds. The implementation of Stall is OS-specific, but must not relinquish control of the processor. Because of this, delays longer than 100 microseconds must use Sleep instead of Stall.
The Switch, Case and Default statements help simplify the creation of conditional and branching code. The Switch statement transfers control to a statement within its body. If the Case value is an Integer, Buffer or String, then control passes to the statement that matches the value of Switch( Predicate). If the Case value is a Package, then control passes if any member of the package matches the Switch (Predicate). The Switch CaseTermList can include any number of Case instances, but no two Case values (or members of a value, if value is a Package) within the same Switch statement can contain the same value. Execution of the statement body begins at the selected statements TermList and proceeds until the end of the body or until an ExitSwitch (or other valid Exitx) statement transfers control out of the body. Use of the Switch statement usually looks something like this:
Switch ( expression ) { Case ( value ) { Statements executed if Lequal(expression, value) } Case ( Package() {value,value,value}) { Statements executed if Lequal(expression, any value in package) Default { statements executed if expression does not equal any case constant-expression } }
The Default statement is executed if no Case value matches the value of switch ( expression ). If the Default statement is omitted, and no Case match is found, none of the statements in the Switch body are executed. There can be at most one Default statement. The Default statement need not come at the end; it can appear anywhere in the body of the Switch statement. A Case or Default term can only appear inside a Switch statement. Switch statements can be nested. Compatibility Note: The Switch, Case, and Default terms are new to ACPI 2.0. However, their implementation is backward compatible with ACPI 1.0 AML interpreters.
Compaq/Intel/Microsoft/Phoenix/Toshiba
368 Advanced Configuration and Power Interface Specification Compiler Note: The following example demonstrates how the Switch statement should be translated into ACPI 1.0-compatible AML:
Switch (Add(ABCD(),1) { Case(1) { statements1 } Case(Package() {4,5,6}) { statements2 } Default { statements3 } }
is translated as:
While(Zero) { Name(_T_I,0) // Create Integer temporary variable for result Store(Add(ABCD(),1),_T_I) If (LEqual(_T_I,1)) { statements1 } Else { If (LNotEqual(Match(Package() {4,5,6},MEQ,_T_I,MTR,0,0),Ones)) { statements2 } Else { statements3 } } }
Note: If the compiler is unable to determine the type of the expression, then it should generate a warning and assume integer type. The warning should indicate that the ASL should use one of the type conversion operators (Int, Buff, DecStr or HexStr). For example:
Switch(ABCD()) // Cant determine the type because methods can return anything. { case statements }
Performs a run-time unload of a Definition Block that was loaded using a Load term. Loading or unloading a Definition Block is a synchronous operation, and no control method execution occurs during the function. On completion of the Unload operation, the Definition Block has been unloaded (all the namespace objects created as a result of the corresponding Load operation will be removed from the namespace).
Compaq/Intel/Microsoft/Phoenix/Toshiba
Predicate is evaluated as an integer. If the integer is non-zero, the list of terms in TermList is executed. The operation repeats until the Predicate evaluates to zero.
The ASL terms for Type 2 Opcodes are listed in the following table. Table 16-9 Type 2 Opcodes ASL Statement Acquire Add And Buff Concatenate ConcatenateResTemplate CondRefOf Decrement DecStr DerefOf Divide FindSetLeftBit FindSetRightBit FromBCD HexStr Increment Index Int LAnd Description Acquire a mutex Add two values Bitwise And Convert data type to buffer Concatenate two strings, integers or buffers Concatenate two resource templates Conditional reference to an object Decrement a value Convert data type to decimal string Dereference an object reference Divide Index of first least significant bit set Index of first mo st significant bit set Convert from BCD to numeric Convert data type to hexadecimal string Increment a value Reference the nth element/byte/character of a package, buffer or string Convert data type to integer Logical And
Compaq/Intel/Microsoft/Phoenix/Toshiba
370 Advanced Configuration and Power Interface Specification Table 16-9 Type 2 Opcodes (continued) ASL Statement LEqual LGreater LGreaterEqual LLess LLessEqual LNot LNotEqual LoadTable LOr Match Mid Mod Multiply NAnd NOr Not ObjectType Or RefOf ShiftLeft ShiftRight SizeOf Store String Subtract ToBCD Wait Xor Description Logical Equal Logical Greater Logical Not less Logical Less Logical Not greater Logical Not Logical Not equal Load Table from RSDT/XSDT Logical Or Search for match in package array Returns a portion of buffer or string Modulo Multiply Bitwise Nand Bitwise Nor Bitwise Not Type of object Bitwise Or Reference to an object Shift value left Shift value right Get the size of a buffer, string, or package Store value Copy ASCII string from buffer Subtract values Convert numeric to BCD Wait Bitwise Xor
Compaq/Intel/Microsoft/Phoenix/Toshiba
SynchObject must be a mutex synchronization object. It refers to the mutex to be acquired. Ownership of the Mutex is obtained. If the Mutex is already owned by a different invocation, the processor is relinquished until the owner of the Mutex releases it or until at least TimeoutValue milliseconds have elapsed. A Mutex can be acquired more than once by the same invocation. This operation returns True if a timeout occurred and the mutex ownership was not acquired. A TimeoutValue of 0xFFFF indicates that there is no time out and the operation will wait indefinitely.
Addend1 and Addend2 are evaluated as integer data types and are added, and the result is optionally stored into Result. Overflow conditions are ignored and the result of overflows simply loses the most significant bits.
Source1 and Source2 are evaluated as integer data types, a bitwise AND is performed, and the result is optionally stored into Result.
Data must be evaluated to integer, string, or buffer. Data is then converted to buffer type and the result is optionally stored into Result. If Data was an integer, it is converted into 4 bytes of buffer, taking the least significant type of integer as the first byte of buffer. If Data is a buffer, no conversion is performed.
Source1 and Source2 are evaluated. Source1 and Source2 must be of the same data type (that is, both integers, both strings, or both buffers). Source2 is concatenated to Source1 and the result data is optionally stored into Result.
Compaq/Intel/Microsoft/Phoenix/Toshiba
372 Advanced Configuration and Power Interface Specification Table 16-10 Concatenate Data Types Source1 Data Type Integer String Buffer Source2 Data Type Integer String Buffer Result Data Type Buffer String Buffer
Source1 and Source2 are evaluated as resource template buffers. The resource descriptors from Source2 are appended to the resource descriptors from Source1. Then a new end tag and checksum are appended and the result is stored in Result, if specified. If either Source1 or Source2 is exactly 1 byte in length, a run-time error occurs. An empty buffer is treated as a resource template with only an end tag.
Attempts to set Destination to refer to Source. The Source of this operation can be any object type (for example, data package, device object, and so on). On success, the Destination object is set to refer to Source and the execution result of this operation is the value True. On failure, Destination is unchanged and the execution result of this operation is the value False. This can be used to reference items in the namespace that may appear dynamically (for example, from a dynamically loaded differentiation definition block). CondRefOf is equivalent to RefOf except that if the Source object does not exist, it is fatal for RefOf but not for CondRefOf .
Converts the contents of the Source to a DataRefObject using the conversion rules in 16.2.2 and then copies the results without conversion to the object referred to by Destination . If Destination is already an initialized object of type DataRefObject, the original contents of Destination are discarded and replaced with Source. Otherwise, a fatal error is generated. Compatibility Note: The Copy operator is new in ACPI 2.0.
Compaq/Intel/Microsoft/Phoenix/Toshiba
This operation decrements the Addend by one and the result is stored back to Addend. Equivalent to Subtract(Addend,1,Addend). Underflow conditions are ignored and the result is 1s.
Data must be evaluated to integer, string, or buffer. Data is then converted to a decimal string, and the result is optionally stored into Result. If Data is already a string, no action is performed. If Data is a buffer, it is converted to a string of decimal values separated by commas.
Returns the object referred by the Source object reference. If the Source evaluates to an object reference, the actual contents of the object referred to are returned. If the Source evaluates to a string, the string is evaluated as an ASL name (relative to the current scope) and the contents of that object are returned. If the object specified by Source does not exist then a fatal error is generated. Compatibility Note: The use of a String with DerefOf is new in ACPI 2.0.
Dividend and Divisor are evaluated as integer data. Dividend is divided by Divisor, then the resulting remainder is optionally stored into Remainder and the resulting quotient is optionally stored into Result. Divide-by-zero exceptions are fatal.
Source is evaluated as integer data type, and the one-based bit location of the first MSb (most significant set bit) is optionally stored into Result. The result of 0 means no bit was set, 1 means the left-most bit set is the first bit, 2 means the left-most bit set is the second bit, and so on.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Source is evaluated as integer data type, and the one-based bit location of the most LSb ( least significant set bit) is optionally stored in Result. The result of 0 means no bit was set, 32 means the first bit set is the thirty-second bit, 31 means the first bit set is the thirty-first bit, and so on.
The FromBCD operation is used to convert BCDValue to a numeric format and store the numeric value into Result.
Data must be evaluated to integer, string, or buffer. Data is then converted to a hexadecimal string, and the result is optionally stored into Result. If Data is already a string, no action is performed. If Data is a buffer, it is converted to a string of hexadecimal values separated by commas.
Add one to the Addend and place the result back in Addend. Equivalent to Add( Addend, 1, Addend). Overflow conditions are ignored and the result of an overflow is zero.
Source is evaluated to a buffer, string, or package data type. Index is evaluated to an integer. The reference to the nth object (where n = Index) within Source is optionally stored as a reference into Destination. When Source evaluates to a Buffer, Index returns a reference to a Buffer Field containing the nth byte in the buffer. When Source evaluates to a String, Index returns a reference to a Buffer Field containing the nth character in the string. When Source evaluates to a Package, Index returns a reference to the nth object in the package.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Note: DeRefOf is necessary in the first operand of the Store command in order to get the actual object, rather than just a reference to the object. If DeRefOf were not used, then Local0 would contain an object reference to the sixth element in the first package rather than the number 1.
The Index operator returns a reference to an 8-bit Buffer Field (similar to that created using CreateByteField). If Source is evaluated to a buffer data type, the ObjectReference refers to the byte at Index within Source. If Source is evaluated to a buffer data type, a Store operation will only change the byte at Index within Source. The following example ASL code shows the results of a series of Store operations:
Name(SRCB, Buffer() {0x10, 0x20, 0x30, 0x40}) Name(BUFF, Buffer() {0x1, 0x2, 0x3, 0x4})
The following will store 0x78 into the 3rd byte of the destination buffer:
Store (0x12345678, Index(BUFF, 2))
The following will store 0x10 into the 2nd byte of the destination buffer:
Store (SRCB, Index(BUFF, 1))
Compaq/Intel/Microsoft/Phoenix/Toshiba
376 Advanced Configuration and Power Interface Specification The following will store 0x41 (an A) into the 4th byte of the destination buffer:
Store(ABCDEFGH, Index(BUFF, 3))
Compatibility Note: New in ACPI 2.0. In ACPI 1.0, the behavior of storing data larger than 8-bits into a buffer using Index was undefined.
The Index operator returns a reference to an 8-bit Buffer Field (similar to that created using CreateByteField). Compatibility Note: New in ACPI 2.0.
Data must be evaluated to integer, string, or buffer. Data is then converted to integer type and the result is optionally stored into Result. If Data was a string, it must be either a decimal or hexadecimal numeric string (in other words, prefixed by 0x) and the value must not exceed the maximum of an integer value. If the value is exceeding the maximum, the result of the conversion is unpredictable. If Data was a Buffer, the first 8 bytes of the buffer are converted to an integer, taking the first byte as the least significant byte of the integer.
Source1 and source2 are evaluated as integers. If both values are non-zero, True is returned: otherwise, False is returned.
Source1 and Source2 must be evaluated to the same data type as integers, strings, or buffers. If the values are equal, True is returned; otherwise, False is returned.
Source1 and Source2 must be evaluated to the same data type as integers, strings, or buffers. If Source1 is greater than Source2, True is returned; otherwise, False is returned.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Source1 and Source2 must be evaluated to the same data type as integers, strings, or buffers. If Source1 is greater than or equal to Source2, True is returned; otherwise, False is returned.
Source1 and Source2 must be evaluated to the same data type as integers, strings, or buffers. If Source1 is less than Source2, True is returned; otherwise, False is returned.
Source1 and Source2 must be evaluated to the same data type as integers, strings, or buffers. If Source1 is less than or equal to Source2, True is returned; otherwise, False is returned.
Source1 is evaluated as an integer. If the value is non-zero True is returned; otherwise, False is returned.
Source1 and Source2 must be evaluated to the same data type as integers, strings, or buffers. If Source1 is not equal to Source2, True is returned; otherwise, False is returned.
Compaq/Intel/Microsoft/Phoenix/Toshiba
378 Advanced Configuration and Power Interface Specification Performs a run-time load of a Differentiated Definition Block from the XSDT. The XSDT is searched for a table where the Signature field matches SignatureString, the OEM ID field matches OEMIDString, and the OEM Table ID matches OEMTableIDString. All comparisons are case sensitive. If the SignatureString is greater than four characters, the OEMIDString is greater than six characters, or the OEMTableID is greater than eight characters, a run-time error is generated. The OS can also check the OEM Table ID and Revision ID against a database for a newer revision Definition Block of the same OEM Table ID and load it instead. The RootPathString specifies the root of the Definition Block. It is evaluated using normal scoping rules, assuming that the scope of the LoadTable instruction is the current scope. The new Definition Block can override this by specifying absolute names or by adjusting the namespace location using the Scope operator. If RootPathString is not specified, \ is assumed If ParameterPathString and ParameterData are specified, the data object specified by ParameterData is stored into the object specified by ParameterPathString after the table has been added into the namespace. If the first character of ParameterPathString is a backslash (\) or caret (^) character, then the path of the object is ParameterPathString. Otherwise, it is RootPathString.ParameterPathString . If the specified object does not exist, a run-time error is generated. The handle of the loaded table is returned. If no table matches the specified signature, then 0 is returned. Any table referenced by a Data Table Region must be in memory marked by AddressRangeReserved or AddressRangeNVS. Loading a Definition Block is a synchronous operation. Upon completion of the operation, the Definition Block has been loaded. The control methods defined in the Definition Block are not executed during load time. For example:
Store(LoadTable(OEM1,MYOEM,TABLE1,\\_SB.PCI0,MYD,Package(){0,\\_SB.PCI0}), Local0)
This command would search through the RSDT or XSDT for a table with the signature OEM1, the OEM ID of MYOEM, and the table ID of TABLE1. If not found, it would store Zero in Local0. Otherwise, it will store a package containing 0 and \\_SB.PCI0 into the variable at \_SB.PCI0.MYD.
Source1 and Source2 are evaluated as integers. If either value is non-zero, True is returned; otherwise, False is returned.
SearchPackage is evaluated to a package object and is treated as a one-dimension array. A comparison is performed for each element of the package, starting with the index value indicated by StartIndex (0 is the first element). If the element of SearchPackage being compared against is called P[i] , then the comparison is: if (P[i] Op1 MatchObject1) and (P[i] Op2 MatchObject2) then Match => i is returned.
Compaq/Intel/Microsoft/Phoenix/Toshiba
If the comparison succeeds, the index of the element that succeeded is returned; otherwise, the constant object ONES is returned. Op1 and Op2 have the values and meanings listed in the Table 16-13. Table 16-11 Match Term Operator Meanings Operator TRUE A dont care, always returns TRUE EQ Returns TRUE if P[i] == MatchObject LE Returns TRUE if P[i] <= MatchObject LT Returns TRUE if P[i] < MatchObject GE Returns TRUE if P[i] >= MatchObject GT Returns TRUE if P[i] > MatchObject Following are some example uses of Match:
Name(P1, Package() {1981, 1983, 1985, 1987, 1989, 1990, 1991, 1993, 1995, 1997, 1999, 2001} ) // match 1993 == P1[i] Match(P1, MEQ, 1993, MTR, 0, 0) // match 1984 == P1[i] Match(P1, MEQ, 1984, MTR, 0, 0) // -> 7, since P1[7] == 1993
Encoding 0 1 2 3 4 5
// match P1[i] > 1984 and P1[i] <= 2000 Match(P1, MGT, 1984, MLE, 2000, 0) // -> 2, since P1[2]>1984 and P1[2]<=2000 // match P1[i] > 1984 and P1[i] <= 2000, starting with 3rd element Match(P1, MGT, 1984, MLE, 2000, 3) // -> 3, first match at or past Start
Source is evaluated as either a Buffer or String. If Source is a buffer, then Length bytes, starting with the Indexth byte (zero-based) are optionally copied into Result. If Index is greater than or equal to the length of the buffer, then the result is an empty buffer. Otherwise, if Index + Length is greater than or equal to the length of the buffer, then only bytes up to an including the last byte are included in the result. If Source is a string, then Length characters, starting with the Indexth character (zero-based) are optionally copied into Result. If Index is greater than or equal to the length of the buffer, then the result is an empty string. Otherwise, if Index + Length is greater than or equal to the length of the string, then only bytes up to an including the last character are included in the result.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Dividend and Divisor are evaluated as integer data. Dividend is divided by Divisor, then the resulting remainder is optionally stored into Result. If Divisor evaluates to zero, a fatal exception is generated.
Multiplicand and Multiplier are evaluated as integer data types. Multiplicand is multiplied by Multiplier and the result is optionally stored into Result. Overflow conditions are ignored and results are undefined.
Source1 and Source2 are evaluated as integer data types, a bitwise NAND is performed, and the result is optionally stored in Result.
Source1 and Source2 are evaluated as integer data types, a bitwise NOR is performed, and the result is optionally stored in Result.
Source1 is evaluated as an integer data type, a bitwise NOT is performed, and the result is optionally stored in Result.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The execution result of this operation is an integer that has the numeric value of the object type for Object. The object type codes are listed in Table 16-14. Notice that if this operation is performed on an object reference such as one produced by the Alias, Index, or RefOf statements, the object type of the base object is returned. For typeless objects such as pre-defined scope names (in other words, \_SB, \_GPE, and so on), the type value 0 ( Uninitialized) is returned. Table 16-12 Values Returned By the ObjectType Operator Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 >16 Meaning Uninitialized Integer String Buffer Package Field Unit Device Event Method Mutex Operation Region Power Resource Processor Thermal Zone Buffer Field DDB Handle Debug Object Reserved
Source1 and Source2 are evaluated as integer data types, a bitwise OR is performed, and the result is optionally stored in Result.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Returns an object reference to Object. Object can be any object type (for example, a package, a device object, and so on). If the Object does not exist, the result of a RefOf operation is fatal. Use the CondRefOf term in cases where the Object might not exist. The primary purpose of RefOf() is to allow an object to be passed to a method as an argument to a method without the object being evaluated at the time of the method was loaded.
Source and ShiftCount are evaluated as integer data types. Source is shifted left with the least significant bit zeroed ShiftCount times. The result is optionally stored into Result.
Source and ShiftCount are evaluated as integer data types. Source is shifted right with the most significant bit zeroed ShiftCount times. The result is optionally stored into Result.
Returns the size of a buffer, string, or package data object. For a buffer, it returns the size in bytes of the data. For a string, it returns the size in bytes of the string, not counting the trailing NULL. For a package, it returns the number of elements. For an object reference, the size of the referenced object is returned. Other data types cause a fatal run-time error.
This operation evaluates Source converts to the data type of Destination and writes the results into Destination. For information on automatic data-type conversion, see section 16.2.2, ASL Data Types. Stores to Operational Region Field data types may relinquish the processor depending on the region type. All stores (of any type) to the constant Zero, constant One, or constant Ones object are not allowed. Stores to read-only objects are fatal. The execution result of the operation is the same as the data written to Destination.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following example creates the name CNT that references an integer data object with the value 5 and then stores CNT to Local0. After the Store operation, Local0 is an integer object with the value 5.
Name(CNT, 5) Store(CNT, Local0)
Source is evaluated as a buffer. Starting with the first byte, the contents of the buffer are copied into the string until the number of characters specified by Length is reached. If Length is not specified or is Ones , then the contents of the buffer are copied until a null (0) character is found. In any case, a fatal error will be generated if the number of characters copied exceeds 200 (not including the terminating null). The result is copied into the Result.
Addend1 and Addend2 are evaluated as integer data types. Addend2 is subtracted from Addend1, and the result is optionally stored into Result. Underflow conditions are ignored and the result simply loses the most significant bits.
The ToBCD operation is used to convert Value from a numeric format to a BCD format and optionally store the numeric value into Result.
SynchObject must be an event synchronization object. The calling method blocks waiting for the event to be signaled. The pending signal count is decremented. If there is no pending signal count, the processor is relinquished until a signal count is posted to the Event or until at least TimeoutValue milliseconds have elapsed. This operation returns a non-zero value if a timeout occurred and a signal was not acquired. A TimeoutValue of 0xFFFF indicates that there is no time out and the operation will wait indefinitely.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Source1 and Source2 are evaluated as integer data types, a bitwise XOR is performed, and the result is optionally stored into Result.
NameString must refer to an existing Method in the namespace. If the Method is not present, a fatal error is generated. It can either be an absolute namespace path or else it must be accessible at the current scope of invocation. The number of arguments in ArgList must match the number of arguments declared in the method object.
Declares a Buffer, of size BuffSize and initial value of Initializer (ByteList). The optional BuffSize parameter specifies the size of the buffer and the initial value is specified in Initializer ByteList. If BuffSize is not specified, it defaults to the size of initializer. If the count is too small to hold the value specified by initializer, initializer size is used. For example, all four of the following examples generate the same data in namespace, although they have different ASL encodings:
Buffer(10) {P00.00A} Buffer(Arg0) {0x50 0x30 0x30 0x2e 0x30 0x30 0x41} Buffer(10) {0x50 0x30 0x30 0x2e 0x30 0x30 0x41 0x00 0x00 0x00} Buffer() {0x50 0x30 0x30 0x2e 0x30 0x30 0x41 0x00 0x00 0x00}
) { PackageList}
Compaq/Intel/Microsoft/Phoenix/Toshiba
Declares an unnamed aggregation of data items, constants, and/or references to control methods. The size of the package is NumElements. PackageList contains the list data items, constants, and/or control method references used to initialize the package. If NumElements is absent, it is set to match the number of elements in the PackageList. If NumElements is present and greater than the number of elements in the PackageList, the default entry of type Uninitialized (see ObjectType) is used to initialize the package elements beyond those initialized from the PackageList. Evaluating an undefined element will yield an error, but elements can be assigned values to make them defined. It is an error for NumElements to be less than the number of elements in the PackageList. It is an error for NumElements to exceed 255. There are two types of package elements in the PackageList: data objects and references to control methods. Note: If non-method code-package objects are implemented in an ASL compiler, evaluations of these objects are performed within the scope of the invoking method, and are performed when the containing definition block is loaded. This means that the targets of all stores, loads, and references to the locals, arguments, or constant terms are in the same name scope as the invoking method. Example 1: Note
Package () { 3, 9, ACPI 1.0 COMPLIANT, Package () { CheckSum=>, Package () { 7, 9 } }, 0 }
Example 4: This encoding allocates space for ten things to be defined later (see the Name and Index term definitions).
Package (10) {}
Note: The ability to create variable-sized packages is new in ACPI 2.0. ACPI 1.0 only allowed fixed-size packages with up to 255 elements.
Compaq/Intel/Microsoft/Phoenix/Toshiba
16.2.3.6.3.1 Integers
LeadDigitChar OctalDigitChar HexDigitChar Integer DecimalConst OctalConst HexConst ByteConst WordConst DWordConst QWordConst := 1- 9 := 0- 7 := DigitChar | A-F | a- f := := := := := := := := DecimalConst | OctalConst | HexConst LeadDigitChar | <DecimalConst DigitChar> 0 | <OctalConst OctalDigitChar> <0x HexDigitChar> | <0X HexDigitChar> | <HexConst HexDigitChar> Integer=>0x00-0xff Integer=>0x0000-0xffff Integer=>0x00000000-0xffffffff Integer=>0x0000000000000000-0xffffffffffffffff
Numeric constants can be specified in decimal, octal, or hexadecimal. Octal constants are preceded by a leading zero (0), and hexadecimal constants are preceded by a leading zero and either a lower or upper case x. In some cases, the grammar specifies that the number must evaluate to an integer within a limited range, such as 0x00 0xFF, and so on.
16.2.3.6.3.2 Strings
String AsciiCharList AsciiChar EscapeSeq SimpleEscapeSeq OctalEscapeSeq HexEscapeSeq NullChar := AsciiCharList := Nothing | <EscapeSequence AsciiCharList> | <AsciiChar AsciiCharList> := 0x01-0x21 | 0x23-0x5B | 0x5D-0x7F := SimpleEscapeSeq | OctalEscapeSeq | HexEscapeSeq := \' | \" | \a | \b | \f | \n | \r | \t | \v | \\ := \ OctalDigit | \ OctalDigit OctalDigit | \ OctalDigit OctalDigit OctalDigit := \x HexDigit | \x HexDigit HexDigit := 0x00
String literals consist of zero or more ASCII characters surrounded by double quotation marks ("). A String may not exceed 200 characters. A string literal represents a sequence of characters that, taken together, form a null-terminated string. After all adjacent strings in the constant have been concatenated, NullChar is appended. Since double quotation marks are used close a string, a special escape sequence (\") is used to allow quotation marks within strings. Other escape sequences are listed in the table below:
ASCII Character 0x07 (BEL) 0x08 (BS) 0x0C (FF) 0x0A (LF) 0x0D (CR) 0x09 (TAB) 0x0B (VT) 0x22 (")
Compaq/Intel/Microsoft/Phoenix/Toshiba
(continued) Escape Sequence \' \\ ASCII Character 0x27 (') 0x5C (\)
Since literal strings are read-only constants, the following ASL statement (for example) is not supported:
Store(ABC, DEF)
The constant declaration terms are Zero, One, Ones , and Revision.
Converts EISAIDString, a 7-character text string argument, into its corresponding 4-byte numeric EISA ID encoding. It can be used when declaring IDs for devices that have EISA IDs.
Compaq/Intel/Microsoft/Phoenix/Toshiba
For a full definition of the ResourceTemplateTerm macro, see section 6.4.1, ASL Macros for Resource Descriptors.
Compaq/Intel/Microsoft/Phoenix/Toshiba
This macro will convert an ASCII string to a Unicode string contained in a buffer.
The debug data object is a virtual data object. Writes to this object provide debugging information. On at least debug versions of the interpreter, any writes into this object are appropriately displayed on the systems native kernel debugger. All writes to the debug object are otherwise benign. If the system is in use without a kernel debugger, then writes to the debug object are ignored. The following table relates the ASL term types that can be written to the Debug object to the format of the information on the kernel debugger display. Table 16-13 Debug Object Display Formats ASL Term Type Numeric data object String data object Object reference Display Format All digits displayed in hexadecimal format. String is displayed. Information about the object is displayed (for example, object type and object name), but the object is not evaluated.
The Debug object is a write-only object; attempting to read from the debug object is not supported.
Up to 7 argument-object references can be passed to a control method. On entry to a control method, only the argument objects that are passed are usable.
Up to 8 local objects can be referenced in a control method. On entry to a control method, these objects are uninitialized and cannot be used until some value or reference is stored into the object. Once initialized, these objects are preserved in the scope of execution for that control method.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following is an example of how these macros can be used to create a resource template that can be returned from a _PRS control method:
ResourceTemplate() { StartDependentFn(1,1) { IRQ(Level, ActiveLow, Shared){10, 11} DMA(TypeF, NotBusMaster, Transfer16){4} IO(Decode16, 0x1000, 0x2000, 0, 0x100) IO(Decode16, 0x5000, 0x6000, 0, 0x100, IO1) } StartDependentFn(1,1) { IRQ(Level, ActiveLow, Shared){} DMA(TypeF, NotBusMaster, Transfer16){5} IO(Decode16, 0x3000, 0x4000, 0, 0x100) IO(Decode16, 0x5000, 0x6000, 0, 0x100, IO2) } EndDependentFn() }
Occasionally, it is necessary to change a parameter of a descriptor in an existing resource template. To facilitate this, the descriptor macros optionally include a name declaration that can be used later to refer to the descriptor. When a name is declared with a descriptor, the ASL compiler will automatically create field names under the given name to refer to individual fields in the descriptor. For example, given the above resource template, the following code changes the minimum and maximum addresses for the I/O descriptor named IO2:
Store(0xA000, IO2._MIN) Store(0xB000, IO2._MAX)
The resource template macros for each of the resource descriptors are listed below, after the table that defines the resource descriptor. The resource template macros are formally defined in section 15, Memory. The reserved names (such as _MIN and _MAX) for the fields of each resource descriptor are defined in the appropriate table entry of the table that defines that resource descriptor.
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following macro generates a short IRQ descriptor without optional IRQ Information byte:
IRQNoFlags( NameString | Nothing // A name to refer back to this resource ) { ByteConstExpr [, ByteConstExpr ... ] // list of IRQ numbers (valid values: 0-15)
The following macros generates a Start Dependent Function descriptor without the optional Priority byte:
StartDependentFnNoPri( ) { Descriptors
Compaq/Intel/Microsoft/Phoenix/Toshiba
392 Advanced Configuration and Power Interface Specification The following macro generates a short Fixed I/O descriptor:
FixedIO( WordConstExpr, ByteConstExpr NameString | Nothing ) // _BAS, Address base // _LEN, Range length // A name to refer back to this resource
16.2.4.6 ASL Macro for Fixed I/O Port Descriptor 16.2.4.7 ASL Macro for Short Vendor-Defined Descriptor
The following macro generates a short Vendor-Defined descriptor:
VendorShort( NameString | Nothing // A name to refer back to this resource ) { ByteConstExpr [, ByteConstExpr ...] // List of bytes, up to 7 bytes }
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
The following macros generates a WORD Address des criptor with ResourceType = BusNumber:
WordBusNumber( ResourceConsumer | ResourceProducer | Nothing, MinFixed | MinNotFixed | Nothing, MaxFixed | MaxNotFixed | Nothing, SubDecode | PosDecode | Nothing, WordConstExpr, WordConstExpr, WordConstExpr, WordConstExpr, WordConstExpr, ByteConstExpr | Nothing, StringData | Nothing NameString | Nothing ) // // // // // // // // // // // // // // // Nothing=>ResourceConsumer _MIF, Nothing=>MinNotFixed _MAF, Nothing=>MaxNotFixed _DEC, Nothing=>PosDecode _GRA, Address granularity _MIN, Address range minimum _MAX, Address range max _TRA: Translation _LEN, Address range length Resource Source Index; if Nothing, not generated Resource Source; if Nothing, not generated A name to refer back to this resource
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Number in bold.
Compaq/Intel/Microsoft/Phoenix/Toshiba
398 Advanced Configuration and Power Interface Specification Table 17-1 AML Grammar Notation Conventions (continued) Notation Convention Angle brackets (< > ) Description Used to group items. Separates alternatives. Example <a b> | <c d> means either a b or c d. aterm := bterm | [cterm dterm] means the following constructs are possible: bterm cterm dterm aterm := [bterm | cterm] dterm means the following constructs are possible: bterm dterm cterm dterm Dash character ( - ) Parenthesized term following another term. Indicates a range. The parenthesized term is the repeat count of the previous term. 1-9 means a single digit in the range 1 to 9 inclusive. aterm(3) means aterm aterm aterm. bterm(n ) means n number of bterms.
Bar symbol ( | )
OemTableID
OemRev CreatorID
CreatorRev
Compaq/Intel/Microsoft/Phoenix/Toshiba
The AML encoding can be categorized in the following groups: Name objects encoding Data objects encoding Package length encoding Term objects encoding Miscellaneous objects encoding
:= <LeadNameChar NameChar NameChar NameChar> // Notice that NameSegs shorter than 4 characters are // filled with trailing _s. := <RootChar NamePath> | <PrefixPath NamePath> := Nothing | <^ PrefixPath> := NameSeg | DualNamePath | MultiNamePath := := := := := DualNamePrefix NameSeg NameSeg 0x2e MultiNamePrefix SegCount NameSeg(SegCount) 0x2f ByteData // SegCount can be from 1 to 255. // MultiNamePrefix(35) => 0x2f 0x23 // and following by 35 NameSegs. // So, the total encoding length // will be 1 + 1 + 35*4 = 142. // Notice that: // DualNamePrefix NameSeg NameSeg // has a smaller encoding than the // equivalent encoding of: // MultiNamePrefix(2) NameSeg NameSeg := NameString | ArgObj | LocalObj := SimpleName | DebugObj | Type6Opcode := SuperName | NullName
Compaq/Intel/Microsoft/Phoenix/Toshiba
PkgLeadByte
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
DefCreateBitField CreateBitFieldOp SourceBuff BitIndex DefCreateByteField CreateByteFieldOp ByteIndex DefCreateDWordField CreateDWordFieldOp DefCreateField CreateFieldOp NumBits DefCreateQWordField CreateQWordFieldOp DefCreateWordField CreateWordFieldOp DefDataRegion DataRegionOp DefDevice DeviceOp DefEvent EventOp DefField FieldOp DefIndexField IndexFieldOp DefMethod MethodOp MethodFlags
:= CreateByteFieldOp SourceBuff ByteIndex NameString := 0x8c := TermArg=>Integer := CreateDWordFieldOp SourceBuff ByteIndex NameString := 0x8a := CreateFieldOp SourceBuff BitIndex NumBits NameString := ExtOpPrefix 0x13 := TermArg=>Integer := CreateQWordFieldOp SourceBuff ByteIndex NameString := 0x8f := CreateWordFieldOp SourceBuff ByteIndex NameString := 0x8b := DataRegionOp NameString TermArg TermArg TermArg := ExOpPrefix 0x88 := DeviceOp PkgLength NameString ObjectList := ExtOpPrefix 0x82 := EventOp NameString := ExtOpPrefix 0x02 := FieldOp PkgLength NameString FieldFlags FieldList := ExtOpPrefix 0x81 := IndexFieldOp PkgLength NameString NameString FieldFlags FieldList := ExtOpPrefix 0x86 := MethodOp PkgLength NameString MethodFlags TermList := 0x14 := ByteData // bit 0-2: ArgCount (0-7) // bit 3: SerializeFlag // 0: NotSerialized // 1: Serialized // bit 4-7: SyncLevel (0x00-0x0f) := MutexOp NameString SyncFlags := ExtOpPrefix 0x01 := ByteData // bit 0-3: SyncLevel (0x00-0x0f) // bit 4-7: reserved (must be 0)
Compaq/Intel/Microsoft/Phoenix/Toshiba
RegionOffset RegionLen DefPowerRes PowerResOp SystemLevel ResourceOrder DefProcessor ProcessorOp ProcID PblkAddr PblkLen DefThermalZone ThermalZoneOp
:= OpRegionOp NameString RegionSpace RegionOffset RegionLen := ExtOpPrefix 0x80 := ByteData // 0x00: SystemMemory // 0x01: SystemIO // 0x02: PCI_Config // 0x03: EmbeddedControl // 0x04: SMBus // 0x05: CMOS // 0x06: PciBarTarget // 0x80-0xff: user defined := TermArg=>Integer := TermArg=>Integer := PowerResOp PkgLength NameString SystemLevel ResourceOrder ObjectList := ExtOpPrefix 0x84 := ByteData := WordData := ProcessorOp PkgLength NameString ProcID PblkAddr PblkLen ObjectList := ExtOpPrefix 0x83 := ByteData := DwordData := ByteData := ThermalZoneOp PkgLength NameString ObjectList := ExtOpPrefix 0x85
DefBreak BreakOp DefBreakPoint BreakPointOp DefContinue ContinueOp DefElse ElseOp DefFatal FatalOp FatalType FatalCode FatalArg DefIfElse IfOp Predicate DefLoad LoadOp DDBHandleObject DefNoop NoopOp DefNotify NotifyOp NotifyObject NotifyValue
:= IfOp PkgLength Predicate TermList DefElse := 0xa0 := TermArg=>Integer := LoadOp NameString DDBHandleObject := ExtOpPrefix 0x20 := SuperName := NoopOp := 0xa3 := := := := NotifyOp NotifyObject NotifyValue 0x86 SuperName=>ThermalZone|Processor|Device TermArg=>Integer
Compaq/Intel/Microsoft/Phoenix/Toshiba
:= SleepOp MsecTime := ExtOpPrefix 0x22 := TermArg=>Integer := StallOp UsecTime := ExtOpPrefix 0x21 := TermArg=>ByteData := UnloadOp DDBHandleObject := ExtOpPrefix 0x2a := WhileOp PkgLength Predicate TermList := 0xa2
DefAnd AndOp DefBuff BuffOp DefBuffer BufferOp BufferSize DefConcat ConcatOp Data
:= AndOp Operand Operand Target := 0x7b := BuffOp Operand Target := 0x96 := := := := := := BufferOp PkgLength BufferSize ByteList 0x11 TermArg=>Integer ConcatOp Data Data Target 0x73 TermArg=>ComputationalData
Compaq/Intel/Microsoft/Phoenix/Toshiba
DefConcatRes ConcatResOp BufData DefCondRefOf CondRefOfOp DefCopy CopyOp DefDecStr DecStrOp DefDecrement DecrementOp DefDerefOf DerefOfOp ObjReference
:= ConcatResOp BufData BufData Target := 0x84 := TermArg=>Buffer := CondRefOfOp SuperName Target := ExtOpPrefix 0x12 := CopyOp TermArg SimpleName := 0x9d := DecStrOp Operand Target := 0x97 := DecrementOp SuperName := 0x76 := DerefOfOp ObjReference := 0x83 := TermArg=>ObjectReference|String //ObjectReference is an object produced by terms //such as Index, RefOf or CondRefOf. := := := := := := DivideOp Dividend Divisor Remainder Quotient 0x78 TermArg=>Integer TermArg=>Integer Target Target
DefDivide DivideOp Dividend Divisor Remainder Quotient DefFindSetLeftBit FindSetLeftBitOp DefFindSetRightBit FindSetRightBitOp DefFromBCD FromBCDOp BCDValue DefHexStr HexStrOp DefIncrement IncrementOp DefIndex IndexOp BuffPkgStrObj IndexValue DefInt IntOp DefLAnd LandOp DefLEqual LequalOp DefLGreater LgreaterOp DefLGreaterEqual LgreaterEqualOp DefLLess LlessOp DefLLessEqual LlessEqualOp
:= FindSetLeftBitOp Operand Target := 0x81 := FindSetRightBitOp Operand Target := 0x82 := FromBCDOp BCDValue Target := ExtOpPrefix 0x28 := TermArg=>Integer := HexStrOp Operand Target := 0x98 := IncrementOp SuperName := 0x75 := := := := IndexOp BuffPkgStrObj IndexValue Target 0x88 TermArg=>Buffer, Package or String TermArg=>Integer
:= IntOp Operand Target := 0x99 := LandOp Operand Operand := 0x90 := LequalOp Operand Operand := 0x93 := LgreaterOp Operand Operand := 0x94 := LgreaterEqualOp Operand Operand := LnotOp LlessOp := LlessOp Operand Operand := 0x95 := LlessEqualOp Operand Operand := LnotOp LgreaterOp
Compaq/Intel/Microsoft/Phoenix/Toshiba
StartIndex DefMid MidOp MidObj DefMod ModOp DefMultiply MultiplyOp DefNAnd NandOp DefNOr NorOp DefNot NotOp DefObjectType ObjectTypeOp DefOr OrOp DefPackage DefVarPackage PackageOp VarPackageOp NumElements VarNumElements PackageElementList PackageElement DefRefOf RefOfOp DefShiftLeft ShiftLeftOp ShiftCount DefShiftRight ShiftRightOp DefSizeOf SizeOfOp
:= RefOfOp SuperName := 0x71 := ShiftLeftOp Operand ShiftCount Target := 0x79 := TermArg=>Integer := ShiftRightOp Operand ShiftCount Target := 0x7a := SizeOfOp SuperName := 0x87
Compaq/Intel/Microsoft/Phoenix/Toshiba
DefStore StoreOp DefString LengthArg StringOp DefSubtract SubtractOp DefToBCD ToBCDOp DefWait WaitOp DefXOr XorOp
:= StoreOp TermArg SuperName := 0x70 := StringOp TermArg LengthArg Target := TermArg=>Integer := 0x9c := SubtractOp Operand Operand Target := 0x74 := ToBCDOp Operand Target := ExtOpPrefix 0x29 := WaitOp EventObject Operand := ExtOpPrefix 0x25 := XorOp Operand Operand Target := 0x7f
Compaq/Intel/Microsoft/Phoenix/Toshiba
408 Advanced Configuration and Power Interface Specification Table 17-2 AML Byte Stream Byte Values Encoding Value 0x00 0x01 0x02-0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15-0x2D 0x2E (.) 0x2F (/) 0x30-0x40 Encoding Name ZeroOp OneOp AliasOp NameOp BytePrefix WordPrefix DWordPrefix StringPrefix QWordPrefix ScopeOp BufferOp PackageOp VarPackageOp MethodOp DualNamePrefix MultiNamePrefix Encoding Group Data Object Data Object Term Object Term Object Data Object Data Object Data Object Data Object Data Object Term Object Term Object Term Object TermObjec t Term Object Name Object Name Object Fixed List Arguments NameString NameString NameString DataRefObject ByteData WordData DWordData AsciiCharList NullChar QWordData NameString TermArg ByteData TermArg NameString ByteData NameSeg NameSeg ByteData NameSeg(N) Variable List Arguments TermList ByteList PackageTermList PackageTermList TermList
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 17-2 AML Byte Stream Byte Values (continued) Encoding Value 0x41-0x5A (A-Z) 0x5B ([) 0x5B 0x01 0x5B 0x02 0x5B 0x12 0x5B 0x13 0x5B 0x1F Encoding Name NameChar ExtOpPrefix MutexOp EventOp CondRefOfOp CreateFieldOp LoadTableOp Encoding Group Name Object Term Object Term Object Term Object Term Object Term Object Fixed List Arguments ByteData NameString ByteData NameString SuperName SuperName TermArg TermArg TermArg NameString TermArg TermArg TermArg TermArg TermArg TermARg NameString NameString SuperName TermArg TermArg SuperName WordData SuperName SuperName TermArg SuperName SuperName TermArg Target TermArg Target SuperName Variable List Arguments
0x5B 0x20 0x5B 0x21 0x5B 0x22 0x5B 0x23 0x5B 0x24 0x5B 0x25 0x5B 0x26 0x5B 0x27 0x5B 0x28 0x5B 0x29 0x5B 0x2A 0x5B 0x30
LoadOp StallOp SleepOp AcquireOp SignalOp WaitOp ResetOp ReleaseOp FromBCDOp ToBCD UnloadOp RevisionOp
Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Data Object
Compaq/Intel/Microsoft/Phoenix/Toshiba
410 Advanced Configuration and Power Interface Specification Table 17-2 AML Byte Stream Byte Values (continued) Encoding Value 0x5B 0x31 0x5B 0x32 0x5B 0x80 0x5B 0x81 0x5B 0x82 0x5B 0x83 0x5B 0x84 0x5B 0x85 0x5B 0x86 0x5B 0x87 0x5B 0x88 0x5C (\) 0x5D 0x5E (^) 0x5F(_) 0x60 (`) 0x61 (a) 0x62 (b) 0x63 (c) 0x64 (d) Encoding Name DebugOp FatalOp OpRegionOp FieldOp DeviceOp ProcessorOp PowerResOp ThermalZoneOp IndexFieldOp BankFieldOp DataRegionOp RootChar ParentPrefixChar NameChar Local0Op Local1Op Local2Op Local3Op Local4Op Encoding Group Debug Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Name Object Name Object Name Object Local Object Local Object Local Object Local Object Local Object Fixed List Arguments ByteData DWordData TermArg NameString ByteData TermArg TermArg NameString ByteData NameString NameString ByteData DWordData ByteData NameString ByteData WordData NameString NameString NameString ByteData NameString NameString TermArg ByteData NameString TermArg TermArg TermArg Variable List Arguments FieldList ObjectList ObjectList ObjectList ObjectList FieldList FieldList
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 17-2 AML Byte Stream Byte Values (continued) Encoding Value 0x65 (e) 0x66 (f) 0x67 (g) 0x68 (h) 0x69 (i) 0x6A (j) 0x6B (k) 0x6C (l) 0x6D (m) 0x6E (n) 0x6F 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7A 0x7B Encoding Name Local5Op Local6Op Local7Op Arg0Op Arg1Op Arg2Op Arg3Op Arg4Op Arg5Op Arg6Op StoreOp RefOfOp AddOp ConcatOp SubtractOp IncrementOp DecrementOp MultiplyOp DivideOp ShiftLeftOp ShiftRightOp AndOp Encoding Group Local Object Local Object Local Object Arg Object Arg Object Arg Object Arg Object Arg Object Arg Object Arg Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Fixed List Arguments TermArg SuperName SuperName TermArg TermArg Target TermArg TermArg Target TermArg TermArg Target SuperName SuperName TermArg TermArg Target TermArg TermArg Target Target TermArg TermArg Target TermArg TermArg Target TermArg TermArg Target Variable List Arguments
Compaq/Intel/Microsoft/Phoenix/Toshiba
412 Advanced Configuration and Power Interface Specification Table 17-2 AML Byte Stream Byte Values (continued) Encoding Value 0x7C 0x7D 0x7E 0x7F 0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 Encoding Name NandOp OrOp NorOp XorOp NotOp FindSetLeftBitOp FindSetRightBitOp DerefOfOp ConcatResOp ModOp NotifyOp SizeOfOp IndexOp MatchOp Encoding Group Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Fixed List Arguments TermArg TermArg Target TermArg TermArg Target TermArg TermArg Target TermArg TermArg Target TermArg Target TermArg Target TermArg Target TermArg TermArg TermArg Target TermArg TermArg Target SuperName TermArg SuperName TermArg TermArg Target TermArg ByteData TermArg ByteData TermArg TermArg TermArg TermArg NameString TermArg TermArg NameString TermArg TermArg NameString TermArg TermArg NameString SuperName Variable List Arguments
Compaq/Intel/Microsoft/Phoenix/Toshiba
Table 17-2 AML Byte Stream Byte Values (continued) Encoding Value 0x8F 0x90 0x91 0x92 0x92 0x93 0x92 0x94 0x95 0x92 0x93 0x94 0x95 0x96 0x97 0x98 0x99 0x9A-0x9B 0x9C 0x9D 0x9E 0x9F 0xA0 Encoding Name CreateQWordField LandOp LorOp LnotOp LNotEqualOp LLessEqualOp LGreaterEqualOp LEqualOp LGreaterOp LLessOp BuffOp DecStrOp HexStrOp IntOp StringOp CopyOp MidOp ContinueOp IfOp Encoding Group Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Term Object Fixed List Arguments TermArg TermArg NameString TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg TermArg Target TermArg Target TermArg Target TermArg Target TermArg TermArg Target TermArg SimpleName TermArg TermArg TermArg Target TermArg Variable List Arguments TermList
Compaq/Intel/Microsoft/Phoenix/Toshiba
414 Advanced Configuration and Power Interface Specification Table 17-2 AML Byte Stream Byte Values (continued) Encoding Value 0xA1 0xA2 0xA3 0xA4 0xA5 0xA60xCB 0xCC 0xCD0xFE 0xFF Encoding Name ElseOp WhileOp NoopOp ReturnOp BreakOp BreakPointOp OnesOp Encoding Group Term Object Term Object Term Object Term Object Term Object Term Object Data Object Fixed List Arguments TermArg TermArg Variable List Arguments TermList TermList
Compaq/Intel/Microsoft/Phoenix/Toshiba
Assume further that a definition block is loaded that creates a node \S0.CPU.SET, and loads a block using it as a root. Assume the loaded block contains the following names:
STP1 ^GET ^^PCI0 ^^PCI0.SBS \S2 \S2.ISA.COM1 ^^^S3 ^^^S2.MEM ^^^S2.MEM.SET Scope(\S0.CPU.SET.STP1) { XYZ ^ABC ^ABC.DEF }
'PCI0' DualNamePrefix 'PCI0' 'SBS_' 'ISA_' 'COM1' ParentPrefixChar 'S3__' ParentPrefixChar DualNamePrefix 'S2__' 'MEM_' ParentPrefixChar MultiNamePrefix 3 'S2__' 'MEM_'
After the block is loaded, the namespace will look like this (names added to the namespace by the loading operation are shown in bold):
\ S0 MEM SET GET CPU SET STP1 XYZ ABC DEF GET PCI0 SBS S1 MEM SET GET CPU SET GET S2 ISA COM1 MEM SET S3
Compaq/Intel/Microsoft/Phoenix/Toshiba
A.1 Overview
The power management of individual devices is the responsibility of a policy owner in the operating system. This software element will implement a power management policy that is appropriate for the type (or class) of device being managed. Device power management policy typically operates in conjunction with a global system power policy implemented in the operating system. In general, the device-class power management policy strives to reduce power consumption while the system is working by transitioning among various available power states according to device usage. The challenge facing policy owners is to minimize power consumption without adversely impacting the systems usability. This balanced approach provides the user with both power savings and good performance. Because the policy owner has very specific knowledge about when a device is in use or potentially in use, there is no need for hardware timers or such to determine when to make these transitions. Similarly, this level of understanding of device usage makes it possible to use fewer device power states. Generally, intermediate states attempt to draw a compromise between latency and consumption because of the uncertainty of actual device usage. With the increased knowledge in the OS, good decisions can be made about whether the device is needed at all. With this ability to turn devices off more frequently, the benefit of having intermediate states diminishes. The policy owner also determines what class-specific events can cause the system to transition from sleeping to working states, and enables this functionality based on application or user requests. Notice that the definition of the wake events that each class supports will influence the systems global power policy in terms of the level of power management a system sleeping state can attain while still meeting wake latency requirements set by applications or the user.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Device power-state transitions are typically invoked through bus-specific mechanisms (for example, ATA Standby, USB Suspend, and so on). In some cases, bus-specific mechanisms are not available and devicespecific mechanisms must be used. Notice that the explicit command for entering the D3 state might be the removal of power. It is the responsibility of the policy owner (or other software) to restore any lost device context when returning to the D0 state.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Device determined by the OS to not be needed by any applications or the user. System enters a sleeping state.
D3
D0
D2
Required
D3
Required
If a device is in the D1 or D2 state it must resume within 100 ms. A device in the D3 state may take as long as it needs to power up. It is the responsibility of the policy owner to advertise to the system how long a device requires to power up. All audio devices must be capable of D0, D2 and D3 states. It is desirable that an audio device be capable of D1 state. The difference between D1 and D2 is that a device capable of D1 can maintain complete state information in reduced power mode. The policy owner or other software must save all states for D2capable devices. Some audio samples may be lost in transitioning into and out of the D2 state. Notice that the D1 state was added to allow digital signal processor (DSP)-equipped audio hardware to exploit low-power modes in the DSP. For example, a DSP may be used to implement Dolby AC-3 Decode. When paused it stops playing audio, but the DSP may contain thousands of bytes worth of state information. If the DSP supports a low-power state, it can shut down and later resume from exactly the audio sample where it paused without losing state information.
Compaq/Intel/Microsoft/Phoenix/Toshiba
D2/D1 D0 D2 D0
D0 D2 D3 D3
When an audio device is in the D0 state it will refuse system requests to transition to D3 state unless it is in background record mode. When an audio device is paused (D1 or D2) and it receives a request to transition to the D3 state, it will save the state of the audio device and transition to the D3 state. Since multimedia applications often open and close audio files in rapid succession, it is recommended that an inactivity timer be employed by the policy owner to prevent needless shutdowns (D3 transitions) of the audio hardware. For example, frequent power cycling may damage audio devices powered by vacuum tubes.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
A.6.1 Power State Definitions A.6.1.1 CRT Monitors and LCD Panels
State D0 Status Required Definition This state is equivalent to the On state defined in the VESA DPMS specification (see Related Documents) and is signaled to the dis play using the DPMS method. Display is fully on Video image is active D1 Optional This state is equivalent to the Standby state defined in the VESA DPMS and is signaled to the display using the DPMS method. Display is functional but may be conserving energy Video image is blank Latency to return to D0 must be less than 5 seconds D2 Required This state is equivalent to the Suspend state defined in the VESA DPMS specification and is signaled to the display using the DPMS method. Display is functional and conserving energy Video image is blank Latency to return to D0 is less than 10 seconds D3 Required This state is equivalent to the Off state defined in the VESA DPMS specification and is signaled to the display using the DPMS method. Display is non-functional Video image is blank
Compaq/Intel/Microsoft/Phoenix/Toshiba
D1/D2/D3 D0
These state transition definitions apply to both the monitor/ LCD and the video controller. However, the control of the two devices is independent, except that a video controller will never be put into a lower power state than its monitor/LCD(s). Transitions for the video controller are commanded via the bus-specific control mechanism for device states. Monitor/LCD transitions are commanded by signaling from the video controller (DPMS) and are only generated as a result of explicit commands from the policy-owner. Monitor/LCD power control is functionally independent from any other interface the monitor may provide (such as USB). For instance, Hubs and HID devices in the monitor enclosure may be power-managed by their driver over the USB bus, but the Monitor/LCD device itself may not; it must be power-managed by DPMS from the video controller.
Compaq/Intel/Microsoft/Phoenix/Toshiba
D1
Optional
Compaq/Intel/Microsoft/Phoenix/Toshiba
Requested by the system *Depends on capability of device (if it features D1 or D3 wake capability or not); device will be put in state with the lowest possible power consumption.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
D2
Optional
Compaq/Intel/Microsoft/Phoenix/Toshiba
(continued) State D3 Status Required Definition Card status change interrupt: Disabled and need not be detected. Card functional interrupt: Disabled and need not be detected. Controller context (for example, memory, I/O windows): Lost. Controller interface: Non-functional (processor can not access cards). Clock to controller: Off. Power to cards (slots): Off (card context lost). Note: If Vcc is removed (for example, PCI Bus B3) while the device is in the D3 state, a bus-specific reset (for example, PCI RST#) must be asserted when power is restored and functions will then return to the D0 state with a full power-on reset sequence. Whenever the transition from D3 to D0 is initiated through assertion of a bus-specific reset, the power-on defaults will be restored to the function by hardware just as at initial power up. The function must then be fully initialized and reconfigured by software.
Cause Any card in any slot needing to transition to state D0 due to a wake event or because of system usage. No card in any slot is in state D0. No card in any slot is in state D0 or D1. All cards in all slots are in state D3.
Compaq/Intel/Microsoft/Phoenix/Toshiba
A.11.1 Power State Definitions A.11.1.1 Hard Disk, CD-ROM and IDE/ATAPI Removable Storage Devices
State D0 Status Required Definition Drive controller (for example, interface and control electronics) is functional. Interface mode context (for example, communications timings) is programmed.
D1
Optional
Drive controller (for example, interface and control electronics) is functional. Interface mode context (for example, communications timings) is preserved. Drive motor (for example, spindle) is stopped, with fast-start mode enabled, if available. Laser (if any) is off. Recommended latency to return to D0 is less than 5 seconds. Power consumption in D1 should be no more than 80% of power consumed in D0. Note: For ATA devices, this state is invoked by the Standby Immediate command.
D2 D3
N/A Required
This state is not defined for storage devices. Drive controller (for example, interface and control electronics) is not functional; context is lost. Interface mode (for example, communications timings) is not preserved. Drive motor (for example, spindle) is stopped. Laser (if any) is off. Power consumption in D3 is no more than 10% of power consumed in D0. Note: For ATA devices, this state is invoked by the sleep command.
Compaq/Intel/Microsoft/Phoenix/Toshiba
A.11.2 Power Management Policy A.11.2.1 Hard Disk, Floppy Disk, CD-ROM and IDE/ATAPI Removable Storage Devices
Present State D3 D0 D0 Next State D0 D1* D3 Cause Device usage (high-priority I/O). Device inactivity (no high-priority I/O) for some period of time (T1). Device inactivity (no high-priority I/O) for a period of time (T2=>T1). System enters sleeping state. D1* D0 * If supported. Device usage (High-priority I/O).
Note: For ATA, the D3-to-D0 transition requires a reset of the IDE channel. This means that both devices on a channel must be placed into D3 at the same time.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
APPENDIX B: Video Extensions B ACPI Extensions for Display Adapters B.1 Introduction
This section of the document describes a number of specialized ACPI methods to support motherboard graphics devices. In many cases, system manufacturers need to add special support to handle multiple output devices such as panels and TV-out capabilities, as well as special power management features. This is particularly true for notebook manufacturers. The methods described here have been designed to enable interaction between the system BIOS, video driver, and OS to smoothly support these features. Systems containing a built-in display adapter are required to implement the ACPI Extensions for Display Adapters. Table B-1 Video Extension Object Requirements Method _DOS _DOD _ROM _GPD _SPD _VPO _ADR _BCL _BCM _DDC Description Enable/Disable output switching Enumerate all devices attached to display adapter Get ROM Data Get POST Device Set POST Device Video POST Options Return the unique ID for this device Query list of brightness control levels supported Set the brightness level Return the EDID for this device Required if system supports display switching or LCD brightness levels Required if integrated controller supports output switching Required if ROM image is stored in proprietary format Required if _VPO is implemented Required if _VPO is implemented Required if system supports changing post VGA device Required Required if embedded LCD supports brightness control Required if _BCL is implemented Required if embedded LCD does not support return of EDID via standard interface Required if the system supports display switching (via hotkey) Required if the system supports display switching (via hotkey Required if the system supports display switching (via hotkey).
Return status of output device Query graphics state Device state set
Compaq/Intel/Microsoft/Phoenix/Toshiba
B.2 Definitions
Built-in display adapter. This is a graphics chip that is built into the motherboard and cannot be replaced. ACPI information is valid for such built-in devices. Add-in display adapter. This is a graphics chip or board that can be added to or removed from the computer. Because the system BIOS cannot have specific knowledge of add-in boards, ACPI information is not available for add-in devices. Boot-up display adapter. This is the display adapter programmed by the system BIOS during machine power-on self-test (POST). It is the device upon which the machine will show the initial operating system boot screen, as well as any system BIOS messages . The system can change the boot-up display adapter, and it can switch between the built-in adapter and the add-in adapter. Display device. This is a synonym for the term display adapter discussed above. Output device. This is a device, which is a recipient of the output of a display device. For example, a CRT or a TV is an output device.
_PS0 / PR0 _PS1 / PR1 _PS3 _DOS _DOD _ROM _GPD _SPD _VPO CRT |- _ADR |- _DDC |- _DCS |- _DGS |- _DSS |- _PS0 |- _PS1 |- _PS2 |- _PS3 |- LCD |- _ADR |- _DDC |- _DCS |- _DGS |- _DSS |- _BCL |- _BCM |- _PS0 |- _PS1 |- _PS2 |- _PS3 |- TV |- _ADR |- _DDC |- _DCS |- _DGS |- _DSS
// // // // // // // // // // // // \
Method to control display output switching Method to retrieve information about child output devices Method to retrieve the ROM image for this device Method for determining which VGA device will post Method for controlling which VGA device will post Method for determining the post options Child device CRT Hardware ID for this device Get EDID information from the monitor device Get current hardware status Query desired hardware active \ inactive state Set hardware active \ inactive state
- Power methods - for the output device / // // // // // // // // \ - Power methods - for the output device / // // // // // // Child Device TV Hardware ID for this device Get EDID information from the monitor device Get current hardware status Query desired hardware active \ inactive state Set hardware active \ inactive state Child device LCD Hardware ID for this device Get EDID information from the monitor device Get current hardware status Query desired hardware active \ inactive state Set hardware active \ inactive state Brightness control levels Brightness control method
Compaq/Intel/Microsoft/Phoenix/Toshiba
The LCD device represents the built-in output device. Mobile PCs will always have a built-in LCD display, but desktop systems that have a built-in graphics adapter generally dont have a built-in output device. Notify(VGA, 0x80) is an event that should be generated whenever the state of one of the output devices attached to the VGA controller has been switched or toggled. This event will, for example, be generated when the user presses a hotkey to switch the active display output from the LCD panel to the CRT. Notify(VGA, 0x81) is an event that should be generated whenever the state of any output devices attached to the VGA controller has been changed. This event will, for example, be generated when the user plugs-in or remove a CRT from the VGA port. In this case, OSPM will re -enumerate all devices attached to VGA controller. The event number is standardized because the event will be handled by the OS directly under certain circumstances (see _DOS method later in this specification).
Compaq/Intel/Microsoft/Phoenix/Toshiba
The _DOS method controls this automatic switching behavior. This method should do so by saving the parameter passed to this method in a global variable somewhere in the BIOS data segment. The system BIOS then checks the value of this variable when doing display switching. This method is also used to control the generation of the display switching Notify(VGA, 0x80/0x81). The system BIOS, when doing switching of the active display, must verify the state of the variable set by the _DOS method. The default value of this variable must be 1.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Device ID. The device ID must match the IDs specified by Video Chip Vendors. They must also be unique under VGA namespace. BIOS. Can detect the device. Non-VGA output device whose power is related to the VGA device. This can be used when specifying devices like TV Tuner, DVD decoder, Video Capture, and so on. For VGA multiple-head devices, this specifies head ID. Reserved (must be 0) Table B-3 Bits 0x0100 0x0110 0x0200 0 Commonly-used Device IDs Definition Monitor Panel TV Other
20:18 31:21
Compaq/Intel/Microsoft/Phoenix/Toshiba
Compaq/Intel/Microsoft/Phoenix/Toshiba
Sample Code:
Method (_SPD, 1) { // Make the motherboard device the device to post }
Compaq/Intel/Microsoft/Phoenix/Toshiba
The first number in the package is the level of the panel when full power is connected to the machine. The second number in the package is the level of the panel when the machine is on batteries. All other numbers are treated as a list of levels OSPM will cycle through when the user toggles (via a keystroke) the brightness level of the display. These levels will be set using the _BCM method described in the following section.
The method will be called in response to a power source change or at the specific request of the end user, for example, when the user presses a function key that represents brightness control.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Sample Code:
Method (_DDC, 2) { If (LEqual (Arg0, 1)) { Return (Buffer(128){ ,,,, }) } If (LEqual (Arg0, 2)) { Return (Buffer(256){ ,,,, }) } Return (0) }
The buffer will later be interpreted as an EDID data block. The format of this data is defined by the VESA EDID specification.
Example: If the output signal is activated by _DSS, _DCS returns 0x1F or 0x0F. If the output signal is inactivated by _DSS, _DCS returns 0x1D or 0x0D. If the device is not attached or cannot be detected, _DCS returns 0x0xxxx and should return 0x1xxxx if it is attached. If the output signal cannot be activated, _ DCS returns 0x1B or 0x0B. If the output connector does not exist (when undocked), _DCS returns 0x00.
Compaq/Intel/Microsoft/Phoenix/Toshiba
Device State
The desired state represents what the user wants to activate or deactivate, based on the special function keys the user pressed. OSPM will query the desired state when it receives the display toggle event (described earlier).
Compaq/Intel/Microsoft/Phoenix/Toshiba
OS may call in such an order to force BIOS to make _DGS jump to next state without actual CRT, LCD switching CRT._DSS(40000000L); LCD._DSS(C0000001L);
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index
_EJx 162 AC adapter device ID 139 power source objects 265 AC status notification 255 access types, Operation Region 353 access, device 301 AccessAs term 310 acoustics See noise ACPI definition 13 device ID 138 goals 1 ACPI Hardware See hardware ACPI Machine Language See AML ACPI mode entering 234 exiting 239 ACPI Namespace AML encoding 414 control method access 129 definition 13 display adapters 436 embedded controller device definition 302 generic hardware registers 77 Modifier Objects encoding, AML 401 modifiers, ASL 361 naming conventions 123 Processor statements 217 root namespaces 126 SMBus host controller objects 307 ACPI Source Language See ASL ACPI System Description tables See tables ACPI-compatible hardware See hardware Acquire (Acquire a Mutex) 371 Acquire terms 358 active cooling _ACx object 267, 274 control methods 270 definition 42, 267 engaging 270 preferences 42, 272 threshold values 272 active line printer (LPT) ports 34 Active List (_ALx) object 275 Add (Add) 371 add-in display adapter, definition 436 Address (_ADR) object 146 Address Range types 316 address register (SMB_ADDR) 294 Address Space Descriptors DWORD 181 QWORD 177 resource specific flags 186 valid combinations 176 WORD 184 addresses alarm fields 68 BARs (Base Address Registers) 355 blocking, BIOS 316 bus types 147 control methods 129 decoding 252 FACS 106 format 89 functional fixed hardware 44 Generic Address Structure (GAS) 89 generic hardware 45, 51 I/O (S)APIC 117 map interfaces 316 map samples 320 mixed, preventing 117 registers 57 reset register 77 slave 254, 305 SMBus 305 system description tables 85 Advanced Configuration and Power Interface See ACPI Advanced Programmable Interrupt Controller See APIC alarm address register (SMB_ALRM_ADDR) 295 alarm data register (SMB_ALRM_DATA) 296 alarm events 67 Alias (Declare Name Alias) 361 allocation, device resources 159 AML Arg Objects encoding 407 battery events 260 byte values 407 code event handler 46 compiling 45 Control Method Battery 261 data buffers, SMBus 310 Data Objects encoding 400 Debug Objects encoding 407 definition 13 grammar 398 Local Objects encoding 407 Name Objects encoding 399 Named Objects encoding 401
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 447
Namespace encoding 414 Namespace Modifier Objects encoding 401 notation conventions 397 Package Length encoding 400 purpose of 45 sleep button code example 65 SMBus device access protocols 311 specification 397 Term Objects encoding 401 Type 1 Opcodes encoding 403 Type 2 Opcodes encoding 404 And (Bitwise And) 371 angle brackets AML 398 ASL notation 323 answering phones modem example 32 power management 2 waking computer 34 APIC _MAT (Multiple APIC Table Entry) 155 definition 13 I/O 16, 113 local 16 multiple description table (MADT) 16 NMI 115 Processor Local 112 structure types 112 support 110, 113 APM BIOS 24 appliance PCs 105 ARB_DIS 75 architecture, system description tables 85 Arg Objects encoding, AML 407 arguments, control methods 130 Arg x (Method Argument Data Objects) 389 ASL _FIX usage example 152 _HPP example 154 AML, relation to 322 case sensitivity 341 CMOS protocols 354 comments 322 compiler directive terms 347 converting to AML 45 data objects 384 data types 342 definition 13 Definition Block terms 347 EC-SMB-HC device code 304 embedded controller device code 303 grammar 322 grammar notation 322 index with buffers example code 375 language 324 lid status code example 81
macros 129, 390. See also macros, ASL modifiers 341, 361 multiple Smart Battery subsystem code 260 Named Object terms 348 names 324 Namespace modifiers 361 nested packages sample code 375 object names 341 object terms 347, 361 objects, declaring 128 opcodes 362, 369 parameters 346 power button code example 63 Power Resource statements 197 reserved object names 341 SMBBlock code 314 SMBBlockProcessCall code 315 SMBByte code 313 SMBProcessCall code 315 SMBQuick code 312 SMBSendReceive code 312 SMBus data buffer code 311 SMBus devices 309 SMBWord code 313 storing results 346 strings 322 terms 324, 346 thermal zone examples 278 Type 1 Opcodes 362 Type 2 Opcodes 369 User Terms 384 virtual register code 310 AT interrupt model 120 ATA hard disks See storage devices audible output See noise audio devices, power management 418, 419 aware device drivers 134 Back From Sleep (_BFS) 205 BankField (Declare Bank/Data Field) 348 bar symbol AML notation 398 ASL notation 323 BARs (Base Address Registers) 355 Base Bus Number (_BBN) object 194 batteries See also Smart Batteries capacity 38 Control Method Batteries 260 emergency shutdown 40 events 260 low-level warnings 39 management 37 multiple 37 power status information 31 remaining capacity 264 types supported 31 Battery Information (_BIF) object 261
Compaq/Intel/Microsoft/Phoenix/Toshiba
Battery Status (_BST) object 263 Battery Trip Point (_BTP) object 264 bay devices 268 BIOS address range types 316 configuring boot devices 36 determining ACPI support 69 Device Objects 351 devices, switching 445 Dock Name (_BDN) 192 initialization 233 legacy functions 24 legacy specifications 12 limitations on power management 2 memory initialization 235 relation to ACPI 4 resetting enable bits 79 S4 Sleeping state transition 230 bits alarm 68 child 51, 77 child status 79 control 77 diagram legend 47 enable 55 general-purpose events 79 generic hardware registers 77 ignored 16, 52 interrupt status 51 lid status 81 parent 51, 77 PM timer 75 PM1 Control registers 74 PM1 Enable registers 73 PM1 Status registers 70 PM2 Control register 75 processor control register 76 processor LVL2 76 processor LVL3 77 register notation 47 reserved 17, 51, 88 reset register 77 SMBus protocol encoding 306 status 55, 77 system event signals 36 wake enabled 31 write-only 52 blanks 322 block count register (SMB_BCNT) 295 block devices, GPE 249 Block Write-Read Block Process Call (SMBBlockProcessCall) protocol 315 blocking, control methods 129 blocks, register 56 BM_RLD 74 BM_STS 70
bold AML notation 397 ASL notation 323 boot architecture flags, IA-PC 105 boot devices 36 boot resources, embedded controller 121 bootstrap ROM 236 boot-up 232 boot-up display adapter, definition 436 brackets, angle AML notation 398 ASL notation 323 Break (Break) 363 BreakPoint (BreakPoint) 363 bridges Base Bus Number (_BBN) 194 DWORD 182 flags 188 ISA bus device 242, 351 power states 31 purpose 87 QWORD 179 WORD 185 Brightness Control Levels Supported, Query List of (_BCL) 441 brightness control, LCDs 435 Brightness Level, Set (_BCM) 442 Buff (Convert Data Type to Buffer) 371 Buffer (Declare Buffer Object) 384 Buffer data type, ASL 343 Buffer field data type, ASL 345 buffers, SMBus 310 built-in display adapter, definition 436 Burst Disable Embedded Controller (BD_EC) 288 Burst Enable Embedded Controller (BE_EC) 288 Burst flags 287 burst mode 288 Bus/Device packages 351 buses power management standards 29, 417 segment locations 195 setting power states 30 button control models 60 buttons See power button; sleep button byte values, AML 407 C0 processor power state definition 23 implementation 213 C1 processor power state definition 23 implementation 215 C2 processor power state definition 23 implementation 215
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 449
C3 processor power state definition 23 implementation 215 cache controller configuration 234 caches, flushing 216, 232 capacity, battery calculating 38 low-level warnings 40 remaining 264 status information 31 CardBus mode 192 case sensitivity, ASL 341 Case statements 368 category names 6 Celsius scale 269 centenary value, RTC alarm 67 Central Processing Unit See CPU CENTURY 68 channels, DMA 167 chemistry independence 255 child bits 51, 77 child objects, ASL statements 322 child status bits 79 CLK_VAL 76 clock logic 213 CMOS protocols 354 cold boots 77, 234 cold insertion and removal 160 COM port devices, power management 32, 418, 421 command protocols, SMBus 305 command register (SMB_CMD) 295 commands, embedded controller interface 287 comments, ASL 322 compatibility memory 236 compatibility, compiler 367 Compatible ID (_CID) object 147 compiler directive terms 347 compiling, ASL to AML 45, 367 composite battery 37 Concatenate (Concatenate) 371 ConcatenateResTemplate (Concatenate Resource Templates) 372 CondRefOf (Conditional Reference Of) 372 configuration objects, device 149 configuring BIOS initialization 234 boot devices 36 modem example 36 Plug and Play devices 36 Constant Data Terms 387 context, device 14 context, system definition 18 during emergency shutdown 40 restoring 20
S4 sleeping state 229 sleep states lost in 22 contiguous RAM 236 Continue Continue Innermost Enclosing While 364 control bits functions 77 symbol 47 Control Method Battery 37, 137, 138, 260 control methods See also objects _ADR (Return the Unique ID for this Device) 441 _BCL (Query List of Brightness Control Levels Supported) 441 _BCM (Set the Brightness Level) 442 _BDN (BIOS Dock Name) 192 _BFS (Back From Sleep) 205 _DCK (Dock) 192 _DCS (Return the Status of Output Device) 443 _DDC (Return the EDID for this Device) 442 _DDS (Device Set State) 444 _DGS (Query Graphics State) 443 _DOD (Enumerate All Devices Attached to the Display Adapter) 438 _DOS (Enable/Disable Output Switching) 437 _FDM (Floppy Disk Drive Mode) 249 _GPD (Get POST Device) 440 _GTF (Get Task File) 245 _GTM (Get Timing Mode) 246 _GTS (Going To Sleep) 206 _LID (lid device) 241 _MSG (Message) 241 _OFF 198 _ON 199 _PS0 (Power State 0) 201 _PS1 (Power State 1) 201 _PS2 (Power State 2) 201 _PS3 (Power State 3) 201 _PSC (Power State Current) 202 _PSW 204 _PTS (Prepare To Sleep) 205 _REG (Region) 192 _ROM (Get Rom Data) 439 _SCP (Set Cooling Policy) 276 _SPD (Set POST Device) 440 _SST (System Status) 241 _STM (Set Timing Mode) 247 _TMP (Temperature) 267, 277 _VPO (Video POST OPtions) 441 _WAK (System Wake) 210 arguments 130 ASL, writing 322 battery 261 definition 14
Compaq/Intel/Microsoft/Phoenix/Toshiba
device identification 146 device removal 160 event handling 134 generic objects 139 initialization (_INI) 191 lid device 241 OEM-supplied 205 overview 129 power button 62, 242 Power Resource objects 198 power source 265 resources 149 sleep button 64, 242 Smart Battery Subsystem 258 system indicators 240 thermal management 274 video extensions 435 control registers 55 controllers, embedded definition 15 interface 15 conversion, data types 342 cooling modes 42, 267 cooling preferences 42, 272 Copy Copy Object 372 core logic, system events 36 CPU boot configuration 234 boot-up 232 cache flushing 216 clock logic 213 definition 14 fixed hardware control 43, 44 multiple performance state control 220 non-symmetric power state support 212 passive cooling 270 performance states 23 power management 35 processor power states 23, 211 thermal management 41 throttling 213, 217 waking operations 31 crashed systems 61 CreateBitField 349 CreateByteField 349 CreateDWordField 349 CreateField (Field) 350 CreateQWordField 350 CreateWordField 350 Critical battery state 40 Critical Temperature (_CRT) object 272, 275 critical temperature shutdowns 267, 272 Cross Device Dependency 52 CRT monitors, power management 422 C-States (processor power) 216, 218 CT phones See modems
Current Resource Settings (_CRS) objects 150 Cx states See processor power states D0-Fully On control method 201 definition 21 In Rush Current (_IRC) object 204 power resource object 202 transitioning to 202 D1 Device State control methods 201 definition 21 power resource objects 202 transitioning to 202 D2 Device State control methods 201 definition 21 power resource objects 203 transitioning to 203 D3-Off control methods 201 definition 21 transitioning to 199 dash character AML notation 398 ASL notation 323 data buffers, SMBus 310 data macros 387 Data Objects encoding, AML 400 data objects, ASL Buffer 384 data macros 387 Literal data 385 Package 384 types of 384 data register array (SMB_DATA) 295 data types ASL 342 concatenate 372 data types, resource See resource data types DataTableRegion 350 day alarm 67 day mode 28 DAY_ALRM 68 DDB Handle data type, ASL 345 DDT, Plug and Play devices 35 Debug Data Object 389 Debug Object data type, ASL 346 Debug Objects encoding, AML 407 Debug Port Specification, Microsoft 93 debugging AML code 407 requirements for 322 decimals, notation 322 Decrement (Decrement) 373 DecStr (Convert Data Type to Decimal String) 373
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 451
dedicated embedded controller interface 284 Default statements 368 defined generic objects 139 Definition Block term 347 Definition Blocks ASL code 341 definition 14 encoding 126 loading 87, 109, 365 loading from XSDT 377 unloading 368 definitions See terminology degrees, Kelvin 269 dependencies, device 52, 167 DerefOf (Dereference Of Operator) 373 description tables See tables design guides 6, 7 desktop PCs power management 28 profile system type 105 Device (Declare Bus/Device Package) 351 device and processor performance states 23, 35 Device Class Power Management specifications 29 Device data type, ASL 345 device drivers, ACPI-Aware 134 Device Name (_DDN) object 148 device power management 28, 416 modem example 32 objects 199 requirements 418 resources 30 specifications 416 standards 29 states 21, 22 status 31 Device Set State (_DSS) 444 devices audio, power management 419 class-specific objects 138 COM port, power management 421 configuration objects 149 context, definition 14 definition 14 graphics 435 identification objects 146 IDs, common 439 input, power management 424 insertion and removal objects 159 interference 52 modems, power management 426 network, power management 428 object notification 136 PC Card controllers, power management 429 Plug and Play IDs 138
power states 21, 22 resource allocation 159 resource control method 149 SMBus, declaring 307 storage, power management 431 waking system 203 Devices Attached to the Display Adapter (_DOD) 438 diagram legends 47 Differentiated Definition Block Bus/Device packages 351 definition 14 determining device power capabilities 30 modem example 33 Differentiated Description Block isolation logic 33 Differentiated System Description Table See DSDT digital modems See modems Direct Memory Access (_DMA) object 150 Disable (_DIS) object 150 Disable Output Switching (_DOS) 437 display adapters ACPI Namespace 436 control methods 435 definitions 436 requirements for 435 switching devices 445 display devices, power management 418, 422 Display Power Management Signaling Specification (DPMS) 417 Divide (Divide) 373 DMA data structure 167 DMA Descriptor macro 391 Dock (_DCK) control method 192 docking control methods 159, 192 event signals 36 objects 161 query events 78 documentation organization 10 supplemental 12 drain rates, battery 38 drivers interference 52 restoration 22 DSDT definition 14, 110 location 86 purpose 87 dual 8259 113 dual-button model 61 duty cycle 213 DVD decoders 438 DWORD 76, 181
Compaq/Intel/Microsoft/Phoenix/Toshiba
DWORD Address Space Descriptor macro 394 dynamic insertion and removal 159 dynamic objects 130 dynamic Operation Regions 359 dynamic transitioning 48 E_TMR_VAL 75 E820 mapping 316 EC_DATA (embedded controller data register) 287 EC_SC (R) (embedded controller status register) 286 EC_SC (W) (embedded controller command register) 287 ECDT 121 ECI See embedded controller interface EC-SMB-HC 292, 303 EDBA (Extended BIOS Data Area) 86 EDID control methods (_DDC) 442 EFI definition 14 GetMemoryMap interface 318 RSDP location 90 EISA ID 148 EISA systems 86 EISAID macro 387 Eject (_EJx) object 162 Eject Device List (_EDL) object 161 Ejection Dependent Device (_EJD) object 161 ejection mechanisms 159 Else/ElseIf (Else Operator) 364 embedded controller address space 51 boot resources table 121 burst mode 288 definition 15 device ID 138 device object 242 event control example 78 Global Lock 108 multiple 282 operations 83 queuing events 135 region control method 193 embedded controller interface ACPI Namespace objects 302 algorithms 291 ASL code, device 303 bi-directional communications 282 Burst flag 287 command interrupt model 290 command register (EC_SC (W)) 287 command set 287 commands, restricted 302 configurations, additional 285 data register (EC_DATA) 287 definition 15
device access 301 firmware requirements 289 Input Buffer Full (IBF) flag 286, 291 interrupt mo del 290 objects 302 OEM-definable values 291 Output Buffer Full (OBF) flag 286, 291 private 284 registers 285 SCI event (SCI_EVT) flags 286 shared 283, 285 SMBus host controller 292 SMBus notification header (OS_SMB_EVT) 289 SMBus protocol descriptions 296 SMBus registers 292 SMI event flags 287 specifications 282 status register (EC-SC (W)) 286 emergency shutdown 40 enable bits corresponding status bits 79 resetting 79 symbol 47 enable register 36 Enable/Disable Output Switch (_DOS) 437 encoding AML 399 Definition Blocks 126 object names, ASL 341 tables 88 End Dependent Functions 168 end tag 170 End-Dependent Functions Descriptor macro 391 energy conservation See power management Enterprise servers 105 Enumerate All Devices Attached to the Display Adapter (_DOD) 438 enumeration, enabling 307 errors, fatal 365 Ethernet adapters See network devices Event (Declare Event Synchronization Object) 352 Event data type, ASL 345 events alarm 67 AML code handler 46 battery 260 button 60 enable register 36 fixed feature 15 fixed handling 132 general model 36 general-purpose registers 15, 77 hardware 49 interrupt 49, 69
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 453
link status 429 OS-transparent 50 power button 62 power button override 63 programming model 130 query 78 shared 51 status register 36 synchronization objects 366 synchronization, waiting for 383 user-initiated 60 wake frame 429 exiting ACPI mode 239 Extended BIOS Data Area (EDBA) 86 extended I/O bus 138 Extended Interrupt Descriptor 188 Extended Interrupt Descriptor macro 395 Extended Root Systems Description Table See XSDT Extensible Firmware Interface See EFI External (Declare External Objects) 347 FACS definition 15 flags 108 Global Lock 108 table fields 106 FADT alarm bits 67 cache flushing 216, 232 definition 15 flags 103, 104 location 86 optional feature bits 70 Plug and Play IDs 151 processor power states 212 purpose 86 reset register location 77 SCI interrupt mapping 69 table fields 96 fans active cooling 42, 270 device operations 242 noise preferences 42 Plug and Play ID 84 thermal zone example 280 Fatal (Fatal Check) 365 fatal errors 365 features fixed 15 generic 15 generic hardware 79 Field (Declare Field Objects) 352 fields alarm 68 cache flushing 232 declaring objects 352
embedded controller boot resources 121 FACS 106 FADT 96, 151 I/O APIC 113 I/O SAPIC 116 MADT 111 NMI 115 Processor Local APIC 112 processor performance 223 reserved 88 RSDT 94 SBST 120 SMBus 309 Start Dependent Functions 167 XSDT 95 FindSetLeftBit (Find Set Left Bit) 373 FindSetRightBit (Find Set Right Bit) 374 firmware ACPI System 5 embedded controller requirements 289 OSPM controls 25 SMM functional fixed hardware implementation 44 Firmware ACPI Control Structure See FACS Fixed ACPI Description Table See FADT fixed event handling 132 fixed features definition 15 events 15 registers 15 fixed hardware definition 43 feature control bits 74 feature enable bits 72 feature status bits 70 features 53 functional implementation 44 interfaces 44 power button 61 programming model 43 register blocks 56 registers 54, 70 sleep button 64 fixed location I/O port descriptor 170 Fixed Register Resource Provider (_FIX) 151 fixed width registers 190 FixedList 322 flags Burst 287 DWORD 181 FACS 108 FADT 103, 104 I/O resource 187, 188 IA-PC boot architecture 105 Input Buffer Full (IBF) 286, 291 interrupt vector 189
Compaq/Intel/Microsoft/Phoenix/Toshiba
local APIC 112 MADT 111 memory resource 186 MPS INTI 114 Output Buffer Full (OBF) 286, 291 QWORD 177 SCI event (SCI_EVT) 286 SMI event (SMI_EVT) 287 system type 105 WORD 184 floppy controller device objects 247 Floppy Disk Drive Mode (_FDM) control method 249 Floppy Disk Enumerate (_FDE) object 247 Floppy Disk Information (_FDI) object 248 floppy disks See storage devices flushing caches 216, 232 frequency mismatch 136 FromBCD (Convert from BCD) 374 functional device configuration 234 functional fixed hardware 44 functions End Dependent 168 Start Dependent 167 G0 Working state behavior during 226 definition 19 properties 20 transitioning to 48 transitioning to Sleeping state 231 transitioning to Soft-Off 231 G1 Sleeping state definition 19 properties 20 transitioning to 226 G2 Soft Off definition 19 properties 20 transitioning to 48 G3 Mechanical Off definition 19 properties 20 transitioning from 48 transitioning to 27 game pads See input devices GAS See Generic Address Structure GBL_EN 73 GBL_RLS 74 GBL_STS 71 general event model 36 general-purpose event registers addresses 58, 77 blocks 59, 79 definition 15 event 0 79 event 0 enable 80
event 0 status 80 event 1 80 event 1 enable 81 event 1 status 80 grouping 57 wake events, role in 135 general-purpose events handling 133 queuing for execution 134 wake 134 generic address space, SMBus 305 Generic Address Structure (GAS) 89 generic events example 78 top-level 78 generic feature, definition 15 generic hardware definition 43 features 53, 79 power button control 62 programming model 45 registers 45, 54, 77 sleep button control 64 generic ISA bus device 242 generic objects 139 generic register descriptor 190 Generic Register Descriptor macro 396 Get POST Device (_GPD) 440 Get Power Status 31 Get ROM Data (_ROM) 439 Get Task File (_GTF) control method 245 Get Timing Mode (_GTM) control method 246 GetMemoryMap 318 Global Lock 108 Global Lock (_GLK) object 196 Global Lock Mutex 145 global standby timer 51 global system interrupts 113, 119 global system states definition 16, 19 terminology 19 transitioning 26, 49 goals ACPI 1 OSPM 1 power management 2 Going To Sleep (_GTS) control method 206 GPE block devices 139, 249 control method 134 grammar AML 398 ASL 322 grammar notation AML 397 ASL 322
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 455
graphics devices, requirements for 435 Graphics State, Query (_DGS) 443 Green PCs, power management for 28 groupings, register See register groupings guides, design 6, 7 hardware See also fixed hardware; generic hardware ACPI interfaces 4 ACPI specifications 43 definition 13 events 49 features 53 fixed 43 generic 45 ignored bits 52 interfaces 5 legacy 51 legacy vs. ACPI 3 OEM implementation 3 OS-independent 44, 45 OSPM model 48 register definitions 45 registers 54 reserved bits 51 value-added 45 hardware ID (_HID) object 148, 257 headers, long 95 headers, table 85, 92 heat management See thermal management hexadecimals, notation 322 HexStr (Convert Data Typ 374 holes, compatibility 236 home PCs, power management for 28 host controller objects, SMBus 307 hot insertion and removal 160, 162 Hot Plug Memory Table Specification, Microsoft 93 Hot Plug Parameters (_HPP) object 153 Hot Temperature (_HOT) object 275 hung systems 61 hysteresis 268 I/O APIC _MAT (Multiple APIC Table Entry 155 definition 16 Global System Interrupts 120 mixed addresses, preventing 117 structure 113 I/O operations, lazy 2 I/O Port Descriptor macros 391 I/O port descriptors 169 I/O resource flag 187, 188 I/O SAPIC definition 16 mixed addresses, preventing 117 Platform Interrupt Source structure 117 structure 116
I/O space 51, 87 IA (Intel Architecture) specifications 12 IA processors 216 IA-32 systems 44 IA-PC boot architecture flags 105 definition 16 interrupt models 113 memory map system 316 memory mapping 235 RSDP location 90 ID, Compatible (_CID object) 147 IDE controller device 243 drives 46 IDE devices See storage devices identification objects, device 146 idle loops, CPU 35 idle timers, legacy 51 IDs, Plug and Play 138, 146 If (If Operator) 365 ignored bits definition 16, 52 PM1 Status register 72 implementation requirements OEM 3 OS 10 OSPM 9 In Rush Current (_IRC) object 204 Include (Include Another ASL File) 347 Increment (Increment) 374 independence, OS ACPI 3 functional fixed hardware 44 generic hardware 45 Independent Hardware Vendors (IHVs) power management standards 29 Index (Index) 374 Index with Buffers 375 Index with Packages 375 Index with Strings 376 IndexField (Declare Index/Data Fields) 356 indicators, system 240 initialization BIOS 233 boot-up 232 OS 238 initialization object (_INI) 191 Input Buffer Full (IBF) flag 286, 291 input devices, power management 418, 424 Input/Output See I/O insertion and removal objects 159 insertion and removal, batteries 260 Int (Convert Data Type to Integer) 376 INT 15 mapping 316 Integer data type, ASL 343
Compaq/Intel/Microsoft/Phoenix/Toshiba
Integers 386 Intel Architecture specifications 12 Intel Architecture-Personal Computer See IA PC interdependent resources 167 interfaces ACPI 4 battery 37 BIOS, legacy 24 Control Method Battery 261 design guides 6 EC-SMB-HC 292 embedded controller 15 extensible firmware (EFI) 14 fixed hardware 44 hardware 5 mapping 316 sharing protocols 285 SMBus 18, 305 interference, device 52 Interrupt Descriptor macro, Extended 395 interrupt events logic 49 SCI 69 shareable 69 SMI 69 Interrupt Source Overrides 113 interrupt sources, non-maskable (NMIs) 115 interrupt status bits 51 interrupts embedded controller interface 290 Extended Interrupt Descriptor 188 models 110, 113, 119 Platform Interrupt Source structure 117 PMIs 117 invocation, control methods 129 IRQ Descriptor macro, ASL 390 IRQs data structure 165 mapping 113, 115 modem configuration example 36 PCI routing 158 ISA bus device 138, 242 Device Objects code 351 interrupt sources 113 old cards 169 ISDN Terminal Adapters See modems isolation logic 33 italics, ASL notation 323 joysticks See input devices Kelvin scale 269 kernel 4 key, logic diagrams 47 keyboard controllers 282 keyboards See input devices
LAN, waking from 28 LAnd (Logical And) 376 large resource data type 171 latency acceptable 26 global power states 20 processor power states 211 lazy I/O operations 2 LCD panels brightness control 435 power management 422 legacy BIOS interfaces 24 legacy hardware BIOS specification 12 boot flags 105 converting to fixed 43 definition 16 interrupt handlers 69 support 3 legacy OS, definition 16 legacy systems definition 16 memory mapping 235 power button functions 27 power management 50 power state transitions 48 switching devices out of 192 transitioning to ACPI 69 legends, logic diagrams 47 LEqual (Logical Equal) 376 LGreater (Logical Greater) 376 LGreaterEqual (Logical Greater Than Or Equal) 377 lid device 139 lid status notification values 138 lid switch 81 life, battery 38 link status events 429 LINT 115 Literal Data Terms 385 LLess (Logical Less) 377 LLessEqual (Logical Less Than Or Equal) 377 LNot (Logical Not) 377 Load (Load Differentiated Definition Block) 365 loading Definition Blocks 87, 109, 365, 377 LoadTable (Load Definition Block From XSDT) 377 local APIC, definition 16 local area networks See LAN Local Objects encoding, AML 407 Localx (Method Local Data Objects 389 Lock (_LCK) object 163 Lock, Global 108 logic fixed power button 61
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 457
generic hardware event example 78 lid switch 81 sleep button 64 sleeping/wake control 66 logic diagram legends 47 Long Vendor-Defined Descriptor macros 392 LOr (Logical Or) 378 low-level warnings, battery 39 LPT ports 34 macros, ASL 24-bit Memory Descriptor 392 32-bit Fixed Memory Descriptor 393 32-bit Memory Descriptor 392 coding 129 data 387 DMA Descriptor 391 DWORD 394 EISAID 387 End-Dependent Functions Descriptor 391 Extended Interrupt Descriptor 395 Fixed I/O Port Descriptor 392 Generic Register Descriptor 396 I/O Port Descriptor 391 IRQ Descriptor 390 QWORD 393 Resource Descriptors 390 Resource Template 388 Start Dependent Function Descriptor 391 Unicode 389 Vendor-Defined Descriptors 392 WORD 395 MADT _MAT object 155 definition 16 flags 111 interrupt models 110 table fields 111 Magic Packet wake 428 management See power management; thermal management mapping E820 316 EFI GetMemoryMap 318 Global System Interrupts 120 INT 15 316 interfaces for 316 IRQs 113, 115 PCI interrupt pins 157 physical memory 235 Query System Address Map function 321 samples 320 Match (Find Object Match) 378 MCA systems 86 Mechanical Off definition 19 properties 20
transitioning from 48 transitioning to 27 memory BIOS initialization 235 controller configuration 234 descriptor macros 392, 393 devices 252 map interfaces 316 map sample 320 NVS 235 physical mapping 235 resource flag 186, 187 memory device 139 memory range descriptors 24-Bit 171 32-Bit 173 32-Bit Fixed Location 175 purpose 172 memory space 51 Message (_MSG) control method 241 Method (Declare Control Method) 357 Method data type, ASL 345 methods, control See control methods mice See input devices Microsoft Device Class Power Management specifications 29 Mid (Retrieve Portion of Buffer or String 379 mobile PCs lid switch 81 power management 27 profile system type 105 Mod (Modulo) 380 modems configuration example 36 power management 418, 426 power management example 32 modifiers ASL names 341 namespace 361 Module Device 139, 250 MON-ALRM 68 monitors See display devices month alarm 67 motherboard device configurations ACPI goals 1 controlled by OSPM 24 modems 427 MPS INTI flags 114 Multiple APIC Description Table See MADT Multiple APIC Table Entry (_MAT) object 155 multiple Smart Battery Subsystem 259 Multiply (Multiply) 380 multiprocessor PCs performance control 220 power management for 28 mutex
Compaq/Intel/Microsoft/Phoenix/Toshiba
acquiring 371 Global Lock 145 release synchronization objects 366 Mutex (Declare Synchronization/Mutex Object) 358 Mutex data type, ASL 345 Name (Declare Named Object) 361 Name Objects encoding, AML 399 Named Object terms 348 Named Objects encoding, AML 401 names, ASL 324 names, object 16 Namespace See ACPI Namespace naming conventions 123 NAnd (Bitwise Nand) 380 nested packages 375 network devices, power management 418, 428 night mode 28 NMIs 115 noise, active cooling 42 non-linear address spaces 305 Non-Maskable Interrupt Sources (NMIs) 115 non-visible states, device power 21 Non-Volatile Sleep state, definition 20 Non-Volatile Sleeping memory (NVS) 235 Noop Code (No Operation) 365 NOr (Bitwise Nor) 380 Not (Not) 380 notation AML 397 ASL 322 numeric constants 322 register bits 47 Nothing 322 notification battery removal 260 embedded controller interface 289 power button control 62 Smart Battery status 255 temperature changes 269 Notify (Notify) 366 numeric constants, notation 322 NVS files checking validity 237 restoring from 20 NVS memory 235 object name, definition 16 Object Reference data type, ASL 346 object terms, ASL 347 objects See also control methods _ACx (Active Cooling) 267, 274 _ADR (Address) 146 _ALx (Active List) 275 _BBN (Base Bus Number) 194 _BIF (Battery Information) 261 _BST (Battery Status) 263
_BTP (Battery Trip Point) 264 _CID (Compatible ID) 147 _CRS (Current Resource Settings) 150 _CRT (Critical Temperature) 272, 275 _CST (C States) 218 _DDN (Device Name 148 _DIS (Disable) 150 _DMA (Direct Memory Access) 150 _EDL (Eject Device List) 161 _EJD (Ejection Dependent Device) 161 _EJx (Eject) 162 _FDE (Floppy Disk Enumerate) 247 _FDI (Floppy DIsk Information) 248 _FIX (Fixed Register Resource Provider) 151 _GLK (Global Lock) 196 _HID (hardware ID) 148, 257 _HOT (Hot Temperature) 275 _HPP (Hot Plug Parameters) 153 _INI (Init) 191 _IRC (In Rush Current) 204 _LCK (Lock) 163 _MAT (Multiple APIC Table Entry) 155 _PCL (Power Consumer List) 265 _PCT (Performance Control) 221 _PPC (Performance Present Capabilities) 223 _PR0 (Power Resources for D0) 202 _PR1 (Power Resources for D1) 202 _PR2 (Power Resources for D2) 203 _PRS (Possible Resource Settings) 156 _PRT (PCI Routing Table) 157 _PRW (Power Resources for Wake) 135, 203 _PSL (Passive List) 275 _PSR (Power Source) 265 _PSS (Performance Supported States) 222 _PSV (Passive) 267, 276 _PTC (Processor Throttling Control) 217 _PXM (Proximity) 159 _RMV (Remove) 163 _S1D 204 _S2D 204 _S3D 204 _S4D 205 _SBS (Smart Battery Subsystem) 257 _SEG (Segment) 195 _SRS (Set Resource Settings) 159 _STA (Status) 164, 199 _STR (String) 148 _SUN (Slot User Number) 148 _TC1 (Thermal Constant 1) 276 _TC2 (Thermal Constant 2) 276 _TSP (Thermal Sampling Period) 277 _TZD (Thermal Zone Devices) 277 _TZP (Thermal Zone Polling) 277 _UID (Unique ID) 148 ASL encoding 341 ASL statements 322
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 459
ASL, declaring 128 control methods 129 data 384 definition 16 device configuration 149 device identification 146 device insertion and removal 159 device power resource 202 device-specific 240 dynamic 130 EC-SMB-HC 303 embedded controller interface 302 floppy controller 247 generic 139 global scope 126 initialization 191 Module Device 250 names, reserved 341 Notify operator 136 OS-defined 145 Power Resource 197 processor 217 revision data 145 Smart Battery 257 SMBus host controller 307 static 130 thermal management 274 unnamed 127 ObjectType 322, 381 OEM implementation 3 OEM-supplied control methods 205 off See Mechanical Off; Soft-Off OFF 198 ON 199 One (Constant One Object) 387 Ones (Constant Ones Object) 387 opcodes Type 1, AML 403 Type 1, ASL 362 Type 2, AML 404 Type 2, ASL 369 Operating System See OS Operating System-directed Powe r Management See OSPM Operation Region data type, ASL 345 Operation Region Field Unit data type, ASL 344 operation regions SMBus 305, 308 OperationRegion term access types 353 Declare Operation Region 358 operators, ASL 342 OpRegion 129 Or (Bit -wis e Or) 381 organization, document 10 original equipment manufacturer See OEM
OS AML support, required 322 boot flags 105 compatibility requirements 10 defined object names 145 DefinitionBlock compiling 347 device power management 30 drivers, embedded controller interface 282 functional fixed hardware implementation 44 independent generic hardware 45 legacy hardware interaction 3 loading 237 name object 145 policy owner, device power management 416 power management 2 Query System Address Map 321 S4 Sleeping state transition 230 transparent events 50 OSPM caches, flushing 232 cooling policy changes 268 cooling preferences 42 definition 17 device insertion and removal 159 event handlers 51 exclusive controls 25 fixed hardware access 43 fixed hardware registers 70 functions 24 general-event register access 79 generic hardware model 46 Get Power Status 31 goals 1 hardware model 48 implementation requirements 9 passive cooling 270 performance states 35 power management vs. performance 197 power state control 25 Real Time Clock Alarm (RTC) 67 resetting system 77 Set Power State operation 30 SMBus registration 307 thermal management 41, 267 transitioning to sleeping states 227 transitioning working to sleeping states 231 transitioning working to soft-off state 231 Output Buffer Full (OBF) flag 286, 291 output devices control methods 443 definition 436 switching 445 types of 438 override, power button 63 P_BLK 76 P_LVL2 76
Compaq/Intel/Microsoft/Phoenix/Toshiba
P_LVL3 77 P0 performance state, definition 23 P1 performance state, definition 23 Package (Declare Package Object) 384 Package data type, ASL 344 packages definition 17 length 126 length encoding, AML 400 nested 375 packet error checking (PEC) 306 parameters, ASL 346 parent bits 51, 77 parent objects, ASL statements 322 parentheses, AML notation 398 Passive (_PSV) object 267, 276 passive cooling definition 42, 267 preferences 42, 272 processor clock throttling 270 threshold values 272 Passive List (_PSL) object 275 PC Card controllers, power management 418, 429 PC keyboard controllers 282 PCCARD 417 PCI BAR target operations 355 bus number 194 buses, address space translation 87 Device Objects code 351 device power management 417 interrupt pins 157 IRQ routing 158 power management 417 PCI configuration space 43, 51 PCI Interrupt Link device 139 PCI Routing Table (_PRT) object 157 PCISIG 417 PCMCIA 417 PEC (packet error checking) 293, 306 Performance Control (_PCT) object 221 Performance Present Capabilities (_PPC) object 223 performance states definitions 23 device 35 Performance Supported States (_PSS) object 222 performance, energy conservation vs. 42, 197 Persistent System Description Table (PSDT) 110 phones, answering modem example 32 power management 2 waking computer 34
PIC method 145 pins general event model 37 GPE 79 platform implementation 5 independence 3 Platform Interrupt Source structure 117 Platform Management Interrupts (PMIs) 117 Plug and Play devices ACPI control 35 IDs 138, 146 large resource items 171 modem example 36 resource control method 149 small resource items 165 specifications 12 PM timer bits 75 function 51 idle time, determining 35 operations 60 register address 57 register blocks 59 PM1 Control registers addresses 57 bits 74 blocks 58 grouping 56, 73 PM1 Enable registers 72 PM1 Event registers addresses 57 blocks 58 grouping 56, 70 PM1 Status registers 70 PM2 Control registers addresses 57 bits 75 blocks 58 PM2 Controller register grouping 57 PMIs 117 Pn performance state, definition 23 PNPBIOS 24 Polarity flags 114 policy owner 416 polling, thermal 269, 270 port descriptors, I/O 169 portability See independence, OS Possible Resource Settings (_PRS) object 156 POST Device control methods 440 power button ASL code example 63 control methods 62, 242 definition 17 device ID 139 dual-button model 61
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 461
fixed hardware 61 functions 27 object notification values 137 override 63, 66 single-button model 61 Power Consumer List (_PCL) object 265 power consumption device and processor performance states 23 device power states 22 global power states 20 power loss Mechanical Off 48 S4 Non-Volatile Sleep state 20 power management audio devices 419 BIOS 2 buses 417 COM port devices 421 cooling, relationship to 42 definition 17 desktop PCs 28 device 28, 416, 418 device objects 199 display devices 422 display standards 417 goals 1, 2 input devices 424 lazy I/O operations 2 legacy 50 mobile PCs 27 modem devices 426 modem example 32 multiprocessor PCs 28 network devices 428 PC Card controllers 429 PCI 417 PCMCIA 417 performance states 35 performance vs. energy conservation 42, 197 Plug and Play devices 36 preferred system types 105 processor 35 servers 28 setting device power states 30 standards 29 storage devices 431 power management (PM) timer bits 75 function 51 idle time, determining 35 operations 60 register address 57 register blocks 59 Power Resource data type, ASL 345 power resources battery management 253
child objects 198 definition 17 device objects 202 devices, turning off 31 Differentiated Definition Block 30 isolation logic 33 objects 197 shared 34 wake system object 203 Power Source (_PSR) object 265 power sources AC adapter 265 definit ion 17 object notification values 137 power states control methods 201 controlled by OSPM 25 device 21 global 19 non-symmetric processor 212 objects 201 processor 23, 211 sleeping 22 transitioning 48 user-visible 26 PowerResource (Declare Power Resource) 359 preferences, user performance vs. energy conservation 42, 272 power button 27 preferred PM profile system 105 Prepare to Sleep (_PTS) control method 205 private embedded controller interface 284 Process Call (SMBProcessCall) protocol 314 processor See CPU Processor (Declare Processor) 360 processor and device performance states 23 processor control block 59 processor control registers addresses 57 bits 76 Processor data type, ASL 345 processor device notification values 138 Processor Local APIC 112, 115 Processor Local SAPIC 117 processor LVL2 register 76, 212 processor LVL3 register 77, 212 processor objects 217 processor register block 76 Processor Throttling Control (_PTC) object 217 programming models events 130 feature summary 53 fixed 43 generic 45 protocol register (SMB_PRTCL) 293 protocols
Compaq/Intel/Microsoft/Phoenix/Toshiba
BARs (Base Address Registers) 355 CMOS 354 SMBus 296, 305, 311 Proximity (_PXM) object 159 PSDT 110 pseudocode language See AML pulsed interrupts 290 PWRBTN_EN 73 PWRBTN_STS 71 Query Embedded Controller (QR_EC) 289 query events 78 Query System Address Map function 321 query value, definition 47 quotes AML notation 397 ASL notation 323 QWORD 177 QWORD Address Space Descriptor macro 393 Read Embedded Controller (RD_EC) 287 Read/Write Block (SMBBlock) protocol 314 Read/Write Byte (SMBByte) protocol 313 Read/Write Quick (SMBQuick) protocol 311 Read/Write Word (SMBWord) protocol 313 Real Time Clock Alarm (RTC) 67 reclaim memory 235 RefOf (Reference Of) 382 Region (_REG) control method 192 register bits, notation 47 register blocks 56 register definitions, hardware 44 register groupings definition 17, 55 list of 56 registers BARs (Base Address Registers) 355 control 55 EC-SMB-HC 292 embedded controller interface 285 enable 36 fixed feature 15 fixed hardware 70 general-purpose event 15 reset 77 SMB-HC 300 status 36 status/enable 55 virtual 306, 310 related device interference 52 Release (Release a Mutex Synchronization Object) 366 Release terms 358 Remaining Battery Percentage 38, 264 removal objects 159 removal, batteries 260 Remove (_RMV) object 163 requirements, implementation
OS 10 OSPM 9 reserved bits definition 17 hardware 51 PM1 Control registers 74 PM1 Enable registers 73 PM1 Status register 71, 72 software requirements 88 reserved object names 341 reserved SMBus protocol values 305 Reset (Reset an Event Synchronization Object) 366 reset register 77 resource data types Address Space Descriptors 176 control methods 164 DMA 167 End Dependent Functions 168 end tag 170 IRQ 165 large 171 memory range descriptors 171 small 164 Start Dependent Functions 167 vendor defined 170, 173 resource descriptor macros 390 Resource Template macro 388 resources allocation 159 control method 149 interdependencies 167 resources, power See power resources restoring system context 20, 229 results, storing 346 Return (Return) 366 Revision (Constant Revision Object) 387 revision data object 145 RISC processors 176 RISC systems 27 ROM control methods 439 Root System Description Pointer See RSDP Root System Description Table See RSDT RSDP definition 17 location 90 table structure 91 RSDT definition 17 location 86 table fields 94 RTC (Real Time Clock Alarm) 67 RTC/CMOS protocols 354 RTC_EN 73 RTC_STS 72 S0 State (Working) 208
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 463
S1 Sleeping state _S1D object 204 behavior during 208 definition 22 implementation 228 transitioning 207 waking using RTC 67 S2 Sleeping state _S2D object 204 behavior during 208 definition 22 implementation 228 transitioning 207 waking using RTC 67 S3 Sleeping state _S3D object 204 behavior during 209 definition 22 implementation 229 transitioning 207 waking using RTC 67 S4 Sleeping state _S4D object 205 behavior during 209 definition 20, 22 implementation 229 low-level battery 40 waking using RTC 67 S5 Soft-Off behavior during 210, 230 definition 19, 22 properties 20 transitioning to 231 SAPIC definition 18 I/O 16, 116 local 16 NMI 115 Processor Local 117 support 110 saving system context during emergency shutdown 40 S4 Non-Volatile Sleep state 20, 229 SBST 121 SCI battery status information 31 definition 18 embedded controller events 290 enable bits 31 event flags (SCI_EVT) 286 interrupt handlers 50, 69 SCI_EN 69, 70, 74 Scope (Declare Name Scope) 362 SCSI, power management 417 Secondary System Description Table See SSDT Segment (_SEG) object 195
Send/Receive Byte (SMBSendReceive) protocol 312 separators, ASL 322 Serialized methods 358 server machines, power management 28 Set Cooling Policy (SCP) control method 276 Set POST Device (_SPD) 440 Set Power State 30 Set Resource Settings (_SRS) object 159 Set the Brightness Level (_BCM) 442 Set Timing Mode (_STM) control method 247 settings, user performance vs. energy conservation 42, 272 power button 27 shareable interrupts 69 shared interface, embedded controller 283, 285 ShiftLeft (Shift Left) 382 ShiftRight (Shift Right) 382 Short Vendor-Defined Descriptor macro 392 shutdown, emergency 40, 272 shutting down See Mechanical Off; Soft-Off Signal (Signal a Synchronization Event) 366 signatures collisions, avoiding 93 interpreting 86, 94 values, storing 88 Simple Boot Flag Specification, Microsoft 93 single quotes AML notation 397 ASL notation 323 single-button model 61 SizeOf (SizeOf Data Object) 382 slave addresses, SMBus 254, 305 Sleep (Sleep) 366 sleep button ASL code example 65 control methods 64, 242 definition 17 device ID 139 fixed hardware 64 object notification values 137 support 64 Sleeping states behavior during 208 button logic 64 control methods 205 definitions 19, 22 entering 227 logic controlling 66 non-volatile 20 objects 204 packages, system state 206 power consumption 20 power loss 20 properties 20 transitioning 26, 206
Compaq/Intel/Microsoft/Phoenix/Toshiba
transitioning to 225, 226 user settings 27 waking using RTC 67 Slot User Number (_SUN) object 148 SLP_EN 74, 227 SLP_EN field 66 SLP_TYPx 74, 227 SLP_TYPx field 55, 66 SLPBTN_EN 73 SLPBTN_STS 71 small resource data type 164 Smart Batteries control methods 258 definition 18 device ID 139 multiple battery subsystem 259 objects 257 single battery subsystem 258 SMBus data buffers 311 SMBus devices 308 specifications 12 status notification 255 subsystem 37, 253 supported 31 table 18 table formats 120 Smart Battery Charger functions 255 status notification 256 Smart Battery Selector 256 Smart Battery System Manager functions 255 status notification 256 SMB-HC 254, 259, 300 SMBus address register (SMB_ADDR) 294 address space 305 alarm address register (SMB_ALRM_ADDR) 295 alarm data register (SMB_ALRM_DATA) 296 block count register (SMB_BCNT) 295 Block Write-Read Block Process Call (SMBBlockProcessCall) protocol 315 command register (SMB_CMD) 295 commands, restricted 302 data buffers 310 data register array (SMB_DATA) 295 definition 18 device access, embedded controller interface 301 device enumeration, enabling 307 device ID 139 embedded controller interface 292 encoding, bit 306 fields, declaring 309
generic hardware addresses 51 host controller notification header (OS_SMB_EVT) 289 host controller objects, declaring 307 interface 18 operation regions 305, 308 PEC (packet error checking) 306 Process Call (SMBProcessCall) protocol 314 protocol register (SMB_PRTCL) 293 protocols 296, 305, 311 Read/Write Block (SMBBlock) protocol 314 Read/Write Byte (SMBByte) protocol 313 Read/Write Quick (SMBQuick) 311 Read/Write Word (SMBWord) protocol 313 Send/Receive Byte (SMBSendReceive) protocol 312 slave addresses 254, 305 specifications 12 status codes 306 status register (SMB_STS) 292 transactions 306 virtual registers 306 SMI definition 18 embedded controller firmware 289 event flags (SMI_EVT) 287 interrupt events 50, 69 SMM firmware 44 Soft-Off behavior during 210, 230 definition 19, 22 properties 20 transitioning crashed systems to 61 transitioning to 48, 231 SOHO servers 105 sources, power See power sources SSDT 17, 110 Stall (Stall for a Short Time) 367 standards device power states 29 power management 29 Start Dependent functions 167 Start-Dependent Function Descriptor macro 391 statements ASL 322 Case 368 Default 368 ElseIf 364 If 364 Power Resource 197 Processor 217 Switch 368 states See power states static objects 130 Status (_STA) 199 Status (_STA) object 164
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 465
status bits corresponding enable bits 79 functions 77 symbol 47 status codes, SMBus 306 status notification, Smart Battery 255 status register 36 status register (SMB_STS) 292 status, battery 31 status/enable registers 55 sticky status bit, definition 47 storage devices, power management 418, 431 Store (Store) 382 storing results, ASL operators 346 Streamlined Advanced Programmable Interrupt Controller See SAPIC String (_STR) object 148 String (Create ASCII String From Buffer) 383 String data type, ASL 343 strings, ASL 322, 386 Subtract (Subtract) 383 supplemental documentation 12 surprise-style removal 159, 163 Switch Select Code To Execute Based O 367 Switch statements 368 switching, output devices 445 Sx states See Sleeping states symbols, logic diagrams 47 syntax ASL 322 OperationRegion 308 Power Resource statements 197 system context definition 18 during emergency shutdown 40 restoring 20 S4 Sleeping state 229 sleep states lost in 22 System Control Interrupt See SCI system description tables See tables system events, general model 36 system indicators 240 System Management Bus See SMBus System Management Interrupt See SMI System Management Mode See SMM system memory space 51 system states, global See global system states System Status (_SST) control method 241 System Wake (_WAK) control method 210 tables address format 89 compatibility 89 DSDT 110 embedded controller boot resources 121 encoding format 88 FACS 106
FADT 96 headers 85, 92 MADT 111 overview 85 RSDP 91 RSDT 94 SBST (Smart Battery Description) 120 signatures 93 SSDT 110 XSDT 95 Temperature (_TMP) control method 267, 277 temperature changes, detecting 268 temperature management See thermal management Term Objects encoding, AML 401 terminology design guides 6, 7 device power states 21 general 13 global system states 19 performance states 23 processor power states 23 sleeping states 22 terms AML 397 ASL 324, 346 ASL notation 323 Thermal Constant 1 (_TC1) object 276 Thermal Constant 2 (_TC2) object 276 thermal management control methods 274 energy conservation, optimizing 42 notification of temperature changes 269 objects 274 OSPM controlled 267 overview 41 performance, optimizing 42 polling 269, 270 temperature changes, detecting 268 threshold settings, dynamically changing 268 trip points 269 Thermal Sampling Period (_TSP) object 277 thermal states, definition 18 Thermal Zone data type, ASL 345 Thermal Zone Devices (_TZD) object 277 Thermal Zone Polling (_TZP) object 277 thermal zones basic configuration 278 examples 278 mobile PC example 41 multiple 42 multiple-speed fan example 280 object notification values 137 object requirements 278 ThermalZone (Declare Thermal Zone) 360
Compaq/Intel/Microsoft/Phoenix/Toshiba
thirty-two bit fixed location memory range descriptor 175 thirty-two bit memory range descriptor 173 throttling 213, 217 THT_EN 76 timers global standby 51 idle 51 power management (PM) 51, 60 TMR- field 60 TMR_EN 73 TMR_STS 70 TMR_VAL 75 ToBCD (Convert to BCD) 383 token ring adapters See network devices top of memory 236 transactions, SMBus data buffers 310 status codes 306 transitioning crashed systems 61 device power states 417 Legacy mode to ACPI 69 power states 26, 48 waking and sleeping 225 working to sleeping states 231 working to soft-off states 231 transparent events 50 transparent switching, device power states 22 trap monitors 51 Trigger Mode flags 114 trip points, thermal 269 turning off See Mechanical Off; Soft-Off; transitioning TVs 438 twenty-four bit memory range descriptor 171 Type 1 Opcodes AML encoding 403 ASL 362 Type 2 Opcodes AML encoding 404 ASL 362, 369 UARTs, power management 421 Unicode macro 389 Uninitialzed data type, ASL 342 Unique ID (_UID) object 148 Unload (Unload Differentiated Definition Block) 368 unnamed objects 127 unrelated device interference 52 upper case, ASL names 341 USB, power management 417, 418 user preferences performance vs. energy conservation 42, 272 power button 27 User Terms 384
user-visible power states 26 value-added hardware enabling OSPM 45 registers 77 Variable List 322 VCR-style ejection mechanism 159 vendor defined descriptor macros 392 vendor defined resource data types 170, 173 VESA specifications 417 VGA 438, 440 video controllers, power management 422 Video Electronics Standards Associations (VESA) 417 video extensions, requirements for 435 Video POST Options (_VPO) 441 virtual data objects 389 virtual registers 306, 310 visible states global system 19 power 26 Wait (Wait for a Synchronization Event) 383 WAK_STS (Wake Status) 66, 72 wake frame events 429 waking _BFS (Back From Sleep) control method 205 _WAK control method 210 audio devices 420 COM ports 421 device power resource object (_PRW) 203 devices 419 disabling system-waking devices 204 display devices 424 initialization 232 input devices 425 latency time 26 lid switch 81 logic controlling 66 modem devices 427 modem example 32, 34 network devices 429 OS operations 31 overview 225 PC Card controllers 431 Real Time Clock Alarm (RTC) 67 resetting lost enable bits 79 storage devices 434 warm insertion and removal 160, 162 warnings, battery 39 WBINVD 216, 232 web sites Intel Architecture 12 Microsoft 12 PCISIG 417 PCMCIA 417 Smart Battery System 12 SMBus specification 305
Compaq/Intel/Microsoft/Phoenix/Toshiba
Index 467
USB-IF 418 While (While) 369 WORD 184 WORD Address Descriptor macro 395 Working state behavior during 226 definition 19 properties 20 transitioning to 48 transitioning to Sleeping state 231 transitioning to Soft-Off 231 workstations 105 Write Embedded Controller (WR_EC) 288
write-only bits control 47 definition 52 XOr (Bitwise Xor) 384 XSDT definition 18 loading Definition Block 377 location 86 table fields 95 Zero (Constant Zero Object) 387 Zero, One, Ones data type, ASL 346 zones, thermal See thermal zones
Compaq/Intel/Microsoft/Phoenix/Toshiba