Bug 67950 - [ivb regression][bisect] 3.10: i915 blanks eDP panel when CSM is disabled in UEFI
[ivb regression][bisect] 3.10: i915 blanks eDP panel when CSM is disabled in ...
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
XOrg git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Intel GFX Bugs mailing list
Intel GFX Bugs mailing list
https://bugzilla.kernel.org/show_bug....
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-09 13:23 UTC by Michael Shigorin
Modified: 2013-11-01 11:50 UTC (History)
3 users (show)

See Also:


Attachments
dmesg from UX31A running under 3.10.5 with drm.debug=0xe (101.73 KB, text/plain)
2013-08-09 13:23 UTC, Michael Shigorin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Shigorin 2013-08-09 13:23:43 UTC
Created attachment 83890 [details]
dmesg from UX31A running under 3.10.5 with drm.debug=0xe

This has been reported in ALT Linux bugzilla (in Russian), posting here at Kirill's request as I've confirmed a report by another user on the same hardware I happen to use.

3.10.x kernels up to and including 3.10.5 result in turning off the backlight at i915 module load time on ASUS UX31A (i7-3517U); dmesg with drm.debug=0xe and late module load (not in initrd) is attached; external VGA monitor works fine (dmesg and Xorg.1.log available if needed).

Here's a transcript of sysfs knob fiddling over ssh:

root@ux class/backlight/intel_backlight # cat actual_brightness 
0
root@ux class/backlight/intel_backlight # cat max_brightness 
4302
root@ux class/backlight/intel_backlight # echo 800 > brightness       
root@ux class/backlight/intel_backlight # cat actual_brightness       
4302

and corresponding bits of dmesg (including further attempts at putting 100 and 80 values into brightness; both resulted in actual_brightness reading the same values but the screen backlight is still off):

[  877.052934] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4302
[  881.868818] [drm:intel_panel_get_backlight], get backlight PWM = 4302
[  974.670199] [drm:intel_panel_get_backlight], get backlight PWM = 4302
[  978.469350] [drm:intel_panel_actually_set_backlight], set backlight PWM = 100
[  981.176898] [drm:intel_panel_get_backlight], get backlight PWM = 100
[  990.186065] [drm:intel_panel_actually_set_backlight], set backlight PWM = 80

acpi_video0 doesn't have any effect either.

This bug hasn't manifested itself on 3.9.7 with very similar configuration on the same hardware.

