From patchwork Tue Feb 13 08:16:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomi Valkeinen X-Patchwork-Id: 13554663 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 32DC2C4829A for ; Tue, 13 Feb 2024 08:17:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B294910E316; Tue, 13 Feb 2024 08:17:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="jrgaoN5l"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by gabe.freedesktop.org (Postfix) with ESMTPS id 51BC110E316 for ; Tue, 13 Feb 2024 08:17:14 +0000 (UTC) Received: from [127.0.1.1] (91-154-35-128.elisa-laajakaista.fi [91.154.35.128]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7053C13AB; Tue, 13 Feb 2024 09:17:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1707812224; bh=YsSXyUoBoQT0IwX3NdvoTnvhBuIOfrZ35XLfOOL2+Tw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=jrgaoN5lVRxxcFXito+GQZkNpUXZvI0n/DOMbqAkOX0JgbGKs60bfZEFNCIVjA8S8 SJ/SVlYeaO2IAqjLTlqGbdazvFFk5EwlJXrPM9kaYHx17yHjQaC/gbAXn/m2MJhw9e ZsimXMe1awPF3DnXYbdVQ6sS7yrcGmW7K7Mt5UHw= From: Tomi Valkeinen Date: Tue, 13 Feb 2024 10:16:36 +0200 Subject: [PATCH 1/2] drm/tidss: Fix initial plane zpos values MIME-Version: 1.0 Message-Id: <20240213-tidss-fixes-v1-1-d709e8dfa505@ideasonboard.com> References: <20240213-tidss-fixes-v1-0-d709e8dfa505@ideasonboard.com> In-Reply-To: <20240213-tidss-fixes-v1-0-d709e8dfa505@ideasonboard.com> To: Jyri Sarha , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Sam Ravnborg , Devarsh Thakkar , Aradhya Bhatia , Francesco Dolcini Cc: Tomi Valkeinen , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Tomi Valkeinen X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=openpgp-sha256; l=2076; i=tomi.valkeinen@ideasonboard.com; h=from:subject:message-id; bh=YsSXyUoBoQT0IwX3NdvoTnvhBuIOfrZ35XLfOOL2+Tw=; b=owEBbQKS/ZANAwAIAfo9qoy8lh71AcsmYgBlyyV/yfb/cYWS5pNx0IA84/3kZKinY05RPOM0Z c0jEEyZaeiJAjMEAAEIAB0WIQTEOAw+ll79gQef86f6PaqMvJYe9QUCZcslfwAKCRD6PaqMvJYe 9Z3dEACXkwC3bLK5AqM40K1v8IGB7Z01jp9J0lLRqtHAvKMUoRyu0nFcj5knVSOW7Pzh5ZmFanC FenJi3nCboq/dMdOU0r1mqeZIOPm/SskViSpWJVRGGdcgAVYvniLqvorP3/dxjhQasCGhqpaykd mIis3vc8xc4E7pJUarely91uBOawwVgtRkcGSepEiqEWa7OhUJUIwzIDeOHCnc66t5MeFK89Oqj 3XeB4cG+sPbZVQn/VIiqmQek41L5QF5PoRaNi+saA6qGHD0JvGsbgwkxyuyh7I2XACIU1eHNdte AXa1GgL4fSjQmS4pr95zu5YU/kk/RE0z8jfYUf4OcVWnLWAfZNa4+BW6Ee5eoE+7V61FknkzIJg DKH78Zv+cM5JPwtWNFepCEr+tx8J7eNU5AwwpPveO4gLQvgdZkW3P5tXadxzf7nGlbn7O1+uIZY BbniXwuNK7j0wgLSmQpwlE/RelgZ8Cg3JMimRl59V6qzYqsUObUHbS5PBKVvlDuvvSqvqCnqamY DJWMgbMfveMdRSUh9yon/dWzDTrW+Q/PV6Op1UopN5APuR+jWnV6cIdj8bnfvyaYoOHFBrBQTlV SGaBzfohhivQeaGmiqT92jCNuwyW6DIVskGhO8XHq29MhAopUNh3LQatX7YJzE2OJj/8uiRElNh crqwdQLTCSDiVuw== X-Developer-Key: i=tomi.valkeinen@ideasonboard.com; a=openpgp; fpr=C4380C3E965EFD81079FF3A7FA3DAA8CBC961EF5 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" When the driver sets up the zpos property it sets the default zpos value to the HW id of the plane. That is fine as such, but as on many DSS versions the driver arranges the DRM planes in a different order than the HW planes (to keep the non-scalable planes first), this leads to odd initial zpos values. An example is J721e, where the initial zpos values for DRM planes are 1, 3, 0, 2. In theory the userspace should configure the zpos values properly when using multiple planes, and in that sense the initial zpos values shouldn't matter, but there's really no reason not to fix this and help the userspace apps which don't handle zpos perfectly. In particular, Weston seems to have issues dealing with the planes with the current default zpos values. So let's change the zpos values for the DRM planes to 0, 1, 2, 3. Another option would be to configure the planes marked as primary planes to zpos 0. On a two display system this would give us plane zpos values of 0, 0, 1, 2. The end result and behavior would be very similar in this option, and I'm not aware that this would actually help us in any way. So, to keep the code simple, I opted for the 0, 1, 2, 3 values. Signed-off-by: Tomi Valkeinen Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Reviewed-by: Aradhya Bhatia --- drivers/gpu/drm/tidss/tidss_plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c index e1c0ef0c3894..68fed531f6a7 100644 --- a/drivers/gpu/drm/tidss/tidss_plane.c +++ b/drivers/gpu/drm/tidss/tidss_plane.c @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss, drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs); - drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0, + drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0, num_planes - 1); ret = drm_plane_create_color_properties(&tplane->plane, From patchwork Tue Feb 13 08:16:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomi Valkeinen X-Patchwork-Id: 13554664 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E4301C48BC3 for ; Tue, 13 Feb 2024 08:17:23 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4F78110E410; Tue, 13 Feb 2024 08:17:20 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="Nujxj16x"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by gabe.freedesktop.org (Postfix) with ESMTPS id 52F2F10E33F for ; Tue, 13 Feb 2024 08:17:14 +0000 (UTC) Received: from [127.0.1.1] (91-154-35-128.elisa-laajakaista.fi [91.154.35.128]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 5678515C2; Tue, 13 Feb 2024 09:17:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1707812225; bh=9m5KGOCuoxEboIm7ISn1H7ymbfhZyzGAdsVPUFGEUFs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Nujxj16x/71Mipo+7k7H6Vb52scs2D3vAx3kUESeoecn1+92JHEmcALH3XF+93qYm 5ygRBB6ivJ3U0qQrK0VrkyCCZ7WGYXgofo0Zn4Tu0kLwP76BQt1+lQBbJftyqLIlw9 H4fRLItjWH+lJE8LQgNuu6+An5CqbaGbl0fBhZFw= From: Tomi Valkeinen Date: Tue, 13 Feb 2024 10:16:37 +0200 Subject: [PATCH 2/2] drm/tidss: Fix sync-lost issue with two displays MIME-Version: 1.0 Message-Id: <20240213-tidss-fixes-v1-2-d709e8dfa505@ideasonboard.com> References: <20240213-tidss-fixes-v1-0-d709e8dfa505@ideasonboard.com> In-Reply-To: <20240213-tidss-fixes-v1-0-d709e8dfa505@ideasonboard.com> To: Jyri Sarha , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Sam Ravnborg , Devarsh Thakkar , Aradhya Bhatia , Francesco Dolcini Cc: Tomi Valkeinen , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Tomi Valkeinen X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=openpgp-sha256; l=2366; i=tomi.valkeinen@ideasonboard.com; h=from:subject:message-id; bh=9m5KGOCuoxEboIm7ISn1H7ymbfhZyzGAdsVPUFGEUFs=; b=owEBbQKS/ZANAwAIAfo9qoy8lh71AcsmYgBlyyV/PKaDqj8BU7nZv3kGkUVewpGZevzHN23SW 21DZri8+PGJAjMEAAEIAB0WIQTEOAw+ll79gQef86f6PaqMvJYe9QUCZcslfwAKCRD6PaqMvJYe 9URzEACrf0IrNFIbW2TM83jy0NHz052ksxO6HTVcgqRmRkG+cetyU72kmxhmeabSNtJ4ApQCT6L 9RC+qRxx+as4n/sbvTGHLzQhmcwvcZQoM3H6aGJRIijiDNAjg/EMS0oYoZuVDDgrBjrr4fm7aS3 XyK5qR8skhHz4WVi+iBXOhiWEgsXWUbyhyNxfUYFIHBvvglS0GgY6a8gBKSsWjvpN2k/+XWGkDH JypW3RqRa91dFbhMCDy1ButhP9eE4RUrhRI7lEAj0RUAZxXMp6bDj1cSUlPs3ZIlWMhQtgK2b/e vLncLDjlX4kfx00JHVHLHPenMq0yyMiz5XY5NDQdKD32af/2TLL44/V/xwRLogg6RN9jEZt8Cpn 3ZkaDFd8xDhk58bRA327qg2e5p3OPE2ipr5PETUMZ1QnN4wI8Lsq1Rhc/O6xIUoQOJldUNycGUz a7CFjKUKiQ21YA5y9kJ1j6w/dBNXAsq9LzmjtO82oRz5tHxXkRn3+tcsfyqVUXp99fs/x7ICpKh FMi//zkTr4MYqpWJw5Th2xqA8oXI21C85c6fu/JNUEU3m07r/8ClGL625lnIkSbtMSFJXKSpxHE 7HV9FCzJNQVIAInytwvwLgq76aj/d1wW9UtvWN4HX/4/EZtYOGVtp5BW1+QfRzIzdIkhqHyTQyA Bgr+FC6Vr1c+BOg== X-Developer-Key: i=tomi.valkeinen@ideasonboard.com; a=openpgp; fpr=C4380C3E965EFD81079FF3A7FA3DAA8CBC961EF5 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" A sync lost issue can be observed with two displays, when moving a plane from one disabled display to an another disabled display, and then enabling the display to which the plane was moved to. The exact requirements for this to trigger are not clear. It looks like the issue is that the layers are left enabled in the first display's OVR registers. Even if the corresponding VP is disabled, it still causes an issue, as if the disabled VP and its OVR would still be in use, leading to the same VID being used by two OVRs. However, this is just speculation based on testing the DSS behavior. Experimentation shows that as a workaround, we can disable all the layers in the OVR when disabling a VP. There should be no downside to this, as the OVR is anyway effectively disabled if its VP is disabled, and it seems to solve the sync lost issue. However, there may be a bigger issue in play here, related to J721e erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result in Synclost During the Next Frame"). Experimentation also shows that the OVR's CHANNELIN field has similar issue. So we may need to revisit this when we find out more about the core issue. Signed-off-by: Tomi Valkeinen Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Reviewed-by: Aradhya Bhatia --- drivers/gpu/drm/tidss/tidss_crtc.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c index 5f838980c7a1..94f8e3178df5 100644 --- a/drivers/gpu/drm/tidss/tidss_crtc.c +++ b/drivers/gpu/drm/tidss/tidss_crtc.c @@ -265,6 +265,16 @@ static void tidss_crtc_atomic_disable(struct drm_crtc *crtc, reinit_completion(&tcrtc->framedone_completion); + /* + * If a layer is left enabled when the videoport is disabled, and the + * vid pipeline that was used for the layer is taken into use on + * another videoport, the DSS will report sync lost issues. Disable all + * the layers here as a work-around. + */ + for (u32 layer = 0; layer < tidss->feat->num_planes; layer++) + dispc_ovr_enable_layer(tidss->dispc, tcrtc->hw_videoport, layer, + false); + dispc_vp_disable(tidss->dispc, tcrtc->hw_videoport); if (!wait_for_completion_timeout(&tcrtc->framedone_completion,