[PATCH 2/6] drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock

[Marek Vasut]

On 6/25/24 8:11 AM, Alexander Stein wrote:
> Hi Marek,
> 
> Am Dienstag, 25. Juni 2024, 02:33:53 CEST schrieb Marek Vasut:
>> On 6/24/24 11:26 AM, Alexander Stein wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> Am Freitag, 21. Juni 2024, 16:54:51 CEST schrieb Marek Vasut:
>>>> On 6/21/24 12:32 PM, Alexander Stein wrote:
>>>>
>>>> Hi,
>>>>
>>>> skipping the parts where I would simply write "OK" ...
>>>>
>>>>>>>> As FVUEN is cleared at the next VSYNC event I suspect the DSI timings
>>>>>>>> are (slightly) off, but unfortunately I don't have equipment to check
>>>>>>>> DSI signal quality/timings.
>>>>>>>
>>>>>>> As long as the LCDIFv3 pixel clock are equal or slightly slower than
>>>>>>> what the TC9595 PixelPLL generates, AND, DSIM serializer has enough
>>>>>>> bandwidth on the DSI bus (i.e. set the bus to 1 GHz, the TC9595 DSI RX
>>>>>>> cannot go any faster), you should have no issues on that end.
>>>>>
>>>>> I'm using samsung,burst-clock-frequency = <1000000000> so this should be
>>>>> okay. That is 1080p resolution.
>>>>
>>>> Yes, correct.
>>>>
>>>>>>> When in doubt, try and use i2ctransfer to read out register 0x300
>>>>>>> repeatedly, that's DSI RX error counter register. See if the DSI error
>>>>>>> count increments.
>>>>>
>>>>> If the bridge is not working the registers look like this:
>>>>> 300: c0800000
>>>>> 464: 00000001
>>>>>
>>>>> they are not changing and stay like that.
>>>>>
>>>>> If the bridge is actually running they are like
>>>>> 300: c08000d3
>>>>> 464: 00000000
>>>>>
>>>>> and are also not changing.
>>>>
>>>> Uh ... that looks like the whole chip clock tree somehow locked up .
>>>>
>>>> Thinking about this, I once did force the DSIM into 24 MHz mode (there
>>>> is PLL bypass setting, where the DSIM uses 24 MHz serializer clock
>>>> directly for the DSI HS clock) or something close, it was enough to
>>>> drive a low resolution panel. But the upside was, with a 200 MHz 5Gsps
>>>> scope set to AC-coupling and 10x probe, I could discern the traffic on
>>>> DSI data lane and decode it by hand. The nice thing is, you could
>>>> trigger on 1V2 LP mode, so you know where the packet starts. The
>>>> downside is, if you have multiple data lanes, the packet is spread
>>>> across them.
>>>>
>>>> You could also tweak tc_edp_atomic_check()/tc_edp_mode_valid() and force
>>>> only low(er) resolution modes of your DP panel right from the start, so
>>>> you wouldn't need that much DSI bandwidth. Maybe you could reach some
>>>> mode where your equipment is enough to analyze the traffic by hand ?
>>>
>>> I think I got it running now. Apparently there were different, independent
>>> problems which you addressed by your series.
>>
>> Oh, glad I could help.
>>
>>> Unfortunately the patch
>>> 'tc358767: Disable MIPI_DSI_CLOCK_NON_CONTINUOUS' introduced a new problem
>>> (at least for me). For the record I'm running the following patch stack based
>>> on next-20240621:
>>
>> Thanks for tracking it down. I can drop that one
>> MIPI_DSI_CLOCK_NON_CONTINUOUS patch from the series and do a V4. Would
>> that work for you ? At least there would be some improvement to the
>> driver and I can analyze the MIPI_DSI_CLOCK_NON_CONTINUOUS issue in
>> detail separately.
> 
> Sure, thanks to your patches this bridge does its job now.
> Sure, now that I have a reference system I can easily try a V4 without
> the MIPI_DSI_CLOCK_NON_CONTINUOUS patch.

V4 is now out, thanks !