MST Use Case Ex v1

39899 Balentine Drive, Suite 125 Phone: 510 651 5122 Newark, CA 94560 Fax: 510 651 5127
URL:
MST Use Case Example
Version 1
18 January 2011
Purpose
This is a companion document to DisplayPort Standard Version 1.2 and provides tangible examples of how a topology consisting of MST DP devices is to be managed while DisplayPort Standard describes the overall framework.
Summary
This document is Version 1 of the MST DP Usage Example Document Series, and covers how an MST DP Source device and a device containing MST Branching Unit are to interact with each other to perform typical topology and payload bandwidth management functions. A topology consisting of an MST DP Source device, an MST Splitter Branch device, and two video stream sinks is covered in this document.
Table of Contents
Preface (7)
Acknowledgements (8)
Revision History (9)
References (10)
1 Example MST Topology without Audio Stream Sink (11)
1.1 Topology Change Sequences of This Document (14)
1.2 Topology Discovery (14)
1.2.1 Source Device Operation (14)
1.2.2 Splitter Branch Device Operation (21)
1.3 Reading and Writing DP Device Global Unique Identifier (GUID) (21)
1.3.1 Source Device Operation (22)
1.3.2 Splitter Branch Device Operation (24)
1.4 Obtaining Display Capabilities (25)
1.4.1 Source Device Operation (25)
1.4.2 Splitter Branch Device Operation (30)
1.5 Establishing a Virtual Channel from PC to Display 1 (31)
1.5.1 Source Device Operation (31)
1.5.2 Splitter Branch Device Operation (36)
1.6 Establishing a Virtual Channel from PC to Display 2 (37)
1.6.1 Source Device Operation (37)
1.6.2 Splitter Branch Device Operation (41)
1.7 Reallocating the Virtual Channel from PC to Display 1 (41)
1.7.1 Source Device (41)
1.7.2 Splitter Branch Device Operation (45)
1.8 Deleting Virtual Channel from PC to Display 1 (45)
1.8.1 Source Device (45)
1.8.2 Splitter Branch Device Operation (47)
1.9 Cloning the Virtual Channel from PC to Display 2 on Display 1 (47)
1.9.1 Source Device Operation (47)
1.9.2 Splitter Branch Device Operation (49)
1.10 Deleting Cloned Virtual Channel from PC to Display 2 (49)
1.10.1 Source Device Operation (49)
1.10.2 Splitter Branch Device Operation (50)
1.11 Handling Unexpected Changes in Available PBN (51)
1.11.1 Splitter Branch Device Operation (51)
1.11.2 Source Device Operation (52)
1.12 Entering and Exiting Sleep Mode (53)
1.12.1 Source Device Operation (53)
1.12.2 Splitter Branch Device Operation (56)
1.13 Connection Status Change of a Remote Device Due to Unplug or Power Off Event (57)
1.13.1 Splitter Branch Device Operation (57)
1.13.2 Source Device Operation (58)
1.14 Connection Status Change of a Remote Device Due to Plug or Power On Event (59)
1.14.1 Splitter Branch Device Operation (59)
1.14.2 Source Device Operation (60)
2 Example MST Topology with Audio (62)
2.1 Topology Discovery (63)
2.2 Establishing a Virtual Channel from PC to Display 1 with Audio (66)
2.3 Establishing a Virtual Channel from PC to Display 2 with Audio (67)
3 Native AUX Transactions for Sideband MSG Delivery (69)
3.1 Sideband MSG From uPacket TX to uPacket RX (DOWN_REQ or UP_REP) (69)
3.2 Sideband MSG From uPacket RX to uPacket TX (UP_REQ or DOWN_REP) (69)
4 Appendix A: MST Source Device Acting as SST-mode-only Device (70)
5 Appendix B: MST Source Device with Two DP Output Connectors (71)
Tables
Table 0-1: Main Contributors (8)
Table 1-1: Reference Documents (10)
Table 1-1: LINK_ADDRESS Message Transaction (17)
Table 1-2: LINK_ADDRESS Message Transaction Sideband MSG (17)
Table 1-3: LINK_ADDRESS Message Transaction Reply (17)
Table 1-4: LINK_ADDRESS Message Transaction Reply First Sideband MSG (19)
Table 1-5: LINK_ADDRESS Message Transaction Reply Second Sideband MSG (20)
Table 1-6: Sideband MSG for the GUID REMOTE_DPCD_READ Message Transaction Request 22 Table 1-7: Sideband MSG for the GUID REMOTE_DPCD_READ Message Transaction Reply (22)
Table 1-8: Sideband MSG for the GUID REMOTE_DPCD_WRITE Message Transaction Request23 Table 1-9: Sideband MSG for the GUID REMOTE_DPCD_Write Message Transaction Reply (24)
Table 1-10: Sideband MSG for the REMOTE_DPCD_WRITE Message Transaction Request Setting the I2C Speed to 100K (25)
Table 1-11: Sideband MSG for the REMOTE_DPCD_WRITE Message Transaction Reply (26)
Table 1-12: Message Transaction Request for Reading 128-Byte EDID from a Remote Sink Device26 Table 1-13: Sideband MSG for REMOTE_I2C_READ Message Transaction Request (27)
Table 1-14: First Sideband MSG Reply for REMOTE_I2C_READ Message Transaction (28)
Table 1-15: Second Sideband MSG Reply for REMOTE_I2C_READ Message Transaction (28)
Table 1-16: Third Sideband MSG Reply for REMOTE_I2C_READ Message Transaction (29)
Table 1-17: Fourth Sideband MSG Reply for REMOTE_I2C_READ Message Transaction Reply . 29 Table 1-18: ENUM_PATH_RESOURCES Message Transaction Request Sideband MSG (31)
Table 1-19: ENUM_PATH_RESOURCES Message Transaction Reply Sideband MSG (32)
Table 1-20: Virtual Channel (VC) Payload ID Table (35)
Table 1-21: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG (35)
Table 1-22: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG (36)
Table 1-23: ENUM_PATH_RESOURCES Message Transaction Request Sideband MSG (37)
Table 1-24: ENUM_PATH_RESOURCES Message Transaction Reply Sideband MSG (38)
Table 1-25: uPacket TX and RX VC Payload ID Table (39)
Table 1-26: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG (40)
Table 1-27: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG (40)
Table 1-28: uPacket TX and RX VC Payload ID Table (42)
Table 1-29: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG for Reallocating a Virtual Channel (44)
Table 1-30: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG for Reallocating
a Virtual Channel (44)
Table 1-31: Delete VC ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG .. 45 Table 1-32: Delete VC ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG (46)
Table 1-33: uPacket TX and uPacket RX VC Payload ID Table (47)
Table 1-34: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG for Cloning Example (48)
Table 1-35: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG for Cloning Example (48)
Table 1-36: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG for Deleting a Cloned Virtual Channel Example (49)
Table 1-37: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG for Deleting a Cloned Virtual Channel Example (50)
Table 1-38: RESOURCE_STATUS_NOTIFY Message Transaction Request Sideband MSG (51)
Table 1-39: RESOURCE_STATUS_NOTIFY Message Transaction Reply Sideband MSG (52)
Table 1-40: POWER_DOWN_PHY Message Transaction Request Sideband MSG (53)
Table 1-41: POWER_DOWN_PHY Message Transaction Reply Sideband MSG (53)
Table 1-42: CLEAR_PAYLOAD_ID_TABLE Message Transaction Request Sideband MSG (54)
Table 1-43: CLEAR_PAYLOAD_ID_TABLE Message Transaction Reply Sideband MSG (55)
Table 1-44: POWER_UP_PHY Message Transaction Request Sideband MSG (55)
Table 1-45: POWER_UP_PHY Message Transaction Reply Sideband MSG (56)
Table 1-46: Unplug CONNECTION_STATUS_NOTIFY Broadcast Message Transaction Request Sideband MSG (57)
Table 1-47: Unplug CONNECTION_STATUS_NOTIFY Broadcast Message Transaction Reply Sideband MSG (58)
Table 1-48: Plug CONNECTION_STATUS_NOTIFY Broadcast Message Transaction Request Sideband MSG (59)
Table 1-49: Plug CONNECTION_STATUS_NOTIFY Broadcast Message Transaction Reply Sideband MSG (60)
Table 2-1: Audio Video Support Requirements (63)
Table 2-2: LINK_ADDRESS Message Transaction Reply First Sideband MSG (64)
Table 2-3: LINK_ADDRESS Message Transaction Reply Second Sideband MSG (65)
Table 2-4: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG with Audio (66)
Table 2-5: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG (66)
Table 2-6: ALLOCATE_PAYLOAD Message Transaction Request Sideband MSG with Audio (67)
Table 2-7: ALLOCATE_PAYLOAD Message Transaction Reply Sideband MSG (68)
Figures
Figure 1-1: Logical Topology Covered in this Document (11)
Figure 1-2: Physical Topology of PC and Multi-stream Sink Monitor (12)
Figure 1-3: Physical Topology of PC and Multi-stream Sink Monitor (13)
Figure 1-4: Physical Topology with Separate PC, Branch Device and Single Stream DP Monitors .. 13 Figure 1-5: Determine Whether LINK_ADDRESS Message Transaction Should be Used (15)
Figure 1-6: Virtual Channel Allocation Procedure Flowchart (34)
Figure 2-1: Audio Example Topology (62)
Preface
Intellectual Property
Copyright © 2011 Video Electronics Standards Association. All rights reserved.
While every precaution has been taken in the preparation of this standard, the Video Electronics Standards Association and its contributors assume no responsibility for errors or omissions, and make no warranties, expressed or implied, of functionality or suitability for any purpose.
Trademarks
All trademarks used within this document are the property of their respective owners. DMT, DP, DisplayPort, EDID, and VESA are trademarks of the Video Electronics Standards Association.
HDCP is a trademark of Digital Content Protection, LLC
I2C is a trademark of Philips.
Patents
VESA draws attention to the fact that it is claimed that compliance with this Standard may involve the use of a patent or other intellectual property right (collectively, “IPR”). VESA takes no position concerning the evidence, validity, and scope of this IPR.
THIS STANDARD IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY IMPLEMENTATION OF THIS STANDARD SHALL BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER VESA, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER DIRECTLY OR INDIRECTLY ARISING FROM THE IMPLEMENTATION OF THIS STANDARD.
Support for this Standard
Clarifications and application notes to support this standard may be written. To obtain the latest standard and any support documentation, contact VESA.
If you have a product, which incorporates DisplayPort, you should ask the company that manufactured your product for assistance. If you are a manufacturer, VESA can assist you with any clarification you may require. Submit all comments or reported errors in writing to VESA using one of the following methods.
•Fax: 510 651 5127, direct this fax to Technical Support at VESA
•e-mail: support@
•Mail: Technical Support
VESA
39899 Balentine Drive, Suite 125
Newark, CA 94560
Acknowledgements
This document would not have been possible without the efforts of VESA’s DisplayPort Task Group. In particular, the following individuals and their companies contributed significant time and knowledge to this version of the document.
Table 0-1: Main Contributors
Name Company
Tony Cheng AMD
Syed Hussain AMD
George Kyriazis Apple
Bob Ridenour Apple
Yoshinobu Banba EIZO NANAO
George Hayek Intel
Srikanth Kambhatla Intel
Cameron Buschardth NVIDIA
David Steers NVIDIA
Ken Jaramillo NXP Semiconductor
John Garrett STMicroelectronics Editor
Alan Kobayashi STMicroelectronics Co-editor
Revision History
January 18, 2011Initial Release
References
Table 1-2: Reference Documents
Document Version / Revision Date VESA Policy 200 Intellectual Property Rights Version B February 2005 VESA DisplayPort Standard Version 1.2 January 2010
VESA and Industry Standards and Guidelines for Computer Display Monitor
Version 1. Rev.12 November 2008 Timing (DMT
VESA Enhanced Extended Display Identification Data Standard (E-EDID) Rel. A Version 1 February 2000
1 Example MST Topology without Audio Stream Sink
This document covers how an MST DP Source device and a device containing MST Branching Unit are to interact to perform typical topology and payload bandwidth management functions in the following logical topology.
Figure 1-4: Physical Topology with Separate PC, Branch Device and Single Stream DP
Monitors
1.1 Topology Change Sequences of This Document
There are two ways an MST DP Source device can be notified of a topology change.
By a Hot Plug/Unplug event indicating a connection or disconnection of an immediate downstream device to its uPacket TX port.
By receipt of a CONNECTION_STATUS_NOTIFY message transaction indicating a connection or disconnection of a remote device.
Note: Alternately, the Topology Manager in a Source device may choose to periodically poll the
UP_REQ_RDY bit of the immediate downstream device to monitor the connection change event.
In this document, topology discovery and ensuing operations upon a plugging of an immediate
downstream device (that is, the Splitter to which to stream sinks are already connected) to an MST DP Source device is covered first. Connection status change of a remote device is covered later in this
document.
1.2 Topology Discovery
This example explains the sequence of events necessary to discover the connected stream sinks. It is assumed that both stream sinks are connected to the branching unit before the branching unit is
connected to the source device.
1.2.1Source Device Operation
When the Splitter is plugged to the MST DP Source device, the Source device is notified of a Hot
Plug event via the detection of a long (that is, longer than 2ms) HPD pulse. Topology Manager of the DP Source device will read certain DPCD locations of the Splitter to determine the newly connected device type so that it can update the topology map to its Stream Policy Maker.
The DPCD locations to be read for topology discovery are DPCD_REV,
DOWNSTREAMPORT_PRESENT and MSTM_CAP. The given DPCD locations are read to
determine what type of DP device was connected and whether the device is MST capable (and thus capable of handling message transactions using Sideband MSGs) as shown in the following diagram.
With the logical topology used in this document, the immediate downstream device has an MST
Branching Unit. Once it is determined that the device has an MST Branching Unit, the Topology
Manager of the MST Source device must use the LINK_ADDRESS Message transaction to discover the devices connected to the Branching Unit.
Figure 1-5: Determine Whether LINK_ADDRESS Message Transaction Should be Used The MST DP Source device sets UP_REQ_EN bit and UPSTREAM_IS_SRC bit of the immediate downstream device to declare itself as an MST DP Source device before issuing the
LINK_ADDRESS Message Transaction to the immediate downstream device. The MST DP Source
device uses the information received from the LINK_ADDRESS Message transaction to determine whether other DP MST Branching units are connected. If other DPMST Branching units are discovered, the LINK_ADDRESS Message transaction is sent to each DP MST Branching unit to determine the device connected to it. This procedure continues until the Source device’s search goals are met (all sinks found, first sink found or some other goal).
An example algorithm to find all connected sinks is given below.
Procedure FindAccessibleDPDevices given RAD of MST DP Branch device Send LINK_ADDRESS Message to address of MST DP Branching Unit
Wait wait_time_out time period (4 sec.) or until LINK_ADDRESS Message reply if wait_time_out time period elapsed without LINK_ADDRESS Message reply exit procedure indicating failure
endif
if device GUID field is empty (zeros)
Write a GUID into the device
else
if device already in list of devices found
if duplicate GUID obtained by traversing a loop
exit procedure indicating a loop
else
There are multiple paths to the same device
exit procedure
endif
endif
endif
Add device to list of devices found
for each downstream port of the MST DP Branch device
if MST Branching Unit connected to downstream port
Execute FindAccessibleDPDevices with address of MST DP Branch device else
Add device to list of stream sinks/SST DP devices
endif
endfor
end procedure
The Message Transaction source device will wait for 4 seconds for a reply for all message transactions. This is the time period to wait for the entire message transaction reply to be received; in other words, the wait time period for the last Sideband MSG for the message transaction reply to be received by the message source device.
Given two RADs for the same DP MST device (same GUID), the following procedure will determine whether the DP MST device is part of a loop or is accessible through multiple paths.
Procedure IsDevicePartOfLoop given RAD1 and RAD2 to same DP MST device if RAD1 has fewer links than RAD2
Set SmallerRAD to RAD1
Set LargerRAD to RAD2
else
Set SmallerRAD to RAD2
Set LargerRAD to RAD1
endif
Set N to the number of links in SmallerRAD
if the first N links of SmallerRAD is the same as the N links of LargerRAD return true
endif
return false
end procedure
The list of sinks and SST DP devices from the above procedure will contain the relative address for the two stream sinks in this examples topology. The LINK_ADDRESS Message Transaction request and reply for this example are shown below.
Table 1-1: LINK_ADDRESS Message Transaction
LINK_ADDRESS Message Transaction Request Field Name Value
Zero
Request_Identifier 0
000 0001
Table 1-2: LINK_ADDRESS Message Transaction Sideband MSG LINK_ADDRESS Message Transaction Sideband MSG Request Field Name Value
Link_Count_Total
Link_Count_Remaining
No RAD
Broadcast_Message
Path_Message
Sideband_MSG_Body_Length Start_Of_Message_Transaction End_Of_Message_Transaction zero
Message_Sequence_No Sideband_MSG_Header_CRC zero
Request_Identifier
Sideband_MSG_Data_CRC 0001 0000
00 0010 1
1
1011
000 0001 1101 0101
The following shows the above values grouped into bytes.
10h 02h CBh 01h D5h
The following LINK_ADDRESS Message Transaction reply will be received for the physical topology consisting of a PC connected to a daisy chainable monitor with an attached SST DP Monitor.
Table 1-3: LINK_ADDRESS Message Transaction Reply
LINK_ADDRESS Message Transaction Reply Field Name Value
Reply_Type
Request_Identifier
Global_Unique_Identifier (GUID) of the originating branch device zeros
Number_Of_Ports
Input_Port[0]
Peer_Device_Type[0]
Port_Number[0]
Messaging_Capability_Status[0] 0
000 0001 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 0000 1111 0001 0000 0000 0011
1
001 0000
1
DisplayPort_Device_Plug_Status[0]
zeros
Input_Port[1]
Peer_Device_Type[1]
Port_Number[1]
Messaging_Capability_Status[1]
DisplayPort_Device_Plug_Status[1]
Legacy_Device_Plug_Status[1]
zeros
DPCD_Revision[1]
Peer_Global_Unique_Identifier[1]
Number_SDP_Streams[1]
Number_SDP_Stream_Sinks[1]
Input_Port[2]
Peer_Device_Type[2]
Port_Number[2]
Messaging_Capability_Status[2]
DisplayPort_Device_Plug_Status[2]
Legacy_Device_Plug_Status[2]
zeros
DPCD_Revision[2]
Peer_Global_Unique_Identifier[2] (Same as branch unit since this is a logical port) Number_SDP_Streams[2]
Number_SDP_Stream_Sinks[2] 1
00 0000 0
011 0001
1
0 0000 0001 0010 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
011 1000
1
0 0000 0001 0010 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 0000 1111 0001 0000 0000 0000
The following shows the above values grouped into bytes. 01h 01h 02h 03h 04h 05h 06h 07h 08h 09h
0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h 03h 90h C0h
31h 40h 12h 00h 00h 00h 00h 00h 00h 00h
00h 00h 00h 00h 00h 00h 00h 00h 00h 00h
38h 40h 12h 01h 02h 03h 04h 05h 06h 07h
08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h 00h
Since the above LINK_ADDRESS Message Transaction reply is greater than 44-bytes (48 bytes minus the size of the Sideband Header and Sideband Body CRC, 3 + 41), the reply must be divided into multiple Sideband Messages. The LINK_ADDRESS Message Transaction reply is split into two Sideband Messages between the DPCD_Version[2] and GUID[2]. With this split, the first Sideband Message is 47-bytes, and the second Sideband message is 21-bytes. The split can be performed at any point as long as the resultant Sideband messages are less than or equal to 48-bytes. In this case the split of the Message Transaction reply should not result in more than two Sideband messages. Table 1-4: LINK_ADDRESS Message Transaction Reply First Sideband MSG
LINK_ADDRESS Message Transaction Reply Field Name Value
Link_Count_Total
Link_Count_Remaining
No RAD
Broadcast_Message
Path_Message
Sideband_MSG_Body_Length
Start_Of_Message_Transaction
End_Of_Message_Transaction
zero
Message_Sequence_No
Sideband_MSG_Header_CRC
Reply_Type
Request_Identifier
Global_Unique_Identifier (GUID) of the originating branch device zeros
Number_Of_Ports
Input_Port[0]
Peer_Device_Type[0]
Port_Number[0]
Messaging_Capability_Status[0]
DisplayPort_Device_Plug_Status[0]
zeros
Input_Port[1]
Peer_Device_Type[1] 0001 0000
10 1100 1
1001
000 0001 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 0000 1111 0001 0000 0000 0011
1
001 0000
1
1
00 0000 0
011
Port_Number[1]
Messaging_Capability_Status[1] DisplayPort_Device_Plug_Status[1] Legacy_Device_Plug_Status[1] zeros
DPCD_Revision[1]
Peer_Global_Unique_Identifier[1] Number_SDP_Streams[1] Number_SDP_Stream_Sinks[1] Input_Port[2]
Peer_Device_Type[2]
Port_Number[2]
Messaging_Capability_Status[2] DisplayPort_Device_Plug_Status[2] Legacy_Device_Plug_Status[2] zeros
DPCD_Revision[2]
Sideband_MSG_Data_CRC 0001
1
0 0000 0001 0010 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
011 1000
1
0 0000 0001 0010 0010 1000
The following shows the above values grouped into bytes.
10h 2Ch 89h 01h 01h 02h 03h 04h 05h 06h
07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h
03h 90h C0h 31h 40h 12h 00h 00h 00h 00h
00h 00h 00h 00h 00h 00h 00h 00h 00h 00h
00h 00h 00h 38h 40h 12h 28h
Table 1-5: LINK_ADDRESS Message Transaction Reply Second Sideband MSG LINK_ADDRESS Message Transaction Reply Field Name Value
Link_Count_Total
Link_Count_Remaining
No RAD
Broadcast_Message
Path_Message
Sideband_MSG_Body_Length
Start_Of_Message_Transaction
End_Of_Message_Transaction
zero
Message_Sequence_No
Sideband_MSG_Header_CRC
Peer_Global_Unique_Identifier[2] (Same as branch unit since 0001 0000
01 0010 0
1
1111 0000 0001
this is a logical port) Number_SDP_Streams[2]
Number_SDP_Stream_Sinks[2]
Sideband_MSG_Data_CRC 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 0000 1111 0001 0000 0000 0000 0011 1011
The following shows the above values grouped into bytes.
10h 12h 4Fh 01h 02h 03h 04h 05h 06h 07h
08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h 00h
3Bh
1.2.2Splitter Branch Device Operation
When a Splitter Branch device completes initializing and is ready to handle AUX request transactions from its upstream device, the Splitter Branch device will assert HPD on its upstream physical port.
Part of the initialization sequence is setting the MSTM_CAP DPCD location MST_CAP bit to 1. The Splitter Branch device will begin monitoring its downstream ports for device connections. When the Splitter Branch device detects devices connected to its downstream ports, its Topology Assistant has the option of reading the device information from the connected DP device for later reporting when a LINK_ADDRESS Message Transaction is received from the Topology Manager in the Source
device; alternately, it may do nothing, just waiting for the LINK_ADDRESS Message Transaction
before reading the device information of the connected DP device. Table 2-93 of the VESA
DisplayPort Standard Ver.1.2 describes what information needs to be obtained to determine the
values for the Peer_Device_Type and Messaging_Capability_Status fields of the LINK_ADDRESS Message Transaction reply.
The Splitter Branch device will monitor the MSTM_CTRL DPCD location UP_REQ_EN bit. When the UP_REQ_EN bit is set to 1 by the upstream device(s), it will set the UP_REQ_EN bit of the
downstream devices to 1 as long as those devices are MST devices (indicated by the MST_CAP bit equal to 1).
Note: When the UP_REQ_EN bit is cleared to (or remains) 0 on the upstream port by the upstream device, the Splitter Branch device will clear the UP_REQ_EN bit of the downstream devices to 0 and operate as an SST Branch device (either an output switch or a replicater) as described in Section 3.”.
1.3 Reading and Writing DP Device Global Unique Identifier (GUID)
In this example the SST DP Sink device Display 1 supports HBR2. Therefore, Display 1 needs to have DPCD revision number 1.2. Because it has DPCD revision number 1.2, Display 1 must have a GUID field. Assuming Display 1 doesn’t contain a USB device, the GUID field can be set to zero as power-on reset default value. If the GUID field is set to zero, the GUID field must be writable using Native AUX CH transactions. This example provides the Message transactions required to read and
subsequently write the GUID field assuming the GUID field is set to zero.
1.3.1Source Device Operation
From the LINK_ADDRESS Message Transaction reply received from the last branch device, the MST DP Source device knows the DPCD version number supported by the SST DP Sink devices.
For Display 1 the DPCD revision number supported is 1.2 indicating it supports a GUID field. The MST DP Source device sends a REMOTE_DPCD_READ Message Transaction request to the last branch device to read the GUID field of Display 1. The Sideband MSG containing the
REMOTE_DPCD_READ Message Transaction request is shown in the following table.
Table 1-6: Sideband MSG for the GUID REMOTE_DPCD_READ Message Transaction
Request
REMOTE_DPCD_READ Message Transaction Request Sideband MSG Field Name Value
Link_Count_Total
Link_Count_Remaining
No RAD
Broadcast_Message
Path_Message
Sideband_MSG_Body_Length Start_Of_Message_Transaction End_Of_Message_Transaction zero
Message_Sequence_No Sideband_MSG_Header_CRC zero
Request_Identifier
Port_Number
DPCD_Address
Number_Of_Bytes_To_Read Sideband_MSG_Data_CRC 0001 0000
00 0110 1
1
1100
010 0000 0001 0000 0000 0000 0011 0000 0001 0000 1110 1010
The following shows the above values grouped into bytes.
10h 06h CCh 20h 10h 00h 30h 10h EAh
The GUID field read will be zero. The reply to the above Message transaction request is shown in the table below.
Table 1-7: Sideband MSG for the GUID REMOTE_DPCD_READ Message Transaction Reply REMOTE_DPCD_READ Message Transaction Reply Sideband MSG Field Name Value
Link_Count_Total
Link_Count_Remaining
No RAD
Broadcast_Message
Path_Message
Sideband_MSG_Body_Length Start_Of_Message_Transaction End_Of_Message_Transaction zero
Message_Sequence_No Sideband_MSG_Header_CRC Reply_Type
Request_Identifier
zeros
Port_Number
Number_Of_Bytes_Read Data_Read[0] GUID
Data_Read[1] 0001 0000
01 0100 1
1
1001
010 0000 0000 0001 0001 0000 0000 0000 0000 0000。