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@xxxxxxxxxxx> 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é