All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Aradhya Bhatia <a-bhatia1@ti.com>,
	Devarsh Thakkar <devarsht@ti.com>,
	linux-kernel@vger.kernel.org, Maxime Ripard <mripard@kernel.org>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Jyri Sarha <jyri.sarha@iki.fi>
Subject: Re: [PATCH 10/10] drm/tidss: Fix atomic_flush check
Date: Wed, 1 Nov 2023 16:56:58 +0200	[thread overview]
Message-ID: <20231101145658.GZ12764@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20231101-tidss-probe-v1-10-45149e0f9415@ideasonboard.com>

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;
>  
>  	/*

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: 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>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] drm/tidss: Fix atomic_flush check
Date: Wed, 1 Nov 2023 16:56:58 +0200	[thread overview]
Message-ID: <20231101145658.GZ12764@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20231101-tidss-probe-v1-10-45149e0f9415@ideasonboard.com>

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;
>  
>  	/*

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-11-01 14:56 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01  9:17 [PATCH 00/10] drm/tidss: Probe related fixes and cleanups Tomi Valkeinen
2023-11-01  9:17 ` Tomi Valkeinen
2023-11-01  9:17 ` [PATCH 01/10] drm/tidss: Use pm_runtime_resume_and_get() Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 13:47   ` Laurent Pinchart
2023-11-01 13:47     ` Laurent Pinchart
2023-11-01  9:17 ` [PATCH 02/10] drm/tidss: Use PM autosuspend Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 13:54   ` Laurent Pinchart
2023-11-01 13:54     ` Laurent Pinchart
2023-11-02  6:34     ` Tomi Valkeinen
2023-11-02  6:34       ` Tomi Valkeinen
2023-11-05 22:53       ` Laurent Pinchart
2023-11-05 22:53         ` Laurent Pinchart
2023-11-06  7:54         ` Tomi Valkeinen
2023-11-06  7:54           ` Tomi Valkeinen
2023-11-01  9:17 ` [PATCH 03/10] drm/tidss: Drop useless variable init Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 13:54   ` Laurent Pinchart
2023-11-01 13:54     ` Laurent Pinchart
2023-11-01  9:17 ` [PATCH 04/10] drm/tidss: Move reset to the end of dispc_init() Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 13:57   ` Laurent Pinchart
2023-11-01 13:57     ` Laurent Pinchart
2023-11-02  6:40     ` Tomi Valkeinen
2023-11-02  6:40       ` Tomi Valkeinen
2023-11-05 22:54       ` Laurent Pinchart
2023-11-05 22:54         ` Laurent Pinchart
2023-11-06 11:56         ` Tomi Valkeinen
2023-11-06 11:56           ` Tomi Valkeinen
2023-11-01  9:17 ` [PATCH 05/10] drm/tidss: Return error value from from softreset Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 13:59   ` Laurent Pinchart
2023-11-01 13:59     ` Laurent Pinchart
2023-11-02  6:44     ` Tomi Valkeinen
2023-11-02  6:44       ` Tomi Valkeinen
2023-11-01  9:17 ` [PATCH 06/10] drm/tidss: Check for K2G in in dispc_softreset() Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 14:22   ` Laurent Pinchart
2023-11-01 14:22     ` Laurent Pinchart
2023-11-01  9:17 ` [PATCH 07/10] drm/tidss: Fix dss reset Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 14:30   ` Laurent Pinchart
2023-11-01 14:30     ` Laurent Pinchart
2023-11-02  7:33     ` Tomi Valkeinen
2023-11-02  7:33       ` Tomi Valkeinen
2023-11-02 14:54   ` Francesco Dolcini
2023-11-02 14:54     ` Francesco Dolcini
2023-11-01  9:17 ` [PATCH 08/10] drm/tidss: Add dispc_is_idle() Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 14:32   ` Laurent Pinchart
2023-11-01 14:32     ` Laurent Pinchart
2023-11-02  7:03     ` Tomi Valkeinen
2023-11-02  7:03       ` Tomi Valkeinen
2023-11-01  9:17 ` [PATCH 09/10] drm/tidss: IRQ code cleanup Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 14:52   ` Laurent Pinchart
2023-11-01 14:52     ` Laurent Pinchart
2023-11-02  7:00     ` Tomi Valkeinen
2023-11-02  7:00       ` Tomi Valkeinen
2023-11-01  9:17 ` [PATCH 10/10] drm/tidss: Fix atomic_flush check Tomi Valkeinen
2023-11-01  9:17   ` Tomi Valkeinen
2023-11-01 14:56   ` Laurent Pinchart [this message]
2023-11-01 14:56     ` Laurent Pinchart
2023-11-02  8:23     ` Tomi Valkeinen
2023-11-02  8:23       ` Tomi Valkeinen
2023-11-02 14:55   ` Francesco Dolcini
2023-11-02 14:55     ` Francesco Dolcini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231101145658.GZ12764@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a-bhatia1@ti.com \
    --cc=devarsht@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jyri.sarha@iki.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.