Fast resume, which was introduced in Windows XP, is often mentioned when implementing power support in your WDM driver. But what does "fast resume" mean and when implementing fast resume, what side effects occur in your driver? I'll to answer both of these questions as well as the reasoning behind this feature. When I started to write this entry, I tried to look up fast resume in the WDK and found absolutely nothing! I was shocked since this is a very common term (at least internally at Microsoft); after speaking with the power team, there is a white paper that describes fast resume but you would never know it from the title "Measuring System Resume Performance on Windows Vista."
First, let's go over how to handle IRP_MN_SET_POWER/SystemPowerState for PowerSystemWorking (aka S0) IRP. You are supposed to pend the S0 irp and subsequently complete the S0 irp after you have requested a IRP_MN_SET_POWER/DevicePowerState PowerDeviceD0 IRP and it has been processed by the entire stack (which means you must register a Po completion routine which is where you complete the S0 IRP). In short, this means that the S0 IRP is pended in your driver as long as it takes for your device to power up. The definition of fast resume is simply that instead of pending the S0 IRP until the D0 IRP completes, you do not pend the S0 IRP and let it complete before the D0 IRP has been processed in your stack.
Sounds simple, right? Well, the devil is in the details. Here are a couple of issues with fast resume that I have encountered:
So given these issues, why would you even want to implement fast resume? The answer lies in the history of fast resume, or rather, Windows 2000 which did not have this feature. Resume times on Windows 2000 laptops was not great. There were a causes for the poor resume time, but a large contributor was device resume time. Since the OS serialized S0 IRPs to all devices in the PnP tree, the time for each device to resume added sequentially to the system's resume time. The OS serialization of the S0 IRPs could not change for Windows XP, so the problem was attacked at the other end...each driver would complete the S0 IRP as fast as it could so the OS could resume quickly and then asynchronously power up the device. This way each device could power up in parallel and the total time to power up was not sequential (nor was it only the longest of any device to power up since there is still ordering between parent and child devices) and resume time could be dramatically slower.
Given the perceivable value you are giving to the user by implementing fast resume, I recommend that you implement it in your (non bus) function driver and handle the new races between PnP state changing IRPs and power IRPs (which if you implemented idle during S0, must also be accounted for already. Considering the complicated aspects of asynchronously managing a parent's power state and a child's power state, I would not recommend that you implement fast resume in a bus driver. This follows the recommendations in the aforementioned white paper.
Obligatory KMDF plug: KMDF automatically implements fast resume for you and handles both issues behind the scenes. You will not process a pnp state changing irp while power up (or down) and if you are a bus driver, you will get an implementation which maintains the parent/child relationship with respect to power state.