Skip to content

L
linux
Switch branch/tag
  1. 11 Jan, 2022 1 commit
    • Liu Ying's avatar
      drm/atomic: Check new_crtc_state->active to determine if CRTC needs disable in self refresh mode · 69e63001
      Liu Ying authored 
      Actual hardware state of CRTC is controlled by the member 'active' in
struct drm_crtc_state instead of the member 'enable', according to the
kernel doc of the member 'enable'.  In fact, the drm client modeset
and atomic helpers are using the member 'active' to do the control.

Referencing the member 'enable' of new_crtc_state, the function
crtc_needs_disable() may fail to reflect if CRTC needs disable in
self refresh mode, e.g., when the framebuffer emulation will be blanked
through the client modeset helper with the next commit, the member
'enable' of new_crtc_state is still true while the member 'active' is
false, hence the relevant potential encoder and bridges won't be disabled.

So, let's check new_crtc_state->active to determine if CRTC needs disable
in self refresh mode instead of new_crtc_state->enable.

Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarLiu Ying <victor.liu@nxp.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211230040626.646807-1-victor.liu@nxp.com
      69e63001
  3. 22 Dec, 2021 1 commit
  5. 17 Dec, 2021 8 commits
  7. 16 Dec, 2021 16 commits
  9. 15 Dec, 2021 1 commit
    • 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
  11. 14 Dec, 2021 3 commits
  13. 13 Dec, 2021 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7