ACPI battery and power subsystem firmware implementation
Windows platforms are expected to expose their battery devices and AC adapters in firmware through ACPI by using standardized control method interfaces, as described in the ACPI specification.
Every mobile Windows platform must have one power source device and one or more batteries. Information from these subsystems is used to convey power status to the user. This status includes such information as whether the platform is running on AC or DC power, the level of charge for each battery, and battery charging status. The Windows power manager aggregates this information and makes it available to the Windows battery meter and other power management components.
This topic details how the platform should expose power subsystem information to the Windows power manager. For more information, see Chapter 10, Power Source Devices, in the ACPI specification.
Note
Some of the information described in this article is specific to Windows and is not detailed in the recent ACPI specification.
ACPI power supply object
The ACPI firmware must provide and implement a single ACPI power source device per section 10.3 of the ACPI specification. This object must report itself with a Hardware ID (_HID) of "ACPI0003".
Note For systems that have multiple power sources, all physical power sources must be multiplexed through a single power device object in ACPI. This object must represent the composite status of power inputs for the system. Client systems must not provide multiple power source device objects. (Additional power source objects may be present on server systems that have multiple power supplies.)
This object must also implement the Power Source (_PSR) method. This method returns the status of the power source and conveys whether the power source is currently online (AC power) or offline (on battery power). The _PSR method must only report online (AC power) when the system is connected to main power. When the state of _PSR changes, the platform must generate an interrupt and a Notify(0x80) command on the device in the ACPI namespace. This must be performed immediately after the platform detects the physical state change.
ACPI battery control methods
The ACPI firmware must provide and implement an ACPI control method object for each battery in the system per section 10.2 of the ACPI specification. Each battery device must do all of the following:
- Identify itself with a Hardware ID (_HID) of "PNP0C0A".
- Implement the Status (_STA) method to indicate if the device is enabled, disabled, or not present.
- Report static information by using the Battery Information Extended (_BIX) method.
- Report battery status by using the Battery Status (_BST) control method.
- Support level-of-charge events by using the Battery Trip Point (_BTP) mechanism.
Optionally, a battery device can implement the Slot Unit Number (_SUN) or indicate battery order for the purposes of display in the user interface (UI).
The following discussion presents the details of these methods and describes their Windows-specific requirements.
ACPI implementation of battery static information
The ACPI firmware must implement the _BIX method for each battery to provide static information about the battery, including design capacity, cycle count, and serial number. The following table expands on the definitions of the fields that are described in section 10.2.2.2 of the ACPI specification, and enumerates Windows-specific requirements for this information.
| Topics | Description | Windows-specific requirements |
|---|---|---|
| Revision | Indicates _BIX revision. | Must be set to 0x0. |
| Power unit | Determines if the units reported by the hardware are milliamps and milliamp-hours or milliwatts and milliwatt-hours. | Must be set to 0x0 to indicate units are milliwatts and milliwatt-hours. This value must not change at runtime. |
| Design capacity | Indicates the original capacity of the battery in milliwatt-hours. | Must be set to an accurate value and cannot be set to 0x0 or 0xFFFFFFFF. This value must not change at runtime. |
| Last full battery charge | Indicates the current full charge capacity of the battery. | Must be set to an accurate value and cannot be set to 0x0 or 0xFFFFFFFF. This value must update each time cycle count increases. This value must remain constant when the battery is discharging. We recommend that this value be updated only when the battery reaches full charge. |
| Battery technology | Indicates if the battery is rechargeable or one-use. | Must be set to 0x1 to indicate the battery is rechargeable. |
| Design voltage | Indicates the design voltage of the battery. | Must be set to the design voltage of the battery when new in millivolts. Must not be set to 0x0 or 0xFFFFFFFF. This value must not change at runtime. |
| Design capacity of Warning | Indicates an OEM-provided low battery warning level. | Windows ignores this value. |
| Design capacity of Low | Indicates the critical battery level at which Windows must immediately shut down or hibernate before the system powers off. | Must be set to a value between 0 and 5 percent of the battery design capacity. |
| Battery capacity granularity 1 | Indicates the minimum amount of remaining charge change that can be detected by the hardware between the Design Capacity of Warning and Design Capacity of Low. | Must be set to a value no larger than 1 percent of the battery design capacity. |
| Battery capacity granularity 2 | Indicates the minimum amount of remaining charge change that can be detected by the hardware between Last Full Charge Capacity and Design Capacity of Warning. | Must be set to a value no larger than 75 milliwatts (approximately 0.25 percent of a 25 watt-hour battery). (1/400) of the battery design capacity. |
| Cycle count | Indicates the battery cycle count. Must be set to a value larger than 0x0. | Must not be set to 0xFFFFFFFF. |
| Measurement accuracy | Indicates the accuracy of the battery capacity measurement. | Must be set to 95,000 or better, indicating 95 percent accuracy or better. |
| Max sampling time | The maximum supported sampling time between two successive _BST evaluations, which will show a difference in remaining capacity. | No specific requirement. |
| Min sampling time | The minimum supported sampling time between two successive _BST evaluations, which will show a difference in remaining capacity. | No specific requirement. |
| Max averaging interval | The maximum averaging interval, in milliseconds, supported by the battery fuel gauge. | No specific requirement. |
| Min averaging interval | The minimum averaging interval, in milliseconds, supported by the battery fuel gauge. | No specific requirement. |
| Model number | OEM-provided battery model number. | Must not be NULL. |
| Serial number | OEM-provided battery serial number. | Must not be NULL. |
| Battery type | OEM-provided battery type information. | No specific requirement. |
| OEM information | OEM-provided information. | No specific requirement. |
In addition to these requirements, the platform firmware must generate an interrupt and a Notify(0x81) command on the battery device in the ACPI namespace whenever any of the battery state data in _BIX changes. This includes last full charge capacity, design capacity, and cycle count. This must be performed immediately after the state change is detected by the platform.
The last full charge capacity represents the estimated amount of energy the battery is expected to hold the last time the battery was fully charged. Windows assumes that this value is updated only when the battery has been charged. Therefore, the last full charge capacity value must not change while the battery discharges. We recommend that this only be updated when the battery reaches full charge.
ACPI implementation of battery real-time status information
The ACPI firmware must implement the _BST method for each battery to provide real-time status information about the battery, including remaining capacity and current rate of drain. The following table expands on the definitions of the fields that are described in section 10.2.2.6 of the ACPI specification, and enumerates Windows-specific requirements for this information.
| Topics | Description | Windows-specific requirements |
|---|---|---|
| Battery state | Indicates if the battery is currently being charged, is discharging, or is in a critical state. | The Battery State must report charging only if the battery is charging. Likewise, the Battery State must report discharging only if the battery is discharging. A battery that is neither charging nor discharging must report neither bit. |
| Battery present rate | Provides the current rate of drain in milliwatts from the battery. | Must be a value greater than 0x0 and less than 0xFFFFFFFF. Must be accurate within the value of Measurement Accuracy in _BIX. |
| Battery remaining capacity | Provides the remaining battery capacity in milliwatt-hours. | Must be greater than 0x0 and less than 0xFFFFFFFF. Must be accurate within the value of Measurement Accuracy in _BIX. |
| Battery present voltage | Indicates the current voltage across the terminals of the battery. | Must be between a value of 0x0 and 0xFFFFFFFF in millivolts. |
When any data in _BST changes, the platform must generate an interrupt and a Notify(0x80) on the battery device in the ACPI namespace. This must be performed immediately after the physical state change is detected by the platform. This includes any change in the Battery State field for the charging bit (Bit0) or discharging bit (Bit1).
Additionally, the platform must implement the _BTP-Battery Trip Point-method. _BTP allows Windows to specify a remaining capacity threshold that when crossed, causes the platform to generate an interrupt and a Notify(0x80) on the battery device in the ACPI namespace. The _BTP method prevents Windows from needing to poll the battery periodically.
Windows OS-specific battery control methods
The ACPI specification affords for device and operating system-specific control methods through the Device-Specific Method or _DSM control method. _DSM is described in section 9.14.1 of the ACPI specification.
Windows 8 supports the following _DSM methods for Control Method Battery devices.
Thermal charge rate direction
| Topics | Value | Description |
|---|---|---|
| UUID | 4c2067e3-887d-475c-9720-4af1d3ed602e | GUID that indicates extensions to Windows Control Method Battery driver support. |
| Revision ID | 0 | First revision of this capability. |
| Function index | 0x1 | Set battery charge throttle. |
| Arguments | Thermal limit | Integer value from 0 to 100 indicating the thermal charge limit. A value of 40 percent indicates the battery should be charged at 40 percent of maximum rate. A value of 0 percent indicates battery charging should be stopped until this method is called again. |
| Return value(s) | None | N/A |
User-serviceable battery
| Topics | Value | Description |
|---|---|---|
| UUID | 4c2067e3-887d-475c-9720-4af1d3ed602e | GUID that indicates extensions to Windows Control Method Battery driver support. |
| Revision ID | 0 | First revision of this capability. |
| Function index | 0x2 | Indicates this _DSM is for OSPM to determine if the battery device is user-serviceable or not. |
| Arguments | None | No arguments are required. |
| Return value(s) | Package containing a single integer. | 0x0 if the battery is not user-serviceable and cannot be replaced by the end user, or can be replaced by the end user with additional tools. 0x1 if the battery can be replaced by the end-user without additional tools. |
Charging watchdog required
| Topics | Value | Description |
|---|---|---|
| UUID | 4c2067e3-887d-475c-9720-4af1d3ed602e | GUID that indicates extensions to Windows Control Method Battery driver support. |
| Revision ID | 0 | First revision of this capability. |
| Function index | 0x3 | Indicates this _DSM is for OSPM to determine if the Control Method Battery requires periodic watchdog resetting to maintain high current charging and the period at which the watchdog must be reset. |
| Arguments | None | No arguments are required. |
| Return value(s) | Package containing a single integer. | 0x0 if the battery does not require watchdog servicing. Values inclusive of 0x0000001e and 0x12C indicate the maximum poling interval in seconds. All other values are ignored and are treated as 0x0 and watchdog resetting is not required. If a valid watchdog interval is specified, Windows will execute the _BST method at an interval no longer than the watchdog value specified when the value of BatteryState in the _BST method is set to charging. Dynamic update of this value is not supported. |
Windows provides a detailed view of system batteries in the desktop tray application. Each battery, together with its current status, is listed in the UI. The following example UI shows two batteries.
The order in which Windows shows batteries can be specified by the firmware. This is achieved by using the Slot User Number (_SUN) method as defined in section 6.1.11 of the ACPI specification. The _SUN method returns an integer that represents the unique ID of the battery. Windows lists each battery object in ascending order based on the value of the _SUN method.
If any battery object includes a _SUN method, then all battery objects must also provide a _SUN method. Windows does not support the case where some batteries have a _SUN method and other batteries do not. If no _SUN objects are provided, Windows sorts the batteries based on their full device instance path; this configuration is supported, but not recommended.