|
Building S4OS Hibernate-Capable PCs for Windows Me —
Windows Platform Design Notes
Designing Hardware for the Microsoft Windows Family of Operating Systems
Building S4OS Hibernate-Capable PCs for Windows Me
Abstract: This paper summarizes research and recommendations for building great Hibernate-capable PCs running the Microsoft® Windows® Millennium Edition (Windows Me) operating system, where hibernation is controlled by the operating system.
March 31, 2000
Contents
Windows Me Support for S4OS Hibernate 2
WDM Audio Drivers (VxD audio not supported) 4
Power Management Guidelines for Audio 4
Power Interfaces for Audio Drivers 4
WDM Net and Modem Drivers 7
Power Management Guidelines for Net and Modem 7
Network/Modem Device Power States 8
Power Interfaces for Net Drivers 10
Display Drivers 13
Power Management Guidelines for Graphics Adapters 13
Power Interfaces for Windows Me Display Adapter Drivers 14
Windows Me Hibernate Testing 19
Tools for Testing Windows Me S4OS Hibernation 19
What to Test for S4OS Hibernate Support 20
Important Test Information 21
Troubleshooting S4OS Hibernate and Standby Issues 21
Windows Me Support for S3 Sleep State 23
Disclaimer: The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to the patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.
Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not apply to you.
Microsoft, WebTV, Win32, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.
© 2000 Microsoft Corporation. All rights reserved.
Windows Me Support for S4OS Hibernate
In response to end-user feedback requesting more quickly available PC's, Windows Millennium Edition has built in support for hibernation (OS-controlled ACPI S4 sleep state). Hibernation saves the complete state of the PC and removes power. The PC will appear to be totally off. This is the lowest power sleeping state available and is secure from power outages.
When the end-user resumes from a hibernated sleep state, the BIOS will go through the normal POST and then read the hiberfile that was previously created to save the PC's state. The PC will then resume right to the very state it was in when the user previously entered hibernation.
By using hibernate, the end-user will have a reduced startup time AND will not have to start applications, open files, or navigate to the pages they were editing or reading in files. In real start up time, hibernation could save several minutes of productivity time versus the traditional cold start approach.
It is important to note that for servicing the PC, the end-user should use the shutdown, not the hibernation option.
Windows Me supports Hibernate capabilities (ACPI S4 sleep state). Windows Me S4OS Hibernate is available on new PCs and upgrades that meet the requirements for the correct display drivers and no VXD audio drivers, as described in this article.
Information in this section was published in the 2/99 edition of the Microsoft Hardware Newsletter.
This section provides some background details and testing issues for OEMs who are implementing S4OS Hibernate on Windows Me platforms.
Hibernate Implementation Details. Windows Me uses the software mechanism S4OS to enter the S4 (Hibernate) sleep state. When transitioning to the S4 sleep state, Windows Me will first try to use the SLP_TYP values from the \_S4 package. If the \_S4 object is not present in the ACPI Name Space, Windows Me will use the SLP_TYP values from the \_S5 package. This is done to provide support for hibernation (S4OS) on as many machines as possible. This is only supported on ACPI systems.
When transitioning to the S5 state, Windows Me clears all wakeup enable registers (PM1x_EVT and GPEx_EN – ACPI Sections 4.7.2.4 and 7.5.2.6). To provide wake functionality from the S4 sleep state, the ACPI namespace must contain the \_S4 package.
Additional S4 Information. To remove S4BIOS support and retain S4OS support, BIOS developers can implement the following items, as required in the ACPI 1.0b specification (available from http://www.teleport.com/~acpi/) to support the S4 sleep state:
FACS flag S4BIOS_F must be set to 0 (Section 5.2.6, Table 5-8) to remove S4BIOS support.
ACPI Name Space must contain the \_S4 package.
FACP Flag – RTC_S4 must be set to 1 (Section 5.2.5, Table 5-6) t support RTC wake from the S4 sleep state.
In addition to setting the RTC_S4 flag, the system must also have the \_S4 package to fully support RTC wake from S4.
Requirements for Windows ME S4OS Hibernate support:
Audio supported with WDM audio drivers
WDM modem drivers; power management-capable network device driver
No SCSI controller
No legacy video-capture devices connected to the system
WebTV® for Windows is not installed
ICS server is not enabled
S4OS Hibernate Availability Logic
User sees the S4OS Hibernate option only when correct, supported drivers are found on new OEM systems.
If a device causes the resume to fail two times, the S4OS Hibernate option disappears.
If the system fails to resume two times, we ask whether the user wants the power management option disabled.
If the failing device or driver is removed, the S4OS Hibernate returns.
The Hibernation Shutdown option returns.
Windows Me Help and troubleshooters provide basic support.
A good S3 implementation directly effects Hibernation in Windows Me.
S4BIOS Support
Windows Me includes support for BIOS support for S4 (S4BIOS) in addition to operating system support for S4 (S4OS).
S4OS will deliver better performance, reliability, and ultimately should get your company’s products to market faster as you develop multiple platforms. If the S4OS requirements are met, S4OS will be used.
S4BIOS is targeted for the current installed base of notebooks, while new shipments should leverage S4OS.
For S4BIOS, the BIOS must support the _S4 object, S4BIOS_F in the FACS, the S4BIOS_REQ, plus whatever mechanism is used to implement the hibernation file, whether that is a special file or a special partition on the hard disk.
If these are present, then the operating system will display the Hibernation tab in the Power Options control panel. (Note that the operating system does not check for the actual presence of the special partition.)
WDM Audio Drivers (VxD audio not supported) Power Management Guidelines for Audio
The following summarizes the power management requirements for audio components.
From the PC 99 Design Guide:
17.28 System and devices comply with PCI bus power management Specification
Required
PCI-based audio controllers and add-on devices must comply with the PCI Bus Power Management Specification, Revision 1.0 or later (PCI PM). Audio devices implemented on the system board must comply fully with the ACPI 1.0 specification.
This specification is available at http://www.microsoft.com/hwdev/specs/PMref/PMaudio.htm.
17.31 Audio Drivers meet PC 99 requirements for WDM driver support
Required
All audio devices must have drivers that use the WDM architecture exclusively. The manufacturer can either supply a WDM driver with the audio device or rely on a WDM driver provided with Windows. WDM drivers should expect to see the same Power Management messages for Windows 2000 or Windows Me.
Power Interfaces for Audio Drivers From the Windows 2000 DDK (published December 1999), under section 4.2 of Kernel Streaming. IAdapterPowerManagement
Power management of the WDM audio adapter is accomplished primarily through the IAdapterPowerManagement interface that the adapter driver registers with PortCls during the StartDevice phase of device initialization. Registration is accomplished through the PcRegisterAdapterPowerManagement routine exported for this purpose by PortCls.
The IAdapterPowerManagement interface consists of three methods that Port Class Library uses to facilitate device power management. These methods are described below.
IAdapterPowerManagement::PowerChangeState
NTSTATUS
PowerChangeState)(
IN POWER_STATE NewState
);
PowerChangeState requests the device change to the new power state. PowerChangeState is called by PortCls in response to an IRP_MN_SET_POWER power IRP. It is a call that should not fail. It is used by PortCls and the system to place the device in the desired power state. Since the system attempts to suspend active audio streams, the driver must be capable of saving and restoring its context appropriately.
To assist the driver, PortCls will pause any active audio streams prior to calling this method to place the device in a sleep state. After calling this method, PortCls will unpause active audio streams to wake the device. Miniports can opt for additional notification by utilizing the IPowerNotify interface.
Parameters
NewState
The requested new power state for the device. The new power state (NewStateQuery.DeviceState) may be one of four values, as follows.
PowerDeviceD0
Full power state (D0). This code may be a function of the current power state. Save the new state. This local value is used to determine when to cache property accesses and when to permit the driver from accessing the hardware.
PowerDeviceD1
The sleep state having the lowest latency with respect to the latency time required to return to D0
PowerDeviceD2
A medium latency sleep state. In this state the device driver cannot assume that it can touch the hardware so any accesses need to be cached and the hardware restored upon entering D
PowerDeviceD3
A full hibernation state and is the longest latency sleep state. The driver cannot access the hardware in this state and must cache any hardware accesses and restore the hardware upon returning to D0 or D1
Return Value
Returns STATUS_SUCCESS or an appropriate error code.
IAdapterPowerManagement::QueryDeviceCapabilities
NTSTATUS
QueryDeviceCapabilities)(
IN PDEVICE_CAPABILITIES PowerDeviceCaps
);
The QueryDeviceCapabilities method is called by PortCls in response to a PnP IRP_MN_QUERY_CAPABILITIES IRP. This method passes to the WDM driver a capabilities structure that defines the mappings between system power states and device power states.
Parameters
PowerDeviceCaps
The device's capabilities.
Return Value
Returns STATUS_SUCCESS or an appropriate error code.
Comments
Values for each mapping are filled in when the structure is passed with the method call. Typically, the adapter driver should not change these settings. If the adapter driver must override the defaults, it can change the mappings to a deeper (less-powered) device power state but not to a weaker (more-powered) device power state. For example, the mappings for S1 (PowerSystemSleeping1) can be changed from D1 to D3, but not to D0.
In order to fill in the PowerDeviceCaps for a device, the miniport must register the interface portclass in or before the AddDevice function. The operating system queries devices before StartDevice is called. In order to change the mappings between system power states and device power states, the adapter driver changes the PowerDeviceCaps.DeviceState array. These mappings should be changed only if required. The following sample shows how to map D1 mappings to D3:
for (ii=ULONG(PowerSystemWorking); i<=ULONG(PowerSystemShutdown); i++ )
{
if (PowerDeviceCaps->DeviceState[i] == PowerDeviceD1)
{
PowerDeviceCaps->DeviceState[i] = PowerDeviceD3;
}
}
IAdapterPowerManagement::QueryPowerChangeState
NTSTATUS
QueryPowerChangeState)(
IN POWER_STATE NewStateQuery
)
The QueryPowerChangeState method is called by PortCls in response to the receipt of an IRP_MN_QUERY_POWER power IRP. This call is used by PortCls and the system to query for acceptability of a potential device power state change. The driver can deny the power state change by returning a value other than STATUS_SUCCESS .A call to QueryPowerStateChange is not guaranteed to occur prior to all PowerChangeState calls.
Parameters
NewStateQuery
The requested, new power state for the device.
Return Value
Returns STATUS_SUCCESS or an appropriate error code
IPowerNotify
The IPowerNotify interface is an optional interface that miniports can expose if they desire explicit notification of power state changes. The interface provides a single method (or callback) that is called by the miniport's corresponding port driver in response to a power state change.
Using wave audio as an example, when the device is requested to go to a sleep state the port driver pauses any active streams and then calls the power notify callback to inform the miniport of the impending power down. The miniport then has an opportunity to save any necessary context before the adapter's PowerChangeState method is called.
The process is reversed when the device is powering up. PortCls first calls the adapter's PowerChangeState method to power up the adapter. The port driver then calls the miniport's callback to allow the miniport to restore its context. Finally, the port driver unpauses any previously paused active audio streams.
IPowerNotify::PowerChangeNotify
NTSTATUS
PowerChangeNotify(
IN POWER_STATE PowerState
);
Parameters
PowerState
Current power state.
Return Value
Returns STATUS_SUCCESS if successful. Otherwise, returns an appropriate error code.
| 