Intel-GFX Archive on 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: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/i915: Disable SAGV on bw init, to force QGV point recalculation
Date: Thu, 18 Jan 2024 10:35:56 +0200	[thread overview]
Message-ID: <Zaji7CC77kmy1jW4@intel.com> (raw)
In-Reply-To: <20240117155718.3439-4-stanislav.lisovskiy@intel.com>

On Wed, Jan 17, 2024 at 05:57:18PM +0200, Stanislav Lisovskiy wrote:
> Problem is that on some platforms, we do get QGV point mask in wrong
> state on boot. However driver assumes it is set to 0
> (i.e all points allowed), however in reality we might get them all restricted,
> causing issues.
> Lets disable SAGV initially to force proper QGV point state.
> If more QGV points are available, driver will recalculate and update
> those then after next commit.
> 
> v2: - Added trace to see which QGV/PSF GV point is used when SAGV is
>       disabled.
> v3: - Move force disable function to intel_bw_init in order to initialize
>       bw state as well, so that hw/sw are immediately in sync after init.
> v4: - Don't try sending PCode request, seems like it is not possible at
>       intel_bw_init, however assigning bw->state to be restricted as if
>       SAGV is off, still forces driveer to send PCode request anyway on
>       next modeset, so the solution still works.
>       However we still need to address the case, when no display is connected,
>       which anyway requires much more changes.
> 
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 24 ++++++++++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_bw.h |  2 ++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index 7baa1c13eccd..36a6304207ba 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -852,6 +852,27 @@ static unsigned int icl_max_bw_qgv_point(struct drm_i915_private *i915,
>  	return max_bw_point;
>  }
>  
> +void icl_force_disable_sagv(struct drm_i915_private *i915, struct intel_bw_state *bw_state)
> +{
> +	unsigned int max_bw_qgv_point = icl_max_bw_qgv_point(i915, 0);
> +	unsigned int qgv_points;
> +	unsigned int psf_points;
> +
> +	qgv_points = BIT(max_bw_qgv_point);
> +
> +	/*
> +	 * We don't restrict PSF GV points, when disabling SAGV
> +	 */
> +	psf_points = 0;

Using 0 looks very wrong here. Since we have no idea how much
bandwidth the display is consuming at this time we should
restrict this to the max psf gv point as well.

> +
> +	bw_state->qgv_points_mask = ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
> +				      ADLS_PCODE_REQ_PSF_PT(psf_points)) &
> +				      icl_qgv_points_mask(i915);
> +
> +	drm_dbg_kms(&i915->drm, "Forcing SAGV disable: leaving QGV point %d\n",
> +				max_bw_qgv_point);

You didn't actually poke the hardware to disable anything.

> +}
> +
>  static int mtl_find_qgv_points(struct drm_i915_private *i915,
>  			       unsigned int data_rate,
>  			       unsigned int num_active_planes,
> @@ -1351,5 +1372,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
>  	intel_atomic_global_obj_init(dev_priv, &dev_priv->display.bw.obj,
>  				     &state->base, &intel_bw_funcs);
>  
> +	if (DISPLAY_VER(dev_priv) < 14)

Should be some kind of range check to avoid putting garbage in there on
old platforms that don't support QGV.

> +		icl_force_disable_sagv(dev_priv, state);
> +
>  	return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
> index 59cb4fc5db76..243192fd4cae 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -74,5 +74,7 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
>  			    bool *need_cdclk_calc);
>  int intel_bw_min_cdclk(struct drm_i915_private *i915,
>  		       const struct intel_bw_state *bw_state);
> +void icl_force_disable_sagv(struct drm_i915_private *dev_priv,
> +			    struct intel_bw_state *bw_state);

Why?

>  
>  #endif /* __INTEL_BW_H__ */
> -- 
> 2.37.3

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2024-01-18  8:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17 15:57 [PATCH 0/3] QGV/SAGV related fixes Stanislav Lisovskiy
2024-01-17 15:57 ` [PATCH 1/3] drm/i915: Add meaningful traces for QGV point info error handling Stanislav Lisovskiy
2024-01-18 12:24   ` Gustavo Sousa
2024-01-17 15:57 ` [PATCH 2/3] drm/i915: Extract code required to calculate max qgv/psf gv point Stanislav Lisovskiy
2024-01-18  8:24   ` Ville Syrjälä
2024-01-17 15:57 ` [PATCH 3/3] drm/i915: Disable SAGV on bw init, to force QGV point recalculation Stanislav Lisovskiy
2024-01-18  8:35   ` Ville Syrjälä [this message]
2024-01-18  8:50     ` Lisovskiy, Stanislav
2024-01-18  9:07       ` Ville Syrjälä
2024-01-18  9:26         ` Lisovskiy, Stanislav
2024-02-01 12:33         ` Lisovskiy, Stanislav
2024-01-17 16:57 ` ✗ Fi.CI.CHECKPATCH: warning for QGV/SAGV related fixes (rev4) Patchwork
2024-01-17 16:57 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-17 17:15 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-01-18 20:04 ` ✗ Fi.CI.CHECKPATCH: warning for QGV/SAGV related fixes (rev5) Patchwork
2024-01-18 20:04 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-18 20:23 ` ✗ Fi.CI.BAT: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2024-02-19  9:18 [PATCH 0/3] QGV/SAGV related fixes Stanislav Lisovskiy
2024-02-19  9:18 ` [PATCH 3/3] drm/i915: Disable SAGV on bw init, to force QGV point recalculation Stanislav Lisovskiy
2024-02-20  9:31 [PATCH 0/3] QGV/SAGV related fixes Stanislav Lisovskiy
2024-02-20  9:31 ` [PATCH 3/3] drm/i915: Disable SAGV on bw init, to force QGV point recalculation Stanislav Lisovskiy
2024-03-20 22:33   ` Govindapillai, Vinod

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=Zaji7CC77kmy1jW4@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox