stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled
       [not found] <20220309164948.10671-1-ville.syrjala@linux.intel.com>
@ 2022-03-09 16:49 ` Ville Syrjala
  2022-03-09 19:29   ` [Intel-gfx] " Lisovskiy, Stanislav
  2022-03-16 17:55   ` Lisovskiy, Stanislav
  2022-03-09 16:49 ` [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible Ville Syrjala
  1 sibling, 2 replies; 10+ messages in thread
From: Ville Syrjala @ 2022-03-09 16:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: stable

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

For modern platforms the spec explicitly states that a
SAGV block time of zero means that SAGV is not supported.
Let's extend that to all platforms. Supposedly there should
be no systems where this isn't true, and it'll allow us to:
- use the same code regardless of older vs. newer platform
- wm latencies already treat 0 as disabled, so this fits well
  with other related code
- make it a bit more clear when SAGV is used vs. not
- avoid overflows from adding U32_MAX with a u16 wm0 latency value
  which could cause us to miscalculate the SAGV watermarks on tgl+

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8ee31c9590a7..40a3094e55ca 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
 		MISSING_CASE(DISPLAY_VER(dev_priv));
 	}
 
-	/* Default to an unusable block time */
-	dev_priv->sagv_block_time_us = -1;
+	dev_priv->sagv_block_time_us = 0;
 }
 
 /*
@@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
 	result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1;
 	result->enable = true;
 
-	if (DISPLAY_VER(dev_priv) < 12)
+	if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us)
 		result->can_sagv = latency >= dev_priv->sagv_block_time_us;
 }
 
@@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct intel_crtc_state *crtc_state,
 	struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 	struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0;
 	struct skl_wm_level *levels = plane_wm->wm;
-	unsigned int latency = dev_priv->wm.skl_latency[0] + dev_priv->sagv_block_time_us;
+	unsigned int latency = 0;
+
+	if (dev_priv->sagv_block_time_us)
+		latency = dev_priv->sagv_block_time_us + dev_priv->wm.skl_latency[0];
 
 	skl_compute_plane_wm(crtc_state, plane, 0, latency,
 			     wm_params, &levels[0],
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
       [not found] <20220309164948.10671-1-ville.syrjala@linux.intel.com>
  2022-03-09 16:49 ` [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled Ville Syrjala
@ 2022-03-09 16:49 ` Ville Syrjala
  2022-03-09 18:59   ` Lisovskiy, Stanislav
  1 sibling, 1 reply; 10+ messages in thread
From: Ville Syrjala @ 2022-03-09 16:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: stable, Stanislav Lisovskiy

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Don't just mask off all the PSF GV points when SAGV gets disabled.
This should in fact cause the Pcode to reject the request since
at least one PSF point must remain enabled at all times.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_bw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
index ad1564ca7269..adf58c58513b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -992,7 +992,8 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
 	 * cause.
 	 */
 	if (!intel_can_enable_sagv(dev_priv, new_bw_state)) {
-		allowed_points = BIT(max_bw_point);
+		allowed_points &= ADLS_PSF_PT_MASK;
+		allowed_points |= BIT(max_bw_point);
 		drm_dbg_kms(&dev_priv->drm, "No SAGV, using single QGV point %d\n",
 			    max_bw_point);
 	}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
  2022-03-09 16:49 ` [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible Ville Syrjala
@ 2022-03-09 18:59   ` Lisovskiy, Stanislav
  2022-03-09 19:08     ` Ville Syrjälä
  0 siblings, 1 reply; 10+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-09 18:59 UTC (permalink / raw)
  To: Ville Syrjala; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Don't just mask off all the PSF GV points when SAGV gets disabled.
> This should in fact cause the Pcode to reject the request since
> at least one PSF point must remain enabled at all times.

Good point, however I think this is not the full fix:

BSpec says:

"At least one GV point of each type must always remain unmasked."

and

"The GV point of each type providing the highest bandwidth 
 for display must always remain unmasked."

So I guess we should then also choose thr PSF GV point with
the highest bandwidth as well.

Stan


> 
> Cc: stable@vger.kernel.org
> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index ad1564ca7269..adf58c58513b 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -992,7 +992,8 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
>  	 * cause.
>  	 */
>  	if (!intel_can_enable_sagv(dev_priv, new_bw_state)) {
> -		allowed_points = BIT(max_bw_point);
> +		allowed_points &= ADLS_PSF_PT_MASK;
> +		allowed_points |= BIT(max_bw_point);
>  		drm_dbg_kms(&dev_priv->drm, "No SAGV, using single QGV point %d\n",
>  			    max_bw_point);
>  	}
> -- 
> 2.34.1
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
  2022-03-09 18:59   ` Lisovskiy, Stanislav
