Advanced Configuration and Power Interface Specification

Advanced Configuration and Power Interface Specification
Method(_Q18, 1) { // Thermal sensor device at address 0011 000
// Arg0 contains notification value (if any)
// Arg0 = 0 if device supports only SMBALERT#
}
Notify (\_SB.TZ0.THM1, 0x80)
5.6.4.1.2 Dispatching to an ACPI-Aware Device Driver
Certain device support, such as an embedded controller, requires a dedicated GPE to service the
device. Such GPEs are dispatched to native OS code to be handled and not to the corresponding
GPE-specific control method.
In the case of the embedded controller, an OS-native, ACPI-aware driver is given the GPE event for
its device. This driver services the embedded controller device and determines when events are to be
reported by the embedded controller by using the Query command. When an embedded controller
event occurs, the ACPI-aware driver dispatches the requests to other ACPI-aware drivers that have
registered to handle the embedded controller queries or queues control methods to handle each
event. If there is no device driver to handle specific queries, OEM AML code can perform OEMspecific
functions that are customized to each event on the particular platform by including specific
control methods in the namespace to handle these events. For an embedded controller event, OSPM
will queue the control method of the name _QXX, where XX is the hex format of the query code.
Notice that each embedded controller device can have query event control methods.
Similarly, for an SMBus driver, if no driver registers for SMBus alarms, the SMBus driver will
queue control methods to handle these. Methods must be placed under the SMBus device with the
name _QXX where XX is the hex format of the SMBus address of the device sending the alarm.
5.6.4.2 GPE Wake Events
An important use of the general-purpose events is to implement device wake events. The
components of the ACPI event programming model interact in the following way:
• When a device asserts its wake signal, the general-purpose status event bit used to track that
device is set.
• While the corresponding general-purpose enable bit is enabled, the SCI interrupt is asserted.
• If the system is sleeping, this will cause the hardware, if possible, to transition the system into
the S0 state.
• Once the system is running, OSPM will dispatch the corresponding GPE handler.
• The handler needs to determine which device object has signaled wake and performs a wake
Notify
• command on the corresponding device object(s) that have asserted wake.
• In turn OSPM will notify OSPM native driver(s) for each device that will wake its device to
service it.
Events that wake may not be intermixed with non-wake (runtime) events on the same GPE input.
The only exception to this rule is made for the special devices below. Only the following devices are
allowed to utilize a single GPE for both wake and runtime events:
1. Button Devices
246 April, 2015 Version 6.0