linux-kernel - Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink On/Off

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251113091910.GA15538@francesco-nb>
Date: Thu, 13 Nov 2025 10:19:10 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: Herve Codina <herve.codina@...tlin.com>
Cc: 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>,
	Maxime Ripard <mripard@...nel.org>,
	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
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink
 On/Off

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 don't think that masking the error would be the correct solution.
> The root cause has to be identified. The "sn65dsi83 2-002c: Unexpected link
> status 0x01" should not appear.
> 
> Can you check your clocks ?
> Does your hardware use the REFCLK external clock ?

No, REFCLK is tied to GND.

> The driver expects the clock from the MIPI D-PHY channel A HS continuous (bit 0
> in 0x0A register).

Francesco