1. 28 Apr, 2020 6 commits
  2. 27 Apr, 2020 4 commits
  3. 25 Apr, 2020 14 commits
  4. 24 Apr, 2020 12 commits
  5. 23 Apr, 2020 1 commit
    • Lyude Paul's avatar
      Revert "drm/dp_mst: Remove single tx msg restriction." · 973a5909
      Lyude Paul authored
      This reverts commit 6bb0942e.
      
      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: default avatarLyude Paul <lyude@redhat.com>
      Fixes: 6bb0942e ("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.comReviewed-by: default avatarSean Paul <sean@poorly.run>
      973a5909
  6. 21 Apr, 2020 3 commits