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
Created attachment 373542 [details, diff] gentoo-sources 3.13.6 <-> 3.13.7 i915 driver differences This file shows the changes made to the i915 driver between 3.13.6 and 3.13.7.
Created attachment 373544 [details] 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.
Created attachment 373546 [details] 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 300000.
(In reply to nvinson from comment #3) > Created attachment 373546 [details] > 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 300000. sorry, copy and past error in the description. This file actually shows the clock limit set to 165000 and not 300000. It also shows the 2560x1440 modeline being pruned.
I wonder if it's here where this is being set and the conditionals are not being met. if (IS_G4X(dev)) return 165000; else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8) return 300000; else return 225000; So, the processor architecture has to be haswell. The gen 8 refers to the render engine. Do you have the time/energy for a git bisect?
(In reply to Mike Pagano from comment #5) > I wonder if it's here where this is being set and the conditionals are not > being met. > > if (IS_G4X(dev)) > return 165000; > else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8) > return 300000; > else > return 225000; > > > So, the processor architecture has to be haswell. The gen 8 refers to the > render engine. > > Do you have the time/energy for a git bisect? Sorry, I should have written back to this bug sooner. The upstream version has the cause and a patch to fix it. The cause is due to upstream adding a !hdmi->has_hdmi_sink check to the first if. if (!hdmi->has_hdmi_sink || IS_G4X(dev)) return 165000; else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8) return 300000; else return 225000; This seems to cause a problem for both HDMI <-> Single link DVI cables and HDMI <-> Dual link DVI cables (athough HDMI <-> single link DVI is not supposed to work in the first as I understand it). The fix upstream provided relaxes the !hdmi->has_hdmi_sink check a bit and allow the user to override the limit. I will post that patch from upstream as an attachment here. The end result of the patch is that I am forced to use a 1920x1200 console, but once I start X I can override the limits (using xorg.conf or xrandr) and push the resolution back up to 2560x1440. Unfortunately, the upstream patch does not appear to have made it into the kernel sources, yet. At least I did not see the patch when I reviewed 3.14 sources.
Created attachment 374060 [details, diff] Upstream kernel patch for 3.13.7 This patch allows users to exceed the 165 MHz limit the intel i915 driver imposes on HDMI <-> DVI connections.
FYI, It looks like the upstream patch has made it into v3.15-rc5 sources (https://github.com/torvalds/linux/blob/v3.15-rc5/drivers/gpu/drm/i915/intel_hdmi.c). I would not object if this bug was to be closed now. Thanks.
I should have closed this awhile ago. Thanks for your efforts.
