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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E1BCCCA489 for ; Wed, 8 Jun 2022 01:38:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1385712AbiFHBgW (ORCPT ); Tue, 7 Jun 2022 21:36:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1386449AbiFGWs5 (ORCPT ); Tue, 7 Jun 2022 18:48:57 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 14CBA27410D for ; Tue, 7 Jun 2022 12:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654630602; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2hQw9PjwI7xzOPycqxwicemxVs6g0PK0F6TWsxf3MaA=; b=c4ovMLnOziPCg3y9QEDPL5p6Zndnp+j7e3Om9OKumNoaJvUZApAYyz6/8A7sWpUu1Dmt/M oEDy3ZcUY7I3Juz5atmjT3WZqRL2xNWkUgbThG3f/O3CXMOSMx32oqnmMwZbdEfZibgUeI YXfil3PHFLFuDd2q7SUNC7zttZ18Mtg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-496-O_3NXQaoOv-axGes3qAn5Q-1; Tue, 07 Jun 2022 15:36:40 -0400 X-MC-Unique: O_3NXQaoOv-axGes3qAn5Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9753680D190; Tue, 7 Jun 2022 19:35:14 +0000 (UTC) Received: from emerald.redhat.com (unknown [10.22.9.252]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4AA422C0484A; Tue, 7 Jun 2022 19:34:45 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org Cc: Wayne Lin , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Fangzhi Zuo , Jani Nikula , Imre Deak , Daniel Vetter , Sean Paul , David Airlie , Daniel Vetter , Thomas Zimmermann , Bhawanpreet Lakha , linux-kernel@vger.kernel.org (open list) Subject: [RESEND RFC 10/18] drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots() Date: Tue, 7 Jun 2022 15:29:25 -0400 Message-Id: <20220607192933.1333228-11-lyude@redhat.com> In-Reply-To: <20220607192933.1333228-1-lyude@redhat.com> References: <20220607192933.1333228-1-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently with the MST helpers we avoid releasing payloads _and_ avoid pulling in the MST state if there aren't any actual payload changes. While we want to keep the first step, we need to now make sure that we're always pulling in the MST state on all modesets that can modify payloads - even if the resulting payloads in the atomic state are identical to the previous ones. This is mainly to make it so that if a CRTC is still assigned to a connector but is set to DPMS off, the CRTC still holds it's payload allocation in the atomic state and still appropriately pulls in the MST state for commit tracking. Otherwise, we'll occasionally forget to update MST payloads from changes caused by non-atomic DPMS changes. Doing this also allows us to track bandwidth limitations in a state correctly even between DPMS changes, so that there's no chance of a simple ->active change being rejected by the atomic check. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index e73b34c0cc9e..c5edcf2a26c8 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4485,6 +4485,7 @@ int drm_dp_atomic_release_time_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_state *topology_state; struct drm_dp_mst_atomic_payload *payload; struct drm_connector_state *old_conn_state, *new_conn_state; + bool update_payload = true; old_conn_state = drm_atomic_get_old_connector_state(state, port->connector); if (!old_conn_state->crtc) @@ -4496,10 +4497,12 @@ int drm_dp_atomic_release_time_slots(struct drm_atomic_state *state, struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, new_conn_state->crtc); - if (!crtc_state || - !drm_atomic_crtc_needs_modeset(crtc_state) || - crtc_state->enable) + /* No modeset means no payload changes, so it's safe to not pull in the MST state */ + if (!crtc_state || !drm_atomic_crtc_needs_modeset(crtc_state)) return 0; + + if (!crtc_state->mode_changed && !crtc_state->connectors_changed) + update_payload = false; } topology_state = drm_atomic_get_mst_topology_state(state, mgr); @@ -4507,6 +4510,8 @@ int drm_dp_atomic_release_time_slots(struct drm_atomic_state *state, return PTR_ERR(topology_state); topology_state->pending_crtc_mask |= drm_crtc_mask(old_conn_state->crtc); + if (!update_payload) + return 0; payload = drm_atomic_get_mst_payload_state(topology_state, port); if (WARN_ON(!payload)) { -- 2.35.3