Starting subtest: dpms-vs-vblank-race
(kms_flip:1362) igt_kms-CRITICAL: Test assertion failure function kmstest_set_connector_dpms, file ../lib/igt_kms.c:1367:
(kms_flip:1362) igt_kms-CRITICAL: Failed assertion: drmModeConnectorSetProperty(fd, connector->connector_id, dpms, mode) == 0
(kms_flip:1362) igt_kms-CRITICAL: Last errno: 22, Invalid argument
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* ICL: igt@kms_flip@dpms-vs-vblank-race - fail - Failed assertion: drmModeConnectorSetProperty(fd, connector->connector_id, dpms, mode) == 0
Another link training failure that results in us not being able to drive the requested mode. The IGT signature is slightly different this time because the failure happens while using the legacy ConnectorSetProperty() interface to toggle DPMS, rather than the more common modesetting interfaces, but the end result is the same --- the underlying atomic transaction is rejected and EINVAL (22) is propagated up to userspace as the error code.
In this case the modeline being attempted is
"1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
The 148500 clock on this mode * a minimum RGB bpp of 18 means that we require a data rate of 2683000/8 = 334125 to drive this mode. However the previous link training gave us
<7> [354.746236] [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 162000 max bpp 24 pixel clock 148500KHz
Since 334125 > 2*162000, we don't have enough bandwidth to drive the desired mode.
*** This bug has been marked as a duplicate of bug 111185 ***