다음을 통해 공유

Windows 7: 1394 Bus Driver

  • 아티클

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 Windows 7. The 1394 bus driver was rewritten for Windows 7 to provide support for higher speeds and alternative media, as defined in the IEEE-1394b specification. The 1394 bus driver that is included with Windows 7 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 Windows 7.

This information applies to the Windows 7 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.

Contents

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 Windows 7 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 100 megabits 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 Windows 7 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_id‑hi, and chip_id‑lo 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 IEEE‑1394 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 IEEE‑1394a 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 IEEE‑1394b but all devices on the bus comply with IEEE‑1394a, 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 situations you might want to override the default behavior of the new 1394 bus driver. You can 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 gene­ration 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 configuration ROM. Setting this value to 1 causes the new 1394 bus driver to use asynchronous quadlet read transactions to retrieve the contents of the configuration ROM.
EnumerateIP1394 DWORD 0 or 1

0

 Setting this value to 0 disables enumera­­tion 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 optimizes the 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. End users must 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.

General DDI Changes

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

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

1394 DDI Speed and Payload Definitions

Beginning with the Windows 7 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.

Table 2 describes the maximum asynchronous payload size for each of the newly supported speeds.

Table 2. Asynchronous Payload Size

Name Value Description
ASYNC_PAYLOAD_800_RATE 4096 800 Mb/s
ASYNC_PAYLOAD_1600_RATE 4096  160 Mb/s
ASYNC_PAYLOAD_3200_RATE 4096 3,200 Mb/s

 Table 3 describes the speed flags for each of the newly supported speeds.

Table 3. Speed Flags

Name Value Description
SPEED_FLAGS_800 0x08  800 Mb/s
SPEED_FLAGS_1600 0x10 1,600 Mb/s
SPEED_FLAGS_3200 0x20 3,200 Mb/s

Table 4 describes the speed code values for each of the newly supported speeds.

Table 4. Speed Codes

Name Value Description
SCODE_800_RATE 3 800 Mb/s
SCODE_1600_RATE 4 1,600 Mb/s
SCODE_3200_RATE 5 3,200 Mb/s

1394 DDIs with Speed or Payload Changes

 

The following is a list of the 1394 I/O requests that use the new speed and payload size values that were described earlier in this paper:

REQUEST_ASYNC_READ

u.AsyncRead.nBlockSize

Specifies the size of each individual block within the data stream that is read as a whole from the 1394 node. If this parameter is zero, the maximum packet size for the device and speed selected is used to issue these read requests. 

You can specify the new values in Table 2 for the nBlockSize parameter. We recommend that client drivers set the nBlockSize parameter to 0 so that the 1394 bus driver uses the maximum supported value.

REQUEST_ASYNC_WRITE

u.AsyncWrite.nBlockSize

Specifies the size of each individual block within the data stream that is written as a whole to the 1394 node. If this parameter is zero, then the maximum packet size for the selected speed is used to divide these write requests. 

You can specify the new values in Table 2 for the nBlockSize parameter. We recommend that client drivers set the nBlockSize parameter to 0 so that the 1394 bus driver uses the maximum supported value.

REQUEST_ISOCH_ALLOCATE_BANDWIDTH

u.IsochAllocateBandwidth.fulSpeed

Specifies the connection speed to use to allocate bandwidth. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps.

u.IsochAllocateBandwidth.SpeedSelected

Specifies the actual speed that is selected to allocate bandwidth. The value is one of SPEED_FLAGS_xxx (see the fulSpeed member description). 

You can specify the new values in Table 3 for the fulSpeed parameter. The new 1394 bus driver can return the new values in Table 3 in the SpeedSelected parameter.

REQUEST_ISOCH_ALLOCATE_RESOURCES

u.IsochAllocateResources.fulSpeed

Specifies the connection speed to use to communicate on the channel. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps. 

You can specify the new values in Table 3 for the fulSpeed parameter.

REQUEST_ISOCH_FREE_BANDWIDTH

u.IsochFreeBandwidth.fulSpeed

Specifies the connection speed to use to free bandwidth. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps. 

You can specify the new values in Table 3 for the fulSpeed parameter.

The new 1394 bus driver uses the fulSpeed parameter only when the IRB_FLAG_ALLOW_REMOTE_FREE flag is set and the IRB_FLAG_USE_PRE_CALCULATE_VALUE flag is not set in the Flags parameter of the IRB. In all other situations, the new 1394 bus driver ignores the fulSpeed parameter.

REQUEST_SET_DEVICE_XMIT_PROPERTIES

u.SetDeviceXmitProperties.fulSpeed

Specifies the maximum speed for transactions to the device. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps. 

You can specify the new values in Table 3 for the fulSpeed parameter.

REQUEST_ASYNC_STREAM

u.AsyncStream.nSpeed

Specifies the transfer rate. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps. 

