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

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello,

sorry, a typo below.

On Mon Nov 24, 2025 at 1:12 PM CET, 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@bootlin.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
                                 ^^^^^^^^
				 there isn't

> 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,..."))
>  * 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"
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com




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