Hardware White Paper
	
Microsoft® Windows® 2000 Operating Systems - Base Development
System State-to-Device State Mappings (SxD)
This paper describes the algorithms the ACPI driver provided with the Microsoft® Windows® 2000 operating system uses to calculate the state mappings associated with a system and its devices transitioning from the working state to a sleeping state. The S-state-to-D-state mappings show how _SxD objects can be used to eliminate ambiguity and to provide rules and recommendations to system/BIOS developers to ensure a system will function as designed. 
DRAFT Version 0.7a, June 9, 1999
Contents

Introduction	2
Example System Configurations	2
Device Power Management Objects	3
_SxD Device Power Management Objects	5
ACPI and WDM Drivers	6
Why Devices Cannot Influence SxD Mappings	14
Conclusion	15

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, 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.
© 1999 Microsoft Corporation. All rights reserved.

Introduction
When a system transitions from the working state (S0) to a sleeping state (S1-S4), all the devices in the system must transition to the appropriate device state (D0-D3). The system state-to-device state mappings for the individual devices and buses in the system are calculated by the Windows 2000 ACPI driver during initialization. 
These mappings are used and propagated throughout the system to allow devices to transition into the appropriate state whenever enabled, so that they will wake the computer. The S-state-to-D-state mappings at best can be cumbersome to calculate. Sometimes they are impossible to calculate accurately. To address this problem, the _SxD objects were created. These objects allow the ACPI driver to generate an explicit S-state-to-D-state mapping for any given sleeping state (represented by “x”), and help to eliminate erratic system behavior. 
The goal of this white-paper is to document the algorithms the Windows 2000 ACPI driver uses to calculate the S-state-to-D-state mappings, show how the _SxD objects can be used to eliminate ambiguity, and provide rules and recommendations to system/BIOS developers to ensure their systems work as designed This white paper requires a working knowledge of the current PCI Specification and the PCI Bus Power Management Interface Specification. Both of these specifications can be obtained from the PCI Special Interest Group home page at: http://www.pcisig.com/specs.html.
Example System Configurations
For the purposes of this white paper, all examples and discussion are based upon a standard ACPI desktop machine with an ACPI BIOS taken from the ACPI Good BIOS List (For more information on the ACPI Good BIOS List, see http://www.microsoft.com/hwdev/onnow/goodbios.htm.) The machine is PIIX4-based with an AGP graphics adapter and an ESS audio chip present and enabled on the motherboard. The system provides Vaux power to the PCI bus to support wakeup from D3Cold. This machine will be configured three distinct ways using slightly different PCI-compliant network interface cards (NICs). 
In the first configuration the PCI-compliant NIC is on the motherboard and supports PME# wakeup from both D3Hot and D3Cold states. 
In the second configuration the PCI-compliant NIC is inserted into one of the available PCI slots and still supports PME# wakeup from both D3Hot and D3Cold states. The third configuration uses a PCI-compliant NIC inserted into one of the available PCI slots but it only is capable of PME# wakeup from the D3Hot state. Please note that all three example configurations are mutually exclusive. There is no example featuring two NICs. 
•	System Configuration #1 - Standard PCI-compliant NIC (motherboard device) with PME# assert for both D3Hot and D3Cold.
•	System Configuration #2 - Standard PCI-compliant NIC (add-in card) with PME# assert for both D3Hot and D3Cold.
•	System Configuration #3 - Standard PCI-compliant NIC (add-in card) with support for PME# assertion for D3Hot only.
The simplified namespace for the machines is as follows:
System Namespace
Scope (\_SB)
	{
	Device (PCI0){

		Device (PCI1){
			Device (VGA){
				_PS0
				_PR0
				_PS1
				_PR1
				_PS3
			}
		}

	Device (USB0) { … }
	Device (NET0) { … }		// Note: Not Present for System Configurations 2 and 3
  
	Device (ISA0){
		Device (AUD0) {…}
		}
	} // Close PCI0
}
Device Power Management Objects
For any device that is power managed using ACPI, a Definition Block contains one or more of the objects found in the following table. 

Device Power Management Child Objects
Object	Description	
_IRC	Object that signifies the device has a significant inrush current draw.	
_PRW	Object that evaluates to the device’s power requirements in order to wake the system from a system sleeping state.	
_PR0	Object that evaluates to the device’s power requirements in the D0 device state (device fully on).	
_PR1	Object that evaluates to the device’s power requirements in the D1 device state. The only devices that supply this level are those which can achieve the defined D1 device state according to the related device class.	
_PR2	Object that evaluates to the device’s power requirements in the D2 device state. The only devices that supply this level are those which can achieve the defined D2 device state according to the related device class. 	
_PSC	Object that evaluates to the device’s current power state.	
_PSW	Control method that enables or disables the device’s WAKE function.	
_PS0	Control method that puts the device in the D0 device state (device fully on).	
_PS1	Control method that puts the device in the D1 device state.	
_PS2	Control method that puts the device in the D2 device state.	
_PS3	Control method that puts the device in the D3 device state (device off).	
_S0D	Highest D-State supported by the device in the S0 state	
_S1D	Highest D-State supported by the device in the S1 state	
_S2D	Highest D-State supported by the device in the S2 state	
_S3D	Highest D-State supported by the device in the S3 state	
_S4D	Highest D-State supported by the device in the S4 state	
_S5D	Highest D-State supported by the device in the S5 state	

Power management of a device is accomplished through two different means:
•	Power Resource control
•	Device-specific control
Power Resources are resources that can be shared among multiple devices. The operating system software will control these devices automatically by determining which particular Power Resources need to be in the ON state at any given time. The OS makes this determination by considering the state of all devices connected to a Power Resource.
For many devices, Power Resource control is all that is required. However, in some cases device objects may include their own device-specific control methods. If this is the case, both types of power management controls can be applied in combination or individually as required.
The following rules apply to device power management objects:
Rule #1: For devices that are not capable or not enabled for wakeup, the device will enter the D3 device state for all non-working S-states.

•	If a system does not have any wakeup-enabled devices other than the real-time clock, all devices will enter D3 when the system enters S1-S5. 

Rule #2: For a given S-State, a device cannot be in a higher D-State than its parent device. 

•	For example: for the System Configuration #1 example described earlier, the NIC cannot be in a higher D-state (D2) than the PCI bus (D3).

Rule #3: Mixing _PRx and _PSx objects

a)	_PRx objects may be used independently of _PSx objects to describe a device’s power management requirements in a given “x” state.  _PR0 must be present if any _PRx methods are used.
b)	_PSx objects can be used independently of _PRx objects for device-specific control. However, if _PS0 is present, a corresponding _PS3 must also be present. 
c)	If _PRx and _PSx objects are both used to describe the power capabilities of a device they must be paired. Failure to pair the two objects makes it extremely difficult for the ACPI driver to determine which _PSx method to run after evaluating the _PRx object. 
d)	 _PRW is required if the device can wake the system. However, the corresponding  _PSW is optional, but not required to enable/disable the device’s wake capabilities. 

