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

[Maxime Ripard]

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@xxxxxxxxx> 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.

Maxime

Attachment: signature.asc
Description: PGP signature