[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260105234452.GH10026@pendragon.ideasonboard.com>
Date: Tue, 6 Jan 2026 01:44:52 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Nicolas Dufresne <nicolas@...fresne.ca>,
Stefan Klug <stefan.klug@...asonboard.com>,
Xavier Roumegue <xavier.roumegue@....nxp.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Clark Williams <clrkwllms@...nel.org>, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH 4/4] media: dw100: Split interrupt handler to fix timeout
error
On Mon, Jan 05, 2026 at 04:37:48PM -0500, Steven Rostedt wrote:
> On Mon, 05 Jan 2026 14:03:58 -0500 Nicolas Dufresne wrote:
> > Le lundi 05 janvier 2026 à 12:35 +0100, Stefan Klug a écrit :
> > > In the previous commit, the interrupt handler was changed to threaded.
> > > This sometimes leads to DW100_INTERRUPT_STATUS_INT_ERR_TIME_OUT being
> > > set after changing the vertex map. This can be seen by repeated error
> > > outputs in dmesg:
> > >
> > > dw100 32e30000.dwe: Interrupt error: 0x1
> > >
> > > As there is no documentation available, it is unclear why that happens
> > > and if this condition can simply be ignored. By splitting the interrupt
> > > handling into two parts and only handling the dw100_job_finish() within
> > > the threaded part, the error does not occur anymore.
> > >
> > > Signed-off-by: Stefan Klug <stefan.klug@...asonboard.com>
> >
> > Ok, but arguably, this could be squashed.
Stefan mentioned that in the cover letter, yes. The patches are
currently split because 4/4 shouldn't be needed based on our
understanding of the hardware. We're hoping for feedback on the issue
from someone with knowledge of the DW100 and access to its
documentation.
> Agreed. Because it doesn't seem to make sense to have a oneshot threaded
> irq handler that doesn't have the two parts (non-threaded to acknowledge the
> irq, and the threaded to handle it and re-enable it).
Why is so ? Isn't oneshot meant exactly for this purpose ? It's
documented as not reenabling the interrupt after the hardirq handler
(which is absent after 3/4) returns, why would a hardirq handler be
mandatory then ?
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists