PC Card and CardBus Multifunction Devices and Windows ...



[pic]Platform Design Notes

Design Tips and News from the Developers of the Microsoft® Windows® Operating Systems

PC Card and CardBus Multifunction Devices and Windows Compatibility

Version 1.0 — April 25, 2000

Abstract

This paper provides the design guidelines for multifunction PC Card devices and their drivers under the Microsoft® Windows® 2000, Windows NT® 4.0, Windows 95/98, and Windows 98 Second Edition operating systems.

Contents

Introduction 3

Classification of Multifunction Cards under PC Card Standards 3

Designing CardBus Multifunction Devices to Standards 4

Common Silicon Configuration Space 4

Required CardBus CIS Tuples 5

Windows Support for PC Card and CardBus Multifunction Devices 6

Power Management for PC Card and CardBus Multifunction Devices 7

Summary 7

References 8

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, IN THIS DOCUMENT.

Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to the patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.

Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a particular purpose, and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret, or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not apply to you.

Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

© 1999 Microsoft Corporation. All rights reserved.

Introduction

A multifunction device occupies a single location on its parent bus, but includes more than one function. Examples of multifunction devices include modem/network adapters, audio/game ports, and so on.

To ensure compatibility with the Windows 95/98 and Windows 2000 operating systems, the most important factor is to design the device to industry specification for the bus on which the device will be installed. By designing to specification, vendors avoid pitfalls that may prevent the device from easily interoperating with Windows and other devices on the system. The key goal is to enable the operating system to recognize the device, assign the resources it needs, and load the proper driver.

For general information about designing multifunction devices for Windows compatibility, see Designing Multifunction Devices for Windows Operating Systems at .

This paper provides guidelines that will help designers develop CardBus and PC Card multifunction devices and drivers that operate correctly under the Windows family of operating systems.

Classification of Multifunction Cards under PC Card Standards

PC Card multifunction devices fall into two main groups: true 16-bit multifunction PC Cards and CardBus 32-bit multifunction PC Cards.

True 16-bit Multifunction PC Card. A true 16-bit multifunction PC Card (sometimes called an “R2” card because it complies with Revision 2 of the PCMCIA specification) is one that has both a multifunction ID and the CISTPL_LONGLINK_MFC tuple in its primary tuple chain, with the locations of the Function Configuration Registers (FCR) for each function defined in the function-specific CIS. This requirement allows a true multifunction PC Card to be controlled independently of its functions.

The classification of a standard 16-bit multifunction PC Card is based on the original design of the PCMCIA Standard, Release 2.1—1991-1994. Lacking specific design instructions, the design of some multifunction PC Cards caused problems under Windows operating systems with interrupt line sharing, independent control of functions, and mapping I/O ports within each function into the host space. These problems are well understood today and hardware can be designed to avoid them. For information about implementing multifunction standards in 16-bit PC Card designs, see .

Windows reads the PC Card tuples to obtain all logical configuration information for a 16-bit PC Card device, including multifunction information and power requirements. For information about the required I/O card tuples that support Plug and Play for 16-bit PC Card devices, see the PC Card information in PC 99 System Design Guide, available at .

PC Card multifunction devices must not share registers, with one exception: The PC Card 16-bit Interface Legacy Mode BAR—offset 44h in the Type 2 PCI header—must be shared among the multiple functional units, just as they must share the same compatibility registers with the Exchangeable Card Architecture (ExCA) programming model, as defined in the PCI to PCMCIA CardBus Bridge Register Description (Yenta specification), written by Intel and available from PCMCIA at .

CardBus 32-bit Multifunction PC Card. A CardBus 32-bit multifunction card follows the PCI addressing scheme that allows multiple functions. The following changes were made to the PC Card Standard to help designers avoid problems with multifunction devices:

• Separate configuration registers for each function.

• Additional configuration registers to define the I/O address range used by each function.

• Minor modifications to existing configuration registers to support sharing the IREQ signal between functions.

• Modifications to Card Services to support individual control and event notification for each function on the multiple I/O function PC Card and to support IREQ sharing.

Requirements for the Common Silicon Configuration Space and required I/O tuples that support Plug and Play for 32-bit CardBus devices are described in the next section.

Designing CardBus Multifunction Devices to Standards

CardBus was designed as a combination of the 16-bit PC Card and PCI in order to gain the benefits of PCI in a PC Card format. Windows support for CardBus places specific design constraints on CardBus cards, as summarized in the following sections.

Common Silicon Configuration Space

CardBus cards must implement a configuration space that meets the Common Silicon guidelines defined in Section 2.6, “CardBus/PCI Common Silicon Requirements,” of the PC Card Standard, Volume 10: Guidelines (available from PCMCIA; see ). CardBus controllers must also implement a Common Silicon configuration space.

