Guidelines for products that work well with the Microsoft® Windows® xp and Windows Server 2003 operating systems

səhifə	12/22
tarix	18.07.2016
ölçüsü	0.89 Mb.

1 ... 8 9 10 11 12 13 14 15 ... 22

B2.0 Bus/Device Controllers

B2.1 CardBus/PCMCIA Controllers and Devices

All general requirements in B1.0 are included by reference.

B2.1.1 CardBus/PCMCIA Controllers and Devices - Windows Compatibility

B2.1.1.1 “PCMCIA_INTERFACE_STANDARD Interface Memory Card Routines” in the Windows DDK

Note: This is a general reference, not a requirement.

B2.1.1.2 DELETED

B2.1.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/bus/cardbus/
"Design Guidelines for PC Card and CardBus, Version 1.1" at http://www.microsoft.com/hwdev/platform/pcdesign/desguide/default.asp

Note: This is a general reference, not a requirement.

B2.1.1.4 CardBus Host Controllers and Windows Compatibility

http://www.microsoft.com/hwdev/bus/cardbus/cardbus1.asp

B2.1.1.5 PC Card Voltage Requirements for Windows

http://www.microsoft.com/hwdev/bus/cardbus/pccardvlt.asp
(implementing R2 version cards to use only 3.3 V)

Note: This is a general reference, not a requirement.

B2.1.1.6 DELETED

B2.1.1.7 DELETED

B2.1.2 CardBus/PCMCIA Controllers and Devices - Industry Standards

Note: This list provides complete titles and web locations for references cited. The listing of a reference here does not imply that complete compliance with that reference is a Windows Logo Program requirement.

B2.1.2.1 PC Card Controller Device Class Power Management Reference Specification, V. 2.0

http://www.microsoft.com/hwdev/resources/specs/pmref/PMcard.asp

B2.1.2.2 PC Card Standard Guidelines

http://www.pcmcia.org/bookstore.htm

B2.1.2.3 PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges

Provided in Volume 11, PC Card Standard, Release 7, http://www.pcmcia.org/bookstore.htm

B2.1.2.4 PCI to PCMCIA CardBus Bridge Register Description

http://www.pcmcia.org/bookstore.htm

B2.1.3 CardBus/PCMCIA Controllers and Devices - Quality

WHQL Test Specification References:
Chapter 14: PC Card Test Specification

B2.1.3.1 Pass WHQL tests - See B1.3.

See “CardBus/PCMCIA Controllers” and device-specific topics in the HCT documentation.

B2.1.4 CardBus/PCMCIA Controllers and Devices - Windows Experience

See "Design Guidelines for PC Card and CardBus" at http://www.microsoft.com/hwdev/platform/pcdesign/desguide/default.asp.

B2.1.4.1 Controller complies with industry standards and Windows-compatible configuration

B2.1.4.1 Exchangeable Card Architecture register set.

The built-in software supporting 16-bit PC Card cards in Windows includes drivers for the industry-standard Exchangeable Card Architecture-compatible (ExCA-compatible) socket controllers. To be compatible with these drivers, socket-controller implementations must support the industry-standard ExCA base register set.

Notice that some controllers do not fully implement the register set and therefore are incompatible. Also, some controllers implement extended registers or enhancements. The built-in Windows drivers do not exploit these features, even though the controller might be compatible.

B2.1.4.2 CardBus bridges.

Systems must support the definition in PC Card Standard Release 7 (or later) PC Card Host System Specification (Volume 11), PCI-to-CardBus Bridge Register Description (Section 4) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI Configuration Space header assigned the Header Type field value of 82h.

Windows supports this specification. Any controller features that are not part of this specification will not be used in standard drivers. The BIOS is responsible for any hardware initialization or setup required to make the controller comply with this specification or other requirements in this document.

Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows in the same manner as other PCI bus bridges.

PCCard-3 in "PC Card and CardBus Guidelines" Version 1.1, is incorrect; it should also list header type 02h in addition to type 82h, which is listed as an acceptable header type for CardBus bridges.

B2.1.4.3 ISA and PCI interrupts.

PC Card software dynamically configures the bridge to use ISA interrupts for 16-bit PC Card cards and to use PCI interrupts for CardBus cards. CardBus controllers must maintain mapping of IRQ routing. Also, notice that systems implementing CardBus controllers must fully support PCI 2.2 as well as additional PCI requirements for IRQ routing.

To ensure that Windows system correctly assign ISA IRQs to 16-bit PC Cards, A CardBus controller with parallel ISA IRQ mode must have all ISA IRQs pins, except IRQ 0 (timer), 1 (keyboard), 6 (floppy), 8 (CMOS), and 13 (math coprocessor).

