Bug 107894 - [Gemini Lake] HDMI 2.0 compliance test failed - HF1-51 AVI InfoFrame for Y420VDB and Y420CMBD
Summary: [Gemini Lake] HDMI 2.0 compliance test failed - HF1-51 AVI InfoFrame for Y420...
Status: CLOSED FIXED
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
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks: 107905
  Show dependency tree / graph
 
Reported: 2018-09-11 03:23 UTC by JingWu Lin
Modified: 2018-12-28 12:20 UTC (History)
3 users (show)

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

Attachments
C (59.42 KB, image/jpeg)
2018-09-11 03:23 UTC, JingWu Lin 		no flags Details
VIC=0 (59.42 KB, image/jpeg)
2018-09-11 05:34 UTC, JingWu Lin 		no flags Details
kernel log (1.03 MB, text/plain)
2018-09-16 13:25 UTC, JingWu Lin 		no flags Details
Test patch correctly generates AVI IF VIC for YCbCr420 modes (653 bytes, patch)
2018-10-16 22:43 UTC, Clinton Taylor 		no flags Details | Splinter Review
Show Obsolete (1) View All

Description JingWu Lin 2018-09-11 03:23:24 UTC 
Created attachment 141514 [details]
C

GKL fails HDMI 2.0 compliance test HF1-51 AVI InfoFrame for Y420VDB and Y420CMBD.

The VIC is 0 in YCBCR420 from the HDMI output signal  (the expected VIC are 96,97,101,102).
Comment 1 JingWu Lin 2018-09-11 05:34:51 UTC 
Created attachment 141519 [details]
VIC=0
Comment 2 Lakshmi 2018-09-11 06:30:09 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 3 JingWu Lin 2018-09-16 13:25:10 UTC 
Created attachment 141582 [details]
kernel log

board: GLK RVP
kernel: Linux version 4.19.0-rc2-drm-tip-2018y-09m-04d+
Comment 4 Clinton Taylor 2018-10-02 23:45:03 UTC 
Unable to duplicate this issue on an Astro VA-1842 HDMI Protocol Analyzer. A QD980B with 18G HDMI analyzer show unstable video and the CTA VIC 0 appears when the AVI infoframe is not updating. Working with Quantum Data to determine device stability issues. 
  
Is the output displayed on the QD980 in the attached picture stable?
Comment 5 Clinton Taylor 2018-10-12 21:25:05 UTC 
VDB data block doesn't appear to be decoded correctly during EDID parse. Trying to determine why QD980 EDID VDB modes are being rejected.
Comment 6 Clinton Taylor 2018-10-15 23:47:01 UTC 
Duplicated this result using libdrm modetest. Investigation continues.
Comment 7 Clinton Taylor 2018-10-16 17:02:05 UTC 
During drm_hdmi_avi_infoframe_from_display_mode() the code assumes a VIC of 95 and without SCDC supported is an illegal value and sets the VIC to 0.

Of course in YCbCr420 mode a VIC of 95 doesn't require SCDC to be supported and the test equipment is not enabling SCDC. The i915 drivers assumption that SCDC supported is the only way to know that the SINK is HDMI 2.0 is incorrect.
Comment 8 Ville Syrjala 2018-10-16 17:49:22 UTC 
(In reply to Clinton Taylor from comment #7)
> During drm_hdmi_avi_infoframe_from_display_mode() the code assumes a VIC of
> 95 and without SCDC supported is an illegal value and sets the VIC to 0.
> 
> Of course in YCbCr420 mode a VIC of 95 doesn't require SCDC to be supported
> and the test equipment is not enabling SCDC. The i915 drivers assumption
> that SCDC supported is the only way to know that the SINK is HDMI 2.0 is
> incorrect.

I suppose we could just look for the HDMI forum vsdb instead?
Comment 9 Clinton Taylor 2018-10-16 20:47:52 UTC 
> I suppose we could just look for the HDMI forum vsdb instead?

Still not enough as some 64:27 modes are HDMI 2.0 VICs and they could just be located in the DTD's. Ex. VIC 90 (2560x1080@60) is an HDMI 2.0 VIC that doesn't require scrambling and wouldn't be included in the vsdb. However, 2560x1080@60 is native in many HDMI 1.X monitors. 

My current fix for this compliance issue is:

bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported ||
				crtc_state->ycbcr420;

to check for a YCbCr420. However this only fixes the problem for VIC 95, 96, etc. I still need to find a solution for other HDMI 2.0 VICs. Maybe OR in vsdb present, OR HDMI forum vendor data block present. Need to cover as many cases as necessary or we are just moving the problem to another test failure.
Comment 10 Clinton Taylor 2018-10-16 21:01:31 UTC 
and the QD980B doesn't generate a HDMI Forum VSDB during CTS 2.0 compliance tests that doesn't require one to be in the EDID.
Comment 11 Clinton Taylor 2018-10-16 22:43:48 UTC 
Created attachment 142064 [details] [review]
Test patch correctly generates AVI IF VIC for YCbCr420 modes

Please test this patch to confirm HF1-51 compliance passes correctly.
Comment 12 Clinton Taylor 2018-10-17 23:15:13 UTC 
https://patchwork.freedesktop.org/patch/257241/
Comment 13 Lakshmi 2018-10-24 11:57:13 UTC 
Clint, any further updates here?
Comment 14 Clinton Taylor 2018-10-24 21:27:09 UTC 
Patch V2 submitted upstream:
https://patchwork.freedesktop.org/patch/258300/

reviews welcome
Comment 15 Clinton Taylor 2018-10-26 20:17:06 UTC 
pushed to drm-misc-next
Comment 16 Francesco Balestrieri 2018-12-28 09:23:03 UTC 
JingWu Lin, do you confirm that the issue is resolved?

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.