Bug 112072 - DisplayPort over USB-Type C Connector Not Recognised on Intel NUC8i5BEK (Gen 9, CoffeeLake)
Summary: DisplayPort over USB-Type C Connector Not Recognised on Intel NUC8i5BEK (Gen ...
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-20 12:52 UTC by Geoffrey Allott
Modified: 2019-11-29 19:42 UTC (History)
1 user (show)

See Also:
i915 platform: CFL
i915 features: display/Other


Attachments

Description Geoffrey Allott 2019-10-20 12:52:53 UTC
I am running linux kernel 5.3.1 on an Intel NUC8i5BEK which has CoffeeLake graphics (Intel® Iris® Plus Graphics 655).

The device has two graphics output ports, 1 HDMI and 1 USB Type-C. The kernel reports 3 connectors; port A appears to be for embedded DisplayPort which is reported disconnected (there is a note "Haswell uses DDI functions to detect digital outputs. On SKL pre-D0 the strap isn't connected, so we assume it's there.").

I've connected an ASUS ROG PG278Q Monitor to the USB Type-C port using a Type-C to DisplayPort cable, but no video modes are reported except for the default VGA ones, meaning I'm stuck at a resolution of 1024x768. (The monitor supports 2560x1440@144). The video output does work, though.

I have noticed that the function `bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)` will always return `false` for this particular GPU (which is GEN 9).

In `static int intel_dp_get_modes(struct drm_connector *connector)` for DP-2 (the only connected connector) there is no EDID detected, it is not eDP and there is no fixed mode; so get_modes adds no modes.

I should note that this problem occurs both on my custom kernel and on the latest Arch Linux ISO and the latest Ubuntu ISO. The Intel UEFI-BIOS recognises the monitor's native resolution just fine.

Here's my kernel config:
https://pastebin.com/hStMFVfE

Here's a kernel log with drm logging enabled:
https://pastebin.com/VNhZGJPu
Comment 1 Geoffrey Allott 2019-10-20 19:22:11 UTC
Update: looks like `intel_dp_get_edid` ultimately calls `intel_dp_aux_xfer` which gets "native defer, I2C Nack" repeatedly when trying to get the edid. This returns a -EREMOTEIO and so the edid remains NULL.
Comment 2 Lakshmi 2019-10-21 06:17:30 UTC
(In reply to Geoffrey Allott from comment #0)
> I am running linux kernel 5.3.1 on an Intel NUC8i5BEK which has CoffeeLake
> graphics (Intel® Iris® Plus Graphics 655).
> 
> The device has two graphics output ports, 1 HDMI and 1 USB Type-C. The
> kernel reports 3 connectors; port A appears to be for embedded DisplayPort
> which is reported disconnected (there is a note "Haswell uses DDI functions
> to detect digital outputs. On SKL pre-D0 the strap isn't connected, so we
> assume it's there.").
>
Even though it's reported as disconnected, edp still working?
 
> I've connected an ASUS ROG PG278Q Monitor to the USB Type-C port using a
> Type-C to DisplayPort cable, but no video modes are reported except for the
> default VGA ones, meaning I'm stuck at a resolution of 1024x768. (The
> monitor supports 2560x1440@144). The video output does work, though.
>

Are there 2 issues in this bug? edp is not working and external display works with only resolution 1024x768?

Can you attach display info cat /sys/kernel/debug/dri/0/i915_display_info ?

Can you verify the issue with drmtip (https://cgit.freedesktop.org/drm-tip) with kernel parameters drm.debug=0x1e log_buf_len=4M.
Comment 3 Geoffrey Allott 2019-10-21 20:04:07 UTC
> Even though it's reported as disconnected, edp still working?

> Are there 2 issues in this bug? edp is not working and external display works with only resolution 1024x768?

Please forgive me, I'm not super-familiar with this stuff. The device is just a small box & has no integrated display. I assume that means eDP should not work. Please correct me if I'm wrong and eDP controls the external ports. The problem is that the screen's native resolution is not detected.

There is no such file /sys/kernel/debug/dri/0/i915_display_info on my system. Here's the info I can gather:

$ ls /sys/class/drm
card0  card0-DP-1  card0-DP-2  card0-HDMI-A-1  renderD128  version
$ for connector in /sys/class/drm/card0-*; do
> echo $connector
> ls $connector
> cat $connector/enabled
> cat $connector/edid
> cat $connector/modes
> cat $connector/status
> done
/sys/class/drm/card0-DP-1
device  dpms  edid  enabled  i2c-4  modes  power  status  subsystem  uevent
disabled
disconnected
/sys/class/drm/card0-DP-2
device  dpms  edid  enabled  i2c-5  modes  power  status  subsystem  uevent
enabled
1024x768
800x600
800x600
848x480
640x480
connected
/sys/class/drm/card0-HDMI-A-1
device  dpms  edid  enabled  i2c-1  modes  power  status  subsystem  uevent
disabled
disconnected

Here's the log with drm-tip and the command line you mentioned:
https://pastebin.com/dmAdM17T
Comment 4 Geoffrey Allott 2019-10-21 20:11:51 UTC
Needed to be root to read the debug info... here it is:

CRTC info
---------
CRTC 51: pipe: A, active=yes, (size=1024x768), dither=no, bpp=24
	fb: 118, pos: 0x0, size: 1024x768
	encoder 104: type: DDI C, connectors:
		connector 105: type: DP-2, status: connected, mode:
		"1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
	cursor visible? no, position (0, 0), size 0x0, addr 0x00000000
	num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=10000000, scalers[1]: use=no, mode=0
	--Plane id 31: type=PRI, crtc_pos=   0x   0, crtc_size=1024x 768, src_pos=0.0000x0.0000, src_size=1024.0000x768.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)
	--Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
	--Plane id 47: type=CUR, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
	underrun reporting: cpu=yes pch=yes 
CRTC 72: pipe: B, active=no, (size=0x0), dither=no, bpp=0
	underrun reporting: cpu=yes pch=yes 
CRTC 93: pipe: C, active=no, (size=0x0), dither=no, bpp=0
	underrun reporting: cpu=yes pch=yes 

Connector info
--------------
connector 95: type DP-1, status: disconnected
connector 105: type DP-2, status: connected
	physical dimensions: 0x0mm
	subpixel order: Unknown
	CEA rev: 0
	DPCD rev: 12
	audio support: no
	DP branch device present: no
	HDCP version: HDCP1.4 
	modes:
		"1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
		"800x600": 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
		"800x600": 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
		"848x480": 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
		"640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
connector 111: type HDMI-A-1, status: disconnected
Comment 5 Lakshmi 2019-10-24 07:37:19 UTC
Can you reproduce this issue with latest drmtip? (https://cgit.freedesktop.org/drm-tip) with kernel parameters drm.debug=0x1e log_buf_len=4M. If the problem persists attach the full dmesg from boot.
Comment 6 Geoffrey Allott 2019-10-24 08:28:55 UTC
I attached the log from drm-tip as of a couple of days ago:
https://pastebin.com/dmAdM17T

I will check later today with the latest version.
Comment 7 Lakshmi 2019-10-24 09:45:12 UTC
(In reply to Geoffrey Allott from comment #6)
> I attached the log from drm-tip as of a couple of days ago:
> https://pastebin.com/dmAdM17T
> 
> I will check later today with the latest version.

My bad, I missed that.
Comment 8 Geoffrey Allott 2019-10-27 07:11:46 UTC
Problem persists with latest drm-tip.
Comment 9 Martin Peres 2019-11-29 19:42:23 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/531.


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.