It is recommended that system vendors using parallel ISA IRQ mode always connect ISA IRQs 3, 4, 5, 7, 9, 10, 11, 12, 14, 15 and not cross wire them.

For vendors using serialized IRQ mode, the above is not relevant because they only need to connect the serial IRQ pin, and the ISA IRQ information will be sent to the PCI chip set serially; the ISA IRQ information can specify any of IRQ 0-15.

B2.1.4.4 See A3.4.4.5

B2.1.4.5 See A3.4.4.5

B2.1.4.2 CardBus cards are configured correctly

Required tuples are defined in PCCard-14 through PCCard-16 in "Design Guidelines for PC Card and CardBus, Version 1.1"

B2.1.4.3 16-bit PC Cards are configured correctly; driver supports sharing of level-mode interrupts

For complete requirements, see PCCard-11 through PCCard-13 in "Design Guidelines for PC Card and CardBus, Version 1.1"

CardBus systems support both 16-bit PC Card cards and CardBus cards. In this environment, interrupt sharing becomes an issue because CardBus controllers can use PCI interrupts, which are level-sensitive and sharable. To help alleviate interrupt limitations in CardBus systems, Windows can take advantage of PCI interrupt-sharing capabilities.

In cases where no ISA IRQs are available to a 16-bit PC Card card in a CardBus controller, the operating system will assign a PCI interrupt to the card. All 16-bit PC Card card drivers must "hook" the interrupt, whether it is sharable or not, before its hardware generates any interrupts.

B2.1.4.4 No user intervention; no system restart occurs when installing devices, except when required by the operating system

See PCCard-11 through PCCard-20 and 21 in "Design Guidelines for PC Card and CardBus, Version 1.1"PCCard-20, 21

B2.1.4.5 ZV-compatible 16-bit PC Cards comply with ZV standard definitions, and driver uses DirectDraw VPE

ZV-compatible PC Card drivers must use software interfaces based on 32-bit Microsoft DirectDraw® Video Port Extensions (VPE) in order to configure the graphics controller to receive video input using the ZV port. This includes programming the graphics controller to configure the format of the video data, its location on screen, and so on. VPE is part of Microsoft DirectX® APIs.

ZV card device drivers must handle dynamic graphics state changes, such as resolution changes, color depth changes, and switching to and from full-screen MS-DOS®–based applications.

B2.1.4.6 CardBus controller designed to support wake-from-D3cold supports PME# assertion from D3cold, and socket supplies Vaux power to cards in D3cold state

CardBus cards (which are by definition PCI devices) must comply with PCI Bus Power Management Interface Specification, Revision 1.1 or later, in order for power management to be implemented properly under Windows, which uses PME# as the wake-up signal. This is the only industry specification that ensures compatibility with the power management capabilities of Windows.

The CardBus card must use the CSTSCHG pin to signal wake-up events. This is because there is no PME# pin on the CardBus interface, and the CardBus card must use PME_EN in the card’s Configuration Space to enable wake-up events. Specifically, setting the PME_EN bit in the card’s Configuration Space must provide the same behavior as setting both the GWAK and WKUP bits in the card’s Function Event Mask register.

If wake-from-D3cold is implemented in a platform, the following are required:

Associated CardBus controller must support PME# assertion from D3cold.
Associated socket must supply sufficient Vaux power to support the card in its D3cold state.

This requirement must be independently met by each enabled D3cold-wake-capable CardBus socket in the system, as defined in the host system chapter of PC Card Standard, version 7.

B2.1.5 CardBus/PCMCIA Controllers and Devices - FAQs

B2.1.5.1 Current PC Card/CardBus FAQs

See http://www.microsoft.com/winlogo/hardware/

B2.1.5.2 Updated at B2.1.4.3

B2.1.5.3 Updated at B2.1.4.6

B2.1.5.4 Updated at B2.1.4.2

B2.1.R CardBus/PCMCIA Controllers and Devices - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/

B2.2 IEEE 1394 Controllers and Devices

All general requirements in B1.0 are included by reference.

B2.2.1 1394 Controllers/Devices - Windows Compatibility

B2.2.1.1 WDM support for devices that use the IEEE 1394 bus

"IEEE 1394 Structures" in the Windows DDK.

Note: This is a general reference, not a requirement.

B2.2.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/bus/1394/

Note: This is a general reference, not a requirement.

B2.2.1.3 Plug and Play Specification for IEEE 1394

http://www.microsoft.com/hwdev/resources/specs/1394PNP.asp

