Message ID | 20231101-tidss-probe-v1-10-45149e0f9415@ideasonboard.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:abcd:0:b0:403:3b70:6f57 with SMTP id f13csp283413vqx; Wed, 1 Nov 2023 02:21:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHTIWACX6puFCPzeh7yfYuHZz+9W9lrDrAus8QTGjaYZTGdy1m9IbfTLEPpvUoHdN8zf0IP X-Received: by 2002:a17:902:d50d:b0:1cc:3875:e654 with SMTP id b13-20020a170902d50d00b001cc3875e654mr9012710plg.26.1698830502229; Wed, 01 Nov 2023 02:21:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698830502; cv=none; d=google.com; s=arc-20160816; b=z3jIdjgsnZOb8tB9DHhfOknvHZXUi5MV2eFXXeZH1uPfERFdUEacybG3J6FgjC+HaJ 9cFkawn+uTMRfGJNRH8Pb7NKMkb5SDSGkLbJNIn4Yc7OQA3wG+NwBAP1iDzw5/F0TjZC usnRfzXkgH9Eq66oKsczAKQ21MordrKIvPY6BBs6T4h9t8J1N0gkWXFtLd5vCsC8blQ8 4zPaxmUcESo3Sl+ladBTgUyS5EcM5V5/w/qGNkSAivzYOaFP8DSTA9EX2TMoGlROQh+K 0B+1FTdbAkfE0jcOA59onGJ0xHuk/+naLyENiIA1/q8cpMU+q6oetUwQH26bflrdl/sw mC8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=RT2JT2gBFWTktn7TIoBqKPO1iMcwDsIMympww+gk7WA=; fh=IpenHstmzluQ2qG4rgZds4W72uLPbZNMEjQq5GLr0+k=; b=UztNxoTMW9YzUnhIZvSnaR9FIv42s546SX/YoT5RgryYcKbbJgmmAjOBgWEiuNC4Gp wMQwyi2MS1EuUFQuWPcO0elTBvlMjBfK6+oRN0aJ02Qd/pC229wR1LK7+nuBcIsGSxEF QNTcycBEa7qYd7WklSf/L++LHVyXBtADi+mP4GnFUkDdoNSo0nTSO3uz50prKo3N3Ql9 ts4Fwm6i+qkQVNF9uUXOyot6Wug7agzHlDO45YydDhcSRQdBGvay8lIZHnB/OucpKGKt 0tARRuHhHowcO59MhDJtx8Vzh0lJotrCyYRWIkOPbwZcWj8e7734X2G8ziFTinECz1AR lO1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=dAbxEauT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id kk6-20020a170903070600b001b8904eadb8si2519391plb.460.2023.11.01.02.21.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 02:21:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=dAbxEauT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 2BEA48074CA6; Wed, 1 Nov 2023 02:21:11 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231926AbjKAJUJ (ORCPT <rfc822;rbbytesnap@gmail.com> + 35 others); Wed, 1 Nov 2023 05:20:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234822AbjKAJUG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Nov 2023 05:20:06 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1238611D for <linux-kernel@vger.kernel.org>; Wed, 1 Nov 2023 02:19:26 -0700 (PDT) Received: from [127.0.1.1] (91-158-149-209.elisa-laajakaista.fi [91.158.149.209]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 0F6751C1D; Wed, 1 Nov 2023 10:18:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1698830305; bh=OSH8ynuiJ2YVkYrZuWQq2MVjAg+Zul2OXF3bZ5EaKoY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=dAbxEauTggKPBtvsLnTgVxvWaN51QrLuJNaTEEl3DVqw9QseUa8JBoFOKtKTJk4/B NKF+dbkFvR5sgddorjc/PJjo2yisNgv9W6fG56YeAYj6n7PuYRVrtOlFu5h4Yxx5pi wxL8hRRQqvGLAQlysHgUcHB6eIeSXf6GslDZexQ0= From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Date: Wed, 01 Nov 2023 11:17:47 +0200 Subject: [PATCH 10/10] drm/tidss: Fix atomic_flush check MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231101-tidss-probe-v1-10-45149e0f9415@ideasonboard.com> References: <20231101-tidss-probe-v1-0-45149e0f9415@ideasonboard.com> In-Reply-To: <20231101-tidss-probe-v1-0-45149e0f9415@ideasonboard.com> To: Aradhya Bhatia <a-bhatia1@ti.com>, Devarsh Thakkar <devarsht@ti.com>, Jyri Sarha <jyri.sarha@iki.fi>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=openpgp-sha256; l=1701; i=tomi.valkeinen@ideasonboard.com; h=from:subject:message-id; bh=OSH8ynuiJ2YVkYrZuWQq2MVjAg+Zul2OXF3bZ5EaKoY=; b=owEBbQKS/ZANAwAIAfo9qoy8lh71AcsmYgBlQhfowmaSVl6BO4E/HgJrUUSCbYheTzOdaTI7j cPYBH4VqoyJAjMEAAEIAB0WIQTEOAw+ll79gQef86f6PaqMvJYe9QUCZUIX6AAKCRD6PaqMvJYe 9eIYEACPcoPMlIy8n0o9G8hXcsLaHmiclB9/T6IHAxb7QlmvPnQG5uC4ENthjLwTslHTcm9AKI3 cZ9lB9izizrFbL0x/lKcOPbFBScAOw1ADcOXo/4ECGzcCcZaFXMSmR0lJkd4INJ9PGnCIR9Bb99 R55+b+J0BFFDqBd1GEMjWlrRHp7kZWFsNEm5eZgOcbSiX52yQwzF2+kam2CjGIeZ5vnuxS0wB6g YEm972d2h9Ffn728GLcoqlRb/r5wQmWVeHecmiKLkEmUKZOUzScS3s0XmtrfCAi64iDazfjT5/r F1JGSOsp6PWWoreiAhrDb77x4Y0K1B/2NAeIYeMcI8RzZw1hnnch8Il8D1pLjO9bqsbCN2WVDO+ bf7Q0zjCCv4Xlo2/6SP+bPr15R+VZWfjDne8l22OtOc/cFXUMjh4utEtuDAu5AGWgFEJyf5oi8I DGPku/a64Y9TmVtYTrvK7EWrk7tD2XU0piwij6GK1sidpzk1F4mysb0O6xVl4GfIk6S5k515MrS ws599EtVW10LYkxigCxnBtQcETXPA1tePRLPE/oBDJHgOVBw/adQ09KpmomET4rplN7FhSCGMjM CHraJxTbEKvPg9JdknRS1e2MTspW5EtMUvERx/b9S0ONGSLaw1AP0sNTAcFamjFSOvAQBouPhb9 ztjKjvBih4QbYmQ== X-Developer-Key: i=tomi.valkeinen@ideasonboard.com; a=openpgp; fpr=C4380C3E965EFD81079FF3A7FA3DAA8CBC961EF5 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 01 Nov 2023 02:21:11 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781352892574411358 X-GMAIL-MSGID: 1781352892574411358 |
Series |
drm/tidss: Probe related fixes and cleanups
|
|
Commit Message
Tomi Valkeinen
Nov. 1, 2023, 9:17 a.m. UTC
tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not,
returns immediately as there's no reason to do any register changes.
However, the code checks for 'crtc->state->enable', which does not
reflect the actual HW state. We should instead look at the
'crtc->state->active' flag.
This causes the tidss_crtc_atomic_flush() to proceed with the flush even
if the active state is false, which then causes us to hit the
WARN_ON(!crtc->state->event) check.
Fix this by checking the active flag, and while at it, fix the related
debug print which had "active" and "needs modeset" wrong way.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_crtc.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
Comments
Hi Tomi, Thank you for the patch. On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote: > tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, > returns immediately as there's no reason to do any register changes. > > However, the code checks for 'crtc->state->enable', which does not > reflect the actual HW state. We should instead look at the > 'crtc->state->active' flag. > > This causes the tidss_crtc_atomic_flush() to proceed with the flush even > if the active state is false, which then causes us to hit the > WARN_ON(!crtc->state->event) check. > > Fix this by checking the active flag, and while at it, fix the related > debug print which had "active" and "needs modeset" wrong way. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > --- > drivers/gpu/drm/tidss/tidss_crtc.c | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c > index 5e5e466f35d1..4c7009a5d643 100644 > --- a/drivers/gpu/drm/tidss/tidss_crtc.c > +++ b/drivers/gpu/drm/tidss/tidss_crtc.c > @@ -169,13 +169,12 @@ static void tidss_crtc_atomic_flush(struct drm_crtc *crtc, > struct tidss_device *tidss = to_tidss(ddev); > unsigned long flags; > > - dev_dbg(ddev->dev, > - "%s: %s enabled %d, needs modeset %d, event %p\n", __func__, > - crtc->name, drm_atomic_crtc_needs_modeset(crtc->state), > - crtc->state->enable, crtc->state->event); > + dev_dbg(ddev->dev, "%s: %s active %d, needs modeset %d, event %p\n", > + __func__, crtc->name, crtc->state->active, > + drm_atomic_crtc_needs_modeset(crtc->state), crtc->state->event); While at it, how about this ? dev_dbg(ddev->dev, "%s: %s is %sactive, %s modeset, event %p\n", __func__, crtc->name, crtc->state->active ? "" : "not ", drm_atomic_crtc_needs_modeset(crtc->state) ? "needs", "doesn't need", crtc->state->event); > > /* There is nothing to do if CRTC is not going to be enabled. */ > - if (!crtc->state->enable) > + if (!crtc->state->active) I think the drm_atomic_helper_commit_planes() helper will handle this if you pass it the DRM_PLANE_COMMIT_ACTIVE_ONLY flag. > return; > > /*
On 01/11/2023 16:56, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote: >> tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, >> returns immediately as there's no reason to do any register changes. >> >> However, the code checks for 'crtc->state->enable', which does not >> reflect the actual HW state. We should instead look at the >> 'crtc->state->active' flag. >> >> This causes the tidss_crtc_atomic_flush() to proceed with the flush even >> if the active state is false, which then causes us to hit the >> WARN_ON(!crtc->state->event) check. >> >> Fix this by checking the active flag, and while at it, fix the related >> debug print which had "active" and "needs modeset" wrong way. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> --- >> drivers/gpu/drm/tidss/tidss_crtc.c | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c >> index 5e5e466f35d1..4c7009a5d643 100644 >> --- a/drivers/gpu/drm/tidss/tidss_crtc.c >> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c >> @@ -169,13 +169,12 @@ static void tidss_crtc_atomic_flush(struct drm_crtc *crtc, >> struct tidss_device *tidss = to_tidss(ddev); >> unsigned long flags; >> >> - dev_dbg(ddev->dev, >> - "%s: %s enabled %d, needs modeset %d, event %p\n", __func__, >> - crtc->name, drm_atomic_crtc_needs_modeset(crtc->state), >> - crtc->state->enable, crtc->state->event); >> + dev_dbg(ddev->dev, "%s: %s active %d, needs modeset %d, event %p\n", >> + __func__, crtc->name, crtc->state->active, >> + drm_atomic_crtc_needs_modeset(crtc->state), crtc->state->event); > > While at it, how about this ? Why not. The active part won't be needed if we use DRM_PLANE_COMMIT_ACTIVE_ONLY, though. > dev_dbg(ddev->dev, "%s: %s is %sactive, %s modeset, event %p\n", > __func__, crtc->name, crtc->state->active ? "" : "not ", > drm_atomic_crtc_needs_modeset(crtc->state) ? "needs", "doesn't need", > crtc->state->event); > >> >> /* There is nothing to do if CRTC is not going to be enabled. */ >> - if (!crtc->state->enable) >> + if (!crtc->state->active) > > I think the drm_atomic_helper_commit_planes() helper will handle this if > you pass it the DRM_PLANE_COMMIT_ACTIVE_ONLY flag. I considered it, but it does a bit more, as it also affects the plane updates. We specifically did not use DRM_PLANE_COMMIT_ACTIVE_ONLY as it didn't work with DSS. That said, I can't figure out what was the issue. It's possible the issue was only on the older DSS HW, with omapdrm (tidss code was originally somewhat based on omapdrm). I'm pretty sure the issue was related to multi-display systems and the plane updates there. But I don't have any multi-display board which uses tidss. So, I'll keep this patch, but add another on top, which uses DRM_PLANE_COMMIT_ACTIVE_ONLY. Then it'll be easy to revert the DRM_PLANE_COMMIT_ACTIVE_ONLY one if needed, while still keeping this fix. Tomi
On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote: > tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, > returns immediately as there's no reason to do any register changes. > > However, the code checks for 'crtc->state->enable', which does not > reflect the actual HW state. We should instead look at the > 'crtc->state->active' flag. > > This causes the tidss_crtc_atomic_flush() to proceed with the flush even > if the active state is false, which then causes us to hit the > WARN_ON(!crtc->state->event) check. > > Fix this by checking the active flag, and while at it, fix the related > debug print which had "active" and "needs modeset" wrong way. Candidate for stable? Add a Fixes tag? Francesco
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c index 5e5e466f35d1..4c7009a5d643 100644 --- a/drivers/gpu/drm/tidss/tidss_crtc.c +++ b/drivers/gpu/drm/tidss/tidss_crtc.c @@ -169,13 +169,12 @@ static void tidss_crtc_atomic_flush(struct drm_crtc *crtc, struct tidss_device *tidss = to_tidss(ddev); unsigned long flags; - dev_dbg(ddev->dev, - "%s: %s enabled %d, needs modeset %d, event %p\n", __func__, - crtc->name, drm_atomic_crtc_needs_modeset(crtc->state), - crtc->state->enable, crtc->state->event); + dev_dbg(ddev->dev, "%s: %s active %d, needs modeset %d, event %p\n", + __func__, crtc->name, crtc->state->active, + drm_atomic_crtc_needs_modeset(crtc->state), crtc->state->event); /* There is nothing to do if CRTC is not going to be enabled. */ - if (!crtc->state->enable) + if (!crtc->state->active) return; /*