On 05.03.2018 12:02, Mark Wylde wrote:
Thanks Nico for taking your valuable time to answer my questions. I really appreciate it, and knowing that it should be possible makes me feel better about continuing the project.
I've ordered another display that has better matching specifications. I'll reply here to let others know if it works or not although I agree this is probably not a coreboot issue.
Well that though might have come too hasty. There is some board specific information that coreboot might miss, e.g. how many lanes are actually implemented. If the original display needed only a single DP lane, maybe they omitted the traces for the other lanes (in your log, coreboot tries to train 2 lanes). And maybe there is more that I didn't consider.
A log of the successful training with the original display might give more clues. In case you haven't tried yet, you can probably also let Linux do the DP training. And last but not least, there is a edp_debug() definition at the top of `soc/rockchip/common/edp.c`.
Nico
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.
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.)
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 (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.)
-
Julius Werner -
Nico Huber