Note: This is a general reference, not a requirement.

B2.2.1.4 IEEE 1394 Support in Windows

http://www.microsoft.com/hwdev/bus/1394/

Note: This is a general reference, not a requirement.

B2.2.2 1394 Controllers/Devices - Industry Standards

B2.2.2.1 1394 Open Host Controller Interface Specification, Revision 1.0

ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/ohcir100.pd

B2.2.2.2 1394 Trade Association Power Specification, Part 1: Cable Power Distribution; 1394 Trade Association Power Specification, Part 3: Power State Management

ftp://ftp.p1394pm.org/pub/p1394pm/

B2.2.2.3 IEEE 1394 Standards

B2.2.2.3.1 IEEE 1394-1995 or later standards, and IEEE 1394a.

IEEE 1394a-2000 amendment to IEEE 1394-1995
IEEE 1394-1995 Standard for a High Performance Serial Bus

B2.2.2.3.2 IEEE 1212-1991 and function discovery in IEEE 1212r

Global Engineering Documents at http://global.ihs.com/.

B2.2.2.4 IEEE 1394 devices comply with appropriate industry-recognized transport and command standards

B2.2.2.4.1 IEC 61883 Parts 1-6, including CIP, CMP, and FCP.

CIP (common isochronous packet) headers, CMP (connection management protocol), and FCP (function control protocol).

B2.2.2.4.2 1394TA AV/C 3.0 and the AV/C subunit family of specifications

Including AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1.

B2.2.2.4.3 INCITS Serial Bus Protocol (SBP-2) transport protocols

(ANSI National Committee for Information Technology Standards (INCITS) 3.25-1998 [SBP-2]).

B2.2.2.4.4 INCITS T10 Reduced Block Commands (RBC).

B2.2.2.4.5 INCITS T10 Multimedia Command Set 2 (MMC-2) or later.

B2.2.2.4.6 Storage class devices must conform to the ANSI standards for SBP-2 (or later) with the appropriate command set: RBC or MMC-2 (or later).

B2.2.2.4.7 Printing devices using the SBP-2 (or later) protocol must conform to the guidelines set in "SBP-2 Support and Windows"

http://www.microsoft.com/hwdev/tech/print/sbp2_w2000.asp

B2.2.3 1394 Controllers/Devices - Quality

WHQL Test Specification References:
Chapter 19: IEEE 1394 Test Specification

B2.2.3.1 Pass WHQL tests

See B1.3.

Specifically see “IEEE 1394 Controllers” and device-specific topics in the HCT documentation.

B2.2.4 1394 Controllers/Devices - Windows Experience

B2.2.4.1 Open HCI controllers and devices support advances defined in IEEE 1394a-1999

Including peak data rate requirements for Open Host Controller Interface.

Any device that support IEEE 1394 features and interconnectivity that interface to the IEEE 1394 bus must support the industry standards and its amendments as they apply to internal and external devices. Minimum requirements consist of the following.

B2.2.4.2 Device configuration ROM is correctly implemented

The device configuration ROM space must provide configuration information as specified in the IEEE 1212r-2000 standard and applicable IEEE 1394 standards, thus providing Plug and Play device control.

B2.2.4.3 Devices demonstrate interoperability with other devices

All devices must support Plug and Play for intended use in both a minimal and an extended bus configuration. A minimal configuration is the minimum number of devices necessary to demonstrate the primary use of the device. An extended configuration has at least two devices added to the minimal configuration. The added devices can be extraneous to the use.

B2.2.4.4 DELETED

B2.2.4.5 DELETED

B2.2.4.6 Self-powered devices propagate the power bus through each connector

As defined in the 1394 Trade Association Power Specification.

Devices and controllers are not required to comply with 1394 Trade Association Power Specification, Part 3: Power State Management. This standard version is required with the release of a future operating system.

B2.2.4.7 Vendor and model leafs support textual descriptor leaf format

Textual descriptors are required for Vendor_ID and Model_ID entries in the CSR space in order to display this information to the user. Each textual descriptor points to a leaf that contains a single character string. Examples of valid textual descriptors are found in the IEEE 1394 Plug and Play specification.

B2.2.4.8 DELETED

B2.2.4.9 DELETED

B2.2.4.10 DELETED

B2.2.4.11 DELETED

B2.2.4.12 Descriptors are required for Vendor_ID and Model_ID entries in the Configuration Status Register (CSR) space

B2.2.4.13 SBP-2-capable devices comply with SBP-2-related requirements

Devices using the SBP-2 protocol must conform to the requirements set in “SBP-2 Support and Windows” at http://www.microsoft.com/hwdev/tech/print/sbp2_w2000.asp.

A unit directory is required for independent function and control of each device unit. A valid pointer to a unit directory must be provided in the root directory.

B2.2.5 1394 Controllers/Devices - FAQs

B2.2.5.1 Current IEEE 1394 FAQs

See http://www.microsoft.com/winlogo/hardware/

B2.2.5.2 Updated at B2.2.4.6

B2.2.5.3 DELETED

B2.2.R 1394 Controllers/Devices - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/

B2.3 Infrared/Wireless

All general requirements in B1.0 are included by reference.

B2.3.1 Infrared/Wireless - Windows Compatibility

B2.3.1.1 "IrDA Miniport NIC Drivers” and “Wireless WAN Objects" in the Windows DDK

An NDIS 5.1 miniport driver is required for all IrDA data devices and wireless network devices.

Note: This is a general reference, not a requirement.

B2.3.1.2 Reference: Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/tech/network/wireless

Note: This is a general reference, not a requirement.

B2.3.1.3 IrDA Plug and Play Issues and Windows

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwbgen/html/irdapnp.asp

Note: This is a general reference, not a requirement.

B2.3.1.4 Windows XP: IrTran-P, IrLPT, and IrDA Networking Support under Windows

http://www.microsoft.com/hwdev/archive/infrared/IrCOMM.asp

Note: This is a general reference, not a requirement.

B2.3.2 Infrared/Wireless - Industry Standards

B2.3.2.1 IrDA documents - Serial Infrared Physical Layer Specification; Control IR Specification

http://www.irda.org/

An IR device must be designed to comply with approved IrDA specifications. If the system is intended to run data transfer applications with other IrDA data devices, it must comply with the IrDA Serial Infrared Data Link Standard Specifications.

B2.3.2.2 IrDA Bridge Device Definition, 1.0

http://www.usb.org/developers.

B2.3.2.3 Bluetooth Wireless Technology Specifications

Bluetooth H:1 Specification
Bluetooth SDP Specification
Bluetooth Specification 1.1

http://www.bluetooth.com/

B2.3.2.4 IEEE 802.11 Specifications

http://www.ieee.org/

B2.3.3 Infrared/Wireless - Quality

WHQL Test Specification References:
Chapter 22: Driver Quality Test Specification
Plus technology-specific test specifications

B2.3.3.1 Pass WHQL tests - See B1.3.

Windows XP: See “Bluetooth Controllers,” “Infrared (IrDA) Controllers,” and device-specific topics in the HCT documentation.

B2.3.4 Infrared/Wireless - Windows Experience

Design Guideline References: "Wireless Technologies" web page at http://www.microsoft.com/hwdev/tech/network/wireless/

B2.3.4.1 DELETED

B2.3.4.2 System supports standard input speeds of 4 Mb/s

Device support is required for FIR input speeds of 4 Mbps for all IrDA Data devices.

B2.3.4.3 System provides a separate, physically-isolated transceiver for each IR protocol supported

This requirement provides for correct implementation for a system that includes IR support for any combination of devices that use the IrDA Data protocol, the IrDA Control protocol, or the universal consumer–IR approach to legacy remote control, each of which use different device signals. The system must also expose each separate transceiver to the operating system.

If multiple IR protocols are supported, controllers must provide separate data connections into the PC using USB.

B2.3.4.4 Mobile PC IR devices, if implemented, support D0 and D3 states

Mobile PC Note
IR capabilities are not required for mobile PCs. IrDA devices must support D0 and D3 states, controlled by methods defined in Section 3.4 of the ACPI 1.0b specification or by the relevant bus-specific methods.

B2.3.4.5 Bluetooth wireless host controllers meet requirements

Bluetooth Host controllers must meet the following requirements.

B2.3.4.5.1 Support Plug and Play on the applicable bus.

USB must meet “Part H:2 USB Transport Layer.”

B2.3.4.5.2 Support the Bluetooth H:1 specification for host controllers, including the mechanism for reporting the version supported.

B2.3.4.5.3 Support the bus-specific transport class extensions (for example, H:2-H:4) where applicable.

B2.3.4.5.4 The Bluetooth host controller must use one of the following physical transports as specified by the SIG: USB, UART, or PCI.

Alternatively, the Bluetooth host controller may use the BCSP transport specification.

B2.3.4.5.5 Support Bluetooth scatternet.

Bluetooth host controller must support at least 2 concurrent piconets (scatternet) plus be able to allow the host to join a device requesting a connection to the existing piconet for which the local radio is the master. The scatternet support should follow the enhanced scatternet support errata defined by the Bluetooth SIG.

