On 06.03.2018 22:13, Julius Werner wrote:
Although even if they did have the lane exposes it looks like your
helpful advice on the coreboot function would be a bit out of my depth.
It's pretty simple... try this patch (untested) which should implement what I suggested. I think there's a decent chance this might make your other panel work as well. (Note that this is *only* for the exact panel you originally posted log output for. Also: I think this should work, but there's a slim chance wrong pixel clocks may damage a panel, no warranty, yada yada.)
diff --git a/src/soc/rockchip/rk3288/clock.c b/src/soc/rockchip/rk3288/clock .c index 74151e85cb..4474ff81aa 100644 --- a/src/soc/rockchip/rk3288/clock.c +++ b/src/soc/rockchip/rk3288/clock.c @@ -539,6 +539,11 @@ static int pll_para_config(u32 freq_hz, struct pll_div *div, u32 *ext_div) return -1; }
div->no = 4;div->nf = 91;div->nr = 4;return 0;div->no = no; best_diff_khz = vco_khz;
While this might be closer to the optimum for 60Hz, it would still try to pump data at around 136MHz. DP doesn't use a variable pixel clock on the physical layer. It's using either 1.62GHz (reduced bit-rate, RBR) or 2.7GHz (high bit-rate, HBR). Or (not supported by this code and likely not by the SoC) 5.4GHz (HBR2) or 8.1GHz (HBR3). Data is encoded with 10 bits per 8 bits of payload, so for a single lane at HBR you can only get up to 2.7GHz / 10 * 8 / 18 = 120MHz.
I'm not sure if the coreboot source is prepared for that, though. There
are some pieces in the code that confuse me (e.g. the zeros passed to rk_edp_set_video_cr_mn(), Julius, do you happen to know something about that? is there public documentation for Rockchip's display engine?).
Sorry, I gotta admit I'm not a display guy at all. We mostly just took what they gave us. The reference manuals were all shared with us under NDA... you could try asking them directly, but I doubt you'll have much luck. The document you're looking for is called "Rockchip EDP TX IP Interface". It has lots of nice explanations including about M and N, but I don't really understand them without background.
If it relates to what I know from Intel graphics, M/N gives the ratio how much of the bandwidth on the lanes is used for actual picture data.
I would, however, give the following one shot:
in soc/rockchip/common/edp.c line 615 override the lane count:
edp->link_train.lane_count = 1;
The other lanes aren't routed on the board. This isn't going to help.
To be clear, I meant to override it with 1. As far as I understand the code, this should configure both sink and source to use only a single lane.
Nico