<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Wrong max TMDS clock rate on ThinkPad W541 mini-DisplayPort output"
href="https://bugs.freedesktop.org/show_bug.cgi?id=107585">107585</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Wrong max TMDS clock rate on ThinkPad W541 mini-DisplayPort output
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>Simon80@gmail.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>I have a ThinkPad W541 (released in Q1 2015) with an Intel Core i7-4910MQ
processor in it. According to the processor specs[1], it is theoretically
capable of driving 3840x2160@60Hz, but only supports HDMI 1.4. The laptop
itself has a mini-DisplayPort 1.2 port.
[1]
<a href="https://ark.intel.com/products/78939/Intel-Core-i7-4910MQ-Processor-8M-Cache-up-to-3_90-GHz">https://ark.intel.com/products/78939/Intel-Core-i7-4910MQ-Processor-8M-Cache-up-to-3_90-GHz</a>
The laptop's own specifications[2] claim it's capable of outputting 4K at 60Hz,
but there's no specific confirmation of what's possible on the Dual-Mode HDMI
output.
[2]
<a href="http://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad%20W541/ThinkPad_W541_Platform_Specifications.pdf">http://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad%20W541/ThinkPad_W541_Platform_Specifications.pdf</a>
Older kernels (4.6 and below, it turns out) are able to output 4K at 30Hz via
passive mini-DisplayPort to HDMI adapter. I tried to use `cvt` to calculate a
mode I could add via xrandr to manually force 4K output, but it turns out that
cvt outputs something that requires a clock rate above 300 MHz, which the
kernel rejected:
<span class="quote">> $ cvt --verbose 3840 2160 30.0
> Warning: Refresh Rate is not CVT standard (50, 60, 75 or 85Hz).
> # 3840x2160 29.98 Hz (CVT) hsync: 65.96 kHz; pclk: 338.75 MHz
> Modeline "3840x2160_30.00" 338.75 3840 4080 4488 5136 2160 2163 2168 2200 -hsync +vsync</span >
I later also tried the --reduced option, which cvt refuses to process unless
the refresh rate is a multiple of 60 Hz. Eventually, I got this working without
using the numbers from cvt, see below.
At this point, I bisected the kernel to figure out why it stopped working, and
ended up on commit c578d15226c99f0566d5d022f81af6b7d69928db:
<span class="quote">> drm/i915: Respect DP++ adaptor TMDS clock limit
>
> Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
> and take it into account when checking the port clock.
>
> Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
> the adaptor TMDS clock limit in the modeset path, in case users are
> already "overclocking" their TMDS links. One subtle change here is that
> we'll have to respect the adaptor TMDS clock limit when we decide whether
> to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
> accidentally driving the TMDS link out of spec even when the user chose
> a mode that fits wihting the limits at 8bpc. This means you can't
> "overclock" your DP++ dongle at 12bpc anymore, but you can continue to
> do so at 8bpc.
>
> Note that for simplicity we'll use the I2C access method for all dual
> mode adaptors including type 2. Otherwise we'd have to start mixing
> DP AUX and HDMI together. In the future we may need to do that if we
> come across any board designs that don't hook up the DDC pins to the
> DP++ connectors. Such boards would obviously only work with type 2
> dual mode adaptors, and not type 1.
>
> v2: Store adaptor type under indel_hdmi->dp_dual_mode
> Deal with DRM_DP_DUAL_MODE_UNKNOWN
> Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(),
> and use it for type1 adaptors as well
>
> Cc: <a href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a>
> Reported-by: Tore Anderson <<a href="mailto:tore@fud.no">tore@fud.no</a>>
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> Cc: Paulo Zanoni <<a href="mailto:paulo.r.zanoni@intel.com">paulo.r.zanoni@intel.com</a>>
> Cc: Shashank Sharma <<a href="mailto:shashank.sharma@intel.com">shashank.sharma@intel.com</a>>
> Cc: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>>
> Signed-off-by: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>>
> Link: <a href="http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.com">http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.com</a>
> Reviewed-by: Shashank Sharma <<a href="mailto:shashank.sharma@intel.com">shashank.sharma@intel.com</a>>
> (cherry picked from commit b1ba124d8e95cca48d33502a4a76b1ed09d213ce)
> Signed-off-by: Jani Nikula <<a href="mailto:jani.nikula@intel.com">jani.nikula@intel.com</a>></span >
I then built a 4.18 kernel and enabled KMS debug output in the drm module,
which confirmed the problem:
<span class="quote">> [ 13.052359] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: DP-HDMI ADAPTOR\004 (err 0)
> [ 13.053111] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode adapt or ID: ff (err 0)
> [ 13.053144] [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 1 HDMI) detected (max TMDS clock: 165000 kHz)</span >
I modified the detection logic to consider adaptor ID 0xff as a type 2 adaptor,
which leads the kernel to try to query the max TMDS clock rate dynamically.
Such a query fails on this hardware, so I guess it might be fair to describe it
as a type 1 adapter that supports a max TMDS clock rate of 300 MHz. Modifying
the hardcoded return value to be 300Mhz, instead of 165, results in a kernel
that works perfectly on this hardware, but I guess that may not be a safe
solution for some other type 1 adapters.
After a bit of email correspondence with Jani Nikula, I noticed that `xrandr
--verbose` spits out ful modelines that I could then provide back to it on
broken kernels to re-add the missing display modes. I tried this out and it
provides a reasonable workaround, assuming one has access to a kernel that can
provide the correct numbers:
<span class="quote">> xrandr --newmode 3840x2160_30.00 297 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync
> xrandr --addmode HDMI1 3840x2160_30.00</span >
However, it would be much better to get this working by default. I took a look
at the VBT on this system with intel_bios_reader, and I can see this line:
<span class="quote">> HDMI max data rate: 0x01</span >
A snippet from the kernel seems to imply that this value translates to 300
MHz[3].
Is there any reason why the i915 module couldn't look at the VBT and relax the
clock rate limit to 300 MHz when that's indicated in the VBT? That would solve
this problem without black screen issues on 165Mhz type 1 adapters.
[3]
<a href="https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/intel_vbt_defs.h#L309-L311">https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/intel_vbt_defs.h#L309-L311</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>