The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-cml-h: Random tests - Failed assertion: ret == 0, error: -22 != 0
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_374/fi-cml-h/igt@gem_eio@kms.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_374/fi-cml-h/igt@kms_plane_lowres@pipe-c-tiling-y.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_376/fi-cml-h/igt@kms_atomic_transition@2x-modeset-transitions.html

A CI Bug Log filter associated to this bug has been updated:

{- fi-cml-h: Random tests - Failed assertion: ret == 0, error: -22 != 0 -}
{+ fi-cml-h: Random tests - Failed assertion: ret == 0, error: -22 != 0 +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_377/fi-cml-h/igt@kms_atomic_transition@2x-modeset-transitions-nonblocking.html

This is basically the same problem as bug 111185 but on fi-cml-h's DP-3 connector rather than fi-icl-u4's DP-4 connector.

Specifically, we have link training failures when attempting 2 lanes at data rate 270000

<7> [237.429108] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:123:DP-3] Link Training failed at link rate = 270000, lane count = 2

which forces us to downgrade to 2 lanes at data rate 162000:

<7> [239.250661] [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 162000 max bpp 36 pixel clock 148500KHz
<7> [239.250697] [drm:intel_dp_compute_config [i915]] Force DSC en = 0
<7> [239.250733] [drm:intel_atomic_check [i915]] Encoder config failure: -22

and this fails because the 148500 clock * a minimum RGB bpp of 18 means that we require a minimum bandwidth of 2673000/8 = 334125 to drive this mode.  Since 334125 > 270000 the modeset fails.

Since this bug and bug 111185 are caused by flaky hardware (either the board, the cable, or any dongles/adapters that are part of the link), I think it makes sense to keep a separate bug for each platform; I'm not going to mark this one as a duplicate of bug 111185, even though conceptually it's the same problem, since really the only "fix" is replacing hardware on those two separate machines.

Impact-wise, this is a CI-specific problem; it reduces the value of CI on this board, but won't impact end users (rejecting these modesets and forcing the userspace display server to pick a smaller mode is exactly what's supposed to happen).  Given that we should be able to write a bit more precise CIbuglog filters that look for "Link Training failed at link rate = XXX, lane count = X" followed later by a "Encoder config failure: -22" I think we can do a pretty good job of recognizing and filtering these failures without causing lots of false positives or false negatives, so I'm setting the importance to "low."  It's also worth noting that the hardware here doesn't seem to be as flaky as the ICL hardware in bug 111185's case, although it's possible that may change over time.

Woops, one typo; my comment should have said

 "... Since 334125 > 2*162000 the modeset fails."

-- 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/442.