1394 Bus Driver in Windows 7 - 1

1394 Bus Driver in Windows 7 - 1

1394 Bus Driver in Windows 7

June 18, 2009

Abstract

This paper provides information about IEEE 1394 support in Windows®7. It provides information for 1394 developers to understand the new 1394 bus driver in Windows7.The 1394 bus driver was rewritten for Windows7 to provide support for higher speeds and alternative media, as defined in the IEEE-1394b specification. The 1394 bus driverthat is included with Windows7replaces the 1394 bus driversthat were included with earlier versions of Windows. This paper provides information about the differences between the new 1394 bus driver implementationand the earlier implementation, as well as information about the new functionality that is included in the 1394 bus driver for Windows7.

This information applies to the Windows7 operating system.

References and resources discussed here are listed at the end of this paper.

The current version of this paper is maintained on the Web at:

Disclaimer: This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

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 after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

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

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, MSDN, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Document History

Date / Change
June 18, 2009 / First publication

Contents

Introduction

New and Legacy 1394 Bus Drivers

Differences in Functional Behavior

All I/O Requests Pended

Configuration ROM Retrieval

IEEE-1394-1995 PHY Support

Referencing NODE_DEVICE_EXTENSION

Device Driver Interface (DDI) Changes

Retrieving the Contents of a 1394 Node’s Configuration ROM

Retrieving the Configuration ROM Header

New Configuration ROM

Previously Retrieved Configuration ROM

Gap Count Optimization

Modifying the Default Behavior

Registry Value Locations

Registry Values

General DDI Changes

1394 DDI Speed and Payload Definitions

1394 DDIs with Speed or Payload Changes

REQUEST_ASYNC_READ

REQUEST_ASYNC_WRITE

REQUEST_ISOCH_ALLOCATE_BANDWIDTH

REQUEST_ISOCH_ALLOCATE_RESOURCES

REQUEST_ISOCH_FREE_BANDWIDTH

REQUEST_SET_DEVICE_XMIT_PROPERTIES

REQUEST_ASYNC_STREAM

REQUEST_ISOCH_MODIFY_STREAM_PROPERTIES

REQUEST_GET_SPEED_BETWEEN_DEVICES

Determining New or Legacy DDI Support

Extended Bus Reset Notification DDIs

PHY Packet Support DDIs

REQUEST_SEND_PHY_PACKET

REQUEST_RECEIVE_PHY_PACKETS

Retrieve Configuration ROM DDI

Resources

Introduction

The 1394 bus driver was rewritten for Windows®7 to add support for higher speeds and alternative media as defined in the IEEE-1394b specification. This paper refers to the Windows7 version of the 1394 bus driver as the new 1394 bus driver and the earlier version of the 1394 bus driver as the legacy 1394 bus driver.

This paper provides the following information about the new 1394 bus driver:

• Design and implementation differences between the new 1394 bus driver and the legacy 1394 bus driver.
• Behavior of the new 1394 bus driver.
• Changes to the device driver interfaces (DDIs) for the new 1394 bus driver.

This paper assumes that you are familiar with 1394 technology and its corresponding implementation for Windows. It also assumes that you are familiar with the basic terminology that is related to Windows kernel-mode device drivers as well as basic knowledge of the 1394 DDIs and their corresponding I/O request blocks (IRBs). For more information about 1394 and Windows kernel-mode device drivers, see “Resources”at the end of this paper.

New and Legacy 1394 Bus Drivers

The new 1394 bus driver is a single (monolithic) device driver, 1394OHCI.SYS, which was implemented by using the kernel-mode driver framework (KMDF). The legacy 1394 bus driver included multiple device drivers that were implemented by using the Windows Driver Model (WDM)in a port/miniport configuration. The port driver is 1394BUS.SYS,and the primary miniport driver is OHCI1394.SYS. Figure 1 compares the new and the legacy 1394 bus drivers.

Figure 1. Legacy versus new 1394 bus drivers

Figure 2 shows the 1394 stack with the new 1394 bus driver and the Microsoft-supported 1394 client drivers.

Figure 2. 1394 Driver Stack

Differencesin Functional Behavior

The new 1394 bus driver was designed to be fully backward compatible with the legacy 1394 bus driver. This section describes some of the known differences in behavior between the new 1394 bus driver and the legacy 1394 bus driver.

All I/O Requests Pended

All I/O requests that are sent to the new 1394 bus driver return STATUS_PENDING. This differs from the behavior of the legacy 1394 bus driver, where certain I/O requests complete immediately.

This change in behavior is because the new 1394 bus driver is implemented by using KMDF instead of WDM.

Client device drivers must wait until I/O requests that are sent to the new 1394 bus driver complete. You can dothis by using an I/O completion routine. The status of the completed I/O request is in the IRP.

Configuration ROM Retrieval

The new 1394 bus driver tries to use asynchronous block transactions at higher bus speeds to retrieve the contents of a node’s configurationROM. This differs from the behavior of the legacy 1394 bus driver, which uses asynchronous quadlet reads at S100 speed—or 100megabits per second (Mbps).

The new 1394 bus driver also uses the values that are specified in the generation and max_rom entries in the node’s configurationROMheader to improve the retrieval of the remainingcontent of the configurationROM.

For more information about the logic that the new 1394 bus driver uses to retrieve the contents of a node's configurationROM, see “Retrieving the Contents of a 1394 Node’s Configuration ROM” later in this paper.

IEEE-1394-1995 PHY Support

The new 1394 bus driver requires a physical layer (PHY) that supports IEEE-1394a or IEEE-1394b. It does not support a PHY that supports IEEE-1394-1995. This requirement is because of the new 1394 bus driver’s exclusive use of short (arbitrated) bus resets.

Referencing NODE_DEVICE_EXTENSION

Some client device drivers reference the device extension in the 1394 bus driver that is associated with the physical device object (PDO) for the device. This device extensionis described by the NODE_DEVICE_EXTENSION structure. In the new 1394 bus driver, this structure remains at the same location as in the legacy 1394 bus driver, but the nonstatic members of the structure might not be valid. When client device drivers use the new 1394 bus driver, theymust ensure that the data that they access in this structure is valid. The static members of the NODE_DEVICE_EXTENSION structure that contain valid data are Tag, DeviceObject, and PortDeviceObject. All other members of the NODE_DEVICE_EXTENSION structure are not static. Client device driversmust not reference these members.

Device Driver Interface (DDI) Changes

The following areknown changes in functional behavior of the 1394 DDIs between the new 1394 bus driver and the legacy 1394 bus driver:

REQUEST_GET_LOCAL_HOST_INFO

In the new 1394 bus driver, setting nLevel to GET_HOST_CSR_CONTENTS and specifying the SPEED_MAP_LOCATION as CsrBaseAddress is not supported. The speed map is obsolete in the IEEE-1394a specification.

REQUEST_GET_SPEED_TOPOLOGY_MAPS

This DDI has been obsolete since Windows 2000. Calling this DDI on the new 1394 bus driver returns STATUS_INVALID_PARAMETER.

REQUEST_GET_SPEED_BETWEEN_DEVICES

In the new 1394 bus driver, this DDI returns only the speed between the local node and the device. The USE_LOCAL_NODE flag must be set in the u.GetMaxSpeedBetweenDevices.fulFlags parameter.

Retrieving the Contents of a 1394 Node’s Configuration ROM

This section provides details about how the new 1394 bus driver retrieves the contents of a node’s configurationROM, which is later used for device enumeration. Processing the contents of a node’s configurationROM for device discovery has not changed for Windows7 and therefore is not discussed. For more information about how the contents of a node's configurationROM is processed, see ”IEEE 1394 Bus” in the Windows Driver Kit (WDK).

The new 1394 bus driver retrieves the contents of a node’s configurationROM after a 1394 bus reset by sending asynchronous read transactions to the node. The new 1394 bus driver tries to minimize the number of asynchronousread transactions that are sent to a nodeto retrieve the contents of the node's configurationROM.

Retrieving the Configuration ROM Header

The first step to retrievethe contents of a node’s configurationROM is to retrieve the node’s configurationROM header. The configurationROM header is inthe first five quadlets of a node’s configurationROM.This header includes the entire contents of the businformation block, as defined in the IEEE-1394a specification.

The new 1394 bus driver tries to retrieve the configurationROM header in a single asynchronous block read transaction. However, certain 1394 devices fail to respond to this transaction correctly. In this situation, the new 1394 bus driver uses five asynchronous quadlet read transactions to retrieve the configurationROM header.

The speed of communication with a node is determined during retrieval of the node's configurationROM header. The new 1394 bus driver sends the asynchronous read transaction to the node at the highest supported speed and considers any slower nodes between the local node and the target node. If the asynchronous read transaction fails to complete successfully at the highest supported speed, then the new 1394 bus driver sends another asynchronous read transaction to the node at a slower speed. The new 1394 bus driver continues to send asynchronous read transactions to the node at slower and slower speeds until a transaction completes successfully. After the asynchronous transaction completes successfully at aparticular speed,that speed is used forall further communication with the node until another 1394 bus reset occurs. If the asynchronous read transaction fails to complete at the slowest possible speed, then the new 1394 bus driver fails to retrieve the contents of the node’s configuration ROM.

After the configurationROM header is retrieved, the new 1394 bus driver checks whether the contents of the node’s configurationROM were previously retrieved. If so, the new 1394 bus driver can reuse its cached version. Otherwise, the new 1394 bus driver must retrieve the remaining contents of the node’s configurationROM.

NewConfiguration ROM

If the new 1394 bus driver determines that the contents of the node’s configurationROM was not previously retrieved, it proceeds to retrieve the remainingcontents of the node’s configurationROM.

The new 1394 bus driver uses the max_romvalue in the businformation block of the configuration ROM header to determine the size of the asynchronous read transactions to send to the nodeto retrieve the remaining contents of the configuration ROM. If any asynchronous read transaction fails—regardless of the max_romvalue—the new 1394 bus driver uses asynchronousquadlet read transactions to retrieve the remaining contents of the node’s configurationROM.

Previously Retrieved Configuration ROM

After the new 1394 bus driver retrieves the contents of a node’s configurationROM header, it determines whether the headermatches the header of one of the cached copies of configurationROMcontents that the driver previously retrieved. If the new 1394 bus driver finds a matching configurationROM header, then it reuses the cached configurationROM contents.

The new 1394 bus driver uses the following steps to determine whether it can reuse a cached copy of the contents of a node's configurationROM:

1.Determine whetherthe node_vendor_id, chip_idhi, and chip_idlo values in the businformation block of the node's configurationROM header match those same values in the header of one of thedriver's cached copies of configurationROM contents.

2.If a match is found in step 1, then determine whether the generation value in the businformation blockalso matches. If the generation value has not changed (or if it is set to 1, which indicates that it never changes), then the driver reuses the cached contents of the configurationROM.

You can find descriptions of the configurationROM values in the preceding steps in the IEEE1394 specifications.

If the new 1394 bus driver fails to find a matching cached configurationROM header or if it must reread the contents of the node’s configurationROM because the generation value changed, then it follows the preceding steps to retrievethe contents of a new configurationROM.

Gap Count Optimization

The default behavior of the new 1394 bus driver is to optimize the gap count whenit finds only IEEE1394a devices on the 1394 bus, excluding the local node. For example, if the system that is running the new 1394 bus driver has a host controller that complies with IEEE1394b but all devices on the bus comply with IEEE1394a, then the new 1394 bus driver tries to optimize the gap count.

