Bug 111553 - Linux 4.10 and newer limit pixel clock to 165 MHz on Haswell-ULT laptop
Summary: Linux 4.10 and newer limit pixel clock to 165 MHz on Haswell-ULT laptop
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: not set not set
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-03 22:10 UTC by Michael Hanselmann (hansmi)
Modified: 2019-09-14 18:57 UTC (History)
1 user (show)

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


Attachments
i915 log of attaching Dell U2715H to Linux 4.19 (24.01 KB, text/x-log)
2019-09-03 22:10 UTC, Michael Hanselmann (hansmi)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hanselmann (hansmi) 2019-09-03 22:10:18 UTC
Created attachment 145258 [details]
i915 log of attaching Dell U2715H to Linux 4.19

I've recently upgraded a laptop from Debian 9 (Stretch) which used Linux 4.9 to
10 (Buster) which is using Linux 4.19. For about two years I've successfully
used a custom modeline to drive an external monitor at its native
resolution:

  # 2560x1440 59.95 Hz (CVT 3.69M9-R) hsync: 88.79 kHz; pclk: 241.50 MHz
  Modeline "2560x1440R" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync

The upgrade involved switching from X.Org to Wayland with KMS. The native
resolution is no longer offered and the monitor is driven at 2048x1152 instead.
The situation is obviously undesirable. I'm not sure whether I've been driving
the hardware out of specs or whether I'm dealing with a bug.

