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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vci5up5d6n724vj6bral3xt3nzq2plc4egwld5ivl3244nsi6i@lr2uoyyb6z6w>
Date: Fri, 21 Nov 2025 10:57:35 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: 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, regressions@...ts.linux.dev, 
	thomas.petazzoni@...tlin.com
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink
 On/Off

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

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

Maxime

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