Bug 68030 - [Haswell] blank Screen with intel ddx on first use right after using fbdev ddx. Breaking SuSE Install
Summary: [Haswell] blank Screen with intel ddx on first use right after using fbdev dd...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-12 18:31 UTC by Rodrigo Vivi
Modified: 2017-07-24 22:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
script to reproduce bug (473 bytes, text/plain)
2013-08-12 18:31 UTC, Rodrigo Vivi 		no flags Details
fbdev xorg conf (5.18 KB, text/plain)
2013-08-12 18:31 UTC, Rodrigo Vivi 		no flags Details
intel xorg conf (3.68 KB, text/plain)
2013-08-12 18:31 UTC, Rodrigo Vivi 		no flags Details
normal intel ddx run: dmesg (151.74 KB, text/plain)
2013-08-12 18:32 UTC, Rodrigo Vivi 		no flags Details
normal intel ddx run: xorg.0.log (21.28 KB, text/plain)
2013-08-12 18:32 UTC, Rodrigo Vivi 		no flags Details
fbdev running: dmesg (8.23 KB, text/plain)
2013-08-12 18:33 UTC, Rodrigo Vivi 		no flags Details
fbdev running: xorg log (21.27 KB, text/plain)
2013-08-12 18:33 UTC, Rodrigo Vivi 		no flags Details
intel running after fbdev: blank screen! (dmesg) (66.13 KB, text/plain)
2013-08-12 18:34 UTC, Rodrigo Vivi 		no flags Details
intel running after fbdev: blank screen! (xorg log) (21.18 KB, text/plain)
2013-08-12 18:34 UTC, Rodrigo Vivi 		no flags Details
dmesg regular boot with intelddx since I always forgot to increase log buf size (153.72 KB, text/plain)
2013-08-12 19:11 UTC, Rodrigo Vivi 		no flags Details
dmesgs with ickle's patch (32.58 KB, text/plain)
2013-08-13 20:32 UTC, Rodrigo Vivi 		no flags Details
Full dmesg (206.25 KB, text/plain)
2013-09-13 13:09 UTC, Rodrigo Vivi 		no flags Details
Full logs with SNA and ddx debug=full (310.04 KB, text/plain)
2013-09-18 14:57 UTC, Rodrigo Vivi 		no flags Details
View All

Description Rodrigo Vivi 2013-08-12 18:31:14 UTC 
Created attachment 83979 [details]
script to reproduce bug

Bug description:

Blank screen on the first intel DDX run right after running FBDEV DDX.
Not even possible to alternate to fbcon. Have to reboot or restart X to get screen back.

This behaviour breaks SuSE installation.

System environment:
-- chipset: Haswell
-- system architecture: x86_64
-- xf86-video-intel: xorg-x11-driver-video-7.4.0.1-0.81.27
-- xserver: 1.6.5
-- libdrm: 2.4.41-0.8.46
-- kernel: nightly 7e4f3f0cb9d232721bfdaa00c27c5550f70428a8 3.11.0-rc4-0.11
-- Linux distribution: SLED
-- Display connector: DP

Reproducing steps:

- Run Intel ddx and stop it.
- Run FBDEV ddx and stop it.
- Run Intel ddx again.
- Blank Screen (only on first run after fbdev)
- Restart X or machine and screen is back.
Comment 1 Rodrigo Vivi 2013-08-12 18:31:39 UTC 
Created attachment 83980 [details]
fbdev xorg conf
Comment 2 Rodrigo Vivi 2013-08-12 18:31:54 UTC 
Created attachment 83981 [details]
intel xorg conf
Comment 3 Rodrigo Vivi 2013-08-12 18:32:25 UTC 
Created attachment 83982 [details]
normal intel ddx run: dmesg
Comment 4 Rodrigo Vivi 2013-08-12 18:32:45 UTC 
Created attachment 83983 [details]
normal intel ddx run: xorg.0.log
Comment 5 Rodrigo Vivi 2013-08-12 18:33:14 UTC 
Created attachment 83984 [details]
fbdev running: dmesg
Comment 6 Rodrigo Vivi 2013-08-12 18:33:31 UTC 
Created attachment 83985 [details]
fbdev running: xorg log
Comment 7 Rodrigo Vivi 2013-08-12 18:34:12 UTC 
Created attachment 83986 [details]
intel running after fbdev: blank screen! (dmesg)
Comment 8 Rodrigo Vivi 2013-08-12 18:34:28 UTC 
Created attachment 83987 [details]
intel running after fbdev: blank screen! (xorg log)
Comment 9 John Sundragon Waitz 2013-08-12 18:53:34 UTC 
It might save work for others to state that experts at SUSE looked at intel_reg_dumper output and it appears that the state of the PIPEACONF register might be relevant to the root cause.
Comment 10 Rodrigo Vivi 2013-08-12 19:11:54 UTC 
Created attachment 83988 [details]
dmesg regular boot with intelddx since I always forgot to increase log buf size
Comment 11 Chris Wilson 2013-08-13 17:40:12 UTC 
The WARN is significant as it is pointing out the DPMS performed by uxa following the modeset finds the output disabled:

[  131.230177] [drm:check_encoder_state], [ENCODER:10:DAC-10]
[  131.230183] [drm:check_encoder_state], [ENCODER:11:TMDS-11]
[  131.230187] ------------[ cut here ]------------
[  131.230250] WARNING: CPU: 0 PID: 3268 at drivers/gpu/drm/i915/intel_display.c:8487 check_encoder_state+0x1f9/0x270 [i915]()
[  131.230254] encoder's computed active state doesn't match tracked active state (expected 1, found 0)
[  131.230256] Modules linked in: nfs(F) fscache(F) lockd(F) sunrpc(F) af_packet(F) xt_limit(F) snd_pcm_oss(F) snd_mixer_oss(F) snd_seq(F) snd_seq_device(F) binfmt_misc(F) ip6t_REJECT(F) nf_conntrack_ipv6(F) nf_defrag_ipv6(F) ip6table_raw(F) xt_CT(F) ipt_REJECT(F) xt_state(F) iptable_raw(F) iptable_filter(F) ip6table_mangle(F) nf_conntrack_netbios_ns(F) nf_conntrack_broadcast(F) nf_conntrack_ipv4(F) nf_conntrack(F) nf_defrag_ipv4(F) ip_tables(F) cpufreq_conservative(F) cpufreq_userspace(F) ip6table_filter(F) ip6_tables(F) cpufreq_powersave(F) x_tables(F) ipv6(F) fuse(F) nls_iso8859_1(F) nls_cp437(F) vfat(F) fat(F) loop(F) dm_mod(F) snd_hda_codec_realtek(F) snd_hda_intel(F) snd_hda_codec(F) snd_hwdep(F) snd_pcm(F) snd_timer(F) snd(F) hid_generic(F) hp_wmi(F) tpm_infineon(F) soundcore(F) ehci_pci(F) sparse_keymap(F) rfkill(F) ehci_hcd(F) acpi_cpufreq(F) e1000e(F) sr_mod(F) cdrom(F) tpm_tis(F) snd_page_alloc(F) iTCO_wdt(F) pcspkr(F) serio_raw(F) mperf(F) ptp(F) sg(F) iTCO_vendor_support(F) lpc_ich(F) i2c_i801(F) mfd_core(F) wmi(F) pps_core(F) rtc_cmos(F) tpm(F) tpm_bios(F) ext3(F) jbd(F) mbcache(F) i915(F) drm_kms_helper(F) drm(F) intel_agp(F) i2c_algo_bit(F) intel_gtt(F) i2c_core(F) video(F) usbhid(F) hid(F) sd_mod(F) crc_t10dif(F) xhci_hcd(F) usbcore(F) fan(F) usb_common(F) button(F) thermal(F) processor(F) thermal_sys(F) hwmon(F) scsi_dh_rdac(F) scsi_dh_hp_sw(F) scsi_dh_emc(F) scsi_dh_alua(F) scsi_dh(F) ahci(F) libahci(F) libata(F) scsi_mod(F)
[  131.230388] CPU: 0 PID: 3268 Comm: X Tainted: GF       W    3.11.0-rc4-0.11-default #1
[  131.230391] Hardware name: Hewlett-Packard HP Z230 SFF Workstation/1906, BIOS L51 v01.00 06/07/2013
[  131.230395]  0000000000002127 ffff88011577bc18 ffffffff8149505e ffff88011577bc58
[  131.230403]  ffffffff8104a167 ffff88011280c000 ffff880114a0e000 0000000000000001
[  131.230409]  ffff88011280c3f0 ffff88011280c000 ffff88011280c408 ffff88011577bcb8
[  131.230416] Call Trace:
[  131.230431]  [<ffffffff8149505e>] dump_stack+0x6a/0x7c
[  131.230440]  [<ffffffff8104a167>] warn_slowpath_common+0x87/0xb0
[  131.230446]  [<ffffffff8104a231>] warn_slowpath_fmt+0x41/0x50
[  131.230488]  [<ffffffffa022a469>] check_encoder_state+0x1f9/0x270 [i915]
[  131.230524]  [<ffffffffa023216d>] intel_modeset_check_state+0x7d/0xa0 [i915]
[  131.230555]  [<ffffffffa02321db>] intel_connector_dpms+0x4b/0x90 [i915]
[  131.230586]  [<ffffffffa0198c57>] drm_mode_obj_set_property_ioctl+0x357/0x370 [drm]
[  131.230612]  [<ffffffffa0198c9d>] drm_mode_connector_property_set_ioctl+0x2d/0x30 [drm]
[  131.230635]  [<ffffffffa018b44a>] drm_ioctl+0x3aa/0x630 [drm]
[  131.230665]  [<ffffffffa0198c70>] ? drm_mode_obj_set_property_ioctl+0x370/0x370 [drm]
[  131.230675]  [<ffffffff8117c163>] do_vfs_ioctl+0x83/0x370
[  131.230681]  [<ffffffff8117c4e1>] SyS_ioctl+0x91/0xb0
[  131.230690]  [<ffffffff8149d529>] ? do_page_fault+0x9/0x10
[  131.230697]  [<ffffffff814a1ad2>] system_call_fastpath+0x16/0x1b
[  131.230702] ---[ end trace 78439480d92af715 ]---
[  131.230706] [drm:check_encoder_state], [ENCODER:16:TMDS-16]
[  131.230711] [drm:check_encoder_state], [ENCODER:19:TMDS-19]
[  131.230715] [drm:check_crtc_state], [CRTC:3]
[  131.230721] [drm:check_crtc_state], [CRTC:5]
[  131.230725] [drm:check_crtc_state], [CRTC:7]
Comment 12 Rodrigo Vivi 2013-08-13 20:32:53 UTC 
Created attachment 84029 [details]
dmesgs with ickle's  patch

The situation improved a lot.

No warn.
No oops.
Screen back after alternating to fbcon.
But still blank screen when starting intel ddx after fbcon
Comment 13 Daniel Vetter 2013-08-13 20:33:05 UTC 
An igt testcase for this would be pretty awesome ...
Comment 14 Chris Wilson 2013-08-26 17:02:18 UTC 
Rodrigo, can you add a ton of printk through modesetting see why we decide to only do a fbset versus modeset?
Comment 15 Rodrigo Vivi 2013-09-11 18:28:40 UTC 
The most strange thing I notice was when if fails

on intel_connector_dpms mode is != connector->dpms so it doesn't return on that point like on every time that that works.

When it works:
[   22.003560] [drm:intel_crtc_set_config], MODE_CHANGED intel_crtc_set_config 8031
[   22.003574] [drm:intel_crt_dpms], VIVI: intel_crt_dpms 148
[   22.003578] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846
[   22.003581] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846
[   22.003584] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846
[   22.003586] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846
[   22.003589] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846

