Bug 98912

Summary: [SKL] LSPCON: ext. HDMI hotplug not working on i7-6700HQ laptop
Product: DRI Reporter: raptorteak
Component: DRM/IntelAssignee: Imre Deak <imre.deak>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs, ville.syrjala
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: SKL i915 features: display/HDMI, display/LSPCON
Attachments:
Description Flags
dmesg
none
xrandr
none
dmesg-drm-tip
none
dmesg-drm-tip-patched
none
Set short HPD signaling
none
dmesg_2017_02_22
none
dmesg_patch_no_longer_working none

Description raptorteak 2016-11-30 14:18:06 UTC
Created attachment 128283 [details]
dmesg

Laptop : Inspiron 15 Gaming 7566
Distro : Xubuntu 16.04
CPU : Intel i7-6700HQ + HD 530
Additional GPU : Nvidia GeForce GTX 960M

What happens : The only way to have an external monitor recognized via HDMI is to have it plugged at boot. Attempting to hotplug an HDMI monitor later on always fails.

Reproduce rate : every time. Tested on kernels 4.4 and 4.9-rc6.

dmesg note : Kernel 4.9-rc6, without nouveau. The PC boots with the HDMI monitor plugged in (working), and at ~70s I unplug/replug it (not working anymore).

xrandr note : xrandr --verbose while the monitor was still plugged in and functional. Hotplugging results in only eDP1 being recognized.

Additional notes : Tried with and without nouveau. Both result in the same behaviour.
Comment 1 raptorteak 2016-11-30 14:19:18 UTC
Created attachment 128284 [details]
xrandr

xrandr --verbose
Comment 2 Imre Deak 2016-11-30 14:47:30 UTC
EDID read failed. Could you check if EDID is available via any other i2c gmbus:
# modprobe i2c-dev
# i2cdump -y <bus_num> 0x40 i

