Message-ID: <jakr7ccumjo5jqzqlnbxur34itbspip25iicx5oq2bm3hoj23j@w3qllbfu4xnm>
Date: Mon, 24 Nov 2025 16:55:34 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: Philippe Schenker <philippe.schenker@...ulsing.ch>, 
	Herve Codina <herve.codina@...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 Mon, Nov 24, 2025 at 01:12:55PM +0100, Luca Ceresoli wrote:
> Hello João, Francesco, Maxime, Hervé,
> 
> On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote:
> > 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?
> 
> This looks like the best solution in principle. However I'm not sure the
> ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is
> only known to the DSI host and there is an API for the DSI device to obtain
> it from the DSI host.
> 
> I'd be happy to be proven wrong though, and that the above idea can work.
> 
> In case it doesn't we should reconsider the quirk. But as Maxime pointed
> out in another reply the quirk property in DT is not doable for backwards
> compatibility. Other options that have come to mind to use the quirk:
> 
>  * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk
>    if (of_machine_is_compatible("toradex,..."))

There's nothing in that machine that is very specific if it's driven by
the relationship between the clock the DSI controller can match and the
panel connected to it. So it won't just affect a single board.

>  * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk
>    if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to
>    say "this hardware is able to provide a correct clock"

And similarly, if this depends on the resolution, and the rate the DSI
driver is able to provide, it's not something the DT can express
properly. Some panels can support multiple resolutions for example. What
happens if one can lock and the other cannot?

Either way, it's not something that will be solved overnight. Please
send a revert.

Maxime

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

Powered by blists - more mailing lists