Rule #4: If ACPI is responsible for power management of a given device, the BIOS must provide either _PRx or _PSx objects to place the device in D0 and D3. 

Valid
Matching 
 _PS0 and  _PR0.

 _PRW defined but  _PSW not required	Valid
Matching 
_PSx - _PRx, 

 _PRW  optional  _PSW defined	Invalid
Missing
_PS1 for _PR1 object.	Invalid
Missing _PS3	Invalid
Missing _PR0	
Device (Net0)
  {
     _PRW

     _PS0       
     _PS3       
     
     _PR0      
  }
	Device (Net1)
  {
     _PRW
     _PSW

     _PS0
     _PS1
     _PS2        
     _PS3
     
     _PR0
     _PR1
     _PR2
  }	Device (Net2)
  {
     _PRW
     _PS0
     _PS3

     _PR0
     _PR1
  }
	Device (Net3)
  {
     _PRW
     _PSW

     _PS0
     _PS1
  }
	Device (Net3)
  {
     _PRW
     _PSW
     
     _PS1
     _PR1

     _PS3
  }

_SxD Device Power Management Objects
For systems that do not control device power states through power plane management, but whose devices support multiple D-states, more information is required by the operating system to determine the S-state to D-state mapping for the device. The ACPI BIOS can give this information to the operating system using the _SxD objects. These objects tell the OS the highest D-state supported by a device for any given S-state. The OS is allowed to pick a lower D-state for a given S-state, but cannot exceed the highest D-state defined by the _SxD objects. 
The _SxD objects all evaluate to an integer that corresponds to the highest D-state supported in the given S-State. For example, S1D returns the highest D-state supported in S1. 
The SxD mappings are explicit and override the _PRx and the _PSx objects. The _PRx objects and _PSx control methods are still evaluated when transitioning to the appropriate D-state but are not considered when calculating the S-state-to-D-state mappings if SxD is present. 
Rule #5: Although the _SxD objects are optional, they are required if enhanced system capabilities, such as wake from D3Hot, are desired.

