Created attachment 118572 [details] dmesg log SKL-Y fails HDMI CTS 1.4b test 7-27 with the following error: Iter 01: 640x480p @ 60 Hz 4:3, known Content AR Visual Aspect ratio checks were not performed. Unknown AVI aspect ratio. (No Data) To reproduce: 1. Use Quantumdata 980 HDMI protocol analyzer and execute CTS 1.4b test 7-27 "AVI InfoFrame" 2. Set the HDMI resolution on the DUT to 640x480p The problem is that the EDID requests VIC-1 but the DUT returns VIC-0 - therefore the "Unknown AVI aspect ration. (No Data)" error occurs. System architecture: x86_64 Kernel version: 4.3.0-rc2-ge29411e Linux distribution: ChromeOS-eywa Machine or motherboard model: SKL-Y RVP3 Display connector: HDMI
Created attachment 118573 [details] Quantumdata 980 CTS report and captures
I'm able to reproduce this issue on BSW as well.
+KMD owners
This doesn't fix the issue in question, but you're missing the dmc firmware: [ 0.688796] [drm:intel_csr_ucode_init] Loading i915/skl_dmc_ver1.bin [ 0.688828] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2 [ 0.688835] [drm:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (0) [ 0.688839] [drm:i915_firmware_load_error_print] *ERROR* The driver is built-in, so to load the firmware you need to include it either in the kernel (see CONFIG_EXTRA_FIRMWARE) or in your initrd/initramfs image.
The mode is a bit off: "640x480" 60 25180 640 656 752 800 480 490 492 525 0x48 0xa The real CEA mode would be: "640x480" 60 25175 640 656 752 800 480 490 492 525 0x48 0xa Seems the KHZ2PICOS trick we use in comparing the modes is a bit too strict to see that these are supposed to be the same mode. I think we'll need to revise my detailed timing fixup to take the 10kHz clock resolution limit better into account.
Created attachment 119299 [details] [review] [PATCH] drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference So I was thinking somehting like this to solve it. I would be interested in knowing if it actually works.
I'm working on it and will let you know if it did the trick. -Nathan On Fri, Oct 30, 2015 at 01:42:51PM +0000, bugzilla-daemon@freedesktop.org wrote: > Comment # 6 on bug 92217 from Ville Syrjala > > Created attachment 119299 [details] [review] [review] > [PATCH] drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to > 5kHz clock difference > > So I was thinking somehting like this to solve it. I would be interested in > knowing if it actually works. > > ---------------------------------------------------------------------- > > You are receiving this mail because: > * You reported the bug.
@Ville - I verified your patch and it passes the 640x480 mode now. I tested 1980x1080 again just to make sure and that is passing as well. The patch fixed the problem.
So resolved as fixed.
Fix was confirmed. So closed.
The patch isn't merged anywhere yet.
commit 4c6bcf44549907cb50b67f98eb13717a4adc6b33 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Nov 16 21:05:12 2015 +0200 drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference in topic/drm-misc, and therefore also nightly.
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.