All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v25 2/8] drm/i915: Use bw state for per crtc SAGV evaluation
Date: Tue, 21 Apr 2020 19:00:38 +0300	[thread overview]
Message-ID: <20200421160038.GC6112@intel.com> (raw)
In-Reply-To: <20200420111416.23550-3-stanislav.lisovskiy@intel.com>

On Mon, Apr 20, 2020 at 02:14:10PM +0300, Stanislav Lisovskiy wrote:
> Future platforms require per-crtc SAGV evaluation
> and serializing global state when those are changed
> from different commits.
> 
> v2: - Add has_sagv check to intel_crtc_can_enable_sagv
>       so that it sets bit in reject mask.
>     - Use bw_state in intel_pre/post_plane_enable_sagv
>       instead of atomic state
> 
> v3: - Fixed rebase conflict, now using
>       intel_atomic_crtc_state_for_each_plane_state in
>       order to call it from atomic check
> v4: - Use fb modifier from plane state
> 
> v5: - Make intel_has_sagv static again(Ville)
>     - Removed unnecessary NULL assignments(Ville)
>     - Removed unnecessary SAGV debug(Ville)
>     - Call intel_compute_sagv_mask only for modesets(Ville)
>     - Serialize global state only if sagv results change, but
>       not mask itself(Ville)
> 
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@intel.com>
> Cc: James Ausmus <james.ausmus@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_bw.h |   6 ++
>  drivers/gpu/drm/i915/intel_pm.c         | 113 ++++++++++++++++++------
>  drivers/gpu/drm/i915/intel_pm.h         |   3 +-
>  3 files changed, 93 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
> index ac004d6f4276..d6df91058223 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -18,6 +18,12 @@ struct intel_crtc_state;
>  struct intel_bw_state {
>  	struct intel_global_state base;
>  
> +	/*
> +	 * Contains a bit mask, used to determine, whether correspondent
> +	 * pipe allows SAGV or not.
> +	 */
> +	u8 pipe_sagv_reject;
> +
>  	unsigned int data_rate[I915_MAX_PIPES];
>  	u8 num_active_planes[I915_MAX_PIPES];
>  };
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b0810d76ad47..d06a1a3713ed 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -43,6 +43,7 @@
>  #include "i915_fixed.h"
>  #include "i915_irq.h"
>  #include "i915_trace.h"
> +#include "display/intel_bw.h"
>  #include "intel_pm.h"
>  #include "intel_sideband.h"
>  #include "../../../platform/x86/intel_ips.h"
> @@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
>  void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
>  {
>  	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	const struct intel_bw_state *new_bw_state;
>  
> -	if (!intel_can_enable_sagv(state))
> +	/*
> +	 * Just return if we can't control SAGV or don't have it.
> +	 * This is different from situation when we have SAGV but just can't
> +	 * afford it due to DBuf limitation - in case if SAGV is completely
> +	 * disabled in a BIOS, we are not even allowed to send a PCode request,
> +	 * as it will throw an error. So have to check it here.
> +	 */
> +	if (!intel_has_sagv(dev_priv))
> +		return;
> +
> +	new_bw_state = intel_atomic_get_new_bw_state(state);
> +	if (!new_bw_state)
> +		return;
> +
> +	if (!intel_can_enable_sagv(new_bw_state))
>  		intel_disable_sagv(dev_priv);
>  }
>  
>  void intel_sagv_post_plane_update(struct intel_atomic_state *state)
>  {
>  	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	const struct intel_bw_state *new_bw_state;
>  
> -	if (intel_can_enable_sagv(state))
> +	/*
> +	 * Just return if we can't control SAGV or don't have it.
> +	 * This is different from situation when we have SAGV but just can't
> +	 * afford it due to DBuf limitation - in case if SAGV is completely
> +	 * disabled in a BIOS, we are not even allowed to send a PCode request,
> +	 * as it will throw an error. So have to check it here.
> +	 */
> +	if (!intel_has_sagv(dev_priv))
> +		return;
> +
> +	new_bw_state = intel_atomic_get_new_bw_state(state);
> +	if (!new_bw_state)
> +		return;
> +
> +	if (intel_can_enable_sagv(new_bw_state))
>  		intel_enable_sagv(dev_priv);
>  }
>  
>  static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state)
>  {
> -	struct drm_device *dev = crtc_state->uapi.crtc->dev;
> -	struct drm_i915_private *dev_priv = to_i915(dev);
> +	struct intel_atomic_state *state = to_intel_atomic_state(crtc_state->uapi.state);
>  	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> +	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  	struct intel_plane *plane;
> +	const struct intel_plane_state *plane_state;
>  	int level, latency;
>  
> +	if (!intel_has_sagv(dev_priv))
> +		return false;
> +
>  	if (!crtc_state->hw.active)
>  		return true;
>  
> +	/*
> +	 * SKL+ workaround: bspec recommends we disable SAGV when we have
> +	 * more then one pipe enabled
> +	 */
> +	if (hweight8(state->active_pipes) > 1)
> +		return false;
> +
>  	if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
>  		return false;
>  
> -	for_each_intel_plane_on_crtc(dev, crtc, plane) {
> +	intel_atomic_crtc_state_for_each_plane_state(plane, plane_state, crtc_state) {
>  		const struct skl_plane_wm *wm =
>  			&crtc_state->wm.skl.optimal.planes[plane->id];
>  
> @@ -3803,7 +3845,7 @@ static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state
>  		latency = dev_priv->wm.skl_latency[level];
>  
>  		if (skl_needs_memory_bw_wa(dev_priv) &&
> -		    plane->base.state->fb->modifier ==
> +		    plane_state->uapi.fb->modifier ==
>  		    I915_FORMAT_MOD_X_TILED)
>  			latency += 15;
>  
> @@ -3819,35 +3861,44 @@ static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state
>  	return true;
>  }
>  
> -bool intel_can_enable_sagv(struct intel_atomic_state *state)
> +bool intel_can_enable_sagv(const struct intel_bw_state *bw_state)
>  {
> -	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	return bw_state->pipe_sagv_reject == 0;
> +}
> +
> +static int intel_compute_sagv_mask(struct intel_atomic_state *state)
> +{
> +	int ret;
>  	struct intel_crtc *crtc;
> -	const struct intel_crtc_state *crtc_state;
> -	enum pipe pipe;
> +	struct intel_crtc_state *new_crtc_state;
> +	struct intel_bw_state *new_bw_state = NULL;
> +	const struct intel_bw_state *old_bw_state = NULL;
> +	int i;
>  
> -	if (!intel_has_sagv(dev_priv))
> -		return false;
> +	for_each_new_intel_crtc_in_state(state, crtc,
> +					 new_crtc_state, i) {
> +		new_bw_state = intel_atomic_get_bw_state(state);
> +		if (IS_ERR(new_bw_state))
> +			return PTR_ERR(new_bw_state);
>  
> -	/*
> -	 * If there are no active CRTCs, no additional checks need be performed
> -	 */
> -	if (hweight8(state->active_pipes) == 0)
> -		return true;
> +		old_bw_state = intel_atomic_get_old_bw_state(state);
>  
> -	/*
> -	 * SKL+ workaround: bspec recommends we disable SAGV when we have
> -	 * more then one pipe enabled
> -	 */
> -	if (hweight8(state->active_pipes) > 1)
> -		return false;
> +		if (intel_crtc_can_enable_sagv(new_crtc_state))
> +			new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> +		else
> +			new_bw_state->pipe_sagv_reject |= BIT(crtc->pipe);
> +	}
>  
> -	/* Since we're now guaranteed to only have one active CRTC... */
> -	pipe = ffs(state->active_pipes) - 1;
> -	crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> -	crtc_state = to_intel_crtc_state(crtc->base.state);
> +	if (!new_bw_state)
> +		return 0;
>  
> -	return intel_crtc_can_enable_sagv(crtc_state);
> +	if (intel_can_enable_sagv(new_bw_state) != intel_can_enable_sagv(old_bw_state)) {

Missing the lock_global_state() for the old_maks != new_mask case.
Otherwise seems fine.

Now I believe we need to separate state->modeset from sag, as I
mentioned in the previous review. Please take care of that stuff
before we continue with the rest of this series.

> +		ret = intel_atomic_serialize_global_state(&new_bw_state->base);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
>  }
>  
>  /*
> @@ -5860,6 +5911,12 @@ skl_compute_wm(struct intel_atomic_state *state)
>  	if (ret)
>  		return ret;
>  
> +	if (state->modeset) {
> +		ret = intel_compute_sagv_mask(state);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	/*
>  	 * skl_compute_ddb() will have adjusted the final watermarks
>  	 * based on how much ddb is available. Now we can actually
> diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
> index 9a6036ab0f90..fd1dc422e6c5 100644
> --- a/drivers/gpu/drm/i915/intel_pm.h
> +++ b/drivers/gpu/drm/i915/intel_pm.h
> @@ -9,6 +9,7 @@
>  #include <linux/types.h>
>  
>  #include "i915_reg.h"
> +#include "display/intel_bw.h"
>  
>  struct drm_device;
>  struct drm_i915_private;
> @@ -41,7 +42,7 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
>  			      struct skl_pipe_wm *out);
>  void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
>  void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
> -bool intel_can_enable_sagv(struct intel_atomic_state *state);
> +bool intel_can_enable_sagv(const struct intel_bw_state *bw_state);
>  int intel_enable_sagv(struct drm_i915_private *dev_priv);
>  int intel_disable_sagv(struct drm_i915_private *dev_priv);
>  void intel_sagv_pre_plane_update(struct intel_atomic_state *state);
> -- 
> 2.24.1.485.gad05a3d8e5

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-04-21 16:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-20 11:14 [Intel-gfx] [PATCH v25 0/8] SAGV support for Gen12+ Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 1/8] drm/i915: Introduce skl_plane_wm_level accessor Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 2/8] drm/i915: Use bw state for per crtc SAGV evaluation Stanislav Lisovskiy
2020-04-21 16:00   ` Ville Syrjälä [this message]
2020-04-22  7:50     ` Lisovskiy, Stanislav
2020-04-22 16:38       ` Ville Syrjälä
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 3/8] drm/i915: Separate icl and skl SAGV checking Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 4/8] drm/i915: Add TGL+ SAGV support Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 5/8] drm/i915: Added required new PCode commands Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 6/8] drm/i915: Rename bw_state to new_bw_state Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 7/8] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
2020-04-20 11:14 ` [Intel-gfx] [PATCH v25 8/8] drm/i915: Enable SAGV support for Gen12 Stanislav Lisovskiy
2020-04-20 13:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for SAGV support for Gen12+ (rev26) Patchwork
2020-04-20 17:16 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-04-20 21:05   ` Lisovskiy, Stanislav
2020-04-20 21:43     ` Vudum, Lakshminarayana
2020-04-20 21:20 ` [Intel-gfx] ✓ Fi.CI.IGT: success " 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=20200421160038.GC6112@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@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.