06.03.2018 09:55, Mark Wylde wrote:
I think I understand by your response that ASUS has used a 20 pin connector on the motherboard part. Therefore they haven't connected up the the ML1 lane. It also looks like with only 1 lane you can only have a resolution of 1680×1050 (18 bit color depth) [3] which would be a waste of the 15'' display. 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.
So I think we can conclude it's impossible to get a bigger monitor (or at least one with a bigger resolution) through the eDP port. I guess one could get a controller board and hook the monitor up via the HDMI mini port, but I think I'll pass on that. It was interesting to learn more about eDP though.
The resolution isn't limited, only the data rate is. If the display supports different refresh rates than the usual 60Hz (possible, the datasheet isn't clear about that, IMHO), you can have a higher reso- lution at a lower refresh rate. So FHD at 50Hz might be possible with a single lane. You could try to figure the display's support for lower rates using the OS' driver (e.g. xrandr with Linux/X.Org).
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?).
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;
2. in soc/rockchip/rk3288/display.c line 101 override the pixel clock:
edid.mode.pixel_clock = 113850;
The number assumes that the display can do 2.7GHz on the lane. You'd have to go down to 30Hz (68310) otherwise.
Nico
So looking at the specs for the display that comes with the ASUS
Chromebook C201 I can see the following PIN structure [1] is required on the display end.
I'm confused... there's 30 pins there, but there should only be 20 on the connector. I guess you got this from the panel datasheet directly? If you bought your panel together with the cable, you still don't know how those map to what's on the connector. Looks like they're dropping 10 of them and rearranging the rest, because this looks nothing like the schematics I have. (For reference it starts with two VCC_LED, two VCC33_LCD, then HOTPLUG and two backlight-related pins.)
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;
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.
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.
-
Julius Werner -
Nico Huber