https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7093/re-tgl-u/igt@kms_plane_scaling@2x-scaler-multi-pipe.html Starting subtest: 2x-scaler-multi-pipe (kms_plane_scaling:1493) igt_kms-CRITICAL: Test assertion failure function do_display_commit, file ../lib/igt_kms.c:3464: (kms_plane_scaling:1493) igt_kms-CRITICAL: Failed assertion: ret == 0 (kms_plane_scaling:1493) igt_kms-CRITICAL: Last errno: 22, Invalid argument (kms_plane_scaling:1493) igt_kms-CRITICAL: error: -22 != 0 Subtest 2x-scaler-multi-pipe failed.
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * TGL: igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed assertion: ret == 0 - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7093/re-tgl-u/igt@kms_plane_scaling@2x-scaler-multi-pipe.html
From logs it can be seen <7> [886.185133] [drm:intel_atomic_setup_scalers [i915]] Too many scaling requests 3 > 2 Available 2 scalers, however requested for 3. Can this cause an issue?
Yes, Swati is correct; the issue is that the test is trying to use too many scalers. The test only explicitly enables two plane scalers per pipe, but fails to account for one of the scalers already being used by the pipe (i.e., in "panel fitter" mode). In this case, the second display is driving a YCbCr display which necessitates the use of a pipe scaler even in cases where the resolution does not change: <7> [152.668726] [drm:skl_update_scaler [i915]] scaler_user index 1.31: staged scaling request for 3840x2160->3840x2160 scaler_users = 0x80000000 ... <7> [154.169675] [drm:intel_dump_pipe_config [i915]] active: yes, output_types: HDMI (0x40), output format: YCBCR4:2:0 Once we try to activate scaling on two planes, our scaler user bitmask for the second display has three bits turned on (highest bit in the mask is the crtc): <7> [154.115560] [drm:skl_update_scaler [i915]] scaler_user index 0.1: staged scaling request for 500x500->3840x2160 scaler_users = 0x3 <7> [154.115676] [drm:skl_update_scaler [i915]] scaler_user index 1.9: staged scaling request for 400x400->3840x2160 scaler_users = 0x80000300 which ultimately results in the kernel rejecting the atomic transaction as invalid as Swati pointed out: <7> [154.115816] [drm:intel_atomic_setup_scalers [i915]] Too many scaling requests 3 > 2 This is exactly the behavior we want --- kernel properly rejects userspace requests that it doesn't have the resources to handle. Real userspace would take the failure into account and try again with a different compositing strategy. Unfortunately our IGT tests are trying to use insider knowledge of the hardware resources, but failing to account for CRTC scaler usage due to YUV outputs, which leads to a false positive failure. This should be fixed on the IGT side; there's no impact to end users, only to CI. Setting priority/exposure to low.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/513.
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.