| Summary: | [Gemini Lake] HDMI 2.0 compliance test failed - HF1-34 Video timing YCbCr 420 deep color | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | JingWu Lin <jingwu.lin> | ||||||||
| Component: | DRM/Intel | Assignee: | Clinton Taylor <clinton.a.taylor> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
| Severity: | major | ||||||||||
| Priority: | highest | CC: | intel-gfx-bugs, lakshminarayana.vudum | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||||||
| i915 platform: | GLK | i915 features: | display/HDMI | ||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 107905 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
JingWu Lin
2018-09-11 03:19:30 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. Created attachment 141557 [details]
kernel log
board: GLK RVP
kernel: Linux version 4.19.0-rc2-drm-tip-2018y-09m-04d+
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). Jingwu,
Can you attach a copy of the EDID xml file being used during the compliance tests?
Thanks
Created attachment 141674 [details]
test EDID for HF1-34
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. GLK output unstable on QD980B analyzers. Trying to determine reason why QD980B is reporting many errors before this item can be addressed. 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. Actually the 12bpc 4K mode does work as long as it's the first modeset. Subsequent modesets do not yield correct video timings. 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. Patch at DRI-Devel mailing list has not received a review yet. RB received for upstream patch. (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.