Message-Id: <DECUJMA1JWIC.2PYDSYBID4I94@bootlin.com>
Date: Wed, 19 Nov 2025 18:27:38 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Francesco Dolcini" <francesco@...cini.it>, "Tomi Valkeinen"
 <tomi.valkeinen@...asonboard.com>
Cc: "Herve Codina" <herve.codina@...tlin.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

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).


--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists