All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 1/3] drm/i915/cdclk: Fix CDCLK programming order when pipes are active
Date: Tue, 26 Mar 2024 22:31:26 +0200	[thread overview]
Message-ID: <20240326203128.10259-2-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20240326203128.10259-1-ville.syrjala@linux.intel.com>

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Currently we always reprogram CDCLK from the
intel_set_cdclk_post_plane_update() when using squahs/crawl.
The code only works correctly for the cd2x update or full
modeset cases, and it was simply never updated to deal with
squash/crawl.

If the CDCLK frequency is increasing we must reprogram it
before we do anything else that might depend on the new
higher frequency, and conversely we must not decrease
the frequency until everything that might still depend
on the old higher frequency has been dealt with.

So let us only consider the relationship of the old and
new CDCLK frequencies when determining where to do
the reprogramming, regarless of whether all pipes might
be off or not at the time.

If the CDCLK freqiency remains unchanges we may still have to
do the reprogramming to change the voltage_level. Currently
we do that from intel_set_cdclk_pre_plane_update() which
probably is the right choice most of the time. The only
counterexample is when the voltage_level needs to increase
due to a DDI port, but the CDCLK frequency is decreasing.
The current approach will not bump the voltage level up until
after the port has already been enabled, which is too late.
But we'll take care of that case separately.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 31aaa9780dfc..49e2f09a796a 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2600,7 +2600,6 @@ intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state)
 		intel_atomic_get_old_cdclk_state(state);
 	const struct intel_cdclk_state *new_cdclk_state =
 		intel_atomic_get_new_cdclk_state(state);
-	enum pipe pipe = new_cdclk_state->pipe;
 
 	if (!intel_cdclk_changed(&old_cdclk_state->actual,
 				 &new_cdclk_state->actual))
@@ -2609,11 +2608,11 @@ intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state)
 	if (IS_DG2(i915))
 		intel_cdclk_pcode_pre_notify(state);
 
-	if (pipe == INVALID_PIPE ||
-	    old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
+	if (old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
 		drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
 
-		intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
+		intel_set_cdclk(i915, &new_cdclk_state->actual,
+				new_cdclk_state->pipe);
 	}
 }
 
@@ -2632,7 +2631,6 @@ intel_set_cdclk_post_plane_update(struct intel_atomic_state *state)
 		intel_atomic_get_old_cdclk_state(state);
 	const struct intel_cdclk_state *new_cdclk_state =
 		intel_atomic_get_new_cdclk_state(state);
-	enum pipe pipe = new_cdclk_state->pipe;
 
 	if (!intel_cdclk_changed(&old_cdclk_state->actual,
 				 &new_cdclk_state->actual))
@@ -2641,11 +2639,11 @@ intel_set_cdclk_post_plane_update(struct intel_atomic_state *state)
 	if (IS_DG2(i915))
 		intel_cdclk_pcode_post_notify(state);
 
-	if (pipe != INVALID_PIPE &&
-	    old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
+	if (old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
 		drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
 
-		intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
+		intel_set_cdclk(i915, &new_cdclk_state->actual,
+				new_cdclk_state->pipe);
 	}
 }
 
-- 
2.43.2


  reply	other threads:[~2024-03-26 20:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26 20:31 [PATCH 0/3] drm/i915/cdclk: CDCLK fixes Ville Syrjala
2024-03-26 20:31 ` Ville Syrjala [this message]
2024-03-26 21:22   ` [PATCH 1/3] drm/i915/cdclk: Fix CDCLK programming order when pipes are active Ville Syrjälä
2024-03-26 21:42   ` Gustavo Sousa
2024-03-26 21:50     ` Ville Syrjälä
2024-03-26 22:10   ` [PATCH v2 " Ville Syrjala
2024-03-28 11:34     ` Shankar, Uma
2024-03-26 20:31 ` [PATCH 2/3] drm/i915/cdclk: Fix voltage_level programming edge case Ville Syrjala
2024-03-26 22:10   ` [PATCH v2 " Ville Syrjala
2024-03-26 20:31 ` [PATCH 3/3] drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks Ville Syrjala
2024-03-27  1:49 ` ✗ Fi.CI.SPARSE: warning for drm/i915/cdclk: CDCLK fixes (rev3) Patchwork
2024-03-27  2:04 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-27 15:50 ` ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240326203128.10259-2-ville.syrjala@linux.intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.