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

[Alexander Stein]

Hi Marek,

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. 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:
* Add linux-next specific files for 20240621
* arm64: dts: imx8mp: Add TC9595 DSI-DP bridge on TQMa8MPxL/MBa8MPxL
* drm: bridge: samsung-dsim: Initialize bridge on attach
* drm/bridge: tc358767: Reset chip again on attach
* drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
* drm/bridge: tc358767: Split tc_pxl_pll_en() into parameter calculation and enablement
* drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock
* drm/bridge: tc358767: Drop line_pixel_subtract
* drm/bridge: tc358767: Set LSCLK divider for SYSCLK to 1
* Revert "drm/bridge: tc358767: Set default CLRSIPO count"

All of them are needed, reverting/dropping a single one results in a
non-functioning bridge.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/