This section summarizes the Plug and Play requirements for PCI devices.
10. Devices use PCI 2.1 Configuration Space register for Plug and Play device ID
Required
The PCI 2.1 specification describes the Configuration Space register used by the system to identify and configure each device attached to the bus. The Configuration Space register is made up of a 256-byte field for each device and contains sufficient information for the system to identify the capabilities of the device. Configuration of the device is also controlled from this register.
The Configuration Space register is made up of a header region and a device-dependent region. Each Configuration Space register must have a 64-byte header at offset 0. All the device registers that the device circuit uses for initialization, configuration, and catastrophic error handling must fit in the space between byte 64 and byte 255.
All other registers that the device uses during normal operation must be located in normal I/O or memory space. Unimplemented registers or reads to reserved registers must complete normally and return zero (0). Writes to reserved registers must complete normally, and the data must be discarded.
11. Device IDs include PCI 2.1 Subsystem IDs
Required
The following diagram shows the two registers added to the Configuration Space header for PCI 2.1. Although these registers are only recommended in PCI 2.1, they are mandatory for PC 98. Support for these registers requires non-zero values to be populated for both the Subsystem ID and Subsystem Vendor ID.
New registers in Configuration Space header for PCI 2.1
31
16
15
0
Subsystem ID
Subsystem Vendor ID
2Ch
These fields are necessary for the correct enumeration of a device. When the Subsystem ID fields are populated correctly for the adapter, Windows can differentiate between adapters based on the same PCI chip.
The Subsystem ID also allows Windows to load system miniports for system-board devices. Thus, Subsystem IDs are also a requirement on system-board devices. The exceptions to this requirement are PCI-to-PCI bridges and core chip sets.
Two methods can be used to implement a Subsystem Vendor ID:
For more information, see the article titled “IDs and Serial Numbers for Plug and Play” on the web site at http://www.microsoft.com/hwdev/busbios/.
Important: Multiple-monitor support allows display class devices to be initialized independently of the system initialization process. For this reason, system-board and add-on display devices cannot use the VGA BIOS POST routine to populate the Subsystem Vendor ID because the device’s POST code might not be executed until later in the process, after device enumeration occurs. For system-board devices, the system BIOS should populate the Subsystem Vendor ID at power on. Add-on display adapters should provide a method for populating the Subsystem Vendor ID at the point when power is applied and the device is initialized to the state that it is ready for POST.
12. Configuration Space is correctly populated
Required
Windows places extra constraints on a few configuration registers and has uncovered some problem usage of other registers. Microsoft provides a program named Pci.exe to help debug the use of the Configuration Space. This program is available on the Microsoft FTP server, as described in the “PCI References” section at the end of this chapter.
The following items are specific requirements for the Configuration Space:
Follow the base class, sub-class, and programming interface values outlined in PCI 2.1.
See PCI 2.1 for correct usage of these registers. Notice that BARs (10, 14, 18, 1C, 20, and 24h) should return zero if they are not used, indicating that no memory or I/O space is needed.
Also, for performance reasons, it is recommended that run-time registers for PCI devices should not be placed in the Configuration Space.
13. Interrupt routing supported using ACPI
| Required |
The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of the Advanced Configuration and Power Interface Specification, Revision 1.0 or higher.
14. BIOS does not configure I/O systems to share PCI interrupts
Recommended
This applies to boot devices configured by the BIOS on systems based on Intel Architecture processors. The operating system should configure all other devices. For systems that will run the Windows operating system, OEMs should design the BIOS so that it does not configure the I/O systems in the PC to share PCI interrupts for boot devices. An exception exists for legacy audio devices following the configuration guidelines outlined in the white paper titled Implementing Legacy Audio Devices on the PCI Bus, available on the web site at http://www.intel.com/pc-supp/platform/ac97/wp/leg_pci.htm.
Windows does not support sharing an IRQ between real-mode and protected-mode code within the I/O subsystem. An example of this is an NDIS 2.0 driver (real mode) and a SCSI miniport driver (protected mode) for two PCI devices that share the same IRQ. The problem is that the IRQ needs to be reflected to real mode for the NDIS 2.0 driver to work.
However, if the IRQ is reflected to real mode, the real-mode SCSI driver (which usually is not called because Windows takes over in protected mode) might touch the hardware, which would cause the SCSI miniport to be confused. Windows resolves this problem either by switching everything to protected mode or by falling back to real mode.
15. BIOS configures boot device IRQ and writes to the interrupt line register
Required
This requirement applies to boot devices configured by the BIOS on systems based on Intel Architecture processors. Windows should configure all other devices because, after an IRQ is assigned by the system BIOS, Windows cannot change the IRQ, even if necessary. If the BIOS assigns the IRQ and Windows needs it for another device, a sharing problem occurs.
The BIOS must configure the boot device IRQ to a PCI-based IRQ and must write the IRQ into the interrupt line register 3Ch, even if the BIOS does not enable the device. This way, the operating system can still enable the device with the known IRQ at configuration time, if possible.
16. Hot swapping for any PCI device uses ACPI-based methods
Required
Windows 98 and Windows NT 5.0 support dynamic enumeration, installation, and removal of PCI devices only if there is a supported hardware insert/remove notification mechanism.
The appropriate notification mechanism is supported as a bus standard for CardBus bus controllers. For other solutions, such as those required for docking stations or other devices, the hardware insert/remove notification mechanism must be implemented as defined in Section 5.6.3 of the ACPI 1.0 specification. To properly function with the native support in the operating system, developing industry standards, such as those referred to as PCI Hot Plug and Compact PCI, must use ACPI-based methods for supporting hardware insertion and removal as defined in the ACPI 1.0 specification.