ACPI in Linux Architecture, Advances, and Challenges
Total Page:16
File Type:pdf, Size:1020Kb
ACPI in Linux Architecture, Advances, and Challenges Len Brown Anil Keshavamurthy David Shaohua Li Robert Moore Venkatesh Pallipadi Luming Yu Intel Open Source Technology Center {len.brown, anil.s.keshavamurthy, shaohua.li}@intel.com {robert.moore, venkatesh.pallipadi, luming.yu}@intel.com Abstract providing major portions of an ACPI imple- mentation in OS-independent ACPI modules ACPI (Advanced Configuration and Power In- that can be integrated into any operating sys- terface) is an open industry specification es- tem. tablishing industry-standard interfaces for OS- The ACPICA software can be hosted on any directed configuration and power management operating system by writing a small and rel- on laptops, desktops, and servers. atively simple OS Services Layer (OSL) be- ACPI enables new power management technol- tween the ACPI subsystem and the host oper- ogy to evolve independently in operating sys- ating system. tems and hardware while ensuring that they continue to work together. The ACPICA source code is dual-licensed such that Linux can share it with other operating sys- This paper starts with an overview of the tems, such as FreeBSD. ACPICA architecture. Next a section describes the implementation architecture in Linux. 1.1 ACPICA Overview Later sections detail recent advances and cur- rent challenges in Linux/ACPI processor power ACPICA defines and implements a group of management, CPU and memory hot-plug, software components that together create an legacy plug-and-play configuration, and hot- implementation of the ACPI specification. A keys. major goal of the architecture is to isolate all operating system dependencies to a relatively small translation or conversion layer (the OS 1 ACPI Component Architecture Services Layer) so that the bulk of the ACPICA code is independent of any individual operat- The purpose of ACPICA, the ACPI Component ing system. Therefore, hosting the ACPICA Architecture, is to simplify ACPI implementa- code on new operating systems requires no tions for operating system vendors (OSVs) by source code modifications within the CA code • 51 • 52 • ACPI in Linux itself. The components of the architecture in- clude (from the top down): Operating System • A user interface to the power management and configuration features. • A power management and power policy ACPI Subsystem component (OSPM). 1 OS Services Layer • A configuration management component. • ACPI-related device drivers (for example, ACPI Core Subsystem drivers for the Embedded Controller, SM- Bus, Smart Battery, and Control Method Battery). • An ACPI Core Subsystem component that provides the fundamental ACPI services (such as the AML2 interpreter and names- Figure 1: The ACPI Subsystem Architecture pace3 management). • An OS Services Layer for each host oper- The OS Services Layer is the only component ating system. of the ACPICA that contains code that is spe- cific to a host operating system. Figure 1 illus- 1.2 The ACPI Subsystem trates the ACPI Subsystem is composed of the OSL and the Core. The ACPI Subsystem implements the low level The ACPI Core Subsystem supplies the ma- or fundamental aspects of the ACPI specifica- jor building blocks or subcomponents that are tion. It includes an AML parser/interpreter, required for all ACPI implementations includ- ACPI namespace management, ACPI table and ing an AML interpreter, a namespace man- device support, and event handling. Since the ager, ACPI event and resource management, ACPICA core provides low-level system ser- and ACPI hardware support. vices, it also requires low-level operating sys- tem services such as memory management, One of the goals of the Core Subsystem is to synchronization, scheduling, and I/O. To allow provide an abstraction level high enough such the Core Subsystem to easily interface to any that the host OS does not need to understand operating system that provides such services, or know about the very low-level ACPI details. the OSL translates OS requests into the native For example, all AML code is hidden from the calls provided by the host operating system. OSL and host operating system. Also, the de- tails of the ACPI hardware are abstracted to 1 OSPM, Operating System directed Power Manage- higher-level software interfaces. ment. 2AML, ACPI Machine Language exported by the BIOS in ACPI tables, interpreted by the OS. The Core Subsystem implementation makes no 3The ACPI namespace tracks devices, objects, and assumptions about the host operating system methods accessed by the interpreter. or environment. The only way it can request 2005 Linux Symposium • 53 Resource Event Host Operating System Management Management Namespace ACPI Table ACPI H/W ACPI Subsystem Management Management Management OS Services Layer Host/OS ACPI/OS AML Interpreter Interface Interface Core Subsystem Figure 3: Internal Modules of the ACPI Core ACPI Interface Subsystem 1.4 AML Interpreter Figure 2: Interaction between the Architectural The AML interpreter is responsible for the Components parsing and execution of the AML byte code that is provided by the computer system ven- operating system services is via interfaces pro- dor. The services that the interpreter provides vided by the OSL. Figure 2 shows that the OSL include: component “calls up” to the host operating sys- tem whenever operating system services are re- • AML Control Method Execution quired, either for the OSL itself, or on behalf of the Core Subsystem component. All native • Evaluation of Namespace Objects calls directly to the host are confined to the OS Services Layer, allowing the core to remain OS 1.5 ACPI Table Management independent. This component manages the ACPI tables. The 1.3 ACPI Core Subsystem tables may be loaded from the firmware or di- rectly from a buffer provided by the host oper- ating system. Services include: The Core Subsystem is divided into several log- ical modules or sub-components. Each mod- • ACPI Table Parsing ule implements a service or group of related • ACPI Table Verification services. This section describes each sub- component and identifies the classes of external • ACPI Table installation and removal interfaces to the components, the mapping of these classes to the individual components, and the interface names. Figure 3 shows the inter- 1.6 Namespace Management nal modules of the ACPI Core Subsystem and their relationship to each other. The AML inter- The Namespace component provides ACPI preter forms the foundation of the component, namespace services on top of the AML inter- with additional services built upon this founda- preter. It builds and manages the internal ACPI tion. namespace. Services include: 54 • ACPI in Linux • Namespace Initialization from either the 1.9 Event Handling BIOS or a file • Device Enumeration The Event Handling component manages the ACPI System Control Interrupt (SCI). The sin- • Namespace Access gle SCI multiplexes the ACPI timer, Fixed • Access to ACPI data and tables Events, and General Purpose Events (GPEs). This component also manages dispatch of no- tification and Address Space/Operation Region 1.7 Resource Management events. Services include: The Resource component provides resource • ACPI mode enable/disable query and configuration services on top of the Namespace manager and AML interpreter. Ser- • ACPI event enable/disable vices include: • Fixed Event Handlers (Installation, re- moval, and dispatch) • Getting and Setting Current Resources • General Purpose Event (GPE) Handlers • Getting Possible Resources (Installation, removal, and dispatch) • Getting IRQ Routing Tables • Notify Handlers (Installation, removal, • Getting Power Dependencies and dispatch) • Address Space and Operation Region 1.8 ACPI Hardware Management Handlers (Installation, removal, and dis- patch) The hardware manager controls access to the ACPI registers, timers, and other ACPI–related hardware. Services include: 2 ACPICA OS Services Layer (OSL) • ACPI Status register and Enable register access The OS Services Layer component of the archi- • ACPI Register access (generic read and tecture enables the re-hosting or re-targeting of write) the other components to execute under different operating systems, or to even execute in envi- • Power Management Timer access ronments where there is no host operating sys- • Legacy Mode support tem. In other words, the OSL component pro- vides the glue that joins the other components • Global Lock support to a particular operating system and/or environ- ment. The OSL implements interfaces and ser- • Sleep Transitions support (S-states) vices using native calls to host OS. Therefore, • Processor Power State support (C-states) an OS Services Layer must be written for each target operating system. • Other hardware integration: Throttling, Processor Performance, etc. The OS Services Layer has several roles. 2005 Linux Symposium • 55 1. It acts as the front-end for some OS-to- 2.1.1 OS Boot-load-Time Services ACPI requests. It translates OS requests that are received in the native OS format Boot services are those functions that must be (such as a system call interface, an I/O re- executed very early in the OS load process, be- quest/result segment interface, or a device fore most of the rest of the OS initializes. These driver interface) into calls to Core Subsys- services include the ACPI subsystem initializa- tem interfaces. tion, ACPI hardware initialization, and execu- tion of the _INI control methods for various de- 2. It exposes a set of OS-specific application vices within the ACPI namespace. interfaces. These interfaces translate ap- plication requests to calls to the ACPI in- terfaces. 2.1.2 Device Driver Load-Time Services 3. The OSL component implements a stan- For the devices that appear in the ACPI names- dard set of interfaces that perform OS de- pace, the operating system must have a mecha- pendent functions (such as memory allo- nism to detect them and load device drivers for cation and hardware access) on behalf of them. The Device driver load services provide the Core Subsystem component. These this mechanism. The ACPI subsystem provides interfaces are themselves OS-independent services to assist with device and bus enumer- because they are constant across all OSL ation, resource detection, and setting device re- implementations.