public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: James Ausmus <james.ausmus@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH 3/3] drm/i915/tgl: Remove single pipe restriction from SAGV
Date: Thu, 26 Sep 2019 15:34:35 +0300	[thread overview]
Message-ID: <20190926123435.GJ1208@intel.com> (raw)
In-Reply-To: <20190925203352.9827-4-james.ausmus@intel.com>

On Wed, Sep 25, 2019 at 01:33:52PM -0700, James Ausmus wrote:
> For Gen12, BSpec no longer tells us to disable SAGV when > 1 pipe is
> active. Update intel_can_enable_sagv to allow this, and loop through all
> active planes on all active crtcs to check against the interlaced and
> latency restrictions.
> 
> BSpec: 49325
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: James Ausmus <james.ausmus@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 63 +++++++++++++++++----------------
>  1 file changed, 32 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ca2bec09edb5..cb50c697a6b8 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3775,7 +3775,6 @@ bool intel_can_enable_sagv(struct intel_atomic_state *state)
>  	struct intel_crtc *crtc;
>  	struct intel_plane *plane;
>  	struct intel_crtc_state *crtc_state;
> -	enum pipe pipe;
>  	int level, latency;
>  	int sagv_block_time_us;
>  
> @@ -3791,47 +3790,49 @@ bool intel_can_enable_sagv(struct intel_atomic_state *state)
>  		return true;
>  
>  	/*
> -	 * SKL+ workaround: bspec recommends we disable SAGV when we have
> +	 * SKL-ICL workaround: bspec recommends we disable SAGV when we have
>  	 * more then one pipe enabled
>  	 */
> -	if (hweight8(state->active_pipes) > 1)
> +	if (INTEL_GEN(dev_priv) < 12 && hweight8(state->active_pipes) > 1)
>  		return false;
>  
> -	/* 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);
> +	for_each_intel_crtc(&dev_priv->drm, crtc) {
> +		crtc_state = to_intel_crtc_state(crtc->base.state);
> +		if (!crtc_state->base.active)
> +			continue;
>  
> -	if (crtc->base.state->adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
> -		return false;
> +		if (crtc->base.state->adjusted_mode.flags &
> +		    DRM_MODE_FLAG_INTERLACE)
> +			return false;
>  
> -	for_each_intel_plane_on_crtc(dev, crtc, plane) {
> -		struct skl_plane_wm *wm =
> -			&crtc_state->wm.skl.optimal.planes[plane->id];
> +		for_each_intel_plane_on_crtc(dev, crtc, plane) {
> +			struct skl_plane_wm *wm =
> +				&crtc_state->wm.skl.optimal.planes[plane->id];

This whole loop is bothering me. I'd much rather we move to a scheme
where each plane computes it's SAGV friendlyness when computing the
watermarks. We'll anyway need that since we need to caclulate the
watermarks differently for the SAGV on vs. off cases.

>  
> -		/* Skip this plane if it's not enabled */
> -		if (!wm->wm[0].plane_en)
> -			continue;
> +			/* Skip this plane if it's not enabled */
> +			if (!wm->wm[0].plane_en)
> +				continue;
>  
> -		/* Find the highest enabled wm level for this plane */
> -		for (level = ilk_wm_max_level(dev_priv);
> -		     !wm->wm[level].plane_en; --level)
> -		     { }
> +			/* Find the highest enabled wm level for this plane */
> +			for (level = ilk_wm_max_level(dev_priv);
> +			     !wm->wm[level].plane_en; --level)
> +			     { }
>  
> -		latency = dev_priv->wm.skl_latency[level];
> +			latency = dev_priv->wm.skl_latency[level];
>  
> -		if (skl_needs_memory_bw_wa(dev_priv) &&
> -		    plane->base.state->fb->modifier ==
> -		    I915_FORMAT_MOD_X_TILED)
> -			latency += 15;
> +			if (skl_needs_memory_bw_wa(dev_priv) &&
> +			    plane->base.state->fb->modifier ==
> +			    I915_FORMAT_MOD_X_TILED)
> +				latency += 15;
>  
> -		/*
> -		 * If any of the planes on this pipe don't enable wm levels that
> -		 * incur memory latencies higher than sagv_block_time_us we
> -		 * can't enable SAGV.
> -		 */
> -		if (latency < sagv_block_time_us)
> -			return false;
> +			/*
> +			 * If any of the planes on this pipe don't enable wm
> +			 * levels that incur memory latencies higher than
> +			 * sagv_block_time_us we can't enable SAGV.
> +			 */
> +			if (latency < sagv_block_time_us)
> +				return false;
> +		}
>  	}
>  
>  	return true;
> -- 
> 2.22.1

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

  reply	other threads:[~2019-09-26 12:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 20:33 Add support for TGL in SAGV code paths James Ausmus
2019-09-25 20:33 ` [PATCH 1/3] drm/i915: Extract SAGV block time function James Ausmus
2019-09-27 17:51   ` Ville Syrjälä
2019-09-25 20:33 ` [PATCH 2/3] drm/i915/tgl: Read SAGV block time from PCODE James Ausmus
2019-09-27 18:01   ` Ville Syrjälä
2019-09-27 18:18   ` Ville Syrjälä
2019-09-25 20:33 ` [PATCH 3/3] drm/i915/tgl: Remove single pipe restriction from SAGV James Ausmus
2019-09-26 12:34   ` Ville Syrjälä [this message]
2019-09-27 17:16     ` James Ausmus
2019-09-25 21:02 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Extract SAGV block time function Patchwork
2019-09-25 21:25 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-26 16:23 ` ✓ 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=20190926123435.GJ1208@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=james.ausmus@intel.com \
    --cc=lucas.demarchi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox