27.10.2015 Views

Advanced Configuration and Power Interface Specification

ACPI_6.0

ACPI_6.0

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

ACPI Software Programming Model<br />

• PNP0C0C — <strong>Power</strong> Button Device<br />

• PNP0C0D — Lid Device<br />

• PNP0C0E — Sleep Button Device<br />

2. PCI Bus Wakeup Event Reporting (PME)<br />

• PNP0A03 — PCI Host Bridge<br />

All wake events that are not exclusively tied to a GPE input (for example, one input is shared for<br />

multiple wake events) must have individual enable <strong>and</strong> status bits in order to properly h<strong>and</strong>le the<br />

semantics used by the system.<br />

5.6.4.2.1 Managing a Wake Event Using Device _PRW Objects<br />

A device’s _PRW object provides the zero-based bit index into the general-purpose status register<br />

block to indicate which general-purpose status bit from either GPE0_BLK or GPE1_BLK is used as<br />

the specific device’s wake mask. Although the hardware must maintain individual device wake<br />

enable bits, the system can have multiple devices using the same general-purpose event bit by using<br />

OEM-specific hardware to provide second-level status <strong>and</strong> enable bits. In this case, the OEM AML<br />

code is responsible for the second-level enable <strong>and</strong> status bits.<br />

OSPM enables or disables the device wake function by enabling or disabling its corresponding GPE<br />

<strong>and</strong> by executing its _PSW control method (which is used to take care of the second-level enables).<br />

When the GPE is asserted, OSPM still executes the corresponding GPE control method that<br />

determines which device wakes are asserted <strong>and</strong> notifies the corresponding device objects. The<br />

native OS driver is then notified that its device has asserted wake, for which the driver powers on its<br />

device to service it.<br />

If the system is in a sleeping state when the enabled GPE bit is asserted the hardware will transition<br />

the system into the S0 state, if possible.<br />

5.6.4.2.2 Determining the System Wake Source Using _Wxx Control Methods<br />

After a transition to the S0 state, OSPM may evaluate the _SWS object in the \_GPE scope to<br />

determine the index of the GPE that was the source of the transition event. When a single GPE is<br />

shared among multiple devices, the platform provides a _Wxx control method, where xx is GPE<br />

index as described in Section 5.6.4.2.2, that allows the source device of the transition to be<br />

determined. If implemented, the _Wxx control method must exist in the \_GPE scope or in the scope<br />

of a GPE block device.<br />

If _Wxx is implemented, either hardware or firmware must detect <strong>and</strong> save the source device as<br />

described in Section 7.4.3, “_SWS (System Wake Source)”. During invocation, the _Wxx control<br />

method determines the source device <strong>and</strong> issues a Notify(,0x2) on the device that caused<br />

the system to transition to the S0 state. If the device uses a bus-specific method of arming for<br />

wakeup, then the Notify must be issued on the parent of the device that has a _PRW method. The<br />

_Wxx method must issue a Notify(,0x2) only to devices that contain a _PRW method<br />

within their device scope. OSPM’s evaluation of the _SWS <strong>and</strong> _Wxx objects is indeterminate. As<br />

such, the platform must not rely on _SWS or _Wxx evaluation to clear any hardware state, including<br />

GPEx_STS bits, or to perform any wakeup-related actions.<br />

If the GPE index returned by the _SWS object is only referenced by a single _PRW object in the<br />

system, it is implied that the device containing that _PRW is the wake source. In this case, it is not<br />

necessary for the platform to provide a _Wxx method.<br />

Version 6.0 247

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!