The Common Silicon configuration space is a PCI-like configuration space that is not fully compliant with the PCI specification. Specifically, under the CardBus standard, card vendors do not have to implement certain critical fields—described in the PC Card standard as “allocated”—in the configuration space. The PC Card standard guidelines for silicon common to both PCI and CardBus products recommend the implementation of these fields.

However, because the PCI component in Windows performs CardBus configuration, Windows needs the allocated fields to be implemented on CardBus devices. Windows supports only CardBus devices whose configuration space meets the Common Silicon guidelines, to maintain compatibility with existing PCI system software and drivers. Without the allocated fields (listed in Table 1), the cards cannot be fully treated as PCI devices and cannot be supported under Windows.

Table 1. Required Allocated Fields

|Field |Description and comments |

|Vendor ID |This read-only field contains a unique ID (in PCI space) for the card manufacturer. The PCI SIG assigns a |

| |single unique ID to a vendor. |

|Device ID |These read-only fields are vendor-assigned values that uniquely identify the device among all vendors of |

|Revision ID |PCI or CardBus products. |

|Class Code |This read-only field is defined in PCI 2.1. It describes what type of device the card is. |

|Max_Lat |These read-only fields specify the desired settings for Latency Timer values according to PCI 2.1. A value|

|Min_Gnt |of 0 indicates the device has no major requirements for the settings of Latency Timers. |

|Interrupt Line |This register must be read-write and must not be connected to anything, just as on PCI cards. This |

| |register is used to store the current IRQ routing for the device. |

Note: These field have been listed as “Required ‘Allocated’ Fields” in the PC Design Guides since PC 97 Hardware Design Guide, and have been required under the Windows Logo Program since July 1, 1997.

The CardBus specification also lists two RESERVED fields (offset 2C in the Configuration Space), which are defined in PCI 2.1 and later specifications as the Subsystem ID and Subsystem Vendor ID (SID and SVID; see Table 2). All PCI devices must implement these fields for Plug and Play compatibility with Windows; therefore, these fields are also required of CardBus cards. For more information about the requirements to provide a Subsystem ID and Subsystem Vendor ID for Windows compatibility, see the paper PCI Device Subsystem IDs at .

Table 2. Required RESERVED Fields

|Field |Description |

|Subsystem ID |Unique value determined by the vendor. |

|Subsystem Vendor ID |Unique vendor ID assigned by the PCI SIG. |

Note: These field have been listed as “Required Reserved Fields” in the PC Design Guides since PC 97 Hardware Design Guide, and have been required under the Windows Logo Program since July 1, 1997.

Required CardBus CIS Tuples

Table 3 summarizes the set of card tuples recommended in the PC Card guidelines. Microsoft strongly recommends that Cardbus hardware vendors implement all recommended card tuples for compatibility with future versions of Windows.

Windows 2000 currently accesses only the Common Silicon configuration space and ignores the CardBus tuples.

Currently, Windows 9x reads CardBus tuples only to determine power requirements and obtains all other configuration information for the device from its Common Silicon configuration space. If there are no tuples on a CardBus card, the power is assumed to be the voltage sense power defined by the connector pins. For all CardBus cards today this should be 3.3V.

A CardBus device must indicate power requirements other than 3.3V with an appropriate Power Description structure in the CISTPL_CFTABLE_ENTRY_CB tuple. CardBus cards can have two different voltages at the same time: Vcc and Vpp. By definition, Vcc of CardBus cards can be 3.3V, X.XV or Y.YV. The X.X and Y.Y settings are reserved for future use, so all CardBus cards today have a Vcc of 3.3V. Vpp can be 3.3V, 5V, or 12V; however, the Vpp pin is global to the card, which means that all functions on a multifunction CardBus card must specify the same Vpp value. In other words, one function’s tuple cannot request a Vpp of 5V and another function’s tuple request a Vpp of 12V.

Table 3. Required CardBus Tuples

|Tuple ID |Tuple code |Comments |

|04h |CISTPL_CONFIG_CB |— |

|05h |CISTPL_CFTABLE_ENTRY_CB |— |

|07h |CISTPL_BAR |— |

|13h |CISTPL_LINKTARGET |Required as first tuple in PC Card standard. |

|15h |CISTPL_VERS_1 |— |

|20h |CISTPL_MANFID |— |

|FFh |CISTPL_END |Required as end-of-chain tuple in PC Card standard. |

|21h |CISTPL_FUNCID |Recommended in PC Card standard; required in PC Design Guides. |