You can get the available gmbus instances with:
# i2cdetect -l
Comment 3 Imre Deak 2016-11-30 15:13:23 UTC
(In reply to Imre Deak from comment #2)
> EDID read failed. Could you check if EDID is available via any other i2c
> gmbus:
> # modprobe i2c-dev
> # i2cdump -y <bus_num> 0x40 i

Sorry wong address, with the correct one:

# i2cdump -y <bus_num> 0x50 i

> 
> You can get the available gmbus instances with:
> # i2cdetect -l
Comment 4 raptorteak 2016-11-30 15:16:27 UTC
$ sudo i2cdetect -l
i2c-3	i2c       	DPDDC-A                         	I2C adapter
i2c-1	i2c       	i915 gmbus dpb                  	I2C adapter
i2c-6	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter
i2c-4	i2c       	DPDDC-B                         	I2C adapter
i2c-2	i2c       	i915 gmbus dpd                  	I2C adapter
i2c-0	i2c       	i915 gmbus dpc                  	I2C adapter
i2c-5	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter

$ sudo i2cdump -y 0 0x50 i
Error: Block read failed, return code -1

$ sudo i2cdump -y 1 0x50 i
Error: Block read failed, return code -1

$ sudo i2cdump -y 2 0x50 i
Error: Block read failed, return code -1


I ran these commands while the external monitor was plugged in and functional (from boot). Should I run them with the monitor hotplugged and not working ?
Comment 5 Imre Deak 2016-11-30 15:44:10 UTC
(In reply to raptorteak from comment #4)

I'm guessing that you have an LSPCON DP->HDMI adaptor on the board and your kernel missing the support for it. You could check with:

# i2cdump -y 4 0x40 i

If that succeeds (should return the adaptor ID), could you try the drm-tip branch from:
git://anongit.freedesktop.org/drm-tip

That includes LSPCON support.
Comment 6 raptorteak 2016-11-30 17:16:45 UTC
Created attachment 128290 [details]
dmesg-drm-tip

HDMI unplug at ~ 48s.
HDMI replug at ~ 66s.
Comment 7 raptorteak 2016-11-30 17:17:39 UTC
$ sudo i2cdump -y 4 0x40 i
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04    DP-HDMI ADAPTOR?
10: a8 00 1c f8 50 53 31 37 35 30 b0 00 00 78 0f 00    ?.??PS1750?..x?.
20: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00    ..?.............
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ??..............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Looks like you are right about the adapter. However, drm-tip didn't do the trick :< . Unless there is a specific config to enable ?

Above is a newer dmesg from the drm-tip run.
Comment 8 Imre Deak 2016-11-30 18:02:37 UTC
(In reply to raptorteak from comment #7)
> $ sudo i2cdump -y 4 0x40 i
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04    DP-HDMI ADAPTOR?
> 10: a8 00 1c f8 50 53 31 37 35 30 b0 00 00 78 0f 00    ?.??PS1750?..x?.
> 20: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00    ..?.............
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 40: 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ??..............
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 
> Looks like you are right about the adapter. However, drm-tip didn't do the
> trick :< . Unless there is a specific config to enable ?
> 
> Above is a newer dmesg from the drm-tip run.

Thanks, LSPCON is enabled now and the monitor is detected during bootup, but after replug the adaptor's AUX channel is down for some reason, so detection will fail. One possibility is that the adaptor switches to LS mode during unplug and we have to switch back to PCON mode. Could you get the same i2cdump as above after replugging and try the following patch:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9dfbde4..96809cf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4101,9 +4101,13 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
+	struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 	uint8_t *dpcd = intel_dp->dpcd;
 	uint8_t type;
 
+	if (lspcon->active)
+		lspcon_resume(lspcon);
+
 	if (!intel_dp_get_dpcd(intel_dp))
 		return connector_status_disconnected;
Comment 9 raptorteak 2016-12-01 08:56:17 UTC
Awesome, that did it. I can now unplug/replug and the new monitor is always detected (and usable). Works like a charm overall.

The i2cdump remains exactly the same, although I'm not quite sure when you wanted me to do it (before/after patch?).

Cheers!
Comment 10 Imre Deak 2016-12-01 09:12:02 UTC
(In reply to raptorteak from comment #9)
> Awesome, that did it. I can now unplug/replug and the new monitor is always
> detected (and usable). Works like a charm overall.
> 
> The i2cdump remains exactly the same, although I'm not quite sure when you
> wanted me to do it (before/after patch?).

Great, thanks for trying it! Sorry, I meant with drm-tip, before the patch and after unplug/replug, to see if the adaptor really did switch to LS mode on its own as we suspected (offset 0x40 tells that). But it'd would be enough if you could still provide a dmesg with the patch including the unplug/replug event, that would also show what's going on.

Thanks!

> 
> Cheers!
Comment 11 raptorteak 2016-12-01 09:19:10 UTC
Created attachment 128296 [details]
dmesg-drm-tip-patched

Unplug ~106s
Replug ~119s
Comment 12 Imre Deak 2016-12-01 09:46:38 UTC
(In reply to raptorteak from comment #11)
> Created attachment 128296 [details]
> dmesg-drm-tip-patched
> 
> Unplug ~106s
> Replug ~119s

Ok, looks like it's changing to LS mode on its own. It's somewhat surprising, perhaps done for power saving. I'll follow up with a patch with a fix, we can close the bug once that gets merged. Thanks for your help!
Comment 13 Imre Deak 2017-02-21 17:28:35 UTC
Created attachment 129802 [details] [review]
Set short HPD signaling

Could you give a try if the attached patch on top of drm-tip also fixes the problem? That is without the change in comment 8.
Comment 14 raptorteak 2017-02-22 14:05:01 UTC
Created attachment 129827 [details]
dmesg_2017_02_22
Comment 15 raptorteak 2017-02-22 14:05:20 UTC
Hey Imre,

I'm afraid this doesn't work. Here's the dmesg with drm.debug=0xe.
As usual, computer booted with HDMI plugged in, unplug at ~26s, replug at ~36s.
Comment 16 Imre Deak 2017-02-22 14:27:12 UTC
(In reply to raptorteak from comment #15)
> Hey Imre,
> 
> I'm afraid this doesn't work. Here's the dmesg with drm.debug=0xe.
> As usual, computer booted with HDMI plugged in, unplug at ~26s, replug at
> ~36s.

Thanks. Ok, I tried this based on Ville's earlier idea to switch from long to short HPD pulses. That is how normally branch devices work and that is how the MegaChips LSPCON adaptor works too (although that one uses short pulses regardless of the branch control HPD flag value). In any case your LSPCON adaptor rejects the setting of this flag with an AUX NAK, so my bet is that it doesn't support this.

Based on the above my solution would be still the change in comment 8, I'll send a patch with that.
Comment 17 raptorteak 2017-02-23 14:44:36 UTC
Created attachment 129873 [details]
dmesg_patch_no_longer_working

Just wanted to say that your current patch (V2) does no longer work with current drm-tip.

The process goes further than unpatched since I can see EDID negotiation in dmesg but sadly the power seems to be turned off anyway, and the screen stays in "no signal" mode.
Comment 18 raptorteak 2017-02-23 16:08:15 UTC
Wooops, nevermind, It does work perfectly. I was just surprised that xfce didn't show a popup that something was hotplugged, but going into the display settings I can enable the monitor and it works as expected. Sorry, false alert.
Comment 19 Imre Deak 2017-02-23 16:19:23 UTC
(In reply to raptorteak from comment #18)
> Wooops, nevermind, It does work perfectly. I was just surprised that xfce
> didn't show a popup that something was hotplugged, but going into the
> display settings I can enable the monitor and it works as expected. Sorry,
> false alert.

Right. I did see in your log the change from LS to PCON mode after replug as expected and then detection succeeding and setting the connector state to connected. After that there was just no modeset from userspace, as you would expect after a disconnected->connected uevent. But it looks like you figured the reason for that.
Comment 20 Ricardo 2017-02-24 18:25:07 UTC
Imre what is the next step look like the patch works, should I place this bug as resolved?

And once integrated and verified we can close it?
Comment 21 Imre Deak 2017-02-27 12:34:05 UTC
(In reply to Ricardo from comment #20)
> Imre what is the next step look like the patch works, should I place this
> bug as resolved?

Yes, the patch is merged now. I set this now to resolved.

> 
> And once integrated and verified we can close it?

Yes, can be closed once the reporter has verified it.
Comment 22 raptorteak 2017-03-06 14:50:11 UTC
Can confirm the bug is fixed using drm-tip from 2017/03/04
Comment 23 Jani Nikula 2017-03-07 16:17:58 UTC
(In reply to raptorteak from comment #22)
> Can confirm the bug is fixed using drm-tip from 2017/03/04

Thanks for the follow-up!

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.