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

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

[João Paulo Gonçalves]

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

Best Regards,
João Paulo Gonçalves

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

[Herve Codina]

Hi João

On Mon, 10 Nov 2025 16:03:51 -0300
João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.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

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

[Francesco Dolcini]

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

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

[Luca Ceresoli]

Hello João, Francesco,

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

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3910 bytes --]

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

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Herve Codina]

Hi Maxime,

On Tue, 18 Nov 2025 17:56:36 +0100
Maxime Ripard <mripard@kernel.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@gmail.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é

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 5369 bytes --]

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@kernel.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@gmail.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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Tomi Valkeinen]

Hi,

On 19/11/2025 10:40, Maxime Ripard wrote:
> 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@kernel.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@gmail.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?
I agree.

We could either revert the error handling, or change it to a print
(dev_dbg? but will it flood-print then if the unlock irq is being raised
all the time) instead of doing a reset.

 Tomi

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

[Luca Ceresoli]

Hi Maxime, João, Francesco,

On Wed Nov 19, 2025 at 9:40 AM CET, Maxime Ripard wrote:
> 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@kernel.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@gmail.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?

Fully understood, and we fully agree on the principle.

My hope is that João/Francesco can investigate and find the root cause, and
we can find a solution that works for both cases in a short time (say, this
week).

Without that we'd of course need to revert, but the next minute we'd still
need to find a solution to make error management work in the nominal case,
and I suspect we may end up with an ugly "works-without-pll" quirk and keep
it forever.

João, Francesco, on what hardware do you observe the problem? Which SoC?
Which encoder, any previous bridges?

Which clock rates?

Which is the board dts?

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Francesco Dolcini]

Hello Luca, Herve

On Wed, Nov 19, 2025 at 11:08:23AM +0100, Luca Ceresoli wrote:
> 
> On Wed Nov 19, 2025 at 9:40 AM CET, Maxime Ripard wrote:
> > On Wed, Nov 19, 2025 at 08:51:27AM +0100, Herve Codina wrote:
> >> On Tue, 18 Nov 2025 17:56:36 +0100
> >> Maxime Ripard <mripard@kernel.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@gmail.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?
> 
> Fully understood, and we fully agree on the principle.
> 
> My hope is that João/Francesco can investigate and find the root cause, and
> we can find a solution that works for both cases in a short time (say, this
> week).

This week it will not happen, unfortunately :-(. I have no time to look
into it and João has no longer access to the hardware.

> Without that we'd of course need to revert, but the next minute we'd still
> need to find a solution to make error management work in the nominal case,
> and I suspect we may end up with an ugly "works-without-pll" quirk and keep
> it forever.

So, it seems that the actual DSI clock is the root cause, and from some
check yesterday it's not possible to fix it (limitation on the clock
generation). In practice the display is working fine with the PLL not
locked (quite some people is using it without any issue).


> João, Francesco, on what hardware do you observe the problem? Which SoC?
> Which encoder, any previous bridges?

Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi

There is a DPI to DSI bridge in the module, tc358778, it has a 25MHz
reference clock.

TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> Display

From a preliminary investigation this is a HW limitation, we are not
able to generate a "good enough" DSI clock, see tc358768_calc_pll() for
the actual code implementation of it, I believe that the datasheet is
not available without NDA.

Maybe the ugly hack "works-without-pll" is the way to work? It will
require a DT change, but this seems doable.

Please note that this is the outcome of a short investigation done
yesterday afternoon, so maybe I am overlooking something, unfortunately
I do not have the bandwidth to work on it more this week.

> Which clock rates?
71100000

Francesco

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

[Tomi Valkeinen]

Hi,

On 19/11/2025 13:12, Francesco Dolcini wrote:
> Hello Luca, Herve
> 
> On Wed, Nov 19, 2025 at 11:08:23AM +0100, Luca Ceresoli wrote:
>>
>> On Wed Nov 19, 2025 at 9:40 AM CET, Maxime Ripard wrote:
>>> On Wed, Nov 19, 2025 at 08:51:27AM +0100, Herve Codina wrote:
>>>> On Tue, 18 Nov 2025 17:56:36 +0100
>>>> Maxime Ripard <mripard@kernel.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@gmail.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?
>>
>> Fully understood, and we fully agree on the principle.
>>
>> My hope is that João/Francesco can investigate and find the root cause, and
>> we can find a solution that works for both cases in a short time (say, this
>> week).
> 
> This week it will not happen, unfortunately :-(. I have no time to look
> into it and João has no longer access to the hardware.
> 
>> Without that we'd of course need to revert, but the next minute we'd still
>> need to find a solution to make error management work in the nominal case,
>> and I suspect we may end up with an ugly "works-without-pll" quirk and keep
>> it forever.
> 
> So, it seems that the actual DSI clock is the root cause, and from some
> check yesterday it's not possible to fix it (limitation on the clock
> generation). In practice the display is working fine with the PLL not
> locked (quite some people is using it without any issue).

I might be mistaken, but I don't think the PLL will work if unlocked...
But maybe the case is that it unlocks and lock again right afterwards.
>> João, Francesco, on what hardware do you observe the problem? Which SoC?
>> Which encoder, any previous bridges?
> 
> Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> 
> There is a DPI to DSI bridge in the module, tc358778, it has a 25MHz
> reference clock.
> 
> TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> Display
> 
> From a preliminary investigation this is a HW limitation, we are not
> able to generate a "good enough" DSI clock, see tc358768_calc_pll() for

I haven't studied the docs or done any testing, but I would think that
it doesn't matter for the PLL even if the incoming DSI clock is a bit
off, as long as it's continuous and stable.

My first thought was that the DSI is using non-continuous clock, but at
least the driver has code to drop the MIPI_DSI_CLOCK_NON_CONTINUOUS flag.

> the actual code implementation of it, I believe that the datasheet is
> not available without NDA.
> 
> Maybe the ugly hack "works-without-pll" is the way to work? It will
> require a DT change, but this seems doable.

Revert is easier than adding new hacky DT properties... At least until
the problem is understood.

> Please note that this is the outcome of a short investigation done
> yesterday afternoon, so maybe I am overlooking something, unfortunately
> I do not have the bandwidth to work on it more this week.
> 
>> Which clock rates?
> 71100000
It would be a good test to try out with a few different clocks.

 Tomi

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

[Francesco Dolcini]

On Wed, Nov 19, 2025 at 02:09:04PM +0200, Tomi Valkeinen wrote:
> On 19/11/2025 13:12, Francesco Dolcini wrote:
> > On Wed, Nov 19, 2025 at 11:08:23AM +0100, Luca Ceresoli wrote:
> >>
> >> On Wed Nov 19, 2025 at 9:40 AM CET, Maxime Ripard wrote:
> >>> On Wed, Nov 19, 2025 at 08:51:27AM +0100, Herve Codina wrote:
> >>>> On Tue, 18 Nov 2025 17:56:36 +0100
> >>>> Maxime Ripard <mripard@kernel.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@gmail.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?
> >>
> >> Fully understood, and we fully agree on the principle.
> >>
> >> My hope is that João/Francesco can investigate and find the root cause, and
> >> we can find a solution that works for both cases in a short time (say, this
> >> week).
> > 
> > This week it will not happen, unfortunately :-(. I have no time to look
> > into it and João has no longer access to the hardware.
> > 
> >> Without that we'd of course need to revert, but the next minute we'd still
> >> need to find a solution to make error management work in the nominal case,
> >> and I suspect we may end up with an ugly "works-without-pll" quirk and keep
> >> it forever.
> > 
> > So, it seems that the actual DSI clock is the root cause, and from some
> > check yesterday it's not possible to fix it (limitation on the clock
> > generation). In practice the display is working fine with the PLL not
> > locked (quite some people is using it without any issue).
> 
> I might be mistaken, but I don't think the PLL will work if unlocked...
> But maybe the case is that it unlocks and lock again right afterwards.
> >> João, Francesco, on what hardware do you observe the problem? Which SoC?
> >> Which encoder, any previous bridges?
> > 
> > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> > 
> > There is a DPI to DSI bridge in the module, tc358778, it has a 25MHz
> > reference clock.
> > 
> > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> Display
> > 
> > From a preliminary investigation this is a HW limitation, we are not
> > able to generate a "good enough" DSI clock, see tc358768_calc_pll() for
> 
> I haven't studied the docs or done any testing, but I would think that
> it doesn't matter for the PLL even if the incoming DSI clock is a bit
> off, as long as it's continuous and stable.
> 
> My first thought was that the DSI is using non-continuous clock, but at
> least the driver has code to drop the MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
> 
> > the actual code implementation of it, I believe that the datasheet is
> > not available without NDA.
> > 
> > Maybe the ugly hack "works-without-pll" is the way to work? It will
> > require a DT change, but this seems doable.
> 
> Revert is easier than adding new hacky DT properties... At least until
> the problem is understood.
> 
> > Please note that this is the outcome of a short investigation done
> > yesterday afternoon, so maybe I am overlooking something, unfortunately
> > I do not have the bandwidth to work on it more this week.
> > 
> >> Which clock rates?
> > 71100000
> It would be a good test to try out with a few different clocks.

50 MHz works, for example.

It seems that the issue exists when the actual display clock is different
from the dsi clock. And this can happen for the reason I explained
before (the DSI clock is computed starting from this 25MHz reference
clock).

Francesco

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

[Luca Ceresoli]

Hello,

On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
...
>> I might be mistaken, but I don't think the PLL will work if unlocked...
>> But maybe the case is that it unlocks and lock again right afterwards.
>> >> João, Francesco, on what hardware do you observe the problem? Which SoC?
>> >> Which encoder, any previous bridges?
>> >
>> > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
>> >
>> > There is a DPI to DSI bridge in the module, tc358778, it has a 25MHz
>> > reference clock.
>> >
>> > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> Display
>> >
>> > From a preliminary investigation this is a HW limitation, we are not
>> > able to generate a "good enough" DSI clock, see tc358768_calc_pll() for

Thanks Francesco for the feedback!

I'm not sure I completely understand the issue described, but if the TI
bridge requires a clock that cannot be provided by the hardware, then this
actually looks like "a HW limitation" as you wrote, due to a HW integration
limitation/bug/issue/whatever. In case this is confirmed, I think quirks
are an appropriate tool to handle HW integration issues.

>> I haven't studied the docs or done any testing, but I would think that
>> it doesn't matter for the PLL even if the incoming DSI clock is a bit
>> off, as long as it's continuous and stable.
>>
>> My first thought was that the DSI is using non-continuous clock, but at
>> least the driver has code to drop the MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
>>
>> > the actual code implementation of it, I believe that the datasheet is
>> > not available without NDA.
>> >
>> > Maybe the ugly hack "works-without-pll" is the way to work? It will
>> > require a DT change, but this seems doable.
>>
>> Revert is easier than adding new hacky DT properties... At least until
>> the problem is understood.
>>
>> > Please note that this is the outcome of a short investigation done
>> > yesterday afternoon, so maybe I am overlooking something, unfortunately
>> > I do not have the bandwidth to work on it more this week.
>> >
>> >> Which clock rates?
>> > 71100000
>> It would be a good test to try out with a few different clocks.
>
> 50 MHz works, for example.
>
> It seems that the issue exists when the actual display clock is different
> from the dsi clock. And this can happen for the reason I explained
> before (the DSI clock is computed starting from this 25MHz reference
> clock).


--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Herve Codina]

Hi Luca, Francesco, others

On Wed, 19 Nov 2025 18:27:38 +0100
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:

> Hello,
> 
> On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
> ...
> >> I might be mistaken, but I don't think the PLL will work if unlocked...
> >> But maybe the case is that it unlocks and lock again right afterwards.  
> >> >> João, Francesco, on what hardware do you observe the problem? Which SoC?
> >> >> Which encoder, any previous bridges?  
> >> >
> >> > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> >> >
> >> > There is a DPI to DSI bridge in the module, tc358778, it has a 25MHz
> >> > reference clock.
> >> >
> >> > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> Display
> >> >
> >> > From a preliminary investigation this is a HW limitation, we are not
> >> > able to generate a "good enough" DSI clock, see tc358768_calc_pll() for  
> 
> Thanks Francesco for the feedback!
> 
> I'm not sure I completely understand the issue described, but if the TI
> bridge requires a clock that cannot be provided by the hardware, then this
> actually looks like "a HW limitation" as you wrote, due to a HW integration
> limitation/bug/issue/whatever. In case this is confirmed, I think quirks
> are an appropriate tool to handle HW integration issues.
> 
> >> I haven't studied the docs or done any testing, but I would think that
> >> it doesn't matter for the PLL even if the incoming DSI clock is a bit
> >> off, as long as it's continuous and stable.
> >>
> >> My first thought was that the DSI is using non-continuous clock, but at
> >> least the driver has code to drop the MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
> >>  
> >> > the actual code implementation of it, I believe that the datasheet is
> >> > not available without NDA.
> >> >
> >> > Maybe the ugly hack "works-without-pll" is the way to work? It will
> >> > require a DT change, but this seems doable.  
> >>
> >> Revert is easier than adding new hacky DT properties... At least until
> >> the problem is understood.
> >>  
> >> > Please note that this is the outcome of a short investigation done
> >> > yesterday afternoon, so maybe I am overlooking something, unfortunately
> >> > I do not have the bandwidth to work on it more this week.
> >> >  
> >> >> Which clock rates?  
> >> > 71100000  
> >> It would be a good test to try out with a few different clocks.  
> >
> > 50 MHz works, for example.
> >
> > It seems that the issue exists when the actual display clock is different
> > from the dsi clock. And this can happen for the reason I explained
> > before (the DSI clock is computed starting from this 25MHz reference
> > clock).  
> 

