[Bug 99250] New: [SKL,IVB] HDMI and DP: EDID-supplied BPP is not always properly clamped.

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 99250
           Summary: [SKL,IVB] HDMI and DP: EDID-supplied BPP is not always
                    properly clamped.
           Product: DRI
           Version: DRI git
          Hardware: All
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: sielicki at yandex.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 128711
  --> https://bugs.freedesktop.org/attachment.cgi?id=128711&action=edit
Patch

-- Display connector: (such as HDMI, DP, eDP, ...)
        HDMI

  Seen with:
        * Dell E6430 (Ivybridge i5-3340M)
        * Skylake NUC6I7KYK
        * Acer X233H 24-bit monitor with ability for 30-bit FRC.

# Steps to reproduce the issue.

        With male-to-male HDMI cable, plug monitor into either of
        these devices. Output will appear, but it is corrupt.

# How often does the steps listed above trigger the issue?

        Always, with or without X, seen on framebuffer.
        Does not occur when using HDMI to DVI adapter.

# What's going on?

With Ivybridge, HDMI can only ever operate in 8BPC or 12BPC.
* ( page 78:
https://01.org/sites/default/files/documentation/snb_ihd_os_vol3_part3.pdf )

With HDMI 1.3, I believe it's legal for the monitor EDID to claim a maximum BPP
of 30.

See the following chunk of code:

> drivers/gpu/drm/i915/intel_hdmi.c:1308
>
> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
>                                struct intel_crtc_state *pipe_config,
>                                struct drm_connector_state *conn_state)
> {
>       ...  SNIP ...
>
>         /*
>          * HDMI is either 12 or 8, so if the display lets 10bpc sneak
>          * through, clamp it down. Note that g4x/vlv don't support 12bpc hdmi
>          * outputs. We also need to check that the higher clock still fits
>          * within limits.
>          */
>         if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
>             hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true) == MODE_OK &&
>             hdmi_12bpc_possible(pipe_config)) {
>                 DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
>                 desired_bpp = 12*3;
>
>                 /* Need to adjust the port link by 1.5x for 12bpc. */
>                 pipe_config->port_clock = clock_12bpc;
>         } else {
>                 DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
>                 desired_bpp = 8*3;
>
>                 pipe_config->port_clock = clock_8bpc;
>         }
> }

That check for (pipe_bpp > 24) is not right. It needs to check that BPP is
sufficient for 12bpc (eg: >= 36) rather than check that bpp is more than
sufficient for 8bpc.

Attached patch 0001-Fix-BPP-clamping-on-HDMI.patch does that, and it fixes the
problem with this monitor on the Ivybridge laptop. Corrupt output is no longer
seen.

It does not fix the problem with the NUC6I7KYK, though. I will open another bug
for that and link to it in here.

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