Bug 72961

Summary: [hdmi to dvi regression] Patch to hdmi_portclock_limit disables resolutions that worked with the 3.13.6 kernel
Product: Drivers Reporter: Nicholas Vinson (nvinson)
Component: Video(DRI - Intel)Assignee: Ville Syrjala (ville.syrjala)
Status: RESOLVED CODE_FIX    
Severity: normal CC: daniel, intel-gfx-bugs
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.13.7 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: dmesg output of 3.13.6 kernel with DRM debugging information
dmesg output of 3.13.7 kernel with DRM debugging information
[PATCH] drm/i915: Allow user modes to exceed DVI 165MHz limit

Description Nicholas Vinson 2014-03-26 02:26:53 UTC 
My computer uses the Asus Maximux VI Hero motherboard which only contains an HDMI out, the i4771 CPU, and is connected to a Dell 2713hm using a DVI <-> HDMI cable (http://www.amazon.com/gp/product/B00851NVDO/ref=oh_details_o03_s00_i00?ie=UTF8&psc=1).  The rationale for this setup is that the Dell monitor is capable of 2560x1440, but only if the signal comes in on its DVI or Display Ports.  This setup worked with the 3.13.6 kernel.

However, after upgrading to gentoo-sources 3.13.7 from 3.13.6 I could no longer switch to 2560x1440 @ 60 Hz due to a patch to the hdmi_portclock_limit() function found in drivers/gpu/drm/i915/intel_hdmi.c.  The patch appears to limit the port clock to 165000 (while in 3.13.6 it was limited to 300000) and this limit causes the prune the modeline for the 2560x1440 resolution.  I discovered this by adding debugging statements to the hdmi_portclock_limit() function for both kernels and comparing dmesg output.

Reproducible: Always

Steps to Reproduce:
1. Update 3.13.6 kernel configuration for 3.13.7 gentoo-sources
2. Build 3.13.7 kernel (and associated modules)
3. Reboot using new kernel
Actual Results:  
System reboots and starts using the 1920x1200 resolution.  All attempts to manually set the resolution to 2560x1440 (including adding the modeline using xrandr) fails.

Expected Results:  
System to start up using 2560x1440 resolution as it did with the 3.13.6 linux kernel.

The patch made to hdmi_portclock_limit() seems to be related to the issues described in https://bugzilla.kernel.org/show_bug.cgi?id=70331 and https://bugs.freedesktop.org/show_bug.cgi?id=75345
Comment 1 Nicholas Vinson 2014-03-26 02:29:41 UTC 
Created attachment 130711 [details]
dmesg output of 3.13.6 kernel with DRM debugging information

dmesg output with DRM debugging information

This is the output of dmesg of the 3.13.6 kernel after I enabled DRM debugging and added print statements to hdmi_portclock_limit().  The output shows the port clock limit set to 300000.
Comment 2 Nicholas Vinson 2014-03-26 02:31:43 UTC 
Created attachment 130721 [details]
dmesg output of 3.13.7 kernel with DRM debugging information

dmesg output of 3.13.7 kernel with DRM debugging information

This is the output of dmesg of the 3.13.7 kernel after I enabled DRM
debugging and added print statements to hdmi_portclock_limit().  The output
shows the port clock limit set to 165000.  It also shows the 2560x1440 modeline being pruned.
Comment 3 Jani Nikula 2014-03-26 09:42:12 UTC 
Broken by
commit 6375b768a9850b6154478993e5fb566fa4614a9c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Mar 3 11:33:36 2014 +0200

    drm/i915: Reject >165MHz modes w/ DVI monitors

This does not take into account HDMI to dual-link DVI adapters, like the one in question. This gets tricky. We should reject >165 MHz modes for *single-link* DVI monitors (regardless of whether connected directly or through an adapter) and also *dual-link* DVI monitors connected *directly* (because we simply do not support that, at all).
Comment 4 Ville Syrjala 2014-03-26 14:27:06 UTC 
Created attachment 130731 [details]
[PATCH] drm/i915: Allow user modes to exceed DVI 165MHz limit

Based on what the cable looks like, I think it's just a plain old passive single link DVI <-> HDMI cable. So it looks like your monitor accepts out of spec frequencies on the DVI connector. Probably it's just a HDMI input w/ a DVI connector. But the monitor apparently doesn't report back the HDMI VSDB EDID block so the source can't identify it as a HDMI monitor, which means the driver can't know that the monitor will accept HDMI signals.

In this case we just filter out the high resolution modes, so you still get a picture on the screen, but if we were to revert the patch then people with monitors which don't accept out of spec DVI signals would get no picture at all. So we get to pick the option where everyone gets at least some kind of picture.

But the patch does seem to be a bit too strict. We should probably still allow you to manually add the mode w/ xrandr. In that case you're basically telling the driver that you know what you're doing. This patch attempts to fix that. Let me know if it works.
Comment 5 Nicholas Vinson 2014-03-26 23:49:43 UTC 
(In reply to Ville Syrjala from comment #4)
> Created attachment 130731 [details]
> [PATCH] drm/i915: Allow user modes to exceed DVI 165MHz limit
> 
> Based on what the cable looks like, I think it's just a plain old passive
> single link DVI <-> HDMI cable. So it looks like your monitor accepts out of
> spec frequencies on the DVI connector. Probably it's just a HDMI input w/ a

I can confirm that the monitor will accept out of spec frequencies because I have attached a HDMI <-> single-link DVI cable to it and got 2560x1440 as well.

As for the cable I'm currently using, I am not completely sure.  As you can tell from Amazon's website it claims to be able to handle resolutions beyond what a single-link DVI cable can (1440p and 4Kx2K for example).  I guess the only way I could ever really know would be to take the cable apart and see if it just wires or if it has circuitry in it.

> DVI connector. But the monitor apparently doesn't report back the HDMI VSDB
> EDID block so the source can't identify it as a HDMI monitor, which means
> the driver can't know that the monitor will accept HDMI signals.
> 
> In this case we just filter out the high resolution modes, so you still get
> a picture on the screen, but if we were to revert the patch then people with
> monitors which don't accept out of spec DVI signals would get no picture at
> all. So we get to pick the option where everyone gets at least some kind of
> picture.
> 
> But the patch does seem to be a bit too strict. We should probably still
> allow you to manually add the mode w/ xrandr. In that case you're basically
> telling the driver that you know what you're doing. This patch attempts to
> fix that. Let me know if it works.

I added the patch to the kernel sources and rebooted.  The maximum resolution I can get with the console is 1920x1200.  Inside X, I was able to add the 2560x1440 mode back using xrandr and achieve that resolution.  I have verified that I can add a configuration file to /etc/X11/xorg.conf.d to get X to start with the 2560x1440 resolution.  Personally, I am satisfied with this solution.  Thank you.
Comment 6 Jani Nikula 2014-03-27 07:05:58 UTC 
(In reply to Nicholas Vinson from comment #5)
> I added the patch to the kernel sources and rebooted.  The maximum
> resolution I can get with the console is 1920x1200.  Inside X, I was able to
> add the 2560x1440 mode back using xrandr and achieve that resolution.  I
> have verified that I can add a configuration file to /etc/X11/xorg.conf.d to
> get X to start with the 2560x1440 resolution.  Personally, I am satisfied
> with this solution.  Thank you.

Thanks for trying it out.

Because fixes to earlier regressions win, I think we should go with this solution. (The commits that enabled the feature for you were considered a regression, and the fixes to that regressed your feature. If we reverted back to before the first regression, this wouldn't work for you anyway, I think.)

Ville, please post the patch to the list.
Comment 9 Daniel Vetter 2014-04-11 13:32:49 UTC 
Jani needs to pick up the patch to -fixes.
Comment 10 Jani Nikula 2014-04-11 14:27:32 UTC 
(In reply to Daniel Vetter from comment #9)
> Jani needs to pick up the patch to -fixes.

commit b6842feb63a23a6a988f4e1ffb93408d8ff6931e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Mar 27 11:08:45 2014 +0200

    drm/i915: Allow user modes to exceed DVI 165MHz limit
Comment 11 Daniel Vetter 2014-04-11 14:30:29 UTC 
I think this is about as good as it gets without risking regressions. Now users can manually set the mode, but we don't risk black screens on other systems where this doesn't magically work.