I managed to identify what appears to be the causing condition in
"drivers/gpu/drm/i915/intel_hdmi.c:hdmi_port_clock_limit" and confirmed that
the native resolution is automatically chosen after applying a minor patch (the
same original code exists in Linux 5.2 so it's not specific to 4.19):

---
--- ./drivers/gpu/drm/i915/intel_hdmi.c.orig    2019-09-03 23:43:19.679250829 +0200
+++ ./drivers/gpu/drm/i915/intel_hdmi.c 2019-09-03 23:43:47.223415491 +0200
@@ -1504,10 +1504,6 @@
                struct intel_connector *connector = hdmi->attached_connector;
                const struct drm_display_info *info = &connector->base.display_info;
 
-               if (hdmi->dp_dual_mode.max_tmds_clock)
-                       max_tmds_clock = min(max_tmds_clock,
-                                            hdmi->dp_dual_mode.max_tmds_clock);
-
                if (info->max_tmds_clock)
                        max_tmds_clock = min(max_tmds_clock,
                                             info->max_tmds_clock);
---

"dp_dual_mode.max_tmds_clock" is set to 165 MHz by
"drm_dp_dual_mode_max_tmds_clock". I'm attaching a kernel log.

The condition I ended up removing was added in commit b1ba124d8e95 by Ville
Syrjälä in May 2016
(<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1ba124d8e95>).

Machine information from dmidecode: Toshiba Satellite Z30-A with Intel Core
i7-4500U CPU @ 1.80GHz (Type 0, Family 6, Model 69, Stepping 1).

Monitor information: Dell U2715H with a native resolution of 2560x1440,
connected via a noname HDMI cable. Tests with another cable didn't bring an
improvement.

Kernel: 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64

Excerpt from EDID:
---
…
Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
               2560 2608 2640 2720 hborder 0
               1440 1443 1448 1481 vborder 0
               +hsync -vsync
               VertFreq: 59 Hz, HorFreq: 88786 Hz
…
Monitor ranges (GTF): 56-86Hz V, 30-113kHz H, max dotclock 300MHz
…
---
Comment 1 Ville Syrjala 2019-09-04 14:08:27 UTC
There is clearly a dual-mode adaptor in the chain somewhere:
[ 1428.752898] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: DP-HDMI ADAPTOR\004 (err 0)
[ 1428.753676] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode adaptor ID: ff (err 0)
[ 1428.753728] [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 1 HDMI) detected (max TMDS clock: 165000 kHz)

Is the connector on the laptop a DP/mini-DP or HDMI?
Comment 2 Michael Hanselmann (hansmi) 2019-09-04 17:41:30 UTC
(In reply to Ville Syrjala from comment #1)
> Is the connector on the laptop a DP/mini-DP or HDMI?

The electrical connector is an HDMI Type A, as is the connector on the monitor.

Would you like me to open the device to check whether there's any converter chip from DP to HDMI in the signal path (the mainboard pictures I found online were all of insufficient clarity)?
Comment 3 Ville Syrjala 2019-09-05 10:21:34 UTC
(In reply to Michael Hanselmann (hansmi) from comment #2)
> (In reply to Ville Syrjala from comment #1)
> > Is the connector on the laptop a DP/mini-DP or HDMI?
> 
> The electrical connector is an HDMI Type A, as is the connector on the
> monitor.
> 
> Would you like me to open the device to check whether there's any converter
> chip from DP to HDMI in the signal path (the mainboard pictures I found
> online were all of insufficient clarity)?

Nah. It's clearly there since we can talk to it.

So yeah, basically that means that you're trying to drive it out of spec, or the manufacturer messed up and used a dual-mode chip that misreports its maximum TMDS clock. We have to err on the side of caution and filter out modes that look out of spec, doing otherwise would lead to some poor chap getting a black screen.

However if you want you can still keep driving it out of spec with the custom modeline. I guess the question is how would you add one under whatever wayland compositor you use.
Comment 4 Michael Hanselmann (hansmi) 2019-09-05 18:21:03 UTC
(In reply to Ville Syrjala from comment #3)
> We have to err on the side of caution and filter out
> modes that look out of spec, doing otherwise would lead to some poor chap
> getting a black screen.

I can only agree with you. Thank you for your quick assessment!

> However if you want you can still keep driving it out of spec with the
> custom modeline. I guess the question is how would you add one under
> whatever wayland compositor you use.

It's Gnome with Mutter. I'll investigate and follow-up for any future readers.
Comment 5 Michael Hanselmann (hansmi) 2019-09-09 20:09:36 UTC
(In reply to Michael Hanselmann (hansmi) from comment #4)
> It's Gnome with Mutter. I'll investigate and follow-up for any future
> readers.

It appears as if Mutter doesn't allow for custom modelines and passes the kernel's modelines through. I've tried the following kernel command line parameters:

  video=2560x1440MR@59
  video=HDMI-A-2:2560x1440R

Unfortunately the pixel clock is still limited to 165 MHz.

Ville, is there a way I can force a mode via parameters?
Comment 6 Ville Syrjala 2019-09-10 07:28:07 UTC
(In reply to Michael Hanselmann (hansmi) from comment #5)
> (In reply to Michael Hanselmann (hansmi) from comment #4)
> > It's Gnome with Mutter. I'll investigate and follow-up for any future
> > readers.
> 
> It appears as if Mutter doesn't allow for custom modelines and passes the
> kernel's modelines through. I've tried the following kernel command line
> parameters:
> 
>   video=2560x1440MR@59
>   video=HDMI-A-2:2560x1440R
> 
> Unfortunately the pixel clock is still limited to 165 MHz.
> 
> Ville, is there a way I can force a mode via parameters?

Nope. Looks like the cmdline mode is treated the same as mode coming from the EDID, ie. is subject to getting filtered out from the connector's mode list.
Comment 7 Michael Hanselmann (hansmi) 2019-09-14 18:57:00 UTC
(In reply to Ville Syrjala from comment #6)
> Nope. Looks like the cmdline mode is treated the same as mode coming from
> the EDID, ie. is subject to getting filtered out from the connector's mode
> list.

That filtering is indeed the case. None of my other attempts like writing to the adapter and EDID via I²C worked (either the transactions were NACKed or outright ignored). As I'd rather not maintain my own kernel build I ended up writing a custom kernel module using Kernel probes to override the return value from "drm_dp_dual_mode_detect":

https://github.com/hansmi/fake-dp-dual-mode

Now, this is obviously a hack, but it's fine for myself. I'd be able to submit a kernel patch to add a parameter overriding the automatic detection. Do you think that'd be worth it?


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.