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

[Philippe Schenker <philippe.schenker@impulsing.ch>]

[-- 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 --]