Bit[0]
|
Write status, _RW
1 This memory range is read-write.
0 This memory range is read-only.
Table 6-44 I/O Resource Flag (Resource
Type = 1) Definitions
Bits
|
Meaning
|
Bits[7:6]
|
Reserved (must be 0)
|
Bit[5]
|
Sparse Translation, _TRS.
This bit is only meaningful if Bit[4] is set.
1 SparseTranslation: 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.
0 DenseTranslation: 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.
0 TypeStatic: 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)
|
Bit[1:0]
|
_RNG
3 Memory window covers
the entire range
2 ISARangesOnly. 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: n000-n0FF, n400-n4FF, n800-n8FF, nC00-nCFF. This bit can
only be set for bridges entirely configured through ACPI namespace.
1 NonISARangesOnly. 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.
0 Reserved
|
Table 6-45 Bus Number Range Resource Flag
(Resource Type = 2) Definitions
Bits
|
Meaning
|
Bit[7:0]
|
Reserved (must be 0)
|
6.4.3.6 Extended Interrupt Descriptor
Type 1, Large Item Name
0x9
The Extended Interrupt Descriptor is necessary to describe
interrupt settings and possibilities for systems that support interrupts above
15.
To specify multiple interrupt numbers, this descriptor
allows vendors to list an array of possible interrupt numbers, any one of which
can be used.
Table 6-46 Extended Interrupt Descriptor
Definition
Offset
|
Field Name
|
Definition
|
Byte 0
|
Extended Interrupt Descriptor
|
Value = 0x89 (10001001B) – Type = 1,
Large item name = 0x09
|
Byte 1
|
Length, bits[7:0]
|
Variable length, minimum value = 0x06
|
Byte 2
|
Length, bits[15:8]
|
Variable length, minimum value = 0x00
|
Byte 3
|
Interrupt Vector Flags
|
Interrupt Vector Information.
Bit[7:4] Reserved
(must be 0)
Bit[3] Interrupt
is shareable, _SHR
Bit[2] Interrupt
Polarity, _LL
0 Active-High: This interrupt is sampled
when
the signal is high, or true.
1 Active-Low: This interrupt is sampled
when
the signal is low, or false.
Bit[1] Interrupt
Mode, _HE
0 Level-Triggered: Interrupt is triggered in response
to
the signal being in either a high or low state.
1 Edge-Triggered: This interrupt is
triggered
in response to a change in signal
state,
either high to low or low to high.
Bit[0] Consumer/Producer: 1–This
device consumes this resource
0–This 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.
|
Byte 4n+5
|
Interrupt Number, _INT bits [7:0]
|
Interrupt number
|
Byte 4n+6
|
Interrupt Number, _INT bits [15:8]
|
|
Byte 4n+7
|
Interrupt Number, _INT bits [23:16]
|
|
Byte 4n+8
|
Interrupt Number, _INT bits [31:24]
|
|
…
|
…
|
Additional interrupt numbers
|
Byte x
|
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.
|
String
|
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 Interrupt (page 218) for a description of the ASL macro
that creates an Extended Interrupt descriptor.
6.4.3.7 Generic Register Descriptor
Type 1, Large Item Name
0x2
The generic register descriptor describes the location of a
fixed width register within any of the ACPI-defined address spaces.
Table 6-47 Generic Register Descriptor
Definition
Offset
|
Field Name, ASL Field Name
|
Definition
|
Byte 0
|
Generic Register Descriptor
|
Value = 0x82 (10000010B)
Type = 1, Large item name = 0x02
|
Byte 1
|
Length, bits[7:0]
|
Value = 0x0C (12)
|
Byte 2
|
Length, bits[15:8]
|
Value = 0x00
|
Byte 3
|
Address Space ID, _ASI
|
The address space where the data structure or register exists.
Defined values are: 0x00 System
Memory
0x01 System
I/O
0x02 PCI
Configuration Space
0x03
>Embedded Controller
0x04
>SMBus
0x7F Functional
Fixed Hardware
|
Byte 4
|
Register Bit Width, _RBW
|
Indicates the register width in bits.
|
Byte 5
|
Register Bit Offset, _RBO
|
Indicates the offset to the start of the register in bits from
the Register Address.
|
Byte 6
|
Address Size, _ASZ
|
Specifies access size.
0-Undefined (legacy reasons)
1-Byte access
2-Word access
3-Dword access
4-Qword access
|
Byte 7
|
Register Address, _ADR
bits[7:0]
|
Register Address
|
Byte 8
|
Register Address, _ADR bits[15:8]
|
|
Byte 9
|
Register Address, _ADR bits[23:16]
|
|
Byte 10
|
Register Address, _ADR bits[31:24]
|
|
Byte 11
|
Register Address, _ADR bits[39:32]
|
|
Byte 12
|
Register Address, _ADR bits[47:40]
|
|
Byte 13
|
Register Address, _ADR bits[55:48]
|
|
Byte 14
|
Register Address, _ADR bits[63:56]
|
|
See Register (page 218) for a description of the ASL macro
that creates a Generic Register resource descriptor.
6.5 Other
Objects and Control Methods
Table 6-48 Other Objects and Methods
Object
|
Description
|
_INI
|
Device initialization method that is run shortly after ACPI
has been enabled.
|
_DCK
|
Indicates that the device
is a docking station.
|
_BDN
|
Correlates a docking station between ACPI and legacy
interfaces.
|
_REG
|
Notifies AML code of a
change in the availability of an operation region.
|
_BBN
|
PCI bus number set up by the BIOS.
|
_SEG
|
Indicates a bus segment location.
|
_GLK
|
Indicates the Global Lock
must be acquired when accessing a device.
|
6.5.1 _INI
(Init)
_INI is a device initialization object that performs device
specific initialization. This control method is located under a device object
and is run only when OSPM loads a description table. There are restrictions
related to when this method is called and governing writing code for this
method. The _INI method must only access Operation Regions that have been
indicated to available as defined by the _REG method. The _REG method is
described in section 6.5.4, "_REG (Region)." This control method is run before
_ADR, _CID, _HID, _SUN, and _UID are run.
Before evaluating the _INI object, OSPM evaluates the _STA
object for the device. If the _STA object does not exist for the device, the
device is assumed to be both present and functional. 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 and is not functional, OSPM will not run the _INI and will not examine
the children of the device for _INI methods. If the _STA object evaluation
indicates that the device is not present but is functional, OSPM will not
evaluate the _INI object, but will examine each of the children of the device
for _INI objects (see the description of _STA for the explanation of this
special case.) 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 OSPM performed _INI object actions based upon the _STA
Present and Functional bits are summarized in the table below.
Table 6-49 OSPM _INI Object Actions
_STA Present Bit
|
_STA Functional Bit
|
Actions
|
0
|
0
|
Do not run _INI, do not examine device children
|
0
|
1
|
Do not run _INI, examine device children
|
1
|
0
|
Run _INI, examine device children
|
1
|
1
|
Run _INI, examine device children
|
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.
In addition to device initialization, OSPM unconditionally
evaluates an _INI object under the \_SB namespace, if present, at the beginning
of namespace initialization.
6.5.2 _DCK (Dock)
This control method is
located in the device object that represents the docking station (that is, the
device object with all the _EJx control methods for the docking station)
presence of _DCK indicates to the OS that the device is really a docking
station.
_DCK also controls the
isolation logic on the docking connector. This allows an OS to prepare for
docking before the bus is activated and devices appear on the bus.
Arguments:
Arg0
1–Dock
(that is, remove isolation from connector)
0–Undock
(isolate from connector)
Return Code:
1
if successful, 0 if failed.
Note: When _DCK is called with 0, OSPM
will ignore the return value. The _STA object that follows the _EJx control
method will notify whether or not the portable has been ejected.
6.5.3 _BDN (BIOS Dock Name)
_BDN is used to correlate a docking station reported via
ACPI and the same docking station reported via legacy interfaces. It is
primarily used for upgrading over non-ACPI environments.
_BDN must appear under a device object that represents the
dock, that is, the device object with _Ejx methods. This object must return a
DWORD that is the EISA-packed DockID returned by the Plug and Play BIOS
Function 5 (Get Docking Station Identifier) for a dock.
Note: If the
machine does not support PNPBIOS, this object is not required.
6.5.4 _REG (Region)
The OS runs _REG
control methods to inform AML code of a change in the availability of an
operation region. When an operation region handler is unavailable, AML cannot
access data fields in that region. (Operation region writes will be ignored and
reads will return indeterminate data.).
Except for the cases
shown below, control methods must assume all operation regions inaccessible
until the _REG(RegionSpace, 1) method is executed. Once _REG has been executed
for a particular operation region, indicating that the operation region handler
is ready, a control method can access fields in the operation region.
Conversely, control methods must not access fields in operation regions when
_REG method execution has not indicated that the operation region handler is
ready.
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
}
}
}
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. PCI1's
_REG method would not be run until the PCI-PCI bridge has been properly
configured. At the same time, the OS will also run ETH0's _REG method since its
PCI Config Space would be also available. The OS will again run ETH0's _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, ETH0's _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:
0 SystemMemory
1 SystemIO
2 PCI_Config
3 Embedded
Controller
4 SMBus
5 CMOS
6 PCIBARTarget
0x80-0xFF OEM region
space handler
Arg1: Integer:1 for connecting the handler, 0 for disconnecting the handler
6.5.5 _BBN (Base Bus Number)
For multi-root PCI platforms, the _BBN object evaluates to
the PCI bus number that the BIOS assigns. This is needed to access a PCI_Config
operation region for the specific bus. The _BBN object is located under a PCI
host bridge and must be unique for every host bridge within a segment since it
is the PCI bus number.
6.5.6 _SEG (Segment)
The optional _SEG object is located under a PCI host bridge
and evaluates to an integer that describes the PCI Segment Group (see PCI
Firmware Specification v3.0). If _SEG does not exist, OSPM assumes that all PCI
bus segments are in PCI Segment Group 0.
PCI Segment Group is purely a software concept managed by
system firmware and used by OSPM. It is a logical collection of PCI buses (or
bus segments). There is no tie to any physical entities. It is a way to
logically group the PCI bus segments and PCI Express Hierarchies. _SEG is a
level higher than _BBN.
PCI Segment Group supports more than 256 buses in a system
by allowing the reuse of the PCI bus numbers. Within each PCI Segment Group,
the bus numbers for the PCI buses must be unique. PCI buses in different PCI
Segment Group are permitted to have the same bus number.
A PCI Segment Group contains one or more PCI host bridges.
The lower 16 bits of _SEG returned integer is the PCI
Segment Group number. Other bits are reserved.
6.5.6.1 Example
Device(ND0) { // this is a node 0
Name(_HID, "ACPI0004")
// Returns the "Current Resources"
Name(_CRS,
ResourceTemplate() {
…
}
)
Device(PCI0) {
Name(_HID, EISAID("PNP0A03"))
Name(_ADR, 0x00000000)
Name(_SEG, 0) // The buses below
the host bridge belong to PCI segment 0
…
Name(_BBN, 0)
…
}
Device(PCI1) {
…
Name(_SEG, 0) // The buses below
the host bridge belong to PCI segment 0
…
Name(_BBN, 16)
…
}
…
}
Device(ND1) { // this is a node 1
Name(_HID, "ACPI0004")
// Returns the "Current Resources"
Name(_CRS,
ResourceTemplate() {
…
}
)
Device(PCI0) {
Name(_HID, EISAID("PNP0A03"))
Name(_ADR, 0x00000000)
Name(_SEG, 1) // The buses below
the host bridge belong to PCI segment 1
…
Name(_BBN, 0)
…
}
Device(PCI1) {
…
Name(_SEG, 1) // The buses below
the host bridge belong to PCI segment 1
…
Name(_BBN, 16)
…
}
}
6.5.7 _GLK
(Global Lock)
This optional named
object is located in a device object. This object returns a value that
indicates to any entity that accesses this device (in other words, OSPM or any
device driver) whether the Global Lock must be acquired when accessing the
device. OS-based device accesses must be performed while in acquisition of the
Global Lock when potentially contentious accesses to device resources are
performed by non-OS code, such as System Management Mode (SMM)-based code in
Intel architecture-based systems.
An example of this
device resource contention is a device driver for an SMBus-based device
contending with SMM-based code for access to the Embedded Controller, SMB-HC,
and SMBus target device. In this case, the device driver must acquire and
release the Global Lock when accessing the device to avoid resource contention
with SMM-based code that accesses any of the listed resources.
Return Codes:
1
Global Lock required, 0 Global Lock not required
7 Power and Performance Management
This section specifies the device power management objects
and system power management objects. OSPM uses these objects to manage the
platform by achieving a desirable balance between performance and energy
conservation goals.
Device performance states (Px states) are power consumption
and capability states within the active (D0) device power state. Performance
states allow OSPM to make tradeoffs between performance and energy
conservation. Device performance states have the greatest impact when the
implementation is such that the states invoke different device efficiency
levels as opposed to a linear scaling of performance and energy consumption.
Since performance state transitions occur in the active device states, care
must be taken to ensure that performance state transitions do not adversely
impact the system.
Device performance state objects, when necessary, are
defined on a per device class basis as described in the device class
specifications (See Appendix A).
The system state indicator objects are also specified in
this section.
7.1 Declaring a Power Resource
Object
An ASL PowerResource
statement is used to declare a PowerResource object. A Power Resource object refers to a
software-controllable power plane, clock plane, or other resource upon which an
integrated ACPI power-managed device might rely. Power resource objects can
appear wherever is convenient in namespace.
The syntax of a PowerResource statement is:
PowerResource (resourcename,
systemlevel, resourceorder) {NamedList}
where the systemlevel
parameter is a number and the resourceorder parameter is a numeric constant (a WORD). For a
formal definition of the PowerResource statement syntax, see
section 17, "ACPI Source Language Reference."
Systemlevel is the
lowest power system sleep level OSPM must maintain to keep this power resource
on (0 equates to S0, 1 equates to S1, and so on).
Each power-managed ACPI device lists the resources it
requires for its supported power levels. OSPM multiplexes this information from
all devices and then enables and disables the required Power Resources
accordingly. The resourceorder field in
the Power Resource object is a unique value per Power Resource, and it provides
the system with the order in which Power Resources must be enabled or disabled.
Power Resources are enabled from low values to high values and
are disabled from high values to low values. The operating software enables or
disables all affected Power Resources in any one resourceorder level at a time before moving on to the next ordered
level. Putting Power Resources in different order levels provides power
sequencing and serialization where required.
A Power Resource can have named objects under its Namespace
location. For a description of the ACPI-defined 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.1 Defined Child Objects for a Power Resource
Each power resource object is required to have the
following control methods to allow basic control of each power resource
OSPM changes the state of device objects in the system, the power resources
that are needed will also change causing OSPM to turn power resources on and
off. To determine the initial power resource settings the _STA method can be
used.
Table 7-1 Power Resource Child Objects
Object
|
Description
|
_OFF
|
Set the resource off.
|
_ON
|
Set the resource on.
|
_STA
|
Object that evaluates to the current on or off state of the
Power Resource. 0–OFF, 1–ON
|
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
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
7.1.4 _STA (Status)
Returns the current ON or OFF status for the power
resource.
Arguments:
None
Result Code:
0 indicates the power resource is currently off.
1 indicates the power resource is currently on.
7.2 Device Power Management
Objects
For a device that is power-managed using ACPI, a Definition
Block contains one or more of the
objects found in the table below. Power management of a device is done using
two different paradigms:
· Power Resource control
· Device-specific control
Power Resources are resources that could be shared amongst
multiple devices. The operating software will automatically handle control of
these devices by determining which particular Power Resources need to be in the
ON state at any given time. This determination is made by considering the state
of all devices connected to a Power Resource.
By definition, a device that is OFF does not have any power
resource or system power state requirements. Therefore, device objects do not
list power resources for the OFF power state.
For OSPM to put the device in the D3 state, the following
must occur:
· All Power Resources no longer referenced by any device in the
system must be in the OFF state.
· If present, the _PS3 control method is executed to set the device
into the D3 device state.
The only transition allowed from the D3 device state is to the D0
>device state.
For many devices the Power Resource control is all that is
required; however, device objects may include their own device-specific control
method.
These two types of power management controls (through Power
Resources and through specific devices) can be applied in combination or
individually as required.
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.
When controlling power
to devices which must wake the system during a system sleeping state:
· The device must declare its
ability to wake the system by declaring either the _PRW or _PSW object.
· If _PR0 is present, then OSPM
must choose a sleeping state which is less than or equal to the sleeping state
specified.
· After OSPM has called _PTS,
it must call the device's _PSW to enable wake.
· OSPM must transition the
device into a D-state which is greater than or equal that specified by the
device's _SxD object, but less than or equal to that specified by the device's
_SxW object.
· OSPM may transition the
system to the specified sleep state.
Table 7-2 Device Power Management Child
Objects
Object
|
Description
|
_DSW
|
Control method
that enables or disables the device's wake function for device-only wake.
|
_PS0
|
Control method that puts the device in the D0 device state
(device fully on).
|
_PS1
|
Control method that puts the device in the D1 device state.
|
_PS2
|
Control method that puts the device in the D2 device state.
|
_PS3
|
Control method that puts the device in the D3 device state
(device off).
|
_PSC
|
Object that evaluates to the device's current power state.
|
_PR0
|
Object that evaluates to the device's power requirements in
the D0 device state (device fully on).
|
_PR1
|
Object that evaluates to the device's 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.
|
_PR2
|
Object that evaluates to the device's 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.
|
_PRW
|
Object that evaluates to the device's power requirements in
order to wake the system from a system sleeping state.
|
_PSW
|
Control method that enables or disables the device's wake
function.
|
_IRC
|
Object that signifies the device has a significant inrush
current draw.
|
_S1D
|
Highest
D-state supported by the device in the S1 state
|
_S2D
|
Highest
D-state supported by the device in the S2 state
|
_S3D
|
Highest
D-state supported by the device in the S3 state
|
_S4D
|
Highest
D-state supported by the device in the S4 state
|
_S0W
|
Lowest D-state supported by the device in the
S0 state which can wake the device
|
_S1W
|
Lowest D-state supported by the device in the
S1 state which can wake the system.
|
_S2W
|
Lowest D-state supported by the device in the
S2 state which can wake the system.
|
_S3W
|
Lowest D-state supported by the device in the
S3 state which can wake the system.
|
_S4W
|
Lowest D-state supported by the device in the
S4 state which can wake the system.
|
7.2.1 _DSW (Device Sleep
Wake)
In addition to _PRW, this control method can be used to
enable or disable the device's ability to wake a sleeping system. This control
method can only access Operation Regions that are either always available while
in a system working state or that are available when the Power Resources
referenced by the _PRW object are all ON. For example, do not put a power plane
control for a bus controller within configuration space located behind the bus.
The method should enable the device only for the last system state/device state
combination passed in by OSPM. OSPM will only pass in combinations allowed by
the _SxD and _SxW objects.
The arguments provided to _DSW indicate the eventual Device
State the device will be transitioned to and the eventual system state that the
system will be transitioned to. The target system state is allowed to be the
system working state (S0). The _DSW method will be run before the device is
placed in the designated state and also before the system is placed in the
designated system state.
Compatibility Note: The _PSW method is deprecated in ACPI
3.0. The _DSW method should be used instead. OSPM will only use the _PSW method
if OSPM does not support _DSW or if the _DSW method is not present.
Arguments:
0– Enable / Disable: 0
to disable the device's wake capabilities.
1
to enable the device's wake capabilities.
1- Target
System State 0 to indicate system will be in S0
1
to indicate system will be in S1
…
2-Target Device State 0 to indicate that the device
will remain in D0
1
to indicate that the device will be placed in either D0 or D1
2
to indicate that the device will be placed in either D0, D1, or D2
3
to indicate that the device will be placed in either D0, D1, D2, or D3
Result Code:
None
7.2.2 _PS0 (Power State 0)
This Control Method is used to put the specific device into
its D0 state. This Control Method can only access Operation Regions that are either always available while in a system
working state or that are available when the Power Resources references by the _PR0
>object are all ON.
Arguments:
None
Result Code:
None
7.2.3 _PS1 (Power State 1)
This control method is used to put the specific device into
its D1 state. This control method can
only access Operation Regions that are either always available while in a
system working state or that are available when the Power Resources references
by the _PR1 object are all ON.
Arguments:
None
Result Code:
None
7.2.4 _PS2 (Power State 2)
This control method is used to put the specific device into
its D2 state. This control method can
only access Operation Regions that are either always available while in a
system working state or that are available when the Power Resources references
by the _PR2 object are all ON.
Arguments:
None
Result Code:
None
7.2.5 _PS3 (Power State 3)
This control method is used to put the specific device into
its D3 state. This control method can only access Operation Regions that are
always available while in a system working state.
A device in the D3 state must no longer be using its
resources (for example, its memory space and I/O ports are available to other
devices).
Arguments:
None
Result Code:
None
7.2.6 _PSC (Power State Current)
This control method evaluates
to the current device state. This control method is not required if the device
state can be inferred by the Power Resource settings. This would be the case
when the device does not require a _PS0, _PS1, _PS2, or _PS3 control method.
Arguments:
None
Result Code:
The result codes are shown in Table 7-3.
Table 7-3 _PSC
Control Method Result Codes
Result
|
Device State
|
0
|
D0
|
1
|
D1
|
2
|
D2
|
3
|
D3
|
7.2.7 _PR0
(Power Resources for D0)
This object evaluates to a package of the following
definition:
Table 7-4 Power Resource Requirements
Package
Element
|
Object
|
Description
|
1
|
object reference
|
Reference to required Power Resource #0
|
N
|
object reference
|
Reference to required Power Resource #N
|
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.
7.2.8 _PR1
(Power Resources for D1)
This object evaluates to a package as defined in Table 7-4.
For OSPM to put the device in the D1 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 _PS1 control method is executed to set the device into
the D1 device state.
_PR1 must return
the same data each time it is evaluated. All power resources referenced must
exist in the namespace.
7.2.9 _PR2
(Power Resources for D2)
This object evaluates to a package as defined in Table 7-4.
For OSPM to put the device in the D2 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 _PS2 control method is executed to set the device into
the D2 device state.
_PR2 must return
the same data each time it is evaluated. All power resources referenced must
exist in the namespace.
7.2.10 _PRW
(Power Resources for Wake)
This object is only required for devices that have the
ability to wake the system from a system sleeping state. This object evaluates
to a package of the following definition:
Table 7-5 Wake
Power Requirements Package
Element
|
Object Type
|
Description
|
0
|
Numeric or package
|
If the data type of this package element is numeric, then this
_PRW package element is the bit index in the GPEx_EN, in the GPE blocks
described in the FADT, of the enable bit that is enabled for the wake event.
If the data type of this package element is a package, then
this _PRW package element is itself a package containing two elements
first is an object reference to the GPE Block device that contains the GPE
that will be triggered by the wake event. The second element is numeric and
it contains the bit index in the GPEx_EN, in the GPE Block referenced by the
first element in the package, of the enable bit that is enabled for the wake
event.
For example, if this field is a package then it is of the
form: Package(){\_SB.PCI0.ISA.GPE,
2}
|
1
|
Numeric
|
The lowest power system sleeping state that can be entered
while still providing wake functionality.
|
2
|
Object Reference
|
Reference to required Power Resource #0
|
N
|
Object Reference
|
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.
3. The D-state being entered must be at least that specified in the _SxD
state but no greater than that specified in the _SxW state.
Then, if the system enters a sleeping state OSPM must
ensure:
1. Interrupts are disabled.
2. The sleeping state being entered must be less than 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.
7.2.11 _PSW
(Power State Wake)
In addition to the _PRWcontrol method, this control method
can be used to enable or disable the device's ability to wake a
sleeping system. This control method can only access Operation Regions that are either always available while in a system working state or
that are available when the Power Resources references by the _PRW object are
all ON. For example, do not put a power plane control for a bus controller
within configuration space located behind the bus.
Compatibility Note: The _PSW method is deprecated in ACPI
3.0. OSPM must use _DSW if it is present. Otherwise, it may use _PSW.
Arguments:
0– Enable / Disable: 0
to disable the device's wake capabilities.
1
to enable the device's wake capabilities.
Result Code:
None
7.2.12 _IRC
(In Rush Current)
The presence of this object signifies that transitioning
the device to its D0 state causes a system-significant in-rush current load
general, such operations need to be serialized such that multiple operations
are not attempted concurrently. Within ACPI, this type of serialization can be
accomplished with the resourceorder parameter
of the device's Power Resources; however, this does not serialize
ACPI-controlled devices with non-ACPI controlled devices. IRC is used to
signify this fact outside of OSPM to OSPM such that OSPM can serialize all
devices in the system that have in-rush current serialization requirements.
OSPM can only transition one device containing an _IRC object within its device
scope to the D0 state at a time. It is important to note that OSPM does not
evaluate the _IRC object. It has no defined input arguments nor does it return
any value. OSPM derives meaning simply from the existence of the _IRC object.
7.2.13 _S1D
(S1 Device State)
This object evaluates to an integer that conveys to OSPM
the highest power (lowest number) D-state supported by this device in the S1
system sleeping state. _S1D must return the same integer each time it is
evaluated. This value overrides an S-state to D-state mapping OSPM may
ascertain from the device's power resource declarations. See Table 7-3 for valid
result codes.
If the device can wake the system from the S1 system
sleeping state (see _PRW) then the device must support wake in the D-state
returned by this object. However, OSPM cannot assume wake from the S1 system
sleeping state is supported in any lower D-state unless specified by a
corresponding _S1W object. The table below provides a mapping from Desired
Actions to Resultant D-state entered based on the values returned from the
_S1D, _PRW, and _S1W objects if they exist . (D/C means Don't Care –evaluation is irrelevant, and N/A means Non Applicable – object does not
exist).
Table 7-6 S1
Action / Result Table
Desired Action
|
_S1D
|
_PRW
|
_S1W
|
Resultant D-state
|
Enter S1
|
D/C
|
D/C
|
D/C
|
OSPM decides
|
Enter S1, No Wake
|
2
|
D/C
|
D/C
|
Enter D2 or D3
|
Enter S1, Wake
|
2
|
1
|
N/A
|
Enter D2
|
Enter S1, Wake
|
2
|
1
|
3
|
Enter D2 or D3
|
Enter S1, Wake
|
N/A
|
1
|
2
|
Enter D0,D1 or D2
|
7.2.14 _S2D
(S2 Device State)
This object evaluates to an integer that conveys to OSPM
the highest power (lowest number) D-state supported by this device in the S2
system sleeping state. _S2D must return the same integer each time it is
evaluated. This value overrides an S-state to D-state mapping OSPM may
ascertain from the device's power resource declarations. See Table 7-3 for valid
result codes.
If the device can wake the system from the S2 system
sleeping state (see _PRW) then the device must support wake in the D-state
returned by this object. However, OSPM cannot assume wake from the S2 system
sleeping state is supported in any lower D-state unless specified by a
corresponding _S2W object. The table below provides a mapping from Desired
Actions to Resultant D-state entered based on the values returned from the
_S2D, _PRW, and _S2W objects if they exist . (D/C means Don't Care –evaluation is irrelevant, and N/A means Non Applicable – object does not
exist).
Table 7-7 S2
Action / Result Table
Desired Action
|
_S2D
|
_PRW
|
_S2W
|
Resultant D-state
|
Enter S2
|
D/C
|
D/C
|
D/C
|
OSPM decides
|
Enter S2, No Wake
|
2
|
D/C
|
D/C
|
Enter D2 or D3
|
Enter S2, Wake
|
2
|
2
|
N/A
|
Enter D2
|
Enter S2, Wake
|
2
|
2
|
3
|
Enter D2 or D3
|
Enter S2, Wake
|
N/A
|
2
|
2
|
Enter D0,D1 or D2
|
7.2.15 _S3D
(S3 Device State)
This object evaluates to an integer that conveys to OSPM
the highest power (lowest number) D-state supported by this device in the S3
system sleeping state. _S3D must return the same integer each time it is
evaluated. This value overrides an S-state to D-state mapping OSPM may
ascertain from the device's power resource declarations. See Table 7-3 for valid
result codes.
If the device can wake the system from the S3 system
sleeping state (see _PRW) then the device must support wake in the D-state
returned by this object. However, OSPM cannot assume wake from the S3 system
sleeping state is supported in any lower D-state unless specified by a
corresponding _S3W object. The table below provides a mapping from Desired
Actions to Resultant D-state entered based on the values returned from the
_S3D, _PRW, and _S3W objects if they exist . (D/C means Don't Care –evaluation is irrelevant, and N/A means Non Applicable – object does not
exist).
Table 7-8 S3
Action / Result Table
Desired Action
|
_S3D
|
_PRW
|
_S3W
|
Resultant D-state
|
Enter S3
|
N/A
|
D/C
|
N/A
|
OSPM decides
|
Enter S3, No Wake
|
2
|
D/C
|
D/C
|
Enter D2 or D3
|
Enter S3, Wake
|
2
|
3
|
N/A
|
Enter D2
|
Enter S3, Wake
|
2
|
3
|
3
|
Enter D2 or D3
|
Enter S3, Wake
|
N/A
|
3
|
2
|
Enter D0, D1 or D2
|
7.2.16 _S4D
(S4 Device State)
This object evaluates to an integer that conveys to OSPM
the highest power (lowest number) D-state supported by this device in the S4
system sleeping state. _S4D must return the same integer each time it is
evaluated. This value overrides an S-state to D-state mapping OSPM may
ascertain from the device's power resource declarations. See Table 7-3 for valid
result codes.
If the device can wake the system from the S4 system
sleeping state (see _PRW) then the device must support wake in the D-state
returned by this object. However, OSPM cannot assume wake from the S4 system
sleeping state is supported in any lower D-state unless specified by a
corresponding _S4W object. The table below provides a mapping from Desired
Actions to Resultant D-state entered based on the values returned from the
_S4D, _PRW, and _S4W objects if they exist . (D/C means Don't Care –evaluation is irrelevant, and N/A means Non Applicable – object does not
exist).
Table 7-9 S4
Action / Result Table
Desired Action
|
_S4D
|
_PRW
|
_S4W
|
Resultant D-state
|
Enter S4
|
N/A
|
D/C
|
N/A
|
OSPM decides
|
Enter S4, No Wake
|
2
|
D/C
|
D/C
|
Enter D2 or D3
|
Enter S4, Wake
|
2
|
4
|
N/A
|
Enter D2
|
Enter S4, Wake
|
2
|
4
|
3
|
Enter D2 or D3
|
Enter S4, Wake
|
N/A
|
4
|
2
|
Enter D0, D1 or D2
|
7.2.17 _S0W (S0 Device Wake State)
This object evaluates to an integer that conveys to OSPM
the lowest power (highest number) D-state supported by this device in the S0
system sleeping state where the device can wake itself. _S0W must return the same integer each time it is
evaluated. This value allows OSPM to choose the lowest power D-state and still
achieve wake functionality. If object evaluates to zero, then the device cannot
wake itself from any lower sleeping state.
7.2.18 _S1W (S1 Device Wake State)
This object evaluates to an integer that conveys to OSPM
the lowest power (highest number) D-state supported by this device in the S1
system sleeping state which can wake the system. _S1W must return the same integer each time it is evaluated. This
value allows OSPM to choose a lower S-state to D-state mapping than specified
by _S1D. This value must always be greater than or equal to _S1D, if _S1D is present.
7.2.19 _S2W (S2 Device Wake State)
This object evaluates to an integer that conveys to OSPM
the lowest power (highest number) D-state supported by this device in the S2
system sleeping state which can wake the system. _S2W must return the same integer each time it is evaluated. This
value allows OSPM to choose a lower S-state to D-state mapping than specified
by _S2D. This value must always be greater than or equal to _S2D, if _S2D is
present.
7.2.20 _S3W (S3 Device Wake State)
This object evaluates to an integer that conveys to OSPM
the lowest power (highest number) D-state supported by this device in the S3
system sleeping state which can wake the system. _S3W must return the same integer each time it is evaluated. This
value allows OSPM to choose a lower S-state to D-state mapping than specified
by _S3D. This value must always be greater than or equal to _S3D, if _S3D is
present.
7.2.21 _S4W (S4 Device Wake State)
This object evaluates to an integer that conveys to OSPM
the lowest power (highest number) D-state supported by this device in the S4
system sleeping state which can wake the system. _S4W must return the same integer each time it is evaluated. This
value allows OSPM to choose a lower S-state to D-state mapping than specified
by _S4D. This value must always be greater than or equal to _S4D, if _S4D is
present.
7.3 OEM-Supplied System-Level Control Methods
An OEM-supplied Definition Block provides some number of controls appropriate for
system-level management. These are used by OSPM to integrate to the
OEM-provided features. The following table lists the defined OEM system
controls that can be provided.
Table 7-10 BIOS-Supplied Control Methods
for System-Level Functions
Object
|
Description
|
\_BFS
|
Control method executed immediately following a wake event.
|
\_PTS
|
Control method used to notify the platform of impending sleep
transition.
|
\_GTS
|
Control method executed just prior to setting the sleep enable
(SLP_EN) bit.
|
\_S0
|
Package that defines system \_S0 state mode.
|
\_S1
|
Package that defines system \_S1 state mode.
|
\_S2
|
Package that defines system \_S2 state mode.
|
\_S3
|
Package that defines system \_S3 state mode.
|
\_S4
|
Package that defines system \_S4 state mode.
|
\_S5
|
Package that defines system \_S5 state mode.
|
\_TTS
|
Control method
used to prepare to sleep and run once awakened
|
\_WAK
|
Control method run once awakened.
|
7.3.1 \_BFS (Back From Sleep)
_BFS is an optional control method. If it exists, OSPM must
execute the _BFS method immediately following wake from any sleeping state S1,
S2, S3, or S4. _BFS allows ACPI system firmware to perform any required system
specific functions when returning a system sleep state. OSPM will execute the _BFS
control method before performing any other physical I/O or enabling any
interrupt servicing upon returning from a sleeping state. A value that
indicates the sleeping state from which the system was awoken (in other words,
1=S1, 2=S2, 3=S3, 4=S4) is passed as an argument to the _BFS control method.
The _BFS method must be self-contained (not call other
methods). Additionally, _BFS may only access OpRegions that are currently
available (see the _REG method for details).
Arguments:
0: The
value of the previous sleeping state (1 for S1, 2 for S2, and so on).
7.3.2 \_PTS (Prepare To Sleep)
The _PTS control method is executed by the OS during the
sleep transition process for S1, S2, S3, S4, and for orderly S5 shutdown
sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5
soft-off state) is passed to the _PTS control method. This method is called
after OSPM has notified native device drivers of the sleep state transition and
before the OSPM has had a chance to fully prepare the system for a sleep state
transition. Thus, this control method can be executed a relatively long time
before actually entering the desired sleeping state. If OSPM aborts the sleep
state transition, OSPM should run the _WAK method to indicate this condition to
the platform.
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.
The platform must not make any assumptions about the state
of the machine when _PTS is called. For example, operation region accesses that
require devices to be configured and enabled may not succeed, as these devices
may be in a non-decoding state due to plug and play or power management
operations.
Arguments:
0: The
value of the sleeping state (1 for S1, 2 for S2, and so on).
7.3.3 \_GTS (Going To Sleep)
_GTS is an optional control method. If it exists, OSPM must
execute the _GTS control method just prior to setting the sleep enable (SLP_EN)
bit in the PM1 control register when entering the S1, S2, S3, and S4 sleeping
states and when entering S5 for orderly shutdown. _GTS allows ACPI system
firmware to perform any required system specific functions prior to entering a
system sleep state. OSPM will set the sleep enable (SLP_EN) bit in the PM1
control register immediately following the execution of the _GTS control method
without performing any other physical I/O or allowing any interrupt servicing.
The sleeping state value (1, 2, 3, 4, or 5) is passed as an argument to the
_GTS control method. The _GTS method must not attempt to directly place the system
into a sleeping state. OSPM performs this function by setting the sleep enable
bit upon return from _GTS. In the case of entry into the S5 soft off state
however, _GTS may indeed perform operations that place the system into the S5
state as OSPM will not regain control.
The _GTS method must be self-contained (not call other
methods). Additionally, _GTS may only access OpRegions that are currently
available (see the _REG method for details).
Arguments:
0: The
value of the sleeping state (1 for S1, 2 for S2, and so on).
7.3.4 System
\_Sx
states
All system states supported by the system must provide a
package containing the DWORD value of the following format in the static
Definition Block. The system states, known as S0–S5, are referenced in
the namespace as \_S0–\_S5 and for clarity the short Sx names are used unless specifically referring to the
named \_Sx object. For each Sx state, there is a defined system behavior.
Table 7-11 System State Package
Byte Length
|
Byte Offset
|
Description
|
1
|
0
|
Value for PM1a_CNT.SLP_TYP register to enter this system
state.
|
1
|
1
|
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.
|
2
|
2
|
Reserved
|
States S1–S4 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.
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 ;Build real mode handler the resume
push offset sp50 ;context, with eip = sp50
call SaveProcessorState
mov eax,
ResumeVector ; set firmware's resume vector
mov [eax],
offset OsRealModeResumeCode
mov edx,
PM1a_STS ;Make sure wake status
is clear
mov ax,
WAK_STS ;(cleared by asserting the bit
out dx, ax ;in the status register)
mov edx,
PM1b_STS ;
out dx, ax ;
and eax,
not SLP_TYP_MASK
or eax,
SlpTyp ;set SLP_TYP
or ax,
SLP_EN ; set
SLP_EN
cmp FlushCaches,
0
jz short
sp10 ; If
needed, ensure no dirty data in
call FlushProcessorCaches ;the caches while sleeping
sp10: mov edx, PM1a_SLP_TYP ;get address for PM1a_SLP_TYP
out dx, ax ;start h/w sequencing
mov edx,
PM1b_SLP_TYP ; get address for PM1b_SLP_TYP
out dx, ax ;start h/w sequencing
mov edx,
PM1a_STS ; get address for
PM1x_STS
mov ecx,
PM1b_STS
sp20: in ax, dx ;wait for WAK status
xchg edx, ecx
test ax, WAK_STS
jz short
sp20
sp50:
}
// Done..
*ResumeVector = NULL;
return 0;
}
7.3.4.1 System
\_S0 State (Working)
While the system is in the S0 state, it is in the system
working state. The behavior of this state is defined as:
· The processors are in the C0, C1, C2, or C3 states
processor-complex context is maintained and instructions are executed as
defined by any of these processor states.
· Dynamic RAM context is maintained and is read/write by the
processors.
· Devices states are individually managed by the operating software
and can be in any device state (D0, D1, D2, or D3).
· Power Resources are in a state compatible with the current device
states.
Transition into the S0 state from some system sleeping state is automatic, and by virtue that
instructions are being executed OSPM, assumes the system to be in the S0 state.
7.3.4.2 System
\_S1 State (Sleeping with Processor Context Maintained)
While the system is in the S1 sleeping state, its behavior
is the following:
· The processors are not executing instructions
processor-complex context is maintained.
· Dynamic RAM context is maintained.
· Power Resources are in a state compatible with the system S1 state.
All Power Resources that supply a System-Level reference of S0 are in the OFF
state.
· Devices states are compatible with the current Power Resource
states. Only devices that solely reference Power Resources that are in the ON
state for a given device state can be in that device state. In all other cases,
the device is in the D3 (off) state.
· Devices that are enabled to wake the system and that can do so
from their current device state can initiate a hardware event that transitions
the system state to S0. This transition causes the processor to continue
execution where it left off.
To transition into the S1 state, the OSPM must flush all
processor caches.
7.3.4.3 System
\_S2 State
The S2 sleeping state is logically lower than the S1 state and is assumed to conserve more power
behavior of this state is defined as:
· The processors are not executing instructions
processor-complex context is not maintained.
· Dynamic RAM context is maintained.
· Power Resources are in a state compatible with the system S2
state. All Power Resources that supply a System-Level reference of S0 or S1 are
in the OFF state.
· Devices states are compatible with the current Power Resource
states. Only devices that solely reference Power Resources that are in the ON
state for a given device state can be in that device state. In all other cases,
the device is in the D3 (off) state.
· Devices that are enabled to wake the system and that can do so
from their current device state can initiate a hardware event that transitions
the system state to S0. This transition causes the processor to begin execution
at its boot location. The BIOS performs initialization of core functions as
needed to exit an S2 state and passes control to the firmware resume vector.
See section 15.3.2, "BIOS Initialization of Memory," for more details on BIOS
initialization.
Because the processor context can be lost while in the S2
state, the transition to the S2 state requires that the operating software flush
all dirty cache to dynamic RAM (DRAM).
7.3.4.4 System
\_S3 State
The S3 state is logically lower than the S2 state and is
assumed to conserve more power. The behavior of this state is defined as
follows:
· The processors are not executing instructions
processor-complex context is not maintained.
· Dynamic RAM context is maintained.
· Power Resources are in a state compatible with the system S3
state. All Power Resources that supply a System-Level reference of S0, S1, or
S2 are in the OFF state.
· Devices states are compatible with the current Power Resource
states. Only devices that solely reference Power Resources that are in the ON
state for a given device state can be in that device state. In all other cases,
the device is in the D3 (off) state.
· Devices that are enabled to wake the system and that can do so
from their current device state can initiate a hardware event that transitions
the system state to S0. This transition causes the processor to begin execution
at its boot location. The BIOS performs initialization of core functions as
necessary to exit an S3 state and passes control to the firmware resume vector.
See section 15.3.2, "BIOS Initialization of Memory," for more details on BIOS initialization.
From the software viewpoint, this state is functionally the
same as the S2 state. The operational difference can be that some Power
Resources that could be left ON to be in the S2 state might not be available to
the S3 state. As such, additional devices may need to be in a logically lower
D0, D1, D2, or D3 state for S3 than S2. Similarly, some device wake events can
function in S2 but not S3.
Because the processor context can be lost while in the S3
state, the transition to the S3 state requires that the operating software
flush all dirty cache to DRAM.
7.3.4.5 System
\_S4 State
While the system is in this state, it is in the system S4
sleeping state. The state is logically lower than the S3 state and is assumed
to conserve more power. The behavior of this state is defined as follows:
· The processors are not executing instructions
processor-complex context is not maintained.
· DRAM context is not maintained.
· Power Resources are in a state compatible with the system S4
state. All Power Resources that supply a System-Level reference of S0, S1, S2,
or S3 are in the OFF state.
· Devices states are compatible with the current Power Resource
states. In other words, all devices are in the D3 state when the system state
is S4.
· Devices that are enabled to wake the system and that can do so
from their device state in S4 can initiate a hardware event that transitions
the system state to S0. This transition causes the processor to begin execution
at its boot location.
After OSPM has executed the _PTS control method and has put
the entire system state into main memory, there are two ways that OSPM may
handle the next phase of the S4 state transition; saving and restoring main
memory. The first way is to use the operating system's drivers to access the
disks and file system structures to save a copy of memory to disk and then
initiate the hardware S4 sequence by setting the SLP_EN register bit. When the
system wakes, the firmware performs a normal boot process and transfers control
to the OS via the firmware_waking_vector loader. The OS then restores the
system's memory and resumes execution.
The alternate method for entering the S4 state is to
utilize the BIOS via the S4BIOS transition. The BIOS uses firmware to save a copy
of memory to disk and then initiates the hardware S4 sequence. When the system
wakes, the firmware restores memory from disk and wakes OSPM by transferring
control to the FACS waking vector.
The S4BIOS transition is optional, but any system that
supports this mechanism must support entering the S4 state via the direct OS
mechanism. Thus the preferred mechanism for S4 support is the direct OS
mechanism as it provides broader platform support. The alternate S4BIOS
transition provides a way to achieve S4 support on operating systems that do
not have support for the direct method.
7.3.4.6 System
\_S5 State (Soft Off)
The S5 state is
similar to the S4 state except that OSPM does not save any context. The system
is in the soft off state and requires a complete boot when awakened (BIOS and
OS). Software uses a different state value to distinguish between this state
and the S4 state to allow for initial boot operations within the BIOS to
distinguish whether or not the boot is going to wake from a saved memory image.
OSPM does not disable wake events before setting the SLP_EN bit when entering
the S5 system state. This provides support for remote management initiatives by
enabling Remote Start capability. An ACPI-compliant OS must provide an end user
accessible mechanism for disabling all wake devices, with the exception of the
system power button, from a single point in the user interface.
7.3.5 _SWS (System Wake Source)
This object provides a means for OSPM to definitively determine
the source of an event that caused the system to enter the S0 state. General-purpose
event and fixed-feature hardware registers containing wake event sources
information are insufficient for this purpose as the source event information
may not be available after transitions to the S0 state from all other system
states (S1-S5). To determine the source event that caused the system to
transition to the S0 state, OSPM will evaluate the _SWS object, when it exists,
under the \_GPE scope (for all fixed-feature general-purpose events from the
GPE Blocks), under the \_SB scope (for fixed-feature hardware events), and
within the scope of a GPE Block device (for GPE events from this device). _SWS
objects may exist in any or all of these locations as necessary for the
platform to determine the source event that caused the system to transition to
the S0 state.
To enable OSPM to determine the source of the S0 state transition
via the _SWS object, hardware or firmware should detect and save the event
that caused the transition so that it can be returned during _SWS object
evaluation. The single wake source for the system may be latched in hardware
during the transition so that no false wake events can be returned by _SWS
implementation that does not use hardware to latch a single wake source for the
system and instead uses firmware to save the wake source must do so as quickly
as possible after the wakeup event occurs, so that _SWS does not return values
that correspond to events that occurred after the sleep-to-wake transition.
Such an implementation must also take care to ensure that events that occur
subsequent to the wakeup source being saved do not overwrite the original
wakeup source. The source event data returned by _SWS must be determined for
each transition into the S0 state. The value returned by _SWS must also be
persistent during the system's residency in the S0 state as OSPM may evaluate
_SWS multiple times. In this case, the platform must return the same source
event information for each invocation.
Arguments:
None
Result Code
SourceEvent: DWordConst
Where:
SourceEvent is the index of the GPE input that caused the system to
transition to the S0 state if OSPM evaluates _SWS under the \_GPE scope.
SourceEvent is the index of the GPE input that caused the system to
transition to the S0 state if OSPM evaluates _SWS within the scope of a GPE
Block device. In this case the index is relative to the GPE block device, and
is not unique system-wide.
SourceEvent is the index in the PM1 Status register that caused the
system to transition to the S0 state if OSPM evaluates _SWS under the \_SB
scope .
SourceEvent has all bits set (Ones) if the event that caused the system to
transition to the S0 state cannot be determined when OSPM evaluates _SWS under
any of the three scopes listed above.
After evaluating an _SWS object
within the \_GPE scope or within the scope of a GPE block device, OSPM will
invoke the _Wxx control method corresponding to the GPE index returned by _SWS
if it exists. This allows the platform to further determine source event if
the GPE is shared among multiple devices. See Section 5.6.2.2.4 for details.
7.3.6 \_TTS (Transition To State)
The _TTS control method is executed by the OSPM at the
beginning of the sleep transition process for S1, S2, S3, S4, and orderly S5
shutdown. OSPM will invoke _TTS before it has notified any native mode device
drivers of the sleep state transition. The sleeping state value (For example,
1, 2, 3, 4 or 5 for the S5 soft-off state) is passed to the _TTS
control method.
The _TTS control method is also executed by the OSPM at the
end of any sleep transition process when the system transitions to S0 from S1,
S2, S3, or S4. OSPM will invoke _TTS after it has notified any native mode
device drivers of the end of the sleep state transition. The working state
value (0) is passed to the _TTS control method.
If OSPM aborts the sleep transition process, OSPM will
still run _TTS for an S0 transition to indicate the OSPM has returned to the S0
state. The platform must assume that if OSPM invokes the _TTS control method
for an S1, S2, S3, or S4 transition, that OSPM will invoke _TTS control method
for an S0 transition before returning to the S0 state.
The platform must not make any assumptions about the state of
the machine when _TTS is called. For example, operation region accesses that
require devices to be configured and enabled may not succeed, as these devices
may be in a non-decoding state due to plug and play or power management
operations.
Arguments:
0: The
value of the sleeping state (1 for S1, 2 for S2, and so on)
7.3.7 \_WAK (System Wake)
After the system wakes from a sleeping state, it will
invoke the \_WAK method and pass the sleeping state value that has ended. This
operation occurs asynchronously with other driver notifications in the system
and is not the first action to be taken when the system wakes. The AML code for
this control method issues device, thermal, and other notifications to ensure
that OSPM checks the state of devices, thermal zones, and so on, that could not
be maintained during the system sleeping state. For example, if the system
cannot determine whether a device was inserted or removed from a bus while in
the S2 state, the _WAK method would issue a devicecheck type of notification for that bus when issued with
the sleeping state value of 2 (for more information about types of
notifications, see section 5.6.3, "Device Object Notifications"). Notice
that a device check notification from the \_SB node will cause OSPM to
re-enumerate the entire tree[11].
Hardware is not obligated to track the state needed to
supply the resulting status; however, this method must return status concerning
the last sleep operation initiated by OSPM. The result codes can be used to
provide additional information to OSPM or user.
Arguments:
0 The
value of the sleeping state (1 for S1, 2 for S2, and so on).
Result Code (2 DWORD package):
Status Bit
field of defined conditions that occurred during sleep.
0x00000000 Wake
was signaled and was successful
0x00000001 Wake
was signaled but failed due to lack of power.
0x00000002 Wake
was signaled but failed due to thermal condition.
Other Reserved
PSS If
non-zero, the effective S-state the power supply really entered.
This value is used to detect when the targeted S-state
was not entered because of too much current being drawn from the power supply.
For example, this might occur when some active device's current consumption
pushes the system's power requirements over the low power supply mark, thus
preventing the lower power mode from being entered as desired.
7.4 OSPM usage of _GTS, _PTS, _TTS, _WAK, and _BFS
OSPM will invoke _GTS, _PTS, _TTS, _WAK, and _BFS in the
following order:
1.OSPM decides (through a policy scheme) to place the
system into a sleeping state.
2._TTS(Sx) is run, where Sx is the desired sleep state to
enter.
3. OSPM notifies all native device drivers of the sleep
state transition
4._PTS is run
5.OSPM readies system for the sleep state transition
6._GTS is run
7.OSPM writes the sleep vector and the system enters the
specified Sx sleep state.
8.System Wakes up
9._BFS is run
10.OSPM readies system for the return from the sleep state
transition
11._WAK is run
12. OSPM notifies all native device drivers of the return
from the sleep state transition
13._TTS(0) is run to indicate the return to the S0 state.
Figure 7-1 Working / Sleeping State object
evaluation flow
8 Processor Power and Performance State Configuration and Control
This section describes the configuration and control of the
processor's power and performance states. The major controls over the
processors are:
· Processor
power states: C0, C1, C2, C3, … Cn
· 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 made.
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 configuration
and control interface is discussed in the following sections along with how
controls interacts with the various goals.
8.1 Processor Power States
ACPI defines the power state of system processors while
in the G0 working state as being either active (executing)
or sleeping (not executing). Processor power states include are designated C0,
C1, C2, C3, …Cn. The C0 power state is an active power state where the CPU
executes instructions. The C1 through Cn power states are processor sleeping
states where the processor consumes less power and dissipates less heat than
leaving the processor in the C0 state. While in a sleeping state, the processor
does not execute any instructions. Each processor sleeping state has a latency
associated with entering and exiting that corresponds to the power savings
general, the longer the entry/exit latency, the greater the power savings when
in the state. To conserve power, OSPM places the processor into one of its
supported sleeping states when idle. While in the C0 state, ACPI allows the
performance of the processor to be altered through a defined "throttling"
process and through transitions into multiple performance states (P-states). A
diagram of processor power states is provided below.
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 CPU's 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.
The platform may alternatively define interfaces allowing OSPM to enter
C-states using the _CST object, which is defined in Section 8.4.2.1, "_CST (C
States)".
Processor power state support is symmetric when presented
via the FADT and P_BLK interfaces; OSPM assumes all processors in a system
support the same power states. If processors have non-symmetric power 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
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.6, "System Description Table Header").
The following sections describe processor power states in
detail.
8.1.1 Processor Power State C0
While the processor is in the C0 power state, it executes
instructions. While in the C0 power state, OSPM can generate a policy to run
the processor at less than maximum performance. The clock throttling mechanism
provides OSPM with the functionality to perform this task in addition to
thermal control. The mechanism allows OSPM to program a value into a register
that reduces the processor's performance to a percentage of maximum
performance.
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)
performance of the processor by the clock logic can be expressed with the
following equation:
Equation 1 Duty Cycle Equation
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.
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 processor's 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):
Figure 8-3 Example
Control for the STPCLK#
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:
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 when
using the P_BLK and FADT interfaces; 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.
8.1.2 Processor Power State C1
All processors must support this power state. This state is
supported through a native instruction of the processor (HLT for IA 32-bit
processors), and assumes no hardware support is needed from the chipset
hardware latency of this state must be low enough that OSPM does not consider
the latency aspect of the state when deciding whether to use it. Aside from
putting the processor in a power state, this state has no other
software-visible effects. In the C1 power state, the processor is able to
maintain the context of the system caches.
The hardware can exit this state for any reason, but must
always exit this state when an interrupt is to be presented to the
processor.
8.1.3 Processor Power State C2
This processor power state is optionally supported by the system.
If present, the state offers improved power savings over the C1 state and is
entered by using the P_LVL2 command register for the local processor or an
alternative mechanism as indicated by the _CST object. The worst-case hardware
latency for this state is declared in the FADT and OSPM can use this
information to determine when the C1 state should be used instead of the C2
state. Aside from putting the processor in a power state, this state has no
other software-visible effects. OSPM assumes the C2 power state has lower power
and higher exit latency than the C1 power state.
The C2 power state is an optional ACPI clock state that
needs chipset hardware support. This clock logic consists of an interface that
can be manipulated to cause the processor complex to precisely transition into
a C2 power state. In a C2 power state, the processor is assumed capable of
keeping its caches coherent; for example, bus master and multiprocessor
activity can take place without corrupting cache context.
The C2 state puts the processor into a low-power state
optimized around multiprocessor and bus master systems. OSPM will cause an idle
processor complex to enter a C2 state if there are bus masters or Multiple
processor activity (which will prevent OSPM from placing the processor complex
into the C3 state). The processor complex is able to snoop bus master or
multiprocessor CPU accesses to memory while in the C2 state.
The hardware can exit this state for any reason, but must
always exit this state whenever an interrupt is to be presented to
the processor.
8.1.4 Processor Power State C3
This processor power state is optionally supported by the
system. If present, the state offers improved power savings over the C1 and C2
state and is entered by using the P_LVL3 command register for the local
processor or an alternative mechanism as indicated by the _CST object
worst-case hardware latency for this state is declared in the FADT, and OSPM
can use this information to determine when the C1 or C2 state should be used
instead of the C3 state. While in the C3 state, the processor's caches maintain
state but the processor is not required to snoop bus master or multiprocessor
CPU accesses to memory.
The hardware can exit this state for any reason, but must
always exit this state when an interrupt is to be presented to the processor or
when BM_RLD is set and a bus master is attempting to gain access to memory.
OSPM is responsible for ensuring that the caches maintain
coherency. In a uniprocessor environment, this can be done by using the
PM2_CNT.ARB_DIS bus master arbitration disable register to ensure bus master
cycles do not occur while in the C3 state. In a multiprocessor environment, the
processors' caches can be flushed and invalidated such that no dynamic
information remains in the caches before entering the C3 state.
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, "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
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: a lot 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
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.
8.1.5 Additional Processor Power
States
ACPI introduced optional processor power states beyond C3
starting in ACPI 2.0. These power states, C4… Cn, are conveyed to OSPM through
the _CST object defined in section 8.4.2.1, "_CST (C-States)." These additional
power states are characterized by equivalent operational semantics to the C1
through C3 power states, as defined in the previous sections, but with
different entry/exit latencies and power savings. See section 8.4.2.1, "_CST
(C-States)," for more information.
8.2 Flushing Caches
To support the C3 power state without using the ARB_DIS
feature, the hardware must provide functionality to flush and invalidate the
processors' caches (for an IA processor, this would be the WBINVD instruction).
To support the S1, S2 or S3 sleeping states, the hardware must provide
functionality to flush the platform caches. Flushing of caches is supported by
one of the following mechanisms:
· Processor instruction to write back and invalidate system caches
(WBINVD instruction for IA processors).
· Processor instruction to write back but not invalidate system
caches (WBINVD instruction for IA processors and some chipsets with partial
support; that is, they don't invalidate the caches).
The ACPI specification expects all platforms to support the
local CPU instruction for flushing system caches (with support in both the CPU
and chipset), and provides some limited "best effort" support for systems that
don't currently meet this capability. The method used by the platform is
indicated through the appropriate FADT fields and flags indicated in this
section.
ACPI specifies parameters in the FADT that describe the
system's cache capabilities. If the platform properly supports the processor's
write back and invalidate instruction (WBINVD for IA processors), then this
support is indicated to OSPM by setting the WBINVD flag in the FADT.
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.
8.3 Power, Performance, and
Throttling State Dependencies
Cost and complexity trade-off considerations have driven into
the platform control dependencies between logical processors when entering
power, performance, and throttling states. These dependencies exist in various
forms in multi-processor, multi-threaded processor, and multi-core
processor-based platforms. These dependencies may also be hierarchical
example, a multi-processor system consisting of processors containing multiple
cores containing multiple threads may have various dependencies as a result of
the hardware implementation.
Unless OSPM is aware of the dependency between the logical
processors, it might lead to scenarios where one logical processor is
implicitly transitioned to a power, performance, or throttling state when it is
unwarranted, leading to incorrect / non-optimal system behavior. Given
knowledge of the dependencies, OSPM can coordinate the transitions between
logical processors, choosing to initiate the transition when doing so does not
lead to incorrect or non-optimal system behavior. This OSPM coordination is
referred to as Software (SW) Coordination. Alternately, it might be possible
for the underlying hardware to coordinate the state transition requests on
multiple logical processors, causing the processors to transition to the target
state when the transition is guaranteed to not lead to incorrect or non-optimal
system behavior. This scenario is referred to as Hardware (HW) coordination.
When hardware coordinates transitions, OSPM continues to initiate state
transitions as it would if there were no dependencies. However, in this case it
is required that hardware provide OSPM with a means to determine actual state
residency so that correct / optimal control policy can be realized.
Platforms containing logical processors with
cross-processor dependencies in the power, performance, or throttling state
control areas use ACPI defined interfaces to group logical processors into what
is referred to as a dependency domain. The Coordination Type characteristic for
a domain specifies whether OSPM or underlying hardware is responsible for the
coordination. When OSPM coordinates, the platform may require that OSPM transition
ALL (0xFC) or ANY ONE (0xFD) of the processors belonging to the domain into a
particular target state. OSPM may choose at its discretion to perform
coordination even though the underlying hardware supports hardware
coordination. In this case, OSPM must transition all logical processors in the
dependency domain to the particular target state.
There are no dependencies implied between a processor's
C-states, P-states or T-states. Hence, for example it is possible to use the
same dependency domain number for specifying dependencies between P-states
among one set of processors and C-states among another set of processors
without any dependencies being implied between the P-State transitions on a
processor in the first set and C-state transitions on a processor in the second
set.
8.4 Declaring Processors
Each processor in the system must be declared in the ACPI
namespace in either the \_SB or \_PR scope but not both. Declaration of
processor in the \_PR scope is required for platforms desiring compatibility
with ACPI 1.0-based OSPM implementations. Processors are declared either via
the ASL Processor statement or the ASL Device statement. A Processor
> definition declares a processor object that provides
processor configuration information and points to the processor register block
(P_BLK). A Device definition for
a processor is declared using the ACPI0007 hardware identifier (HID). In this
case, processor configuration information is provided exclusively by objects in
the processor device's object list.
When the platform uses the APIC interrupt model, OSPM
associates processors declared in the namespace with entries in the MADT. Prior
to ACPI 3.0, this was accomplished using the processor object's ProcessorID and
the ACPI Processor ID fields in MADT entries. UID fields have been added to
MADT entries in ACPI 3.0. By expanding processor declaration using Device definitions, UID object values under a processor
device can now be used to associate processor devices with entries in the MADT.
This removes the previous 256 processor declaration limit.
Processor-specific objects may be included in the processor
object's optional object list or declared within the processor device's scope.
These objects serve multiple purposes including providing alternative
definitions for the registers described by the processor register block (P_BLK)
and processor performance state control. Other ACPI-defined device-related
objects are also allowed in the processor object's object list or under the
processor device's scope (for example, the unique identifier object _UID).
With device-like characteristics attributed to processors,
it is implied that a processor device driver will be loaded by OSPM to, at a
minimum, process device notifications. OSPM will enumerate processors in the
system using the ACPI Namespace, processor-specific native identification
instructions, and optionally the _HID method.
OSPM will ignore definitions of ACPI-defined objects in an
object list of a processor object declared under the \_PR namespace.
For more information on the declaration of the processor
object, see section 17.5.93, "Processor (Declare Processor)." Processor-specific
objects are described in the following sections.
8.4.1 _PDC (Processor Driver
Capabilities)
This optional object is a method that is used by OSPM to
communicate to the platform the level of processor power management support provided
by OSPM. This object is a child object of the processor. OSPM evaluates _PDC
prior to evaluating any other processor power management objects returning
configuration information.
The _PDC object provides OSPM a mechanism to convey to the
platform the capabilities supported by OSPM for processor power management.
This allows the platform to modify the ACPI namespace objects returning
configuration information for processor power management based on the level of
support provided by OSPM. Using this method provides a mechanism for OEMs to
provide support for new technologies on legacy OSes, while also allowing OSPM
to leverage new technologies on platforms capable of supporting them. This
method is evaluated once during processor device initialization, and will not
be re-evaluated during resume from a sleep state transition. The platform must
preserve state information across S1-S3 sleep state transitions.
Syntax
_PDC (PDCBuffer)=> Null
Arguments
PDCBuffer
DWordConst
Buffer (RevisionID, Count, CapabilitiesDWORD1
style='font-size:90%'>,…,CapabilitiesDWORDn)
RevisionID
The revision ID of the CapabilitiesDWORD
format.
Count
The number of CapabilitiesDWORD
style='font-size:90%;font-family:"Courier New"'> values in the buffer.
CapabiltiesDWORD1-n
Capabilities DWords, where
each bit defines capabilities and features supported by OSPM for processor configuration
and power management as specified by the CPU manufacturer.
The use of _PDC is deprecated in
ACPI 3.0 in favor of _OSC. For backwards compatibility, _PDC may be implemented
using _OSC as follows:
Method(_PDC,1)
{
CreateDwordField (Arg0, 0, REVS)
CreateDwordField (Arg0, 4, SIZE)
//
// Local0 = Number of bytes for Arg0
//
Store (SizeOf (Arg0), Local0)
//
// Local1 = Number of Capabilities bytes in
Arg0
//
Store (Subtract (Local0, 8), Local1)
//
// TEMP = Temporary field holding Capability
DWORDs
//
CreateField (Arg0, 64, Multiply (Local1, 8),
TEMP)
//
// Create the Status (STS0) buffer with the
first DWORD = 0
// This is required to return errors defined
by _OSC.
//
Name (STS0, Buffer () {0x00, 0x00, 0x00,
0x00})
//
// Concatenate the _PDC capabilities bytes to
the STS0 Buffer
// and store them in a local variable for
calling OSC
//
Concatenate (STS0, TEMP, Local2)
// Note: The UUID passed into _OSC is CPU
vendor specific. Consult CPU
// vendor documentation for UUID and
Capabilities Buffer bit definitions
_OSC
(ToUUID("4077A616-290C-47BE-9EBD-D87058713953"), REVS, SIZE, Local2)
}
Section 6.2.9, "_OSC (Operating System Capabilities)",
describes the _OSC object, which can be used to convey processor related OSPM
capabilities to the platform. Consult CPU vendor specific documentation for the
UUID and Capabilities Buffer bit definitions used by _OSC for a specific
processor.
8.4.2 Processor
Power State Control
ACPI defines two processor power state (C state) control
interfaces. These are:
1) The Processor
Register Block's (P_BLK's) P_LVL2 and P_LVL3 registers coupled with FADT
P_LVLx_LAT values and
2) The _CST
object in the processor's object list.
P_BLK based C state controls are described in Section 4,
"ACPI Hardware Specification" and Section 8.1, "Processor Power States". _CST
based C state controls expand the functionality of the P_BLK based controls
allowing the number and type of C states to be dynamic and accommodate CPU
architecture specific C state entry and exit mechanisms as indicated by
registers defined using the Functional Fixed Hardware address space.
8.4.2.1 _CST (C States)
_CST is an optional object that provides an alternative
method to declare the supported processor power states (C States). Values
provided by the _CST object override P_LVLx values in P_BLK and P_LVLx_LAT
values in the FADT. The _CST object allows the number of processor power states
to be expanded beyond C1, C2, and C3 to an arbitrary number of power states.
The entry semantics for these expanded states, (in other words), the
considerations for entering these states, are conveyed to OSPM by the
C-state_Type field and correspond to the entry semantics for C1, C2, and C3 as
described in sections 8.1.2 through 8.1.4. _CST defines ascending C-states
characterized by lower power and higher entry/exit latency.
Syntax
_CST => CSTPackage
Return Value
CSTPackage: Package (Count, CState,…, CState) where:
Count:
style='font-size:90%;font-family:"Courier New"'>ByteConst
The number of CState packages
included in CSTPackage
CState: Package (Register, Type,
style='font-size:80%;font-family:"Courier New";font-style:normal'> Latency, Power)
Where:
Register: RegisterTerm
A register that OSPM reads
to place the processor in the corresponding C state.
Type: ByteConst
The C State type (for
example, 1=C1, 2=C2, 3=C3). This field conveys the semantics to be used by OSPM
when entering/exiting the C state. Zero is not a valid value
Latency: WordConst
The worst-case latency in
microseconds to enter and exit the C State. There are no latency restrictions.
Power: DWordConst
The average power
consumption in milliwatts of the processor when in the corresponding C State.
The platform must expose a _CST object for either all or
none of its processors. If the _CST object exists, OSPM uses the C state information
specified in the _CST object 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 C_State_Register registers in the _CST object.
The platform may change the number or type of C States
available for OSPM use dynamically by issuing a Notify events on the processor object with a notification
value of 0x81. This will cause OSPM to re-evaluate any _CST object residing
under the processor object notified. For example, the platform might notify
OSPM that the number of supported C States has changed as a result of an
asynchronous AC insertion / removal event.
The platform must specify unique C_State_Register addresses
for all entries within a given _CST object.
_CST eliminates the ACPI 1.0 restriction that all
processors must have C State parity. With _CST, each processor can have its
own characteristics independent of other processors. For example, processor 0
can support C1, C2 and C3, while processor 1 supports only C1.
The fields in the processor structure remain for backward
compatibility.
EXAMPLE
Processor (
\_SB.CPU0, //
Processor Name
1, //
ACPI Processor number
0x120, //
PBlk system IO address
6 ) //
PBlkLen
{
Name(_CST, Package()
{
4, // There are
four C-states defined here with three semantics
//
The third and fourth C-states defined have the same C3 entry semantics
Package(){ResourceTemplate(){Register(FFixedHW,
0, 0, 0)}, 1, 20, 1000},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x161)}, 2, 40, 750},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x162)}, 3, 60, 500},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x163)}, 3, 100, 250}
})
}
Notice in the example above that OSPM should anticipate the
possibility of a _CST object providing more than one entry with the same
C_State_Type value. In this case OSPM must decide which C_State_Register it
will use to enter that C state.
EXAMPLE
This is an example usage of the _CST object using the typical values as 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.
8.4.2.2 _CSD
(C-State Dependency)
This
optional object provides C-state control cross logical processor dependency
information to OSPM. The _CSD object evaluates to a packaged list of
information that correlates with the C-state information returned by the _CST
object. Each packaged list entry identifies the C-state for which the
dependency is being specified (as an index into the _CST object list), a dependency
domain number for that C-state, the coordination type for that C-state and the
number of logical processors belonging to the domain for the particular
C-state. It is possible that a particular C-state may belong to multiple
domains. That is, it is possible to have multiple entries in the _CSD list with
the same CStateIndex value.
Syntax
_CSD => CSDPackage
Return Value
CSDPackage:Package (CStateDep,…,
style='font-size:80%;font-family:"Courier New"'>CStateDep)
Where:
CStateDep: Package (NumberOfEntries, Revision, Domain,
style='font-size:80%;font-family:"Courier New";font-style:normal'>
CoordType, NumProcessors, Index)
Where:
NumberOfEntries:ByteConst
The number
of entries in the CStateDep
package including this field. Current value is 6.
Revision:
style='font-size:90%;font-family:"Courier New"'>ByteConst
The revision
number of the CStateDep
package format. Current value is 0.
Domain: DWordConst
The dependency domain number
to which this C state entry belongs.
CoordType: DWordConst
The type of coordination
that exists (hardware) or is required (software) as a result of the underlying
hardware dependency. Could be either 0xFC (SW_ALL), 0xFD (SW_ANY) or 0xFE (HW_ALL)
indicating whether OSPM is responsible for coordinating the C-state transitions
among processors with dependencies (and needs to initiate the transition on all
or any processor in the domain) or whether the hardware will perform this
coordination.
NumProcessors: DWordConst
The number of processors
belonging to the domain for the particular C-state. OSPM will not start
performing power state transitions to a particular C-state until this number of
processors belonging to the same domain for the particular C-state have been
detected and started.
Index: DWordConst
Indicates the index of the
C-State entry in the _CST object for which the dependency applies.
Given that the number or type of available C States may
change dynamically, ACPI supports Notify events on the processor object, with
Notify events of type 0x81 causing OSPM to re-evaluate any _CST objects
residing under the particular processor object notified. On receipt of Notify
events of type 0x81, OSPM should re-evaluate any present _CSD objects also.
EXAMPLE
This is an example usage of the _CSD structure in a
Processor structure in the name space. The example represents a two processor
configuration. The C1-type state can be independently entered on each
processor. For the C2-type state, there exists dependence between the two
processors, such that one processor transitioning to the C2-type state, causes
the other processor to transition to the C2-type state. A similar dependence
exists for the C3-type state. OSPM will be required to coordinate the C2 and C3
transitions between the two processors. Also OSPM can initiate a transition on
either processor to cause both to transition to the common target C-state.
Processor (
\_SB.CPU0, //
Processor Name
1, //
ACPI Processor number
0x120, //
PBlk system IO address
6 ) //
PBlkLen
{
Name (_CST, Package()
{
3, //
There are three C-states defined here with three semantics
Package(){ResourceTemplate(){Register(FFixedHW,
0, 0, 0)}, 1, 20, 1000},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x161)}, 2, 40, 750},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x162)}, 3, 60, 500}
})
Name(_CSD, Package()
{
Package(){6, 0, 0, 0xFD,
2, 1}, // 6 entries, Revision 0, Domain 0, OSPM Coordinate
// Initiate on Any Proc, 2 Procs, Index 1 (C2-type)
Package(){6, 0, 0, 0xFD,
2, 2} // 6 entries, Revision 0, Domain 0, OSPM Coordinate
// Initiate on Any Proc, 2 Procs, Index 2 (C3-type)
})
}
Processor (
\_SB.CPU1, //
Processor Name
2, //
ACPI Processor number
, //
PBlk system IO address
) //
PBlkLen
{
Name(_CST, Package()
{
3, //
There are three C-states defined here with three semantics
Package(){ResourceTemplate(){Register(FFixedHW,
0, 0, 0)}, 1, 20, 1000},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x161)}, 2, 40, 750},
Package(){ResourceTemplate(){Register(SystemIO,
8, 0, 0x162)}, 3, 60, 500}
})
Name(_CSD, Package()
{
Package(){6, 0, 0, 0xFD,
2, 1}, // 6 entries, Revision 0, Domain 0, OSPM Coordinate
// Initiate on any Proc, 2 Procs, Index 1 (C2-type)
Package(){6, 0, 0, 0xFD,
2, 2} // 6 entries, Revision 0, Domain 0, OSPM Coordinate
// Initiate on any Proc, 2 Procs, Index 2 (C3-type)
})
}
When the platform issues a Notify(\_SB.CPU0, 0x81) to inform OSPM to
re-evaluate _CST when the number of available processor power states changes,
OSPM should also evaluate _CSD.
8.4.3 Processor
Throttling Controls
ACPI defines two processor throttling (T state) control
interfaces. These are:
1) The Processor
Register Block's (P_BLK's) P_CNT register and
2) The
combined _PTC, _TSS, and _TPC objects in the processor's object list.
P_BLK based throttling state controls are described in
Section 4, "ACPI Hardware Specification" and Section 8.1.1, "Processor Power
State C0". Combined _PTC, _TSS, and _TPC based throttling state controls expand
the functionality of the P_BLK based control allowing the number of T states to
be dynamic and accommodate CPU architecture specific T state control mechanisms
as indicated by registers defined using the Functional Fixed Hardware address
space. While platform definition of the _PTC, _TSS, and _TPC objects is optional,
all three objects must exist under a processor for OSPM to successfully perform
processor throttling via these controls.
8.4.3.1 _PTC
(Processor Throttling Control)
_PTC is an optional object that defines a processor
throttling control interface alternative to the I/O address spaced-based P_BLK
throttling control register (P_CNT) described in section 4, "ACPI Hardware
Specification". The processor throttling control register mechanism remains as
defined in section 8.1.1, " Processor Power State C0."
OSPM performs processor throttling control by writing the
Control field value for the target throttling state (T-state), retrieved from
the Throttling Supported States object (_TSS), to the Throttling Control
Register (THROTTLE_CTRL) defined by the _PTC object. OSPM may select any
processor throttling state indicated as available by the value returned by the
_TPC control method.
Success or failure of the processor throttling state
transition is determined by reading the Throttling Status Register
(THROTTLE_STATUS) to determine the processor's current throttling state. If the
transition was successful, the value read from THROTTLE_STATUS will match the
"Status" field in the _TSS entry that corresponds to the targeted processor
throttling state.
The _PTC object contains data in the following format:
Name (_PTC, Package()
{
ResourceTemplate(){Throttling_Control_Register}, //Generic
Register Descriptor
ResourceTemplate(){Throttling_Status_Register} //Generic Register Descriptor
}) // End of _PTC
The platform must expose a _PTC object for either all or
none of its processors. 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, //
Processor Name
1, //
ACPI Processor number
0x120, //
PBlk system IO address
6 ) //
PBlkLen
{ //Object List
Name(_PTC, Package () //
Processor Throttling Control object
{
ResourceTemplate(){Register(FFixedHW,
0, 0, 0)}, // Throttling_CTRL
ResourceTemplate(){Register(FFixedHW,
0, 0, 0)} // Throttling_STATUS
}) // End of _PTC object
} // End of Object List
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, // Processor Name
1, //
ACPI Processor number
0x120, //
PBLK system IO address
6 ) //
PBLK Len
{ //Object List
Name(_PTC,
Package () // Processor Throttling Control object –
//32
bit wide IO space-based register at the <P_BLK> address
{
ResourceTemplate(){Register(SystemIO,
32, 0, 0x120)}, // Throttling_CTRL
ResourceTemplate(){Register(SystemIO,
32, 0, 0x120)} // Throttling_STATUS
}) // End of _PTC object
} // End of Object List
8.4.3.2 _TSS
(Throttling Supported States)
This optional object indicates to OSPM the number of
supported processor throttling states that a platform supports. This object
evaluates to a packaged list of information about available throttling states
including percentage of maximum internal CPU core frequency, maximum power
dissipation, control register values needed to transition between throttling
states, and status register values that allow OSPM to verify throttling state
transition status after any OS-initiated transition change request. The list is
sorted in descending order by power dissipation. As a result, the zeroth entry
describes the highest performance throttling state (no throttling applied) and
the 'nth' entry describes the lowest performance
throttling state (maximum throttling applied).
Name (_TSS, Package()
{ // Field Name Field
Type
Package () //
Throttle State 0 Definition – T0
{
FreqPercentageOfMaximum, //
DWordConst
Power, //
DWordConst
TransitionLatency, //
DWordConst
Control, //
DWordConst
Status //
DWordConst
},
.
.
.
Package () //
Throttle State n Definition – Tn
{
FreqPercentageOfMaximum, //
DWordConst
Power, //
DWordConst
TransitionLatency, //
DWordConst
Control, //
DWordConst
Status //
DWordConst
}
}) // End of _TSS object
Each throttling state entry contains five data fields as
follows:
· FreqPercentageOfMaximum. Indicates the percent of the core CPU operating
frequency that will be available when this throttling state is invoked
range for this field is 1-100. This percentage applies independent of the
processor's performance state (P-state). That is, this throttling state will
invoke the percentage of maximum frequency indicated by this field as applied
to the CoreFreq
field of the_PSS entry corresponding to the P-state for which the processor is currently
resident.
· Power.
Indicates the throttling state's maximum power dissipation (in milliWatts). OSPM
ignores this field on platforms the support P-states, which provide power
dissipation information via the _PSS object.
· TransitionLatency.
Indicates the worst-case latency in microseconds that the CPU is
unavailable during a transition from any throttling state to this throttling
state.
· Control. Indicates
the value to be written to the Processor Control Register (THROTTLE_CTRL) in
order to initiate a transition to this throttling state.
· Status. Indicates
the value that OSPM will compare to a value read from the Throttle Status
Register (THROTTLE_STATUS) to ensure that the transition to the throttling
state was successful. OSPM may always place the CPU in the lowest power throttling
state, but additional states are only available when indicated by the _TPC control
method. A value of zero indicates the transition to the Throttling state is
asynchronous, and as such no status value comparison is required.
When providing the
_TSS, the platform must supply a _TSS entry whose FreqPercentageOfMaximum
field value is 100.
This provides a means for OSPM to disable throttling and achieve maximum
performance.
8.4.3.3 _TPC
(Throttling Present Capabilities)
This optional object is a method that dynamically indicates
to OSPM the number of throttling states currently supported by the platform.
This method returns a number that indicates the _TSS entry number of the
highest power throttling state that OSPM can use at a given time. OSPM may
choose the corresponding state entry in the _TSS as indicated by the value
returned by the _TPC method or any lower power (higher numbered) state entry in
the _TSS.
Arguments:
None
Returned Value:
Number
of states supported (integer)
0
– states 0 .. nth state available (all states available)
1
– state 1 .. nth state available
2
– state 2 .. nth state available
…
n – state n available only
In order to support dynamic changes of _TPC object, Notify
events on the processor object of type 0x82 will cause OSPM to reevaluate any _TPC
object in the processor's object list. This allows AML code to notify OSPM when
the number of supported throttling states may have changed as a result of an
asynchronous event. OSPM ignores _TPC Notify events on platforms that support
P-states unless the platform has limited OSPM's use of P-states to the lowest
power P-state. OSPM may choose to disregard any platform conveyed T-state
limits when the platform enables OSPM usage of other than the lowest power
P-state.
8.4.3.4 _TSD
(T-State Dependency)
This optional object provides T-state control cross logical
processor dependency information to OSPM. The _TSD object evaluates to a
packaged list of information that correlates with the T-state information
returned by the _TSS object. Each packaged list entry identifies a dependency
domain number for the logical processor's T-states, the coordination type for
that T-state and the number of logical processors belonging to the domain.
Syntax
_TSD => TSDPackage
Return Value
TSDPackage: Package (TStateDep,…, TStateDep)
Where:
TStateDep: Package (NumberOfEntries, Revision, Domain,
style='font-size:80%;font-family:"Courier New";font-style:normal'> CoordType,
NumProcessors)
Where:
NumberOfEntries:ByteConst
The number
of entries in the TStateDep
package including this field. Current value is 5.
Revision:
style='font-size:90%;font-family:"Courier New"'>ByteConst
The revision
number of the TStateDep
package format. Current value is 0.
Domain: DWordConst
The dependency domain number
to which this T-state entry belongs.
CoordType: DWordConst
The type of coordination
that exists (hardware) or is required (software) as a result of the underlying
hardware dependency. Could be either 0xFC (SW_ALL), 0xFD (SW_ANY) or 0xFE
(HW_ALL) indicating whether OSPM is responsible for coordinating the T-state
transitions among processors with dependencies (and needs to initiate the
transition on all or any processor in the domain) or whether the hardware will
perform this coordination.
NumProcessors: DWordConst
The number of processors
belonging to the domain for this logical processor's T-states. OSPM will not
start performing power state transitions to a particular T-state until this
number of processors belonging to the same domain have been detected and
started.
EXAMPLE
This is an example usage of the _TSD structure in a
Processor structure in the name space. The example represents a two processor
configuration with three T-states per processor. For all T-states, there exists
dependence between the two processors, such that one processor transitioning to
a particular T-state, causes the other processor to transition to the same
T-state. OSPM will be required to coordinate the T-state transitions between
the two processors and can initiate a transition on either processor to cause
both to transition to the common target T-state.
Processor (
\_SB.CPU0, //
Processor Name
1, //
ACPI Processor number
0x120, //
PBlk system IO address
6) //
PBlkLen
{ //Object List
Name(_PTC, Package () //
Processor Throttling Control object –
//32
bit wide IO space-based register at the <P_BLK> address
{
ResourceTemplate(){Register(SystemIO,
32, 0, 0x120)}, // Throttling_CTRL
ResourceTemplate(){Register(SystemIO,
32, 0, 0x120)} // Throttling_STATUS
}) // End of _PTC object
Name (_TSS, Package()
{
Package()
{
0x64, //
Frequency Percentage (100%, Throttling OFF state)
0x0, //
Power
0x0, //
Transition Latency
0x7, //
Control THT_EN:0 THTL_DTY:111
0x0, //
Status
}
Package()
{
0x58, //
Frequency Percentage (87.5%)
0x0, //
Power
0x0, //
Transition Latency
0xF, //
Control THT_EN:1 THTL_DTY:111
0x0, //
Status
}
Package()
{
0x4B, //
Frequency Percentage (75%)
0x0, //
Power
0x0, //
Transition Latency
0xE, //
Control THT_EN:1 THTL_DTY:110
0x0, //
Status
}
})
Name (_TSD, Package()
{
Package(){5,
0, 0, 0xFD, 2} // 5 entries, Revision 0, Domain 0,
OSPM Coordinate, 2 Procs
}) // End of _TSD object
Method (_TPC, 0) //
Throttling Present Capabilities method
{
If
(\_SB.AC)
{
Return(0) //
All Throttle States are available for use.
}
Else
{
Return(2) //
Throttle States 0 an 1 won't be used.
}
} // End of _TPC method
} // End of processor object list
Processor (
\_SB.CPU1, //
Processor Name
2, //
ACPI Processor number
, //
PBlk system IO address
) //
PBlkLen
{ //Object List
Name(_PTC, Package () //
Processor Throttling Control object –
//32
bit wide IO space-based register at the <P_BLK> address
{
ResourceTemplate(){Register(SystemIO,
32, 0, 0x120)}, // Throttling_CTRL
ResourceTemplate(){Register(SystemIO,
32, 0, 0x120)} // Throttling_STATUS
}) // End of _PTC object
Name (_TSS, Package()
{
Package()
{
0x64, //
Frequency Percentage (100%, Throttling OFF state)
0x0, //
Power
0x0, //
Transition Latency
0x7, //
Control THT_EN:0 THTL_DTY:111
0x0, //
Status
}
Package()
{
0x58, //
Frequency Percentage (87.5%)
0x0, //
Power
0x0, //
Transition Latency
0xF, //
Control THT_EN:1 THTL_DTY:111
0x0, //
Status
}`
Package()
{
0x4B, //
Frequency Percentage (75%)
0x0, //
Power
0x0, //
Transition Latency
0xE, //
Control THT_EN:1 THTL_DTY:110
0x0, //
Status
}
})
Name (_TSD, Package()
{
Package(){5,
0, 0, 0xFD, 2} // 5 entries, Revision 0, Domain 0,
OSPM Coordinate, 2 Procs
}) // End of _TSD object
Method (_TPC, 0) //
Throttling Present Capabilities method
{
If
(\_SB.AC)
{
Return(0) //
All Throttle States are available for use.
}
Else
{
Return(2) //
Throttle States 0 an 1 won't be used.
}
} // End of _TPC method
} // End of processor object list
8.4.4 Processor Performance Control
Processor performance control is implemented through three
optional objects whose presence indicates to OSPM that the platform and CPU are
capable of supporting multiple performance states. The platform must supply all
three objects if processor performance control is implemented. The platform
must expose processor performance control objects for either all or none of its
processors. The processor performance control objects define the supported
processor performance states, allow the processor to be placed in a specific
performance state, and report the number of performance states currently
available on the system.
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.
8.4.4.1 _PCT (Performance Control)
This optional object declares an interface that allows OSPM
to transition the processor into a performance state. OSPM performs processor
performance transitions by writing the performance state–specific control
value to a Performance Control Register (PERF_CTRL).
OSPM may select a processor performance state as indicated
by the performance state value returned by the _PPC method, or any lower power
(higher numbered) state. The control value to write is contained in the
corresponding _PSS entry's "Control" field.
Success or failure of the processor performance transition
is determined by reading a Performance Status Register (PERF_STATUS) to
determine the processor's current performance state. If the transition was
successful, the value read from PERF_STATUS will match the "Status" field in
the _PSS entry that corresponds to the desired processor performance state.
This object evaluates to a package that declares the
above-mentioned transition control and status addresses as follows:
Name (_PCT, Package()
{
ResourceTemplate(){Perf_Ctrl_Register}, //Generic Register Descriptor
ResourceTemplate(){Perf_Status_Register} //Generic Register
Descriptor
}) // End of _PCT
8.4.4.2 _PSS (Performance Supported
States)
This optional object indicates to OSPM the number of
supported processor performance states that any given system can support. This
object evaluates to a packaged list of information about available performance
states including internal CPU core frequency, typical power dissipation,
control register values needed to transition between performance states, and
status register values that allow OSPM to verify performance transition status
after any OS-initiated transition change request. The list is sorted in
descending order by typical power dissipation. As a result, the zeroth entry
describes the highest performance state and the 'nth' entry describes the lowest performance state.
Name (_PSS, Package()
{ // Field Name Field
Type
Package () //
Performance State 0 Definition – P0
{
CoreFreq, //
DWordConst
Power, //
DWordConst
TransitionLatency, //
DWordConst
BusMasterLatency, //
DWordConst
Control, //
DWordConst
Status //
DWordConst
},
.
.
.
Package () //
Performance State n Definition –Pn
{
CoreFreq, //
DWordConst
Power, //
DWordConst
TransitionLatency, //
DWordConst
BusMasterLatency, //
DWordConst
Control, //
DWordConst
Status //
DWordConst
}
}) // End of _PSS object
Each performance state entry contains six data fields as
follows:
· CoreFreq.
Indicates the core CPU operating frequency (in MHz).
· Power.
Indicates the performance state's maximum 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.
8.4.4.3 _PPC (Performance Present
Capabilities)
This optional object is a method that dynamically indicates
to OSPM the number of performance states currently supported by the platform.
This method returns a number that indicates the _PSS entry number of the
highest performance state that OSPM can use at a given time. OSPM may choose
the corresponding state entry in the _PSS as indicated by the value returned by
the _PPC method or any lower power (higher numbered) state entry in the _PSS.
Arguments:
None
Returned Value:
Number
of states supported (integer)
0 states
0 .. nth state available (all states available)
1 state
1 .. nth state available
2 state
2 .. nth state available
…
n state
n available only
In order to support dynamic changes of _PPC object, Notify
events on the processor object. Notify events of type 0x80 will cause OSPM to
reevaluate any _PPC objects residing under the particular processor object
notified. This allows AML code to notify OSPM when the number of supported
states may have changed as a result of an asynchronous event (AC
insertion/removal, docked, undocked, and so on).
8.4.4.4 Processor
Performance Control Example
EXAMPLE:
This is an example of processor performance control objects
in a processor object list.
In this example, a uniprocessor platform that has processor
performance capabilities with support for three performance states as follows:
1. 500 MHz (8.2W) supported at any time
2. 600 MHz (14.9W) supported only when AC powered
3. 650 MHz (21.5W) supported only when docked
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: Evaluates to 1 if
system is docked, zero otherwise.
\_SB.AC: 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)}, // PERF_CTRL
ResourceTemplate(){Register(FFixedHW,
0, 0, 0)} //
PERF_STATUS
}) // End of _PCT object
Name (_PSS, Package()
{
Package(){650,
21500, 500, 300, 0x00, 0x08}, // Performance State zero (P0)
Package(){600,
14900, 500, 300, 0x01, 0x05}, // Performance State one (P1)
Package(){500,
8200, 500, 300, 0x02, 0x06} // Performance State two (P2)
}) // End of _PSS object
Method (_PPC, 0) //
Performance Present Capabilities method
{
If
(\_SB.DOCK)
{
Return(0) //
All _PSS states available (650, 600, 500).
}
If
(\_SB.AC)
{
Return(1) //
States 1 and 2 available (600, 500).
}
Else
{
Return(2) //
State 2 available (500)
}
} // End of _PPC method
} // End of processor object list
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.
8.4.4.5 _PSD
(P-State Dependency)
This optional object provides P-state control cross logical
processor dependency information to OSPM. The _PSD object evaluates to a
packaged list of information that correlates with the P-state information returned
by the _PSS object. Each packaged list entry identifies a dependency domain
number for the logical processor's P-states, the coordination type for that
P-state and the number of logical processors belonging to the domain.
Syntax
_PSD => PSDPackage
Return Value
PSDPackage: Package (PStateDep,…, PStateDep)
Where:
PStateDep: Package (NumberOfEntries, Revision, Domain,
style='font-size:80%;font-family:"Courier New";font-style:normal'>
CoordType, NumProcessors)
Where:
NumberOfEntries:ByteConst
The number
of entries in the PStateDep
package including this field. Current value is 5.
Revision:
style='font-size:90%;font-family:"Courier New"'>ByteConst
The revision
number of the PStateDep
package format. Current value is 0.
Domain: DWordConst
The dependency domain number
to which this P-state entry belongs.
CoordType: DWordConst
The type of coordination
that exists (hardware) or is required (software) as a result of the underlying
hardware dependency. Could be either 0xFC (SW_ALL), 0xFD (SW_ANY) or 0xFE
(HW_ALL) indicating whether OSPM is responsible for coordinating the P-state
transitions among processors with dependencies (and needs to initiate the
transition on all or any processor in the domain) or whether the hardware will
perform this coordination.
NumProcessors: DWordConst
The number of processors
belonging to the domain for this
logical processor's P-states. OSPM will not start performing power state
transitions to a particular P-state until this number of processors belonging
to the same domain have been detected and started.
EXAMPLE
This is an example usage of the _PSD structure in a
Processor structure in the name space. The example represents a two processor
configuration with three performance states per processor. For all performance
states, there exists dependence between the two processors, such that one
processor transitioning to a particular performance state, causes the other
processor to transition to the same performance state. OSPM will be required to
coordinate the P-state transitions between the two processors and can initiate
a transition on either processor to cause both to transition to the common
target P-state.
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)}, // PERF_CTRL
ResourceTemplate(){Register(FFixedHW,
0, 0, 0)} //
PERF_STATUS
}) // End of _PCT object
Name (_PSS, Package()
{
Package(){650,
21500, 500, 300, 0x00, 0x08}, // Performance State zero (P0)
Package(){600,
14900, 500, 300, 0x01, 0x05}, // Performance State one (P1)
Package(){500,
8200, 500, 300, 0x02, 0x06} // Performance State two (P2)
}) // End of _PSS object
Method (_PPC, 0) //
Performance Present Capabilities method
{
} // End of _PPC method
Name (_PSD, Package()
{
Package(){5,
0, 0, 0xFD, 2} // 5 entries, Revision 0), Domain 0, OSPM
//
Coordinate, Initiate on any Proc, 2 Procs
}) // End of _PSD object
} // End of processor object list
Processor (
\_SB.CPU1, //
Processor Name
2, //
ACPI Processor number
, //
PBlk system IO address
) //
PBlkLen
{
Name(_PCT, Package () //
Performance Control object
{
ResourceTemplate(){Register(FFixedHW,
0, 0, 0)}, // PERF_CTRL
ResourceTemplate(){Register(FFixedHW,
0, 0, 0)} //
PERF_STATUS
}) // End of _PCT object
Name (_PSS, Package()
{
Package(){650,
21500, 500, 300, 0x00, 0x08}, // Performance State zero (P0)
Package(){600,
14900, 500, 300, 0x01, 0x05}, // Performance State one (P1)
Package(){500,
8200, 500, 300, 0x02, 0x06} // Performance State two (P2)
}) // End of _PSS object
Method (_PPC, 0) //
Performance Present Capabilities method
{
} // End of _PPC
method
Name (_PSD, Package()
{
Package(){5,
0, 0, 0xFD, 2} // 5 entries, Revision 0, Domain 0, OSPM
//
Coordinate, Initiate on any Proc, 2 Procs
}) // End of _PSD object
} // End of processor object list
9 ACPI-Devices and Device Specific Objects
This section describes ACPI defined devices and
device-specific objects. The system status indicator objects, declared under
the \_SI scope in the ACPI Namespace, are also specified in this section.
9.1 \_SI System Indicators
ACPI provides an interface for a variety of simple and
icon-style indicators on a system. All indicator controls are in the \_SI portion of the namespace. The following table lists
all defined system indicators. (Notice that there are also per-device
indicators specified for battery devices).
Table 9-1 System Indicator Control Methods
Object
|
Description
|
_SST
|
System status indicator
|
_MSG
|
Messages waiting indicator
|
9.1.1 _SST (System Status)
This optional object is a control method that OSPM invokes
to set the system status indicator as desired.
Arguments:
0 No
system state indication. Indicator off.
1 Working
2 Waking
3 Sleeping.
Used to indicate system state S1, S2 or S3.
4 Sleeping
with context saved to non-volatile storage.
9.1.2 _MSG (Message)
This control method sets the system's message-waiting
status indicator.
Arguments:
0 Number
of messages waiting
9.1.3 BLT (Battery Level
Threshold)
This optional control method is used by OSPM to indicate to
the platform the user's preference for various battery level thresholds. This
method allows platform battery indicators to be synchronized with OSPM provided
battery notification levels. Note that if _BLT is implemented on a
multi-battery system, it is required that the power unit for all batteries must
be the same. See section 10.2 for more details on battery levels.
Arguments:
Argument 1: DWORD:
0x00000001 –0x7FFFFFFF (in units of mWh or mAh, depending on the Power Units value)
User's preference for
battery warning level. If the level specified is less than the design capacity
of warning, it may be ignored by the platform so that the platform can ensure a
successful wake on low battery.
Argument 2: DWORD:
0x00000001 –0x7FFFFFFF (in units of mWh or mAh, depending on the Power Units value)
User's preference for battery
low level. If this level is less than the design capacity of low, it may be
ignored by the platform.
Argument 3: DWORD:
0x00000001 –0x7FFFFFFF (in units of mWh or mAh, depending on the Power Units value)
User's preference for battery
wake level. If this level is less than the platform's current wake on low
battery level, it may be ignored by the platform. If the platform does not
support a configurable wake on low battery level, this may be ignored by the
platform..
9.2 Control Method Ambient Light
Sensor Device
The following section illustrates the operation and
definition of the Control Method Ambient Light Sensor (ALS) device.
The ambient light sensor device can optionally support
power management objects (e.g. _PS0, _PS3) to allow the OS to manage the
device's power consumption.
The Plug and Play ID of an ACPI control method ambient
light sensor device is ACPI0008.
Table 9-2: Control Method Ambient Light Sensor Device
Object
|
Description
|
_ALI
|
The current ambient light illuminance reading in lux (lumen
per square meter). [Required]
|
_ALC
|
The current ambient light color chromacity reading, specified
using x and y coordinates per the CIE Yxy color model. [Optional]
|
_ALT
|
The current ambient light color temperature reading in degrees
Kelvin. [Optional]
|
_ALR
|
Returns a set of ambient light illuminance to display
brightness mappings that can be used by an OS to calibrate its ambient light
policy. [Required]
|
_ALP
|
Ambient light sensor polling frequency in tenths of seconds.
[Optional]
|
9.2.1 Overview
This
definition provides a standard interface by which the OS may query properties
of the ambient light environment the system is currently operating in, as well
as the ability to detect meaningful changes in these values when the
environment changes. Two ambient light properties are currently supported by
this interface: illuminance and color.
Ambient light illuminance readings are obtained via
the _ALI method. Illuminance readings indicate the amount of light incident
upon (falling on) a specified surface area. Values are specified in lux (lumen per square meter) and give an indication of
how "bright" the environment is. For example, an overcast day is roughly 1000
lux, a typical office environment 300-400 lux, and a dimly-lit conference room
around 10 lux.
A possible use of ambient light illuminance data by
the OS is to automatically adjust the brightness (or luminance) of the display device – e.g. increase display
luminance in brightly-lit environments and decrease display luminance in
dimly-lit environments. Note that Luminance is a measure of light radiated
(reflected, transmitted, or emitted) by a surface, and is typically measured in
nits. The _ALR method provides a
set of ambient light illuminance to display luminance mappings that can be used
by an OS to calibrate its policy for a given platform configuration.
Ambient light color readings are obtained via the _ALT
and/or _ALC methods. Two methods are defined to allow varying
types/complexities of ambient light sensor hardware to be used. _ALT returns
color temperature readings in degrees Kelvin. Color temperature values
correlate a light source to a standard black body radiator and give an
indication of the type of light source present in a given environment (e.g.
daylight, fluorescent, incandescent). ALC returns color chromacity readings
per the CIE Yxy color model. Chromacity x and y coordinates provide a more
straightforward indication of ambient light color characteristics. Note that
the CIE Yxy color model is defined by the International Commission on
Illumination (abbreviated as CIE from its French title Commission
Internationale de l'Eclairage) and is based on human perception instead of
absolute color.
A possible use of ambient light color data by the OS
is to automatically adjust the color of displayed images depending on the
environment the images are being viewed in. This may be especially important
for reflective/transflective displays where the type of ambient light may have
a large impact on the colors perceived by the user.
9.2.2 _ALI (Ambient
Light Illuminance)
This control method returns the current ambient light illuminance
reading in lux (lumen per square meter). Expected values range from ~1 lux for
a dark room, ~300 lux for a typical office environment, and 10,000+ lux for
daytime outdoor environments – although readings may vary depending on
the location of the sensor to the light source. Special values are reserved to
indicate out of range conditions (see below).
Arguments:
None
Result Code:
Zero: The
current reading is below the supported range or sensitivity of the sensor.
Ones: The
current reading is above the supported range or sensitivity of the sensor.
All other values: The
current ambient light brightness in lux (lumens per square meter).
9.2.3 _ALT (Ambient
Light Temperature)
This optional control method returns the current ambient
light color temperature reading in degrees Kelvin (°K). Lower color
temperatures imply warmer light (emphasis on yellow and red); higher color
temperatures imply a colder light (emphasis on blue). This value can be used
to gauge various properties of the lighting environment – for example,
the type of light source. Expected values range from ~1500°K for candlelight,
~3000°K for a 200-Watt incandescent bulb, and ~5500°K
for full sunlight on a summer day – although readings may vary depending
on the location of the sensor to the light source. Special values are reserved
to indicate out of range conditions (see below).
Arguments:
None
Result Code:
Zero: The
current reading is below the supported range or sensitivity of the sensor.
Ones: The
current reading is above the supported range or sensitivity of the sensor.
All other values: The
current ambient light temperature in degrees Kelvin.
9.2.4 _ALC (Ambient Light Color
Chromacity)
This optional control method returns the current ambient
light color chromacity readings per the CIE Yxy color model. The x and y
(chromacity) coordinates are specified using a fixed 10-4 notation
due to the lack of floating point values in ACPI. Valid values are within the
range 0 (0x0000) through 1 (0x2710). A single 32-bit integer value is used,
where the x coordinate is stored in the high word and the y coordinate in the
low word. For example, the value 0x0C370CDA would be used to specify the white
point for the CIE Standard Illuminant D65 (a standard representation of average
daylight) with x = 0.3127 and y = 0.3290. Special values are reserved to
indicate out of range conditions (see below).
Arguments:
None
Result Code:
Zero: The
current reading is below the supported range or sensitivity of the sensor.
Ones: The
current reading is above the supported range or sensitivity of the sensor.
All
other values: The current ambient
light color chromacity x and y coordinate values, per the CIE Yxy color model.
9.2.5 _ALR (Ambient
Light Response)
This object evaluates to a package of ambient
light illuminance to display luminance
mappings that can be used by an OS to
calibrate its ambient light policy for a given sensor configuration.
The OS can use this information to extrapolate an ALS response curve - noting
that these values may be treated differently depending on the OS implementation
but should be used in some form to calibrate ALS policy.
The data set is specified as a package of packages, where
each tuple (inner package) consists of the pair of integer values of the form:
{<display luminance adjustment>,
<ambient light illuminance>}
Package elements should be listed in monotonically
increasing order based upon the ambient light illuminance value (the
Y-coordinate on the graph) to simplify parsing by the OS.
Ambient light illuminance values are specified in lux
(lumens per square meter). Display luminance (or brightness) adjustment values
are specified using relative percentages in order simplify the means by which these
adjustments are applied in lieu of changes to the user's display brightness
preference. A value of 100 is used to indicate no (0%) display brightness
adjustment given the lack of signed data types in ACPI. Values less than 100
indicate a negative adjustment (dimming); values greater than 100 indicate a
positive adjustment (brightening). For example, a display brightness
adjustment value of 75 would be interpreted as a -25% adjustment, and a value
of 110 as a +10% adjustment.
Figure
9-1: A five-point ALS Response Curve
Figure 9-1 illustrates the use of five points to
approximate an example response curve, where the dotted line represents an
approximation of the desired response (solid curve). Extrapolation of the
values between these points is OS-specific – although for the purposes of
this example we'll assume a piecewise linear approximation. The ALS response
curve (_ALR) would be specified as follows:
Name(_ALR, Package(5) {
Package{70, 0}, //
Min ( -30% adjust at 0 lux)
Package{73, 10}, // (
-27% adjust at 10 lux)
Package{85, 80}, // (
-15% adjust at 80 lux)
Package{100,300}, //
Baseline ( 0% adjust at 300 lux)
Package{150,1000} //
Max (+50% adjust at 1000 lux)
})
Within this data set exist three points of particular
interest: baseline, min, and max. The baseline value represents an ambient light illuminance value (in lux) for the
environment where this system is most likely to be used. When the system is
operating in this ambient environment the ALS policy will apply no (0%)
adjustment to the default display brightness setting. For example, given a
system with a 300 lux baseline,
operating in a typical office ambient environment (~300 lux), configured with a
default display brightness setting of 50% (e.g. 60 nits), the ALS policy would
apply no backlight adjustment, resulting in an absolute display brightness
setting of 60 nits.
Min and max are used to indicate cutoff points in order to
prevent an over-zealous response by the ALS policy and to influence the
policy's mode of operation. For example, the min and max
points from the figure above would be specified as (70,0) and (150,1000)
respectively – where min
indicates a maximum negative adjustment of 30% and max represents a maximum positive adjustment of 500%.
Using a large display brightness adjustment for max allows an ALS response that approaches a
fully-bright display (100% absolute) in very bright ambient environments
regardless of the user's display brightness preference. Using a small value
for max (e.g. 0% @ 300 lux) would
influence the ALS policy to limit the use of this technology solely as a
power-saving feature (never brighten the display). Conversely, setting min to a 0% adjustment instructs ALS policy to brighten
but never dim.
A minimum of two data points are required in the return
package, interpreted as min and max. Note that the baseline
style='font-style:normal'>value does not have to be explicitly stated; it can
be derived from the response curve. Addition elements can be provided to
fine-tune the response between these points. Figure 9-2 illustrates the use of
two data points to achieve a response similar to (but simpler than) that
described in Figure 9-1.
Figure
9-2: A two-point ALS Response Curve
This example lacks an explicit baseline and includes a min
style='font-style:normal'> with an ambient light value above 0 lux. The baseline
can easily be extrapolated by ALS Policy
(e.g. 0% adjustment at ~300 lux). All ambient light brightness settings below
min (20 lux) would be treated in a similar
fashion by ALS policy (e.g. -30% adjustment). This two-point response curve
would be modeled as:
Name(_ALR, Package(3) {
Package{70, 30}, //
Min ( -30% adjust at 30 lux)
Package{150,1000} //
Max (+50% adjust at 1000 lux)
})
This model can be used to convey a wide range of ambient
light to display brightness responses. For example, a transflective display
– a technology where illumination of the display can be achieved by
reflecting available ambient light, but also augmented in dimly-lit
environments with a backlight – could be modeled as illustrated in Figure
9-3.
Figure
9-3: Example Response Curve for a Transflective Display
This three-point approximation would result in an ALS
response that allows the backlight to increase as the ambient lighting
decreases. In this example, no backlight adjustment is needed in bright
environments (1000+ lux), maximum backlight may be needed in dim environments
(~30 lux), but a lower backlight setting may be used in a very-dark room (~0
lux) – resulting in an elbow around 30 lux. This response would be
modeled in _ALR as follows:
Name(_ALR, Package(3) {
Package{180, 0} (
+80% adjust at 0 lux)
Package{200, 30}, //
Max (+100% adjust at 30 lux)
Package{0, 1000}, //
Min ( 0% adjust at 1,000 lux)
})
Note the ordering of package elements: monotonically
increasing from the lowest ambient light value (0 lux) to the brightness (1000
lux).
The transflective display example also highlights the need
for non-zero values for the user's display brightness preference – which
we'll refer to as the reference display
brightness value. This requirement is derived from the model's use of relative
adjustments. For example, applying any adjustment to a 0% reference display
brightness value always results in a 0% absolute display brightness setting.
Likewise, using a very small reference display brightness (e.g. 5%) results in
a muted response (e.g. +30% of 5% = 6.5% absolute). The solution is to apply a
reasonably large value (e.g. 50%) as the reference display brightness setting
– even in the case where no backlight is applied. This allows relative
adjustments to be applied in a meaningful fashion while conveying to the user
that the display is still usable (via reflected light) under typical ambient
conditions.
The OS derives the user's display brightness preference
(this reference value) either from the
Brightness Control Levels (_BCL) object or another OS-specific mechanism. See
section 9.2.8,
"Relationship to Backlight Control Methods", for more information.
9.2.6 _ALP (Ambient Light Polling)
This optional object evaluates to a recommended polling frequency (in tenths of seconds) for this
ambient light sensor. A value of zero – or the absence of this object
when other ALS objects are defined – indicates that OSPM does not need to
poll the sensor in order to detect meaningful changes in ambient light (the
hardware is capable of generating asynchronous notifications).
The use of polling is allowed but strongly discouraged by
this specification. OEMs should design systems that asynchronously notify OSPM
whenever a meaningful change in the ambient light occurs—relieving the OS
of the overhead associated with polling.
This value is specified as tenths of seconds. For example,
a value of 10 would be used to indicate a 1 second polling frequency. As this
is a recommended value, OSPM will
consider other factors when determining the actual polling frequency to use.
Arguments:
None
Result Code:
Zero: Polling
by the OS is not required.
All
other values: The recommended polling
frequency, in tenths of seconds.
9.2.7 Ambient Light Sensor Events
To communicate meaningful changes in ALS illuminance to
OSPM, AML code should issue a Notify(als_device
style='font-family:"Courier New"'>, 0x80) whenever the lux reading
changes more than 10% (from the last reading that resulted in a notification). OSPM
receives this notification and evaluates the _ALI control method to determine
the current ambient light status. The OS then adjusts the display brightness
based upon its ALS policy (derived from _ALR).
The definition of what constitutes a meaningful change is left to the system integrator, but should be at a
level of granularity that provides an appropriate response without overly
taxing the system with unnecessary interrupts. For example, an ALS
configuration may be tuned to generate events for all changes in ambient light
illuminance that result in a minimum ±5% display brightness response (as
defined by _ALR).
To communicate meaningful changes in ALS color temperature
to OSPM, AML code should issue a Notify(als_device
style='font-family:"Courier New"'>, 0x81) whenever the lux reading
changes more than 10% (from the last reading that resulted in a notification). OSPM
receives this notification and evaluates the _ALT and _ALC control method to
determine the current ambient light color temperature.
To communicate meaningful changes in ALS response to OSPM,
AML code should issue a Notify(als_device
style='font-family:"Courier New"'>, 0x82) whenever the set of points
used to convey ambient light response has changed. OSPM receives this
notification and evaluates the _ALR object to determine the current response
points.
9.2.8 Relationship to Backlight Control Methods
The Brightness Control Levels (_BCL) method –described in section 0 – can be used to indicate user-selectable display
brightness levels. The information provided by this method indicates the
available display brightness settings, the recommended default brightness
settings for AC and DC operation, and the absolute maximum and minimum
brightness settings. These values indirectly influence the operation of the OSPM's
ALS policy.
Display brightness adjustments produced by ALS policy are
relative to the current user backlight setting, and the resulting absolute
value must be mapped (rounded) to one of the levels specified in _BCL. This
introduces the requirement for fine-grain display brightness control in order
to achieve a responsive ALS system – which typically materializes as a
need for additional entries in the _BCL list in order to provide reasonable
resolution to the OS (e.g. 3-10% granularity). Note that user brightness
controls (e.g. hotkeys) are not required to make use of all levels specified in
_BCL.
9.3 Battery Device
A battery device is required to either have an ACPI Smart
Battery Table or a Control Method Battery interface. In the case of an ACPI
Smart Battery Table, the Definition Block needs to include a Bus/Device Package
for the SMBus host controller. This will install an OS specific driver for the
SMBus, which in turn will locate the Smart Battery System Manager or Smart
Battery Selector and Smart Battery Charger SMBus devices.
The Control Method Battery interface is defined in section
10.2, "Control Method Batteries."
9.4 Control Method Lid Device
Platforms containing lids convey lid status (open / closed)
to OSPM using a Control Method Lid Device.
To implement a control method lid device, AML code should
issue a Notify(lid_device
style='font-family:"Courier New"'>, 0x80) for the device whenever the
lid status has changed. The _LID control method for the lid device must be
implemented to report the current state of the lid as either opened or closed.
The lid device can support _PRW and _PSW methods to select
the wake functions for the lid when the lid transitions from closed to opened.
The Plug and Play ID of an ACPI control method lid device
is PNP0C0D.
Table 9-4 Control Method Lid Device
Object
|
Description
|
_LID
|
Returns the current status of the lid.
|
9.4.1 _LID
Evaluates to the current status of the lid.
Result Code:
Zero: The
lid is closed
Non-zero: The
lid is open
9.5 Control Method Power and Sleep Button Devices
The system's power or sleep button can either be
implemented using the fixed register space as defined in section 4.7.2.2,
"Buttons," or implemented in AML code as a control method power button device.
In either case, the power button override function or similar unconditional
system power or reset functionality is still implemented in external hardware.
To implement a control method power-button or sleep-button
device, implement AML code that delivers two types of notifications concerning
the device. The first is Notify(Object,
0x80) to signal that the button was pressed while the system was in the S0
state to indicate that the user wants the machine to transition from S0 to some
sleeping state. The other notification is Notify(Object, 0x2) to signal that the button was pressed while the
system was in an S1 to S4 state and to cause the system to wake. When the
button is used to wake the system, the wake notification (Notify(Object, 0x2)) must occur after OSPM actually wakes, and a
button-pressed notification (Notify(Object, 0x80)) must not occur.
The Wake Notification indicates that the system is awake
because the user pressed the button and therefore a complete system resume
should occur (for example, turn on the display immediately, and so on).
9.6 Embedded Controller Device
Operation of the embedded controller host controller
register interface requires that the embedded controller driver has
ACPI-specific knowledge. Specifically, the driver needs to provide an
"operational region" of its embedded controller address space, and needs to use
a general-purpose event (GPE) to service the host controller interface
more information about an ACPI-compatible embedded controller device, see
section 12, "ACPI Embedded Controller Interface Specification."
The embedded controller device object provides the _HID of
an ACPI-integrated embedded controller device of PNP0C09 and the host
controller register locations using the device standard methods. In addition,
the embedded controller must be declared as a named device object that includes
a set of control methods. For more information, see section 12.11, "Defining an
Embedded Controller Device in ACPI Namespace").
9.7 Fan Device
A fan device is assumed to be in operation when it is in
the D0 state. Thermal zones reference fan device(s) as being responsible
primarily for cooling within that zone. Notice that multiple fan devices can be
present for any one thermal zone. They might be actual different fans, or they
might be used to implement one fan of multiple speeds (for example, by turning
both "fans" on the one fan will run full speed).
The Plug and Play ID of a fan device is PNP0C0B. For more
information about fan devices, see section 11, "Thermal Management."
9.8 Generic Container Device
A generic container device is a bridge that does not
require a special OS driver because the bridge does not provide or require any
features not described within the normal ACPI device functions. The resources
the bridge requires are specified via normal ACPI resource mechanisms. Device
enumeration for child devices is supported via ACPI namespace device
enumeration and OS drivers require no other features of the bus. Such a bridge
device is identified with the Plug and Play ID of PNP0A05 or PNP0A06.
A generic bus bridge device is typically used for
integrated bridges that have no other means of controlling them and that have a
set of well-known devices behind them. For example, a portable computer can
have a "generic bus bridge" known as an EIO bus that bridges to some number of
Super-I/O devices. The bridged resources are likely to be positively decoded as
either a function of the bridge or the integrated devices. In this example, a
generic bus bridge device would be used to declare the bridge then child
devices would be declared below the bridge; representing the integrated
Super-I/O devices.
9.9 ATA Controller Devices
There are two types of ATA Controllers: IDE controllers (also
known as ATA controllers) and Serial ATA (SATA) controllers. IDE controllers
are those using the traditional IDE programming interface, and may support
Parallel ATA (P-ATA) or SATA connections. SATA controllers may be designed to
operate in emulation mode only, native mode only, or they may be designed to
support both native and non-native SATA modes. Regardless of the mode
supported, SATA controllers are designed to work solely with drives supporting
the Serial ATA physical interface. As described below, SATA controllers are
treated similarly but not identically to traditional IDE controllers.
Platforms that contain controllers that support native and
non-native SATA modes must take steps to ensure the proper objects are placed
in the namespace for the mode in which they are operating.
Table 9-5 ATA Specific Objects
Object
|
Description
|
Controller Type
|
_GTF
|
Optional object that returns the ATA task file needed to
re-initialize the drive to boot up defaults.
|
Both
|
_GTM
|
Optional object that returns the IDE controller timing
information.
|
IDE-only
|
_STM
|
Optional control method that sets the IDE controller's
transfer timing settings.
|
IDE-only
|
_SDD
|
Optional control method that informs the platform of the type
of device attached to a port.
|
SATA-only
|
9.9.1 Objects
for Both ATA and SATA Controllers
9.9.1.1 _GTF (Get Task File)
This optional object returns
a buffer containing the ATA commands used to restore the drive to boot up
defaults (that is, the state of the drive after POST). The returned buffer is
an array with each element in the array consisting of seven 8-bit register
values (56 bits) corresponding to ATA task registers 1F1 thru 1F7. Each entry
in the array defines a command to the drive.
This object may appear under SATA port device objects or
under IDE channel objects.
ATA task file array definition:
· Seven
register values for command 1
· Reg
values: (1F1, 1F2, 1F3, 1F4, 1F5, 1F6, 1F7)
· Seven
register values for command 2
· Reg
values: (1F1, 1F2, 1F3, 1F4, 1F5, 1F6, 1F7)
· Seven
register values for command 3
·
lang=NO-BOK>Reg values: (1F1, 1F2, 1F3, 1F4, 1F5, 1F6, 1F7)
Etc……
After powering up the drive, OSPM will send these commands
to the drive, in the order specified. On SATA HBAs, OSPM evaluates _SDD before
evaluating _GTF. The IDE driver may modify some of the feature commands or
append its own to better tune the drive for OSPM features before sending the
commands to the drive.
This Control Method is listed under each drive device
object. _GTF must be called after calling _STM.
Arguments:
None
Result Code:
A buffer that is a byte stream of ATA commands to send
to the drive.
Example of the return from _GTF:
Method(_GTF, 0x0, NotSerialized)
{
Return(GTF0)
}
Name(GTF0, Buffer(0x1c)
{
0x03, 0x00, 0x00, 0x00, 0x00, 0xa0, 0xef,
0x03, 0x00, 0x00, 0x00, 0x00,
0xa0, 0xef, 0x00, 0x10, 0x00,
0x00, 0x00, 0xa0, 0xc6, 0x00, 0x00, 0x00,
0x00, 0x00, 0xa0, 0x91
}
9.9.2 IDE
Controller Device
Most device drivers can save and restore the registers of
their device. For IDE controllers and drives, this is not true because there
are several drive settings for which ATA does not provide mechanisms to read.
Further, there is no industry standard for setting timing information for IDE
controllers. Because of this, ACPI interface mechanisms are necessary to
provide the operating system information about the current settings for the
drive and channel, and for setting the timing for the channel.
OSPM and the IDE driver will follow these steps when
powering off the IDE subsystem:
1. The IDE driver will call the _GTM control method to get the current
transfer timing settings for the IDE channel. This includes information about
DMA and PIO modes.
2. The IDE driver will call the standard OS services to power down the
drives and channel.
3. As a result, OSPM will execute the appropriate _PS3 methods and turn off
unneeded power resources.
To power on the IDE subsystem, OSPM and the IDE driver will
follow these steps:
1. The IDE
driver will call the standard OS services to turn on the drives and channel.
2. As a
result, OSPM will execute the appropriate _PS0 methods and turn on required
power resources.
3. The IDE
driver will call the _STM control method passing in transfer timing settings
for the channel, as well as the ATA drive ID block for each drive on the
channel. The _STM control method will configure the IDE channel based on this
information.
4. For each
drive on the IDE channel, the IDE driver will run the _GTF to determine the ATA
commands required to reinitialize each drive to boot up defaults.
5. The IDE
driver will finish initializing the drives by sending these ATA commands to the
drives, possibly modifying or adding commands to suit the features supported by
the operating system.
The following shows the namespace for these objects:
\_SB //
System bus
PCI0 //
PCI bus
IDE1 //
First IDE channel
_ADR //
Indicates address of the channel on the PCI bus
_GTM //
Control method to get current IDE channel settings
_STM //
Control method to set current IDE channel settings
_PR0 //
Power resources needed for D0 power state
DRV1 //
Drive 0
_ADR //
Indicates address of master IDE device
_GTF //
Control method to get task file
DRV2 //
Drive 1
_ _ADR //
Indicates address of slave IDE device
_ _GTF //
Control method to get task file
IDE2 //
Second IDE channel
_ADR //
Indicates address of the channel on the PCI bus
_GTM //
Control method to get current IDE channel settings
_STM //
Control method to set current IDE channel settings
_ _PR0 //Power
resources needed for D0 power state
DRV1 //
Drive 0
_ADR //
Indicates address of master IDE device
_GTF //
Control method to get task file
DRV2 //
Drive 1
_ADR //
Indicates address of slave IDE device
_GTF //
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).
9.9.2.1 IDE
Controller-specific Objects
9.9.2.1.1 _GTM (Get Timing Mode)
This Control Method returns
the current settings for the IDE channel.
This control method is listed under each channel device
object.
Arguments:
None
Result Code:
A buffer with the current settings for the IDE
channel:
Buffer (){
PIO Speed 0 //DWORD
DMA Speed 0 //DWORD
PIO Speed 1 //DWORD
DMA Speed 1 //DWORD
Flags //DWORD
}
Table 9-6 _GTM Method Result Codes
Field
|
Format
|
Description
|
PIO Speed 0
|
DWORD
|
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.
|
DMA Speed 0
|
DWORD
|
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.
|
PIO Speed 1
|
DWORD
|
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.
|
DMA Speed 1
|
DWORD
|
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.
|
Flags
|
DWORD
|
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)
|
9.9.2.1.2 _STM (Set Timing Mode)
This Control Method sets
the IDE channel's transfer timings to the setting requested. The AML code is
required to convert and set the nanoseconds timing to the appropriate transfer
mode settings for the IDE controller. _STM may also make adjustments so that
_GTF control methods return the correct commands for the current channel
settings.
This control method takes three arguments: Channel timing
information (as described in Table 9-6), and the ATA drive ID block for each
drive on the channel. The channel timing information is not guaranteed to be
the same values as returned by _GTM; the OS may tune these values as needed.
The ATA drive ID block is the raw data returned by the Identify
Drive, ATA command, which has the command code "0ech." The _STM control method
is responsible for correcting for drives that misreport their timing
information.
Arguments:
Arg0 Buffer Channel
timing information (formatted as described in Table 9-6)
Arg1 Buffer ATA
drive IDE block for drive 0
Arg2 Buffer ATA
drive IDE block for drive 1
Result Code:
None
9.9.3 Serial ATA
(SATA) Controller Device
9.9.3.1 Definitions
· HBA – Host Bus
Adapter
· Native SATA aware –Refers to system software (BIOS, option ROM, operating system, etc) that
comprehends a particular SATA HBA implementation and understands its
programming interface and power management behavior.
· Non-native SATA aware - Refers
to system software (BIOS, option ROM, operating system, etc) that does not
comprehend a particular SATA HBA implementation and does not understand its
programming interface or power management behavior. Typically, non-native SATA
aware software will use a SATA HBA's emulation interface (e.g. task file
registers) to control the HBA and access its devices.
· Emulation mode –Optional mode supported by a SATA HBA. Allows non-native SATA aware software to
access SATA devices via traditional task file registers.
· Native mode –Optional mode supported by a SATA HBA. Allows native SATA aware software to access
SATA devices via registers that are specific to the HBA.
· Hybrid Device – Refers
to a SATA HBA that implements both an emulation and a native programming
interface.
9.9.3.2 Overview
A SATA HBA differs from an IDE controller in a number of
ways. First, it can save its complete device context. Second, it replaces IDE
channels, which may support up to 2 attached devices, with ports, which support
only a single attached device, unless a port multiplier is present. See the
SATA spec (http://www.serialata.org/collateral/index.shtml) for more
information. Finally, SATA does not require timing information from the
platform, allowing a simplification in how SATA controllers are represented in
ACPI. (_GTM and _STM are replaced by the simpler _SDD method.)
All ports, even those attached off a port multiplier, are
represented as children directly under the SATA controller device. This is
practical because the SATA specification does not allow a port multiplier to be
attached to a port multiplier. Each port's _ADR indicates to which root port
they are connected, as well as the port multiplier location, if applicable.
(See Table 6-2 for _ADR format.)
Since this specification only covers the configuration of
motherboard devices, it is also the case that the control methods defined in
this section cannot be used to send taskfiles to devices attached via either an
add-in SATA HBA, or attached via a motherboard SATA HBA, if used with a port
multiplier that is not also on the motherboard.
The following shows an example SATA namespace:
\_SB -System bus
PCI0 -PCI bus
SATA -SATA Controller device
_ ADR -Indicates address of the controller on the PCI bus
_ PR0 -
Power resources needed for D0 power state
PRT0 - Port 0 device
_ADR -Indicates physical port and port multiplier topology
_SDD -Identify information for drive attached to this port
_GTF -Control method to get task file
PRTn - Port n device
_ADR -Indicates physical port and port multiplier topology
_SDD -Identify information for drive attached to this port
_GTF -Control method to get task file
9.9.3.3 SATA
controller-specific control methods
In order to ensure proper interaction between OSPM, the
firmware, and devices attached to the SATA controller, it is a requirement that
OSPM execute the _SDD and _GTF control methods when certain events occur. OSPM's response to events must be as follows:
COMRESET, Initial OS load, device insertion, HBA D3 to
D0 transition, asynchronous loss of signal:
1. OSPM sends IDENTIFY DEVICE or IDENTIFY PACKET DEVICE command to the
attached device.
2. OS executes _SDD. _SDD control method requires 1 argument that consists
of the data block received from an attached device as a result of a host issued
IDENTIFY DEVICE or IDENTIFY PACKET DEVICE command.
3. After the _SDD method completes, the OS executes the _GTF method. Using
the task file information provided by _GTF, the OS then sends the _GTF
taskfiles to the attached device.
Device removal and HBA D0 to D3 transition:
1. No OSPM action required.
9.9.3.3.1 _SDD
(Set Device Data)
This optional object is a control method that conveys to
the platform the type of device connected to the port. The _SDD object may
exist under a SATA port device object. The platform typically uses the information
conveyed by the _SDD object to construct the values returned by the _GTF object.
OSPM conveys to the platform the ATA drive ID block, which
is the raw data returned by the Identify (Packet) Device, ATA command (command
code "0ech."). Please see the ATA/ATAPI-6 specification for more details.
Arguments:
Arg0 Buffer ATA
drive identify block, contents described by the ATA specification
Result Code:
None
9.10 Floppy Controller Device Objects
9.10.1 _FDE (Floppy Disk Enumerate)
Enumerating devices attached to a floppy disk controller is
a time-consuming function. In order to speed up the process of floppy
enumeration, ACPI defines an optional enumeration object that is defined directly under the device object for the floppy
disk controller. It returns a buffer of five 32-bit values. The first four
values are Boolean values indicating the presence or absence of the four floppy
drives that are potentially attached to the controller. A non-zero value
indicates that the floppy device is present. The fifth value returned indicates
the presence or absence of a tape controller. Definitions of the tape presence
value can be found in Table 9-7.
Arguments:
None
Result Code:
A buffer containing values that indicate the presence
or absence of floppy devices.
Buffer (){
Floppy 0 //
Boolean DWORD
Floppy 1 //
Boolean DWORD
Floppy 2 //
Boolean DWORD
Floppy 3 //
Boolean DWORD
Tape //
See table below
}
Table 9-7 Tape Presence
Value
|
Description
|
0
|
Unknown if device is present
|
1
|
Device is present
|
2
|
Device is never present
|
>2
|
Reserved
|
9.10.2 _FDI
(Floppy Disk Information)
This object returns information about a floppy disk drive.
This information is the same as that returned by the INT 13 Function 08H on
IA-PCs.
Result Code:
Package {
Drive Number //BYTE
Device Type //BYTE
Maximum Cylinder Number //WORD
Maximum Sector Number //WORD
Maximum Head Number //WORD
disk_specify_1 //BYTE
disk_specify_2 //BYTE
disk_motor_wait //BYTE
disk_sector_siz //BYTE
disk_eot //BYTE
disk_rw_gap //BYTE
disk_dtl //BYTE
disk_formt_gap //BYTE
disk_fill //BYTE
disk_head_sttl //BYTE
disk_motor_strt //BYTE
}
Table 9-8 ACPI Floppy Drive Information
Field
|
Format
|
Definition
|
Drive Number
|
BYTE
|
As reported by _INT 13 Function 08H
|
Device Type
|
BYTE
|
As reported by _INT 13 Function 08H
|
Maximum Cylinder Number
|
WORD
|
As reported by _INT 13 Function 08H
|
Maximum Sector Number
|
WORD
|
As reported by _INT 13 Function 08H
|
Maximum Head Number
|
WORD
|
As reported by _INT 13 Function 08H
|
Disk_specify_1
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_specify_2
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_motor_wait
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_sector_siz
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_eot
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_rw_gap
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_dtl
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_formt_gap
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_fill
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_head_sttl
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
Disk_motor_strt
|
BYTE
|
As reported in ES:D1 from INT 13 Function 08H
|
9.10.3 _FDM (Floppy Disk Drive Mode)
This control method switches the mode (300RPM/360RPM) of
all floppy disk drives attached to this controller. If this control method is
implemented, the platform must reset the mode of all drives to 300RPM mode
after a Dx to D0 transition of the
controller.
Arguments:
0 – Set the mode of all
drives to 300RPM mode.
1 – Set the mode of all
drives to 360RPM mode.
Result Code:
None
9.11 GPE
Block Device
The GPE Block device is an optional device that allows a
system designer to describe GPE blocks beyond the two that are described in the
FADT. Control methods associated with the GPE pins of GPE block devices exist
as children of the GPE Block device, not within the \_GPE namespace.
A GPE Block device consumes I/O or memory address space, as
specified by its _PRS or _CRS child objects. The interrupt vector used by the
GPE block does not need to be the same as the SCI_INT field. The interrupt used
by the GPE block device is specified in the _CRS and _PRS methods associated
with the GPE block. The _CRS of a GPE Block device may only specify a single
register address range, either I/O or memory. This range contains two
registers: the GPE status and enable registers. Each register's length is
defined as half of the length of the _CRS-defined register address range.
A GPE Block device must have a _HID or a _CID of
"ACPI0006."
Note: A system
designer must describe the GPE block necessary to bootstrap the system in the
FADT as a GPE0/GPE1 block. GPE Block devices cannot be used to implement these
GPE inputs.
To represent the GPE block associated with the FADT, the
system designer needs only to include the ACPI0006 device in the tree, and not have any _CRS, _PRS, _SRS, or other GPE-specific
methods associated with that block. Any block that does not represent the GPE
block of the FADT must contain the _Lxx, _Exx, _Wxx, _CRS, _PRS, or _SRS
methods required to use/program that block. OSPM assumes the first ACPI0006
device without a _CRS is the GPE device that is associated with the FADT.
// ASL example of root GPE block
Device(\_SB.PCI0.GPE0) {
Name(_HID,"ACPI0006")
Name(_UID,1)
}
// ASL example of a non-root GPE block
Device(\_SB.PCI0.GPE1) {
Name(_HID, "ACPI0006")
Name(_UID, 2)
Name(_CRS, Buffer () {
IO(Decode16, FC00, FC03, 4,
4,)
IRQ( Level, ActiveHigh,
Shared,) { 5 }
})
Method(_L02) { … }
Method(_E07) { … }
Method(_W04) { … }
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.
9.11.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, _Exx, and _Wxx) 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) { … }
Method(_W04) { … }
}
9.12 Module
Device
This optional device is a container object that acts as a
bus node in a namespace. It may contain child objects that are devices or
buses. The module device is declared using the ACPI0004 hardware identifier
(HID).
If the module device contains a _CRS object, the "bus"
described by this object is assumed to have these resources available for
consumption by its child devices. If a _CRS object is present, any resources
not produced in the module device's _CRS object may not be allocated to child
devices.
Providing a _CRS object is undesirable in some module
devices. For example, consider a module device used to describe an add-in board
containing multiple host bridges without any shared resource decoding logic
this case the resource ranges available to the host bridges are not controlled
by any entity residing on the add-in board, implying that a _CRS object in the
associated module device would not describe any real feature of the underlying
hardware. A_CRS object must exist with a module device if the device contains
PCI host bridge devices (See section 9.12.1 "Describing PCI Bus and Segment
Group Numbers under Module Devices").
To account for cases like this, the system designer may
optionally omit the module device's _CRS object. If no _CRS object is present,
OSPM will assume that the module device is a simple container object that does
not produce the resources consumed by its child devices. In this case, OSPM
will assign resources to the child devices as if they were direct children of
the module device's parent object.
For an example with a module device _CRS object present,
consider a Module Device containing three child memory devices. If the _CRS
object for the Module Device contains memory from 2 GB through 6 GB, then the
child memory devices may only be assigned addresses within this range.
Example:
Device (\_SB.NOD0) {
Name (_HID, "ACPI0004") //
Module device
Name (_UID, 0)
Name (_PRS, ResourceTemplate() {
WordIO (
ResourceProducer,
MinFixed, //
_MIF
MaxFixed,,, //
_MAF
0x0000, //
_GRA
0x0000, //
_MIN
0x7FFF, //
_MAX
0x0, //
_TRA
0x8000) //
_LEN
DWordMemory
(
ResourceProducer,, //
For Main Memory + PCI
MinNotFixed, //
_MIF
MaxNotFixed, //
_MAF
Cacheable, //
_MEM
ReadWrite, //
_RW
0x0FFFFFFF, //
_GRA
0x40000000, //
_MIN
0x7FFFFFFF, //
_MAX
0x0, //
_TRA
0x00000000) //
_LEN
})
Method (_SRS, 1) { ... }
Method (_CRS, 0) { ... }
Device (MEM0) { //
Main Memory (256MB module)
Name (_HID,
EISAID("PNP0C80"))
Name (_UID, 0)
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
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
DWordMemory
(
ResourceProducer,,
MinNotFixed, //
_MIF
MaxNotFixed, //
_MAF
NonCacheable, //
_MEM
ReadWrite, //
_RW
0x0FFFFFFF, // _GRA
0x40000000, // _MIN
0x7FFFFFFF, //
_MAX
0x0, //
_TRA
0x00000000) //
_LEN
})
Method (_CRS, 0) { ... }
Method (_SRS, 1) { ... }
}
}
9.12.1 Describing PCI Bus and Segment Group Numbers under Module
Devices
If a module device exposes one or more PCI root busses,
OSPM must be able to determine what PCI bus and segment group numbers are
defined for the module device. A module device may be a container for root
buses in multiple segment groups. Because the _SEG method can only return a
single number, _SEG cannot adequately describe this case. To properly convey
this information to OSPM, the PCI bus number resource descriptor in the module
device must include both the bus and segment resources produced by the module
device. To describe this in systems that implement multiple PCI segment
groups, the segment group resources produced by a module device must be encoded
in bits 8 and higher of the module device's WordBusNumber resource descriptor.
For systems that do not expose multiple PCI segment groups, bits 8 and higher
of the module device's WordBusNumber resource descriptor must be zero.
Note: The range of PCI segment groups reported in the _CRS
of module devices cover both assigned and unassigned PCI root bridges. In the
case of hot add of a PCI root bridge, OSPM does not re-evaluate the _CRS of its
parent module device as its resources are not expected to change in this case.
For an example of a module device encoding PCI segment
group ranges with PCI bus number resources, consider a module device that
describes two PCI root bridges as child devices. The _CRS for the module
device describes 2 PCI root bridges as child devices, where each PCI root
bridge consumes its own PCI segment.
Example:
Device (\_SB.NOD0) {
Name (_HID, "ACPI0004") //
Module device
Name (_UID, 0)
Name (_CRS, ResourceTemplate() {
WordIO (
ResourceProducer,
MinFixed, //
_MIF
MaxFixed,,, //
_MAF
0x0000, //
_GRA
0x0000, //
_MIN
0x7FFF, //
_MAX
0x0, //
_TRA
0x8000) //
_LEN
DWordMemory
(
ResourceProducer,, //
For Main Memory + PCI
MinNotFixed, //
_MIF
MaxNotFixed, //
_MAF
Cacheable, //
_MEM
ReadWrite, //
_RW
0x0FFFFFFF, //
_GRA
0x40000000, //
_MIN
0x7FFFFFFF, //
_MAX
0x0, //
_TRA
0x00000000) //
_LEN
WordBusNumber (
ResourceProducer,
MinFixed, //
_MIF
MaxFixed,, //
_MAF
0x00, //
_GRA
0x0000, //
_MIN (indicates minimum segment number 0)
0x01FF, //
_MAX (indicates maximum segment of 1)
0x0, //
_TRA
0x80) //
_LEN
})
Device (PCI0) { //
PCI Root Bridge
Name (_HID,
EISAID("PNP0A03"))
Name (_UID, 0)
Name (_BBN, 0x00)
Name (_SEG, 0x00) //
assign segment 0 of module device to PCI0
Name (_CRS,
ResourceTemplate () {
WordBusNumber
(
ResourceProducer,
MinFixed, //
_MIF
MaxFixed,, //
_MAF
0x00, //
_GRA
0x00, //
_MIN
0xFF, //
_MAX
0x0, //
_TRA
0x80) //
_LEN
WordIO
(
ResourceProducer,
MinFixed, //
_MIF
MaxFixed,,, //
_MAF
0x0000, //
_GRA
0x0000, //
_MIN
0x0CF7, //
_MAX
0x0, //
_TRA
0x0CF8) //
_LEN
DWordMemory
(
ResourceProducer,,
MinNotFixed, //
_MIF
MaxNotFixed, //
_MAF
NonCacheable, //
_MEM
ReadWrite, //
_RW
0x0FFFFFFF, //
_GRA
0x40000000, // _MIN
0x5FFFFFFF, //
_MAX
0x0, //
_TRA
0x00000000) //
_LEN
})
}
}
Device (PCI1) { //
PCI Root Bridge
Name (_HID,
EISAID("PNP0A03"))
Name (_UID, 0)
Name (_BBN, 0x00)
Name (_SEG, 0x01) //
assign segment 1 of module device to PCI1
Name (_CRS,
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
0x0D00, //
_MIN
0x7FFF, //
_MAX
0x0, //
_TRA
0x7300) //
_LEN
DWordMemory
(
ResourceProducer,
MinNotFixed, //
_MIF
MaxNotFixed, //
_MAF
NonCacheable, //
_MEM
ReadWrite, //
_RW
0x0FFFFFFF, //
_GRA
0x60000000, // _MIN
0x7FFFFFFF, //
_MAX
0x0, //
_TRA
0x00000000) //
_LEN
})
}
}
9.13 Memory Devices
Memory devices allow a platform designer to optionally
describe the dynamic properties of memory. If a platform cannot have memory
added or removed while the system is active, then memory devices are not
necessary. Memory devices may describe exactly the same physical memory that
the System Address Map interfaces describe (see section 15, "System Address Map
Interfaces"). They do not describe how that memory is, or has been, used. If a
region of physical memory is marked in the System Address Map interface as
AddressRangeReserved or AddressRangeNVS and it is also described in a memory
device, then it is the responsibility of the OS to guarantee that the memory
device is never disabled.
It is not necessary to describe all memory in the system
with memory devices if there is some memory in the system that is static in
nature. If, for instance, the memory that is used for the first 16 MB of system
RAM cannot be ejected, inserted, or disabled, that memory may only be
represented by the System Address Map interfaces. But if memory can be ejected,
inserted, or disabled, it must be represented by a memory device.
9.13.1 Address Decoding
Memory devices must provide a _CRS object that describes
the physical address space that the memory decodes. If the memory can decode
alternative ranges in physical address space, the devices may also provide
_PRS, _SRS and _DIS objects. Other device objects may also apply if the device
can be ejected.
9.13.2 Example: Memory Device
Scope (\_SB){
Device (MEM0) {
Name (_HID, EISAID ("PNP0C80"))
Name (_CRS, ResourceTemplate
() {
QwordMemory
ResourceConsumer,
,
MinFixed,
MaxFixed,
Cacheable,
ReadWrite,
0xFFFFFFF,
0x10000000,
0x30000000,
0,
,,)
}
}
}
9.14 _UPC (USB Port Capabilities)
This optional object is a method that allows the platform
to communicate to the operating system, certain USB port capabilities that are
not provided for through current USB host bus adaptor specifications (e.g.
UHCI, OHCI and EHCI). If implemented by the platform, this object will be
present for each USB port (child) on a given USB host bus adaptor; operating
system software can examine these characteristics at boot time in order to gain
knowledge about the system's USB topology, available USB ports, etc. This
method is applicable to USB root hub ports as well as ports that are
implemented through integrated USB hubs.
Syntax
_UPC => UPCPackage
Return Value
UPCPackage: Package (PortIsConnectable,
PortConnectorType, Reserved0, Reserved1)
Where:
PortIsConnectable:ByteConst
If this value is non-zero
(0xFF), then the port is connectable. If this value is zero (0x00), then the port
is not connectable.
Note: The definition of a
'connectable' port is dependent upon the implementation of the USB port within
a particular platform. For example,
§ If
a USB port is user visible(as
indicated by the _PLD object) and connectable, then an end user can freely
connect and disconnect USB devices to the USB port.
§ If
a USB port is not user visible and is connectable, then an end user cannot
freely connect and disconnect USB devices to the USB port. A USB device that is
directly "hard-wired" to a USB port is an example of a USB port that
is not user visible and is connectable.
§ If
a USB port is not user visible and is not connectable, then the USB port is
physically implemented by the USB host controller, but is not being used by the
platform and therefore cannot be accessed by an end user.
It is illegal for a USB port
to be specified as visible and not connectable.
PortConnectorType:ByteConst
This field is used to specify
the host connector type. It is ignored by OSPM if the port is not user visible:
0x00: Type
'A' connector
0x01: Mini-AB
connector
0x02: ExpressCard
0x03 - 0xFE: Reserved
0xFF: Proprietary
connector
Reserved0: Dword
style='font-size:90%;font-family:"Courier New"'>Const
This value is reserved for
future use and must be zero.
Reserved1: Dword
style='font-size:90%;font-family:"Courier New"'>Const
This value is reserved for
future use and must be zero.
EXAMPLE
The following is an example of a port characteristics object implemented for a
USB host controller's root hub where:
§ 3 Ports are implemented; Port 1 is not user visible/not
connectable and Ports 2 and 3 are user visible and connectable.
§ Port 2 is located on the back panel
§ Port 3 has an integrated 2 port hub. Note that because this port
hosts an integrated hub, it is therefore not sharable with another host
controller (e.g. If the integrated hub is a USB2.0 hub, the port can never be
shared with a USB1.1 companion controller).
§ The ports available through the embedded hub are located on the
front panel and are adjacent to one another.
//
// Root hub device for this host controller. This controller
implements 3 root hub ports.
//
Device( RHUB) {
Name( _ADR, 0x00000000) //
root HUB always has a value of 0
// Root hub, port 1
Device( PRT1) {
// Address object for port 1. This
value must be 1
Name( _ADR, 0x00000001)
// USB port capabilities object.
This object returns the system
// specific USB port
configuration information for port number 1
// Because this port is
not connectable it is assumed to be not visible.
// Therefore a _PLD descriptor is
not required.
Name( _UPC, Package(){
0x00, //
Port is not connectable
0xFF, //
Connector type (N/A for non-visible ports)
0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 – must be zero
} // Device( PRT1)
//
// Root Hub, Port 2
//
Device( PRT2) {
// Address object for port
2. This value must be 2
Name(_ADR, 0x00000002)
Name( _UPC, Package(){
0xFF, //
Port is connectable
0x00, //
Connector type – Type 'A' 0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 – must be zero
// provide physical port location info
Name( _PLD, Buffer( 0x10) {
0x00000081, //
Revision 1, Ignore color
//
Color (ignored), width and height not
0x00000000, //
required as this is a standard USB 'A' type
//
connector
0x00000c69, //
User visible, Back panel, Vertical
//
Center, shape = vert. rectangle
0x00000003}) //
ejectable, requires OPSM eject assistance
} // Device( PRT2)
//
// Root Hub, Port 3
//
Device( PRT3) {
// Address object for port
3. This value must be 3
Name(_ADR, 0x00000003)
// Because this port is not
connectable it is assumed to be not visible.
// Therefore a _PLD descriptor is
not required.
Name( _UPC, Package(){
0x00, //
Port is not connectable
0xFF, //
Connector type (N/A for non-visible ports)
0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 - must be zero
// Declare the integrated hub
object
Device( IHUB) {
//
Address object for the hub. This value must be 0
Name(_ADR,
0x00000000)
// Integrated hub, port 1
Device(
PRT1) {
// Address object for the port.
Because the port is implemented on
// integrated hub port #1, this value
must be 1
Name(
_ADR, 0x00000001)
//
USB port characteristics object. This object returns the system
// specific USB port configuration
information for integrated hub port
// number 1
Name( _UPC, Package(){
0xFF, //
Port is connectable
0x00, //
Connector type – Type 'A' 0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 – must be zero
// provide physical port location info
Name( _PLD, Buffer( 0x10) {
0x00000081, //
Revision 1, Ignore color
//
Color (ignored), width and height not
0x00000000, //
required as this is a standard USB 'A' type
//
connector
0x000010a1, //
User visible, front panel, Vertical
//
lower, horz. Left, shape = horz. rectangle
0x00000003}) //
ejectable, requires OPSM eject assistance
} //
Device( PRT1)
//
// Integrated hub, port 2
//
Device( PRT2) {
// Address object for the port.
Because the port is implemented on
// integrated hub port #2, this value
must be 2
Name( _ADR, 0x00000002)
// USB port characteristics object.
This object returns the system
// specific USB port configuration
information for integrated hub port
// number 2
Name( _UPC, Package(){
0xFF, //
Port is connectable
0x00, //
Connector type – Type 'A' 0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 – must be zero
Name( _PLD, Buffer( 0x10) {
0x00000081, //
Revision 1, Ignore color
//
Color (ignored), width and height not
0x00000000, //
required as this is a standard USB 'A' type
//
connector
0x000012a1, //
User visible, front panel, Vertical
//
lower, horz. right, shape = horz. rectangle
0x00000003}) //
ejectable, requires OPSM eject assistance
} // Device( PRT2)
} // Device( IHUB)
} // Device( PRT3)
} // Device( RHUB)
9.14.1 USB 2.0 Host
Controllers and _UPC and _PLD
Platforms implementing USB2.0 host controllers that consist
of one or more USB1.1 compliant companion controllers (e.g. UHCI or OHCI) must
implement a _UPC and a _PLD object for each port USB port that can be routed
between the EHCI host controller and its associated companion controller. This
is required because a USB Port Capabilities object implemented for a port that
is a child of an EHCI host controller may not be available if the OSPM disables
the parent host controller. For example, if root port 1 on an EHCI host
controller is routable to root port 1 on its companion controller, then the
namespace must provide a _UPC and a _PLD object under each host controller's
associated port 1 child object.
EXAMPLE
Scope( \_SB) {
…
Device(PCI0) {
…
// Host controller (EHCI)
Device( USB0) {
// PCI device#/Function# for this HC. Encoded
as specified in the ACPI
// specification
Name(_ADR, 0xyyyyzzzz)
// Root hub device for this HC #1.
Device(RHUB) {
Name(_ADR, 0x00000000) //
must be zero for USB root hub
// Root hub, port 1
Device(PRT1) {
Name(_ADR, 0x00000001)
//
USB port configuration object. This object returns the system
// specific USB port configuration
information for port number 1
// Must match the _UPC declaration
for USB1.RHUB.PRT1 as it is this
// host controller's companion
Name( _UPC, Package(){
0xFF, //
Port is connectable
0x00, //
Connector type – Type 'A' 0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 – must be zero
// provide physical port location
info for port 1
// Must match the _UPC declaration
for USB1.RHUB.PRT1 as it is this
// host controller's companion
Name( _PLD, Buffer( 0x10) {
0x00000081, //
Revision 1, Ignore color
//
Color (ignored), width and height not
0x00000000, //
required as this is a standard USB 'A' type
//
connector
0x000010a1, //
User visible, front panel, Vertical
//
lower, horz. Left, shape = horz. rectangle
0x00000003}) //
ejectable, requires OPSM eject assistance
} // Device( PRT1)
//
// Define other ports, control
methods, etc
…
…
} // Device( RHUB)
} // Device( USB0)
// Companion Host controller (OHCI or
UHCI)
Device( USB1) {
// PCI device#/Function# for this HC. Encoded
as specified in the ACPI
// specification
Name(_ADR, 0xyyyyzzzz)
// Root hub device for this HC #1.
Device(RHUB) {
Name(_ADR, 0x00000000) //
must be zero for USB root hub
// Root hub, port 1
Device(PRT1) {
Name(_ADR, 0x00000001)
// USB port configuration object.
This object returns the system
// specific USB port configuration
information for port number 1
// Must match the _UPC declaration
for USB0.RHUB.PRT1 as this host
// controller is a companion to
the EHCI host controller
// provide physical port location
info for port 1
Name( _UPC, Package(){
0xFF, //
Port is connectable
0x00, //
Connector type – Type 'A' 0x00000000, //
Reserved 0 – must be zero
0x00000000}) //
Reserved 1 – must be zero
// Must match the _PLD declaration
for USB0.RHUB.PRT1 as this host
// controller is a companion to
the EHCI host controller
Name( _PLD, Buffer( 0x10) {
0x00000081, //
Revision 1, Ignore color
//
Color (ignored), width and height not
0x00000000, //
required as this is a standard USB 'A' type
//
connector
0x000010a1, //
User visible, front panel, Vertical
//
lower, horz. Left, shape = horz. rectangle
0x00000003}) //
ejectable, requires OPSM eject assistance
} // Device( PRT1)
//
// Define other ports, control
methods, etc
…
…
} // Device( RHUB)
} // Device( USB1)
} // Device( PCI0)
} // Scope( _\SB)
9.15 Device Object Name Collision
Devices containing both _HID and _CID may have device
specific control methods pertaining to both the device ID in the _HID and the
device ID in the _CID. These device specific control methods are defined by the
device owner (a standard body or a vendor or a group of vendor partners). Since
these object names are not controlled by a central authority, there is a likelihood
that the names of objects will conflict between two defining parties. The _DSM
object described in the next section solves this conflict.
9.15.1 _DSM (Device
Specific Method)
This optional object is a control method that enables
devices to provide device specific control functions that are consumed by the
device driver.
Arguments:
Arg0 (Buffer): UUID
Arg1 (Integer): Revision
ID
Arg2 (Integer): Function
Index
Arg3 (Package): Arguments
UUID –Universal Unique Identifier (16 Byte Buffer)
Revision ID – the
function's revision. This revision is specific to the UUID.
Function Index
– Represents a specific function whose meaning is specific to the UUID
and Revision ID. Function indices should start with 1. Function number zero is
a query function (see the special return code defined below).
Arguments – a
package containing the parameters for the function specified by the UUID, Revision ID and Function Index.
Successive revisions of Function Arguments must be backward compatible with earlier revisions. See section 9,
"ACPI Devices and Device Specific Objects", for any _DSM definitions for ACPI
devices. New UUIDs may also be created by OEMs and IHVs for custom devices and
other interface or device governing bodies (e.g. the PCI SIG), as long as the
UUID is different from other published UUIDs. Only the issuer of a UUID can
authorize a new Function Index, Revision
ID or Function Argument for that UUID.
Result Code:
Return – If Function
Index is zero, the return is
a buffer, with one bit for each function index, starting with zero. Bit 0
indicates support for at least one function for the specified UUID and Revision
ID. If set to zero, no functions are supported for the specified UUID and
Revision ID. If set to one, at least one function is supported. For all other
bits in the buffer, a bit is set to zero to indicate if the function index is
not supported for the specific UUID and Revision ID. If the bit representing a
particular function index would lie outside of the buffer, it should be assumed
to be 0 (that is, not supported).
If Function index is
non-zero, the return is any data object.
The type and meaning of the returned data object depends on the UUID and Revision ID.
Implementation Note
Since the purpose of the _DSM method is to avoid the name
space collision, the implementation of this method shall not use any other
method or data object which is not defined in this specification unless its
driver and usage is completely under the control of the platform vendor.
Example:
// _DSM – Device Specific Method
//
// Arg0: UUID Unique
function identifier
// Arg1: Integer Revision
Level
// Arg2: Integer Function
Index (0 = Return Supported Functions)
// Arg3: Package Parameters
Function(_DSM,{IntObj,BuffObj},{BuffObj, IntObj, IntObj, PkgObj})
{
//
// Switch based on which unique function
identifier was passed in
//
switch(Arg0)
{
//
// First function
identifier
//
case(ToUUID("893f00a6-660c-494e-bcfd-3043f4fb67c0"))
{
switch(Arg2)
{
//
//
Function 0: Return supported functions, based on revision
//
case(0)
{
switch(Arg1)
{
//
revision 0: functions 1-4 are supported
case(0)
{return (Buffer() {0x1F})}
//
revision 1: functions 1-5 are supported
case(1)
{return (Buffer() {0x3F})}
}
//
revision 2+: functions 1-7 are supported
return
(Buffer() {0x7F})
}
//
//
Function 1:
//
case(1)
{
…
function 1 code …
Return(Zero)
}
//
//
Function 2:
//
case(2)
{
…
function 2 code …
Return(Buffer(){0x00})
}
case(3)
{ … function 3 code …}
case(4)
{ … function 4 code …}
case(5)
{ if (LLess(Arg1,1) BreakPoint; … function 5 code … }
case(6)
{ if (LLess(Arg1,2) BreakPoint; … function 6 code … )
case(7)
{ if (LLess(Arg1,3) BreakPoint; … function 7 code … )
default
{BreakPoint }
}
}
//
// Second function
identifier
//
case(ToUUID("107ededd-d381-4fd7-8da9-08e9a6c79644"))
{
//
//
Function 0: Return supported functions (there is only one revision)
//
if
(LEqual(Arg2,Zero))
return
(Buffer() {0x3}) // only one function supported
//
//
Function 1
//
if
(LEqual(Arg2,One))
{
…
function 1 code …
Return(Unicode("text"))
}
//
//
Function 2+: Runtime Error
//
else
BreakPoint;
}
}
//
// If not one of the function identifiers we
recognize, then return a buffer
// with bit 0 set to 0 indicating no
functions supported.
//
return(Buffer(){0})
}
9.16 PC/AT RTC/CMOS Devices
Most
computers contain an RTC device which also contains battery-backed RAM
represented as a linear array of bytes. There is a standard mechanism for
accessing the first 64 bytes of non-volatile RAM in devices that are compatible
with the Motorola RTC/CMOS device that was in the IBM PC/AT. Newer devices
usually contain at least 128 bytes of battery-backed RAM. New PNP IDs were
assigned for these devices.
Certain
bytes within the battery-backed RAM have pre-defined values. In particular, the
time, date, month, year, century, alarm time and RTC periodic interrupt are
read-only.
9.16.1 PC/AT-compatible
RTC/CMOS Devices (PNP0B00)
The
standard PC/AT-compatible RTC/CMOS device is denoted by the PnP ID PNP0B00
an ACPI platform uses a device that is compatible with this device, it may
describe this in its ACPI namespace. ASL may then read and write this as a
linear 64-byte array. If PNP0B00 is used, ASL and ACPI operating systems may
not assume that any extensions to the CMOS exist.
Note: This means that the CENTURY field in the Fixed
ACPI Description Table may only contain values between 0 and 63.
This is an example of how this
device could be described:
Device (RTC0) {
Name(_HID, EISAID("PNP0B00"))
Name (_FIX, Package(1) {
EISAID("PNP0B00") }
)
Name(_CRS, ResourceTemplate() {
IO(Decode16, 0x70, 0x70, 0x1, 0x2)
}
OperationRegion(CMS1, CMOS, 0, 0x40)
Field(CMS1, ByteAcc, NoLock, Preserve) {
AccessAs(ByteAcc, 0),
CM00, 8,
,256,
CM01, 8,
CM02, 16,
, 216,
CM03, 8
}
9.16.2 Intel
PIIX4-compatible RTC/CMOS Devices (PNP0B01)
The
Intel PIIX4 contains an RTC/CMOS device that is compatible with the one in the
PC/AT. But it contains 256 bytes of non-volatile RAM. The first 64 bytes are
accessed via the same mechanism as the 64 bytes in the PC/AT. The upper 192
bytes are accessed through an interface that is only used on Intel chips. (See 82371AB
PCI-TO-ISA / IDEXCELERATOR (PIIX4) for details.)
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 (_FIX, Package(1) {
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
}
9.16.3 Dallas Semiconductor-compatible RTC/CMOS Devices (PNP0B02)
Dallas
Semiconductor RTC/CMOS devices are compatible with the one in the PC/AT, but
they contain 256 bytes of non-volatile RAM or more. The first 64 bytes are
accessed via the same mechanism as the 64 bytes in the PC/AT. The upper bytes
are accessed through an interface that is only used on Dallas Semiconductor
chips.
Any
platform containing this device or one that is compatible with it may use the
PNP ID PNP0B02. This will allow an ACPI-compatible OS to recognize the RTC/CMOS
device as using the Dallas Semiconductor programming interface. Thus, the array
of bytes that ASL can read and write with this device is 256 bytes long.
Description
of these devices is similar to the PIIX4 example above, and the CENTURY field
of the FADT may also contain values between 0 and 255.
9.17 Control Method User Presence Detection Device
The following section illustrates the operation and
definition of the Control Method User Presence Detection (UPD) device.
The user presence detection device can optionally support
power management objects (e.g. _PS0, _PS3) to allow the OS to manage the device's
power consumption.
The Plug and Play ID of an ACPI control method user
presence detection device is ACPI0009.
Table 9-9: Control Method User Presence Detection Device
Object
|
Description
|
_UPD
|
The current user presence detection reading. [Required]
|
_UPP
|
User presence detection polling frequency in tenths of
seconds. [Optional]
|
9.17.1 _UPD (User Presence Detect)
This control method returns the user presence detection
reading, indicating whether or not the user is currently present from the
perspective of this sensor. Three states are currently defined for UPD sensor
readings: absent, present, and unknown, represented by the values 0x00, 0x01, and 0xFF respectively. The
unknown state is used to convey that the sensor is currently unable to
determine user presence due to some environmental or other transient factor.
All other values are reserved.
Arguments:
None
Result Code:
0x00: Absent:A user is not currently detected by this sensor.
0x01: Present:A user is currently detected by this
sensor.
0xFF: Unknown: The sensor is currently unable to determine if a
user is present or absent.
9.17.2 _UPP (User
Presence Polling)
This optional object evaluates to a recommended polling frequency (in tenths of seconds) for this
user presence sensor. A value of zero – or the absence of this object
when other UPD objects are defined – indicates that the OS does not
need to poll the sensor in order to detect meaningful changes in user presence
(the hardware is capable of generating asynchronous notifications).
The use of polling is allowed but strongly discouraged by
this specification. OEMs should design systems that asynchronously notify OSPM
whenever a meaningful change in user presence occurs—relieving the OS of
the overhead associated with polling.
This value is specified as tenths of seconds. For example,
a value of 10 would be used to indicate a 1 second polling frequency. As this
is a recommended value, OSPM will consider other factors when determining the
actual polling frequency to use.
Arguments:
None
Result Code:
Zero: Polling
by the OS is not required.
All
other values: The recommended polling
frequency, in tenths of seconds.
9.17.3 User Presence Sensor Events
To
communicate changes in user presence to OSPM, AML code should issue a Notify
style=';font-family:"Courier New"'>(upd_device, 0x80)
> whenever a change in user presence has occurred. The
OS receives this notification and calls the _UPD control method to determine
the current user presence status.
UPD
notifications should be generated whenever a transition occurs between one of
the user presence states (absent, present, or unknown) – but at a level
of granularity that provides an appropriate response without overly taxing the
system with unnecessary interrupts.
9.18 I/O APIC Device
This optional device describes a discrete I/O APIC device
that is not bus enumerated (e.g., as a PCI device). Describing such a device in
the ACPI name space is only necessary if hot plug of this device is supported.
If hot plug of this device is not supported, an MADT I/O APIC (section 5.2.11.6,"I/O
APIC") entry or I/O SAPIC (section 5.2.11.12, "I/O SAPIC Structure") entry is
sufficient to describe this device.
An I/O APIC device is an I/O unit that complies with either
of the APIC interrupt models supported by ACPI. These interrupt models are
described Section 5.2.11.6,"I/O APIC" and Section 5.2.11.12,"I/O SAPIC
Structure". If the device is an I/O unit that complies with the APIC interrupt
model, it is declared using the ACPI000A identifier. If this device is an I/O
unit that complies with the SAPIC interrupt model, it is declared using the
ACPI000B identifier. If this device complies with both the APIC and SAPIC
interrupt models (I/OxAPIC), it is declared using the ACPI0009 identifier.
An I/O APIC device declared using any of the above
identifiers must contain a _GSB
object as defined in Section 6.2.5, "_GSB (Global System Interrupt Base)" to
report its Global System Interrupt Base. It must also contain a _CRS object
that reports the base address of the I/O APIC device. The _CRS object is
required to contain only one resource, a memory resource pointing to the I/O
APIC register base.
Note: because the _CRS and _GSB methods provide sufficient
information, it is not necessary to provide _MAT under an I/O APIC device.
For an I/O APIC device that is described both in the MADT
and in the name space, the base address described in the MADT entry must be the
same as the base address in the IO APIC device _CRS at boot time. OSPM must
use the information from the MADT until such a time as the _CRS and _GSB
methods in the name space device can be processed. At this point OSPM must
ignore the MADT entry.
10 Power Source Devices
This section specifies the battery and AC adapter device
objects OSPM uses to manage power resources.
A battery device is required to either have a Smart Battery
subsystem or a Control Method Battery interface
as described in this section. OSPM is required to be able to connect and manage
a battery on either of these interfaces. This section describes these
interfaces.
In the case of a compatible ACPI Smart Battery Table, the
Definition Block needs to include a
Bus/Device package for the SMB-HC. This will install an OS-specific driver for
the SMBus, which in turn will locate the components of the Smart Battery
subsystem. In addition to the battery or batteries, the Smart Battery subsystem
includes a charger and a manager device to handle subsystems with multiple
batteries.
The Smart Battery System Manager is one implementation of a
manager device that is capable of arbitrating among the available power sources
(AC power and batteries) for a system. It provides a superset of the Smart
Battery Selector functionality, such as safely responding to power events (AC
versus battery power), inserting and removing batteries and notifying the OS of
all such changes. Additionally, the Smart Battery System Manager is capable of
handling configurations including simultaneous charging and discharging of
multiple batteries. Unlike the Smart Battery Selector that shares
responsibility for configuring the battery system with OSPM, the Smart Battery
System Manager alone controls the safe configuration of the battery system and
simply issues status changes to OSPM when the configuration changes. Smart
Battery System Manager is the recommended solution for handling
multiple-battery systems.
10.1 Smart Battery Subsystems
The Smart Battery subsystem is defined by the:
· System
Management Bus Specification (SMBS)
· Smart
Battery Data Specification (SBDS)
· Smart
Battery Charger Specification (SBCS)
· Smart
Battery System Manager Specification (SBSM)
· Smart
Battery Selector Specification (SBSS)
An ACPI-compatible Smart Battery subsystem consists of:
· An
SMB-HC (CPU to SMB-HC) interface
· At
least one Smart Battery
· A
Smart Battery Charger
· Either
a Smart Battery System Manager or a Smart Battery Selector if more than one
Smart Battery is supported
In such a subsystem, a standard way of communicating with a
Smart Battery and Smart Battery Charger is through the SMBus physical
protocols. The Smart Battery System Manager or Smart Battery Selector provides
event notification (battery insertion/removal, and so on) and charger SMBus
routing capability for any Smart Battery subsystem. A typical Smart Battery
subsystem is illustrated below:
Figure 10-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 following table.
Table 10-1 Example SMBus Device Slave
Addresses
SMBus Device Description
|
SMBus Slave Address (A0-A6)
|
SMBus Host Slave Interface
|
0x8
|
Smart Battery Charger/Charger Selector or Charger System
Manager
|
0x9
|
Smart Battery System Manager or Smart Battery Selector
|
0xA
|
Smart Battery
|
0xB
|
Each SMBus device has up to 256 registers that are
addressed through the SMBus protocol's Command value. SMBus devices are addressed by providing the slave address with
the desired register's 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-HC that resides in embedded controller
address space; however, an OS can support any SMB-HC that has a native SMB-HC device
driver.
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)
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.
10.1.1 ACPI Smart Battery Status
Change Notification Requirements
The Smart Battery System Manager, the Smart Battery
Selector, and the Smart Battery Charger each have an optional mechanism for
notifying the system that the battery configuration or AC status has changed. ACPI requires that this interrupt
mechanism be through the SMBus Alarm Notify mechanism.
For systems using an embedded controller as the SMBus host,
a battery system device issues a status change notification by either mastering
the SMBus to send the notification directly to the SMBus host, or by emulating
it in the embedded controller. In either case, the process is the same. After
the notification is received or emulated, the embedded controller asserts an
SCI. The source of the SCI is identified by a GPE that indicates the SCI was
caused by the embedded controller. The embedded controller's status register
alarm bit is set, indicating that the SMBus host received an alarm message
Alarm Address Register contains the address of the SMBus device that originated
the alarm and the Alarm Data Registers contain the contents of that device's
status register.
10.1.1.1 Smart Battery Charger
This requires a Smart Battery Charger, on a battery or AC
status change, to generate an SMBus Alarm Notify. The contents of the Smart
Battery Charger's ChargerStatus() command register (0x13) is placed in the
embedded controller's Alarm Data Registers, the Smart Battery Charger's slave
address (0x09) is placed in the embedded
controller's Alarm Address Register and the EC's Status Register's Alarm bit is
set. The embedded controller then asserts an SCI.
10.1.1.2 Smart Battery Charger with optional System Manager or
Selector
A Smart Battery Charger that contains the optional System
Manager or Selector function (as indicated by the ChargerSpecInfo() command
register, 0x11, bit 4) is required to generate an SMBus Alarm Notify on a
battery or AC status change. The content of the Smart Battery Charger with an
optional System Manager, the BatterySystemState() command register (0x21) (or
in the case of an optional Selector, the SelectorState() (0x01) ), is placed in
the EC's Alarm Data Registers, the Smart Battery Charger's slave address (0x09)
is placed in the embedded controller's Alarm Address Register, and the embedded
controller's Status Register's Alarm bit is set. The embedded controller then
asserts an SCI.
10.1.1.3 Smart Battery System Manager
The Smart Battery System Manager is required to generate an
SMBus Alarm Notify on a battery or AC status change. The content of the Smart
Battery System Manager's BatterySystemState() command register (0x01) is placed
in the EC's Alarm Data Registers, the Smart Battery System Manager's slave
address (0x0A) is placed in the EC's Alarm Address Register, and the embedded
controller's Status Register's Alarm bit is set. The embedded controller then
asserts an SCI.
10.1.1.4 Smart Battery Selector
The requirements for the Smart Battery Selector are the
same as the requirements for the Smart Battery System Manager, with the
exception that the contents of the SelectorState() command register (0x01) are
used instead of BatterySystemState(). The Smart Battery Selector is a subset of
the Smart Battery System Manager and does not have the added support for
simultaneous charge/discharge of multiple batteries. The System Manager is the
preferred implementation.
10.1.2 Smart Battery Objects
The Smart Battery subsystem requires a number of objects to
define its interface. These are summarized below:
Table 10-2 Smart Battery Objects
Object
|
Description
|
_HID
|
This is the hardware ID named object that contains a string.
For Smart Battery subsystems, this object returns the value of "ACPI0002."
This identifies the Smart Battery subsystem to the Smart Battery driver.
|
_SBS
|
This is the Smart Battery named object that contains a DWORD.
This named object returns the configuration of the Smart Battery subsystem
and is encoded as follows: 0 – Maximum of one Smart Battery and no Smart Battery
System Manager or Smart Battery Selector.
1 – Maximum of one Smart Battery and a Smart Battery
System Manager or Smart Battery Selector.
2 – Maximum of two Smart Batteries and a Smart Battery
System Manager or Smart Battery Selector.
3 – Maximum of three Smart Batteries and a Smart Battery
System Manager or Smart Battery Selector.
4 – Maximum of four Smart Batteries and a Smart Battery
System Manager or Smart Battery Selector.
The maximum number of batteries is for the system. Therefore,
if the platform is capable of supporting four batteries, but only two are
normally present in the system, then this field should return 4. Notice that
a value of 0 indicates a maximum support of one battery and there is no Smart
Battery System Manager or Smart Battery Selector present in the system.
|
10.1.3 Smart Battery Subsystem
Control Methods
As the SMBus is not an enumerable bus, all devices on the
bus must be declared in the ACPI name space. As the Smart Battery driver
understands Smart Battery, Smart Battery Charger, and Smart Battery System
Manager or Smart Battery Selector; only a single device needs to be declared
per Smart Battery subsystem. The driver gets information about the subsystem
through the hardware ID (which defines a Smart Battery subsystem) and the
number of Smart Batteries supported on this subsystem (_SBS named object)
ACPI Smart Battery table indicates the energy levels of the platform at which
the system should warn the user and then enter a sleeping state. The Smart
Battery driver then reflects these as threshold alarms for the Smart Batteries.
The _SBS control method returns the configuration of the
Smart Battery subsystem. This named object returns a DWORD value with a number
from 0 to 4. If the number of batteries is greater than 0, then the Smart
Battery driver assumes that a Smart Battery System Manager or Smart Battery Selector
is present. If 0, then the Smart Battery driver assumes a single Smart Battery
and neither a Smart Battery System Manager nor Smart Battery Selector is
present.
A Smart 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.
10.1.3.1 Example: Single Smart Battery Subsystem
This section illustrates how to define a Smart Battery
subsystem containing a single Smart Battery and charger. The platform
implementation is illustrated below:
Figure 10-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-HC interface. The embedded controller
interface sits at system I/O port addresses 0x62 and 0x66. The SMB-HC is 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.
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
10.1.3.2 Multiple Smart Battery Subsystem: Example
This section illustrates how to define a Smart Battery
subsystem that contains three Smart Batteries, a Smart Battery System Manager,
and a Smart Battery Charger. The platform implementation is illustrated below:
Figure 10-3 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-HC interface. The embedded controller
interface sits at system I/O port addresses 0x100 and 0x101. The SMB-HC resides
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:
Device (EC1) {
Name (_HID, EISAID("PNP0C09"))
Name (_CRS,
ResourceTemplate () { //
port 0x100 and 0x101
IO(Decode16,
0x100, 0x100, 0, 2)
}
)
Name (_GPE, 1)
Device (SMB1) {
Name (_HID,
"ACPI0001") // Smart
Battery Host Controller
Name (_EC, 0x9031) //
EC offset (0x90), Query (0x31)
Device (SBS1){ //
Smart Battery Subsystem
Name
(_HID, "ACPI0002") // Smart Battery
Subsystem ID
Name
(_SBS, 0x3) //
Indicates support for three batteries
} // end of SBS1
} // end of SMB1
} // end of EC
10.2 Control Method Batteries
The following section illustrates the operation and
definition of the Control Method Battery.
10.2.1 Battery Events
The AML code handling an SCI for a battery event notifies
the system of which battery's status may have changed. The OS uses the _BST
control method to determine the current status of the batteries and what
action, if any, should be taken (for more information about the _BST control
method, see section 10.2.2, "Battery Control Methods"). The typical action is
to notify applications monitoring the battery status to provide the user with
an up-to-date display of the system battery state. But in some cases, the
action may involve generating an alert or even forcing a system into a sleeping
state. In any case, any changes in battery status should generate an SCI in a
timely manner to keep the system power state UI consistent with the actual
state of the system battery (or batteries).
Unlike most other devices, when a battery is inserted or
removed from the system, the device itself (the battery bay) is still
considered to be present in the system. For most systems, the _STA for this
device will always return a value with bits 0-3 set and will toggle bit 4 to
indicate the actual presence of a battery (see section 6.3.7, "_STA [Status]").
When this insertion or removal occurs, the AML code handler for this event
should issue a Notify(battery_device,
0x81) to indicate that the static battery information has changed. For systems
that have battery slots in a docking station or batteries that cannot be
surprise-removed, it may be beneficial or necessary to indicate that the entire
device has been removed. In this case, the standard methods and notifications
described in section 6.3, "Device Insertion, Removal, and Status Objects,"
should be used.
When the present state of the battery has changed or when
the trip point set by the _BTP control method is reached or crossed, the
hardware will assert a general purpose event. The AML code handler for this
event issues a Notify(battery_device,
0x80) on the battery device. This notification is also sent when the Status
Flags returned from _BMD change.
In the case where the remaining battery capacity becomes
critically low, the AML code handler issues a Notify(battery_device, 0x80) and reports the
battery critical flag in the _BST object. The OS performs an emergency
shutdown. For a full description of the critical battery state, see section
3.9.4, "Low Battery Levels."
Sometimes the value to be returned from _BST or _BIF will
be temporarily unknown. In this case, the method may return the value
0xFFFFFFFF as a placeholder. When the value becomes known, the appropriate
notification (0x80 for _BST or 0x81 for BIF) should be issued, in like manner
to any other change in the data returned by these methods. This will cause OSPM
to re-evaluate the method—obtaining the correct data value.
When one or more of the status flags returned by the _BMD
control method change, AML code issues a Notify(battery_device, 0x82) on the battery device unless this
change occurs during a call to _BMC and the value of the status flags in _BMD
match the value passed in to _BMC. If the value of the status bits cannot be
set to reflect the action requested by the executing _BMC, the AML code will
issue this notification. For example, calling _BMC with bit 0 set to initiate
a calibration cycle while AC power is not available will cause AML to issue a Notify(battery_device, 0x82).
10.2.2 Battery Control Methods
The Control Method Battery is a battery with an AML code
interface between the battery and the host PC. The battery interface is
completely accessed by AML code control methods, allowing the OEM to use any
type of battery and any kind of communication interface supported by ACPI. OSPM
requires accurate battery data to perform optimal power management policy and
to provide the end user with a meaningful estimation of remaining battery life.
As such, control methods that return battery information should calculate this
information rather than return hard coded data.
A Control Method Battery is described as a device object.
Each device object supporting the Control Method Battery interface contains the
following additional control methods. When there are two or more batteries in
the system, each battery will have an independent device object in the name
space.
Table 10-3 Battery Control Methods
Object
|
Description
|
_BIF
|
Returns static information about a battery (in other words,
model number, serial number, design voltage, and so on).
|
_OSC
|
OSPM Capabilities conveyance for batteries.
|
_BST
|
Returns the current battery status (in other words, dynamic
information about the battery, such as whether the battery is currently
charging or discharging, an estimate of the remaining battery capacity, and
so on).
|
_BTP
|
Sets the Battery Trip point, which generates an SCI when
batterycapacity reaches the specified point.
|
_PCL
|
List of pointers to the device objects representing devices
powered by the battery.
|
_STA
|
Returns general status of the battery (for a description of
the _STA control method, see section 6.3.7, "_STA (Status]").
|
_BTM
|
Returns estimated runtime at the present average rate of
drain, or the runtime at a specified rate.
|
_BMD
|
Returns battery information related to battery recalibration
and charging control.
|
_BMC
|
Control calibration and charging
|
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.
10.2.2.1 _BIF (Battery Information)
This object returns the static portion of the Control
Method Battery information. This information remains constant until the battery
is changed.
Arguments:
None
Result Code:
Package {
// ASCIIZ is ASCII character string terminated
with a 0x00.
Power Unit //DWORD
Design Capacity //DWORD
Last Full Charge Capacity //DWORD
Battery Technology //DWORD
Design Voltage //DWORD
Design Capacity of Warning //DWORD
Design Capacity of Low //DWORD
Battery Capacity Granularity 1 //DWORD
Battery Capacity Granularity 2 //DWORD
Model Number //ASCIIZ
Serial Number //ASCIIZ
Battery Type //ASCIIZ
OEM Information //ASCIIZ
}
Table 10-4 _BIF Method Result Codes
Field
|
Format
|
Description
|
Power Unit
|
DWORD
|
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
|
Battery's 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
|
DWORD
|
0x00000000 – Primary (for example, non-rechargeable)
0x00000001 – Secondary (for example, rechargeable)
|
Design Voltage
|
DWORD
|
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
|
DWORD
|
Battery capacity granularity between low and warning in [mAh]
or [mWh]. That is, this is the smallest increment in capacity that the
battery is capable of measuring. See note below for more details
|
Battery Capacity Granularity 2
|
DWORD
|
Battery capacity granularity between warning and Full in [mAh]
or [mWh]. That is, this is the smallest increment in capacity that the
battery is capable of measuring. This may be a different value than Battery
Capacity Granularity 1 to accommodate systems where the granularity accuracy
may change depending on the battery level. See note below for more details.
|
Model Number
|
ASCIIZ
|
OEM-specific Control Method Battery model number
|
Serial Number
|
ASCIIZ
|
OEM-specific Control Method Battery serial number
|
Battery Type
|
ASCIIZ
|
The OEM-specific Control Method Battery type
|
OEM Information
|
ASCIIZ
|
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.
|
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).
· On a multiple-battery system, all batteries in the
system must use the same power unit.
· The definition of battery capacity granularity has
been clarified. For OSPM to determine if systems support the clarified
definition of battery capacity granularity, OSPM may evaluate an _OSC method at
the battery scope to indicate support for this capability, and for the platform
to indicate if it supports these extended capabilities.
10.2.2.2 _OSC
Definition for Control Method Battery
_OSC for
control method battery is uniquely identified by the UUID: f18fc78b-0f15-4978-b793-53f833a1d35b
The
Revision 1 capabilities described under this _OSC are defined in Table 10-5.
Table 10-5 Control Method Battery _OSC
Capabilities DWORD2 Bit Definitions
Capabilities DWORD2
bits
|
Interpretation
|
0
|
0 - OS does not support
revised battery granularity definition.
1 - OS
supports revised battery granularity definition.
|
1
|
0 - OS does not support
specifying wake on low battery user preference.
1 - OS supports
specifying wake on low battery user preference, See section 9.1.3, "_BLT
Battery Level Threshold) for more information.
|
2-31
|
Reserved
|
Bits defined in Capabilities
DWORD2 provide information regarding OS supported features. Contents in DWORD2
are passed one-way; the OS will disregard the corresponding bits of DWORD2 in
the Return Code.
10.2.2.3 _BST (Battery Status)
This object returns the present battery status. Whenever
the Battery State value changes, the
system will generate an SCI to notify the OS.
Arguments:
None
Result Code:
Package {
Battery State //DWORD
Battery Present Rate //DWORD
Battery Remaining Capacity //DWORD
Battery Present Voltage //DWORD
}
Table 10-6 _BST Method Result Codes
Field
|
Format
|
Description
|
Battery State
|
DWORD
|
Bit values. Notice that the Charging bit and the Discharging
style='font-style:normal'> 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.4, "Low Battery Levels"). This does not mean battery failure.
|
Battery Present Rate
|
DWORD
|
Returns the power or current being supplied or accepted
through the battery's terminals (direction depends on the Battery State value). The Battery Present Rate
style='font-style:normal'> 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
|
Battery Remaining Capacity
|
DWORD
|
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
|
Battery Present Voltage
|
DWORD
|
Returns the voltage across the battery's 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 Alkaline-Manganese 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 battery's remaining capacity [%] as a
value in the range 0 through 100 as follows:
10.2.2.4 _BTP (Battery Trip Point)
This object is used to set a trip point to generate an SCI
whenever the Battery Remaining Capacity
reaches or crosses the value specified in the _BTP object. Specifically, if Battery
Remaining Capacity is less than the last
argument passed to _BTP, a notification must be issued when the value of Battery
Remaining Capacity rises to be greater than
or equal to this trip-point value. Similarly, if Battery Remaining
Capacity is greater than the last argument
passed to _BTP, a notification must be issued when the value of Battery
Remaining Capacity falls to be less than or
equal to this trip-point value. The last argument passed to _BTP will be kept
by the system.
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
10.2.2.5 _BTM
(Battery Time)
This optional object returns the estimated runtime of the
battery while it is discharging.
Arguments:
Rate at which the battery is expected to discharge:
0x00000000 – indicates
that the battery will continue discharging at the current rate. The rate
should be based on the average rate of drain, not the current rate of drain.
0x00000001 – 0x7FFFFFFF – the rate (in mA or mW).
Result Code:
0x00000000 – Specified rate is too large for
batteries to supply. If the argument was 0x00000000, _BTM should only return
0x00000000 if the battery is critical.
0x00000001 – 0xFFFFFFFE – Estimated runtime in seconds.
0xFFFFFFFF – Runtime is unknown.
10.2.2.6 _BMD
(Battery Maintenance Data)
This optional object returns information about the
battery's capabilities and current state in relation to battery calibration and
charger control features. If the _BMC object (defined below) is present under
a battery device, this object must also be present. Whenever the Status
Flags value changes, AML code will issue a Notify(battery_device, 0x82). In addition, AML will issue a Notify(battery_device
style='font-style:normal'>, 0x82) if evaluating _BMC did not result in causing
the Status Flags to be set as
indicated in that argument to _BMC. AML is not required to issue Notify(battery_device, 0x82) if the Status Flags
style='font-style:normal'> change while evaluating _BMC unless the change does
not correspond to the argument passed to _BMC..
Arguments:
None
Result Code:
Package {Status Flags //DWORD
Capability Flags //DWORD
Recalibrate Count //DWORD
Quick Recalibrate Time //DWORD
Slow Recalibrate Time //DWORD}
Table 10-7 _BMD Method Result Codes
Field
|
Format
|
Description
|
Status Flags
|
DWORD
|
Bit values. Bit0 is mutually exclusive with Bit1 and Bit2.
If the charger is being manually controlled, there cannot be an AML
controlled calibration cycle.
Bit0 – 1 indicates the battery is running an AML controlled calibration cycle
Bit1 – 1 indicates that charging has been disabled.
Bit2 – 1 indicates the battery is configured to discharge while AC power is available.
Bit3 – 1 indicates that the battery should be recalibrated.
Bit4 – 1 indicates that the OS should put the system into standby to speed charging during a
calibration cycle. This is optional (based on user preference) if "Slow
Recalibrate Time" is not equal to 0x00000000.
Bit5 – Bit31 – reserved.
|
Capability Flags
|
DWORD
|
Bit values that describe the capabilities of the battery
system. These bits allows a battery system with more limited capabilities to
still be calibrated by OSPM.
Bit0 – 1
indicates that an AML controlled calibration cycle is supported.
Bit1 – 1
indicates that disabling the charger is supported.
Bit2 – 1
indicates that discharging while running on AC is supported.
Bit3 – 1
indicates that calling _BMC for one battery will affect the state of all
batteries in the system. This is for battery systems that cannot control
batteries individually.
Bit4 – 1
indicates that calibration should be done by first fully charging the battery
and then discharging it. Not setting this bit will indicate that calibration
can be done by simply discharging the battery.
Bit4 – Bit31 – reserved.
|
Recalibrate Count
|
DWORD
|
This is used by battery systems that can't detect when
calibration is required, but wish to recommend that the battery should be
calibrated after a certain number of cycles. Counting the number of cycles
and partial cycles is done by the OS.
0x00000000 – Only calibrate when Status Flag bit 3 is set.
0x00000000 – 0xFFFFFFFF – calibrate battery after detecting this many battery
cycles.
|
Quick Recalibrate Time
|
DWORD
|
Returns the estimated time it will take to calibrate the
battery if the system is put into standby whenever Status Flags Bit4 is set. While the AML controlled calibration
cycle is in progress, this returns the remaining time in the calibration
cycle.
0x000000000 – indicates that standby while calibrating the battery is not supported. The
system should remain in S0 until calibration is completed.
0x00000001 – 0xFFFFFFFE – estimated recalibration time in seconds.
0xFFFFFFFF – indicates that the estimated time to recalibrate the battery is unknown.
|
Slow Recalibrate Time
|
DWORD
|
Returns the estimated time it will take to calibrate the
battery if Status Flag Bit4 is
ignored. While the AML controlled calibration cycle is in progress, this
returns the remaining time in the calibration cycle.
0x000000000 – indicates that battery calibration may not be successful if Status Flags Bit4 is ignored.
0x00000001 – 0xFFFFFFFE – estimated recalibration time in seconds.
0xFFFFFFFF – indicates that the estimated time to recalibrate the battery is unknown.
|
See section 3.9.5, "Battery Calibration" for an overview of
Battery Calibration.
The Capability Flags
and Recalibration Count are used
to indicate what functions are controlled by AML and what functions are
controlled by OSPM as described in section 3.9.5, "Battery Calibration"
the system does not implement an AML controlled calibration cycle (bit 0), it
may indicate using bit 1 and bit 2 that the OS can control a generic
calibration cycle without prompting the user to remove the power cord. Recalibration
Count may be used to indicate that the BIOS
cannot determine when calibration should be preformed so bit 3 of the Status
Flags will never be set. In that case,
OSPM will attempt to count the number of cycles.
Bit3 is used by systems that do not have individual control
over the batteries and can only perform calibration on all batteries in the
system at once. On such a system, if one battery requests calibration and
another battery does not, the OS may suggest that the user remove the battery
that doesn't need calibration, before initiating the calibration cycle. When
this bit is set, reading the Recalibrate Time from either battery should give
the time to recalibrate all batteries present in the system.
10.2.2.7 _BMC
(Battery Maintenance Control)
This object is used to initiate calibration cycles or to
control the charger and whether or not a battery is powering the system. This
object is only present under a battery device if the _BMD Capabilities Flags have bit 0, 1, or 2 set.
Arguments:
Flags indicating which features to enable:
Bit0 – Set to initiate
an AML controlled calibration cycle. Clear to end the calibration cycle.
Bit1 – Set to disable
charging. Clear to enable charging.
Bit2 – Set to allow the
battery to discharge while AC power is available. Clear to prevent discharging
while AC power is available.
Result Code:
None
See section 3.9.5 for an overview of Battery Calibration.
Evaluating this object with bit0 set will initiate an AML
controlled recalibration cycle if _BMD indicates that this is supported. The
calibration cycle is controlled by the platform and will typically include
disabling the AC adapter and discharging the battery, then charging the
battery. While the battery is charging, the BIOS should set Bit4 of the Status
flags returned by _BMD if it is possible to put the system into standby during
calibration to speed up charging. Evaluating this with Bit0 equal to 0 will
abort the calibration cycle if one is in process. If the BIOS determines that
the calibration cycle must be aborted (for example AC power is lost), or the
calibration completes successfully, the BIOS will end the cycle automatically,
clear the _BMD Status Flag Bit0, and
send a notify 0x82. While the calibration cycle is in process, the battery
will report data normally, so the OS must disable battery alarms.
Bit1 and Bit2 may not be used in conjunction with the AML
controlled calibration cycle. Having Bit0 set will override Bit1 and Bit2.
Bit1 will prevent the battery from charging even though AC power is connected.
Bit2 will allow the system to draw its power from the battery even though AC
power is available. When the battery is no longer capable of delivering
current, this setting is automatically cleared, and the system will continue
running off AC power without interruption. In addition, if AC power is lost
this bit will be cleared. When AC power comes back, the OS must set the bit
again if the user wants to continue discharging. When the system clears this
bit automatically, it will result in a change in the Status Flags returned by _BMD. This will cause a notify 0x82.
Bit1 is only cleared automatically if an AML controlled calibration cycle is
initiated.
When a battery is discharging because Bit2 is set, the _PSR
method of the AC adapter device will report that AC is offline because the
system is not running off of the AC adapter. If the batteries are controlled
individually (Bit3 of the _BMD Capabilities Flags), setting either battery to discharge will cause _PSR to report AC
offline. If more than one battery in the system has Bit2 set to discharge the
battery, it is up to the system to decide which battery to discharge, so only
on a system that discharges the batteries one at a time, a battery with Bit2
set may not be discharging if another battery in the system is being
discharged.
If Batteries are not controlled individually, calling _BMC
will initiate calibration, disable charge, and/or allow discharge on all
batteries in the system. The state of these batteries will be reflected in the
_BMD Status Flags for all batteries.
10.3 AC Adapters and Power Source Objects
The Power Source objects describe the power source used to
run the system.
Table 10-8 Power Source Control Methods
Object
|
Description
|
_PSR
|
Returns present power source device.
|
_PCL
|
List of pointers to powered devices.
|
10.3.1 _PSR (Power Source)
Returns the current power source devices. Used for the AC
adapter and is located under the AC adapter object in name space. Used to
determine if system is running off the AC adapter. This will report that the
system is not running on the AC adapter if any of the batteries in the system
is being forced to discharge through _BMC.
Arguments:
None
Result Code:
0x00000000 – Off-line
0x00000001 – On-line
10.3.2 _PCL (Power Consumer List)
This object evaluates to a list of pointers, each pointing
to a device or a bus powered by the power source device. Pointing to a bus
indicates that all devices under the bus are powered by the power source
device.
10.4 Example: Power Source Name Space
The ACPI name space for a computer with an AC adapter and
two batteries associated with a docking station that has an AC adapter and a
battery is shown in Figure 10-4.
Figure 10-4 Power Source Name Space
Example that Includes a Docking Station
11 Thermal Management
This section describes the ACPI thermal model and specifies
the ACPI Namespace objects OSPM uses for thermal management of the platform.
11.1 Thermal Control
ACPI defines interfaces that allow OSPM to be proactive in
its system cooling policies. With OSPM in control of the operating environment,
cooling decisions can be made based on the system's application load, the
user's preference towards performance or energy conservation, and thermal
heuristics. Graceful shutdown of devices or the entire system at critical heat
levels becomes possible as well. The following sections describe the ACPI
thermal model and the ACPI Namespace objects available to OSPM to apply
platform thermal management policy.
The ACPI thermal model is based around conceptual platform regions
called thermal zones that physically
contain devices, thermal sensors, and cooling controls. Generally speaking, the
entire platform is one large thermal zone, but the platform can be partitioned
into several ACPI thermal zones if necessary to enable optimal thermal
management.
ACPI Thermal zones are a logical collection of interfaces
to temperature sensors, trip points, thermal property information, and thermal
controls. Thermal zone interfaces apply either thermal zone wide or to
specific devices, including processors, contained within the thermal zone. ACPI
defines namespace objects that provide the thermal zone-wide interfaces in
section 11.3, "Thermal Objects". A subset of these objects may also be defined
under devices. OS implementations compatible with the ACPI 3.0 thermal model,
interface with these objects but also support OS native device driver
interfaces that perform similar functions at the device level. This allows the
integration of devices with embedded thermal sensors and controls, perhaps not
accessible by AML, to participate in the ACPI thermal model through their
inclusion in the ACPI thermal zone. OSPM is responsible for applying an
appropriate thermal policy when a thermal zone contains both thermal objects
and native OS device driver interfaces for thermal control.
Some devices in a thermal zone may be comparatively large
producers of thermal load in relation to other devices in the thermal zone.
Devices may also have varying degrees of thermal sensitivity. For example, some
devices may tolerate operation at a significantly higher temperature than other
devices. As such, the platform can provide OSPM with information about the
platform's device topology and the resulting influence of one device's thermal
load generation on another device. This information must be comprehended by
OSPM for it to achieve optimal thermal management through the application of
cooling controls.
ACPI expects all temperatures to be represented in tenths
of degrees. This resolution is deemed sufficient to enable OSPM to perform
robust platform thermal management.
Figure 11-1 ACPI Thermal Zone
11.1.1 Active, Passive, and
Critical Policies
There are three cooling policies that OSPM uses to control
the thermal state of the hardware. The policies are active, passive and critical.
· Active Cooling. OSPM
takes a direct action such as turning on a fan. Applying active cooling controls
typically consume power and produce some amount of noise, but are able to cool a
thermal zone without limiting system performance. Active cooling temperature trip
points declare the temperature thresholds OSPM uses to decide when to start or
stop different active cooling devices.
· Passive Cooling. OSPM
reduces the power consumption of devices to reduce the temperature of a thermal
zone, such as slowing (throttling) the processor clock. Applying passive
cooling controls typically produces no user-noticeable noise. Passive cooling temperature
trip points specify the temperature thresholds where OSPM will start or stop
passive cooling.
· Critical Trip Points.
These are threshold temperatures at which OSPM performs an orderly, but
critical, shutdown of a device or the entire system. The _HOT object declares
the critical temperature at which OSPM may choose to transition the system into
the S4 sleeping state, if supported, The _CRT object declares the critical
temperature at which OSPM must perform a critical shutdown.
When a thermal zone appears in the ACPI Namespace or when a
new device becomes a member of a thermal zone, OSPM retrieves the temperature
thresholds (trip points) at which it executes a cooling policy. When OSPM
receives a temperature change notification, it evaluates the thermal zone's
temperature interfaces to retrieve current temperature values. OSPM compares
the current temperature values against the temperature thresholds. If any
temperature is greater than or equal to a corresponding active trip point then
OSPM will turn on the associated active cooling device(s). If any temperature
is greater than or equal to a corresponding passive trip point then OSPM will
perform passive cooling. If the _TMP object returns a value greater than or
equal to the value returned by the _HOT object then OSPM may choose to
transition the system into the S4 sleeping state, if supported. If the _TMP object
returns a value greater than or equal to the value returned by the _CRT object then
OSPM must shut the system down. Embedded Hot and Critical trip points may also
be exposed by individual devices within a thermal zone. Upon passing of these
trip points, OSPM must decide whether to shut down the device or the entire
system based upon device criticality to system operation. OSPM must also
evaluate the thermal zone's temperature interfaces when any thermal zone
appears in the namespace (for example, during system initialization) and must
initiate a cooling policy as warranted independent of receipt of a temperature
change notification. This allows OSPM to cool systems containing a thermal zone
whose temperature has already exceeded temperature thresholds at initialization
time.
An optimally designed system that uses several thresholds
can notify OSPM of thermal increase or decrease by raising an event every
several degrees. This enables OSPM to anticipate thermal trends and incorporate
heuristics to better manage the system's temperature.
To implement a preference towards performance or energy
conservation, OSPM can request that the platform change the priority of active
cooling (performance) versus passive cooling (energy conservation/silence) by evaluating
the _SCP (Set Cooling Policy) object for the thermal zone or a corresponding OS-specific
interface to individual devices within a thermal zone.
11.1.2 Dynamically Changing
Cooling Temperature Trip Points
The platform or its devices can change the active and
passive cooling temperature trip points and notify OSPM to reevaluate the trip
point interfaces to establish the new policy threshold settings. The following
are the primary uses for this type of thermal notification:
· When OSPM changes the platform's cooling policy from one cooling
mode to another.
· When a swappable bay device is inserted or removed. A swappable
bay is a slot that can accommodate several different devices that have
identical form factors, such as a CD-ROM drive, disk drive, and so on. Many
mobile PCs have this concept already in place.
· After the crossing of an active or passive trip point is signaled
to implement hysteresis.
In each situation, OSPM must be notified to re-evaluate the
thermal zone's trip points via the AML code execution of a Notify(thermal_zone, 0x81) statement or via
an OS specific interface invoked by device drivers for zone devices
participating in the thermal model.
11.1.2.1 OSPM Change of Cooling Policy
When OSPM changes the platform's cooling policy from one
cooling mode to the other, the following occurs:
1. OSPM notifies the platform of the new cooling mode by running the Set
Cooling Policy (_SCP) control method in all thermal zones and invoking the
OS-specific Set Cooling Policy interface to all participating devices in each
thermal zone.
2. Thresholds are updated in the hardware and OSPM is notified of the
change.
3. OSPM re-evaluates the active and passive cooling temperature trip
points for the zone and all devices in the zone to obtain the new temperature
thresholds.
11.1.2.2 Resetting Cooling Temperatures to Adjust to Bay Device
Insertion or Removal
The platform can adjust the thermal zone temperature to
accommodate the maximum operating temperature of a bay device as necessary
example:
1. Hardware detects that a device was inserted into or removed from the
bay, updates the temperature thresholds, and then notifies OSPM of the thermal
policy change and device insertion events.
2. OSPM re-enumerates the devices and re-evaluates the active and passive
cooling temperature trip points.
11.1.2.3 Resetting Cooling Temperatures to Implement Hysteresis
An OEM can build hysteresis into platform thermal design by
dynamically resetting cooling temperature thresholds. For example:
1. When the
temperature increases to the designated threshold, OSPM will turn on the
associated active cooling device or perform passive cooling.
2. The platform resets the threshold value to a lower temperature (to
implement hysteresis) and notifies OSPM of the change. Because of this new
threshold value, the fan will be turned off at a lower temperature than when it
was turned on (therefore implementing a negative hysteresis).
3. When the temperature hits the lower threshold value, OSPM will turn off
the associated active cooling device or cease passive cooling. The hardware
will reset _ACx to its original value
and notify OSPM that the trip points have once again been altered.
11.1.3 Detecting
Temperature Changes
The ability of the platform and its devices to
asynchronously notify an ACPI-compatible OS of meaningful changes in the
thermal zone's temperature is a highly desirable capability that relieves OSPM
from implementing a poll-based policy and generally results in a much more
responsive and optimal thermal policy implementation. Each notification
instructs OSPM to evaluate whether a trip point has been crossed and allows
OSPM to anticipate temperature trends for the thermal zone.
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 zone's 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 zone's
temperature occurs – relieving OSPM 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 11.3.18, "_TZP," for more
information.
11.1.3.1 Temperature Change Notifications
Thermal zone-wide temperature sensor hardware that supports
asynchronous temperature change notifications does so using an SCI. The AML code
that responds to this SCI must execute a Notify(thermal_zone, 0x80) statement to inform OSPM that a meaningful
change in temperature has occurred. Alternatively, devices with embedded
temperature sensors may signal their associated device drivers and the drivers
may use an OS-specific interface to signal OSPM's thermal policy driver. A
device driver may also invoke a device specific control method that executes a Notify(thermal_zone, 0x80) statement. When
OSPM receives this thermal notification, it will evaluate the thermal zone's
temperature interfaces to evaluate the current temperature values. OSPM will
then compare the values to the corresponding cooling policy trip point values
(either zone-wide or device-specific). If the temperature has crossed over any
of the policy thresholds, then OSPM will actively or passively cool (or stop
cooling) the system, or shut the system down entirely.
Both the number and granularity of thermal zone trip points
are OEM-specific. However, it is important to notice that since OSPM can use
heuristic knowledge to help cool the system, the more events OSPM receives the
better understanding it will have of the system's thermal characteristic.
Figure 11-2 Thermal Events
For example, the simple 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 zone's basic
characteristics (temperature trends).
Note: The ACPI
specification defines Kelvin as the standard unit for absolute temperature
values. All thermal zone objects must report temperatures in Kelvin when
reporting absolute temperature values. 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 q/K = T/°C + 273.2.
11.1.3.2 Polling
Temperature sensor hardware that is incapable of generating
thermal change events, or that can do so for only 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 11.3.18, "_TZP,"
for more information.
11.1.4 Active Cooling
Active cooling devices typically consume power and produce
some amount of noise when enabled. These devices attempt to cool a thermal zone
through the removal of heat rather than limiting the performance of a device to
address an adverse thermal condition.
The active cooling interfaces in conjunction with the
active cooling lists allow the platform to use an active device that offers
varying degrees of cooling capability or multiple cooling devices. The active
cooling temperature trip points designate the temperature where Active cooling
is engaged or disengaged (depending upon the direction in which the temperature
is changing). For thermal zone-wide active cooling controls, the _ALx object evaluates to a list of devices that actively
cool the zone. For example:
· If a standard single-speed fan is the Active cooling device, then
_AC0 evaluates to the temperature where active cooling is engaged and the fan is
listed in _AL0.
· If the zone uses two independently controlled single-speed fans
to regulate the temperature, then _AC0 will evaluate to the maximum cooling
temperature using two fans, and _AC1 will evaluate to the standard cooling
temperature using one fan.
· If a zone has a single fan with a low speed and a high speed, the
_AC0 will evaluate to the temperature associated with running the fan at
high-speed, and _AC1 will evaluate to the temperature associated with running
the fan at low speed. _AL0 and _AL1 will both point to different device objects
associated with the same physical fan, but control the fan at different speeds.
For ASL coding examples that illustrate these points, see
sections 11.5, "Thermal Zone Interface Requirements," and 11.6, "Thermal Zone
Examples."
11.1.5 Passive Cooling
Passive cooling controls are able to cool a thermal zone
without creating noise and without consuming additional power (actually saving
power), but do so by decreasing the performance of the devices in the zone .
11.1.5.1 Processor Clock Throttling
The processor passive cooling threshold (_PSV) in
conjunction with the processor list (_PSL) allows the platform to indicate the
temperature at which a passive control, for example clock throttling, will be
applied to the processor(s) residing in a given thermal zone. Unlike other
cooling policies, during passive cooling of processors OSPM may take the
initiative to actively monitor the temperature in order to cool the platform.
On an ACPI-compatible platform that properly implements CPU
throttling, the temperature transitions will be similar to the following figure,
in a coolable environment, running a coolable workload:
Figure 11-3 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 zone's temperature:
Equation
#1: DP [%] = _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 11.3, "Thermal Objects"). The _TSP object contains a
time interval that OSPM uses to poll the hardware to sample the temperature.
Whenever the time value returned by _TSP has elapsed, OSPM will evaluate _TMP
to sample the current temperature (shown as Tn in the above equation). Then
OSPM will use the sampled temperature and the passive cooling temperature trip
point (_PSV) (which is the target temperature Tt) to evaluate the equation for DP. The granularity of
style='font-family:Symbol'>DP is determined by the CPU duty width of the
system.
Note: Equation #1
has an implied formula.
Equation #2: Pn = Pn-1 + HW[- DP ] where 0% <=
Pn <= 100%
For Equation #2, whenever Pn-1 + DP 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:
For absolute temperatures:
1. If the right hand side of Equation #1 is negative, HW[ DP] is rounded to the next available higher
setting of frequency.
2. If the right hand side of Equation #1 is positive, HW[DP] is rounded to the next available lower
setting of frequency.
For relative
temperatures:
1. If the right hand side of Equation #1 is positive, HW[ DP] is rounded to the next available higher
setting of frequency.
2. If the right hand side of Equation #1 is negative, HW[DP] 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.
11.1.6 Critical Shutdown
When the thermal zone-wide
temperature sensor value reaches the threshold indicated by _CRT, OSPM must
immediately shut the system down. The system must disable the power either
after the temperature reaches some hardware-determined level above _CRT or
after a predetermined time has passed. Before disabling power, platform
designers should incorporate some time that allows OSPM to run its critical
shutdown operation. There is no requirement for a minimum shutdown operation
window that commences immediately after the temperature reaches _CRT. This is
because:
· Temperature might rise rapidly in some systems and slowly on
others, depending on casing design and environmental factors.
· Shutdown can take several minutes on a server and only a few
seconds on a hand-held device.
Because of this indistinct
discrepancy and the fact that a critical heat situation is a remarkably rare
occurrence, ACPI does not specify a target window for a safe shutdown. It is
entirely up to the OEM to build in a safe buffer that it sees fit for the
target platform.
11.2 Cooling Preferences
A robust OSPM implementation
provides the means for the end user to convey a preference (or a level of
preference) for either performance or energy conservation to OSPM. Allowing the
end user to choose this preference is most critical to mobile system users
where maximizing system run-time on a battery charge often has higher priority
over realizing maximum system performance. For example, if a user is taking
notes on her PC in a quiet environment, such as a library or a corporate
meeting, she may want the system to emphasize passive cooling so that the
system operates quietly, even at the cost of system performance.
A user preference towards
performance corresponds to the Active cooling mode while a user's preference
towards energy conservation or quiet corresponds to the Passive cooling mode.
ACPI defines an interface to convey the cooling mode to the platform. Active
cooling can be performed with minimal OSPM thermal policy intervention
example, the platform indicates through thermal zone parameters that crossing a
thermal trip point requires a fan to be turned on. Passive cooling requires
OSPM thermal policy to manipulate device interfaces that reduce performance to
reduce thermal zone temperature.
Either cooling mode will be
activated only when the thermal condition requires it. When the thermal zone is
at an optimal temperature level where it does not warrant any cooling, both
modes result in a system operating at its maximum potential with all fans
turned off.
Thermal zones supporting the Set
Cooling Policy interface allow the user to switch the system's cooling mode
emphasis. See section 11.3.7, "_SCP," for more information.
Figure 11-4 Active
and Passive Threshold Values
As illustrated in Figure 11-4, the platform must convey the
value for each threshold to instruct OSPM to initiate the cooling policies at
the desired target temperatures. The platform 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 11-5 below.
Figure 11-5 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.
11.2.1 Evaluating Thermal Device Lists
The Notify(thermal_zone,
0x82) statement is used to inform OSPM that a change has been made to the
thermal zone device lists. This thermal event instructs OSPM to re-evaluate the _ALx, _PSL, and _TZD
objects.
For example, a system that supports the dynamic insertions
of processors might issue this notification to inform OSPM of changes to _PSL
following the insertion or removal of a processor. OSPM would re-evaluate all
thermal device lists and adjust its policy accordingly.
Notice that this notification can be used with the Notify(thermal_zone, 0x81) statement to
inform OSPM to both re-evaluate all device lists and all thresholds.
Alternatively, devices may include the _TZM (Thermal Zone
Member) object their device scope to convey their thermal zone association to
OSPM. Section 11.3.17, "_TZM (Thermal Zone Member)", for more information.
11.2.2 Evaluating
Device Thermal Relationship Information
The Notify(thermal_zone,
0x83) statement is used to inform OSPM that a change has been made to the
thermal influence information. This thermal event instructs OSPM to re-evaluate
the _TRT object. The thermal influence between devices may change when active
cooling moves air across device packages as compared to when only passive
cooling controls are applied.
11.3 Thermal Objects
Objects related to thermal management are listed in Table 11-1.
Table 11-1 Thermal
Objects
Object
|
Description
|
|
_ACx
|
Returns active cooling policy threshold values in tenths of
degrees.
|
|
|
_ALx
|
List of active cooling device objects.
|
|
|
_CRT
|
Returns critical trip point in tenths of degrees where OSPM
must perform a critical shutdown.
|
|
|
_HOT
|
Returns critical trip point in tenths of degrees where OSPM
may choose to transition the system into S4.
|
|
|
_PSL
|
List of processor device objects for clock throttling.
|
|
|
_PSV
|
Returns the passive cooling policy threshold value in tenths
of degrees.
|
|
|
_RTV
|
Conveys whether temperatures are expressed in terms of
absolute or relative values.
|
|
|
_SCP
|
Sets platform cooling policy (active or passive).
|
|
|
_TC1
|
Thermal constant for passive cooling.
|
|
|
_TC2
|
Thermal constant for passive cooling.
|
|
|
_TMP
|
Returns the thermal zone's current temperature in tenths of
degrees.
|
|
|
_TPT
|
Conveys the temperature of a devices internal temperature
sensor to the platform when a temperature trip point is crossed.
|
|
|
_TRT
|
Table of values that convey the Thermal Relationship between
devices
|
|
|
_TSP
|
Thermal sampling period for Passive cooling in tenths of
seconds.
|
|
|
_TST
|
Conveys the minimum separation for a devices' programmable temperature
trip points.
|
|
|
_TZD
|
List of devices whose temperature is measured by this thermal
zone.
|
|
|
_TZM
|
Returns the thermal zone for which a device is a member.
|
|
|
_TZP
|
Thermal zone polling frequency in tenths of seconds.
|
|
| |
With
the exception of _TPT, _TST, and the _TZM objects, the objects described in the
following sections may exist under a thermal zone. Devices with embedded
thermal sensors and controls may contain static cooling temperature trip points
or dynamic cooling temperature trip points that must be programmed by the
device's driver. In this case, thermal objects defined under a device serve to
convey the platform specific values for these settings to the devices driver.
11.3.1 _ACx (Active Cooling)
This optional object, if present under a thermal zone, returns
the temperature trip point at which OSPM must start or stop Active cooling,
where x is a value between 0 and 9 that
designates multiple active cooling levels of the thermal zone. If the Active
cooling device has one cooling level (that is, "on") then that cooling level must
be defined as _AC0. If the cooling device has two levels of capability, such as
a high fan speed and a low fan speed, then they must be defined as _AC0 and
_AC1 respectively. The smaller the value of x, the greater the cooling strength _ACx
style='font-style:normal'> represents. In the above example, _AC0 represents
the greater level of cooling (the faster fan speed) and _AC1 represents the
lesser level of cooling (the slower fan speed). For every _ACx method, there must be a matching _ALx
style='font-style:normal'> object.
If this object it present under a device, the device's
driver evaluates this object to determine the device's corresponding active
cooling temperature trip point. This value may then be used by the device's
driver to program an internal device temperature sensor trip point. When this
object is present under a device, either the device must contain a native OS
device driver interface supporting a corresponding active cooling control or
there must be a matching _ALx object under the thermal zone of which the device
is a member.
Arguments:
None
Result Code:
Active cooling temperature threshold in tenths of
degrees.
The result code is an integer value that represents tenths
of degrees. For example, 300.0K is represented by the integer 3000.
11.3.2 _ALx
style='font-style:normal'> (Active List)
This object is defined under a thermal zone and evaluates
to a list of Active cooling devices to be turned on when the corresponding _ACx temperature threshold is exceeded. For example,
these devices could be fans.
Arguments:
None
Result Code:
A package consisting of
references to all active cooling devices that should be engaged when the
associated active cooling threshold (_ACx) is exceeded.
11.3.3 _CRT (Critical
Temperature)
This object, when defined under a thermal zone, returns
the critical temperature at which OSPM must shutdown the system. If this object
it present under a device, the device's driver evaluates this object to
determine the device's critical cooling temperature trip point. This value may
then be used by the device's driver to program an internal device temperature
sensor trip point.
Arguments:
None
Result Code:
Critical temperature
threshold in tenths of degrees.
The result is an integer value that represents tenths of
degrees. For example, 300.0K is represented by the integer 3000.
11.3.4 _HOT (Hot Temperature)
This object, when defined under a thermal zone, returns the
critical temperature at which OSPM may choose to transition the system into the
S4 sleeping state. The platform vendor should define _HOT to be far enough
below _CRT so as to allow OSPM enough time to transition the system into the S4
sleeping state. While dependent on the amount of installed memory, on typical
platforms OSPM implementations can transition the system into the S4 sleeping
state in tens of seconds. If this object it present under a device, the
device's driver evaluates this object to determine the device's hot cooling
temperature trip point. This value may then be used by the device's driver to
program an internal device temperature sensor trip point.
Arguments:
None
Result Code:
Critical temperature
threshold in tenths of degrees.
The result is an integer value that represents tenths of
degrees. For example, 300.0K is represented by the integer 3000.
11.3.5 _PSL (Passive List)
This object is defined under a thermal zone and evaluates
to a list of processor objects to be used for passive cooling.
Arguments:
None
Result Code:
A package consisting of
references to all processor objects that will be used for passive cooling when
the zone's passive cooling threshold (_PSV) is exceeded.
11.3.6 _PSV (Passive)
This optional object, if present under a thermal zone, evaluates
to the temperature at which OSPM must activate passive cooling policy.
If this object it present under a device, the device's
driver evaluates this object to determine the device's corresponding passive
cooling temperature trip point. This value may then be used by the device's
driver to program an internal device temperature sensor trip point. When this
object is present under a device, the device must contain a native OS device
driver interface supporting a passive cooling control.
Arguments:
None
Result Code:
Passive cooling temperature
threshold in tenths of degrees.
The result code is an integer value that represents tenths
of degrees. For example, 300.0 Kelvin is represented by 3000.
11.3.7 _RTV (Relative Temperature Values)
This optional object may be present under a device or a
thermal zone and is evaluated by OSPM to determine whether the values returned
by temperature trip point and current operating temperature interfaces under
the corresponding device or thermal zone represent absolute or relative
temperature values.
If the _RTV object is not present or is present and
evaluates to zero then OSPM assumes that all values returned by temperature
trip point and current operating temperature interfaces under the device or
thermal zone represent absolute temperature values expressed in tenths of
degrees Kelvin.
If the _RTV object is present and evaluates to a non zero
value then all values returned by temperature trip point and current operating
temperature interfaces under the corresponding device or thermal zone represent
temperature values relative to a zero point that is defined as the maximum
value of the device's or thermal zone's critical cooling temperature trip
point. In this case, temperature trip point and current operating temperature
interfaces return values in units that are tenths of degrees below the zero point.
OSPM evaluates the _RTV object before evaluating any other
temperature trip point or current operating temperature interfaces.
Arguments:
None
Result Code:
Integer indicating whether
values returned by temperature trip point and current operating temperature
interfaces represent absolute of relative temperature values.
11.3.8 _SCP (Set Cooling
Policy)
This optional object is a control method that OSPM invokes
to set the platform's cooling mode policy setting. The platform may use the
evaluation of _SCP to reassign _ACx and
_PSV temperature trip points according to the mode or limits conveyed by OSPM.
OSPM will automatically evaluate _ACx and _PSV objects after executing _SCP. This object may exist under a
thermal zone or a device.
Arguments:
Arg0 (Integer): Mode
Arg1 (Integer): Acoustic
Limit
Arg2 (Integer): Power
Limit
Where:
Mode – 0 =
Active, 1 = Passive
Acoustic Limit
– Specifies the maximum acceptable acoustic level that active cooling
devices may generate. Values are 1 to 5 where 1 means no acoustic tolerance and
5 means maximum acoustic tolerance.
Power Limit – Specifies the maximum acceptable power level that active cooling devices may
consume. Values are from 1 to 5 where 1 means no power may be used to cool and
5 means maximum power may be used to cool.
Result Code:
None
Example:
// Fan Control is defined as follows:
// Speed 1 (Fan is Off): Acoustic Limit 1, Power Limit 1, <=
64C
// Speed 2: Acoustic Limit 2,
Power Limit 2, 65C - 74C
// Speed 3: Acoustic Limit 3,
Power Limit 3, 75C - 84C
// Speed 4: Acoustic Limit 4,
Power Limit 4, 85C - 94C
// Speed 5: Acoustic Limit 5,
Power Limit 5, >= 95C
// _SCP Notifies the platform the current cooling mode.
// Arg0 = Mode
// 0 - Active cooling
// 1 - Passive cooling
// Arg1 = Acoustic Limit
// 1 = No acoustic tolerance
// ...
// 5 = maximum acoustic tolerance
// Arg2 = Power Limit
// 1 = No power may be used to cool
// ...
// 5 = maximum power may be used to cool
Method(_SCP,3,Serialized)
{
// Store the Cooling Mode in NVS and use as
needed in
// the rest of the ASL Code.
Store(Arg0, CTYP)
// Set PSVT to account for a Legacy OS that
does not pass
// in either the acoustic limit or Power
Limit.
If(Arg0)
{
Store(60,PSVT)
}
Else
{
Store(97,PSVT)
}
If (CondRefOf (_OSI,Local0))
{
If (\_OSI ("3.0 _SCP Extensions"))
{
// Determine Power Limit.
//
// NOTE1: PSVT = Passive
Cooling Trip Point stored
// in NVS in Celsius.
//
// NOTE2: 4 Active Cooling
Trips Points correspond to 5
// unique Power Limit
regions and 5 unique acoustic limit
// regions.
//
// NOTE3: This code will
define Passive cooling so that
// CPU throttling will be
initiated within the Power Limit
// Region passed in such
that the next higher Power Limit
// Region will not be
reached.
Switch(Arg2)
{
Case(1) //
Power Limit = 1.
{
//
Stay in Acoustic Limit 1.
Store(60,PSVT) //
Passive = 60C.
}
Case(2) //
Power Limit = 2.
{
//
Store Highest supported Acoustic Level
//
at this Power Limit (1 or 2).
Store(70,PSVT)
If(Lequal(Arg1,1))
{
//
Stay in Acoustic Level 1.
Store(60,PSVT)
}
}
Case(3) //
Power Limit = 3.
{
//
Store Highest supported Acoustic Level
//
at this Power Limit (1, 2, or 3).
Store(80,PSVT)
If(Lequal(Arg1,2))
{
//
Stay in Acoustic Level 1 or 2.
Store(70,PSVT)
}
If(Lequal(Arg1,1))
{
//
Stay in Acoustic Level 1.
Store(60,PSVT)
}
}
Case(4) //
Power Limit = 4.
{
//
Store Highest supported Acoustic Level
//
at this Power Limit (1, 2, 3, or 4).
Store(90,PSVT)
If(Lequal(Arg1,3))
{
//
Stay in Acoustic Level 1 or 2.
Store(80,PSVT)
}
If(Lequal(Arg1,2))
{
//
Stay in Acoustic Level 1 or 2.
Store(70,PSVT)
}
If(Lequal(Arg1,1))
{
//
Stay in Acoustic Level 1.
Store(60,PSVT)
}
}
Case(5) //
Power Limit = 5.
{
//
Store Highest supported Acoustic Level
//
at this Power Limit (1, 2, 3, 4, or 5).
Store(97,PSVT)
If(Lequal(Arg1,4))
{
//
Stay in Acoustic Level 1 or 2.
Store(90,PSVT)
}
If(Lequal(Arg1,3))
{
//
Stay in Acoustic Level 1 or 2.
Store(80,PSVT)
}
If(Lequal(Arg1,2))
{
//
Stay in Acoustic Level 1 or 2.
Store(70,PSVT)
}
If(Lequal(Arg1,1))
{
//
Stay in Acoustic Level 1.
Store(60,PSVT)
}
}
// Case 5
} // Switch Arg 2
} // _OSI - Extended _SCP
} // CondRefOf _OSI
} // Method _SCP
11.3.9 _TC1 (Thermal Constant 1)
This object evaluates to the constant _TC1 for use in the
Passive cooling formula:
DPerformance [%]= _TC1 * ( Tn - Tn-1 ) + _TC2 * (Tn. - Tt)
Arguments:
None
Result Code:
Integer value of
thermal constant #1.
11.3.10 _TC2 (Thermal Constant 2)
This object evaluates to the constant _TC2 for use in the
Passive cooling formula:
DPerformance [%]= _TC1 * ( Tn - Tn-1 ) + _TC2 *(Tn - Tt)
Arguments:
None
Result Code:
Integer value of
thermal constant #2.
11.3.11 _TMP (Temperature)
This control method returns the thermal zone's current
operating temperature.
Arguments:
None
Result Code:
The current temperature of the thermal zone in tenths of
degrees. For example, 300.0K is represented by the integer 3000.
11.3.12 _TPT (Trip Point
Temperature)
This optional object may be present under a device and is
invoked by OSPM to indicate to the platform that the devices' embedded
temperature sensor has crossed a cooling temperature trip point. After
invocation, OSPM immediately evaluates the devices' Active and Passive cooling
temperature trip point values. This enables the platform to implement
hysteresis.
Arguments:
Current value of device's
embedded temperature sensor in tenths of degrees.
Result Code:
None
11.3.13 _TRT
(Thermal Relationship Table)
This object evaluates to a package of packages each of
which describes the thermal relationship between devices within a thermal zone.
OSPM uses the combined information about the thermal relationships of all
devices in the thermal zone to make thermal policy decisions.
Name (_TRT, Package()
{ // Field Name Field
Type
Package () // First Thermal
Relationship Package Data
{
SourceDevice, //
ObjectReference to a Device Object
TargetDevice, //
ObjectReference to a Device Object
ThermalInfluence, //
Integer
ThermalSamplingPeriod, //
Integer
Reserved1, //
Integer
Reserved2, //
Integer
Reserved3, //
Integer
Reserved4 //
Integer
},
.
.
.
Package () // Last Thermal
Relationship Package Data
{
SourceDevice, //
ObjectReference to a Device Object
TargetDevice, //
ObjectReference to a Device Object
ThermalInfluence, //
Integer
ThermalSamplingPeriod, //
Integer
Reserved1, //
Integer
Reserved2, //
Integer
Reserved3, //
Integer
Reserved4 //
Integer
}
}) // End of _TRT object
Each Thermal Relationship Table entry contains eight data
fields as follows:
· SourceDevice.
The device that is influencing the device indicated by TargetDevice.
· TargetDevice.
The device that is influenced by the device indicated by SourceDevice
· ThermalInfluence.
Indicates the thermal influence of SourceDevice on TargetDevice represented as tenths of degrees Kelvin that the device indicated by SourceDevice raises the temperature of the device indicated by TargetDevice
style='font-style:normal'> per Watt of thermal load that SourceDevice generates.
· ThermalSamplingPeriod. The minimum period of time in tenths of seconds that
OSPM should wait after applying a passive control to the device indicated by SourceDevice to detect its impact on the device indicated by TargetDevice
style='font-style:normal'>.
· Reserved1. Reserved for future use.
· Reserved2. Reserved for future use.
· Reserved3.
Reserved for future
use.
· Reserved4. Reserved for future use.
11.3.14 _TSP (Thermal Sampling Period)
This object evaluates to a thermal sampling period (in
tenths of seconds) used by OSPM to implement the Passive cooling equation. This
value, along with _TC1 and _TC2, will enable OSPM to provide the proper
hysteresis required by the system to accomplish an effective passive cooling
policy. The granularity of the sampling period is 0.1 seconds. For example, if
the sampling period is 30.0 seconds, then _TSP needs to report 300; if the
sampling period is 0.5 seconds, then it will report 5. OSPM can normalize the
sampling over a longer period if necessary.
Arguments:
None
Result Code:
Thermal sampling
period for passive cooling, in tenths of seconds.
11.3.15 _TST (Temperature Sensor
Threshold)
This optional object may be present under a device and is
evaluated by OSPM to determine the minimum separation for a devices'programmable temperature trip points. When a device contains multiple
programmable temperature trip points, it may not be necessary for OSPM to poll
the device's temperature after crossing a temperature trip point when
performing passive cooling control policy. To eliminate polling, the device can
program intermediate trip points of interest (higher or lower than the current
temperature) and signal the crossing of the intermediate trip points to OSPM.
The distance between the current temperature and these intermediate trip points
may be platform specific and must be set far enough away from the current
temperature so as to not to miss the crossing of a meaningful temperature point.
The _TST object conveys the recommended minimum separation between the current
temperature and an intermediate temperature trip point to OSPM.
Arguments:
None
Result Code:
Temperature sensor threshold
in tenths of degrees.
11.3.16 _TZD
(Thermal Zone Devices)
This optional object evaluates to a package of device
names. Each name corresponds to a device in the ACPI namespace that is
associated with the thermal zone. The temperature reported by the thermal zone
is roughly correspondent to that of each of the devices.
The list of devices returned by the control method need not
be a complete and absolute list of devices affected by the thermal zone.
However, the package should at least contain the devices that would uniquely
identify where this thermal zone is located in the machine. For example, a
thermal zone in a docking station should include a device in the docking
station, a thermal zone for the CD-ROM bay, should include the CD-ROM.
Arguments:
None
Result Code:
A package
consisting of references to devices associated with the thermal zone.
11.3.17 _TZM
(Thermal Zone Member)
This optional object may exist under any device definition
and evaluates to a reference to the thermal zone of which the device is a
member.
Arguments:
None
Result Code:
A reference to the
thermal zone of which the device is a member.
11.3.18 _TZP
(Thermal Zone Polling)
This optional object evaluates to a recommended polling frequency (in tenths of seconds) for this
thermal zone. A value of zero indicates that OSPM does not need to poll the
temperature of this thermal zone in order to detect temperature changes (the
hardware is capable of generating asynchronous notifications). Notice that the
absence of _TZP informs OSPM to implement polling using an OS-provided default
frequency.
The use of polling is allowed but strongly discouraged by
this specification. OEMs should design systems that asynchronously notify OSPM
whenever a meaningful change in the zone's temperature occurs—relieving
the OS of the overhead associated with polling. See section 11.1.3, "Detecting
Temperature Changes," for more information.
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.
11.4 Native OS Device Driver Thermal Interfaces
OS implementations compatible with the ACPI 3.0 thermal
model, interface with the thermal objects of a thermal zone but also comprehend
the thermal zone devices' OS native device driver interfaces that perform
similar functions to the thermal objects at the device level.
The recommended native OS device driver thermal interfaces
that enable OSPM to perform optimal performance / thermal management include:
· Reading a value from a device's embedded thermal sensor
· Reading a value that indicates whether temperature and trip point
values are reported in absolute or relative temperatures
· Setting the platform's cooling mode policy setting
· Reading the embedded thermal sensor's threshold
· Reading the device's active and passive cooling temperature trip
points
· Reading the device's association to a thermal zone
· Signaling the crossing of a thermal trip point
· Reading the desired polling frequency at which to check the
devices temperature if the device cannot signal OSPM or signal OSPM optimally
(both before and after a temperature trip point is crossed)
· Setting / limiting a device's performance / throttling states
· Engaging / disengaging a device's active cooling controls
These interfaces are OS specific and as such the OS vendor
defines the exact interface definition for each target operating system.
11.5 Thermal Zone Interface Requirements
While not all thermal zone interfaces are required to be
present in each thermal zone, OSPM levies conditional requirements for the
presence of specific thermal zone interfaces based on the existence of other
related thermal zone interfaces. These interfaces may be implemented by thermal
zone-wide objects or by OS-specific device driver exposed thermal interfaces.
The requirements are outlined below:
· A thermal zone must contain at least one temperature interface;either the _TMP object or a member device temperature interface.
· A thermal zone must contain at least one trip point (critical,
near critical, active, or passive)..
· If _ACx is defined then an associated _ALx must be defined (e.g.
defining _AC0 requires _AL0 also be defined).
· If _PSV is defined then either the _PSL or _TZD objects must exist.
The _PSL and _TZD objects may both exist.
· If _PSL is defined then:
· If
a linear performance control register is defined (via either P_BLK or the _PTC,
_TSS, _TPC objects) for a processor defined in _PSL or for a processor device in
the zone as indicated by _TZM then the _TC1, _TC2, and objects must exist
_TSP object must also be defined if the device requires polling.
· If
a linear performance control register is not defined (via either P_BLK or the
_PTC, _TSS, _TPC objects) for a processor defined in _PSL or for a processor
device in the zone as indicated by _TZM then the processor must support
processor performance states (in other words, the processor's processor object
must include _PCT, _PSS, and _PPC).
· If _PSV is defined and _PSL is not defined then at least one
device in thermal zone, as indicated by either the _TZD device list or devices'_TZM objects, must support device performance states.
· _SCP is optional.
· _TZD is optional outside of the _PSV requirement outlined above.
· If _HOT is defined then the system must support the S4 sleeping
state.
11.6 Thermal
Zone Examples
11.6.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 allows OSPM to dynamically adjust its thermal
policy as devices are added or removed from the system.
Scope(\_SB) {
Processor(
CPU0,
1, //
unique number for this processor
0x110, //
system IO address of Pblk Registers
0x06 //
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)
FAN, 1, //
fan power (on/off)
, 6, //
reserved
TMP, 16, //
current temp
AC0, 16, //
active cooling temp (fan high)
, 16, //
reserved
PSV, 16, //
passive cooling temp
HOT 16, //
critical S4 temp
CRT, 16 //
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(_HOT)
{ Return (\_SB.PCI0.ISA0.EC0.HOT) } // 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-
} // end of \_SB scope
11.6.2 Example: Multiple-Speed Fans
The following ASL describes a thermal zone consisting of a
processor and one dual-speed fan. As with the previous example, this thermal
zone object (TZ0) is defined in the \_SB scope and represents the entire
system. This is an example only.
Scope(\_SB) {
Processor(
CPU0,
1, //
unique number for this processor
0x110, //
system IO address of Pblk Registers
0x06 //
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, 16, //
current temp
AC0, 16, //
active cooling temp (high)
AC1, 16, //
active cooling temp (low)
PSV, 16, //
passive cooling temp
HOT 18, //
critical S4 temp
CRT, 16 //
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
}
// 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(_UID,
0)
Name(_PR0,
Package(){FN10, FN11})
}
// Create FAN device
object FN2
Device (FN2) {
//
Device ID for the FAN
Name(_HID,
EISAID("PNP0C0B"))
Name(_UID,
1)
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(_HOT)
{ Return (\_SB.PCI0.ISA0.EC0.HOT) } // 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
} // end of \_SB scope
11.6.3 Example:Thermal Zone with Multiple Devices
Scope(\_SB) {
Device(CPU0) {
Name(_HID,
"ACPI0007")
Name(_UID, 0)
//
// Load additional objects
if 3.0 Thermal model support is available
//
Method(_INI, 0) {
If
(\_OSI("3.0 Thermal Model")) {
LoadTable("OEM1",
"PmRef", "Cpu0", "\\_SB.CPU0") // 3.0 Thermal
Model
}
}
// For brevity, most
processor objects have been excluded
// from this example (such
as _PSS, _CST, _PCT, _PPC, etc.)
// Processor Throttle
Control object
Name(_PTC,
ResourceTemplate() {
Register(SystemIO,
32, 0, 0x120) // Processor Control
Register(SystemIO,
32, 0, 0x120) // Processor Status
})
// Throttling Supported
States
// The values shown are for
exemplary purposes only
Name(_TSS, Package() {
//
Read: freq percentage, power, latency, control, status
Package()
{0x64, 1000, 0x0, 0x7, 0x0}, // Throttle off (100%)
Package()
{0x58, 800, 0x0, 0xF, 0x0}, // 87.5%
Package()
{0x4B, 600, 0x0, 0xE, 0x0}, // 75%
Package()
{0x3F, 400, 0x0, 0xD, 0x0} // 62.5%
})
// Throttling Present
Capabilities
// The values shown are for
exemplary purposes only
Method(_TPC) {
If(\_SB.AC)
{
Return(0) //
All throttle states available
}
Else {
Return(2) //
Throttle states >= 2 are available
}
}
} // end of CPU0 scope
Device(CPU1) {
Name(_HID,
"ACPI0007")
Name(_UID, 1)
//
// Load additional objects
if 3.0 Thermal model support is available
//
Method(_INI, 0) {
If
(\_OSI("3.0 Thermal Model")) {
LoadTable("OEM1",
"PmRef", "Cpu1", "\\_SB.CPU1") // 3.0 Thermal
Model
}
}
// For brevity, most
processor objects have been excluded
// from this example (such
as _PSS, _CST, _PCT, _PPC, _PTC, etc.)
// Processor Throttle
Control object
Name(_PTC,
ResourceTemplate() {
Register(SystemIO,
32, 0, 0x120) // Processor Control
Register(SystemIO,
32, 0, 0x120) // Processor Status
})
// Throttling Supported
States
// The values shown are for
exemplary purposes only
Name(_TSS, Package() {
//
Read: freq percentage, power, latency, control, status
Package()
{0x64, 1000, 0x0, 0x7, 0x0}, // Throttle off (100%)
Package()
{0x58, 800, 0x0, 0xF, 0x0}, // 87.5%
Package()
{0x4B, 600, 0x0, 0xE, 0x0}, // 75%
Package()
{0x3F, 400, 0x0, 0xD, 0x0} // 62.5%
})
// Throttling Present
Capabilities
// The values shown are for
exemplary purposes only
Method(_TPC) {
If(\_SB.AC)
{
Return(0) //
All throttle states available
}
Else {
Return(2) //
Throttle states >= 2 are available
}
}
} // end of CPU1 scope
Scope(\_SB.PCI0.ISA0) {
Device(EC0) {
Name(_HID,
EISAID("PNP0C09")) // ID for this
EC
//
// Load additional objects
if 3.0 Thermal model support is available
//
Method(_INI, 0) {
If
(\_OSI("3.0 Thermal Model")) {
LoadTable("OEM1",
"PmRef", "Tz3", "\\_SB.PCI0.ISA0.EC0") // 3.0 Tz
}
}
// 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
, 6, //
reserved
TMP, 16, //
current temp
AC0, 16, //
active cooling temp
PSV, 16, //
passive cooling temp
HOT, 16, //
critical S4 temp
CRT, 16 //
critical temp
}
// Following is a method
that OSPM will schedule after it
// 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
}
// Following is a
single fan with one speed.
// Create FAN device
object FN1
Device (FN1) {
//
Device ID for the FAN
Name(_HID,
EISAID("PNP0C0B"))
Name(_UID,
0)
Name(_PR0,
Package(){FN10})
}
// Receives an SCI and
queries the EC to receive value 7
Method(_Q07) {
Notify
(\_SB.PCI0.ISA0.EC0.TZ0, 0x80)
} // end of Notify method
// Create standard
specific thermal zone
ThermalZone (TZ0) {
Method(_TMP)
{ Return (\_SB.PCI0.ISA0.EC0.TMP )} // get current temp
Name(_PSL,
Package() {\_SB.CPU0, \_SB.CPU1}) // passive
cooling devices
Name(_AL0,
Package() {\_SB.PCI0.ISA0.EC0.FN1}) // active cooling
Method(_AC0)
{ Return (\_SB.PCI0.ISA0.EC0.AC0) } // fan temp (high)
Method(_AC1)
{ Return (\_SB.PCI0.ISA0.EC0.AC1) } // fan temp (low)
Method(_PSV)
{ Return (\_SB.PCI0.ISA0.EC0.PSV) } // passive cooling temp
Method(_HOT)
{ Return (\_SB.PCI0.ISA0.EC0.HOT) } // get critical S4 temp
Method(_CRT)
{ Return (\_SB.PCI0.ISA0.EC0.CRT) } // get crit. temp
Name(_TC1,
4) //
bogus example constant
Name(_TC2,
3) //
bogus example constant
Method(_SCP,
1) { Store (Arg0, \_SB.PCI0.ISA0.EC0.MODE) } // set cooling mode
Name(_TSP,
150) //
passive sampling = 15 sec
} // end of TZ0
} // end of ECO
} // end of \_SB.PCI0.ISA0 scope
} // end of \_SB scope
//
// ACPI 3.0 Thermal Model SSDT
//
DefinitionBlock (
"TZASSDT.aml",
"OEM1",
0x01,
"PmRef",
"Tz3",
0x3000
)
{
External(\_SB.PCI0.ISA0.EC0,
DeviceObj)
External(\_SB.CPU0,
DeviceObj)
External(\_SB.CPU1,
DeviceObj)
Scope(\_SB.PCI0.ISA0.EC0)
{
// Create an ACPI
3.0 specific thermal zone
ThermalZone (TZ0) {
//
This TRT is for exemplary purposes only
Name(_TRT,
Package() {
//
Thermal relationship package data. A package is generated for
//
each permutation of device sets. 2 devices = 4 entries.
//
Read: source, target, thermal influence, sampling period, 4 reserved
Package
() {\_SB.CPU0, \_SB.CPU0, 20, 1, 0, 0, 0, 0},
Package
() {\_SB.CPU0, \_SB.CPU1, 10, 15, 0, 0, 0, 0},
Package
() {\_SB.CPU1, \_SB.CPU0, 10, 15, 0, 0, 0, 0},
Package
() {\_SB.CPU1, \_SB.CPU1, 20, 1, 0, 0, 0, 0}
})
// end of TRT
} // end of TZ0
} // end of EC0 Scope
} // end of SSDT
//
// CPU0 3.0 Thermal Model SSDT
//
DefinitionBlock (
"CPU0SSDT.aml",
"OEM1",
0x01,
"PmRef",
"CPU0",
0x3000
)
{
External(\_SB.CPU0,
DeviceObj)
External(\_SB.PCI0.ISA0.TZ0,
ThermalZoneObj)
Scope(\_SB.CPU0)
{
//
// Add the objects required
for 3.0 extended thermal support
//
// Create a region and
fields for thermal support; the platform
// fills in the values and
traps on writes to enable hysteresis.
// The Operation Region
location is invalid
OperationRegion(CP00,
SystemMemory, 0x00000000, 0xA)
Field(CP00, ByteAcc, Lock,
Preserve) {
SCP, 1, //
thermal policy (passive/active)
RTV, 1, //
absolute or relative temperature
, 6, //
reserved
AC0, 16, //
active cooling temp
PSV, 16, //
passive cooling temp
CRT, 16, //
critical temp
TPT, 16, //
Temp trip point crossed
TST, 8 //
Temp sensor threshold
}
Method(_TZM, 0) {
Return(\_SB.PCI0.ISA0.TZ0) } // thermal zone member
// Some thermal zone methods
are now located under the
// thermal device
participating in the 3.0 thermal model.
// These methods provide
device specific thermal information
Method(_SCP, 1) {
Store (Arg0, \_SB.CPU0.SCP) } // set cooling mode
Method(_RTV) {
Return (\_SB.CPU0.RTV) } // absolute
or relative temp
Method(_AC0) {
Return (\_SB.CPU0.AC0) } // active
cooling (fan) temp
Method(_PSV) {
Return (\_SB.CPU0.PSV) } // passive
cooling temp
Method(_CRT) {
Return (\_SB.CPU0.CRT) } // critical
temp
Name(_TC1, 4) //
thermal constant 1 (INVALID)
Name(_TC2, 3) //
thermal constant 2 (INVALID)
Method(_TPT, 1) {
Store (Arg0, \_SB.CPU0.TPT)} // trip point temp
Method(_TST) {
Return (\_SB.CPU0.TST) } // temp
sensor threshold
} // end of CPU0 scope
} // end of SSDT
//
// CPU1 3.0 Thermal Model SSDT
//
DefinitionBlock (
"CPU1SSDT.aml",
"OEM1",
0x01,
"PmRef",
"CPU1",
0x3000
)
{
External(\_SB.CPU1,
DeviceObj)
External(\_SB.PCI0.ISA0.TZ0,
ThermalZoneObj)
Scope(\_SB.CPU1)
{
//
// Add the objects required
for 3.0 extended thermal support
//
// Create a region and
fields for thermal support; the platform
// fills in the values and
traps on writes to enable hysteresis.
// The Operation Region
location is invalid
OperationRegion(CP01,
SystemIO, 0x00000008, 0xA)
Field(CP01, ByteAcc, Lock,
Preserve) {
SCP, 1, //
thermal policy (passive/active)
RTV, 1, //
absolute or relative temperature
, 6, //
reserved
AC0, 16, //
active cooling temp
PSV, 16, //
passive cooling temp
CRT, 16, //
critical temp
TPT, 16, //
Temp trip point crossed
TST, 8 //
Temp sensor threshold
}
Method(_TZM, 0) {
Return(\_SB.PCI0.ISA0.TZ0) } // thermal zone member
// Some thermal zone methods
are now located under the
// thermal device
participating in the 3.0 thermal model.
// These methods provide
device specific thermal information
Method(_SCP, 1) {
Store (Arg0, \_SB.CPU1.SCP) } // set cooling mode
Method(_RTV) {
Return (\_SB.CPU1.RTV) } // absolute
or relative temp
Method(_AC0) {
Return (\_SB.CPU1.AC0) } // active
cooling (fan) temp
Method(_PSV) {
Return (\_SB.CPU1.PSV) } // passive
cooling temp
Method(_CRT) {
Return (\_SB.CPU1.CRT) } // critical
temp
Name(_TC1, 4) //
thermal constant 1 (INVALID)
Name(_TC2, 3) //
thermal constant 2 (INVALID)
Method(_TPT, 1) {
Store (Arg0, \_SB.CPU1.TPT)} // trip point temp
Method(_TST) {
Return (\_SB.CPU1.TST) } // temp
sensor threshold
} // end of CPU1 scope
} // end of SSDT
12 ACPI Embedded Controller Interface Specification
ACPI defines 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. This in turn enables the OEM to provide platform features that the
OS OSPM and applications can take advantage of.
ACPI also defines a standard hardware and software
communications interface between an OS driver and an Embedded Controller-based
SMB-HC (EC-SMB-HC).
The ACPI standard supports multiple embedded controllers in
a system, each with its own resources. Each embedded controller has a flat
byte-addressable I/O space, currently defined as 256 bytes. Features
implemented in the embedded controller have an event "query" mechanism that
allows feature hardware implemented by the embedded controller to gain the
attention of an OS driver or ASL/AML code handler. The interface has been
specified to work on the most popular embedded controllers on the market today,
only requiring changes in the way the embedded controller is "wired" to the
host interface.
Two interfaces are specified:
· A private interface, exclusively owned by the embedded controller
driver.
· A shared interface, used by the embedded controller driver and
some other driver.
This interface is separate from the traditional PC keyboard
controller. Some OEMs might choose to implement the ACPI Embedded Controller
Interface (ECI) within the same embedded controller as the keyboard controller
function, but the ECI requires its own unique host resources (interrupt event
and access registers).
This interface does support sharing the ECI with an
inter-environment interface (such as SMI) and relies on the ACPI-defined
"Global Lock" protocol. For information about the Global Lock interface, see
section 5.2.10.1, "Global Lock." Both the shared and private EC interfaces are
described in the following sections.
The ECI has been designed such that a platform can use it
in either the legacy or ACPI modes with minimal changes between the two
operating environments. This is to encourage standardization for this interface
to enable faster development of platforms as well as opening up features within
these controllers to higher levels of software.
12.1 Embedded Controller Interface Description
Embedded controllers are the general class of
microcontrollers used to support OEM-specific implementations. 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 is a unique feature in that it can perform complex
low-level functions through a simple interface to the host microprocessor(s).
Although there is a large variety of microcontrollers in
the market today, the most commonly used embedded controllers include a host
interface that connects the embedded controller to the host data bus, allowing
bi-directional communications. A bi-directional interrupt scheme reduces the
host processor latency in communicating with the embedded controller.
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.
Figure
12-1 Shared Interface
The diagram above depicts the general register model
supported by the ACPI Embedded Controller Interface.
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
following diagram illustrates the embedded controller architecture that
includes a dedicated ACPI interface.
Figure 12-2 Private Interface
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 system's
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 system's use of the
interface and the system management handler's use of the interface. This is
done using the Global Lock as described in section 5.2.10.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 problem 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.
12.2 Embedded Controller
Register Descriptions
The embedded controller contains three registers at two
address locations: EC_SC and EC_DATA. The EC_SC, or Embedded Controller
Status/Command register, acts as two registers: a status register for reads to
this port and a command register for writes to this port. The EC_DATA (Embedded
Controller Data register) acts as a port for transferring data between the host
CPU and the embedded controller.
12.2.1 Embedded Controller Status, EC_SC (R)
This is a read-only register that indicates the current
status of the embedded controller interface.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
IGN
|
SMI_EVT
|
SCI_EVT
|
BURST
|
CMD
|
IGN
|
IBF
|
OBF
|
Where:
IGN:
|
Ignored
|
SMI_EVT:
|
1 – Indicates SMI event is pending (requesting SMI
query).
|
|
0 – No SMI events are pending.
|
SCI_EVT:
|
1 – Indicates SCI event is pending (requesting SCI
query).
|
|
0 – No SCI events are pending.
|
BURST:
|
1 – Controller is in burst mode for polled command
processing.
|
|
0 – Controller is in normal mode for interrupt-driven
command processing.
|
CMD:
|
1 – Byte in data register is a command byte (only used
by controller).
|
|
0 – Byte in data register is a data byte (only used by
controller).
|
IBF:
|
1 – Input buffer is full (data ready for embedded
controller).
|
|
0 – Input buffer is empty.
|
OBF:
|
1 – Output buffer is full (data ready for host).
|
|
0 – Output buffer is empty.
|
The Output Buffer Full (OBF) flag is set when the embedded
controller has written a byte of data into the command or data port but the
host has not yet read it. After the host reads the status byte and sees the OBF
flag set, the host reads the data port to get the byte of data that the
embedded controller has written. After the host reads the data byte, the OBF
flag is cleared automatically by hardware. This signals the embedded controller
that the data has been read by the host and the embedded controller is free to
write more data to the host.
The Input Buffer Full (IBF) flag is set when the host has
written a byte of data to the command or data port, but the embedded controller
has not yet read it. After the embedded controller reads the status byte and
sees the IBF flag set, the embedded controller reads the data port to get the
byte of data that the host has written. After the embedded controller reads the
data byte, the IBF flag is automatically cleared by hardware. This is the
signal to the host that the data has been read by the embedded controller and
that the host is free to write more data to the embedded controller.
The SCI event (SCI_EVT) flag is set when the embedded
controller has detected an internal event that requires the operating system's
attention. The embedded controller sets this bit in the status register, and
generates an SCI to OSPM. OSPM needs this bit to differentiate command-complete
SCIs from notification SCIs. OSPM uses the query command to request the cause
of the SCI_EVT and take action. For more information, see section 13.3,
"Embedded Controller Command Set.")
The SMI event (SMI_EVT) flag is set when the embedded
controller has detected an internal event that requires the system management
interrupt handler's 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.
12.2.2 Embedded Controller Command, EC_SC (W)
This is a write-only register that allows commands to be
issued to the embedded controller. Writes to this port are latched in the input
data register and the input buffer full flag is set in the status register.
Writes to this location also cause the command bit to be set in the status
register. This allows the embedded controller to differentiate the start of a
command sequence from a data byte write operation.
12.2.3 Embedded Controller Data, EC_DATA (R/W)
This is a read/write register that allows additional
command bytes to be issued to the embedded controller, and allows OSPM to read
data returned by the embedded controller. Writes to this port by the host are
latched in the input data register, and the input buffer full flag is set in
the status register. Reads from this register return data from the output data
register and clear the output buffer full flag in the status register.
12.3 Embedded Controller
Command Set
The embedded controller command set allows OSPM to
communicate with the embedded controllers. ACPI defines the commands and their
byte encodings for use with the embedded controller that are shown in the
following table.
Table 12-1 Embedded Controller Commands
Embedded Controller Command
|
Command Byte Encoding
|
Read Embedded Controller (RD_EC)
|
0x80
|
Write Embedded Controller (WR_EC)
|
0x81
|
Burst Enable Embedded Controller (BE_EC)
|
0x82
|
Burst Disable Embedded Controller (BD_EC)
|
0x83
|
Query Embedded Controller (QR_EC)
|
0x84
|
12.3.1 Read Embedded Controller, RD_EC (0x80)
This command byte allows OSPM to read a byte in the address
space of the embedded controller. This command byte is reserved for exclusive
use by OSPM, and it indicates to the embedded controller to generate SCIs in
response to related transactions (that is, IBF=0 or OBF=1 in the EC Status
Register), rather than SMIs. This command consists of a command byte written to
the Embedded Controller Command register (EC_SC), followed by an address byte
written to the Embedded Controller Data register (EC_DATA). The embedded
controller then returns the byte at the addressed location. The data is read at
the data port after the OBF flag is set.
12.3.2 Write Embedded Controller, WR_EC (0x81)
This command byte allows OSPM to write a byte in the
address space of the embedded controller. This command byte is reserved for
exclusive use by OSPM, and it indicates to the embedded controller to generate
SCIs in response to related transactions (that is, IBF=0 or OBF=1 in the EC
Status Register), rather than SMIs. This command allows OSPM to write a byte in
the address space of the embedded controller. It consists of a command byte
written to the Embedded Controller Command register (EC_SC), followed by an
address byte written to the Embedded Controller Data register (EC_DATA),
followed by a data byte written to the Embedded Controller Data Register
(EC_DATA); this is the data byte written at the addressed location.
12.3.3 Burst Enable Embedded Controller, BE_EC (0x82)
This command byte allows OSPM to request dedicated
attention from the embedded controller and (except for critical events)
prevents the embedded controller from doing tasks other than receiving command
and data from the host processor (either the system management interrupt
handler or OSPM). This command is an optimization that allows the host
processor to issue several commands back to back, in order to reduce latency at
the embedded controller interface. When the controller is in the burst mode, it
should transition to the burst disable state if the host does not issue a
command within the following guidelines:
· First Access – 400 microseconds
· Subsequent Accesses – 50 microseconds each
· Total Burst Time – 1 millisecond
In addition, the embedded controller can disengage the
burst mode at any time to process a critical event. If the embedded controller
disables burst mode for any reason other than the burst disable command, it
should generate an SCI to OSPM to indicate the change.
While in burst mode, the embedded controller follows these
guidelines for OSPM driver:
SCIs are generated as normal, including IBF=0 and OBF=1.
Accesses should be responded to within 50 microseconds.
Burst mode is entered in the following manner:
OSPM driver writes the Burst Enable Embedded Controller,
BE_EC (0x82) command byte and then the Embedded Controller will prepare to
enter the Burst mode. This includes processing any routine activities such that
it should be able to remain dedicated to OSPM interface for ~ 1 microsecond.
The Embedded Controller sets the Burst bit of the Embedded
Controller Status Register, puts the Burst Acknowledge byte (0x90) into the SCI
output buffer, sets the OBF bit, and generates an SCI to signal OSPM that it is
in Burst mode.
Burst mode is exited the following manner:
OSPM driver writes the Burst Disable Embedded Controller,
BD_EC (0x83) command byte and then the Embedded Controller will exit Burst mode
by clearing the Burst bit in the Embedded Controller Status register and
generating an SCI signal (due to IBF=0).
The Embedded Controller clears the Burst bit of the
Embedded Controller Status Register.
12.3.4 Burst Disable Embedded
Controller, BD_EC (0x83)
This command byte releases the embedded controller from a
previous burst enable command and allows it to resume normal processing. This
command is sent by OSPM or system management interrupt handler after it has
completed its entire queued command sequence to the embedded controller.
12.3.5 Query Embedded Controller,
QR_EC (0x84)
OSPM driver sends this command when the SCI_EVT flag in the
EC_SC register is set. When the embedded controller has detected a system event
that must be communicated to OSPM, it first sets the SCI_EVT flag in the EC_SC
register, generates an SCI, and then waits for OSPM to send the query (QR_EC)
command. OSPM detects the embedded controller SCI, sees the SCI_EVT flag set,
and sends the query command to the embedded controller. Upon receipt of the
QR_EC command byte, the embedded controller places a notification byte with a
value between 0-255, indicating the cause of the notification. The notification
byte indicates which interrupt handler operation should be executed by OSPM to
process the embedded controller SCI. The query value of zero is reserved for a
spurious query result and indicates "no outstanding event."
12.4 SMBus Host Controller
Notification Header (Optional), OS_SMB_EVT
This query command notification header is the special
return code that indicates events with an SMBus controller implemented within
an embedded controller. These events include:
· Command completion
· Command error
· Alarm reception
The actual notification value is declared in the EC-SMB-HC
device object in the ACPI Namespace.
12.5 Embedded Controller Firmware
The embedded controller firmware must obey the following
rules in order to be ACPI-compatible:
· SMI Processing.
Although it is not explicitly stated in
the command specification section, a shared embedded controller interface has a
separate command set for communicating with each environment it plans to
support. In other words, the embedded controller knows which environment is
generating the command request, as well as which environment is to be notified
upon event detection, and can then generate the correct interrupts and
notification values. This implies that a system management handler uses
commands that parallel the functionality of all the commands for ACPI including
query, read, write, and any other implemented specific commands.
· SCI/SMI Task Queuing.
If the system design is sharing the
interface between both a system management interrupt handler and OSPM, the
embedded controller should always be prepared to queue a notification if it
receives a command. The embedded controller only sets the appropriate event
flag in the status (EC_SC) register if the controller has detected an event
that should be communicated to the OS or system management handler
embedded controller must be able to field commands from either environment
without loss of the notification event. At some later time, the OS or system
management handler issues a query command to the embedded controller to request
the cause of the notification event.
· Notification Management.
The use of the embedded controller means
using the query (QR_EC) command to notify OSPM of system events requiring
action. If the embedded controller is shared with the operating system, the SMI
handler uses the SMI_EVT flag and an SMI query command (not defined in this
document) to receive the event notifications. The embedded controller doesn't
place event notifications into the output buffer of a shared interface unless
it receives a query command from OSPM or the system management interrupt
handler.
12.6 Interrupt Model
The EC Interrupt Model uses pulsed interrupts to speed the
clearing process. The Interrupt is firmware generated using an EC
general-purpose output and has the waveform shown in Figure 12-3. The embedded
controller SCI is always wired directly to a GPE input, and OSPM driver treats
this as an edge event (the EC SCI GPE cannot be shared).
Figure
12-3 EC Interrupt Waveform
12.6.1 Event Interrupt Model
The embedded controller must generate SCIs for the events
listed in the following table.
Table 12-2 Events for Which Embedded
Controller Must Generate SCIs
Event
|
Description
|
IBF=0
|
Signals that the embedded controller has read the last command
or data from the input buffer and the host is free to send more data.
|
OBF=1
|
Signals that the embedded controller has written a byte of
data into the output buffer and the host is free to read the returned data.
|
SCI_EVT=1
|
Signals that the embedded controller has detected an event
that requires OS attention. OSPM should issue a query (QR_EC) command to find
the cause of the event.
|
12.6.2 Command Interrupt Model
The embedded controller must generate SCIs for commands as
follows:
· Read Command (3 Bytes)
Byte #1
|
(Command byte Header)
|
Interrupt on IBF=0
|
Byte #2
|
(Address byte to read)
|
No Interrupt
|
Byte #3
|
(Data read to host)
|
Interrupt on OBF=1
|
· Write Command (3 Bytes)
Byte #1
|
(Command byte Header)
|
Interrupt on IBF=0
|
Byte #2
|
(Address byte to write)
|
Interrupt on IBF=0
|
Byte #3
|
(Data to read )
|
Interrupt on IBF=0
|
· Query Command (2 Bytes)
Byte #1
|
(Command byte Header)
|
No Interrupt
|
Byte #2
|
(Query value to host)
|
Interrupt on OBF=1
|
· Burst Enable Command (2
Bytes)
Byte #1
|
(Command byte Header)
|
No Interrupt
|
Byte #2
|
(Burst acknowledge byte)
|
Interrupt on OBF=1
|
· Burst Disable Command (1
Byte)
Byte #1
|
(Command byte Header)
|
Interrupt on IBF=0
|
12.7 Embedded Controller Interfacing Algorithms
To initiate communications with the embedded controller,
OSPM or system management handler acquires ownership of the interface. This
ownership is acquired through the use of the Global Lock (described in section
5.2.10.1, "Global Lock"), or is owned by default by OSPM as a non-shared
resource (and the Global Lock is not required for accessibility).
After ownership is acquired, the protocol always consists
of the passing of a command byte. The command byte will indicate the type of
action to be taken. Following the command byte, zero or more data bytes can be
exchanged in either direction. The data bytes are defined according to the
command byte that is transferred.
The embedded controller also has two status bits that
indicate whether the registers have been read. This is used to ensure that the
host or embedded controller has received data from the embedded controller or
host. When the host writes data to the command or data register of the embedded
controller, the input buffer flag (IBF) in the status register is set within 1
microsecond. When the embedded controller reads this data from the input
buffer, the input buffer flag is reset. When the embedded controller writes
data into the output buffer, the output buffer flag (OBF) in the status
register is set. When the host processor reads this data from the output
buffer, the output buffer flag is reset.
12.8 Embedded Controller
Description Information
Certain aspects of the embedded controller's operation have
OEM-definable values associated with them. The following is a list of values
that are defined in the software layers of the ACPI specification:
· Status flag indicating whether the interface requires the use of
the Global Lock.
· Bit position of embedded controller interrupt in general-purpose
status register.
· Decode address for command/status register.
· Decode address for data register.
· Base address and query value of any EC-SMBus controller.
For implementation details of the above listed information,
see sections 12.11, "Defining an Embedded Controller Device in ACPI Namespace,"
and 12.12, "Defining an EC SMBus Host Controller in ACPI Namespace."
An embedded controller will require the inclusion of the
GLK method in its ACPI namespace 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 method.
12.9 SMBus Host Controller Interface via Embedded Controller
This section specifies a standard interface that an ACPI-compatible
OS can use to communicate with embedded controller-based SMBus host controllers
(EC-SMB-HC). This interface allows the host processor (under control of OSPM)
to manage devices on the SMBus. Typical devices residing on the SMBus include
Smart Batteries, Smart Battery Chargers, contrast/backlight control, and
temperature sensors.
The EC-SMB-HC interface consists of a block of registers
that reside in embedded controller space. These registers are used by software
to initiate SMBus transactions and receive SMBus notifications. By using a
well-defined register set, OS software can be written to operate with any
vendor's embedded controller hardware.
Certain SMBus segments have special requirements that the
host controller filters certain SMBus commands (for example, to prevent an
errant application or virus from potentially damaging the battery subsystem).
This is most easily accomplished by implementing the host interface controller
through an embedded controller—as embedded controller can easily filter
out potentially problematic commands.
Notice that an EC-SMB-HC interface will require the
inclusion of the GLK method in its ACPI namespace if potentially contentious
accesses to device resources are performed by non-OS code. See section 6.5.7,
"_GLK (Global Lock)" for details on using the _GLK method.
12.9.1 Register Description
The EC-SMBus host interface is a flat array of registers
that are arranged sequentially in the embedded controller address space.
12.9.1.1 Status Register, SMB_STS
This register indicates general status on the SMBus. This
includes SMB-HC command completion status, alarm received status, and error
detection status (the error codes are defined later in this section). This
register is cleared to zeroes (except for the ALRM bit) whenever a new command
is issued using a write to the protocol (SMB_PRTCL) register. This register is
always written with the error code before clearing the protocol register
SMB-HC query event (that is, an SMB-HC interrupt) is raised after the clearing
of the protocol register.
Note: OSPM must
ensure the ALRM bit is cleared after it has been serviced by writing '00' to
the SMB_STS register.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
DONE
|
ALRM
|
RES
|
|
|
STATUS
|
|
|
Where:
DONE:
|
Indicates the last command has completed and no error.
|
ALRM:
|
Indicates an SMBus alarm message has been received.
|
RES:
|
Reserved
|
STATUS:
|
Indicates SMBus communication status for one of the
reasons listed in the following table.
|
Table 12-3 SMBus Status Codes
Status Code
|
Name
|
Description
|
00h
|
SMBus OK
|
Indicates the transaction has been successfully completed.
|
07h
|
SMBus Unknown Failure
|
Indicates failure because of an unknown SMBus error.
|
10h
|
SMBus Device Address Not Acknowledged
|
Indicates the transaction failed because the slave device
address was not acknowledged.
|
11h
|
SMBus Device Error Detected
|
Indicates the transaction failed because the slave device
signaled an error condition.
|
12h
|
SMBus Device Command Access Denied
|
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 Charger's
output.
|
13h
|
SMBus Unknown Error
|
Indicates the transaction failed because the SMBus host
encountered an unknown error.
|
17h
|
SMBus Device Access Denied
|
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 system's power planes.
|
18h
|
SMBus Timeout
|
Indicates the transaction failed because the SMBus host
detected a timeout on the bus.
|
19h
|
SMBus Host Unsupported Protocol
|
Indicates the transaction failed because the SMBus host does
not support the requested protocol.
|
1Ah
|
SMBus Busy
|
Indicates that the transaction failed because the SMBus host
reports that the SMBus is presently busy with some other transaction
example, the Smart Battery might be sending charging information to the Smart
Battery Charger.
|
1Fh
|
SMBus PEC (CRC-8) Error
|
Indicates that a Packet Error Checking (PEC) error occurred
during the last transaction.
|
All other error codes are
reserved.
12.9.1.2 Protocol
Register, SMB_PRTCL
This register determines the type of SMBus transaction
generated on the SMBus. In addition to indicating the protocol type to the
SMB-HC, a write to this register initiates the transaction on the SMBus. Notice
that bit 7 of the protocol value is used to indicate whether packet error
checking should be employed. A value of 1 (one) in this bit indicates that PEC
format should be used for the specified protocol, and a value of 0 (zero)
indicates the standard (non-PEC) format should be used.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
PEC
|
PROTOCOL
|
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.
12.9.1.3 Address
Register, SMB_ADDR
This register contains the 7-bit address to be generated on
the SMBus. This is the first byte to be sent on the SMBus for all of the
different protocols.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
ADDRESS (A6:A0)
|
RES
|
Where:
RES:
|
Reserved
|
ADDRESS:
|
7-bit SMBus address. This address is not zero aligned (in
other words, it is only a 7-bit address (A6:A0) that is aligned from bit
1-7).
|
12.9.1.4 Command Register, SMB_CMD
This register contains the command byte that will be sent
to the target device on the SMBus and is used for the following protocols: send
byte, write byte, write word, read byte, read word, process call, block read
and block write. It is not used for the quick commands or the receive byte
protocol, and as such, its value is a "don't care" for those commands.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
COMMAND
|
Where:
COMMAND:
|
Command byte to be sent to SMBus device.
|
12.9.1.5 Data Register Array, SMB_DATA[i], i=0-31
This bank of registers contains the remaining bytes to be
sent or received in any of the different protocols that can be run on the
SMBus. The SMB_DATA[i] registers are defined on a per-protocol basis and, as
such, provide efficient use of register space.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
DATA
|
Where:
DATA:
|
One byte of data to be sent or received (depending upon
protocol).
|
12.9.1.6 Block Count Register, SMB_BCNT
This register contains the number of bytes of data present
in the SMB_DATA[i] registers preceding any write block and following any read
block transaction. The data size is defined on a per protocol basis.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
RES
|
BCNT
|
12.9.1.7 Alarm
Address Register, SMB_ALRM_ADDR
This register contains the address of an alarm message
received by the host controller, at slave address 0x8, from the SMBus master
that initiated the alarm. The address indicates the slave address of the device
on the SMBus that initiated the alarm message. The status of the alarm message
is contained in the SMB_ALRM_DATAx registers. Once an alarm message has been
received, the SMB-HC will not receive additional alarm messages until the ALRM
status bit is cleared.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
ADDRESS (A6:A0)
|
RES
|
Where:
RES:
|
Reserved
|
ADDRESS:
|
Slave address (A6:A0) of the SMBus device that initiated
the SMBus alarm message.
|
12.9.1.8 Alarm Data Registers, SMB_ALRM_DATA[0], SMB_ALRM_DATA[1]
These registers contain the two data bytes of an alarm
message received by the host controller, at slave address 0x8, from the SMBus
master that initiated the alarm. These data bytes indicate the specific reason
for the alarm message, such that OSPM can take actions. Once an alarm message
has been received, the SMB-HC will not receive additional alarm messages until
the ALRM status bit is cleared.
Bit7
|
Bit6
|
Bit5
|
Bit4
|
Bit3
|
Bit2
|
Bit1
|
Bit0
|
DATA (D7:D0)
|
Where:
DATA:
|
Data byte received in alarm message.
|
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.
12.9.2 Protocol Description
This section describes how to initiate the different
protocols on the SMBus through the interface described in section 13.9.1,
"Register Descriptions." The registers should all be written with the
appropriate values before writing the protocol value that starts the SMBus
transaction. All transactions can be completed in one pass.
12.9.2.1 Write
Quick
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_PRTCL:
|
Write 0x02 to initiate the write quick protocol.
|
Data Returned:
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.2 Read
Quick
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_PRTCL:
|
Write 0x03 to initiate the read quick protocol.
|
Data Returned:
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.3 Send Byte
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_PRTCL:
|
Write 0x04 to initiate the send byte protocol, or 0x84 to
initiate the send byte protocol with PEC.
|
Data Returned:
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.4 Receive
Byte
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_PRTCL:
|
Write 0x05 to initiate the receive byte protocol, or 0x85
to initiate the receive byte protocol with PEC.
|
Data Returned:
SMB_DATA[0]:
|
Data byte received.
|
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.5 Write
Byte
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_DATA[0]:
|
Data byte to be sent.
|
SMB_PRTCL:
|
Write 0x06 to initiate the write byte protocol, or 0x86
to initiate the write byte protocol with PEC.
|
Data Returned:
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.6 Read Byte
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_PRTCL:
|
Write 0x07 to initiate the read byte protocol, or 0x87 to
initiate the read byte protocol with PEC.
|
Data Returned:
SMB_DATA[0]:
|
Data byte received.
|
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.7 Write
Word
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_DATA[0]:
|
Low data byte to be sent.
|
SMB_DATA[1]:
|
High data byte to be sent.
|
SMB_PRTCL:
|
Write 0x08 to initiate the write word protocol, or 0x88
to initiate the write word protocol with PEC.
|
Data Returned:
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.8 Read
Word
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_PRTCL:
|
Write 0x09 to initiate the read word protocol, or 0x89 to
initiate the read word protocol with PEC.
|
Data Returned:
SMB_DATA[0]:
|
Low data byte received.
|
SMB_DATA[1]:
|
High data byte received.
|
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.9 Write Block
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_DATA[0-31]:
|
Data bytes to write (1-32).
|
SMB_BCNT:
|
Number of data bytes (1-32) to be sent.
|
SMB_PRTCL:
|
Write 0x0A to initiate the write block protocol, or 0x8A
to initiate the write block protocol with PEC.
|
Data Returned:
SMB_PRTCL:
|
0x00 to indicate command completion.
|
SMB_STS:
|
Status code for transaction.
|
12.9.2.10 Read
Block
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_PRTCL:
|
Write 0x0B to initiate the read block protocol, or 0x8B
to initiate the read block protocol with PEC.
|
Data Returned:
SMB_BCNT:
|
Number of data bytes (1-32) received.
|
SMB_DATA[0-31]:
|
Data bytes received (1-32).
|
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.11 Process
Call
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_DATA[0]:
|
Low data byte to be sent.
|
SMB_DATA[1]:
|
High data byte to be sent.
|
SMB_PRTCL:
|
Write 0x0C to initiate the process call protocol, or 0x8C
to initiate the process call protocol with PEC.
|
Data Returned:
SMB_DATA[0]:
|
Low data byte received.
|
SMB_DATA[1]:
|
High data byte received.
|
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
12.9.2.12 Block Write-Block Read Process Call
Data Sent:
SMB_ADDR:
|
Address of SMBus device.
|
SMB_CMD:
|
Command byte to be sent.
|
SMB_DATA[0-31]:
|
Data bytes to write (1-31).
|
SMB_BCNT:
|
Number of data bytes (1-31) to be sent.
|
SMB_PRTCL:
|
Write 0x0D to initiate the write block-read block process
call protocol, or 0x8D to initiate the write block-read block process call
protocol with PEC.
|
Data Returned:
SMB_BCNT:
|
Number of data bytes (1-31) received.
|
SMB_DATA[0-31]:
|
Data bytes received (1-31).
|
SMB_STS:
|
Status code for transaction.
|
SMB_PRTCL:
|
0x00 to indicate command completion.
|
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.
12.9.3 SMBus Register Set
The register set for the SMB-HC has the following format.
All registers are 8 bit.
Table 12-4 SMB EC Interface
LOCATION
|
REGISTER NAME
|
DESCRIPTION
|
BASE+0
|
SMB_PRTCL
|
Protocol register
|
BASE+1
|
SMB_STS
|
Status register
|
BASE+2
|
SMB_ADDR
|
Address register
|
BASE+3
|
SMB_CMD
|
Command register
|
BASE+4
|
SMB_DATA[0]
|
Data register zero
|
BASE+5
|
SMB_DATA[1]
|
Data register one
|
BASE+6
|
SMB_DATA[2]
|
Data register two
|
BASE+7
|
SMB_DATA[3]
|
Data register three
|
BASE+8
|
SMB_DATA[4]
|
Data register four
|
BASE+9
|
SMB_DATA[5]
|
Data register five
|
BASE+10
|
SMB_DATA[6]
|
Data register six
|
BASE+11
|
SMB_DATA[7]
|
Data register seven
|
BASE+12
|
SMB_DATA[8]
|
Data register eight
|
BASE+13
|
SMB_DATA[9]
|
Data register nine
|
BASE+14
|
SMB_DATA[10]
|
Data register ten
|
BASE+15
|
SMB_DATA[11]
|
Data register eleven
|
Table 12-4 SMB EC Interface (continued)
BASE+16
|
SMB_DATA[12]
|
Data register twelve
|
BASE+17
|
SMB_DATA[13]
|
Data register thirteen
|
BASE+18
|
SMB_DATA[14]
|
Data register fourteen
|
BASE+19
|
SMB_DATA[15]
|
Data register fifteen
|
BASE+20
|
SMB_DATA[16]
|
Data register sixteen
|
BASE+21
|
SMB_DATA[17]
|
Data register seventeen
|
BASE+22
|
SMB_DATA[18]
|
Data register eighteen
|
BASE+23
|
SMB_DATA[19]
|
Data register nineteen
|
BASE+24
|
SMB_DATA[20]
|
Data register twenty
|
BASE+25
|
SMB_DATA[21]
|
Data register twenty-one
|
BASE+26
|
SMB_DATA[22]
|
Data register twenty-two
|
BASE+27
|
SMB_DATA[23]
|
Data register twenty-three
|
BASE+28
|
SMB_DATA[24]
|
Data register twenty-four
|
BASE+29
|
SMB_DATA[25]
|
Data register twenty-five
|
BASE+30
|
SMB_DATA[26]
|
Data register twenty-six
|
BASE+31
|
SMB_DATA[27]
|
Data register twenty-seven
|
BASE+32
|
SMB_DATA[28]
|
Data register twenty-eight
|
BASE+33
|
SMB_DATA[29]
|
Data register twenty-nine
|
BASE+34
|
SMB_DATA[30]
|
Data register thirty
|
BASE+35
|
SMB_DATA[31]
|
Data register thirty-one
|
BASE+36
|
SMB_BCNT
|
Block Count Register
|
BASE+37
|
SMB_ALRM_ADDR
|
Alarm address
|
BASE+38
|
SMB_ALRM_DATA[0]
|
Alarm data register zero
|
BASE+39
|
SMB_ALRM_DATA[1]
|
Alarm data register one
|
12.10 SMBus Devices
The embedded controller interface provides the system with
a standard method to access devices on the SMBus. It does not define the data
and/or access protocol(s) used by any particular SMBus device. Further, the
embedded controller can (and probably will) serve as a gatekeeper to prevent
accidental or malicious access to devices on the SMBus.
Some SMBus devices are defined by their address and a
specification that describes the data and the protocol used to access that
data. For example, the Smart Battery System devices are defined by a series of
specifications including:
· Smart Battery Data specification
· Smart Battery Charger specification
· Smart Battery Selector specification
· Smart Battery System Manager specification
The embedded controller can also be used to emulate (in part
or totally) any SMBus device.
12.10.1 SMBus Device Access Restrictions
In some cases, the embedded controller interface will not
allow access to a particular SMBus device. Some SMBus devices can and do
communicate directly between themselves. Unexpected accesses can interfere with
their normal operation and cause unpredictable results.
12.10.2 SMBus Device Command Access Restriction
There are cases where
part of an SMBus device's commands are public while others are private.
Extraneous attempts to access these commands might cause interference
with the SMBus device's normal operation.
The Smart Battery and the Smart Battery Charger are good
examples of devices that should not have their entire command set exposed
Smart Battery commands the Smart Battery Charger to supply a specific charging
voltage and charging current. Attempts by anyone to alter these values can
cause damage to the battery or the mobile system. To protect the system's
integrity, the embedded controller interface can restrict access to these
commands by returning one of the following error codes: Device Command Access
Denied (0x12) or Device Access Denied (0x17).
12.11 Defining an Embedded
Controller Device in ACPI Namespace
An embedded controller device is created using the named
device object. The embedded controller's device object requires the following
elements:
Table 12-5 Embedded Controller Device
Object Control Methods
Object
|
Description
|
_CRS
|
Named object that returns the Embedded Controller's current
resource settings. Embedded Controllers are considered static resources; hence only return their defined resources. The embedded controller resides
only in system I/O or memory space. The first address region returned is the
data port, and the second address region returned is the status/command port
for the embedded controller. CRS is a standard device configuration control
method defined in section 6.2.1, "_CRS (Current Resource Settings)."
|
_HID
|
Named object that provides the Embedded Controller's Plug and
Play identifier. This value is set to PNP0C09. _HID is a standard device
configuration control method defined in section 6.1.4, "_HID (Hardware ID)."
|
_GPE
|
Named Object that evaluates to either an integer or a package.
If _GPE evaluates to an integer, the value is the bit assignment of the SCI
interrupt within the GPEx_STS register of a GPE block described in the FADT
that the embedded controller will trigger.
If _GPE evaluates to a package, then that package contains two
elements. The first is an object reference to the GPE Block device that
contains the GPE register that will be triggered by the embedded controller.
The second element is numeric (integer) that specifies the bit assignment of
the SCI interrupt within the GPEx_STS register of the GPE Block device
referenced by the first element in the package. This control method is
specific to the embedded controller.
|
12.11.1 Example: EC
Definition ASL Code
Example ASL code that defines an embedded controller device
is shown below:
Device(EC0) {
// PnP ID
Name(_HID, EISAID("PNP0C09"))
// Returns the "Current Resources" of EC
Name(_CRS,
ResourceTemplate(){ //
port 0x62 and 0x66
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)
OperationRegion(ECOR, EmbeddedControl, 0,
0xFF)
Field(ECOR, ByteAcc, Lock, Preserve) {
// Field definitions go here
}
}
12.12 Defining an EC SMBus Host Controller in ACPI Namespace
An EC-SMB-HC device is defined using the named device
object. The EC-SMB- HC's device object requires the following elements:
Table 12-6 EC SMBus HC Device Objects
Object
|
Description
|
_HID
|
Named object that provides the EC-SMB- HC's Plug and Play
identifier. This value is be set to ACPI0001. _HID is a standard device
configuration control method defined in section 6.1.4, "_HID (Hardware ID)."
|
_EC
|
Named object that evaluates to a WORD that defines the SMBus
attributes needed by the SMBus driver. _EC is the Embedded Controller Offset
Query Control Method. The most significant byte is the address offset in
embedded controller space of the SMBus controller; the least significant byte
is the query value for all SMBus events.
|
12.12.1 Example: EC SMBus Host Controller ASL-Code
Example ASL code that defines an SMB-HC from within an
embedded controller device is shown below:
Device(EC0)
{
Name(_HID,
EISAID("PNP0C09"))
Name(_CRS, ResourceTemplate()
{
IO(Decode16,
0x62, 0x62, 0, 1), // Status port
IO(Decode16,
0x66, 0x66, 0, 1) // command port
})
Name(_GPE, 0)
Device (SMB0)
{
Name(_HID, "ACPI0001") //
EC-SMB-HC
Name(_UID, 0) //
Unique device identifier
Name(_EC, 0x2030)
// EC offset 0x20, query bit 0x30
:
}
Device (SMB1)
{
Name(_HID,
"ACPI0001") //
EC-SMB-HC
Name(_UID, 1) //
Unique device identifier
Name(_EC, 0x8031)
// EC offset 0x80, query bit 0x31
:
}
} // end of EC0
13 ACPI System Management Bus Interface Specification
This section describes the System Management Bus (SMBus)
generic address space and the use of this address space to access SMBus devices
from AML.
Unlike other address spaces, SMBus operation regions are
inherently non-linear, where each offset
within an SMBus address space represents a variable-sized (from 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
for all transactions.
The SMBus interface presented in this section is intended
for use with any hardware implementation compatible with the SMBus
specification. SMBus hardware is broadly classified as either
non-EC–based or EC-based. EC-based SMBus implementations comply with the
standard register set defined in section 13, ACPI Embedded Controller Interface
Specification."
Non-EC SMBus implementations can employ any hardware
interface and are typically used for their cost savings when SMBus security is
not required. Non–EC-based SMBus implementations require the development
of hardware specific drivers for each OS implementation. See section 13.2,
"Declaring SMBus Host Controller Objects," for more information.
Support of the SMBus generic address space by
ACPI-compatible operating systems is optional. As such, the Smart Battery
System Implementer's Forum (SBS-IF) has defined an SMBus interface based on a
standard set of control methods. This interface is documented in the SMBus
Control Method Interface Specification,
available from the SBS-IF Web site at: http://www.sbs-forum.org/.
13.1 SMBus Overview
SMBus is a two-wire interface based upon the I²C protocol.
The SMBus is a low-speed bus that provides positive addressing for devices, as
well as bus arbitration. For more information, refer to the complete set of
SMBus specifications published by the SBS-IF.
13.1.1 SMBus Slave Addresses
Slave addresses are specified using a 7-bit non-shifted
notation. For example, the slave address of the Smart Battery Selector device
would be specified as 0x0A (1010b), not 0x14 (10100b) as might be found in
other documents. These two different forms of addresses result from the format
in which addresses are transmitted on the SMBus.
During transmission over the physical SMBus, the slave
address is formatted in an 8-bit block with bits 7-1 containing the address and
bit 0 containing the read/write bit. ASL code, on the other hand, presents the
slave address simply as a 7-bit value making it the responsibility of the OS
(driver) to shift the value if needed. For example, the ASL value would have to
be shifted left 1 bit before being written to the SMB_ADDR register in the EC
based SMBus as described in section 12.9.1.3, "Address Register, SMB_ADDR."
13.1.2 SMBus
Protocols
There are seven possible command protocols for any given SMBus slave device, and a device may
use any or all of the protocols to communicate. The protocols and associated
access type indicators are listed below. Notice that the protocols values are
similar to those defined for the EC-based SMBus in section 12.9.1.2, "Protocol
Register, SMB_PRTCL," except that protocol pairs (for example, Read Byte, Write
Byte) have been joined.
Table 13-1 SMBus Protocol Types
Value
Type
Description
|
0x02
|
SMBQuick
|
SMBus Read/Write Quick Protocol
|
0x04
|
SMBSendReceive
|
SMBus Send/Receive Byte Protocol
|
0x06
|
SMBByte
|
SMBus Read/Write Byte Protocol
|
0x08
|
SMBWord
|
SMBus Read/Write Word Protocol
|
0x0A
|
SMBBlock
|
SMBus Read/Write Block Protocol
|
0x0C
|
SMBProcessCall
|
SMBus Process Call Protocol
|
0x0D
|
SMBBlockProcessCall
|
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
example, the value 0x86 would be used to specify the PEC version of the SMBus
Read/Write Byte protocol.
Figure 13-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) for
write transactions.
13.1.3 SMBus Status Codes
The use of status codes helps AML determine whether an
SMBus transaction was successful. In general, a status code of zero indicates
success, while a non-zero value indicates failure. The SMBus interface uses the
same status codes defined for the EC-SMBus (see section 12.9.1.1, "Status
Register, SMB_STS").
13.1.4 SMBus
Command Values
SMBus devices may optionally support up to 256
device-specific commands. For these devices, each command value supported by the device is modeled by this interface
as a separate virtual register.
Protocols that do not transmit a command value (for example, Read/Write Quick
and Send/Receive Byte) are modeled using a single virtual register (with a
command value = 0x00).
13.2 Declaring SMBus Host Controller
Objects
EC-based SMBus 1.0-compatible HCs should be modeled in the
ACPI namespace as described in section 13.12, "Defining an Embedded Controller
SMBus Host Controller in ACPI Namespace." An example definition is given below.
Using the HID value "ACPI0001" identifies that this SMB-HC is implemented on an
embedded controller using the standard SMBus register set defined in section 12.9,
SMBus Host Controller Interface via Embedded Controller."
Device (SMB0)
{
Name(_HID,
"ACPI0001") //
EC-based SMBus 1.0 compatible Host Controller
Name(_EC, 0x2030)
// 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") //
EC-based SMBus 2.0 compatible Host Controller
Name(_EC, 0x2030)
// EC offset 0x20, query bit 0x30
:
}
Non–EC-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 segment's 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.
13.3 Declaring
SMBus Devices
The SMBus, as defined by the SMBus 1.0 Specification, is
not an enumerable bus. As a result, an SMBus 1.0-compatible SMB-HC driver
cannot discover child devices on the SMBus and load the appropriate
corresponding device drivers. As such, SMBus 1.0-compatible devices are
declared in the ACPI namespace, in like manner to other motherboard devices,
and enumerated by OSPM.
The SMBus 2.0 specification adds mechanisms enabling device
enumeration on the bus while providing compatibility with existing devices.
ACPI defines and associates the "ACPI0005" HID value with an EC-based SMBus
2.0-compatible host controller. OSPM will enumerate SMBus 1.0-compatible
devices when declared in the namespace under an SMBus 2.0-compatible host
controller.
The responsibility for the definition of ACPI namespace
objects, required by an SMBus 2.0-compatible host controller driver to
enumerate non–bus-enumerable devices, is relegated to the Smart Battery
System Implementers Forum (http://www.sbs-forum.org).
Starting in ACPI 2.0, _ADR is used to associate SMBus
devices with their lowest SMBus slave address.
13.4 Declaring SMBus Operation Regions
Each SMBus operation region definition identifies a single
SMBus slave address. Operation regions are defined only for those SMBus devices
that need to be accessed from AML. As with other regions, SMBus operation
regions are only accessible via the Field
term (see section 13.5, "Declaring SMBus Fields").
This interface models each SMBus device as having a
256-byte linear address range. Each byte offset within this range corresponds
to a single command value (for example, byte offset 0x12 equates to command
value 0x12), with a maximum of 256 command values. By doing this, SMBus address
spaces appear linear and can be processed in a manner similar to the other
address space types.
The syntax for the OperationRegion term (from section 17.5.89, "OperationRegion (Declare
Operation Region]") is described below.
OperationRegion (
RegionName, //
NameString
RegionSpace, //
RegionSpaceKeyword
Offset, // TermArg=>Integer
Length //
TermArg=>Integer
)
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 13-2 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.
Figure 13-2 Smart Battery Subsystem
Devices
The following ASL code shows the use of the OperationRegion
term to describe these SMBus devices:
Device (SMB0)
{
Name(_HID,
"ACPI0001") //
EC-SMBus Host Controller
Name(_EC, 0x2030)
// EC offset 0x20, query bit
0x30
OperationRegion(SBC0, SMBus, 0x0900,
0x100) // Smart Battery Charger
OperationRegion(SBS0, SMBus, 0x0A00,
0x100) // Smart Battery Selector
OperationRegion(SBD0, SMBus, 0x0B00,
0x100) // Smart Battery Device(s)
:
}
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).
13.5 Declaring
SMBus Fields
As with other regions, SMBus operation regions are only
accessible via the Field term. Each field element is assigned a unique command
value and represents a virtual register on the targeted SMBus device.
The syntax for the Field term (from section 17.5.38, "Event
(Declare Event Synchronization Object]") is described below.
Field(
RegionName, //
NameString=>OperationRegion
AccessType, //
AccessTypeKeyword
LockRule, //
LockRuleKeyword
UpdateRule //
UpdateRuleKeyword – ignored
) {FieldUnitList}
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 buffer's contents which may be of any size. When a field of
this type is used as the source argument in an operation it simply evaluates to
a buffer. When used as the destination, however, the buffer is passed
bi-directionally to allow data to be returned from write operations. The
modified buffer then becomes the execution result of that operation. This is
slightly different than the normal case in which the execution result is the
same as the value written to the destination. Note that the source is never
changed, since it could be a read only object (see section 13.6,
"Declaring an SMBus Data Buffer" and section 17.1.5, "Opcode Terms").
· 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 ignored for 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 17.1.3,
"ASL Root and SecondaryTerms") 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
section 13.1.2,
"SMBus Protocols," for a listing of the SMBus protocol types and values.
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.
Figure 13-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,
Preserve)
{
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
element's byte offset (for example, MFGA=0, RCAP=1, BTMP=8). The AccessAs term indicates which SMBus protocol to use for each
command value.
13.6 Declaring and Using an SMBus
Data Buffer
The use of a data buffer for SMBus transactions allows AML
to receive status and data length values, as well as making it possible to
implement the Process Call protocol. As previously mentioned, the BufferAcc access type is used to indicate to the field
handler that a region-specific data buffer will be used.
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 0 of the data buffer
BYTE Length; //
Byte 1 of the data buffer
BYTE[32] Data; //
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 buffer. Use 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 protocol—this
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 13.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){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, OB1) //
OB1 = Status (Byte)
CreateByteField(BUFF, 0x01, OB2) //
OB2 = Length (Byte)
CreateWordField(BUFF, 0x02, OB3) //
OB3 = Data (Word – Bytes 2 & 3)
CreateField(BUFF, 0x10, 256, OB4) //
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 CreateField primitives to access the data buffer's sub-elements
(Status, Length, and Data), where Data (bytes 2-33) is 'typecast' as both word (OB3) and block (OB4) data.
The example above demonstrates the use of the Store()
operator to invoke a Read Block transaction to obtain the name of the battery
manufacturer. Evaluation of the source
operand (MFGN) results in a 34-byte buffer that gets copied by Store() to the destination buffer (BUFF).
Capturing the results of a write operation, for example to
check the status code, requires an additional Store() operator, as shown below.
Store(Store(BUFF, MFGN), BUFF) //
Invoke Write Block transaction
If(LEqual(OB1, 0x00)) {…} //
Transaction successful?
Note that the outer Store() copies the results of the Write
Block transaction back into BUFF. This is the nature of BufferAcc's
bi-directionality described in section 13.5, "Declaring SMBus Fields" It
should be noted that storing (or parsing) the result of an SMBus Write
transaction is not required although useful for ascertaining the outcome of a
transaction.
SMBus Process Call protocols require similar semantics due
to the fact that only destination operands are passed bi-directionally. These
transactions require the use of the double-Store() semantics to properly
capture the return results.
13.7 Using the SMBus Protocols
This section provides information and examples on how each
of the SMBus protocols can be used to access SMBus devices from AML.
13.7.1 Read/Write Quick (SMBQuick)
The SMBus Read/Write Quick protocol (SMBQuick) is typically
used to control simple devices using a device-specific binary command (for
example, ON and OFF). Command values are not used by this protocol and thus
only a single element (at offset 0) can be specified in the field definition.
This protocol transfers no data.
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,
Preserve)
{
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){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, OB1) //
OB1 = Status (Byte)
/* Signal device (e.g. OFF) */
Store(FLD0, BUFF) //
Invoke Read Quick transaction
If(LEqual(OB1, 0x00)) {…} //
Successful?
/* Signal device (e.g. ON) */
Store(BUFF, FLD0) //
Invoke Write Quick transaction
In this example, a single field element (FLD0) at offset 0
is defined to represent the protocol's 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 transferred—access to the register is simply used as a
mechanism to invoke the transaction.
13.7.2 Send/Receive Byte (SMBSendReceive)
The SMBus Send/Receive Byte protocol (SMBSendReceive)
transfers a single byte of data. Like Read/Write Quick, command values are not
used by this protocol and thus only a single element (at offset 0) can be
specified in the field definition.
The following ASL code illustrates how a device supporting
the Send/Receive Byte protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200,
0x100) // SMBus device at slave address 0x42
Field(SMBD, BufferAcc, NoLock,
Preserve)
{
AccessAs(BufferAcc,
SMBSendReceive) // Use the SMBus Send/Receive Byte protocol
FLD0, 8 //
Virtual register at command value 0.
}
/* Create the SMBus data buffer */
Name(BUFF, Buffer(34){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, STAT) //
STAT = Status (Byte)
CreateByteField(BUFF, 0x02, DATA) //
DATA = Data (Byte)
/* 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
In this example, a single field element (FLD0) at offset 0
is defined to represent the protocol's 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.
13.7.3 Read/Write Byte (SMBByte)
The SMBus Read/Write Byte protocol (SMBByte) also transfers
a single byte of data. But unlike Send/Receive Byte, this protocol uses a
command value to reference up to 256 byte-sized virtual registers.
The following ASL code illustrates how a device supporting
the Read/Write Byte protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200,
0x100) // SMBus device at slave address 0x42
Field(SMBD, BufferAcc, NoLock, Preserve)
{
AccessAs(BufferAcc,
SMBByte) // Use the SMBus Read/Write
Byte protocol
FLD0, 8, //
Virtual register at command value 0.
FLD1, 8, //
Virtual register at command value 1.
FLD2, 8 //
Virtual register at command value 2.
}
/* Create the SMBus data buffer */
Name(BUFF, Buffer(34){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, STAT) //
STAT = Status (Byte)
CreateByteField(BUFF, 0x02, DATA) //
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
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.
13.7.4 Read/Write Word (SMBWord)
The SMBus Read/Write Word protocol (SMBWord) transfers 2
bytes of data. This protocol also uses a command value to reference up to 256
word-sized virtual device registers.
The following ASL code illustrates how a device supporting
the Read/Write Word protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200,
0x100) // SMBus device at slave address 0x42
Field(SMBD, BufferAcc, NoLock,
Preserve)
{
AccessAs(BufferAcc,
SMBWord) // Use the SMBus Read/Write
Word protocol
FLD0, 8, //
Virtual register at command value 0.
FLD1, 8, //
Virtual register at command value 1.
FLD2, 8 //
Virtual register at command value 2.
}
/* Create the SMBus data buffer */
Name(BUFF, Buffer(34){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, STAT) //
STAT = Status (Byte)
CreateWordField(BUFF, 0x02, DATA) //
DATA = Data (Word)
/* 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…
}
/* Write the word '0x5416' to the
device using command value 2 */
Store(0x5416, DATA) //
Save 0x5416 into the data buffer
Store(BUFF, FLD2) //
Invoke a Write Word transaction
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.
13.7.5 Read/Write Block (SMBBlock)
The SMBus Read/Write Block protocol (SMBBlock) transfers
variable-sized (0-32 bytes) data. This protocol uses a command value to
reference up to 256 block-sized virtual registers.
The following ASL code illustrates how a device supporting
the Read/Write Block protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200,
0x100) // SMBus device at slave address 0x42
Field(SMBD, BufferAcc, NoLock,
Preserve)
{
AccessAs(BufferAcc,
SMBBlock) // Use
the SMBus Read/Write Block protocol
FLD0, 8, //
Virtual register at command value 0.
FLD1, 8, //
Virtual register at command value 1.
FLD2, 8 //
Virtual register at command value 2.
}
/* Create the SMBus data buffer */
Name(BUFF, Buffer(34){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, STAT) //
STAT = Status (Byte)
CreateByteField(BUFF, 0x01, SIZE) //
SIZE = Length (Byte)
CreateField(BUFF, 0x10, 256, DATA) //
DATA = Data (Block)
/* 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
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.
13.7.6 Word Process Call (SMBProcessCall)
The SMBus Process Call protocol (SMBProcessCall) transfers
2 bytes of data bi-directionally (performs a Write Word followed by a Read Word
as an atomic transaction). This protocol uses a command value to reference up
to 256 word-sized virtual registers.
The following ASL code illustrates how a device supporting
the Process Call protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200,
0x100) // SMBus device at slave address 0x42
Field(SMBD, BufferAcc, NoLock, Preserve)
{
AccessAs(BufferAcc,
SMBProcessCall) // Use the SMBus Process Call protocol
FLD0, 8, //
Virtual register at command value 0.
FLD1, 8, //
Virtual register at command value 1.
FLD2, 8 //
Virtual register at command value 2.
}
/* Create the SMBus data buffer */
Name(BUFF, Buffer(34){}) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, STAT) //
STAT = Status (Byte)
CreateWordField(BUFF, 0x02, DATA) //
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(Store(BUFF, FLD1), BUFF) //
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.
13.7.7 Block Process Call (SMBBlockProcessCall)
The SMBus Block Write-Read Block Process Call protocol
(SMBBlockProcessCall) transfers a block of data bi-directionally (performs a
Write Block followed by a Read Block as an atomic transaction). The maximum
aggregate amount of data that may be transferred is limited to 32 bytes. This
protocol uses a command value to reference up to 256 block-sized virtual
registers.
The following ASL code illustrates how a device supporting
the Process Call protocol should be accessed:
OperationRegion(SMBD, SMBus, 0x4200,
0x100) // SMbus device at slave address 0x42
Field(SMBD, BufferAcc, NoLock, Preserve)
{
AccessAs(BufferAcc,
SMBBlockProcessCall) // Use the Block Process Call protocol
FLD0, 8, //
Virtual register representing a command value of 0
FLD1, 8 //
Virtual register representing a command value of 1
}
/* Create the SMBus data buffer as BUFF
*/
Name(BUFF, Buffer(34)()) //
Create SMBus data buffer as BUFF
CreateByteField(BUFF, 0x00, STAT) //
STAT = Status (Byte)
CreateByteField(BUFF, 0x01, SIZE) //
SIZE = Length (Byte)
CreateField(BUFF, 0x10, 256, DATA) //
Data (Block)
/* Process Call with input value
"ACPI" to the device using command value 1 */
Store("ACPI", DATA) //
Fill in outgoing data
Store(8, SIZE) //
Length of the valid data
Store(Store(BUFF, FLD1), BUFF) //
Execute the PC
if (LEqual(STAT, 0x00)) //
Test the status
{
/* BUFF now contains information
returned from PC */
/* SIZE now equals size of data
returned */
}
14 System Address Map Interfaces
This section explains how an
ACPI-compatible system conveys its memory resources/type mappings to OSPM.
There are three ways for the system to convey memory resources /mappings to
OSPM. The first is an INT 15 BIOS interface that is used in IA-PC–based
systems to convey the system's initial memory map. EFI enabled systems use the
EFI defined GetMemoryMap() boot
services function to convey memory resources to the OS loader. These resources
must then be conveyed by the OS loader to OSPM. See the EFI specification for
more information on EFI services.
Lastly, if memory resources may be added or removed
dynamically, memory devices are defined in the ACPI Namespace conveying the
resource information described by the memory device (see section 10.12, "Memory
Devices").
ACPI defines five address range types; AddressRangeMemory, AddressRangeACPI,
AddressRangeNVS, AddressRangeUnusable, and AddressRangeReserved as described in
the table below:
Table 14-1 Address Range Types
Value
|
Mnemonic
|
Description
|
1
|
AddressRangeMemory
|
This range is available RAM usable by the operating system.
|
2
|
AddressRangeReserved
|
This range of addresses is in use or reserved by the system
and must not be used by the operating system.
|
3
|
AddressRangeACPI
|
ACPI Reclaim Memory. This range is available RAM usable by the
OS after it reads the ACPI tables.
|
4
|
AddressRangeNVS
|
ACPI NVS Memory. This range of addresses is in use or reserve
by the system and must not be used by the operating system. This range is
required to be saved and restored across an NVS sleep.
|
5
|
AddressRangeUnusuable
|
This range of address contains memory in which
errors have been detected. This range must not be used by the OSPM.
|
Other
|
Undefined
|
Undefined. Reserved for future use. OSPM must treat any range
of this type as if the type returned was AddressRangeReserved.
|
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 memory space.
· The address range is within an NVRAM device where reads and
writes to memory locations are no longer successful, that is, the device was
worn out.
Note: OSPM will not
save or restore memory reported as AddressRangeReserved or AddressRangeUnusable
when transitioning to or from the S4 sleeping state.
14.1 INT 15H, E820H - Query
System Address Map
This interface is used in real mode only on IA-PC-based
systems and provides a memory map for all of the installed RAM, and of physical
memory ranges reserved by the BIOS. The address map is returned through
successive invocations of this interface; each returning information on a
single range of physical addresses. Each range includes a type that indicates
how the range of physical addresses is to be treated by the OSPM.
If the information returned from E820 in some way differs
from INT-15 88 or INT-15 E801, the information returned from E820 supersedes
the information returned from INT-15 88 or INT-15 E801. This replacement allows
the BIOS to return any information that it requires from INT-15 88 or INT-15
E801 for compatibility reasons. For compatibility reasons, if E820 returns any
AddressRangeACPI or AddressRangeNVS memory ranges below 16 MB, the INT-15 88
and INT-15 E801 functions must return the top of memory below the
AddressRangeACPI and AddressRangeNVS memory ranges.
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 14-2 Input
to the INT 15h E820h Call
EAX
|
Function Code
|
E820h
|
EBX
|
Continuation
|
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.
|
ES:DI
|
Buffer Pointer
|
Pointer to an Address Range Descriptor structure that the BIOS
fills in.
|
ECX
|
Buffer Size
|
The length in bytes of the structure passed to the BIOS
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.
|
EDX
|
Signature
|
'SMAP' Used by the BIOS to verify the caller is requesting
the system map information to be returned in ES:DI.
|
Table 14-3 Output from the INT 15h E820h
Call
CF
|
Carry Flag
|
Non-Carry – Indicates No Error
|
EAX
|
Signature
|
'SMAP.' Signature to verify correct BIOS revision.
|
ES:DI
|
Buffer Pointer
|
Returned Address Range Descriptor pointer. Same value as on
input.
|
ECX
|
Buffer Size
|
Number of bytes returned by the BIOS in the address range
descriptor. The minimum size structure returned by the BIOS is 20 bytes.
|
EBX
|
Continuation
|
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 14-4 Address Range Descriptor
Structure
Offset in Bytes
|
Name
|
Description
|
0
|
BaseAddrLow
|
Low 32 Bits of Base Address
|
4
|
BaseAddrHigh
|
High 32 Bits of Base Address
|
8
|
LengthLow
|
Low 32 Bits of Length in Bytes
|
12
|
LengthHigh
|
High 32 Bits of Length in Bytes
|
16
|
Type
|
Address type of this range
|
20
|
Extended Attributes
|
See Table 14-5
|
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
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 14-1.
Table 14-5 Extended Attributes for Address Range
Descriptor Structure
Bit
|
Mnemonic
|
Description
|
0
|
AddressRangeEnabled
|
If clear, the OSPM ignores the Address Range Descriptor. This
allows the BIOS to populate the E820 table with a static number of structures
but only enable them as necessary
|
1
|
AddressRangeNonVolatile
|
If set, the Address Range Descriptor represents non-volatile
memory. Memory reported as non-volatile may require characterization to
determine its suitability for use as conventional RAM.
|
2-31
|
Reserved
|
Reserved for future use.
|
14.2 E820 Assumptions and Limitations
· The
BIOS returns address ranges describing baseboard memory.
· The BIOS does not return a
range description for the memory mapping of PCI devices, ISA Option ROMs, and
ISA Plug and Play cards because the OS has mechanisms available to detect them.
· The BIOS returns chip set-defined address holes that are not
being used by devices as reserved.
· Address ranges defined for baseboard memory-mapped I/O devices,
such as APICs, are returned as reserved.
· All occurrences of the system BIOS are mapped as reserved,
including the areas below 1 MB, at 16 MB (if present), and at end of the 4-GB
address space.
· Standard PC address ranges are not reported. For example, video
memory at A0000 to BFFFF physical addresses are not described by this function.
The range from E0000 to EFFFF is specific to the baseboard and is reported as
it applies to that baseboard.
· All of lower memory is reported as normal memory. The OS must
handle standard RAM locations that are reserved for specific uses, such as the
interrupt vector table (0:0) and the BIOS data area (40:0).
14.3 EFI
GetMemoryMap() Boot Services Function
EFI enabled systems use the EFI defined GetMemoryMap() boot
services function to convey memory resources to the OS loader. These resources
must then be conveyed by the OS loader to OSPM.
The GetMemoryMap interface is only available at boot
services time. It is not available as a run-time service after OSPM is loaded.
The OS or its loader initiates the transition from boot services to run-time
services by calling ExitBootServices(). After the call to ExitBootServices()
all system memory map information must be derived from objects in the ACPI
Namespace.
The GetMemoryMap() interface returns an array of EFI memory
descriptors. These memory descriptors define a system memory map of all the
installed RAM, and of physical memory ranges reserved by the firmware. Each
descriptor contains a type field that dictates how the physical address range
is to be treated by the operating system. The table below describes the memory
types returned by the EFI GetMemoryMap() interface along with a mapping from
EFI memory type to ACPI address range types. See the EFI specification for more
information on EFI memory types.
Table 14-6 EFI
Memory Types and mapping to ACPI address range types
Type
|
Mnemonic
|
Description
|
ACPI Address Range Type
|
0
|
EfiReservedMemoryType
|
Not used.
|
AddressRangeReserved
|
1
|
EfiLoaderCode
|
The Loader and/or OS may use this memory as they see fit.
Note: the OS loader
that called ExitBootServices() is executing out of one or more EfiLoaderCode
sections.
|
AddressRangeMemory
|
Table 14-7 EFI Memory Types and mapping to
ACPI address range types (continued)
Type
|
Mnemonic
|
Description
|
ACPI Address Range Type
|
2
|
EfiLoaderData
|
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.
|
AddressRangeMemory
|
3
|
EfiBootServicesCode
|
Memory available for general use.
|
AddressRangeMemory
|
4
|
EfiBootServicesData
|
Memory available for general use.
|
AddressRangeMemory
|
5
|
EfiRuntimeServiceCode
|
The OS and loader must preserve this memory range in the
working and ACPI S1–S3 states.
|
AddressRangeReserved
|
6
|
EfiRuntimeServicesData
|
The OS and loader must preserve this memory range in the
working and ACPI S1–S3 states.
|
AddressRangeReserved
|
7
|
EfiConventionalMemory
|
Memory available for general use.
|
AddressRangeMemory
|
8
|
EfiUnusableMemory
|
Memory that should not be used by the OS. For example, memory
that failed EFI memory test.
|
AddressRangeReserved
|
9
|
EfiACPIReclainMemory
|
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.
|
AddressRangeACPI
|
10
|
EfiACPIMemoryNVS
|
The OS and loader must preserve this memory range in the
working and ACPI S1–S3 states.
|
AddressRangeNVS
|
11
|
EfiMemoryMappedIO
|
The OS does not use this memory. All system memory-mapped I/O
port space information should come from ACPI tables.
|
AddressRangeReserved
|
12
|
EfiMemoryMappedIOPortSpace
|
The OS does not use this memory. All system memory-mapped I/O
port space information should come from ACPI tables.
|
AddressRangeReserved
|
13
|
EfiPalCode
|
The OS and loader must preserve this memory range in the
working and ACPI S1–S3 states.
|
AddressRangeReserved
|
14.4 EFI Assumptions and Limitations
· The
firmware returns address ranges describing the current system memory
configuration.
· The firmware does not
return a range description for the memory mapping of PCI devices, ISA Option
ROMs, and ISA Plug and Play cards because the OS has mechanisms available to
detect them.
· The firmware returns chip set-defined address holes that are not
being used by devices as reserved.
· Address ranges defined for baseboard memory-mapped I/O devices,
such as APICs, are returned as reserved.
· All occurrences of the system firmware are mapped as reserved,
including the areas below 1 MB, at 16 MB (if present), and at end of the 4-GB
address space. This can include PAL code on ItaniumTM- based systems.
· Standard PC address ranges are not reported. For example, video
memory at A0000 to BFFFF physical addresses are not described by this function.
The range from E0000 to EFFFF is specific to the baseboard and is reported as
it applies to that baseboard.
· All of lower memory is reported as normal memory. The OS must
handle standard RAM locations that are reserved for specific uses, such as the
interrupt vector table (0:0) and the BIOS data area (40:0).
· EFI contains descriptors for memory mapped I/O and memory mapped
I/O port space to allow for virtual mode calls to EFI run-time functions
OS must never use these regions.
14.5 Example Address Map
This sample address map (for an Intel processor-based
system) describes a machine that has 128 MB of RAM, 640 KB of base memory and
127 MB of extended memory. The base memory has 639 KB available for the user
and 1 KB for an extended BIOS data area. A 4-MB Linear Frame Buffer (LFB) is
based at 12 MB. The memory hole created by the chip set is from 8 MB to 16 MB.
Memory‑mapped APIC devices are in the system. The I/O Unit is at FEC00000
and the Local Unit is at FEE00000. The system BIOS is remapped to 1 GB–64
KB.
The 639-KB endpoint of the first memory range is also the
base memory size reported in the BIOS data segment at 40:13. The following
table shows the memory map of a typical system.
Table 14-8 Sample
Memory Map
Base (Hex)
|
Length
|
Type
|
Description
|
0000 0000
|
639 KB
|
AddressRangeMemory
|
Available Base memory. Typically the same value as is
returned using the INT 12 function.
|
0009 FC00
|
1 KB
|
AddressRangeReserved
|
Memory reserved for use by the BIOS(s). This area
typically includes the Extended BIOS data area.
|
000F 0000
|
64 KB
|
AddressRangeReserved
|
System BIOS
|
0010 0000
|
7 MB
|
AddressRangeMemory
|
Extended memory, which is not limited to the 64‑MB
address range.
|
0080 0000
|
4 MB
|
AddressRangeReserved
|
Chip set memory hole required to support the LFB mapping
at 12 MB.
|
0100 0000
|
120 MB
|
AddressRangeMemory
|
Baseboard RAM relocated above a chip set memory hole.
|
FEC0 0000
|
4 KB
|
AddressRangeReserved
|
I/O APIC memory mapped I/O at FEC00000.
|
FEE0 0000
|
4 KB
|
AddressRangeReserved
|
Local APIC memory mapped I/O at FEE00000.
|
FFFF 0000
|
64 KB
|
AddressRangeReserved
|
Remapped System BIOS at end of address space.
|
14.6 Example: Operating System
Usage
The following code segment illustrates the algorithm to be
used when calling the Query System Address Map function. It is an
implementation example and uses non‑standard mechanisms.
E820Present = FALSE;
Reg.ebx = 0;
do {
Reg.eax = 0xE820;
Reg.es = SEGMENT (&Descriptor);
Reg.di = OFFSET (&Descriptor);
Reg.ecx = sizeof (Descriptor);
Reg.edx = 'SMAP';
_int( 15, regs );
if ((Regs.eflags & EFLAG_CARRY) ||
Regs.eax != 'SMAP') {
break;
}
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
.
.
.
}
15 Waking and Sleeping
ACPI defines a mechanism to transition the system between
the working state (G0) and a sleeping state (G1) or the soft-off (G2) state.
During transitions between the working and sleeping states, the context of the
user's operating environment is maintained. ACPI defines the quality of the G1
sleeping state by defining the system attributes of four types of ACPI sleeping
states (S1, S2, S3, and S4). Each sleeping state is defined to allow
implementations that can tradeoff cost, power, and wake latencies.
Additionally, ACPI defines the sleeping states such that an ACPI platform can
support multiple sleeping states, allowing the platform to transition into a
particular sleeping state for a predefined period of time and then transition
to a lower power/higher wake latency sleeping state (transitioning through the
G0 state)[15].
ACPI defines a programming model that provides a mechanism
for OSPM to initiate the entry into a sleeping or soft-off state (S1-S5); this
consists of a 3-bit field SLP_TYPx that indicates the type of sleep
state to enter, and a single control bit SLP_EN to start the sleeping process.
Note: Systems containing
processors without a hardware mechanism to place the processor in a low-power
state may additionally require the execution of appropriate native instructions
to place the processor in a low-power state after OSPM sets the SLP_EN bit
hardware may implement a number of low-power sleeping states and then associate
these states with the defined ACPI sleeping states (through the SLP_TYPx
fields). The ACPI system firmware creates a sleeping object associated with
each supported sleeping state (unsupported sleeping states are identified by
the lack of the sleeping object). Each sleeping object contains two constant
3-bit values that OSPM will program into the SLP_TYPa and SLP_TYPb fields (in
fixed register space).
ACPI also defines an alternate mechanism for entering and
exiting the S4 state that passes control to the BIOS to save and restore
platform context. Context ownership is similar in definition to the S3 state,
but hardware saves and restores the context of memory to non-volatile storage
(such as a disk drive), and OSPM treats this as an S4 state with implied
latency and power constraints. This alternate mechanism of entering the S4
state is referred to as the S4BIOS transition.
Prior to entering a sleeping state (S1-S4), OSPM will
execute OEM-specific AML/ASL code contained in the _PTS (Prepare To Sleep)
control method. One use of the _PTS control method is that it can indicate to
the embedded controller what sleeping state the system will enter when the
SLP_EN bit is set. The embedded controller can then respond by executing the
proper power-plane sequencing upon this bit being set.
Immediately prior to entering a system sleeping state, OSPM
will execute the _GTS (Going To Sleep) control method. _GTS allows ACPI system
firmware to perform any necessary system specific functions prior to entering a
system sleeping state.
Upon waking, OSPM will execute the _BFS (Back From Sleep)
control method. This allows ACPI system firmware to perform any necessary
system specific functions prior to returning control to OSPM. The _WAK (Wake) control method is then executed. This control
method again contains OEM-specific AML/ASL code. One use of the _WAK control
method requests OSPM to check the platform for any devices that might have been
added or removed from the system while the system was asleep. For example, a PC
Card controller might have had a PC Card added or removed, and because the
power to this device was off in the sleeping state, the status change event was
not generated.
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."
15.1 Sleeping States
The illustration below shows the transitions between the
working state, the sleeping states, and the Soft Off state.
Figure 15-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.
· 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) state–defined 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.)
ACPI-compatible 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 ACPI's 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).
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 low-power 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.
15.1.1 S1 Sleeping State
The S1 state is defined as a low wake-latency sleeping
state. In this state, all system context is preserved with the exception of CPU
caches. Before setting the SLP_EN bit, OSPM will flush the system caches
the platform supports the WBINVD instruction (as indicated by the WBINVD and
WBINVD_FLUSH flags in the FADT), OSPM will execute the WBINVD instruction
hardware is responsible for maintaining all other system context, which
includes the context of the CPU, memory, and chipset.
Examples of S1 sleeping state implementation alternatives
follow.
15.1.1.1 Example
1: S1 Sleeping State Implementation
This example references an IA processor that supports the
stop grant state through the assertion of the STPCLK# signal. When SLP_TYPx is
programmed to the S1 value (the OEM chooses a value, which is then placed in
the \_S1 object) and the SLP_ENx bit is subsequently set, the hardware can
implement an S1 state by asserting the STPCLK# signal to the processor, causing
it to enter the stop grant state.
In this case, the system clocks (PCI and CPU) are still
running. Any enabled wake event causes the hardware to de-assert the STPCLK#
signal to the processor whereby OSPM must first invalidate the CPU caches and
then transition back into the working state.
15.1.1.2 Example
2: S1 Sleeping State Implementation
When SLP_TYPx is programmed to the S1 value and the SLP_ENx
bit is subsequently set, the hardware will implement an S1 sleeping state
transition by doing the following:
1. Placing the processor into the stop grant state.
2. Stopping the processor's input clock, placing the processor into the
stop clock state.
3. Placing system memory into a self-refresh or suspend-refresh state.
Refresh is maintained by the memory itself or through some other reference
clock that is not stopped during the sleeping state.
4. Stopping all system clocks (asserts the standby signal to the system PLL
chip). Normally the RTC will continue running.
In this case, all clocks in the system have been stopped
(except for the RTC). Hardware must reverse the process (restarting system
clocks) upon any enabled wake event whereby OSPM must first invalidate the CPU
caches and then transition back into the working state.
15.1.2 S2 Sleeping State
The S2 state is defined as a low wake latency sleep state.
This state is similar to the S1 sleeping state where any context except for
system memory may be lost. Additionally, control starts from the processor's
reset vector after the wake event. Before setting the SLP_EN bit, OSPM will
flush the system caches. If the platform supports the WBINVD instruction (as
indicated by the WBINVD and WBINVD_FLUSH flags in the FADT), OSPM will execute
the WBINVD instruction. The hardware is responsible for maintaining chip set
and memory context. An example of an S2 sleeping state implementation follows.
15.1.2.1 Example:S2 Sleeping State Implementation
When the SLP_TYPx register(s) are programmed to the S2
value (found in the \_S2 object) and the SLP_EN bit is set, the hardware will
implement an S2 sleeping state transition by doing the following:
1. Stopping system clocks (the only running clock is the RTC).
2. Placing system memory into a self-refresh or suspend-refresh state.
3. Powering off the CPU and cache subsystem.
In this case, the CPU is reset upon detection of the wake
event; however, core logic and memory maintain their context. Execution control
starts from the CPU's boot vector. The BIOS is required to:
· Program
the initial boot configuration of the CPU (such as the CPU's MSR and MTRR
registers).
· Initialize
the cache controller to its initial boot size and configuration.
· Enable
the memory controller to accept memory accesses.
· Jump
to the waking vector.
15.1.3 S3 Sleeping State
The S3 state is defined as a low wake-latency sleep state.
From the software viewpoint, this state is functionally the same as the S2
state. The operational difference is that some Power Resources that may have
been left ON in the S2 state may not be available to the S3 state. As such, some
devices may be in a lower power state when the system is in S3 state than when
the system is in the S2 state. Similarly, some device wake events can function
in S2 but not S3. An example of an S3 sleeping state implementation follows.
15.1.3.1 Example:S3 Sleeping State Implementation
When the SLP_TYPx register(s) are programmed to the S3
value (found in the \_S3 object) and the SLP_EN bit is set, the hardware will
implement an S3 sleeping state transition by doing the following:
1. Placing the memory into a low-power auto-refresh or self-refresh state.
2. Devices that are maintaining memory isolating themselves from other
devices in the system.
3. Removing power from the system. At this point, only devices supporting
memory are powered (possibly partially powered). The only clock running in the
system is the RTC clock.
In this case, the wake event repowers the system and resets
most devices (depending on the implementation).
Execution control starts from the CPU's boot vector
BIOS is required to:
1. Program the initial boot configuration of the CPU (such as the MSR and
MTRR registers).
2. Initialize the cache controller to its initial boot size and
configuration.
3. Enable the memory controller to accept memory accesses.
4. Jump to the waking vector.
Notice that if the configuration of cache memory controller
is lost while the system is sleeping, the BIOS is required to reconfigure it to
either the pre-sleeping state or the initial boot state configuration. The BIOS
can store the configuration of the cache memory controller into the reserved
memory space, where it can then retrieve the values after waking. OSPM will
call the _PTS method once per session (prior to sleeping).
The BIOS is also responsible for restoring the memory
controller's configuration. If this configuration data is destroyed during the
S3 sleeping state, then the BIOS needs to store the pre-sleeping state or
initial boot state configuration in a non-volatile memory area (as with RTC
CMOS RAM) to enable it to restore the values during the waking process.
When OSPM re-enumerates buses coming out of the S3 sleeping
state, it will discover any devices that have been inserted or removed, and
configure devices as they are turned on.
15.1.4 S4 Sleeping State
The S4 sleeping state is the lowest-power, longest
wake-latency sleeping state supported by ACPI. In order to reduce power to a
minimum, it is assumed that the hardware platform has powered off all devices.
Because this is a sleeping state, the platform context is maintained. Depending
on how the transition into the S4 sleeping state occurs, the responsibility for
maintaining system context changes. S4 supports two entry mechanisms: OS
initiated and BIOS-initiated. The OSPM-initiated mechanism is similar to the
entry into the S1-S3 sleeping states; OSPM driver writes the SLP_TYPx fields
and sets the SLP_EN bit. The BIOS-initiated mechanism occurs by OSPM
transferring control to the BIOS by writing the S4BIOS_REQ value to the SMI_CMD
port.
In OSPM-initiated S4 sleeping state, OSPM is responsible
for saving all system context. Before entering the S4 state, OSPM will save
context of all memory with the exception of memory reported as type
AddressRangeReserved (see section 15, "System Address Map Interfaces," for more
information). Upon waking, OSPM will then restore the system context. When OSPM
re-enumerates buses coming out of the S4 sleeping state, it will discover any
devices that have come and gone, and configure devices as they are turned on.
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).
15.1.4.1 Operating
System-Initiated S4 Transition
If OSPM supports OSPM-initiated S4 transition, it will not
generate a BIOS-initiated S4 transition. Platforms that support the
BIOS-initiated S4 transition also support OSPM-initiated S4 transition.
OSPM-initiated S4 transition is initiated by OSPM by saving
system context, writing the appropriate values to the SLP_TYPx register(s), and
setting the SLP_EN bit. Upon exiting the S4 sleeping state, the BIOS restores
the chipset to its POST condition, updates the hardware signature (described
later in this section), and passes control to OSPM through a normal boot
process.
When the BIOS builds the ACPI tables, it generates a
hardware signature for the system. If the hardware configuration has changed
during an OS-initiated S4 transition, the BIOS updates the hardware signature
in the FACS table. A change in hardware configuration is defined to be any
change in the platform hardware that would cause the platform to fail when
trying to restore the S4 context; this hardware is normally limited to boot
devices. For example, changing the graphics adapter or hard disk controller
while in the S4 state should cause the hardware signature to change. On the
other hand, removing or adding a PC Card device from a PC Card slot should not
cause the hardware signature to change.
15.1.4.2 The S4BIOS Transition
The BIOS-initiated S4 transition begins with OSPM writing
the S4BIOS_REQ value into the SMI_CMD port (as specified in the FADT). Once
gaining control, the BIOS then saves the appropriate memory and chip set
context, and then places the platform into the S4 state (power off to all
devices).
In the FACS memory table, there is the S4BIOS_F bit that
indicates hardware support for the BIOS-initiated S4 transition. If the hardware
platform supports the S4BIOS state, it sets the S4BIOS_F flag within the FACS
memory structure prior to booting the OS. If the S4BIOS_F flag in the FACS
table is set, this indicates that OSPM can request the BIOS to transition the
platform into the S4BIOS sleeping state by writing the S4BIOS_REQ value (found
in the FADT) to the SMI_CMD port (identified by the SMI_CMD value in the FADT).
Upon waking the BIOS, software
restores memory context and jumps to the waking vector (similar to wake from an
S3 state). Coming out of the S4BIOS state, the BIOS must only configure boot
devices (so it can read the disk partition where it saved system context). When
OSPM re-enumerates buses coming out of the S4BIOS state, it will discover any
devices that have come and gone, and configure devices as they are turned on.
15.1.5 S5 Soft Off State
OSPM places the platform in the S5 soft off state to
achieve a logical off. Notice that the S5 state is not a sleeping state (it is a G2 state) and no context is saved by OSPM
or hardware but power may still be applied to parts of the platform in this
state and as such, it is not safe to disassemble. Also notice that from a
hardware perspective, the S4 and S5 states are nearly identical. When
initiated, the hardware will sequence the system to a state similar to the off
state. The hardware has no responsibility for maintaining any system context
(memory or I/O); however, it does allow a transition to the S0 state due to a
power button press or a Remote Start. Upon start-up, the BIOS performs a normal
power-on reset, loads the boot sector, and executes (but not the waking vector,
as all ACPI table context is lost when entering the S5 soft off state).
The _TTS control method allows the BIOS a mechanism for
performing some housekeeping, such as storing the targeted sleep state in a
"global" variable that is accessible by other control methods (such as _PS3 and
_DSW).
15.1.6 Transitioning from the
Working to the Sleeping State
On a transition of the system from the working to the
sleeping state, the following occurs:
1. OSPM decides (through a policy scheme) to place the system into the
sleeping state.
2. OSPM invokes the _TTS method to indicate the deepest possible system
state the system will transition to (1, 2, 3, or 4 representing S1, S2, S3, and
S4).
3. OSPM examines all devices enabled to wake the system and determines the
deepest possible sleeping state the system can enter to support the enabled
wake functions. The _PRW named object under each device is examined, as well as
the power resource object it points to.
4. OSPM places all device drivers into their respective Dx state. If the device is enabled for wake, it enters
the Dx state associated with the
wake capability. If the device is not enabled to wake the system, it enters the
D3 state.
5. OSPM executes the _PTS control method, passing an argument that
indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3,
and S4).
6. OSPM saves any other processor's context (other than the local
processor) to memory.
7. OSPM writes the waking vector into the FACS table in memory.
8. OSPM executes 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).
9. OSPM clears the WAK_STS in the PM1a_STS and PM1b_STS registers.
10. OSPM saves the local processor's context to memory.
11. OSPM flushes caches (only if entering S1, S2 or S3).
12. OSPM sets GPE enable registers to ensure that all appropriate wake
signals are armed.
13. If entering an S4 state using the S4BIOS mechanism, OSPM writes the
S4BIOS_REQ value (from the FADT) to the SMI_CMD port. This passes control to
the BIOS, which then transitions the platform into the S4BIOS state.
14. If not entering an S4BIOS state, then OSPM writes SLP_TYPa (from the
associated sleeping object) with the SLP_ENa bit set to the PM1a_CNT register.
15. OSPM writes SLP_TYPb with the SLP_EN bit set to the PM1b_CNT register.
16. On systems containing processors without a hardware mechanism to place
the processor in a low-power state, OSPM executes appropriate native
instructions to place the processor in a low-power state.
17. OSPM loops on the WAK_STS bit (in both the PM1a_CNT and PM1b_CNT
registers).
18. The system enters the specified sleeping state.
Note: this is
accomplished after step 14 or 15 above.
15.1.7 Transitioning from the
Working to the Soft Off State
On a transition of the system from the working to the soft
off state, the following occurs:
1. OSPM executes the _PTS control method, passing the argument 5.
2. OSPM prepares its components to shut down (flushing disk caches).
3. OSPM executes the _GTS control method, passing the argument 5.
4. OSPM writes SLP_TYPa (from the \_S5 object) with the SLP_ENa bit set to
the PM1a_CNT register.
5. OSPM writes SLP_TYPb (from the \_S5 object) with the SLP_ENb bit set to
the PM1b_CNT register.
6. The system enters the Soft Off state.
15.2 Flushing Caches
Before entering the S1, S2 or S3 sleeping states, OSPM is
responsible for flushing the system caches. ACPI provides a number of
mechanisms to flush system caches. These include:
· Using
a native instruction (for example, the IA32 WBINVD instruction) to flush and
invalidate platform caches.
WBINVD_FLUSH flag set (1) in the FADT indicates the system provides this
support level.
· Using
the IA32 instruction WBINVD to flush but not invalidate the platform caches.
WBINVD flag set (1) in the FADT indicates the system provides this support
level.
The manual flush mechanism has two caveats:
· Largest
cache is 1 MB in size (FLUSH_SIZE is a maximum value of 2 MB).
· No
victim caches (for which the manual flush algorithm is unreliable).
Processors with built-in victim caches will not support the
manual flush mechanism and are therefore required to support the WBINVD
mechanism to use the S2 or S3 state.
The manual cache-flushing mechanism relies on the two FADT
fields:
· FLUSH_SIZE.
> Indicates twice the size of the largest cache in
bytes.
· FLUSH_STRIDE.
> Indicates the smallest line size of the caches in
bytes.
The cache flush size value is typically twice the size of
the largest cache size, and the cache flush stride value is typically the size
of the smallest cache line size in the platform. OSPM will flush the system
caches by reading a contiguous block of memory indicated by the cache flush
size.
15.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 15-2
illustrates the flow of the boot-up software.
Figure 15-2 BIOS
Initialization
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 as a result of a hard or soft reset.
When executing from the power-on reset vector as a result
of a power-on sequence, a hard or soft reset, or waking from an S4 sleep
state, the platform firmware performs
complete hardware initialization; placing the system in a boot configuration.
The firmware then passes control to the operating system boot loader.
When executing from the power-on reset vector as a result
of waking from an S2 or S3 sleep state, the platform firmware performs only the
hardware initialization required to restore the system to either the state the
platform was in prior to the initial operating system boot, or to the pre-sleep
configuration state. In multiprocessor systems, non-boot processors should be
placed in the same state as prior to the initial operating system boot. The
platform firmware then passes control back to OSPM system by jumping to either
the Firmware_Waking_Vector or the X_Firmware_Waking_Vector in the FACS (see
table 5-12 for more information). The contents of operating system memory
contents may not be changed during the S2 or S3 sleep state.
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 doesn't
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
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
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.
15.3.1 Placing the System in ACPI
Mode
When a platform initializes from a cold boot (mechanical
off or from an S4 or S5 state), the hardware platform may be configured in a
legacy configuration. From these states, the BIOS software initializes the
computer as it would for a legacy operating system. When control is passed to
the operating system, OSPM will check the SCI_EN bit and if it is not set will
then enable ACPI mode by first finding the ACPI tables, and then by generating
a write of the ACPI_ENABLE value to the SMI_CMD port (as described in the
FADT). The hardware platform will set the SCI_EN bit to indicate to OSPM that
the hardware platform is now configured for ACPI.
Note: Before SCI is
enabled, no SCI interrupt can occur. Nor can any SCI interrupt occur
immediately after ACPI is on. The SCI interrupt can only be signaled after OSPM
has enabled one of the GPE/PM1 enable bits.
When the platform is waking from an S1, S2 or S3 state,
OSPM assumes the hardware is already in the ACPI mode and will not issue an
ACPI_ENABLE command to the SMI_CMD port.
15.3.2 BIOS Initialization of
Memory
During a power-on reset, an exit from an S4 sleeping state,
or an exit from an S5 soft-off state, the BIOS needs to initialize memory. This
section explains how the BIOS should configure memory for use by a number of
features including:
· ACPI
tables.
· BIOS
memory that wants to be saved across S4 sleeping sessions and should be cached.
· BIOS
memory that does not require saving and should be cached.
For example, the configuration of the platform's cache
controller requires an area of memory to store the configuration data. During
the wake sequence, the BIOS will re-enable the memory controller and can then
use its configuration data to reconfigure the cache controllers. To support
these three items, IA-PC-based systems contain system address map reporting
interfaces that return the following memory range types:
· ACPI
Reclaim Memory. Memory identified by the
BIOS that contains the ACPI tables. This memory can be any place above 8 MB and
contains the ACPI tables. When OSPM is finished using the ACPI tables, it is
free to reclaim this memory for system software use (application space).
· ACPI
Non-Volatile-Sleeping Memory (NVS). Memory
identified by the BIOS as being reserved by the BIOS for its use. OSPM is
required to tag this memory as cacheable, and to save and restore its image
before entering an S4 state. Except as directed by control methods, OSPM is not
allowed to use this physical memory. OSPM will call the _PTS control method
some time before entering a sleeping state, to allow the platform's AML code to
update this memory image before entering the sleeping state. After the system
awakes from an S4 state, OSPM will restore this memory area and call the _WAK
control method to enable the BIOS to reclaim its memory image.
Note: The memory
information returned from the system address map reporting interfaces should be
the same before and after an S4 sleep.
When the system is first booting, OSPM will invoke E820
interfaces on IA-PC-based legacy systems or the GetMemoryMap() interface on
EFI-enabled systems to obtain a system memory map (see section 15, "System
Address Map Interfaces," for more information). As an example, the following
memory map represents a typical IA-PC-based legacy platform's physical memory
map.
Figure 15-3 Example Physical Memory Map
The names and attributes of the different memory regions
are listed below:
· 0–640
KB. Compatibility Memory. Application
executable memory for an 8086 system.
· 640
KB–1 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
MB–8 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
MB–Top of Memory1. This area
contains memory to the "top of memory1" boundary. In this area, memory-mapped
I/O blocks are possible.
· Boot
Base–4 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
15-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.
Figure 15-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).
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.
15.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 file's 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.
Figure 15-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.
15.3.4 Exiting ACPI Mode
For machines that do not boot in ACPI mode, ACPI provides a
mechanism that enables the OS to disable ACPI. The following occurs:
1. OSPM unloads all ACPI drivers (including the ACPI driver).
2. OSPM disables all ACPI events.
3. OSPM finishes using all ACPI registers.
4. OSPM issues an I/O access to the port at the address contained in the
SMI_CMD field (in the FADT) with the value contained in the ACPI_DISABLE field
(in the FADT).
5. BIOS then remaps all SCI events to legacy events and resets the SCI_EN
bit.
6. Upon seeing the SCI_EN bit cleared, the ACPI OS enters the legacy OS
mode.
When and if the legacy OS returns control to the ACPI OS,
if the legacy OS has not maintained the ACPI tables (in reserved memory and
ACPI NVS memory), the ACPI OS will reboot the system to allow the BIOS to
re-initialize the tables.
16 Non-Uniform Memory Access (NUMA) Architecture Platforms
Systems employing a Non Uniform Memory Access (NUMA) architecture
contain collections of hardware resources including processors, memory, and I/O
buses, that comprise what is commonly known as a "NUMA node". Two or more NUMA
nodes are linked to each other via a high-speed interconnect. Processor
accesses to memory or I/O resources within the local NUMA node are generally
faster than processor accesses to memory or I/O resources outside of the local
NUMA node, accessed via the node interconnect. ACPI defines interfaces that
allow the platform to convey NUMA node topology information to OSPM both
statically at boot time and dynamically at run time as resources are added or
removed from the system.
16.1
NUMA Node
A conceptual model for a node in a NUMA configuration may
contain one or more of the following components:
· Processor
· Memory
· I/O Resources
· Networking, Storage
· Chipset
The components defined as part of the model are intended to
represent all possible components of a NUMA node. A specific node in an
implementation of a NUMA platform may not provide all of these components. At a
minimum, each node must have a chipset with an interface to the interconnect
between nodes.
The defining characteristic of a NUMA system is a coherent global
memory and / or I/O address space that can be accessed by all of the
processors. Hence, at least one node must have memory, at least one node must
have I/O resources and at least one node must have processors. Other than the
chipset, which must have components present on every node, each is
implementation dependent. In the ACPI name space, NUMA nodes are described as module
devices. See Section 9.12,"Module Device".
16.2
System Locality
A collection of components that are presented to OSPM as a
Symmetrical Multi-Processing (SMP) unit belong to the same System Locality,
also known as a Proximity Domain. The granularity of a System Locality is typically
at the NUMA Node level although the granularity can also be at the sub-NUMA
node level or the processor, memory and host bridge level. A System Locality is
reported to the OSPM using the _PXM method. If OSPM only needs to know a
near/far distinction among the System Localities, the _PXM method is
sufficient.
OSPM makes no assumptions about the proximity or nearness
of different proximity domains. The difference between two integers representing
separate proximity domains does not imply distance between the proximity
domains (in other words, proximity domain 1 is not assumed to be closer to
proximity domain 0 than proximity domain 6).
16.2.1 System Resource Affinity
Table Definition
This optional System Resource Affinity Table (SRAT)
provides the boot time description of the processor and memory ranges belonging
to a system locality. OSPM will consume the SRAT only at boot time. OSPM
should use _PXM for any devices that are hot-added into the system after boot
up.
The SRAT describes the system locality that all processors
and memory present in a system belong to at system boot. This includes memory
that can be hot-added (that is memory that can be added to the system while it
is running, without requiring a reboot). OSPM can use this information to optimize
the performance of NUMA architecture systems. For example, OSPM could utilize
this information to optimize allocation of memory resources and the scheduling
of software threads.
16.3
System Locality Distance Information
Optionally, OSPM may further optimize a NUMA architecture
system using information about the relative memory latency distances among the
System Localities. This may be useful if the distance between multiple system
localities is significantly different. In this case, a simple near/far
distinction may be insufficient. This information is contained in the optional System
Locality Information Table (SLIT) and is returned from the evaluation of the _SLI
object.
The SLIT is a matrix that describes the relative distances between
all System Localities. Support for the _PXM object is required for SLIT
System Locality as returned by the _PXM object is used as the row and column
indices of the matrix.
Implementation Note: The size of the SLIT table is determined by the largest _PXM value
used in the system. Hence, to minimize the size of the SLIT table, the _PXM
values assigned by the system firmware should be in the range 0, …, N-1, where
N is the number of System Localities. If _PXM values are not packed into this
range, the SLIT will still work, but more memory will have to be allocated to
store the "Entries" portion of the SLIT for the matrix.
The static SLIT table provides the boot time description of
the relative distances among all System Localities. For hot-added devices and dynamic
reconfiguration of the system localities, the _SLI object must be used for runtime
update.
The _SLI method is an optional object that provides the
runtime update of the relative distances from the System Locality i to all other System Localities in the system. Since
_SLI method is providing additional relative distance information among System
Localities, if implemented, it is provided alongside with the _PXM method.
16.3.1.1
Online Hot Plug
In the case of online addition, the Bus Check notification
(0x0) is performed on a device object to indicate to OSPM that it needs to
perform the Plug and Play re-enumeration operation on the device tree starting
from the point where it has been notified. OSPM needs to evaluate all _PXM
objects associated with the added System Localities, or _SLI objects if the
SLIT is present.
In the case of online deletion, OSPM needs to perform the
Plug and Play ejection operation when it receives the Eject Request
notification (0x03). OSPM needs to remove the relative distance information
from its internal data structure for the removed System Localities.
16.3.1.2
Impact to Existing Localities
Dynamic reconfiguration of the system may cause the
relative distance information (if the optional SLIT is present) to become
stale. If this occurs, the System Locality Information Update notification may
be generated by the platform to a device at a point on the device tree that
represents a System Locality. This indicates to OSPM that it needs to invoke
the _SLI objects associated with the System Localities on the device tree
starting from the point where it has been notified.
17 ACPI Source Language (ASL) Reference
This section formally defines the ACPI Source Language (ASL).
ASL is a source language for defining ACPI objects including writing ACPI
control methods. OEMs and BIOS developers define objects and write control
methods in ASL and then use a translator tool (compiler) to generate ACPI
Machine Language (AML) versions of the control methods. For a formal definition
of AML, see the ACPI Machine Language (AML) Specification, section 18, "ACPI
Machine Language Specification."
AML and ASL are different languages though they are closely related.
Every ACPI-compatible OS must support AML. A given user can
define some arbitrary source language (to replace ASL) and write a tool to
translate it to AML.
An OEM or BIOS vendor needs to write ASL and be able to
single-step AML for debugging. (Debuggers and similar tools are expected to be
AML-level tools, not source-level tools.) An ASL translator implementer must
understand how to read ASL and generate AML. An AML interpreter author must
understand how to execute AML.
This section has two parts:
· The
ASL grammar, which is the formal ASL specification and also serves as a quick
reference.
· A
full ASL reference, which includes for each ASL operator: the operator
invocation syntax, the type of each argument, and a description of the action
and use of the operator.
17.1 ASL Language Grammar
The purpose of this section is to state unambiguously the
grammar rules used by the syntax checker of an ASL compiler.
ASL statements declare objects. Each object has three
parts, two of which might not be present.
Object
:= ObjectType FixedList VariableList
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 {}.
17.1.1 ASL Grammar Notation
The notation used to express the ASL grammar is specified
in the following table.
Table 17‑ 1 ASL Grammar Notation
Notation Convention
|
Description
|
Example
|
Term := Term Term …
|
The term to the left of := can be expanded into the sequence
of terms on the right.
|
aterm := bterm cterm means that aterm can be expanded into the
two-term sequence of bterm followed by cterm.
|
Angle brackets (< > )
|
Used to group items.
|
<a b> | <c d> means either
a b or c d.
|
Arrow (=>)
|
Indicates required run-time reduction of an ASL argument to an
AML data type. Means "reduces to" or "evaluates to" at run-time.
|
"TermArg => Integer"
means that the argument must be an ASL TermArg that must resolve to an Integer
> data type when it is evaluated by an AML
interpreter.
|
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
|
Terms separated from each other by spaces form an ordered
list.
|
N/A
|
Word in bold
|
Denotes the name of a term in the ASL grammar, representing
any instance of such a term. ASL terms are not case-sensitive.
|
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 (' ')
|
Indicate constant characters.
|
'A'
|
0xdd
|
Refers to a byte value expressed as two hexadecimal digits.
|
0x21 means a value of hexadecimal 21, or decimal 37. Notice
that a value expressed in hexadecimal must start with a leading zero (0).
|
Dash character ( - )
|
Indicates a range.
|
1-9 means a single digit in the range 1 to 9 inclusive.
|
17.1.2 ASL Name and
Pathname Terms
LeadNameChar :=
'A'-'Z' | 'a'-'z' | '_'
DigitChar :=
'0'-'9'
NameChar :=
DigitChar | LeadNameChar
RootChar :=
'\'
ParentPrefixChar :=
'^'
PathSeparatorChar :=
'.'
CommaChar :=
','
SemicolonDelimiter :=
Nothing | ';'
NameSeg :=
<LeadNameChar> |
<LeadNameChar NameChar> |
<LeadNameChar NameChar NameChar> |
<LeadNameChar NameChar NameChar NameChar>
NameString
:=
<RootChar NamePath> | <ParentPrefixChar PrefixPath NamePath> |
NonEmptyNamePath
NamePath
:=
Nothing | <NameSeg NamePathTail>
NamePathTail
:=
Nothing | <PathSeparatorChar NameSeg NamePathTail>
NonEmptyNamePath
:=
NameSeg | <NameSeg NamePathTail>
PrefixPath
:=
Nothing | <ParentPrefixChar PrefixPath>
17.1.3 ASL Root and Secondary Terms
//
Root Term
ASLCode
:=
DefinitionBlockTerm
//
Major Terms
SuperName
:=
NameString | ArgTerm | LocalTerm | DebugTerm | Type6Opcode | UserTerm
Target
:=
Nothing | SuperName
TermArg
:=
Type2Opcode | DataObject | ArgTerm | LocalTerm | NameString
UserTerm
:=
NameString( //
NameString => Method
ArgList
) => Nothing | DataRefObject
//
List Terms
ArgList
:=
Nothing | <TermArg ArgListTail>
ArgListTail
:=
Nothing | <CommaChar TermArg ArgListTail>
ByteList
:=
Nothing | <ByteConstExpr ByteListTail>
ByteListTail
:=
Nothing | <CommaChar ByteConstExpr ByteListTail>
DWordList
:=
Nothing | <DWordConstExpr DWordListTail>
DWordListTail
:=
Nothing | <CommaChar DWordConstExpr DWordListTail>
FieldUnitList
:=
Nothing | <FieldUnit FieldUnitListTail>
FieldUnitListTail
:=
Nothing | <CommaChar FieldUnit FieldUnitListTail>
FieldUnit
:=
FieldUnitEntry | OffsetTerm | AccessAsTerm
FieldUnitEntry
:=
<Nothing | NameSeg> CommaChar Integer
ObjectList
:=
Nothing | <Object ObjectList>
Object
:=
CompilerDirective | NamedObject | NameSpaceModifier
PackageList
:=
Nothing | <PackageElement PackageListTail>
PackageListTail
:=
Nothing | <CommaChar PackageElement PackageListTail>
PackageElement
:=
DataObject | NameString
ParameterTypePackage
:=
ObjectTypeKeyword | {Nothing |
ParameterTypePackageList}
ParameterTypePackageList
:=
ObjectTypeKeyword | <ObjectTypeKeyword CommaChar
ParameterTypePackageList>
ParameterTypesPackage
:=
ObjectTypeKeyword | {Nothing |
ParameterTypesPackageList}
ParameterTypesPackageList
:=
ParameterTypePackage | <ParameterTypePackage CommaChar
ParameterTypesPackageList>
TermList
:=
Nothing | <Term SemicolonDelimiter TermList>
Term
:=
Object | Type1Opcode | Type2Opcode
//
Conditional Execution Terms
CaseTermList
:=
Nothing | CaseTerm | DefaultTerm DefaultTermList | CaseTerm CaseTermList
DefaultTermList
:=
Nothing | CaseTerm | CaseTerm DefaultTermList
IfElseTerm
:=
IfTerm ElseTerm
17.1.4 ASL Data and
Constant Terms
//
Numeric Value Terms
LeadDigitChar
:=
'1'-'9'
HexDigitChar :=
DigitChar | 'A'-'F' | 'a'-'f
lang=ES-MX>'
OctalDigitChar
:=
'0'-'7'
NullChar
:=
0x00
//
Data Terms
DataObject
:=
BufferData | PackageData | IntegerData | StringData
DataRefObject
:=
DataObject | ObjectReference | DDBHandle
ComputationalData
:=
BufferData | IntegerData | StringData
BufferData
:=
Type5Opcode | BufferTerm
IntegerData
:=
Type3Opcode | Integer | ConstTerm
PackageData
:=
PackageTerm
StringData
:=
Type4Opcode | String
//
Integer Terms
Integer
:=
DecimalConst | OctalConst | HexConst
DecimalConst
:=
LeadDigitChar | <DecimalConst DigitChar>
OctalConst
:=
'0' | <OctalConst OctalDigitChar>
HexConst
:=
<0x HexDigitChar> | <0X
HexDigitChar> | <HexConst
HexDigitChar>
ByteConst
:=
Integer => 0x00-0xFF
WordConst
:=
Integer => 0x0000-0xFFFF
DWordConst
:=
Integer => 0x00000000-0xFFFFFFFF
QWordConst
:=
Integer => 0x0000000000000000-0xFFFFFFFFFFFFFFFF
ByteConstExpr
:=
<Type3Opcode | ConstExprTerm | Integer> => ByteConst
WordConstExpr
:=
<Type3Opcode | ConstExprTerm | Integer> => WordConst
DwordConstExpr
:=
<Type3Opcode | ConstExprTerm | Integer> => DWordConst
QwordConstExpr
:=
<Type3Opcode | ConstExprTerm | Integer> => QWordConst
ConstTerm
:=
ConstExprTerm | Revision
ConstExprTerm
:=
Zero
| One
| Ones
//
String Terms
String
:=
'"' Utf8CharList '"'
Utf8CharList
:=
Nothing | <EscapeSequence Utf8CharList> | <Utf8Char Utf8CharList>
Utf8Char
:=
0x01-0x21 |
0x23-0x5B |
0x5D-0x7F |
0xC2-0xDF 0x80-0xBF |
0xE0 0xA0-0xBF 0x80-0xBF |
0xE1-0xEC 0x80-0xBF 0x80-0xBF |
0xED 0x80-0x9F 0x80-0xBF |
0xEE-0xEF 0x80-0xBF 0x80-0xBF |
0xF0 0x90-0xBF 0x80-0xBF 0x80-0xBF |
0xF1-0xF3 0x80-0xBF 0x80-0xBF 0x80-0xBF |
EscapeSequence
:=
SimpleEscapeSequence | OctalEscapeSequence | HexEscapeSequence
HexEscapeSequence
:=
\x HexDigitChar |
\x HexDigitChar HexDigitChar
SimpleEscapeSequence :=
\' | \" | \a
| \b | \f | \n | \r
lang=PT-BR> | \t | \v | \\
OctalEscapeSequence :=
\ OctalDigitChar |
\ OctalDigitChar OctalDigitChar |
\ OctalDigitChar OctalDigitChar OctalDigitChar
//
Miscellaneous Data Type Terms
DDBHandle
:=
Integer
ObjectReference
:=
Integer
Boolean
:=
True | False
True
:=
Ones
False
:=
Zero
17.1.5 ASL Opcode
Terms
CompilerDirective
:=
IncludeTerm | ExternalTerm
NamedObject
:=
BankFieldTerm | CreateBitFieldTerm | CreateByteFieldTerm | CreateDWordFieldTerm
| CreateFieldTerm | CreateQWordFieldTerm | CreateWordFieldTerm | DataRegionTerm
| DeviceTerm | EventTerm | FieldTerm | FunctionTerm | IndexFieldTerm |
MethodTerm | MutexTerm | OpRegionTerm | PowerResTerm | ProcessorTerm |
ThermalZoneTerm
NameSpaceModifier
:=
AliasTerm | NameTerm | ScopeTerm
Type1Opcode
:=
BreakTerm | BreakPointTerm | ContinueTerm | FatalTerm | IfElseTerm | LoadTerm |
NoOpTerm | NotifyTerm | ReleaseTerm | ResetTerm | ReturnTerm | SignalTerm |
SleepTerm | StallTerm | SwitchTerm | UnloadTerm | WhileTerm
A Type 1 opcode term does not return
a value and can only be used standalone on a line of ASL code. Since these
opcodes do not return a value they cannot be used as a term in an expression.
Type2Opcode
:=
AcquireTerm | AddTerm | AndTerm | ConcatTerm | ConcatResTerm | CondRefOfTerm |
CopyObjectTerm | DecTerm | DerefOfTerm | DivideTerm |FindSetLeftBitTerm |
FindSetRightBitTerm | FromBCDTerm | IncTerm | IndexTerm | LAndTerm | LEqualTerm
| LGreaterTerm | LGreaterEqualTerm | LLessTerm | LLessEqualTerm | LNotTerm |
LNotEqualTerm | LoadTableTerm | LOrTerm | MatchTerm | MidTerm |ModTerm |
MultiplyTerm | NAndTerm | NOrTerm | NotTerm | ObjectTypeTerm | OrTerm |
RefOfTerm | ShiftLeftTerm | ShiftRightTerm | SizeOfTerm | StoreTerm |
SubtractTerm | TimerTerm | ToBCDTerm | ToBufferTerm | ToDecimalStringTerm |
ToHexStringTerm | ToIntegerTerm | ToStringTerm | WaitTerm | XorTerm | UserTerm
A Type 2 opcode returns a value and
can be used in an expression.
Type3Opcode
:=
AddTerm | AndTerm | DecTerm | DerefOfTerm | DivideTerm | EISAIDTerm |
FindSetLeftBitTerm | FindSetRightBitTerm | FromBCDTerm | IncTerm | LAndTerm |
LEqualTerm | LGreaterTerm | LGreaterEqualTerm | LLessTerm | LLessEqualTerm |
LNotTerm | LNotEqualTerm | LOrTerm | MatchTerm | ModTerm | MultiplyTerm |
NAndTerm | NOrTerm | NotTerm | OrTerm | ShiftLeftTerm | ShiftRightTerm |
SubtractTerm | ToBCDTerm | ToIntegerTerm | XorTerm
The Type 3 opcodes are a subset of
Type 2 opcodes that return an Integer
value and can be used in an expression that evaluates to a constant. These
opcodes may be evaluated at ASL compile-time. To ensure that these opcodes will
evaluate to a constant, the following rules apply: The term cannot have a
destination (target) operand, and must have either a Type3Opcode, Type4Opcode,
Type5Opcode, ConstExprTerm, Integer, BufferTerm, Package, or String for all
arguments.
Type4Opcode
:=
ConcatTerm | DerefOfTerm | MidTerm | ToDecimalStringTerm | ToHexStringTerm |
ToStringTerm
The Type 4 opcodes are a subset of
Type 2 opcodes that return a String
value and can be used in an expression that evaluates to a constant. These
opcodes may be evaluated at ASL compile-time. To ensure that these opcodes will
evaluate to a constant, the following rules apply: The term cannot have a
destination (target) operand, and must have either a Type3Opcode, Type4Opcode,
Type5Opcode, ConstExprTerm, Integer, BufferTerm, Package, or String for all
arguments.
Type5Opcode
:=
ConcatTerm | ConcatResTerm | DerefOfTerm | MidTerm | ResourceTemplateTerm |
ToBufferTerm | ToUUIDTerm | UnicodeTerm
The Type 5 opcodes are a subset of
Type 2 opcodes that return a Buffer
value and can be used in an expression that evaluates to a constant. These
opcodes may be evaluated at ASL compile-time. To ensure that these opcodes will
evaluate to a constant, the following rules apply: The term cannot have a
destination (target) operand, and must have either a Type3Opcode, Type4Opcode,
Type5Opcode, ConstExprTerm, Integer, BufferTerm, Package, or String for all
arguments.
Type6Opcode
:=
RefOfTerm | DerefOfTerm | IndexTerm | UserTerm
17.1.6 ASL Primary
(Terminal) Terms
AccessAsTerm
:=
AccessAs (
AccessType, //
AccessTypeKeyword
AccessAttribute //
Nothing | ByteConstExpr | AccessAttribKeyword
)
AcquireTerm
:=
Acquire
(
SyncObject, //
SuperName => Mutex
TimeoutValue //
WordConstExpr
) => Boolean //
True means timed-out
AddTerm
:=
Add
(
Addend1, //
TermArg => Integer
Addend2, //
TermArg => Integer
Result //
Target
) => Integer
AliasTerm
:=
Alias
(
SourceObject, //
NameString
AliasObject //
NameString
)
AndTerm
:=
And
(
Source1, //
TermArg => Integer
Source2, //
TermArg => Integer
Result //
Target
) => Integer
ArgTerm
:=
Arg0 | Arg1 | Arg2
| Arg3 | Arg4 | Arg5
| Arg6
BankFieldTerm
:=
BankField
(
RegionName, //
NameString => OperationRegion
BankName, //
NameString => FieldUnit
BankValue, //
TermArg => Integer
AccessType, //
AccessTypeKeyword
LockRule, //
LockRuleKeyword
UpdateRule //
UpdateRuleKeyword
) {FieldUnitList}
BreakTerm
:=
Break
BreakPointTerm
:=
BreakPoint
BufferTerm
:=
Buffer
(
BuffSize //
Nothing | TermArg => Integer
) {StringData | ByteList} => Buffer
CaseTerm
:=
Case (
Value //
DataObject
) {TermList}
ConcatTerm :=
Concatenate (
Source1, //
TermArg => ComputationalData
Source2, //
TermArg => ComputationalData
Result // Target
) => ComputationalData
ConcatResTerm
:=
ConcatenateResTemplate
(
Source1, //
TermArg => Buffer
Source2, //
TermArg => Buffer
Result //
Target
) => Buffer
CondRefOfTerm
:=
CondRefOf
(
Source, //
SuperName
Destination // Target
) => Boolean
CopyObjectTerm
:=
CopyObject
(
Source, //
TermArg => DataRefObject
Result, // NameString | LocalTerm | ArgTerm
) => DataRefObject
ContinueTerm
:=
Continue
CreateBitFieldTerm
:=
CreateBitField
(
SourceBuffer, //
TermArg => Buffer
BitIndex, //
TermArg => Integer
BitFieldName //
NameString
)
CreateByteFieldTerm
:=
CreateByteField
(
SourceBuffer, //
TermArg => Buffer
ByteIndex, //
TermArg => Integer
ByteFieldName //
NameString
)
CreateDWordFieldTerm
:=
CreateDWordField
(
SourceBuffer, //
TermArg => Buffer
ByteIndex, //
TermArg => Integer
DWordFieldName //
NameString
)
CreateFieldTerm
:=
CreateField
(
SourceBuffer, //
TermArg => Buffer
BitIndex, //
TermArg => Integer
NumBits, //
TermArg => Integer
FieldName //
NameString
)
CreateQWordFieldTerm
:=
CreateQWordField
(
SourceBuffer, //
TermArg => Buffer
ByteIndex, //
TermArg => Integer
QWordFieldName //
NameString
)
CreateWordFieldTerm
:=
CreateWordField
(
SourceBuffer, //
TermArg => Buffer
ByteIndex, //
TermArg => Integer
WordFieldName //
NameString
)
DataRegionTerm :=
DataTableRegion (
RegionName, // NameString
SignatureString, // TermArg => String
OemIDString, // TermArg => String
OemTableIDString //
TermArg => String
)
DebugTerm :=
Debug
DecTerm :=
Decrement (
Minuend //
SuperName
) => Integer
DefaultTerm :=
Default {TermList}
lang=NO-BOK>DefinitionBlockTerm :=
DefinitionBlock
class="GrammarASLCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCharCChar"> (
AMLFileName, //
StringData
TableSignature, //
StringData
ComplianceRevision, //
ByteConst
OEMID, //
StringData
TableID, //
StringData
OEMRevision //
DWordConst
) {ObjectList}
DerefOfTerm
:=
DerefOf
(
Source //
TermArg => ObjectReference
//
ObjectReference is an object
produced by terms such
// as Index, RefOf or CondRefOf
style='font-style:normal'>.
) => DataRefObject
DeviceTerm
:=
Device
(
DeviceName //
NameString
) {ObjectList}
DivideTerm
:=
Divide
(
Dividend, //
TermArg => Integer
Divisor, //
TermArg => Integer
Remainder, //
Target
Result //
Target
) => Integer //
Returns Result
EISAIDTerm
:=
EISAID
(
EisaIdString //
StringData
) => DWordConst
ElseTerm
:=
Else {TermList}
> | ElseIfTerm | Nothing
ElseIfTerm
:=
ElseIf
(
Predicate //
TermArg => Integer
) {TermList} ElseTerm
EventTerm
:=
Event
(
EventName //
NameString
)
ExternalTerm
:=
External
(
ObjName, //
NameString
ObjType, // Nothing | ObjectTypeKeyword
ResultType, // Nothing | ParameterTypePackage
ParameterTypes // Nothing | ParameterTypesPackage
)
FatalTerm
:=
Fatal
(
Type, //
ByteConstExpr
Code, // DWordConstExpr
Arg // TermArg => Integer
)
FieldTerm
:=
Field (
RegionName, //
NameString => OperationRegion
AccessType, //
AccessTypeKeyword
LockRule, //
LockRuleKeyword
UpdateRule //
UpdateRuleKeyword
) {FieldUnitList}
FindSetLeftBitTerm
:=
FindSetLeftBit
(
Source, //
TermArg => Integer
Result //
Target
) => Integer
FindSetRightBitTerm
:=
FindSetRightBit
(
Source, //
TermArg => Integer
Result //
Target
) => Integer
FromBCDTerm
:=
FromBCD
(
BCDValue, //
TermArg => Integer
Result //
Target
) => Integer
FunctionTerm
:=
Function (
FunctionName, //
NameString
ReturnType, // Nothing | ParameterTypePackage
ParameterTypes // Nothing | ParameterTypesPackage
) {TermList}
IfTerm
:=
If
(
Predicate //
TermArg => Integer
) {TermList}
IncludeTerm
:=
Include
(
FilePathName //
StringData
)
IncTerm
:=
Increment
(
Addend //
SuperName
) => Integer
IndexTerm
:=
Index
(
Source, //
TermArg => <String | Buffer | PackageTerm>
Index, //
TermArg => Integer
Destination // Target
) => ObjectReference
IndexFieldTerm
:=
IndexField
(
IndexName, //
NameString => FieldUnit
DataName, //
NameString => FieldUnit
AccessType, //
AccessTypeKeyword
LockRule, //
LockRuleKeyword
UpdateRule //
UpdateRuleKeyword
) {FieldUnitList}
LAndTerm
:=
LAnd
(
Source1, //
TermArg => Integer
Source2 //
TermArg => Integer
) => Boolean
LEqualTerm
:=
LEqual
(
Source1, //
TermArg => ComputationalData
Source2 //
TermArg => ComputationalData
) => Boolean
LGreaterTerm
:=
LGreater
(
Source1, //
TermArg => ComputationalData
Source2 //
TermArg => ComputationalData
) => Boolean
LGreaterEqualTerm
:=
LGreaterEqual
(
Source1, //
TermArg => ComputationalData
Source2 //
TermArg => ComputationalData
) => Boolean
LLessTerm
:=
LLess
(
Source1, //
TermArg => ComputationalData
Source2 //
TermArg => ComputationalData
) => Boolean
LLessEqualTerm
:=
LLessEqual
(
Source1, //
TermArg => ComputationalData
Source2 //
TermArg => ComputationalData
) => Boolean
LNotTerm
:=
LNot
(
Source, //
TermArg => Integer
) => Boolean
LNotEqualTerm
:=
LNotEqual
(
Source1, //
TermArg => ComputationalData
Source2 //
TermArg => ComputationalData
) => Boolean
LoadTerm
:=
Load
(
Object, //
NameString
DDBHandle //
SuperName
)
LoadTableTerm
:=
LoadTable
(
SignatureString, //
TermArg => String
OemIDString, //
TermArg => String
OemTableIDString, //
TermArg => String
RootPathString, //
Nothing | TermArg => String
ParameterPathString, //
Nothing | TermArg => String
ParameterData //
Nothing | TermArg => DataRefObject
) => DDBHandle
LocalTerm
:=
Local0 | Local1 | Local2 | Local3 | Local4 | Local5 | Local6 | Local7
LOrTerm
:=
LOr
(
Source1, //
TermArg => Integer
Source2 //
TermArg => Integer
) => Boolean
MatchTerm
:=
Match
(
SearchPackage, //
TermArg => Package
Op1, // MatchOpKeyword
MatchObject1, //
TermArg => ComputationalData
Op2, // MatchOpKeyword
MatchObject2, // TermArg => ComputationalData
StartIndex //
TermArg => Integer
) => <Ones |
Integer>
MethodTerm
:=
Method
(
MethodName, //
NameString
NumArgs, //
Nothing | ByteConstExpr
SerializeRule, // Nothing | SerializeRuleKeyword
SyncLevel, //
Nothing | ByteConstExpr
ReturnType, // Nothing | ParameterTypePackage
ParameterTypes //
Nothing | ParameterTypesPackage
) {TermList}
MidTerm
:=
Mid
(
Source, //
TermArg => <Buffer | String>
Index, //
TermArg => Integer
Length, //
TermArg => Integer
Result // Target
) => <Buffer | String>
ModTerm
:=
Mod
(
Dividend, //
TermArg => Integer
Divisor, //
TermArg => Integer
Result //
Target
) => Integer //
Returns Result
MultiplyTerm
:=
Multiply
(
Multiplicand, //
TermArg => Integer
Multiplier, //
TermArg => Integer
Result //
Target
) => Integer
MutexTerm
:=
Mutex
(
MutexName, //
NameString
SyncLevel //
ByteConstExpr
)
NameTerm
:=
Name
(
ObjectName, //
NameString
Object //
DataObject
)
NAndTerm
:=
NAnd
(
Source1, //
TermArg => Integer
Source2, //
TermArg => Integer
Result //
Target
) => Integer
NoOpTerm
:=
NoOp
NOrTerm
:=
NOr
(
Source1, //
TermArg => Integer
Source2, //
TermArg => Integer
Result //
Target
) => Integer
NotifyTerm
:=
Notify
(
Object, //
SuperName => <ThermalZone | Processor | Device>
NotificationValue // TermArg => Integer
)
NotTerm
:=
Not
(
Source, //
TermArg => Integer
Result //
Target
) => Integer
ObjectTypeTerm
:=
ObjectType
(
Object //
SuperName
) => Integer
OffsetTerm
:=
Offset (
ByteOffset //
IntegerData
)
OpRegionTerm
:=
OperationRegion
(
RegionName, //
NameString
RegionSpace, // RegionSpaceKeyword
Offset, // TermArg => Integer
Length //
TermArg => Integer
)
OrTerm
:=
Or
(
Source1, //
TermArg => Integer
Source2, //
TermArg => Integer
Result //
Target
) => Integer
PackageTerm
:=
Package
(
NumElements //
Nothing | ByteConstExpr | TermArg => Integer
) {PackageList} => Package
PowerResTerm
:=
PowerResource
(
ResourceName, //
NameString
SystemLevel, // ByteConstExpr
ResourceOrder //
WordConstExpr
) {ObjectList}
ProcessorTerm
:=
Processor
(
ProcessorName, //
NameString
ProcessorID, //
ByteConstExpr
PBlockAddress, //
DwordConstExpr | Nothing (=0)
PblockLength // ByteConstExpr | Nothing (=0)
) {ObjectList}
RefOfTerm
:=
RefOf
(
Object //
SuperName
) => ObjectReference
ReleaseTerm
:=
Release
(
SyncObject //
SuperName
)
ResetTerm
:=
Reset
(
SyncObject //
SuperName
)
ReturnTerm
:=
Return
(
Arg //
Nothing | TermArg => DataRefObject
)
ScopeTerm
:=
Scope
(
Location //
NameString
) {ObjectList}
ShiftLeftTerm
:=
ShiftLeft
(
Source, //
TermArg => Integer
ShiftCount, //
TermArg => Integer
Result //
Target
) => Integer
ShiftRightTerm
:=
ShiftRight
(
Source, //
TermArg => Integer
ShiftCount, //
TermArg => Integer
Result //
Target
) => Integer
SignalTerm
:=
Signal
(
SyncObject //
SuperName
)
SizeOfTerm
:=
SizeOf
(
DataObject //
SuperName => <String | Buffer | Package>
) => Integer
SleepTerm
:=
Sleep
(
MilliSeconds //
TermArg => Integer
)
StallTerm
:=
Stall
(
MicroSeconds //
TermArg => Integer
)
StoreTerm
:=
Store
(
Source, //
TermArg => DataRefObject
Destination //
SuperName
) => DataRefObject
SubtractTerm
:=
Subtract
(
Minuend, //
TermArg => Integer
Subtrahend, //
TermArg => Integer
Result //
Target
) => Integer
SwitchTerm
:=
Switch
(
Predicate //
TermArg => ComputationalData
) {CaseTermList}
ThermalZoneTerm
:=
ThermalZone
(
ThermalZoneName //
NameString
) {ObjectList}
TimerTerm :=
Timer => Integer
ToBCDTerm :=
ToBCD (
Value, //
TermArg => Integer
Result //
Target
) => Integer
ToBufferTerm :=
ToBuffer (
Data, //
TermArg => ComputationalData
Result //
Target
) => ComputationalData
ToDecimalStringTerm :=
ToDecimalString (
Data, //
TermArg => ComputationalData
Result //
Target
) => String
ToHexStringTerm :=
ToHexString (
Data, //
TermArg => ComputationalData
Result //
Target
) => String
ToIntegerTerm
:=
ToInteger
(
Data, //
TermArg => ComputationalData
Result //
Target
) => Integer
ToStringTerm
:=
ToString
(
Source, //
TermArg => Buffer
Length, // Nothing | TermArg => Integer
Result //
Target
) => String
ToUUIDTerm
:=
ToUUID (
String //
StringData
) => Buffer
UnicodeTerm
:=
Unicode
(
String //
StringData
) => Buffer
UnloadTerm
:=
Unload
(
DDBHandle //
SuperName
)
WaitTerm
:=
Wait
(
SyncObject, //
SuperName => Event
TimeoutValue //
TermArg => Integer
) => Boolean //
True means timed-out
WhileTerm
:=
While
(
Predicate //
TermArg => Integer
) {TermList}
XOrTerm
:=
XOr
(
Source1, //
TermArg => Integer
Source2, //
TermArg => Integer
Result //
Target
) => Integer
17.1.7 ASL
Parameter Keyword Terms
AccessAttribKeyword
:=
SMBQuick | SMBSendReceive | SMBByte | SMBWord |
SMBBlock | SMBProcessCall | SMBBlockProcessCall
> // Note: Used for SMBus
BufferAcc only.
AccessTypeKeyword
:=
AnyAcc | ByteAcc | WordAcc | DWordAcc |
QWordAcc | BufferAcc
AddressKeyword
:=
AddressRangeMemory |
AddressRangeReserved |
AddressRangeNVS |
AddressRangeACPI
AddressSpaceKeyword
:=
RegionSpaceKeyword | FFixedHW
BusMasterKeyword
:=
BusMaster | NotBusMaster
DecodeKeyword
:=
SubDecode | PosDecode
DMATypeKeyword
:=
Compatibility | TypeA | TypeB |
TypeF
InterruptTypeKeyword
:=
Edge | Level
InterruptLevel
:=
ActiveHigh | ActiveLow
IODecodeKeyword
:=
Decode16 | Decode10
LockRuleKeyword
:=
Lock | NoLock
MatchOpKeyword
:=
MTR | MEQ | MLE
| MLT | MGE | MGT
MaxKeyword
:=
MaxFixed | MaxNotFixed
MemTypeKeyword
:=
Cacheable | WriteCombining | Prefetchable | NonCacheable
MinKeyword
:=
MinFixed | MinNotFixed
ObjectTypeKeyword
:=
UnknownObj | IntObj | StrObj | BuffObj |
PkgObj | FieldUnitObj | DeviceObj | EventObj |
MethodObj | MutexObj | OpRegionObj | PowerResObj |
ProcessorObj | ThermalZoneObj | BuffFieldObj | DDBHandleObj
RangeTypeKeyword
:=
ISAOnlyRanges |
NonISAOnlyRanges | EntireRange
ReadWriteKeyword
:=
ReadWrite | ReadOnly
RegionSpaceKeyword
:=
UserDefRegionSpace | SystemIO |
SystemMemory | PCI_Config | EmbeddedControl
>| SMBus |
SystemCMOS | PciBarTarget
ResourceTypeKeyword
:=
ResourceConsumer |
ResourceProducer
SerializeRuleKeyword
:=
Serialized | NotSerialized
ShareTypeKeyword
:=
Shared | Exclusive
TranslationKeyword
:=
SparseTranslation |
DenseTranslation
TypeKeyword
:=
TypeTranslation | TypeStatic
UpdateRuleKeyword
:=
Preserve | WriteAsOnes | WriteAsZeros
UserDefRegionSpace
:=
IntegerData => 0x80 - 0xFF
XferTypeKeyword
:=
Transfer8 | Transfer16 | Transfer8_16
17.1.8 ASL Resource
Template Terms
ResourceTemplateTerm
:=
ResourceTemplate () {ResourceMacroList}
=> Buffer
ResourceMacroList
:=
Nothing | <ResourceMacroTerm ResourceMacroList>
ResourceMacroTerm
:=
DMATerm | DWordIOTerm | DWordMemoryTerm | DWordSpaceTerm | EndDependentFnTerm |
ExtendedIOTerm | ExtendedMemoryTerm | ExtendedSpaceTerm | FixedIOTerm |
InterruptTerm | IOTerm | IRQNoFlagsTerm | IRQTerm | Memory24Term |
Memory32FixedTerm | Memory32Term | QWordIOTerm | QWordMemoryTerm |
QWordSpaceTerm | RegisterTerm | StartDependentFnTerm |
StartDependentFnNoPriTerm | VendorLongTerm | VendorShortTerm |
WordBusNumberTerm | WordIOTerm | WordSpaceTerm
DMATerm
:=
DMA
(
DMAType, //
DMATypeKeyword (_TYP)
BusMaster, //
BusMasterKeyword (_BM)
XferType, //
XferTypeKeyword (_SIZ)
DescriptorName //
Nothing | NameString
) {ByteList} //
List of channels (0-7 bytes)
DWordIOTerm
:=
DWordIO
(
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
RangeType, //
Nothing (EntireRange) | RangeTypeKeyword (_RNG)
AddressGranularity, //
DWordConstExpr (_GRA)
MinAddress, //
DWordConstExpr (_MIN)
MaxAddress, //
DWordConstExpr (_MAX)
AddressTranslation, // DWordConstExpr (_TRA)
AddressLength, // DWordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName, //
Nothing | NameString
TranslationType, //
Nothing | TypeKeyword (_TTP)
TranslationDensity //
Nothing | TranslationKeyword (_TRS)
)
DWordMemoryTerm
:=
DWordMemory
(
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
MemType, // Nothing (NonCacheable) | MemTypeKeyword (_MEM)
ReadWriteType, // ReadWriteKeyword (_RW)
AddressGranularity, //
DWordConstExpr (_GRA)
MinAddress, //
DWordConstExpr (_MIN)
MaxAddress, //
DWordConstExpr (_MAX)
AddressTranslation, // DWordConstExpr (_TRA)
AddressLength, // DWordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName, //
Nothing | NameString
AddressRange, //
Nothing | AddressKeyword (_MTP)
MemoryType //
Nothing | TypeKeyword (_TTP)
)
DWordSpaceTerm
:=
DWordSpace
(
ResourceType, //
ByteConstExpr (_RT), 0xC0
– 0xFF
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
TypeSpecificFlags, // ByteConstExpr (_TSF)
AddressGranularity, //
DWordConstExpr (_GRA)
MinAddress, //
DWordConstExpr (_MIN)
MaxAddress, //
DWordConstExpr (_MAX)
AddressTranslation, // DWordConstExpr (_TRA)
AddressLength, // DWordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName //
Nothing | NameString
)
EndDependentFnTerm
:=
EndDependentFn
()
ExtendedIOTerm
:=
ExtendedIO (
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
RangeType, //
Nothing (EntireRange) | RangeTypeKeyword (_RNG)
AddressGranularity, //
QWordConstExpr (_GRA)
MinAddress, //
QWordConstExpr (_MIN)
MaxAddress, //
QWordConstExpr (_MAX)
AddressTranslation, // QWordConstExpr (_TRA)
AddressLength, // QWordConstExpr (_LEN)
TypeSpecificAttributes, // Nothing | QWordConstExpr
DescriptorName, //
Nothing | NameString
TranslationType, //
Nothing | TypeKeyword (_TTP)
TranslationDensity //
Nothing | TranslationKeyword (_TRS)
)
ExtendedMemoryTerm
:=
ExtendedMemory (
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
MemType, // Nothing (NonCacheable) | MemTypeKeyword (_MEM)
ReadWriteType, // ReadWriteKeyword (_RW)
AddressGranularity, //
QWordConstExpr (_GRA)
MinAddress, //
QWordConstExpr (_MIN)
MaxAddress, //
QWordConstExpr (_MAX)
AddressTranslation, // QWordConstExpr (_TRA)
AddressLength, // QWordConstExpr (_LEN)
TypeSpecificAttributes, // Nothing | QWordConstExpr
DescriptorName, //
Nothing | NameString
AddressRange, //
Nothing | AddressKeyword (_MTP)
MemoryType //
Nothing | TypeKeyword (_TTP)
)
ExtendedSpaceTerm
:=
ExtendedSpace (
ResourceType, //
ByteConstExpr (_RT), 0xC0
– 0xFF
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
TypeSpecificFlags, // ByteConstExpr (_TSF)
AddressGranularity, //
QWordConstExpr (_GRA)
MinAddress, //
QWordConstExpr (_MIN)
MaxAddress, //
QWordConstExpr (_MAX)
AddressTranslation, // QWordConstExpr (_TRA)
AddressLength, // QWordConstExpr (_LEN)
TypeSpecificAttributes, // Nothing | QWordConstExpr
DescriptorName //
Nothing | NameString
)
FixedIOTerm
:=
FixedIO
(
AddressBase, //
WordConstExpr (_BAS)
RangeLength, //
ByteConstExpr (_LEN)
DescriptorName //
Nothing | NameString
)
InterruptTerm
:=
Interrupt
(
ResourceType, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
InterruptType, // InterruptTypeKeyword (_LL, _HE)
InterruptLevel, //
InterruptLevelKeyword (_LL, _HE)
ShareType, //
Nothing (Exclusive) ShareTypeKeyword (_SHR)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName //
Nothing | NameString
) {DWordList} //
list of interrupts (_INT)
IOTerm
:=
IO
(
IODecode, //
IODecodeKeyword (_DEC)
MinAddress, //
WordConstExpr (_MIN)
MaxAddress, //
WordConstExpr (_MAX)
Alignment, //
ByteConstExpr (_ALN)
RangeLength, //
ByteConstExpr (_LEN)
DescriptorName //
Nothing | NameString
)
IRQNoFlagsTerm
:=
IRQNoFlags
(
DescriptorName //
Nothing | NameString
) {ByteList} //
list of interrupts (0-15 bytes)
IRQTerm
:=
IRQ
(
InterruptType, //
InterruptTypeKeyword (_LL, _HE)
InterruptLevel, //
InterruptLevelKeyword (_LL, _HE)
ShareType, //
Nothing (Exclusive) | ShareTypeKeyword (_SHR)
DescriptorName //
Nothing | NameString
) {ByteList} //
list of interrupts (0-15 bytes)
Memory24Term
:=
Memory24
(
ReadWriteType, //
ReadWriteKeyword (_RW)
MinAddress[23:8], //
WordConstExpr (_MIN)
MaxAddress[23:8], //
WordConstExpr (_MAX)
Alignment, //
WordConstExpr (_ALN)
RangeLength, //
WordConstExpr (_LEN)
DescriptorName //
Nothing | NameString
)
Memory32FixedTerm
:=
Memory32Fixed
(
ReadWriteType, //
ReadWriteKeyword (_RW)
AddressBase, //
DWordConstExpr (_BAS)
RangeLength, //
DWordConstExpr (_LEN)
DescriptorName //
Nothing | NameString
)
Memory32Term
:=
Memory32
(
ReadWriteType, //
ReadWriteKeyword (_RW)
MinAddress, //
DWordConstExpr (_MIN)
MaxAddress, //
DWordConstExpr (_MAX)
Alignment, //
DWordConstExpr (_ALN)
RangeLength, //
DWordConstExpr (_LEN)
DescriptorName //
Nothing | NameString
)
QWordIOTerm
:=
QWordIO
(
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
RangeType, //
Nothing (EntireRange) | RangeTypeKeyword (_RNG)
AddressGranularity, //
QWordConstExpr (_GRA)
MinAddress, //
QWordConstExpr (_MIN)
MaxAddress, //
QWordConstExpr (_MAX)
AddressTranslation, // QWordConstExpr (_TRA)
AddressLength, // QWordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName, //
Nothing | NameString
TranslationType, //
Nothing | TypeKeyword (_TTP)
TranslationDensity //
Nothing | TranslationKeyword (_TRS)
)
QWordMemoryTerm
:=
QWordMemory
(
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
MemType, // Nothing (NonCacheable) | MemTypeKeyword (_MEM)
ReadWriteType, // ReadWriteKeyword (_RW)
AddressGranularity, //
QWordConstExpr (_GRA)
MinAddress, //
QWordConstExpr (_MIN)
MaxAddress, //
QWordConstExpr (_MAX)
AddressTranslation, // QWordConstExpr (_TRA)
AddressLength, // QWordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName, //
Nothing | NameString
AddressRange, //
Nothing | AddressKeyword (_MTP)
MemoryType //
Nothing | TypeKeyword (_TTP)
)
QWordSpaceTerm
:=
QWordSpace
(
ResourceType, //
ByteConstExpr (_RT), 0xC0
– 0xFF
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
TypeSpecificFlags, // ByteConstExpr (_TSF)
AddressGranularity, //
QWordConstExpr (_GRA)
MinAddress, //
QWordConstExpr (_MIN)
MaxAddress, //
QWordConstExpr (_MAX)
AddressTranslation, // QWordConstExpr (_TRA)
AddressLength, // QWordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName //
Nothing | NameString
)
RegisterTerm
:=
Register
(
AddressSpaceID, //
AddressSpaceKeyword (_ASI)
RegisterBitWidth, //
ByteConstExpr (_RBW)
RegisterOffset, //
ByteConstExpr (_RBO)
RegisterAddress, //
QWordConstExpr (_ADR)
AccessSize, // ByteConstExpr (_ASZ)
DescriptorName //
Nothing | NameString
)
StartDependentFnTerm
:=
StartDependentFn
(
CompatPriority, //
ByteConstExpr (0-2)
PerfRobustPriority // ByteConstExpr (0-2)
) {ResourceMacroList}
StartDependentFnNoPriTerm
:=
StartDependentFnNoPri
() {ResourceMacroList}
VendorLongTerm
:=
VendorLong
(
DescriptorName //
Nothing | NameString
) {ByteList}
VendorShortTerm
:=
VendorShort
(
DescriptorName //
Nothing | NameString
) {ByteList} //
Up to 7 bytes
WordBusNumberTerm
:=
WordBusNumber
(
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
AddressGranularity, //
WordConstExpr (_GRA)
MinAddress, //
WordConstExpr (_MIN)
MaxAddress, //
WordConstExpr (_MAX)
AddressTranslation, // WordConstExpr (_TRA)
AddressLength, // WordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName //
Nothing | NameString
)
WordIOTerm
:=
WordIO
(
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
RangeType, //
Nothing (EntireRange) | RangeTypeKeyword (_RNG)
AddressGranularity, //
WordConstExpr (_GRA)
MinAddress, //
WordConstExpr (_MIN)
MaxAddress, //
WordConstExpr (_MAX)
AddressTranslation, // WordConstExpr (_TRA)
AddressLength, // WordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName, //
Nothing | NameString
TranslationType, //
Nothing | TypeKeyword (_TTP)
TranslationDensity //
Nothing | TranslationKeyword (_TRS)
)
WordSpaceTerm
:=
WordSpace
(
ResourceType, //
ByteConstExpr (_RT), 0xC0
– 0xFF
ResourceUsage, //
Nothing (ResourceConsumer)| ResourceTypeKeyword
Decode, // Nothing (PosDecode) | DecodeKeyword (_DEC)
MinType, //
Nothing (MinNotFixed) | MinKeyword (_MIF)
MaxType, // Nothing (MaxNotFixed) | MaxKeyword (_MAF)
TypeSpecificFlags, // ByteConstExpr (_TSF)
AddressGranularity, //
WordConstExpr (_GRA)
MinAddress, //
WordConstExpr (_MIN)
MaxAddress, //
WordConstExpr (_MAX)
AddressTranslation, // WordConstExpr (_TRA)
AddressLength, // WordConstExpr (_LEN)
ResourceSourceIndex, //
Nothing | ByteConstExpr
ResourceSource, // Nothing | StringData
DescriptorName //
Nothing | NameString
)
17.2 ASL Concepts
This reference section is for developers who are writing
ASL code while developing definition blocks for platforms.
17.2.1 ASL Names
This section describes how to encode object names using ASL.
The following table lists the characters legal in any
position in an ASL object name. ASL names are not case-sensitive and will be
converted to upper case.
Table 17‑2 Named Object Reference Encodings
Value
|
Description
|
Title
|
0x41-0x5A, 0x5F, 0x61-0x7A
|
Lead character of name
('A'–'Z', '_' , 'a'–'z')
|
LeadNameChar
|
0x30-0x39, 0x41-0x5A,
0x5F, 0x61-0x7A
|
Non-lead (trailing) character of name
('A'–'Z', '_', 'a'–'z', '0'–'9')
|
NameChar
|
The following table lists the
name modifiers that can be prefixed to an ASL name.
Table 17‑3 Definition Block Name Modifier Encodings
|
Description
|
NamePrefix :=
|
Followed by …
|
5C
|
Namespace root ('\')
|
RootPrefix
|
Name
|
5E
|
Parent namespace ('^')
|
ParentPrefix
|
ParentPrefix or Name
|
17.2.1.1 _T_x Reserved Object Names
The ACPI specification reserves object names with the
prefix _T_ for internal use by the ASL compiler. The ASL compiler may, for
example, use these objects to store temporary values when implementing
translation of complicated control structures into AML. The ASL compiler must
declare _T_x objects normally (using
Name) and must not define them more than once within the same scope.
17.2.2 ASL Literal
Constants
This section describes how to encode integer and string
constants using ASL.
17.2.2.1 Integers
DigitChar :=
'0'-'9'
LeadDigitChar := '1'-'class=StyleGrammarCharCharBoldCharChar>9' OctalDigitChar := '0'-'class=StyleGrammarCharCharBoldCharChar>7'
HexDigitChar :=
DigitChar | 'A'-'F' | 'class=StyleGrammarCharCharBoldCharChar>a'-'f'
Integer :=
DecimalConst | OctalConst | HexConst
DecimalConst :=
LeadDigitChar | <DecimalConst DigitChar>
OctalConst :=
'0' | <OctalConst
OctalDigitChar>
HexConst :=
<0x HexDigitChar> |
<0X HexDigitChar> |
<HexConst HexDigitChar>
ByteConst :=
Integer => 0x00-0xFF
WordConst :=
Integer => 0x0000-0xFFFF
DWordConst :=
Integer => 0x00000000-0xFFFFFFFF
QWordConst :=
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.
17.2.2.2 Strings
String :=
'"' Utf8CharList '"'
Utf8CharList :=
Nothing | <EscapeSequence Utf8CharList> | <Utf8Char Utf8CharList>
Utf8Char :=
0x01-0x21 |
0x23-0x5B
|
0x5D-0x7F
|
0xC2-0xDF
0x80-0xBF |
0xE0
0xA0-0xBF 0x80-0xBF |
0xE1-0xEC
0x80-0xBF 0x80-0xBF |
0xED
0x80-0x9F 0x80-0xBF |
0xEE-0xEF
0x80-0xBF 0x80-0xBF |
0xF0
0x90-0xBF 0x80-0xBF 0x80-0xBF |
0xF1-0xF3
0x80-0xBF 0x80-0xBF 0x80-0xBF |
0xF4
0x80-0x8F 0x80-0xBF 0x80-0xBF
EscapeSeq :=
SimpleEscapeSeq | OctalEscapeSeq | HexEscapeSeq
SimpleEscapeSeq := \' | \" | \a | \b | \f
| \n | \r | \t
| \v | \\
OctalEscapeSeq := \ OctalDigitChar |
\
OctalDigitChar
OctalDigitChar |
\
OctalDigitChar
OctalDigitChar OctalDigitChar
HexEscapeSeq :=
\x HexDigitChar
|
\x HexDigitChar HexDigit
lang=PT-BR>Char
NullChar :=
0x00
String literals consist of zero or more ASCII characters
surrounded by double quotation marks ("). 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, a null
character is appended.
Strings in the source file may be encoded using the UTF-8
encoding scheme as defined in the Unicode 4.0 specification. UTF-8 is a
byte-oriented encoding scheme, where some characters take a single byte and
others take multiple bytes. The ASCII character values 0x01-0x7F take up
exactly one byte.
However, only one operator currently supports UTF-8
strings: Unicode. Since string literals are defined to contain only non-null
character values, both Hex and Octal escape sequence values must be non-null
values in the ASCII range 0x01 through 0xFF. For arbitrary byte data (outside
the range of ASCII values), the Buffer
object should be used instead.
Since the backslash is used as the escape character and
also the namespace root prefix, any string literals that are to contain a fully
qualified namepath from the root of the namespace must use the double backslash
to indicate this:
Name (_EJD, "\\_SB.PCI0.DOCK1")
The double backslash is only required within quoted string
literals.
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:
Table 17‑4 ASL Escape Sequences
Escape Sequence
|
ASCII Character
|
\a
|
0x07 (BEL)
|
\b
|
0x08 (BS)
|
\f
|
0x0C (FF)
|
\n
|
0x0A (LF)
|
\r
|
0x0D (CR)
|
\t
|
0x09 (TAB)
|
\v
|
0x0B (VT)
|
\"
|
0x22 (")
|
\' |
0x27 (')
|
\\
|
0x5C (\)
|
Since literal strings are read-only constants, the
following ASL statement (for example) is not supported:
Store ("ABC", "DEF")
However, the following sequence of statements is supported:
Name (STR, "DEF")
...
Store ("ABC", STR)
17.2.3 ASL Resource Templates
ASL includes some macros for creating resource descriptors.
The ResourceTemplate macro creates a Buffer in which resource descriptor macros
can be listed. The ResourceTemplate macro automatically generates an End
descriptor and calculates the checksum for the resource template. The format
for the ResourceTemplate macro is as follows:
ResourceTemplate ()
{
// List of resource macros
}
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:
Name (PRS0, 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 at run-time (i.e., during a method
execution.) 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.
The offset returned by a reference to a resource descriptor
field name is either in units of bytes (for 8-, 16-, 32-, and 64-bit field
widths) or in bits (for all other field widths). In all cases, the returned
offset is the integer offset (in either bytes or bits) of the name from the
first byte (offset 0) of the parent resource template.
For example, given the above resource template, the
following code changes the minimum and maximum addresses for the I/O descriptor
named IO2:
CreateWordField (PRS0, IO2._MIN, IMIN)
Store (0xA000, IMIN)
CreateWordField (PRS0, IO2._MAX, IMAX)
Store (0xB000, IMAX)
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.
17.2.4 ASL Macros
The ASL compiler supports some built in macros to assist in
various ASL coding operations. The following table lists some of the supported
directives and an explanation of their function.
Table 17-5 Example
ASL Built-in Macros
ASL Statement
|
Description
|
AccessAs
(AccessType, AccessAttribute)
|
Used in a Fieldlist
parameter to supply the Access Type and Access Attributes of the remaining
FieldUnits within the list (or until another AccessType macro is
encountered.)
|
Offset (ByteOffset)
|
Used in a FieldList parameter
to supply the byte offset of
the next defined field within its parent region. This can be used instead of
defining the bit lengths that need to be skipped. All offsets are defined
from beginning to end of a region.
|
EISAID (TextID)
|
Macro that converts the 7-character text argument into its
corresponding 4-byte numeric EISA ID encoding. This can be used when
declaring IDs for devices that are EISA IDs.
|
ResourceTemplate ()
|
Macro used to supply Plug and Play resource descriptor
information in human readable form, which is then translated into the
appropriate binary Plug and Play resource descriptor encodings. For more
information about resource descriptor encodings, see section 6.4, "Resource
Data Types for ACPI."
|
ToUUID (AsciiString)
|
Macro will convert an ASCII string to a 128-bit buffer.
|
Unicode (StringData)
|
Macro that converts an ASCII string to a Unicode string
contained in a buffer.
|
17.2.5 ASL Data Types
ASL provides a wide variety of data types and operators
that manipulate data. It also provides mechanisms for both explicit and
implicit conversion between the data types when used with ASL operators.
The table below describes each of the available data types.
Table 17-6 Summary of ASL Data Types
|
ASL Data Type
|
Description
|
[Uninitialized]
|
No assigned type or value. This is
the type of all control method LocalX variables and unused ArgX variables at
the beginning of method execution, as well as all uninitialized Package
elements. Uninitialized objects must be initialized (via Store or
CopyObject) before they may be used as source operands in ASL expressions.
|
Buffer
|
An array of bytes. Uninitialized
elements are zero by default.
|
Buffer Field
|
Portion of a buffer created using
CreateBitField, CreateByteField, CreateWordField, CreateQWordField,
CreateField, or returned by the Index operator.
|
DDB Handle
|
Definition block handle returned
by the Load operator
|
Debug Object
|
Debug output object. Formats an
object and prints it to the system debug port. Has no effect if debugging is
not active.
|
Device
|
Device or bus object
|
Event
|
Event synchronization object
|
Field Unit (within an Operation
Region)
|
Portion of an address space, bit-aligned
and of one-bit granularity. Created using Field, BankField, or IndexField.
|
Integer
|
An n-bit little-endian unsigned integer.
In ACPI 1.0 this was at least 32 bits. In ACPI 2.0 and later, this is 64
bits.
|
Integer Constant
|
Created by the ASL terms "Zero",
"One", "Ones", and "Revision".
|
Method
|
Control Method (Executable AML
function)
|
Mutex
|
Mutex synchronization object
|
Object Reference
|
Reference to an object created
using the RefOf, Index, or CondRefOf operators
|
Operation Region
|
Operation Region (A region within
an Address Space)
|
Package
|
Collection of ASL objects with a fixed number of elements (up
to 255).
|
Power Resource
|
Power Resource description object
|
Processor
|
Processor description object
|
String
|
Null-terminated ASCII string.
|
Thermal Zone
|
Thermal Zone description object
|
Compatibility Note:
The ability to store and manipulate object references was first introduced in ACPI
2.0. In ACPI 1.0 references could not be stored in variables, passed as parameters
or returned from functions.
17.2.5.1 Data Type Conversion Overview
ASL
provides two mechanisms to convert objects from one data type to another data
type at run-time (during execution of the AML interpreter). The first
mechanism, Explicit Data Type Conversion, allows
the use of explicit ASL operators to convert an object to a different data
type. The second mechanism, Implicit Data Type Conversion, is invoked by the AML interpreter when it is
necessary to convert a data object to an expected data type before it is used
or stored.
The
following general rules apply to data type conversions:
· Input parameters are always
subject to implicit data type conversion (also known as implicit source operand
conversion) whenever the operand type does not match the expected input type.
· Output (target) parameters for all
operators except the explicit data conversion operators are subject to implicit
data type conversion (also known as implicit result object conversion) whenever
the target is an existing named object or named field that is of a different
type than the object to be stored.
· Output parameters for the explicit
data conversion operators, as well as output parameters that refer to a method
local or argument (LocalX or ArgX) are not subject to implicit type conversion.
Both of these mechanisms (explicit and implicit conversion)
are described in detail in the sections that follow.
17.2.5.2 Explicit Data Type Conversions
The following ASL operators are provided to explicitly convert an object from one data type to another:
· EISAID Converts a 7-character text argument into its
corresponding 4-byte numeric EISA ID encoding.
· FromBCD Convert
an Integer to a BCD Integer
· ToBCD Convert
a BCD Integer to a standard binary Integer.
· ToBuffer Convert
an Integer, String, or Buffer to an object of type Buffer
· ToDecimalString Convert
an Integer, String, or Buffer to an object of type String. The string contains
the ASCII representation of the decimal value of the source operand.
· ToHexString Convert
an Integer, String, or Buffer to an object of type String. The string contains
the ASCII representation of the hexadecimal value of the source operand.
· ToInteger Convert
an Integer, String, or Buffer to an object of type Integer.
· ToString Copy
directly and convert a Buffer to an object of type String.
· ToUUID Convert an ASCII string to a UUID Buffer.
The following ASL operators are provided to copy and transfer
objects:
· CopyObject Explicitly
store a copy of the operand object to the target name. No implicit type
conversion is performed. (This operator is used to avoid the implicit
conversion inherent in the ASL Store operator.)
· Store Store
a copy of the operand object to the target name. Implicit conversion is
performed if the target name is of a fixed data type (see below). However,
Stores to method locals and arguments do not perform implicit conversion and
are therefore the same as using CopyObject.
17.2.5.3 Implicit Data Type Conversions
Automatic or Implicit
type conversions can take place at two different times during the execution of
an ASL operator. First, it may be necessary to convert one or more of the
source operands to the data type(s) expected by the ASL operator. Second, the
result of the operation may require conversion before it is stored into the
destination. (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.)
Such data conversions
are performed by an AML interpreter during execution of AML code and are known
collectively as Implicit Operand Conversions. As described briefly above, there are two
different types of implicit operand conversion:
1. Conversion of a source
operand from a mismatched data type to the correct data type required by an ASL
operator, called Implicit Source Conversion. This conversion occurs when a source operand
must be converted to the operand type expected by the operator. Any or all of
the source operands may be converted in this manner before the execution of the
ASL operator can proceed.
2. Conversion of the result of
an operation to the existing type of a target operand before it is stored into
the target operand, called Implicit Result Conversion. This conversion occurs when the target is a fixed
type such as a named object or a field. When storing to a method Local or Arg,
no conversion is required because these data types are of variable type (the
store simply overwrites any existing object and the existing type).
17.2.5.4 Implicit Source Operand Conversion
During the execution of
an ASL operator, each source operand is processed by the AML interpreter as
follows:
·style='font:70%'> If the operand is of the type
expected by the operator, no conversion is necessary.
·style='font:70%'> If the operand type is incorrect,
attempt to convert it to the proper type.
·style='font:70%'> For the Concatenate operator and
logical operators (LEqual, LGreater, LGreaterEqual, LLess, LLessEqual, and
LNotEqual), the data type of the first operand dictates the required type of
the second operand, and for Concatenate only, the type of the result object.
(The second operator is implicitly converted, if necessary, to match the type
of the first operand.)
·style='font:70%'> If conversion is impossible, abort
the running control method and issue a fatal error.
An implicit source conversion will be attempted anytime a source operand
contains a data type that is different that the type expected by the operator.
For example:
Store
("5678", Local1)
Add
(0x1234, Local1, BUF1)
In the Add statement
above, Local1 contains a
String object and must undergo conversion to an Integer object before the Add
operation can proceed.
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.
The table below describes the source operand conversions available
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)
The Concatenate operator 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 17-7,
the highest priority conversion is to Integer. Therefore, both of the following
objects will be converted to Integers:
XYZ (0x05040302)
MNOP (0x31, 0x32, 0x33,
0x34)
And will then be joined together and the resulting type and
value will be:
Buffer (0x02, 0x03, 0x04, 0x05, 0x31,
0x32, 0x33, 0x34)
17.2.5.5 Implicit Result Object Conversion
For all ASL operators that generate and store a result
value (including the Store operator), the result object is processed and stored
by the AML interpreter as follows:
·style='font:70%'> If the ASL operator is one of the explicit
> conversion operators (ToString,
ToInteger, etc., and the CopyObject operator), no conversion is performed. (In other
words, the result object is stored directly to the target and completely
overwrites any existing object already stored at the target.)
·style='font:70%'> If the target is a method local or
argument (LocalX or ArgX), no conversion is performed and the result is stored
directly to the target.
·style='font:70%'> If the target is a fixed type such as
a named object or field object, an attempt is made to convert the source to the
existing target type before storing.
·style='font:70%'> If conversion is impossible, abort
the running control method and issue a fatal error.
An implicit result conversion can occur anytime the result of an operator
is stored into an object that is of a fixed type. For example:
Name
(BUF1, Buffer (10))
Add
(0x1234, 0x789A, BUF1)
Since BUF1 is a named
object of fixed type Buffer,
the Integer result of the Add operation must be converted to a Buffer before it
is stored into BUF1.
17.2.5.6 Data Types and Type Conversions
The following table lists the available ASL data types and
the available data type conversions (if any) for each. The entry for each
data type is fully cross-referenced, showing both the types to which the object
may be converted as well as all other types that may be converted to the data
type.
The allowable conversions apply to both explicit and
implicit conversions.
Table 17‑7 Data Types and Type Conversions
|
ASL Data Type
|
Can be implicitly or explicitly converted to these
Data Types: (In priority order)
|
Can be implicitly or explicitly converted from these
Data Types:
|
|
[Uninitialized]
|
None. Causes a fatal error when used as a source operand in
any ASL statement.
|
Integer, String, Buffer, Package, DDB Handle, Object Reference
|
|
Buffer
|
Integer, String, Debug Object
|
Integer, String
|
|
Buffer Field
|
Integer, Buffer, String, Debug Object
|
Integer, Buffer, String
|
|
DDB Handle
|
Integer, Debug Object
|
Integer
|
|
Debug Object
|
None. Causes a fatal error when used as a source operand in
any ASL statement.
|
Integer, String, Buffer, Package, Field Unit, Buffer Field,
DDB Handle
|
|
Device
|
None
|
None
|
|
Event
|
None
|
None
|
|
Field Unit (within an Operation Region)
|
Integer, Buffer, String, Debug Object
|
Integer, Buffer, String
|
|
Integer
|
Buffer, Buffer Field, DDB Handle, Field Unit, String, Debug
Object
|
Buffer, String
|
|
Integer Constant
|
Integer, Debug Object
|
None. Also, storing any object to a constant is a no-op, not
an error.
|
|
Method
|
None
|
None
|
|
Mutex
|
None
|
None
|
|
Object Reference
|
None
|
None
|
|
Operation Region
|
None
|
None
|
|
Package
|
Debug Object
|
None
|
|
String
|
Integer, Buffer, Debug Object
|
Integer, Buffer
|
|
Power Resource
|
None
|
None
|
|
Processor
|
None
|
None
|
|
Thermal Zone
|
None
|
None
|
|
17.2.5.7 Data Type Conversion Rules
The following table presents the detailed data conversion
rules for each of the allowable data type conversions. These conversion rules
are implemented by the AML Interpreter and apply to all conversion types
— explicit conversions, implicit source conversions, and implicit result
conversions.
Table 17-8 Object Conversion Rules
|
To convert from an object of this Data Type
|
To an object of this Data Type
|
This action is performed by the AML Interpreter:
|
Buffer
|
Buffer Field
|
The contents of the buffer are copied to the Buffer Field
the 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: This conversion was first introduced in
ACPI 2.0. The behavior in ACPI 1.0 was undefined.
|
Debug Object
|
Each buffer byte is displayed as a hexadecimal integer,
delimited by spaces and/or commas.
|
Field Unit
|
The entire contents of the buffer are copied to the Field
Unit. If the buffer is larger (in bits) than the size of the Field Unit, it
is broken into pieces and completely written to the Field Unit, lower chunks
first. If the buffer (or the last piece of the buffer, if broken up) is
smaller than the size of the Field Unit, it is zero extended before being
written.
|
Integer
|
If no integer object exists, a new integer is created
contents of the buffer are copied to the Integer, starting with the
least-significant bit and continuing until the buffer has been completely
copied — up to the maximum number of bits in an Integer. The size of an
Integer is indicated by the Definition Block table header's Revision field. A
Revision field value less than 2 indicates that the size of an Integer is
32-bits. A value greater than or equal to 2 signifies that the size of an
Integer is 64-bits. If the buffer is smaller than the size of an integer, it
is zero extended. If the buffer is larger than the size of an integer, it is
truncated.
|
String
|
If no string object exists, a new string is created. If the
string already exists, it is completely overwritten and truncated or extended
to accommodate the converted buffer exactly.The entire contents of the buffer
are converted to a string of two-character hexadecimal numbers, each
separated by a space.
|
Buffer Field
|
[See the Integer and Buffer Rules]
|
If the Buffer Field is smaller than or equal to the size of an
Integer (in bits), it will be treated as an Integer. Otherwise, it will be
treated as a Buffer. The size of an Integer is indicated by the Definition
Block table header's Revision field. A Revision field value less than 2
indicates that the size of an Integer is 32-bits. A value greater than or
equal to 2 signifies that the size of an Integer is 64-bits. (See the
conversion rules for the Integer and Buffer data types.)
|
DDB Handle
|
[See the Integer Rule]
|
The object is treated as an Integer (See conversion rules for
the Integer data type.)
|
Field Unit
|
[See the Integer and Buffer Rules]
|
If the Field Unit is smaller than or equal to the size of an
Integer (in bits), it will be treated as an Integer. If the Field Unit is
larger than the size of an Integer, it will be treated as a Buffer. The size
of an Integer is indicated by the Definition Block table header's Revision
field. A Revision field value less than 2 indicates that the size of an
Integer is 32-bits. A value greater than or equal to 2 signifies that the
size of an Integer is 64-bits. (See the conversion rules for the Integer and
Buffer data types.)
|
Integer
|
Buffer
|
If no buffer object exists, a new buffer object is created
based on the size of the integer (4 bytes for 32-bit integers and 8 bytes for
64-bit integers). If a buffer object already exists, the Integer
overwrites the entire Buffer object. 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 bits than the size of the buffer,
the Integer is zero-extended to fill the entire buffer.
|
Buffer Field
|
The Integer overwrites the entire Buffer Field. 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: This conversion was first introduced in
ACPI 2.0. The behavior in ACPI 1.0 was undefined.
|
Debug Object
|
The integer is displayed as a hexadecimal value.
|
Field Unit
|
The Integer overwrites the entire Field Unit. 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.
|
String
|
If no string object exists, a new string object is created
based on the size of the integer (8 characters for 32-bit integers and 16
characters for 64-bit integers). If the string already exists, it is
completely overwritten and truncated or extended to accommodate the converted
integer exactly. In either case, the entire integer is converted to a string
of hexadecimal ASCII characters.
|
Package
|
Package
|
If no package object exists, a new package object is created.
If the package already exists, it is completely overwritten and truncated or
extended to accommodate the source package exactly. Any and all existing valid
(non-null) package elements of the target package are deleted, and the entire
contents of the source package are copied into the target package.
|
Debug Object
|
Each element of the package is displayed based on its type.
|
String
|
Buffer
|
If no buffer object exists, a new buffer object is created
a buffer object already exists, it is completely overwritten. If the string
is longer than the buffer, the string is truncated before copying. If the
string is shorter than the buffer, the remaining buffer bytes are set to zero.
In either case, the string is treated as a buffer, with each ASCII string
character copied to one buffer byte, including the null terminator.
|
Buffer Field
|
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: This conversion was first introduced in
ACPI 2.0. The behavior in ACPI 1.0 was undefined.
|
Debug Object
|
Each string character is displayed as an ASCII character.
|
Field Unit
|
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 are lost. If the Field Unit is greater than
eight bits, then the additional bits are zeroed.
|
Integer
|
If no integer object exists, a new integer is created
integer is initialized to the value zero and the ASCII string is interpreted
as a hexadecimal constant. Each string character is interpreted as a
hexadecimal value ('0'-'9', 'A'-'F', 'a'-'f'), starting with the first
character as the most significant digit, and ending with the first
non-hexadecimal character, end-of-string, or when the size of an integer is
reached (8 characters for 32-bit integers and 16 characters for 64-bit
integers). Note: the first non-hex character terminates the conversion
without error, and a "0x" prefix is not allowed.
|
17.2.5.8 Rules for Storing and Copying Objects
The table below lists the actions performed when storing objects to different
types of named targets. ASL provides the following types of "store"
operations:
· The Store operator is used to explicitly store an object to a
location, with implicit conversion support of the source object.
· 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.
· The CopyObject operator is used to explicitly store a copy of an
object to a location, with no implicit conversion support.
Table 17-9 Object Storing and Copying
Rules
When Storing an object of any data type to this type of
Target location
|
This action is performed by the Store operator or
any ASL operator with a Target operand:
|
This action is performed by the CopyObject
operator:
|
Method ArgX variable
|
The object is copied to the destination with no conversion
applied, with one exception. If the ArgX contains an Object Reference, an
automatic de-reference occurs and the object is copied to the target of the
Object Reference instead of overwriting the contents of ArgX
|
Method LocalX variable
|
The object is copied to the destination with no conversion
applied. Even if LocalX contains an Object Reference, it is overwritten.
|
Field Unit or Buffer Field
|
The object is copied to the destination after implicit result
conversion is applied
|
Fields permanently retain their type and cannot be changed.
Therefore, CopyObject can only be used to copy an object of type Integer or
Buffer to fields.
|
Named data object
|
The object is copied to the destination after implicit result
conversion is applied to match the existing type of the named location
|
The object and type are copied to the named location.
|
17.2.5.9 Rules for Reading and Writing Objects
In the descriptions below, read operations always return
the actual object, not a copy of the object in order that constructs of the
form:
Add
(Local1, Local2, Local3)
do not create unnecessary copies of Local1 or Local2.
Also, this behavior enables the call-by-reference semantics of control method
invocation.
17.2.5.9.1 ArgX Objects
1) Read from ArgX parameters
§ ObjectReference -Automatic dereference, return the target of the reference. Use of DeRefOf
returns the same.
§ Buffer – Return the
Buffer. Can create an Index, Field, or Reference to the buffer.
§ Package – Return
the Package. Can create an Index or Reference to the package.
§ All other
object types – Return the object.
Example method invocation for the table below:
MTHD
(RefOf (Obj), Buf, Pkg, Obj)
Table 17-10 Reading from ArgX Objects
Parameter
|
MTHD ArgX Type
|
Read operation on ArgX
|
Result of read
|
RefOf (Obj),
|
Reference to object Obj
|
Store (Arg0, …)
CopyObject (Arg0, …)
DeRefOf (Arg0)
|
Obj
Obj
Obj
|
Buf,
|
Buffer
|
Store (Arg1, …)
CopyObject (Arg1, …)
Index (Arg1, …)
Field (Arg1, …)
|
Buf
Buf
Index (Buf)
Field (Buf)
|
Pkg
|
Package
|
Store (Arg2, …)
CopyObject (Arg2, …)
Index (Arg2, …)
|
Pkg
Pkg
Index (Pkg)
|
Obj
|
All other object types
|
Store (Arg3, …)
CopyObject (Arg3, …)
|
Obj
Obj
|
2) Store to ArgX parameters
§ ObjectReference objects -Automatic dereference, copy the object and overwrite the final target.
§ All other
object types- Copy the object and
overwrite the ArgX variable. (Direct writes to buffer or package ArgX
parameters will also simply overwrite ArgX)
Table 17-11 Writing to ArgX Objects
Current type of ArgX
|
Object to be written
|
Write operation on ArgX
|
Result of write (in ArgX)
|
RefOf (OldObj)
|
Obj
(Any type)
|
Store (…, ArgX)
CopyObject (…, ArgX)
|
RefOf (copy of Obj)
RefOf (copy of Obj)
|
All other object types
|
Obj
(Any type)
|
Store (…, ArgX)
CopyObject (…, ArgX)
|
Copy of Obj
Copy of Obj
|
Note: RefOf (ArgX) returns a reference to ArgX.
17.2.5.9.2 LocalX Objects
1) Read from LocalX variables
§ ObjectReference - If
performing a DeRefOf return the target of the reference. Otherwise, return the
reference.
§ All other
object types - Return a the object
Table 17-12 Reading from LocalX Objects
Current LocalX Type
|
Read operation on LocalX
|
Result of read
|
RefOf (Obj)
|
Store (LocalX, …)
CopyObject (LocalX, …)
DeRefOf (LocalX)
|
RefOf (Obj)
RefOf (Obj)
Obj
|
Obj (All other types)
|
Store (LocalX, …)
CopyObject (LocalX, …)
|
Obj
Obj
|
2) Store to LocalX variables
§ All object types - Delete
any existing object in LocalX first, then store a copy of the object.
Table 17-13 Writing to LocalX Objects
Current LocalX Type
|
Object to be written
|
Write operation on LocalX
|
Result of write (in LocalX)
|
All object types
|
Obj
(Any type)
|
Store (…, LocalX)
CopyObject (…, LocalX)
|
Copy of Obj
Copy of Obj
|
17.2.5.9.3 Named Objects
1) Read from Named object
§ ObjectReference - If
performing a DeRefOf return the target of the reference. Otherwise, return the
reference.
§ All other
object types - Return the object
Table 17-14 Reading from Named Objects
Current NAME Type
|
Read operation on NAME
|
Result of read
|
RefOf (Obj)
|
Store (NAME, …)
CopyObject (NAME, …)
DeRefOf (NAME)
|
RefOf (Obj)
RefOf (Obj)
Obj
|
Obj (All other types)
|
Store (NAME, …)
CopyObject (NAME, …)
|
Obj
Obj
|
2) Store to Named object
§ All object types - Delete
any existing object in NAME first, then store a copy of the object. The Store
operator will perform an implicit conversion to the existing type in NAME.
CopyObject does not perform an implicit store.
Table 17-15 Writing to Named Objects
Current NAME Type
|
Object to be written
|
Write operation on NAME
|
Result of write (in NAME)
|
A
(Any Type)
|
Obj
(Any type)
|
Store (…, NAME)
CopyObject (…, NAME)
|
Copy of Obj (converted
to type A)
Copy of Obj (No
conversion)
|
17.3 ASL Operator Summary
Operator Name Page Description
1. Acquire 218 Acquire
a mutex
2. Add 218 Integer
Add
3. Alias
lang=PT-BR>Define a name alias
4. And 218 Integer
Bitwise And
5. ArgX 218 Method
argument data objects
6. BankField 218 Declare
fields in a banked configuration object
7. Break 218 Continue following the innermost enclosing While
8. BreakPoint 218 Used for debugging, stops execution in the debugger
9. Buffer 218 Declare
Buffer object
10. Case 218
>Expression for conditional execution
11. Concatenate
> 218 Concatenate
two strings, integers or buffers
12. ConcatenateResTemplate
> 218 Concatenate two
resource templates
13. CondRefOf
> 218 Conditional
reference to an object
14. Continue 218
>Continue innermost enclosing While loop
15. CopyObject 218
>Copy and existing object
16. CreateBitField 218
>Declare a bit field object of a buffer object
17. CreateByteField 218
>Declare a byte field object of a buffer object
18. CreateDWordField 218
>Declare a DWord field object of a buffer object
19. CreateField 218
>Declare an arbitrary length bit field of a buffer
object
20. CreateQWordField 218
>Declare a QWord field object of a buffer object
21. CreateWordField 218
>Declare a Word field object of a buffer object
22. DataTableRegion 218
>Declare a Data Table Region
23. Debug 218
>Debugger output
24. Decrement
> 218 Decrement
an Integer
25. Default 218
>Default execution path in Switch()
26. DefinitionBlock 218
>Declare a Definition Block
27. DerefOf
> 218 Dereference
an object reference
28. Device
> 218 Declare
a bus/device object
29. Divide
> 218 Integer
Divide
30. DMA 218
>DMA Resource Descriptor macro
31. DWordIO 218
>DWord IO Resource Descriptor macro
32. DWordMemory 218
>DWord Memory Resource Descriptor macro
33. DWordSpace 218
>DWord Space Resource Descriptor macro
34. EisaId 218
>EISA ID String to Integer conversion macro
35. Else 218
>Alternate conditional execution
36. ElseIf 218
>Conditional execution
37. EndDependentFn 218
>End Dependent Function Resource Descriptor macro
38. Event
> 218 Declare
an event synchronization object
39. ExtendedIO
> Extended
IO Resource Descriptor macro
40. ExtendedMemory
> Extended
Memory Resource Descriptor macro
41. ExtendedSpace
> Extended
Space Resource Descriptor macro
42. External 218
>Declare external objects
43. Fatal 218
>Fatal error check
44. Field
> 218 Declare
fields of an operation region object
45. FindSetLeftBit
> 218 Index
of first least significant bit set
46. FindSetRightBit
> 218 Index
of first most significant bit set
47. FixedIO 218
>Fixed I/O Resource Descriptor macro
48. FromBCD
> 218 Convert
from BCD to numeric
49. Function
> 218 Declare
control method
50. If 218
>Conditional execution
51. Include 218
>Include another ASL file
52. Increment
> 218 Increment
a Integer
53. Index
> 218 Indexed
Reference to member object
54. IndexField
> 218 Declare
Index/Data Fields
55. Interrupt 218
>Interrupt Resource Descriptor macro
56. IO 218
>IO Resource Descriptor macro
57. IRQ 218
>Interrupt Resource Descriptor macro
58. IRQNoFlags 218
>Short Interrupt Resource Descriptor macro
59.
style='text-transform:uppercase'>LAnd 218 Logical
And
60. LEqual
> 218 Logical
Equal
61. LGreater
> 218 Logical
Greater
62. LGreaterEqual
> 218 Logical
Not less
63. LLess
> 218 Logical
Less
64. LLessEqual
> 218 Logical
Not greater
65. LNot
> 218 Logical
Not
66. LNotEqual
> 218 Logical
Not equal
67. Load 218
>Load differentiating definition block
68. LoadTable
> 218 Load
Table from RSDT/XSDT
69. LocalX
> 218 Method
local data objects
70. LOr
> 218 Logical
Or
71. Match
> 218 Search
for match in package array
72. Memory24 218
>Memory Resource Descriptor macro
73. Memory32 218
>Memory Resource Descriptor macro
74. Memory32Fixed 218
>Memory Resource Descriptor macro
75. Method
> 218 Declare
a control method
76. Mid
> 218 Return
a portion of buffer or string
77. Mod
> 218 Integer
Modulo
78. Multiply
> 218 Integer
Multiply
79. Mutex
> 218 Declare
a mutex synchronization object
80. Name 218
>Declare a Named object
81. NAnd
> 218 Integer
Bitwise Nand
82. NoOp 218
>No operation
83. NOr
> 218 Integer
Bitwise Nor
84. Not
> 218 Integer
Bitwise Not
85. Notify 218
>Notify Object of event
86. ObjectType
> 218 Type
of object
87. One 218
>Constant One Object (1)
88. Ones 218
>Constant Ones Object (-1)
89. OperationRegion
> 218 Declare
an operational region
90. Or
> 218 Integer
Bitwise Or
91. Package 218
>Declare a package object
92. PowerResource 218 Declare
a power resource object
93. Processor Declare a processor
package
94. QWordIO 218
>QWord IO Resource Descriptor macro
95. QWordMemory 218
>QWord Memory Resource Descriptor macro
96. QWordSpace 218
>Qword Space Resource Descriptor macro
97. RefOf
> 218 Create
Reference to an object
98. Register 218
>Generic register Resource Descriptor macro
99. Release 218
>Release a synchronization object
100. Reset 218
>Reset a synchronization object
101. ResourceTemplate 218
>Resource to buffer conversion macro
102. Return 218
>Return from method execution
103. Revision 218
>Constant revision object
104. Scope 218
>Open named scope
105. ShiftLeft
> 218 Integer
shift value left
106. ShiftRight
> 218 Integer
shift value right
107. Signal 218
>Signal a synchronization object
108. SizeOf
> 218 Get
the size of a buffer, string, or package
109. Sleep 218
>Sleep n milliseconds (yields the processor)
110. Stall 218
>Delay n microseconds (does not yield the processor)
111. StartDependentFn 218
>Start Dependent Function Resource Descriptor macro
112. StartDependentFnNoPri 218
>Start Dependent Function Resource Descriptor macro
113. Store
> 218 Store
object
114. Subtract
> 218 Integer
Subtract
115. Switch 218
>Select code to execute based on expression value
116. ThermalZone
> 218 Declare
a thermal zone package.
117. Timer 218 Get
64-bit timer value
118. ToBCD
> 218 Convert
Integer to BCD
119. ToBuffer
> 218 Convert
data type to buffer
120. ToDecimalString
> 218 Convert
data type to decimal string
121. ToHexString
> 218 Convert
data type to hexadecimal string
122. ToInteger
> 218 Convert
data type to integer
123. ToString
> 218 Copy
ASCII string from buffer
124. ToUUID 218
>Convert Ascii string to UUID
125. Unicode 218
>String to Unicode conversion macro
126. Unload 218
>Unload definition block
127. VendorLong 218
>Vendor Resource Descriptor
128. VendorShort 218
>Vendor Resource Descriptor
129. Wait
> 218 Wait
on an Event
130. While 218
>Conditional loop
131. WordBusNumber 218
>Word Bus number Resource Descriptor macro
132. WordIO 218
>Word IO Resource Descriptor macro
133. WordSpace 218
>Word Space Resource Descriptor macro
134. Xor
> 218 Integer
Bitwise Xor
135. Zero 218
>Constant Zero object (0)
17.4 ASL Operator Summary By Type
Operator Name Page Description
//
ASL compiler controls
External 218 Declare external objects
Include 218 Include another ASL file
//
ACPI table management
DefinitionBlock 218 Declare a Definition Block
Load 218 Load definition block
LoadTable 218 Load
Table from RSDT/XSDT
Unload 218 Unload definition block
//
Miscellaneous named object creation
Alias 218 Define a name alias
Buffer 218 Declare
Buffer object
Device 218 Declare
a bus/device object
Function 218 Declare
a control method
Method 218 Declare
a control method
Name 218 Declare a Named object
Package 218 Declare a package object
PowerResource 218 Declare
a power resource object
Processor 218 Declare
a processor package
Scope 218 Open named scope
ThermalZone 218 Declare
a thermal zone package.
//
Operation Regions
BankField 218 Declare
fields in a banked configuration object
DataTableRegion 218 Declare a Data Table Region
Field 218 Declare
fields of an operation region object
IndexField 218 Declare
Index/Data Fields
OperationRegion 218 Declare
an operational region
//
Buffer Fields
CreateBitField 218 Declare a bit field object of a buffer object
CreateByteField 218 Declare a byte field object of a buffer object
CreateDWordField 218 Declare a DWord field object of a buffer object
CreateField 218 Declare an arbitrary length bit field of a buffer
object
CreateQWordField 218 Declare a QWord field object of a buffer object
CreateWordField 218 Declare a Word field object of a buffer object
//
Synchronization
Acquire 218 Acquire
a mutex
Event 218 Declare
an event synchronization object
Mutex 218 Declare
a mutex synchronization object
Notify 218 Notify Object of event
Release 218 Release a synchronization object
Reset 218 Reset a synchronization object
Signal 218 Signal a synchronization object
Wait 218 Wait
on an Event
//
Object references
CondRefOf 218 Conditional
reference to an object
DerefOf 218 Dereference
an object reference
RefOf 218 Create
Reference to an object
//
Integer arithmetic
Add 218 Integer
Add
And 218 Integer
Bitwise And
Decrement 218 Decrement
an Integer
Divide 218 Integer
Divide
FindSetLeftBit 218 Index
of first least significant bit set
FindSetRightBit 218 Index
of first most significant bit set
Increment 218 Increment
a Integer
Mod 218 Integer
Modulo
Multiply 218 Integer
Multiply
NAnd 218 Integer
Bitwise Nand
NOr 218 Integer
Bitwise Nor
Not 218 Integer
Bitwise Not
Or 218 Integer
Bitwise Or
ShiftLeft 218 Integer
shift value left
ShiftRight 218 Integer
shift value right
Subtract 218 Integer
Subtract
Xor 218 Integer
Bitwise Xor
//
Logical operators
LAnd
> 218 Logical
And
LEqual 218 Logical
Equal
LGreater 218 Logical
Greater
LGreaterEqual 218 Logical
Not less
LLess 218 Logical
Less
LLessEqual 218 Logical
Not greater
LNot 218 Logical
Not
LNotEqual 218 Logical
Not equal
LOr 218 Logical
Or
//
Method execution control
Break 218 Continue following the innermost enclosing While
BreakPoint 218 Used for debugging, stops execution in the debugger
Case 218 Expression for conditional execution
Continue 218 Continue innermost enclosing While loop
Default 218 Default execution path in Switch()
Else 218 Alternate conditional execution
ElseIf 218 Conditional execution
Fatal 218 Fatal error check
If 218 Conditional execution
NoOp 218 No operation
Return 218 Return from method execution
Sleep 218 Sleep n milliseconds (yields the processor)
Stall 218 Delay n microseconds (does not yield the processor)
Switch 218 Select code to execute based on expression value
While 218 Conditional loop
//
Data type conversion and manipulation
Concatenate 218 Concatenate
two strings, integers or buffers
CopyObject 218 Copy and existing object
Debug 218 Debugger output
EisaId 218 EISA ID String to Integer conversion macro
FromBCD 218 Convert
from BCD to numeric
Index 218 Indexed
Reference to member object
Match 218 Search
for match in package array
Mid 218 Return
a portion of buffer or string
ObjectType 218 Type
of object
SizeOf 218 Get
the size of a buffer, string, or package
Store 218 Store
object
Timer 218 Get 64-bit timer value
ToBCD 218 Convert
Integer to BCD
ToBuffer 218 Convert
data type to buffer
ToDecimalString 218 Convert
data type to decimal string
ToHexString 218 Convert
data type to hexadecimal string
ToInteger 218 Convert
data type to integer
ToString 218 Copy
ASCII string from buffer
ToUUID 218 Convert Ascii string to UUID
Unicode 218 String to Unicode conversion macro
//
Resource Descriptor macros
ConcatenateResTemplate 218 Concatenate
two resource templates
DMA 218 DMA Resource Descriptor macro
DWordIO 218 DWord IO Resource Descriptor macro
DWordMemory 218 DWord Memory Resource Descriptor macro
DWordSpace 218 DWord Space Resource Descriptor macro
EndDependentFn 218 End Dependent Function Resource Descriptor macro
ExtendedIO
>Extended I/O Resource Descriptor macro
ExtendedMemory
>Extended Memory Resource Descriptor macro
ExtendedSpace
>Extended Space Resource Descriptor macro
FixedIO 218 Fixed I/O Resource Descriptor macro
Interrupt 218 Interrupt Resource Descriptor macro
IO 218 IO Resource Descriptor macro
IRQ 218 Interrupt Resource Descriptor macro
IRQNoFlags 218 Short Interrupt Resource Descriptor macro
Memory24 218 Memory Resource Descriptor macro
Memory32 218 Memory Resource Descriptor macro
Memory32Fixed 218 Memory Resource Descriptor macro
QWordIO 218 QWord IO Resource Descriptor macro
QWordMemory 218 QWord Memory Resource Descriptor macro
QWordSpace 218 Qword Space Resource Descriptor macro
Register 218 Generic register Resource Descriptor macro
ResourceTemplate 218 Resource to buffer conversion macro
StartDependentFn 218 Start Dependent Function Resource Descriptor macro
StartDependentFnNoPri 218 Start Dependent Function Resource Descriptor macro
VendorLong 218 Vendor Resource Descriptor
VendorShort 218 Vendor Resource Descriptor
WordBusNumber 218 Word Bus number Resource Descriptor macro
WordIO 218 Word IO Resource Descriptor macro
WordSpace 218 Word Space Resource Descriptor macro
//
Constants
One 218 Constant One Object (1)
Ones
lang=FR> Constant
Ones Object (-1)
Revision
lang=FR> Constant
revision object
Zero 218 Constant Zero object (0)
//
Control method objects
ArgX 218 Method
argument data objects
LocalX 218 Method
local data objects
17.5 ASL Operator Reference
This section describes each of the ASL operators
syntax for each operator is given, with a description of each argument and an
overall description of the operator behavior. Example ASL code is provided for
the more complex operators.
ASL operators can be categorized as follows:
· Named Object creation
· Method execution control (If, Else, While, etc.)
· Integer math
· Logical operators
· Resource Descriptor macros
· Object conversion
· Utility/Miscellaneous
17.5.1 Acquire (Acquire a
Mutex)
Syntax
Acquire (SyncObject, TimeoutValue)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
SynchObject must be
a mutex synchronization object. TimeoutValue is evaluated as an Integer.
Description
Ownership of the Mutex is obtained. If the Mutex is already
owned by a different invocation, the current execution thread is suspended
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 (or greater) indicates that
there is no timeout and the operation will wait indefinitely.
17.5.2 Add (Integer Add)
Syntax
Add (Addend1, Addend2, Result)
> => Integer
Arguments
Addend1 and Addend2 are evaluated as Integers.
Description
The operands 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.
17.5.3 Alias
(Declare Name Alias)
Syntax
Alias (SourceObject, AliasObject)
Arguments
SourceObject is any
named object. AliasObject is a
NameString.
Description
Creates a new object named AliasObject that 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 exist 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.
Example
The following example shows the use of an Alias term:
Alias
(\SUS.SET.EVEN, SSE)
17.5.4 And (Integer Bitwise And)
Syntax
And (Source1, Source2, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Source1 and
Source2 are evaluated as
Integers.
Description
A bitwise AND is
performed and the result is optionally stored into Result.
17.5.5 Argx (Method Argument
Data Objects)
Syntax
Arg0
| Arg1 | Arg2 |
class=StyleSyntaxElementBoldCharChar>Arg3 | Arg4 |
class=StyleSyntaxElementBoldCharChar>Arg5 | Arg6
Description
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.
17.5.6 BankField (Declare Bank/Data Field)
Syntax
BankField
(RegionName, BankName,
BankValue, AccessType, LockRule, UpdateRule) {FieldUnitList}
Arguments
RegionName is the name
of the host Operation Region. BankName is the name of the bank selection 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.
Description
This operator 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.
Example
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 a 256-byte operational region
in SystemIO space
// and name it GIO0
OperationRegion (GIO0,
SystemIO, 0x125, 0x100)
// Create some fields 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
}
17.5.7 Break (Break from While)
Syntax
Break
Description
Break causes
execution to continue immediately following the innermost enclosing While or Switch scope, in the current Method. If there is no enclosing While or Switch within the current Method, a fatal error is generated.
Compatibility Note:In ACPI 1.0, the Break operator continued immediately following the innermost
"code package." Starting in ACPI 2.0, the Break operator was changed to exit
the innermost "While" or "Switch" package. This should have no impact on
existing code, since the ACPI 1.0 definition was, in practice, useless.
17.5.8
BreakPoint (Execution Break Point)
Syntax
BreakPoint
Description
Used for debugging, the Breakpoint opcode stops the execution and enters the AML
debugger. In the non-debug version of the AML interpreter, BreakPoint is equivalent to Noop
>.
17.5.9 Buffer (Declare
Buffer Object)
Syntax
Buffer (BuffSize) {
>String or ByteList} =>Buffer
Arguments
Declares a Buffer of size BuffSize and optional initial value of String
style='font-style:normal'>or ByteList.
Description
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, the 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}
17.5.10 Case (Expression for Conditional Execution)
Syntax
Case
(Value) {TermList}
Arguments
Value specifies an
Integer, Buffer, String or Package object. TermList is a sequence of executable ASL expressions.
Description
Execute code based upon the value of a Switch statement.
If the Case Value
is an Integer, Buffer or String, then control passes to the statement that
matches the value of the enclosing Switch (Value). If the Case value is a Package, then control passes if any
member of the package matches the Switch (Value). The Switch
> CaseTermList can include any number
of Case instances, but no two Case Values (or members of a Value
style='font-style:normal'>, if Value
is a Package) within the same Switch statement can contain the
same value.
Execution of the statement body begins at the start of the TermList
and proceeds until the end of the TermList
body or until a Break or Continue operator transfers control out of the body.
17.5.11 Concatenate (Concatenate
Data)
Syntax
Concatenate
(Source1, Source2, Result)
class=StyleSyntaxElementBoldCharChar> =>ComputationalData
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2 and the type of the result object. Source2 is implicitly converted if necessary
to match the type of Source1.
Description
Source2 is
concatenated to Source1 and the
result data is optionally stored into Result.
Table 17-16 Concatenate Data Types
Source1 Data Type
|
Source2 Data Type (è
Converted Type)
|
Result Data Type
|
Integer
|
Integer/String/Buffer è Integer
|
Buffer
|
String
|
Integer/String/Buffer è String
|
String
|
Buffer
|
Integer/String/Buffer è Buffer
|
Buffer
|
17.5.12 ConcatenateResTemplate
(Concatenate Resource Templates)
Syntax
ConcatenateResTemplate
(Source1, Source2,
class=StyleSyntaxElementItalicCharChar>Result) => Buffer
Arguments
Source1 and Source2 are evaluated as Resource Template buffers.
Description
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
style='font-style:normal'> 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.
17.5.13 CondRefOf (Create Object
Reference Conditionally)
Syntax
CondRefOf
(Source, Result)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
Attempts to create a reference to the Source object. The Source
style='font-style:normal'> of this operation can be any object type (for
example, data package, device object, and so on), and the result data is
optionally stored into Result.
Description
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 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
>.
17.5.14 Continue (Continue Innermost Enclosing While)
Syntax
Continue
Description
Continue causes
execution to continue at the start of the innermost enclosing While scope, in the currently executing Control Method,
at the point where the condition is evaluated. If there is no enclosing While within the current Method, a fatal error is
generated.
17.5.15 CopyObject (Copy and Store
Object)
Syntax
CopyObject (
class=StyleSyntaxElementItalicCharChar>Source, Destination)
class=StyleSyntaxElementBoldCharChar> => DataRefObject
Arguments
Converts the contents of the Source to a DataRefObject using the conversion rules in 17.2.5
and then copies the results without conversion to the object referred to by Destination.
Description
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 CopyObject operator was first introduced new in ACPI 2.0.
17.5.16 CreateBitField
(Create 1-Bit Buffer Field)
Syntax
CreateBitField
(SourceBuffer, BitIndex,
BitFieldName)
Arguments
SourceBuffer is
evaluated as a buffer. BitIndex
is evaluated as an integer. BitFieldName is a NameString.
Description
A new buffer field object named BitFieldName is created for the bit of SourceBuffer
style='font-style:normal'> at the bit index of BitIndex. The bit-defined field within SourceBuffer
style='font-style:normal'> must exist.BitFieldName is created for the bit of SourceBuffer
style='font-style:normal'> at the bit index of BitIndex. The bit-defined field within SourceBuffer
style='font-style:normal'> must exist.
17.5.17
CreateByteField (Create 8-Bit Buffer Field)
Syntax
CreateByteField
(SourceBuffer,
ByteIndex, ByteFieldName)
Arguments
SourceBuffer is
evaluated as a buffer. ByteIndex
is evaluated as an integer. ByteFieldName is a NameString.
Description
A new buffer field object named ByteFieldName is created for the byte of SourceBuffer
style='font-style:normal'> at the byte index of ByteIndex. The byte-defined field within SourceBuffer
style='font-style:normal'> must exist.
17.5.18
CreateDWordField (Create 32-Bit Buffer Field)
Syntax
CreateDWordField
(SourceBuffer,
ByteIndex, DWordFieldName)
Arguments
SourceBuffer is
evaluated as a buffer. ByteIndex
is evaluated as an integer. DwordFieldName is a NameString.
Description
A new buffer field object named DWordFieldName is created for the DWord of SourceBuffer
style='font-style:normal'> at the byte index of ByteIndex. The DWord-defined field within SourceBuffer
style='font-style:normal'> must exist.
17.5.19
CreateField (Create Arbitrary Length Buffer Field)
Syntax
CreateField
(SourceBuffer,
BitIndex, NumBits, FieldName)
Arguments
SourceBuffer is
evaluated as a buffer. BitIndex
and NumBits are evaluated as
integers. FieldName is a NameString.
Description
A new buffer field object named FieldName is created for the bits of SourceBuffer
style='font-style:normal'> at BitIndex for NumBits. The entire
bit range of the defined field within SourceBuffer must exist. If NumBits
style='font-style:normal'>evaluates to zero, a fatal exception is generated.
17.5.20
CreateQWordField (Create 64-Bit Buffer Field)
Syntax
CreateQWordField
(SourceBuffer,
ByteIndex, QWordFieldName)
Arguments
SourceBuffer is
evaluated as a buffer. ByteIndex
is evaluated as an integer. QWordFieldName is a NameString.
Description
A new buffer field object named QWordFieldName is created for the QWord of SourceBuffer
style='font-style:normal'> at the byte index of ByteIndex. The QWord-defined field within SourceBuffer
style='font-style:normal'> must exist.
17.5.21
CreateWordField (Create 16-Bit Buffer Field)
Syntax
CreateWordField
(SourceBuffer,
ByteIndex, WordFieldName)
Arguments
SourceBuffer is
evaluated as a buffer. ByteIndex
is evaluated as an integer. WordFieldName is a NameString.
Description
A new bufferfield object named WordFieldName is created for the word of SourceBuffer
style='font-style:normal'> at the byte index of ByteIndex. The word-defined field within SourceBuffer
style='font-style:normal'> must exist.
17.5.22 DataTableRegion (Create
Data Table Operation Region)
Syntax
DataTableRegion (
class=StyleSyntaxElementItalicCharChar>RegionName,
SignatureString, OemIDString, OemTableIDString)
Arguments
Creates a new region named RegionName. 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
style='font-style:normal'>. 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
length of the region is the length of the table.
Description
A Data Table Region is a special Operation Region
region space is always memory. Any table referenced by a Data Table Region must
be in memory marked by AddressRangeReserved or AddressRangeNVS.
17.5.23 Debug (Debugger Output)
Syntax
Debug
Description
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
system's 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 17-17 Debug Object Display Formats
ASL Term Type
|
Display Format
|
Numeric data object
|
All digits displayed in hexadecimal
format.
|
String data object
|
String is displayed.
|
Object reference
|
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.
17.5.24 Decrement (Integer Decrement)
Syntax
Decrement
(Minuend) =>Integer
Arguments
Minuend is evaluated
as an Integer.
Description
This operation decrements the Minuend by one and the result is stored back to Minuend
style='font-style:normal'>. Equivalent to Subtract (Minuend, 1, Minuend). Underflow conditions are ignored and the result is
Ones.
17.5.25 Default
(Default Execution Path in Switch)
Syntax
Default
{TermList}
Arguments
TermList is a
sequence of executable ASL expressions.
Description
Within the body of a Switch (page 218) statement, the statements
specified by TermList will be executed
if no Case
(page 218) statement value matches the Switch statement value. If Default 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 in the immediate scope of the parent
Switch statement. The Default
statement can appear anywhere in the body of the Switch statement.
17.5.26 DefinitionBlock (Declare Definition Block)
Syntax
DefinitionBlock
(AMLFileName,
TableSignature, ComplianceRevision, OEMID, TableID, OEMRevision)
{TermList}
Arguments
AMLFileName is a
string that specifies the desired name of the translated output AML file. TableSignature is a string that contains the 4-character ACPI
signature. ComplianceRevision is
an 8-bit value. OEMID is a
6-character string, TableId is an
8-character string, and OEMRevision is
a 32-bit value. TermList is a
sequence of executable ASL expressions.
Description
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.
For compatibility with ACPI versions before ACPI 2.0, the
bit width of Integer objects is dependent on the ComplianceRevision. If the ComplianceRevision
style='font-style:normal'> is less than 2, all integers are restricted to 32
bits. Otherwise, full 64-bit integers are used.
17.5.27
DerefOf (Dereference an Object Reference)
Syntax
DerefOf (Source)
class=StyleSyntaxElementBoldCharChar> =>Object
Arguments
Returns the object referred by the Source object reference.
Description
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
was first introduced in ACPI 2.0.
17.5.28 Device (Declare Bus/Device Package)
Syntax
Device (DeviceName) {
>ObjectList}
Arguments
Creates a Device object of name DeviceName, which represents either a bus or a device or any
other similar hardware. Device opens a name scope.
Description
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 device's 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 device's normal capabilities
and for any Device Object required to fill in the tree for such a device
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 device's ID and
configuration information and the parent PCI device, because it is required to
get the ISA Device Package placement in the namespace correct.
Example
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) { //
primary controller
Name (_ADR, 0) //
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) {
…
}
}
}
}
17.5.29 Divide (Integer Divide)
Syntax
Divide (Dividend, Divisor, Remainder, Result)
> => Integer
Arguments
Dividend and Divisor are evaluated as Integers.
Description
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.
The function return value is the Result (quotient).
17.5.30 DMA (DMA Resource Descriptor Macro)
Syntax
DMA (DmaType,
class=StyleSyntaxElementItalicCharChar>IsBusMaster, DmaTransferSize,
class=StyleSyntaxElementItalicCharChar>DescriptorName) {DmaChannelList}
> => Buffer
Arguments
DmaType specifies
the type of DMA cycle: ISA compatible (Compatibility), EISA Type
A (TypeA), EISA Type B (TypeB) or EISA Type F (TypeF
>). The 2-bit field DescriptorName._TYP
is automatically created to refer to this portion of the resource descriptor, where
'0' is Compatibility, '1' is TypeA, '2' is TypeB and '3' is TypeF.
IsBusMaster specifies
whether this device can generate DMA bus master cycles (BusMaster)
or not (NotBusMaster). If nothing is
specified, then BusMaster is assumed. The 1-bit field DescriptorName._BM
is automatically created to refer to this portion of the resource descriptor,
where '0' is NotBusMaster and '1' is BusMaster.
DmaTransferSize
specifies the size of DMA cycles the device is capable of generating: 8-bit (Transfer8),
16-bit (Transfer16) or both 8 and
16-bit (Transfer8_16). The 2-bit
field DescriptorName._SIZ is automatically created to refer to
this portion of the resource descriptor, where '0' is Transfer8, '1' is
Transfer8_16 and '2' is Transfer16.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
DmaChannelList is a
comma-delimited list of integers in the range 0 through 7 that specify the DMA
channels used by the device. There may be no duplicates in the list.
Description
The DMA macro
evaluates to a buffer which contains a DMA resource descriptor. The format of
the DMA resource descriptor can be found in "DMA Descriptor" (page 202).
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.31
DWordIO (DWord IO Resource Descriptor Macro)
Syntax
DWordIO (ResourceUsage, IsMinFixed, IsMaxFixed, Decode,
ISARanges, AddressGranularity, AddressMinimum, AddressMaximum, AddressTranslation,
RangeLength, ResourceSourceIndex, ResourceSource, DescriptorName, TranslationType,
TranslationDensity)
Arguments
ResourceUsage
specifies whether the I/O range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
IsMinFixed specifies whether the minimum address of this I/O range is
fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName._MIF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this I/O range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName._MAF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MaxFixed and '0' is MaxNotFixed.
Decode specifies
whether or not the device decodes the I/O range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName._DEC
is automatically created to refer to this portion of the resource descriptor,
where '1' is SubDecode and '0' is PosDecode.
ISARanges specifies
whether the I/O ranges specifies are limited to valid ISA I/O ranges (ISAOnly),
valid non-ISA I/O ranges (NonISAOnly)
or encompass the whole range without limitation (EntireRange). The 2-bit field DescriptorName._RNG
is automatically created to refer to this portion of the resource descriptor,
where '1' is NonISAOnly, '2' is ISAOnly and '0' is EntireRange.
AddressGranularity
evaluates to a 32-bit integer that specifies the power-of-two boundary (- 1) on
which the I/O range must be aligned. The 32-bit field DescriptorName._GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 32-bit integer that specifies the lowest possible base address
of the I/O range. The value must have '0' in all bits where the corresponding
bit in AddressGranularity is '1'.
For bridge devices which translate addresses, this is the address on the
secondary bus. The 32-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 32-bit integer that specifies the highest possible base address of the I/O
range. The value must have '0' in all bits where the corresponding bit in AddressGranularity is '1'. For bridge devices which translate
addresses, this is the address on the secondary bus. The 32-bit field DescriptorName._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressTranslation
evaluates to a 32-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 32-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 32-bit integer that specifies the total number of bytes decoded
in the I/O range. The 32-bit field DescriptorName._LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string containing
the path of a device which produces the pool of resources from which this I/O
range is allocated. If this
argument is specified,
but the ResourceSourceIndex argument is not specified, a zero value is assumed.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is Memory. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName._TTP is automatically
created to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more information
TranslationDensity is an optional argument that specifies whether or
not the translation from the primary to secondary bus is sparse (SparseTranslation)
or dense (DenseTranslation). It is only
used when TranslationType is TypeTranslation. If nothing is specified, then DenseTranslation is
assumed. The 1-bit field DescriptorName._TRS is automatically
created to refer to this portion of the resource descriptor, where '1' is
SparseTranslation and '0' is DenseTranslation. See _TRS (page 218) for more
information.
Description
The DWordIO macro
evaluates to a buffer which contains a 32-bit I/O range resource descriptor.
The format of the 32-bit I/O range resource descriptor can be found in "DWord
Address Space Descriptor " (page 215). The macro is designed to be used inside
of a ResourceTemplate (page 218).
17.5.32 DWordMemory (DWord Memory Resource Descriptor Macro)
Syntax
DWordMemory
(ResourceUsage, Decode,
IsMinFixed, IsMaxFixed, Cacheable, ReadAndWrite, AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation, RangeLength, ResourceSourceIndex, ResourceSource,
DescriptorName, MemoryType, TranslationType)
Arguments
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the Memory range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName._DEC
is automatically created to refer to this portion of the resource descriptor,
where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this Memory range is
fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName._MIF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this Memory range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName._MAF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MaxFixed and '0' is MaxNotFixed.
Cacheable specifies
whether or not the memory region is cacheable (Cacheable), cacheable
and write-combining (WriteCombining),
cacheable and prefetchable (Prefetchable) or uncacheable (NonCacheable). If nothing is specified, then NonCacheable is assumed. The 2-bit
field DescriptorName._MEM is automatically created to refer to
this portion of the resource descriptor, where '1' is Cacheable, '2' is
WriteCombining, '3' is Prefetchable and '0' is NonCacheable.
ReadAndWrite
specifies whether or not the memory region is read-only (ReadOnly)
or read/write (ReadWrite). If nothing
is specified, then ReadWrite is assumed. The 1-bit field DescriptorName._RW
is automatically created to refer to this portion of the resource descriptor,
where '1' is ReadWrite and '0' is ReadOnly.
AddressGranularity
evaluates to a 32-bit integer that specifies the power-of-two boundary (- 1) on
which the Memory range must be aligned. The 32-bit field DescriptorName._GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 32-bit integer that specifies the lowest possible base address
of the Memory range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 32-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 32-bit integer that specifies the highest possible base address of the
Memory range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 32-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 32-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 32-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 32-bit integer that specifies the total number of bytes decoded
in the Memory range. The 32-bit field DescriptorName._LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this Memory range is allocated. If this argument is specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed
style='font-size:110%'>.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
.
MemoryType is an optional argument that specifies the memory
usage. The memory can be marked as normal (AddressRangeMemory),
used as ACPI NVS space (AddressRangeNVS),
used as ACPI reclaimable space (AddressRangeACPI) or as system reserved (AddressRangeReserved
>). If nothing is specified, then AddressRangeMemory
is assumed. The 2-bit field DescriptorName._MTP is automatically
created in order to refer to this portion of the resource descriptor, where '0'is AddressRangeMemory, '1' is AddressRangeReserved, '2' is AddressRangeACPI and
'3' is AddressRangeNVS.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is I/O. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName._TTP is automatically
created to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more
information.
Description
The DWordMemory macro
evaluates to a buffer which contains a 32-bit memory resource descriptor
format of the 32-bit memory resource descriptor can be found in "DWord
Address Space Descriptor " (page 215). The macro is designed to be used inside
of a ResourceTemplate (page 218).
17.5.33 DWordSpace (DWord Space Resource Descriptor Macro)
Syntax
DWordSpace
(ResourceType, ResourceUsage, Decode, IsMinFixed, IsMaxFixed,
TypeSpecificFlags, AddressGranularity, AddressMinimum, AddressMaximum, AddressTranslation,
RangeLength, ResourceSourceIndex, ResourceSource, DescriptorName)
Arguments
ResourceType evaluates
to an 8-bit integer that specifies the type of this resource. Acceptable values
are 0xC0 through 0xFF.
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the Memory range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName._DEC
is automatically created to refer to this portion of the resource descriptor,
where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this Memory range
is fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName._MIF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this Memory range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName._MAF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MaxFixed and '0' is MaxNotFixed.
TypeSpecificFlags
evaluates to an 8-bit integer. The flags are specific to the ResourceType.
AddressGranularity
evaluates to a 32-bit integer that specifies the power-of-two boundary (- 1) on
which the Memory range must be aligned. The 32-bit field DescriptorName._GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 32-bit integer that specifies the lowest possible base address
of the Memory range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 32-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 32-bit integer that specifies the highest possible base address of the
Memory range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 32-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 32-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 32-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 32-bit integer that specifies the total number of bytes decoded
in the Memory range. The 32-bit field DescriptorName._LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this Memory range is allocated. If this argument is specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed
style='font-size:110%'>.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The DWordSpace macro
evaluates to a buffer which contains a 32-bit Address Space resource
descriptor. The format of the 32-bit Address Space resource descriptor can be
found in "DWord Address Space Descriptor " (page 215). The macro is
designed to be used inside of a ResourceTemplate (page 218).
17.5.34 EISAID (EISA ID String To Integer Conversion Macro)
Syntax
EISAID (EisaIdString)
> => DWordConst
Arguments
The EisaIdString must
be a String object of the form "UUUNNNN", where "U" is an uppercase letter and
"N" is a hexadecimal digit. No asterisks or other characters are allowed in the
string.
Description
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.
Example
EISAID ("PNP0C09") // This is a
valid invocation of the macro.
17.5.35 Else (Alternate Execution)
Syntax
Else {TermList}
Arguments
TermList is a
sequence of executable ASL statements.
Description
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.
Example
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)
}
17.5.36 ElseIf
(Alternate/Conditional Execution)
Syntax
ElseIf (Predicate)
Arguments
Predicate is evaluated
as an Integer.
Description
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. If no Predicate
evaluates to non-zero, then the statements in the Else term list are executed.
Compatibility Note:
The ElseIf operator was first
introduced in ACPI 2.0, but is backward compatible with the ACPI 1.0
specification. An ACPI 2.0 and later ASL compiler must synthesize ElseIf
from the If. and Else opcodes available in 1.0. For example:
If (predicate1)
{
…statements1…
}
ElseIf (predicate2)
{
…statements2…
}
Else
{
…statements3…
}
is translated to the following:
If (predicate1)
{
…statements1…
}
Else
{
If (predicate2)
{
…statements2…
}
Else
{
…statements3…
}
}
17.5.37 EndDependentFn (End Dependent Function Resource Descriptor
Macro)
Syntax
EndDependentFn
() => Buffer
Description
The EndDependentFn macro
generates an end-of-dependent-function resource descriptor buffer inside of an ResourceTemplate
(page 218). It must be matched with a StartDependentFn
(page 218) or StartDependentFnNoPri
(page 218) macro.
17.5.38 Event (Declare Event Synchronization Object)
Syntax
Event (EventName)
Arguments
Creates an event synchronization object named EventName.
Description
For more information about the uses of an event
synchronization object, see the ASL definitions for the Wait, Signal, and Reset
function operators.
17.5.39 ExtendedIO
(Extended IO Resource Descriptor Macro)
Syntax
ExtendedIO
(ResourceUsage, IsMinFixed,
IsMaxFixed, Decode,
class=StyleSyntaxElementItalicCharChar>ISARanges, AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation,
RangeLength, TypeSpecificAttributes,
DescriptorName, TranslationType,
TranslationDensity)
Arguments
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
IsMinFixed specifies whether the minimum address of this I/O range is
fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName._MIF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this I/O range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName._MAF
is automatically created to refer to this portion of the resource descriptor,
where '1' is MaxFixed and '0' is MaxNotFixed.
Decode specifies
whether or not the device decodes the I/O range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName._DEC
is automatically created to refer to this portion of the resource descriptor,
where '1' is SubDecode and '0' is PosDecode.
ISARanges specifies
whether the I/O ranges specifies are limited to valid ISA I/O ranges (ISAOnly),
valid non-ISA I/O ranges (NonISAOnly)
or encompass the whole range without limitation (EntireRange). The 2-bit field DescriptorName._RNG
is automatically created to refer to this portion of the resource descriptor,
where '1' is NonISAOnly, '2' is ISAOnly and '0' is EntireRange.
AddressGranularity
evaluates to a 64-bit integer that specifies the power-of-two boundary (- 1) on
which the I/O range must be aligned. The 64-bit field DescriptorName._GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 64-bit integer that specifies the lowest possible base address
of the I/O range. The value must have '0' in all bits where the corresponding
bit in AddressGranularity is '1'.
For bridge devices which translate addresses, this is the address on the
secondary bus. The 64-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 64-bit integer that specifies the highest possible base address of the I/O
range. The value must have '0' in all bits where the corresponding bit in AddressGranularity is '1'. For bridge devices which translate
addresses, this is the address on the secondary bus. The 64-bit field DescriptorName._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressTranslation
evaluates to a 64-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 64-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 64-bit integer that specifies the total number of bytes decoded
in the I/O range. The 64-bit field DescriptorName._LEN is automatically created to refer to this
portion of the resource descriptor.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is Memory. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName. _TTP is automatically
created to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more information
TranslationDensity is an optional argument that specifies whether or
not the translation from the primary to secondary bus is sparse (SparseTranslation)
or dense (DenseTranslation). It is only
used when TranslationType is TypeTranslation. If nothing is specified, then DenseTranslation is
assumed. The 1-bit field DescriptorName._TRS is automatically
created to refer to this portion of the resource descriptor, where '1' is
SparseTranslation and '0' is DenseTranslation. See _TRS (page 218) for more
information.
TypeSpecificAttributes
is an optional argument that specifies attributes specific to this resource
type. See section 6.4.3.5.4.1,"Type Specific Attributes".
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operatorsDescription
The ExtendedIO macro
evaluates to a buffer which contains a 64-bit I/O resource descriptor, which
describes a range of I/O addresses. The format of the 64-bit I/O resource
descriptor can be found in "Extended Address Space Descriptor" (page ).
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.40 ExtendedMemory (Extended Memory Resource Descriptor Macro)
Syntax
ExtendedMemory
(ResourceUsage, Decode,
IsMinFixed, IsMaxFixed, Cacheable, ReadAndWrite, AddressGranularity,
AddressMinimum, AddressMaximum, AddressTranslation, RangeLength, TypeSpecificAttributes,
DescriptorName, MemoryType, TranslationType)
Arguments
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the Memory range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName._DEC
is automatically created to refer to this portion of the resource descriptor,
where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this Memory range
is fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this Memory range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
Cacheable specifies
whether or not the memory region is cacheable (Cacheable), cacheable
and write-combining (WriteCombining),
cacheable and prefetchable (Prefetchable) or uncacheable (NonCacheable). If nothing is specified, then NonCacheable is assumed. The 2-bit
field DescriptorName._MEM is automatically created to refer to
this portion of the resource descriptor, where '1' is Cacheable, '2' is
WriteCombining, '3' is Prefetchable and '0' is NonCacheable.
ReadAndWrite
specifies whether or not the memory region is read-only (ReadOnly)
or read/write (ReadWrite). If nothing
is specified, then ReadWrite is assumed. The 1-bit field DescriptorName._RW
is automatically created to refer to this portion of the resource descriptor,
where '1' is ReadWrite and '0' is ReadOnly.
AddressGranularity
evaluates to a 64-bit integer that specifies the power-of-two boundary (- 1) on
which the Memory range must be aligned. The 64-bit field DescriptorName._GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 64-bit integer that specifies the lowest possible base address
of the Memory range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 64-bit field DescriptorName ._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 64-bit integer that specifies the highest possible base address of the
Memory range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 64-bit field DescriptorName ._MAX is automatically created to refer to this portion of the resource
descriptor.
AddressTranslation
evaluates to a 64-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 64-bit field DescriptorName. _TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 64-bit integer that specifies the total number of bytes decoded
in the Memory range. The 64-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
MemoryType is an optional argument that specifies the memory
usage. The memory can be marked as normal (AddressRangeMemory),
used as ACPI NVS space (AddressRangeNVS),
used as ACPI reclaimable space (AddressRangeACPI) or as system reserved (AddressRangeReserved
>). If nothing is specified, then AddressRangeMemory
is assumed. The 2-bit field DescriptorName. _MTP is automatically
created in order to refer to this portion of the resource descriptor, where '0'is AddressRangeMemory, '1' is AddressRangeReserved, '2' is AddressRangeACPI and
'3' is AddressRangeNVS.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is I/O. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName. _TTP is automatically created
to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more
information.
TypeSpecificAttributes
is an optional argument that specifies attributes specific to this resource
type. See section 6.4.3.5.4.1,"Type Specific Attributes".
Description
The ExtendedMemory macro
evaluates to a buffer which contains a 64-bit memory resource descriptor, which
describes a range of memory addresses. The format of the 64-bit memory resource
descriptor can be found in "Extended Address Space Descriptor" (page ).
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.41 ExtendedSpace (Extended Address Space Resource Descriptor
Macro)
Syntax
ExtendedSpace
(ResourceType, ResourceUsage, Decode, IsMinFixed,
IsMaxFixed, TypeSpecificFlags, AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation, RangeLength, TypeSpecificAttributes, DescriptorName)
Arguments
ResourceType evaluates
to an 8-bit integer that specifies the type of this resource. Acceptable values
are 0xC0 through 0xFF.
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the Memory range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this Memory range
is fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this Memory range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
TypeSpecificFlags
evaluates to an 8-bit integer. The flags are specific to the ResourceType.
AddressGranularity
evaluates to a 64-bit integer that specifies the power-of-two boundary (- 1) on
which the Memory range must be aligned. The 64-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 64-bit integer that specifies the lowest possible base address
of the Memory range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 64-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 64-bit integer that specifies the highest possible base address of the
Memory range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 64-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 64-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 64-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 64-bit integer that specifies the total number of bytes decoded
in the Memory range. The 64-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
TypeSpecificAttributes
is an optional argument that specifies attributes specific to this resource
type. See section 6.4.3.5.4.1,"Type Specific Attributes".
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The ExtendedSpace macro
evaluates to a buffer which contains a 64-bit Address Space resource
descriptor, which describes a range of addresses. The format of the 64-bit
AddressSpace descriptor can be found in "Extended Address Space Descriptor"
(page ).
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.42 External (Declare External Objects)
Syntax
External (ObjectName, ObjectType, ReturnType,
ParameterTypes)
Arguments
ObjectName is a
NameString. ObjectType is an
optional ObjectTypeKeyword. If not specified, "UnknownObj" type
is assumed.
ReturnType is
optional. If the specified object type is MethodObj, then this specifies
the type or types of object returned by the method. If the method does not
return an object, then nothing is specified or UnknownObj is specified. To specify a single return type,
simply use the ObjectTypeKeyword (e.g. IntObj, PkgObj,
etc.). To specify multiple possible return types, enclose the comma-separated ObjectTypeKeywords
with braces. For example: {IntObj, BuffObj}.
ParameterTypes is
optional. If the specified object type is MethodObj, this
specifies both the number and type of the method parameters. It is a comma-separated, variable-length list of the
expected object type or types for each of the method parameters, enclosed in
braces. For each parameter, the parameter type consists of either an ObjectTypeKeyword or a comma-separated sub-list of ObjectTypeKeywords
style='font-style:normal'> enclosed in braces. There can be no more than seven
parameters in total.Description
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.
17.5.43
Fatal (Fatal Error Check)
Syntax
Fatal (Type, Code, Arg)
Arguments
This operation is used to inform the OS that there has been
an OEM-defined fatal error.
Description
In response, the OS must log the fatal event and perform a
controlled OS shutdown in a timely fashion.
17.5.44 Field (Declare Field Objects)
Syntax
Field (RegionName, AccessType, LockRule,
UpdateRule) {FieldUnitList}
Arguments
RegionName refers to
the host operation region.
AccessType defines
the default access width of the field definition. 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 exceptions 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.
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.
Description
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.
The following table relates region types declared with an OperationRegion
term to the different access types supported for each region.
Table 17-18 OperationRegion Region Types
and Access Types
Region Type
|
Permitted Access Type(s)
|
Description
|
SystemMemory
|
ByteAcc | WordAcc | DWordAcc | QWordAcc
| AnyAcc
|
All access allowed
|
SystemIO
|
ByteAcc | WordAcc | DWordAcc | QWordAcc
| AnyAcc
|
All access allowed
|
PCI_Config
|
ByteAcc | WordAcc | DWordAcc | QWordAcc
| AnyAcc
|
All access allowed
|
EmbeddedControl
|
ByteAcc
|
Byte access only
|
SMBus
|
BufferAcc
|
Reads and writes to this operation region
involve the use of a region specific data buffer. (See below.)
|
CMOS
|
ByteAcc
|
Byte access only
|
PciBarTarget
|
ByteAcc | WordAcc | DWordAcc | QWordAcc
| AnyAcc
|
All access allowed
|
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.
17.5.44.1 CMOS Protocols
This section describes how CMOS can be accessed from ASL.
Most computers contain an RTC/CMOS device that can be represented as a linear
array of bytes of non-volatile memory. There is a standard mechanism for
accessing the first 64 bytes of non-volatile RAM in devices that are compatible
with the Motorola RTC/CMOS device that was in the IBM PC/AT. But today's
RTC/CMOS devices usually contain more than 64 bytes of non-volatile RAM, and
there is no standard for access to these extensions. To solve this problem, new
PnP IDs were created for each type of extension. These are PNP0B00, PNP0B01,
and PNP0B02. The specific devices that these PnP IDs support are described in
section 9.16, "PC/AT RTC/CMOS Device", along with field definition ASL example
code.
All bytes of CMOS that are related to the current time,
day, date, month, year and century are read-only.
17.5.44.2 PCI Device BAR Target Protocols
This section describes how PCI
devices' control registers can be accessed from ASL. PCI devices each have an
address space associated with them called the Configuration Space. At offset
0x10 through offset 0x27, there are as many as six Base Address Registers,
(BARs). These BARs contain the base address of a series of control registers
(in I/O or Memory space) for the PCI device. Since a Plug and Play OS may
change the values of these BARs at any time, ASL cannot read and write from
these deterministically using I/O or Memory operation regions. Furthermore, a
Plug and Play OS will automatically assign ownership of the I/O and Memory
regions associated with these BARs to a device driver associated with the PCI
device. An ACPI OS (which must also be a Plug and Play operating system) will
not allow ASL to read and write regions that are owned by native device
drivers.
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.
17.5.44.2.1 Declaring a PCI BAR Target Operation Region
PCI BARs contain the base address of an I/O or Memory
region that a PCI device's control registers lie within. Each BAR implements a
protocol for determining whether those control registers are within I/O or
Memory space and how much address space the PCI device decodes. (See the PCI
Specification for more details.)
PCI BAR Target operation regions are declared by providing
the offset of the BAR within the PCI device's PCI configuration space. The BAR
determines whether the actual access to the device occurs through an I/O or
Memory cycle, not by the declaration of the operation region. The length of the
region is similarly implied.
In the term OperationRegion(PBAR, PciBarTarget, 0x10, 0x4),
the offset is the offset of the BAR within the configuration space of the
device. This would be an example of an operation region that uses the first BAR
in the device.
17.5.44.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.
17.5.45 FindSetLeftBit (Find First Set Left Bit)
Syntax
FindSetLeftBit
(Source, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Source is evaluated
as an Integer.
Description
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.
17.5.46
FindSetRightBit (Find First Set Right Bit)
Syntax
FindSetRightBit
(Source, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Source is evaluated
as an Integer.
Description
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.
17.5.47
FixedIO
(Fixed IO Resource Descriptor Macro)
Syntax
FixedIO (AddressBase, RangeLength, DescriptorName)
> => Buffer
Arguments
AddressBase
evaluates to a 16-bit integer. It describes the starting address of the fixed
I/O range. The field DescriptorName.
_BAS is automatically created to refer to this portion of the resource
descriptor.
RangeLength
evaluates to an 8-bit integer. It describes the length of the fixed I/O range.
The field DescriptorName. _LEN is
automatically created to refer to this portion of the resource descriptor.
DescriptorName
evaluates to a name string which refers to the entire resource descriptor.
Description
The FixedIO macro
evaluates to a buffer which contains a fixed I/O resource descriptor
format of the fixed I/O resource descriptor can be found in "Fixed
Location I/O Port Descriptor " (page 205). The macro is designed to be used
inside of a ResourceTemplate (page 218).
17.5.48 FromBCD (Convert BCD To Integer)
Syntax
FromBCD (BCDValue,
class=StyleSyntaxElementItalicCharChar>Result) =>Integer
Arguments
BCDValue is
evaluated as an Integer.
Description
The FromBCD
operation is used to convert BCDValue to a numeric format and
store the numeric value into Result.
17.5.49 Function
(Declare Control Method)
Syntax
Function (FunctionName, ReturnType, ParameterTypes)
{TermList}
Arguments
ReturnType is
optional and specifies the type(s) of the object(s) returned by the method
the method does not return an object, then nothing is specified or UnknownObj
is specified. To specify a single return type, simply use the ObjectTypeKeyword (e.g. IntObj, PkgObj
>, etc.). To specify multiple possible return types,
enclose the comma-separated ObjectTypeKeywords with braces
example: {IntObj, BuffObj}.
ParameterTypes
specifies both the number and type of the method parameters. It is a comma-separated, variable-length list of the
expected object type or types for each of the method parameters, enclosed in
braces. For each parameter, the parameter type consists of either an ObjectTypeKeyword or a comma-separated sub-list of ObjectTypeKeywords
style='font-style:normal'> enclosed in braces. There can be no more than seven
parameters in total.
Description
Function declares a
named package containing a series of terms that collectively represent a
control method. A control method is a procedure that can be invoked to perform
computation. Function opens a
name scope
System software executes a control method by executing the
terms in the package in order. For more information on method execution, see
section 5.5.2, "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.
Functions are equivalent to a Method that specifies NotSerialized
>.
Compatibility Note:New for ACPI 3.0
Example
The following block of ASL
sample code shows the use of Function for defining a control method:
Function (EXAM, IntObj, {StrObj,
{IntObj, StrObj}})
{
Name (Temp,"")
Store (Arg0, Temp) //
could have used Arg1
Return (SizeOf
(Concatenate (Arg1, Temp)))
}
This declaration is equivalent to:
Method (EXAM, 2, NotSerialized, 0,
IntObj, {StrObj, {IntObj, StrObj}})
{
…
}
17.5.50 If (Conditional Execution)
Syntax
If (Predicate) {
>TermList}
Arguments
Predicate is
evaluated as an Integer.
Description
If the Predicate is
non-zero, the term list of the If term
is executed.
Example
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)
}
17.5.51 Include (Include Additional ASL File)
Syntax
Include (FilePathName)
Arguments
FilePathname is a
StringData data type that contains the full OS file system path.
Description
Include another file that contains ASL terms to be inserted
in the current file of ASL terms. The file must contain elements that are
grammatically correct in the current scope.
Example
Include ("dataobj.asl")
17.5.52
Increment (Integer Increment)
Syntax
Increment
(Addend) =>Integer
Arguments
Addend is
evaluated as an Integer.
Description
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.
17.5.53
Index (Indexed Reference To Member Object)
Syntax
Index (
class=StyleSyntaxElementItalicCharChar>Source, Index,
class=StyleSyntaxElementItalicCharChar>Destination) =>ObjectReference
Arguments
Source is
evaluated to a buffer, string, or package data type. Index is evaluated to an integer
reference to the nth object (where n = Index) within Source is
optionally stored as a reference into Destination.
Description
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.
17.5.53.1 Index with Packages
The following example ASL code shows a way to use the Index term to store into a local variable the sixth
element of the first package of a set of nested packages:
Name (IO0D, Package () {
Package () {
0x01, 0x03F8,
0x03F8, 0x01, 0x08, 0x01, 0x25, 0xFF, 0xFE, 0x00, 0x00
},
Package () {
0x01, 0x02F8,
0x02F8, 0x01, 0x08, 0x01, 0x25, 0xFF, 0xBE, 0x00, 0x00
},
Package ()
{
0x01,
0x03E8, 0x03E8, 0x01, 0x08, 0x01, 0x25, 0xFF, 0xFA, 0x00, 0x00
},
Package ()
{
x01,
0x02E8, 0x02E8, 0x01, 0x08, 0x01, 0x25, 0xFF, 0xBA, 0x00, 0x00
},
Package() {
0x01, 0x0100,
0x03F8, 0x08, 0x08, 0x02, 0x25, 0x20, 0x7F, 0x00, 0x00,
}
})
// Get the 6th element of the first package
Store (DeRefOf (Index (DeRefOf (Index (IO0D,
0)), 5)), Local0)
Note: DeRefOf is
necessary in the first operand of the Store operator 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.
17.5.53.2 Index with Buffers
The following example ASL code shows a way to store into
the third byte of a buffer:
Name (BUFF, Buffer () {0x01, 0x02, 0x03,
0x04, 0x05})
// Store 0x55 into the third byte of the
buffer
Store (0x55, Index (BUFF, 2))
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
style='font-style:normal'> 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))
The following will store 0x41 (an 'A') into the 4th
byte of the destination buffer:
Store ("ABCDEFGH", Index (BUFF, 3))
Compatibility Note:
First introduced in ACPI 2.0. In ACPI 1.0, the behavior of storing data larger
than 8-bits into a buffer using Index was undefined.
17.5.53.3 Index with Strings
The following example ASL code shows a way to store into
the 3rd character in a string:
Name (STR, "ABCDEFGHIJKL")
// Store 'H' (0x48) into the third character
to the string
Store ("H", Index (STR, 2))
The Index operator
returns a reference to an 8-bit Buffer Field (similar to that created using CreateByteField).
Compatibility Note:
First introduced in ACPI 2.0.
17.5.54 IndexField (Declare
Index/Data Fields)
Syntax
IndexField
(IndexName,
DataName, AccessType, LockRule, UpdateRule) {FieldUnitList}
Arguments
IndexName and DataName
refer to field unit objects. AccessType, LockRule,
UpdateRule, and FieldList are the same format as the Field term.
Description
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.
The value written to the IndexName register is defined to be a byte offset that is
aligned on an AccessType boundary.
For example, if AccessType is DwordAcc,
valid index values are 0, 4, 8, etc. This value is always a byte offset and is
independent of the width or access type of the DataName register.
Example
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 a 256-byte
operational region in SystemIO space
// and name it GIO0
OperationRegion
(GIO0, 1, 0x125, 0x100)
// Create a 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
17.5.55 Interrupt (Interrupt
Resource Descriptor Macro)
Syntax
Interrupt
(ResourceUsage,
EdgeLevel, ActiveLevel, Shared, ResourceSourceIndex, ResourceSource,
DescriptorName) {InterruptList
class=StyleSyntaxElementBoldCharChar>} => Buffer
Arguments
ResourceUsage
describes whether the device consumes the specified interrupt (ResourceConsumer)
or produces it for use by a child device (ResourceProducer). If nothing is specified, then ResourceConsumer is
assumed.
EdgeLevel describes
whether the interrupt is edge triggered (Edge) or level triggered
(Level). The field DescriptorName.
_HE is automatically created to refer to this portion of the resource
descriptor, where '1' is Edge and '0' is Level.
ActiveLevel
describes whether the interrupt is active-high (ActiveHigh) or
active-low (ActiveLow). The field DescriptorName.
_LL is automatically created to refer to this portion of the resource
descriptor, where '1' is ActiveHigh and '0' is ActiveLow.
Shared describes
whether the interrupt can be shared with other devices (Shared)
or not (Exclusive). The field DescriptorName.
_SHR is automatically created to refer to this portion of the resource
descriptor, where '1' is Shared and '0' is Exclusive. If nothing is specified,
then Exclusive is assumed.
ResourceSourceIndex
evaluates to an integer between 0x00 and 0xFF and describes the resource source
index. If it is not specified, then it is not generated. If this argument is
specified, the ResourceSource
argument must also be specified.
ResourceSource evaluates to a string which uniquely identifies the
resource source. If it is not specified, it is not generated. If this argument
style='color:red'>is specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed.
DescriptorName evaluates
to a name string which refers to the entire resource descriptor.
InterruptList is a
comma-delimited list on integers, at least one value is required. Each integer
represents a 32-bit interrupt number. There may be no duplicates in the list
field "DescriptorName. _INT" is
automatically created to refer to this portion of the resource descriptor.
Description
The Interrupt macro
evaluates to a buffer that contains an interrupt resource descriptor
format of the interrupt resource descriptor can be found in "Extended
Interrupt Descriptor " (page 218). The macro is designed to be used inside of a
ResourceTemplate (page 218).
17.5.56
lang=IT>IO (IO Resource Descriptor Macro)
Syntax
IO (Decode,
class=StyleSyntaxElementItalicCharChar>AddressMin, AddressMax,
class=StyleSyntaxElementItalicCharChar>AddressAlignment, RangeLength,
class=StyleSyntaxElementItalicCharChar>DescriptorName) => Buffer
Argument
Decode describes
whether the I/O range uses 10-bit decode (Decode10) or 16-bit
decode (Decode16). The field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is Decode16 and
'0' is Decode10.
AddressMin evaluates
to a 16-bit integer that specifies the minimum acceptable starting address for
the I/O range. It must be an even multiple of AddressAlignment. The field DescriptorName
style='font-style:normal'>._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMax evaluates
to a 16-bit integer that specifies the maximum acceptable starting address for
the I/O range. It must be an even multiple of AddressAlignment. The field DescriptorName
style='font-style:normal'>._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressAlignment
evaluates to an 8-bit integer that specifies the alignment granularity for the
I/O address assigned. The field DescriptorName. _ALN is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to an 8-bit integer that specifies the number of bytes in the I/O
range. The field DescriptorName.
_LEN is automatically created to refer to this portion of the resource
descriptor.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
.
Description
The IO macro evaluates
to a buffer which contains an IO resource descriptor. The format of the IO
descriptor can be found in "I/O Port Descriptor" (page 204). The macro
is designed to be used inside of a ResourceTemplate (page 218).
17.5.57 IRQ (Interrupt Resource Descriptor
Macro)
Syntax
IRQ
(EdgeLevel, ActiveLevel, Shared,
DescriptorName) {InterruptList} => Buffer
Arguments
EdgeLevel describes
whether the interrupt is edge triggered (Edge) or level triggered
(Level). The field DescriptorName.
_HE is automatically created to refer to this portion of the resource descriptor,
where '1' is Edge and ActiveHigh and '0' is Level
>and ActiveLow.
ActiveLevel
describes whether the interrupt is active-high (ActiveHigh) or
active-low (ActiveLow). The field DescriptorName.
_LL is automatically created to refer to this portion of the resource
descriptor, where '1' is Edge and ActiveHigh and '0' is Level
>and ActiveLow.
Shared describes
whether the interrupt can be shared with other devices (Shared)
or not (Exclusive). The field DescriptorName.
_SHR is automatically created to refer to this portion of the resource
descriptor, where '1' is Shared and '0'is Exclusive. If nothing is
specified, then Exclusive is
assumed.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
.
InterruptList is a
comma-delimited list of integers in the range 0 through 15, at least one value
is required. There may be no duplicates in the list.
Description
The IRQ macro
evaluates to a buffer that contains an IRQ resource descriptor. The format of the
IRQ descriptor can be found in "IRQ Descriptor" (page 201). The macro
produces the three-byte form of the descriptor. The macro is designed to be
used inside of a ResourceTemplate (page 218).
17.5.58 IRQNoFlags (Interrupt Resource Descriptor Macro)
Syntax
IRQNoFlags
(DescriptorName)
{InterruptList} => Buffer
Arguments
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer.
InterruptList is a
comma-delimited list of integers in the range 0 through 15, at least one value
is required. There may be no duplicates in the list Description
The IRQNoFlags
macro evaluates to a buffer which contains an active-high, edge-triggered IRQ
resource descriptor. The format of the IRQ descriptor can be found in IRQ
Descriptor (page 201). The macro produces the two-byte form of the descriptor.
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.59 LAnd (Logical And)
Syntax
LAnd (Source1,
class=StyleSyntaxElementItalicCharChar>Source2) =>Boolean
Arguments
Source1 and source2 are evaluated as integers.
Description
If both values are non-zero, True is returned: otherwise, False
is returned.
17.5.60 LEqual (Logical Equal)
Syntax
LEqual (Source1,
class=StyleSyntaxElementItalicCharChar>Source2) =>Boolean
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2. Source2 is implicitly converted if necessary to match the type
of Source1.
Description
If the values are equal, True is returned; otherwise, False
is returned. For integers, a numeric compare is performed. For strings and
buffers, True is returned only if both lengths are the same and the result of a
byte-wise compare indicates exact equality.
17.5.61
LGreater (Logical Greater)
Syntax
LGreater (Source1,
class=StyleSyntaxElementItalicCharChar>Source2) => Boolean
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2. Source2 is implicitly converted if necessary to match the type
of Source1.
Description
If Source1 is
greater than Source2, True is returned; otherwise, False is returned
integers, a numeric comparison is performed. For strings and buffers, a
lexicographic comparison is performed. True is returned if a byte-wise (unsigned) compare discovers
at least one byte in Source1 that is numerically greater than the
corresponding byte in Source2. False
is returned if at least one byte in Source1
is numerically less than the corresponding byte in Source2. In the case of byte-wise equality, True
is returned if the length of Source1 is
greater than Source2, False
is returned if the length of Source1 is
less than or equal to Source2.
17.5.62 LGreaterEqual (Logical
Greater Than Or Equal)
Syntax
LGreaterEqual
(Source1, Source2)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2. Source2 is implicitly converted if necessary to match the type
of Source1.
Description
If Source1 is
greater than or equal to Source2,
True is returned; otherwise, False is
returned. Equivalent to LNot(LLess()).
See the description of the LLess operator.
17.5.63
LLess (Logical Less)
Syntax
LLess (Source1,
class=StyleSyntaxElementItalicCharChar>Source2) =>Boolean
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2. Source2 is implicitly converted if necessary to match the type
of Source1.
Description
If Source1 is
less than Source2, True
is returned; otherwise, False is returned. For integers, a numeric comparison
is performed. For strings and buffers, a lexicographic comparison is
performed. True is returned if a
byte-wise (unsigned) compare discovers at least one byte in Source1
that is numerically less than the corresponding byte in Source2. False is returned if at least one
byte in Source1 is numerically greater
than the corresponding byte in Source2. In the case of byte-wise equality, True is returned if the
length of Source1 is less than Source2, False is returned if the length of Source1
style='font-style:normal'> is greater than or equal to Source2.
17.5.64
LLessEqual (Logical Less Than Or Equal)
Syntax
LLessEqual
(Source1, Source2)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2. Source2 is implicitly converted if necessary to match the type
of Source1.
Description
If Source1 is
less than or equal to Source2,
True is returned; otherwise False is returned. Equivalent to LNot(LGreater()). See the description
of the LGreater operator.
17.5.65
LNot (Logical Not)
Syntax
LNot (Source)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
Source1 is
evaluated as an integer.
Description
If the value is zero True
is returned; otherwise, False is returned.
17.5.66 LNotEqual (Logical Not Equal)
)
Syntax
LNotEqual
(Source1, Source2)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
Source1 and Source2
style='font-style:normal'> must each evaluate to an integer, a
string, or a buffer. The data
type of Source1
dictates the required type of Source2. Source2 is implicitly converted if necessary to match the type
of Source1.
Description
If Source1 is
not equal to Source2, True is returned; otherwise False is returned. Equivalent
to LNot(LEqual()).See the
description of the LEqual operator.
17.5.67 Load (Load Definition Block)
Syntax
Load (Object, DDBHandle)
Arguments
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 an ACPI
DESCRIPTION_HEADER of type SSDT. The Definition Block must be totally contained
within the supplied operation region or operation region field. OSPM reads this
table into memory, the checksum is verified, and then it is loaded into the
ACPI namespace. The DDBHandle
parameter is the handle to the Definition Block that can be used to unload the
Definition Block at a future time.
Description
Performs a run-time load of a Definition Block. Any table
referenced by Load must be in memory
marked as AddressRangeReserved or AddressRangeNVS.
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.
17.5.68 LoadTable (Load Definition Block From XSDT)
Syntax
LoadTable
(SignatureString,
OEMIDString, OEMTableIDString, RootPathString, ParameterPathString,
ParameterData) => DDBHandle
Arguments
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
style='font-style:normal'>.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.
Description
Performs a run-time load of a Definition Block from the
XSDT. Any table referenced by LoadTable
must be in memory marked by AddressRangeReserved or AddressRangeNVS. Note: OSPM
loads the DSDT and all SSDTs during initialization. As such, Definition Blocks
to be conditionally loaded via LoadTable must contain signatures other than "SSDT".
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.
Example
Store
(LoadTable ("OEM1", "MYOEM", "TABLE1", "\\_SB.PCI0","MYD",
Package () {0,"\\_SB.PCI0"}), Local0)
This operation 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.
17.5.69 Localx (Method
Local Data Objects)
Syntax
Local0
| Local1 | Local2 |
class=StyleSyntaxElementBoldCharChar>Local3 | Local4 |
class=StyleSyntaxElementBoldCharChar>Local5 | Local6 |
class=StyleSyntaxElementBoldCharChar>Local7
Description
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.
17.5.70 LOr (Logical Or)
Syntax
LOr (Source1,
class=StyleSyntaxElementItalicCharChar>Source2) =>Boolean
Arguments
Source1 and
Source2 are evaluated as
integers.
Description
If either value is non-zero, True is returned; otherwise, False is returned.
17.5.71
Match (Find Object Match)
Syntax
Match (SearchPackage, Op1, MatchObject1, Op2,
MatchObject2, StartIndex) =>
class=StyleSyntaxElementBoldCharChar>Ones | Integer
Arguments
SearchPackage is
evaluated to a package object and is treated as a one-dimension array. Each
package element must evaluate to either an integer, a string, or a buffer.
Uninitialized package elements and elements that do not evaluate to integers,
strings, or buffers are ignored. Op1 and
Op2 are match operators.
MatchObject1 and MatchObject2 are the objects to be matched and must each evaluate
to either an integer, a string, or a buffer. StartIndex is the starting index within the SearchPackage
style='font-style:normal'>.
Description
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
style='font-style:normal'> being compared against is called P[i], then the comparison is:
If
(P[i]
style='font-size:90%;font-family:"Courier New"'>Op1
style='font-size:90%;font-family:"Courier New"'>MatchObject1) and (
style='font-size:90%;font-family:"Courier New"'>P[i]
style='font-size:90%;font-family:"Courier New"'>Op2
style='font-size:90%;font-family:"Courier New"'>MatchObject2) then Match =>
style='font-size:90%;font-family:"Courier New"'> i is returned.
If the comparison succeeds, the index of the element that
succeeded is returned; otherwise, the constant object Ones is returned. The data type of the MatchObject
dictates the required type of the package element. If necessary, the package
element is implicitly converted to match the type of the MatchObject. If the
implicit conversion fails for any reason, the package element is ignored (no
match.)
Op1 and
Op2 have the values and meanings listed in the Table 17-19.
Table 17-19 Match Term Operator Meanings
Operator
|
Encoding
|
Macro
|
TRUE – A don't care, always returns
TRUE
|
0
|
MTR
|
EQ – Returns TRUE if P[i] ==
MatchObject
|
1
|
MEQ
|
LE – Returns TRUE if P[i] <=
MatchObject
|
2
|
MLE
|
LT – Returns TRUE if P[i] < MatchObject
|
3
|
MLT
|
GE – Returns TRUE if P[i] >=
MatchObject
|
4
|
MGE
|
GT – Returns TRUE if P[i] > MatchObject
|
5
|
MGT
|
Example
Following are some example uses of Match:
Name (P1,
Package () {1981, 1983, 1985, 1987, 1989,
1990, 1991, 1993, 1995, 1997, 1999}
)
// match 1993 == P1[i]
Match (P1, MEQ, 1993, MTR, 0, 0) //
-> 7, since P1[7] == 1993
// match 1984 == P1[i]
Match (P1, MEQ, 1984, MTR, 0, 0) //
-> ONES (not found)
// match P1[i] > 1984 and P1[i]
<= 2000
Match (P1, MGT, 1984, MLE, 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, 3) //
-> 3, first match at or past Start
17.5.72 Memory24 (Memory Resource
Descriptor Macro)
Syntax
Memory24 (ReadAndWrite,
class=StyleSyntaxElementItalicCharChar>AddressMinimum, AddressMaximum,
class=StyleSyntaxElementItalicCharChar>AddressAlignment, RangeLength,
class=StyleSyntaxElementItalicCharChar>DescriptorName)
Arguments
ReadAndWrite
specifies whether or not the memory region is read-only (ReadOnly)
or read/write (ReadWrite). If nothing
is specified, then ReadWrite is assumed. The 1-bit field DescriptorName._RW
is automatically created to refer to this portion of the resource descriptor,
where '1' is ReadWrite and '0' is ReadOnly.
AddressMinimum
evaluates to a 16-bit integer that specifies bits [8:23] of the lowest possible
base address of the memory range. All other bits are assumed to be zero
value must be an even multiple of AddressAlignment. The 16-bit field DescriptorName
style='font-style:normal'>._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 16-bit integer that specifies bits [8:23] of the highest possible base
address of the memory range. All other bits are assumed to be zero. The value
must be an even multiple of AddressAlignment. The 16-bit field DescriptorName
style='font-style:normal'>._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressAlignment
evaluates to a 16-bit integer that specifies bits [0:15] of the required
alignment for the memory range. All other bits are assumed to be zero
address selected must be an even multiple of this value. The 16-bit field DescriptorName. _ALN is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 16-bit integer that specifies the total number of bytes decoded
in the memory range. The 16-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The Memory24 macro
evaluates to a buffer which contains an 24-bit memory descriptor. The format of
the 24-bit memory descriptor can be found in "24-Bit Memory Range
Descriptor " (page 208). The macro is designed to be used inside of a ResourceTemplate
(page 218).
NOTE: The use of Memory24 is deprecated and should not be used in new designs.
17.5.73 Memory32 (Memory Resource
Descriptor Macro)
Syntax
Memory32 (ReadAndWrite,
class=StyleSyntaxElementItalicCharChar>AddressMinimum, AddressMaximum,
class=StyleSyntaxElementItalicCharChar>AddressAlignment, RangeLength,
class=StyleSyntaxElementItalicCharChar>DescriptorName)
Arguments
ReadAndWrite
specifies whether or not the memory region is read-only (ReadOnly)
or read/write (ReadWrite). If nothing
is specified, then ReadWrite is assumed. The 1-bit field DescriptorName._RW
is automatically created to refer to this portion of the resource descriptor,
where '1' is ReadWrite and '0' is ReadOnly.
AddressMinimum
evaluates to a 32-bit integer that specifies the lowest possible base address
of the memory range. The value must be an even multiple of AddressAlignment. The 32-bit field DescriptorName
style='font-style:normal'>._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 32-bit integer that specifies the highest possible base address of the
memory range. The value must be an even multiple of AddressAlignment. The 32-bit field DescriptorName
style='font-style:normal'>._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressAlignment
evaluates to a 32-bit integer that specifies the required alignment for the
memory range. The address selected must be an even multiple of this value
32-bit field DescriptorName. _ALN
is automatically created to refer to this portion of the resource descriptor.
RangeLength
evaluates to a 32-bit integer that specifies the total number of bytes decoded
in the memory range. The 32-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The Memory32 macro
evaluates to a buffer which contains a 32-bit memory descriptor, which
describes a memory range with a minimum, a maximum and an alignment. The format
of the 32-bit memory descriptor can be found in "32-Bit Memory Range
Descriptor " (page 209). The macro is designed to be used inside of a ResourceTemplate
(page 218).
17.5.74 Memory32Fixed (Memory Resource Descriptor Macro)
Syntax
Memory32Fixed
(ReadAndWrite,
AddressBase, RangeLength,
class=StyleSyntaxElementItalicCharChar>DescriptorName)
Arguments
ReadAndWrite
specifies whether or not the memory region is read-only (ReadOnly)
or read/write (ReadWrite). If nothing
is specified, then ReadWrite is assumed. The 1-bit field DescriptorName._RW
is automatically created to refer to this portion of the resource descriptor,
where '1' is ReadWrite and '0' is ReadOnly.
AddressBase
evaluates to a 32-bit integer that specifies the base address of the memory
range. The 32-bit field DescriptorName. _BAS is automatically created to refer to this portion of the
resource descriptor.
RangeLength
evaluates to a 32-bit integer that specifies the total number of bytes decoded
in the memory range. The 32-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The Memory32Fixed macro
evaluates to a buffer which contains a 32-bit memory descriptor, which
describes a fixed range of memory addresses. The format of the fixed 32-bit
memory descriptor can be found in 32-Bit Fixed Memory Range Descriptor
(page 210). The macro is designed to be used inside of a ResourceTemplate (page
218).
17.5.75 Method (Declare Control Method)
Syntax
Method (MethodName, NumArgs, SerializeRule,
SyncLevel, ReturnType, ParameterTypes) {TermList}
Arguments
Creates a new control method of name MethodName.
MethodName is evaluated as a Namestring
data type. NumArgs is evaluated
as an integer data type.
ReturnType is
optional and specifies the type(s) of the object(s) returned by the method
the method does not return an object, then nothing is specified or UnknownObj
is specified. To specify a single return type, simply use the ObjectTypeKeyword (e.g. IntObj, PkgObj
>, etc.). To specify multiple possible return types,
enclose the comma-separated ObjectTypeKeywords with braces
example: {IntObj, BuffObj}
style='font-size:90%'>.
ParameterTypes is
optional and specifies the type of the method parameters. It is a comma-separated, variable-length list of the expected
object type or types for each of the method parameters, enclosed in braces
each parameter, the parameter type consists of either an ObjectTypeKeyword or a comma-separated sub-list of ObjectTypeKeywords
style='font-style:normal'> enclosed in braces. If ParameterTypes is specified, the number of parameters must match NumArgs
style='font-style:normal'>.
Description
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 method execution,
see section 5.5.2, "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
style='font-style:normal'> 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.
Example
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) // assert power
Sleep (10)
// wait 10ms
Store (One,
GIO.IDER) // de-assert reset#
Stall (10)
// wait 10us
Store
(Zero, GIO.IDEI) // de-assert isolation
}
17.5.76 Mid (Extract Portion of Buffer
or String)
Syntax
Mid (Source,
class=StyleSyntaxElementItalicCharChar>Index, Length,
class=StyleSyntaxElementItalicCharChar>Result) => Buffer or String
Arguments
Source is evaluated
as either a Buffer or String. Index and
Length are evaluated as Integers.
Description
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.
17.5.77 Mod (Integer Modulo)
Syntax
Mod (Dividend, Divisor, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Dividend and Divisor are evaluated as Integers.
Description
The Dividend is
divided by Divisor, and then the
resulting remainder is optionally stored into Result. If Divisor evaluates to zero, a fatal exception is generated.
17.5.78 Multiply (Integer Multiply)
Syntax
Multiply (Multiplicand, Multiplier, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Multiplicand and
Multiplier are evaluated as Integers.
Description
The Multiplicand is
multiplied by Multiplier and
the result is optionally stored into Result. Overflow conditions are ignored and results are undefined.
17.5.79 Mutex (Declare Synchronization/Mutex Object)
Syntax
Mutex (MutexName, SyncLevel)
Arguments
Creates a data mutex synchronization object named MutexName, with level from 0 to 15 specified by SyncLevel
style='font-style:normal'>.
Description
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 of a thread before acquiring any mutexes is
zero. The SyncLevel of the Global Lock (\_GL) is zero.
17.5.80 Name
(Declare Named Object)
Syntax
Name
(ObjectName, Object)
Arguments
Creates a new object named ObjectName. Attaches Object to ObjectName in the
Global ACPI namespace.
Description
Creates ObjectName
in the namespace, which references the Object.
Example
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)
17.5.81 NAnd
(Integer Bitwise Nand)
Syntax
NAnd (Source1,
class=StyleSyntaxElementItalicCharChar>Source2, Result)
> => Integer
Arguments
Source1 and
Source2 are evaluated as
Integers.
Description
A bitwise NAND
is performed and the result is optionally
stored in Result.
17.5.82 NoOp Code (No Operation)
Syntax
NoOp
Description
This operation has no effect.
17.5.83
NOr (Integer Bitwise Nor)
Syntax
NOr (Source1, Source2, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Source1 and
Source2 are evaluated as
Integers.
Description
A bitwise NOR is
performed and the result is optionally stored in Result.
17.5.84
Not (Integer Bitwise Not)
Syntax
Not (Source,
class=StyleSyntaxElementItalicCharChar>Result) =>Integer
Arguments
Source is evaluated
as an integer data type.
Description
A bitwise NOT is
performed and the result is optionally stored in Result.
17.5.85 Notify (Notify Object of Event)
Syntax
Notify (Object, NotificationValue)
Arguments
Notifies the OS that the NotificationValue for the Object has occurred. Object
must be a reference to a device, processor, or thermal zone object.
Description
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."
17.5.86
ObjectType (Get Object Type)
Syntax
ObjectType
(Object) =>Integer
Arguments
Object is any valid
object.
Description
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 17-20. 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
typeless objects such as predefined scope names (in other words, \_SB, \_GPE,
etc.), the type value 0 (Uninitialized) is returned.
Table 17-20 Values Returned By the
ObjectType Operator
Value
|
Meaning
|
0
|
Uninitialized
|
1
|
Integer
|
2
|
String
|
3
|
Buffer
|
4
|
Package
|
5
|
Field Unit
|
6
|
Device
|
7
|
Event
|
8
|
Method
|
9
|
Mutex
|
10
|
Operation Region
|
11
|
Power Resource
|
12
|
Processor
|
13
|
Thermal Zone
|
14
|
Buffer Field
|
15
|
DDB Handle
|
16
|
Debug Object
|
>16
|
Reserved
|
17.5.87 One (Constant One Object)
Syntax
One
Description
The constant One
object is an object of type Integer that will always read the LSB as set and
all other bits as clear (that is, the value of 1). Writes to this object are
not allowed.
17.5.88 Ones (Constant Ones Object)
Syntax
Ones
Description
The constant Ones
object is an object of type Integer that will always read as all bits set.
Writes to this object are not allowed.
17.5.89 OperationRegion (Declare
Operation Region)
Syntax
OperationRegion
(RegionName, RegionSpace,
Offset, Length)
Arguments
Declares an operation region named RegionName. Offset
is the offset within the selected RegionSpace at which the region starts (byte-granular), and Length
style='font-style:normal'> is the length of the region in bytes.
Description
An Operation Region is a type of data object where read or
write operations to the data object are performed in some hardware space
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.
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.
Example
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#
}
17.5.90 Or
(Integer Bitwise Or)
Syntax
Or (Source1, Source2, Result)
> => Integer
Arguments
Source1 and
Source2 are evaluated as
Integers.
Description
A bitwise OR is
performed and the result is optionally stored in Result.
17.5.91 Package (Declare Package Object)
Syntax
Package (NumElements) {
>PackageList} => Package
Arguments
NumElements is
evaluated as an integer data type. PackageList is an initializer list of objects.
Description
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.
Examples
Example 1:
Package () {
3,
9,
"ACPI 1.0
COMPLIANT",
Package () {
"CheckSum=>",
Package
() {7, 9}
},
0
}
Example 2: This example defines and initializes a
two-dimensional array.
Package () {
Package () {11, 12,
13},
Package () {21, 22, 23}
}
Example 3: 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 was first introduced in ACPI 2.0. ACPI 1.0
only allowed fixed-size packages with up to 255 elements.
17.5.92 PowerResource (Declare
Power Resource)
Syntax
PowerResource
(ResourceName,
SystemLevel, ResourceOrder) {ObjectList}
Arguments
Declares a power resource named ResourceName. PowerResource opens a name scope.
Description
For a definition of the PowerResource term, see section 7.1, "Declaring a Power Resource
Object."
17.5.93 Processor (Declare
Processor)
Syntax
Processor
(ProcessorName,
ProcessorID, PBlockAddress, PblockLength) {ObjectList}
Arguments
Declares a named processor object named ProcessorName. Processor opens a name scope. Each
processor is required to have a unique ProcessorID value that is unique from any other ProcessorID
style='font-style:normal'> value.
For each processor in the system, the ACPI BIOS declares
one processor object in the namespace anywhere within the \_SB scope
compatibility with operating systems implementing ACPI 1.0, the processor
object may also be declared under the \_PR scope. An ACPI-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. It is valid for every processor to have a PBlockLength of 0.
Description
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, _PPC, _PSD, _TSD,
_CSD, _PDC, _TPC, _TSS, and _OSC. 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 Power and
Performance State Configuration and Control."
17.5.94 QWordIO (QWord IO Resource Descriptor Macro)
Syntax
QWordIO (ResourceUsage,
class=StyleSyntaxElementItalicCharChar>IsMinFixed, IsMaxFixed,
class=StyleSyntaxElementItalicCharChar>Decode, ISARanges,
class=StyleSyntaxElementItalicCharChar>AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation,
RangeLength, ResourceSourceIndex, ResourceSource,
DescriptorName, TranslationType, TranslationDensity)
Arguments
ResourceUsage
specifies whether the I/O range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
IsMinFixed specifies whether the minimum address of this I/O range is
fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this I/O range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
Decode specifies
whether or not the device decodes the I/O range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
ISARanges specifies
whether the I/O ranges specifies are limited to valid ISA I/O ranges (ISAOnly),
valid non-ISA I/O ranges (NonISAOnly)
or encompass the whole range without limitation (EntireRange). The 2-bit field DescriptorName._RNG
is automatically created to refer to this portion of the resource descriptor,
where '1' is NonISAOnly, '2' is ISAOnly and '0' is EntireRange.
AddressGranularity
evaluates to a 64-bit integer that specifies the power-of-two boundary (- 1) on
which the I/O range must be aligned. The 64-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 64-bit integer that specifies the lowest possible base address
of the I/O range. The value must have '0' in all bits where the corresponding
bit in AddressGranularity is '1'.
For bridge devices which translate addresses, this is the address on the
secondary bus. The 64-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 64-bit integer that specifies the highest possible base address of the I/O
range. The value must have '0' in all bits where the corresponding bit in AddressGranularity is '1'. For bridge devices which translate
addresses, this is the address on the secondary bus. The 64-bit field DescriptorName._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressTranslation
evaluates to a 64-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 64-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 64-bit integer that specifies the total number of bytes decoded
in the I/O range. The 64-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this I/O range is allocated. If
this argument is
specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is Memory. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName. _TTP is automatically
created to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more information
TranslationDensity is an optional argument that specifies whether or
not the translation from the primary to secondary bus is sparse (SparseTranslation)
or dense (DenseTranslation). It is only
used when TranslationType is TypeTranslation. If nothing is specified, then DenseTranslation is
assumed. The 1-bit field DescriptorName. _TRS is automatically
created to refer to this portion of the resource descriptor, where '1' is
SparseTranslation and '0' is DenseTranslation. See _TRS (page 218) for more
information.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined descriptor
field names may be appended to this name to access individual fields within the
descriptor via the Buffer Field operators.
Description
The QWordIO macro
evaluates to a buffer which contains a 64-bit I/O resource descriptor, which
describes a range of I/O addresses. The format of the 64-bit I/O resource
descriptor can be found in QWord Address Space Descriptor (page 212).
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.95 QWordMemory (QWord Memory Resource Descriptor Macro)
Syntax
QWordMemory
(ResourceUsage,
Decode, IsMinFixed, IsMaxFixed, Cacheable, ReadAndWrite, AddressGranularity,
AddressMinimum, AddressMaximum, AddressTranslation, RangeLength,
ResourceSourceIndex, ResourceSource, DescriptorName, MemoryType,
TranslationType)
Arguments
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the Memory range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this Memory range
is fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this Memory range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
Cacheable specifies
whether or not the memory region is cacheable (Cacheable), cacheable
and write-combining (WriteCombining),
cacheable and prefetchable (Prefetchable) or uncacheable (NonCacheable). If nothing is specified, then NonCacheable is assumed. The 2-bit
field DescriptorName. _MEM is automatically created to refer to
this portion of the resource descriptor, where '1' is Cacheable, '2' is
WriteCombining, '3' is Prefetchable and '0' is NonCacheable.
ReadAndWrite
specifies whether or not the memory region is read-only (ReadOnly)
or read/write (ReadWrite). If nothing
is specified, then ReadWrite is assumed. The 1-bit field DescriptorName._RW
is automatically created to refer to this portion of the resource descriptor,
where '1' is ReadWrite and '0' is ReadOnly.
AddressGranularity
evaluates to a 64-bit integer that specifies the power-of-two boundary (- 1) on
which the Memory range must be aligned. The 64-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 64-bit integer that specifies the lowest possible base address
of the Memory range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 64-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 64-bit integer that specifies the highest possible base address of the
Memory range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 64-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 64-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 64-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 64-bit integer that specifies the total number of bytes decoded
in the Memory range. The 64-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this Memory range is allocated. If this argument is specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed
style='font-size:110%'>.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
MemoryType is an optional argument that specifies the memory
usage. The memory can be marked as normal (AddressRangeMemory),
used as ACPI NVS space (AddressRangeNVS),
used as ACPI reclaimable space (AddressRangeACPI) or as system reserved (AddressRangeReserved
>). If nothing is specified, then AddressRangeMemory
is assumed. The 2-bit field DescriptorName. _MTP is automatically
created in order to refer to this portion of the resource descriptor, where '0'is AddressRangeMemory, '1' is AddressRangeReserved, '2' is AddressRangeACPI and
'3' is AddressRangeNVS.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is I/O. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName. _TTP is automatically
created to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more
information.
Description
The QWordMemory macro
evaluates to a buffer which contains a 64-bit memory resource descriptor, which
describes a range of memory addresses. The format of the 64-bit memory resource
descriptor can be found in "QWord Address Space Descriptor " (page 212).
The macro is designed to be used inside of a ResourceTemplate (page 218).
17.5.96 QWordSpace (QWord Space Resource Descriptor Macro)
Syntax
QWordSpace
(ResourceType, ResourceUsage, Decode, IsMinFixed,
IsMaxFixed, TypeSpecificFlags, AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation, RangeLength, ResourceSourceIndex,
ResourceSource, DescriptorName)
Arguments
ResourceType evaluates
to an 8-bit integer that specifies the type of this resource. Acceptable values
are 0xC0 through 0xFF.
ResourceUsage
specifies whether the Memory range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the Memory range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this Memory range
is fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this Memory range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
TypeSpecificFlags
evaluates to an 8-bit integer. The flags are specific to the ResourceType.
AddressGranularity
evaluates to a 64-bit integer that specifies the power-of-two boundary (- 1) on
which the Memory range must be aligned. The 64-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 64-bit integer that specifies the lowest possible base address
of the Memory range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 64-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 64-bit integer that specifies the highest possible base address of the
Memory range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 64-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 64-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 64-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 64-bit integer that specifies the total number of bytes decoded
in the Memory range. The 64-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this Memory range is allocated. If this argument is specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed
style='font-size:110%'>.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The QWordSpace macro
evaluates to a buffer which contains a 64-bit Address Space resource
descriptor, which describes a range of addresses. The format of the 64-bit
AddressSpace descriptor can be found in "QWord Address Space Descriptor "
(page 212). The macro is designed to be used inside of a ResourceTemplate (page
218).
17.5.97 RefOf (Create Object Reference)
Syntax
RefOf (Object)
class=StyleSyntaxElementBoldCharChar> =>ObjectReference
Arguments
Object can be any
object type (for example, a package, a device object, and so on).
Description
Returns an object reference to Object. 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 the method without the object being evaluated at the time the
method was loaded.
17.5.98 Register
(Generic Register Resource Descriptor Macro)
Syntax
Register
(AddressSpaceKeyword,
RegisterBitWidth, RegisterBitOffset,
class=StyleSyntaxElementItalicCharChar>RegisterAddress, AccessSize, DescriptorName)
Arguments
AddressSpaceKeyword specifies
the address space where the register exists. The register can exist in I/O
space (SystemIO), memory (SystemMemory), PCI configuration space (PCI_Config
>), embedded controller space (EmbeddedControl), SMBus (SMBus) or fixed-feature hardware (FFixedHW). The 8-bit field DescriptorName.
_ASI is automatically created in order to refer to this portion of the resource
descriptor. See _ASI (page 218) for more information, including a list of valid
values and their meanings.
RegisterBitWidth
evaluates to an 8-bit integer that specifies the number of bits in the
register. The 8-bit field DescriptorName. _RBW is automatically created in order to refer to this portion of
the resource descriptor. See _RBW (page 218) for more information.
RegisterBitOffset
evaluates to an 8-bit integer that specifies the offset in bits from the start
of the register indicated by RegisterAddress. The 8-bit field DescriptorName
style='font-style:normal'>. _RBO is automatically created in order to refer to
this portion of the resource descriptor. See _RBO (page 218) for more
information.
RegisterAddress evaluates
to a 64-bit integer that specifies the register address. The 64-bit field DescriptorName. _ADR is automatically created in order to refer to
this portion of the resource descriptor. See _ADR (page 218) for more
information.
AccessSize evaluates
to an 8-bit integer that specifies the size of data values used when accessing
the address space as follows:
0-Undefined (legacy)
1-Byte access
2-Word access
3-Dword access
4-Qword access
The 8-bit field DescriptorName. _ASZ is automatically created in order to refer to
this portion of the resource descriptor. See _ASZ(page 218) for more
information. For backwards compatibility, the AccesSize parameter is optional when invoking the Register
macro. If the AccessSize
parameter is not supplied then the AccessSize field will be set to zero. In this case, OSPM will
assume the access size.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The Register macro
evaluates to a buffer which contains a generic register resource descriptor.
The format of the generic register resource descriptor can be found in "Generic
Register Descriptor " (page 218). The macro is designed to be used inside of a ResourceTemplate
(page 218).
17.5.99 Release (Release a Mutex Synchronization Object)
Syntax
Release (SyncObject)
Arguments
SynchObject must be
a mutex synchronization object.
Description
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.
17.5.100 Reset (Reset an Event Synchronization Object)
Syntax
Reset (SyncObject)
Arguments
SynchObject must
be an Event synchronization object.
Description
This operator is used to reset an event synchronization
object to a non-signaled state. See also the Wait and Signal function operator
definitions.
17.5.101 ResourceTemplate
(Resource To Buffer Conversion Macro)
Syntax
ResourceTemplate
() {ResourceMacroList} => Buffer
Description
For a full definition of the ResourceTemplateTerm macro,
see " ASL Resource Templates" (page 218)
17.5.102 Return (Return from Method Execution)
Syntax
Return
Return
()
Return
(Arg)
Arguments
Arg is optional and can
be any valid object or reference.
Description
Returns control to the invoking control method, optionally
returning a copy of the object named in Arg.
If no Arg object is specified, a
Return(Zero) is generated by the ASL compiler.
Note: in the
absence of an explicit Return ()
statement, the return value to the caller is undefined.
17.5.103 Revision (Constant Revision
Object)
Syntax
Revision
Description
The constant Revision
object is an object of type Integer that will always read as the revision of
the AML interpreter.
17.5.104 Scope (Open Named Scope)
Syntax
Scope (Location) {
>ObjectList}
Arguments
Opens and assigns a base namespace scope to a collection of
objects. All object names defined within the scope act relative to Location. Notice that Location
style='font-style:normal'> does not have to be below the surrounding scope, but
can refer to any location within the namespace. The Scope term
itself does not create objects, but only locates objects in the namespace; the
located objects are created by other ASL terms.
Description
The object referred to by Location must already exist in the namespace and be one of
the following object types that has a namespace scope associated with it:
· Predefined scope such as: \
(root), \_SB, \GPE, \_PR,
\_TZ, etc.
· Device
· Processor
· Thermal Zone
· Power Resource
The Scope term
alters the current namespace location to the existing Location.
This causes the defined objects within ObjectList to occur relative to this 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)
}
places the defined objects in the ACPI namespace as shown:
\PCI0.X
\RQ
\Y
17.5.105 ShiftLeft (Integer Shift Left)
Syntax
ShiftLeft
(Source, ShiftCount,
Result) =>Integer
Arguments
Source and ShiftCount are evaluated as Integers.
Description
Source is shifted
left with the least significant bit zeroed ShiftCount times. The result is optionally stored into Result.
17.5.106 ShiftRight (Integer Shift
Right)
Syntax
ShiftRight
(Source, ShiftCount,
class=StyleSyntaxElementItalicCharChar>Result) => Integer
Arguments
Source and ShiftCount are evaluated as Integers.
Description
Source is
shifted right with the most significant bit zeroed ShiftCount times. The result is optionally stored
into Result.
17.5.107 Signal (Signal a Synchronization Event)
Syntax
Signal (SyncObject)
Arguments
SynchObject must
be an Event synchronization object.
Description
The Event object is signaled once, allowing one invocation
to acquire the event.
17.5.108 SizeOf (Get Data Object Size)
Syntax
SizeOf (ObjectName)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
ObjectName must be a
buffer, string or package object.
Description
Returns the size of a buffer, string, or package data
object.
For a buffer, it returns the size in bytes of the data
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.
17.5.109 Sleep (Milliseconds Sleep)
Syntax
Sleep (MilliSeconds)
Arguments
The Sleep term is
used to implement long-term timing requirements. Execution is delayed for at least the required
number of milliseconds.
Description
The implementation of Sleep is to round the request up to the closest sleep time supported by the
OS and relinquish the processor.
17.5.110 Stall (Stall for a Short Time)
Syntax
Stall (MicroSeconds)
Arguments
The Stall term is
used to implement short-term timing requirements. Execution is delayed for at least the required
number of microseconds.
Description
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
>.
17.5.111 StartDependentFn
(Start Dependent Function Resource Descriptor Macro)
Syntax
StartDependentFn
(CompatibilityPriority,
PerformancePriority) {ResourceList}
Arguments
CompatibilityPriority indicates
the relative compatibility of the configuration specified by ResourceList relative to the PC/AT. 0 = Good, 1 = Acceptable, 2 =
Sub-optimal.
PerformancePriority
indicates the relative performance of the configuration specified by ResourceList relative to the other configurations. 0 = Good, 1 =
Acceptable, 2 = Sub-optimal.
ResourceList is a
list of resources descriptors which must be selected together for this
configuration.
Description
The StartDependentFn macro
evaluates to a buffer which contains a start dependent function resource
descriptor, which describes a group of resources which must be selected
together. Each subsequent StartDependentFn or StartDependentFnNoPri resource
descriptor introduces a new choice of resources for configuring the device,
with the last choice terminated with an EndDependentFn resource descriptor
format of the start dependent function resource descriptor can be found in "Start
Dependent Functions Descriptor" (page 203). This macro generates the two-byte
form of the resource descriptor. The macro is designed to be used inside of a ResourceTemplate
(page 218).
17.5.112 StartDependentFnNoPri (Start Dependent Function Resource
Descriptor Macro)
Syntax
StartDependentFnNoPri
() {ResourceList}
Description
The StartDependentFnNoPri macro evaluates to a buffer which contains a start dependent function
resource descriptor, which describes a group of resources which must be
selected together. Each subsequent StartDependentFn or StartDependentFnNoPri
resource descriptor introduces a new choice of resources for configuring the
device, with the last choice terminated with an EndDependentFn resource
descriptor. The format of the start dependent function resource descriptor can
be found in "Start Dependent Functions Descriptor" (page 203). This
macro generates the one-byte form of the resource descriptor. The macro is
designed to be used inside of a ResourceTemplate (page 218).
This is similar to StartDependentFn (page 218) with both CompatibilityPriority and PerformancePriority
style='font-style:normal'> set to 1, but is one byte shorter.
17.5.113 Store (Store an Object)
Syntax
Store (Source,
class=StyleSyntaxElementItalicCharChar>Destination) =>DataRefObject
Arguments
This operation evaluates Source, converts it to the data type of Destination
style='font-style:normal'>, and writes the result into Destination. For information on automatic data-type conversion,
see section 16.2.2, "ASL Data Types."
Description
Stores to OperationRegion 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 depends on the type of Destination. For
any type other than an operation region field, the execution result is the same
as the data written to Destination. For
operation region fields with an AccessType of ByteAcc, WordAcc,
DWordAcc, QWordAcc or AnyAcc, the execution result is the same as the data written to Destination
as in the normal case, but when the AccessType is BufferAcc, the operation region handler may modify
the data when it is written to the Destination so that the execution result contains modified data.
Example
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)
17.5.114
Subtract (Integer Subtract)
Syntax
Subtract (Minuend,
class=StyleSyntaxElementItalicCharChar>Subtrahend, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Minuend and Subtrahend are evaluated as Integers.
Description
Subtrahend is
subtracted from Minuend, and
the result is optionally stored into Result. Underflow conditions are ignored and the result simply loses the most
significant bits.
17.5.115 Switch (Select Code To Execute Based On Expression)
Syntax
Switch (Expression) {
class=StyleSyntaxElementItalicCharChar>CaseTermList}
Arguments
Expression is an
ASL expression that evaluates to an Integer, String or Buffer.
Description
The Switch, Case and Default statements help simplify the creation of conditional and branching
code. The Switch statement
transfers control to a statement within the enclosed body of executable ASL
code
If the Case Value
is an Integer, Buffer or String, then control passes to the statement that
matches the value of Switch (Expression). If the Case value is a Package, then control passes if any member of the package
matches the Switch (Value)
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 have the same value.
Execution of the statement body begins at the selected
TermList and proceeds until the TermList end of body or until a Break or Continue statement transfers control out of the body.
The Default
statement is executed if no Case
Value matches the value of Switch (expression)
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 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 were first introduced in ACPI 2.0. However,
their implementation is backward compatible with ACPI 1.0 AML interpreters.
Example
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
}
}
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 (One)
{
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…
}
Break
}
Note: If the ASL
compiler is unable to determine the type of the expression, then it will
generate a warning and assume a type of Integer. The warning will indicate that
the code should use one of the type conversion operators (Such as ToInteger,
ToBuffer, ToDecimalString or ToHexString). Caution: Some of these operators are
defined starting with ACPI 2.0 and as such may not be supported by ACPI 1.0b
compatible interpreters.
For example:
Switch (ABCD ()) // Cannot
determine the type because methods can return anything.
{
…case statements…
}
will generate a warning and the following code:
Name (_T_I, 0)
Store (ABCD (), _T_I)
To remove the warning, the code should be:
Switch (ToInteger (ABCD ()))
{
…case statements…
}
17.5.116 ThermalZone (Declare Thermal
Zone)
Syntax
ThermalZone
(ThermalZoneName)
{ObjectList}
Arguments
Declares a Thermal Zone object named ThermalZoneName. 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.
Description
A thermal 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
ACPI-compatible namespace may define Thermal Zone objects in either the \_SB or
\_TZ scope but not both.
For example ASL code that uses a ThermalZone statement, see
section 12, "Thermal Management."
17.5.117 Timer (Get
64-Bit Timer Value)
Syntax
Timer =>Integer
Description
The timer opcode returns a monotonically increasing value
that can be used by ACPI methods to measure time passing, this enables speed
optimization by allowing AML code to mark the passage of time independent of OS
ACPI interpreter implementation.
The Sleep opcode
can only indicate waiting for longer than the time specified.
The value resulting from this opcode is 64-bits. It is
monotonically increasing, but it is not guaranteed that every result will be
unique, i.e. two subsequent instructions may return the same value. The only
guarantee is that each subsequent evaluation will be greater-than or equal to
the previous ones.
The period of this timer is 100 nanoseconds. While the
underlying hardware may not support this granularity, the interpreter will do
the conversion from the actual timer hardware frequency into 100 nanosecond
units.
Users of this opcode should realize that a value returned
only represents the time at which the opcode itself executed. There is no
guarantee that the next opcode in the instruction stream will execute in any
particular time bound.
The OSPM can implement this using the ACPI Timer and keep
track of overrun. Other implementations are possible. This provides abstraction
away from chipset differences
Compatibility Note:New for ACPI 3.0
17.5.118 ToBCD (Convert Integer to BCD)
Syntax
ToBCD (Value, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Value is evaluated as an integer
Description
The ToBCD operator
is used to convert Value from a numeric (Integer) format to a BCD
format and optionally store the numeric value into Result.
17.5.119 ToBuffer (Convert Data to Buffer)
Syntax
ToBuffer (Data, Result)
class=StyleSyntaxElementBoldCharChar> =>Buffer
Arguments
Data must
be an Integer, String, or Buffer data type.
Description
Data is converted to
buffer type and the result is optionally stored into Result. If Data
was an integer, it is converted into n bytes of buffer (where n is 4 if the
definition block has defined integers as 32-bits or 8 if the definition block
has defined integers as 64-bits as indicated by the Definition Block table
header's Revision field), taking the least significant byte of integer as the
first byte of buffer. If Data is
a buffer, no conversion is performed. If Data is a string, each
ASCII string character is copied to one buffer byte, including the string null
terminator.
17.5.120 ToDecimalString (Convert
Data to Decimal String)
Syntax
ToDecimalString
(Data, Result) =>String
Arguments
Data must
be an Integer, String, or Buffer data type.
Description
Data is 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. (Each byte of the buffer is converted to a single
decimal value.)
17.5.121
ToHexString (Convert Data to Hexadecimal String)
Syntax
ToHexString
(Data, Result) =>String
Arguments
Data must
be an Integer, String, or Buffer data type.
Description
Data is 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.
17.5.122 ToInteger (Convert Data to
Integer)
Syntax
ToInteger
(Data, Result)
class=StyleSyntaxElementBoldCharChar> =>Integer
Arguments
Data must
be an Integer, String, or Buffer data type.
Description
Data is 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. If Data was an integer, no action is performed.
17.5.123 ToString (Convert Buffer To String)
Syntax
ToString (Source,
class=StyleSyntaxElementItalicCharChar> Length, Result)
class=StyleSyntaxElementBoldItalicCharChar> => String
Arguments
Source is evaluated
as a buffer. Length is evaluated
as an integer data type.
Description
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 or a null (0) character is found.
If Length is not specified or is Ones, then the
contents of the buffer are copied until a null (0) character is found. If the
source buffer has a length of zero, a zero length (null terminator only) string
will be created. The result is copied into the Result.
17.5.124 ToUUID
(Convert String to UUID Macro)
Syntax
ToUUID
(AsciiString) =>Buffer
Arguments
AsciiString is
evaluated as a String data type.
Description
This macro will convert an ASCII string to a 128-bit
buffer. The string must have the following format:
aabbccdd-eeff-gghh-iijj-kkllmmnnoopp
where aa – pp
are one byte hexadecimal numbers, made up of hexadecimal digits. The resulting
buffer has the following format:
Table 17-21 UUID Buffer Format
String
|
Offset In Buffer
|
aa
|
3
|
bb
|
2
|
cc
|
1
|
dd
|
0
|
ee
|
5
|
ff
|
4
|
gg
|
7
|
hh
|
6
|
ii
|
8
|
jj
|
9
|
kk
|
10
|
ll
|
11
|
mm
|
12
|
nn
|
13
|
oo
|
14
|
pp
|
15
|
Compatibility Note:New for ACPI 3.0
17.5.125 Unicode (String To Unicode Conversion Macro)
Syntax
Unicode (String)
class=StyleSyntaxElementBoldCharChar> =>Buffer
Arguments
This macro will convert a string to a Unicode (UTF-16)
string contained in a buffer. The format of the Unicode string is 16 bits per
character, with a 16-bit null terminator.
17.5.126 Unload (Unload Definition Block)
Syntax
Unload
(Handle)
Arguments
Handle is evaluated
as a DDBHandle data type.
Description
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).
17.5.127 VendorLong (Long Vendor Resource Descriptor)
Syntax
VendorLong
(DescriptorName)
{VendorByteList}
Arguments
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer.
VendorByteList evaluates
to a comma-separated list of 8-bit integer constants, where each byte is added
verbatim to the body of the VendorLong resource descriptor. A maximum of n
bytes can be specified. UUID and UUID specific descriptor subtype are part of
the VendorByteList.
Description
The VendorLong macro
evaluates to a buffer which contains a vendor-defined resource descriptor
format of the long form of the vendor-defined resource descriptor can be found
in Vendor-Defined Descriptor (page 209). The macro is designed to be
used inside of a ResourceTemplate (page 218).
This is similar to VendorShort (page 218), except that the
number of allowed bytes in VendorByteList is
65,533 (instead of 7).
17.5.128 VendorShort (Short Vendor Resource Descriptor)
Syntax
VendorShort
(DescriptorName)
{VendorByteList}
Arguments
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer.
Description
The VendorShort macro
evaluates to a buffer which contains a vendor-defined resource descriptor
format of the short form of the vendor-defined resource descriptor can be found
in "Vendor-Defined Descriptor" (page 206). The macro is designed to be
used inside of a ResourceTemplate (page 218).
This is similar to VendorLong (page 218), except that the
number of allowed bytes in VendorByteList is
7 (instead of 65,533).
17.5.129 Wait (Wait for a Synchronization Event)
Syntax
Wait (SyncObject, TimeoutValue)
class=StyleSyntaxElementBoldCharChar> =>Boolean
Arguments
SynchObject must be
an event synchronization object. TimeoutValue is evaluated as an Integer. The calling method blocks
while waiting for the event to be signaled.
Description
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 (or greater) indicates that
there is no time out and the operation will wait indefinitely.
17.5.130 While (Conditional Loop)
Syntax
While (Predicate) {
>TermList}
Arguments
Predicate is
evaluated as an integer.
Description
If the Predicate is
non-zero, the list of terms in TermList is executed. The operation repeats
until the Predicate evaluates
to zero.
17.5.131 WordBusNumber (Word Bus Number Resource Descriptor Macro)
Syntax
WordBusNumber
(ResourceUsage,
IsMinFixed, IsMaxFixed,
class=StyleSyntaxElementItalicCharChar>Decode, AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation,
RangeLength, ResourceSourceIndex, ResourceSource,
DescriptorName)
Arguments
ResourceUsage
specifies whether the bus range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
IsMinFixed specifies whether the minimum address of this bus number
range is fixed (MinFixed) or can
be changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this bus number range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
Decode specifies
whether or not the device decodes the bus number range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
AddressGranularity
evaluates to a 16-bit integer that specifies the power-of-two boundary (- 1) on
which the bus number range must be aligned. The 16-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 16-bit integer that specifies the lowest possible bus number for
the bus number range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 16-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 16-bit integer that specifies the highest possible bus number for the bus
number range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 16-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 16-bit integer that specifies the offset to be added to a
secondary bus bus number which results in the corresponding primary bus bus
number. For all non-bridge devices or bridges which do not perform translation,
this must be '0'. The 16-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 16-bit integer that specifies the total number of bus numbers
decoded in the bus number range. The 16-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this I/O range is allocated. If
this argument is
specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The WordBusNumber macro
evaluates to a buffer which contains a 16-bit bus-number resource descriptor.
The format of the 16-bit bus number resource descriptor can be found in "Word
Address Space Descriptor " (page 217). The macro is designed to be used inside
of a ResourceTemplate (page 218).
17.5.132 WordIO (Word IO Resource Descriptor Macro)
Syntax
WordIO (ResourceUsage,
class=StyleSyntaxElementItalicCharChar>IsMinFixed, IsMaxFixed,
class=StyleSyntaxElementItalicCharChar>Decode, ISARanges,
class=StyleSyntaxElementItalicCharChar>AddressGranularity, AddressMinimum,
AddressMaximum, AddressTranslation,
RangeLength, ResourceSourceIndex, ResourceSource,
DescriptorName, TranslationType, TranslationDensity)
Arguments
ResourceUsage
specifies whether the I/O range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
IsMinFixed specifies whether the minimum address of this I/O range is
fixed (MinFixed) or can be
changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this I/O range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
Decode specifies whether
or not the device decodes the I/O range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
ISARanges specifies
whether the I/O ranges specifies are limited to valid ISA I/O ranges (ISAOnly),
valid non-ISA I/O ranges (NonISAOnly)
or encompass the whole range without limitation (EntireRange). The 2-bit field DescriptorName._RNG
is automatically created to refer to this portion of the resource descriptor,
where '1' is NonISAOnly, '2' is ISAOnly and '0' is EntireRange.
AddressGranularity
evaluates to a 16-bit integer that specifies the power-of-two boundary (- 1) on
which the I/O range must be aligned. The 16-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 16-bit integer that specifies the lowest possible base address
of the I/O range. The value must have '0' in all bits where the corresponding
bit in AddressGranularity is '1'.
For bridge devices which translate addresses, this is the address on the
secondary bus. The 16-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 16-bit integer that specifies the highest possible base address of the I/O
range. The value must have '0' in all bits where the corresponding bit in AddressGranularity is '1'. For bridge devices which translate
addresses, this is the address on the secondary bus. The 16-bit field DescriptorName._MAX is automatically created to refer to this
portion of the resource descriptor.
AddressTranslation
evaluates to a 16-bit integer that specifies the offset to be added to a
secondary bus I/O address which results in the corresponding primary bus I/O
address. For all non-bridge devices or bridges which do not perform
translation, this must be '0'. The 16-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 16-bit integer that specifies the total number of bytes decoded
in the I/O range. The 16-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this I/O range is allocated. If
this argument is
specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
TranslationType is an optional argument that specifies whether the
resource type on the secondary side of the bus is different (TypeTranslation)
from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the
secondary side of the bus is Memory. If TypeStatic is specified, then the
secondary side of the bus is I/O. If nothing is specified, then TypeStatic is
assumed. The 1-bit field DescriptorName. _TTP is automatically
created to refer to this portion of the resource descriptor, where '1' is
TypeTranslation and '0' is TypeStatic. See _TTP (page 218) for more information
TranslationDensity is an optional argument that specifies whether or
not the translation from the primary to secondary bus is sparse (SparseTranslation)
or dense (DenseTranslation). It is only
used when TranslationType is TypeTranslation. If nothing is specified, then DenseTranslation is
assumed. The 1-bit field DescriptorName. _TRS is automatically
created to refer to this portion of the resource descriptor, where '1' is
SparseTranslation and '0' is DenseTranslation. See _TRS (page 218) for more
information.
Description
The WordIO macro
evaluates to a buffer which contains a 16-bit I/O range resource descriptor.
The format of the 16-bit I/O range resource descriptor can be found in "Word
Address Space Descriptor " (page 217). The macro is designed to be used inside
of a ResourceTemplate (page 218).
17.5.133 WordSpace
(Word Space Resource Descriptor Macro) )
Syntax
WordSpace
(ResourceType, ResourceUsage,
class=StyleSyntaxElementItalicCharChar>Decode, IsMinFixed,
class=StyleSyntaxElementItalicCharChar>IsMaxFixed, TypeSpecificFlags,
AddressGranularity,
AddressMinimum, AddressMaximum, AddressTranslation,
class=StyleSyntaxElementItalicCharChar>RangeLength, ResourceSourceIndex, ResourceSource,
DescriptorName)
Arguments
ResourceType evaluates
to an 8-bit integer that specifies the type of this resource. Acceptable values
are 0xC0 through 0xFF.
ResourceUsage
specifies whether the bus range is consumed by this device (ResourceConsumer)
or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
Decode specifies
whether or not the device decodes the bus number range using positive (PosDecode)
or subtractive (SubDecode) decode
nothing is specified, then PosDecode is assumed. The 1-bit field DescriptorName.
_DEC is automatically created to refer to this portion of the resource
descriptor, where '1' is SubDecode and '0' is PosDecode.
IsMinFixed specifies whether the minimum address of this bus number
range is fixed (MinFixed) or can
be changed (MinNotFixed)
nothing is specified, then MinNotFixed is assumed. The 1-bit field DescriptorName.
_MIF is automatically created to refer to this portion of the resource
descriptor, where '1' is MinFixed and '0' is MinNotFixed.
IsMaxFixed specifies
whether the maximum address of this bus number range is fixed (MaxFixed)
or can be changed (MaxNotFixed)
nothing is specified, then MaxNotFixed is assumed. The 1-bit field DescriptorName.
_MAF is automatically created to refer to this portion of the
resource descriptor, where '1' is MaxFixed and '0' is MaxNotFixed.
TypeSpecificFlags
evaluates to an 8-bit integer. The flags are specific to the ResourceType.
AddressGranularity
evaluates to a 16-bit integer that specifies the power-of-two boundary (- 1) on
which the bus number range must be aligned. The 16-bit field DescriptorName. _GRA is automatically created to refer to this
portion of the resource descriptor.
AddressMinimum
evaluates to a 16-bit integer that specifies the lowest possible bus number for
the bus number range. The value must have '0' in all bits where the
corresponding bit in AddressGranularity is '1'. For bridge devices which translate addresses, this is the
address on the secondary bus. The 16-bit field DescriptorName._MIN is automatically created to refer to this
portion of the resource descriptor.
AddressMaximum evaluates
to a 16-bit integer that specifies the highest possible bus number for the bus
number range. The value must have '0' in all bits where the corresponding bit
in AddressGranularity is '1'bridge devices which translate addresses, this is the address on the secondary
bus. The 16-bit field DescriptorName._MAX
is automatically created to refer to this portion of the resource descriptor.
AddressTranslation
evaluates to a 16-bit integer that specifies the offset to be added to a
secondary bus bus number which results in the corresponding primary bus bus
number. For all non-bridge devices or bridges which do not perform translation,
this must be '0'. The 16-bit field DescriptorName._TRA is automatically created to refer to this
portion of the resource descriptor.
RangeLength
evaluates to a 16-bit integer that specifies the total number of bus numbers
decoded in the bus number range. The 16-bit field DescriptorName. _LEN is automatically created to refer to this
portion of the resource descriptor.
ResourceSourceIndex is
an optional argument which evaluates to an 8-bit integer that specifies the
resource descriptor within the object specified by ResourceSource. If this argument is specified, the ResourceSource
style='font-style:normal'> argument must also be specified.
ResourceSource is an optional argument which evaluates to a string
containing the path of a device which produces the pool of resources from which
this I/O range is allocated. If
this argument is
specified, but the ResourceSourceIndex argument is not specified, a zero value is assumed.
DescriptorName is an
optional argument that specifies a name for an integer constant that will be
created in the current scope that contains the offset of this resource
descriptor within the current resource template buffer. The predefined
descriptor field names may be appended to this name to access individual fields
within the descriptor via the Buffer Field operators.
Description
The WordSpace macro
evaluates to a buffer which contains a 16-bit Address Space resource
descriptor. The format of the 16-bit Address Space resource descriptor can be
found in "Word Address Space Descriptor " (page 217). The macro is
designed to be used inside of a ResourceTemplate (page 218).
17.5.134 XOr (Integer Bitwise
Xor)
Syntax
XOr (Source1, Source2, Result)
> => Integer
Arguments
Source1 and
Source2 are evaluated as
Integers.
Description
A bitwise XOR is
performed and the result is optionally stored into Result.
17.5.135
Zero (Constant Zero Object)
Syntax
Zero
Description
The constant Zero
object is an object of type Integer that will always read as all bits
clear. Writes to this object are not allowed.
18 ACPI Machine Language (AML)
Specification
This section formally defines the ACPI Control Method Machine
Language (AML) language. AML is the ACPI Control Method virtual machine
language, machine code for a virtual machine that is supported by an
ACPI-compatible OS. ACPI control methods can be written in AML, but humans
ordinarily write control methods in ASL.
AML is the language processed by the ACPI AML interpreter.
It is primarily a declarative language. It's best not to think of it as a
stream of code, but rather as a set of declarations that the ACPI AML
interpreter will compile into the ACPI Namespace at definition block load time.
For example, notice that DefByte allocates an anonymous integer variable with a
byte-size initial value in ACPI namespace, and passes in an initial value
byte in the AML stream that defines the initial value is not the address of the variable's storage location.
An OEM or BIOS vendor needs to write ASL and be able to
single-step AML for debugging. (Debuggers and other ACPI control method
language tools are expected to be AML-level tools, not source-level tools.) An
ASL translator implementer must understand how to read ASL and generate AML
AML interpreter author must understand how to execute AML.
AML and ASL are different languages though they are closely related.
All ACPI-compatible operating systems must support AML. A
given user can define some arbitrary source language (to replace ASL) and write
a tool to translate it to AML. However, the ACPI group will support a single
translator for a single language, ASL.
18.1 Notation
Conventions
The notation conventions in the table below help the reader
to interpret the AML formal grammar.
Table 18-1 AML Grammar Notation
Conventions
Notation Convention
|
Description
|
Example
|
0xdd
Refers to a byte value expressed as 2 hexadecimal
digits.
0x21
Number in bold.
Denotes the encoding of the AML term.
Term => Evaluated Type
Shows the resulting type of the evaluation of Term.
Single quotes (' ')
Indicate constant characters.
'A' => 0x41
Term := Term Term …
The term to the left of := can be expanded into the
sequence of terms on the right.
aterm := bterm cterm means that aterm can be expanded
into the two-term sequence of bterm followed by cterm.
Term Term Term …
Terms separated from each other by spaces form an
ordered list.
Angle brackets (< > )
Used to group items.
<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
Dash character ( - )
Indicates a range.
1-9 means a single digit in the range 1 to 9 inclusive.
Parenthesized term following another term.
The parenthesized term is the repeat count of the
previous term.
aterm(3) means aterm aterm
aterm.
bterm(n) means n number of bterms.
18.2 AML
Grammar Definition
This section defines the byte values that make up an AML
byte stream.
The AML encoding can be categorized in the following
groups:
· Table
and Table Header encoding
· Name
objects encoding
· Data
objects encoding
· Package
length encoding
· Term
objects encoding
· Miscellaneous
objects encoding
18.2.1 Table and
Table Header Encoding
AMLCode :=
DefBlockHdr TermList
DefBlockHdr :=
TableSignature TableLength SpecCompliance CheckSum OemID OemTableID OemRevision
CreatorID CreatorRevision
TableSignature :=
DWordData //
As defined in section 5.2.3.
TableLength :=
DwordData //
Length of the table in bytes including
// the block header.
SpecCompliance :=
ByteData //
The revision of the structure.
CheckSum :=
ByteData //
Byte checksum of the entire table.
OemID :=
ByteData(6) // OEM ID of
up to 6 characters. If the OEM
// ID is shorter than 6 characters, it
// can be terminated with a NULL
// character.
OemTableID :=
ByteData(8) // OEM Table
ID of up to 8 characters. If
// the OEM Table ID is shorter than 8
// characters, it can be terminated with
// a NULL character.
OemRevision :=
DWordData //
OEM Table Revision.
CreatorID :=
DWordData //
Vendor ID of the ASL compiler.
CreatorRevision :=
DWordData //
Revision of the ASL compiler.
18.2.2 Name Objects Encoding
LeadNameChar :=
'A'-'Z' | '_'
DigitChar :=
'0'-'9'
NameChar :=
DigitChar | LeadNameChar
RootChar :=
'\'
ParentPrefixChar := '^'
'A'-'Z' :=
0x41 - 0x5A
'_' :=
0x5F
'0'-'9' :=
0x30 - 0x39
'\' :=
0x5C
'^' :=
0x5E
NameSeg :=
<LeadNameChar NameChar NameChar NameChar>
// Notice that NameSegs shorter than 4 characters are filled with
// trailing underscores ('_'s).
NameString :=
<RootChar NamePath> | <PrefixPath NamePath>
PrefixPath :=
Nothing | <'^' PrefixPath>
NamePath :=
NameSeg | DualNamePath | MultiNamePath | NullName
DualNamePath :=
DualNamePrefix NameSeg NameSeg
DualNamePrefix :=
0x2E
MultiNamePath :=
MultiNamePrefix SegCount NameSeg(SegCount)
MultiNamePrefix := 0x2F
SegCount :=
ByteData
Note: SegCount can be from 1 to 255. For example: MultiNamePrefix(35) is
encoded as 0x2f 0x23 and followed 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 encoding of: MultiNamePrefix(2)
NameSeg NameSeg
SimpleName :=
NameString | ArgObj | LocalObj
SuperName :=
SimpleName | DebugObj | Type6Opcode
NullName :=
0x00
Target :=
SuperName | NullName
18.2.3 Data Objects Encoding
ComputationalData := ByteConst |
WordConst | DwordConst | QwordConst | String | ConstObj | RevisionOp |
DefBuffer
DataObject :=
ComputationalData | DefPackage | DefVarPackage
DataRefObject :=
DataObject | ObjectReference | DDBHandle
ByteConst :=
BytePrefix ByteData
BytePrefix :=
0x0A
WordConst :=
WordPrefix WordData
WordPrefix :=
0x0B
DWordConst :=
DWordPrefix DWordData
DWordPrefix :=
0x0C
QWordConst :=
QWordPrefix QWordData
QWordPrefix :=
0x0E
String :=
StringPrefix AsciiCharList NullChar
StringPrefix :=
0x0D
ConstObj :=
ZeroOp | OneOp | OnesOp
ByteList :=
Nothing | <ByteData ByteList>
ByteData :=
0x00 - 0xFF
WordData :=
ByteData[0:7] ByteData[8:15]
// 0x0000-0xFFFF
DWordData :=
WordData[0:15] WordData[16:31]
// 0x00000000-0xFFFFFFFF
QWordData :=
DwordData[0:31] DwordData[32:63]
// 0x0000000000000000-0xFFFFFFFFFFFFFFFF
AsciiCharList :=
Nothing | <AsciiChar AsciiCharList>
AsciiChar :=
0x01 - 0x7F
NullChar :=
0x00
ZeroOp :=
0x00
OneOp :=
0x01
OnesOp :=
0xFF
RevisionOp :=
ExtOpPrefix 0x30
ExtOpPrefix :=
0x5B
18.2.4 Package Length Encoding
PkgLength :=
PkgLeadByte |
<PkgLeadByte ByteData> |
<PkgLeadByte ByteData ByteData> |
<PkgLeadByte ByteData ByteData ByteData>
PkgLeadByte :=
<bit 7-6: ByteData count that follows (0-3)>
<bit 5-4: Only used if PkgLength < 63>
<bit 3-0: Least significant package length nybble>
class=GrammarCommentCharChar> has only one byte, bit 0 through 5 are used to
encode the package length (in other words, values 0-63). If the package length
value is more than 63, more than one byte must be used for the encoding in
which case bit 4 and 5 of the PkgLeadByte are reserved and must be zero. If the
multiple bytes encoding is used, bits 0-3 of the PkgLeadByte
18.2.5 Term Objects Encoding
TermObj :=
NameSpaceModifierObj | NamedObj | Type1Opcode | Type2Opcode
TermList :=
Nothing | <TermObj TermList>
TermArg :=
Type2Opcode | DataObject | ArgObj | LocalObj
UserTermObj :=
NameString TermArgList
TermArgList :=
Nothing | <TermArg TermArgList>
ObjectList :=
Nothing | <Object ObjectList>
Object :=
NameSpaceModifierObj | NamedObj
18.2.5.1 Namespace Modifier Objects Encoding
NameSpaceModifierObj := DefAlias |
DefName | DefScope
DefAlias :=
AliasOp NameString NameString
AliasOp :=
0x06
DefName :=
NameOp NameString DataRefObject
NameOp :=
0x08
DefScope :=
ScopeOp PkgLength NameString TermList
ScopeOp :=
0x10
18.2.5.2 Named Objects Encoding
NamedObj :=
DefBankField | DefCreateBitField | DefCreateByteField | DefCreateDWordField |
DefCreateField | DefCreateQWordField | DefCreateWordField | DefDataRegion |
DefDevice | DefEvent | DefField | DefIndexField | DefMethod | DefMutex |
DefOpRegion | DefPowerRes | DefProcessor | DefThermalZone
DefBankField :=
BankFieldOp PkgLength NameString NameString BankValue FieldFlags FieldList
BankFieldOp :=
ExtOpPrefix 0x87
BankValue :=
TermArg => Integer
FieldFlags :=
ByteData //
bit 0-3: AccessType
// 0 AnyAcc
// 1 ByteAcc
// 2 WordAcc
// 3 DWordAcc
// 4 QWordAcc
// 5 BufferAcc
// 6 Reserved
// 7-15
Reserved
//
bit 4: LockRule
// 0 NoLock
// 1 Lock
//
bit 5-6: UpdateRule
// 0 Preserve
// 1 WriteAsOnes
// 2 WriteAsZeros
//
bit 7: Reserved (must be 0)
FieldList :=
Nothing | <FieldElement FieldList>
FieldElement :=
NamedField | ReservedField | AccessField
NamedField :=
NameSeg PkgLength
ReservedField :=
0x00 PkgLength
AccessField :=
0x01 AccessType
AccessAttrib
AccessType :=
ByteData //
Same as AccessType bits of FieldFlags.
AccessAttrib :=
ByteData //
If AccessType is BufferAcc for the SMB
//
OpRegion, AccessAttrib can be one of
//
the following values:
// 0x02 SMBQuick
// 0x04 SMBSendReceive
// 0x06 SMBByte
// 0x08 SMBWord
// 0x0A SMBBlock
// 0x0C SMBProcessCall
// 0x0D SMBBlockProcessCall
DefCreateBitField := CreateBitFieldOp
SourceBuff BitIndex NameString
CreateBitFieldOp := 0x8D
SourceBuff :=
TermArg => Buffer
BitIndex :=
TermArg => Integer
DefCreateByteField := CreateByteFieldOp
SourceBuff ByteIndex NameString
CreateByteFieldOp := 0x8C
ByteIndex :=
TermArg => Integer
DefCreateDWordField := CreateDWordFieldOp
SourceBuff ByteIndex NameString
CreateDWordFieldOp := 0x8A
DefCreateField :=
CreateFieldOp SourceBuff BitIndex NumBits NameString
CreateFieldOp :=
ExtOpPrefix 0x13
NumBits :=
TermArg => Integer
DefCreateQWordField := CreateQWordFieldOp
SourceBuff ByteIndex NameString
CreateQWordFieldOp := 0x8F
DefCreateWordField := CreateWordFieldOp
SourceBuff ByteIndex NameString
CreateWordFieldOp := 0x8B
DefDataRegion :=
DataRegionOp NameString TermArg TermArg TermArg
DataRegionOp :=
ExOpPrefix 0x88
DefDevice :=
DeviceOp PkgLength NameString ObjectList
DeviceOp :=
ExtOpPrefix 0x82
DefEvent :=
EventOp NameString
EventOp :=
ExtOpPrefix 0x02
DefField :=
FieldOp PkgLength NameString FieldFlags FieldList
FieldOp :=
ExtOpPrefix 0x81
DefIndexField :=
IndexFieldOp PkgLength NameString NameString FieldFlags FieldList
IndexFieldOp :=
ExtOpPrefix 0x86
DefMethod :=
MethodOp PkgLength NameString MethodFlags TermList
MethodOp :=
0x14
MethodFlags :=
ByteData //
bit 0-2: ArgCount (0-7)
//
bit 3: SerializeFlag
// 0 NotSerialized
// 1 Serialized
//
bit 4-7: SyncLevel (0x00-0x0f)
DefMutex :=
MutexOp NameString SyncFlags
MutexOp :=
ExtOpPrefix 0x01
SyncFlags :=
ByteData //
bit 0-3: SyncLevel (0x00-0x0f)
//
bit 4-7: Reserved (must be 0)
DefOpRegion :=
OpRegionOp NameString RegionSpace RegionOffset RegionLen
OpRegionOp :=
ExtOpPrefix 0x80
RegionSpace :=
ByteData //
0x00 SystemMemory
//
0x01 SystemIO
//
0x02 PCI_Config
//
0x03 EmbeddedControl
//
0x04 SMBus
//
0x05 CMOS
//
0x06 PciBarTarget
//
0x80-0xFF: User Defined
RegionOffset :=
TermArg => Integer
RegionLen :=
TermArg => Integer
DefPowerRes :=
PowerResOp PkgLength NameString SystemLevel ResourceOrder ObjectList
PowerResOp :=
ExtOpPrefix 0x84
SystemLevel :=
ByteData
ResourceOrder :=
WordData
DefProcessor :=
ProcessorOp PkgLength NameString ProcID PblkAddr PblkLen ObjectList
ProcessorOp :=
ExtOpPrefix 0x83
ProcID :=
ByteData
PblkAddr :=
DwordData
PblkLen :=
ByteData
DefThermalZone :=
ThermalZoneOp PkgLength NameString ObjectList
ThermalZoneOp :=
ExtOpPrefix 0x85
18.2.5.3 Type 1 Opcodes Encoding
Type1Opcode :=
DefBreak | DefBreakPoint | DefContinue | DefFatal | DefIfElse | DefLoad |
DefNoop | DefNotify | DefRelease | DefReset | DefReturn | DefSignal | DefSleep
| DefStall | DefUnload | DefWhile
DefBreak :=
BreakOp
BreakOp :=
0xA5
DefBreakPoint :=
BreakPointOp
BreakPointOp :=
0xCC
DefContinue :=
ContinueOp
ContinueOp :=
0x9F
DefElse :=
Nothing | <ElseOp PkgLength TermList>
ElseOp :=
0xA1
DefFatal :=
FatalOp FatalType FatalCode FatalArg
FatalOp :=
ExtOpPrefix 0x32
FatalType :=
ByteData
FatalCode :=
DwordData
FatalArg :=
TermArg => Integer
DefIfElse :=
IfOp PkgLength Predicate TermList DefElse
IfOp :=
0xA0
Predicate :=
TermArg => Integer
DefLoad :=
LoadOp NameString DDBHandleObject
LoadOp :=
ExtOpPrefix 0x20
DDBHandleObject :=
SuperName
DefNoop :=
NoopOp
NoopOp :=
0xA3
DefNotify :=
NotifyOp NotifyObject NotifyValue
NotifyOp :=
0x86
NotifyObject :=
SuperName => ThermalZone | Processor | Device
NotifyValue :=
TermArg => Integer
DefRelease :=
ReleaseOp MutexObject
ReleaseOp :=
ExtOpPrefix 0x27
MutexObject :=
SuperName
DefReset :=
ResetOp EventObject
ResetOp :=
ExtOpPrefix 0x26
EventObject :=
SuperName
DefReturn :=
ReturnOp ArgObject
ReturnOp :=
0xA4
ArgObject :=
TermArg => DataRefObject
DefSignal :=
SignalOp EventObject
SignalOp :=
ExtOpPrefix 0x24
DefSleep :=
SleepOp MsecTime
SleepOp :=
ExtOpPrefix 0x22
MsecTime :=
TermArg => Integer
DefStall :=
StallOp UsecTime
StallOp :=
ExtOpPrefix 0x21
UsecTime :=
TermArg => ByteData
DefUnload :=
UnloadOp DDBHandleObject
UnloadOp :=
ExtOpPrefix 0x2A
DefWhile :=
WhileOp PkgLength Predicate TermList
WhileOp :=
0xA2
18.2.5.4 Type 2 Opcodes Encoding
Type2Opcode :=
DefAcquire | DefAdd | DefAnd | DefBuffer | DefConcat | DefConcatRes |
DefCondRefOf | DefCopyObject | DefDecrement | DefDerefOf | DefDivide |
DefFindSetLeftBit | DefFindSetRightBit | DefFromBCD | DefIncrement | DefIndex |
DefLAnd | DefLEqual | DefLGreater | DefLGreaterEqual | DefLLess | DefLLessEqual
| DefMid | DefLNot | DefLNotEqual | DefLoadTable | DefLOr | DefMatch | DefMod |
DefMultiply | DefNAnd | DefNOr | DefNot | DefObjectType | DefOr | DefPackage |
DefVarPackage | DefRefOf | DefShiftLeft | DefShiftRight | DefSizeOf | DefStore
| DefSubtract | DefTimer | DefToBCD | DefToBuffer | DefToDecimalString |
DefToHexString | DefToInteger | DefToString | DefWait | DefXOr | UserTermObj
Type6Opcode :=
DefRefOf | DefDerefOf | DefIndex | UserTermObj
DefAcquire :=
AcquireOp MutexObject Timeout
AcquireOp :=
ExtOpPrefix 0x23
Timeout :=
WordData
DefAdd :=
AddOp Operand Operand Target
AddOp :=
0x72
Operand :=
TermArg => Integer
DefAnd :=
AndOp Operand Operand Target
AndOp :=
0x7B
DefBuffer :=
BufferOp PkgLength BufferSize ByteList
BufferOp :=
0x11
BufferSize :=
TermArg => Integer
DefConcat :=
ConcatOp Data Data Target
ConcatOp :=
0x73
Data :=
TermArg => ComputationalData
DefConcatRes :=
ConcatResOp BufData BufData Target
ConcatResOp :=
0x84
BufData :=
TermArg => Buffer
DefCondRefOf :=
CondRefOfOp SuperName Target
CondRefOfOp :=
ExtOpPrefix 0x12
DefCopyObject :=
CopyObjectOp TermArg SimpleName
CopyObjectOp :=
0x9D
DefDecrement :=
DecrementOp SuperName
DecrementOp :=
0x76
DefDerefOf :=
DerefOfOp ObjReference
DerefOfOp :=
0x83
ObjReference :=
TermArg => ObjectReference | String
DefDivide :=
DivideOp Dividend Divisor Remainder Quotient
DivideOp :=
0x78
Dividend :=
TermArg => Integer
Divisor :=
TermArg => Integer
Remainder :=
Target
Quotient :=
Target
DefFindSetLeftBit := FindSetLeftBitOp
Operand Target
FindSetLeftBitOp := 0x81
DefFindSetRightBit := FindSetRightBitOp
Operand Target
FindSetRightBitOp := 0x82
DefFromBCD :=
FromBCDOp BCDValue Target
FromBCDOp :=
ExtOpPrefix 0x28
BCDValue :=
TermArg => Integer
DefIncrement :=
IncrementOp SuperName
IncrementOp :=
0x75
DefIndex :=
IndexOp BuffPkgStrObj IndexValue Target
IndexOp :=
0x88
BuffPkgStrObj :=
TermArg => Buffer, Package or String
IndexValue :=
TermArg => Integer
DefLAnd :=
LandOp Operand Operand
LandOp :=
0x90
DefLEqual :=
LequalOp Operand Operand
LequalOp :=
0x93
DefLGreater :=
LgreaterOp Operand Operand
LgreaterOp :=
0x94
DefLGreaterEqual :=
LgreaterEqualOp Operand Operand
LgreaterEqualOp := LnotOp
LlessOp
DefLLess :=
LlessOp Operand Operand
LlessOp :=
0x95
DefLLessEqual :=
LlessEqualOp Operand Operand
LlessEqualOp :=
LnotOp LgreaterOp
DefLNot :=
LnotOp Operand
LnotOp :=
0x92
DefLNotEqual :=
LnotEqualOp Operand Operand
LnotEqualOp :=
LnotOp LequalOp
DefLoadTable :=
LoadTableOp TermArg TermArg TermArg TermArg TermArg TermArg
LoadTableOp :=
ExtOpPrefix 0x1F
DefLOr :=
LorOp Operand Operand
LorOp :=
0x91
DefMatch :=
MatchOp SearchPkg MatchOpcode Operand MatchOpcode Operand StartIndex
MatchOp :=
0x89
SearchPkg :=
TermArg => Package
MatchOpcode :=
ByteData //
0 MTR
//
1 MEQ
//
2 MLE
//
3 MLT
//
4 MGE
//
5 MGT
StartIndex :=
TermArg => Integer
DefMid :=
MidOp MidObj TermArg TermArg Target
MidOp :=
0x9E
MidObj :=
TermArg => Buffer | String
DefMod :=
ModOp Dividend Divisor Target
ModOp :=
0x85
DefMultiply :=
MultiplyOp Operand Operand Target
MultiplyOp :=
0x77
DefNAnd :=
NandOp Operand Operand Target
NandOp :=
0x7C
DefNOr :=
NorOp Operand Operand Target
NorOp :=
0x7E
DefNot :=
NotOp Operand Target
NotOp :=
0x80
DefObjectType :=
ObjectTypeOp SuperName
ObjectTypeOp :=
0x8E
DefOr :=
OrOp Operand Operand Target
OrOp :=
0x7D
DefPackage :=
PackageOp PkgLength NumElements PackageElementList
PackageOp :=
0x12
DefVarPackage :=
VarPackageOp PkgLength VarNumElements PackageElementList
VarPackageOp :=
0x13
NumElements :=
ByteData
VarNumElements :=
TermArg => Integer
PackageElementList := Nothing |
<PackageElement PackageElementList>
PackageElement :=
DataRefObject | NameString
DefRefOf :=
RefOfOp SuperName
RefOfOp :=
0x71
DefShiftLeft :=
ShiftLeftOp Operand ShiftCount Target
ShiftLeftOp :=
0x79
ShiftCount :=
TermArg => Integer
DefShiftRight :=
ShiftRightOp Operand ShiftCount Target
ShiftRightOp :=
0x7A
DefSizeOf :=
SizeOfOp SuperName
SizeOfOp :=
0x87
DefStore :=
StoreOp TermArg SuperName
StoreOp :=
0x70
DefSubtract :=
SubtractOp Operand Operand Target
SubtractOp :=
0x74
DefTimer :=
TimerOp
TimerOp :=
0x5B 0x33
DefToBCD :=
ToBCDOp Operand Target
ToBCDOp :=
ExtOpPrefix 0x29
DefToBuffer :=
ToBufferOp Operand Target
ToBufferOp :=
0x96
DefToDecimalString := ToDecimalStringOp
Operand Target
ToDecimalStringOp := 0x97
DefToHexString :=
ToHexStringOp Operand Target
ToHexStringOp :=
0x98
DefToInteger :=
ToIntegerOp Operand Target
ToIntegerOp :=
0x99
DefToString :=
ToStringOp TermArg LengthArg Target
LengthArg :=
TermArg => Integer
ToStringOp :=
0x9C
DefWait :=
WaitOp EventObject Operand
WaitOp :=
ExtOpPrefix 0x25
DefXOr :=
XorOp Operand Operand Target
XorOp :=
0x7F
18.2.6 Miscellaneous Objects Encoding
Miscellaneous objects include:
· Arg
objects
· Local
objects
· Debug
objects
18.2.6.1 Arg Objects Encoding
ArgObj :=
Arg0Op | Arg1Op | Arg2Op | Arg3Op | Arg4Op | Arg5Op | Arg6Op
Arg0Op :=
0x68
Arg1Op :=
0x69
Arg2Op :=
0x6A
Arg3Op :=
0x6B
Arg4Op :=
0x6C
Arg5Op :=
0x6D
Arg6Op :=
0x6E
18.2.6.2 Local Objects
Encoding
LocalObj :=
Local0Op | Local1Op | Local2Op | Local3Op | Local4Op | Local5Op | Local6Op |
Local7Op
Local0Op :=
0x60
Local1Op :=
0x61
Local2Op :=
0x62
Local3Op :=
0x63
Local4Op :=
0x64
Local5Op :=
0x65
Local6Op :=
0x66
Local7Op :=
0x67
18.2.6.3 Debug Objects Encoding
DebugObj :=
DebugOp
DebugOp :=
ExtOpPrefix 0x31
18.3 AML Byte Stream Byte Values
The following table lists all the byte values that can be
found in an AML byte stream and the meaning of each byte value. This table is
useful for debugging AML code.
Table 18-2 AML Byte Stream Byte Values
|
|
Encoding Value
|
Encoding Name
|
Encoding Group
|
Fixed List Arguments
|
Variable List Arguments
|
0x00
|
ZeroOp
|
Data Object
|
—
|
—
|
0x01
|
OneOp
|
Data Object
|
—
|
—
|
0x02-0x05
|
—
|
—
|
—
|
—
|
0x06
|
AliasOp
|
Term Object
|
NameString NameString
|
—
|
0x07
|
—
|
—
|
—
|
—
|
0x08
|
NameOp
|
Term Object
|
NameString DataRefObject
|
—
|
0x09
|
—
|
—
|
—
|
—
|
0x0A
|
BytePrefix
|
Data Object
|
ByteData
|
—
|
0x0B
|
WordPrefix
|
Data Object
|
WordData
|
—
|
0x0C
|
DWordPrefix
|
Data Object
|
DWordData
|
—
|
0x0D
|
StringPrefix
|
Data Object
|
AsciiCharList NullChar
|
—
|
0x0E
|
QWordPrefix
|
Data Object
|
QWordData
|
—
|
0x0F
|
—
|
—
|
—
|
—
|
0x10
|
ScopeOp
|
Term Object
|
NameString
|
TermList
|
0x11
|
BufferOp
|
Term Object
|
TermArg
|
ByteList
|
0x12
|
PackageOp
|
Term Object
|
ByteData
|
Package TermList
|
0x13
|
VarPackageOp
|
Term Object
|
TermArg
|
Package TermList
|
0x14
|
MethodOp
|
Term Object
|
NameString ByteData
|
TermList
|
0x15-0x2D
|
—
|
—
|
—
|
—
|
0x2E ('.')
|
DualNamePrefix
|
Name Object
|
NameSeg NameSeg
|
—
|
0x2F ('/')
|
MultiNamePrefix
|
Name Object
|
ByteData NameSeg(N)
|
—
|
0x30-0x40
|
—
|
—
|
—
|
—
|
0x41-0x5A ('A'-'Z')
|
NameChar
|
Name Object
|
—
|
—
|
0x5B ('[')
|
ExtOpPrefix
|
—
|
ByteData
|
—
|
0x5B 0x01
|
MutexOp
|
Term Object
|
NameString ByteData
|
—
|
0x5B 0x02
|
EventOp
|
Term Object
|
NameString
|
—
|
0x5B 0x12
|
CondRefOfOp
|
Term Object
|
SuperName SuperName
|
—
|
0x5B 0x13
|
CreateFieldOp
|
Term Object
|
TermArg TermArg TermArg NameString
|
—
|
0x5B 0x1F
|
LoadTableOp
|
Term Object
|
TermArg TermArg TermArg TermArg TermArg
TermArg
|
—
|
0x5B 0x20
|
LoadOp
|
Term Object
|
NameString SuperName
|
—
|
0x5B 0x21
|
StallOp
|
Term Object
|
TermArg
|
—
|
0x5B 0x22
|
SleepOp
|
Term Object
|
TermArg
|
—
|
0x5B 0x23
|
AcquireOp
|
Term Object
|
SuperName WordData
|
—
|
0x5B 0x24
|
SignalOp
|
Term Object
|
SuperName
|
—
|
0x5B 0x25
|
WaitOp
|
Term Object
|
SuperName TermArg
|
—
|
0x5B 0x26
|
ResetOp
|
Term Object
|
SuperName
|
—
|
0x5B 0x27
|
ReleaseOp
|
Term Object
|
SuperName
|
—
|
0x5B 0x28
|
FromBCDOp
|
Term Object
|
TermArg Target
|
—
|
0x5B 0x29
|
ToBCD
|
Term Object
|
TermArg Target
|
—
|
0x5B 0x2A
|
UnloadOp
|
Term Object
|
SuperName
|
—
|
0x5B 0x30
|
RevisionOp
|
Data Object
|
—
|
—
|
0x5B 0x31
|
DebugOp
|
Debug Object
|
—
|
—
|
0x5B 0x32
|
FatalOp
|
Term Object
|
ByteData DWordData TermArg
|
—
|
0x5B 0x33
|
TimerOp
|
Term Object
|
—
|
—
|
0x5B 0x80
|
OpRegionOp
|
Term Object
|
NameString ByteData TermArg TermArg
|
—
|
0x5B 0x81
|
FieldOp
|
Term Object
|
NameString ByteData
|
FieldList
|
0x5B 0x82
|
DeviceOp
|
Term Object
|
NameString
|
ObjectList
|
0x5B 0x83
|
ProcessorOp
|
Term Object
|
NameString ByteData DWordData ByteData
|
ObjectList
|
0x5B 0x84
|
PowerResOp
|
Term Object
|
NameString ByteData WordData
|
ObjectList
|
0x5B 0x85
|
ThermalZoneOp
|
Term Object
|
NameString
|
ObjectList
|
0x5B 0x86
|
IndexFieldOp
|
Term Object
|
NameString NameString ByteData
|
FieldList
|
0x5B 0x87
|
BankFieldOp
|
Term Object
|
NameString NameString TermArg ByteData
|
FieldList
|
0x5B 0x88
|
DataRegionOp
|
Term Object
|
NameString TermArg TermArg TermArg
|
—
|
0x5C ('\')
|
RootChar
|
Name Object
|
—
|
—
|
0x5D
|
—
|
—
|
—
|
—
|
0x5E ('^')
|
ParentPrefixChar
|
Name Object
|
—
|
—
|
0x5F('_')
|
NameChar—
|
Name Object
|
—
|
—
|
0x60 ('`')
|
Local0Op
|
Local Object
|
—
|
—
|
0x61 ('a')
|
Local1Op
|
Local Object
|
—
|
—
|
0x62 ('b')
|
Local2Op
|
Local Object
|
—
|
—
|
0x63 ('c')
|
Local3Op
|
Local Object
|
—
|
—
|
0x64 ('d')
|
Local4Op
|
Local Object
|
—
|
—
|
0x65 ('e')
|
Local5Op
|
Local Object
|
—
|
—
|
0x66 ('f')
|
Local6Op
|
Local Object
|
—
|
—
|
0x67 ('g')
|
Local7Op
|
Local Object
|
—
|
—
|
0x68 ('h')
|
Arg0Op
|
Arg Object
|
—
|
—
|
0x69 ('i')
|
Arg1Op
|
Arg Object
|
—
|
—
|
0x6A ('j')
|
Arg2Op
|
Arg Object
|
—
|
—
|
0x6B ('k')
|
Arg3Op
|
Arg Object
|
—
|
—
|
0x6C ('l')
|
Arg4Op
|
Arg Object
|
—
|
—
|
0x6D ('m')
|
Arg5Op
|
Arg Object
|
—
|
—
|
0x6E ('n')
|
Arg6Op
|
Arg Object
|
—
|
—
|
0x6F
|
—
|
—
|
—
|
—
|
0x70
|
StoreOp
|
Term Object
|
TermArg SuperName
|
—
|
0x71
|
RefOfOp
|
Term Object
|
SuperName
|
—
|
0x72
|
AddOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x73
|
ConcatOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x74
|
SubtractOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x75
|
IncrementOp
|
Term Object
|
SuperName
|
—
|
0x76
|
DecrementOp
|
Term Object
|
SuperName
|
—
|
0x77
|
MultiplyOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x78
|
DivideOp
|
Term Object
|
TermArg TermArg Target Target
|
—
|
0x79
|
ShiftLeftOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x7A
|
ShiftRightOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x7B
|
AndOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x7C
|
NandOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x7D
|
OrOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x7E
|
NorOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x7F
|
XorOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x80
|
NotOp
|
Term Object
|
TermArg Target
|
—
|
0x81
|
FindSetLeftBitOp
|
Term Object
|
TermArg Target
|
—
|
0x82
|
FindSetRightBitOp
|
Term Object
|
TermArg Target
|
—
|
0x83
|
DerefOfOp
|
Term Object
|
TermArg
|
—
|
0x84
|
ConcatResOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x85
|
ModOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x86
|
NotifyOp
|
Term Object
|
SuperName TermArg
|
—
|
0x87
|
SizeOfOp
|
Term Object
|
SuperName
|
—
|
0x88
|
IndexOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x89
|
MatchOp
|
Term Object
|
TermArg ByteData TermArg
ByteData TermArg TermArg
|
—
|
0x8A
|
CreateDWordFieldOp
|
Term Object
|
TermArg TermArg NameString
|
—
|
0x8B
|
CreateWordFieldOp
|
Term Object
|
TermArg TermArg NameString
|
—
|
0x8C
|
CreateByteFieldOp
|
Term Object
|
TermArg TermArg NameString
|
—
|
0x8D
|
CreateBitFieldOp
|
Term Object
|
TermArg TermArg NameString
|
—
|
0x8E
|
ObjectTypeOp
|
Term Object
|
SuperName
|
—
|
0x8F
|
CreateQWordFieldOp
|
Term Object
|
TermArg TermArg NameString
|
—
|
0x90
|
LandOp
|
Term Object
|
TermArg TermArg
|
—
|
0x91
|
LorOp
|
Term Object
|
TermArg TermArg
|
—
|
0x92
|
LnotOp
|
Term Object
|
TermArg
|
—
|
0x92 0x93
|
LNotEqualOp
|
Term Object
|
TermArg TermArg
|
—
|
0x92 0x94
|
LLessEqualOp
|
Term Object
|
TermArg TermArg
|
—
|
0x92 0x95
|
LGreaterEqualOp
|
Term Object
|
TermArg TermArg
|
—
|
0x93
|
LEqualOp
|
Term Object
|
TermArg TermArg
|
—
|
0x94
|
LGreaterOp
|
Term Object
|
TermArg TermArg
|
—
|
0x95
|
LLessOp
|
Term Object
|
TermArg TermArg
|
—
|
0x96
|
ToBufferOp
|
Term Object
|
TermArg Target
|
—
|
0x97
|
ToDecimalStringOp
|
Term Object
|
TermArg Target
|
—
|
0x98
|
ToHexStringOp
|
Term Object
|
TermArg Target
|
—
|
0x99
|
ToIntegerOp
|
Term Object
|
TermArg Target
|
—
|
0x9A-0x9B
|
—
|
—
|
—
|
—
|
0x9C
|
ToStringOp
|
Term Object
|
TermArg TermArg Target
|
—
|
0x9D
|
CopyObjectOp
|
Term Object
|
TermArg SimpleName
|
—
|
0x9E
|
MidOp
|
Term Object
|
TermArg TermArg TermArg Target
|
—
|
0x9F
|
ContinueOp
|
Term Object
|
—
|
—
|
0xA0
|
IfOp
|
Term Object
|
TermArg
|
TermList
|
0xA1
|
ElseOp
|
Term Object
|
—
|
TermList
|
0xA2
|
WhileOp
|
Term Object
|
TermArg
|
TermList
|
0xA3
|
NoopOp
|
Term Object
|
—
|
—
|
0xA4
|
ReturnOp
|
Term Object
|
TermArg
|
—
|
0xA5
|
BreakOp
|
Term Object
|
—
|
—
|
0xA6-0xCB
|
—
|
—
|
—
|
—
|
0xCC
|
BreakPointOp
|
Term Object
|
—
|
—
|
0xCD-0xFE
|
—
|
—
|
—
|
—
|
0xFF
|
OnesOp
|
Data Object
|
—
|
—
|
|
| |
18.4 AML Encoding of Names in the
Namespace
Assume the following namespace exists:
\
S0
MEM
SET
GET
S1
MEM
SET
GET
CPU
SET
GET
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
}
This will be encoded in AML as:
'STP1'
ParentPrefixChar
'GET_'
ParentPrefixChar
ParentPrefixChar 'PCI0'
ParentPrefixChar
ParentPrefixChar DualNamePrefix 'PCI0' 'SBS_'
RootChar 'S2__'
RootChar
MultiNamePrefix 3 'S2__' 'ISA_' 'COM1'
ParentPrefixChar
ParentPrefixChar ParentPrefixChar 'S3__'
ParentPrefixChar
ParentPrefixChar ParentPrefixChar DualNamePrefix 'S2__' 'MEM_'
ParentPrefixChar
ParentPrefixChar ParentPrefixChar MultiNamePrefix 3 'S2__' 'MEM_' 'SET_'
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
APPENDIX A: Device Class Specifications
A Device Class PM Specifications
This section defines the behavior of devices as that
behavior relates to power management and, specifically, to the four device
power states defined by ACPI. The goal is enabling device vendors to design
power-manageable products that meet the basic needs of OSPM and can be utilized
by any ACPI-compatible operating system.
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 system's 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
system's 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.
A.2 Device Power States
The following definitions apply to devices of all classes:
· D0. State in which device
is on and running. It is receiving full power from the system and is delivering
full functionality to the user.
· D1. Class-specific
low-power state (defined in the following section) in which device context may
or may not be lost. Buses in D1 cannot do anything to the bus that would force
devices on that bus to lose context.
· D2. Class-specific
low-power state (defined in the following section) in which device context may
or may not be lost. Attains greater power savings than D1. Buses in D2 can
cause devices on that bus to lose some context (for example, the bus reduces
power supplied to the bus). Devices in D2 must be prepared for the bus to be in
D2 or higher.
· D3. State in which device
is off and not running. Device context is lost. Power can be removed from the
device.
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
device-specific 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.
A.2.1 Bus Power Management
Policy owners for bus devices (for example, PCI, USB, Small
Computer System Interface [SCSI]) have the additional responsibility of
tracking the power states of all devices on the bus and for transitioning the
bus itself to only those power states that are consistent with those of its
devices. This means that the bus state can be no lower than the highest state
of one of its devices. However, enabled wake events can affect this as well.
For example, if a particular device is in the D2 state and set to wake the
system and the bus can only forward wake requests while in the D1 state, then
the bus must remain in the D1 state even if all devices are in a lower state.
Below are summaries of relevant bus power management
specifications with references to the sources.
A.2.2 Display Power Management
Refer to the Display Power Management Signaling
Specification (DPMS), available from:
Video Electronics Standards Association (VESA)
2150 North First Street
Suite 440
San Jose, CA 95131-2029
A DPMS-compliant video controller and DPMS-compliant
monitor use the horizontal and vertical sync signals to control the power mode
of the monitor. There are 4 modes of operation: normal, standby, suspend and
off. DPMS-compliant video controllers toggle the sync lines on or off to select
the power mode.
A.2.3 PCMCIA/PCCARD/CardBus
Power Management
Refer to the PCMCIA (Personal Computer Memory Card
International Association) Web site, at http://www.pcmcia.org.
PCMCIA and PCCARD devices do not have device power states
defined. The only power states available are on and off, controlled by the host
bus controller. The CardBus specification is a superset of the PCCARD
specification, incorporating the power management specification for PCI bus.
Power management capabilities query, state transition commands and wake event
reporting are identical.
A.2.4 PCI Power Management
Refer to the PCI Special Interest Group (PCISIG) Web site,
at http://www.pcisig.com/.
· PCI Bus Power Management Capabilities Query. PCI Bus device capabilities are
reported via the optional Capabilities List registers, which are accessed via
the Cap_Ptr.
· PCI Bus Power Management State Transition Commands. PCI Bus device power states are controlled and
queried via the standard Power Management Status/Control Register (PMCSR).
· PCI Bus Wakeup Event Reporting. PCI wake events are reported on the optional PME# signal, with
setting of the Wake_Int bit in the PMCSR. Wake event reporting is controlled by
the Wake_En bit in the PMCSR register.
A.2.5 USB Power Management
Refer to the Universal Serial Bus Implementers Forum
(USB-IF ) Web site, at http://www.usb.org/.
· USB Power Management Capabilities Query. USB device capabilities are reported to the USB
Host via the standard Power Descriptors. These address power consumption,
latency time, wake support, and battery support and status notification.
· USB Power Management State Transition Commands. USB device power states are controlled by the USB
Host via the standard SET_FEATURE command. USB device power states are queried
via the standard USB GET_STATUS command.
· USB Wakeup Event Reporting.
USB wake event reporting is controlled using the SET_FEATURE command, with
value DEVICE_REMOTE_WAKEUP. USB wake events are reported by sending remote wake
resume signaling.
A.2.6 Device Classes
Below is a list of the class-specific device power
management definitions available in this specification. Notice that there
exists a default device class definition that applies to all devices, even if
there is a separate, class-specific section that adds additional requirements.
· Audio Device Class.
Applies to audio devices.
· COM Port Device Class.
Applies to COM ports devices.
· Display Device Class.
Applies to CRT monitors, LCD panels, and video controllers for those devices.
· Input Device Class.
Applies to standard types of input devices such as keyboards, keypads, mice,
pointing devices, joysticks, and game pads, plus new types of input devices
such as virtual reality devices.
· Modem Device Class.
Applies to modem and modem-like (for example, ISDN terminal adapters) devices.
· Network Device Class.
Applies specifically to Ethernet and token ring adapters. ATM and ISDN adapters
are not supported by this specification.
· PC Card Controller Device Class. Applies to PC Card controllers and slots.
· Storage Device Class.
Applies specifically to ATA hard disks, floppy disks, ATAPI and SCSI CD-ROMs,
and the IDE channel.
A.3 Default Device Class
The requirements expressed in this section apply to all
devices, even if there is a separate, class-specific power management
definition that identifies additional requirements.
A.3.1 Default Power State Definitions
State
|
Definition
|
D0
|
Device is on and running. It is receiving full power from the
system, and is delivering full functionality to the user.
|
D1
|
This state is not defined and not used by the default device
class.
|
D2
|
This state is not defined and not used by the default device
class.
|
D3
|
Device is off and not running. Device context is assumed
lost, and there is no need for any of it to be preserved in hardware. This
state should consume the minimum power possible. Its only requirement is to
recognize a bus-specific command to re-enter D0. Power can be removed from
the device while in D3. If power is removed, the device will receive a
bus-specific hardware reset upon reapplication of power, and should
initialize itself as in a normal power on.
|
A.3.2 Default Power Management
Policy
Present State
|
Next State
|
Cause
|
D0
|
D3
|
Device determined by the OS to not be needed by any
applications or the user.
System enters a sleeping state.
|
D3
|
D0
|
Device determined by the OS to be needed by some application
or the user.
|
A.3.3 Default Wake Events
There are no default wake events, because knowledge of the
device is implicit in servicing such events. Devices can expose wake
capabilities to OSPM, and device-specific software can enable these, but there
is no generic application-level or OS-wide support for undefined wake events.
A.3.4 Minimum Power Capabilities
All devices must support the D0 and D3 states.
Functionality available in D0 must be available after returning to D0 from D3
without requiring a system reboot or any user intervention. This requirement
applies whether or not power is removed from the device during D3.
A.4 Audio Device Class
The requirements expressed in this section apply to audio
devices.
A.4.1 Power State Definitions
State
|
Status
|
Definition
|
D0
|
Required
|
Power is on. Device is operating.
|
D1
|
Optional
|
Power consumption is less than D0 state. Device must be able
to transition between D0 and D1 states within 100 ms. No audio samples may be
lost by entering and leaving this state.
|
D2
|
Required
|
Power consumption is less than D0 state. Device must be able
to transition between D0 and D2 states within 100 ms. Audio samples may be
lost by entering and leaving this state.
|
D3
|
Required
|
The device is completely off or drawing minimal power
example, a stereo will be off, but a light-emitting diode (LED) may be on and
the stereo may be listening to IR commands.
|
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
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 D2-capable 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.
A.4.2 Power Management Policy
For the purpose of the following state transition policy,
the following device-specific operational states are defined:
· Playing. Audio is
playing.
· Recording:
· Foreground
>. Normal application is recording. Recording is
considered foreground unless specifically designated low priority.
· Background
>. Speech recognition or speech activity detection is
running. Recording may be preempted by foreground recording or playing
audio recording may be designated as background.
· Full Duplex. Device is
simultaneously playing and recording.
· Paused. File handle is
open. Only devices that are playing, foreground recording or in full duplex
operation may be paused. Background recording may not be paused. State is
static and never lost. The paused state assumes that a device must transition
to the resumed state rapidly. Playing or recording must be resumed within 100 ms.
No audio samples may be lost between the device is paused and later resumed.
· Closed. No file handle is
open.
Present State
|
Next State
|
Cause
|
D3
|
D0
|
Audio device moves from closed to open state or paused when
the device receives the resume command.
|
D0
|
D1
|
Audio device receives pause command. If device is D1 capable,
this state is preferred. If not, the device driver will preserve context, and
the device will be set to D2.
|
D2/D1
|
D0
|
Audio device receives a resume command.
|
D0
|
D2
|
Audio device is closed. Audio inactivity timer started.
|
D2
|
D3
|
Audio inactivity timer expires.
|
D0
|
D3
|
Audio device is in background record mode and receives
power-down command.
|
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.
A.4.3 Wake Events
An audio device may be a wake device. For example, a USB
microphone designed for security applications might use the USB wake mechanism
to signal an alarm condition.
A.4.4 Minimum Power Capabilities
All audio devices must be capable of D0, D2 and D3 power
states. If the device is capable of maintaining context while in a low-power
state it should advertise support for D1. Transitional latency for the D2 or D3
states must be less than 100 ms. There are no latency restrictions for D3
transitions, but the policy owner should advertise the amount of time required.
A.5 COM Port
Device Class
The requirements expressed in this section apply to
Universal Asynchronous Receiver/Transmitters (UARTs) such as the common NS16550
buffered serial port and equivalents.
The two required states for any power-managed COM Port are
full on (D0) and full off (D3). This in turn requires that the COM port
hardware be power-manageable by ACPI control methods for COM ports that are on
system boards, or by standard bus power management controls for COM ports that
are on add-in cards (for example, PCI). Because of this, ISA-based COM port
add-in cards will not be able to meet this requirement, and therefore cannot be
compliant with this specification.
A.5.1 Power State Definitions
State
|
Status
|
Definition
|
D0
|
Required
|
Line drivers are on. UART context is preserved.
|
D1
|
N/A
|
This state is not defined for COM Ports. Use the D3 state
instead.
|
D2
|
N/A
|
This state is not defined for COM Ports. Use the D3 state
instead.
|
D3
|
Required
|
Line drivers are off (unpowered; outputs isolated from devices
attached to the port). UART context is lost. Latency to return to D0 is less
than 1 second.
|
A.5.2 Power Management Policy
Present State
|
Next State
|
Cause
|
D3
|
D0
|
Power-on reset
COM port opened by an application
|
D0
|
D3
|
COM port closed
System enters sleeping state while wake is disabled on this
device.
System enters sleeping state while wake is enabled on this
device and the device is capable of generating wake to the system from state
D3.
|
A.5.3 Wake Events
If the COM port is capable of generating wake events,
asserting the "ring indicator" line (V.24 circuit 125) will cause the COM port
to assert a wake event. There are two common mechanisms that may be employed
(either one or both) for performing machine wake using COM ports.
The first provides a solution that is capable of waking the
PC whether the UART is powered (D0) or not (D3). Here, the "ring indicator"
line (from V.24 circuit 125) is commonly connected directly to the system wake
device in addition to being connected to the UART. While this implementation is
normative for COM ports located on system motherboards (see the ACPI
specification), it could also be done by add-in cards with COM ports that
reside on buses supporting system wake from devices in D3 (for example, PME#
signal on PCI).
The second mechanism requires that the UART be powered (D0)
to use the UART's interrupt output pin to generate the wake event instead. When
using this method, the OS COM port policy owner or power management control
methods are expected to configure the UART. Although any UART interrupt source
(for example, 'data ready') could theoretically be used to wake the system,
these methods are beyond the scope of this document.
A.5.4 Minimum Power Capabilities
A COM port conforming to this specification must support
the D0 and D3 states.
A.6 Display Device Class
The requirements expressed in this section apply to all
devices engaged in the display of program content, which includes full screen
display devices, display controllers, and graphics adapters. This class does
not include video capture devices unless they are children of the graphics
adapter. This class does not include edge displays or hardware indicators for
device states.
While saving power from the display and adapter are primary
goals of Display Device Class power management definitions, the definitions are
also intended to ensure that the user perceives the system as "off"during system sleeping states, as required above. When the system enters a
lower power state, the screen must go black so the user knows the system is
idle. This is important because devices that cannot actually save power
(standard televisions, for example) can still support the user notice of system
idle by going black.
A.6.1 Power State Definitions
A.6.1.1 CRT
Monitors (not including other full screen displays)
State
|
Status
|
Definition
|
D0
|
Required
|
This state is equivalent to the "On" state defined in the VESA
DPMS specification (see Related Documents) and is signaled to the display
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
|
CRT Monitors are a special case in power management
the one hand, they support a common defined method (DPMS) for changing power
states. On the other hand, that procedure and the CRT support is extremely
slow and out of keeping with other faster power control methods used by other
forms of display. This definition should not preclude the use of faster and
more effective methods of transitioning the CRT if they are available and known
to the controller. DPMS is not recommended as solution for new display devices
in the future.
A.6.1.2 Internal Flat Panel Devices
State
|
Status
|
Definition
|
D0
|
Required
|
This state is equivalent to the "On" state for a DPMS device,
but is signaled to the panel by the correct application of power and/or
controller specific signaling.
Display is fully on
Backlight (if present) is fully on(subject to performance
state requirements – see below)
Video image is active
|
D1
|
Optional
|
This state is not required to be physically different than a
D3 state if the device is able to meet the resume requirement and the driver
is able to restore state.
Display retains internal state but may be conserving energy
Backlight(if present) is fully off
Video image is blank
Latency to return to D0 must be less than 500 milliseconds
|
D2
|
Optional
|
This state is not required to be physically different than a
D3 state if the device is able to meet the resume requirement and the driver
is able to restore state.
Display retains state but is conserving energy
Backlight (if present) is fully off; Video image is blank
Latency to return to D0 is less than 500 milliseconds
|
D3
|
Required
|
This state is equivalent to the "Off" state defined in the
VESA DPMS specification. It is signaled by the removal of power or possibly
by controller-specific signaling.
Display is non-functional
Backlight (if present) is fully off.
Video image is blank
Latency to return to D0 is less than 500 milliseconds
|
Internal flat panels (also known as local flat panels or
sometimes as LCDs) do not normally support or require DPMS signaling to change
power states. Instead, controllers capable of managing such panels tend to
provide vendor-specific methods to control internal flat panels, often
involving special sequencing of power signals to the panel. Some may be
managed only by the application or removal of power.
Backlight control for power management states is likewise
controller and even platform specific. Note that on-off backlight control for
power management states is often unrelated to backlight intensity or brightness
control that is used while in the D0 state.
The 500 milliseconds is only to allow some existing
hardware to function . The target for new devices should be 100 milliseconds.
A.6.1.3 DVI Displays (Digital Flat
Panels and DVI Monitors)
State
|
Status
|
Definition
|
D0
|
Required
|
This state is equivalent to the "On" state for a DPMS device,
but is signaled to the display by the correct application of power and/or
controller specific signaling.
Display is fully on
Video image is active
|
D1
|
Optional
|
This state is not required to be physically different than a
D3 state if the device is able to meet the resume requirement and the driver
is able to restore state. It is signaled by the removal of display output and
time expiring. The physical state entered is no different than D2.
Display retains internal state but may be conserving energy
Video image is blank
Latency to return to D0 must be less than 250 milliseconds
|
D2
|
Optional
|
This state is not required to be physically different than a
D3 state if the device is able to meet the resume requirement and the driver
is able to restore state. It is signaled by the removal of display output and
time expiring The physical state entered is no different than D1.
Display retains state but is conserving energy
Video image is blank
Latency to return to D0 is less than 250 milliseconds
|
D3
|
Required
|
This state is equivalent to the "Off" state defined in the
VESA DPMS specification. It is signaled by the removal of display output and
time expiring
Display is non-functional
Video image is blank
Latency to return to D0 is less than 250 milliseconds
|
Although 250 milliseconds is shown here because not all
devices in this group are fast now, the target resume for a new device should
be 100 milliseconds.
A.6.1.4 Standard TV Devices (and Analog HDTVs)
State
|
Status
|
Definition
|
D0
|
Required
|
This state is equivalent to the "On" state for a DPMS device.
Display is fully on
Video image is active
|
D1
|
Optional
|
Video image is blank
Latency to return to D0 must be less than 100 milliseconds
|
D2
|
Optional
|
Video image is blank
Latency to return to D0 must be less than 100 milliseconds
|
D3
|
Required
|
This state is not equivalent to the "Off" state defined in the
VESA DPMS specification because not power is actually saved.
Video image is blank
Latency to return to D0 is less than 100 milliseconds
|
A.6.1.5 Other (new) Full Screen Devices
Some devices not specifically defined here already exist,
such as projectors that emulate CRTs or HDTVs. Others may be coming. It is important
for any device used for full screen display to support power transitions and
power management states, but the primary requirement for the method should be
low overhead.
State
|
Status
|
Definition
|
D0
|
Required
|
This state is equivalent to the "On" state for a DPMS device,
but is signaled to the panel by the correct application of power and/or
device specific signaling known to the controller.
Display is fully on
Video image is active
|
D1
|
Optional
|
This state is not required to be physically different than a
D3 state if the device is able to meet the resume requirement and the driver
is able to restore state. It is signaled to the panel by the correct
application of power and/or device specific signaling known to the
controller..
Display retains internal state but may be conserving energy
Video image is blank
Latency to return to D0 must be less than 100 milliseconds
|
D2
|
Optional
|
This state is not required to be physically different than a
D3 state if the device is able to meet the resume requirement and the driver
is able to restore state. It is signaled to the panel by the correct
application of power and/or device specific signaling known to the
controller.
Display retains state but is conserving energy
Video image is blank
Latency to return to D0 is less than 100 milliseconds
|
D3
|
Required
|
This state is equivalent to the "Off" state defined in the
VESA DPMS specification. It is signaled by the removal of display output
and/or device specific methods known to the controller.
Display is non-functional
Video image is blank
Latency to return to D0 is less than 250 milliseconds
|
Although 250 milliseconds is shown here because not all
devices in this group are fast now, the target resume for a new device should
be 100 milliseconds.
A.6.1.6 Video Controllers (Graphics Adapters)
State
|
Status
|
Definition
|
D0
|
Required
|
Back-end is on
Video controller context is preserved
Video memory contents are preserved
|
D1
|
Optional
|
Back-end is off, except for CRT control signaling (DPMS)
Video controller context is preserved
Video memory contents is preserved
Latency to return to D0 is less than 100 milliseconds
|
D2
|
Optional
|
Back-end is off, except for CRT control signaling (DPMS)
Video controller context is lost
Video memory contents is lost
Latency to return to D0 is less than 200 milliseconds
|
D3
|
Required
|
Back-end is off
Video controller context is lost (power removed)
Video memory contents is lost (power removed)
Latency to return to D0 is less than 200 milliseconds
|
A.6.1.7 Display Codecs
Like the displays they control, display codecs are children
of the adapter and cannot be in a higher state than the adapter or a lower
state than the displays they control . It is generally not helpful to deal
with codecs entirely separately from the adapter or the displays they control.
While it may vary from device to device, a codec will either be safely powered
down when its display is powered down or it may require power as long as the
adapter receives power.
A.6.2 Power Management Policy
for the Display Class
Present State
|
Next State
|
Cause
|
D0
|
D1
|
User inactivity for a period of time (T1)
|
D1
|
D2
|
User inactivity for a period of time (T2 > T1)
|
D2
|
D3
|
User inactivity for a period of time (T3 > T2)
|
D1/D2/D3
|
D0
|
User activity or application UI change (for example, dialog
pop-up)
|
These state transition definitions apply to both the full
screen display 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 full screen display. Also, while full screen
displays can transition directly from D1 to D3 or from D2 to D3, the adapters
require a transition to D0 from D1 or D2 before entering D3.
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 and are only generated as a
result of explicit commands from the policy-owner. Full screen display 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 from the video controller
using the methods above.
A.6.3 Wake Events
Display devices incorporating a system power switch should
generate a wake event when the switch is pressed while the system is sleeping.
A.6.4 Minimum Power Capabilities
A CRT monitor conforming to this specification must support
the D0, D2, and D3 states. Other full screen displays only need to support D0
and D3. Support for the D1 state is optional in all cases. Transitional
latencies for the D1 or D2 state must meet the requirements above.
A video controller conforming to this specification must
support the D0 and D3 states. Support for the D1 and D2 states is optional.
Transitional latencies for the D1 must be less than 100 milliseconds while D2
and D3 must transition to D0 in less than 200 milliseconds.
A.6.5 Performance States
for Display Class Devices
Performance states for display devices and adapters have
one clear difference from defined power management states. There is no display
in any power management state higher than D0. However, performance states are
all applied within D0, which means they save power while continuing to display.
Not all display class devices will support performance states, but in all
cases, they must allow continued display where they exist.
A.6.5.1 Common Requirements for Display Class
Performance States
The definition of each state (up the line toward the OSPM)
must include maximum latency information on transitions into the state and
transitions out of the state. (For states other than DPS1, it may be necessary
to indicate whether the latency is the time from DPS0 to DPSx or only from
DPSx-1 to DPSx.)
Each state has to have a relative weight indicator or a
relative power savings indicator. I.e., it can make a difference in OSPM
policies whether DPS1 saves 2% power and DPS2 save 75% power even if latency is
longer.
While ASL NameSpace structures may provide some of this
information, it is recommended that display class performance states be entered
and exited by driver and not by control method wherever possible.
A.6.5.2 Performance states for Full Screen Displays
A.6.5.2.1 CRT Performance States
Some CRTs (in theory) have the capability for "reduced
on" -- a mode which displays but uses less power than full performance.
Even without this capability, a CRT may be able to use reduced refresh or other
methods to reduce the total power of displaying.
A.6.5.2.2 Internal Flat Panel
In general, panels consume a fixed amount of power.
However, some panels are also capable of supporting reduced refresh. More
important, the amount of backlight brightness is a major factor in system
power. This clearly needs to be coordinated with direct ASL control methods
for brightness and with ambient light sensing when present. However, a performance
state may be achieved by offsetting the brightness value computed by other
methods, either by a fixed amount or a fixed percentage.
A.6.5.2.3 DVI Full Screen Devices
DVI Devices are normally capable of frequency control and
may be able to benefit by frequency control. However, because of sensitivity
to signal loss, DVI devices may have limitations on other types of performance
control.
A.6.5.2.4 Standard TV and Analog HDTVs
Standard TV and Analog HDTVs do not appear capable of
performance states. Codecs controlling them may be capable of power saving,
however.
A.6.5.2.5 New Devices
The ability to reduce power while continuing to display
will be increasingly important
A.6.5.3 Performance States for Video Controllers/Display
Adapters
Adapters are somewhat limited during performance states
because they have to continue to support display on one or more full screen
devices. However, they can still do a number of things to support performance
states, including
· Changes to basic display and render capabilities, including speed
or frequency range supported.
· Feature/Capability/Quality Control – limiting specific
hardware features, limiting refresh rates, limiting resolutions.
The limiting factor on what can be supported may sometimes
be in the OSPM. If the OSPM support dynamic changes in these features during a
performance state change (even if no other time), more opportunities arise.
Once again, the latency on transitions and the power saved
by specific states have to be made available to the OSPM in order to use these
options effectively.
A.7 Input Device Class
The requirements expressed in this section apply to
standard types of input devices such as keyboards, keypads, mice, pointing
devices, joysticks, game pads, to devices that combine these kinds of input
functionality (composite devices, and so on), and to new types of input devices
such as virtual reality devices, simulation devices, and so on.
A.7.1 Power State Definitions
State
|
Status
|
Definition
|
D0
|
Required
|
Device is receiving full power from its power source,
delivering full functionality to the user, and preserving applicable context
and state information.
|
D1
|
Optional
|
Input device power consumption is greatly reduced. In general,
device is in a power management state and is not delivering any functionality
to the user except wake functionality if applicable. Device status, state, or
other information indicators (for example, LEDs, LCD displays, and so on) are
turned off to save power.
The following device context and state information should be
preserved by the policy owner or other software:
Keyboard. Num, caps,
scroll lock states (and Compose and Kana states if applicable) and associated
LED/indicator states, repeat delay, and repeat rate.
Joystick. Forced
feedback effects (if applicable).
Any input device
context and state information that cannot be preserved by the device when
it's conserving power.
|
D2
|
N/A
|
This state is not defined for input devices, use D1 as the
power management state instead.
|
D3
|
Required
|
Input device is off and not running. In general, the device is
not delivering any functionality to the user except wake functionality if
applicable. Device context and state information is lost.
|
A.7.2 Power Management Policy
Present State
|
Next State
|
Cause
|
D3
|
D0
|
Requested by the system
|
D0
|
D1/D3*
|
Requested by the system (for example, system goes to sleep
with wake enabled)
|
D0/D1
|
D3
|
Requested by the system (for example, system goes to sleep
with wake disabled)
Power is removed
|
D1/D3
|
D0
|
Device with enabled wake capability requests transition by
generating a wake event
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.
A.7.3 Wake Events
It is recommended, but not required, that input devices
implement and support bus-specific wake mechanisms if these are defined for
their bus type. This is recommended because a user typically uses an input
device of some kind to wake the system when it is in a power management state
(for example, when the system is sleeping).
The actual input data (particular button or key pressed)
that's associated with a wake event should never be discarded by the device
itself, but should always be passed along to the policy owner or other software
for further interpretation. This software implements a policy for how this
input data should be interpreted, and decides what should be passed along to
higher-level software, and so on.
It is recommended that the device button(s) or key(s) used
for power management purposes are clearly labeled with text and/or icons. This
is recommended for keyboards and other input devices on which all buttons or
keys are typically labeled with text and/or icons that identify their usage.
For example, a keyboard could include a special-purpose
power management button (for example, "Power") that, when pressed during a
system sleeping state, generates a wake event. Alternatively, the button(s) on
mice and other pointing devices could be used to trigger a wake event.
Examples of more advanced wake events include keyboard wake
signaling when any key is pressed, mouse wake signaling on detection of X/Y
motion, joystick wake signaling on X/Y motion, and so on. However, in order to
avoid accidental or unintentional wake of the system, and to give the user some
control over which input events will result in a system wake, it's suggested
that more advanced types of wake events are implemented as features that can be
turned on or off by the user (for example, as part of the OSPM user interface).
A.7.4 Minimum Power Capabilities
An input device conforming to this specification must
support the D0 and D3 states. Support for the D1 state is optional.
A.8 Modem Device Class
The requirements expressed in this section apply to modems
and similar devices, such as USB controlled ISDN Terminal Adapters ("digital
modems") and computer-connected telephone devices ("CT phones"). This
specification will refer to these devices as "modems; the same considerations
apply to digital modems and CT phones unless explicitly stated otherwise.
The scope of this section is further restricted to modems
that support power management using methods defined by the relevant PC-modem
connection bus. These include PCI, USB, PCCARD (PCMCIA), CardBus, and modems on
the system motherboard described by ACPI BIOS control methods. The scope does
not include bus-specific means for devices to alert the host PC (for example,
how to deliver a "ringing"' message), nor does it address how those alerting
operations are controlled.
A.8.1 Technology Overview
Modems are traditionally serial devices, but today modems
may be attached to a PC by many different means. Further, many new modems
expose a software serial interface, where the modem controller function is
implemented in software. This specification addresses three different
connection types:
· Traditional connections without power-managed connections (for
example, COM, LPT, ISA)
· Power managed connections (for example, PCCARD, CardBus, PCI,
USB)
· Motherboard modems
For some of the above modem connection types mentioned,
there are three different modem architectures possible:
· Traditional modem (DAA, DSP, and controller in hardware)
· Controller-less design (DAA and DSP in hardware)
· "Soft modem" design (DAA and CODEC only in hardware)
The hardware components of the modem shall be controlled by
the relevant bus commands, where applicable (USB, PCI, CardBus). The software
components are dependent on the power state of the CPU.
A.8.1.1 Traditional
Connections
In older methods (COM, LPT, ISA) the modem is controlled
primarily by serialized ASCII command strings (for example, V.25ter) and
traditional V.24 (RS-232) out-of-band leads. In these legacy devices, there are
no common means for power management other than the power switch for the
device, or the entire system unit.
An external modem connected to a COM port or LPT port
typically has its own power supply. An LPT port modem might run from the
current on the LPT port +5V supply. For COM or LPT port modems, power is
typically controlled by a user switch.
The most common modem type is an ISA card with an embedded
COM port. From a software standpoint, they are logically identical to external
modems, but the modems are powered by the PC system unit. Power is drawn from
the ISA bus without independent power switching.
A.8.1.2 Power-Managed
Connections
PCMCIA, PCCARD and CardBus slots are powered and
power-managed by the system, using means defined in the relevant bus
specifications. For PCMCIA and PCCARD devices, only D0 and D3 states are
available, via Socket Services in the OS and/or ACPI BIOS. CardBus adds
intermediate states, using the same mechanisms defined for PCI Bus.
PCI bus slots are powered and power-managed by the system,
using means defined in the PCI specification.
USB devices may be powered by the USB itself (100mA or
500mA), or have their own external power supply. All USB devices are
power-managed by the USB bus master, using means defined in the USB specification.
A.8.1.3 Motherboard
Modems
A modem embedded in the motherboard is powered by controls
on the motherboard. It should be power-managed by using control methods exposed
via ACPI BIOS tables.
A.8.2 Power State Definitions
State
|
Status
|
Definition
|
D0
|
Required
|
Phone interface is on (may be on or off hook)
Speaker is on
Controller Context is preserved
|
D1
|
N/A
|
Not defined (do not use)
|
D2
|
Optional
|
Phone interface is not powered by the host (on hook)
Speaker is off
Controller context is preserved
2 seconds maximum restore time
|
D3
|
Required
|
Phone interface is not powered by host (on hook)
Speaker is off
Controller context may be lost
5 seconds maximum restore time
|
A.8.3 Power Management Policy
Present State
|
Next State
|
Cause
|
D2/D3
|
D0
|
System issues a bus command to enter the D0 state (for
example, an application is answering or originating a call).
|
D0
|
D2
|
System issues a bus command to enter the D2 state. (for
example, an application is listening for an incoming call).
|
D0
|
D3
|
System issues a bus command to enter the D3 state (for
example, all applications have closed the Modem device).
|
A.8.4 Wake Events
For any type of modem device, wake events (if supported and
enabled) are only generated in response to detected "ringing" from an incoming
call. All other events associated with modems (V.8bis messages, and so on)
require that the PC be in the "working" state to capture them. The methods and
signals used to generate the wake may vary as a function of the modem
connection (bus) type and modem architecture.
Machine wake is allowed from any modem power state (D0, D2,
and D3), and is accomplished by methods described in the appropriate bus power
management specification (PCI, USB, PCCARD), or by ACPI system board control
methods (for Modem on Motherboard implementations).
If the specific modem implementation or connection type
does not enable it to assert system wake signaling, these modems will not be
able to wake the machine. The OS modem policy owner will have to retain the PC
in the "working" state to perform all
types of event detection (including ringing).
A.8.5 Minimum Power Capabilities
A modem or similar device conforming to this specification
must support the D0 and D3 states. Support of the D2 state is optional.
A.9 Network Device Class
The requirements expressed in this section apply to
Ethernet and token ring adapters. ATM and ISDN adapters are not supported by
this specification.
A.9.1 Power State Definitions
For the purpose of the following state definitions "no bus
transmission" means that transmit requests from the host processor are not
honored, and "no bus reception" means that received data are not transferred to
host memory.
State
|
Status
|
Definition
|
D0
|
Required
|
Device is on and running and is delivering full functionality
and performance to the user
Device is fully compliant with the requirements of the
attached network
|
D1
|
Optional
|
No bus transmission allowed
No bus reception allowed
No interrupts can occur
Device context may be lost
|
D2
|
Optional
|
No bus transmission allowed
No bus reception allowed
No interrupts can occur
Device context may be lost
|
D3
|
Required
|
Device context is assumed to be lost
No bus transmission allowed
No bus reception allowed
No interrupts can occur
|
This document does not specify maximum power and maximum
latency requirements for the sleeping states because these numbers are very
different for different network technologies. The device must meet the
requirements of the bus that it attaches to.
Although the descriptions of states D1 and D2 are the same,
the choice of whether to implement D1 or D2 or both may depend on bus services
required, power requirements, or time required to restore the physical layer.
For example, a device designed for a particular bus might include state D1
because it needs a bus service such as a bus clock to support Magic Packet™
wake, and that service is available in the bus device's D1 power state but not
in D2. Also, a device might include both state D1 and state D2 to provide a
choice between lower power and lower latency.
A.9.2 Power Management Policy
Present State
|
Next State
|
Cause
|
D0
|
Dx
|
System enters sleep state. If wake is enabled, Dx is the lowest power state (for example, D1, D2,
D3) from which the network device supports system wake.
An appropriate time-out has elapsed after a "link down"
condition was detected. Dx is the
lowest power state in which the network device can detect "link up."
|
D0
|
D3
|
System initiated network shutdown.
System enters sleep state and wake is either not enabled or
the network device is capable of waking from D3.
|
D1/D2/D3
|
D0
|
System wake (transition to S0), including a wake caused by a
network wake event.
|
A.9.3 Wake Events
Network wake events are generally the result of either a
change in the link status or the
reception of a wake frame from
the network.
A.9.3.1 Link
Status Events
Link status wake events are useful to indicate a change in
the network's availability, particularly when this change may impact the level
at which the system should re-enter the sleeping state. For example, a
transition from "link off" to "link on" may trigger the system to re-enter
sleep at a higher level (for example, S2 versus S3) so that wake frames can be
detected. Conversely, a transition from "link on" to "link off" may trigger the
system to re-enter sleep at a deeper level (for example, S3 versus S2) since
the network is not currently available. The network device should implement an
internal delay to avoid unnecessary transitions when the link status toggles on
or off momentarily.
A.9.3.2 Wake
Frame Events
Wake frame events are used to wake the system whenever meaningful data is presented to the system over the network.
Examples of meaningful data include the reception of a Magic Packet™, a
management request from a remote administrator, or simply network traffic
directly targeted to the local system. In all of these cases the network device
was pre-programmed by the policy owner or other software with information on
how to identify wake frames from other network traffic. The details of how this
information is passed between software and network device depend on the OS and
therefore are not described in this specification.
A.9.4 Minimum Power Capabilities
A network device conforming to this specification must
support the D0 and D3 states. Support for the D1 and D2 states is optional.
A.10 PC Card Controller Device
Class
The requirements expressed in this section apply to PC Card
controller devices and the PC Card slots.
Power management of PC Cards is not defined by this specification. PC Card power management is
defined by the relevant power management specification for the card's device
class (for example, network, modem, and so on), in conjunction with the PC Card
standard (for 16-bit cards) or the PCI Power Management Specification (for
CardBus cards).
A.10.1 Power State Definitions
State
|
Status
|
Definition
|
D0
|
Required
|
Card status change interrupts are fully functional.
Card functional interrupts are fully functional.
Controller context (for example, memory, I/O windows) is fully
functional.
Controller interface is fully functional (processor can access
cards).
Power to cards (slots) is available (may be on or off under
software control).
The controller is at its highest power consumption level.
Bus command response time is at its fastest level.
PC Cards can be in any Dx
power state (D0-D3).
Note: In D0 state,
CSTSCHG interrupts can be passed to a system from a powered down PC Card (for
more detail, refer to section 5.2.11.2 of PC Card Standard, Electrical
Specification).
|
D1
|
Optional
|
Card status change interrupts are disabled. CSTSCHG interrupt
events are still detectable by the controller and cause the bus-specific wake
signal to be asserted if wake is enabled on the controller.
Card functional interrupts are disabled.
Controller context is preserved (all register contents must be
maintained but memory and I/O windows need not be functional).
Controller interface is non-functional (processor cannot
access cards).
Power to cards (slots) is available (may be on or off; retains
power setting it had at time of entry to D1).
Power-level consumption for the controller is high but less
than D0.
The time required to restore the function from the D1 state to
the D0 state is quicker than resumption from D3.
Bus command response time is equal to or slower than in D0.
PC Cards can be in the D1, D2, or D3 power states (not D0).
Note: In D1 state,
CSTSCHG interrupts can be passed to a system from a powered-down PC Card (for
more detail, refer to section 5.2.11.2 of PC Card Standard, Electrical
Specification).
|
D2
|
Optional
|
Functionally the same as D1 (may be implemented instead of D1
in order to allow bus and/or system to enter a lower-power state).
|
D3
|
Required
|
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.
|
A.10.2 Power Management Policy
The PC Card controller is a bus controller. As such, its
power state is dependent on the devices plugged into the bus (child devices).
OSPM will track the state of all devices on the bus and will put the bus into
the best possible power state based on the current device requirements on that
bus. For example, if the PC Card cards are all in the D1 state, OSPM will put
the PC Card controller in the D1 state.
Present State
|
Next State
|
Cause
|
D2/D3
|
D0
|
Any card in any slot needing to transition to state D0 due to
a wake event or because of system usage.
|
D0
|
D1
|
No card in any slot is in state D0.
|
D0
|
D2
|
No card in any slot is in state D0 or D1.
|
D0
|
D3
|
All cards in all slots are in state D3.
|
A.10.3 Wake Events
A wake event is any event that would normally assert the
controller's status change interrupt (for example, card insertion, card battery
state change, card ReqAttn event, and so on) or ring-indicate signal.
A.10.4 Minimum Power Capabilities
A PC Card controller device conforming to this
specification must support the D0 and D3 states. Support for the D1 or D2
states is optional.
A.11 Storage Device Class
The requirements expressed in this section apply to ATA
hard disks, floppy disks, ATAPI and SCSI CD-ROMs, and the IDE channel.
A.11.1 Power State Definitions
A.11.1.1 Hard
Disk, CD-ROM and IDE/ATAPI Removable Storage Devices
State
|
Status
|
Definition
|
D0
|
Required
|
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
|
N/A
|
This state is not defined for storage devices.
|
D3
|
Required
|
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.
|
A.11.1.2 Floppy
Disk Devices
State
|
Status
|
Definition
|
D0
|
Required
|
Drive controller (for example, interface and control
electronics) is functional.
Drive motor (for example, spindle) is turning.
|
D1
|
N/A
|
This state is not defined for floppy disk drives.
|
D2
|
N/A
|
This state is not defined for floppy disk drives.
|
D3
|
Required
|
Drive controller (for example, interface and control
electronics) is not functional; context is lost.
Drive motor (for example, spindle) is stopped.
|
A.11.1.3 IDE
Channel Devices
State
|
Status
|
Definition
|
D0
|
Required
|
Adapter is functional.
Adapter interface mode (for example, communications timings)
is programmed.
Power is applied to the bus (and all devices connected to it).
|
D1
|
N/A
|
This state is not defined for the IDE Channel.
|
D2
|
N/A
|
This state is not defined for the IDE Channel.
|
D3
|
Required
|
Adapter is non-functional.
Adapter interface mode (for example, communications timings)
is not preserved.
Power to the bus (and all devices connected to it) may be off.
|
A.11.2 Power
Management Policy
A.11.2.1 Hard
Disk, Floppy Disk, CD-ROM and IDE/ATAPI Removable Storage Devices
Present State
|
Next State
|
Cause
|
D3
|
D0
|
Device usage (high-priority I/O).
|
D0
|
D1*
|
Device inactivity (no high-priority I/O) for some period of
time (T1).
|
D0
|
D3
|
Device inactivity (no high-priority I/O) for a period of time
(T2=>T1).
System enters sleeping state.
|
D1*
|
D0
|
Device usage (High-priority I/O).
|
* If supported. 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.
A.11.2.2 IDE
Channel Devices
Present State
|
Next State
|
Cause
|
D3
|
D0
|
Any device on the channel needing to transition to a state
other than state D3.
|
D0
|
D3
|
All devices on the channel in state D3.
|
A.11.3 Wake Events
Storage devices with removable media can, optionally,
signal wake upon insertion of media using their bus-specific notification
mechanism. There are no other wake events defined for Storage devices.
A.11.4 Minimum Power Capabilities
A hard disk, CD-ROM or IDE/ATAPI removable storage device
conforming to this specification must support the D0 and D3 states. Support for
the D1 state is optional.
A floppy disk and IDE channel device conforming to this
specification must support the D0 and D3 states.
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
|
Description
|
|
_DOS
|
Enable/Disable output
switching
|
Required if system
supports display switching or LCD brightness levels
|
_DOD
|
Enumerate all devices
attached to display adapter
|
Required if integrated
controller supports output switching
|
_ROM
|
Get ROM Data
|
Required if ROM image is
stored in proprietary format
|
_GPD
|
Get POST Device
|
Required if _VPO is
implemented
|
_SPD
|
Set POST Device
|
Required if _VPO is
implemented
|
_VPO
|
Video POST Options
|
Required if system
supports changing post VGA device
|
_ADR
|
Return the unique ID for
this device
|
Required
|
_BCL
|
Query list of brightness
control levels supported
|
Required if embedded LCD
supports brightness control
|
_BCM
|
Set the brightness level
|
Required if _BCL is
implemented
|
_DDC
|
Return the EDID for this
device
|
Required if embedded LCD
does not support return of EDID via standard interface
|
_DCS
|
Return status of output
device
|
Required if the system
supports display switching (via hotkey)
|
_DGS
|
Query graphics state
|
Required if the system
supports display switching (via hotkey
|
_DSS
|
Device state set
|
Required if the system
supports display switching (via hotkey).
|
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.
B.3 ACPI Namespace
This is an example of
the display-related namespace on an ACPI system:
GPE //
ACPI General-purpose HW event
_L0x //
Notify(VGA, 0x80) to tell OSPM of the event, when user presses
// the hot key to switch the
output status of the monitor.
// Notify(VGA, 0x81) to tell
the event to OSPM, when there are any
// changes on the sub-devices
for the VGA controller
SB
|- PCI
|- VGA //
Define the VGA controller in the namespace
|-_PS0 / PR0
|-_PS1 / PR1
|-_PS3
|-_DOS // Method to
control display output switching
|-_DOD // Method to
retrieve information about child output devices
|-_ROM // Method to
retrieve the ROM image for this device
|-_GPD // Method for
determining which VGA device will post
|-_SPD // Method for
controlling which VGA device will post
|-_VPO // Method for
determining the post options
|-CRT // Child device CRT
|-_ADR // Hardware ID for this device
|-_DDC // Get EDID information from the
monitor device
|-_DCS // Get current hardware status
|-_DGS // Query desired hardware active \
inactive state
|-_DSS // Set hardware active \ inactive
state
|-_PS0 \
|-_PS1 - Power methods
|-_PS2 - for the output device
|-_PS3 /
|-LCD // Child device LCD
|-_ADR // Hardware ID for this device
|-_DDC // Get EDID information from the
monitor device
|-_DCS // Get current hardware status
|-_DGS // Query desired hardware active \
inactive state
|-_DSS // Set hardware active \ inactive
state
|-_BCL // Brightness control levels
|-_BCM // Brightness control method
|-_BQC // Brightness Query Current Level
|-_PS0 \
|-_PS1 - Power methods
|-_PS2 - for the output device
|-_PS3 /
|-TV // Child Device TV
|-_ADR // Hardware ID for this device
|-_DDC // Get EDID information from the
monitor device
|-_DCS // Get current hardware status
|-_DGS // Query desired hardware active \
inactive state
|-_DSS // Set hardware active \ inactive
state
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 don't have a built-in output device.
B.4 Display-specific Methods
The methods described
in this section are all associated with specific display devices. This
device-specific association is represented in the namespace example in the
previous section by the positioning of these methods in a device tree.
B.4.1 _DOS (Enable/Disable
Output Switching)
Many ACPI machines
currently reprogram the active display output automatically when the user
presses the display toggle switch on the keyboard. This is done because most
video device drivers are currently not capable of being notified synchronously
of such state changes. However, this behavior violates the ACPI specification,
because the system modifies some graphics device registers.
The existence of the
_DOS method indicates that the system BIOS is capable of automatically
switching the active display output or controlling the brightness of the LCD.
If it exists at all, the _DOS method must be present for all display output
devices. This method is required if the system supports display switching or
LCD brightness control.
Arguments:
Bit 1:0
0: The system BIOS should not
automatically switch (toggle) the active display output, but instead just save
the desired state change for the display output devices in variables associated
with each display output, and generate the display switch event. OSPM can query
these state changes by calling the _DGS method.
1: The system BIOS should
automatically switch (toggle) the active display output, with no interaction
required on the OS part. The display switch event should not be generated in
this case.
2: The
_DGS values should be locked. It's highly recommended that the system BIOS do
nothing when hotkey pressed. No switch, no notification.
3: The
system BIOS should not automatically switch (toggle) the active display output,
but instead generate the display switch event notify codes 0x82, 0x83, or 0x84.
OSPM will determine what display output state should be set, and change the
display output state without further involvement from the system BIOS.
Bit
2
0: The
system BIOS should automatically control the brightness level of the LCD when
the power changes from AC to DC.
1: The
system BIOS should not automatically control the brightness level of the LCD
when the power changes from AC to DC.
Return Value:
None
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.
B.4.2 _DOD
(Enumerate All Devices Attached to the
Display Adapter)
This
method is used to enumerate devices attached to the display adapter. This method is required if integrated
controller supports output switching.
On many laptops today,
a number of devices can be connected to the graphics adapter in the machine.
These devices are on the motherboard and generally are not directly enumerable
by the video driver; for this reason, all motherboard VGA attached devices are
listed in the ACPI namespace.
These devices fall into
two categories:
·
>Video output devices. For example, a machine with a single display
device on the motherboard can have three possible output devices attached to
it, such as a TV, a CRT, or a panel.
·
>Non-video output devices. For example, TV Tuner, DVD decoder, Video Capture. They just attach to
VGA and their power management closely relates to VGA.
Both ACPI and the video
driver have the ability to program and configure output devices. This means
that both ACPI and the video driver must enumerate the devices using the same
IDs. To solve this problem, the _DOD method returns a list of devices attached
to the graphics adapter, along with device-specific configuration information.
This information will allow the cooperation between ACPI components and the
video driver.
Every child device
enumerated in the ACPI namespace under the graphics adapter must be specified
in this list of devices. Each display device must have its own ID, which is
unique with respect to any other attachable devices enumerated.
Arguments:
None
Return Value:
A buffer containing an array of video device
attributes as described in the table below.
Sample Code:
Method (_DOD, 0) {
Return (
Package()
{
0x00000110,
// Primary LCD panel, not detectable by BIOS
0x80000100,
// CRT type display, not detectable by BIOS
0x80000220,
// TV type display, not detectable by the BIOS
0x80000411,
// Secondary LCD panel, not detectable by BIOS
}
)
}
Table B-2: Video Output Device
Attributes
Bits
|
Definition
|
15:0
|
Device ID. The device
ID must match the ID's specified by Video Chip Vendors. They must also be
unique under VGA namespace.
|
Bit 3:0
Display Index
A zero-based instance of the Display, when multiple displays
of the same type are attached, regardless of where it is associated. Starting
from the first adapter and its first display of the type on the first
integrated internal device and then incrementing per device-function
according to its relative port number.
Bit 7:4
Display Port Attachment
This field differentiates displays of the same type attached
at different points of one adapter. The zero-based number scheme is specific
to each Video Chip Vendors' implementation.
Bit 11:8
Display Type
Describes the specific type of Display Technology in use.
0 – Other
1 – VGA* CRT or VESA* Compatible Analog Monitor
2 – TV/HDTV or other Analog-Video Monitor
3 – External Digital Monitor (See Note 1.)
4 – Internal/Integrated Digital Flat Panel (See Note 2.)
5~15 – Reserved for future use
Bit 15:12
Chipset Vendor Specific.
16
|
BIOS can detect the device.
|
17
|
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 … etc.
|
20:18
|
For VGA multiple-head devices, this specifies head or pipe ID
e.g. for Dual-Pipe*, Dual-Display*, Duo-View*, TwinView*, Triple-View* … etc,
beginning with 0 for head 0 or single-head device and increasing for each
additional head.
|
30:21
|
Reserved (must be 0)
|
31
|
Device ID Scheme
1 – Uses the bit-field definitions above (bits 15:0)
0 – Other scheme, contact the Video Chip Vendor
| | | | |
As mentioned in the above
Table, a "Pipe" or "Head" refers to a unique display content stream e.g. at a
particular color-depth, resolution, and refresh-rate. The "Port" refers to the
display output device attachment and may include a DAC, encoder or other
mechanism required to support a given display end-point. The "Display Type"
describes the generalized class of display output technology, and the means of
integration. The "Display Index" is then an index that assists in creating a
unique identifier display end-points in scenarios where other attributes are the
same.
Figure B-1 Example Display Architecture
Table B-3: Example Device Ids
Bits
Definition
0x000xyyyy
|
Bit 31 = 0. Other proprietary scheme - 0x110 Device ID is an
exception. (See Note 3)
|
0x00000110
|
Integrated LCD Panel #1 using a common, backwards compatible
ID
|
0x80000100
|
Integrated VGA CRT or VESA compatible Monitor #1 on Port0
|
0x80000240
|
Integrated TV #1 on Port4
|
0x80000410
|
Integrated Internal LCD Panel #1 on Port1
|
0x80000421
|
LVDS Panel #2 Dual-Link using Port2 & 3. (See Note 4)
|
0x80000131
|
VGA CRT or VESA compatible Monitor #2 on Port3
|
0x80000121
|
Dual-Link VGA CRT or VESA compatible Monitor #2 using Port2
& 3. (See Note 4.)
|
0x80000320
|
DVI Monitor #1 on Port2 (shares Port2 with a Dual-Function
DVI/TV Encoder). (See Note 5)
|
0x80000331
|
DVI Monitor #2 on Port3
|
0x80000330
|
Dual-Link DVI Monitor #1 using Port2 & 3
|
0x80000231
|
TV #2 on Port2 (shares Port2 with a Dual-Function DVI/TV
Encoder). (See Note 5)
| |
Notes:
- An "External
Digital Monitor" is an external display device attachable via a
user-accessible connector standard (e.g. DFP* or DVI* Compatible
Monitors).
- An "Internal
Flat Panel" is a non-detachable fixed pixel display device, including a
backlight, and is internally associated, without user-accessible
connectors, to the Video Chip (e.g. TFT LCD via TMDS*, LVDS* interface).
- When Bit 31 is
0, no assumptions can be made on which ID will be used for any particular
display type. Contact the Video Chip vendor for details of the ID scheme
employed.
- In certain
cases multiple Displays Ports may be combined to increase bandwidth for a
particular Display in higher-resolution modes. In this situation, the
Display Type and Port Number should remain the same in order to retain a
consistent ID for the same device, regardless of the selected display
mode.
- In certain
cases, more than one type of display (and connector) may be supportable on
a single Port (e.g. DVI + TV + CRT on a single Display Encoder device),
while only one display is selectable at any time. In this case the Port
Number field of the ID may be the same as other Display ID's however the other
fields (e.g. Display Type) provide uniqueness.
B.4.3 _ROM (Get ROM Data)
This method is used to
get a copy of the display devices' ROM data. This method is required when the ROM image is stored in a proprietary
format such as stored in the system BIOS ROM. This method is not necessary if
the ROM image can be read through standard PCI interface (using ROM BAR).
The video driver can
use the data returned by this method to program the device. The format of the
data returned by this function is a large linear buffer limited to 4 KB
content of the buffer is defined by the graphics independent hardware vendor
(IHV) that builds this device. The format of this ROM data will traditionally
be compatible with the ROM format of the normal PCI video card, which will
allow the video driver to program its device, independently of motherboard
versus add-in card issues.
The data returned by the _ROM method is implementation-specific
data that the video driver needs to program the device. This method is defined
to provide this data as motherboard devices typically don't have a dedicated
option ROM. This method will allow a video driver to get the key implementation
specific data it needs so that it can fully control and program the device
without BIOS support.
Arguments:
Arg0:Offset of the display device ROM data.
Arg1:Size of the buffer to fill in (up to 4K).
Output:
Buffer
of bytes
B.4.4 _GPD (Get POST Device)
This method is required if the _VPO method is implemented.
This method is used as a mechanism for the OS to query a
CMOS value that determines which VGA device will be posted at boot. A zero
return value indicates the motherboard VGA will be posted on the next boot, a 1
indicates a PCI VGA device will be posted, and a 2 indicates an AGP VGA device
will be posted.
Arguments:
None
Return Value:
A
32-bit value
Bit 1:0
00 –Post the motherboard VGA device
01 –Post an add-in PCI VGA device
10 –Post an add-in AGP VGA device
11 – Post
an add-in PCI-Express VGA device
Bit 31:2
Reserved (must be 0)
B.4.5 _SPD (Set POST Device)
This method is required if the _VPO method is implemented.
This method is used as a mechanism for the OS to update a
CMOS value that determines which video device will be posted at boot. A zero
argument will cause the "motherboard" to be posted on the next boot, a 1 will
cause an add-in PCI device to be posted, and a 2 will cause an add-in AGP
device to be posted.
Arguments:
Bit 1:0
00 – Post the motherboard VGA device
01 – Post an add-in PCI VGA device
10 – Post an add-in AGP VGA device
11 – Post an add-in PCI-Express VGA device
Bit 31:2
Reserved (must be 0)
Return Value:
A
32-bit value
0
– Success
non-zero
– Failure
Sample Code:
Method (_SPD, 1) { // Make the
motherboard device the device to post }
B.4.6 _VPO (Video POST Options)
This method is required for systems with video devices
built onto the motherboard and support changing post-VGA device.
This method is used as
a mechanism for the OS to determine what options are implemented. This method
will be used in conjunction with _GPD and _SPD.
Arguments:
None
Return Value:
A
32-bit integer
Bit 0: Posting the motherboard VGA device is an
option. (Bit 0 should always be set)
Bit 1: Posting a PCI VGA device is an option.
Bit 2: Posting an AGP VGA device is an option.
Bit 3: Posting a PCI-Express VGA device is an
option.
Bits 31:4: Reserved (must be zero)
B.5
Notifications for Display Devices
Display devices may need to know about external,
asynchronous events. In order to accommodate that, the following notifications
are defined.
The event number is
standardized because the event will be handled by the OS directly under certain
circumstances (see _DOS method in this specification).
These notifications are
valid for Display Devices.
Value
|
Description
|
0x80
|
Cycle Output Device.
Used to notify OSPM 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.
|
0x81
|
Output Device Status Change. Used to notify OSPM 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
|
0x82
|
Cycle Display Output Hotkey Pressed. Used to notify OSPM whenever the user has
pressed the Cycle display hotkey.
|
0x83
|
Next Display Output Hotkey Pressed. Used to notify OSPM whenever the user has pressed
the Next display hotkey.
|
0x84
|
Previous Display Output Hotkey Pressed. Used to notify OSPM whenever the user has pressed
the Previous display hotkey.
|
B.6 Output Device-specific Methods
The methods in this
section are methods associated with the display output device.
B.6.1 _ADR (Return the Unique ID for this Device)
This method returns a
unique ID representing the display output device. All output devices must have
a unique hardware ID. This method is required for all The IDs returned by this
method will appear in the list of hardware IDs returned by the _DOD method.
Arguments:
None
Return Value:
32-bit
device ID
Sample Code:
Method
(_ADR, 0) {
return(0x0100)
// device ID for this CRT
}
This method is required
for all output display devices.
B.6.2 _BCL (Query List of Brightness Control Levels Supported)
This method allows the
OS to query a list of brightness level supported by built-in display output
devices. (This method in not allowed for externally connected displays.) This
method is required if an integrated LCD is present and supports brightness
levels.
Each brightness level is
represented by a number between 0 and 100, and can be thought of as a
percentage. For example, 50 can be 50% power consumption or 50% brightness, as
defined by the OEM.
The OEM may define the
number 0 as "Zero brightness" that can mean to turn off the lighting
(e.g. LCD panel backlight) in the device. This may be useful in the case of an
output device that can still be viewed using only ambient light, for example, a
transflective LCD. If Notify(Output Device, 0x85) for "Zero brightness" is
issued, OSPM may be able to turn off the lighting by calling _BCM(0).
Arguments:
None
Return Value:
Package
of bytes
Sample Code:
Method
(_BCL, 0) {
//
List of supported brightness levels
Return
(Package(7){
80, //
level when machine has full power
50,
// level when machine is on batteries
//
other supported levels
20,
40, 60, 80, 100}
}
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.
B.6.3 _BCM (Set the Brightness Level)
This method allows OSPM
to set the brightness level of a built-in display output device.
The OS will only set
levels that were reported via the _BCL method. This method is required if _BCL
is implemented.
Arguments:
Arg0:Desired brightness level
Return Value:
None
Sample Code:
Method
(_BCM, 1) { // Set the requested level }
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.
B.6.4
_BQC (Brightness Query Current level)
This method returns the current brightness level of a
built-in display output device.
Arguments:
None
Return Value:
An
Integer – must be one of the values listed in the _BCL.
B.6.5 _DDC (Return the EDID for this Device)
This method returns an
EDID (Extended Display Identification Data) structure that represents the
display output device. This method is required for integrated LCDs that do not
have another standard mechanism for returning EDID data.
Arguments:
Arg0:Requested data length in bytes
0x01
– 128 bytes
0x02
– 256 bytes
Return Value:
0
– Failure, invalid parameter
non-zero
– Requested data, 128 or 256 bytes of data
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.
B.6.6 _DCS (Return the Status of Output Device)
This method is required
if hotkey display switching is supported.
Arguments:
None
Return Value:
32-bit
device status
Table B-4 Device Status
Bits
|
Definition
|
0
|
Output connector exists in the system now
|
1
|
Output is activated
|
2
|
Output is ready to switch
|
3
|
Output is not defective
(it is functioning properly)
|
4
|
Device is attached (this is optional)
|
5-31
|
Reserved (must be zero)
|
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.
B.6.7 _DGS (Query Graphics State)
This method is used to
query the state (active or inactive) of the output device. This method is
required if hotkey display switching is supported.
Arguments:
None
Return Value:
A
32-bit device state
Table B-5 Device State
Bits
|
Definition
|
0
|
0 – next desired
state is inactive
1 – means next
desired state is active
|
1-31
|
Reserved (must be zero)
|
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).
B.6.8 _DSS – Device Set State
OSPM will call this
method when it determines the outputs can be activated or deactivated. OSPM
will manage this to avoid flickering as much as possible. This method is
required if hotkey display switching is supported.
Arguments:
A
32-bit device state
Return Value:
None
Table B-6 Device Status
Bits
|
Definition
|
0
|
0 – Set output
device to inactive state
1 – Set output
device to active state
|
30
|
0 – Do whatever
Bit31 requires to do
1 – Don't do actual
switching, but need to change _DGS to next state
|
31
|
0 – Don't do actual switching, just cache the change
1 – If Bit30 = 0, commit actual switching, including any _DSS with MSB=0
called before
If Bit30 = 1, don't
do actual switching, change _DGS to next state
|
1-29
|
Reserved (must be zero)
|
Example Usage:
OS may call
in such an order to turn off CRT, and turn on LCD
CRT._DSS(0);
LCD._DSS(80000001L);
or
LCD._DSS(1);
CRT._DSS(80000000L);
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);
B.7 Notifications Specific to Output Devices
Output devices may need to know about external,
asynchronous events. In order, each of these events corresponds to accommodate
that, pressing a key or button on the following machine. Using these
notifications is not appropriate if no physical device exists that is
associated with them. OSPM may ignore any of these notifications if, for
example the current user does not have permission to change the state of the
output device.
These notifications are only valid for Output Devices.
Value
|
Description
|
0x85
|
Cycle Brightness.
Used to notify OSPM that the output device brightness should be increased by
one level. Used to notify OSPM that the user pressed a button or key that is
associated with cycling brightness. A useful response by OSPM would be to
increase output device brightness by one or more levels. (Levels are defined
in _BCL.) If the brightness level is currently at the maximum value, it
should be set to the minimum level.
|
0x86
|
Increase Brightness. Used
to notify OSPM that the output device brightness should be increased by one
or more levels as defined by the _BCL object. Used to notify OSPM that the
user pressed a button or key that is associated with increasing brightness.
If the brightness level is currently at the maximum value, OSPM may should
ignore the notification.
|
0x87
|
Decrease Brightness. Used
to notify OSPM that the output device brightness should be decreased by one
or more levels as defined by the _BCL object. Used to notify OSPM that the
user pressed a button or key that is associated with decreasing device
brightness. If the brightness level is currently at the minimum value, OSPM
may should ignore the notification.
|
0x88
|
Zero Brightness. Used
to notify OSPM that the output device brightness should be zeroed,
effectively turning off any lighting that is associated with the device. Used
to notify OSPM that the user pressed a button or key associated with zeroing
device brightness. This is not to be confused with putting the device in a
D3 state. While the brightness may be decreased to zero, the device may
still be displaying, using only ambient light.
|
0x89
|
Display Device Off.
Used to notify OSPM that the device should be put in an off state, one that
is not active or visible to the user, usually D3, but possibly D1 or D2. Used
to notify OSPM that the user pressed a low power button or key associated
with putting the device in an off state. There is no need for a corresponding
"device on" notification, for two reasons. First, OSPM may choose to toggle
device state when this event is pressed multiple times. Second, OSPM may
(and probably will) choose to turn the monitor on whenever the user types on
the keyboard, moves the mouse, or otherwise indicates that he or she is
attempting to interact with the machine.
|
B.8 Notes on State Changes
It is possible to have
any number of simultaneous active output devices. It is possible to have 0, 1,
2 ... and so on active output devices. For example, it is possible for both the
LCD device and the CRT device to be active simultaneously. It is also possible
for all display outputs devices to be inactive (this could happen in a system
where multiple graphics cards are present).
The state of the output
device is separate from the power state of the device. The "active" state
represents whether the image being generated by the graphics adapter would be
sent to this particular output device. A device can be powered off or in a
low-power mode but still be the active output device. A device can also be in
an off state but still be powered on.
Example of the
display-switching mechanism:
The laptop has three
output devices on the VGA adapter. At this moment in time, the panel and the TV
are both active, while the CRT is inactive. The automatic display-switching
capability has been disabled by OSPM by calling _DOS(0), represented by global
variable display_switching = 0.
The system BIOS, in
order to track the state of these devices, will have three global variable to
track the state of these devices. There are currently initialized to:
crt_active
– 0
panel_active
– 1
tv_active
– 1
The user now presses
the display toggle switch, which would switch the TV output to the CRT.
The system BIOS first
updates three temporary variables representing the desired state of output
devices:
want_crt_active
– 1
want_panel_active
– 1
want_tv_active
– 0
Then the system BIOS
checks the display_switching variable. Because this variable is set to zero,
the system BIOS does not do any device reprogramming, but instead generates a Notify(VGA, 0x80/0x81) event for the display. This
event will be sent to OSPM.
OSPM will call the _DGS
method for each enumerated output device to determine which devices should now
be active. OSPM will determine whether this is possible, and will reconfigure
the internal data structure of the OS to represent this state change. The graphics
modes will be recomputed and reset.
Finally, OSPM will call
the _DSS method for each output device it has reconfigured.
Note: OSPM may not have called the _DSS routines with
the same values and the _DGS routines returned, because the user may be overriding
the default behavior of the hardware-switching driver or operating
system-provided UI. The data returned by the _DGS method (the want_XXX values)
are only a hint to the OS as to what should happen with the output devices.
If the
display-switching variable is set to 1, then the BIOS would not send the event,
but instead would automatically reprogram the devices to switch outputs
legacy display notification mechanism could also be performed at this time.
Index
_EJx
AC adapter
device ID
power source objects
AC status notification
access types, Operation Region
access, device..
AccessAs term
acoustics noise
ACPI
definition
device ID
goals
ACPI HardwareSee hardware
ACPI Machine LanguageSee AML
ACPI mode
entering
exiting
ACPI Namespace
AML encoding
control method access
definition
display adapters
embedded controller device definition
generic hardware registers
Modifier Objects encoding, AML
naming conventions
Processor statements
root namespaces
SMBus host controller objects
ACPI Source LanguageSee ASL
ACPI System
Description tables........ See tables
ACPI-compatible
hardware............ See hardware
Acquire (Acquire a
Mutex)
Acquire terms.
active cooling
_ACx object
control methods
definition
engaging
preferences
threshold values
active line printer (LPT) ports
Active List (_ALx) object
Add (Integer Add)
add-in display adapter, definition
Address (_ADR) object
Address Range types
address register (SMB_ADDR)
Address Space Descriptors
DWORD resource descriptor format
Extended
QWORD resource descriptor format
resource specific flags
WORD resource descriptor format
Address Space Resource Descriptors
valid combinations
addresses
alarm fields..
BARs (Base Address Registers)
blocking, BIOS
bus types
control methods
decoding
FACS
format
functional fixed hardware
Generic Address Structure (GAS)
generic hardware
I/O (S)APIC
map interfaces
map samples
mixed, preventing
registers
reset register.
slave
SMBus
system description tables
Advanced Configuration and Power Interface See ACPI
Advanced Programmable Interrupt Controller See APIC
alarm address register (SMB_ALRM_ADDR)
alarm data register (SMB_ALRM_DATA)
alarm events
Alias (Declare Name Alias)
allocation, device resources
Ambient Light Sensor devices
AML
Arg Objects encoding
battery events
byte values.
code event handler
compiling
Control Method Battery
data buffers, SMBus
Data Objects encoding
Debug Objects encoding
definition
grammar
Local Objects encoding
Name Objects encoding
Named Objects encoding
Namespace encoding
Namespace Modifier Objects encoding
notation conventions
Package Length encoding
purpose of
sleep button code example
SMBus device access protocols
specification
Term Objects encoding
Type 1 Opcodes encoding
Type 2 Opcodes encoding
And (Integer Bitwise And)
angle brackets
AML
ASL notation
answering phones
modem example
waking computer
APIC
_MAT (Multiple APIC Table Entry)
definition
I/O
local
multiple description table (MADT)
NMI
Processor Local
structure types
support
APM BIOS
appliance PCs.
ARB_DIS
architecture, system description tables
Arg Objects encoding, AML
arguments, control methods
Argx (Method Argument Data Objects)
arrow symbol
ASL notation
ASL
_FIX usage example
_HPP example
AML, relation to
case sensitivity
CMOS protocols
comments
converting to AML
data and constant
terms
data types
definition
Definition Block
terms
EC-SMB-HC device code
embedded controller
device code
grammar
grammar notation
index with buffers
example code
lid status code
example
macros
modifiers
multiple Smart
Battery subsystem code
name and pathname
terms
nested packages
sample code
object names
objects, declaring
opcode terms
opcodes
operator reference
operator summary
operator summary by
type
parameter keyword
terms
parameters..
power button code
example
Power Resource
statements
primary terms
reserved object names
resource template
terms
root and secondary
terms
SMBBlock code
SMBBlockProcessCall
code
SMBByte code
SMBProcessCall code
SMBQuick code
SMBSendReceive code
SMBus data buffer
code
SMBus devices
SMBWord code
storing results
strings
thermal zone examples
virtual register code
AT interrupt model
ATA hard disksSee storage devices
audible output
noise
audio devices, power
management
aware device drivers
Back From Sleep
(_BFS)
BankField (Declare
Bank/Data Field)
bar symbol
AML notation
ASL notation
BARs (Base Address
Registers)
Base Bus Number
(_BBN) object
batteriesSee
also Smart Batteries
capacity
Control Method
Batteries
emergency shutdown
events
low-level warnings
management.
multiple
power status
information
remaining capacity
types supported
Battery Information
(_BIF) object
Battery Status (_BST)
object
Battery Trip Point
(_BTP) object
bay devices
BIOS
address range types
configuring boot
devices
determining ACPI
support
Device Objects
devices, switching
Dock Name (_BDN)
initialization
legacy functions
legacy specifications
limitations on power
management
memory initialization
relation to ACPI
resetting enable bits
S4 Sleeping state
transition
bits
alarm
child
child status
control
diagram legend
enable
general-purpose
events
generic hardware
registers
ignored
interrupt status
lid status
parent
77
PM timer
PM1 Control registers
PM1 Enable registers
PM1 Status registers
PM2 Control register
processor control
register
processor LVL2
processor LVL3
register notation
reserved
52, 86
reset register.
SMBus protocol
encoding
status
blocks, register.
BM_RLD
BM_STS
bold
AML notation
ASL notation
boot architecture
flags, IA-PC
boot devices
boot resources,
embedded controller
bootstrap ROM
boot-up
boot-up display
adapter, definition
brackets, angle
AML notation
ASL notation
Break (Break from
While)
BreakPoint (Execution
Break Point)
bridges
Base Bus Number
(_BBN)
DWORD
flags
ISA bus device
power states..
purpose
QWORD
WORD
Brightness Control
Levels Supported, Query List of (_BCL)
brightness control,
LCDs
Brightness Level, Set
(_BCM)
Buffer (Declare
Buffer Object)
Buffer field data
type, ASL
buffers, SMBus
built-in display
adapter, definition
Burst Disable
Embedded Controller (BD_EC) 359
Burst Enable Embedded
Controller (BE_EC) 359
Burst flags
burst mode
Bus/Device packages
buses
power management
standards
segment locations
setting power states
button control models
buttonsSee power button; sleep button
byte values, AML
C0 processor power
state
definition
implementation
C1 processor power
state
definition
implementation
C2 processor power
state
definition
implementation
C3 processor power
state
definition
implementation
cache controller
configuration
caches, flushing
capacity, battery
calculating
low-level warnings
remaining
status information
CardBus mode
Case (Conditional
Execution)
case sensitivity, ASL
category names
Celsius scale
centenary value, RTC
alarm
Central Processing UnitSee CPU
CENTURY
channels, DMA
chemistry
independence
child bits
child objects, ASL
statements
child status bits
CLK_VAL
clock logic
CMOS protocols
cold boots.
cold insertion and
removal
COM port devices, power management
command protocols,
SMBus
command register
(SMB_CMD)
commands, embedded
controller interface
comments, ASL
compatibility memory
compatibility,
compiler
Compatible ID (_CID)
object
compiling, ASL to AML
composite battery
Concatenate
(Concatenate Data)
ConcatenateResTemplate
(Concatenate Resource Templates) 456
CondRefOf
(Conditional Reference Of)
configuration
objects, device
configuring
BIOS initialization
boot devices.
modem example
Plug and Play devices
context, device..
context, system
definition
during emergency
shutdown
restoring
S4 sleeping state
sleep states lost in
contiguous RAM
Continue (Continue
Innermost Enclosing While) 457
control bits
functions
symbol
Control Method
Battery
control methods See
also objects, See also objects, See also
style='font-style:normal'> objects, See also objects
_ADR (Return the Unique ID for this Device)
_BCL (Query List of
Brightness Control Levels Supported)
_BCM (Set the
Brightness Level)
_BDN (BIOS Dock Name)
_BFS (Back From
Sleep)
_DCK (Dock)
_DCS (Return the
Status of Output Device) 576
_DDC (Return the EDID
for this Device)
_DDS (Device Set
State)
_DGS (Query Graphics
State)
_DOD (Enumerate All
Devices Attached to the Display Adapter)
_DOS (Enable/Disable
Output Switching)
_FDM
(Floppy Disk Drive Mode)
_GPD (Get POST
Device)
_GTF (Get Task File)
_GTM (Get Timing
Mode)
_GTS (Going To Sleep)
_LID (lid device)
_MSG (Message)
_OFF
_ON
_PS0 (Power State 0)
_PS1 (Power State 1)
_PS2 (Power State 2)
_PS3 (Power State 3)
_PSC (Power State
Current)
_PSW
_PTS (Prepare To
Sleep)
_REG (Region)
>_ROM
(Get Rom Data)
_SCP (Set Cooling
Policy)
_SPD (Set POST
Device)
_SST (System Status)
_STM (Set Timing
Mode)
_TMP (Temperature)
_VPO (Video POST
OPtions)
_WAK (System Wake)
arguments...
ASL, writing
battery
definition
device identification
device removal
generic objects
initialization (_INI)
lid device
OEM-supplied
overview
power button
Power Resource
objects
power source
resources
sleep button
Smart Battery
Subsystem
system indicators
thermal management
video extensions
control registers
controllers, embedded
definition
interface
conversion, data
types
cooling modes
326
cooling preferences
333
CopyObject (Copy an
Object)
core logic, system
events
CPU
boot configuration
boot-up
cache flushing
clock logic
definition
fixed hardware
control
multiple performance
state control
non-symmetric power
state support
passive cooling
performance states
power management
processor power
states
thermal management
throttling
265
waking operations
crashed systems
62
CreateBitField
(Create 1-Bit Buffer Field)
CreateByteField
(Create 8-Bit Buffer Field)
CreateDWordField
(Create 32-Bit Buffer Field) 458
CreateField (Create
Arbitrary Length Buffer Field) 458
CreateQWordField
(Create 64-Bit Buffer Field) 458
CreateWordField
(Create 16-Bit Buffer Field) 459
Critical battery
state
Critical Temperature (_CRT)
object
critical temperature
shutdowns
Cross Device
Dependency
CRT monitors, power
management
C-States (processor
power)
CT phonesSee modems
Current Resource
Settings (_CRS) objects
Cx statesSee processor power states
D0-Fully On
control method
definition
In Rush Current
(_IRC) object
power resource object
transitioning to
D1 Device State
control methods
definition
power resource
objects
transitioning to
D2 Device State
control methods
definition
power resource
objects
transitioning to
D3-Off
control methods
definition
transitioning to
dash character
AML notation
ASL notation
data buffers, SMBus
Data Objects
encoding, AML
data objects, ASL
Buffer
Package
data
register array (SMB_DATA)
data types
ASL
concatenate
data types, resource
resource data types
DataTableRegion
(Create Data Table Operation Region)
day alarm
day mode
DAY_ALRM...
DDB Handle data type,
ASL
DDT, Plug and Play
devices
Debug (Debugger
Output)
Debug Object data
type, ASL
Debug Objects
encoding, AML
Debug Port
Specification, Microsoft
debugging
requirements for
decimals, notation
Decrement (Integer
Decrement)
Default (Default
Execution Path in Switch)
defined generic
objects
Definition Blocks
ASL code
definition
encoding
loading
loading from XSDT
unloading
DefinitionBlock
(Declare Definition Block)
definitionsSee terminology
degrees, Kelvin
dependencies, device
DerefOf (Dereference
an Object Reference)
description tablesSee tables
design guides.
desktop PCs
power management
profile system type
Device (Declare Bus/Device
Package)
device and processor
performance states.... 23, 36
Device Class Power
Management specifications 30
Device data type, ASL....................... 437,
441
device drivers,
ACPI-Aware
Device Name (_DDN)
object
device power
management
541
modem example
objects
requirements
resources
specifications
standards
30
states
status
Device Set State
(_DSS)
devices
audio, power
management
class-specific
objects
COM port, power
management
configuration objects
context, definition
definition
graphics
identification
objects
input, power
management
insertion and removal
objects
interference...
modems, power
management
network, power
management
object notification
PC Card controllers,
power management
Plug and Play IDs
power states..
resource allocation
resource control
method
SMBus, declaring
storage, power
management
waking system
Devices Attached to
the Display Adapter (_DOD) 568
diagram legends
Differentiated
Definition Block
Bus/Device packages
definition
determining device
power capabilities
modem example
Differentiated
Description Block
isolation logic
Differentiated System
Description Table See DSDT
digital modems........................... See modems
Direct Memory Access
(_DMA) object
Disable (_DIS) object
Disable Output
Switching (_DOS)
display adapters
ACPI Namespace
control methods
definitions..
requirements for
switching devices
display devices,
power management..... 543, 546
Display Power
Management Signaling Specification (DPMS) 542
Divide (Integer
Divide)
DMA resource
descriptor format
DMA Resource
Descriptor Macro
Dock (_DCK) control
method
docking
control methods............................ 189,
227
event signals.
objects
query events.
documentation
organization........................................... 9
supplemental
drain rates, battery
drivers
interference...
restoration
DSDT
definition
110
location
purpose
dual 8259........................................ 114,
115
dual-button model
duty cycle
DVD decoders.
DWORD
DWORD resource
descriptor format
DWordIO (DWord IO
Resource Descriptor Macro) 463
DWordMemory (DWord
Memory Resource Descriptor Macro) 465
DWordSpace (DWord
Space Resource Descriptor Macro) 466
dynamic insertion and
removal
dynamic objects
dynamic Operation
Regions
dynamic transitioning
E_TMR_VAL..
E820 mapping
EC_DATA (embedded
controller data register) 358
EC_SC (R) (embedded
controller status register) 357
EC_SC (W) (embedded
controller command register) 358
ECDT
ECI............... See embedded controller interface
EC-SMB-HC................................... 362,
373
EDID control methods
(_DDC)
EFI
definition
GetMemoryMap
interface
RSDP location
EISA ID
EISAID (EISA ID
String To Integer Conversion Macro) 467
Eject (_EJx) object
Eject Device List
(_EDL) object
Ejection Dependent
Device (_EJD) object
ejection mechanisms
Else (Alternate
Execution)
ElseIf
(Alternate/Conditional Execution)
embedded controller
address space
boot resources table
burst mode.
definition
device ID
device object
event control example
multiple
operations
queuing events
region control method
embedded controller
interface
ACPI Namespace
objects
algorithms..
ASL code, device
bi-directional
communications
Burst flag...
command interrupt model
command register
(EC_SC (W))
command set
commands, restricted
configurations,
additional
data register
(EC_DATA)
definition
device access
firmware requirements
Input Buffer Full
(IBF) flag............ 357, 362
interrupt model
objects
OEM-definable values
Output Buffer Full
(OBF) flag........ 357, 362
registers
shared......................................... 354,
356
SMBus host controller
SMBus notification
header (OS_SMB_EVT) 360
SMBus protocol
descriptions
SMBus registers
SMI event flags
specifications
status register
(EC-SC (W))
emergency shutdown
enable bits
corresponding status
bits
resetting
symbol
enable register...
Enable/Disable Output
Switch (_DOS)
encoding
AML
Definition Blocks
object names, ASL
tables
End Dependent
Functions resource descriptor format 202
end tag resource
descriptor format
EndDependentFn End
Dependent Functions Descriptor Macro) 469
energy conservation........ See power management
Enterprise servers
Enumerate All Devices
Attached to the Display Adapter (_DOD) 568
enumeration, enabling
errors, fatal
Ethernet adapters................ See network devices
Event (Declare Event
Synchronization Object) 469
Event data type, ASL........................ 437,
441
events
alarm
AML code handler
battery
button
enable register
fixed feature..
fixed handling
general model
general-purpose
registers.................... 15, 77
hardware
interrupt.
68
link status..
OS-transparent
power button
power button override
programming model
query
shared
status register
synchronization
objects
synchronization,
waiting for
user-initiated.
wake frame.
exiting ACPI mode
extended I/O bus
Extended Interrupt
resource descriptor format 224
Extended IO Resource
Descriptor Macro
Extended Memory Resource
Descriptor Macro 471
Extended resource
descriptor format
Extended Root Systems
Description Table See XSDT
Extended Space
Resource Descriptor Macro
Extensible Firmware
Interface............... See EFI
External (Declare
External Objects)
FACS
definition
flags
Global Lock
table fields..
FADT
alarm bits
cache flushing.............................. 258,
402
definition
flags
location
optional feature bits
Plug and Play IDs
processor power
states
purpose
reset register
location
SCI interrupt mapping
table fields...
fans
active cooling
330
device operations
noise preferences
Plug and Play ID
thermal zone example
Fatal (Fatal Error
Check)
fatal errors
features
fixed
generic
generic hardware
Field (Declare Field
Objects)
fields
alarm
cache flushing
declaring objects
embedded controller
boot resources
FACS
FADT..
169
I/O APIC...
I/O SAPIC.
MADT
NMI
Processor Local APIC
processor performance.................... 271,
342
reserved
RSDT
SBST
SMBus
Start Dependent
Functions
XSDT
FindSetLeftBit (Find
First Set Left Bit)
FindSetRightBit (Find
First Set Right Bit)
firmware
ACPI System......................................... 5
embedded controller
requirements
OSPM controls
SMM functional fixed
hardware implementation 46
Firmware ACPI Control
Structure..... See FACS
Fixed ACPI
Description Table.......... See FADT
fixed event handling
fixed features
definition
events
registers
fixed hardware
definition
feature control bits
feature enable bits
feature status bits
features
functional
implementation
interfaces
power button
programming model
register blocks
registers..
69
sleep button..
fixed location I/O
port descriptor resource descriptor format 203
Fixed Register
Resource Provider (_FIX)
fixed width registers
FixedIO (Fixed IO
Resource Descriptor)
FixedList
flags
Burst
DWORD
FACS
FADT
I/O resource
IA-PC boot
architecture
Input Buffer Full
(IBF).................. 357, 362
interrupt vector
local APIC.
MADT
memory resource
MPS INTI..
Output Buffer Full
(OBF).............. 357, 362
QWORD..................................... 211,
218
SMI event (SMI_EVT)
system type
WORD
floppy controller
device objects
Floppy
Disk Drive Mode (_FDM) control method 290
Floppy Disk Enumerate
(_FDE) object
Floppy Disk
Information (_FDI) object
floppy disks....................... See storage devices
flushing caches................................. 258,
401
frequency mismatch
FromBCD (Convert BCD
To Integer)
Function (Declare
Control Method)
functional device
configuration
functional fixed hardware
functions
End Dependent
Start Dependent
G0 Working state
behavior during
definition
properties
transitioning to
transitioning to
Sleeping state
transitioning to
Soft-Off
G1 Sleeping state
definition
properties
transitioning to
G2 Soft Off
definition
properties
transitioning to
G3 Mechanical Off
definition
properties
transitioning from
transitioning to
game pads............................ See input devices
GAS.................. See Generic Address Structure
GBL_EN
GBL_RLS
GBL_STS
general event model
general-purpose event
registers
addresses
77
blocks
79
definition
event 0
event 0 enable
event 0 status
event 1
event 1 enable
event 1 status
grouping
wake events, role in
general-purpose events
handling
wake
generic address
space, SMBus
Generic Address
Structure (GAS)
generic events
example
252
top-level
generic feature,
definition
generic hardware
definition
features...
79
power button control
programming model
registers
55, 77
sleep button control
generic ISA bus
device
generic objects
generic register
resource descriptor format
Get POST Device
(_GPD)
Get Power Status
Get
ROM Data (_ROM)
Get Task File (_GTF)
control method
Get Timing Mode
(_GTM) control method
GetMemoryMap
Global Lock...
Global Lock (_GLK)
object
Global Lock Mutex
Global Lock Structure
global standby timer
global system
interrupts..................... 114, 120
global system states
definition
19
terminology..
transitioning
50, 570
goals
ACPI.................................................... 1
OSPM.................................................. 1
power management.................................. 2
Going To Sleep (_GTS)
control method
GPE
block devices............................... 146,
291
control method
grammar
AML
ASL
grammar notation
AML
ASL
graphics devices,
requirements for
Graphics State, Query
(_DGS)
Green PCs, power
management for
groupings, register........... See register groupings
guides, design
7
hardware See also fixed hardware; generic hardware
ACPI interfaces....................................... 4
ACPI specifications
definition
events
features
fixed
generic
ignored bits..
interfaces............................................... 5
legacy
legacy vs. ACPI...................................... 3
OEM implementation.............................. 3
OS-independent
47
OSPM model
register definitions
registers
reserved bits.
value-added..
hardware ID (_HID)
object.................. 161, 310
headers, long
headers, table
90
heat management......... See thermal management
hexadecimals,
notation
holes, compatibility
home PCs, power
management for
host controller
objects, SMBus
hot insertion and
removal................... 190, 193
Hot Plug Memory Table
Specification, Microsoft 92
Hot Plug Parameters
(_HPP) object 171, 173, 175
Hot Temperature
(_HOT) object
hung systems
62
hysteresis
I/O APIC
_MAT (Multiple APIC
Table Entry
definition
Global System
Interrupts
mixed addresses,
preventing............ 117, 227
structure
I/O operations, lazy..................................... 2
I/O port resource
descriptor format
I/O resource flag
I/O SAPIC
definition
mixed addresses,
preventing............ 117, 227
Platform Interrupt
Source structure
structure
I/O space
85
IA (Intel
Architecture) specifications
IA processors..
IA-32 systems..
IA-PC
boot architecture
flags
definition
interrupt models
memory map system
memory mapping
RSDP location
ID, Compatible (_CID
object)
IDE
controller device
drives
IDE devices........................ See storage devices
identification
objects, device
idle loops, CPU
idle timers, legacy
IDs, Plug and Play........................... 144,
159
If (Conditional
Execution)
ignored bits
definition
52
PM1 Status register
implementation
requirements
OEM.................................................... 3
OS....................................................... 9
OSPM.................................................. 8
In Rush Current
(_IRC) object
Include (Include
Additional ASL File)
Increment (Integer
Increment)
independence, OS
ACPI.................................................... 2
functional fixed
hardware
generic hardware
Independent Hardware
Vendors (IHVs)
power management
standards
Index (Indexed
Reference To Member Object) 480
Index with Buffers
Index with Packages
Index with Strings
IndexField (Declare
Index/Data Fields)
indicators, system
initialization
BIOS
boot-up
OS
initialization object
(_INI)
Input Buffer Full
(IBF) flag................ 357, 362
input devices, power
management........ 543, 555
Input/Output...................................... See I/O
insertion and removal
objects
insertion and
removal, batteries
INT 15 mapping
Integer data type,
ASL....................... 437, 441
Integers
Intel Architecture specifications
Intel
Architecture-Personal Computer. See
IA-PC
interdependent
resources
interfaces
ACPI.................................................... 4
battery
BIOS, legacy
Control Method
Battery
design guides......................................... 5
EC-SMB-HC
embedded controller
extensible firmware
(EFI)
fixed hardware
hardware................................................ 5
mapping
sharing protocols
SMBus.
375
interference, device
Interrupt (Extended
Interrupt Descriptor Macro) 483
interrupt events
logic
SCI
shareable
SMI
Interrupt Source
Overrides
interrupt sources,
non-maskable (NMIs)
interrupt status bits
interrupts
embedded controller
interface
Extended Interrupt
resource descriptor format 224
models................................. 111,
114, 120
Platform Interrupt
Source structure
PMIs
invocation, control
methods
IO (I/O Port Resource
Descriptor Macro)
IRQ (Interrupt
Resource Descriptor Macro
IRQNoFlags (Interrupt
Resource Descriptor Macro) 485
IRQs
mapping...................................... 114,
116
PCI routing
resource descriptor
format
ISA
bus device............................ 145,
155, 283
Device Objects code
interrupt sources
old cards
ISDN Terminal
Adapters............... See modems
isolation logic..
italics, ASL notation
joysticks.............................. See input devices
Kelvin scale
kernel....................................................... 4
key, logic diagrams
keyboard controllers
keyboards............................. See input devices
LAnd (Logical And)
large resource
resource descriptor format
latency
acceptable
570
global power states
processor power
states
lazy I/O operations...................................... 2
LCD panels
brightness control
power management
legacy BIOS
interfaces
legacy hardware
BIOS specification
boot flags...
converting to fixed
definition
interrupt handlers
support.................................................. 3
legacy OS, definition
legacy systems
definition
memory mapping
power button
functions
power management
power state
transitions
switching devices out
of
transitioning to ACPI
legends, logic
diagrams
LEqual (Logical
Equal)
LGreater (Logical
Greater)
LGreaterEqual
(Logical Greater Than Or Equal) 487
lid device
lid status
notification values............... 143, 144
lid switch
life, battery
link status events
LINT
LLess (Logical Less)
LLessEqual (Logical
Less Than Or Equal)
LNot (Logical Not)
LNotEqual (Logical
Not Equal)
Load (Load Definition
Block)
loading Definition
Blocks...... 85, 109, 488, 489
LoadTable (Load Definition
Block From XSDT) 489
local APIC,
definition
Local Objects
encoding, AML
Localx (Method Local Data Objects)............ 490
Lock (_LCK) object
Lock, Global..
logic
fixed power button
generic hardware
event example
lid switch
sleep button..
sleeping/wake control
logic diagram legends
LOr (Logical Or)
low-level warnings,
battery
LPT ports
macros, ASL
24-bit Memory
Resource Descriptor
32-bit Fixed Memory
Resource Descriptor 493
32-bit Memory
Resource Descriptor
coding
DMA Resource
Descriptor
DWordIO Resource
Descriptor
DWordMemory Resource
Descriptor
DWordSpace Resource
Descriptor
EISAID Conversion
End Dependent
Functions Resource Descriptor 469
Extended Interrupt
Resource Descriptor
ExtendedIO Resource
Descriptor
ExtendedMemory
Resource Descriptor
ExtendedSpace
Resource Descriptor
FixedIO Resource
Descriptor
I/O Port Resource
Descriptor
IRQ Interrupt
Resource Descriptor
IRQNoFlags Interrupt
Resource Descriptor 485
QWordIO Resource
Descriptor
QWordMemory Resource
Descriptor
QWordSpace Resource
Descriptor
Register Resource
Descriptor
ResourceTemplate
Start Dependent
Function NoPri Resource Descriptor 512
Start Dependent
Function Resource Descriptor
Unicode Conversion
UUID Conversion
VendorLong Resource
Descriptor
VendorShort Resource
Descriptor
WordBusNumber
Resource Descriptor
WordIO Resource
Descripto
WordSpace Resource
Descriptor
MADT
_MAT object
definition............................................ 16
flags
interrupt models
table fields..
Magic Packet wake
management See power management; thermal management
mapping
E820
EFI GetMemoryMap
INT 15
interfaces for
IRQs.......................................... 114,
116
PCI interrupt pins
physical memory
Query System Address
Map function
samples
Match (Find Object
Match)
Mechanical Off
definition
properties
transitioning from
transitioning to
memory
BIOS initialization
controller
configuration
descriptor macros
devices
map interfaces
map sample
NVS
physical mapping
resource flag
memory device
memory range
descriptors
24-Bit
32-Bit
32-Bit Fixed Location
purpose
memory space...
Memory24 (Memory
Resource Descriptor Macro) 491
Memory32 (Memory Resource
Descriptor Macro) 492
Memory32Fixed (Memory
Resource Descriptor Macro) 493
Message (_MSG)
control method
Method (Declare
Control Method)
Method data type, ASL..................... 437,
441
methods, control............... See control methods
mice.................................... See input devices
Microsoft Device
Class Power Management specifications 30
Mid (Extract Portion
of Buffer or String)
mobile PCs
lid switch
power management
profile system type
Mod (Integer Modulo)
modems
configuration example
power management........................ 543,
556
power management
example
modifiers
ASL names.
Module Device................................. 146,
292
MON-ALRM...
monitors........................... See display devices
month alarm
motherboard device
configurations
ACPI goals............................................ 1
controlled by OSPM
modems
MPS INTI flags
Multiple APIC
Description Table... See
MADT
Multiple APIC Table
Entry (_MAT) object
multiple Smart
Battery Subsystem
Multiply (Integer
Multiply)
multiprocessor PCs
performance control
power management for
mutex
acquiring
Global Lock
release
synchronization objects
Mutex (Declare
Synchronization/Mutex Object) 495
Mutex data type, ASL....................... 437,
441
Name (Declare Named
Object)
Name Objects
encoding, AML
name terms, ASL
Named Objects
encoding, AML
names, object...
Namespace...................... See ACPI Namespace
naming conventions
NAnd (Integer Bitwise
Nand)
nested packages
network devices,
power management.... 543, 559
NMIs
noise, active cooling
non-linear address
spaces
Non-Maskable
Interrupt Sources (NMIs)
non-visible states,
device power
Non-Volatile Sleep
state, definition
Non-Volatile Sleeping
memory (NVS)
NoOp Code (No
Operation)
NOr (Integer Bitwise
Nor)
Not (Integer Bitwise
Not)
notation
AML
ASL
numeric constants
register bits..
Nothing
notification
battery removal
power button control
Smart Battery status............................. 309
temperature changes
Notify (Notify Object
of Event)
numeric constants,
notation
NVS files
checking validity
restoring from
NVS memory.
object name,
definition
Object Reference data
type, ASL......... 437, 441
objects See also control methods, See also
style='font-style:normal'> control methods, See also control methods, See also
style='font-style:normal'> control methods
_ACx (Active Cooling).................. 327,
336
_ADR (Address)
_ALx (Active List)
_BBN (Base Bus
Number)
_BIF (Battery Information)
_BST (Battery Status)............ 317,
319, 321
_BTP (Battery Trip
Point)
_CID (Compatible ID)
_CRS (Current
Resource Settings)... 166, 300
_CRT (Critical
Temperature)........... 332, 336
_CST (C States)
_DDN (Device Name
_DIS (Disable)
_DMA (Direct Memory
Access)
_EDL (Eject Device
List)
_EJD (Ejection
Dependent Device)
_EJx (Eject)
_FDE (Floppy Disk
Enumerate)
_FDI (Floppy DIsk
Information)
_FIX (Fixed Register
Resource Provider)
_GLK (Global Lock)
_HID (hardware ID)....................... 161,
310
_HOT (Hot
Temperature)
_HPP (Hot Plug
Parameters).... 171, 173, 175
_INI (Init)...
_IRC (In Rush
Current)
_LCK (Lock)
_MAT (Multiple APIC
Table Entry)
_PCL (Power Consumer
List)
_PCT (Performance
Control)
_PPC (Performance Present
Capabilities)
_PR0 (Power Resources
for D0)
_PR1 (Power Resources
for D1)
_PR2 (Power Resources
for D2)
_PRS (Possible
Resource Settings)
_PRT (PCI Routing
Table)
_PRW (Power Resources
for Wake).. 140, 239
_PSL (Passive List)
_PSR (Power Source)
_PSS (Performance
Supported States) 263, 267, 270, 273
_PSV (Passive)............................ 327,
337
_PTC (Processor
Throttling Control)
_PXM (Proximity)
_RMV (Remove)
_S1D
_S2D
_S3D
_S4D
_SBS (Smart Battery
Subsystem)
_SEG (Segment)
_SRS (Set Resource
Settings)
_STA (Status).............................. 198,
235
_STR (String)
_SUN (Slot User
Number)
_TC1 (Thermal
Constant 1)
_TC2 (Thermal
Constant 2)
_TSP (Thermal
Sampling Period)
_TZD (Thermal Zone
Devices)
_TZP (Thermal Zone
Polling).. 281, 304, 343
_UID (Unique ID)
ASL encoding
ASL statements
ASL, declaring
control methods
definition
device configuration
device identification
device insertion and
removal
device power resource
device-specific
dynamic
EC-SMB-HC
embedded controller
interface
floppy controller
generic
global scope
initialization
Module Device
names, reserved
Notify operator
OS-defined.
Power Resource
processor
revision data
Smart Battery
SMBus host controller
static
thermal management
unnamed
ObjectType
ObjectType (Get
Object Type)
OEM implementation.................................. 3
OEM-supplied control
methods
off....................... See Mechanical Off; Soft-Off
OFF
ON
One (Constant One
Object)
Ones (Constant Ones
Object)
opcodes
Type 1, AML
Type 2, AML
Operating System............................... See OS
Operating
System-directed Power Management See
OSPM
Operation Region data
type, ASL........ 437, 441
Operation Region
Field Unit data type, ASL 437, 441
operation regions
SMBus....................................... 375,
378
OperationRegion
(Declare Operation Region) 498
OperationRegion term
access types
operator reference,
ASL
operator summary by
type, ASL
operator summary, ASL
operators, ASL
OpRegion
Or (Integer Bitwise
Or)
organization,
document................................ 9
original equipment
manufacturer......... See OEM
OS
AML support, required
boot flags...
compatibility
requirements........................ 9
defined object names
device power
management
drivers, embedded
controller interface
functional fixed
hardware implementation
independent generic
hardware
legacy hardware
interaction........................ 3
loading
name object
policy owner, device
power management
power management.................................. 2
Query System Address
Map
S4 Sleeping state
transition
transparent events
OSPM
caches, flushing
cooling policy
changes
cooling preferences
definition
device insertion and
removal
event handlers
exclusive controls
fixed hardware access
fixed hardware
registers
functions
general-event
register access
generic hardware
model
Get Power Status
goals..................................................... 1
hardware model
implementation
requirements..................... 8
passive cooling
performance states
power management vs.
performance
power state control
Real Time Clock Alarm
(RTC)
resetting system
Set Power State
operation
SMBus registration
thermal management
325
transitioning to
sleeping states
transitioning working
to sleeping states
transitioning working
to soft-off state
Output Buffer Full
(OBF) flag............ 357, 362
output devices
control methods
definition...
switching...
types of
override, power
button
P_BLK
P_LVL2
P_LVL3
P0 performance state,
definition
P1 performance state,
definition
Package (Declare
Package Object)
Package data type,
ASL..................... 437, 441
packages
definition
length
length encoding, AML
nested
packet error checking
(PEC)
parameters, ASL
parent bits..
77
parent objects, ASL
statements
parentheses, AML
notation
Passive (_PSV) object....................... 327,
337
passive cooling
definition
326
preferences
333
processor clock
throttling
threshold values
Passive List (_PSL)
object
PC Card controllers,
power management 543, 560
PC keyboard
controllers
PCCARD
PCI
BAR target operations
bus number.
buses, address space
translation
Device Objects code
device power
management
interrupt pins
IRQ routing
power management
PCI configuration
space........................ 45, 52
PCI Interrupt Link
device
PCI Routing Table
(_PRT) object
PCISIG
PCMCIA
PEC (packet error
checking)................ 364, 376
Performance Control
(_PCT) object
Performance Present
Capabilities (_PPC) object 271
performance states
definitions
device
Performance Supported
States (_PSS) object 263, 267, 270, 273
performance, energy
conservation vs...... 44, 233
Persistent System
Description Table (PSDT) 111
phones, answering
modem example
waking computer
PIC method
pins
general event model
GPE
platform
implementation....................................... 5
independence.......................................... 2
Platform Interrupt
Source structure
Platform Management
Interrupts (PMIs)
Plug and Play devices
ACPI control
IDs............................................. 144,
159
large resource items
resource control
method
small resource items
specifications
PM timer
bits
function
idle time,
determining
operations
register address
register blocks
PM1 Control registers
addresses
bits
blocks
grouping.
73
PM1 Enable registers
PM1 Event registers
addresses
blocks
grouping.
69
PM1 Status registers
PM2 Control registers
addresses
bits
blocks
PM2 Controller
register grouping
PMIs
Pn performance state,
definition
PNPBIOS
Polarity flags..
policy owner...
polling, thermal............................... 328,
329
port descriptors, I/O
portability...................... See independence, OS
Possible Resource
Settings (_PRS) object
POST Device control
methods
power button
ASL code example
control methods
282
definition
device ID
dual-button model
fixed hardware
functions
object notification
values
override..
65
single-button model
Power Consumer List
(_PCL) object
power consumption
device and processor
performance states
device power states
global power states
power loss
Mechanical Off
S4 Non-Volatile Sleep
state
power management
audio devices
BIOS.................................................... 2
buses
COM port devices
cooling, relationship
to
definition
desktop PCs.
device
541, 543
device objects
display devices
display standards
goals..................................................... 2
input devices
lazy I/O operations.................................. 2
legacy
mobile PCs..
modem devices
modem example
multiprocessor PCs
network devices
PC Card controllers
PCI
PCMCIA...
performance states
performance vs.
energy conservation... 44, 233
Plug and Play devices
preferred system
types
processor
servers
setting device power
states
standards
storage devices
power management (PM)
timer
bits
function
idle time,
determining
operations
register address
register blocks
Power Resource data
type, ASL.......... 437, 441
power resources
battery management
child objects
definition
device objects
devices, turning off
Differentiated
Definition Block
isolation logic
objects
shared
wake system object
Power Source (_PSR)
object
power sources
AC adapter.
definition
object notification
values
power states
control methods
controlled by OSPM
device
global
non-symmetric
processor
objects
processor
253
sleeping
transitioning.
user-visible...
PowerResource
(Declare Power Resource)
preferences, user
performance vs.
energy conservation... 44, 333
power button
preferred PM profile
system
Prepare to Sleep
(_PTS) control method
Process Call
(SMBProcessCall) protocol
processor......................................... See CPU
Processor (Declare
Processor)
processor and device
performance states
processor control
block
processor control
registers
addresses
bits
Processor data type,
ASL................... 437, 441
processor device
notification values
Processor devices
Processor Local APIC....................... 113,
116
Processor Local SAPIC
processor LVL2
register....................... 76, 254
processor LVL3
register....................... 77, 254
processor objects
processor register
block
Processor Throttling
Control (_PTC) object
programming models
events
feature summary
fixed
generic
protocol register
(SMB_PRTCL)
protocols
BARs (Base Address
Registers)
CMOS
SMBus................................ 366,
375, 382
Proximity (_PXM)
object
PSDT
pseudocode language........................ See AML
pulsed interrupts
PWRBTN_EN..
PWRBTN_STS
Query Embedded
Controller (QR_EC)
query events
Query System Address
Map function
query value,
definition
quotes
AML notation
ASL notation
QWord IO Resource
Descriptor Macro
QWord Memory Resource
Descriptor Macro
QWORD resource
descriptor format 210, 503, 505, 506
QWord Space Resource
Descriptor Macro
Read Embedded
Controller (RD_EC)
Read/Write Block
(SMBBlock) protocol
Read/Write Byte
(SMBByte) protocol
Read/Write Quick
(SMBQuick) protocol
Read/Write Word
(SMBWord) protocol
Real Time Clock Alarm
(RTC)
reclaim memory
RefOf (Create Object
Reference)
Region (_REG) control
method
register bits,
notation
register blocks..
register definitions,
hardware
Register Generic
Register Descriptor Macro)
register groupings
definition
56
list of
registers
BARs (Base Address
Registers)
control
EC-SMB-HC
embedded controller
interface
enable
fixed feature..
fixed hardware
general-purpose event
reset
SMB-HC...
status
status/enable.
virtual......................................... 376,
380
related device
interference
Release (Release a
Mutex Synchronization Object) 507
Release terms..
Remaining Battery
Percentage.............. 39, 318
removal objects
removal, batteries
Remove (_RMV) object
requirements,
implementation
OS....................................................... 9
OSPM.................................................. 8
reserved bits
definition
hardware
PM1 Control registers
PM1 Enable registers
PM1 Status register
71
software requirements
reserved object names
reserved SMBus
protocol values
Reset (Reset an Event
Synchronization Object) 508
reset register
resource data types
Address Space
Resource Descriptors
control methods
DMA
End Dependent
Functions
end tag
IRQ
large
large vendor defined
memory range
descriptors
small
small vendor defined
Start Dependent
Functions
vendor defined
resources
allocation...
control method
interdependencies
resources, power................. See power resources
ResourceTemplate
Resource To Buffer Conversion Macro) 508
restoring system
context...................... 20, 399
results, storing
Return (Return from
Method Execution)
Revision (Constant
Revision Object)
revision data object
RISC processors
RISC systems..
ROM
control methods
Root System
Description Pointer...... See RSDP
Root System
Description Table......... See RSDT
RSDP
definition
location
table structure
RSDT
definition
location
table fields...
RTC (Real Time Clock
Alarm)
RTC/CMOS protocols
RTC_EN
RTC_STS
S0 State (Working)
S1 Sleeping state
_S1D object
behavior during
definition
implementation
transitioning
waking using RTC
S2 Sleeping state
_S2D object
behavior during
definition
implementation
transitioning
waking using RTC
S3 Sleeping state
_S3D object
behavior during
definition
implementation
transitioning
waking using RTC
S4 Sleeping state
_S4D object
behavior during
definition
22
implementation
low-level battery
waking using RTC
S5 Soft-Off
behavior during............................ 249,
400
definition
22
properties
transitioning to
SAPIC
definition
I/O
117
local................................................... 16
NMI
Processor Local
support
SATA
controller device
saving system context
during emergency
shutdown
S4 Non-Volatile Sleep
state.............. 20, 399
SBST
SCI
battery status
information
definition
embedded controller
events
enable bits
interrupt handlers
68
SCI_EN
69, 74
Scope (Open Named
Scope)
SCSI, power
management
Secondary System
Description Table.. See SSDT
Segment (_SEG) object
Send/Receive Byte
(SMBSendReceive) protocol 382
separators, ASL
Serialized methods............................ 478,
494
server machines,
power management
Set Cooling Policy
(SCP) control method
Set POST Device
(_SPD)
Set Power State
Set Resource Settings
(_SRS) object
Set the Brightness
Level (_BCM)
Set Timing Mode
(_STM) control method
settings, user
performance vs.
energy conservation... 44, 333
power button
shareable interrupts
shared interface,
embedded controller.... 354, 356
ShiftLeft (Integer
Shift Left)
ShiftRight (Integer
Shift Right)
Short Vendor-Defined
Resource Descriptor macro 519
shutdown, emergency
332
shutting down....... See Mechanical Off; Soft-Off
Signal (Signal a
Synchronization Event)
signatures
collisions, avoiding
92
interpreting
92
values, storing
Simple Boot Flag
Specification, Microsoft
single quotes
AML notation
ASL notation
single-button model
SizeOf (Get Data
Object Size)
slave addresses,
SMBus..................... 308, 375
Sleep (Milliseconds
Sleep)
sleep button
ASL code example
control methods
282
definition
device ID
fixed hardware
object notification
values
support
Sleeping states
behavior during
button logic..
control methods
definitions
22
entering
logic controlling
non-volatile..
objects
packages, system
state
power consumption
power loss
properties
transitioning
245, 570
transitioning to
user settings.
waking using RTC
Slot User Number
(_SUN) object
SLP_EN...
397
SLP_EN field...
SLP_TYPx
397
SLP_TYPx field
65
SLPBTN_EN...
SLPBTN_STS.
small resource data
type
Smart Batteries
control methods
definition
device ID
multiple battery
subsystem
objects
single battery
subsystem
SMBus data buffers
SMBus devices
specifications
status notification................................ 309
subsystem
307
supported
table
table formats
Smart Battery Charger
functions
status notification
Smart Battery
Selector
Smart Battery System
Manager
functions
status notification
SMB-HC................................. 308,
312, 370
SMBus
address register
(SMB_ADDR)
address space
alarm address
register (SMB_ALRM_ADDR) 366
alarm data register
(SMB_ALRM_DATA) 366
block count register
(SMB_BCNT)
Block Write-Read
Block Process Call (SMBBlockProcessCall) protocol 385
command register
(SMB_CMD)
commands, restricted
data buffers.
data
register array (SMB_DATA)
definition
device access,
embedded controller interface 371
device enumeration,
enabling
device ID
embedded controller
interface
encoding, bit
fields, declaring
generic hardware
addresses
host controller
notification header (OS_SMB_EVT) 360
host controller
objects, declaring
interface
operation regions.......................... 375,
378
PEC (packet error
checking)
Process Call
(SMBProcessCall) protocol
protocol register
(SMB_PRTCL)
protocols.............................. 366,
375, 382
Read/Write Block
(SMBBlock) protocol
Read/Write Byte
(SMBByte) protocol
Read/Write Quick
(SMBQuick)
Read/Write Word
(SMBWord) protocol
Send/Receive Byte
(SMBSendReceive) protocol 382
slave addresses............................. 308,
375
specifications
status codes
status register
(SMB_STS)
transactions.
virtual registers
SMBus devices
SMI
definition
embedded controller
firmware
event flags (SMI_EVT)
interrupt events
68
SMM firmware.
Soft-Off
behavior during............................ 249,
400
definition
22
properties
transitioning crashed
systems to
transitioning to
401
SOHO servers.
sources, power..................... See power sources
SSDT
111
Stall (Stall for a
Short Time)
standards
device power states
power management
Start Dependent
functions resource descriptor format 201
StartDependentFn
Start Dependent Function Resource Descriptor Macro) 511
StartDependentFnNoPri
Start Dependent Function Resource Descriptor Macro) 512
statements
ElseIf
If
Power Resource
Processor
statements, ASL
statesSee power states
static objects...
Status (_STA).
Status (_STA) object
status bits
corresponding enable
bits
functions
symbol
status codes, SMBus
status notification, Smart Battery
status register...
status register
(SMB_STS)
status, battery...
status/enable
registers
sticky status bit,
definition
storage devices,
power management
Store (Store an
Object)
storing results, ASL
operators
Streamlined Advanced
Programmable Interrupt Controller See SAPIC
String (_STR) object
String data type, ASL....................... 437,
441
strings, ASL.................................... 411,
434
Subtract (Integer
Subtract)
supplemental
documentation
surprise-style
removal........................ 189, 198
Switch (Select Code
To Execute Based On Expression) 513
switching, output
devices
Sx states............................ See Sleeping states
symbols, logic
diagrams
syntax
OperationRegion
Power Resource
statements
syntax, ASL...
system context
definition
during emergency shutdown
restoring
S4 Sleeping state
sleep states lost in
System Control
Interrupt..................... See SCI
system description
tables.................. See tables
system events,
general model
system indicators
System Management Bus............... See SMBus
System Management
Interrupt............. See SMI
System Management
Mode............... See SMM
system memory space
system states, global..... See global system states
System Status (_SST)
control method
System Wake (_WAK)
control method
tables
address format
compatibility
DSDT
embedded controller boot
resources
encoding format
FACS
FADT
headers...
90
MADT
overview
RSDP
RSDT
SBST (Smart Battery
Description)
signatures
92
SSDT
XSDT
Temperature (_TMP)
control method.... 327, 341
temperature changes,
detecting
temperature
management See thermal management
Term Objects
encoding, AML
terminology
design guides
7
device power states
general
global system states
performance states
processor power
states
sleeping states
terms
AML
ASL notation
Thermal Constant 1
(_TC1) object
Thermal Constant 2
(_TC2) object
thermal management
control methods
energy conservation,
optimizing
notification of
temperature changes
objects
OSPM controlled
overview
performance, optimizing
polling........................................ 328,
329
temperature changes,
detecting
threshold settings,
dynamically changing
trip points..
Thermal Sampling
Period (_TSP) object
thermal states,
definition
Thermal Zone data
type, ASL............. 437, 441
Thermal Zone Devices
(_TZD) object
Thermal Zone Polling
(_TZP) object 281, 304, 343
thermal zones
basic configuration........................ 345,
348
examples..................................... 345,
348
mobile PC example
multiple
multiple-speed fan
example
object notification
values
object requirements
ThermalZone (Declare
Thermal Zone)
thirty-two bit fixed
location memory range resource descriptor format 208
thirty-two bit memory
range resource descriptor format 207
throttling........................................ 255,
265
THT_EN
Timer
(Get 64-Bit Timer Value)
timers
global standby
idle
power management (PM)
60
TMR- field
TMR_EN
TMR_STS
TMR_VAL
ToBCD (Convert
Integer to BCD)
ToBuffer (Convert
Data to Buffer)
ToDecimalString
(Convert Data to Decimal String) 516
ToHexString (Convert
Data to Hexadecimal String) 516
ToInteger (Convert
Data to Integer)
token ring adapters............. See network devices
top of memory
ToString (Convert
Buffer To String)
transactions, SMBus
data buffers.
status codes
transitioning
crashed systems
62
device power states
Legacy mode to ACPI
power states
49, 570
working to sleeping
states
working to soft-off
states
transparent events
transparent
switching, device power states
trap monitors
Trigger Mode flags
trip points, thermal
turning off See Mechanical Off; Soft-Off; transitioning
TVs
twenty-four bit
memory range resource descriptor format 206
Type 1 Opcodes, AML
encoding
Type 2 Opcodes, AML
encoding
UARTs, power
management
Unicode (String To
Unicode Conversion Macro) 518
Uninitialzed data
type, ASL............... 437, 441
Unique ID (_UID)
object
Unload (Unload
Definition Block)
unnamed objects
unrelated device
interference
upper case, ASL names
USB, power management
user preferences
performance vs.
energy conservation... 44, 333
power button
user-visible power
states
UUID (Convert String
to UUID Macro)
value-added hardware
enabling OSPM
registers
Variable List...
VCR-style ejection
mechanism
vendor defined large
resource descriptor format 207
vendor defined
resource data types
vendor defined small
resource descriptor format 204
VendorLong Long
Vendor-Defined Descriptor macro) 518
VendorShort Vendor
Defined Resource Descriptor Macro) 519
VESA specifications
VGA.............................................. 568,
572
video controllers,
power management
Video Electronics
Standards Associations (VESA) 542
video extensions,
requirements for
Video POST Options
(_VPO)
virtual data objects
virtual registers................................ 376,
380
visible states
global system
power
Wait (Wait for a
Synchronization Event)
WAK_STS (Wake Status)
71
wake frame events
waking
_BFS (Back From
Sleep) control method
_WAK control method
audio devices
COM ports.
device power resource
object (_PRW)
devices
disabling
system-waking devices
display devices
initialization
input devices
latency time
570
lid switch
logic controlling
modem devices
modem example
35
network devices
OS operations
PC Card controllers
Real Time Clock Alarm
(RTC)
resetting lost enable
bits
storage devices
warm insertion and
removal................ 190, 193
warnings, battery
WBINVD........................................ 258,
402
web sites
Intel Architecture
Microsoft
PCISIG
PCMCIA...
Smart Battery System
SMBus specification
USB-IF
While (Conditional
Loop)
WORD resource
descriptor format
WordBusNumber (Word
Bus Number Resource Descriptor Macro) 520
WordIO (Word IO
Resource Descriptor Macro) 521
WordSpace (Word Space
Resource Descriptor Macro) 523
Working state
behavior during
definition
properties
transitioning to
transitioning to
Sleeping state
transitioning to
Soft-Off
workstations...
Write Embedded
Controller (WR_EC)
write-only bits
control
definition
XOr
(Integer Bitwise Xor)
XSDT
definition
loading Definition
Block
location
table fields...
Zero (Constant Zero
Object)
Zero, One, Ones data
type, ASL.......... 437, 441
zones, thermal...................... See thermal zones
[1]
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.
RTC wakeup alarm is required, the
fixed hardware feature status bit is optional.
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.
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.
On x86-based platforms, the OSPM
uses the Hot Pluggable bit to determine whether it should shift into PAE mode
to allow for insertion of hot-plug memory with physical addresses over 4 GB.
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. The root of the name space and
certain locations where interaction is being designed are the areas in which
extra care must be taken.
Unless the operation being performed
is explicitly prepared for failure in name resolution, this is considered an
error and may cause the system to stop working.
A Plug and Play (EISA) ID can be
obtained by sending e-mail to pnpid@microsoft.com.
Plug and Play BIOS Specification
Version 1.0A, May 5, 1994, Compaq Computer Corp., Intel Corp., Phoenix
Technologies Ltd.
Or it is at least assumed to be in
the D3 state by its device driver. For example, if the device doesn't
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.
[11]
Only buses that support hardware-defined enumeration methods are done
automatically at run-time. This would include ACPI-enumerated devices.
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.
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.
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 device's slave address is aligned to
bit 1 of the host controller's slave command register, bit 1 of the slave
address is aligned to bit 2 of the controller's slave command register, and so
on.
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).
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.
NO LICENSE, EXPRESS OR
IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS
GRANTED OR INTENDED HEREBY.
HP, INTEL, MICROSOFT,
PHOENIX, AND TOSHIBA DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR
INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION
IN THIS SPECIFICATION. HP, 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.
Copyright
@ 1996, 1997, 1998, 1999, 2001, 2002, 2003, 2004, 2005, 2006 Hewlett-Packard
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.
|