Message-Id: <DEH33WWQKCOS.1MPPXB090YH3H@bootlin.com>
Date: Mon, 24 Nov 2025 18:00:57 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Maxime Ripard" <mripard@...nel.org>
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>, "Emanuele Ghidoli"
 <ghidoliemanuele@...il.com>
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to
 blink On/Off

On Mon Nov 24, 2025 at 4:55 PM CET, Maxime Ripard wrote:
> 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.

I think the best thing (and what I was kind of expecting) is that
Francesco/Emanuele/João send a revert patch adding to the commit message
all the relevant info they are collecting. They definitely understand the
issue much better than others right now.

If that's not OK, I can do it.

Luca

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

Powered by blists - more mailing lists