Bug 105406 - No internal display on kernels > 4.4.x
Summary: No internal display on kernels > 4.4.x
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-09 00:40 UTC by David S.
Modified: 2019-07-12 16:02 UTC (History)
4 users (show)

See Also:
i915 platform: SNB
i915 features: display/DP


Attachments
kernel_4-15_no_working_display (93.92 KB, text/plain)
2018-03-14 17:52 UTC, Elizabeth
no flags Details
kernel_4-4-120_working_display (97.31 KB, text/plain)
2018-03-15 16:14 UTC, Elizabeth
no flags Details
Output of dd if=/dev/drm_dp_aux1 > dpcd (1.25 KB, application/gzip)
2018-04-30 00:07 UTC, David S.
no flags Details
Output of cat /sys/class/drm/card0-DP-2/edid > edid (128 bytes, application/octet-stream)
2018-04-30 00:07 UTC, David S.
no flags Details
EDID and DPCD info from my hardware (1.45 KB, application/octet-stream)
2019-05-12 14:13 UTC, Peteris Rudzusiks
no flags Details
i915_vbt.gz (1.38 KB, application/gzip)
2019-05-13 15:38 UTC, Peteris Rudzusiks
no flags Details
[PATCH 1/2] drm/dp: Add DP_DPCD_QUIRK_NO_SINK_COUNT (2.15 KB, patch)
2019-05-13 16:21 UTC, Ville Syrjala
no flags Details | Splinter Review
[PATCH 2/2] drm/i915: Skip SINK_COUNT read on CH7511 (2.30 KB, patch)
2019-05-13 16:22 UTC, Ville Syrjala
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David S. 2018-03-09 00:40:11 UTC
I have a J2-680L POS (Point Of Sale) that runs Manjaro Linux. The problem is that ANY kernel newer than 4.4.x will not enable the internal display and I am forced to use an external display.

This has been duplicated by testing with the latest releases of Fedora, CentOS, Debian and Ubuntu.

The internal display will work up untill GRUB, after GRUB the display will go blank and is not detected by the system. This happens whether I am using modesetting or xf86-video-intel.

Here are a few bits of information relating to the system. If anything else is needed please let me know...

inxi -Fz
https://pastebin.com/zJmPFEak

lsmod
https://pastebin.com/yLLkmwDP

xrandr - NOTE: the internal screen is detected as connected on DP-2
https://pastebin.com/rQKDaLf8

hwinfo --monitor
https://pastebin.com/k4rvVSPW

hwinfo --gfxcard
https://pastebin.com/qHQFJM9F

As a side note i also tried creating a x11 intel.conf containing:

Section "Device"
        Identifier  "Intel Graphics"
        Driver      "modesetting"
        BusID       "PCI:0:2:0"
EndSection

To no avail which has now lead me to believe this is an regression.

Thanks.
Comment 1 Elizabeth 2018-03-09 21:01:18 UTC
Hi, is it possible that you test with latest kernel stable: https://www.kernel.org?
Comment 2 David S. 2018-03-10 10:33:51 UTC
I have the exact same results of no internal display with kernels 4.9.86 & 4.14.25 and 4.15.8.

The system works fine with an external monitor on the above mentioned kernels but the internal display does not function, it is not even detected.
Comment 3 Elizabeth 2018-03-12 17:14:23 UTC
Thank you for testing, could you please attach dmesg or kern.log, with drm.debug=0xe parameter on grub, on raw text, with boot information?
Comment 4 David S. 2018-03-13 22:09:45 UTC
Hi, here is the output of dmesg with the flags set at boot as requested..

https://pastebin.com/5z5hSKCg
Comment 5 Elizabeth 2018-03-14 17:52:06 UTC
Created attachment 138112 [details]
kernel_4-15_no_working_display
Comment 6 Elizabeth 2018-03-14 18:28:11 UTC
From dmesg:

[drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:60:DP-2]
[   22.091324] [drm:intel_dp_detect [i915]] [CONNECTOR:60:DP-2]
[   22.091877] [drm:intel_dp_read_dpcd [i915]] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00
[   22.092216] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:60:DP-2] disconnected
[   22.092302] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:VGA-1]
[   22.092322] [drm:intel_crt_detect [i915]] [CONNECTOR:48:VGA-1] force=1
[   22.092345] [drm:intel_crt_detect [i915]] ironlake hotplug adpa=0x83f40018, result 1
[   22.092364] [drm:intel_crt_detect [i915]] CRT detected via hotplug
[   22.131595] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   22.131618] [drm:drm_add_display_info [drm]] non_desktop set to 0

These lines look suspicious, but not sure if related. Could you attach another log of a working version to compare? Same with drm.debug parameter. 

Thanks.
Comment 7 David S. 2018-03-14 23:27:03 UTC
Firstly just want to say thank you for you support in this matter, i really appreciate it.

Here is the dmesg with drm.debug=0xe from kernel 4.4.120 where the internal screen works as expected.

https://pastebin.com/uA0JTacq
Comment 8 Elizabeth 2018-03-15 16:14:16 UTC
Created attachment 138133 [details]
kernel_4-4-120_working_display

From the 4.4.120 dmesg:

After the DP-2 is detected:

[   15.410309] [drm:intel_dp_detect] [CONNECTOR:39:DP-2]
[   15.410845] [drm:intel_dp_get_dpcd] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00
[   15.410850] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source no, sink no
[   15.410853] [drm:intel_dp_print_rates] source rates: 162000, 270000
[   15.410855] [drm:intel_dp_print_rates] sink rates: 162000, 270000
[   15.410858] [drm:intel_dp_print_rates] common rates: 162000, 270000

The modes of that connector are probed: 

[   15.424921] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:39:DP-2] probed modes :
[   15.424926] [drm:drm_mode_debug_printmodeline] Modeline 43:"1024x768" 60 65000 1024 1048 1184 1344 768 772 778 806 0x48 0xa
[   15.424930] [drm:drm_mode_debug_printmodeline] Modeline 45:"1024x768" 85 94500 1024 1072 1168 1376 768 769 772 808 0x40 0x5
[   15.424934] [drm:drm_mode_debug_printmodeline] Modeline 44:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
 
And the connector detected as enable is the DP-2(39):

[   15.424970] [drm:drm_enable_connectors] connector 27 enabled? no
[   15.424972] [drm:drm_enable_connectors] connector 30 enabled? no
[   15.424974] [drm:drm_enable_connectors] connector 35 enabled? no
[   15.424976] [drm:drm_enable_connectors] connector 37 enabled? no
[   15.424986] [drm:drm_enable_connectors] connector 39 enabled? yes

Meanwhile, in the 4.15 dmesg:

After the dp-2 is detected:

[   14.988279] [drm:intel_dp_detect [i915]] [CONNECTOR:60:DP-2]
[   14.988821] [drm:intel_dp_read_dpcd [i915]] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00
[   14.989157] [drm:drm_helper_hpd_irq_event [drm_kms_helper]] [CONNECTOR:60:DP-2] status updated from unknown to disconnected

The connector probed is VGA instead:

[   14.989251] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:VGA-1]
[   14.989298] [drm:intel_crt_detect [i915]] [CONNECTOR:48:VGA-1] force=1
[   14.989328] [drm:intel_crt_detect [i915]] ironlake hotplug adpa=0xa3f40018, result 1
[   14.989349] [drm:intel_crt_detect [i915]] CRT detected via hotplug
[   15.027723] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   15.027744] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   15.027822] [drm:intel_connector_update_modes [i915]] ELD: no CEA Extension found
[   15.027908] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:VGA-1] probed modes :
[   15.027927] [drm:drm_mode_debug_printmodeline [drm]] Modeline 65:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
[   15.027943] [drm:drm_mode_debug_printmodeline [drm]] Modeline 71:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[   15.027959] [drm:drm_mode_debug_printmodeline [drm]] Modeline 66:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 ...

And the one detected as enable is the vga(48):

[   15.174252] [drm:drm_setup_crtcs [drm_kms_helper]] connector 48 enabled? yes
[   15.174264] [drm:drm_setup_crtcs [drm_kms_helper]] connector 51 enabled? no
[   15.174270] [drm:drm_setup_crtcs [drm_kms_helper]] connector 56 enabled? no
[   15.174275] [drm:drm_setup_crtcs [drm_kms_helper]] connector 58 enabled? no
[   15.174280] [drm:drm_setup_crtcs [drm_kms_helper]] connector 60 enabled? no
Comment 9 Elizabeth 2018-03-15 16:17:24 UTC
If possible, could you try to replicate on kernel 4.13?
Comment 10 Ville Syrjala 2018-03-15 16:55:27 UTC
[   14.988821] [drm:intel_dp_read_dpcd [i915]] DPCD: 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00

means we were able to read the DPCD, and it has a valid revision number.

That leads me to suspect that the display might be saying that SINK_COUNT is zero.

Please run this:
dd if=/dev/drm_dp_aux1 bs=1 skip=$((0x200)) count=1 2>/dev/null | xxd -p

Your kernel will need to be built with CONFIG_DRM_DP_AUX_CHARDEV=y for that to work.
Comment 11 David S. 2018-03-16 01:06:07 UTC
Hi, Elizabeth i only have access to the LTS kernels and current mainline, so i'm unable to test with kernel 4.13.

Ville, the output of that command returns "00".

The screen still isnt working after reboots and typing the command. Here is the configs used by my current kernel, which has already CONFIG_DRM_DP_AUX_CHARDEV=y set.

https://pastebin.com/XQKnN0mW

Thanks.
Comment 12 Jani Saarinen 2018-03-29 07:10:44 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 13 David S. 2018-04-03 00:00:56 UTC
Just updating to say that there is still no change using kernel 4.16.0

Here is the dmesg with drm.debug=0xe

https://pastebin.com/7QBCCJkt

Thanks.
Comment 14 Jani Saarinen 2018-04-24 07:11:45 UTC
Jani, Ville, any advice here?
Comment 15 Jani Nikula 2018-04-24 08:51:53 UTC
(In reply to David S. from comment #13)
> https://pastebin.com/7QBCCJkt

Please always attach logs etc. on the bug. Pastebins go away, and then we're left with nothing.
Comment 16 Jani Nikula 2018-04-24 09:46:50 UTC
Looks like this was broken for you by

commit 30d9aa4265fe4b2b28239934770b2c2d59858df3
Author: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Date:   Wed Mar 30 18:05:25 2016 +0530

    drm/i915: Read sink_count dpcd always

in v4.7. (Did you ever try v4.5 or v4.6? I suspect those should have worked.)

I have seen very few displays with DPCD rev 1.0 like you have, and it's so old I've never been able to acquire the 1.0 or even 1.1 specs to see how the sink count part was written back then.

It seems to me that the current code is okay for DP 1.2 and later. But maybe we should look assume sink count == 1 for non-branch devices with DPCD 1.0/1.1.
Comment 17 Ville Syrjala 2018-04-24 13:09:56 UTC
(In reply to Jani Nikula from comment #16)
> Looks like this was broken for you by
> 
> commit 30d9aa4265fe4b2b28239934770b2c2d59858df3
> Author: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
> Date:   Wed Mar 30 18:05:25 2016 +0530
> 
>     drm/i915: Read sink_count dpcd always
> 
> in v4.7. (Did you ever try v4.5 or v4.6? I suspect those should have worked.)
> 
> I have seen very few displays with DPCD rev 1.0 like you have, and it's so
> old I've never been able to acquire the 1.0 or even 1.1 specs to see how the
> sink count part was written back then.

I have the 1.0/1.1. SINK_COUNT always worked the same way. Ie. this looks to be a broken DP sink we're dealing with here.
Comment 18 Jani Nikula 2018-04-24 14:47:13 UTC
Please run this and report the result:

# dd if=/dev/drm_dp_aux1 bs=1 skip=$((0x400)) count=12 2>/dev/null | xxd -p

Let's see if there's any chance we could quirk just that one sink.
Comment 19 David S. 2018-04-27 00:06:38 UTC
Hi,

The output from running the above mentioned command is...

000000434837353131100100

Thanks.
Comment 20 Jani Nikula 2018-04-27 08:26:05 UTC
(In reply to David S. from comment #19)
> 000000434837353131100100

So in newer DP spec the first three bytes would be the sink OUI which we could use to quirk different behaviour for the sink. Alas DPCD 1.0 has that as sink specific, and it doesn't have the OUI. Seems a bit risky to use that for quirking.

Ville, what do you think? Quirk all DPCD 1.0/1.1 or use unreliable stuff for quirking a specific device? Other ideas?
Comment 21 Ville Syrjala 2018-04-27 13:03:42 UTC
Can we get a full binary DPCD dump please?

dd if=/dev/drm_dp_aux1 > dpcd

If that returns an error then you will have to use ddrescue instead of dd.
Uncompressed the complete dump should should 1MiB in size. Probably want to compress it with gzip before attaching.

Also can we get a copy of the EDID as well? This needs to be done with the kernel where the display still works.
cat /sys/class/drm/card0-DP-2/edid > edid
Comment 22 David S. 2018-04-30 00:07:03 UTC
Created attachment 139221 [details]
Output of dd if=/dev/drm_dp_aux1 > dpcd
Comment 23 David S. 2018-04-30 00:07:51 UTC
Created attachment 139222 [details]
Output of cat /sys/class/drm/card0-DP-2/edid > edid
Comment 24 Jani Saarinen 2018-04-30 07:54:57 UTC
Ville, have a look latest data
Comment 25 Ville Syrjala 2018-05-25 18:09:00 UTC
So we see "CH7511" in vendor specific bytes after the sink OUI. The OUI itself is 0. And we see that there are no downstream ports and SINK_COUNT==0 (which doesn't really make sense).

Actually this looks like it could be a new incarnation of bug #92172. That one was closed without a fix. Based on all the other google hits it looks like CH7511 doesn't take the DP/eDP specs seriously at all. Not sure if all CH7511 suck or if it's just a matter of the device manufacturers not configuring the thing correctly.

For instance in this case I also see the eDP cap bit being 0, but the registers at 0x700 have some backlight control junk at least. Although many of the values don't seem to make much sense when compared with the spec.
Comment 26 Peteris Rudzusiks 2019-05-12 14:11:08 UTC
I have a POS computer that also uses CH7511. Just like in David's case, the internal display of the POS is broken with Linux kernels 4.5+. The display shows no output. I can confirm that commit 30d9aa4265fe is the first commit since v4.4 that does not work.

For what it's worth, here is a patch for v4.19.35 that fixes the problem for me. Not sure if this is a proper fix or hacky workaround for broken hardware, but it works for me and maybe someone else finds it useful.

---
 drivers/gpu/drm/i915/intel_dp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f92079e19de8..ec908f605708 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3840,6 +3840,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 	 */
 	intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count);
 
+	if (!drm_dp_is_branch(intel_dp->dpcd))
+		return true; /* native DP sink */
+
 	/*
 	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
 	 * a dongle is present but no display. Unless we require to know
@@ -3850,9 +3853,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 	if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count)
 		return false;
 
-	if (!drm_dp_is_branch(intel_dp->dpcd))
-		return true; /* native DP sink */
-
 	if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
 		return true; /* no per-port downstream info */
 
-- 
2.17.1


The CH7511 is not a branch device according to DPCD, so intel_dp_get_dpcd() function will return without actually using the incorrect SINK_COUNT variable.
Comment 27 Peteris Rudzusiks 2019-05-12 14:13:56 UTC
Created attachment 144239 [details]
EDID and DPCD info from my hardware
Comment 28 Ville Syrjala 2019-05-13 13:09:50 UTC
Hmm. So it's an internal panel but it's not flagged as eDP. If it was I think we wouldn't be having this problem.

Please attach a copy of /sys/kernel/debug/dri/0/i915_vbt
Comment 29 Peteris Rudzusiks 2019-05-13 15:38:20 UTC
Created attachment 144247 [details]
i915_vbt.gz

copy of /sys/kernel/debug/dri/0/i915_vbt
Comment 30 Ville Syrjala 2019-05-13 16:20:20 UTC
(In reply to Peteris Rudzusiks from comment #29)
> Created attachment 144247 [details]
> i915_vbt.gz
> 
> copy of /sys/kernel/debug/dri/0/i915_vbt

Sadly it doesn't look like there's anything in the VBT that could help us. I think we'll need to quirk this.
Comment 31 Ville Syrjala 2019-05-13 16:21:37 UTC
Created attachment 144248 [details] [review]
[PATCH 1/2] drm/dp: Add DP_DPCD_QUIRK_NO_SINK_COUNT
Comment 32 Ville Syrjala 2019-05-13 16:22:13 UTC
Created attachment 144249 [details] [review]
[PATCH 2/2] drm/i915: Skip SINK_COUNT read on CH7511

Please test these patches to make sure I didn't fumble it.
Comment 33 Peteris Rudzusiks 2019-05-15 08:11:25 UTC
Tested kernel v5.1.2 with your patches applied - it worked!
Comment 34 Ville Syrjala 2019-07-12 16:02:52 UTC
commit 6e93a3b3264ed21fc07dc247f757939f844fbdc7
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue May 28 17:06:50 2019 +0300

    drm/i915: Skip SINK_COUNT read on CH7511

Fix pushed. Thanks for the bug report and testing.


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.