From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: intel-gfx@lists.freedesktop.org, jani.saarinen@intel.com
Subject: Re: [PATCH 2/5] drm/i915: Break intel_dbuf_mbus_update into 2 separate parts
Date: Fri, 22 Mar 2024 19:50:45 +0200 [thread overview]
Message-ID: <Zf3E9XVJck_uuuJj@intel.com> (raw)
In-Reply-To: <20240322114046.24930-3-stanislav.lisovskiy@intel.com>
On Fri, Mar 22, 2024 at 01:40:43PM +0200, Stanislav Lisovskiy wrote:
> We need to be able to update dbuf min tracker and mdclk ratio
> separately if mbus_join state didn't change, so lets add one
> degree of freedom and make it possible.
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 55 ++++++++++++--------
> 1 file changed, 33 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 8ff69da664807..2b947870527fc 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3570,16 +3570,38 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private *i915, u8 ratio
> DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1));
> }
>
> +static void intel_dbuf_mdclk_min_tracker_update(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> +
> + if (DISPLAY_VER(i915) >= 20 &&
> + old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state->mdclk_cdclk_ratio) {
> + /*
> + * For Xe2LPD and beyond, when there is a change in the ratio
> + * between MDCLK and CDCLK, updates to related registers need to
> + * happen at a specific point in the CDCLK change sequence. In
> + * that case, we defer to the call to
> + * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> + */
> + return;
> + }
That whole condition I think needs to go. We want to update the ratio
also when changing mbus joining. But that behavioural change doesn't
really belong in this patch, so this is
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> +
> + intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state->mdclk_cdclk_ratio,
> + new_dbuf_state->joined_mbus);
> +}
> +
> /*
> * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus state before
> * update the request state of all DBUS slices.
> */
> -static void intel_dbuf_mbus_update(struct intel_atomic_state *state)
> +static void intel_dbuf_mbus_join_update(struct intel_atomic_state *state)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> u32 mbus_ctl;
> - const struct intel_dbuf_state *old_dbuf_state =
> - intel_atomic_get_old_dbuf_state(state);
> const struct intel_dbuf_state *new_dbuf_state =
> intel_atomic_get_new_dbuf_state(state);
>
> @@ -3600,21 +3622,6 @@ static void intel_dbuf_mbus_update(struct intel_atomic_state *state)
> intel_de_rmw(i915, MBUS_CTL,
> MBUS_HASHING_MODE_MASK | MBUS_JOIN |
> MBUS_JOIN_PIPE_SELECT_MASK, mbus_ctl);
> -
> - if (DISPLAY_VER(i915) >= 20 &&
> - old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state->mdclk_cdclk_ratio) {
> - /*
> - * For Xe2LPD and beyond, when there is a change in the ratio
> - * between MDCLK and CDCLK, updates to related registers need to
> - * happen at a specific point in the CDCLK change sequence. In
> - * that case, we defer to the call to
> - * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> - */
> - return;
> - }
> -
> - intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state->mdclk_cdclk_ratio,
> - new_dbuf_state->joined_mbus);
> }
>
> void intel_dbuf_pre_plane_update(struct intel_atomic_state *state)
> @@ -3632,8 +3639,10 @@ void intel_dbuf_pre_plane_update(struct intel_atomic_state *state)
>
> WARN_ON(!new_dbuf_state->base.changed);
>
> - if (!old_dbuf_state->joined_mbus && new_dbuf_state->joined_mbus)
> - intel_dbuf_mbus_update(state);
> + if (!old_dbuf_state->joined_mbus && new_dbuf_state->joined_mbus) {
> + intel_dbuf_mbus_join_update(state);
> + intel_dbuf_mdclk_min_tracker_update(state);
> + }
>
> gen9_dbuf_slices_update(i915,
> old_dbuf_state->enabled_slices |
> @@ -3655,8 +3664,10 @@ void intel_dbuf_post_plane_update(struct intel_atomic_state *state)
>
> WARN_ON(!new_dbuf_state->base.changed);
>
> - if (old_dbuf_state->joined_mbus && !new_dbuf_state->joined_mbus)
> - intel_dbuf_mbus_update(state);
> + if (old_dbuf_state->joined_mbus && !new_dbuf_state->joined_mbus) {
> + intel_dbuf_mbus_join_update(state);
> + intel_dbuf_mdclk_min_tracker_update(state);
> + }
>
> gen9_dbuf_slices_update(i915,
> new_dbuf_state->enabled_slices);
> --
> 2.37.3
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2024-03-22 17:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 11:40 [PATCH 0/5] Enable fastset for mbus_join state change Stanislav Lisovskiy
2024-03-22 11:40 ` [PATCH 1/5] drm/i915: Update mbus in intel_dbuf_mbus_update and do it properly Stanislav Lisovskiy
2024-03-22 17:46 ` Ville Syrjälä
2024-03-22 11:40 ` [PATCH 2/5] drm/i915: Break intel_dbuf_mbus_update into 2 separate parts Stanislav Lisovskiy
2024-03-22 17:50 ` Ville Syrjälä [this message]
2024-03-22 11:40 ` [PATCH 3/5] drm/i915: Use old mbus_join value when increasing CDCLK Stanislav Lisovskiy
2024-03-22 17:45 ` Ville Syrjälä
2024-03-25 14:44 ` Gustavo Sousa
2024-03-25 14:55 ` Ville Syrjälä
2024-03-22 11:40 ` [PATCH 4/5] drm/i915: Loop over all active pipes in intel_mbus_dbox_update Stanislav Lisovskiy
2024-03-22 17:51 ` Ville Syrjälä
2024-03-22 11:40 ` [PATCH 5/5] drm/i915: Implement vblank synchronized MBUS join changes Stanislav Lisovskiy
2024-03-22 18:06 ` Ville Syrjälä
2024-03-25 8:59 ` Lisovskiy, Stanislav
2024-03-25 9:09 ` [PATCH 3/3] " Stanislav Lisovskiy
2024-03-22 12:28 ` ✗ Fi.CI.CHECKPATCH: warning for Enable fastset for mbus_join state change (rev2) Patchwork
2024-03-22 12:41 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-23 8:31 ` ✗ 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=Zf3E9XVJck_uuuJj@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.saarinen@intel.com \
--cc=stanislav.lisovskiy@intel.com \
/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.