From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/15] drm/i915: Extract skl_crtc_calc_dbuf_bw()
Date: Thu, 27 Jan 2022 10:24:52 +0200 [thread overview]
Message-ID: <20220127082452.GF31846@intel.com> (raw)
In-Reply-To: <20220118092354.11631-7-ville.syrjala@linux.intel.com>
On Tue, Jan 18, 2022 at 11:23:45AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Extract the dbuf slice data_rate calculation into a small
> helper. Should make it a bit easier to handle the different
> color planes of planar formats correctly.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 82 +++++++++++++------------
> 1 file changed, 44 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index c35bad21b657..f0d6fad048c7 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -672,6 +672,49 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
> return to_intel_bw_state(bw_state);
> }
>
> +static void skl_crtc_calc_dbuf_bw(struct intel_bw_state *bw_state,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct intel_dbuf_bw *crtc_bw = &bw_state->dbuf_bw[crtc->pipe];
> + enum plane_id plane_id;
> +
> + memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> +
> + if (!crtc_state->hw.active)
> + return;
> +
> + for_each_plane_id_on_crtc(crtc, plane_id) {
> + const struct skl_ddb_entry *ddb_y =
> + &crtc_state->wm.skl.plane_ddb_y[plane_id];
> + const struct skl_ddb_entry *ddb_uv =
> + &crtc_state->wm.skl.plane_ddb_uv[plane_id];
> + unsigned int data_rate = crtc_state->data_rate[plane_id];
> + unsigned int dbuf_mask = 0;
> + enum dbuf_slice slice;
> +
> + dbuf_mask |= skl_ddb_dbuf_slice_mask(i915, ddb_y);
> + dbuf_mask |= skl_ddb_dbuf_slice_mask(i915, ddb_uv);
> +
> + /*
> + * FIXME: To calculate that more properly we probably
> + * need to split per plane data_rate into data_rate_y
> + * and data_rate_uv for multiplanar formats in order not
> + * to get accounted those twice if they happen to reside
> + * on different slices.
> + * However for pre-icl this would work anyway because
> + * we have only single slice and for icl+ uv plane has
> + * non-zero data rate.
> + * So in worst case those calculation are a bit
> + * pessimistic, which shouldn't pose any significant
> + * problem anyway.
> + */
> + for_each_dbuf_slice_in_mask(i915, slice, dbuf_mask)
> + crtc_bw->used_bw[slice] += data_rate;
> + }
> +}
> +
> int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> @@ -684,50 +727,13 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
> int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - enum plane_id plane_id;
> - struct intel_dbuf_bw *crtc_bw;
> -
> new_bw_state = intel_atomic_get_bw_state(state);
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> old_bw_state = intel_atomic_get_old_bw_state(state);
>
> - crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe];
> -
> - memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> -
> - if (!crtc_state->hw.active)
> - continue;
> -
> - for_each_plane_id_on_crtc(crtc, plane_id) {
> - const struct skl_ddb_entry *plane_alloc =
> - &crtc_state->wm.skl.plane_ddb_y[plane_id];
> - const struct skl_ddb_entry *uv_plane_alloc =
> - &crtc_state->wm.skl.plane_ddb_uv[plane_id];
> - unsigned int data_rate = crtc_state->data_rate[plane_id];
> - unsigned int dbuf_mask = 0;
> - enum dbuf_slice slice;
> -
> - dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, plane_alloc);
> - dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, uv_plane_alloc);
> -
> - /*
> - * FIXME: To calculate that more properly we probably
> - * need to to split per plane data_rate into data_rate_y
> - * and data_rate_uv for multiplanar formats in order not
> - * to get accounted those twice if they happen to reside
> - * on different slices.
> - * However for pre-icl this would work anyway because
> - * we have only single slice and for icl+ uv plane has
> - * non-zero data rate.
> - * So in worst case those calculation are a bit
> - * pessimistic, which shouldn't pose any significant
> - * problem anyway.
> - */
> - for_each_dbuf_slice_in_mask(dev_priv, slice, dbuf_mask)
> - crtc_bw->used_bw[slice] += data_rate;
> - }
> + skl_crtc_calc_dbuf_bw(new_bw_state, crtc_state);
> }
>
> if (!old_bw_state)
> --
> 2.32.0
>
next prev parent reply other threads:[~2022-01-27 8:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 9:23 [Intel-gfx] [PATCH 00/15] drm/i915: Fix bandwith related cdclk calculations Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 01/15] drm/i915: Drop pointless dev_priv argument Ville Syrjala
2022-01-27 8:15 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 02/15] drm/i915: Extract skl_ddb_entry_init() Ville Syrjala
2022-01-27 8:16 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 03/15] drm/i915: Fix plane relative_data_rate calculation Ville Syrjala
2022-01-27 8:21 ` Lisovskiy, Stanislav
2022-01-27 8:50 ` Ville Syrjälä
2022-01-18 9:23 ` [Intel-gfx] [PATCH 04/15] drm/i915: Introduce skl_plane_ddb_iter Ville Syrjala
2022-01-27 8:22 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 05/15] drm/i915: Extract skl_allocate_plane_ddb() Ville Syrjala
2022-01-27 8:24 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 06/15] drm/i915: Extract skl_crtc_calc_dbuf_bw() Ville Syrjala
2022-01-27 8:24 ` Lisovskiy, Stanislav [this message]
2022-01-18 9:23 ` [Intel-gfx] [PATCH 07/15] drm/i915: Tweak plane ddb allocation tracking Ville Syrjala
2022-02-01 8:06 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 08/15] drm/i915: Split plane data_rate into data_rate+data_rate_y Ville Syrjala
2022-02-01 8:08 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 09/15] drm/i915: Pre-calculate plane relative data rate Ville Syrjala
2022-02-01 8:11 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 10/15] drm/i915: Remove total[] and uv_total[] from ddb allocation Ville Syrjala
2022-02-01 8:26 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk() Ville Syrjala
2022-02-01 8:52 ` Lisovskiy, Stanislav
2022-02-01 10:05 ` Ville Syrjälä
2022-02-01 11:18 ` Lisovskiy, Stanislav
2022-02-01 13:45 ` Ville Syrjälä
2022-02-01 14:38 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 12/15] drm/i915: Round up when calculating display bandwidth requirements Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 13/15] drm/i915: Properly write lock bw_state when it changes Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 14/15] drm/i915: Fix DBUF bandwidth vs. cdclk handling Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 15/15] drm/i915: Add "maximum pipe read bandwidth" checks Ville Syrjala
2022-01-18 9:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix bandwith related cdclk calculations Patchwork
2022-01-18 9:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-18 10:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-18 11:32 ` [Intel-gfx] ✗ 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=20220127082452.GF31846@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.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.