Bug 105601 - DisplayPort does not work with HDMI adapter on Ivy Bridge
Summary: DisplayPort does not work with HDMI adapter on Ivy Bridge
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: low normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-19 12:59 UTC by Maxim
Modified: 2018-10-19 14:54 UTC (History)
1 user (show)

See Also:
i915 platform: IVB
i915 features: display/DP MST


Attachments
/sys/kernel/debug/dri/0/i915_display_info (5.17 KB, text/plain)
2018-03-19 12:59 UTC, Maxim
no flags Details
dmesg (56.18 KB, text/plain)
2018-03-19 13:00 UTC, Maxim
no flags Details
dmesg with 10kHz patch (250.41 KB, text/x-log)
2018-03-20 20:30 UTC, Maxim
no flags Details
new dmesg (250.41 KB, text/plain)
2018-04-09 08:15 UTC, Maxim
no flags Details
dmesg after flicker (37.62 KB, text/plain)
2018-04-10 10:27 UTC, Maxim
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim 2018-03-19 12:59:12 UTC
Created attachment 138193 [details]
/sys/kernel/debug/dri/0/i915_display_info

I have Lenovo X1 Carbon laptop from 2014 with the following CPU:

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz

lspci reports GPU as

VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

I'm on Gentoo Linux with kernel 4.15.9-gentoo, xorg-server 1.19.5, libdrm 2.4.91 and mesa 18.0.0_rc4. I'm using modesetting driver without xf86-video-intel.

As my laptop has only mini displayport output, I'm trying to use DP-to-HDMI/VGA/DVI converter I got from AliExpress. Sometimes when I plug in the converter and enable the monitor with xrandr it works fine, but most of the time I see the output in xrandr, but when I enable it, monitor does not show anything.

I have this in dmesg:

[15:47] i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
[  +0,000004]   [00] BAD  00 ff ff ff ff ff ff 00 09 d1 bd 78 45 54 00 00
[  +0,000001]   [00] BAD  0b 17 01 03 80 30 1b 78 2e 9a d5 a3 59 55 9f 27
[  +0,000001]   [00] BAD  0c 50 54 21 08 00 61 c0 81 00 81 c0 81 40 81 80
[  +0,000001]   [00] BAD  a9 c0 b3 00 d1 c0 02 3a 80 18 71 38 2d 40 58 2c
[  +0,000001]   [00] BAD  45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 53 33 44
[  +0,000001]   [00] BAD  30 35 38 34 30 53 4c 30 0a 20 00 00 00 fd 00 32
[  +0,000001]   [00] BAD  4c 1e 53 11 00 0a 20 20 20 20 20 20 00 01 ff ff
[  +0,000001]   [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0,108525] i2c i2c-4: sendbytes: NAK bailout.
[  +9,914962] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode adaptor ID 44
[  +0,261571] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode adaptor ID 44

I googled and found bug 92685 and tried kernel patch from there (https://patchwork.freedesktop.org/patch/195306/), but it did not change anything for me.

Attaching i915_display_info and full dmesg, but without drm.debug=0xe yet.
Comment 1 Maxim 2018-03-19 13:00:47 UTC
Created attachment 138194 [details]
dmesg
Comment 2 Ville Syrjala 2018-03-20 18:47:53 UTC
(In reply to Maxim from comment #0)
> Created attachment 138193 [details]
> /sys/kernel/debug/dri/0/i915_display_info
> 
> I have Lenovo X1 Carbon laptop from 2014 with the following CPU:
> 
> Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz

I have a similar carbon and no real issues with any DP++ dongle I've tested.

> [15:47] i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
> [  +0,000004]   [00] BAD  00 ff ff ff ff ff ff 00 09 d1 bd 78 45 54 00 00
> [  +0,000001]   [00] BAD  0b 17 01 03 80 30 1b 78 2e 9a d5 a3 59 55 9f 27
> [  +0,000001]   [00] BAD  0c 50 54 21 08 00 61 c0 81 00 81 c0 81 40 81 80
> [  +0,000001]   [00] BAD  a9 c0 b3 00 d1 c0 02 3a 80 18 71 38 2d 40 58 2c
> [  +0,000001]   [00] BAD  45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 53 33 44
> [  +0,000001]   [00] BAD  30 35 38 34 30 53 4c 30 0a 20 00 00 00 fd 00 32
> [  +0,000001]   [00] BAD  4c 1e 53 11 00 0a 20 20 20 20 20 20 00 01 ff ff
> [  +0,000001]   [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [  +0,108525] i2c i2c-4: sendbytes: NAK bailout.

So it failed even with bit banging :(

> [  +9,914962] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode
> adaptor ID 44
> [  +0,261571] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode
> adaptor ID 44

And the dongle itself is returning garbage when we try to access its registers, so the problem is not limited to the ddc passthrough.

One thing you may want to try is slow down the i2c bus further. We use 100kHz by default, and you may want to try something like 10kHz instead.

--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -127,7 +127,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
 
 /* Intel GPIO access functions */
 
-#define I2C_RISEFALL_TIME 10
+#define I2C_RISEFALL_TIME 100
Comment 3 Maxim 2018-03-20 20:30:33 UTC
Created attachment 138229 [details]
dmesg with 10kHz patch

Hi. I tried the patch you gave me and it seems to work, but I can't be sure yet.

I tried disconnecting adapter from laptop and HDMI from adapter in different orders and each time I'm able to enable HDMI output to my TV. I'll check this with the monitor at my work on the next week.

I've also enabled drm.debug=0xe and noticed some errors and timeouts in dmesg. Attaching it just in case.
Comment 4 Maxim 2018-03-27 08:09:17 UTC
Hi again. Unfortunately, I still have issues with this. I have image on the monitor, but it goes black every couple of seconds or so for a second, thus impossible to work with. I have such lines in dmesg:

[266394.619490] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.622024] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.624561] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.627101] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.629638] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.632165] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.634703] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.637240] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.637254] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110
[266394.637266] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:72:DP-1] disconnected