Gap count optimization occurs only if the new 1394 bus driver determines that the local node is the bus manager.

The new 1394 bus driver determines whether a device complies with IEEE-1394a by the speed setting in the node’s self-id packet. If a node sets both of the bits in the speed (sp) field in the self-id packet, then the new 1394 bus driver considers the node to comply with IEEE-1394b. If the speed field contains any other value, then the new 1394 bus driver considers the node to comply with IEEE-1394a.

The gap count value that is used is based on table E-1 in the IEEE-1394a specification, which provides the gap count as a function of hops. The new 1394 bus driver does not compute the gap count.

You can change the default gap count behavior by using a registry value. For more information, see the following section,”Modifying the Default Behavior.”

Modifying the Default Behavior

We understand that in some situationsyou might want to override the default behavior of the new 1394 bus driver. Youcan do this by setting certain registry values that the new 1394 bus driver supports.

Registry Value Locations

You can set the 1394-related registry values either globally for all 1394 controllers in the system or individually for each 1394 controller. The new 1394 bus driver first queries the global 1394 registry values and then queries the individual 1394 controller registry values.

The following location in the registry contains the global 1394 registry values:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1394ohci

\Parameters

The following location in the registry contains the individual 1394 controller registry values:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class

\{6BDD1FC1-810F-11D0-BEC7-08002BE2092F}\NNNN

<NNNN> represents the instance identification number for each individual 1394 controller.

Registry Values

Table 1 describes the registry values that the new 1394 bus driver supports.You can specify all registry values either globally or for a particular 1394 controller. Any registry values that are specified for a particular 1394 controller override any corresponding globally specified registry values.

Table 1. 1394 Registry Values

Name / Type / Value / Default / Description
DisableGenerationCountCompare / DWORD / 0 or 1 / 0 / The new 1394 bus driver compares the generation count value in the self_id register of the 1394 controller with the generation count value that is received in the asynchronous receive DMA request context buffer when it processes received asynchronous requests. Setting this value to 0 enables generation count comparison. Setting this value to 1 disables generation count comparison.
UseQuadletReadsForEnumeration / DWORD / 0 or 1 / 0 / Setting this value to 0 enables the default method for retrieving the contents of the configurationROM. Setting this value to 1 causes the new 1394 bus driver to use asynchronous quadlet read transactions to retrieve the contents of the configurationROM.
EnumerateIP1394 / DWORD / 0 or 1 / 0 / Setting this value to 0 disables enumeration of IP1394 devices on the 1394 bus. Setting this value to 1 enables enumeration of IP1394 devices on the 1394 bus.
EnableGapCountOptimization / DWORD / 0 or 1 / Optimize for 1394a topology
only / Setting this value to 0 disables gap count optimization. Setting this value to 1 enables gap count optimization.
Note: Enabling gap count optimization optimizesthe gap count for all 1394 bus topologies, including 1394b. The gap count value that is used is based on the table method, as specified in the IEEE-1394a specification. Endusersmust ensure that the gap count that is used is valid for their 1394 bus topology.
EnablePersistentCycleStarts / DWORD / 0 or 1 / 0 / Setting this value to 0 disables cycle start packets if no isochronous-capable nodes are found on the 1394 bus. Setting this value to 1 enables cycle start packets regardless of whether isochronous-capable nodes are found on the 1394 bus.
Note:The new 1394 bus driver disables and enables cycle start packets only if the local node is the bus manager.

GeneralDDI Changes

For Windows7, the 1394 DDIs were changed to support greater speeds as defined by the 1394b specification and enhanced to simplifythe development of 1394 client drivers.

This section describes the general DDI changes that the new 1394bus driver supports. For more information about these 1394 DDIs, see the WDK.

1394 DDI Speed and Payload Definitions

Beginning with the Windows7 WDK, the 1394 header file,1394.h,includes definitions for higher speeds and greater sized payloads. The following tables describe these new flags and values.