Bug 97363

Created attachment 125814 [details]
dmesg

I added some logging to the intel_display.c for both linux-4.6 and linux-4.7. While running these customized kernels I figured out the following:
In both cases the same methods are called. So my first assumption was wrong, that in linux-4.6 maybe a different method then g4x_find_best_dpll was used for calculating the PLL. But I found a difference in the values passed to this method. The value of the parameter target is 100400 using linux-4.6 and 25180 using linux-4.7. As the code of the method g4x_find_best_dpll hasn't changed between these 2 versions, I'd say the different input value causes the bug.
At the moment I haven't found the location where the value for target (crtc_state->port_clock) comes from but it's not that easy navigating through the code just using vim. If I find some time tomorrow I'll try how well IntelliJ can handle C projects to find the cause for the different values for the crtc_state->port_clock
Furthermore I hope this information is useful for somebody else to dig into this issue.

After some further investigations I figured out the following:
* only the LVDS port is affected by this bug, if I attach a monitor via HDMI wayland starts and shows a picture on this monitor but the display of the laptop gets black at the same time
* the wrong value of the crtc_state->port_clock comes from the clock value of the drm_display_mode struct so it seems the wrong frequency is set very early during the initialization of the drm stuff. Unfortunately I still haven't found the place where this happens cause I'm not that familiar with the code of the kernel to know by which part and when the drm initialization gets started. So I mostly did this by trail and error.

Created attachment 126020 [details]
drm-debug-linux-4.6

Created attachment 126021 [details]
drm-debug-linux-4.7

I finally found how to configure the debugging for the drm module(s) \o/. After doing this I found the reason for the different clock values:
For linux 4.6 I get these lines:
[drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables:
[drm:drm_mode_debug_printmodeline] Modeline 0:"1600x900" 0 100400 1600 1648 1680 1792 900 902 907 932 0x8 0xa
For linux 4.7 I get these lines:
[drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables:
[drm:drm_mode_debug_printmodeline] Modeline 0:"640x480" 0 25180 640 648 744 784 480 482 484 509 0x8 0xa

I attached the beginning of both logs for further infos. So it seems the code that retrieves the available modes from the BIOS does something different between these 2 versions.

The second line of the description of
  https://lists.freedesktop.org/archives/dri-devel/2016-August/116579.html
rings a bell... Could this be related and/or of any help?

Just wanted to add that the same error msg and BUG also affects my laptop: Error msg shown at boot, blank screen when starting X or wayland.

Just to add, that this also affects my laptop with a i5 3320m and onboard intel hd4000 graphics. The panel's modes get wrongly identified and this results in distortion across the screen, rendering kernels 4.7* and 4.8* versions as of this writing unusable for me.

Just to add, that this also affects my laptop with a i5 3320m and onboard intel hd4000 graphics. The panel's modes get wrongly identified and this results in distortion across the screen, rendering kernels 4.7* and 4.8* versions as of this writing unusable for me.

Bug 97060 seems related to this one.

Can you try 
git://github.com/vsyrjala/linux.git opregion_panel_type_stuff

I'm not expecting it would really fix the problem, but it will at least show us the full response from the BIOS.

Created attachment 126253 [details]
drm-debug-opregion_panel_type_stuff

I just build a kernel form the given branch and enabled the debugging for the drm module. The attachment contains all debug logs of the drm. Hope this helps to find the cause of this bug.

(In reply to Robin Müller from comment #12)
> Created attachment 126253 [details]
> drm-debug-opregion_panel_type_stuff
> 
> I just build a kernel form the given branch and enabled the debugging for
> the drm module. The attachment contains all debug logs of the drm. Hope this
> helps to find the cause of this bug.

Thanks. I pushed a new patch to the branch which I think should get us back on track with your machine. So please pull again, and retest.

I don't really know if it's any more correct than the current code though, and I don't yet know if it works for the original machine that needs the opregion panel type.

(In reply to Ville Syrjala from comment #13)
> (In reply to Robin Müller from comment #12)
> > Created attachment 126253 [details]
> > drm-debug-opregion_panel_type_stuff
> > 
> > I just build a kernel form the given branch and enabled the debugging for
> > the drm module. The attachment contains all debug logs of the drm. Hope this
> > helps to find the cause of this bug.
> 
> Thanks. I pushed a new patch to the branch which I think should get us back
> on track with your machine. So please pull again, and retest.
> 
> I don't really know if it's any more correct than the current code though,
> and I don't yet know if it works for the original machine that needs the
> opregion panel type.

Thanks, this patch did the trick. After applying the patch the error is gone and my display manager starts again :-)

(In reply to Ville Syrjala from comment #13)
> (In reply to Robin Müller from comment #12)
> > Created attachment 126253 [details]
> > drm-debug-opregion_panel_type_stuff
> > 
> > I just build a kernel form the given branch and enabled the debugging for
> > the drm module. The attachment contains all debug logs of the drm. Hope this
> > helps to find the cause of this bug.
> 
> Thanks. I pushed a new patch to the branch which I think should get us back
> on track with your machine. So please pull again, and retest.
> 
> I don't really know if it's any more correct than the current code though,
> and I don't yet know if it works for the original machine that needs the
> opregion panel type.

This branch resolve the problem on my i5-3317U as well.

I had to resort to a quirk to fix this for all machines. Please test this branch:

git://github.com/vsyrjala/linux.git opregion_panel_type_quirk

(In reply to Ville Syrjala from comment #16)
> I had to resort to a quirk to fix this for all machines. Please test this
> branch:
> 
> git://github.com/vsyrjala/linux.git opregion_panel_type_quirk

Thank you for this, it's working (on np900x4c).

ps: I was trying to enable drm debugging, adding drm.debug=14 to kernel line..is this the right way? And then I'll read the debugging infos with dmesg, right?

(In reply to oceans112 from comment #17)
> (In reply to Ville Syrjala from comment #16)
> > I had to resort to a quirk to fix this for all machines. Please test this
> > branch:
> > 
> > git://github.com/vsyrjala/linux.git opregion_panel_type_quirk
> 
> Thank you for this, it's working (on np900x4c).
> 
> ps: I was trying to enable drm debugging, adding drm.debug=14 to kernel
> line..is this the right way? And then I'll read the debugging infos with
> dmesg, right?

Ooops! I'm sorry but I copy/paste the wrong branch, actually I built and tested opregion_panel_type_stuff. I'll try opregion_panel_type_quirk asap, please ask for any details.

ok, so git://github.com/vsyrjala/linux.git opregion_panel_type_quirk (this time I double-checked) works too.

From Xorg.log I can tell that the driver is picking up the correct output mode for the panel.

(In reply to Ville Syrjala from comment #16)
> I had to resort to a quirk to fix this for all machines. Please test this
> branch:
> 
> git://github.com/vsyrjala/linux.git opregion_panel_type_quirk

Also an affirmative that the quirk based fix works on my Samsung NP900X4D.

(In reply to Emil Andersen Lauridsen from comment #20)
> (In reply to Ville Syrjala from comment #16)
> > I had to resort to a quirk to fix this for all machines. Please test this
> > branch:
> > 
> > git://github.com/vsyrjala/linux.git opregion_panel_type_quirk
> 
> Also an affirmative that the quirk based fix works on my Samsung NP900X4D.

I had to revise the patch a bit more to make it actually work on the original machine that needs the quirk:
git://github.com/vsyrjala/linux.git opregion_panel_type_quirk_2

Please test to make sure I didn't fumble anything for other machines. Fingers crossed that this is the last revision...

(In reply to Ville Syrjala from comment #21)
> (In reply to Emil Andersen Lauridsen from comment #20)
> > (In reply to Ville Syrjala from comment #16)
> > > I had to resort to a quirk to fix this for all machines. Please test this
> > > branch:
> > > 
> > > git://github.com/vsyrjala/linux.git opregion_panel_type_quirk
> > 
> > Also an affirmative that the quirk based fix works on my Samsung NP900X4D.
> 
> I had to revise the patch a bit more to make it actually work on the
> original machine that needs the quirk:
> git://github.com/vsyrjala/linux.git opregion_panel_type_quirk_2
> 
> Please test to make sure I didn't fumble anything for other machines.
> Fingers crossed that this is the last revision...

New branch works here. Nice work.

(In reply to Emil Andersen Lauridsen from comment #22)
> (In reply to Ville Syrjala from comment #21)
> > (In reply to Emil Andersen Lauridsen from comment #20)
> > > (In reply to Ville Syrjala from comment #16)
> > > > I had to resort to a quirk to fix this for all machines. Please test this
> > > > branch:
> > > > 
> > > > git://github.com/vsyrjala/linux.git opregion_panel_type_quirk
> > > 
> > > Also an affirmative that the quirk based fix works on my Samsung NP900X4D.
> > 
> > I had to revise the patch a bit more to make it actually work on the
> > original machine that needs the quirk:
> > git://github.com/vsyrjala/linux.git opregion_panel_type_quirk_2
> > 
> > Please test to make sure I didn't fumble anything for other machines.
> > Fingers crossed that this is the last revision...
> 
> New branch works here. Nice work.

This branch works also on my machine.

Quite useless comment, but I can confirm that last branch works on np900x4c.

So, can we expect to see this merged into 4.8.1?

Patch submitted and under review: https://patchwork.freedesktop.org/series/12380/

Resolving as fixed due to re-test feedback and waiting for patch to be merged and tested to close it.

(In reply to yann from comment #26)
> Resolving as fixed due to re-test feedback and waiting for patch to be
> merged and tested to close it.

Please let's resolve fixed only after the patch has been merged. Thanks.

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Sep 13 12:22:19 2016 +0300

    drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes.