83600 – [HSW] non-existent HDMI-A-3 stomps on DP-1 gpio [was: HDMI monitor does not work via active DisplayPort adapter]

Bug 83600 - [HSW] non-existent HDMI-A-3 stomps on DP-1 gpio [was: HDMI monitor does not work via active DisplayPort adapter]

Summary: [HSW] non-existent HDMI-A-3 stomps on DP-1 gpio [was: HDMI monitor does not w...

Status:	CLOSED WORKSFORME

Alias:	None

Product:	DRI
Classification:	Unclassified
Component:	DRM/Intel (show other bugs)
Version:	unspecified
Hardware:	x86-64 (AMD64) Linux (All)

Importance:	medium normal
Assignee:	Intel GFX Bugs mailing list
QA Contact:	Intel GFX Bugs mailing list

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2014-09-08 05:34 UTC by Chris Cheney
Modified:	2017-03-01 16:48 UTC (History)
CC List:	1 user (show)

See Also:
i915 platform:	HSW
i915 features:	display/DP

Attachments
debug dmesg output (347.01 KB, text/plain) 2014-09-08 05:34 UTC, Chris Cheney	no flags	Details
debug dmesg output - same boot about an hour later (402.51 KB, text/plain) 2014-09-08 06:30 UTC, Chris Cheney	no flags	Details
dmesg for 8b4216f91c7bf8d3459cadf9480116220bd6545e (878.84 KB, text/plain) 2015-02-01 08:13 UTC, Chris Cheney	no flags	Details
dmesg output from 2015-03-21 test (2.09 MB, text/plain) 2015-03-21 21:34 UTC, Chris Cheney	no flags	Details
dmesg output from 2015-04-02 test (1.91 MB, text/plain) 2015-04-03 02:34 UTC, Chris Cheney	no flags	Details
linux 4.4 dmesg debug output (403.13 KB, text/plain) 2016-01-22 04:36 UTC, Chris Cheney	no flags	Details
linux 4.4 dmesg debug output (335.28 KB, text/plain) 2016-01-24 01:37 UTC, Chris Cheney	no flags	Details
Show Obsolete (1) View All

Description Chris Cheney 2014-09-08 05:34:55 UTC

Created attachment 105879 [details]
debug dmesg output

I originally opened Bug 83516 about the issue but the main error at the time besides the backtrace was the "*ERROR* too many voltage retries, give up" which was bisected down to c79057922ed6c2c6df1214e6ab4414fea1b23db2. Afterwards I updated my systems bios again, as a more recent bios came out since I filed that report, and then the previous error went away. However the monitor still does not work and I don't see any obvious problems in the debug dmesg output other than the rather generic:

WARNING: CPU: 0 PID: 1369 at /home/apw/COD/linux/drivers/gpu/drm/i915/intel_dp.c:3649 intel_dp_link_down+0x223/0x260 [i915]()

The time line of the dmesg output was the following:

1. All 3 monitors connected at boot time and system booted to X
2. HDMI monitor hooked up to DisplayPort active adapter did not come on while in X
3. At 191s I switched to the console and the monitor activated and displayed console
4. At 198s I switched back to X and the monitor turned off
5. At 291s I switched back to the console to see if it would work again, but nope.
6. At 328s I switched back to X and the monitor was still off.

I opened this bug since it appears to another but unrelated bug to the previous one. If they should be merged into one bug report that is fine with me.

Comment 1 Chris Cheney 2014-09-08 05:53:42 UTC

Forgot to mention in #1 this dmesg was from the Ubuntu daily build of drm-intel-nightly 201409060350.

Comment 2 Chris Cheney 2014-09-08 06:27:48 UTC

Interestingly I came back to my computer just now and the monitor attached to the DisplayPort active adapter is working at the moment in X. My guess is it is timing related and possibly related to the underlying issue with Bug 83516, the offending commit appears to be timing related as well.

Comment 3 Chris Cheney 2014-09-08 06:30:15 UTC

Created attachment 105880 [details]
debug dmesg output - same boot about an hour later

Comment 4 Chris Cheney 2014-09-13 07:43:49 UTC

I just thought to try forcing the non-working DP->HDMI connection to a lower resolution with xrandr and it worked. Then setting it back to native resolution worked as well. Not sure wtf is going on...

Steps to reproduce:

Run the following:
--
1. xrandr                                - if screen is already working it stops
2. xrandr --output DP1 --mode 1920x1080  - native will not work at this point
3. xrandr --output DP1 --mode 1024x768   - lower resolution works fine
4. xrandr --output DP1 --mode 1920x1080  - now native works fine, wtf?
--

This appears to repeatable ad nauseam. :-\

Comment 5 Chris Cheney 2014-09-13 07:45:27 UTC

Also for whatever reason if the HDMI screen attached to the displayport active adapter is turned off and xrandr is run it will say DP1 is disconnected. I'm pretty sure this didn't use to happen, but I'm not sure if its a driver issue or a newer vbios issue.

Comment 6 Chris Cheney 2014-09-13 19:42:34 UTC

The workaround in #4 consistently works but is far from perfect. Unfortunately any time the displays go to sleep (eg locking the screen or idle too long) or the system is suspended it requires killing X and then restarting it to get it to come back properly.

Comment 7 Chris Cheney 2014-09-28 05:47:29 UTC

Looking at it a bit more it seems to be timing sensitive. If I run the following without a sleep, or a short sleep, between the two xrandr calls it will often not bring the screen back up, but if I up the sleep time to 5 seconds or more it seems to be pretty reliable.

Note the following also works without having to set the lower resolution first as I had previously thought was required.

xrandr --verbose -q -d :0 --output DP1 --off
sleep 5
xrandr --verbose -q -d :0 --output DP1 --auto --right-of HDMI2

Occasionally I'll get an error like the following when running the commands:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  21 (RRSetCrtcConfig)
  Serial number of failed request:  43
  Current serial number in output stream:  43

Comment 8 Chris Cheney 2014-10-11 03:13:15 UTC

I tried out the Mac OS X video driver from 10.9.5 via UniBeast and it works properly for all 3 monitors as well. So both Windows and Mac OS X work fine but Linux does not. If this is somehow due to buggy bios issues I'm a bit surprised that the Mac OS X driver, which was not intended to run on my system. works as well. Is there any way to get the different driver groups inside Intel to share their workarounds for getting DisplayPort working if that is the issue?

Comment 9 Chris Cheney 2014-10-11 21:04:33 UTC

Updated kernel to 3.17.0-994.201410092205 (ea4bec8e96ea8b33b49a7892c1c7f20041a56da6) and still have the same problem and the following backtrace on boot:

[   12.508853] ------------[ cut here ]------------
[   12.508895] WARNING: CPU: 0 PID: 1495 at /home/apw/COD/linux/drivers/gpu/drm/i915/intel_dp.c:3736 intel_dp_link_down+0x223/0x260 [i915]()
[   12.508923] Modules linked in: vmnet(OE) parport_pc vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OE) usblp bnep rfcomm bluetooth joydev hid_logitech_dj usbhid hid mxm_wmi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw rtc_efi mei_me mei lpc_ich shpchp snd_hda_codec_hdmi snd_hda_codec_realtek wmi snd_hda_codec_generic mac_hid tpm_infineon snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm i915 snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq video snd_seq_device snd_timer drm_kms_helper drm snd soundcore ppdev lp parport nls_iso8859_1 igb e1000e psmouse firewire_ohci i2c_algo_bit ahci dca firewire_core ptp libahci crc_itu_t pps_core
[   12.508923]  [last unloaded: vmnet]
[   12.508926] CPU: 0 PID: 1495 Comm: Xorg Tainted: G           OE  3.17.0-994-generic #201410092205
[   12.508927] Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD5H/Z87X-UD5H-CF, BIOS F10 08/21/2014
[   12.508928]  0000000000000e98 ffff8807f13976d8 ffffffff82796b97 0000000000000286
[   12.508930]  0000000000000000 ffff8807f1397718 ffffffff82074a3c ffff8807f1397748
[   12.508931]  ffff8800d7d00000 ffff8800d7d150e0 ffff8800d7df0000 0000000080000002
[   12.508931] Call Trace:
[   12.508938]  [<ffffffff82796b97>] dump_stack+0x46/0x58
[   12.508943]  [<ffffffff82074a3c>] warn_slowpath_common+0x8c/0xc0
[   12.508945]  [<ffffffff82074a8a>] warn_slowpath_null+0x1a/0x20
[   12.508961]  [<ffffffffc032a763>] intel_dp_link_down+0x223/0x260 [i915]
[   12.508975]  [<ffffffffc0331171>] intel_dp_complete_link_train+0x101/0x220 [i915]
[   12.508987]  [<ffffffffc03289d7>] intel_ddi_pre_enable+0x137/0x1b0 [i915]
[   12.508998]  [<ffffffffc0315574>] haswell_crtc_enable+0x134/0x360 [i915]
[   12.509009]  [<ffffffffc0314b77>] __intel_set_mode+0x327/0x490 [i915]
[   12.509020]  [<ffffffffc03176b6>] intel_set_mode+0x16/0x30 [i915]
[   12.509031]  [<ffffffffc03181b6>] intel_crtc_set_config+0x1e6/0x370 [i915]
[   12.509046]  [<ffffffffc0230540>] ? drm_modeset_lock+0x40/0x100 [drm]
[   12.509055]  [<ffffffffc0221fa0>] drm_mode_set_config_internal+0x60/0x100 [drm]
[   12.509061]  [<ffffffffc0289583>] restore_fbdev_mode+0xd3/0x100 [drm_kms_helper]
[   12.509065]  [<ffffffffc028967c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2c/0x50 [drm_kms_helper]
[   12.509069]  [<ffffffffc028ad61>] drm_fb_helper_set_par+0x31/0x80 [drm_kms_helper]
[   12.509072]  [<ffffffffc028acdc>] drm_fb_helper_hotplug_event+0xcc/0x120 [drm_kms_helper]
[   12.509076]  [<ffffffffc028ad79>] drm_fb_helper_set_par+0x49/0x80 [drm_kms_helper]
[   12.509087]  [<ffffffffc03223aa>] intel_fbdev_set_par+0x1a/0x60 [i915]
[   12.509091]  [<ffffffff824118f3>] fb_set_var+0x283/0x3a0
[   12.509094]  [<ffffffff820ab120>] ? check_preempt_wakeup+0x110/0x210
[   12.509096]  [<ffffffff82408734>] fbcon_blank+0x1e4/0x2d0
[   12.509099]  [<ffffffff8249688e>] do_unblank_screen.part.21+0x9e/0x180
[   12.509101]  [<ffffffff824969b8>] do_unblank_screen+0x48/0x80
[   12.509103]  [<ffffffff8248bf15>] complete_change_console+0x65/0xf0
[   12.509105]  [<ffffffff8248d0cc>] vt_ioctl+0x112c/0x11c0
[   12.509107]  [<ffffffff820b3c93>] ? __wake_up+0x53/0x70
[   12.509116]  [<ffffffffc021b1e0>] ? drm_setmaster_ioctl+0xe0/0xe0 [drm]
[   12.509118]  [<ffffffff82480588>] tty_ioctl+0x298/0x8f0
[   12.509121]  [<ffffffff821fbfe5>] do_vfs_ioctl+0x75/0x2c0
[   12.509124]  [<ffffffff821e9f26>] ? vfs_write+0x196/0x1f0
[   12.509128]  [<ffffffff82206535>] ? __fget_light+0x25/0x70
[   12.509129]  [<ffffffff821fc2c1>] SyS_ioctl+0x91/0xb0
[   12.509132]  [<ffffffff827a46ed>] system_call_fastpath+0x1a/0x1f
[   12.509134] ---[ end trace 570811c9b70289e6 ]---

Comment 10 Chris Cheney 2014-11-29 03:33:39 UTC

Using the current Ubuntu drm-intel-nightly build from today using commit 0db9cf7742874ee2c09a35b640c1bb04cb379eb6 I get the following the error instead. The DP connected monitor still doesn't work until I run the xrandr commands mentioned earlier in the bug.

[    4.475561] ------------[ cut here ]------------
[    4.475594] WARNING: CPU: 0 PID: 1481 at /home/apw/COD/linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:125 eb_lookup_vmas.isra.15+0x345/0x3e0 [i915]()
[    4.475595] GPU use of dumb buffer is illegal.
[    4.475596] Modules linked in: bnep rfcomm bluetooth mxm_wmi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lr
w gf128mul glue_helper ablk_helper cryptd serio_raw lpc_ich shpchp 8250_fintek wmi tpm_infineon mac_hid snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_cod
ec snd_hwdep i915 snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi video snd_seq drm_kms_helper snd_seq_device drm snd_timer snd mei_me mei soundcore parport_pc ppdev lp parport nls_iso8859_1 igb psmouse e100
0e firewire_ohci i2c_algo_bit dca firewire_core ahci ptp libahci crc_itu_t pps_core
[    4.475621] CPU: 0 PID: 1481 Comm: Xorg Not tainted 3.18.0-994-generic #201411290205
[    4.475622] Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD5H/Z87X-UD5H-CF, BIOS F10 08/21/2014
[    4.475623]  000000000000007d ffff8807ef40bb88 ffffffff827a5cd7 0000000000000007
[    4.475625]  ffff8807ef40bbd8 ffff8807ef40bbc8 ffffffff82074b0c ffff8807f227eff0
[    4.475626]  ffff8807eed682c0 ffff8807eed681c0 ffff8807ef40bc78 ffff8807f0638400
[    4.475628] Call Trace:
[    4.475636]  [<ffffffff827a5cd7>] dump_stack+0x46/0x58
[    4.475641]  [<ffffffff82074b0c>] warn_slowpath_common+0x8c/0xc0
[    4.475642]  [<ffffffff82074bf6>] warn_slowpath_fmt+0x46/0x50
[    4.475650]  [<ffffffffc04ce605>] eb_lookup_vmas.isra.15+0x345/0x3e0 [i915]
[    4.475659]  [<ffffffffc04cf0e7>] i915_gem_do_execbuffer.isra.23+0x257/0x710 [i915]
[    4.475667]  [<ffffffffc04d0364>] ? i915_gem_execbuffer2+0x84/0x2d0 [i915]
[    4.475675]  [<ffffffffc04d03a6>] i915_gem_execbuffer2+0xc6/0x2d0 [i915]
[    4.475686]  [<ffffffffc03f9e46>] drm_ioctl+0x2e6/0x590 [drm]
[    4.475694]  [<ffffffffc04d02e0>] ? i915_gem_execbuffer+0x440/0x440 [i915]
[    4.475698]  [<ffffffff82202565>] do_vfs_ioctl+0x75/0x2c0
[    4.475700]  [<ffffffff8220cba5>] ? __fget_light+0x25/0x70
[    4.475702]  [<ffffffff82202841>] SyS_ioctl+0x91/0xb0
[    4.475704]  [<ffffffff827b352d>] system_call_fastpath+0x16/0x1b
[    4.475705] ---[ end trace 7a6ac4007f9db969 ]---

Comment 11 Chris Cheney 2015-02-01 08:12:05 UTC

I'm not getting the kernel backtrace any longer with 8b4216f91c7bf8d3459cadf9480116220bd6545e but its still not actually working any better.

If I am reading the dmesg correctly it appears that the driver is flapping DP-1 between "DP-1 on pipe C [CRTC:28]" and NOCRTC eg "[CONNECTOR:40:DP-1] to [NOCRTC]"

This would seem to correlate with what I was seeing with my script sometimes working and sometimes claiming that there was no crtc for the dp connection.

Attaching a new debug dmesg.

Comment 12 Chris Cheney 2015-02-01 08:13:30 UTC

Created attachment 113011 [details]
dmesg for 8b4216f91c7bf8d3459cadf9480116220bd6545e

Comment 13 Chris Cheney 2015-02-01 08:26:41 UTC

I also should note that the script only works while running under MATE, if I try to run under a modern 3d desktop eg Unity it breaks entirely and I can't seem to get my system to work properly again until I disconnect the monitor and reboot. Just disconnecting the monitor leaves X still acting sluggish.

Comment 14 Chris Cheney 2015-03-21 21:33:18 UTC

The most recent build I tried seems to be giving more detailed DP errors I have attached dmesg output from it. It also appears that my workaround no longer works and that the script tells me there is no crtc available for the DP.

It appears to be repeatedly checking status of the connectors, I'm not sure if that is supposed be happening or not.


[    2.020772] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1]
[    2.020774] [drm:intel_dp_detect] [CONNECTOR:40:DP-1]
[    2.021623] [drm:intel_dp_get_dpcd] DPCD: 11 0a 82 01 01 15 01 81 00 01 04 01 0f 00 00
[    2.021626] [drm:intel_dp_print_rates] source rates: 162000,270000,540000,
[    2.021627] [drm:intel_dp_print_rates] sink rates: 162000,270000,
[    2.021628] [drm:intel_dp_print_rates] common rates: 162000,270000,
[    2.023945] [drm:intel_dp_probe_oui] Sink OUI: 000000
[    2.024679] [drm:intel_dp_probe_oui] Branch OUI: 001cf8
[    2.027246] [drm:drm_dp_i2c_do_msg] native defer
[    2.028338] [drm:drm_dp_i2c_do_msg] native defer
[    2.029696] [drm:drm_dp_i2c_do_msg] native defer
[    2.030778] [drm:drm_dp_i2c_do_msg] native defer
[    2.032122] [drm:drm_dp_i2c_do_msg] native defer
[    2.033228] [drm:drm_dp_i2c_do_msg] native defer
[    2.034617] [drm:drm_dp_i2c_do_msg] native defer
[    2.035651] [drm:drm_dp_i2c_do_msg] native defer
[    2.037022] [drm:drm_dp_i2c_do_msg] native defer
[    2.038107] [drm:drm_dp_i2c_do_msg] native defer
[    2.039481] [drm:drm_dp_i2c_do_msg] native defer
[    2.040566] [drm:drm_dp_i2c_do_msg] native defer
[    2.041938] [drm:drm_dp_i2c_do_msg] native defer
[    2.043020] [drm:drm_dp_i2c_do_msg] native defer
[    2.044398] [drm:drm_dp_i2c_do_msg] native defer
[    2.045506] [drm:drm_dp_i2c_do_msg] native defer
[    2.047906] [drm:drm_dp_i2c_do_msg] native defer
[    2.048959] [drm:drm_dp_i2c_do_msg] native defer
[    2.050288] [drm:drm_dp_i2c_do_msg] native defer
[    2.051343] [drm:drm_dp_i2c_do_msg] native defer
[    2.052672] [drm:drm_dp_i2c_do_msg] native defer
[    2.053717] [drm:drm_dp_i2c_do_msg] native defer
[    2.055062] [drm:drm_dp_i2c_do_msg] native defer
[    2.056116] [drm:drm_dp_i2c_do_msg] native defer
[    2.057448] [drm:drm_dp_i2c_do_msg] native defer
[    2.058515] [drm:drm_dp_i2c_do_msg] native defer
[    2.059872] [drm:drm_dp_i2c_do_msg] native defer
[    2.060939] [drm:drm_dp_i2c_do_msg] native defer
[    2.062283] [drm:drm_dp_i2c_do_msg] native defer
[    2.063352] [drm:drm_dp_i2c_do_msg] native defer
[    2.064683] [drm:drm_dp_i2c_do_msg] native defer
[    2.065734] [drm:drm_dp_i2c_do_msg] native defer
[    2.066806] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[    2.066809] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1] status updated from 3 to 1
[    2.066860] [drm:drm_edid_to_eld] ELD monitor IPS234
[    2.066861] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 0, latency present 0 0, video latency 0 0, audio latency 0 0
[    2.066862] [drm:drm_edid_to_eld] ELD size 32, SAD count 1
[    2.066872] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1] probed modes :
[    2.066873] [drm:drm_mode_debug_printmodeline] Modeline 80:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[    2.066893] [drm:drm_mode_debug_printmodeline] Modeline 111:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[    2.066894] [drm:drm_mode_debug_printmodeline] Modeline 82:"1920x1080i" 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
[    2.066895] [drm:drm_mode_debug_printmodeline] Modeline 113:"1920x1080i" 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
[    2.066897] [drm:drm_mode_debug_printmodeline] Modeline 108:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
[    2.066898] [drm:drm_mode_debug_printmodeline] Modeline 105:"1920x1080i" 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15
[    2.066899] [drm:drm_mode_debug_printmodeline] Modeline 91:"1680x1050" 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9
[    2.066900] [drm:drm_mode_debug_printmodeline] Modeline 95:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[    2.066901] [drm:drm_mode_debug_printmodeline] Modeline 96:"1280x960" 60 108000 1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[    2.066902] [drm:drm_mode_debug_printmodeline] Modeline 97:"1152x864" 60 81579 1152 1216 1336 1520 864 865 868 895 0x0 0x6
[    2.066903] [drm:drm_mode_debug_printmodeline] Modeline 86:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[    2.066904] [drm:drm_mode_debug_printmodeline] Modeline 114:"1280x720" 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[    2.066905] [drm:drm_mode_debug_printmodeline] Modeline 110:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[    2.066906] [drm:drm_mode_debug_printmodeline] Modeline 100:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[    2.066908] [drm:drm_mode_debug_printmodeline] Modeline 98:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[    2.066909] [drm:drm_mode_debug_printmodeline] Modeline 106:"720x576" 50 27000 720 732 796 864 576 581 586 625 0x40 0xa
[    2.066910] [drm:drm_mode_debug_printmodeline] Modeline 115:"720x480" 60 27027 720 736 798 858 480 489 495 525 0x40 0xa
[    2.066911] [drm:drm_mode_debug_printmodeline] Modeline 88:"720x480" 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
[    2.066912] [drm:drm_mode_debug_printmodeline] Modeline 99:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa
[    2.066913] [drm:drm_mode_debug_printmodeline] Modeline 104:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa


...

[    2.264380] [drm:intel_crtc_set_config] [CRTC:28] [NOFB]
[    2.264380] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:28], mode_changed=1, fb_changed=0
[    2.264381] [drm:intel_modeset_stage_output_state] [CONNECTOR:40:DP-1] to [NOCRTC]
[    2.264381] [drm:intel_modeset_stage_output_state] [CONNECTOR:40:DP-1] encoder changed, full mode switch

...

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/ has apparently switched to using the following instead for the more recent builds:

git://kernel.ubuntu.com/virgin/linux-stable.git

crack-tip--drm-intel-nightly--2015-03-21

Comment 15 Chris Cheney 2015-03-21 21:34:39 UTC

Created attachment 114509 [details]
dmesg output from 2015-03-21 test

Comment 16 Chris Cheney 2015-03-21 21:43:30 UTC

I also noticed this:

[    1.917224] [drm:intel_dp_init_connector] Adding DP connector on port D

..

[    2.765317] [drm:intel_hpd_irq_handler] digital hpd port D - long
[    2.765317] [drm:intel_hpd_irq_handler] HPD interrupt storm detected on PIN 6
[    2.765348] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long


Perhaps the hpd interrupt storm isn't being ignored effectively to make the port work under Linux?

Comment 17 Jesse Barnes 2015-03-23 16:56:42 UTC

Yeah I guess that's possible, do you see tons of messages like that in the log?  There were two series that affect our aux code posted recently, you could try them and see if they help:

drm/dp: i2c-over-aux short write support

and

drm/dp: Print the number of bytes processed for aux nack

Another thought is that we always need to train at the max link width.  This should force that even if we could potentially go lower:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1141d3..dc02914 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1238,6 +1238,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
        return false;
 
 found:
+       lane_count = max_lane_count;
+
        if (intel_dp->color_range_auto) {
                /*
                 * See:

Comment 18 Chris Cheney 2015-04-03 02:33:24 UTC

Sorry for the slow response, preparing for a move has been getting in my way.

I have attached a new dmesg with output from the patches in comment 17 and drm-intel-nightly git commit 333cf6eed7cae0ee2d6bb1b4c4d421b94f84fc13 "drm-intel-nightly: 2015y-04m-02d-08h-37m-57s UTC integration manifest". Looking back at the git repo Ubuntu uses for their prebuilt test 'drm-intel-nightly' kernels it appears they stopped actually using the drm-intel-nightly tree and switched to something else so this should be quite a bit more up to date than my previous dmesg output.

Comment 19 Chris Cheney 2015-04-03 02:34:25 UTC

Created attachment 114839 [details]
dmesg output from 2015-04-02 test

Comment 20 Chris Cheney 2015-04-03 02:36:17 UTC

I should note that all three heads, including the dp one, seem to come up fine when I switch to console mode instead of X. I'm not sure when that started working though.

Comment 21 Chris Cheney 2015-04-03 02:51:00 UTC

I think I didn't state the previous comment very clearly. In console mode it seems to work consistently but as soon as I switch back to X the dp connected screen stops working, until I switch back to console again. ie it consistently doesn't work under X.

Comment 22 Chris Cheney 2015-04-03 06:06:08 UTC

Going through the dmesg with an untrained eye it looks like it sets up the DP fine and then tears it down about .1s later.

See:

[    2.125767] [drm:intel_crtc_set_config] [CRTC:28] [FB:103] #connectors=1 (x y) (0 0)
[    2.125768] [drm:intel_set_config_compute_mode_changes] inactive crtc, full mode set
[    2.125768] [drm:intel_set_config_compute_mode_changes] modes are different, full mode set
[    2.125770] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0
[    2.125771] [drm:drm_mode_debug_printmodeline] Modeline 102:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[    2.125771] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:28], mode_changed=1, fb_changed=0
[    2.125772] [drm:intel_modeset_stage_output_state] [CONNECTOR:40:DP-1] encoder changed, full mode switch
[    2.125774] [drm:intel_modeset_stage_output_state] [CONNECTOR:33:HDMI-A-1] to [CRTC:20]
[    2.125775] [drm:intel_modeset_stage_output_state] [CONNECTOR:38:HDMI-A-2] to [CRTC:24]
[    2.125776] [drm:intel_modeset_stage_output_state] [CONNECTOR:40:DP-1] to [CRTC:28]
[    2.125776] [drm:intel_modeset_stage_output_state] [ENCODER:39:TMDS-39] crtc changed, full mode switch
[    2.125778] [drm:intel_modeset_stage_output_state] [CRTC:28] enabled, full mode switch
[    2.125779] [drm:intel_modeset_affected_pipes] set mode pipe masks: modeset: 4, prepare: 4, disable: 0
[    2.125781] [drm:connected_sink_compute_bpp] [CONNECTOR:40:DP-1] checking for sink bpp constrains
[    2.125783] [drm:intel_dp_compute_config] DP link computation with max lane count 2 max bw 270000 pixel clock 148500KHz
[    2.125785] [drm:intel_dp_compute_config] DP link bw 0a lane count 2 clock 270000 bpp 24
[    2.125785] [drm:intel_dp_compute_config] DP link bw required 356400 available 432000
[    2.125786] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, dithering: 0
[    2.125786] [drm:intel_dump_pipe_config] [CRTC:28][modeset] config for pipe C
[    2.125787] [drm:intel_dump_pipe_config] cpu_transcoder: C
[    2.125787] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
[    2.125788] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[    2.125788] [drm:intel_dump_pipe_config] dp: 1, gmch_m: 6920601, gmch_n: 8388608, link_m: 288358, link_n: 524288, tu: 64
[    2.125789] [drm:intel_dump_pipe_config] dp: 1, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[    2.125789] [drm:intel_dump_pipe_config] audio: 1, infoframes: 0
[    2.125790] [drm:intel_dump_pipe_config] requested mode:
[    2.125790] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[    2.125791] [drm:intel_dump_pipe_config] adjusted mode:
[    2.125792] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[    2.125792] [drm:intel_dump_crtc_timings] crtc timings: 148500 1920 2008 2052 2200 1080 1084 1089 1125, type: 0x48 flags: 0x5
[    2.125793] [drm:intel_dump_pipe_config] port clock: 270000
[    2.125793] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[    2.125793] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[    2.125794] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[    2.125794] [drm:intel_dump_pipe_config] ips: 0
[    2.125794] [drm:intel_dump_pipe_config] double wide: 0
[    2.127528] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[    2.128753] [drm:intel_dp_start_link_train] clock recovery OK
[    2.130292] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[    2.133852] [drm:intel_dp_complete_link_train] Channel EQ done. DP Training successful
[    2.134390] [drm:intel_audio_codec_enable] ELD on [CONNECTOR:40:DP-1], [ENCODER:39:TMDS-39]
[    2.134391] [drm:hsw_audio_codec_enable] Enable audio codec on pipe C, 32 bytes ELD



Then:

[    2.215356] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1]
[    2.215359] [drm:intel_dp_detect] [CONNECTOR:40:DP-1]
[    2.215363] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1] status updated from 1 to 2
[    2.215366] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1] disconnected

...

[    2.215568] [drm:drm_enable_connectors] connector 40 enabled? no

Comment 23 Chris Cheney 2015-04-03 06:13:42 UTC

I tried running the following xrandr commands again to see what would happen this time:

$ xrandr --verbose -q -d :0 --output DP1 --off
crtc 2: disable

$ xrandr --verbose -q -d :0 --output DP1 --gamma 1.0:1.0:1.0 --auto --right-of HDMI2
screen 0: 5760x1080 1525x286 mm  95.92dpi
crtc 2:    1920x1080   60.0 +3840+0 "DP1"

It displays at least for the moment, but is in some weird very low resolution mode but claims to be 1920x1080, it looks blocky/blurry instead of the way it should.

Comment 24 Chris Cheney 2015-04-03 06:17:42 UTC

Changing the line to force the mode seems to work:

$ xrandr --verbose -q -d :0 --output DP1 --mode 1920x1080 --gamma 1.0:1.0:1.0 --auto --right-of HDMI2
screen 0: 5760x1080 1525x286 mm  95.92dpi
crtc 2:    1920x1080   60.0 +3840+0 "DP1"

If I switch to console and back it stops working until I run those two commands again (off/on with forced resolution). Going into gnome system settings kills the screen output probably for similar reasons since whatever its picking up as the default mode apparently doesn't work properly.

Comment 25 Chris Cheney 2015-04-03 14:07:26 UTC

After a suspend/resume cycle I can no longer get it to work with the xrandr commands, it says the following each time I try to turn if back on:

"xrandr: Need crtc to set gamma on."

Comment 26 Jani Nikula 2016-01-18 13:02:19 UTC

Please try kernel v4.4.

Comment 27 Chris Cheney 2016-01-22 04:35:07 UTC

Attaching dmesg debug output from v4.4.

It seems to work on boot until 'Displays' configuration program is run, which runs xrandr as noted before.

Comment 28 Chris Cheney 2016-01-22 04:36:04 UTC

Created attachment 121200 [details]
linux 4.4 dmesg debug output

Comment 29 Chris Cheney 2016-01-23 08:50:59 UTC

Looking closely at my dmesg output it appears that when xrandr probes (eg running vlc) the driver disables the non-existant (on my system) HDMI-A-3 which is likely using HDMI-D DDC GPIO pins and it ends up disabling my DisplayPort connector. On my system the DisplayPort connecter in the VBT is EFP3 DisplayPort D using the HDMI-D DDC GPIO Pins.

I'm guessing the fix would involve not exporting non-existant devices from the kernel/xorg driver?

My system has physically: 2 HDMI and 1 DP.

--

I didn't have the DP plugged in at the moment when this was run:

$ xrandr -q
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 290mm
   1920x1080     60.00*+  50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     60.02  
   1280x960      60.00  
   1152x864      59.97  
   1280x720      60.00    50.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       60.00    59.94  
HDMI2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 510mm x 290mm
   1920x1080     60.00*+  50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     60.02  
   1280x960      60.00  
   1152x864      59.97  
   1280x720      60.00    50.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       60.00    59.94  
HDMI3 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Comment 30 Chris Cheney 2016-01-24 01:37:51 UTC

Created attachment 121241 [details]
linux 4.4 dmesg debug output

This dmesg output more clearly shows the issue with HDMI-A-3 vs DP-1

Comment 31 Chris Cheney 2016-01-24 03:17:21 UTC

So I was digging around after determining i915 was seeing ports that aren't physically there and found 'video=' so I set 'video=HDMI-A-3:d' which fixed the problem since its no longer trying to stomp it.

I'm guessing the problem is that the i915 driver isn't properly querying VBT for which ports are actually there, eg EFP1,EFP2,EFP3, since there is no indication as far as I can see of any HDMI-A-3 in my VBT.

Comment 32 Dhinakaran Pandiyan 2016-06-23 23:46:07 UTC

Thanks for reporting the bug. Can you try the latest drm-intel-nightly kernel?
I had a HDMI monitor connected via an active DP->HDMI adapter that came up fine with the latest kernel. Also, I did not see the spurious HDMI from xrandr.

Comment 33 Jari Tahvanainen 2017-03-01 15:10:54 UTC

Timeout. Marking as resolved. Please reopen this if problem still persist or create new bug if failure has changed.

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.