<div dir="ltr">I have access to the schematics for Speedy... I'm not allowed to share them, but I'm happy to look up something specific for you if it helps.<div><br></div><div>Nico is right, only one of the four DP lanes coming out of the SoC is routed to the connector. If your panel requires more than that, you're probably SOL. Although I'm not even sure where they would go on that connector... there's only 20 pins, and they all seem to be used already. (I'm not really sure how standardized those connectors are, tbh... if you buy a panel with a different pinout, obviously nothing will work and it might even damage the panel and/or the mainboard.)</div><div><br></div><div>I also remember that RK3288 PLLs often had some issues with jitter (at least they had for HDMI, not sure if it applies to DP). The code we implemented (clock.c:pll_para_config) does whatever it can to meet the pixel clock as exactly as possible, but maybe that wasn't actually the best way to do it. In your case you end up with a very large input divisor (<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">NR = 59), so you're essentially dividing the 24MHz oscillator down to 407KHz and then multiplying it back up (thus amplifying noise). Maybe try hacking that function to hardcode the result to NR = 1, NF = 23, NO = 4 (leading to VCO = 552000KHz, output = 138000KHz) or NR = 4, NF = 91, NO = 4 (leading to VCO = 546000KHz, output = 136500KHz) and see if that helps. (In fact, that latter configuration is closer to the target frequency of 136620KHz than the one you get... what you're seeing is sort of a freak accident resulting from a compounding of rounding errors during the calculation. You're welcome to try to fix the code if you want, but it's kinda difficult to get all the different requirements right at once... for example, you'd have less errors if it were calculating in Hz, but we went with KHz since we were afraid it could overflow in some situations.)</span></div></div>