• Maxime Ripard's avatar
    drm/vc4: kms: Wait for the commit before increasing our clock rate · 244a36e5
    Maxime Ripard authored
    Several DRM/KMS atomic commits can run in parallel if they affect
    different CRTC. These commits share the global HVS state, so we have
    some code to make sure we run commits in sequence. This synchronization
    code is one of the first thing that runs in vc4_atomic_commit_tail().
    
    Another constraints we have is that we need to make sure the HVS clock
    gets a boost during the commit. That code relies on clk_set_min_rate and
    will remove the old minimum and set a new one. We also need another,
    temporary, minimum for the duration of the commit.
    
    The algorithm is thus to set a temporary minimum, drop the previous
    one, do the commit, and finally set the minimum for the current mode.
    
    However, the part that sets the temporary minimum and drops the older
    one runs before the commit synchronization code.
    
    Thus, under the proper conditions, we can end up mixing up the minimums
    and ending up with the wrong one for our current step.
    
    To avoid it, let's move the clock setup in the protected section.
    
    Fixes: d7d96c00 ("drm/vc4: hvs: Boost the core clock during modeset")
    Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
    Reviewed-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
    Tested-by: default avatarJian-Hong Pan <jhp@endlessos.org>
    [danvet: re-apply this from 0c980a00 ("drm/vc4: kms: Wait for the
    commit before increasing our clock rate") because I lost that part in
    my merge resolution in 99b03ca6 ("Merge v5.16-rc5 into drm-next")]
    Fixes: 99b03ca6 ("Merge v5.16-rc5 into drm-next")
    Acked-by: default avatarMaxime Ripard <maxime@cerno.tech>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
    Link: https://lore.kernel.org/r/20211117094527.146275-2-maxime@cerno.tech
    244a36e5
vc4_kms.c 26.8 KB