2022-11-25.log

- S0rin (QUIT: Ping timeout: 260 seconds) (~S0rin@user/s0rin)05:01
+ S0rin (~S0rin@user/s0rin)05:03
Claudeminute, if you quickly want to mess around with PLLD (dsi) , I can assist you :) just needs /dev/mem and sone shell scripts I wrote 08:14
ClaudeIf that works out, you can probably stuff that into a dtoverlay too08:14
ClaudeIt's a bit odd that the dsi bridge needs exactly 3*pixclock. 08:15
- S0rin (QUIT: Ping timeout: 264 seconds) (~S0rin@user/s0rin)09:39
+ S0rin (~S0rin@user/s0rin)09:41
minuteClaude: thanks! i was thinking to ask you for some help today :D10:10
minuteClaude: but i'll be only be back at the device in the afternoon 10:11
minuteClaude: the sn65dsi86 doesn't care much about the pixelclock i think, but if i understand correctly there are only a limited number of valid dsi refclks. the display wants 162 mhz pixclk / 486 mhz refclk10:14
minutebut the pi selects 166 mhz / 498 (need to double check if this is true) which then results in failing dp training in the bridge (actually not sure if it fails dp or dsi link training, but i think dp).10:16
minutethe next step down it can do is 125 mhz. with that i can get flashing color bars with the bridge's color bar test mode. not sure why the timing is broken then. it's possible that 125 is already too low for the display.10:17
minuteIIRC actually i was able to go down to very low pixelclocks using the kintex fpga+analogix edp encoder (like 80mhz?)10:19
minutei guess the tricky part is that the sn65dsi86 needs to recover its clocks from the dsi refclk. if it can't lock to that, everything goes wrong10:22
minute> MIPI D-PHY channel A clock lane; operates up to 750 MHz. Under proper conditions, this clock can be used instead of REFCLK to feed DisplayPort PLL10:54
minuteClaude: yeah so the thing is that i didn't use a dedicated refclk for the DP portion of the bridge, so it has to be recovered from DSI A, and for that only the following clocks are allowed: 384,416,468,486 or 460.8. so i need to get the pi to use one of these frequencies for dsi.10:59
minutethis is also a bit wonky https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/vc4/vc4_dsi.c#L90211:06
minuteClaude: but if i understand correctly the driver gets the dsi clock by just multiplying the pixel clock of the mode by a fixed factor (dsi->divider)11:08
minutedsi->divider is 6 for 24bpp, 4 lanes i think11:10
minuteClaude: ideally i would need to tune PLLD down to 2916000000 hz, do you think that's possible?11:11
minutealternatively 2.808ghz or 2.7648ghz or 2.49599...ghz11:13
minuteactually i'm not sure if clk_get_parent(dsi->pll_phy_clock) is PLLD directly or something in between, but as it is 3ghz i figured it is PLLD11:27
minuteyup https://forums.raspberrypi.com/viewtopic.php?p=1668620&sid=d13f64c07ebf39b25a9871cd6590ca48#p166862011:28
minuteironic that 54mhz * 3 = 162 :(11:28
minute> Clocks are a juggling nightmare in the firmware. A couple of years ago I was trying to get a DSI->HDMI bridge chip going, and getting the clocks right for that meant all sorts of pain elsewhere in the system - I think it killed composite or something. We gave up in the end. Just not enough clocks to go round, along with other issues11:59
minutequote by "jamesh" @ rpi from the forum11:59
ClaudeMinute, currently still at work . When I get home this evening I look for the pll scripts 12:35
ClaudeAlso handy for beyond insane OC on cm4 ;) 12:35
ClaudeStupid firmware limits the pll to punny 2.5GHz 12:36
minutenice, thanks12:38
- S0rin (QUIT: Read error: Connection reset by peer) (~S0rin@user/s0rin)17:34
+ S0rin (~S0rin@user/s0rin)17:51
minuteClaude: ping (sorry to be a bother!)19:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!