aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/include/drm
diff options
context:
space:
mode:
authorLyude Paul <lyude@redhat.com>2020-04-23 12:42:24 -0400
committerLyude Paul <lyude@redhat.com>2020-04-23 13:18:17 -0400
commit973a5909e99d0301a8832ca0cf07f9be01c4e97a (patch)
tree06db975e571fd4d5edeaecee89374a7ecd3db479 /include/drm
parentdma-buf: Couple of documentation typo fixes (diff)
downloadwireguard-linux-973a5909e99d0301a8832ca0cf07f9be01c4e97a.tar.xz
wireguard-linux-973a5909e99d0301a8832ca0cf07f9be01c4e97a.zip
Revert "drm/dp_mst: Remove single tx msg restriction."
This reverts commit 6bb0942e8f46863a745489cce27efe5be2a3885e. Unfortunately it would appear that the rumors we've heard of sideband message interleaving not being very well supported are true. On the Lenovo ThinkPad Thunderbolt 3 dock that I have, interleaved messages appear to just get dropped: [drm:drm_dp_mst_wait_tx_reply [drm_kms_helper]] timedout msg send 00000000571ddfd0 2 1 [dp_mst] txmsg cur_offset=2 cur_len=2 seqno=1 state=SENT path_msg=1 dst=00 [dp_mst] type=ENUM_PATH_RESOURCES contents: [dp_mst] port=2 DP descriptor for this hub: OUI 90-cc-24 dev-ID SYNA3 HW-rev 1.0 SW-rev 3.12 quirks 0x0008 It would seem like as well that this is a somewhat well known issue in the field. From section 5.4.2 of the DisplayPort 2.0 specification: There are MST Sink/Branch devices in the field that do not handle interleaved message transactions. To facilitate message transaction handling by downstream devices, an MST Source device shall generate message transactions in an atomic manner (i.e., the MST Source device shall not concurrently interleave multiple message transactions). Therefore, an MST Source device shall clear the Message_Sequence_No value in the Sideband_MSG_Header to 0. MST Source devices that support field policy updates by way of software should update the policy to forego the generation of interleaved message transactions. This is a bit disappointing, as features like HDCP require that we send a sideband request every ~2 seconds for each active stream. However, there isn't really anything in the specification that allows us to accurately probe for interleaved messages. If it ends up being that we -really- need this in the future, we might be able to whitelist hubs where interleaving is known to work-or maybe try some sort of heuristics. But for now, let's just play it safe and not use it. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200423164225.680178-1-lyude@redhat.com Reviewed-by: Sean Paul <sean@poorly.run>
Diffstat (limited to 'include/drm')
-rw-r--r--include/drm/drm_dp_mst_helper.h5
1 files changed, 5 insertions, 0 deletions
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 2d7c26592c05..96bcf33c03d3 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -593,6 +593,11 @@ struct drm_dp_mst_topology_mgr {
bool payload_id_table_cleared : 1;
/**
+ * @is_waiting_for_dwn_reply: whether we're waiting for a down reply.
+ */
+ bool is_waiting_for_dwn_reply : 1;
+
+ /**
* @mst_primary: Pointer to the primary/first branch device.
*/
struct drm_dp_mst_branch *mst_primary;