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
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.
Okay, you clearly know more than me. ;) All I know is that the pixel clock is supposed to match the value in the EDID descriptor, and that we had problems with jitter on it (although that might have just been HDMI). But I'm not sure how exactly it is used... if you say the eDP clock is constant, maybe it's just being used internally on the SoC (in the connection between Video Output Processor and the eDP block)?
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 think I found it now. We're passing CALCULATED_M to that function, so it's using the second path (which only initializes N to 0x8000). It clears the FIX_M_VID bit which I think means that M is being calculated automatically by the controller.
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.
Oh, okay, yes, I guess that could help. Although it sounds(?) like at that point you're essentially ignoring the EDID and just trying to make up your own video mode, so it seems more like a shot in the dark.
-
Julius Werner -
Nico Huber