@ 2022-03-09 19:08     ` Ville Syrjälä
  2022-03-09 19:34       ` Lisovskiy, Stanislav
  0 siblings, 1 reply; 10+ messages in thread
From: Ville Syrjälä @ 2022-03-09 19:08 UTC (permalink / raw)
  To: Lisovskiy, Stanislav; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Don't just mask off all the PSF GV points when SAGV gets disabled.
> > This should in fact cause the Pcode to reject the request since
> > at least one PSF point must remain enabled at all times.
> 
> Good point, however I think this is not the full fix:
> 
> BSpec says:
> 
> "At least one GV point of each type must always remain unmasked."
> 
> and
> 
> "The GV point of each type providing the highest bandwidth 
>  for display must always remain unmasked."
> 
> So I guess we should then also choose thr PSF GV point with
> the highest bandwidth as well.

The spec says PSF GV is fast enough to now stall the display data
fetch so we don't need to restrict the PSF points here.

-- 
Ville Syrjälä
Intel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled
  2022-03-09 16:49 ` [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled Ville Syrjala
@ 2022-03-09 19:29   ` Lisovskiy, Stanislav
  2022-03-09 20:35     ` Ville Syrjälä
  2022-03-16 17:55   ` Lisovskiy, Stanislav
  1 sibling, 1 reply; 10+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-09 19:29 UTC (permalink / raw)
  To: Ville Syrjala; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> For modern platforms the spec explicitly states that a
