Hi Julius.
Thanks so much for your message it was a great help.
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.
Also my new monitor [2] has the exact same PIN structure for the display, but
unfortunately uses the ML1 lane.
------------------ eDP Pins for C201 Display ------------------
1 = NC No Connection (Reserved for LCD test)
2 = H_GND High Speed Ground
3 = NC No Connection ( Reserved for ML1 - )
4 = NC No Connection (Reserved for ML1+)
5 = H_GND High Speed Ground
6 = ML0 - Complement Signal - Lane 0
7 = ML0+ True Signal - Main Lane 0
8 = H_GND High Speed Ground
9 = AUX+ True Signal - Auxiliary Channel
10 = AUX - Complement Signal - Auxiliary Channel
11 = H_GND High Speed Ground
12 = VCCS Power Supply +3.3 V (typical)
13 = VCCS Power Supply +3.3 V (typical)
14 = NC No Connection (Reserved for LCD test)
15 = GND Ground
16 = GND Ground
17 = HPD Hot Plug Detect
18 = BL_GND BL Ground
19 = BL_GND BL Ground
20 = BL_GND BL Ground
21 = BL_GND BL Ground
22 = LED_EN BL_Enable Signal of LED Converter
23 = LED_PWM PWM Dimming Control Signal of LED Converter
24 = NC No Connection (Reserved for LCD test)
25 = NC No Connection (Reserved for LCD test)
26 = LED_VCCS BL Power
27 = LED_VCCS BL Power
28 = LED_VCCS BL Power
29 = LED_VCCS BL Power
30 = NC No Connection (Reserved for LCD test)
--------------------------------------------------
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.
Thanks Julius and Nico for all your help.
1.
http://www.szdengyi.com/upload/web/lcdspec/N116BGE-EB2-LR-Asus-notebook-pc.pdf
2. http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf
3.
https://forums.lenovo.com/t5/Lenovo-U-and-S-Series-Notebooks/Lenovo-U430p-screen-upgrade/m-p/2155787/highlight/true#M42366
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 5, 2018 11:50 PM, Julius Werner <[email protected]> wrote:
> 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.)
--
coreboot mailing list: [email protected]
https://mail.coreboot.org/mailman/listinfo/coreboot
