Advanced Configuration and Power Interface Specification Hewlett-Packard Corporation

4. 
   
   
   
5. 
      General-Purpose Event Handling
   

An example of a general-purpose event is specified in section 4, “ACPI Hardware Specification,” where EC_STS and EC_EN bits are defined to enable OSPM to communicate with an ACPI-aware embedded controller device driver. The EC_STS bit is set when either an interface in the embedded controller space has generated an interrupt or the embedded controller interface needs servicing. Notice that if a platform uses an embedded controller in the ACPI environment, then the embedded controller’s SCI output must be directly and exclusively tied to a single GPE input bit.

Hardware can cascade other general-purpose events from a bit in the GPEx_BLK through status and enable bits in Operational Regions (I/O space, memory space, PCI configuration space, or embedded controller space). For more information, see the specification of the General-Purpose Event Blocks (GPEx_BLK) in section 4.7.4.1, “General-Purpose Event Register Blocks.”

OSPM manages the bits in the GPEx blocks directly, although the source to those events is not directly known and is connected into the system by control methods. When OSPM receives a general-purpose event (the event is from a GPEx_BLK STS bit), OSPM does the following:

1. 
   Disables the interrupt source (GPEx_BLK EN bit).
   
2. 
   If an edge event, clears the status bit.
   
3. 
   Performs one of the following:
   

• 
  Dispatches to an ACPI-aware device driver.
  
• 
  Queues the matching control method for execution.
  
• 
  Manages a wake event using device _PRW objects.
  

4. 
   If a level event, clears the status bit.
   
5. 
   Enables the interrupt source.
   

• 
  Enable bits must be read/write.
  
• 
  Status bits must be latching.
  
• 
  Status bits must be read/clear, and cleared by writing a “1” to the status bit.
  

1. 
      _Exx, _Lxx, and _Qxx Methods for GPE Processing
   

The _Qxx methods are used for the Embedded Controller and SMBus (below.)

1.    Queuing the Matching Control Method for Execution

   
   

For example, suppose an OEM supplies a wake event for a communications port and uses bit 4 of the GPE0_STS bits to raise the wake event status. In an OEM-provided Definition Block, there must be a Method declaration that uses the name \_GPE._L04 or \GPE._E04 to handle the event. An example of a control method declaration using such a name is the following:

Notify (\_SB.PCIO.COM0, 2)

}

The control method performs whatever action is appropriate for the event it handles. For example, if the event means that a device has appeared in a slot, the control method might acknowledge the event to some other hardware register and signal a change notify request of the appropriate device object. Or, the cause of the general-purpose event can result from more then one source, in which case the control method for that event determines the source and takes the appropriate action.

Notify (\_SB.TZ0.THM1, 0x80)

}

When an SMBus alarm is handled by the SMBus driver, the SMBus driver uses a similar naming convention defined by ACPI for the driver to determine the control method to queue for execution. When an alarm is received by the SMBus host controller, it generally receives the SMBus address of the device issuing the alarm and one word of data. On implementations that use SMBALERT# for notifications, only the device address will be received. The name of the control method to queue is always of the form _Qxx where xx is the SMBus address of the device that issued the alarm. The SMBus address is 7 bits long corresponding to hex values 0 through 7F, although some addresses are reserved and will not be used. The control method will always be queued with one argument that contains the word of data received with the alarm. An exception is the case of an SMBus using SMBALERT# for notifications, in this case the argument will be 0. An example declaration for a control method that handles a SMBus alarm follows:

// Arg0 = 0 if device supports only SMBALERT#

}

2. 
      Dispatching to an ACPI-Aware Device Driver
   

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 OEM-specific 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.

2. 
      GPE Wake Events
   

• 
  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.
  

1) Button Devices

• 
  PNP0C0C — Power Button Device
  
• 
  PNP0C0D — Lid Device
  
• 
  PNP0C0E — Sleep Button Device
  

• 
  PNP0A03 — PCI Host Bridge
  

1.    Managing a Wake Event Using Device _PRW Objects

   
   

OSPM enables or disables the device wake function by enabling or disabling its corresponding GPE and by executing its _PSW control method (which is used to take care of the second-level enables). When the GPE is asserted, OSPM still executes the corresponding GPE control method that determines which device wakes are asserted and notifies the corresponding device objects. The native OS driver is then notified that its device has asserted wake, for which the driver powers on its device to service it.

If the system is in a sleeping state when the enabled GPE bit is asserted the hardware will transition the system into the S0 state, if possible.

2. 
      Determining the System Wake Source Using _Wxx Control Methods
   

If _Wxx is implemented, either hardware or firmware must detect and save the source device as described in Section 7.3.5, “_SWS (System Wake Source)”. During invocation, the _Wxx control method determines the source device and issues a Notify(,0x2) on the device that caused the system to transition to the S0 state. If the device uses a bus-specific method of arming for wakeup, then the Notify must be issued on the parent of the device that has a _PRW method. The _Wxx method must issue a Notify(,0x2) only to devices that contain a _PRW method within their device scope. OSPM’s evaluation of the _SWS and _Wxx objects is indeterminate. As such, the platform must not rely on _SWS or _Wxx evaluation to clear any hardware state, including GPEx_STS bits, or to perform any wakeup-related actions.

6. 
      Device Object Notifications