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.
|
