Wake Requests

< BACK  NEXT >

[oR]

To understand the Windows 2000 architecture for handling wake requests, it is important to first understand the hardware operation. A device that is armed for wake detection appears to have the capability to force a sleeping system back to life. In fact, since the device is a slave of the bus, it really has only the capability to signal its intent to the bus. It is the bus hardware that in turn forces the system out of its sleep.

The significance of this is that the software that drives the hardware is ultimately centered at the bus driver. The arming process starts at the top of the device stack, but the actual waiting occurs at the bottom bus driver. Thus, the overall process for the wake process is

1. A power policy owner (usually a bus driver) initiates a request to arm or disarm the wake mechanism for a device using PoRequestPowerIrp, subcode IRP_MN_WAIT_WAKE. (A callback routine, fired when the IRP eventually finishes, is set.)

2. A driver of wake-capable hardware handles requests to arm and disarm the trigger mechanism.

3. Wake-aware drivers pass down the arm/disarm request to lower-level drivers. The request will pend (perhaps for hours) at the bus driver.

4. The system enters sleep mode.

5. The wake hardware (obviously without suspended software support) tickles the bus and awakens the system CPU.

6. The bus driver (now executing) completes the original IRP_MN_WAIT_ WAKE IRP.

7. Any higher-level driver with a registered I/O Completion routine will be notified as the IRP works its way back up the device stack. A function driver might need to reset the wake trigger mechanism.

8. The original creator of the arming request is notified that the (multihour) process is complete. Presumably, the creator re-arms the wake trigger mechanism for the next (multihour) cycle.

This process is depicted in Figure 10.2.

Figure 10.2. The wake process.

There are several noteworthy points concerning the process. First, a device stack is allowed, at most, one outstanding WAIT_WAKE IRP at a time. Therefore, a single pointer within the FDO device extension is appropriate to hold the WAIT_WAKE IRP pointer if established.

Second, the policy owner that issues the arm or disarm request must do so only when the device is at full power, state D0. Additionally, neither the device nor the system may be in a power state transition at the time the arm or disarm request is made. This last rule appears a bit restrictive in that it might make sense to decide to arm the wake device just before the device enters a reduced power mode. Instead, the decision to arm must be made a priori, with the device stack left enabled for a potential sleep-wake cycle.

Canceling the Wake-Armed IRP

Once issued, an IRP_MN_WAKE_WAIT IRP remains outstanding indefinitely. The bus driver holds this request in a pended state, long before the system even enters the sleep state.

To disarm the wake capability, the IRP must be canceled by the original requestor, the power policy owner. To cancel the request, the policy owner invokes the I/O Manager function IoCancelIrp, described in Table 10.7. A typical need to cancel the power IRP occurs when an armed device is stopped or ejected from the system.

Table 10.7. Function Prototype for IoCancelIrp

BOOLEAN IoCancelIrp	IRQL <= DISPATCH_LEVEL
Parameter	Description
IN PRIP pIrp	Pointer to IRP to cancel
Return value	TRUE - IRP cancellation succeeded
	FALSE - IRP could not be canceled

< BACK  NEXT >