If there is no way to set a correct clock, I agree with Luca a quirk should
be the best solution.

For instance, in the dts:
  ti,pll_may_unlock_quirk;

In the driver, mask the PLL unlock status bit from monitoring (polling
and irq) if this boolean property is true:
 - Mask IRQ PLL Unlock bit in REG_IRQ_EN when IRQ are enabled
 - Mask IRQ PLL Unlock bit in REG_IRQ_STAT in sn65dsi83_handle_errors() to
   avoid a recover process on PLL unlock.

Best regards,
Hervé

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

[Philippe Schenker]

[-- Attachment #1: Type: text/plain, Size: 4405 bytes --]



On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
> Hi Luca, Francesco, others
> 
> On Wed, 19 Nov 2025 18:27:38 +0100
> "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> 
> > Hello,
> > 
> > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
> > ...
> > > > I might be mistaken, but I don't think the PLL will work if
> > > > unlocked...
> > > > But maybe the case is that it unlocks and lock again right
> > > > afterwards.  
> > > > > > João, Francesco, on what hardware do you observe the
> > > > > > problem? Which SoC?
> > > > > > Which encoder, any previous bridges?  
> > > > > 
> > > > > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
> > > > > verdin.dtsi
> > > > > 
> > > > > There is a DPI to DSI bridge in the module, tc358778, it has
> > > > > a 25MHz
> > > > > reference clock.
> > > > > 
> > > > > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
> > > > > Display
> > > > > 
> > > > > From a preliminary investigation this is a HW limitation, we
> > > > > are not
> > > > > able to generate a "good enough" DSI clock, see
> > > > > tc358768_calc_pll() for  
> > 
> > Thanks Francesco for the feedback!
> > 
> > I'm not sure I completely understand the issue described, but if
> > the TI
> > bridge requires a clock that cannot be provided by the hardware,
> > then this
> > actually looks like "a HW limitation" as you wrote, due to a HW
> > integration
> > limitation/bug/issue/whatever. In case this is confirmed, I think
> > quirks
> > are an appropriate tool to handle HW integration issues.
> > 
> > > > I haven't studied the docs or done any testing, but I would
> > > > think that
> > > > it doesn't matter for the PLL even if the incoming DSI clock is
> > > > a bit
> > > > off, as long as it's continuous and stable.
> > > > 
> > > > My first thought was that the DSI is using non-continuous
> > > > clock, but at
> > > > least the driver has code to drop the
> > > > MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
> > > >  
> > > > > the actual code implementation of it, I believe that the
> > > > > datasheet is
> > > > > not available without NDA.
> > > > > 
> > > > > Maybe the ugly hack "works-without-pll" is the way to work?
> > > > > It will
> > > > > require a DT change, but this seems doable.  
> > > > 
> > > > Revert is easier than adding new hacky DT properties... At
> > > > least until
> > > > the problem is understood.
> > > >  
> > > > > Please note that this is the outcome of a short investigation
> > > > > done
> > > > > yesterday afternoon, so maybe I am overlooking something,
> > > > > unfortunately
> > > > > I do not have the bandwidth to work on it more this week.
> > > > >  
> > > > > > Which clock rates?  
> > > > > 71100000  
> > > > It would be a good test to try out with a few different
> > > > clocks.  
> > > 
> > > 50 MHz works, for example.
> > > 
> > > It seems that the issue exists when the actual display clock is
> > > different
> > > from the dsi clock. And this can happen for the reason I
> > > explained
> > > before (the DSI clock is computed starting from this 25MHz
> > > reference
> > > clock).  
> > 
> 
> If there is no way to set a correct clock, I agree with Luca a quirk
> should
> be the best solution.
> 
> For instance, in the dts:
>   ti,pll_may_unlock_quirk;

I followed the discussion only loosely. But I once worked on bringing
up the SN65DSI83 and from what I can remember is that there was a
frequency range of the input clock where the PLL of SN65DSI83 just did
not lock at all.

I couldn't explain what was happening since the clock I fed was within
the limits of the documentation I had.

What I ultimately did was to just choose a clock that works. Given that
experience I'm not sure about adding quirks on TI side.

But anyway I'm not very familiar with the topic and it's a long time
since I worked on it. Just wanted to point out this experience I had,
maybe it helps.

Best Regards,
Philippe

> 
> In the driver, mask the PLL unlock status bit from monitoring
> (polling
> and irq) if this boolean property is true:
>  - Mask IRQ PLL Unlock bit in REG_IRQ_EN when IRQ are enabled
>  - Mask IRQ PLL Unlock bit in REG_IRQ_STAT in
> sn65dsi83_handle_errors() to
>    avoid a recover process on PLL unlock.
> 
> Best regards,
> Hervé

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 717 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3180 bytes --]

On Wed, Nov 19, 2025 at 07:40:23PM +0100, Herve Codina wrote:
> Hi Luca, Francesco, others
> 
> On Wed, 19 Nov 2025 18:27:38 +0100
> "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> 
> > Hello,
> > 
> > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
> > ...
> > >> I might be mistaken, but I don't think the PLL will work if unlocked...
> > >> But maybe the case is that it unlocks and lock again right afterwards.  
> > >> >> João, Francesco, on what hardware do you observe the problem? Which SoC?
> > >> >> Which encoder, any previous bridges?  
> > >> >
> > >> > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
> > >> >
> > >> > There is a DPI to DSI bridge in the module, tc358778, it has a 25MHz
> > >> > reference clock.
> > >> >
> > >> > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> Display
> > >> >
> > >> > From a preliminary investigation this is a HW limitation, we are not
> > >> > able to generate a "good enough" DSI clock, see tc358768_calc_pll() for  
> > 
> > Thanks Francesco for the feedback!
> > 
> > I'm not sure I completely understand the issue described, but if the TI
> > bridge requires a clock that cannot be provided by the hardware, then this
> > actually looks like "a HW limitation" as you wrote, due to a HW integration
> > limitation/bug/issue/whatever. In case this is confirmed, I think quirks
> > are an appropriate tool to handle HW integration issues.
> > 
> > >> I haven't studied the docs or done any testing, but I would think that
> > >> it doesn't matter for the PLL even if the incoming DSI clock is a bit
> > >> off, as long as it's continuous and stable.
> > >>
> > >> My first thought was that the DSI is using non-continuous clock, but at
> > >> least the driver has code to drop the MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
> > >>  
> > >> > the actual code implementation of it, I believe that the datasheet is
> > >> > not available without NDA.
> > >> >
> > >> > Maybe the ugly hack "works-without-pll" is the way to work? It will
> > >> > require a DT change, but this seems doable.  
> > >>
> > >> Revert is easier than adding new hacky DT properties... At least until
> > >> the problem is understood.
> > >>  
> > >> > Please note that this is the outcome of a short investigation done
> > >> > yesterday afternoon, so maybe I am overlooking something, unfortunately
> > >> > I do not have the bandwidth to work on it more this week.
> > >> >  
> > >> >> Which clock rates?  
> > >> > 71100000  
> > >> It would be a good test to try out with a few different clocks.  
> > >
> > > 50 MHz works, for example.
> > >
> > > It seems that the issue exists when the actual display clock is different
> > > from the dsi clock. And this can happen for the reason I explained
> > > before (the DSI clock is computed starting from this 25MHz reference
> > > clock).  
> > 
> 
> If there is no way to set a correct clock, I agree with Luca a quirk should
> be the best solution.
> 
> For instance, in the dts:
>   ti,pll_may_unlock_quirk;

That's not a solution, as it would break DT backward compatibility.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]

On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote:
> 
> 
> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
> > Hi Luca, Francesco, others
> > 
> > On Wed, 19 Nov 2025 18:27:38 +0100
> > "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> > 
> > > Hello,
> > > 
> > > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
> > > ...
> > > > > I might be mistaken, but I don't think the PLL will work if
> > > > > unlocked...
> > > > > But maybe the case is that it unlocks and lock again right
> > > > > afterwards.  
> > > > > > > João, Francesco, on what hardware do you observe the
> > > > > > > problem? Which SoC?
> > > > > > > Which encoder, any previous bridges?  
> > > > > > 
> > > > > > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
> > > > > > verdin.dtsi
> > > > > > 
> > > > > > There is a DPI to DSI bridge in the module, tc358778, it has
> > > > > > a 25MHz
> > > > > > reference clock.
> > > > > > 
> > > > > > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
> > > > > > Display
> > > > > > 
> > > > > > From a preliminary investigation this is a HW limitation, we
> > > > > > are not
> > > > > > able to generate a "good enough" DSI clock, see
> > > > > > tc358768_calc_pll() for  
> > > 
> > > Thanks Francesco for the feedback!
> > > 
> > > I'm not sure I completely understand the issue described, but if
> > > the TI
> > > bridge requires a clock that cannot be provided by the hardware,
> > > then this
> > > actually looks like "a HW limitation" as you wrote, due to a HW
> > > integration
> > > limitation/bug/issue/whatever. In case this is confirmed, I think
> > > quirks
> > > are an appropriate tool to handle HW integration issues.
> > > 
> > > > > I haven't studied the docs or done any testing, but I would
> > > > > think that
> > > > > it doesn't matter for the PLL even if the incoming DSI clock is
> > > > > a bit
> > > > > off, as long as it's continuous and stable.
> > > > > 
> > > > > My first thought was that the DSI is using non-continuous
> > > > > clock, but at
> > > > > least the driver has code to drop the
> > > > > MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
> > > > >  
> > > > > > the actual code implementation of it, I believe that the
> > > > > > datasheet is
> > > > > > not available without NDA.
> > > > > > 
> > > > > > Maybe the ugly hack "works-without-pll" is the way to work?
> > > > > > It will
> > > > > > require a DT change, but this seems doable.  
> > > > > 
> > > > > Revert is easier than adding new hacky DT properties... At
> > > > > least until
> > > > > the problem is understood.
> > > > >  
> > > > > > Please note that this is the outcome of a short investigation
> > > > > > done
> > > > > > yesterday afternoon, so maybe I am overlooking something,
> > > > > > unfortunately
> > > > > > I do not have the bandwidth to work on it more this week.
> > > > > >  
> > > > > > > Which clock rates?  
> > > > > > 71100000  
> > > > > It would be a good test to try out with a few different
> > > > > clocks.  
> > > > 
> > > > 50 MHz works, for example.
> > > > 
> > > > It seems that the issue exists when the actual display clock is
> > > > different
> > > > from the dsi clock. And this can happen for the reason I
> > > > explained
> > > > before (the DSI clock is computed starting from this 25MHz
> > > > reference
> > > > clock).  
> > > 
> > 
> > If there is no way to set a correct clock, I agree with Luca a quirk
> > should
> > be the best solution.
> > 
> > For instance, in the dts:
> >   ti,pll_may_unlock_quirk;
> 
> I followed the discussion only loosely. But I once worked on bringing
> up the SN65DSI83 and from what I can remember is that there was a
> frequency range of the input clock where the PLL of SN65DSI83 just did
> not lock at all.
> 
> I couldn't explain what was happening since the clock I fed was within
> the limits of the documentation I had.
> 
> What I ultimately did was to just choose a clock that works. Given that
> experience I'm not sure about adding quirks on TI side.
> 
> But anyway I'm not very familiar with the topic and it's a long time
> since I worked on it. Just wanted to point out this experience I had,
> maybe it helps.

If the frequency is predictable, can we disable the error recovery if we
know we programmed the bridge in (one of) the affected range?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Luca Ceresoli]

Hello João, Francesco, Maxime, Hervé,

