Designing Multifunction Devices for Windows Operating Systems

This article presents general guidelines for designing multifunction devices and their drivers for the Microsoft Windows 2000, Windows 95/98, and Windows 98 Second Edition operating systems. A separate article, PC Card and CardBus Multifunction Devices and Windows Compatibility, describes specific design issues for PC Card and CardBus devices.

This article also describes multifunction hardware designs that can prevent the operating system from recognizing each function on the device, assigning the resources they need, and loading the proper drivers. Certain interpretations of the multifunction standard can prevent the operating system from performing these tasks.

This article emphasizes specific driver and implementation issues for Windows 2000, but the general design guidelines apply equally for Windows 95/98.

Note: The guidelines in this article do not apply for printer/fax/scanner class multifunction devices.

On This Page

	Introduction
	Bus Class Requirements for Multifunction Devices
	Windows Requirements for Multifunction Devices
	Drivers for Multifunction Devices
	Multifunction Devices Not Designed to Standards
	Summary
	References

Introduction

A multifunction device occupies one device location on its bus but contains more than one functional unit. Each unit corresponds to a driver (or set of drivers that together service the unit). Examples of multifunction devices include combination modem/network adapters, combination audio/game ports, and so on. Any such device should appear to the operating system as multiple separate devices. For example, an add-on sound card that implements audio and gameport capabilities should appear as two independent devices, one serviced by audio drivers and the other serviced by a gameport driver.

Multiple components that happen to be bundled on the same physical card but together provide a single functional unit are not a multifunction device in this sense. A set of such physical components must appear to the operating system and to the user as a single logical device, regardless of how many physical components provide the functionality. For example, a video card with separate 2D and 3D accelerator ASICs should present itself to the operating system as a single device that would be serviced by a single set of drivers that coordinate all I/O for that card.

Each functional unit must be able to operate as a separate device, even if it happens to be serviced by an instance of the same driver(s) as another functional unit on the device. In particular:

Most hardware buses have specifications for presenting multifunction devices to the operating system. Hardware vendors are highly encouraged to follow such specifications when building multifunction devices.

If a multifunction device conforms to the standard for its underlying bus and to the additional guidelines presented in this article, the operating systemsupplied bus driver can enumerate the separate functional units, assign resources, and load drivers for each functional unit on the device. Operating system components manage the fact that there is more than one functional unit at a single device location. The vendor needs to supply only the appropriate miniport or other class driver and INF file for each functional unit on the multifunction device. The multifunction device itself does not need a separate driver or INF.

Top of page

Bus Class Requirements for Multifunction Devices

To ensure that multifunction devices and their drivers work correctly under Windows 2000 and Windows 95/98, the most important factor is to design the device to the industry specification for the bus on which the device will be installed. By designing to the bus specification, vendors can avoid pitfalls that might prevent the device from easily interoperating with Windows and other devices on the system.

Each bus and device must meet the current Plug and Play specifications and power management requirements related to its class, plus requirements defined in Section 6 of the ACPI 1.0 specification, to ensure that the operating system can configure and manage all devices in the system. This includes requirements for automatic device configuration, resource allocation, and dynamic-disable capabilities.

The current Plug and Play specification versions are as follows:

See also Legacy Plug and Play Guidelines, at http://www.microsoft.com/whdc/system/platform/pcdesign/desguide/pcguides.mspx, for a summary of the Plug and Play requirements for motherboard, Super I/O, and ISA devices that use legacy connections.

For information about Plug and Play driver support under Windows 2000, and driver support under the Windows Driver Model (WDM), see the Windows Driver Development Kit (DDK) documentation.

For additional bus class and device class design notes from Windows development teams, see the white papers available on the Windows Platform Development web site.

Top of page

Windows Requirements for Multifunction Devices

Each functional unit must be able to operate as a separate device, even if it happens to be serviced by an instance of the same driver(s) as another functional unit on the device. The operating system must be able to separately access each logical device that is individually enumerated, configure the device resources independently, and disable individual devices.

For example, each individually enumerated functional unit of a PCI multifunction device is treated as if it were a separate add-in device. This means that, for purposes of operating system compatibility, registers cannot be shared among individually enumerated functional units on a PCI multifunction device, and each devices resource settings must be independently configurable. Built-in operating system support for PCI multifunction devices assumes the existence of a separate, independent configuration space for each functional unit on the device.

Although the manufacturer might wish to conserve silicon by implementing a single configuration space for multiple functional units, the manufacturer would then have to develop specialized drivers for detecting and configuring functions on such a device, because the operating system cannot use built-in mechanisms to manage it. Such specialized drivers inevitably interfere with smooth operation of the system. Microsoft strongly recommends that vendors design multifunction hardware to conform to industry standards and not attempt to compensate for a nonstandard design with software.

To ensure proper configuration under Plug and Play, a multifunction device must have the characteristics described in the following sections.

Unique Device Identifier for Each Functional Unit on the Device

Each separate device on the system board or in a multifunction add-on card must be separately enumerated by the BIOS or the corresponding bus driver; therefore, each must provide a unique device ID in the manner required in the current Plug and Play specification for the bus it uses. For example, a USB device must provide a unique VID/PID as defined in the Universal Serial Bus Specification, Version 1.1 or later.

If a device on an expansion card is enumerated, it must have its own resources and a unique ID according to the current device ID requirements for the bus to which the card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips. For example, each separate device or functional unit enumerated on an audio adapter must have a separate Plug and Play device ID and resource configuration. If a game port or CD-drive interface is supplied, separate resources for the game port and CD-drive interface must be allocated in addition to those required for the audio device. Each unit on the device must have the ability to be independently and dynamically disabled.

Note: In contrast to other multifunction devices, functional units on video cards, such as TV tuners, are presented as children of the video device instead of siblings. It is the job of the video driver to enumerate such functional units. For information, hardware vendors should consult the appropriate industry specification, such as the Advanced Configuration and Power Interface Specification.

A PCI device must comply with PCI 2.2 in providing a Subsystem ID (SID) and Subsystem Vendor ID (SVID) as described in PCI Device Subsystem IDs and Windows. CardBus controllers and CardBus bridges must also define PCI-style Subsystem IDs and Subsystem Vendor IDs, because the operating system treats them as PCI devices. For compatibility with future versions of Windows, Microsoft strongly recommends that vendors define SIDs and SVIDs for all PCI device classes, including those listed as exceptions in the PCI 2.2 specification.

Unique Plug and Play ID Exceptions

The following are exceptions to the requirement for a unique Plug and Play ID:

Independent, Unshared Registers for Each Functional Unit on the Device

Each separate functional unit on a multifunction device must not share addresses or registers with other functional units. For example, there can be no sharing between functions of writable PCI configuration space bits, such as the Command register. This also applies to CardBus controllers, which are treated as multifunction PCI devices. For details about PC Card and CardBus multifunction devices, see PC Card and CardBus Multifunction Devices and Windows Compatibility.

PCI devices can and do share interrupts. For information, see Shared Interrupts in PCI Device Drivers.

No Dependencies on Other Functional Units

One functional unit on a multifunction device must not express its resource requirements in terms of other functional units. In addition, it must meet the following guidelines:

No start-order dependencies. The operating system must be able to configure and manage functions in any order. Therefore, no function on a multifunction device can depend on another device (that is, another function) to be started before the function can be started by the operating system.

For example, suppose a multifunction sound card has a gameport function that depends on the sound driver being loaded in order to operate. The operating system might start the gameport function and load its driver first, and might not start the sound function and load its driver until some later time, or possibly not at all. Under Plug and Play, a device must be able to process operating system requests as soon as the device is started. In this scenario, the gameport would be unable to comply.

No hidden dependencies. Separate functional units must be able to operate concurrently, without interfering with each other or with other devices on the system. For example, a combination V.90 and ADSL broadband modem that uses a single DSP must be able to perform both functions at the same time, because they appear as independent devices to the operating system.

Ability to Manage Power to Each Function Independently of Other Functions

Each functional unit in a multifunction 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, if the modem of a combination NIC/modem adapter is active but theres no network activity, the operating system could power down the NIC while waiting for the modem to finish.

Device requirements are defined in the device class power management reference specifications.

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 the correct implementation of the PCI Configuration Space registers used by power management operations, and the appropriate device state (Dx) definitions.

Each functional unit must be able to successfully complete a system sleep/wake transition (where the unit transitions from D0 to D3cold to D0) without losing functionality and without requiring user intervention to restore functionality. All functional units that support wakeup capabilities must correctly support wake from D3cold.

Top of page

Drivers for Multifunction Devices

If different functions within a multifunction device require separate class driversfor example, a combination PCI network adapter and modemthen the device must be designed to meet the requirements and guidelines described in this article. In particular, multifunction devices that contain functional units from separate classes will not be properly recognized during an operating system upgradeand, therefore, drivers will not be properly upgradedunless unique IDs are provided for each device.

If a multifunction device conforms correctly to these guidelines, the driver for its underlying bus enumerates each individual function, allowing the operating system to load the appropriate driver for each function. The bus driver manages the fact that there is more than one function residing at a single device location. To the rest of the operating system, the individual functions operate as independent devices. If theres built-in operating system support for the functional unit, Windows will load its own driver. For example, the operating systemsupplied USB bus driver supports a USB joystick device. Otherwise, the vendor supplies a driver and INF for the functional unit.

WDM is the recommended driver implementation for Windows 98 and Windows 2000 for all bus classes and device classes that WDM supports, including audio, still and video image capture, streaming, joysticks and other HID input devices, USB, and IEEE 1394. For information about WDM, see WDM Technology.

Driver developers should note several issues in selecting the driver architecture to use:

Top of page

Multifunction Devices Not Designed to Standards

Vendors of multifunction devices should implement a separate configuration space with a unique device ID and independent resources for each function. Such designs take best advantage of the operating systems built-in support for multifunction devices.

The following sections describe common hardware designs that do not conform to multifunction standards and therefore should be avoided. Vendors should not make assumptions about operating system support for such designs.

Problem Design 1: Single Configuration Space with Separate Base Address Registers by Functional Unit

A device of this type has a single PCI configuration space with each functional unit corresponding to one or more base address registers that specify I/O or memory ranges unique to each unit.

Under Windows 2000, PC Card and PCI devices that have this design (including CardBus controllers and CardBus cards) can use the operating systemsupplied multifunction bus driver (Mf.sys). This driver presents the device to the operating system as a bus with children, each child corresponding to a functional unit. The Mf.sys driver splits the devices resource ranges among the functional units and handles operating system device relations and power management requests on their behalf.

For information about how to use Mf.sys, see the Windows DDK.

Problem Design 2: Single Base Address Register for Multiple Functions

A device of this type has a single configuration space with a unique device ID, but the configuration space is overloaded to the point that a single base address register represents resources for more than one functional unit, each unit using a portion of the resource range represented by that BAR.

Writing a driver to compensate for this design is highly complex, because support differs for each version of the Windows operating system. It would require a bus driver that can correctly handle its own device relations, manage power, and coordinate resource use among its children. Developing such a driver usually results in large, long-term support and development costs for the vendor, and is not recommended.

Problem Design 3: Multiple Configuration Spaces for a Single Function

A device of this type has multiple configuration spaces, each with a unique device ID and independent resources, but each configuration space represents part of a single function that should be serviced by a single set of drivers. The operating system wrongly detects each configuration space as a separate, independent device, when in fact such devices should always be used together and should not be independently managed.

For example, a video card might contain a frame buffer, rendering hardware, and an accelerator, each on its own chip. If the vendor implements a configuration space for each chip, the operating system wrongly detects three devices and attempts to independently load three different drivers. Instead, the vendor should implement a single configuration space with separate base address registers for the frame buffer, rendering hardware, and accelerator, allowing the operating system to load the appropriate set of video drivers to service these three items as a single device. For example, under Windows 2000, this set would include Videoprt.sys and a vendor-supplied display driver and video miniport driver.

Problem Design 4: Multifunction Devices with Hidden Dependencies

Devices of this type have some hidden shared resource, which means that the operation of one device affects or inhibits another device in ways that the operating system cannot see or manage.

A current example is a multifunction communication device that implements both V.90 data modem and ADSL broadband modem, using a single DSP. If that particular implementation cannot perform both functions at the same time, even though these are independent from the operating systems point of view, then there is a hidden dependency. User scenarios that require both functions to work independently will fail.

Different interpretations of standards for multifunction devices have resulted in hardware designs that interfere with the operating systems ability to detect individual functions, allocate resources, and load the appropriate drivers. Hardware vendors have attempted to compensate for such designs in the following ways:

Top of page

Summary

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

Top of page

References

Top of page