> SAGV block time of zero means that SAGV is not supported.
> Let's extend that to all platforms. Supposedly there should
> be no systems where this isn't true, and it'll allow us to:
> - use the same code regardless of older vs. newer platform
> - wm latencies already treat 0 as disabled, so this fits well
>   with other related code
> - make it a bit more clear when SAGV is used vs. not
> - avoid overflows from adding U32_MAX with a u16 wm0 latency value
>   which could cause us to miscalculate the SAGV watermarks on tgl+
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8ee31c9590a7..40a3094e55ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
>  		MISSING_CASE(DISPLAY_VER(dev_priv));
>  	}
>  
> -	/* Default to an unusable block time */
> -	dev_priv->sagv_block_time_us = -1;
> +	dev_priv->sagv_block_time_us = 0;
>  }
>  
>  /*
> @@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
>  	result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1;
>  	result->enable = true;
>  
> -	if (DISPLAY_VER(dev_priv) < 12)
> +	if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us)
>  		result->can_sagv = latency >= dev_priv->sagv_block_time_us;
>  }
>  
> @@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct intel_crtc_state *crtc_state,
>  	struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
>  	struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0;
>  	struct skl_wm_level *levels = plane_wm->wm;
> -	unsigned int latency = dev_priv->wm.skl_latency[0] + dev_priv->sagv_block_time_us;
> +	unsigned int latency = 0;
> +
> +	if (dev_priv->sagv_block_time_us)
> +		latency = dev_priv->sagv_block_time_us + dev_priv->wm.skl_latency[0];

Should we may be add this to intel_has_sagv? I thought this was supposed to tell,
if SAGV is supported or not. Should we just call it hear as well, may be..
Now we kinda making it less obvious. 

Stan

>  
>  	skl_compute_plane_wm(crtc_state, plane, 0, latency,
>  			     wm_params, &levels[0],
> -- 
> 2.34.1
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
  2022-03-09 19:08     ` Ville Syrjälä
@ 2022-03-09 19:34       ` Lisovskiy, Stanislav
  2022-03-09 20:21         ` Ville Syrjälä
  2022-03-16 18:01         ` [Intel-gfx] " Lisovskiy, Stanislav
  0 siblings, 2 replies; 10+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-09 19:34 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote:
> > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > Don't just mask off all the PSF GV points when SAGV gets disabled.
> > > This should in fact cause the Pcode to reject the request since
> > > at least one PSF point must remain enabled at all times.
> > 
> > Good point, however I think this is not the full fix:
> > 
> > BSpec says:
> > 
> > "At least one GV point of each type must always remain unmasked."
> > 
> > and
> > 
> > "The GV point of each type providing the highest bandwidth 
> >  for display must always remain unmasked."
> > 
> > So I guess we should then also choose thr PSF GV point with
> > the highest bandwidth as well.
> 
> The spec says PSF GV is fast enough to now stall the display data
> fetch so we don't need to restrict the PSF points here.

But why it asks to ensure that we have the PSF GV of highest bandwidth to
stay always unmasked then?

Stan

> 
> -- 
> Ville Syrjälä
> Intel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
  2022-03-09 19:34       ` Lisovskiy, Stanislav
@ 2022-03-09 20:21         ` Ville Syrjälä
  2022-03-16 18:01         ` [Intel-gfx] " Lisovskiy, Stanislav
  1 sibling, 0 replies; 10+ messages in thread
From: Ville Syrjälä @ 2022-03-09 20:21 UTC (permalink / raw)
  To: Lisovskiy, Stanislav; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 09:34:58PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote:
> > > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Don't just mask off all the PSF GV points when SAGV gets disabled.
> > > > This should in fact cause the Pcode to reject the request since
> > > > at least one PSF point must remain enabled at all times.
> > > 
> > > Good point, however I think this is not the full fix:
> > > 
> > > BSpec says:
> > > 
> > > "At least one GV point of each type must always remain unmasked."
> > > 
> > > and
> > > 
> > > "The GV point of each type providing the highest bandwidth 
> > >  for display must always remain unmasked."
> > > 
> > > So I guess we should then also choose thr PSF GV point with
> > > the highest bandwidth as well.
> > 
> > The spec says PSF GV is fast enough to now stall the display data
> > fetch so we don't need to restrict the PSF points here.
> 
> But why it asks to ensure that we have the PSF GV of highest bandwidth to
> stay always unmasked then?

I presume so you don't lock the memory bandwdith to some lower
performance point and hurt all the other things that need
memory bandwidth. Either that or there is some internal
implementation detail that simply doesn't work if you try to
permanently run at a lower performance point.

-- 
Ville Syrjälä
Intel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled
  2022-03-09 19:29   ` [Intel-gfx] " Lisovskiy, Stanislav
@ 2022-03-09 20:35     ` Ville Syrjälä
  0 siblings, 0 replies; 10+ messages in thread
From: Ville Syrjälä @ 2022-03-09 20:35 UTC (permalink / raw)
  To: Lisovskiy, Stanislav; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 09:29:58PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > For modern platforms the spec explicitly states that a
> > SAGV block time of zero means that SAGV is not supported.
> > Let's extend that to all platforms. Supposedly there should
> > be no systems where this isn't true, and it'll allow us to:
> > - use the same code regardless of older vs. newer platform
> > - wm latencies already treat 0 as disabled, so this fits well
> >   with other related code
> > - make it a bit more clear when SAGV is used vs. not
> > - avoid overflows from adding U32_MAX with a u16 wm0 latency value
> >   which could cause us to miscalculate the SAGV watermarks on tgl+
> > 
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index 8ee31c9590a7..40a3094e55ca 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
> >  		MISSING_CASE(DISPLAY_VER(dev_priv));
> >  	}
> >  
> > -	/* Default to an unusable block time */
> > -	dev_priv->sagv_block_time_us = -1;
> > +	dev_priv->sagv_block_time_us = 0;
> >  }
> >  
> >  /*
> > @@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
> >  	result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1;
> >  	result->enable = true;
> >  
> > -	if (DISPLAY_VER(dev_priv) < 12)
> > +	if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us)
> >  		result->can_sagv = latency >= dev_priv->sagv_block_time_us;
> >  }
> >  
> > @@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct intel_crtc_state *crtc_state,
> >  	struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> >  	struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0;
> >  	struct skl_wm_level *levels = plane_wm->wm;
> > -	unsigned int latency = dev_priv->wm.skl_latency[0] + dev_priv->sagv_block_time_us;
> > +	unsigned int latency = 0;
> > +
> > +	if (dev_priv->sagv_block_time_us)
> > +		latency = dev_priv->sagv_block_time_us + dev_priv->wm.skl_latency[0];
> 
> Should we may be add this to intel_has_sagv? I thought this was supposed to tell,
> if SAGV is supported or not. Should we just call it hear as well, may be..
> Now we kinda making it less obvious. 

We already use intel_has_sagv() to see if we should zero out the
block time. I don't think I want to make it a full circle.

> 
> Stan
> 
> >  
> >  	skl_compute_plane_wm(crtc_state, plane, 0, latency,
> >  			     wm_params, &levels[0],
> > -- 
> > 2.34.1
> > 

-- 
Ville Syrjälä
Intel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled
  2022-03-09 16:49 ` [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled Ville Syrjala
  2022-03-09 19:29   ` [Intel-gfx] " Lisovskiy, Stanislav
@ 2022-03-16 17:55   ` Lisovskiy, Stanislav
  1 sibling, 0 replies; 10+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-16 17:55 UTC (permalink / raw)
  To: Ville Syrjala; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> For modern platforms the spec explicitly states that a
> SAGV block time of zero means that SAGV is not supported.
> Let's extend that to all platforms. Supposedly there should
> be no systems where this isn't true, and it'll allow us to:
> - use the same code regardless of older vs. newer platform
> - wm latencies already treat 0 as disabled, so this fits well
>   with other related code
> - make it a bit more clear when SAGV is used vs. not
> - avoid overflows from adding U32_MAX with a u16 wm0 latency value
>   which could cause us to miscalculate the SAGV watermarks on tgl+
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8ee31c9590a7..40a3094e55ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
>  		MISSING_CASE(DISPLAY_VER(dev_priv));
>  	}
>  
> -	/* Default to an unusable block time */
> -	dev_priv->sagv_block_time_us = -1;
> +	dev_priv->sagv_block_time_us = 0;
>  }
>  
>  /*
> @@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
>  	result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1;
>  	result->enable = true;
>  
> -	if (DISPLAY_VER(dev_priv) < 12)
> +	if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us)
>  		result->can_sagv = latency >= dev_priv->sagv_block_time_us;
>  }
>  
> @@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct intel_crtc_state *crtc_state,
>  	struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
>  	struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0;
>  	struct skl_wm_level *levels = plane_wm->wm;
> -	unsigned int latency = dev_priv->wm.skl_latency[0] + dev_priv->sagv_block_time_us;
> +	unsigned int latency = 0;
> +
> +	if (dev_priv->sagv_block_time_us)
> +		latency = dev_priv->sagv_block_time_us + dev_priv->wm.skl_latency[0];
>  
>  	skl_compute_plane_wm(crtc_state, plane, 0, latency,
>  			     wm_params, &levels[0],
> -- 
> 2.34.1
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
  2022-03-09 19:34       ` Lisovskiy, Stanislav
  2022-03-09 20:21         ` Ville Syrjälä
@ 2022-03-16 18:01         ` Lisovskiy, Stanislav
  1 sibling, 0 replies; 10+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-16 18:01 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx, stable

On Wed, Mar 09, 2022 at 09:34:58PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote:
> > > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Don't just mask off all the PSF GV points when SAGV gets disabled.
> > > > This should in fact cause the Pcode to reject the request since
> > > > at least one PSF point must remain enabled at all times.
> > > 
> > > Good point, however I think this is not the full fix:
> > > 
> > > BSpec says:
> > > 
> > > "At least one GV point of each type must always remain unmasked."
> > > 
> > > and
> > > 
> > > "The GV point of each type providing the highest bandwidth 
> > >  for display must always remain unmasked."
> > > 
> > > So I guess we should then also choose thr PSF GV point with
> > > the highest bandwidth as well.
> > 
> > The spec says PSF GV is fast enough to now stall the display data
> > fetch so we don't need to restrict the PSF points here.
> 
> But why it asks to ensure that we have the PSF GV of highest bandwidth to
> stay always unmasked then?
> 
> Stan

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

> 
> > 
> > -- 
> > Ville Syrjälä
> > Intel

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-03-16 18:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20220309164948.10671-1-ville.syrjala@linux.intel.com>
2022-03-09 16:49 ` [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled Ville Syrjala
2022-03-09 19:29   ` [Intel-gfx] " Lisovskiy, Stanislav
2022-03-09 20:35     ` Ville Syrjälä
2022-03-16 17:55   ` Lisovskiy, Stanislav
2022-03-09 16:49 ` [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible Ville Syrjala
2022-03-09 18:59   ` Lisovskiy, Stanislav
2022-03-09 19:08     ` Ville Syrjälä
2022-03-09 19:34       ` Lisovskiy, Stanislav
2022-03-09 20:21         ` Ville Syrjälä
2022-03-16 18:01         ` [Intel-gfx] " Lisovskiy, Stanislav

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).