On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote:
> On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote:
>>
>>
>> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
>> > Hi Luca, Francesco, others
>> >
>> > On Wed, 19 Nov 2025 18:27:38 +0100
>> > "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
>> > > ...
>> > > > > I might be mistaken, but I don't think the PLL will work if
>> > > > > unlocked...
>> > > > > But maybe the case is that it unlocks and lock again right
>> > > > > afterwards.
>> > > > > > > João, Francesco, on what hardware do you observe the
>> > > > > > > problem? Which SoC?
>> > > > > > > Which encoder, any previous bridges?
>> > > > > >
>> > > > > > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
>> > > > > > verdin.dtsi
>> > > > > >
>> > > > > > There is a DPI to DSI bridge in the module, tc358778, it has
>> > > > > > a 25MHz
>> > > > > > reference clock.
>> > > > > >
>> > > > > > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
>> > > > > > Display
>> > > > > >
>> > > > > > From a preliminary investigation this is a HW limitation, we
>> > > > > > are not
>> > > > > > able to generate a "good enough" DSI clock, see
>> > > > > > tc358768_calc_pll() for
>> > >
>> > > Thanks Francesco for the feedback!
>> > >
>> > > I'm not sure I completely understand the issue described, but if
>> > > the TI
>> > > bridge requires a clock that cannot be provided by the hardware,
>> > > then this
>> > > actually looks like "a HW limitation" as you wrote, due to a HW
>> > > integration
>> > > limitation/bug/issue/whatever. In case this is confirmed, I think
>> > > quirks
>> > > are an appropriate tool to handle HW integration issues.
>> > >
>> > > > > I haven't studied the docs or done any testing, but I would
>> > > > > think that
>> > > > > it doesn't matter for the PLL even if the incoming DSI clock is
>> > > > > a bit
>> > > > > off, as long as it's continuous and stable.
>> > > > >
>> > > > > My first thought was that the DSI is using non-continuous
>> > > > > clock, but at
>> > > > > least the driver has code to drop the
>> > > > > MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
>> > > > >
>> > > > > > the actual code implementation of it, I believe that the
>> > > > > > datasheet is
>> > > > > > not available without NDA.
>> > > > > >
>> > > > > > Maybe the ugly hack "works-without-pll" is the way to work?
>> > > > > > It will
>> > > > > > require a DT change, but this seems doable.
>> > > > >
>> > > > > Revert is easier than adding new hacky DT properties... At
>> > > > > least until
>> > > > > the problem is understood.
>> > > > >
>> > > > > > Please note that this is the outcome of a short investigation
>> > > > > > done
>> > > > > > yesterday afternoon, so maybe I am overlooking something,
>> > > > > > unfortunately
>> > > > > > I do not have the bandwidth to work on it more this week.
>> > > > > >
>> > > > > > > Which clock rates?
>> > > > > > 71100000
>> > > > > It would be a good test to try out with a few different
>> > > > > clocks.
>> > > >
>> > > > 50 MHz works, for example.
>> > > >
>> > > > It seems that the issue exists when the actual display clock is
>> > > > different
>> > > > from the dsi clock. And this can happen for the reason I
>> > > > explained
>> > > > before (the DSI clock is computed starting from this 25MHz
>> > > > reference
>> > > > clock).
>> > >
>> >
>> > If there is no way to set a correct clock, I agree with Luca a quirk
>> > should
>> > be the best solution.
>> >
>> > For instance, in the dts:
>> >   ti,pll_may_unlock_quirk;
>>
>> I followed the discussion only loosely. But I once worked on bringing
>> up the SN65DSI83 and from what I can remember is that there was a
>> frequency range of the input clock where the PLL of SN65DSI83 just did
>> not lock at all.
>>
>> I couldn't explain what was happening since the clock I fed was within
>> the limits of the documentation I had.
>>
>> What I ultimately did was to just choose a clock that works. Given that
>> experience I'm not sure about adding quirks on TI side.
>>
>> But anyway I'm not very familiar with the topic and it's a long time
>> since I worked on it. Just wanted to point out this experience I had,
>> maybe it helps.
>
> If the frequency is predictable, can we disable the error recovery if we
> know we programmed the bridge in (one of) the affected range?

This looks like the best solution in principle. However I'm not sure the
ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is
only known to the DSI host and there is an API for the DSI device to obtain
it from the DSI host.

I'd be happy to be proven wrong though, and that the above idea can work.

In case it doesn't we should reconsider the quirk. But as Maxime pointed
out in another reply the quirk property in DT is not doable for backwards
compatibility. Other options that have come to mind to use the quirk:

 * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk
   if (of_machine_is_compatible("toradex,..."))
 * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk
   if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to
   say "this hardware is able to provide a correct clock"

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Luca Ceresoli]

Hello,

sorry, a typo below.

On Mon Nov 24, 2025 at 1:12 PM CET, Luca Ceresoli wrote:
> Hello João, Francesco, Maxime, Hervé,
>
> On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote:
>> On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote:
>>>
>>>
>>> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
>>> > Hi Luca, Francesco, others
>>> >
>>> > On Wed, 19 Nov 2025 18:27:38 +0100
>>> > "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
>>> >
>>> > > Hello,
>>> > >
>>> > > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
>>> > > ...
>>> > > > > I might be mistaken, but I don't think the PLL will work if
>>> > > > > unlocked...
>>> > > > > But maybe the case is that it unlocks and lock again right
>>> > > > > afterwards.
>>> > > > > > > João, Francesco, on what hardware do you observe the
>>> > > > > > > problem? Which SoC?
>>> > > > > > > Which encoder, any previous bridges?
>>> > > > > >
>>> > > > > > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
>>> > > > > > verdin.dtsi
>>> > > > > >
>>> > > > > > There is a DPI to DSI bridge in the module, tc358778, it has
>>> > > > > > a 25MHz
>>> > > > > > reference clock.
>>> > > > > >
>>> > > > > > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
>>> > > > > > Display
>>> > > > > >
>>> > > > > > From a preliminary investigation this is a HW limitation, we
>>> > > > > > are not
>>> > > > > > able to generate a "good enough" DSI clock, see
>>> > > > > > tc358768_calc_pll() for
>>> > >
>>> > > Thanks Francesco for the feedback!
>>> > >
>>> > > I'm not sure I completely understand the issue described, but if
>>> > > the TI
>>> > > bridge requires a clock that cannot be provided by the hardware,
>>> > > then this
>>> > > actually looks like "a HW limitation" as you wrote, due to a HW
>>> > > integration
>>> > > limitation/bug/issue/whatever. In case this is confirmed, I think
>>> > > quirks
>>> > > are an appropriate tool to handle HW integration issues.
>>> > >
>>> > > > > I haven't studied the docs or done any testing, but I would
>>> > > > > think that
>>> > > > > it doesn't matter for the PLL even if the incoming DSI clock is
>>> > > > > a bit
>>> > > > > off, as long as it's continuous and stable.
>>> > > > >
>>> > > > > My first thought was that the DSI is using non-continuous
>>> > > > > clock, but at
>>> > > > > least the driver has code to drop the
>>> > > > > MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
>>> > > > >
>>> > > > > > the actual code implementation of it, I believe that the
>>> > > > > > datasheet is
>>> > > > > > not available without NDA.
>>> > > > > >
>>> > > > > > Maybe the ugly hack "works-without-pll" is the way to work?
>>> > > > > > It will
>>> > > > > > require a DT change, but this seems doable.
>>> > > > >
>>> > > > > Revert is easier than adding new hacky DT properties... At
>>> > > > > least until
>>> > > > > the problem is understood.
>>> > > > >
>>> > > > > > Please note that this is the outcome of a short investigation
>>> > > > > > done
>>> > > > > > yesterday afternoon, so maybe I am overlooking something,
>>> > > > > > unfortunately
>>> > > > > > I do not have the bandwidth to work on it more this week.
>>> > > > > >
>>> > > > > > > Which clock rates?
>>> > > > > > 71100000
>>> > > > > It would be a good test to try out with a few different
>>> > > > > clocks.
>>> > > >
>>> > > > 50 MHz works, for example.
>>> > > >
>>> > > > It seems that the issue exists when the actual display clock is
>>> > > > different
>>> > > > from the dsi clock. And this can happen for the reason I
>>> > > > explained
>>> > > > before (the DSI clock is computed starting from this 25MHz
>>> > > > reference
>>> > > > clock).
>>> > >
>>> >
>>> > If there is no way to set a correct clock, I agree with Luca a quirk
>>> > should
>>> > be the best solution.
>>> >
>>> > For instance, in the dts:
>>> >   ti,pll_may_unlock_quirk;
>>>
>>> I followed the discussion only loosely. But I once worked on bringing
>>> up the SN65DSI83 and from what I can remember is that there was a
>>> frequency range of the input clock where the PLL of SN65DSI83 just did
>>> not lock at all.
>>>
>>> I couldn't explain what was happening since the clock I fed was within
>>> the limits of the documentation I had.
>>>
>>> What I ultimately did was to just choose a clock that works. Given that
>>> experience I'm not sure about adding quirks on TI side.
>>>
>>> But anyway I'm not very familiar with the topic and it's a long time
>>> since I worked on it. Just wanted to point out this experience I had,
>>> maybe it helps.
>>
>> If the frequency is predictable, can we disable the error recovery if we
>> know we programmed the bridge in (one of) the affected range?
>
> This looks like the best solution in principle. However I'm not sure the
> ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is
> only known to the DSI host and there is an API for the DSI device to obtain
                                 ^^^^^^^^
				 there isn't

