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 !
