drm/i915: Fix fastsets on TypeC ports following a non-blocking modeset
authorImre Deak <imre.deak@intel.com>
Mon, 15 Nov 2021 18:11:21 +0000 (20:11 +0200)
committerImre Deak <imre.deak@intel.com>
Wed, 17 Nov 2021 16:54:16 +0000 (18:54 +0200)
commita59308a5fb231aca72b9b070a6577fa49ec2d72a
tree8c7535760eea0cd9f52a3f60da9e682245934f7c
parentfe69a2dd88b2c741bd55336d74dd484d7b848679
drm/i915: Fix fastsets on TypeC ports following a non-blocking modeset

After a non-blocking modeset on a TypeC port's CRTC - possibly blocked
later in drm_atomic_helper_wait_for_dependencies() - a fastset on the
same CRTC may copy the state of CRTC before this gets updated to reflect
the up-to-date DP-alt vs. TBT-alt TypeC mode DPLL used for the CRTC. In
this case after the first (non-blocking) commit completes enabling the
DPLL required for the up-to-date TypeC mode the following fastset will
update the CRTC state pointing to the wrong DPLL. A subsequent disabling
modeset will try to disable the wrong PLL, triggering a state checker
WARN (and leaving the DPLL which is actually used active for good).

Fix the above race by copying the DPLL state for fastset CRTCs from the
old CRTC state at the point where it's guaranteed to be up-to-date
already. This could be handled in the encoder's update_prepare() hook as
well, but that's a bigger change, which is better done as a follow-up.

v2: Copy dpll_hw_state as well. (Ville)

Testcase: igt/kms_busy/extended-modeset-hang-newfb-with-reset
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4308
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211115181121.156197-1-imre.deak@intel.com
drivers/gpu/drm/i915/display/intel_display.c