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 01/13] drm/i915/cdclk: Fix CDCLK programming order when pipes are active
Date: Wed, 27 Mar 2024 19:45:32 +0200	[thread overview]
Message-ID: <20240327174544.983-2-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20240327174544.983-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_pre_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.

Since cdclk_state->pipe is only relevant when doing a cd2x
update we can't use it to determine the correct sequence
during squash/crawl. To that end introduce cdclk_state->disable_pipes
which simply indicates that we must perform the update
while the pipes are disable (ie. during
intel_set_cdclk_pre_plane_update()). Otherwise we use the
same old vs. new CDCLK frequency comparsiong as for cd2x
updates.

The only remaining problem case is when the voltage_level
needs to increase due to a DDI port, but the CDCLK frequency
is decreasing (and not all pipes are being disabled). 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.

v2: Don't break the "must disable pipes case"

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +++++++++------
 drivers/gpu/drm/i915/display/intel_cdclk.h |  3 +++
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 31aaa9780dfc..619529dba095 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,12 @@ 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 ||
+	if (new_cdclk_state->disable_pipes ||
 	    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 +2632,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 +2640,12 @@ 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 &&
+	if (!new_cdclk_state->disable_pipes &&
 	    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);
 	}
 }
 
@@ -3124,6 +3124,7 @@ static struct intel_global_state *intel_cdclk_duplicate_state(struct intel_globa
 		return NULL;
 
 	cdclk_state->pipe = INVALID_PIPE;
+	cdclk_state->disable_pipes = false;
 
 	return &cdclk_state->base;
 }
@@ -3316,6 +3317,8 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state *state)
 		if (ret)
 			return ret;
 
+		new_cdclk_state->disable_pipes = true;
+
 		drm_dbg_kms(&dev_priv->drm,
 			    "Modeset required for cdclk change\n");
 	}
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h b/drivers/gpu/drm/i915/display/intel_cdclk.h
index bc8f86e292d8..2843fc091086 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -53,6 +53,9 @@ struct intel_cdclk_state {
 
 	/* bitmask of active pipes */
 	u8 active_pipes;
+
+	/* update cdclk with pipes disabled */
+	bool disable_pipes;
 };
 
 int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state);
-- 
2.43.2


  reply	other threads:[~2024-03-27 17:45 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 17:45 [PATCH 00/13] drm/i915: Implemnt vblank sycnhronized mbus joining changes Ville Syrjala
2024-03-27 17:45 ` Ville Syrjala [this message]
2024-03-28  9:16   ` [PATCH 01/13] drm/i915/cdclk: Fix CDCLK programming order when pipes are active Murthy, Arun R
2024-03-28 12:32     ` Ville Syrjälä
2024-03-28 11:35   ` Shankar, Uma
2024-03-29 15:29   ` Gustavo Sousa
2024-04-03 15:51     ` Ville Syrjälä
2024-03-27 17:45 ` [PATCH 02/13] drm/i915/cdclk: Fix voltage_level programming edge case Ville Syrjala
2024-03-28 11:40   ` Shankar, Uma
2024-03-29 17:04   ` Gustavo Sousa
2024-04-02 14:56     ` Ville Syrjälä
2024-03-27 17:45 ` [PATCH 03/13] drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks Ville Syrjala
2024-03-28 11:48   ` Shankar, Uma
2024-03-27 17:45 ` [PATCH 04/13] drm/i915/cdclk: Indicate whether CDCLK change happens during pre or post plane update Ville Syrjala
2024-03-28 11:51   ` Shankar, Uma
2024-03-29 17:14   ` Gustavo Sousa
2024-03-27 17:45 ` [PATCH 05/13] drm/i915: Loop over all active pipes in intel_mbus_dbox_update Ville Syrjala
2024-03-28 11:53   ` Shankar, Uma
2024-03-27 17:45 ` [PATCH 06/13] drm/i915: Relocate intel_mbus_dbox_update() Ville Syrjala
2024-03-28 11:54   ` Shankar, Uma
2024-03-29 18:28   ` Gustavo Sousa
2024-03-27 17:45 ` [PATCH 07/13] drm/i915: Extract intel_dbuf_mbus_join_update() Ville Syrjala
2024-03-28 11:57   ` Shankar, Uma
2024-03-29 18:29   ` Gustavo Sousa
2024-03-27 17:45 ` [PATCH 08/13] drm/i915: Extract intel_dbuf_mdclk_min_tracker_update() Ville Syrjala
2024-03-28 12:01   ` Shankar, Uma
2024-03-29 18:31   ` Gustavo Sousa
2024-03-27 17:45 ` [PATCH 09/13] drm/i915: Add debugs for mbus joining and dbuf ratio programming Ville Syrjala
2024-03-28 12:04   ` Shankar, Uma
2024-03-29 18:32   ` Gustavo Sousa
2024-03-27 17:45 ` [PATCH 10/13] drm/i915: Use old mbus_join value when increasing CDCLK Ville Syrjala
2024-03-28 12:07   ` Shankar, Uma
2024-03-27 17:45 ` [PATCH 11/13] drm/i915: Implement vblank synchronized MBUS join changes Ville Syrjala
2024-03-28 16:08   ` Shankar, Uma
2024-03-29 18:15   ` Gustavo Sousa
2024-04-02 14:25     ` Ville Syrjälä
2024-03-27 17:45 ` [PATCH 12/13] drm/i915: Use a plain old int for the cdclk/mdclk ratio Ville Syrjala
2024-03-28 16:09   ` Shankar, Uma
2024-03-29 18:23   ` Gustavo Sousa
2024-04-02 14:49     ` Ville Syrjälä
2024-03-27 17:45 ` [PATCH 13/13] drm/i915: Optimize out redundant dbuf slice updates Ville Syrjala
2024-03-28 16:12   ` Shankar, Uma
2024-03-27 22:44 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Implemnt vblank sycnhronized mbus joining changes Patchwork
2024-03-28 14:50 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-28 15:58 ` Patchwork
2024-03-28 16:15 ` ✓ Fi.CI.IGT: " Patchwork
2024-03-28 16:16 ` [PATCH 00/13] " Shankar, Uma
2024-03-28 18:35 ` ✓ Fi.CI.IGT: success for " Patchwork
2024-03-28 20:30 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-03-29  4:42 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Implemnt vblank sycnhronized mbus joining changes (rev2) Patchwork
2024-03-29  5:00 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-30  2:41 ` ✓ Fi.CI.IGT: " 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=20240327174544.983-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.