ACPI and WDM Drivers
In order to understand when and where to use the various objects and control methods, an understanding of how the ACPI driver calculates the S-state-to-D-state mappings is needed. 
Definitions
Familiarity with the following structures, fields, objects, and control methods is essential to understanding the ACPI driver’s role in producing the SxD mappings.
System Capabilities Structure. During initialization, each driver in the system is provided a structure that describes the system capabilities for the device. This structure contains device information for Plug and Play and for power management. The details of this structure are filled in by the ACPI and bus drivers during device initialization.
Device Capabilities Structure. The DEVICE_CAPABILITIES structure contains a number of fields which represent the supported device and wakeup states. For a detailed outline of the structure refer to the section below.
DeviceD1 and DeviceD2 Fields. These fields indicate that the device supports the D1 and/or D2 device states. Please note that support for the D0 and D3 device states is required and therefore assumed. This highlights another rule of device power management objects: 

Rule #6: Devices must support D0 and D3

WakeFromDx Fields. These fields indicate that the device supports wakeup from the given Dx state. 
DeviceState[S0-S5] Objects. These objects  map the system state to the highest device state support for the device. For example: DeviceState[S1] returns the highest D-state the device can be in when in system state S1. The calculation of these mappings are the focus of this paper.
If DeviceState[S1] = D1 then the device must be in either D1, D2, or D3 when the system enters S1.
SystemWake. This value indicates the lowest sleeping state the machine can enter in order for the device to wakeup the system. 
If SystemWake=S3 then the system can be waked  from either S0, S1, S2 or S3 system states.
DeviceWake. This value indicates the highest device state that the device can enter in order for the device to wakeup the system. 
If DeviceWake=D2 then this device can wake the system from either D0, D1, or D2.
Device Capabilities Structure (Detail)
The structure is as follows:
typedef struct _DEVICE_CAPABILITIES {
    USHORT Size;
    USHORT Version; 			// Version 1.0
    ULONG DeviceD1:1;			// Device supports the D1 State
    ULONG DeviceD2:1;			// Device supports the D2 state
    ULONG 1:1;
    ULONG EjectSupported:1;
    ULONG Removable:1;
    ULONG DockDevice:1;
    ULONG UniqueID:1;
    ULONG SilentInstall:1;
    ULONG RawDeviceOK:1;
    ULONG SurpriseRemovalOK:1;
    ULONG WakeFromD0:1;		// Device can wake from D0
    ULONG WakeFromD1:1;		// Device can wake from D1
    ULONG WakeFromD2:1;		// Device can wake from D2
    ULONG WakeFromD3:1;		// Device can wake from D3
    ULONG HardwareDisabled:1;
    ULONG NonDynamic:1;
    ULONG Reserved:16;

    ULONG Address;
    ULONG UINumber;

    DEVICE_POWER_STATE DeviceState[PowerSystemMaximum];
    SYSTEM_POWER_STATE SystemWake;
    DEVICE_POWER_STATE DeviceWake;
    ULONG D1Latency;
    ULONG D2Latency;
    ULONG D3Latency;
}  DEVICE_CAPABILITIES, *PDEVICE_CAPABILITIES;

