Bug 107894

Summary: [Gemini Lake] HDMI 2.0 compliance test failed - HF1-51 AVI InfoFrame for Y420VDB and Y420CMBD
Product: DRI Reporter: JingWu Lin <jingwu.lin>
Component: DRM/IntelAssignee: Clinton Taylor <clinton.a.taylor>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: highest CC: clinton.a.taylor, 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 Flags
C
none
VIC=0
none
kernel log
none
Test patch correctly generates AVI IF VIC for YCbCr420 modes none

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.