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: >> >> 1. 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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot