Summary: | [DP][MST][SKL] External VGA and DVI monitor not detected after DPMS/second hotplug | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | David Woodhouse <dwmw2> | ||||||||||||||||||||||||
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||||||
Severity: | normal | ||||||||||||||||||||||||||
Priority: | medium | CC: | ernstp, intel-gfx-bugs, jglotzer | ||||||||||||||||||||||||
Version: | XOrg git | ||||||||||||||||||||||||||
Hardware: | Other | ||||||||||||||||||||||||||
OS: | All | ||||||||||||||||||||||||||
Whiteboard: | ReadyForDev | ||||||||||||||||||||||||||
i915 platform: | SKL | i915 features: | display/DP, display/DP MST | ||||||||||||||||||||||||
Attachments: |
|
Description
David Woodhouse
2016-12-16 22:14:58 UTC
Created attachment 128500 [details]
dmesg at boot
Created attachment 128501 [details]
dpms off/on debug
#!/bin/sh -x
dmesg -c
xrandr --verbose
xset dpms force off
dmesg -c
sleep 0.1
xset dpms force on
dmesg -c
xrandr --verbose
dmesg -c
Created attachment 128502 [details]
VGA unplug/replug debug
Created attachment 128503 [details]
undock/redock debug
By undocking and redocking, I get the external monitor to come back to life. Not convinced the big docking connector is really designed to be used every time the screen has blanked though...
Looks like the DP->VGA adaptor NAKs the DPCD SINK_COUNT read during detection while it's in low power state. At the same time it correctly returns the DPCD receiver cap registers. Could you try the following: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index db75bb9..e8673ba 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4099,6 +4099,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp) uint8_t *dpcd = intel_dp->dpcd; uint8_t type; + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + if (!intel_dp_get_dpcd(intel_dp)) return connector_status_disconnected; That appears to fix it; thanks. Tested-by: David Woodhouse <dwmw2@infradead.org> Created attachment 128571 [details] enable DP AUX debug (In reply to David Woodhouse from comment #6) > That appears to fix it; thanks. > > Tested-by: David Woodhouse <dwmw2@infradead.org> Thanks for testing. We probably want to re-enable D3 after handling the HPD, so we'll follow up with a proper fix with that included. Could you still try the script in comment 2 with the attached patches (w/o the change in comment 5) booting with drm.debug=0x8e? In case the problem goes away with these 3 patches then in addition the log with only 0001-drm-dp-add-DPCD-AUX-logging.patch applied would be interesting. Created attachment 128612 [details]
XXX wrong kernel
Still based on the same drm-intel-nightly tree at commit 5415795ad73, with all three patches applied. Same script, except I've got a second DisplayPort monitor plugged in as well as the VGA one.
Created attachment 128616 [details]
script output with three patches
With only the VGA monitor, and with the correct kernel. With all three patches, the monitor comes back to life as expected.
Created attachment 128617 [details]
script output with only debugging patch
With only the first (debugging) patch. As expected, the monitor doesn't wake up.
(In reply to David Woodhouse from comment #10) > Created attachment 128617 [details] > script output with only debugging patch > > With only the first (debugging) patch. As expected, the monitor doesn't wake > up. Thanks, so the spurious HPD IRQ from the adaptor is gone with patch 3. That IRQ could've been the marker of the odd state the adaptor was after xset dpms off: reading the DPCD receiver cap and SINK_COUNT registers work just fine but reading DP_DOWNSTREAM_PORT_0 regs will result in AUX defers. Could you provide one more log, with the same setup, the 3 patches applied and the following script. It'd show if AUX accesses in D3 still cause a problem with these changes: dmesg -c xrandr --verbose xset dpms force off dmesg -c sleep 0.1 xrandr --verbose dmesg -c sleep 0.1 xset dpms force on dmesg -c xrandr --verbose dmesg -c Sure. That'll take a little while because I've plugged the DP monitor in now and it's going to crash hard when I unplug it. I'll file that as a separate bug once I've worked out a serial or USB debug console. Created attachment 128621 [details] as requested in comment 11 (In reply to David Woodhouse from comment #12) > Sure. That'll take a little while because I've plugged the DP monitor in now > and it's going to crash hard when I unplug it. I'll file that as a separate > bug once I've worked out a serial or USB debug console. Ok, that's a DP/MST output, likely a separate issue. (In reply to David Woodhouse from comment #13) > Created attachment 128621 [details] > as requested in comment 11 Arg, this didn't do what I expected, xrandr --verbose woke up the display implicitly before reading the connector info. Thanks for your time we'll work on a fix based on all this info. For reference the following would probably do what I wanted (with same 3 patches and CONFIG_DRM_DP_AUX_CHARDEV=y): devn=/dev/$(basename /sys/class/drm/card0-DP-2/drm_dp_aux?) dmesg -c xset dpms force off sleep 2 dmesg -c echo -ne '\x2' | dd of=$devn bs=1 seek=$(( 0x600 )) count=1 dd if=$devn bs=1 skip=$(( 0x600 )) count=1 | od -tx1 dd if=$devn bs=1 skip=$(( 0x0 )) count=16 | od -tx1 dd if=$devn bs=1 skip=$(( 0x200 )) count=1 | od -tx1 dd if=$devn bs=1 skip=$(( 0x80 )) count=1 | od -tx1 dd if=$devn bs=1 skip=$(( 0x80 )) count=16 | od -tx1 dd if=$devn bs=1 skip=$(( 0x600 )) count=1 | od -tx1 sleep 2 dmesg -c I had the exact same issue (cpuinfo Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz HP Elite 15" laptop) and a drm-intel-nightly kernel with the patch in attachment 3 [details] [review] has completely resolved the issue for me over many cycles of operation. (In reply to John Glotzer from comment #15) > I had the exact same issue (cpuinfo Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz > HP Elite 15" laptop) and a drm-intel-nightly kernel with the patch in > attachment 3 [details] [review] [review] has completely resolved the issue for me > over many cycles of operation. Your attachment reference is bogus, please update. Regarding my previous comment - I meant to say that from attachment 128571 [details] in comment 7 .... I used only patch 3 which is: From ae8032dc0eb3bbda951baf898ab3996393da82d7 Mon Sep 17 00:00:00 2001 From: Imre Deak <imre.deak@intel.com> Date: Tue, 20 Dec 2016 00:36:27 +0200 Subject: [PATCH 3/3] drm/i915: Put DP sink to D3 before turning off port And patched that into the drm-intel-nightly kernel with good results over the past two weeks and many cycles of operation. Thanks; bugzilla recognizes certain patterns and turns them into links, just this time it shouldn't have... Is commit e393d0d6c125 relevant to this? Or does this still need fixing upstream? (In reply to David Woodhouse from comment #19) > Is commit e393d0d6c125 relevant to this? Or does this still need fixing > upstream? The above commit fixes an LSPCON (DP->HDMI adaptor) issue, so it's not relevant to this. This bug still needs fixing in upstream, I haven't got around doing it yet. We are facing the same problem using the following configuration: We have a SKL skull with a Mini DP to DP dongle, having 2 1080 monitors, and one of them is connected through DP - VGA dongle. The Direct connection(MST to DP monitor) is recovering after hotplug event. but the one with the VGA dongle is not, loosing video signal y both monitors. Attaching DMESG ====================================== Graphic stack ====================================== ====================================== Software ====================================== kernel version : 4.12.0-rc3-drm-tip-ww22-commit-187376e+ architecture : x86_64 os version : Ubuntu 17.04 os codename : zesty kernel driver : i915 bios revision : 5.6 bios release date : 09/29/2016 ====================================== Graphic drivers ====================================== modesetting : modesetting_drv.so xorg-xserver : 1.19.3 libdrm : 2.4.81 vaapi (intel-driver) : Intel i965 driver for Intel(R) Skylake - 1.7.3 cairo : 1.14.8 xserver : X.Org X Server 1.19.99.1 intel-gpu-tools (tag) : intel-gpu-tools-1.18-211-g00ce341b intel-gpu-tools (commit) : 00ce341b ====================================== Hardware ====================================== platform : SKL Canyon motherboard id : NUC6i7KYB form factor : Desktop cpu family : Core i7 cpu family id : 6 cpu information : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz gpu card : Intel Corporation Iris Pro Graphics 580 (rev 09) (prog-if 00 [VGA controller]) memory ram : 31.31 GB max memory ram : 32 GB cpu thread : 8 cpu core : 4 cpu model : 94 cpu stepping : 3 socket : Other signature : Type 0, Family 6, Model 94, Stepping 3 hard drive : 223GiB (240GB) current cd clock frequency : 337500 kHz maximum cd clock frequency : 675000 kHz displays connected : DP-7 ====================================== Firmware ====================================== dmc fw loaded : yes dmc version : 1.26 guc fw loaded : NONE guc version wanted : 0.0 guc version found : 0.0 ====================================== kernel parameters ====================================== quiet splash fastboot drm.debug=0xe I put by mistake graphic driver as modesetting, should be xf86-video intel driver in configuration part Created attachment 131814 [details]
dmesg
Seems that the problem is present witn DVI dongle as well, same hardware and software configuration Good afternoon, We tried to replicate using the patches attached, but this ones seems to be already invalid with the latest drm-tip https://cgit.freedesktop.org/drm-tip/ So we'll wait for new versions of those to be upstream so we can test this bug again. Commit info: commit ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest Thank you. Possibly related https://patchwork.freedesktop.org/patch/184991/ First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug. Created attachment 138624 [details]
dmesg-hotplug-vga-dp
Hello, I can't reproduce this issue anymore neither with DVI nor VGA. Closing issue.
======================================
Software
======================================
kernel version : 4.16.0
hostname : gfx-desktop
architecture : x86_64
os version : Ubuntu 17.10
os codename : artful
kernel driver : i915
bios revision : 5.6
bios release date : 08/31/2017
hardware acceleration : disabled
swap partition : enabled on (/dev/nvme0n1p2)
======================================
Hardware
======================================
platform : Skylake Canyon
motherboard id : NUC6i7KYB
form factor : Desktop
cpu family : Core i7
cpu family id : 6
cpu information : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz
gpu card : Intel Corporation Iris Pro Graphics 580 (rev 09) (prog-if 00 [VGA controller])
memory ram : 31.31 GB
max memory ram : 32 GB
display resolution : 3520x1080
cpu thread : 8
cpu core : 4
cpu model : 94
cpu stepping : 3
socket : Other
signature : Type 0, Family 6, Model 94, Stepping 3
current cd clock frequency : 337500 kHz
maximum cd clock frequency : 675000 kHz
displays connected : DP-1 DP-3
======================================
Firmware
======================================
dmc fw loaded : yes
dmc version : 1.27
guc fw loaded : fetch NONE, load NONE
guc version wanted : wanted 9.33, found 0.0
guc version found : wanted 9.33, found 0.0
======================================
kernel parameters
======================================
quiet splash drm.debug=14
|
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.