Note: These fields have been listed as “Required Tuples for CardBus” in the PC Design Guides since PC 97 Hardware Design Guide, and have been required under the Windows Logo Program since July 1, 1997.

Windows Support for PC Card and CardBus Multifunction Devices

If a device implements the related standards correctly, the vendor can rely on Windows system-supplied files to handle enumeration and resource allocation. The vendor needs only to provide a function driver and INF for each function of the device.

The important design consideration is that the device fully complies with PCI 2.1 or later, and that each device—and each function on a multifunction device—provides a Subsystem ID and Subsystem Vendor ID as described in the article at .

Windows 95/98. Under Windows 98 and Windows 95 OSR 2.x, the following system-supplied files are used to install, configure, and control 16-bit PC Card and CardBus cards.

• Socketsv.vxd: Driver for 16-bit PC Card socket controllers.

• Cbss.vxd: Driver for CardBus controllers.

• Pccard.vxd: Bus enumerator for 16-bit PC Cards (R2 cards).

• Pci.vxd: Bus enumerator for PCI devices, including CardBus cards.

• Configmg.vxd: Resource configuration manager.

Windows 2000. Under Windows 2000, the PCI bus driver (Pci.sys) enumerates individual functions and manages the fact that more than one function resides at a single device location.

Windows 2000 provides limited support for PC Card devices that do not completely conform to the multifunction standard, such as 16-bit PC cards that have incomplete configuration register addresses or incomplete configuration registers. Vendors of such devices can use the system-supplied multifunction bus driver (Mf.sys) and must provide a custom INF file for the multifunction device in addition to the usual drivers and INF files for individual functions. New hardware should be designed to conform to the multifunction standard, so that vendors can take advantage of built-in operating system support for multifunction PC Card devices and do not need to supply additional custom INF files for their devices.

For details about Windows 2000 support for multifunction devices, see the Windows 2000/WDM DDK documentation under Setup, Plug & Play, Power Management -> Design Guide -> Part 2: Plug and Play -> 5.0 Supporting Multifunction Devices.

Power Management for PC Card and CardBus Multifunction Devices

Under both Windows 98 and Windows 2000, each device in a multifunction add-on device must separately meet the power management device class specifications for its device class and be independently power managed. This means that the operating system must be able to power manage each function as if it were a separate, independent device. For example, each driver that owns device power policy for a function on a multifunction add-on card can separately register for idle detection and separately handle the operating system's set-power request to power down the function when it is idle. When all functions on the card are idle and can safely be powered down, the parent bus driver reduces power to the multifunction add-on card.

Any 16-bit PC Card device that is capable of signaling a wake-up event to the system, as defined in the Device Class Power Management Reference Specification for its class, must implement the ReqAttn bit and its associated enable bit in the Extended Status register and must signal on the #STSCHG line.

CardBus cards must comply with the requirements defined in PCI Bus Power Management Interface Specification, Revision 1.1 or later. Each device must also comply with the requirements defined in the Device Class Power Management Reference Specification for its class.

The CardBus card must use the CSTSCHG pin to signal wake-up events, 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.

Windows 2000 does not currently support wake-up from either 16-bit PC Cards or CardBus cards. Windows 98 Second Edition supports only wake-on-ring specific to the BIOS implementation on certain laptops. However, Microsoft strongly recommends that capable devices implement signaling of wake-up events, for compatibility with future versions of Windows.

Device Class Power Management Reference Specifications are available at .

Summary

To design a PC Card or CardBus multifunction device for compatibility with Windows operating systems, hardware vendors should do the following:

• Design multifunction PC Card and CardBus devices completely and correctly to the PC Card Standard.

• Follow the guidelines presented in Designing Multifunction Devices for Windows Operating Systems at .

• Implement all recommended tuples for 16-bit PC Card devices.

• Implement all recommended tuples and a Common Silicon configuration space for all CardBus devices, including CardBus controllers.

• Implement signaling of wake-up events for capable devices.

References

• Designing Multifunction Devices for Windows Operating Systems at:



• Windows 2000 Driver Development Kit (DDK) documentation

available on

support for multifunction devices under Setup, Plug & Play, Power Management -> Design Guide -> Part 2: Plug and Play -> 5.0 Supporting Multifunction Devices

• PCI Device Subsystem IDs and Windows at:



• Multiple Function PC Cards at:



• PC Card Standard:

available from PCMCIA on

• PC 99 System Design Guide:

available at

• PCI to PCMCIA CardBus Bridge Register Description (Yenta specification):

available from PCMCIA at

• PCI Bus Power Management Interface Specification, Revision 1.1:

available from PCI at

• Device Class Power Management Reference Specifications:

available at

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download