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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251113084950.44a09e8e@bootlin.com>
Date: Thu, 13 Nov 2025 08:49:50 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: João Paulo Gonçalves
 <jpaulo.silvagoncalves@...il.com>
Cc: 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

Hi João

On Mon, 10 Nov 2025 16:03:51 -0300
João Paulo Gonçalves <jpaulo.silvagoncalves@...il.com> wrote:

> Hello,
> 
> 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.

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 ?

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

Best regards,
Hervé

clock