Message-ID: <gw635fewdxe7falrxz44gxstiuzjpmeh45rwe5bglto524faaz@hj4z2vh22p5n>
Date: Wed, 19 Nov 2025 09:40:11 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Luca Ceresoli <luca.ceresoli@...tlin.com>, 
	Francesco Dolcini <francesco@...cini.it>, 
	João Paulo Gonçalves <jpaulo.silvagoncalves@...il.com>, Andrzej Hajda <andrzej.hajda@...el.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, 
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, 
	João Paulo Gonçalves <joao.goncalves@...adex.com>, linux-kernel@...r.kernel.org, regressions@...ts.linux.dev, 
	thomas.petazzoni@...tlin.com
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink
 On/Off

On Wed, Nov 19, 2025 at 08:51:27AM +0100, Herve Codina wrote:
> Hi Maxime,
> 
> On Tue, 18 Nov 2025 17:56:36 +0100
> Maxime Ripard <mripard@...nel.org> wrote:
> 
> > On Mon, Nov 17, 2025 at 04:27:28PM +0100, Luca Ceresoli wrote:
> > > On Thu Nov 13, 2025 at 10:19 AM CET, Francesco Dolcini wrote:  
> > > > On Thu, Nov 13, 2025 at 08:49:50AM +0100, Herve Codina wrote:  
> > > >> On Mon, 10 Nov 2025 16:03:51 -0300
> > > >> João Paulo Gonçalves <jpaulo.silvagoncalves@...il.com> wrote:  
> > > >> > After commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error
> > > >> > recovery mechanism"), our DSI display stopped working correctly. The
> > > >> > display internally uses a TI SN65DSI83 to convert DSI-to-LVDS, and with
> > > >> > the change, it keeps blinking on and off because the bridge is being
> > > >> > reset by the error recovery mechanism.
> > > >> >
> > > >> > Even before the change, it was possible to see the message below from
> > > >> > the driver indicating that the bridge's internal PLL was not locked
> > > >> > (register 0xE5, bit 0 in [1]):
> > > >> >
> > > >> > [ 11.198616] sn65dsi83 2-002c: Unexpected link status 0x01
> > > >> >
> > > >> > However, it was working. After the change, it stopped working. Masking
> > > >> > the PLL error makes it work again:
> > > >> >
> > > >> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > >> > index 033c44326552..89a0a2ab45b1 100644
> > > >> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > >> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > >> > @@ -429,7 +429,7 @@ static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx)
> > > >> >          */
> > > >> >
> > > >> >         ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat);
> > > >> > -       if (ret || irq_stat) {
> > > >> > +       if (ret || (irq_stat & ~REG_IRQ_STAT_CHA_PLL_UNLOCK)) {
> > > >> >                 /*
> > > >> >                  * IRQ acknowledged is not always possible (the bridge can be in
> > > >> >                  * a state where it doesn't answer anymore). To prevent an
> > > >> >
> > > >> > Any suggestions on how to proceed here?
> > > >> >
> > > >> > #regzbot introduced: ad5c6ecef27e
> > > >> >
> > > >> > [1] https://www.ti.com/lit/ds/symlink/sn65dsi83.pdf
> > > >> >  
> > > >>
> > > >> The PLL should be locked.
> > > >>
> > > >> Also in the datasheet, in 'Table 7-2. Initialization Sequence', the status
> > > >> is checked at the end of the initialization sequence and the sequence has to
> > > >> be done again when the status register value is not 0x00.
> > > >>
> > > >> Even before monitoring (irq or polling method), you have an issue with your PLL
> > > >> mentioned with the "sn65dsi83 2-002c: Unexpected link status 0x01" message.
> > > >>
> > > >> I don't understand even how your panel can be correctly driven with the bridge
> > > >> PLL unlock.  
> > > >
> > > > We'll try to figure out the reason and see what's the best path forward.
> > > >
> > > > Whatever was the reason it was working before, and it should stay
> > > > working  
> > > 
> > > I agree with Hervé that using the chip with an unlocked PLL looks dangerous
> > > and totally out of spec. So I encourage you to investigate what is going on
> > > in the hardware looking for the root cause, checking whether the PLL is
> > > really unlocked and how to get it working properly.
> > > 
> > > The driver should be definitely be written focusing on the nominal case and
> > > handle out-of-spec cases as an exception, not the other way around.
> > > 
> > > I also agree your hardware should not stop working when upgrading to a new
> > > kernel, so this investigation would ideally nail down tha root cause and
> > > point to a solution in a very short time.
> > > 
> > > Hervé has matured quite some experience on SN65DSI84 error management,
> > > leading to his error recovery patch, and I also have a board with that chip
> > > on my desk. So we may be helpful in discussion, as well as reviewing and
> > > testing patches.  
> > 
> > I'd say we should do it the other way around. If that patch breaks
> > systems that were working fine so far without a clear reason, we should
> > revert the offending commit, and *then* work towards a solution to
> > support error recovery that doesn't break that system.
> > 
> 
> I have the feeling that the broken system has an issue from the beginning.
> Why its PLL has been unlocked ?
> 
> I would like to understand what happens but, of course, I don't have the
> hardware to investigate.
> 
> Could the issue been on a component before the SN65DSI83 bridge?
> I mean the component in charge of generating the DSI clock can be a culprit.

I understand what you're saying, but it's not the right way to think about it.

Let's change perspective.

Your work laptop just got a kernel upgrade, and its display doesn't work
anymore. Would you be happy with the answer "it was broken all along, we
might be able to help you fix it, maybe not, who knows when we'll have a
fix"?

It's frustrating, you might not even be able to debug it in the first
place, and most importantly, broken or not, it used to work just fine.

If it used to work for years, how can you possibly argue that it was
broken all along?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists