Message-ID: <20251119085127.6e3e429e@bootlin.com>
Date: Wed, 19 Nov 2025 08:51:27 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Maxime Ripard <mripard@...nel.org>
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

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.

Best regards,
Hervé

Powered by blists - more mailing lists