B2.3.4.5.6 Bluetooth host controllers which are qualified Bluetooth Subsystem End Products shall have the Windows Operating System listed in their Complimentary Subsystem List.

See Bluetooth Qualification Program Reference Document v1.0, 6.1 Bluetooth Subsystems.

Systems including Bluetooth host controllers, radios, or peripherals must comply with Specification of the Bluetooth System, Version 1.1.

B2.3.4.6 Bluetooth-connected peripherals meet requirements

B2.3.4.6.1 Meet all device class-specific Windows Logo requirements

For example, B3.0 for audio, B5.1 for HID, B6.1 for modem, and so on.

B2.3.4.6.2 Comply with all applicable Bluetooth specifications.

Including design-applicable usage profiles.

B2.3.4.6.3 Support Bluetooth SDP and the PnPInformation Service Class.

The Bluetooth system defines a Service Discovery Protocol (SDP). Bluetooth PC peripherals must support SDP and support the Bluetooth Specification 1.1

B2.3.4.6.4 Bluetooth HID devices shall support HID-initiated reconnect.

The HIDReconnectInitiate attribute (defined in the Bluetooth HID Profile, revision 0.9b Section 7.12.6 HIDReconnectInitiate) shall be enabled. The device shall enter Page mode to automatically reconnect to the host if the connection is dropped.

B2.3.4.6.5 Bluetooth Printers shall conform to the Bluetooth SIG HCRP specification or the Bluetooth SIG PAN specification.

B2.3.4.6.6 Bluetooth peripherals shall support service discovery before requiring authentication.

B2.3.4.6.7 Bluetooth Subsystem End Products shall have the Windows Operating System listed in their Complimentary Subsystem List.

See Bluetooth Qualification Program Reference Document v1.0, 6.1 Bluetooth Subsystems.

B2.3.5 Infrared/Wireless - FAQs

See http://www.microsoft.com/winlogo/hardware/

B2.3.5.1 Updated at B2.3.4.5.3

B2.3.R Infrared/Wireless - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/

B2.4 Parallel/Serial Devices

All general requirements in B1.0 are included by reference.

B2.4.1 Parallel/Serial Devices - Windows Compatibility

B2.4.1.1 "Serial Port Devices" and Parallel Port Devices” in the Windows DDK

B2.4.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/tech/comm/

Note: This is a general reference, not a requirement.

B2.4.1.3 Enumerating Serial Devices in Windows

http://www.microsoft.com/hwdev/tech/IO/superio/serddvr.asp

Note: This is a general reference, not a requirement.

B2.4.1.4 DELETED

B2.4.2 Parallel/Serial Devices - Industry Standards

B2.4.2.1 Standard Signaling Method for a Bi-directional Parallel Peripheral Interface for Personal Computers (IEEE 1284 specification)

Global Engineering Documents at http://global.ihs.com/

B2.4.3 Parallel/Serial Devices - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications

B2.4.3.1 Pass WHQL tests - See B1.3

See the “Motherboard” topic in the HCT documentation.

B2.4.4 Parallel/Serial Devices - Windows Experience

Design Guideline References:
Legacy Plug and Play Guidelines

B2.4.4.1 Plug and Play capabilities and operating system compatibility

Implemented as defined in Legacy Plug and Play Guidelines

Note: The following summarizes these legacy requirements, based on Legacy Plug and Play Guidelines:

B2.4.4.1.1 Serial port meets device class specifications for its bus.

B2.4.4.1.2 Legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud.

B2.4.4.1.3 DELETED

B2.4.4.1.4 DELETED

B2.4.4.1.5 Parallel port meets device class specifications for its bus.

B2.4.4.1.6 DELETED

B2.4.4.1.7 DELETED

B2.4.4.1.8 DELETED

B2.4.4.1.9 DELETED

B2.4.4.1.10 IEEE 1284 peripherals have Plug and Play device IDs.

B2.4.4.1.11 DELETED

B2.4.4.1.12 DELETED

B2.4.5 Parallel/Serial Devices - FAQs

See http://www.microsoft.com/winlogo/hardware/

B2.4.R Parallel/Serial Devices - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/

B2.5 PCI Controllers and Devices

All general requirements in B1.0 are included by reference.

B2.5.1 PCI Controllers/Devices - Windows Compatibility

B2.5.1.1 Driver device class support in related DDKs

Bus driver support is built in to Windows; see device class-specific entries in the Windows DDK.

B2.5.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/bus/pci/

Note: This is a general reference, not a requirement.

B2.5.1.3 PCI Device Subsystem IDs and Windows

http://www.microsoft.com/hwdev/bus/pci/pciids.asp

See B2.5.3.2.1

B2.5.1.4 Compatibility Testing for Hot-Plugging Support for PCI Devices

http://www.microsoft.com/hwdev/bus/pci/hotplugpci.asp

Note: This is a general reference, not a requirement.

B2.5.1.5 DELETED

B2.5.1.6 See A1.1.5.3

B2.5.1.7 Correct PCI implementations

If PCI is present in the system, the PCI bus and PCI expansion connectors must meet the requirements defined in the PCI 2.2 specification, plus any additional PCI requirements listed here.

B2.5.3.2.1 Device IDs include PCI Subsystem IDs.

The Subsystem ID (SID) and SVID fields must comply with the SID requirement in PCI 2.2 and the implementation details provided in “PCI Device Subsystem IDs and Windows” at http://www.microsoft.com/hwdev/bus/pci/pciidspec.asp.

AMR devices and MR devices on the system board are not exempt from the requirement for SID and SVID.

B2.5.3.2.2 System does not contain ghost devices.

Bus designs must fully implement all bus requirements on every expansion card connector. A computer must not include any ghost devices, which are devices that do not correctly decode the Type 1/Type 0 indicator. Such a device will appear on multiple PCI buses. A PCI card should be visible through hardware configuration access at only one bus/device/function coordinate.

B2.5.3.2.3 System uses standard method to close base address register (BAR) windows on nonsubtractive decode PCI bridges.

Nonsubtractive decode PCI bridges must implement the standard method to close BAR windows as defined in the PCI to PCI Bridge Architecture Specification Rev. 1.1. Setting the BAR to its maximum value and the limit register to zeros effectively closes the I/O or memory window references in that bridge BAR.

B2.5.3.2.4 See B10.1.4.6

B2.5.3.2.5 DELETED

B2.5.3.2.6 DELETED

B2.5.3.2.7 Configuration Space is correctly populated.

PCI 2.2 describes the configuration space used by the system to identify and configure each device attached to the bus. The configuration space is made up of a header region and a device-dependent region. Each configuration space 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 within 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. Writes to reserved registers must complete normally, and the data must be discarded.

All registers required by the device at interrupt time must be in I/O or memory space.

B2.5.3.2.8 Interrupt routing is supported using ACPI.

The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of ACPI 1.0b (for x86-based systems) and Section 6.2.8 of ACPI 2.0 (for Itanium-based systems). It is important to note that the _PRT object is the only method available for interrupt routing on Itanium-based systems.

B2.5.3.2.9 DELETED

B2.5.3.2.10 DELETED

B2.5.3.2.11 DELETED

B2.5.3.2.12 PCI devices decode only resources found in the Devices BAR.

PCI devices must not decode cycles that are not their own to avoid contention on the PCI bus. Notice that this requirement does not in any way prohibit the standard interfaces provided for by the PCI cache support option discussed in PCI 2.2, which allows the use of a snooping cache coherency mechanism. Auxiliary hardware that is used to provide non-local console support is permitted within the scope of this requirement.

B2.5.2 PCI Controllers/Devices - Industry Standards

B2.5.2.1 PCI Bus Power Management Interface Specification, Revision 1.1 or later

B2.5.2.2 PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges

Details are cited in PCCard-19 of PC Card and CardBus Guidelines, Version 1.1.

B2.5.2.3 PCI Local Bus Specification, Revision 2.2 (PCI 2.2) or later

B2.5.2.4 PCI to PCI Bridge Architecture, Revision 1.1

http://www.pcisig.com/specifications/pci_to_pci_bridge_architecture

B2.5.2.5 PCI-X Specification, Revision 1.0

http://www.pcisig.com/specifications/pci_x

B2.5.2.6 Mini PCI Specification, Revision 1.0

http://www.pcisig.com/specifications/pci_x

B2.5.2.7 PCI Hot-Plug Specification, Revision 1.0

http://www.pcisig.com/specifications/pci_hot_plug

B2.5.3 PCI Controllers/Devices - Quality

WHQL Test Specification References:
Chapter 4: PCI Test Specification

B2.5.3.1 Pass WHQL tests - See B1.3

Search for “PCI” to identify system-specific and device-specific topics in the HCT documentation.

B2.5.3.2 - See B2.5.1.7

B2.5.4 PCI Controllers/Devices - Windows Experience

B2.5.4.1 Power management supported as defined in PCI Bus Power Management Interface Specification, Rev. 1.1 (PCI-PM)