Calculating S-state-to-D-state Mappings
The ACPI driver is responsible for calculating the initial mappings used by the system. These mappings are then propagated throughout the system as the devices are enumerated. These mappings are then used by the WDM drivers to accept or veto standby requests. Because the ACPI driver enumerates the primary buses in the system the mappings must be correct. If the proper mapping information is not supplied in the BIOS the ACPI driver will default to D3 (off) for all non-working system states (S1-S5). 
Note: These default mappings are static and cannot be changed as a result of subsequent device information during enumeration. 
These default mappings may prevent devices that were designed to wakeup the system from doing so. For purposes of simplicity, the enumeration of the PCI bus is used in all examples in this white paper.
When the PCI root bus is found, the ACPI driver needs to determine the default mappings. The ACPI driver begins searching for the SxD mappings—if provided—and then the Power Requirements (_PRx). The _SxD objects provide a simple solution and can be easily implemented to specify the S-state-to-D-state mappings. The _PRx objects conversely are very complex, and most systems therefore do not include the Power Requirement information. If SxD or _PRx are not provided, then it is assumed that all non-working states (S1-S5) map to D3. 
The ACPI driver performs the following steps during initialization:

1.	Check to see if SxD is present. For each specified system state the S-state-to-D-state mappings are complete. For example:

Device (PCI0) { 
_PRW { … }
_PSW { … }

Method (_S1D, 0) {		// S1 => D1
Return (1)
}

Method (_S3D, 0) {		// S3 => D1
Return (1)
}

_PS0 { … }
_PS1 { … } 
_PS3 { … }

Device (Net0) { … }
}

2.	If the SxD mappings are not provided then the ACPI driver examines the _PRx objects to determine the power requirement for the PCI bus in D0-D3. Most systems do not implement power plane information due the complexity and cost involved. SxD provides a lower cost solution and should be used if _PRx methods are not implemented. Assume the power requirements for D0 and D1 are provided:

Device (PCI0) { 
_PRW { … }
_PSW { … }

_PR0 { … }
_PR1 { … }

_PS0 { … }
_PS1 { … }
_PS3 { … }

 Device (Net0) { … }
}
The Power Requirements provide a pointer in the namespace which, when evaluated, provides the power plane information. The power plane information defines that the resource can be ON in a given S-State. For example if _PR0 evaluates to S0, this indicates that the power plane is ON for S0 and is OFF for all other S-states. Assume the PCI bus has the following power requirements for D0 and D1.

	Power Plane 0	Power Plane 1	
_PR0	S0		
_PR1		S3	
Given this mapping, the ACPI driver begins filling in the S-state-to-D-state mappings. The algorithm is as follows:

For S0 to S5 Do
    For D0 to D3 Do
        If  Device Does not Support D-State		// If the Dx state is not valid
            Continue;							// then continue

        Evaluate _PRx for given D-state			// Determine if power plane is on 
												// for given D-State

        If  D-State not supported in S-State		// If the Sx state is not valid for
            Continue;							// the given, then continue

        S-State => D-State
            Break;
    End For
End For

Following this algorithm leads to the following:

For S0
  S0 => D0
End For
        	For S1
  For D0
    Does the PCI Bus support D0? YES
    Evaluate _PR0: S0
    Is Power Plane on in S1: NO
        Continue

  For D1
    Does the PCI Bus support D1? YES
    Evaluate _PR1: S1
    Is Power Plane on in S1: YES
    
    S1 =>D1
        Break;

  End For
End For	For S2
  System State S2 not supported
  S2 => Undefined
End For	

For S3
  For D0
    Does the PCI Bus support D0? YES
    Evaluate _PR0: S0
    Is Power Plane on in S3: NO
        Continue;

  For D1
    Does the PCI Bus support D1? YES
    Evaluate _PR1: S1
    Is Power Plane on in S3: YES
        Continue;

    S3 =>D1
        Break;

  End For
End For	For S4
  For D0
    Does the PCI Bus support D0? YES
    Evaluate _PR0: S0
    Is Power Plane on in S4: NO
        Continue;

  For D1
    Does the PCI Bus support D1? YES
    Evaluate _PR1: S1
    Is Power Plane on in S4: NO
        Continue;
  
  For D2
    Does the PCI Bus support D2? NO
        Continue;

  For D3
    S4 => D3
        Break;

  End For
End For	For S5
  S5 => D3
End For	

3.	Next the ACPI driver evaluates the _PRW for the PCI bus to determine if the PCI bus supports wakeup and, if so, from what S-states. __PRW must be present if the PCI bus supports wakeup events. If  _PRW is present then this object provides the lowest power system state that can be entered while still providing wake functionality. For example:

If _PRW contains S1 then, the PCI bus can wake the system from S0 or S1.

4.	The PCI mappings are almost complete. The last step in the process is to verify that the S-state-to-D-state mappings are valid. If the _PSx methods are provided then the ACPI driver uses this information to verify the mappings. If the _PSx methods are not provided then the mappings are assumed to be correct. Again, assume _PSx methods are provided. For example:

If the device state mapping for S3 => D1 then the ACPI driver must check that the _PS2 method is provided. Since _PS1 is provided, the mapping is correct. If _PS1 and _PR1 were not provided then the ACPI driver would promote the device to the next valid and deepest D-State or D3. 
5.	If the following namespace is assumed:
Device (PCI0) { 
_PRW {S3 }
_PSW { … }

Method (_S1D, 0) {		// S1 => D1
Return (1)
}

Method (_S3D, 0) {		// S3 => D1
Return (1)
}

_PS0 { … }
_PS1 { … } 
_PS2 { … }
_PS3 { … }

Device (Net0) { … }
}

Then the DEVICE_CAPABILITIES for Power Management for the PCI bus would be:
DeviceD1 = 1;				// PCI Bus supports D1
DeviceD2 = 0;				// PCI Bus does not support D2
DeviceState[S0] = D0;		// PCI Bus is in D0-D3 when system is in S0
DeviceState[S1] = D1;		// PCI Bus is in D1-D3 when system is in S1
DeviceState[S2] = Undefined;	// System does not support S2. 
DeviceState[S3] = D1;		// PCI Bus is in D1-D3 when system is in S3
DeviceState[S4] = D3;		// PCI Bus is in D3 when system is in S4
DeviceState[S5] = D3;		// PCI Bus is in D3 when system is in S5
SystemWake = S3;				// System can wake from S0-S3
DeviceWake = D1;				// PCI Bus can wake system from D0 or D1

How PCI and ACPI work together to calculate the capabilities for NET0
Once ACPI is finished enumerating the PCI bus the cycle of enumeration continues. The PCI bus next enumerates any child devices and the device capabilities must again be determined. As mentioned earlier, the original mappings created by the ACPI driver are propagated throughout the system as new devices are found. At this point, only small changes can be made to the DEVICE_CAPABILITIES because of the restriction from rule #2, which states:

Rule #2: For a given S-State, a device cannot be in a higher D-State than its parent device. 
Therefore, whatever changes may be necessary must always be towards a lower device state than that of the parent. For example if the PCI bus maps DeviceState[S3] => D1 then the device NET0 must either keep this mapping or change it to D2 or D3. If the NIC does not support D2, then the only alternative is to map DeviceState[S3] => D3. 
The S-state-to-D-state mappings for the PCI NIC (Intel Pro 100B – e100b.sys) are determined as follows:
1.	The drivers (Pci.sys, E100b.sys) retrieve the parent’s capabilities from the PCI bus, which were calculated above: 

