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

[Luca Ceresoli]

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