Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 1月, 2022 2 次提交
  3. 11 1月, 2022 1 次提交
    • L
      drm/atomic: Check new_crtc_state->active to determine if CRTC needs disable in self refresh mode · 69e63001
      由 Liu Ying 提交于 
      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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLiu Ying <victor.liu@nxp.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211230040626.646807-1-victor.liu@nxp.com
      69e63001
  5. 23 12月, 2021 1 次提交
  7. 17 12月, 2021 8 次提交
  9. 16 12月, 2021 16 次提交
  11. 15 12月, 2021 1 次提交
    • M
      drm/vc4: kms: Wait for the commit before increasing our clock rate · 244a36e5
      由 Maxime Ripard 提交于 
      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: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Tested-by: NJian-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: NMaxime Ripard <maxime@cerno.tech>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://lore.kernel.org/r/20211117094527.146275-2-maxime@cerno.tech
      244a36e5
  13. 14 12月, 2021 4 次提交
  15. 13 12月, 2021 7 次提交