DeviceD1 = 1;			// PCI Bus supports D1
DeviceD2 = 0;			// PCI Bus supports D2

DeviceState[S0] = D0;		// PCI Bus is in D0-D3 when the system is in S0
DeviceState[S1] = D1;		// PCI Bus is in D1-D3 when the system is in S1
DeviceState[S2] = Undef;		// Unsupported System State
DeviceState[S3] = D1;		// PCI Bus is in D3 when the system is in S3
DeviceState[S4] = D3;		// PCI Bus is in D3 when the system is in S4
DeviceState[S5] = D3;		// PCI Bus is in D3 when the system is in S5

SystemWake = S3;		// PCI Bus can wake the system from S0, S1 or S3
DeviceWake = D1;		// PCI Bus can assert PME# if the device is in D0 or D1

2.	Next the driver checks to see if the PCI Power Management Capabilities are present in PCI configuration space for the NIC. Although the presence of the capabilities are not required by PCI, they are used if present and their use is strongly encouraged. Assume that the power capabilities are provided and are as follows:

Supported D-States	D0, D2, D3	
PME# can be asserted from:	D0, D2, D3Hot, D3Cold	

Rule #7: Devices should supply Power Management Capabilities as defined by the appropriate bus specification. 
3.	Now the driver must merge the parent capabilities with the capabilities of the device itself. Given the example data a few inconsistencies exist. 
•	The NIC does not support D1 but does support D2. Therefore, DeviceD1 and DeviceD2 need to be set appropriately. 
DeviceD1 = 0;
DeviceD2 = 1;
•	The second change that is needed is the mapping for DeviceState[S1 and S3]. Since the NIC does not support D1 the mappings needs to be modified to the next lowest support device state => D2. 
DeviceState[S1] = D1  =>  DeviceState[S1] = D2
DeviceState[S3] = D1  =>  DeviceState[S3] = D2
4.	Now the driver must try and decide the appropriate DeviceWake and SystemWake settings for the NIC. The parent’s capabilities indicate that SystemWake = S3. Since the NIC maps S3 => D2, and we can wake the system from D2, therefore:
SystemWake = S3;		// NIC can wake system from S0, S1 or S3
DeviceWake = D2;		// NIC can wake system from Device States D2

Although the NIC can wake the machine from a lower device state, DeviceWake is set to the highest D-State possible for the S-state
5.	The driver is now finished and presents the following capabilities to the ACPI filter driver:
DeviceD1 = 0;				// NIC does not support D1
DeviceD2 = 1;				// NIC does support D2

DeviceState[S0] = D0;		// NIC is in D0-D3 when the system is in S0
DeviceState[S1] = D2;		// NIC is in D2-D3 when the system is in S1
DeviceState[S2] = undefined;	// Undefined System State
DeviceState[S3] = D2;		// NIC is in D2-D3 when the system is in S3
DeviceState[S4] = D3;		// NIC is in D3 when the system is in S4
DeviceState[S5] = D3;		// NIC is in D3 when the system is in S5

SystemWake = S3;		// NIC can wake the system from system states //S0, S1 or S3
DeviceWake = D2;				// NIC can assert PME# if the device is in D2. 

The ACPI driver now looks to see what methods are present to ensure that the correct mappings are present. The ACPI driver first checks to see if any SxD mappings are specified which give an explicit override. One mapping that might be given by the BIOS for the net adapter is to have the device go into D3 when the system enters S3.
Device (NET0) {
    Method (S3D) {
        return (3)
    }
}

If _SxD mappings are not specified then _PRx objects are evaluated. Again, the same algorithms are used to determine the S-state-to-D-state mappings. However, in this instance the ACPI driver will use the defaults provided and will not automatically assign D3 if SxD or _PRx is not provided. 

6.	If the NIC is not defined in the BIOS, or plugs into one of the available PCI-slots, then the ACPI driver does not participate and the mappings are complete. 

Supporting PCI D3Hot
One of the major reasons for adding _SxD mappings is for the support of D3Hot. D3Hot, as defined by the PCI Bus Power Management Interface Specification, is the state in which the PCI card is capable of asserting PME# from D3 without supplying Vaux current. The requirement is that the PCI bus remain powered in order for the PME# signal to be asserted.

For example, assume the following namespace for the example System Configuration #3, in which the NIC is inserted into one of the available PCI-slots and is capable of asserting PME# from D0, D2 or D3Hot: 

System Namespace
  Scope (\_SB)
      {
Device (PCI0){
    	_PRW { …, S0, … }

	Device (PCI1){
         	    Device (VGA){ … } 
          }

  Device (USB0) { … }

  Device (ISA0){
            Device (AUD0) {…}
  }
} // Close PCI0
      }

Given this namespace the NIC will be unable to wake the machine. Why?
1.	The ACPI driver during initialization will not find any _SxD or _PRx objects and will default to D3 for all non-working system states (S1-S5)
2.	_PRW is defined for the PCI bus and therefore SystemWake = S0
3.	The NIC can enter D3 and signal a wakeup event but only from S0 (that is, the NIC can enter D3 when carrier-sense is lost and generate a wakeup event when the cable is plugged back in). 

In order for the NIC to wake the machine from D3, the following changes must be made:
1.	Supply a _PRW for PCI0 according to the capabilities of the machine. If the machine is capable of keeping the PCI bus powered in S1 then the _PRW should be specified in the namespace. 
2.	Supply a S1D method which will keep the PCI bus in a powered state in accordance with the capabilities of the machine. 
Method (_S1D, 0) {		// S1 => D2
    Return (2)
}

The namespace now appears as:
System Namespace
  Scope (\_SB)
      {
Device (PCI0){
  _PRW { …, S1, … }

  Method (_S1D, 0) {
    return (2)
  }

	Device (PCI1){
             Device (VGA){ … } 
	}
  
  Device (USB0} { … }

  Device (ISA0){
            Device (AUD0) {…}
  }
} // Close PCI0
      }

Supporting PCI D3Cold
The presence of the _SxD objects does not limit the PCI bus from entering B3/D3. A device (or bus) can always transition to a lower device state based on the capabilities of the system. Another way is if none of the child devices enumerated by PCI are enabled for wakeup or require the PCI bus to remain powered to wake the system. Given the above namespace in which _S1D => D2, the PCI driver can enter D3 if the wakeup-enabled device supports D3cold. 

If a PCI device supports D3cold then it also must be capable of asserting PME# from D3Hot. 
Why Devices Cannot Influence SxD Mappings
The PCI Bus Power Management specification defines within which D-states a device can assert PME#. However, the ACPI driver cannot use these for the initial mapping of the PCI bus. There are two reasons for this:

1.	The PCI device does not provide information about which S-state the machine can be in to wake the system. It only reports that it can assert PME# from the given D-states. If a PCI device supports PME# assert from D0, D1, and D3, there is no information that tells the OS that S1 => D1. It could be argued that the _PRW could supply this information but again, the mappings are static and calculated at boot only. By the time the PCI devices are enumerated, the ACPI driver has already assigned S1 => D3 for the PCI bus.

2.	The S-state-to-D-state mappings are calculated at boot-up time only. They are static and can not be changed as a result of subsequent device information as the machine is enumerated. For some systems the device information may be included on the other side of a PCI-PCI bridge that has not yet been configured (for example, as in a docking system). In such cases, the S-state-to-D-state mappings have long since been set and, due to complexity, cannot be changed. 

Conclusion
The rules and recommendation made in this white paper are intended to enable systems to provide consistent and reliable operation under Windows 2000. The SxD method provides an economic and straightforward implementation in order for the ACPI driver to accurately and deterministically choose the correct mappings during initialization.
History
June 9, 1999 update=insert new copyright/disclaimer text