Bug 98912

Created attachment 128284 [details]
xrandr

xrandr --verbose

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

(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

$ 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 ?

(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.

Created attachment 128290 [details]
dmesg-drm-tip

HDMI unplug at ~ 48s.
HDMI replug at ~ 66s.

$ 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.

(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;

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!

(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!

Created attachment 128296 [details]
dmesg-drm-tip-patched

Unplug ~106s
Replug ~119s

(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!

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.

Created attachment 129827 [details]
dmesg_2017_02_22

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.

(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.

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.

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.

(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.

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?

(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.

Can confirm the bug is fixed using drm-tip from 2017/03/04

(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!