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.

2. http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 5, 2018 11:50 PM, Julius Werner <jwer...@chromium.org> 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: coreboot@coreboot.org

Reply via email to