1394 Bus Driver in Windows 7

1394 Bus Driver in Windows 7 - 25

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 driver that is included with Windows7 replaces the 1394 bus drivers that were included with earlier versions of Windows. This paper provides information about the differences between the new 1394 bus driver implementation and 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:
http://www.microsoft.com/whdc/connect/1394_Windows7.mspx

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 4

New and Legacy 1394 Bus Drivers 4

Differences in Functional Behavior 5

All I/O Requests Pended 5

Configuration ROM Retrieval 5

IEEE-1394-1995 PHY Support 6

Referencing NODE_DEVICE_EXTENSION 6

Device Driver Interface (DDI) Changes 6

Retrieving the Contents of a 1394 Node’s Configuration ROM 6

Retrieving the Configuration ROM Header 7

New Configuration ROM 7

Previously Retrieved Configuration ROM 8

Gap Count Optimization 8

Modifying the Default Behavior 9

Registry Value Locations 9

Registry Values 9

General DDI Changes 10

1394 DDI Speed and Payload Definitions 10

1394 DDIs with Speed or Payload Changes 11

REQUEST_ASYNC_READ 11

REQUEST_ASYNC_WRITE 11

REQUEST_ISOCH_ALLOCATE_BANDWIDTH 11

REQUEST_ISOCH_ALLOCATE_RESOURCES 12

REQUEST_ISOCH_FREE_BANDWIDTH 12

REQUEST_SET_DEVICE_XMIT_PROPERTIES 12

REQUEST_ASYNC_STREAM 12

REQUEST_ISOCH_MODIFY_STREAM_PROPERTIES 12

REQUEST_GET_SPEED_BETWEEN_DEVICES 13

Determining New or Legacy DDI Support 13

Extended Bus Reset Notification DDIs 13

PHY Packet Support DDIs 14

REQUEST_SEND_PHY_PACKET 14

REQUEST_RECEIVE_PHY_PACKETS 15

Retrieve Configuration ROM DDI 16

Resources 18

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

Differences in 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 do this 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 configuration ROM. 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 configuration ROM header to improve the retrieval of the remaining content of the configuration ROM.

For more information about the logic that the new 1394 bus driver uses to retrieve the contents of a node's configuration ROM, 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 extension is 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, they must 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 drivers must not reference these members.

Device Driver Interface (DDI) Changes

The following are known 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 configuration ROM, which is later used for device enumeration. Processing the contents of a node’s configuration ROM for device discovery has not changed for Windows7 and therefore is not discussed. For more information about how the contents of a node's configuration ROM is processed, see ”IEEE 1394 Bus” in the Windows Driver Kit (WDK).

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

Retrieving the Configuration ROM Header

The first step to retrieve the contents of a node’s configuration ROM is to retrieve the node’s configuration ROM header. The configuration ROM header is in the first five quadlets of a node’s configuration ROM. This header includes the entire contents of the bus information block, as defined in the IEEE-1394a specification.

The new 1394 bus driver tries to retrieve the configuration ROM 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 configuration ROM header.

The speed of communication with a node is determined during retrieval of the node's configuration ROM 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 a particular speed, that speed is used for all 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 configuration ROM header is retrieved, the new 1394 bus driver checks whether the contents of the node’s configuration ROM 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 configuration ROM.

New Configuration ROM

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

The new 1394 bus driver uses the max_rom value in the bus information block of the configuration ROM header to determine the size of the asynchronous read transactions to send to the node to retrieve the remaining contents of the configuration ROM. If any asynchronous read transaction fails—regardless of the max_rom value—the new 1394 bus driver uses asynchronous quadlet read transactions to retrieve the remaining contents of the node’s configuration ROM.

Previously Retrieved Configuration ROM

After the new 1394 bus driver retrieves the contents of a node’s configuration ROM header, it determines whether the header matches the header of one of the cached copies of configuration ROM contents that the driver previously retrieved. If the new 1394 bus driver finds a matching configuration ROM header, then it reuses the cached configuration ROM 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 configuration ROM:

1. Determine whether the node_vendor_id, chip_idhi, and chip_idlo values in the bus information block of the node's configuration ROM header match those same values in the header of one of the driver's cached copies of configuration ROM contents.

2. If a match is found in step 1, then determine whether the generation value in the bus information block also 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 configuration ROM.

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

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

Gap Count Optimization

The default behavior of the new 1394 bus driver is to optimize the gap count when it 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.