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. Best regards, Alexander > > * 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. > > Thank you for testing ! > -- 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/
