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] [day] [month] [year] [list]

Message-ID: <20251119194023.6239d397@bootlin.com>
Date: Wed, 19 Nov 2025 19:40:23 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: "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>,
 <regressions@...ts.linux.dev>, <thomas.petazzoni@...tlin.com>
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to
 blink On/Off

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;

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é