PCI Bus Power Management Interface Specification, Revision 1.1, is the only industry specification that ensures compatibility with the power management capabilities of Windows, which uses PME# as the wakeup signal.

The primary PCI bus controller, PCI-to-PCI bridges, devices that implement PME# must comply with the PCI Bus Power Management Interface Specification, Revision 1.1. PCI add-on devices that do not implement PME# must comply with PCI-PM 1.0.

B2.5.4.1.1 System provides 3.3 V to all PCI connectors.

System supports 3.3 Vaux if the system supports S3 or S4 states for integrated devices that support waking the system and all PCI slots including MiniPCI.

System support for delivery of 3.3Vaux to the PCI bus must be capable of powering a single PCI slot with 375 mA at 3.3V and it must also be capable of powering each of the other PCI slots on the segment with 20 mA at 3.3V whenever the PCI bus is in the B3 state.

System support for delivery of 3.3Vaux to a PCI bus segment must be capable of powering a single PCI slot on that bus segment with 375 mA at 3.3V and it must also be capable of powering each of the other PCI slots on the segment with 20 mA at 3.3V whenever the PCI bus is in the B3 state.

In the case of systems with multiple PCI bus segments, delivering 3.3Vaux to one PCI bus segment does not mean that all PCI bus segments will be required to implement delivery of 3.3Vaux. However, if a system with multiple PCI bus segments provides 3.3Vaux to one or more segments and not to all segments in the system, these capabilities must be clearly marked and documented so that the end user can determine which slots support this capability. Examples of methods for indicating which slots support 3.3Vaux include icons silk-screened on system board sets, slot color-coding, and chassis icons.

Systems must be capable of delivering 375 mA at 3.3V to all PCI slots on a power-managed bus segment whenever the PCI bus is in any “bus powered” state: B0, B1, or B2.

B2.5.4.1.2 PCI add-on cards that use 3.3 Vaux operate correctly, using a method such as the one described in Section 7.4.4 of PCI-PM 1.1.

PCI add-on cards that use 3.3Vaux must operate correctly. This applies when the system supports 3.3Vaux to the PCI connectors.

B2.5.4.1.3 Bus power states are correctly implemented.

The PCI bus and all add-on capable devices on the PCI bus must comply with PCI Bus Power Management Interface Specification, Revision 1.1 or later. This includes correct implementation of the PCI configuration space registers used by power management operations, and the appropriate device state (Dx) definitions for the PCI bus and all add-on-capable devices on the PCI bus. ACPI is not an acceptable alternative.

B2.5.4.1.4 See B7.1.4.4

B2.5.4.2 DELETED

B2.5.4.3 DELETED

B2.5.4.4 DELETED

B2.5.4.5 DELETED

B2.5.5 PCI Controllers/Devices - FAQs

B2.5.5.1 Current PCI-related FAQs

See http://www.microsoft.com/winlogo/hardware/

B2.5.5.2 DELETED

Related requirement deleted.

B2.5.5.3 Updated at B2.5.3.2.1

B2.5.5.4 Updated at B2.5.3.2.1

B2.5.5.5 Updated at B2.5.4

B2.5.5.6 3.3 Updated at B2.5.4

B2.5.R PCI Controllers/Devices - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/.

B2.5.R.1 PCI Subsystem IDs and PCI-to-PCI bridge devices

See "PCI Subsystem IDs and PCI-to-PCI Bridge Devices" at http://www.microsoft.com/hwdev/bus/pci/pcibridge.asp.

B2.5.R.2 Functions in a multifunction PCI device do not share writable PCI Configuration Space bit.

Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI configuration space bits (such as the Command register).

B2.5.R.3 Hot-Plug PCI supported via compatible driver solutions or ACPI

Windows Longhorn supports dynamic enumeration, installation, and removal of PCI devices if the implementation strictly complies with the PCI Standard Hot-Plug Controller and Subsystem Specification (SHPC), Revision 1.0, and the Windows Logo Program requirements for the SHPC driver.

SHPCs that have been designed to meet these requirements do not need any ACPI implementations or vendor-supplied filter drivers. SHPCs will be required for systems running Windows "Longhorn" that provide Hot-Plug PCI support. Other hot-plug implementations will work under Windows only if there is a supported hardware insert/remove notification mechanism, such as a bus standard. An example of an implementation based on an appropriate standards-based notification mechanism is a CardBus bus controller.

For more information about Windows and PCI Hot Plug, see "Hot-Plug PCI and Windows" at http://www.microsoft.com/hwdev/bus/pci/hotplugpci.asp.

B2.5.R.4 PCI 2.3 Interrupt Disable

