Message-ID: <ko2ghflyddv2igj43wkwsaaoneg2jwpdxldlfsix4cllzspdbj@w4fhabuwm5wy>
Date: Fri, 21 Nov 2025 10:58:44 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Philippe Schenker <philippe.schenker@...ulsing.ch>
Cc: Herve Codina <herve.codina@...tlin.com>, 
	Luca Ceresoli <luca.ceresoli@...tlin.com>, Francesco Dolcini <francesco@...cini.it>, 
	Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, 
	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 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@...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.

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

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

Powered by blists - more mailing lists