Can this be fixed or this adapter is impossible to work with?
Comment 5 Ville Syrjala 2018-03-27 09:38:26 UTC
(In reply to Maxim from comment #4)
> Hi again. Unfortunately, I still have issues with this. I have image on the
> monitor, but it goes black every couple of seconds or so for a second, thus
> impossible to work with. I have such lines in dmesg:
> 
> [266394.619490] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.622024] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.624561] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.627101] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.629638] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.632165] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.634703] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.637240] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.637254] [drm:drm_dp_dpcd_access] Too many retries, giving up. First
> error: -110
> [266394.637266] [drm:drm_helper_probe_single_connector_modes]
> [CONNECTOR:72:DP-1] disconnected

Those aren't directly related to the blinking. These are in fact normal messages one would expect during hotplug processing. However they may be a symptom of the dongle failing somehow and wiggling the hotplug line.

> 
> Can this be fixed or this adapter is impossible to work with?

Can you do:

dmesg -C
wait until the display blink has happened a couple of times
dmesg

and attach the log from dmesg.
Comment 6 Jani Saarinen 2018-03-29 07:10:29 UTC
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.
Comment 7 Maxim 2018-04-09 08:15:58 UTC
Created attachment 138693 [details]
new dmesg

Sadly, the problem continues. I came to work once again and tried to connect my monitor, but this time it won't show the image at all. xrandr sees the monitor and can set mode, but nothing happens after it. Judging by dmesg, kernel recognizes monitor, as it prints its model. What can be wrong now? Attaching dmesg after reboot just in case.
Comment 8 Maxim 2018-04-09 11:50:06 UTC
(In reply to Maxim from comment #7)
> Created attachment 138693 [details]
> new dmesg
> 
> Sadly, the problem continues. I came to work once again and tried to connect
> my monitor, but this time it won't show the image at all. xrandr sees the
> monitor and can set mode, but nothing happens after it. Judging by dmesg,
> kernel recognizes monitor, as it prints its model. What can be wrong now?
> Attaching dmesg after reboot just in case.

Actually, ignore that. It seems that I forgot to switch input on monitor... Sorry :)
Comment 9 Jani Saarinen 2018-04-09 12:50:13 UTC
So solved or still issue?
Comment 10 Maxim 2018-04-10 10:27:25 UTC
Created attachment 138723 [details]
dmesg after flicker

(In reply to Ville Syrjala from comment #5)
> Can you do:
> 
> dmesg -C
> wait until the display blink has happened a couple of times
> dmesg
> 
> and attach the log from dmesg.

Okay, so I did as you said. Here's dmesg right after display went black two times.
Comment 11 Ville Syrjala 2018-04-19 16:30:32 UTC
(In reply to Maxim from comment #10)
> Created attachment 138723 [details]
> dmesg after flicker
> 
> (In reply to Ville Syrjala from comment #5)
> > Can you do:
> > 
> > dmesg -C
> > wait until the display blink has happened a couple of times
> > dmesg
> > 
> > and attach the log from dmesg.
> 
> Okay, so I did as you said. Here's dmesg right after display went black two
> times.

Nothing particularly interesting in the log. There is a normal looking disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly the display was just blanked for that period of time?). Also a ton of some ASLE junk but presumably that should be harmless.

Given the evidence we have I'd lean towards the DP++ dongle simply being garbage.
Comment 12 Maxim 2018-04-20 08:10:00 UTC
(In reply to Ville Syrjala from comment #11)
> (In reply to Maxim from comment #10)
> 
> Nothing particularly interesting in the log. There is a normal looking
> disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly
> the display was just blanked for that period of time?). Also a ton of some
> ASLE junk but presumably that should be harmless.
> 
> Given the evidence we have I'd lean towards the DP++ dongle simply being
> garbage.

Okay, I'm OK with that, as long as it works with 10kHz patch :) Are you going to commit it or at least make configurable?
Comment 13 Jani Saarinen 2018-04-27 12:00:04 UTC
Ville, what was next step, is this invalid issue?
Comment 14 Ville Syrjala 2018-04-27 13:30:13 UTC
(In reply to Maxim from comment #12)
> (In reply to Ville Syrjala from comment #11)
> > (In reply to Maxim from comment #10)
> > 
> > Nothing particularly interesting in the log. There is a normal looking
> > disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly
> > the display was just blanked for that period of time?). Also a ton of some
> > ASLE junk but presumably that should be harmless.
> > 
> > Given the evidence we have I'd lean towards the DP++ dongle simply being
> > garbage.
> 
> Okay, I'm OK with that, as long as it works with 10kHz patch :) Are you
> going to commit it or at least make configurable?

We definitely don't want to put that patch in as is since it'll slow down things for everyone. Making it configurable is an option I suppose. Possibly a better option would be to introduce some kind of fallback mechanism where we try to reduce the i2c bus speed when encountering errors. We might want something like that for DDC/CI as well. Or at least I have one monitor here where the DDC/CI isn't happy with the 100KHz speed either.
Comment 15 Lakshmi 2018-10-19 14:54:55 UTC
Reducing the priority to low based on the impact and the workaround.


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.