[Bug 94825] LVDS blank screen on GM45

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Apr 7 09:22:43 UTC 2016


https://bugs.freedesktop.org/show_bug.cgi?id=94825

--- Comment #14 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Rob Kramer from comment #13)
> Some things I could try:
> 
> 1) Override broken panel type via module parameter.
> 2) Disable VBT via module parameter, force use of existing mode.
> 3) Use video=.. parameter to lookup matching VBT panel.

The driver is supposed to work without user having to pass parameters. So if we
can avoid we'll not be adding any.

> 
> I've tried option 1, hack panel_type to 15 in intel_bios.c, and that works:
> 
>   [    4.770027] [drm:intel_lvds_init] using mode from VBT:
>   [    4.770030] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0
> 148500 1920 2040 2080 2200 1080 1081 1092 1125 0x8 0xa
>   [    4.770033] [drm:intel_lvds_init] detected dual-link lvds configuration
> 
> Option 2 also works (hack out VBT setting), but results in messy kernel
> warnings/backtraces about pipe state mismatches, see previously attached
> logs.

Those warns shouldn't happen with
https://lists.freedesktop.org/archives/intel-gfx/2016-April/091392.html

There was also a more troubling error in the log
[drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on
but I don't have a decent idea for that now.

> 
> I don't know if option 3 is too horrible to consider.
> 
> I've applied your patch to 4.5 (with minor port), but it returns too early
> at:
> 
>         ret = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1,
> &edid);
>         if (ret < 0)
>                 return ret;
> 
> Could my kernel be missing some ACPI stuff? There is CONFIG_ACPI_VIDEO=m,
> and the module is loaded. I didn't add a new boot log since there wasn't
> anything new. If you have some ideas on how to debug this, please let me
> know (I know very little about ACPI)..

It's possible ACPI doesn't implement the _DDC method on your board. We could
check that from the ACPI tables. Can you take an 'acpidump -b', stuff the
results into a tarball and attach here?

The question I keep asking myself is "if the panel type is genuinely wrong in
the VBT, how could Windows work on this board?" Any idea if it does?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160407/167cf5cd/attachment.html>


More information about the intel-gfx-bugs mailing list