You can specify the new values in Table 3 for the nSpeed parameter.

REQUEST_ISOCH_MODIFY_STREAM_PROPERTIES

u.IsochModifyStreamProperties.fulSpeed

Specifies the maximum speed for transactions to the device. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps. 

You can specify the new values in Table 3 for the fulSpeed parameter.

REQUEST_GET_SPEED_BETWEEN_DEVICES

u.GetMaxSpeedBetweenDevices.fulSpeed

Specifies the maximum possible transaction speed between the source device and the set of destination devices. The returned value is the maximum speed that all devices simultaneously support. The possible speed values are SPEED_FLAGS_xxx, where xxx is the (approximate) transfer rate in mbps.

You can return the new values in Table 3 in the fulSpeed parameter.

A client driver can also specify USE_SCODE_SPEED flag in the u.GetMaxSpeedBetweenDevices.fulFlags parameter to request that an SCODE_xxx_RATE speed code value, as defined in Table 4, be returned in the fulSpeed parameter instead of a SPEED_FLAGS_xxx value.

Determining New or Legacy DDI Support

A new nLevel value, GET_HOST_DDI_VERSION, has been added to the REQUEST_GET_LOCAL_HOST_INFO I/O request to return the version of the DDIs that the 1394 bus driver supports. This nLevel value is described in Table 5.

Table 5. New REQUEST_GET_LOCAL_HOST_INFO nLevel value

nLevel value Description
GET_HOST_DDI_VERSION Returns the DDI version of the 1394 bus driver.

You can use the REQUEST_GET_LOCAL_HOST_INFO I/O request with this new nLevel value to determine whether the 1394 bus driver is the new 1394 bus driver or the legacy 1394 bus driver. The legacy 1394 bus driver returns a status value of STATUS_INVALID_PARAMETER if the nLevel parameter is set to GET_HOST_DDI_VERSION. The new 1394 bus driver returns a status value of STATUS_SUCCESS.

If you set the u.GetLocalHostInformation.nLevel parameter to GET_HOST_DDI_VERSION, then the u.GetLocalHostInformation.Information parameter must point to a data structure of the following type:

typedef struct _GET_LOCAL_HOST_INFO8 {

USHORT MajorVersion;

USHORT MinorVersion;

} GET_LOCAL_HOST_INFO8, *PGET_LOCAL_HOST_INFO8; 

The new 1394 bus driver sets the MajorVersion and MinorVersion members of this structure to the values in Table 6.

Table 6. DDI Version Values

Name Description
BUS1394_DDI_MAJOR_VERSION The major version of the 1394 bus driver interface.
BUS1394_DDI_MINOR_VERSION The minor version of the 1394 bus driver interface.

Extended Bus Reset Notification DDIs

The new 1394 bus driver supports an extended bus reset notification. This notification returns information about the current generation of the bus, such as the generation count and node ids, to 1394 client drivers in the context of the bus reset notification.

This information can eliminate the need for a 1394 client driver to synchronize the retrieval of the generation count, node ids, and other information, with its bus reset notification handler.

To register for extended bus reset notifications, a client driver uses the existing REQUEST_BUS_RESET_NOTIFICATION I/O request and specifies the new EXTENDED_NOTIFICATION_ROUTINE flag in the u.BusResetNotification.fulFlags parameter.

When the EXTENDED_NOTIFICATION_ROUTINE flag is specified, then the Context parameter that is passed to the ResetRoutine points to a data structure of the following type:

typedef struct _BUS_RESET_DATA {

PVOID ResetContext;

ULONG GenerationCount;

NODE_ADDRESS DeviceNodeId;

NODE_ADDRESS LocalNodeId;

UCHAR SpeedToNode;

} BUS_RESET_DATA, *PBUS_RESET_DATA;

Members

ResetContext

The argument that is specified in the u.BusResetNotification.ResetContext parameter when the REQUEST_BUS_RESET_NOTIFICATION request is sent.

GenerationCount

The current generation of the 1394 bus.

DeviceNodeId

The 1394 address for the device.

 LocalNodeId

The 1394 address for the local host.

SpeedToNode

The negotiated speed to the device. This value is a speed code value, as defined in Table 4. 

PHY Packet Support DDIs

The new 1394 bus driver includes new DDIs for sending and receiving PHY packets, as defined in the IEEE-1394a specification.

You should use the new REQUEST_SEND_PHY_PACKET I/O request instead of REQUEST_SEND_PHY_CONFIG_PACKET. The latter I/O request did not allow for specifying the generation count, which could result in a PHY packet being sent to the wrong generation of the 1394 bus.

REQUEST_SEND_PHY_PACKET

This is a new DDI to send 1394 PHY packets. It replaces the REQUEST_SEND_PHY_CONFIG_PACKET DDI.

The following are the relevant members of the IRB for this request:

