From: Aradhya Bhatia <aradhya.bhatia@linux.dev>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
Devarsh Thakkar <devarsht@ti.com>, Jyri Sarha <jyri.sarha@iki.fi>
Cc: 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,
Jonathan Cormier <jcormier@criticallink.com>,
Bin Liu <b-liu@ti.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/7] drm/tidss: Fix issue in irq handling causing irq-flood issue
Date: Sun, 24 Nov 2024 22:48:35 +0530 [thread overview]
Message-ID: <e2828b26-8ee9-4140-a377-647f5ae12e2f@linux.dev> (raw)
In-Reply-To: <20241021-tidss-irq-fix-v1-1-82ddaec94e4a@ideasonboard.com>
Hi Tomi, Devarsh,
On 10/21/24 19:37, Tomi Valkeinen wrote:
> It has been observed that sometimes DSS will trigger an interrupt and
> the top level interrupt (DISPC_IRQSTATUS) is not zero, but the VP and
> VID level interrupt-statuses are zero.
Does this mean that there was a legitimate interrupt that potentially
went unrecognized? Or that there was a, for the lack of a better word,
fake interrupt trigger that doesn't need handling but just clearing?
>
> As the top level irqstatus is supposed to tell whether we have VP/VID
> interrupts, the thinking of the driver authors was that this particular
> case could never happen. Thus the driver only clears the DISPC_IRQSTATUS
> bits which has corresponding interrupts in VP/VID status. So when this
> issue happens, the driver will not clear DISPC_IRQSTATUS, and we get an
> interrupt flood.
>
> It is unclear why the issue happens. It could be a race issue in the
> driver, but no such race has been found. It could also be an issue with
> the HW. However a similar case can be easily triggered by manually
> writing to DISPC_IRQSTATUS_RAW. This will forcibly set a bit in the
> DISPC_IRQSTATUS and trigger an interrupt, and as the driver never clears
> the bit, we get an interrupt flood.
>
> To fix the issue, always clear DISPC_IRQSTATUS. The concern with this
> solution is that if the top level irqstatus is the one that triggers the
> interrupt, always clearing DISPC_IRQSTATUS might leave some interrupts
> unhandled if VP/VID interrupt statuses have bits set. However, testing
> shows that if any of the irqstatuses is set (i.e. even if
> DISPC_IRQSTATUS == 0, but a VID irqstatus has a bit set), we will get an
> interrupt.
Does this mean if VID/VP irqstatus has been set right around the time
the equivalent DISPC_IRQSTATUS bit is being cleared, the equivalent
DISPC_IRQSTATUS bit is going to get set again, and make the driver
handle the event as we expect it to?
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Co-developed-by: Bin Liu <b-liu@ti.com>
> Signed-off-by: Bin Liu <b-liu@ti.com>
> Co-developed-by: Devarsh Thakkar <devarsht@ti.com>
> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> Co-developed-by: Jonathan Cormier <jcormier@criticallink.com>
> Signed-off-by: Jonathan Cormier <jcormier@criticallink.com>
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
> Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/tidss/tidss_dispc.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c
> index 1ad711f8d2a8..f81111067578 100644
> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
> @@ -780,24 +780,20 @@ static
> void dispc_k3_clear_irqstatus(struct dispc_device *dispc, dispc_irq_t clearmask)
> {
> unsigned int i;
> - u32 top_clear = 0;
>
> for (i = 0; i < dispc->feat->num_vps; ++i) {
> - if (clearmask & DSS_IRQ_VP_MASK(i)) {
> + if (clearmask & DSS_IRQ_VP_MASK(i))
> dispc_k3_vp_write_irqstatus(dispc, i, clearmask);
> - top_clear |= BIT(i);
> - }
> }
> for (i = 0; i < dispc->feat->num_planes; ++i) {
> - if (clearmask & DSS_IRQ_PLANE_MASK(i)) {
> + if (clearmask & DSS_IRQ_PLANE_MASK(i))
> dispc_k3_vid_write_irqstatus(dispc, i, clearmask);
> - top_clear |= BIT(4 + i);
> - }
> }
nit: Maybe these for-loop braces could be dropped as well.
Otherwise, LGTM,
Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Regards
Aradhya
[..]
next prev parent reply other threads:[~2024-11-24 17:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 14:07 [PATCH 0/7] drm/tidss: Interrupt fixes and cleanups Tomi Valkeinen
2024-10-21 14:07 ` [PATCH 1/7] drm/tidss: Fix issue in irq handling causing irq-flood issue Tomi Valkeinen
2024-10-21 15:19 ` Jon Cormier
2024-10-21 15:21 ` Jon Cormier
2024-11-24 17:18 ` Aradhya Bhatia [this message]
2024-11-25 11:08 ` Tomi Valkeinen
2024-10-21 14:07 ` [PATCH 2/7] drm/tidss: Remove unused OCP error flag Tomi Valkeinen
2024-11-22 8:00 ` Devarsh Thakkar
2024-11-24 17:19 ` Aradhya Bhatia
2024-10-21 14:07 ` [PATCH 3/7] drm/tidss: Remove extra K2G check Tomi Valkeinen
2024-11-22 8:00 ` Devarsh Thakkar
2024-11-24 17:20 ` Aradhya Bhatia
2024-10-21 14:07 ` [PATCH 4/7] drm/tidss: Add printing of underflows Tomi Valkeinen
2024-11-22 8:07 ` Devarsh Thakkar
2024-11-24 17:26 ` Aradhya Bhatia
2024-10-21 14:07 ` [PATCH 5/7] drm/tidss: Clear the interrupt status for interrupts being disabled Tomi Valkeinen
2024-10-21 15:13 ` Jon Cormier
2024-11-24 17:28 ` Aradhya Bhatia
2024-10-21 14:07 ` [PATCH 6/7] drm/tidss: Fix race condition while handling interrupt registers Tomi Valkeinen
2024-10-21 15:14 ` Jon Cormier
2024-11-24 17:29 ` Aradhya Bhatia
2024-10-21 14:07 ` [PATCH 7/7] drm/tidss: Rename 'wait_lock' to 'irq_lock' Tomi Valkeinen
2024-11-22 8:09 ` Devarsh Thakkar
2024-11-24 17:30 ` Aradhya Bhatia
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=e2828b26-8ee9-4140-a377-647f5ae12e2f@linux.dev \
--to=aradhya.bhatia@linux.dev \
--cc=airlied@gmail.com \
--cc=b-liu@ti.com \
--cc=daniel@ffwll.ch \
--cc=devarsht@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jcormier@criticallink.com \
--cc=jyri.sarha@iki.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=stable@vger.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.