Typical luck, just as I sent my last message my new monitor arrives. I've just
hooked it up and it actually worked.
Unfortunately it's not a 15'' monitor, but a 14'' one. Not sure how it works on
only 1 lane, but not going to complain.
For anyone else interested the monitor specs are here:
http://www.bvslcd.cn/uploads/2016/11/261508375971.pdf
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 6, 2018 8:55 AM, Mark Wylde <m...@markwylde.co.uk> wrote:
> 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 <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
https://mail.coreboot.org/mailman/listinfo/coreboot