PCI 2.3 Interrupt Disable is required for Longhorn logo for all devices that are first submitted for logo after January 1st, 2004. All devices being submitted for logo testing must include this capability by January 1st, 2006. See section 6.2 of the PCI Local Bus Specification Revision 2.3.

B2.6 USB Controllers and Devices

All general requirements in B1.0 are included by reference.

Note that related BIOS and system-level requirements are included with the Windows Logo Program requirements for systems, as defined in Appendix A.

B2.6.1 USB Controllers/Devices - Windows Compatibility

B2.6.1.1 WDM support for devices that use the USB bus: "Introduction to USB Drivers" in the Windows DDK

Any device that is connected (externally or internally) to a USB port is tested as a USB device—that is, the device provides the capabilities of one or more functions, a hub to the host, or both. As a result, these requirements apply for any device that is connected to a USB port: the USB specification and any related USB device class specification, plus the Windows Logo Program requirements for USB and the related device class.

B2.6.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/bus/usb/

Note: This is a general reference, not a requirement.

B2.6.1.3 USB Plug and Play IDs and Selecting Device Drivers to Load

http://www.microsoft.com/hwdev/archive/BUSBIOS/usbpnp.asp

Note: This is a general reference, not a requirement.

B2.6.2 USB Controllers/Devices - Industry Standards

B2.6.2.1 OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

http://www.microsoft.com/hwdev/bus/usb/
Universal HCI specification is also accepted.

B2.6.2.2 USB class specifications

http://www.usb.org/developers/devclass.html

B2.6.2.3 USB 1.1 Specification (or later)

http://www.usb.org/developers/docs.html

B2.6.2.4 EHCI: Enhanced Host Controller Interface Specification for Universal Serial Bus

http://www.intel.com/technology/usb/ehcispec.htm

B2.6.3 USB Controllers/Devices - Quality

WHQL Test Specification References:
Chapter 9: USB Test Specification

See B1.3.

B2.6.3.1 Pass all applicable WHQL tests

This includes USB 1.1 Chapter 9 and Chapter 11 tests:

B2.6.3.1.1 DELETED

B2.6.3.1.2 Serial number, if implemented, is unique.

B2.6.3.1.3 Hub correctly reports the number of ports accessible by the user.

See “USB Controllers,” “USB Hubs,” and device-specific and system-specific topics in the HCT documentation.

B2.6.3.2 - See B2.6.3.1

B2.6.4 USB Controllers/Devices - Windows Experience

B2.6.4.1 Devices comply with USB power management requirements

Devices must comply with the power management requirements in the Universal Serial Bus Specification, Revision 1.1.

B2.6.4.2 DELETED

B2.6.4.3 USB host controller can wake the system

The USB host controller must support wakeup capabilities from S1, and S3 states. If the system contains multiple USB host controllers, all host controllers integrated on the system board (that is, not add-on cards) are required to support wakeup from S1, and S3.

B2.6.4.4 Devices and drivers support maximum flexibility of hardware interface options

B2.6.4.4.1 Devices and drivers provide multiple alternate settings.

Devices and drivers must provide multiple alternate settings for each interface where any alternate setting consumes isochronous bandwidth.

B2.6.4.4.2 Devices and drivers must not use isochronous bandwidth for alternate setting 0.

Devices must consume bandwidth only when they are in use.

B2.6.4.5 Devices meet requirements in related USB device class specifications

A USB device or driver that fits into one of the USB device class definitions must comply with the related USB device class specification.

The host controller providing USB 1.1 functionality must comply with the specifications for either OpenHCI: Open Host Controller Interface Specification for USB, or Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1.

See B2.6.1.1

B2.6.4.6 Hub and devices that support USB 2.0 comply with USB 2.0 Specification

If a USB hub or device supports USB 2.0, it must comply with the Universal Serial Bus Specification, Revision 2.0. Host controllers providing USB 2.0 functionality must comply with the Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0.

B2.6.4.7 DELETED

B2.6.4.8 USB hubs are self-powered

This requirement does not apply for hubs integrated into USB keyboards or into mobile systems. To minimize USB power consumption requirements, bus-powered hubs must provide ports that can be individually power switched.

This requirement does not apply for hubs integrated into USB keyboards.

Mobile PC Note: This requirement does not apply for hubs integrated into mobile systems.

B2.6.5 USB Controllers/Devices - FAQs

B2.6.5.1 Current USB-related FAQs

See http://www.microsoft.com/winlogo/hardware/.

B2.6.5.2 Updated at B2.6.1.1

B2.6.R USB Controllers/Devices - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/.

1 ... 8 9 10 11 12 13 14 15 ... 22