ZZ: http://www.microsoft.com/china/whdc/system/pnppwr/hotadd/hotplugpci.mspx#ET
Hot-Plug PCI and Windows
本页内容
Hot-Plug PCI Functions and Support
Hot-Plug PCI allows users to install and remove PCI devices while the computer is running. Microsoft Windows 2000, Windows XP, and Windows Server 2003 support Hot-Plug PCI through ACPI.
To take advantage of Hot-Plug PCI support on Windows operating systems, manufacturers of hot-pluggable PCI devices and Hot-Plug PCI controllers should develop standard Plug and Play drivers for their devices, and implement insertion and removal notifications as defined in ACPI 1.0b. Hot-Plug PCI controllers should also implement the _HPP object as defined in ACPI 2.0 for Windows XP and Windows Server 2003, and follow standard rules for implementing ACPI events when connecting to General Purpose Events (GPEs), as described in this article.
Support for Standard Hot Plug Controller (SHPC) as defined in PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0, is planned for Windows Vista.
Manufacturers of SHPCs should ensure that their devices comply with the specification, as described in this paper and with Microsoft Windows Logo Program requirements. Windows Vista will include in-box support through a single SHPC driver. This driver will support all SHPCs that are designed to these requirements. SHPC implementations will not require ACPI insertion and removal notifications.
Windows Hot-Plug PCI Roadmap
Hot-Plug PCI refers to the technology that allows users to install and remove PCI devices while the computer is running. Hot-Plug PCI should not be confused with fail-over functionality that allows automatic switching to a redundant device in the case of a failure. Hot-Plug PCI in this paper refers strictly to inserting and removing PCI devices in a running system. The information in this paper does not apply to CompactPCI, which is a different hardware technology that also provides hot-plug and fail-over functionality.
The PCI Hot-Plug Specification describes the hardware requirements and interfaces to use when designing Hot-Plug PCI devices. This specification is published by the PCI Special Interest Group (PCI SIG) and is available online at http://www.pcisig.com 
Although the PCI Hot-Plug Specification describes hardware requirements, it currently does not define a complete software interface for handling insertion and removal events. Therefore, the software interface Windows 2000 supports for Hot-Plug PCI is the Advanced Configuration and Power Interface (ACPI) specification, Revision 1.0b. The software interface that Windows XP supports is ACPI 1.0b along with one additional object introduced in ACPI 2.0 (the _HPP object). All insert, eject, and removal events can be handled through ACPI 1.0b on Windows 2000 and Windows XP systems. Note that these are the same mechanisms Windows 2000 and Windows XP use for supporting hot-docking of mobile PCs. Hardware manufacturers who are familiar with hot-docking can use their knowledge to implement Hot-Plug PCI. The ACPI specification is available at http://www.acpi.info/
The PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0, defines standard hot-plug interfaces so that all SHPCs can use a single driver and usage model. This specification is available at http://www.pcisig.com .
The rest of this section describes native Hot-Plug PCI support implemented in Windows 2000, Windows XP, and Windows Server 2003, and it describes planned support for SHPC in Windows Vista.
Windows 2000. Hot-Plug PCI support in Windows 2000 consists of the following:
| • | Insertion and removal notifications as defined in the ACPI specification, Revision 1.0b |
| • | Single-level resource re-allocation For information about memory and I/O resource allocations for PCI-to-PCI bridges, see the resources listed at the end of this article. |
| • | Optional vendor-supplied filter driver |
Windows XP. ACPI hot-plug support provided in Windows XP is an incremental improvement over Windows 2000. The following hot-plug support is included in Windows XP (and Windows Server 2003):
| • | Insertion and removal notifications as defined in the ACPI specification, Revision 1.0b | ||||||||
| • | Single-level resource re-allocation | ||||||||
| • | Optional vendor-supplied filter driver | ||||||||
| • | New _HPP object defined in the ACPI 2.0 specification The _HPP object in the ACPI BIOS must be associated with a PCI-PCI bridge. The object informs the operating system of the default settings that should be used for add-in cards inserted into hot-plug slots located behind the bridge. These parameters will also be used by the operating system to program hot-plugged devices and devices that are inserted before system boot but not configured by the BIOS. The default settings addressed by the _HPP object are:
|
Although Windows XP supports the _HPP object from ACPI 2.0, it is not considered an ACPI 2.0-compliant operating system because it does not support all ACPI 2.0 enhancements. For example, Windows XP does not support the new event notifications defined in the ACPI 2.0 Specification.
ACPI hot-plug support is consistent for both 32-bit and 64-bit versions of Windows XP.
Future Support Microsoft is investigating the following native support for Hot-Plug PCI in Windows Vista:
| • | Operating system support for SHPC |
| • | Dynamic configuration of PCI-to-PCI bridges |
Preparing Drivers for Hot-Plug PCI
Hot-Plug PCI is implemented through standard operating system Plug and Play mechanisms. Drivers for devices that can be hot-plugged have no additional requirements beyond the standard Plug and Play support that every Windows driver must have. At a minimum, a Windows Plug and Play driver must implement the following routines:
| • | A DriverEntry routine that allocates memory and initializes driver data structures | ||||||||||
| • | An AddDevice routine that initializes a device | ||||||||||
| • | A DispatchPnP routine that must handle the following IRPs and may handle additional optional IRPs:
|
For complete details about these and other aspects of Plug and Play and power support, see the Windows DDK.
Important: Hot-plug PCI devices can be installed at runtime, after the system firmware has booted the computer. When these devices are installed at runtime, option ROMs on the card will not be executed. As a result, Hot-Plug PCI hardware and drivers must be able to function without having run any option ROMs.
Therefore, in addition to implementing complete Plug and Play support, the designer for a hot-plug device must ensure support for completed device functionality without running an option ROM.
Implementing ACPI-based Hot-Plug PCI in Systems
As previously stated, systems that support Hot-Plug PCI use ACPI to inform the operating system of insertion and removal events. ACPI handles Hot-Plug PCI devices the same way it handles any other type of removable device. The following checklist will help in designing systems:
| 1. | Create device objects for each Hot-Plug PCI slot on its appropriate bus in the ACPI namespace. Because a PCI device might have eight functions on that device, the namespace must list eight device objects for each slot. | ||||||||||
| 2. | For each device object, include the following:
| ||||||||||
| 3. | Ensure that a pin that signals insertion and eject requests is wired to an ACPI GPE bit. | ||||||||||
| 4. | Create an _Lxx or _Exx control method to handle the GPE bits associated with Hot-Plug PCI. |
Example Namespace for Hot-Plug PCI
The following ACPI Source Language (ASL) example describes two Hot-Plug PCI slots behind a PCI-to-PCI bridge. The insertion and removal events for both cards are wired to the same GPE (bit 0x0a) in the chip set. Proprietary status bits in the Hot-Plug PCI controller indicate to control methods the presence of devices in a given slot, whether an event is for device insertion or removal, and which slot the event is for.
Scope(\_SB) {
Device(PCI0) { // Root PCI Bus
Name(_HID, EISAID("PNP0A03")) // _HID for root device
Name(_ADR,0) // Device 0 on this bus
Method (_CRS,0){ // Need current resources for root dev
// Return current resources for root bridge 0
}
Name(_PRT, Package(){ // Need PCI IRQ routing for PCI bridge
// Package with PCI IRQ routing table information
})
// First PCI-to-PCI bridge (No Hot-Plug slots)
Device (P2P1) {
Name(_ADR,0x000C0000) // Device#Ch, Func#0 on bus PCI0
Name(_PRT, Package(){ // Need PCI IRQ routing for PCI bridge
// Package with PCI IRQ routing table information
})
} // end P2P1
// Second PCI-to-PCI bridge (Bus contains Hot-Plug slots)
Device (P2P2) {
Name(_ADR,0x000E0000) // Device#Eh, Func#0 on bus PCI0
Name(_PRT, Package(){ // Need PCI IRQ routing for PCI bridge
// Package with PCI IRQ routing table information
})
Name(_HPP, Package(){0x08,0x40, 0x01, 0x00})
//_HPP only implemented in Windows XP
// Device definitions for Slot 1- HOT PLUG SLOT
Device (S1F0) { // Slot 1, Func#0 on bus P2P2
Name(_ADR,0x00020000)
Method(_EJ0, 1) {
//Code to eject device - remove all power to device
}
Name(_SUN,0x00000001)
}
Device (S1F1) { // Slot 1, Func#1 on bus P2P2
Name(_ADR,0x00020001)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000001)
}
Device (S1F2) { // Slot 1, Func#2 on bus P2P2
Name(_ADR,0x00020002)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000001)
}
Device (S1F3) { // Slot 1, Func#3 on bus P2P2
Name(_ADR,0x00020003)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000000)
}
Device (S1F4) { // Slot 1, Func#4 on bus P2P2
Name(_ADR,0x00020004)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000001)
}
Device (S1F5) { // Slot 1, Func#5 on bus P2P2
Name(_ADR,0x00020005)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000001)
}
Device (S1F6) { // Slot 1, Func#6 on bus P2P2
Name(_ADR,0x00020006)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000001)
}
Device (S1F7) { // Slot 1, Func#7 on bus P2P2
Name(_ADR,0x00020007)
Method(_EJ0, 1) { S1F0._EJ0}
Name(_SUN,0x00000001)
}
// Device definitions for Slot 2- HOT PLUG SLOT
Device (S2F0) { // Slot 2, Func#0 on bus P2P2
Name(_ADR,0x00030000)
Method(_EJ0, 1) {
//Code to eject device - remove all power to device
}
Name(_SUN,0x00000002)
}
Device (S2F1) { // Slot 2, Func#1 on bus P2P2
Name(_ADR,0x00030001)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
Device (S2F2) { // Slot 2, Func#2 on bus P2P2
Name(_ADR,0x00030002)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
Device (S2F3) { // Slot 2, Func#3 on bus P2P2
Name(_ADR,0x00030003)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
Device (S2F4) { // Slot 2, Func#4 on bus P2P2
Name(_ADR,0x00030004)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
Device (S2F5) { // Slot 2, Func#5 on bus P2P2
Name(_ADR,0x00030005)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
Device (S2F6) { // Slot 2, Func#6 on bus P2P2
Name(_ADR,0x00030006)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
Device (S2F7) { // Slot 2, Func#7 on bus P2P2
Name(_ADR,0x00030007)
Method(_EJ0, 1) { S2F0._EJ0}
Name(_SUN,0x00000002)
}
} // end P2P2
} // end PCI0
} // end Scope (\_SB)
Scope(\_GPE) {
Method(_L0A,0){
//Check proprietary bit in Hot-Plug controller
if(//insertion on slot 1){
Notify(\_SB.PCI0.P2P2,0)
}
if(//insertion on slot 2){
Notify(\_SB.PCI0.P2P2,0)
}
if(//ejection request on slot 1){
Notify(\_SB.PCI0.P2P2,3)
}
if(//ejection request on slot 2){
Notify(\_SB.PCI0.P2P2,3)
}
} //end Method (_L0A, 0)
} //end Scope (\_GPE)
Connecting General Purpose Events
ACPI discovers hardware events when a GPE is asserted and a System Control Interrupt (SCI) is raised. Hot-Plug PCI controllers must therefore be wired to the GPE bits of the core chip set. Because of the flexibility of GPEs, there are a number of implementations: a single GPE bit could be used for all Hot-Plug PCI events in the system; another implementation could wire up a GPE bit for each event on each slot.
Regardless of how the events are shared on GPEs, the standard rules for ACPI events must be followed. For more information, see the following sources:
| • | Section 5.6.2.2 of the ACPI specification, Revision 1.0b. |
Event Flow for Insertion. When a device is inserted into the system, the following takes place:
| 1. | User: The user inserts the hardware in the slot. |
| 2. | Hot-Plug PCI controller (HPPC): Asserts a GPE. |
| 3. | Core chip set: Raises an SCI. |
| 4. | ACPI driver: Clears the GPE event and runs the _Lxx method associated with the GPE. |
| 5. | _Lxx method: Reads status bits from the HPPC to determine that the event was an insertion event and which slot the event took place on. |
| 6. | _Lxx method: Executes Notify(,0) on the PCI bus that the slot is on. |
| 7. | ACPI driver: Executes _STA methods for the devices specified in Notify() in the previous step. |
| 8. | _STA: Returns 0x0a; that is, the device is present but not enabled. |
| 9. | ACPI driver: Tells the PCI driver to enumerate the bus. |
| 10. | PCI driver: Reads configuration space to identify the device. |
| 11. | PCI driver/PNP subsystem: Loads and starts the drivers for all functions of the device. |
| 12. | Device drivers: Request the functions be turned on. |
| 13. | ACPI driver: Executes _PS0 methods, if present. |
| 14. | PCI driver: Writes to configuration space to turn on the device according to PCI Power Management specifications. |
| 15. | Device driver: Begins using the device normally. |
Event Flow for Removal. When the user requests to eject a device, the following steps take place. These steps assume that the hardware has an eject button associated with each device. If it does not, then the user must use the Add/Remove Hardware Wizard to eject a device. In this case, the process would start at step 8 in this list:
| 1. | User: The user presses the eject button for the slot. |
| 2. | HPPC: Asserts a GPE. |
| 3. | Core chip set: Raises an SCI. |
| 4. | ACPI driver: Clears the GPE event and runs the _Lxx method associated with the GPE. |
| 5. | _Lxx method: Reads status bits from the HPPC to determine that the event was an eject request and which slot the event took place on. |
| 6. | _Lxx method: Executes Notify(,3) function 0 of the slot that is requesting eject. |
| 7. | ACPI driver: Requests the Plug and Play system to eject the device. |
| 8. | PNP: Queries all drivers for all functions of the device, and if successful, tells the drivers to unload. |
| 9. | PCI driver: Writes to configuration space to turn off the device per PCI Power Management specifications. |
| 10. | ACPI driver: Executes _PS3 methods, if present. |
| 11. | ACPI driver: Executes _EJ0. |
| 12. | _EJ0: Engages motors, solenoids, lights, and so on to eject the device. When the device has been ejected and status bits updated accordingly, it returns. |
| 13. | ACPI driver: Executes _STA to verify the device ejected successfully. |
| 14. | _STA: Returns 0x00 (device not present). Had the device not ejected successfully, _STA would have returned 0x05 (that is, present but not functioning). |
| 15. | ACPI driver: Complete cleanup. Had _STA returned 0x05, the ACPI driver would have told the operating system that there was a problem and an error dialog would pop up on the user's screen. |
Windows Logo Program Timeline
If implemented, SHPCs must conform to the PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0,and to the Windows Logo requirements listed in this section, to take advantage of the built-in support planned for Windows Vista and future versions of Windows. This planned support will eliminate the need for ACPI implementations and vendor-supplied filter drivers. The following requirements are being considered for addition to the Windows Logo Program for Vista.
| • | The Manual Retention Latch (MRL) Sensor is described in section 2.2.3 of the SHPC Specification, Revision 1.0. The MRL Sensor is a switch, optical device or other type of sensor that reports the position of a slot’s MRL to the SHPC. |
| • | Separate indicators are described in section 2.2.1 of the SHPC Specification. Separate indicators show the attention and power states of SHPC slots. |
| • | The Attention Button is described in section 2.2.5 of the SHPC Specification. |
Call to Action
Manufacturers of hot-pluggable PCI devices and Hot-Plug PCI controllers should:
| • | Develop standard Plug and Play drivers for hot-pluggable devices as specified in the Windows DDK. |
| • | Implement insertion and removal notifications as defined in the ACPI Specification Revision 1.0b. |
| • | Implement the _HPP object as defined in the ACPI Specification revision 2.0 for Windows XP. |
| • | Follow standard rules for implementing ACPI events when connecting to GPE events |
| • | Be aware of upcoming revisions to the PCI Hot-Plug Specification to include native support for insertion events, removal events and other hot-plug functionality required of standard Hot-Plug PCI controllers. |
| • | Be aware of resource rebalancing issues for hot-plug devices and PCI-to-PCI bridges. For information, see the list of resources at the end of this article. |
| • | Be aware of Windows Logo Program for Hardware requirements related to Hot-Plug PCI. For information, see the requirements available on Windows Logo Program Requirements. |
| • | Plan to develop and support SHPCs for Windows Vista as defined in this white paper. |
| • | Be aware of upcoming Windows Logo Program for Hardware requirements related to SHPCs. |
Related Information
| • | PCI Hot-Plug Specification at |
| • | ACPI Specifications, Revisions 1.0b and 2.0 at |
| • | |
| • | PCI-to-PCI Bridges and Cardbus Controllers on Windows |
2023
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
