[Bug 107585] New: Wrong max TMDS clock rate on ThinkPad W541 mini-DisplayPort output

Wed Aug 15 20:16:26 UTC 2018

https://bugs.freedesktop.org/show_bug.cgi?id=107585

            Bug ID: 107585
           Summary: Wrong max TMDS clock rate on ThinkPad W541
                    mini-DisplayPort output
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: Simon80 at gmail.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

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 at 60Hz, but only supports HDMI 1.4. The laptop
itself has a mini-DisplayPort 1.2 port.

[1]
https://ark.intel.com/products/78939/Intel-Core-i7-4910MQ-Processor-8M-Cache-up-to-3_90-GHz

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]
http://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad%20W541/ThinkPad_W541_Platform_Specifications.pdf

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:
> $ 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

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:
> 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: stable at vger.kernel.org
> Reported-by: Tore Anderson <tore at fud.no>
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> Cc: Paulo Zanoni <paulo.r.zanoni at intel.com>
> Cc: Shashank Sharma <shashank.sharma at intel.com>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.com
> Reviewed-by: Shashank Sharma <shashank.sharma at intel.com>
> (cherry picked from commit b1ba124d8e95cca48d33502a4a76b1ed09d213ce)
> Signed-off-by: Jani Nikula <jani.nikula at intel.com>

I then built a 4.18 kernel and enabled KMS debug output in the drm module,
which confirmed the problem:
> [   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)

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:
> xrandr --newmode 3840x2160_30.00 297 3840 4016 4104 4400  2160 2168 2178 2250 +hsync +vsync
> xrandr --addmode HDMI1 3840x2160_30.00

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:
> 		HDMI max data rate: 0x01
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]
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/intel_vbt_defs.h#L309-L311

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180815/38d02b92/attachment-0001.html>