When if fails:
[  121.876256] [drm:intel_crtc_set_config], MODE_CHANGED intel_crtc_set_config 8031
[  121.876272] [drm:intel_crt_dpms], VIVI: intel_crt_dpms 148
[  121.876276] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846
[  121.876277] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3859
[  121.876278] [drm:intel_modeset_check_state], VIVI: intel_modeset_check_state 7533
[  121.876279] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804
[  121.876281] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804
[  121.876282] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804
[  121.876283] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804
[  121.876285] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804
[  121.876286] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804
[  121.876287] [drm:intel_connector_check_state], VIVI: 
intel_connector_check_state 3804
Comment 16 Daniel Vetter 2013-09-12 08:46:07 UTC 
Rodrigo, can you please add a few debug printks to intel_crt_dpms to dump the current and the requested dpms mode and then grab a full dmesg when this fails?

It wouldn't surprise me at all if we have yet another bug in our dpms tracking ...
Comment 17 Rodrigo Vivi 2013-09-12 17:14:08 UTC 
connector-dpms and mode at intel_crt_dpms are both 3 always... with ddx intel working, with ddx fbdev and with intel failling
Comment 18 Rodrigo Vivi 2013-09-12 17:28:00 UTC 
but connector-> dpms is changed to OFF here because !crtc
Comment 19 Daniel Vetter 2013-09-13 08:15:59 UTC 
Rodrigo, can you please attach a new debug dmesg with everything from boot to the intel ddx with the broken config? I.e. boot -> fbdev ddx -> intel ddx with black screen. I couldn't find it in all the above stuff ;-)
Comment 20 Rodrigo Vivi 2013-09-13 13:09:28 UTC 
Created attachment 85766 [details]
Full dmesg

This is the latest full dmesg with SuSE kernel and some printks I was using for debug.
Comment 21 Rodrigo Vivi 2013-09-13 18:03:33 UTC 
dpms off/on cycle helps.

With blank screen on intel ddx after fbdev I used
xset dpms force off / than moved the mouse
and got screen back.
Comment 22 Rodrigo Vivi 2013-09-18 14:57:57 UTC 
Created attachment 86067 [details]
Full logs with SNA and ddx debug=full

Chris fixed sna building on SLED and I could get it running here but the issue remains. Attached full new log with SNA and debug=full, but I couldn't notice anything new.

Also he confirmed that with same SLED this bug doesn't occur on IVB.

CRTC is off for some weird reason on this HSW. Any ideas/theories?
Comment 23 Chris Wilson 2013-09-19 14:39:42 UTC 
commit 63a070a31a3963f836539ee7629d64fe3c9f88c8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 18 17:03:40 2013 +0100

    sna: Do not change DPMS mode on unconnected outputs
    
    The operation is in theory redundant, and in the case of Haswell where
    we have multiple outputs aliasing to the same encoder, actually harmful.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 24 Chris Wilson 2013-09-19 14:40:49 UTC 
For UXA, I think


diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 7dc0f68..3c2f964 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -1123,10 +1123,13 @@ intel_output_dpms(xf86OutputPtr output, int dpms)
                                intel_output_dpms_backlight(output,
                                                            intel_output->dpms_mode,
                                                            dpms);