> it from the DSI host.
>
> I'd be happy to be proven wrong though, and that the above idea can work.
>
> In case it doesn't we should reconsider the quirk. But as Maxime pointed
> out in another reply the quirk property in DT is not doable for backwards
> compatibility. Other options that have come to mind to use the quirk:
>
>  * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk
>    if (of_machine_is_compatible("toradex,..."))
>  * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk
>    if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to
>    say "this hardware is able to provide a correct clock"
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com




--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 6410 bytes --]

On Mon, Nov 24, 2025 at 01:12:55PM +0100, Luca Ceresoli wrote:
> Hello João, Francesco, Maxime, Hervé,
> 
> On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote:
> > On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote:
> >>
> >>
> >> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
> >> > Hi Luca, Francesco, others
> >> >
> >> > On Wed, 19 Nov 2025 18:27:38 +0100
> >> > "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
> >> > > ...
> >> > > > > I might be mistaken, but I don't think the PLL will work if
> >> > > > > unlocked...
> >> > > > > But maybe the case is that it unlocks and lock again right
> >> > > > > afterwards.
> >> > > > > > > João, Francesco, on what hardware do you observe the
> >> > > > > > > problem? Which SoC?
> >> > > > > > > Which encoder, any previous bridges?
> >> > > > > >
> >> > > > > > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
> >> > > > > > verdin.dtsi
> >> > > > > >
> >> > > > > > There is a DPI to DSI bridge in the module, tc358778, it has
> >> > > > > > a 25MHz
> >> > > > > > reference clock.
> >> > > > > >
> >> > > > > > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
> >> > > > > > Display
> >> > > > > >
> >> > > > > > From a preliminary investigation this is a HW limitation, we
> >> > > > > > are not
> >> > > > > > able to generate a "good enough" DSI clock, see
> >> > > > > > tc358768_calc_pll() for
> >> > >
> >> > > Thanks Francesco for the feedback!
> >> > >
> >> > > I'm not sure I completely understand the issue described, but if
> >> > > the TI
> >> > > bridge requires a clock that cannot be provided by the hardware,
> >> > > then this
> >> > > actually looks like "a HW limitation" as you wrote, due to a HW
> >> > > integration
> >> > > limitation/bug/issue/whatever. In case this is confirmed, I think
> >> > > quirks
> >> > > are an appropriate tool to handle HW integration issues.
> >> > >
> >> > > > > I haven't studied the docs or done any testing, but I would
> >> > > > > think that
> >> > > > > it doesn't matter for the PLL even if the incoming DSI clock is
> >> > > > > a bit
> >> > > > > off, as long as it's continuous and stable.
> >> > > > >
> >> > > > > My first thought was that the DSI is using non-continuous
> >> > > > > clock, but at
> >> > > > > least the driver has code to drop the
> >> > > > > MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
> >> > > > >
> >> > > > > > the actual code implementation of it, I believe that the
> >> > > > > > datasheet is
> >> > > > > > not available without NDA.
> >> > > > > >
> >> > > > > > Maybe the ugly hack "works-without-pll" is the way to work?
> >> > > > > > It will
> >> > > > > > require a DT change, but this seems doable.
> >> > > > >
> >> > > > > Revert is easier than adding new hacky DT properties... At
> >> > > > > least until
> >> > > > > the problem is understood.
> >> > > > >
> >> > > > > > Please note that this is the outcome of a short investigation
> >> > > > > > done
> >> > > > > > yesterday afternoon, so maybe I am overlooking something,
> >> > > > > > unfortunately
> >> > > > > > I do not have the bandwidth to work on it more this week.
> >> > > > > >
> >> > > > > > > Which clock rates?
> >> > > > > > 71100000
> >> > > > > It would be a good test to try out with a few different
> >> > > > > clocks.
> >> > > >
> >> > > > 50 MHz works, for example.
> >> > > >
> >> > > > It seems that the issue exists when the actual display clock is
> >> > > > different
> >> > > > from the dsi clock. And this can happen for the reason I
> >> > > > explained
> >> > > > before (the DSI clock is computed starting from this 25MHz
> >> > > > reference
> >> > > > clock).
> >> > >
> >> >
> >> > If there is no way to set a correct clock, I agree with Luca a quirk
> >> > should
> >> > be the best solution.
> >> >
> >> > For instance, in the dts:
> >> >   ti,pll_may_unlock_quirk;
> >>
> >> I followed the discussion only loosely. But I once worked on bringing
> >> up the SN65DSI83 and from what I can remember is that there was a
> >> frequency range of the input clock where the PLL of SN65DSI83 just did
> >> not lock at all.
> >>
> >> I couldn't explain what was happening since the clock I fed was within
> >> the limits of the documentation I had.
> >>
> >> What I ultimately did was to just choose a clock that works. Given that
> >> experience I'm not sure about adding quirks on TI side.
> >>
> >> But anyway I'm not very familiar with the topic and it's a long time
> >> since I worked on it. Just wanted to point out this experience I had,
> >> maybe it helps.
> >
> > If the frequency is predictable, can we disable the error recovery if we
> > know we programmed the bridge in (one of) the affected range?
> 
> This looks like the best solution in principle. However I'm not sure the
> ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is
> only known to the DSI host and there is an API for the DSI device to obtain
> it from the DSI host.
> 
> I'd be happy to be proven wrong though, and that the above idea can work.
> 
> In case it doesn't we should reconsider the quirk. But as Maxime pointed
> out in another reply the quirk property in DT is not doable for backwards
> compatibility. Other options that have come to mind to use the quirk:
> 
>  * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk
>    if (of_machine_is_compatible("toradex,..."))

There's nothing in that machine that is very specific if it's driven by
the relationship between the clock the DSI controller can match and the
panel connected to it. So it won't just affect a single board.

>  * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk
>    if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to
>    say "this hardware is able to provide a correct clock"

And similarly, if this depends on the resolution, and the rate the DSI
driver is able to provide, it's not something the DT can express
properly. Some panels can support multiple resolutions for example. What
happens if one can lock and the other cannot?

Either way, it's not something that will be solved overnight. Please
send a revert.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Emanuele Ghidoli]

On 24/11/2025 15:12, Luca Ceresoli wrote:
> Hello,
> 
> sorry, a typo below.
> 
> On Mon Nov 24, 2025 at 1:12 PM CET, Luca Ceresoli wrote:
>> Hello João, Francesco, Maxime, Hervé,
>>
>> On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote:
>>> On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote:
>>>>
>>>>
>>>> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
>>>>> Hi Luca, Francesco, others
>>>>>
>>>>> On Wed, 19 Nov 2025 18:27:38 +0100
>>>>> "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
>>>>>> ...
>>>>>>>> I might be mistaken, but I don't think the PLL will work if
>>>>>>>> unlocked...
>>>>>>>> But maybe the case is that it unlocks and lock again right
>>>>>>>> afterwards.
>>>>>>>>>> João, Francesco, on what hardware do you observe the
>>>>>>>>>> problem? Which SoC?
>>>>>>>>>> Which encoder, any previous bridges?
>>>>>>>>>
>>>>>>>>> Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
>>>>>>>>> verdin.dtsi
>>>>>>>>>
>>>>>>>>> There is a DPI to DSI bridge in the module, tc358778, it has
>>>>>>>>> a 25MHz
>>>>>>>>> reference clock.
>>>>>>>>>
>>>>>>>>> TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
>>>>>>>>> Display
>>>>>>>>>
>>>>>>>>> From a preliminary investigation this is a HW limitation, we
>>>>>>>>> are not
>>>>>>>>> able to generate a "good enough" DSI clock, see
>>>>>>>>> tc358768_calc_pll() for
>>>>>>
>>>>>> Thanks Francesco for the feedback!
>>>>>>
>>>>>> I'm not sure I completely understand the issue described, but if
>>>>>> the TI
>>>>>> bridge requires a clock that cannot be provided by the hardware,
>>>>>> then this
>>>>>> actually looks like "a HW limitation" as you wrote, due to a HW
>>>>>> integration
>>>>>> limitation/bug/issue/whatever. In case this is confirmed, I think
>>>>>> quirks
>>>>>> are an appropriate tool to handle HW integration issues.
>>>>>>
>>>>>>>> I haven't studied the docs or done any testing, but I would
>>>>>>>> think that
>>>>>>>> it doesn't matter for the PLL even if the incoming DSI clock is
>>>>>>>> a bit
>>>>>>>> off, as long as it's continuous and stable.
>>>>>>>>
>>>>>>>> My first thought was that the DSI is using non-continuous
>>>>>>>> clock, but at
>>>>>>>> least the driver has code to drop the
>>>>>>>> MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
>>>>>>>>
>>>>>>>>> the actual code implementation of it, I believe that the
>>>>>>>>> datasheet is
>>>>>>>>> not available without NDA.
>>>>>>>>>
>>>>>>>>> Maybe the ugly hack "works-without-pll" is the way to work?
>>>>>>>>> It will
>>>>>>>>> require a DT change, but this seems doable.
>>>>>>>>
>>>>>>>> Revert is easier than adding new hacky DT properties... At
>>>>>>>> least until
>>>>>>>> the problem is understood.
>>>>>>>>
>>>>>>>>> Please note that this is the outcome of a short investigation
>>>>>>>>> done
>>>>>>>>> yesterday afternoon, so maybe I am overlooking something,
>>>>>>>>> unfortunately
>>>>>>>>> I do not have the bandwidth to work on it more this week.
>>>>>>>>>
>>>>>>>>>> Which clock rates?
>>>>>>>>> 71100000
>>>>>>>> It would be a good test to try out with a few different
>>>>>>>> clocks.
>>>>>>>
>>>>>>> 50 MHz works, for example.
>>>>>>>
>>>>>>> It seems that the issue exists when the actual display clock is
>>>>>>> different
>>>>>>> from the dsi clock. And this can happen for the reason I
>>>>>>> explained
>>>>>>> before (the DSI clock is computed starting from this 25MHz
>>>>>>> reference
>>>>>>> clock).
>>>>>>
>>>>>
>>>>> If there is no way to set a correct clock, I agree with Luca a quirk
>>>>> should
>>>>> be the best solution.
>>>>>
>>>>> For instance, in the dts:
>>>>>   ti,pll_may_unlock_quirk;
>>>>
>>>> I followed the discussion only loosely. But I once worked on bringing
>>>> up the SN65DSI83 and from what I can remember is that there was a
>>>> frequency range of the input clock where the PLL of SN65DSI83 just did
>>>> not lock at all.
>>>>
>>>> I couldn't explain what was happening since the clock I fed was within
>>>> the limits of the documentation I had.
>>>>
>>>> What I ultimately did was to just choose a clock that works. Given that
>>>> experience I'm not sure about adding quirks on TI side.
>>>>
>>>> But anyway I'm not very familiar with the topic and it's a long time
>>>> since I worked on it. Just wanted to point out this experience I had,
>>>> maybe it helps.
>>>
>>> If the frequency is predictable, can we disable the error recovery if we
>>> know we programmed the bridge in (one of) the affected range?
>>
>> This looks like the best solution in principle. However I'm not sure the
>> ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is
>> only known to the DSI host and there is an API for the DSI device to obtain
>                                  ^^^^^^^^
> 				 there isn't
> 
>> it from the DSI host.
>>
>> I'd be happy to be proven wrong though, and that the above idea can work.
>>
>> In case it doesn't we should reconsider the quirk. But as Maxime pointed
>> out in another reply the quirk property in DT is not doable for backwards
>> compatibility. Other options that have come to mind to use the quirk:
>>
>>  * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk
>>    if (of_machine_is_compatible("toradex,..."))
>>  * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk
>>    if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to
>>    say "this hardware is able to provide a correct clock"
>>
>> Luca
>>
>> --
>> Luca Ceresoli, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
> 
> 
> 
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Hi,

I'm debugging the RGB -> tc358778 -> sn65dsi84 pipeline

Some observations:
- If I avoid resetting the pipeline and only clear the status bit, the PLL
unlock flag immediately comes back. Despite this, the display keeps working
fine and the sn65dsi84 appears functional even when the PLL is reported as
unlocked.
- There’s no clear frequency boundary:
working: 50000000, 68750000, 72750000, 75000000
not working: 69750000, 71100000, 72500000
- The tc358778 is configured for continuous-clock DSI.
- I cannot measure the DSI clock directly, but the parallel RGB clock is stable.