I've skimmed over bug #51394 and bug #66462 which might be related; #54687 and #65652 seem rather not.
Comment 1 Daniel Vetter 2013-08-09 17:16:56 UTC
I have the same machine and it seems to still work here. So no idea what's gone boink. Can you please try to bisect this regression?
Comment 2 Michael Shigorin 2013-08-09 17:47:30 UTC
Will try next week, thanks.  In the mean time could you please verify any of http://en.altlinux.org/Regular#main live images which happen to use the same 3.10.5 by now?
Comment 3 Michael Shigorin 2013-08-12 11:53:28 UTC
3.11-rc4 misbehaves the same way here, just in case.  And even worse -- four tuxen with windows flags!!1
Comment 4 Michael Shigorin 2013-08-13 15:34:05 UTC
(In reply to comment #1)
> I have the same machine and it seems to still work here. So no idea what's
> gone boink.
Do you run it in BIOS or UEFI mode?
efifb gets initialized first here as mentioned in dmesg attached.

> Can you please try to bisect this regression?
Yup (thanks boyarsh@altlinux); git bisect log:
# bad: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376] Linux 3.10
# good: [c1be5a5b1b355d40e6cf79cc979eb66dafa24ad1] Linux 3.9
git bisect start 'v3.10' 'v3.9' '--' 'drivers/gpu/drm/i915/'
# bad: [8a5c2ae753c588bcb2a4e38d1c6a39865dbf1ff3] drm/i915: fix ILK GPU reset for render
git bisect bad 8a5c2ae753c588bcb2a4e38d1c6a39865dbf1ff3
# good: [ed5de3995f9cdff997613f240e41033463703121] drm/i915: add media well to VLV force wake routines v2
git bisect good ed5de3995f9cdff997613f240e41033463703121
# good: [fa00abe00e379a0e9b070616baee58692576f29e] DRM/i915: Remove valleyview_hpd_irq_setup.
git bisect good fa00abe00e379a0e9b070616baee58692576f29e
# good: [460da91617d870972a7ae300fad3e13731b67757] drm/i915: compute pipe_config earlier
git bisect good 460da91617d870972a7ae300fad3e13731b67757
# bad: [3600836585e3fdef0a1410d63fe5ce4015007aac] drm/i915: convert DP autodither code to new infrastructure  
git bisect bad 3600836585e3fdef0a1410d63fe5ce4015007aac
# good: [5bfe2ac00395ca37219b7187299cd9d23ae06682] drm/i915: add pipe_config->has_pch_encoder
git bisect good 5bfe2ac00395ca37219b7187299cd9d23ae06682
# good: [965e0c489f360df1beeb567e4540777a09b8896e] drm/i915: introduce pipe_config->dither|pipe_bpp
git bisect good 965e0c489f360df1beeb567e4540777a09b8896e
# good: [4e53c2e010e531b4a014692199e978482d471c7e] drm/i915: precompute pipe bpp before touching the hw
git bisect good 4e53c2e010e531b4a014692199e978482d471c7e
# first bad commit: [3600836585e3fdef0a1410d63fe5ce4015007aac] drm/i915: convert DP autodither code to new
infrastructure

Seems that there's no image (kas@ advised to shine a flashlight upon the display, there were no signs of display manager upon boot when the network was up already).
Comment 5 Michael Shigorin 2013-08-14 14:45:25 UTC
(In reply to comment #2)
> could you please verify any of http://en.altlinux.org/Regular#main
> live images which happen to use the same 3.10.5 by now?
Maybe this helps: today's snapshot including 3.10.6 just works on my UX31A in both BIOS and UEFI modes *if* CSM is enabled in firmware; disabling Boot > Launch CSM triggers the bug.

The images are UEFI/BIOS, CD/Flash hybrid (just dd it onto a stick).
Comment 6 Michael Shigorin 2013-08-15 11:03:00 UTC
(In reply to comment #5)
> [...] 3.10.6 just works on my UX31A [...] *if* CSM is enabled in firmware
Confirmed by the original (ALT) bug poster too.
Comment 7 Michael Shigorin 2013-08-16 12:50:35 UTC
3.10.7 plus the hack from https://bugzilla.kernel.org/show_bug.cgi?id=59841#c41 works on UX31A with CSM disabled.
Comment 8 Daniel Vetter 2013-08-25 12:00:36 UTC
Please retest with latest drm-intel-fixes, specifically

commit 2e6efddd203c15ca5c4700511f717c0e9a3ea31a
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri Aug 23 23:50:23 2013 +0300

    drm/i915: ivb: fix edp voltage swing reg val
Comment 9 Jani Nikula 2013-09-10 05:25:32 UTC
Michael, just to verify what's seen on [1] and [2], please attach /sys/kernel/debug/dri/0/i915_opregion for non-working and working setting of the BIOS option. Thanks.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=59841
[2] https://bugzilla.kernel.org/show_bug.cgi?id=60881
Comment 10 Michael Shigorin 2013-09-10 08:28:02 UTC
(In reply to comment #9)
> please attach /sys/kernel/debug/dri/0/i915_opregion for non-working
> and working setting of the BIOS option
OK, I'll have to get to the office so another console with ssh is handy.
Comment 11 Michael Shigorin 2013-09-10 16:44:47 UTC
Jani, I've posted /sys/kernel/debug/dri/0/i915_opregion for UX31A (both UEFI and UEFI+CSM) at kernel bugzilla so as to keep all dumps to one bug:

https://bugzilla.kernel.org/show_bug.cgi?id=59841#c148 (heh, got striped)
https://bugzilla.kernel.org/attachment.cgi?id=108031
https://bugzilla.kernel.org/attachment.cgi?id=108051

I'll repost these here if you tell me to of course.

Daniel, I haven't had a chance to retest with latest drm-intel-fixes so far, sorry.  Should I try this week?
Comment 12 Chris Wilson 2013-09-10 18:42:56 UTC
Yes, as I wonder if this is something like 

commit fd4daa9cea025ddf8623db289e79d264e9fa66f6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Aug 27 17:04:17 2013 +0100

    drm/i915: Track pfit enable state separately from size

instead of the usual issues.
Comment 13 Jani Nikula 2013-09-11 07:04:22 UTC
(In reply to comment #12)
> Yes, as I wonder if this is something like 
> 
> commit fd4daa9cea025ddf8623db289e79d264e9fa66f6
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Tue Aug 27 17:04:17 2013 +0100
> 
>     drm/i915: Track pfit enable state separately from size
> 
> instead of the usual issues.

Chris, the VBT reports different bpp for CSM vs. no-CSM. One works, the other doesn't. How would that commit be relevant here?
Comment 14 Chris Wilson 2013-09-11 09:14:11 UTC
Less likely in that case... Still worth checking if it is.
Comment 15 Jani Nikula 2013-11-01 11:50:49 UTC
Fixed by
commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Oct 21 10:52:07 2013 +0300

    drm/i915/dp: workaround BIOS eDP bpp clamping issue