[coreboot] Getting an WXGA+ LED MVA panel to work on T400: "G141C1-L01"
toni at bluenox07.de
Mon Sep 26 12:25:58 CEST 2016
thank you for your reply.
> I didn't have the time for a closer look at your logs. But there is one
> thing coreboot does definitely wrong: The clock configuration. You can
> see it from the Linux log as it dumps the settings coreboot made first:
> > [ 6.523864] [drm:drm_mode_debug_printmodeline] Modeline 0:"1440x900" 50 87075 1440 1520 1672 1820 900 903 909 961 0x40 0xa
> > [ 6.523872] [drm:intel_dump_pipe_config] port clock: 87075
> vs what Linux sets up later:
> > [ 8.787651] [drm:drm_mode_debug_printmodeline] Modeline 0:"1440x900" 60 104500 1440 1520 1672 1820 900 903 909 961 0x48 0xa
> > [ 8.787668] [drm:intel_dump_pipe_config] port clock: 104500
Thank you for the hint. As I have really no idea what I should look for, it's
a starting point.
When I'm comparing this to the kernel log of my working CCFL WXGA display, I
notice that on the CCFL WXGA display (which is a LP141WX3-TLR1), the clock
frequency is set exactly to the value specified in the datasheet and EDID:
However on the G141C1-L01 (the MVA panel) datasheet, the clock frequency is
'106.5MHz' in the EDID table - but Linux sets it to 104.5 MHz, if I understand
the above correctly.
The DCLK frequency in the datasheet is specified as:
min. 40MHz, typ. 53.25MHz, max. 65MHz
(see page 16 of )
Could that difference (104.5MHz to 106.5MHz maybe be the issue?
I guess not, since there is a frequency range specified in the datasheet.
I also noticed that the max. current draw of the panel is a little bit higher
than the max. current draw of the LED WXGA+ which I used to compare the pinouts.
(It is known to work and has model number 'LP141WP2-TLB1')
For the MVA, typical for black is 550mA, for white it's 450mA.
For the TN it's 365mA - 495mA with typical 430mA.
What do you think about that?
> Not sure why Linux doesn't get the display running though. But as Linux
> sometimes reuses register settings set by the firmware there is a slight
> chance that fixing coreboot would make it work in Linux too.
You mean, despite the kernel log messages (which say 104500),
it might be that Linux is actually using the clock settings from coreboot, that
So, to check for that - could I temporarily hardcode the correct clock settings
Also, is it worth checking with latest coreboot instead of latest libreboot?
Maybe there are some changes concerning LVDS handling which are not yet in
So many questions :P
> There is a related patch up for review for i945  (older chipset) that
> fixes a similar issue there. Maybe it applies to gm45 too. The code
> looks very similar.
To be honest -- I understand nearly nothing of it :/
Also note that all of this feels way above my skills - at least the coreboot /
Linux / software part.
Merlin Büge <toni at bluenox07.de>
More information about the coreboot