mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Laurent Pinchart <laurent.pinchart@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: Thu, 2 Nov 2023 10:23:58 +0200	[thread overview]
Message-ID: <4fc5c307-082d-4c72-90c8-7bd7efcd2184@ideasonboard.com> (raw)
In-Reply-To: <20231101145658.GZ12764@pendragon.ideasonboard.com>

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


  reply	other threads:[~2023-11-02  8:24 UTC|newest]

Thread overview: 34+ 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 ` [PATCH 01/10] drm/tidss: Use pm_runtime_resume_and_get() Tomi Valkeinen
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 13:54   ` Laurent Pinchart
2023-11-02  6:34     ` Tomi Valkeinen
2023-11-05 22:53       ` Laurent Pinchart
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 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 13:57   ` Laurent Pinchart
2023-11-02  6:40     ` Tomi Valkeinen
2023-11-05 22:54       ` Laurent Pinchart
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 13:59   ` Laurent Pinchart
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 14:22   ` Laurent Pinchart
2023-11-01  9:17 ` [PATCH 07/10] drm/tidss: Fix dss reset Tomi Valkeinen
2023-11-01 14:30   ` Laurent Pinchart
2023-11-02  7:33     ` Tomi Valkeinen
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 14:32   ` Laurent Pinchart
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 14:52   ` Laurent Pinchart
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 14:56   ` Laurent Pinchart
2023-11-02  8:23     ` Tomi Valkeinen [this message]
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=4fc5c307-082d-4c72-90c8-7bd7efcd2184@ideasonboard.com \
    --to=tomi.valkeinen@ideasonboard.com \
    --cc=a-bhatia1@ti.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=devarsht@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jyri.sarha@iki.fi \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®