Bug 107893 - [Gemini Lake] HDMI 2.0 compliance test failed - HF1-34 Video timing YCbCr 420 deep color
Summary: [Gemini Lake] HDMI 2.0 compliance test failed - HF1-34 Video timing YCbCr 420...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: highest major
Assignee: Clinton Taylor
QA Contact: Intel GFX Bugs mailing list
Whiteboard: Triaged, ReadyForDev
Depends on:
Blocks: 107905
  Show dependency treegraph
Reported: 2018-09-11 03:19 UTC by JingWu Lin
Modified: 2018-10-16 13:53 UTC (History)
2 users (show)

See Also:
i915 platform: GLK
i915 features: display/HDMI

kernel log (1.02 MB, text/plain)
2018-09-14 06:24 UTC, JingWu Lin
no flags Details
test EDID for HF1-34 (1.85 KB, application/zip)
2018-09-21 15:40 UTC, JingWu Lin
no flags Details
HF VSDB YCbCr420 bit definition patch (687 bytes, patch)
2018-10-03 21:45 UTC, Clinton Taylor
no flags Details | Splinter Review

Description JingWu Lin 2018-09-11 03:19:30 UTC
GKL fails HDMI 2.0 compliance test HF1-34 Video timing YCbCr 420 deep color.

This item is failed because it cannot detect the 36bpp signal from the source (the Geminilake platform) in YCBCR420 (only has 24bpp).
Comment 1 Lakshmi 2018-09-11 06:31:34 UTC
Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Comment 2 JingWu Lin 2018-09-14 06:24:59 UTC
Created attachment 141557 [details]
kernel log

board: GLK RVP
kernel: Linux version 4.19.0-rc2-drm-tip-2018y-09m-04d+
Comment 3 Lakshmi 2018-09-14 10:08:28 UTC
Priority is set to Highest as this is blocking the customer to pass GKL devices as they are lacking the logo/sticker (Compliance test - pass certificate).
Comment 4 Clinton Taylor 2018-09-20 21:02:01 UTC
    Can you attach a copy of the EDID xml file being used during the compliance tests?

Comment 5 JingWu Lin 2018-09-21 15:40:13 UTC
Created attachment 141674 [details]
test EDID for HF1-34
Comment 6 Ville Syrjala 2018-09-21 16:14:24 UTC
The EDIDs seem to have a video format preference data block. That is something we don't parse and thus we don't mark the VIC 102 as the preferred mode. Which may explain the failure.

In drm we can only really have a single preferred mode, so I guess we should only pick up the first entry from the preference data block. If we really want to sort the modes based on multiple entries in the preference data block we would have to extend our internal mode structure with some kind of preference number rather than just relying on a single flag. Not impossible, but a bit more work than just grabbing the first mode from the preference data block and marking it as the preferred mode.
Comment 7 Clinton Taylor 2018-09-26 23:57:36 UTC
GLK output unstable on QD980B analyzers. Trying to determine reason why QD980B is reporting many errors before this item can be addressed.
Comment 8 Clinton Taylor 2018-10-03 18:04:08 UTC
found incorrect bit definitions for DC YCbCr420 mode support in drm_edid.h. After correcting the bit definitions the mode still doesn't get set properly. 
Continuing investigation.
Comment 9 Clinton Taylor 2018-10-03 19:39:15 UTC
Actually the 12bpc 4K mode does work as long as it's the first modeset. Subsequent modesets do not yield correct video timings.
Comment 10 Clinton Taylor 2018-10-03 21:45:56 UTC
Created attachment 141865 [details] [review]
HF VSDB YCbCr420 bit definition patch

HF VSDB byte 7 bit definitions were incorrect for YCbCr420 Deep Color modes. Changes to /include/drm/drm_edid.h to reflect actual bit locations.

With this patch YCbCr420 36 bit Deep Color is available, but there still appears to be an issue switching modes. Please confirm that you are seeing YCbCr420 deep color with this patch.
Comment 11 Clinton Taylor 2018-10-12 21:12:50 UTC
Patch at DRI-Devel mailing list has not received a review yet.
Comment 12 Clinton Taylor 2018-10-15 22:09:09 UTC
RB received for upstream patch.
Comment 13 Jani Nikula 2018-10-16 13:53:24 UTC
(In reply to Clinton Taylor from comment #12)
> RB received for upstream patch.

We generally don't resolve fixed until the patch has actually been committed to an upstream branch. Sometimes it takes a while...

But it's now in drm-misc-fixes and thus drm-tip:

commit 9068e02f58740778d8270840657f1e250a2cc60f
Author: Clint Taylor <clinton.a.taylor@intel.com>
Date:   Fri Oct 5 14:52:15 2018 -0700

    drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.