by Why should Windows driver writers care about Connected Standby, and what do they need to know about it? That’s what we’ll tell you in this blog post.
What’s happens when you turn your cell phone off? The screen goes blank, but you can still receive email, text messages, and even notices from specific applications that you have running in the background, right? And you will probably hear audio announcements that alert you to these events. In other words, the phone is “off” but you still have some small amount of periodic application activity, you maintain connectivity to the Internet, and certain devices can briefly wake to perform some bits of required work. In addition, when you turn your phone back on the phone comes alive in just a fraction of a second (literally).
Connected Standby is the Windows power state that mimics the way cell phones behave when you turn them off. Microsoft has referred to this as the “always on, always connected” experience. Connected Standby also allows Windows systems to power on almost instantaneously. Who doesn’t love that?
Initially, Connected Standby was restricted to systems built using System On Chip (SOC) architectures. But that’s no longer the case. We can expect to see an increasing number of Windows systems, including both SOCs and full-scale CPUs, make use of Connected Standby and other similar ultra-low-power schemes. That’s why understanding this new state is important for driver writers.
The first thing to understand about Connected Standby is that it’s definitely not the kind of thing that you can retrofit into an existing system. Systems have to be designed to support Connected Standby from the start. Properly supporting connected standby requires coordination between IHVs, the system integrator, and the OEM. The overall design of the entire system is so vital that the two most important tips we can give to any driver writer working on a Connected Standby project are (1) Don’t try to support Connected Standby until you’re sure that the entire platform you’ll be supporting actually supports Connected Standby without your device, and (2) Be sure that you have good technical contacts with the hardware developers for your device as well as the BIOS engineers and systems integrators for the platform you’re supporting. Contacts at Microsoft would be very helpful as well.
Let’s explain a bit about how Connected Standby is implemented. In traditional Windows systems, when a system is not being actively used it can optionally transition to “Sleep” or “Hibernate” state. In ACPI terms, when the system is active it is in S0 (Working) state. When it sleeps it most typically enters S3 state. And when it hibernates the system enters S4 state. S5 state signifies that the system has been shut down and is “powered off.”
When a system supports Connected Standby, it only implements the S0 (Working) and S5 (Shutdown) states. When the system wants to enter a low power idle state, or the user presses the “power” button to put the system to sleep, the system enters Connected Standby instead of S3. While in Connected Standby, the system technically remains in S0 state, but the screen is turned off, most devices have their power and/or clock lines shut down, and the system lowers its power consumption to extremely low levels. In fact, in properly designed systems the amount of power used by a system while in Connected Standby can be as little as a third of that used by a conventional system sleeping in S3.
What do you need to do in your driver to support Connected Standby? For most devices, the answer is that whenever your device is not actively being used you will need to idle your device in its lowest possible power mode. This includes idling in D3Cold if that’s supported by your device. Modern, effective, power management basically turns our old approach to power management upside down: Instead of asking yourself “When is the right time to briefly put my device in a lower power state?” tell yourself “I want my device to live in its lowest possible power state all the time, except when it’s being actively used.” It’s a small difference in thought, but it can lead to a significant savings in terms of power.
There are devices, like network devices, that will require some power, at least some of the time, when the system is in Connected Standby. Therefore, specific actions you need to take for Connected Standby in your particular driver depend on the class of device that your driver will support. There are specific guidelines for the types of devices that can expect to be active (at least part of the time) or awaken while the system is in Connected Standby. These include drivers for devices ranging in type from network to audio to NFC. So, when writing a driver for a device that will live on a Connected Standby system, you’ll want to do is check the guidelines (and Windows Hardware Certification requirements) for your specific device class.
We can’t go into the details of how to support Connected Standby for every device class here. But we hope that we’ve at least introduced you to the idea of Connected Standby, and explained how it affects your approach to Windows driver development. In the coming months, you’ll see more and more systems support Connected Standby and other, similar, ultra-low-power schemes. Who wouldn’t want their laptop to remain responsive to network events, wake up almost instantly, and still use less battery than if it were put into classic sleep state? And, as Windows driver devs, we have an important role to play in implementing this functionality.
OSR Open Systems Resources, Inc.