So far I haven’t found a rule that clearly explain why certain frequency are
without problems while some other generate this issue.
I'm struggling around the input clock frequency and the one generated by
tc358778 using its PLL, and trying to find out how it is possible that the
side effect is a not locked PLL on the sn65dsi84.

I could run additional tests or gather more data if useful.

Thanks,
Emanuele

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

[Luca Ceresoli]

On Mon Nov 24, 2025 at 4:55 PM CET, Maxime Ripard wrote:
> On Mon, Nov 24, 2025 at 01:12:55PM +0100, Luca Ceresoli wrote:
>> Hello João, Francesco, Maxime, Hervé,
>>
>> On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote:
>> > On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote:
>> >>
>> >>
>> >> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote:
>> >> > Hi Luca, Francesco, others
>> >> >
>> >> > On Wed, 19 Nov 2025 18:27:38 +0100
>> >> > "Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
>> >> >
>> >> > > Hello,
>> >> > >
>> >> > > On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote:
>> >> > > ...
>> >> > > > > I might be mistaken, but I don't think the PLL will work if
>> >> > > > > unlocked...
>> >> > > > > But maybe the case is that it unlocks and lock again right
>> >> > > > > afterwards.
>> >> > > > > > > João, Francesco, on what hardware do you observe the
>> >> > > > > > > problem? Which SoC?
>> >> > > > > > > Which encoder, any previous bridges?
>> >> > > > > >
>> >> > > > > > Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62-
>> >> > > > > > verdin.dtsi
>> >> > > > > >
>> >> > > > > > There is a DPI to DSI bridge in the module, tc358778, it has
>> >> > > > > > a 25MHz
>> >> > > > > > reference clock.
>> >> > > > > >
>> >> > > > > > TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 ->
>> >> > > > > > Display
>> >> > > > > >
>> >> > > > > > From a preliminary investigation this is a HW limitation, we
>> >> > > > > > are not
>> >> > > > > > able to generate a "good enough" DSI clock, see
>> >> > > > > > tc358768_calc_pll() for
>> >> > >
>> >> > > Thanks Francesco for the feedback!
>> >> > >
>> >> > > I'm not sure I completely understand the issue described, but if
>> >> > > the TI
>> >> > > bridge requires a clock that cannot be provided by the hardware,
>> >> > > then this
>> >> > > actually looks like "a HW limitation" as you wrote, due to a HW
>> >> > > integration
>> >> > > limitation/bug/issue/whatever. In case this is confirmed, I think
>> >> > > quirks
>> >> > > are an appropriate tool to handle HW integration issues.
>> >> > >
>> >> > > > > I haven't studied the docs or done any testing, but I would
>> >> > > > > think that
>> >> > > > > it doesn't matter for the PLL even if the incoming DSI clock is
>> >> > > > > a bit
>> >> > > > > off, as long as it's continuous and stable.
>> >> > > > >
>> >> > > > > My first thought was that the DSI is using non-continuous
>> >> > > > > clock, but at
>> >> > > > > least the driver has code to drop the
>> >> > > > > MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
>> >> > > > >
>> >> > > > > > the actual code implementation of it, I believe that the
>> >> > > > > > datasheet is
>> >> > > > > > not available without NDA.
>> >> > > > > >
>> >> > > > > > Maybe the ugly hack "works-without-pll" is the way to work?
>> >> > > > > > It will
>> >> > > > > > require a DT change, but this seems doable.
>> >> > > > >
>> >> > > > > Revert is easier than adding new hacky DT properties... At
>> >> > > > > least until
>> >> > > > > the problem is understood.
>> >> > > > >
>> >> > > > > > Please note that this is the outcome of a short investigation
>> >> > > > > > done
>> >> > > > > > yesterday afternoon, so maybe I am overlooking something,
>> >> > > > > > unfortunately
>> >> > > > > > I do not have the bandwidth to work on it more this week.
>> >> > > > > >
>> >> > > > > > > Which clock rates?
>> >> > > > > > 71100000
>> >> > > > > It would be a good test to try out with a few different
>> >> > > > > clocks.
>> >> > > >
>> >> > > > 50 MHz works, for example.
>> >> > > >
>> >> > > > It seems that the issue exists when the actual display clock is
>> >> > > > different
>> >> > > > from the dsi clock. And this can happen for the reason I
>> >> > > > explained
>> >> > > > before (the DSI clock is computed starting from this 25MHz
>> >> > > > reference
>> >> > > > clock).
>> >> > >
>> >> >
>> >> > If there is no way to set a correct clock, I agree with Luca a quirk
>> >> > should
>> >> > be the best solution.
>> >> >
>> >> > For instance, in the dts:
>> >> >   ti,pll_may_unlock_quirk;
>> >>
>> >> I followed the discussion only loosely. But I once worked on bringing
>> >> up the SN65DSI83 and from what I can remember is that there was a
>> >> frequency range of the input clock where the PLL of SN65DSI83 just did
>> >> not lock at all.
>> >>
>> >> I couldn't explain what was happening since the clock I fed was within
>> >> the limits of the documentation I had.
>> >>
>> >> What I ultimately did was to just choose a clock that works. Given that
>> >> experience I'm not sure about adding quirks on TI side.
>> >>
>> >> But anyway I'm not very familiar with the topic and it's a long time
>> >> since I worked on it. Just wanted to point out this experience I had,
>> >> maybe it helps.
>> >
>> > If the frequency is predictable, can we disable the error recovery if we
>> > know we programmed the bridge in (one of) the affected range?
>>
>> This looks like the best solution in principle. However I'm not sure the
>> ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is
>> only known to the DSI host and there is an API for the DSI device to obtain
>> it from the DSI host.
>>
>> I'd be happy to be proven wrong though, and that the above idea can work.
>>
>> In case it doesn't we should reconsider the quirk. But as Maxime pointed
>> out in another reply the quirk property in DT is not doable for backwards
>> compatibility. Other options that have come to mind to use the quirk:
>>
>>  * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk
>>    if (of_machine_is_compatible("toradex,..."))
>
> There's nothing in that machine that is very specific if it's driven by
> the relationship between the clock the DSI controller can match and the
> panel connected to it. So it won't just affect a single board.
>
>>  * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk
>>    if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to
>>    say "this hardware is able to provide a correct clock"
>
> And similarly, if this depends on the resolution, and the rate the DSI
> driver is able to provide, it's not something the DT can express
> properly. Some panels can support multiple resolutions for example. What
> happens if one can lock and the other cannot?
>
> Either way, it's not something that will be solved overnight. Please
> send a revert.

I think the best thing (and what I was kind of expecting) is that
Francesco/Emanuele/João send a revert patch adding to the commit message
all the relevant info they are collecting. They definitely understand the
issue much better than others right now.

If that's not OK, I can do it.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com