[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZUO4f/OjdYW4Paxu@francesco-nb.int.toradex.com>
Date: Thu, 2 Nov 2023 15:55:59 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc: Aradhya Bhatia <a-bhatia1@...com>,
Devarsh Thakkar <devarsht@...com>,
Jyri Sarha <jyri.sarha@....fi>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH 10/10] drm/tidss: Fix atomic_flush check
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
Powered by blists - more mailing lists