-                       drmModeConnectorSetProperty(mode->fd,
-                                                   intel_output->output_id,
-                                                   props->prop_id,
-                                                   dpms);
+
+                       if (output->crtc)
+                               drmModeConnectorSetProperty(mode->fd,
+                                                           intel_output->output_id,
+                                                           props->prop_id,
+                                                           dpms);
+
                        if (dpms != DPMSModeOff)
                                intel_output_dpms_backlight(output,
                                                            intel_output->dpms_mode,
Comment 25 Rodrigo Vivi 2013-09-19 17:19:05 UTC 
Hi Chris,

Thank you very much for fixing this.
I also confirmed that this patch in comment fixes the issue on UXA and already prepared one for Suse's ddx.

Thanks again,
Rodrigo.
Comment 26 Stefan Dirsch 2013-09-19 18:19:52 UTC 
Chris/Rodrigo. This is great news! One question. Knowing that SNA has become the driver default, could you still push the UXA fix to git as well? Thanks a lot!
Comment 27 Rodrigo Vivi 2013-09-20 10:39:43 UTC 
Hi Stefan, 

Since Chris is the real author of the uxa patch as well I think makes more sense for him to push his patch, but I'm going to prepare one right now and submit anyway.

For the xf86-video-intel you use on SLED I had attached the patch on your bugzilla: 817998
Comment 28 Chris Wilson 2013-09-20 10:47:28 UTC 
commit 4497212307dee5e35bc6836201738a2fdb559020
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 18 17:03:40 2013 +0100

    uxa: Do not change DPMS mode on unconnected outputs
    
    The operation is in theory redundant, and in the case of Haswell where
    we have multiple outputs aliasing to the same encoder, actually harmful.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Tested-by: Stefan Dirsch <sndirsch@suse.de>
Comment 29 Stefan Dirsch 2013-09-20 14:31:28 UTC 
Thanks, Chris!
Comment 30 Chris Wilson 2014-02-13 09:53:07 UTC 
i-g-t commit 0b19cb5dc2afe55084b946b053c527b9f44a011f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 3 18:30:56 2013 +0200

    tests/kms_flip: Check the dpms confusion
    
    Some kernels inadvertedly forwarded dpms changes to crtcs connected to
    shared encoders even though that specific output wasn't enabled.
    Hilarity ensued.
    
    Note that we only have shared encoders on hsw (DP+HDMI) and with sdvo
    cards (multi-function encoders).
    
    v2: Do a full OFF->ON->OFF transition to make sure something actually
    happens.
    
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 31 Chris Wilson 2014-02-13 09:53:23 UTC 
kernel commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Sep 29 19:15:07 2013 +0100

    drm/i915: Only apply DPMS to the encoder if enabled
    
    The current test for an attached enabled encoder fails if we have
    multiple connectors aliased to the same encoder - both connectors
    believe they own the enabled encoder and so we attempt to both enable
    and disable DPMS on the encoder, leading to hilarity and an OOPs:
    
    [  354.803064] WARNING: CPU: 0 PID: 482 at
    /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]()
    [  354.803064] wrong connector dpms state
    [  354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm crc32c_intel e1000e intel_agp igb ghash_clmulni_intel intel_gtt aesni_intel cfbfillrect aes_x86_64 cfbimgblt lrw cfbcopyarea drm_kms_helper ptp video thermal processor gf128mul snd_page_alloc drm snd_timer glue_helper 8250_pci snd pps_core ablk_helper agpgart cryptd sg soundcore fan i2c_algo_bit sr_mod thermal_sys 8250 i2c_i801 serial_core
    hwmon cdrom i2c_core evdev button
    [  354.803086] CPU: 0 PID: 482 Comm: kworker/0:1 Not tainted 3.11.2 #1
    [  354.803087] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [  354.803091] Workqueue: events console_callback
    [  354.803092]  0000000000000009 ffff88023611db48 ffffffff814048ac ffff88023611db90
    [  354.803093]  ffff88023611db80 ffffffff8103d4e3 ffff880230d82800 ffff880230f9b800
    [  354.803094]  ffff880230f99000 ffff880230f99448 ffff8802351c0e00 ffff88023611dbe0
    [  354.803094] Call Trace:
    [  354.803098]  [<ffffffff814048ac>] dump_stack+0x54/0x8d
    [  354.803101]  [<ffffffff8103d4e3>] warn_slowpath_common+0x73/0x90
    [  354.803103]  [<ffffffff8103d547>] warn_slowpath_fmt+0x47/0x50
    [  354.803109]  [<ffffffffa089f1be>] ? intel_ddi_connector_get_hw_state+0x5e/0x110 [i915]
    [  354.803114]  [<ffffffffa0896974>] intel_modeset_check_state+0x764/0x770 [i915]
    [  354.803117]  [<ffffffffa08969bb>] intel_connector_dpms+0x3b/0x60 [i915]
    [  354.803120]  [<ffffffffa037e1d0>] drm_fb_helper_dpms.isra.11+0x120/0x160 [drm_kms_helper]
    [  354.803122]  [<ffffffffa037e24e>] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper]
    [  354.803123]  [<ffffffff812116c2>] fb_blank+0x52/0xc0
    [  354.803125]  [<ffffffff8121e04b>] fbcon_blank+0x21b/0x2d0
    [  354.803127]  [<ffffffff81062243>] ? update_rq_clock.part.74+0x13/0x30
    [  354.803129]  [<ffffffff81047486>] ? lock_timer_base.isra.30+0x26/0x50
    [  354.803130]  [<ffffffff810472b2>] ? internal_add_timer+0x12/0x40
    [  354.803131]  [<ffffffff81047f48>] ? mod_timer+0xf8/0x1c0
    [  354.803133]  [<ffffffff81266d61>] do_unblank_screen+0xa1/0x1c0
    [  354.803134]  [<ffffffff81268087>] poke_blanked_console+0xc7/0xd0
    [  354.803136]  [<ffffffff812681cf>] console_callback+0x13f/0x160
    [  354.803137]  [<ffffffff81053258>] process_one_work+0x148/0x3d0
    [  354.803138]  [<ffffffff81053f19>] worker_thread+0x119/0x3a0
    [  354.803140]  [<ffffffff81053e00>] ? manage_workers.isra.30+0x2a0/0x2a0
    [  354.803141]  [<ffffffff8105994b>] kthread+0xbb/0xc0
    [  354.803142]  [<ffffffff81059890>] ? kthread_create_on_node+0x120/0x120
    [  354.803144]  [<ffffffff8140b32c>] ret_from_fork+0x7c/0xb0
    [  354.803145]  [<ffffffff81059890>] ? kthread_create_on_node+0x120/0x120
    
    This regression goes back to the big modeset rework and the conversion
    to the new dpms helpers which started with:
    
    commit 5ab432ef4997ce32c9406721b37ef6e97e57dae1
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Sat Jun 30 08:59:56 2012 +0200
    
        drm/i915/hdmi: convert to encoder->disable/enable
    
    Fixes: igt/kms_flip/dpms-off-confusion
    Reported-and-tested-by: Wakko Warner <wakko@animx.eu.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
    Link:  http://lkml.kernel.org/r/20130928185023.GA21672@animx.eu.org
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@vger.kernel.org
    [danvet: Add regression citation, mention the igt testcase this fixes
    and slap a cc: stable on the patch.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 32 Chris Wilson 2014-02-13 09:54:21 UTC 
commit 72e909953c1865f86fbd6325ff807d7c7357af5f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Feb 13 09:46:13 2014 +0000

    Revert "uxa: Do not change DPMS mode on unconnected outputs"
    
    This reverts commit 4497212307dee5e35bc6836201738a2fdb559020.
    
    Unfortunately, this simple fix does not work for UXA as DPMS is used by
    the xserver to turn off CRTCs and outputs. Since UXA does not implement
    CRTC DPMS, this commit causes us to fail to turn off outputs.
    
    The kernel has been fixed up in the meantime and that commit has been
    recommended to be backported to all stable kernels:
    
    commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Sun Sep 29 19:15:07 2013 +0100
    
        drm/i915: Only apply DPMS to the encoder if enabled
    
    so it should be safe for UXA to rely on its old behaviour.
    
    Bugzilla: https://code.google.com/p/chromium/issues/detail?id=341135
    References: https://bugs.freedesktop.org/show_bug.cgi?id=68030
    Suggested-by: Dominik Behr <dbehr@google.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.