1. Plug and Play and Power Management Overview
KMDF implements integrated Plug and Play and power
management support as an internal state machine. An event is associated
with the transition to each state, and a driver can supply callback
routines that are invoked at each such state change.
If you are familiar with WDM drivers, you probably
remember that any time the system power state changes, the WDM driver
must determine the correct power state for its device and then issue
power management requests to put the device in that state at the
appropriate time. The KMDF state machine automatically handles the
translation of system power events to device power events. For example,
KMDF notifies the driver to
Transition the device to low power when the system hibernates or goes to sleep.
Enable the device’s wake signal so that it can be triggered while the system is running, if the device is idle.
Enable the device’s wake signal so that it can be triggered while the system is in a sleep state.
KMDF
automatically provides for the correct behavior in device parent/child
relationships. If both a parent and a child device are powered down and
the child must power up, KMDF automatically returns the parent to full
power and then powers up the child.
To manage idle devices, the KMDF state machine
notifies the driver to remove the device from the working state and put
it in the designated low-power state when the device is idle and to
return the device to the working state when there are requests to
process.
To accomplish these power transitions, a driver
includes a set of callback routines. These routines are called in a
defined order, and each conforms to a “contract” so that both the device
and the system are guaranteed to be in a particular state when the
driver is called to perform an action. This support makes it much easier
for drivers to power down idle devices. The driver simply sets an
appropriate time-out value and low-power state for its device and
notifies KMDF of these values; KMDF calls the driver to power down the
device at the correct times.
In addition, requests received by the framework and
not yet delivered to the device driver can affect the power state of the
device. If the driver has not configured a queue for power management,
the framework can automatically restore device power before it delivers
the request to the driver. It can also automatically stop and start the
queue in response to Plug and Play and power events.
Finally, the driver that manages power policy for the
device can specify whether a user can control both the behavior of the
device while it is idle and the capability of the device to wake up the
system. All the driver must do is specify the appropriate enumerator
value when it initializes certain power policy settings. KMDF enables
the necessary property sheet through Windows Management Instrumentation
(WMI), and Device Manager displays it.
2. Device Enumeration and Startup
To prepare the device for operation, KMDF calls the
driver’s callback routines in a fixed sequence. The sequence varies
somewhat depending on the driver’s role in the device stack.
2.1. Startup Sequence for a Function or Filter Device Object
The
following example shows the callbacks for an FDO or filter DO that is
involved in bringing a device to the fully operational state, starting
from the Device Inserted state at the bottom of the figure.
|
Device Operational
| Enable self-managed I/O, if driver supports it | EvtDeviceSelfManagedIoInit
or
EvtDeviceSelfManagedIoRestart | | Start power-managed queues (called only if EvtIoStop was previously called during power-down) | EvtIoResume | | Disarm wake signal, if it was armed | EvtDeviceDisarmWakeFromSx EvtDeviceDisarmWakeFromSO (called only during power-up; not called during resource rebalance) | | Enable DMA, if driver supports it | EvtDmaEnablerSelfManagedIoStart
EvtDmaEnablerEnable
EvtDmaEnableFill | | Connect interrupts | EvtDeviceDOEntryPostInterruptsEnabled EvtInterruptEnable | | Notify driver of state change | EvtDeviceDOEntry |
Restart from here if device is in low-power state
| Prepare hardware for power | EvtDevicePrepareHardware | | Change resource requirements | EvtDeviceRemoveAddedResources EvtDeviceFilterAddResourceRequirements EvtDeviceFilterRemoveResourceRequirements |
Restart from here if rebalancing resources
| Create device object | EvtDriverDeviceAdd |
Device Inserted
|
The
spaces between the entries in the preceding example mark the steps that
are involved in starting a device. The column on the left side of the
figure describes the step, and the column on the right lists the event
callbacks that accomplish it.
At the bottom of the figure, the device is not
present on the system. When the user inserts it, KMDF begins by calling
the driver’s EvtDriverDeviceAdd
callback so that the driver can create a device object to represent the
device. KMDF continues calling the driver’s callback routines by
progressing up through the sequence until the device is operational.
Remember that KMDF invokes the event callbacks in bottom-up order as
shown in the figure, so EvtDeviceFilterRemoveResourceRequirements is called before EvtDeviceFilterAddResourceRequirements, and so forth.
If the device was stopped to rebalance resources or
was physically present but not in the working state, not all of the
steps are required as the figure shows.
2.2. Startup Sequence for a Physical Device Object
The following shows the callbacks for a bus driver
(PDO) that are involved in bringing a device to the fully operational
state, starting Device Inserted state at the bottom of the figure.
|
Device Operational
| Enable wake signal, if a wake request from the previous power-down is still pending | EvtDeviceEnableWakeAtBus | | Enable self-managed I/O, if driver supports it | EvtDeviceSelfManagedIoInit
or
EvtDeviceSelfManagedIoRestart | | Start power-managed queues | EvtIoResume (called only if EvtIoStop was called during power-down) | | Enable DMA, if driver supports it | EvtDmaEnablerSelfManagedIoStart
EvtDmaEnablerEnable
EvtDmaEnablerFill | | Connect interrupts | EvtDeviceDOEntryPostInterruptsEnabled EvtInterruptEnable | | Notify driver of state change | EvtDeviceDOEntry | | Disable wake signal, if it was | EvtDeviceDisableWakeAtBus (called only during power-up; not called during resource rebalance) |
Restart from here if device is in low-power state
| Prepare hardware for power | EvtDevicePrepareHardware |
Restart from here if rebalancing resources or if device remained physically present after logical removal
| Create device object | EvtDriverDeviceAdd | | Report resource requirements | EvtDeviceResourceRequirementsQuery EvtDeviceResourcesQuery | | Enumerate child devices | EvtChildListCreateDevice |
Device Inserted
|
KMDF
does not physically delete a PDO until the corresponding device is
physically removed from the system. For example, if a user disables the
device in Device Manager but does not physically remove it, KMDF retains
its device object. Thus, the three steps at the bottom of the preceding
example occur only during Plug and Play enumeration—that is, during
initial boot or when the user plugs in a new device.
If the device was previously disabled but not physically removed, KMDF starts by calling the EvtDevicePrepareHardware callback.
