Message-ID: <b71e941c-fc8a-4ac1-9407-0fe7df73b412@gmail.com>
Date: Mon, 24 Nov 2025 17:44:18 +0100
From: Emanuele Ghidoli <ghidoliemanuele@...il.com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Maxime Ripard <mripard@...nel.org>
Cc: 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>,
 Philippe Schenker <philippe.schenker@...ulsing.ch>
Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink
 On/Off



On 24/11/2025 15:12, Luca Ceresoli wrote:
> 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@...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
>                                  ^^^^^^^^
> 				 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

Hi,

I'm debugging the RGB -> tc358778 -> sn65dsi84 pipeline

Some observations:
- If I avoid resetting the pipeline and only clear the status bit, the PLL
unlock flag immediately comes back. Despite this, the display keeps working
fine and the sn65dsi84 appears functional even when the PLL is reported as
unlocked.
- There’s no clear frequency boundary:
working: 50000000, 68750000, 72750000, 75000000
not working: 69750000, 71100000, 72500000
- The tc358778 is configured for continuous-clock DSI.
- I cannot measure the DSI clock directly, but the parallel RGB clock is stable.

So far I haven’t found a rule that clearly explain why certain frequency are
without problems while some other generate this issue.
I'm struggling around the input clock frequency and the one generated by
tc358778 using its PLL, and trying to find out how it is possible that the
side effect is a not locked PLL on the sn65dsi84.

I could run additional tests or gather more data if useful.

Thanks,
Emanuele

Powered by blists - more mailing lists