PCI Device Subsystem IDs for Windows
On This Page
Specifications and Requirements for Use of PCI IDs with Windows Operating Systems
Specification for Use of PCI IDs with Windows Operating Systems describes how PCI device identifiers are used in Microsoft Windows operating systems and defines the rules associated with assigning IDs for plug-in cards, motherboard implementations, and chipset integrations.
INF Requirements for PCI Devices describes the criteria for submitting a standard/base driver set to WHQL for testing.
FAQ for Windows Logo Program
"Specification for Use of PCI IDs with Windows Operating Systems" replaces all previous FAQs for Windows Logo Program requirements. Although this specification was last revised in 2001, this technical content remains correct for Windows compatibility, and remains a Windows Logo Program requirement.
SVIDs and Windows Logo Testing
Testing for the Microsoft Windows logo program verifies that the SID and SVID registers are populated with valid, non-zero values before the operating system starts its enumeration process. Under the Microsoft Windows logo program, this verification has been required for subsystems on system boards that contain PCI devices since July 1, 1997. It has been required for PCI add-on boards since January 1, 1998.
Tips for SID Implementation
| • | Windows 95 and OSR 2.0 support SID values. However, one problem is that these two versions of Windows 95 do not rank the hardware IDs. For example, VEN, DEV has the same priority as VEN, DEV, SID, and REV. The search stops at the first match and does not try to find a better (more complete) match. As a result, the only way to get SID to work in Windows 95 is to:
| ||||
| • | Windows 98 adds compatible IDs to the registry. Windows 98 creates VEN/DEV and VEN/DEV/REV Compatible IDs in the device's Enum\PCI registry key if the hardware has a valid SID value. Then, if the INF specifies just VEN/DEV and the hardware has a valid SID value loaded, the user will be prompted to insert a disk or browse for a better driver--one that matches the SID. | ||||
| • | Setup routines must maintain SVID/SID integrity. Special care must be taken with "standalone" setup routines to insure that the integrity of the SVID/SID installation is maintained. Specifically, the setup application must only install the components that are appropriate to the configuration. The setup routine cannot install different driver components and features than the INF installs. The setup routine can install applications and utilities, but not control panel features, that are not installed by the INF. | ||||
| • | CAUTION: Do not rely on using the PCI Configuration Space Revision ID register value to indicate a unique PCI device ID in conjunction with the Configuration Space Device ID register value. Several vendors have introduced PCI devices that have compatibility problems between revisions of the device. Using only the Revision ID register value to distinguish among PCI device revisions means that drivers for these devices are forward and backward compatible. This practice has potential serious ramifications for legacy devices and significantly complicates the testing process because the driver will have to be tested against all revisions. To eliminate this problem, PCI device vendors must always revise the Device ID register value when revising a PCI device. This will effectively eliminate the potential problem of compatibility issues with legacy PCI devices. |
PMC Register Block and S-to-D Mapping for Video Adapters
For video adapters with the PCI Power Management Register Block implemented, Windows 2000/Windows XP uses the capabilities re-ported by the Power Management Capabilities (PMC) register to create a System-to-Device state mapping table. In such an S-to-D mapping table, the device power state for a given system power state is always equal to or lower than that system power state.
For example, if system power state S1 can be mapped into D1, D2, or D3 power state for the device, the operating system selected the highest supported and valid device power state for mapping. In this example, S1 would map to D1. If the device supports only D0 and D3 power states, the system power state S1 would be mapped to D3 for the device.
Driver support for D0 and D3 is implicit by exposing the Power Management Register Block in the PCI configuration space for the device (or function). Drivers commonly handle their hardware incorrectly by not supporting the D3 power state in their power management handling code. For example, if the device (or function) reports only D0 and D3 support in the Power Management Register Block, and the associated video miniport driver does not provide D3 support, then the system will not be able to enter S1 (standby) power-saving mode.
To resolve this error, video miniport drivers must support all power states reported by the hardware in the Power Management Register Block. The D1 and D2 capability bits of the PMC Register should be implemented for video adapters as well. By doing so, more flexibility for system power management is provided.