Message-ID: <4e25291266d46777e84f22295b8f1094d8f682cc.camel@impulsing.ch>
Date: Thu, 20 Nov 2025 09:50:27 +0000
From: Philippe Schenker <philippe.schenker@...ulsing.ch>
To: Herve Codina <herve.codina@...tlin.com>, Luca Ceresoli
	<luca.ceresoli@...tlin.com>, Francesco Dolcini <francesco@...cini.it>
CC: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Maxime Ripard
	<mripard@...nel.org>, João Paulo Gonçalves
	<jpaulo.silvagoncalves@...il.com>, Andrzej Hajda <andrzej.hajda@...el.com>,
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman
	<jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann
	<tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter
	<simona@...ll.ch>, João Paulo Gonçalves
	<joao.goncalves@...adex.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "regressions@...ts.linux.dev"
	<regressions@...ts.linux.dev>, "thomas.petazzoni@...tlin.com"
	<thomas.petazzoni@...tlin.com>
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink
 On/Off



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@...tlin.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é

Download attachment "signature.asc" of type "application/pgp-signature" (704 bytes)

Powered by blists - more mailing lists