typedef struct _IRB {

 ULONG FunctionNumber;

 .

 .

 .

 union {

 struct {

 ULONG Flags; 

 ULONG GenerationCount; 

 ULARGE_INTEGER  PhyPacket;

 } SendPhyPacket;

 .

 .

 .

 } u;

} IRB; 

IRB Input

FunctionNumber

REQUEST_SEND_PHY_PACKET

u.SendPhyPacket.Flags

Specifies any nondefault settings for this operation. The following flags are provided:

Flag Description
ASYNC_FLAGS_NO_STATUS Always return success from the send PHY packet operation, regardless of whether the send PHY packet succeeds or fails.

 u.SendPhyPacket.GenerationCount

Specifies the bus reset generation as known by the device driver that submits this request. If the specified generation count does not match the actual generation of the bus, this request is returned with a status of STATUS_INVALID_GENERATION.

u.SendPhyPacket.PhyPacket

Specifies the 64-bit PHY packet that is sent to the 1394 bus. 

I/O Status Block

If successful, the new 1394 bus driver sets Irp->IoStatus.Status to STATUS_SUCCESS. If u.SendPhyPacket.GenerationCount does not match the current bus generation count, the new 1394 bus driver sets Irp->IoStatus.Status to STATUS_INVALID_GENERATION.

REQUEST_RECEIVE_PHY_PACKETS

This is a new DDI to receive 1394 PHY packets.

The following are the relevant members of the IRB for this request:

typedef struct _IRB {

 ULONG FunctionNumber;

 .

 .

 .

 union {

 struct {

 ULONG  Flags;

 PBUS_PHY_PACKET_NOTIFICATION PhyPacketRoutine; 

 PVOID PhyPacketContext;

 } ReceivePhyPackets;

 .

 .

 .

 } u;

} IRB; 

IRB Input

FunctionNumber

REQUEST_RECEIVE_PHY_PACKET

u.ReceivePhyPackets.Flags

Specifies whether a callback should be registered or deactivated. Use REGISTER_PHY_PACKET_NOTIFICATION to register PhyPacketRoutine as the callback. Use DEREGISTER_PHY_PACKET_NOTIFICATION to deactivate any previously registered callback.

u.ReceivePhyPackets.PhyPacketRoutine

Points to the notification routine for received PHY packets. The following is a prototype for the notification routine:

void PhyPacketRoutine(

__in PVOID  Context,

__in ULONG  GenerationCount,

 __in ULARGE_INTEGER  PhyPacket

); 

Parameters

Context

The argument that is specified in the u.ReceivePhyPackets.PhyPacketContext parameter when the REQUEST_RECEIVE_PHY_PACKET request is sent.

GenerationCount

The generation count of the bus for this PHY packet.

PhyPacket

The 64-bit PHY packet that is received from the 1394 bus. 

u. ReceivePhyPackets.PhyPacketContext

Specifies the Context argument to be passed to the PhyPacketRoutine. 

Operation

The PhyPacketRoutine is called at DISPATCH_LEVEL.

Retrieve Configuration ROM DDI

This new DDI returns the contents of a node’s configuration ROM. It returns the entire contents of the device’s configuration ROM, up to a maximum size of 1 kilobyte (KB). The new 1394 bus driver supports only 1‑KB configuration ROMs, which is the same as the legacy 1394 bus driver.

The following are the relevant members of the IRB for this request:

typedef struct _IRB {

 ULONG FunctionNumber;

 .

 .

 .

 union {

 struct {

 ULONG GenerationCount;

 PCROM ConfigRom;

 ULONG UnitDirectoryIndex;

 ULONG UnitDependentDirectoryIndex;

 ULONG VendorLeafIndex;

 ULONG ModelLeafIndex;

 } GetConfigRom;

 .

 .

 .

 } u;

} IRB; 

IRB Input

FunctionNumber

REQUEST_GET_CONFIG_ROM

u.GetConfigRom.GenerationCount

Receives the generation of the bus for which the contents of this configuration ROM was retrieved.

u.GetConfigRom.ConfigRom

A structure that receives the contents of the node's configuration ROM.

u.GetConfigRom.UnitDirectoryIndex

Receives the index to the node’s unit directory in its configuration ROM. This is an index to the Entries array in the u.GetConfigRom.ConfigRom structure.

u.GetConfigRom.UnitDependentDirectoryIndex

Receives the index to the node's unit dependent directory in its configuration ROM. This is an index to the Entries array in the u.GetConfigRom.ConfigRom structure.

u.GetConfigRom.VendorLeafIndex

Receives the index to the node's vendor textual leaf in the configuration ROM. This is an index to the Entries array in the u.GetConfigRom.ConfigRom structure.

u.GetConfigRom.ModelLeafIndex

Receives the index to the node's model textual leaf in the configuration ROM. This is an index to the Entries array in the u.GetConfigRom.ConfigRom structure.

Community Resources