From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EDB9C54FCB for ; Thu, 23 Apr 2020 16:42:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 447D220728 for ; Thu, 23 Apr 2020 16:42:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Db0Ck2Hu" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729753AbgDWQmx (ORCPT ); Thu, 23 Apr 2020 12:42:53 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:29961 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729407AbgDWQmx (ORCPT ); Thu, 23 Apr 2020 12:42:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587660171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=odJrFOK+7bivbDZ7ZKaNo+MENCGaQCojnN8HH0MbtLQ=; b=Db0Ck2HuEuXStMSNpiItPm+emlxXImd6TjpYfliuN5lee7ye/uDgh8a8KRfQu9/y50b7nS GIc36A42Flx1nJBu6574R8rfCCq0xxE7hBjn2zt7T0/Ht2aK2j1NYMANK1PV9WazEVkYb0 52AdaD8JNdMCXP+L6UsDgNzo2hfjIcQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-394-uYnyQ5tLMYyrRTydAnFg0Q-1; Thu, 23 Apr 2020 12:42:49 -0400 X-MC-Unique: uYnyQ5tLMYyrRTydAnFg0Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CB72F803786; Thu, 23 Apr 2020 16:42:30 +0000 (UTC) Received: from Ruby.redhat.com (ovpn-119-186.rdu2.redhat.com [10.10.119.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F7545D9CC; Thu, 23 Apr 2020 16:42:28 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org Cc: Wayne Lin , Sean Paul , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Wayne Lin , linux-kernel@vger.kernel.org Subject: [PATCH] Revert "drm/dp_mst: Remove single tx msg restriction." Date: Thu, 23 Apr 2020 12:42:24 -0400 Message-Id: <20200423164225.680178-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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=3D2 cur_len=3D2 seqno=3D1 state=3DSENT path_m= sg=3D1 dst=3D00 [dp_mst] type=3DENUM_PATH_RESOURCES contents: [dp_mst] port=3D2 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 Fixes: 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.") Cc: Wayne Lin Cc: Sean Paul --- drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++++++++++++-- include/drm/drm_dp_mst_helper.h | 5 +++++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_= dp_mst_topology.c index 21f10ceb3d6c..03a1496f6120 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1205,6 +1205,8 @@ static int drm_dp_mst_wait_tx_reply(struct drm_dp_m= st_branch *mstb, txmsg->state =3D=3D DRM_DP_SIDEBAND_TX_SENT) { mstb->tx_slots[txmsg->seqno] =3D NULL; } + mgr->is_waiting_for_dwn_reply =3D false; + } out: if (unlikely(ret =3D=3D -EIO) && drm_debug_enabled(DRM_UT_DP)) { @@ -1214,6 +1216,7 @@ static int drm_dp_mst_wait_tx_reply(struct drm_dp_m= st_branch *mstb, } mutex_unlock(&mgr->qlock); =20 + drm_dp_mst_kick_tx(mgr); return ret; } =20 @@ -2789,9 +2792,11 @@ static void process_single_down_tx_qlock(struct dr= m_dp_mst_topology_mgr *mgr) ret =3D process_single_tx_qlock(mgr, txmsg, false); if (ret =3D=3D 1) { /* txmsg is sent it should be in the slots now */ + mgr->is_waiting_for_dwn_reply =3D true; list_del(&txmsg->next); } else if (ret) { DRM_DEBUG_KMS("failed to send msg in q %d\n", ret); + mgr->is_waiting_for_dwn_reply =3D false; list_del(&txmsg->next); if (txmsg->seqno !=3D -1) txmsg->dst->tx_slots[txmsg->seqno] =3D NULL; @@ -2831,7 +2836,8 @@ static void drm_dp_queue_down_tx(struct drm_dp_mst_= topology_mgr *mgr, drm_dp_mst_dump_sideband_msg_tx(&p, txmsg); } =20 - if (list_is_singular(&mgr->tx_msg_downq)) + if (list_is_singular(&mgr->tx_msg_downq) && + !mgr->is_waiting_for_dwn_reply) process_single_down_tx_qlock(mgr); mutex_unlock(&mgr->qlock); } @@ -3823,6 +3829,7 @@ static int drm_dp_mst_handle_down_rep(struct drm_dp= _mst_topology_mgr *mgr) mutex_lock(&mgr->qlock); txmsg->state =3D DRM_DP_SIDEBAND_TX_RX; mstb->tx_slots[seqno] =3D NULL; + mgr->is_waiting_for_dwn_reply =3D false; mutex_unlock(&mgr->qlock); =20 wake_up_all(&mgr->tx_waitq); @@ -3830,6 +3837,9 @@ static int drm_dp_mst_handle_down_rep(struct drm_dp= _mst_topology_mgr *mgr) return 0; =20 out_clear_reply: + mutex_lock(&mgr->qlock); + mgr->is_waiting_for_dwn_reply =3D false; + mutex_unlock(&mgr->qlock); if (msg) memset(msg, 0, sizeof(struct drm_dp_sideband_msg_rx)); out: @@ -4683,7 +4693,7 @@ static void drm_dp_tx_work(struct work_struct *work= ) struct drm_dp_mst_topology_mgr *mgr =3D container_of(work, struct drm_d= p_mst_topology_mgr, tx_work); =20 mutex_lock(&mgr->qlock); - if (!list_empty(&mgr->tx_msg_downq)) + if (!list_empty(&mgr->tx_msg_downq) && !mgr->is_waiting_for_dwn_reply) process_single_down_tx_qlock(mgr); mutex_unlock(&mgr->qlock); } diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_hel= per.h index 2d7c26592c05..96bcf33c03d3 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -592,6 +592,11 @@ struct drm_dp_mst_topology_mgr { */ bool payload_id_table_cleared : 1; =20 + /** + * @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. */ --=20 2.25.3