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 ?
Are you running the DSIM host from 24MHz refclock?
Yes, I did not modify imx8mp.dtsi mipi_dsi node
samsung,pll-clock-frequency = <24000000>; in any way , so that's 24 MHz
base.
How shall we proceed with this series ?
Would you mind rebasing and fix patch 2/6 regarding the adjusted mode?
I wouldn't ... and I totally forgot about that, even if I have a V2
patch in my tree already. I'll send it out, thanks for the reminder.
BTW: Patch 3/6 (dropping line_pixel_subtract) is actually necessary for even
running test mode (tc358767.test=1), so this fixes an actual problem as well.
:)
