Re: [Intel-gfx] [PATCH] drm/i915/display: A check on mode->clock, if it exceeds max_dot_clock

[Ville Syrjälä]

On Wed, Nov 23, 2022 at 01:13:56PM +0530, Nischal Varide wrote:
> Making sure that the  mode-clock is not greater than the
> max_dot_clock freq.This patch will prevent attempts from
> userspace to modeset with mode->clock greater than
> max_dot_clock freq.

Already handled elsewhere.

> 
> Signed-off-by: Nischal Varide 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   | 10 ++
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  3 +++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7400d6b4c587..e603b7c01d27 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2045,6 +2045,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   if (intel_dp_hdisplay_bad(dev_priv, adjusted_mode->crtc_hdisplay))
>   return -EINVAL;
>  
> + if (!intel_dp_can_bigjoiner(intel_dp) &&
> + (adjusted_mode->clock > dev_priv->max_dotclk_freq))
> + return -EINVAL;
> +
> + if (intel_dp_can_bigjoiner(intel_dp) &&
> + (adjusted_mode->clock >  (2 * dev_priv->max_dotclk_freq)))
> + return -EINVAL;
> +
> +
> +
>   /*
>* Try to respect downstream TMDS clock limits first, if
>* that fails assume the user might know something we don't.
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 02f8374ea51f..50603806a964 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2247,6 +2247,9 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> + if (adjusted_mode->clock > dev_priv->max_dotclk_freq)
> + return -EINVAL;
> +
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
>conn_state);
> -- 
> 2.36.0

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH] drm/i915/display: A check on mode->clock, if it exceeds max_dot_clock

[Nischal Varide]

Making sure that the  mode-clock is not greater than the
max_dot_clock freq.This patch will prevent attempts from
userspace to modeset with mode->clock greater than
max_dot_clock freq.

Signed-off-by: Nischal Varide 
---
 drivers/gpu/drm/i915/display/intel_dp.c   | 10 ++
 drivers/gpu/drm/i915/display/intel_hdmi.c |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7400d6b4c587..e603b7c01d27 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2045,6 +2045,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (intel_dp_hdisplay_bad(dev_priv, adjusted_mode->crtc_hdisplay))
return -EINVAL;
 
+   if (!intel_dp_can_bigjoiner(intel_dp) &&
+   (adjusted_mode->clock > dev_priv->max_dotclk_freq))
+   return -EINVAL;
+
+   if (intel_dp_can_bigjoiner(intel_dp) &&
+   (adjusted_mode->clock >  (2 * dev_priv->max_dotclk_freq)))
+   return -EINVAL;
+
+
+
/*
 * Try to respect downstream TMDS clock limits first, if
 * that fails assume the user might know something we don't.
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 02f8374ea51f..50603806a964 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2247,6 +2247,9 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
 
+   if (adjusted_mode->clock > dev_priv->max_dotclk_freq)
+   return -EINVAL;
+
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
 conn_state);
-- 
2.36.0

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: make default_lists const data

[Patchwork]

== Series Details ==

Series: drm/i915/guc: make default_lists const data
URL   : https://patchwork.freedesktop.org/series/111201/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418_full -> Patchwork_111201v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111201v1_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_cursor_legacy@torture-move@all-pipes:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-rkl-4/igt@kms_cursor_legacy@torture-m...@all-pipes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-rkl-5/igt@kms_cursor_legacy@torture-m...@all-pipes.html

  
Known issues


  Here are the changes found in Patchwork_111201v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][5] -> [SKIP][6] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-apl:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-apl2/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#4613])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-tglb1/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#7248])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-skl1/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [INCOMPLETE][10] ([i915#7248])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-apl2/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3323])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-skl1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@i915_module_load@resize-bar:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#6412])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-tglb1/igt@i915_module_l...@resize-bar.html

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-apl:  NOTRUN -> [FAIL][13] ([i915#7036])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-apl2/igt@i915_pipe_str...@stress-xrgb-untiled.html

  * igt@i915_pm_backlight@fade-with-dpms:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271]) +37 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-apl7/igt@i915_pm_backli...@fade-with-dpms.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][15] ([i915#3989] / [i915#454])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-skl7/igt@i915_pm...@dc6-dpms.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][16] ([i915#3763])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-skl7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-skl1/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-a-bad-rotation-90-4_tiled_dg2_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#6095])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/shard-tglb1/igt@kms_ccs@pipe-a-bad-rotation-90-4_tiled_dg2_mc_ccs.html

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][19] ([i915#3689] / 

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/mtl: limit second scaler vertical scaling in ver >= 14

[Ville Syrjälä]

On Tue, Nov 22, 2022 at 12:23:43PM +0200, Luca Coelho wrote:
> In newer hardware versions (i.e. display version >= 14), the second
> scaler doesn't support vertical scaling.
> 
> The current implementation of the scaling limits is simplified and
> only occurs when the planes are created, so we don't know which scaler
> is being used.
> 
> In order to handle separate scaling limits for horizontal and vertical
> scaling, and different limits per scaler, split the checks in two
> phases.  We first do a simple check during plane creation and use the
> best-case scenario (because we don't know the scaler that may be used
> at a later point) and then do a more specific check when the scalers
> are actually being set up.
> 
> Signed-off-by: Luca Coelho 
> ---
> 
> In v2:
>* fix DRM_PLANE_NO_SCALING renamed macros;
> 
> In v3:
>* No changes.
> 
> drivers/gpu/drm/i915/display/i9xx_plane.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_atomic.c   | 47 +++
>  .../gpu/drm/i915/display/intel_atomic_plane.c | 39 +--
>  .../gpu/drm/i915/display/intel_atomic_plane.h |  2 +-
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  4 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c   | 19 ++--
>  .../drm/i915/display/skl_universal_plane.c| 26 ++
>  7 files changed, 91 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
> b/drivers/gpu/drm/i915/display/i9xx_plane.c
> index ecaeb7dc196b..390e96f0692b 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
> @@ -326,9 +326,7 @@ i9xx_plane_check(struct intel_crtc_state *crtc_state,
>   if (ret)
>   return ret;
>  
> - ret = intel_atomic_plane_check_clipping(plane_state, crtc_state,
> - DRM_PLANE_NO_SCALING,
> - DRM_PLANE_NO_SCALING,
> + ret = intel_atomic_plane_check_clipping(plane_state, crtc_state, false,
>   
> i9xx_plane_has_windowing(plane));
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 6621aa245caf..43b1c7a227f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -38,6 +38,7 @@
>  #include "intel_atomic.h"
>  #include "intel_cdclk.h"
>  #include "intel_display_types.h"
> +#include "intel_fb.h"
>  #include "intel_global_state.h"
>  #include "intel_hdcp.h"
>  #include "intel_psr.h"
> @@ -375,6 +376,52 @@ static void intel_atomic_setup_scaler(struct 
> intel_crtc_scaler_state *scaler_sta
>   mode = SKL_PS_SCALER_MODE_DYN;
>   }
>  
> + if (plane_state && plane_state->hw.fb) {
> + const struct drm_framebuffer *fb = plane_state->hw.fb;
> + struct drm_rect *src = _state->uapi.src;
> + struct drm_rect *dst = _state->uapi.dst;

We want the scale factor checks for the pfit use case too. So this
stuff shouldn't be so tied into planes. I guess we could go with
a FIXME initially.

> + int hscale, vscale, max_vscale, max_hscale;
> +
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + /*
> +  * On versions 14 and up, only the first
> +  * scaler supports a vertical scaling factor
> +  * of more than 1.0, while a horizontal
> +  * scaling factor of 3.0 is supported.
> +  */
> + max_hscale = 0x3 - 1;
> + if (*scaler_id == 0)
> + max_vscale = 0x3 - 1;
> + else
> + max_vscale = 0x1;

We still have the chicken vs. egg problem here that we'd need to
consider the scale factors already when selecting the scaler.
But that could be another FIXME.

> +
> + } else if (DISPLAY_VER(dev_priv) >= 10 ||
> +!intel_format_info_is_yuv_semiplanar(fb->format, 
> fb->modifier)) {
> + max_hscale = 0x3 - 1;
> + max_vscale = 0x3 - 1;
> + } else {
> + max_hscale = 0x2 - 1;
> + max_vscale = 0x2 - 1;
> + }

Pre-glk hq scaler case not handled.

> +
> + /* Check if required scaling is within limits */
> + hscale = drm_rect_calc_hscale(src, dst, 1, max_hscale);
> + vscale = drm_rect_calc_vscale(src, dst, 1, max_vscale);
> +
> + if (hscale < 0 || vscale < 0) {
> + drm_dbg_kms(_priv->drm,
> + "Scaler %d doesn't support required plane 
> scaling\n",
> + *scaler_id);
> + drm_rect_debug_print("src: ", src, true);
> + 

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi Dave,

On Wed, 23 Nov 2022 15:35:50 +1000 David Airlie  wrote:
>
> Nothing gone wrong as such, just the drm-misc-next pull request was
> sent on a regular weekly cadence, then I merged it a few days later.
> The fix for this is still in the drm-misc-next queue for the next PR
> which I will get this week.

There is nothing currently in the drm-misc tree in linux-next (relative
to the drm tree).  And there was never a fix in there for this problem,
the commit was just removed when I reported it.

If there was a fix for this in the drm-misc tree, I would not have seen
the build failure.
-- 
Cheers,
Stephen Rothwell


pgpak_1Q96ZCI.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCHv3] drm/i915/fbc: Disable FBC when VT-d is enabled

[Ville Syrjälä]

On Wed, Nov 23, 2022 at 09:03:08AM +0530, Arun R Murthy wrote:
> The WaFbcTurnOffFbcWhenHyperVisorIsUsed is applicable for SKL, BXT and
> KBL.
> 
> Bspec: 0852
> 
> v2: Updated commit msg and corrected Bspec format(Jani N)
> v3: Updated the stepping information
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index b5ee5ea0d010..7c06ad454a7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1652,9 +1652,10 @@ static int intel_sanitize_fbc_option(struct 
> drm_i915_private *i915)
>  
>  static bool need_fbc_vtd_wa(struct drm_i915_private *i915)
>  {
> - /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
> + /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt,kbl */
>   if (i915_vtd_active(i915) &&
> - (IS_SKYLAKE(i915) || IS_BROXTON(i915))) {
> + (IS_SKYLAKE(i915) || IS_BROXTON(i915) ||
> + IS_KBL_DISPLAY_STEP(i915, STEP_A0, STEP_B0))) {

No one careas about pre-production hw once the thing has shipped.

>   drm_info(>drm,
>"Disabling framebuffer compression (FBC) to prevent 
> screen flicker with VT-d enabled\n");
>   return true;
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs

[Ghimiray, Himal Prasad]

Thanks Ashutosh for the clarification.

BR
Himal Ghimiray

> -Original Message-
> From: Dixit, Ashutosh 
> Sent: 23 November 2022 11:29
> To: Ghimiray, Himal Prasad 
> Cc: Tvrtko Ursulin ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs
> 
> On Tue, 22 Nov 2022 21:10:01 -0800, Ghimiray, Himal Prasad wrote:
> >
> > > -Original Message-
> > > From: Tvrtko Ursulin 
> > > Sent: 21 November 2022 17:17
> > > To: Ghimiray, Himal Prasad ; intel-
> > > g...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max
> > > memory bandwidth via sysfs
> > >
> > >
> > > On 21/11/2022 10:01, Himal Prasad Ghimiray wrote:
> > > > Export lmem maximum memory bandwidth to the userspace via sysfs
> > > >
> > > > (v2)
> > > > Add TODO comment to have client parts specific condition
> > > > (Anshuman) Remove prelim prefix from the sysfs node name (Aravind)
> > >
> > > Link to userspace consumer?
> > [Ghimiray, Himal Prasad]
> >
> > Does above comment means stating name of sysfs node in commit
> message ?
> 
> No. It means that there has to be a "real" open source userspace program
> (like Mesa, Level-0/OneApi or another accepted program or UMD) which is
> actually reading the sysfs file exposed. Without such a consumer, the sysfs
> addition will not be accepted upstream.
> 
> E.g. see cover letter here:
> 
> https://patchwork.freedesktop.org/series/106460/
> 
> "An approved Level-0/oneAPI UMD pull request which consumes the
> exposed defaults can be seen here:
>   https://github.com/intel/compute-runtime/pull/552
> "
> 
> Thanks.
> --
> Ashutosh

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs

[Dixit, Ashutosh]

On Tue, 22 Nov 2022 21:10:01 -0800, Ghimiray, Himal Prasad wrote:
>
> > -Original Message-
> > From: Tvrtko Ursulin 
> > Sent: 21 November 2022 17:17
> > To: Ghimiray, Himal Prasad ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> > bandwidth via sysfs
> >
> >
> > On 21/11/2022 10:01, Himal Prasad Ghimiray wrote:
> > > Export lmem maximum memory bandwidth to the userspace via sysfs
> > >
> > > (v2)
> > > Add TODO comment to have client parts specific condition (Anshuman)
> > > Remove prelim prefix from the sysfs node name (Aravind)
> >
> > Link to userspace consumer?
> [Ghimiray, Himal Prasad]
>
> Does above comment means stating name of sysfs node in commit message ?

No. It means that there has to be a "real" open source userspace program
(like Mesa, Level-0/OneApi or another accepted program or UMD) which is
actually reading the sysfs file exposed. Without such a consumer, the sysfs
addition will not be accepted upstream.

E.g. see cover letter here:

https://patchwork.freedesktop.org/series/106460/

"An approved Level-0/oneAPI UMD pull request which consumes the exposed
defaults can be seen here:
https://github.com/intel/compute-runtime/pull/552
"

Thanks.
--
Ashutosh

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Update DG2 DMC version to v2.08 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: Update DG2 DMC version to v2.08 (rev2)
URL   : https://patchwork.freedesktop.org/series/64/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12418_full -> Patchwork_64v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_64v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_64v2_full, please notify your bug team to allow 
them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_64v2_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_universal_plane@cursor-fb-leak-pipe-c:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-iclb1/igt@kms_universal_pl...@cursor-fb-leak-pipe-c.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-iclb5/igt@kms_universal_pl...@cursor-fb-leak-pipe-c.html

  
Known issues


  Here are the changes found in Patchwork_64v2_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@fbdev@unaligned-write:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-skl4/igt@fb...@unaligned-write.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-skl9/igt@fb...@unaligned-write.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][5] -> [SKIP][6] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-apl:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-apl3/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#4613])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-tglb6/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#7248])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-skl7/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [INCOMPLETE][10] ([i915#7248])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-apl3/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3323])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-skl7/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@i915_module_load@resize-bar:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#6412])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-tglb6/igt@i915_module_l...@resize-bar.html

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-apl:  NOTRUN -> [FAIL][13] ([i915#7036])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-apl3/igt@i915_pipe_str...@stress-xrgb-untiled.html

  * igt@i915_pm_backlight@fade-with-dpms:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271]) +37 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-apl6/igt@i915_pm_backli...@fade-with-dpms.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][15] ([i915#3989] / [i915#454])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-skl7/igt@i915_pm...@dc6-dpms.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-apl:  [PASS][16] -> [DMESG-FAIL][17] ([i915#5334])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-apl8/igt@i915_selftest@live@gt_heartbeat.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-apl2/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#2521]) +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-skl10/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-edp-1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/shard-skl6/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-edp-1.html

  * 

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[David Airlie]

On Wed, Nov 23, 2022 at 3:21 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled':
> > fbmon.c:(.text+0x1e4): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/fbcmap.o: in function 
> > `fb_modesetting_disabled':
> > fbcmap.c:(.text+0x478): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/fbsysfs.o: in function 
> > `fb_modesetting_disabled':
> > fbsysfs.c:(.text+0xb64): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/modedb.o: in function 
> > `fb_modesetting_disabled':
> > modedb.c:(.text+0x129c): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/fbcvt.o: in function `fb_modesetting_disabled':
> > fbcvt.c:(.text+0x0): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> >
> > Caused by commit
> >
> >   0ba2fa8cbd29 ("fbdev: Add support for the nomodeset kernel parameter")
> >
> > This build does not have CONFIG_VIDEO_NOMODESET set.
> >
> > I applied the following patch for today.
> >
> > From 63f957a050c62478ed1348c5b204bc65c68df4d7 Mon Sep 17 00:00:00 2001
> > From: Stephen Rothwell 
> > Date: Thu, 17 Nov 2022 18:19:22 +1100
> > Subject: [PATCH] fix up for "fbdev: Add support for the nomodeset kernel 
> > parameter"
> >
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  include/linux/fb.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 3a822e4357b1..ea421724f733 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -807,7 +807,7 @@ extern int fb_find_mode(struct fb_var_screeninfo *var,
> >  #if defined(CONFIG_VIDEO_NOMODESET)
> >  bool fb_modesetting_disabled(const char *drvname);
> >  #else
> > -bool fb_modesetting_disabled(const char *drvname)
> > +static inline bool fb_modesetting_disabled(const char *drvname)
> >  {
> >   return false;
> >  }
> > --
> > 2.35.1
>
> This commit went away for a couple of linux-next releases, but now has
> reappeared in the drm tree :-(  What went wrong?

Nothing gone wrong as such, just the drm-misc-next pull request was
sent on a regular weekly cadence, then I merged it a few days later.
The fix for this is still in the drm-misc-next queue for the next PR
which I will get this week.

Dave.

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell  
wrote:
>
> After merging the drm-misc tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
> 
> ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled':
> fbmon.c:(.text+0x1e4): multiple definition of `fb_modesetting_disabled'; 
> drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> ld: drivers/video/fbdev/core/fbcmap.o: in function `fb_modesetting_disabled':
> fbcmap.c:(.text+0x478): multiple definition of `fb_modesetting_disabled'; 
> drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> ld: drivers/video/fbdev/core/fbsysfs.o: in function `fb_modesetting_disabled':
> fbsysfs.c:(.text+0xb64): multiple definition of `fb_modesetting_disabled'; 
> drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> ld: drivers/video/fbdev/core/modedb.o: in function `fb_modesetting_disabled':
> modedb.c:(.text+0x129c): multiple definition of `fb_modesetting_disabled'; 
> drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> ld: drivers/video/fbdev/core/fbcvt.o: in function `fb_modesetting_disabled':
> fbcvt.c:(.text+0x0): multiple definition of `fb_modesetting_disabled'; 
> drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> 
> Caused by commit
> 
>   0ba2fa8cbd29 ("fbdev: Add support for the nomodeset kernel parameter")
> 
> This build does not have CONFIG_VIDEO_NOMODESET set.
> 
> I applied the following patch for today.
> 
> From 63f957a050c62478ed1348c5b204bc65c68df4d7 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell 
> Date: Thu, 17 Nov 2022 18:19:22 +1100
> Subject: [PATCH] fix up for "fbdev: Add support for the nomodeset kernel 
> parameter"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  include/linux/fb.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 3a822e4357b1..ea421724f733 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -807,7 +807,7 @@ extern int fb_find_mode(struct fb_var_screeninfo *var,
>  #if defined(CONFIG_VIDEO_NOMODESET)
>  bool fb_modesetting_disabled(const char *drvname);
>  #else
> -bool fb_modesetting_disabled(const char *drvname)
> +static inline bool fb_modesetting_disabled(const char *drvname)
>  {
>   return false;
>  }
> -- 
> 2.35.1

This commit went away for a couple of linux-next releases, but now has
reappeared in the drm tree :-(  What went wrong?

I have reapplied the above patch...

-- 
Cheers,
Stephen Rothwell


pgpm9Iwk1mS5q.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH] drm/i915/hti: avoid theoretically possible negative shift

[Kees Cook]

On Tue, Nov 22, 2022 at 02:09:48PM +0200, Jani Nikula wrote:
> If phy is PHY_NONE, the shift to register bits becomes negative. Check
> and warn about this.
> 
> Reported-by: coverity-bot 
> References: https://lore.kernel.org/r/202211180848.D39006C@keescook
> Signed-off-by: Jani Nikula 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs

[Ghimiray, Himal Prasad]

> -Original Message-
> From: Tvrtko Ursulin 
> Sent: 21 November 2022 17:17
> To: Ghimiray, Himal Prasad ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs
> 
> 
> On 21/11/2022 10:01, Himal Prasad Ghimiray wrote:
> > Export lmem maximum memory bandwidth to the userspace via sysfs
> >
> > (v2)
> > Add TODO comment to have client parts specific condition (Anshuman)
> > Remove prelim prefix from the sysfs node name (Aravind)
> 
> Link to userspace consumer?
[Ghimiray, Himal Prasad] 
Does above comment means stating name of sysfs node in commit message ?

> 
> > Signed-off-by: Himal Prasad Ghimiray 
> > ---
> >   drivers/gpu/drm/i915/i915_reg.h   |  2 ++
> >   drivers/gpu/drm/i915/i915_sysfs.c | 28 
> >   2 files changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 8e1892d147741..1d59b84b86ad2
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6606,6 +6606,8 @@
> >   #define   POWER_SETUP_I1_WATTSREG_BIT(31)
> >   #define   POWER_SETUP_I1_SHIFT6   /* 10.6 fixed
> point format */
> >   #define   POWER_SETUP_I1_DATA_MASK
>   REG_GENMASK(15, 0)
> > +#define  PCODE_MEMORY_CONFIG   0x70
> > +#define
> MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH 0x0
> >   #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US   0x23
> >   #define   XEHP_PCODE_FREQUENCY_CONFIG 0x6e/* xehpsdv,
> pvc */
> >   /* XEHP_PCODE_FREQUENCY_CONFIG sub-commands (param1) */ diff --git
> > a/drivers/gpu/drm/i915/i915_sysfs.c
> > b/drivers/gpu/drm/i915/i915_sysfs.c
> > index 595e8b5749907..69df2012bd10e 100644
> > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > @@ -37,7 +37,10 @@
> >
> >   #include "i915_drv.h"
> >   #include "i915_sysfs.h"
> > +#include "i915_reg.h"
> >   #include "intel_pm.h"
> > +#include "intel_pcode.h"
> > +
> 
> Please don't do whitespace changes if there isn't a good reason.
[Ghimiray, Himal Prasad] 
Will address this.
> 
> >
> >   struct drm_i915_private *kdev_minor_to_i915(struct device *kdev)
> >   {
> > @@ -231,11 +234,36 @@ static void i915_setup_error_capture(struct device
> *kdev) {}
> >   static void i915_teardown_error_capture(struct device *kdev) {}
> >   #endif
> >
> > +static ssize_t
> > +lmem_max_bw_Mbps_show(struct device *dev, struct device_attribute
> > +*attr, char *buff) {
> > +   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > +   u32 val;
> > +   int err;
> > +
> > +   err = snb_pcode_read_p(>uncore, PCODE_MEMORY_CONFIG,
> > +
> MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH,
> > +  0x0, );
> > +   if (err)
> > +   return err;
> > +
> > +   return sysfs_emit(buff, "%u\n", val); }
> > +
> > +static DEVICE_ATTR_RO(lmem_max_bw_Mbps);
> > +
> >   void i915_setup_sysfs(struct drm_i915_private *dev_priv)
> >   {
> > struct device *kdev = dev_priv->drm.primary->kdev;
> > int ret;
> >
> > +   /*TODO: Need to add client Parts condition check. */
> 
> What does this mean? Are DG1 and DG2 not client parts?
> 
[Ghimiray, Himal Prasad] 
DG1 and Dg2 are client parts. Rather than adding individual platforms we need 
an identifier to
differentiate client parts from server part. 
> > +   if (IS_DG1(dev_priv) || IS_DG2(dev_priv)) {
> > +   ret = sysfs_create_file(>kobj,
> _attr_lmem_max_bw_Mbps.attr);
> > +   if (ret)
> > +   drm_err(_priv->drm, "Setting up sysfs to read
> max B/W
> > +failed\n");
> 
> I suggest at most drm_warn since error is ignored.
[Ghimiray, Himal Prasad] 
Will address this.
> 
> I also suggest expanding B/W to memory bandwidth. Maybe "Failed to create
> maximum memory bandwidth sysfs file"?
[Ghimiray, Himal Prasad] 
Will address this. "Failed to create maximum memory bandwidth sysfs file" looks 
better.
> 
> Regards,
> 
> Tvrtko
> 
> > +   }
> > +
> > if (HAS_L3_DPF(dev_priv)) {
> > ret = device_create_bin_file(kdev, _attrs);
> > if (ret)

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs

[Ghimiray, Himal Prasad]

> -Original Message-
> From: Gupta, Anshuman 
> Sent: 21 November 2022 16:59
> To: Ghimiray, Himal Prasad ; intel-
> g...@lists.freedesktop.org
> Cc: Auld, Matthew 
> Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs
> 
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Himal Prasad Ghimiray
> > Sent: Monday, November 21, 2022 3:32 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> > bandwidth via sysfs
> >
> > Export lmem maximum memory bandwidth to the userspace via sysfs
> >
> > (v2)
> > Add TODO comment to have client parts specific condition (Anshuman)
> > Remove prelim prefix from the sysfs node name (Aravind)
> >
> > Signed-off-by: Himal Prasad Ghimiray 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h   |  2 ++
> >  drivers/gpu/drm/i915/i915_sysfs.c | 28 
> >  2 files changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 8e1892d147741..1d59b84b86ad2
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6606,6 +6606,8 @@
> >  #definePOWER_SETUP_I1_WATTSREG_BIT(31)
> >  #definePOWER_SETUP_I1_SHIFT6   /* 10.6 fixed
> > point format */
> >  #definePOWER_SETUP_I1_DATA_MASK
> > REG_GENMASK(15, 0)
> > +#define  PCODE_MEMORY_CONFIG   0x70
> Please use DG1_ prefix as this mbox started from DG1 onwards.
[Ghimiray, Himal Prasad] 
Will address this.
>  And  please try to follow the ascending order for commands attest for the new
> command we are adding.
[Ghimiray, Himal Prasad] 
Ok.
> > +#define
> > MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH 0x0
> Here as well use DG1_ prefix.
[Ghimiray, Himal Prasad] OK.
> >  #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
> >  #define   XEHP_PCODE_FREQUENCY_CONFIG  0x6e/* xehpsdv,
> > pvc */
> >  /* XEHP_PCODE_FREQUENCY_CONFIG sub-commands (param1) */ diff --git
> > a/drivers/gpu/drm/i915/i915_sysfs.c
> > b/drivers/gpu/drm/i915/i915_sysfs.c
> > index 595e8b5749907..69df2012bd10e 100644
> > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > @@ -37,7 +37,10 @@
> >
> >  #include "i915_drv.h"
> >  #include "i915_sysfs.h"
> > +#include "i915_reg.h"
> >  #include "intel_pm.h"
> > +#include "intel_pcode.h"
> > +
> >
> >  struct drm_i915_private *kdev_minor_to_i915(struct device *kdev)  {
> > @@ -
> > 231,11 +234,36 @@ static void i915_setup_error_capture(struct device
> > *kdev) {}  static void i915_teardown_error_capture(struct device
> > *kdev) {} #endif
> >
> > +static ssize_t
> > +lmem_max_bw_Mbps_show(struct device *dev, struct device_attribute
> > +*attr, char *buff) {
> > +   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > +   u32 val;
> > +   int err;
> > +
> > +   err = snb_pcode_read_p(>uncore,
> > PCODE_MEMORY_CONFIG,
> > +
> > MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH,
> > +  0x0, );
> > +   if (err)
> > +   return err;
> > +
> > +   return sysfs_emit(buff, "%u\n", val); }
> > +
> > +static DEVICE_ATTR_RO(lmem_max_bw_Mbps);
> > +
> >  void i915_setup_sysfs(struct drm_i915_private *dev_priv)  {
> > struct device *kdev = dev_priv->drm.primary->kdev;
> > int ret;
> >
> > +   /*TODO: Need to add client Parts condition check. */
> Nit use space after '/*'
[Ghimiray, Himal Prasad] 
Will address this.
> /* TODO: Need to add client parts specific conditional check */ would be good.
> BR,
> Anshuman Gupta.
> 
> > +   if (IS_DG1(dev_priv) || IS_DG2(dev_priv)) {
> > +   ret = sysfs_create_file(>kobj,
> > _attr_lmem_max_bw_Mbps.attr);
> > +   if (ret)
> > +   drm_err(_priv->drm, "Setting up sysfs to read
> > max B/W failed\n");
> > +   }
> > +
> > if (HAS_L3_DPF(dev_priv)) {
> > ret = device_create_bin_file(kdev, _attrs);
> > if (ret)
> > --
> > 2.25.1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hti: avoid theoretically possible negative shift

[Patchwork]

== Series Details ==

Series: drm/i915/hti: avoid theoretically possible negative shift
URL   : https://patchwork.freedesktop.org/series/92/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418_full -> Patchwork_92v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_92v1_full that come from known 
issues:

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[FAIL][48], [PASS][49], [PASS][50]) ([i915#4392])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk6/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk5/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk6/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk5/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk5/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk3/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk8/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk8/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk8/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk9/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk9/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk9/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk5/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk5/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk5/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk3/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_92v1/shard-glk3/boot.html
   [43]: 

Re: [Intel-gfx] [PATCH v4] drm/i915/mtl: Media GT and Render GT share common GGTT

[Iddamsetty, Aravind]

On 23-11-2022 05:29, Matt Roper wrote:
> On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared between media and render GT. As a
>> result any updates in GGTT shall invalidate TLB of GTs sharing it and
>> similarly any operation on GGTT requiring an action on a GT will have to
>> involve all GTs sharing it. setup_private_pat was being done on a per
>> GGTT based as that doesn't touch any GGTT structures moved it to per GT
>> based.
>>
>> BSPEC: 63834
>>
>> v2:
>> 1. Add details to commit msg
>> 2. includes fix for failure to add item to ggtt->gt_list, as suggested
>> by Lucas
>> 3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
>> it.
>> 4. setup_private_pat moved out of intel_gt_tiles_init
>>
>> v3:
>> 1. Move out for_each_gt from i915_driver.c (Jani Nikula)
>>
>> v4: drop using RCU primitives on ggtt->gt_list as it is not an RCU list
>> (Matt Roper)
>>
>> Cc: Matt Roper 
>> Signed-off-by: Aravind Iddamsetty 
> 
> Reviewed-by: Matt Roper 

Thanks Matt, could you also help with merging the change.

Regards,
Aravind.
> 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 54 +--
>>  drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
>>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
>>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
>>  drivers/gpu/drm/i915/i915_driver.c| 12 ++---
>>  drivers/gpu/drm/i915/i915_gem.c   |  2 +
>>  drivers/gpu/drm/i915/i915_gem_evict.c | 51 +++--
>>  drivers/gpu/drm/i915/i915_vma.c   |  5 ++-
>>  drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
>>  9 files changed, 111 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
>> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> index 8145851ad23d..7644738b9cdb 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> @@ -8,6 +8,7 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space 
>> *vm)
>>  
>>  void i915_ggtt_suspend(struct i915_ggtt *ggtt)
>>  {
>> +struct intel_gt *gt;
>> +
>>  i915_ggtt_suspend_vm(>vm);
>>  ggtt->invalidate(ggtt);
>>  
>> -intel_gt_check_and_clear_faults(ggtt->vm.gt);
>> +list_for_each_entry(gt, >gt_list, ggtt_link)
>> +intel_gt_check_and_clear_faults(gt);
>>  }
>>  
>>  void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
>> @@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt 
>> *ggtt)
>>  
>>  static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
>>  {
>> -struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>>  struct drm_i915_private *i915 = ggtt->vm.i915;
>>  
>>  gen8_ggtt_invalidate(ggtt);
>>  
>> -if (GRAPHICS_VER(i915) >= 12)
>> -intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
>> -  GEN12_GUC_TLB_INV_CR_INVALIDATE);
>> -else
>> -intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +if (GRAPHICS_VER(i915) >= 12) {
>> +struct intel_gt *gt;
>> +
>> +list_for_each_entry(gt, >gt_list, ggtt_link)
>> +intel_uncore_write_fw(gt->uncore,
>> +  GEN12_GUC_TLB_INV_CR,
>> +  GEN12_GUC_TLB_INV_CR_INVALIDATE);
>> +} else {
>> +intel_uncore_write_fw(ggtt->vm.gt->uncore,
>> +  GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +}
>>  }
>>  
>>  u64 gen8_ggtt_pte_encode(dma_addr_t addr,
>> @@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>>  
>>  ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>>  
>> -setup_private_pat(ggtt->vm.gt);
>> -
>>  return ggtt_probe_common(ggtt, size);
>>  }
>>  
>> @@ -1196,7 +1203,14 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, 
>> struct intel_gt *gt)
>>   */
>>  int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>>  {
>> -int ret;
>> +struct intel_gt *gt;
>> +int ret, i;
>> +
>> +for_each_gt(gt, i915, i) {
>> +ret = intel_gt_assign_ggtt(gt);
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
>>  if (ret)
>> @@ -1208,6 +1222,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>>  return 0;
>>  }
>>  
>> +struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
>> +{
>> +struct i915_ggtt *ggtt;
>> +
>> +ggtt = drmm_kzalloc(>drm, sizeof(*ggtt), GFP_KERNEL);
>> +if (!ggtt)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +INIT_LIST_HEAD(>gt_list);
>> +
>> +return ggtt;
>> +}
>> +
>>  int i915_ggtt_enable_hw(struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Disable FBC when VT-d is enabled

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: Disable FBC when VT-d is enabled
URL   : https://patchwork.freedesktop.org/series/111239/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12419 -> Patchwork_111239v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/index.html

Participating hosts (32 -> 33)
--

  Additional (2): bat-rpls-2 bat-atsm-1 
  Missing(1): fi-tgl-dsi 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111239v1:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_module_load@load:
- {bat-atsm-1}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/bat-atsm-1/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@gt_engines:
- {bat-dg2-8}:[PASS][2] -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/bat-dg2-8/igt@i915_selftest@live@gt_engines.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/bat-dg2-8/igt@i915_selftest@live@gt_engines.html

  
Known issues


  Here are the changes found in Patchwork_111239v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#4312] / 
[i915#5594])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][7] ([i915#7229]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@migrate:
- {bat-adlp-6}:   [INCOMPLETE][11] ([i915#7348]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/bat-adlp-6/igt@i915_selftest@l...@migrate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111239v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7348]: https://gitlab.freedesktop.org/drm/intel/issues/7348
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561


Build changes
-

  * 

[Intel-gfx] [PATCHv3] drm/i915/fbc: Disable FBC when VT-d is enabled

[Arun R Murthy]

The WaFbcTurnOffFbcWhenHyperVisorIsUsed is applicable for SKL, BXT and
KBL.

Bspec: 0852

v2: Updated commit msg and corrected Bspec format(Jani N)
v3: Updated the stepping information

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index b5ee5ea0d010..7c06ad454a7d 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1652,9 +1652,10 @@ static int intel_sanitize_fbc_option(struct 
drm_i915_private *i915)
 
 static bool need_fbc_vtd_wa(struct drm_i915_private *i915)
 {
-   /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
+   /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt,kbl */
if (i915_vtd_active(i915) &&
-   (IS_SKYLAKE(i915) || IS_BROXTON(i915))) {
+   (IS_SKYLAKE(i915) || IS_BROXTON(i915) ||
+   IS_KBL_DISPLAY_STEP(i915, STEP_A0, STEP_B0))) {
drm_info(>drm,
 "Disabling framebuffer compression (FBC) to prevent 
screen flicker with VT-d enabled\n");
return true;
-- 
2.25.1

Re: [Intel-gfx] [PATCH v2] drm/i915/perf: Do not parse context image for HSW

[Dixit, Ashutosh]

On Tue, 22 Nov 2022 18:07:00 -0800, Umesh Nerlige Ramappa wrote:
>

Hi Umesh,

> An earlier commit introduced a mechanism to parse the context image to
> find the OA context control offset. This resulted in an NPD on haswell
> when gem_context was passed into i915_perf_open_ioctl params. Haswell
> does not support logical ring contexts, so ensure that the context image
> is parsed only for platforms with logical ring contexts and also
> validate lrc_reg_state.
>
> v2: Fix build failure
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7432
> Fixes: a5c3a3cbf029 ("drm/i915/perf: Determine gen12 oa ctx offset at 
> runtime")
> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 00e09bb18b13..dbd785974f20 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1383,6 +1383,9 @@ static u32 oa_context_image_offset(struct intel_context 
> *ce, u32 reg)
>   u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
>   u32 *state = ce->lrc_reg_state;
>
> + if (drm_WARN_ON(>engine->i915->drm, state == NULL))
> + return U32_MAX;
> +

So if we didn't add the HAS_LOGICAL_RING_CONTEXTS check below state would
be NULL correct? I couldn't figure out how it is NULL on HSW looking at the
code (with the context image pin/unpin).

>   for (offset = 0; offset < len; ) {
>   if (IS_MI_LRI_CMD(state[offset])) {
>   /*
> @@ -1447,7 +1450,8 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
> *stream)
>   if (IS_ERR(ce))
>   return PTR_ERR(ce);
>
> - if (engine_supports_mi_query(stream->engine)) {
> + if (engine_supports_mi_query(stream->engine) &&
> + HAS_LOGICAL_RING_CONTEXTS(stream->perf->i915)) {

This check looks fine since we seem to be looking inside ce->lrc_reg_state
for oactxctrl.

Overall looks fine so this is:

Reviewed-by: Ashutosh Dixit 


>   /*
>* We are enabling perf query here. If we don't find the context
>* offset here, just return an error.
> --
> 2.36.1
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Do not parse context image for HSW (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: Do not parse context image for HSW (rev2)
URL   : https://patchwork.freedesktop.org/series/111231/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12419 -> Patchwork_111231v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/index.html

Participating hosts (32 -> 32)
--

  Additional (2): bat-rpls-2 bat-dg1-6 
  Missing(2): fi-rkl-11600 fi-tgl-dsi 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111231v2:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@migrate:
- {bat-dg2-11}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  
Known issues


  Here are the changes found in Patchwork_111231v2 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_mmap@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][3] ([i915#4083])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6:  NOTRUN -> [SKIP][6] ([i915#7561])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#6621])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6:  NOTRUN -> [SKIP][8] ([i915#4215])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-6:  NOTRUN -> [SKIP][9] ([i915#4212]) +7 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_chamelium@hdmi-crc-fast:
- bat-dg1-6:  NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#4103] / [i915#4213])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-6:  NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#1072] / [i915#4078]) +3 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([i915#3555])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-gtt:
- bat-dg1-6:  NOTRUN -> [SKIP][15] ([i915#3708] / [i915#4077]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@prime_v...@basic-gtt.html

  * igt@prime_vgem@basic-read:
- bat-dg1-6:  NOTRUN -> [SKIP][16] ([i915#3708]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- bat-dg1-6:  NOTRUN -> [SKIP][17] ([i915#3708] / [i915#4873])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111231v2/bat-dg1-6/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
   [18]: 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/perf: Do not parse context image for HSW (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: Do not parse context image for HSW (rev2)
URL   : https://patchwork.freedesktop.org/series/111231/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for 
intel_gt_mcr_wait_for_reg_fw(). Prototype was for intel_gt_mcr_wait_for_reg() 
instead
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for 
intel_gt_mcr_wait_for_reg_fw(). Prototype was for intel_gt_mcr_wait_for_reg() 
instead

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Do not parse context image for HSW (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: Do not parse context image for HSW (rev2)
URL   : https://patchwork.freedesktop.org/series/111231/
State : warning

== Summary ==

Error: dim checkpatch failed
bdbecc07a5b3 drm/i915/perf: Do not parse context image for HSW
-:27: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!state"
#27: FILE: drivers/gpu/drm/i915/i915_perf.c:1386:
+   if (drm_WARN_ON(>engine->i915->drm, state == NULL))

total: 0 errors, 0 warnings, 1 checks, 18 lines checked

Re: [Intel-gfx] [PATCH] drm/i915/uc: Fix table order verification to check all FW types

[Ceraolo Spurio, Daniele]

On 11/22/2022 3:33 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.

Note that the long term plan is to convert this code to be a mock
selftest. It is already only compiled in when selftests are enabled.
And the work involved in the conversion was estimated to be
non-trivial. So that conversion is currently low on the priority list.

Signed-off-by: John Harrison 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 0c80ba51a4bdc..31613c7e0838b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -238,7 +238,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
[INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
[INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
};
-   static bool verified;
+   static bool verified[INTEL_UC_FW_NUM_TYPES];
const struct uc_fw_platform_requirement *fw_blobs;
enum intel_platform p = INTEL_INFO(i915)->platform;
u32 fw_count;
@@ -291,8 +291,8 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
}
  
  	/* make sure the list is ordered as expected */

-   if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified) {
-   verified = true;
+   if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified[uc_fw->type]) {
+   verified[uc_fw->type] = true;
  
  		for (i = 1; i < fw_count; i++) {

/* Next platform is good: */
@@ -343,7 +343,8 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
continue;
  
  bad:

-   drm_err(>drm, "Invalid FW blob order: %s r%u 
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
+   drm_err(>drm, "Invalid %s blob order: %s r%u 
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
+   intel_uc_fw_type_repr(uc_fw->type),
intel_platform_name(fw_blobs[i - 1].p), 
fw_blobs[i - 1].rev,
fw_blobs[i - 1].blob.legacy ? "L" : "v",
fw_blobs[i - 1].blob.major,

[Intel-gfx] [PATCH v2] drm/i915/perf: Do not parse context image for HSW

[Umesh Nerlige Ramappa]

An earlier commit introduced a mechanism to parse the context image to
find the OA context control offset. This resulted in an NPD on haswell
when gem_context was passed into i915_perf_open_ioctl params. Haswell
does not support logical ring contexts, so ensure that the context image
is parsed only for platforms with logical ring contexts and also
validate lrc_reg_state.

v2: Fix build failure

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7432
Fixes: a5c3a3cbf029 ("drm/i915/perf: Determine gen12 oa ctx offset at runtime")
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 00e09bb18b13..dbd785974f20 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1383,6 +1383,9 @@ static u32 oa_context_image_offset(struct intel_context 
*ce, u32 reg)
u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
u32 *state = ce->lrc_reg_state;
 
+   if (drm_WARN_ON(>engine->i915->drm, state == NULL))
+   return U32_MAX;
+
for (offset = 0; offset < len; ) {
if (IS_MI_LRI_CMD(state[offset])) {
/*
@@ -1447,7 +1450,8 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
if (IS_ERR(ce))
return PTR_ERR(ce);
 
-   if (engine_supports_mi_query(stream->engine)) {
+   if (engine_supports_mi_query(stream->engine) &&
+   HAS_LOGICAL_RING_CONTEXTS(stream->perf->i915)) {
/*
 * We are enabling perf query here. If we don't find the context
 * offset here, just return an error.
-- 
2.36.1

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Add GuC CT specific debug print wrappers

[John Harrison]

On 11/22/2022 09:54, Michal Wajdeczko wrote:

On 18.11.2022 02:58, john.c.harri...@intel.com wrote:

From: John Harrison 

Re-work the existing GuC CT printers and extend as required to match
the new wrapping scheme.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 222 +++---
  1 file changed, 113 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 2b22065e87bf9..9d404fb377637 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -18,31 +18,49 @@ static inline struct intel_guc *ct_to_guc(struct 
intel_guc_ct *ct)
return container_of(ct, struct intel_guc, ct);
  }
  
-static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)

-{
-   return guc_to_gt(ct_to_guc(ct));
-}
-
  static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
  {
-   return ct_to_gt(ct)->i915;
-}
+   struct intel_guc *guc = ct_to_guc(ct);
+   struct intel_gt *gt = guc_to_gt(guc);
  
-static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)

-{
-   return _to_i915(ct)->drm;
+   return gt->i915;
  }
  
-#define CT_ERROR(_ct, _fmt, ...) \

-   drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+#define ct_err(_ct, _fmt, ...) \
+   guc_err(ct_to_guc(_ct), "CT " _fmt, ##__VA_ARGS__)
+
+#define ct_warn(_ct, _fmt, ...) \
+   guc_warn(ct_to_guc(_ct), "CT " _fmt, ##__VA_ARGS__)
+
+#define ct_notice(_ct, _fmt, ...) \
+   guc_notice(ct_to_guc(_ct), "CT " _fmt, ##__VA_ARGS__)
+
+#define ct_info(_ct, _fmt, ...) \
+   guc_info(ct_to_guc(_ct), "CT " _fmt, ##__VA_ARGS__)
+
  #ifdef CONFIG_DRM_I915_DEBUG_GUC
-#define CT_DEBUG(_ct, _fmt, ...) \
-   drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+#define ct_dbg(_ct, _fmt, ...) \
+   guc_dbg(ct_to_guc(_ct), "CT " _fmt, ##__VA_ARGS__)
  #else
-#define CT_DEBUG(...)  do { } while (0)
+#define ct_dbg(...)do { } while (0)
  #endif
-#define CT_PROBE_ERROR(_ct, _fmt, ...) \
-   i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+
+#define ct_probe_error(_ct, _fmt, ...) \
+   do { \
+   if (i915_error_injected()) \
+   ct_dbg(_ct, _fmt, ##__VA_ARGS__); \
+   else \
+   ct_err(_ct, _fmt, ##__VA_ARGS__); \
+   } while (0)

guc_probe_error ?


+
+#define ct_WARN_ON(_ct, _condition) \
+   ct_WARN(_ct, _condition, "%s", "ct_WARN_ON(" __stringify(_condition) 
")")
+
+#define ct_WARN(_ct, _condition, _fmt, ...) \
+   guc_WARN(ct_to_guc(_ct), _condition, "CT " _fmt, ##__VA_ARGS__)
+
+#define ct_WARN_ONCE(_ct, _condition, _fmt, ...) \
+   guc_WARN_ONCE(ct_to_guc(_ct), _condition, "CT " _fmt, ##__VA_ARGS__)
  
  /**

   * DOC: CTB Blob
@@ -170,7 +188,7 @@ static int ct_control_enable(struct intel_guc_ct *ct, bool 
enable)
err = guc_action_control_ctb(ct_to_guc(ct), enable ?
 GUC_CTB_CONTROL_ENABLE : 
GUC_CTB_CONTROL_DISABLE);
if (unlikely(err))
-   CT_PROBE_ERROR(ct, "Failed to control/%s CTB (%pe)\n",
+   ct_probe_error(ct, "Failed to control/%s CTB (%pe)\n",
   str_enable_disable(enable), ERR_PTR(err));

btw, shouldn't we change all messages to start with lowercase ?

was:
"CT0: Failed to control/%s CTB (%pe)"
is:
"GT0: GuC CT Failed to control/%s CTB (%pe)"

unless we keep colon (as suggested by Tvrtko) as then:

"GT0: GuC CT: Failed to control/%s CTB (%pe)"
Blanket added the colon makes it messy when a string actually wants to 
start with the prefix. The rule I've been using is lower case word when 
the prefix was part of the string, upper case word when the prefix is 
just being added as a prefix. I originally just had the prefix as raw 
with no trailing space, so the individual print could decide to add a 
colon, a space, or whatever as appropriate. But that just makes for 
messy code with some files having every string look like ": Stuff 
happened" and other files have every string look like " failed to ...". 
The current version seems to be the most readable from the point of view 
of writing the code and of reading the dmesg results.


And to be clear, the 'CT0' you have in your 'was' example only exists in 
the internal tree. It never made it to upstream. It is also just plain 
wrong. Each GT has two CTs - send and receive. So having 'CT1' meaning 
some random CT on GT1 (as opposed to the read channel on GT0, for 
example) was very confusing.


John.




Michal

  
  	return err;

@@ -201,7 +219,7 @@ static int ct_register_buffer(struct intel_guc_ct *ct, bool 
send,
   size);
if (unlikely(err))
  failed:
-   CT_PROBE_ERROR(ct, "Failed to register %s buffer (%pe)\n",
+   ct_probe_error(ct, "Failed to register %s buffer (%pe)\n",
  

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/perf: Do not parse context image for HSW

[Patchwork]

== Series Details ==

Series: drm/i915/perf: Do not parse context image for HSW
URL   : https://patchwork.freedesktop.org/series/111231/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  CC [M]  drivers/gpu/drm/i915/i915_perf.o
drivers/gpu/drm/i915/i915_perf.c: In function ‘oa_context_image_offset’:
drivers/gpu/drm/i915/i915_perf.c:1387:3: error: expected ‘)’ before ‘return’
   return U32_MAX;
   ^~
drivers/gpu/drm/i915/i915_perf.c:1386:5: note: to match this ‘(’
  if (drm_WARN_ON(>engine->i915->drm, state == NULL)
 ^
drivers/gpu/drm/i915/i915_perf.c:1406:1: error: expected expression before ‘}’ 
token
 }
 ^
drivers/gpu/drm/i915/i915_perf.c:1383:14: error: unused variable ‘len’ 
[-Werror=unused-variable]
  u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
  ^~~
drivers/gpu/drm/i915/i915_perf.c:1383:6: error: unused variable ‘offset’ 
[-Werror=unused-variable]
  u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
  ^~
drivers/gpu/drm/i915/i915_perf.c:1406:1: error: no return statement in function 
returning non-void [-Werror=return-type]
 }
 ^
At top level:
drivers/gpu/drm/i915/i915_perf.c:1363:13: error: ‘oa_find_reg_in_lri’ defined 
but not used [-Werror=unused-function]
 static bool oa_find_reg_in_lri(u32 *state, u32 reg, u32 *offset, u32 end)
 ^~
cc1: all warnings being treated as errors
scripts/Makefile.build:250: recipe for target 
'drivers/gpu/drm/i915/i915_perf.o' failed
make[5]: *** [drivers/gpu/drm/i915/i915_perf.o] Error 1
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed
make[4]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed
make[3]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed
make[2]: *** [drivers/gpu] Error 2
scripts/Makefile.build:500: recipe for target 'drivers' failed
make[1]: *** [drivers] Error 2
Makefile:1992: recipe for target '.' failed
make: *** [.] Error 2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Fix table order verification to check all FW types

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Fix table order verification to check all FW types
URL   : https://patchwork.freedesktop.org/series/111228/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12419 -> Patchwork_111228v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/index.html

Participating hosts (32 -> 33)
--

  Additional (2): bat-rpls-2 bat-dg1-6 
  Missing(1): fi-tgl-dsi 

Known issues


  Here are the changes found in Patchwork_111228v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_mmap@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][1] ([i915#4083])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][2] ([i915#4079]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6:  NOTRUN -> [SKIP][4] ([i915#7561])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-6:  NOTRUN -> [SKIP][5] ([i915#6621])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6:  NOTRUN -> [SKIP][6] ([i915#4215])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#4212]) +7 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_chamelium@hdmi-crc-fast:
- bat-dg1-6:  NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- bat-dg1-6:  NOTRUN -> [SKIP][9] ([i915#4103] / [i915#4213])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-6:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#1072] / [i915#4078]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-6:  NOTRUN -> [SKIP][12] ([i915#3555])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-gtt:
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#3708] / [i915#4077]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@prime_v...@basic-gtt.html

  * igt@prime_vgem@basic-userptr:
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([i915#3708] / [i915#4873])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@prime_v...@basic-userptr.html

  * igt@prime_vgem@basic-write:
- bat-dg1-6:  NOTRUN -> [SKIP][15] ([i915#3708]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/bat-dg1-6/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][16] ([i915#7229]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12419/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111228v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@migrate:
- {bat-adlp-6}:   [INCOMPLETE][20] ([i915#7348]) -> 

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: Add GuC specific debug print wrappers

[John Harrison]

On 11/22/2022 09:42, Michal Wajdeczko wrote:

On 18.11.2022 02:58, john.c.harri...@intel.com wrote:

From: John Harrison 

Create a set of GuC printers and start using them.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 32 --
  drivers/gpu/drm/i915/gt/uc/intel_guc.h| 35 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  8 +--
  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 48 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 19 +++---
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 37 ++-
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c |  7 +--
  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 55 +++-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 62 +--
  drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 34 +-
  .../drm/i915/gt/uc/selftest_guc_hangcheck.c   | 22 +++
  .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   | 10 +--
  12 files changed, 179 insertions(+), 190 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 52aede324788e..d9972510ee29b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -94,8 +94,8 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
  
  	spin_lock_irq(gt->irq_lock);

-   WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
+   guc_WARN_ON_ONCE(guc, intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
+gt->pm_guc_events);
gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(gt->irq_lock);
  
@@ -339,7 +339,7 @@ static void guc_init_params(struct intel_guc *guc)

params[GUC_CTL_DEVID] = guc_ctl_devid(guc);
  
  	for (i = 0; i < GUC_CTL_MAX_DWORDS; i++)

-   DRM_DEBUG_DRIVER("param[%2d] = %#x\n", i, params[i]);
+   guc_dbg(guc, "init param[%2d] = %#x\n", i, params[i]);
  }
  
  /*

@@ -451,7 +451,7 @@ int intel_guc_init(struct intel_guc *guc)
intel_uc_fw_fini(>fw);
  out:
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
-   i915_probe_error(gt->i915, "failed with %d\n", ret);
+   guc_probe_error(guc, "init failed with %d\n", ret);
return ret;
  }
  
@@ -484,7 +484,6 @@ void intel_guc_fini(struct intel_guc *guc)

  int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
  {
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
u32 header;
int i;
@@ -519,8 +518,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
   10, 10, );
if (unlikely(ret)) {
  timeout:
-   drm_err(>drm, "mmio request %#x: no reply %x\n",
-   request[0], header);
+   guc_err(guc, "mmio request %#x: no reply %x\n", request[0], 
header);
goto out;
}
  
@@ -541,8 +539,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,

if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == 
GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
  
-		drm_dbg(>drm, "mmio request %#x: retrying, reason %u\n",

-   request[0], reason);
+   guc_dbg(guc, "mmio request %#x: retrying, reason %u\n", 
request[0], reason);
goto retry;
}
  
@@ -550,16 +547,14 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,

u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
  
-		drm_err(>drm, "mmio request %#x: failure %x/%u\n",

-   request[0], error, hint);
+   guc_err(guc, "mmio request %#x: failure %x/%u\n", request[0], 
error, hint);
ret = -ENXIO;
goto out;
}
  
  	if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {

  proto:
-   drm_err(>drm, "mmio request %#x: unexpected reply %#x\n",
-   request[0], header);
+   guc_err(guc, "mmio request %#x: unexpected reply %#x\n", 
request[0], header);
ret = -EPROTO;
goto out;
}
@@ -601,9 +596,9 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc 
*guc,
msg = payload[0] & guc->msg_enabled_mask;
  
  	if (msg & INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)

-   drm_err(_to_gt(guc)->i915->drm, "Received early GuC crash dump 
notification!\n");
+   guc_err(guc, "early notification: Crash dump!\n");
if (msg & INTEL_GUC_RECV_MSG_EXCEPTION)
-

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dvo: Further DVO fixes/cleanups

[Patchwork]

== Series Details ==

Series: drm/i915/dvo: Further DVO fixes/cleanups
URL   : https://patchwork.freedesktop.org/series/91/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12417_full -> Patchwork_91v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_91v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-iclb1/igt@gem_exec_balan...@parallel-out-fence.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-iclb8/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2846])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-glk2/igt@gem_exec_f...@basic-deadline.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-glk9/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_nop@basic-parallel:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-glk5/igt@gem_exec_...@basic-parallel.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-glk2/igt@gem_exec_...@basic-parallel.html

  * igt@i915_pm_backlight@fade-with-dpms:
- shard-apl:  NOTRUN -> [SKIP][7] ([fdo#109271]) +19 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-apl3/igt@i915_pm_backli...@fade-with-dpms.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-skl:  [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-skl1/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-skl9/igt@i915_selftest@live@gt_heartbeat.html

  * 
igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-1:
- shard-glk:  [PASS][10] -> [INCOMPLETE][11] ([i915#5584])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-glk1/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-1.html

  * igt@kms_big_fb@4-tiled-32bpp-rotate-180:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-skl9/igt@kms_big...@4-tiled-32bpp-rotate-180.html

  * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-apl3/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html

  * igt@kms_chamelium@dp-crc-multiple:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-apl3/igt@kms_chamel...@dp-crc-multiple.html

  * igt@kms_color_chamelium@ctm-limited-range:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109284] / [fdo#111827])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-iclb8/igt@kms_color_chamel...@ctm-limited-range.html

  * igt@kms_color_chamelium@ctm-negative:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-skl9/igt@kms_color_chamel...@ctm-negative.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-glk1/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1:
- shard-apl:  [PASS][18] -> [FAIL][19] ([i915#79])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-apl8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-apl8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#79])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12417/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_91v1/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html

  * 

Re: [Intel-gfx] [PATCH v4] drm/i915/mtl: Media GT and Render GT share common GGTT

[Matt Roper]

On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
> On XE_LPM+ platforms the media engines are carved out into a separate
> GT but have a common GGTMMADR address range which essentially makes
> the GGTT address space to be shared between media and render GT. As a
> result any updates in GGTT shall invalidate TLB of GTs sharing it and
> similarly any operation on GGTT requiring an action on a GT will have to
> involve all GTs sharing it. setup_private_pat was being done on a per
> GGTT based as that doesn't touch any GGTT structures moved it to per GT
> based.
> 
> BSPEC: 63834
> 
> v2:
> 1. Add details to commit msg
> 2. includes fix for failure to add item to ggtt->gt_list, as suggested
> by Lucas
> 3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
> it.
> 4. setup_private_pat moved out of intel_gt_tiles_init
> 
> v3:
> 1. Move out for_each_gt from i915_driver.c (Jani Nikula)
> 
> v4: drop using RCU primitives on ggtt->gt_list as it is not an RCU list
> (Matt Roper)
> 
> Cc: Matt Roper 
> Signed-off-by: Aravind Iddamsetty 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 54 +--
>  drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
>  drivers/gpu/drm/i915/i915_driver.c| 12 ++---
>  drivers/gpu/drm/i915/i915_gem.c   |  2 +
>  drivers/gpu/drm/i915/i915_gem_evict.c | 51 +++--
>  drivers/gpu/drm/i915/i915_vma.c   |  5 ++-
>  drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
>  9 files changed, 111 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 8145851ad23d..7644738b9cdb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
>  
>  void i915_ggtt_suspend(struct i915_ggtt *ggtt)
>  {
> + struct intel_gt *gt;
> +
>   i915_ggtt_suspend_vm(>vm);
>   ggtt->invalidate(ggtt);
>  
> - intel_gt_check_and_clear_faults(ggtt->vm.gt);
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_gt_check_and_clear_faults(gt);
>  }
>  
>  void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> @@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
>  
>  static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
>  {
> - struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>   struct drm_i915_private *i915 = ggtt->vm.i915;
>  
>   gen8_ggtt_invalidate(ggtt);
>  
> - if (GRAPHICS_VER(i915) >= 12)
> - intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
> -   GEN12_GUC_TLB_INV_CR_INVALIDATE);
> - else
> - intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + if (GRAPHICS_VER(i915) >= 12) {
> + struct intel_gt *gt;
> +
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_uncore_write_fw(gt->uncore,
> +   GEN12_GUC_TLB_INV_CR,
> +   GEN12_GUC_TLB_INV_CR_INVALIDATE);
> + } else {
> + intel_uncore_write_fw(ggtt->vm.gt->uncore,
> +   GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + }
>  }
>  
>  u64 gen8_ggtt_pte_encode(dma_addr_t addr,
> @@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>  
>   ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>  
> - setup_private_pat(ggtt->vm.gt);
> -
>   return ggtt_probe_common(ggtt, size);
>  }
>  
> @@ -1196,7 +1203,14 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, 
> struct intel_gt *gt)
>   */
>  int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>  {
> - int ret;
> + struct intel_gt *gt;
> + int ret, i;
> +
> + for_each_gt(gt, i915, i) {
> + ret = intel_gt_assign_ggtt(gt);
> + if (ret)
> + return ret;
> + }
>  
>   ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
>   if (ret)
> @@ -1208,6 +1222,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>   return 0;
>  }
>  
> +struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
> +{
> + struct i915_ggtt *ggtt;
> +
> + ggtt = drmm_kzalloc(>drm, sizeof(*ggtt), GFP_KERNEL);
> + if (!ggtt)
> + return ERR_PTR(-ENOMEM);
> +
> + INIT_LIST_HEAD(>gt_list);
> +
> + return ggtt;
> +}
> +
>  int i915_ggtt_enable_hw(struct drm_i915_private *i915)
>  {
>   if (GRAPHICS_VER(i915) < 6)
> @@ -1296,9 +1323,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
>  
>  void i915_ggtt_resume(struct i915_ggtt *ggtt)
>  {
> + struct intel_gt *gt;
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow error capture without a request

[Patchwork]

== Series Details ==

Series: drm/i915: Allow error capture without a request
URL   : https://patchwork.freedesktop.org/series/111224/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111224v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/index.html

Participating hosts (33 -> 32)
--

  Additional (1): fi-tgl-dsi 
  Missing(2): fi-hsw-4770 fi-rkl-11600 

Known issues


  Here are the changes found in Patchwork_111224v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][3] ([i915#7073]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}:   [DMESG-WARN][5] ([i915#6434]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][7] ([i915#6471]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][9] ([i915#4983]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][11] ([i915#6298]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111224v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6471]: https://gitlab.freedesktop.org/drm/intel/issues/6471
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7073]: https://gitlab.freedesktop.org/drm/intel/issues/7073
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561


Build changes
-

  * Linux: CI_DRM_12418 -> Patchwork_111224v1

  CI-20190529: 20190529
  CI_DRM_12418: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7071: 

[Intel-gfx] [PATCH] drm/i915/perf: Do not parse context image for HSW

[Umesh Nerlige Ramappa]

An earlier commit introduced a mechanism to parse the context image to
find the OA context control offset. This resulted in an NPD on haswell
when gem_context was passed into i915_perf_open_ioctl params. Haswell
does not support logical ring contexts, so ensure that the context image
is parsed only for platforms with logical ring contexts and also
validate lrc_reg_state.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7432
Fixes: a5c3a3cbf029 ("drm/i915/perf: Determine gen12 oa ctx offset at runtime")
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 00e09bb18b13..36364fb558d5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1383,6 +1383,9 @@ static u32 oa_context_image_offset(struct intel_context 
*ce, u32 reg)
u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
u32 *state = ce->lrc_reg_state;
 
+   if (drm_WARN_ON(>engine->i915->drm, state == NULL)
+   return U32_MAX;
+
for (offset = 0; offset < len; ) {
if (IS_MI_LRI_CMD(state[offset])) {
/*
@@ -1447,7 +1450,8 @@ static int oa_get_render_ctx_id(struct i915_perf_stream 
*stream)
if (IS_ERR(ce))
return PTR_ERR(ce);
 
-   if (engine_supports_mi_query(stream->engine)) {
+   if (engine_supports_mi_query(stream->engine) &&
+   HAS_LOGICAL_RING_CONTEXTS(stream->perf->i915)) {
/*
 * We are enabling perf query here. If we don't find the context
 * offset here, just return an error.
-- 
2.36.1

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: Use GuC submission API version number

[Ceraolo Spurio, Daniele]

On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.

Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other firmwares do not have that restriction. So
stop making assumptions about them generically fitting in a u16
individually, or in a u32 as a combined 8.8.8.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 +++
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +--
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 91 ---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  | 10 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h  |  3 +-
  5 files changed, 104 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 1bb3f98292866..bb4dfe707a7d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -158,6 +158,9 @@ struct intel_guc {
bool submission_selected;
/** @submission_initialized: tracks whether GuC submission has been 
initialised */
bool submission_initialized;
+   /** @submission_version: Submission API version of the currently loaded 
firmware */
+   struct intel_uc_fw_ver submission_version;
+
/**
 * @rc_supported: tracks whether we support GuC rc on the current 
platform
 */
@@ -268,6 +271,14 @@ struct intel_guc {
  #endif
  };
  
+/*

+ * GuC version number components are only 8-bit, so converting to a 32bit 8.8.8
+ * integer works.
+ */
+#define MAKE_GUC_VER(maj, min, pat)(((maj) << 16) | ((min) << 8) | (pat))
+#define MAKE_GUC_VER_STRUCT(ver)   MAKE_GUC_VER((ver).major, (ver).minor, 
(ver).patch)
+#define GUC_SUBMIT_VER(guc)
MAKE_GUC_VER_STRUCT((guc)->submission_version)
+
  static inline struct intel_guc *log_to_guc(struct intel_guc_log *log)
  {
return container_of(log, struct intel_guc, log);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0a42f1807f52c..53f7f599cde3a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1890,7 +1890,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
  
-	if (GET_UC_VER(guc) < MAKE_UC_VER(70, 0, 0)) {

+   if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 0, 0)) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2330,7 +2330,7 @@ static int register_context(struct intel_context *ce, 
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
  
-	if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))

+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0))
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2342,7 +2342,7 @@ static int register_context(struct intel_context *ce, 
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
  
-		if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))

+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0))
guc_context_policy_init_v70(ce, loop);
}
  
@@ -2956,7 +2956,7 @@ static void __guc_context_set_preemption_timeout(struct intel_guc *guc,

 u16 guc_id,
 u32 preemption_timeout)
  {
-   if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0)) {
struct context_policy policy;
  
  		__guc_context_policy_start_klv(, guc_id);

@@ -3283,7 +3283,7 @@ static int guc_context_alloc(struct intel_context *ce)
  static void __guc_context_set_prio(struct intel_guc *guc,
   struct intel_context *ce)
  {
-   if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0)) {
struct context_policy policy;
  
  		__guc_context_policy_start_klv(, ce->guc_id.id);

@@ -4366,7 +4366,7 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
intel_wakeref_t wakeref;
int ret = 0;
  
-	if (GET_UC_VER(guc) < MAKE_UC_VER(70, 3, 0))

+   if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 1, 0))
return 0;
  
  	__guc_scheduling_policy_start_klv();

@@ -4905,6 +4905,9 @@ void intel_guc_submission_print_info(struct intel_guc 
*guc,
if (!sched_engine)
return;
  
+	drm_printf(p, "GuC Submission API Version: %d.%d.%d\n",

+  

[Intel-gfx] [PATCH] drm/i915/uc: Fix table order verification to check all FW types

[John . C . Harrison]

From: John Harrison 

It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.

Note that the long term plan is to convert this code to be a mock
selftest. It is already only compiled in when selftests are enabled.
And the work involved in the conversion was estimated to be
non-trivial. So that conversion is currently low on the priority list.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 0c80ba51a4bdc..31613c7e0838b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -238,7 +238,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
[INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
[INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
};
-   static bool verified;
+   static bool verified[INTEL_UC_FW_NUM_TYPES];
const struct uc_fw_platform_requirement *fw_blobs;
enum intel_platform p = INTEL_INFO(i915)->platform;
u32 fw_count;
@@ -291,8 +291,8 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
}
 
/* make sure the list is ordered as expected */
-   if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified) {
-   verified = true;
+   if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified[uc_fw->type]) {
+   verified[uc_fw->type] = true;
 
for (i = 1; i < fw_count; i++) {
/* Next platform is good: */
@@ -343,7 +343,8 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
continue;
 
 bad:
-   drm_err(>drm, "Invalid FW blob order: %s r%u 
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
+   drm_err(>drm, "Invalid %s blob order: %s r%u 
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
+   intel_uc_fw_type_repr(uc_fw->type),
intel_platform_name(fw_blobs[i - 1].p), 
fw_blobs[i - 1].rev,
fw_blobs[i - 1].blob.legacy ? "L" : "v",
fw_blobs[i - 1].blob.major,
-- 
2.37.3

Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: More refactoring of UC version numbers

[Ceraolo Spurio, Daniele]

On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.

Signed-off-by: John Harrison 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/gt/uc/intel_uc.c|  6 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 76 +++-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 15 +++--
  3 files changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 1d28286e6f066..e6edad6f8f9dd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -437,9 +437,9 @@ static void print_fw_ver(struct intel_uc *uc, struct 
intel_uc_fw *fw)
  
  	drm_info(>drm, "%s firmware %s version %u.%u.%u\n",

 intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
-fw->file_selected.major_ver,
-fw->file_selected.minor_ver,
-fw->file_selected.patch_ver);
+fw->file_selected.ver.major,
+fw->file_selected.ver.minor,
+fw->file_selected.ver.patch);
  }
  
  static int __uc_init_hw(struct intel_uc *uc)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 774c3d84a4243..5e2ee1ac89514 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -278,8 +278,8 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
  
  		uc_fw->file_selected.path = blob->path;

uc_fw->file_wanted.path = blob->path;
-   uc_fw->file_wanted.major_ver = blob->major;
-   uc_fw->file_wanted.minor_ver = blob->minor;
+   uc_fw->file_wanted.ver.major = blob->major;
+   uc_fw->file_wanted.ver.minor = blob->minor;
uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
found = true;
break;
@@ -438,28 +438,28 @@ static void __force_fw_fetch_failures(struct intel_uc_fw 
*uc_fw, int e)
uc_fw->user_overridden = user;
} else if (i915_inject_probe_error(i915, e)) {
/* require next major version */
-   uc_fw->file_wanted.major_ver += 1;
-   uc_fw->file_wanted.minor_ver = 0;
+   uc_fw->file_wanted.ver.major += 1;
+   uc_fw->file_wanted.ver.minor = 0;
uc_fw->user_overridden = user;
} else if (i915_inject_probe_error(i915, e)) {
/* require next minor version */
-   uc_fw->file_wanted.minor_ver += 1;
+   uc_fw->file_wanted.ver.minor += 1;
uc_fw->user_overridden = user;
-   } else if (uc_fw->file_wanted.major_ver &&
+   } else if (uc_fw->file_wanted.ver.major &&
   i915_inject_probe_error(i915, e)) {
/* require prev major version */
-   uc_fw->file_wanted.major_ver -= 1;
-   uc_fw->file_wanted.minor_ver = 0;
+   uc_fw->file_wanted.ver.major -= 1;
+   uc_fw->file_wanted.ver.minor = 0;
uc_fw->user_overridden = user;
-   } else if (uc_fw->file_wanted.minor_ver &&
+   } else if (uc_fw->file_wanted.ver.minor &&
   i915_inject_probe_error(i915, e)) {
/* require prev minor version - hey, this should work! */
-   uc_fw->file_wanted.minor_ver -= 1;
+   uc_fw->file_wanted.ver.minor -= 1;
uc_fw->user_overridden = user;
} else if (user && i915_inject_probe_error(i915, e)) {
/* officially unsupported platform */
-   uc_fw->file_wanted.major_ver = 0;
-   uc_fw->file_wanted.minor_ver = 0;
+   uc_fw->file_wanted.ver.major = 0;
+   uc_fw->file_wanted.ver.minor = 0;
uc_fw->user_overridden = true;
}
  }
@@ -471,9 +471,9 @@ static int check_gsc_manifest(const struct firmware *fw,
u32 version_hi = dw[HUC_GSC_VERSION_HI_DW];
u32 version_lo = dw[HUC_GSC_VERSION_LO_DW];
  
-	uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK, version_hi);

-   uc_fw->file_selected.minor_ver = FIELD_GET(HUC_GSC_MINOR_VER_HI_MASK, 
version_hi);
-   uc_fw->file_selected.patch_ver = FIELD_GET(HUC_GSC_PATCH_VER_LO_MASK, 
version_lo);
+   uc_fw->file_selected.ver.major = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK, 
version_hi);
+   uc_fw->file_selected.ver.minor = FIELD_GET(HUC_GSC_MINOR_VER_HI_MASK, 
version_hi);
+   uc_fw->file_selected.ver.patch = FIELD_GET(HUC_GSC_PATCH_VER_LO_MASK, 
version_lo);
  
  	return 0;

  }
@@ -532,11 +532,11 @@ static int check_ccs_header(struct intel_gt *gt,
}
  
  	/* Get version numbers from the CSS header */

-   

Re: [Intel-gfx] [PATCH 1/3] drm/i915/uc: Rationalise delimiters in filename macros

[Ceraolo Spurio, Daniele]

On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise


delimiter misspelled twice. Apart from this, it's a simple cleanup, so:

Reviewed-by: Daniele Ceraolo Spurio 

Daniele


them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 0c80ba51a4bdc..774c3d84a4243 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -118,35 +118,35 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
   */
  #define __MAKE_UC_FW_PATH_BLANK(prefix_, name_) \
"i915/" \
-   __stringify(prefix_) name_ ".bin"
+   __stringify(prefix_) "_" name_ ".bin"
  
  #define __MAKE_UC_FW_PATH_MAJOR(prefix_, name_, major_) \

"i915/" \
-   __stringify(prefix_) name_ \
+   __stringify(prefix_) "_" name_ "_" \
__stringify(major_) ".bin"
  
  #define __MAKE_UC_FW_PATH_MMP(prefix_, name_, major_, minor_, patch_) \

"i915/" \
-   __stringify(prefix_) name_ \
+   __stringify(prefix_) "_" name_  "_" \
__stringify(major_) "." \
__stringify(minor_) "." \
__stringify(patch_) ".bin"
  
  /* Minor for internal driver use, not part of file name */

  #define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_) \
-   __MAKE_UC_FW_PATH_MAJOR(prefix_, "_guc_", major_)
+   __MAKE_UC_FW_PATH_MAJOR(prefix_, "guc", major_)
  
  #define MAKE_GUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \

-   __MAKE_UC_FW_PATH_MMP(prefix_, "_guc_", major_, minor_, patch_)
+   __MAKE_UC_FW_PATH_MMP(prefix_, "guc", major_, minor_, patch_)
  
  #define MAKE_HUC_FW_PATH_BLANK(prefix_) \

-   __MAKE_UC_FW_PATH_BLANK(prefix_, "_huc")
+   __MAKE_UC_FW_PATH_BLANK(prefix_, "huc")
  
  #define MAKE_HUC_FW_PATH_GSC(prefix_) \

-   __MAKE_UC_FW_PATH_BLANK(prefix_, "_huc_gsc")
+   __MAKE_UC_FW_PATH_BLANK(prefix_, "huc_gsc")
  
  #define MAKE_HUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \

-   __MAKE_UC_FW_PATH_MMP(prefix_, "_huc_", major_, minor_, patch_)
+   __MAKE_UC_FW_PATH_MMP(prefix_, "huc", major_, minor_, patch_)
  
  /*

   * All blobs need to be declared via MODULE_FIRMWARE().

Re: [Intel-gfx] [PATCH] drm/i915/huc: fix leak of debug object in huc load fence on driver unload

[John Harrison]

On 11/10/2022 16:56, Daniele Ceraolo Spurio wrote:

The fence is always initialized in huc_init_early, but the cleanup in
huc_fini is only being run if HuC is enabled. This causes a leaking of
the debug object when HuC is disabled/not supported, which can in turn
trigger a warning if we try to register a new debug offset at the same
address on driver reload.

To fix the issue, make sure to always run the cleanup code.

Reported-by: Tvrtko Ursulin 
Reported-by: Brian Norris 
Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence")
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Brian Norris 
Cc: Alan Previn 
Cc: John Harrison 

Reviewed-by: John Harrison 


---

Note: I didn't manage to repro the reported warning, but I did confirm
that we weren't correctly calling i915_sw_fence_fini and that this patch
fixes that.

  drivers/gpu/drm/i915/gt/uc/intel_huc.c | 12 +++-
  drivers/gpu/drm/i915/gt/uc/intel_uc.c  |  1 +
  2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index fbc8bae14f76..83735a1528fe 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -300,13 +300,15 @@ int intel_huc_init(struct intel_huc *huc)
  
  void intel_huc_fini(struct intel_huc *huc)

  {
-   if (!intel_uc_fw_is_loadable(>fw))
-   return;
-
+   /*
+* the fence is initialized in init_early, so we need to clean it up
+* even if HuC loading is off.
+*/
delayed_huc_load_complete(huc);
-
i915_sw_fence_fini(>delayed_load.fence);
-   intel_uc_fw_fini(>fw);
+
+   if (intel_uc_fw_is_loadable(>fw))
+   intel_uc_fw_fini(>fw);
  }
  
  void intel_huc_suspend(struct intel_huc *huc)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index dbd048b77e19..41f08b55790e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -718,6 +718,7 @@ int intel_uc_runtime_resume(struct intel_uc *uc)
  
  static const struct intel_uc_ops uc_ops_off = {

.init_hw = __uc_check_hw,
+   .fini = __uc_fini, /* to clean-up the init_early initialization */
  };
  
  static const struct intel_uc_ops uc_ops_on = {

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gsc: Disable GSC engine and power well if FW is not selected

[Ceraolo Spurio, Daniele]

On 11/22/2022 12:52 PM, Rodrigo Vivi wrote:

On Mon, Nov 21, 2022 at 03:16:16PM -0800, Daniele Ceraolo Spurio wrote:

From: Jonathan Cavitt 

The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the engine nor the microcontoller, then we can also disable the
power well.

IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements
between CS setup and forcewake idleness. See in-code comment for detail.

Signed-off-by: Jonathan Cavitt 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: John C Harrison 
Cc: Rodrigo Vivi 
Cc: Vinay Belgaumkar 
---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 18 ++
  drivers/gpu/drm/i915/intel_uncore.c   |  3 +++
  2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d670..99c4b866addd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -894,6 +894,24 @@ static intel_engine_mask_t init_engine_mask(struct 
intel_gt *gt)
engine_mask_apply_compute_fuses(gt);
engine_mask_apply_copy_fuses(gt);
  
+	/*

+* The only use of the GSC CS is to load and communicate with the GSC
+* FW, so we have no use for it if we don't have the FW.
+*
+* IMPORTANT: in cases where we don't have the GSC FW, we have a
+* catch-22 situation that breaks media C6 due to 2 requirements:
+* 1) once turned on, the GSC power well will not go to sleep unless the
+*GSC FW is loaded.
+* 2) to enable idling (which is required for media C6) we need to
+*initialize the IDLE_MSG register for the GSC CS and do at least 1
+*submission, which will wake up the GSC power well.
+*/
+   if (__HAS_ENGINE(info->engine_mask, GSC0) && 
!intel_uc_wants_gsc_uc(>uc)) {
+   drm_notice(>i915->drm,
+  "No GSC FW selected, disabling GSC CS and media 
C6\n");
+   info->engine_mask &= ~BIT(GSC0);
+   }
+
return info->engine_mask;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c

index c1befa33ff59..e63d957b59eb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2701,6 +2701,9 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
if (fw_domains & BIT(domain_id))
fw_domain_fini(uncore, domain_id);
}
+
+   if ((fw_domains & BIT(FW_DOMAIN_ID_GSC)) && !HAS_ENGINE(gt, GSC0))
+   fw_domain_fini(uncore, FW_DOMAIN_ID_GSC);

On a quick glace I was asking "why do you need this since it doesn't have the 
gsc0?
Then I remember that fw_domain got initialized and it will be skipped, right?
Then I though about at least have a comment here, but finally I got myself 
wondering
why we don't do this already in the if above, while we are cleaning the engine 
mask?


I've followed the existing code flows that we have in place for fused 
off VCS/VECS. Basically the existing code goes like this:


1) All FW domains for the platform are initialized
2) We read the fuses and adjust the engine mask accordingly
3) We go back and prune the FW domains that are not applicable anymore 
due to the updated mask.


The idea is to have a single gt-level function doing all the mask 
adjusting and an uncore-level one doing all the domain pruning. I'm not 
against changing this approach, but in that case we should update the 
behavior for VCS/VECS as well (which might be complicated, because 
VCS/VECS engines share FW domains, so the pruning logic is ugly).


Daniele




  }
  
  static void driver_flr(struct intel_uncore *uncore)

--
2.37.3

[Intel-gfx] [PATCH] drm/i915: Allow error capture without a request

[John . C . Harrison]

From: John Harrison 

There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.

In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.

So update the error capture code to always record engine information
if an engine is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 55 +++
 1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64e..2ed1c84c9fab4 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct 
intel_engine_coredump *ee)
 }
 
 static bool record_context(struct i915_gem_context_coredump *e,
-  const struct i915_request *rq)
+  struct intel_context *ce)
 {
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
 
rcu_read_lock();
-   ctx = rcu_dereference(rq->context->gem_context);
+   ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct 
i915_gem_context_coredump *e,
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
 
-   e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
-   e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+   e->total_runtime = intel_context_get_total_runtime_ns(ce);
+   e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
 
simulated = i915_gem_context_no_error_capture(ctx);
 
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs 
*engine, gfp_t gfp, u32 dump_
return ee;
 }
 
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+   struct intel_context *ce,
+   gfp_t gfp)
+{
+   struct intel_engine_capture_vma *vma = NULL;
+
+   ee->simulated |= record_context(>context, ce);
+   if (ee->simulated)
+   return NULL;
+
+   /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+   vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+   vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+   return vma;
+}
+
 struct intel_engine_capture_vma *
 intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
  struct i915_request *rq,
  gfp_t gfp)
 {
-   struct intel_engine_capture_vma *vma = NULL;
+   struct intel_engine_capture_vma *vma;
 
-   ee->simulated |= record_context(>context, rq);
-   if (ee->simulated)
+   vma = engine_coredump_add_context(ee, rq->context, gfp);
+   if (!vma)
return NULL;
 
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct 
intel_engine_coredump *ee,
 */
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
-   vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
-   vma = capture_vma(vma, rq->context->state, "HW context", gfp);
 
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1608,8 +1628,11 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
-   if (!rq || !i915_request_started(rq))
-   goto no_request_capture;
+   if (rq && !i915_request_started(rq)) {
+   drm_info(>gt->i915->drm, "Got hung context on 
%s with no active request!\n",
+engine->name);
+   rq = NULL;
+   }
} else {
/*
 * Getting here with GuC enabled means it is a forced error 
capture
@@ -1625,12 +1648,14 @@ 

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded

[Ceraolo Spurio, Daniele]

On 11/22/2022 12:46 PM, Rodrigo Vivi wrote:

On Mon, Nov 21, 2022 at 03:16:15PM -0800, Daniele Ceraolo Spurio wrote:

If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-FLR is not the same as PCI config space FLR in that
it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs.
However, the driver-FLR does cause a memory wipe of graphics memory
on all discrete GPU platforms or a wipe limited to stolen memory
on the integrated GPU platforms.

Nothing major or blocking, but a few thoughts:

1. Should we document this in the code, at least in a comment in the
flr function?


Sure, I'll add it in


2. Should we call this driver_initiated_flr, aiming to reduce even more
the ambiguity of it?


ok




We perform the FLR as the last action before releasing the MMIO bar, so
that we don't have to care about the consequences of the reset on the
unload flow.

3. should we try to implement this already in the gt_reset case as the
last resrouce before wedging the gt? So we can already test this flow
in the current platforms?


This would be nice to have, but very complicated to implement. The fact 
that FLR kills everything on the system, including resetting display and 
wiping LMEM, means that we would need a new recovery path to 
re-initialize all components. There are also potential questions on how 
to handle LMEM: do we try to migrate it to SMEM before triggering the 
FLR (potentially via CPU memcpy if the GT is dead), or do we just let it 
get wiped?


The reason why I wanted the FLR to be the very last thing before 
releasing MMIO access was exactly to not have to care about the recovery 
path ;)


Daniele




Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  9 +
  drivers/gpu/drm/i915/i915_reg.h   |  3 ++
  drivers/gpu/drm/i915/intel_uncore.c   | 45 +++
  drivers/gpu/drm/i915/intel_uncore.h   | 13 +++
  4 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 510fb47193ec..5dad3c19c445 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -173,6 +173,15 @@ int intel_gsc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
  
+	/*

+* Once the GSC FW is loaded, the only way to kill it on driver unload
+* is to do a driver FLR. Given this is a very disruptive action, we
+* want to do it as the last action before releasing the access to the
+* MMIO bar, which means we need to do it as part of the primary uncore
+* cleanup.
+*/
+   intel_uncore_set_flr_on_fini(>i915->uncore);
+
/* FW is not fully operational until we enable SW proxy */
intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index 8e1892d14774..60e55245200b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -118,6 +118,9 @@
  
  #define GU_CNTL_MMIO(0x101010)

  #define   LMEM_INIT   REG_BIT(7)
+#define   DRIVERFLRREG_BIT(31)
+#define GU_DEBUG   _MMIO(0x101018)
+#define   DRIVERFLR_STATUS REG_BIT(31)
  
  #define GEN6_STOLEN_RESERVED		_MMIO(0x1082C0)

  #define GEN6_STOLEN_RESERVED_ADDR_MASK(0xFFF << 20)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8006a6c61466..c1befa33ff59 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2703,6 +2703,48 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
}
  }
  
+static void driver_flr(struct intel_uncore *uncore)

+{
+   struct drm_i915_private *i915 = uncore->i915;
+   const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
*/
+   int ret;
+
+   drm_dbg(>drm, "Triggering Driver-FLR\n");
+
+   /*
+* Make sure any pending FLR requests have cleared by waiting for the
+* FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
+* to make sure it's not still set from a prior attempt (it's a write to
+* clear bit).
+* Note that we should never be in a situation where a previous attempt
+* is still pending (unless the HW is totally dead), but better to be
+* safe in case something unexpected happens
+*/
+   ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0, 
flr_timeout_ms);
+   if (ret) {
+   drm_err(>drm,
+   "Failed to wait for Driver-FLR bit to clear! %d\n",
+   ret);
+   return;
+   }
+   

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: dedicated MCR locking and hardware semaphore

[Patchwork]

== Series Details ==

Series: i915: dedicated MCR locking and hardware semaphore
URL   : https://patchwork.freedesktop.org/series/111220/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111220v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_111220v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_111220v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/index.html

Participating hosts (33 -> 30)
--

  Additional (2): bat-adls-5 fi-tgl-dsi 
  Missing(5): bat-dg1-6 bat-dg2-8 bat-adlp-6 bat-adln-1 bat-rplp-1 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111220v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
- fi-bsw-nick:[PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-kefka:   [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@requests:
- fi-rkl-11600:   [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-rkl-11600/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-rkl-11600/igt@i915_selftest@l...@requests.html
- fi-skl-6700k2:  [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-skl-6700k2/igt@i915_selftest@l...@requests.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-skl-6700k2/igt@i915_selftest@l...@requests.html
- fi-cfl-8109u:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-cfl-8109u/igt@i915_selftest@l...@requests.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-cfl-8109u/igt@i915_selftest@l...@requests.html
- fi-icl-u2:  [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-icl-u2/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-icl-u2/igt@i915_selftest@l...@requests.html
- fi-apl-guc: NOTRUN -> [DMESG-WARN][15]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-apl-guc/igt@i915_selftest@l...@requests.html
- fi-glk-j4005:   [PASS][16] -> [DMESG-WARN][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-glk-j4005/igt@i915_selftest@l...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-glk-j4005/igt@i915_selftest@l...@requests.html
- fi-skl-guc: [PASS][18] -> [DMESG-WARN][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-skl-guc/igt@i915_selftest@l...@requests.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-skl-guc/igt@i915_selftest@l...@requests.html
- fi-kbl-7567u:   [PASS][20] -> [DMESG-WARN][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-kbl-7567u/igt@i915_selftest@l...@requests.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-kbl-7567u/igt@i915_selftest@l...@requests.html
- fi-cfl-8700k:   [PASS][22] -> [DMESG-WARN][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-cfl-8700k/igt@i915_selftest@l...@requests.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/fi-cfl-8700k/igt@i915_selftest@l...@requests.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@requests:
- {bat-adls-5}:   NOTRUN -> [DMESG-WARN][24]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v1/bat-adls-5/igt@i915_selftest@l...@requests.html
- {bat-jsl-1}:[PASS][25] -> [DMESG-WARN][26]
   [25]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: dedicated MCR locking and hardware semaphore

[Patchwork]

== Series Details ==

Series: i915: dedicated MCR locking and hardware semaphore
URL   : https://patchwork.freedesktop.org/series/111220/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for More GuC firmware version improvements

[Patchwork]

== Series Details ==

Series: More GuC firmware version improvements
URL   : https://patchwork.freedesktop.org/series/111218/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111218v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v1/index.html

Participating hosts (33 -> 34)
--

  Additional (1): fi-tgl-dsi 

Known issues


  Here are the changes found in Patchwork_111218v1 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][1] ([i915#6471]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v1/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][3] ([i915#4983]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][5] ([i915#6298]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6471]: https://gitlab.freedesktop.org/drm/intel/issues/6471
  [i915#6856]: https://gitlab.freedesktop.org/drm/intel/issues/6856
  [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
  [i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561


Build changes
-

  * Linux: CI_DRM_12418 -> Patchwork_111218v1

  CI-20190529: 20190529
  CI_DRM_12418: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7071: 0801475083ccb938b1d3b358502ff97fdb435585 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111218v1: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

064ee63e7773 drm/i915/guc: Use GuC submission API version number
fba8cf42a82b drm/i915/uc: More refactoring of UC version numbers
098a9a1ef232 drm/i915/uc: Rationalise delimiters in filename macros

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v1/index.html

Re: [Intel-gfx] [MAINTAINER TOOLS] docs: updated rules for topic/core-for-CI commit management

[Lucas De Marchi]

On Tue, Nov 22, 2022 at 03:17:14PM +0200, Jani Nikula wrote:

Introduce stricter rules for topic/core-for-CI management. Way too many
commits have been added over the years, with insufficient rationale
recorded in the commit message, and insufficient follow-up with removing
the commits from the topic branch.

New rules:


Why not make a list like this the actual text? It's easier to follow a
bullet/numbered list than the free form text.



1. Require maintainer ack for rebase. Have better gating on when rebases
  happen and on which baselines.


What maintainer? drm-intel-gt-next/drm-intel-next/drm-misc/drm? Any?

I don't want fingers pointed, but just to know the context: was there
any event recently that triggered this? Because the last updates I've
seen on topic/core-for-CI were not from maintainers and
looking at the branch I don't see any issue with the recent commits.
The issue actually seems to be the very old ones.  I'm not sure such
a measure will actually fix the problem.

I myself pushed recently to topic/core-for-CI so I want to know if **I**
caused any issue.



2. Require maintainer/committer ack for adding/removing commits. No
  single individual should decide.


s@maintainers/committer @@? Or just let it have the same requirement as
the drm-intel-* branches. It seems odd to raise the bar for
topic/core-for-CI above the requirement for drm-intel-* branches (even
though that latter is a r-b). From committer-drm-intel.rst:

* Reviewed-by/Acked-by/Tested-by must include the name and email of a 
real
  person for transparency. Anyone can give these, and therefore you 
have to
  value them according to the merits of the person. Quality matters, not
  quantity. Be suspicious of rubber stamps.

* Reviewed-by/Acked-by/Tested-by can be asked for and given informally 
(on the
  list, IRC, in person, in a meeting) but must be added to the commit.

* Reviewed-by. All patches must be reviewed, no exceptions. Please see
  "Reviewer's statement of oversight" in 
`Documentation/process/submitting-patches
  
`_
  and `review training
  `_.



3. Require gitlab issues for new commits added. Improve tracking for
  removing the commits.

Also use the stronger "must" for commit message requiring the
justification for the commit being in topic/core-for-CI.

Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: dim-to...@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
drm-tip.rst | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drm-tip.rst b/drm-tip.rst
index deae95cdd2fe..24036e2ef576 100644
--- a/drm-tip.rst
+++ b/drm-tip.rst
@@ -203,11 +203,13 @@ justified exception. The primary goal is to fix issues 
originating from Linus'
tree. Issues that would need drm-next or other DRM subsystem tree as baseline
should be fixed in the offending DRM subsystem tree.

-Only rebase the branch if you really know what you're doing. When in doubt, ask
-the maintainers. You'll need to be able to handle any conflicts in non-drm code
-while rebasing.
+Only rebase the branch if you really know what you're doing. You'll need to be
+able to handle any conflicts in non-drm code while rebasing.

-Simply drop fixes that are already available in the new baseline.
+Always ask for maintainer ack before rebasing. IRC ack is sufficient.
+
+Simply drop fixes that are already available in the new baseline. Close the
+associated gitlab issue when removing commits.

Force pushing a rebased topic/core-for-CI requires passing the ``--force``
parameter to git::


there is a main issue here that is not being fixed: testing the merged
branch.  I think it would be much better to have the instruction here
to rebuild drm-tip without pushing... This will use the local topic branch:

dim -d rebuild-tip topic/core-for-CI

It's the only way I ever update it because I don't want to push a branch
and have a small window to potentially solve the merge conflicts (while
leaving others wondering why the tip is broken).


@@ -225,11 +227,22 @@ judgement call.
Only add or remove commits if you really know what you're doing. When in doubt,
ask the maintainers.

-Apply new commits on top with regular push. The commit message needs to explain
-why the patch has been applied to topic/core-for-CI. If it's a cherry-pick from
+Always ask for maintainer/committer ack before adding/removing commits. IRC ack
+is sufficient. Record the ``Acked-by:`` in commits being added.
+
+Apply new commits on top with regular push. The commit message must explain why
+the patch has been applied to topic/core-for-CI. If it's a cherry-pick from
another subsystem, please reference the commit with 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for More GuC firmware version improvements

[Patchwork]

== Series Details ==

Series: More GuC firmware version improvements
URL   : https://patchwork.freedesktop.org/series/111218/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More GuC firmware version improvements

[Patchwork]

== Series Details ==

Series: More GuC firmware version improvements
URL   : https://patchwork.freedesktop.org/series/111218/
State : warning

== Summary ==

Error: dim checkpatch failed
f3a008949a16 drm/i915/uc: Rationalise delimiters in filename macros
460dbd43f21f drm/i915/uc: More refactoring of UC version numbers
-:220: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ver' - possible 
side-effects?
#220: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:118:
+#define MAKE_UC_VER_STRUCT(ver)MAKE_UC_VER((ver).major, 
(ver).minor, (ver).patch)

total: 0 errors, 0 warnings, 1 checks, 190 lines checked
60bcf6584e54 drm/i915/guc: Use GuC submission API version number
-:40: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ver' - possible side-effects?
#40: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc.h:279:
+#define MAKE_GUC_VER_STRUCT(ver)   MAKE_GUC_VER((ver).major, (ver).minor, 
(ver).patch)

total: 0 errors, 0 warnings, 1 checks, 221 lines checked

[Intel-gfx] ✓ Fi.CI.BAT: success for add guard padding around i915_vma (rev2)

[Patchwork]

== Series Details ==

Series: add guard padding around i915_vma (rev2)
URL   : https://patchwork.freedesktop.org/series/110720/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_110720v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/index.html

Participating hosts (33 -> 33)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-hsw-4770 

Known issues


  Here are the changes found in Patchwork_110720v2 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +7 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][5] ([i915#7099])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][6] ([i915#1886])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][9] ([i915#7073]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][11] ([i915#6471]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][13] ([i915#4983]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][15] ([i915#6298]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978
URL   : https://patchwork.freedesktop.org/series/111213/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111213v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_111213v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_111213v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/index.html

Participating hosts (33 -> 33)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-rkl-11600 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111213v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@client:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-kbl-soraka/igt@i915_selftest@l...@client.html

  
Known issues


  Here are the changes found in Patchwork_111213v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +7 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][6] ([i915#1886])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8] ([i915#4785])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: [PASS][9] -> [INCOMPLETE][10] ([i915#7308] / 
[i915#7348])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlp-4/igt@i915_selftest@l...@migrate.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#4312] / 
[i915#5594])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-hsw-4770/igt@run...@aborted.html
- bat-adlp-4: NOTRUN -> [FAIL][14] ([i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/bat-adlp-4/igt@run...@aborted.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][15] ([i915#7073]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][17] ([i915#4983]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111213v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][19] ([i915#6298]) -> [PASS][20]
   [19]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: use sysfs_streq() instead of strncmp()

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: use sysfs_streq() instead of strncmp()
URL   : https://patchwork.freedesktop.org/series/111212/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111212v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/index.html

Participating hosts (33 -> 34)
--

  Additional (2): bat-atsm-1 fi-tgl-dsi 
  Missing(1): fi-rkl-11600 

Known issues


  Here are the changes found in Patchwork_111212v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][3] ([i915#7073]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}:   [DMESG-WARN][5] ([i915#6434]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][7] ([i915#6471]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][9] ([i915#4983]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111212v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6077]: https://gitlab.freedesktop.org/drm/intel/issues/6077
  [i915#6078]: https://gitlab.freedesktop.org/drm/intel/issues/6078
  [i915#6093]: https://gitlab.freedesktop.org/drm/intel/issues/6093
  [i915#6094]: https://gitlab.freedesktop.org/drm/intel/issues/6094
  [i915#6166]: https://gitlab.freedesktop.org/drm/intel/issues/6166
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6471]: https://gitlab.freedesktop.org/drm/intel/issues/6471
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6856]: https://gitlab.freedesktop.org/drm/intel/issues/6856
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7073]: https://gitlab.freedesktop.org/drm/intel/issues/7073
  [i915#7125]: 

Re: [Intel-gfx] [CI 1/2] drm/i915/uc: Support for version reduced and multiple firmware files

[John Harrison]

On 11/22/2022 06:12, Jani Nikula wrote:

On Tue, 06 Sep 2022, Daniele Ceraolo Spurio  
wrote:

From: John Harrison 

There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
   i915 must support all existing firmware releases forever
   new minor firmware releases should replace prior versions
   only backwards compatibility breaking releases should be a new file

This patch cleans up the single fallback file support that was added
as a quick fix emergency effort. That is now removed in preference to
supporting arbitrary numbers of firmware files per platform.

The patch also adds support for having GuC firmware files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).

For GuC, the driver will report via dmesg if the found file is older than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio 

I have some wip tools that I occasionally run to spot issues in the
driver. One of the checks is for global data, i.e. data specific to
module, not the device [1].

It flags things like:


+   static bool verified;

added in this commit.

It's kind of benign, but also makes you wonder why the check is only
ever run on the first firmware (type?) of the first device probed. IIUC.
It is validating the firmware table in the driver. So it only needs to 
be done once per driver load, not per device. However, it should be done 
for each firmware type. Looks like that got missed.


The long term plan is to turn this into a sefltest (it is already only 
compiled in if self tests are enabled). I recall there was some issue 
why it didn't fit in the selftest framework before, although I don't 
recall the details.


Will take a look at fixing it...

Thanks,
John.





Usually I just fix the stuff, but I don't get this one.


BR,
Jani.


[1] 'make; i915-check data' https://gitlab.freedesktop.org/jani/i915-check


---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  10 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc.c |   4 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 442 --
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  33 +-
  drivers/gpu/drm/i915/i915_gpu_error.c |  16 +-
  5 files changed, 319 insertions(+), 186 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d56b615bf78..04393932623c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
  
-	if (guc->fw.major_ver_found < 70) {

+   if (guc->fw.file_selected.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce, 
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
  
-	if (guc->fw.major_ver_found >= 70)

+   if (guc->fw.file_selected.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce, 
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
  
-		if (guc->fw.major_ver_found >= 70)

+   if (guc->fw.file_selected.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
  
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct intel_guc *guc,

 u16 guc_id,
 u32 preemption_timeout)
  {
-   if (guc->fw.major_ver_found >= 70) {
+   if (guc->fw.file_selected.major_ver >= 70) {
struct context_policy policy;
  
  		__guc_context_policy_start_klv(, guc_id);

@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
  static void __guc_context_set_prio(struct intel_guc *guc,
   struct intel_context *ce)
  {
-   if (guc->fw.major_ver_found >= 70) {
+   if (guc->fw.file_selected.major_ver >= 70) {
struct context_policy policy;
  
  		__guc_context_policy_start_klv(, ce->guc_id.id);

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985ef..d965ac4832d6 100644
--- 

Re: [Intel-gfx] [RFC 11/13] cgroup/drm: Introduce weight based drm cgroup control

[Tejun Heo]

On Wed, Nov 09, 2022 at 04:11:39PM +, Tvrtko Ursulin wrote:
> +DRM scheduling soft limits
> +~~
> +
> +Because of the heterogenous hardware and driver DRM capabilities, soft limits
> +are implemented as a loose co-operative (bi-directional) interface between 
> the
> +controller and DRM core.
> +
> +The controller configures the GPU time allowed per group and periodically 
> scans
> +the belonging tasks to detect the over budget condition, at which point it
> +invokes a callback notifying the DRM core of the condition.
> +
> +DRM core provides an API to query per process GPU utilization and 2nd API to
> +receive notification from the cgroup controller when the group enters or 
> exits
> +the over budget condition.
> +
> +Individual DRM drivers which implement the interface are expected to act on 
> this
> +in the best-effort manner only. There are no guarantees that the soft limits
> +will be respected.

Soft limits is a bit of misnomer and can be confused with best-effort limits
such as memory.high. Prolly best to not use the term.

> +static bool
> +__start_scanning(struct drm_cgroup_state *root, unsigned int period_us)
> +{
> + struct cgroup_subsys_state *node;
> + bool ok = false;
> +
> + rcu_read_lock();
> +
> + css_for_each_descendant_post(node, >css) {
> + struct drm_cgroup_state *drmcs = css_to_drmcs(node);
> +
> + if (!css_tryget_online(node))
> + goto out;
> +
> + drmcs->active_us = 0;
> + drmcs->sum_children_weights = 0;
> +
> + if (node == >css)
> + drmcs->per_s_budget_ns =
> + DIV_ROUND_UP_ULL(NSEC_PER_SEC * period_us,
> +  USEC_PER_SEC);
> + else
> + drmcs->per_s_budget_ns = 0;
> +
> + css_put(node);
> + }
> +
> + css_for_each_descendant_post(node, >css) {
> + struct drm_cgroup_state *drmcs = css_to_drmcs(node);
> + struct drm_cgroup_state *parent;
> + u64 active;
> +
> + if (!css_tryget_online(node))
> + goto out;
> + if (!node->parent) {
> + css_put(node);
> + continue;
> + }
> + if (!css_tryget_online(node->parent)) {
> + css_put(node);
> + goto out;
> + }
> + parent = css_to_drmcs(node->parent);
> +
> + active = drmcs_get_active_time_us(drmcs);
> + if (active > drmcs->prev_active_us)
> + drmcs->active_us += active - drmcs->prev_active_us;
> + drmcs->prev_active_us = active;
> +
> + parent->active_us += drmcs->active_us;
> + parent->sum_children_weights += drmcs->weight;
> +
> + css_put(node);
> + css_put(>css);
> + }
> +
> + ok = true;
> +
> +out:
> + rcu_read_unlock();
> +
> + return ok;
> +}

A more conventional and scalable way to go about this would be using an
rbtree keyed by virtual time. Both CFS and blk-iocost are examples of this,
but I think for drm, it can be a lot simpler.

Thanks.

-- 
tejun

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/dg2: Introduce Wa_18018764978

[Matt Roper]

On Tue, Nov 22, 2022 at 10:33:05AM -0800, Matt Atwood wrote:
> Wa_18018764978 applies to specific steppings of DG2 (G10 C0+,
> G11 and G12 A0+). Clean up style in function at the same time.
> 
> Bspec: 66622
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 80a979e6f6bec..74379d3c5a4de 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -457,6 +457,9 @@
>  #define GEN8_L3CNTLREG   _MMIO(0x7034)
>  #define   GEN8_ERRDETBCTRL   (1 << 9)
>  
> +#define PSS_MODE2_MMIO(0x703c)
> +#define   SCOREBOARD_STALL_FLUSH_CONTROL REG_BIT(5)
> +
>  #define GEN7_SC_INSTDONE _MMIO(0x7100)
>  #define GEN12_SC_INSTDONE_EXTRA  _MMIO(0x7104)
>  #define GEN12_SC_INSTDONE_EXTRA2 _MMIO(0x7108)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 2afb4f80a954d..ce2be9470c36c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -771,8 +771,13 @@ static void dg2_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
>  
>   /* Wa_14014947963:dg2 */
>   if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_B0, STEP_FOREVER) ||
> - IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915))
> - wa_masked_field_set(wal, VF_PREEMPTION, 
> PREEMPTION_VERTEX_COUNT, 0x4000);
> +  IS_DG2_G11(engine->i915) || 
> IS_DG2_G12(engine->i915))
> +  wa_masked_field_set(wal, VF_PREEMPTION, 
> PREEMPTION_VERTEX_COUNT, 0x4000);

This new formatting is less correct than the original.  It should be:

if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_B0, STEP_FOREVER) ||
IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915))
wa_masked_field_set(wal, VF_PREEMPTION, 
PREEMPTION_VERTEX_COUNT, 0x4000);

And the new workaround below has the same mistake.


Matt

> +
> + /* Wa_18018764978:dg2 */
> + if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_C0, STEP_FOREVER) ||
> +  IS_DG2_G11(engine->i915) || 
> IS_DG2_G12(engine->i915))
> +  wa_masked_en(wal, PSS_MODE2, 
> SCOREBOARD_STALL_FLUSH_CONTROL);
>  
>   /* Wa_15010599737:dg2 */
>   wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
> -- 
> 2.38.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for add guard padding around i915_vma (rev2)

[Patchwork]

== Series Details ==

Series: add guard padding around i915_vma (rev2)
URL   : https://patchwork.freedesktop.org/series/110720/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Update DG2 DMC version to v2.08

[Rodrigo Vivi]

On Tue, Nov 22, 2022 at 12:59:36PM -0800, Matt Roper wrote:
> On Mon, Nov 21, 2022 at 06:18:15PM -0300, Gustavo Sousa wrote:
> > Release notes:
> > 
> > 1. Fixes for Register noclaims and few restore.
> > 
> > Signed-off-by: Gustavo Sousa 
> 
> Now that we've removed force_probe from DG2, in general we're past the
> point where we can just directly update firmware versions like this; if
> someone has a working system with the current kernel + DMC 2.07 and then
> they update to a new kernel containing this patch (but without
> installing DMC 2.08), they'd see a regression.
> 
> In this case, maybe there's still time to sneak this specific update
> into -fixes so that it lands in the same kernel release that removes the
> force_probe protection on DG2?  But in general we need to start
> providing backwards-compatible support for all firmware updates going
> forward.  The GuC/HuC guys just went through an overhaul of their
> firmware handling to deal with this; we probably need something similar
> on the DMC side now too, although I suspect DMC should be simpler to
> deal with since most (all?) DMC firmwares are just drop-in replacements
> and there's no constantly changing firmware<->driver interface like
> there is with the GuC.
> 
> See Documentation/driver-api/firmware/firmware-usage-guidelines.rst for
> the official rules about firmware usage.

Matt is right here. But this update is an important fix and I will propagate
through the -fixes flow, so we don't need for now to support the 2.07 as
fallback. The 6.2 will be released only with the 2.08.

But please make sure you add a "Fixes:" tag to this patch. Then please
let us know when the fw file got accepted in the linux-firmware.git
so we can merge and propagate.

Moving forward we will need to support the fallback version like GuC,
or even better, remove the versioning from the filename entirely like
HuC.

> 
> 
> Matt
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index 081a4d0083b1..697196368fbb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -52,8 +52,8 @@
> >  
> >  #define DISPLAY_VER12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
> >  
> > -#define DG2_DMC_PATH   DMC_PATH(dg2, 2, 07)
> > -#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 07)
> > +#define DG2_DMC_PATH   DMC_PATH(dg2, 2, 08)
> > +#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 08)
> >  MODULE_FIRMWARE(DG2_DMC_PATH);
> >  
> >  #define ADLP_DMC_PATH  DMC_PATH(adlp, 2, 16)
> > -- 
> > 2.38.1
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for add guard padding around i915_vma (rev2)

[Patchwork]

== Series Details ==

Series: add guard padding around i915_vma (rev2)
URL   : https://patchwork.freedesktop.org/series/110720/
State : warning

== Summary ==

Error: dim checkpatch failed
c3b7961dfa97 drm/i915: Wrap all access to i915_vma.node.start|size
-:263: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#263: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c:475:
+   GEM_BUG_ON(i915_vma_offset(vma) != addr);

-:355: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#355: FILE: drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c:65:
+   GEM_BUG_ON(offset + (count - 1) * PAGE_SIZE > i915_vma_size(vma));

-:392: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#392: FILE: drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:223:
+   GEM_BUG_ON(vma->fence_size > i915_vma_size(vma));

-:786: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#786: FILE: drivers/gpu/drm/i915/i915_vma.c:450:
+   GEM_BUG_ON(vma->size > i915_vma_size(vma));

-:869: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#869: FILE: drivers/gpu/drm/i915/i915_vma.h:146:
+   GEM_BUG_ON(!drm_mm_node_allocated(>node));

-:891: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#891: FILE: drivers/gpu/drm/i915/i915_vma.h:168:
+   GEM_BUG_ON(!drm_mm_node_allocated(>node));

-:902: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#902: FILE: drivers/gpu/drm/i915/i915_vma.h:176:
+   GEM_BUG_ON(upper_32_bits(i915_vma_offset(vma)));

-:903: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#903: FILE: drivers/gpu/drm/i915/i915_vma.h:177:
+   GEM_BUG_ON(upper_32_bits(i915_vma_offset(vma) +

total: 0 errors, 8 warnings, 0 checks, 805 lines checked
e9c3d6cce4d8 drm/i915: Introduce guard pages to i915_vma
-:128: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#128: FILE: drivers/gpu/drm/i915/i915_vma.c:783:
+   GEM_BUG_ON(2 * guard > end);

-:208: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_node' - possible 
side-effects?
#208: FILE: drivers/gpu/drm/i915/i915_vma_resource.c:37:
+#define VMA_RES_START(_node) ((_node)->start - (_node)->guard)

-:209: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_node' - possible 
side-effects?
#209: FILE: drivers/gpu/drm/i915/i915_vma_resource.c:38:
+#define VMA_RES_LAST(_node) ((_node)->start + (_node)->node_size + 
(_node)->guard - 1)

total: 0 errors, 1 warnings, 2 checks, 196 lines checked
487b3397fb48 drm/i915: Refine VT-d scanout workaround
-:125: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#125: FILE: drivers/gpu/drm/i915/i915_vma.c:762:
+   GEM_BUG_ON(hweight64(flags & (PIN_OFFSET_GUARD | PIN_OFFSET_FIXED | 
PIN_OFFSET_BIAS)) > 1);

-:134: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#134: FILE: drivers/gpu/drm/i915/i915_vma.c:778:
+   GEM_BUG_ON(overflows_type(flags & PIN_OFFSET_MASK, u32));

total: 0 errors, 2 warnings, 0 checks, 95 lines checked
094fcfb78427 Revert "drm/i915: Improve on suspend / resume time with VT-d 
enabled"

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT

[Rodrigo Vivi]

On Tue, Nov 22, 2022 at 06:50:14PM +, Teres Alexis, Alan Previn wrote:
> 
> 
> On Tue, 2022-11-22 at 12:57 -0500, Vivi, Rodrigo wrote:
> > 
> > 
> [Alan:snip]
> 
> > As I had told I don't have a strong preference, as long as it keep clean
> > and without these many helpers of something "on_gt"...
> > 
> > If this stays inside the gt, just make sure that you call for all the gts,
> > but then you inside the functions you can skip if pxp not enabled... without
> > asking if enabled on_gt... 
> > 
> I think we have here conflicting requests. The "consumers" of pxp feature are 
> gem-execbuf, gem-context, gem-create (and
> even display, for checking). Are we okay with making these callers be aware 
> of "if mtl, ensure i call intel_pxp_foo with
> the media-tile's pxp, agnostic to the request, context or buffer i am dealing 
> with now". If you are okay with this, then
> we can make this stay inside gt without "enabled on_gt" functions. But if 
> dont want to polute such low level backend
> awareness into those upper layers, we need them to call something more global 
> like "intel_gpu_has_pxp_enabled" or
> "intel_gpu_has_pxp_started" at the least with an i915 param. So that these 
> callers dont need to worry about it. Or
> intel_pxp_enabled has to internally check with gt we are being passed with 
> and verify we are on the correct gt to - but
> you said you dont want to have an "enabled on_gt" inside the pxp folder since 
> pxp is a subset of gt. The only thing i
> can think of is just a rename  - i.e. instead of "intel_pxp_enabled_on_gt", 
> have a "intel_gpu_has_pxp_enabled(i915)" -
> but it would reside in the pxp folder. Would this work?

In the end I believe that the pxp needs to be the one with knowledge of the
serving_gt. Either gt0 on TGL or media_gt on MTL.

So, if we keep the intel_pxp inside the intel_gt to make the initialization,
irq, and pm flows cleaner, we need probably need to save the
struct intel_gt *gt_serving_pxp;
inside all the intel_pxp, or in drm_i915_private, and then
have a helper that returns the ...gt_serving_pxp(...)
but then skipping the init/fini functions if gt parent != gt_serving_pxp.

> 
> > > 
> > > ...alan
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version to v2.08

[Matt Roper]

I replied on v1 of this patch before realizing there was a v2 here.  See
https://lists.freedesktop.org/archives/intel-gfx/2022-November/313046.html
for my feedback.


Matt

On Tue, Nov 22, 2022 at 06:17:15PM +, Srivatsa, Anusha wrote:
> Thanks, looked at the rest of the platforms in the file and the changes look 
> good.
> 
> Reviewed-by: Anusha Srivatsa 
> 
> 
> 
> > -Original Message-
> > From: Sousa, Gustavo 
> > Sent: Tuesday, November 22, 2022 10:06 AM
> > To: Srivatsa, Anusha ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version
> > to v2.08
> > 
> > Hi, Anusha.
> > 
> > On Tue, Nov 22, 2022 at 02:27:05PM -0300, Srivatsa, Anusha wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Intel-gfx  On Behalf
> > > > Of Gustavo Sousa
> > > > Sent: Tuesday, November 22, 2022 4:14 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Subject: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version
> > > > to
> > > > v2.08
> > > >
> > > > Release notes:
> > > >
> > > > 1. Fixes for Register noclaims and few restore.
> > > >
> > > > Signed-off-by: Gustavo Sousa 
> > > > ---
> > > >
> > > > v2:
> > > >   - Use correct numbering for the minor version (8 instead of the
> > > > invalid octal 08).
> > > >
> > > >  drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > index 081a4d0083b1..eff3add70611 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > @@ -52,8 +52,8 @@
> > > >
> > > >  #define DISPLAY_VER12_DMC_MAX_FW_SIZE
> > ICL_DMC_MAX_FW_SIZE
> > > >
> > > > -#define DG2_DMC_PATH   DMC_PATH(dg2, 2, 07)
> > > > -#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 07)
> > > > +#define DG2_DMC_PATH   DMC_PATH(dg2, 2, 08)
> > > > +#define DG2_DMC_VERSION_REQUIRED   DMC_VERSION(2, 8)
> > >   ^this should be
> > (2,08)
> > 
> > The v1 was using 08, but the problem is that this value is interpreted as a 
> > bad
> > octal, and that caused the compiler to rightfully complain about it :-).
> > 
> > While the path should contain the "08", I believe the version required must
> > contain valid numbers and we should represent them in the decimal base.
> > There are other similar examples in this file.
> > 
> > --
> > Gustavo Sousa

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Update DG2 DMC version to v2.08

[Matt Roper]

On Mon, Nov 21, 2022 at 06:18:15PM -0300, Gustavo Sousa wrote:
> Release notes:
> 
> 1. Fixes for Register noclaims and few restore.
> 
> Signed-off-by: Gustavo Sousa 

Now that we've removed force_probe from DG2, in general we're past the
point where we can just directly update firmware versions like this; if
someone has a working system with the current kernel + DMC 2.07 and then
they update to a new kernel containing this patch (but without
installing DMC 2.08), they'd see a regression.

In this case, maybe there's still time to sneak this specific update
into -fixes so that it lands in the same kernel release that removes the
force_probe protection on DG2?  But in general we need to start
providing backwards-compatible support for all firmware updates going
forward.  The GuC/HuC guys just went through an overhaul of their
firmware handling to deal with this; we probably need something similar
on the DMC side now too, although I suspect DMC should be simpler to
deal with since most (all?) DMC firmwares are just drop-in replacements
and there's no constantly changing firmware<->driver interface like
there is with the GuC.

See Documentation/driver-api/firmware/firmware-usage-guidelines.rst for
the official rules about firmware usage.


Matt

> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 081a4d0083b1..697196368fbb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -52,8 +52,8 @@
>  
>  #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>  
> -#define DG2_DMC_PATH DMC_PATH(dg2, 2, 07)
> -#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 07)
> +#define DG2_DMC_PATH DMC_PATH(dg2, 2, 08)
> +#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 08)
>  MODULE_FIRMWARE(DG2_DMC_PATH);
>  
>  #define ADLP_DMC_PATHDMC_PATH(adlp, 2, 16)
> -- 
> 2.38.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH 3/6] drm/i915/gsc: GSC firmware loading

[Rodrigo Vivi]

On Tue, Nov 22, 2022 at 11:39:31AM -0800, Ceraolo Spurio, Daniele wrote:
> 
> 
> On 11/22/2022 11:01 AM, Rodrigo Vivi wrote:
> > On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:
> > > GSC FW is loaded by submitting a dedicated command via the GSC engine.
> > > The memory area used for loading the FW is then re-purposed as local
> > > memory for the GSC itself, so we use a separate allocation instead of
> > > using the one where we keep the firmware stored for reload.
> > > 
> > > The GSC is not reset as part of GT reset, so we only need to load it on
> > > first boot and S3/S4 exit.
> > > 
> > > Note that the GSC load takes a lot of time (up to a few hundred ms).
> > > This patch loads it serially as part of driver init/resume, but, given
> > > that GSC is only required for PM and content-protection features
> > > (media C6, PXP, HDCP), we could move the load to a worker thread to 
> > > unblock
> > > non-CP userspace submissions earlier. This will be done as a follow up
> > > step, because there are extra init steps required to actually make use of
> > > the GSC (including a mei component) and it will be cleaner (and easier to
> > > review) if we implement the async load once all the pieces we need for GSC
> > > to work are in place. A TODO has been added to the code to mark this
> > > intention.
> > > 
> > > Bspec: 63347, 65346
> > > Signed-off-by: Daniele Ceraolo Spurio 
> > > Cc: Alan Previn 
> > > Cc: John Harrison 
> > > ---
> > >   drivers/gpu/drm/i915/Makefile|   1 +
> > >   drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  14 +-
> > >   drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
> > >   drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
> > >   drivers/gpu/drm/i915/gt/intel_gt.c   |  11 ++
> > >   drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 186 +++
> > >   drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  13 ++
> > >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  35 +++-
> > >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|   7 +
> > >   drivers/gpu/drm/i915/gt/uc/intel_uc.c|  15 ++
> > >   drivers/gpu/drm/i915/gt/uc/intel_uc.h|   2 +
> > >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
> > >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
> > >   13 files changed, 307 insertions(+), 7 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> > >   create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
> > > 
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 92d37cf71e16..1d45a6f451fa 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -206,6 +206,7 @@ i915-y += gt/uc/intel_uc.o \
> > > gt/uc/intel_huc.o \
> > > gt/uc/intel_huc_debugfs.o \
> > > gt/uc/intel_huc_fw.o \
> > > +   gt/uc/intel_gsc_fw.o \
> > > gt/uc/intel_gsc_uc.o
> > >   # graphics system controller (GSC) support
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
> > > b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > > index 0d812f4d787d..f77eb4009aba 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > > @@ -232,10 +232,22 @@ void i915_gem_resume(struct drm_i915_private *i915)
> > >* guarantee that the context image is complete. So let's just 
> > > reset
> > >* it and start again.
> > >*/
> > > - for_each_gt(gt, i915, i)
> > > + for_each_gt(gt, i915, i) {
> > >   if (intel_gt_resume(gt))
> > >   goto err_wedged;
> > > + /*
> > > +  * TODO: this is a long operation (up to ~200ms) and we don't
> > > +  * need to complete it before driver load/resume is done, so it
> > > +  * should be handled in a separate thread to unlock userspace
> > > +  * submission. However, there are a couple of other pieces that
> > > +  * are required for full GSC support that will complicate things
> > > +  * a bit, and it is easier to move everything to a worker at the
> > > +  * same time, so keep it here for now.
> > > +  */
> > > + intel_uc_init_hw_late(>uc);
> > > + }
> > > +
> > >   ret = lmem_restore(i915, I915_TTM_BACKUP_ALLOW_GPU);
> > >   GEM_WARN_ON(ret);
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
> > > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > > index cbc8b857d5f7..0e24af5efee9 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > > @@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs 
> > > *engine, int reg, u32 value)
> > >   #define I915_GEM_HWS_MIGRATE(0x42 * sizeof(u32))
> > >   #define I915_GEM_HWS_PXP0x60
> > >   #define I915_GEM_HWS_PXP_ADDR   (I915_GEM_HWS_PXP * sizeof(u32))
> > > +#define 

Re: [Intel-gfx] [PATCH 6/6] drm/i915/mtl: MTL has one GSC CS on the media GT

[Rodrigo Vivi]

On Mon, Nov 21, 2022 at 03:16:17PM -0800, Daniele Ceraolo Spurio wrote:
> Now that we have the GSC FW support code as a user to the GSC CS, we
> can add the relevant flag to the engine mask. Note that the engine will
> still be disabled until we define the GSC FW binary file.
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Matt Roper 
> Cc: Rodrigo Vivi 

Reviewed-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 6da9784fe4a2..46acbf390195 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1124,7 +1124,7 @@ static const struct intel_gt_definition 
> xelpmp_extra_gt[] = {
>   .type = GT_MEDIA,
>   .name = "Standalone Media GT",
>   .gsi_offset = MTL_MEDIA_GSI_BASE,
> - .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
> + .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2) | BIT(GSC0),
>   },
>   {}
>  };
> -- 
> 2.37.3
> 

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gsc: Disable GSC engine and power well if FW is not selected

[Rodrigo Vivi]

On Mon, Nov 21, 2022 at 03:16:16PM -0800, Daniele Ceraolo Spurio wrote:
> From: Jonathan Cavitt 
> 
> The GSC CS is only used for communicating with the GSC FW, so no need to
> initialize it if we're not going to use the FW. If we're not using
> neither the engine nor the microcontoller, then we can also disable the
> power well.
> 
> IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements
> between CS setup and forcewake idleness. See in-code comment for detail.
> 
> Signed-off-by: Jonathan Cavitt 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Matt Roper 
> Cc: John C Harrison 
> Cc: Rodrigo Vivi 
> Cc: Vinay Belgaumkar 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 18 ++
>  drivers/gpu/drm/i915/intel_uncore.c   |  3 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index c33e0d72d670..99c4b866addd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -894,6 +894,24 @@ static intel_engine_mask_t init_engine_mask(struct 
> intel_gt *gt)
>   engine_mask_apply_compute_fuses(gt);
>   engine_mask_apply_copy_fuses(gt);
>  
> + /*
> +  * The only use of the GSC CS is to load and communicate with the GSC
> +  * FW, so we have no use for it if we don't have the FW.
> +  *
> +  * IMPORTANT: in cases where we don't have the GSC FW, we have a
> +  * catch-22 situation that breaks media C6 due to 2 requirements:
> +  * 1) once turned on, the GSC power well will not go to sleep unless the
> +  *GSC FW is loaded.
> +  * 2) to enable idling (which is required for media C6) we need to
> +  *initialize the IDLE_MSG register for the GSC CS and do at least 1
> +  *submission, which will wake up the GSC power well.
> +  */
> + if (__HAS_ENGINE(info->engine_mask, GSC0) && 
> !intel_uc_wants_gsc_uc(>uc)) {
> + drm_notice(>i915->drm,
> +"No GSC FW selected, disabling GSC CS and media 
> C6\n");
> + info->engine_mask &= ~BIT(GSC0);
> + }
> +
>   return info->engine_mask;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index c1befa33ff59..e63d957b59eb 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2701,6 +2701,9 @@ void intel_uncore_prune_engine_fw_domains(struct 
> intel_uncore *uncore,
>   if (fw_domains & BIT(domain_id))
>   fw_domain_fini(uncore, domain_id);
>   }
> +
> + if ((fw_domains & BIT(FW_DOMAIN_ID_GSC)) && !HAS_ENGINE(gt, GSC0))
> + fw_domain_fini(uncore, FW_DOMAIN_ID_GSC);

On a quick glace I was asking "why do you need this since it doesn't have the 
gsc0?
Then I remember that fw_domain got initialized and it will be skipped, right?
Then I though about at least have a comment here, but finally I got myself 
wondering
why we don't do this already in the if above, while we are cleaning the engine 
mask?

>  }
>  
>  static void driver_flr(struct intel_uncore *uncore)
> -- 
> 2.37.3
> 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978
URL   : https://patchwork.freedesktop.org/series/111213/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for 
intel_gt_mcr_wait_for_reg_fw(). Prototype was for intel_gt_mcr_wait_for_reg() 
instead
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for 
intel_gt_mcr_wait_for_reg_fw(). Prototype was for intel_gt_mcr_wait_for_reg() 
instead

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978
URL   : https://patchwork.freedesktop.org/series/111213/
State : warning

== Summary ==

Error: dim checkpatch failed
334ba5339553 drm/i915/dg2: Introduce Wa_18018764978
-:34: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (8, 33)
#34: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:773:
if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_B0, STEP_FOREVER) ||
[...]
+wa_masked_field_set(wal, VF_PREEMPTION, 
PREEMPTION_VERTEX_COUNT, 0x4000);

-:38: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#38: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:775:
+wa_masked_field_set(wal, VF_PREEMPTION, 
PREEMPTION_VERTEX_COUNT, 0x4000);

-:41: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (8, 33)
#41: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:778:
+   if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_C0, STEP_FOREVER) ||
[...]
+wa_masked_en(wal, PSS_MODE2, 
SCOREBOARD_STALL_FLUSH_CONTROL);

-:42: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#42: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:779:
+   if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_C0, STEP_FOREVER) ||
+IS_DG2_G11(engine->i915) || 
IS_DG2_G12(engine->i915))

total: 0 errors, 3 warnings, 1 checks, 24 lines checked
2abed76522bc drm/i915/dg2: Introduce Wa_18019271663

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded

[Rodrigo Vivi]

On Mon, Nov 21, 2022 at 03:16:15PM -0800, Daniele Ceraolo Spurio wrote:
> If the GSC was loaded, the only way to stop it during the driver unload
> flow is to do a driver-FLR.
> The driver-FLR is not the same as PCI config space FLR in that
> it doesn't reset the SGUnit and doesn't modify the PCI config
> space. Thus, it doesn't require a re-enumeration of the PCI BARs.
> However, the driver-FLR does cause a memory wipe of graphics memory
> on all discrete GPU platforms or a wipe limited to stolen memory
> on the integrated GPU platforms.

Nothing major or blocking, but a few thoughts:

1. Should we document this in the code, at least in a comment in the
flr function?
2. Should we call this driver_initiated_flr, aiming to reduce even more
the ambiguity of it?

> 
> We perform the FLR as the last action before releasing the MMIO bar, so
> that we don't have to care about the consequences of the reset on the
> unload flow.

3. should we try to implement this already in the gt_reset case as the
last resrouce before wedging the gt? So we can already test this flow
in the current platforms?

> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Alan Previn 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  9 +
>  drivers/gpu/drm/i915/i915_reg.h   |  3 ++
>  drivers/gpu/drm/i915/intel_uncore.c   | 45 +++
>  drivers/gpu/drm/i915/intel_uncore.h   | 13 +++
>  4 files changed, 70 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> index 510fb47193ec..5dad3c19c445 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> @@ -173,6 +173,15 @@ int intel_gsc_fw_upload(struct intel_gsc_uc *gsc)
>   if (err)
>   goto fail;
>  
> + /*
> +  * Once the GSC FW is loaded, the only way to kill it on driver unload
> +  * is to do a driver FLR. Given this is a very disruptive action, we
> +  * want to do it as the last action before releasing the access to the
> +  * MMIO bar, which means we need to do it as part of the primary uncore
> +  * cleanup.
> +  */
> + intel_uncore_set_flr_on_fini(>i915->uncore);
> +
>   /* FW is not fully operational until we enable SW proxy */
>   intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8e1892d14774..60e55245200b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -118,6 +118,9 @@
>  
>  #define GU_CNTL  _MMIO(0x101010)
>  #define   LMEM_INIT  REG_BIT(7)
> +#define   DRIVERFLR  REG_BIT(31)
> +#define GU_DEBUG _MMIO(0x101018)
> +#define   DRIVERFLR_STATUS   REG_BIT(31)
>  
>  #define GEN6_STOLEN_RESERVED _MMIO(0x1082C0)
>  #define GEN6_STOLEN_RESERVED_ADDR_MASK   (0xFFF << 20)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 8006a6c61466..c1befa33ff59 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2703,6 +2703,48 @@ void intel_uncore_prune_engine_fw_domains(struct 
> intel_uncore *uncore,
>   }
>  }
>  
> +static void driver_flr(struct intel_uncore *uncore)
> +{
> + struct drm_i915_private *i915 = uncore->i915;
> + const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
> */
> + int ret;
> +
> + drm_dbg(>drm, "Triggering Driver-FLR\n");
> +
> + /*
> +  * Make sure any pending FLR requests have cleared by waiting for the
> +  * FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
> +  * to make sure it's not still set from a prior attempt (it's a write to
> +  * clear bit).
> +  * Note that we should never be in a situation where a previous attempt
> +  * is still pending (unless the HW is totally dead), but better to be
> +  * safe in case something unexpected happens
> +  */
> + ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0, 
> flr_timeout_ms);
> + if (ret) {
> + drm_err(>drm,
> + "Failed to wait for Driver-FLR bit to clear! %d\n",
> + ret);
> + return;
> + }
> + intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
> +
> + /* Trigger the actual Driver-FLR */
> + intel_uncore_rmw_fw(uncore, GU_CNTL, 0, DRIVERFLR);
> +
> + ret = intel_wait_for_register_fw(uncore, GU_DEBUG,
> +  DRIVERFLR_STATUS, DRIVERFLR_STATUS,
> +  flr_timeout_ms);
> + if (ret) {
> + drm_err(>drm, "wait for Driver-FLR completion failed! 
> %d\n", ret);
> + return;
> + }
> +
> + intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
> +
> 

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC

[Navare, Manasi D]

Thanks Stan for the explanation,
With that

Reviewed-by: Manasi Navare 

Manasi


-Original Message-
From: Lisovskiy, Stanislav  
Sent: Tuesday, November 22, 2022 2:40 AM
To: Navare, Manasi D 
Cc: intel-gfx@lists.freedesktop.org; Saarinen, Jani ; 
Nikula, Jani ; dri-de...@lists.freedesktop.org; 
Govindapillai, Vinod 
Subject: Re: [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC

On Thu, Nov 10, 2022 at 02:23:53PM -0800, Navare, Manasi wrote:
> On Thu, Nov 03, 2022 at 03:23:00PM +0200, Stanislav Lisovskiy wrote:
> > Fix intel_dp_dsc_compute_config, previously timeslots parameter was 
> > used in fact not as a timeslots, but more like a ratio timeslots/64, 
> > which of course didn't have any effect for SST DSC, but causes now 
> > issues for MST DSC.
> > Secondly we need to calculate pipe_bpp using 
> > intel_dp_dsc_compute_bpp only for SST DSC case, while for MST case 
> > it has been calculated earlier already with 
> > intel_dp_dsc_mst_compute_link_config.
> > Third we also were wrongly determining sink min bpp/max bpp, those 
> > limites should be intersected with our limits to find common 
> > acceptable bpp's, plus on top of that we should align those with 
> > VESA bpps and only then calculate required timeslots amount.
> > Some MST hubs started to work only after third change was made.
> > 
> > v2: Make kernel test robot happy(claimed there was unitialzed use,
> > while there is none)
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 69 ++---
> >  drivers/gpu/drm/i915/display/intel_dp.h |  3 +-
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 69 
> > +
> >  3 files changed, 106 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 8288a30dbd51..82752b696498 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -716,9 +716,14 @@ u16 intel_dp_dsc_get_output_bpp(struct 
> > drm_i915_private *i915,
> >  * for SST -> TimeSlotsPerMTP is 1,
> >  * for MST -> TimeSlotsPerMTP has to be calculated
> >  */
> > -   bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> > -intel_dp_mode_to_fec_clock(mode_clock);
> > -   drm_dbg_kms(>drm, "Max link bpp: %u\n", bits_per_pixel);
> > +   bits_per_pixel = DIV_ROUND_UP((link_clock * lane_count) * timeslots,
> > + intel_dp_mode_to_fec_clock(mode_clock) * 
> > 8);
> 
> Why did we remove the *8 in the numerator for the total bandwidth 
> link_clock * lane_count * 8 ?
> 
> Other than this clarification, all changes look good
> 
> Manasi

Hi Manasi,

Because previously this function was actually confusing the ratio timeslots/64, 
with the timeslots number.

It was actually expecting a ratio timeslots/64, rather than the timeslots 
number.

For SST it didn't matter as timeslots were always 1, but for MST case if we 
multiply that by number number of timeslots, this formula will return some big 
bogus bits_per_pixel number(checked that). 
Of course we can pass a ratio timeslots/64 here, but it isn't very convenient 
and intuitive to manipulate.
So I made it to use a "timeslots" parameter as timeslots number, so that the 
ratio is calculated as part of the formula i.e:

((link_clock * lane_count * 8) * (timeslots / 64)) /  
intel_dp_mode_to_fec_clock(mode_clock);

which can be simplified as

((link_clock * lane_count * timeslots) / 8) / 
intel_dp_mode_to_fec_clock(mode_clock);

the whole formula comes from that
pipe_bpp * crtc_clock should be equal to link_total_bw * (timeslots / 64), i.e
timeslots/64 ratio defines, how much of the link_total_bw(link_clock * 
lane_count * 8) we have for those pipe_bpp * crtc_clock, which we want to 
accomodate there.

Obviously if we just multiplied link_total_bw by timeslots, we would get a 
situation that the more timeslots we allocate, the more total bw we get, which 
is wrong and will result in some bogus huge pipe_bpp numbers.

Stan

> 
> > +
> > +   drm_dbg_kms(>drm, "Max link bpp is %u for %u timeslots "
> > +   "total bw %u pixel clock %u\n",
> > +   bits_per_pixel, timeslots,
> > +   (link_clock * lane_count * 8),
> > +   intel_dp_mode_to_fec_clock(mode_clock));
> >  
> > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
> > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) / @@ 
> > -1047,7 +1052,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> > target_clock,
> > mode->hdisplay,
> > bigjoiner,
> > -   pipe_bpp, 1) >> 4;

[Intel-gfx] [PATCH 3/4] drm/i915/gt: Add dedicated MCR lock

[Matt Roper]

We've been overloading uncore->lock to protect access to the MCR
steering register.  That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).  Let's create a dedicated MCR lock to protect the
steering control register over this critical section and stop relying on
the high-traffic uncore->lock.

For now the new lock is a software lock.  However some platforms (MTL
and beyond) have a hardware-provided locking mechanism that can be used
to serialize not only software accesses, but also hardware/firmware
accesses as well; support for that hardware level lock will be added in
a future patch.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Balasubramani Vivekanandan 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c  |  2 +
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 66 -
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |  2 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h|  8 +++
 drivers/gpu/drm/i915/gt/intel_mocs.c|  2 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c |  4 ++
 6 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b5ad9caa5537..f823fc0b3827 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1094,6 +1094,7 @@ static void mmio_invalidate_full(struct intel_gt *gt)
 
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
 
+   intel_gt_mcr_lock(gt);
spin_lock_irq(>lock); /* serialise invalidate with GT reset */
 
awake = 0;
@@ -1129,6 +1130,7 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_write_fw(uncore, GEN12_OA_TLB_INV_CR, 1);
 
spin_unlock_irq(>lock);
+   intel_gt_mcr_unlock(gt);
 
for_each_engine_masked(engine, gt, awake, tmp) {
struct reg_and_bit rb;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index f4484bb18ec9..f9e722d91904 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -143,6 +143,8 @@ void intel_gt_mcr_init(struct intel_gt *gt)
unsigned long fuse;
int i;
 
+   spin_lock_init(>mcr_lock);
+
/*
 * An mslice is unavailable only if both the meml3 for the slice is
 * disabled *and* all of the DSS in the slice (quadrant) are disabled.
@@ -228,6 +230,7 @@ static i915_reg_t mcr_reg_cast(const i915_mcr_reg_t mcr)
  * @instance: instance number (documented as "subsliceid" on older platforms)
  * @value: register value to be written (ignored for read)
  *
+ * Context: The caller must hold the MCR lock
  * Return: 0 for write access. register value for read access.
  *
  * Caller needs to make sure the relevant forcewake wells are up.
@@ -239,7 +242,7 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt *gt,
struct intel_uncore *uncore = gt->uncore;
u32 mcr_mask, mcr_ss, mcr, old_mcr, val = 0;
 
-   lockdep_assert_held(>lock);
+   lockdep_assert_held(>mcr_lock);
 
if (GRAPHICS_VER_FULL(uncore->i915) >= IP_VER(12, 70)) {
/*
@@ -324,6 +327,7 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
 GEN8_MCR_SELECTOR,
 FW_REG_READ | 
FW_REG_WRITE);
 
+   intel_gt_mcr_lock(gt);
spin_lock_irq(>lock);
intel_uncore_forcewake_get__locked(uncore, fw_domains);
 
@@ -331,10 +335,45 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
 
intel_uncore_forcewake_put__locked(uncore, fw_domains);
spin_unlock_irq(>lock);
+   intel_gt_mcr_unlock(gt);
 
return val;
 }
 
+/**
+ * intel_gt_mcr_lock - Acquire MCR steering lock
+ * @gt: GT structure
+ *
+ * Performs locking to protect the steering for the duration of an MCR
+ * operation.  Depending on the platform, this may be a software lock
+ * (gt->mcr_lock) or a hardware lock (i.e., a register that synchronizes
+ * access not only for the driver, but also for external hardware and
+ * firmware agents).
+ *
+ * Context: Takes gt->mcr_lock.  uncore->lock should *not* be held when this
+ *  function is called, although it may be acquired after this
+ *  function call.
+ */
+void intel_gt_mcr_lock(struct intel_gt *gt)
+{
+   lockdep_assert_not_held(>uncore->lock);
+
+   spin_lock(>mcr_lock);
+}
+
+/**
+ * intel_gt_mcr_unlock - Release MCR steering lock
+ * @gt: GT structure
+ *
+ * Releases the lock acquired by intel_gt_mcr_lock().
+ *
+ * Context: Releases gt->mcr_lock
+ */
+void intel_gt_mcr_unlock(struct intel_gt *gt)
+{
+   spin_unlock(>mcr_lock);
+}
+
 /**
  * intel_gt_mcr_read - read a specific instance of an MCR register
  * @gt: GT structure
@@ -342,6 +381,8 @@ static u32 

[Intel-gfx] [PATCH 2/4] drm/i915/gt: Pass gt rather than uncore to lowest-level reads/writes

[Matt Roper]

Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
folling patch.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index ea86c1ab5dc5..f4484bb18ec9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -221,7 +221,7 @@ static i915_reg_t mcr_reg_cast(const i915_mcr_reg_t mcr)
 
 /*
  * rw_with_mcr_steering_fw - Access a register with specific MCR steering
- * @uncore: pointer to struct intel_uncore
+ * @gt: GT to read register from
  * @reg: register being accessed
  * @rw_flag: FW_REG_READ for read access or FW_REG_WRITE for write access
  * @group: group number (documented as "sliceid" on older platforms)
@@ -232,10 +232,11 @@ static i915_reg_t mcr_reg_cast(const i915_mcr_reg_t mcr)
  *
  * Caller needs to make sure the relevant forcewake wells are up.
  */
-static u32 rw_with_mcr_steering_fw(struct intel_uncore *uncore,
+static u32 rw_with_mcr_steering_fw(struct intel_gt *gt,
   i915_mcr_reg_t reg, u8 rw_flag,
   int group, int instance, u32 value)
 {
+   struct intel_uncore *uncore = gt->uncore;
u32 mcr_mask, mcr_ss, mcr, old_mcr, val = 0;
 
lockdep_assert_held(>lock);
@@ -308,11 +309,12 @@ static u32 rw_with_mcr_steering_fw(struct intel_uncore 
*uncore,
return val;
 }
 
-static u32 rw_with_mcr_steering(struct intel_uncore *uncore,
+static u32 rw_with_mcr_steering(struct intel_gt *gt,
i915_mcr_reg_t reg, u8 rw_flag,
int group, int instance,
u32 value)
 {
+   struct intel_uncore *uncore = gt->uncore;
enum forcewake_domains fw_domains;
u32 val;
 
@@ -325,7 +327,7 @@ static u32 rw_with_mcr_steering(struct intel_uncore *uncore,
spin_lock_irq(>lock);
intel_uncore_forcewake_get__locked(uncore, fw_domains);
 
-   val = rw_with_mcr_steering_fw(uncore, reg, rw_flag, group, instance, 
value);
+   val = rw_with_mcr_steering_fw(gt, reg, rw_flag, group, instance, value);
 
intel_uncore_forcewake_put__locked(uncore, fw_domains);
spin_unlock_irq(>lock);
@@ -347,7 +349,7 @@ u32 intel_gt_mcr_read(struct intel_gt *gt,
  i915_mcr_reg_t reg,
  int group, int instance)
 {
-   return rw_with_mcr_steering(gt->uncore, reg, FW_REG_READ, group, 
instance, 0);
+   return rw_with_mcr_steering(gt, reg, FW_REG_READ, group, instance, 0);
 }
 
 /**
@@ -364,7 +366,7 @@ u32 intel_gt_mcr_read(struct intel_gt *gt,
 void intel_gt_mcr_unicast_write(struct intel_gt *gt, i915_mcr_reg_t reg, u32 
value,
int group, int instance)
 {
-   rw_with_mcr_steering(gt->uncore, reg, FW_REG_WRITE, group, instance, 
value);
+   rw_with_mcr_steering(gt, reg, FW_REG_WRITE, group, instance, value);
 }
 
 /**
@@ -588,7 +590,7 @@ u32 intel_gt_mcr_read_any_fw(struct intel_gt *gt, 
i915_mcr_reg_t reg)
for (type = 0; type < NUM_STEERING_TYPES; type++) {
if (reg_needs_read_steering(gt, reg, type)) {
get_nonterminated_steering(gt, type, , );
-   return rw_with_mcr_steering_fw(gt->uncore, reg,
+   return rw_with_mcr_steering_fw(gt, reg,
   FW_REG_READ,
   group, instance, 0);
}
@@ -615,7 +617,7 @@ u32 intel_gt_mcr_read_any(struct intel_gt *gt, 
i915_mcr_reg_t reg)
for (type = 0; type < NUM_STEERING_TYPES; type++) {
if (reg_needs_read_steering(gt, reg, type)) {
get_nonterminated_steering(gt, type, , );
-   return rw_with_mcr_steering(gt->uncore, reg,
+   return rw_with_mcr_steering(gt, reg,
FW_REG_READ,
group, instance, 0);
}
-- 
2.38.1

[Intel-gfx] [PATCH 1/4] drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg()

[Matt Roper]

The kerneldoc function name was not updated when this function was
converted to a non-fw form.

Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR 
register")
Reported-by: kernel test robot 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index d9a8ff9e5e57..ea86c1ab5dc5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -702,7 +702,7 @@ void intel_gt_mcr_get_ss_steering(struct intel_gt *gt, 
unsigned int dss,
 }
 
 /**
- * intel_gt_mcr_wait_for_reg_fw - wait until MCR register matches expected 
state
+ * intel_gt_mcr_wait_for_reg - wait until MCR register matches expected state
  * @gt: GT structure
  * @reg: the register to read
  * @mask: mask to apply to register value
-- 
2.38.1

[Intel-gfx] [PATCH 0/4] i915: dedicated MCR locking and hardware semaphore

[Matt Roper]

We've been overloading uncore->lock to protect access to the MCR
steering register.  That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).  Switch to a dedicated MCR lock to protect the
steering control register over this critical section and stop relying on
the high-traffic uncore->lock.  On pre-MTL platforms the dedicated MCR
lock is just another software lock, but on MTL and beyond we also
utilize the hardware-provided STEER_SEMAPHORE that allows us to
synchronize with external hardware and firmware agents.

Matt Roper (4):
  drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg()
  drm/i915/gt: Pass gt rather than uncore to lowest-level reads/writes
  drm/i915/gt: Add dedicated MCR lock
  drm/i915/mtl: Add hardware-level lock for steering

 drivers/gpu/drm/i915/gt/intel_gt.c  |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 107 ++--
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h|   8 ++
 drivers/gpu/drm/i915/gt/intel_mocs.c|   2 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c |   4 +
 7 files changed, 115 insertions(+), 11 deletions(-)

-- 
2.38.1

[Intel-gfx] [PATCH 4/4] drm/i915/mtl: Add hardware-level lock for steering

[Matt Roper]

Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against races with hardware/firmware agents.  The hardware provides a
dedicated locking mechanism to support this via the STEER_SEMAPHORE
register.  Reading the register acts as a 'trylock' operation; the read
will return 0x1 if the lock is acquired or 0x0 if something else is
already holding the lock; once acquired, writing 0x1 to the register
will release the lock.

We'll continue to grab the software lock as well, just so lockdep can
track our locking; assuming the hardware lock is behaving properly,
there should never be any contention on the software lock in this case.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 29 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index f9e722d91904..fe5f5e0affdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -345,10 +345,9 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
  * @gt: GT structure
  *
  * Performs locking to protect the steering for the duration of an MCR
- * operation.  Depending on the platform, this may be a software lock
- * (gt->mcr_lock) or a hardware lock (i.e., a register that synchronizes
- * access not only for the driver, but also for external hardware and
- * firmware agents).
+ * operation.  On MTL and beyond, a hardware lock will also be taken to
+ * serialize access not only for the driver, but also for external hardware and
+ * firmware agents.
  *
  * Context: Takes gt->mcr_lock.  uncore->lock should *not* be held when this
  *  function is called, although it may be acquired after this
@@ -356,9 +355,28 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
  */
 void intel_gt_mcr_lock(struct intel_gt *gt)
 {
+   int err = 0;
+
lockdep_assert_not_held(>uncore->lock);
 
+   /*
+* Starting with MTL, we need to coordinate not only with other
+* driver threads, but also with hardware/firmware agents.  A dedicated
+* locking register is used.
+*/
+   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   err = wait_for(intel_uncore_read_fw(gt->uncore,
+   STEER_SEMAPHORE) == 0x1, 1);
+
+   /*
+* Even on platforms with a hardware lock, we'll continue to grab
+* a software spinlock too for lockdep purposes.  If the hardware lock
+* was already acquired, there should never be contention on the
+* software lock.
+*/
spin_lock(>mcr_lock);
+
+   drm_WARN_ON_ONCE(>i915->drm, err == -ETIMEDOUT);
 }
 
 /**
@@ -372,6 +390,9 @@ void intel_gt_mcr_lock(struct intel_gt *gt)
 void intel_gt_mcr_unlock(struct intel_gt *gt)
 {
spin_unlock(>mcr_lock);
+
+   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   intel_uncore_write_fw(gt->uncore, STEER_SEMAPHORE, 0x1);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 80a979e6f6be..412c0b399ebd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -67,6 +67,7 @@
 #define GMD_ID_MEDIA   _MMIO(MTL_MEDIA_GSI_BASE + 
0xd8c)
 
 #define MCFG_MCR_SELECTOR  _MMIO(0xfd0)
+#define STEER_SEMAPHORE_MMIO(0xfd0)
 #define MTL_MCR_SELECTOR   _MMIO(0xfd4)
 #define SF_MCR_SELECTOR_MMIO(0xfd8)
 #define GEN8_MCR_SELECTOR  _MMIO(0xfdc)
-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: use sysfs_streq() instead of strncmp()

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: use sysfs_streq() instead of strncmp()
URL   : https://patchwork.freedesktop.org/series/111212/
State : warning

== Summary ==

Error: dim checkpatch failed
78ecf723a966 drm/i915/gvt: use sysfs_streq() instead of strncmp()
-:22: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#22: FILE: drivers/gpu/drm/i915/gvt/cmd_parser.c:921:
+   if (sysfs_streq(cmd, "srm") ||
+   sysfs_streq(cmd, "lrm")) {

-:33: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#33: FILE: drivers/gpu/drm/i915/gvt/cmd_parser.c:935:
+   if (sysfs_streq(cmd, "lrr-src") ||
+   sysfs_streq(cmd, "lrr-dst")) {

total: 0 errors, 0 warnings, 2 checks, 42 lines checked

Re: [Intel-gfx] [PATCH 1/6] drm/i915/uc: Introduce GSC FW

[Jani Nikula]

On Tue, 22 Nov 2022, "Ceraolo Spurio, Daniele" 
 wrote:
> On 11/22/2022 1:03 AM, Jani Nikula wrote:
>> On Mon, 21 Nov 2022, Daniele Ceraolo Spurio 
>>  wrote:
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
>>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> index a8f38c2c60e2..5d0f1bcc381e 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> @@ -6,6 +6,7 @@
>>>   #ifndef _INTEL_UC_H_
>>>   #define _INTEL_UC_H_
>>>   
>>> +#include "intel_gsc_uc.h"
>> And thus intel_gsc_uc.h becomes another file that causes the entire
>> driver to be rebuilt when modified.
>>
>> *sad trombone*
>
> I just followed the same pattern as what is done for GuC and HuC files. 
> What's the recommendation here? Should I split out gsc_uc_types.h from 
> gsc_uc.h ?

Sorry for not being clear, I'm not insisting you do anything at this
time.

But it is something that needs to be refactored eventually.

As an anecdotal data point: I just scripted all the #include
dependencies across all the files in the driver into a digraph and had
graphviz turn it into svg, and on my 80 cm wide 4k screen zoomed out as
far as Firefox can, it's still 15 screenfuls side by side. ;D

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT

[Teres Alexis, Alan Previn]

Not everything of course, but intel_feature_action(param1, ...) enforcing 
param1 to always be struct intel_feature_t i
assumed was what Rodrigo meant. And my intention wasn't to verify that rule but 
rather look for surrounding precedence
for any exceptions to it (i felt PXP was a candidate for an exception since its 
services and consumers are global but
its control-points are within the media tile alone).

Either way, this exception won't be required give the new design direction from 
Rodrigo based on that last reply to
patch #1. We will elevate pxp to be a global subsystem (despite the controls 
being gt specific).


...alan

On Tue, 2022-11-22 at 13:17 +0200, Jani Nikula wrote:
> On Thu, 17 Nov 2022, "Teres Alexis, Alan Previn" 
>  wrote:
> > Respectfully and humbly, i would like to request where is the coding
> > guideline for function naming when u have 2nd level subsystem IPs
> > owning control over global hw features so that we dont need to have
> > this back and forth of conflicting direction from different reviewers
> > especially so long after initial reviews have started. (internally
> > reworking future MTL PXP series end up getting impacted here).
> 
> Do you seriously think we could pre-emptively codify everything in a
> coding guideline?
> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT

[Teres Alexis, Alan Previn]

After a more comprehensive offline discussion with Daniele and Rodrigo, design 
direction was made to go with Option2
where we elevate pxp to a global subsystem and within it it establish a pointer 
to the correct gt for pxp-controls. This
also reflects the current HW architectures where the PXP feature (when viewed 
as a service for contexts and buffers) is
global to all subsystems including any workload on any tile, despite its single 
control-knobs being only in the media
tile (because PXP controls needs to be global to the GPU to avoid any races).

This would mean we move 'struct intel_pxp' to be under i915 so that all 
subsystems that need to call into PXP would now
pass in i915 as its parameter. PXP internally would have a pointer to the 
correct GT (media-tile for MTL and gt0 for
prior).

It would also mean that certain code will still look a little kludgy or needs 
attention:
 - power-related operations like init/fini and suspend/resume would now need to 
called either before or after all-gt
equivalents to ensure proper flow.
 - KCR IRQ will although being a gt level IRQ will now require passing i915 
into the pxp subsystem.

*NOTE: above list, even if i missed any, would still be nowhere near the amount 
of other external facing interfaces that
would be called by global subsystems that would now look clean with i915->pxp 
as its param.

...alan


On Tue, 2022-11-22 at 10:52 -0800, Alan Previn Teres Alexis wrote:
> 
> On Tue, 2022-11-22 at 12:57 -0500, Vivi, Rodrigo wrote:
> > 
> > 
> [Alan:snip]
> 
> > As I had told I don't have a strong preference, as long as it keep clean
> > and without these many helpers of something "on_gt"...
> > 
> > If this stays inside the gt, just make sure that you call for all the gts,
> > but then you inside the functions you can skip if pxp not enabled... without
> > asking if enabled on_gt... 
> > 
> I think we have here conflicting requests. The "consumers" of pxp feature are 
> gem-execbuf, gem-context, gem-create (and
> even display, for checking). Are we okay with making these callers be aware 
> of "if mtl, ensure i call intel_pxp_foo with
> the media-tile's pxp, agnostic to the request, context or buffer i am dealing 
> with now". If you are okay with this, then
> we can make this stay inside gt without "enabled on_gt" functions. But if 
> dont want to polute such low level backend
> awareness into those upper layers, we need them to call something more global 
> like "intel_gpu_has_pxp_enabled" or
> "intel_gpu_has_pxp_started" at the least with an i915 param. So that these 
> callers dont need to worry about it. Or
> intel_pxp_enabled has to internally check with gt we are being passed with 
> and verify we are on the correct gt to - but
> you said you dont want to have an "enabled on_gt" inside the pxp folder since 
> pxp is a subset of gt. The only thing i
> can think of is just a rename  - i.e. instead of "intel_pxp_enabled_on_gt", 
> have a "intel_gpu_has_pxp_enabled(i915)" -
> but it would reside in the pxp folder. Would this work?
> 
> > > 
> > > ...alan
> 

[Intel-gfx] [PATCH 2/3] drm/i915/uc: More refactoring of UC version numbers

[John . C . Harrison]

From: John Harrison 

As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  6 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 76 +++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 15 +++--
 3 files changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 1d28286e6f066..e6edad6f8f9dd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -437,9 +437,9 @@ static void print_fw_ver(struct intel_uc *uc, struct 
intel_uc_fw *fw)
 
drm_info(>drm, "%s firmware %s version %u.%u.%u\n",
 intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
-fw->file_selected.major_ver,
-fw->file_selected.minor_ver,
-fw->file_selected.patch_ver);
+fw->file_selected.ver.major,
+fw->file_selected.ver.minor,
+fw->file_selected.ver.patch);
 }
 
 static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 774c3d84a4243..5e2ee1ac89514 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -278,8 +278,8 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
 
uc_fw->file_selected.path = blob->path;
uc_fw->file_wanted.path = blob->path;
-   uc_fw->file_wanted.major_ver = blob->major;
-   uc_fw->file_wanted.minor_ver = blob->minor;
+   uc_fw->file_wanted.ver.major = blob->major;
+   uc_fw->file_wanted.ver.minor = blob->minor;
uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
found = true;
break;
@@ -438,28 +438,28 @@ static void __force_fw_fetch_failures(struct intel_uc_fw 
*uc_fw, int e)
uc_fw->user_overridden = user;
} else if (i915_inject_probe_error(i915, e)) {
/* require next major version */
-   uc_fw->file_wanted.major_ver += 1;
-   uc_fw->file_wanted.minor_ver = 0;
+   uc_fw->file_wanted.ver.major += 1;
+   uc_fw->file_wanted.ver.minor = 0;
uc_fw->user_overridden = user;
} else if (i915_inject_probe_error(i915, e)) {
/* require next minor version */
-   uc_fw->file_wanted.minor_ver += 1;
+   uc_fw->file_wanted.ver.minor += 1;
uc_fw->user_overridden = user;
-   } else if (uc_fw->file_wanted.major_ver &&
+   } else if (uc_fw->file_wanted.ver.major &&
   i915_inject_probe_error(i915, e)) {
/* require prev major version */
-   uc_fw->file_wanted.major_ver -= 1;
-   uc_fw->file_wanted.minor_ver = 0;
+   uc_fw->file_wanted.ver.major -= 1;
+   uc_fw->file_wanted.ver.minor = 0;
uc_fw->user_overridden = user;
-   } else if (uc_fw->file_wanted.minor_ver &&
+   } else if (uc_fw->file_wanted.ver.minor &&
   i915_inject_probe_error(i915, e)) {
/* require prev minor version - hey, this should work! */
-   uc_fw->file_wanted.minor_ver -= 1;
+   uc_fw->file_wanted.ver.minor -= 1;
uc_fw->user_overridden = user;
} else if (user && i915_inject_probe_error(i915, e)) {
/* officially unsupported platform */
-   uc_fw->file_wanted.major_ver = 0;
-   uc_fw->file_wanted.minor_ver = 0;
+   uc_fw->file_wanted.ver.major = 0;
+   uc_fw->file_wanted.ver.minor = 0;
uc_fw->user_overridden = true;
}
 }
@@ -471,9 +471,9 @@ static int check_gsc_manifest(const struct firmware *fw,
u32 version_hi = dw[HUC_GSC_VERSION_HI_DW];
u32 version_lo = dw[HUC_GSC_VERSION_LO_DW];
 
-   uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK, 
version_hi);
-   uc_fw->file_selected.minor_ver = FIELD_GET(HUC_GSC_MINOR_VER_HI_MASK, 
version_hi);
-   uc_fw->file_selected.patch_ver = FIELD_GET(HUC_GSC_PATCH_VER_LO_MASK, 
version_lo);
+   uc_fw->file_selected.ver.major = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK, 
version_hi);
+   uc_fw->file_selected.ver.minor = FIELD_GET(HUC_GSC_MINOR_VER_HI_MASK, 
version_hi);
+   uc_fw->file_selected.ver.patch = FIELD_GET(HUC_GSC_PATCH_VER_LO_MASK, 
version_lo);
 
return 0;
 }
@@ -532,11 +532,11 @@ static int check_ccs_header(struct intel_gt *gt,
}
 
/* Get version numbers from the CSS header */
-   uc_fw->file_selected.major_ver = FIELD_GET(CSS_SW_VERSION_UC_MAJOR,
+   

[Intel-gfx] [PATCH 1/3] drm/i915/uc: Rationalise delimiters in filename macros

[John . C . Harrison]

From: John Harrison 

The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise
them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 0c80ba51a4bdc..774c3d84a4243 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -118,35 +118,35 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  */
 #define __MAKE_UC_FW_PATH_BLANK(prefix_, name_) \
"i915/" \
-   __stringify(prefix_) name_ ".bin"
+   __stringify(prefix_) "_" name_ ".bin"
 
 #define __MAKE_UC_FW_PATH_MAJOR(prefix_, name_, major_) \
"i915/" \
-   __stringify(prefix_) name_ \
+   __stringify(prefix_) "_" name_ "_" \
__stringify(major_) ".bin"
 
 #define __MAKE_UC_FW_PATH_MMP(prefix_, name_, major_, minor_, patch_) \
"i915/" \
-   __stringify(prefix_) name_ \
+   __stringify(prefix_) "_" name_  "_" \
__stringify(major_) "." \
__stringify(minor_) "." \
__stringify(patch_) ".bin"
 
 /* Minor for internal driver use, not part of file name */
 #define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_) \
-   __MAKE_UC_FW_PATH_MAJOR(prefix_, "_guc_", major_)
+   __MAKE_UC_FW_PATH_MAJOR(prefix_, "guc", major_)
 
 #define MAKE_GUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
-   __MAKE_UC_FW_PATH_MMP(prefix_, "_guc_", major_, minor_, patch_)
+   __MAKE_UC_FW_PATH_MMP(prefix_, "guc", major_, minor_, patch_)
 
 #define MAKE_HUC_FW_PATH_BLANK(prefix_) \
-   __MAKE_UC_FW_PATH_BLANK(prefix_, "_huc")
+   __MAKE_UC_FW_PATH_BLANK(prefix_, "huc")
 
 #define MAKE_HUC_FW_PATH_GSC(prefix_) \
-   __MAKE_UC_FW_PATH_BLANK(prefix_, "_huc_gsc")
+   __MAKE_UC_FW_PATH_BLANK(prefix_, "huc_gsc")
 
 #define MAKE_HUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
-   __MAKE_UC_FW_PATH_MMP(prefix_, "_huc_", major_, minor_, patch_)
+   __MAKE_UC_FW_PATH_MMP(prefix_, "huc", major_, minor_, patch_)
 
 /*
  * All blobs need to be declared via MODULE_FIRMWARE().
-- 
2.37.3

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Use GuC submission API version number

[John . C . Harrison]

From: John Harrison 

The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.

Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other firmwares do not have that restriction. So
stop making assumptions about them generically fitting in a u16
individually, or in a u32 as a combined 8.8.8.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 +++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 91 ---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  | 10 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h  |  3 +-
 5 files changed, 104 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 1bb3f98292866..bb4dfe707a7d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -158,6 +158,9 @@ struct intel_guc {
bool submission_selected;
/** @submission_initialized: tracks whether GuC submission has been 
initialised */
bool submission_initialized;
+   /** @submission_version: Submission API version of the currently loaded 
firmware */
+   struct intel_uc_fw_ver submission_version;
+
/**
 * @rc_supported: tracks whether we support GuC rc on the current 
platform
 */
@@ -268,6 +271,14 @@ struct intel_guc {
 #endif
 };
 
+/*
+ * GuC version number components are only 8-bit, so converting to a 32bit 8.8.8
+ * integer works.
+ */
+#define MAKE_GUC_VER(maj, min, pat)(((maj) << 16) | ((min) << 8) | (pat))
+#define MAKE_GUC_VER_STRUCT(ver)   MAKE_GUC_VER((ver).major, (ver).minor, 
(ver).patch)
+#define GUC_SUBMIT_VER(guc)
MAKE_GUC_VER_STRUCT((guc)->submission_version)
+
 static inline struct intel_guc *log_to_guc(struct intel_guc_log *log)
 {
return container_of(log, struct intel_guc, log);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0a42f1807f52c..53f7f599cde3a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1890,7 +1890,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
 
-   if (GET_UC_VER(guc) < MAKE_UC_VER(70, 0, 0)) {
+   if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 0, 0)) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2330,7 +2330,7 @@ static int register_context(struct intel_context *ce, 
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
 
-   if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0))
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2342,7 +2342,7 @@ static int register_context(struct intel_context *ce, 
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
 
-   if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0))
guc_context_policy_init_v70(ce, loop);
}
 
@@ -2956,7 +2956,7 @@ static void __guc_context_set_preemption_timeout(struct 
intel_guc *guc,
 u16 guc_id,
 u32 preemption_timeout)
 {
-   if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0)) {
struct context_policy policy;
 
__guc_context_policy_start_klv(, guc_id);
@@ -3283,7 +3283,7 @@ static int guc_context_alloc(struct intel_context *ce)
 static void __guc_context_set_prio(struct intel_guc *guc,
   struct intel_context *ce)
 {
-   if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
+   if (GUC_SUBMIT_VER(guc) >= MAKE_GUC_VER(1, 0, 0)) {
struct context_policy policy;
 
__guc_context_policy_start_klv(, ce->guc_id.id);
@@ -4366,7 +4366,7 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
intel_wakeref_t wakeref;
int ret = 0;
 
-   if (GET_UC_VER(guc) < MAKE_UC_VER(70, 3, 0))
+   if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 1, 0))
return 0;
 
__guc_scheduling_policy_start_klv();
@@ -4905,6 +4905,9 @@ void intel_guc_submission_print_info(struct intel_guc 
*guc,
if (!sched_engine)
return;
 
+   drm_printf(p, "GuC Submission API Version: %d.%d.%d\n",
+  guc->submission_version.major, 

[Intel-gfx] [PATCH 0/3] More GuC firmware version improvements

[John . C . Harrison]

From: John Harrison 

Start using the 'submission API version' for deciding which GuC API to
use in the submission code.

Correct version number manipulation code to support full 32bit
major/minor/patch components, except for GuC which is guaranteed to be
8bit safe.

Other minor code clean ups around version number handling.

Signed-off-by: John Harrison 


John Harrison (3):
  drm/i915/uc: Rationalise delimiters in filename macros
  drm/i915/uc: More refactoring of UC version numbers
  drm/i915/guc: Use GuC submission API version number

 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  11 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  15 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 173 --
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  15 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h  |   3 +-
 6 files changed, 150 insertions(+), 73 deletions(-)

-- 
2.37.3

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Require VM_PFNMAP vma for mmap

[Patchwork]

== Series Details ==

Series: dma-buf: Require VM_PFNMAP vma for mmap
URL   : https://patchwork.freedesktop.org/series/111210/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111210v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111210v1/index.html

Participating hosts (33 -> 32)
--

  Missing(1): fi-pnv-d510 

Known issues


  Here are the changes found in Patchwork_111210v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: [PASS][1] -> [INCOMPLETE][2] ([i915#7308] / 
[i915#7348])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlp-4/igt@i915_selftest@l...@migrate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111210v1/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * igt@runner@aborted:
- bat-adlp-4: NOTRUN -> [FAIL][3] ([i915#4312])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111210v1/bat-adlp-4/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][4] ([i915#4983]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111210v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][6] ([i915#6298]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111210v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#7308]: https://gitlab.freedesktop.org/drm/intel/issues/7308
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
  [i915#7348]: https://gitlab.freedesktop.org/drm/intel/issues/7348


Build changes
-

  * Linux: CI_DRM_12418 -> Patchwork_111210v1

  CI-20190529: 20190529
  CI_DRM_12418: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7071: 0801475083ccb938b1d3b358502ff97fdb435585 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111210v1: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

1638e830bb57 dma-buf: Require VM_PFNMAP vma for mmap

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111210v1/index.html

Re: [Intel-gfx] [PATCH] dma-buf: Require VM_PFNMAP vma for mmap

[Daniel Vetter]

On Tue, 22 Nov 2022 at 20:34, Jason Gunthorpe  wrote:
> On Tue, Nov 22, 2022 at 08:29:05PM +0100, Daniel Vetter wrote:
> > You nuke all the ptes. Drivers that move have slightly more than a
> > bare struct file, they also have a struct address_space so that
> > invalidate_mapping_range() works.
>
> Okay, this is one of the ways that this can be made to work correctly,
> as long as you never allow GUP/GUP_fast to succeed on the PTEs. (this
> was the DAX mistake)

Hence this patch, to enforce that no dma-buf exporter gets this wrong.
Which some did, and then blamed bug reporters for the resulting splats
:-) One of the things we've reverted was the ttm huge pte support,
since that doesn't have the pmd_special flag (yet) and so would let
gup_fast through.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Require VM_PFNMAP vma for mmap

[Patchwork]

== Series Details ==

Series: dma-buf: Require VM_PFNMAP vma for mmap
URL   : https://patchwork.freedesktop.org/series/111210/
State : warning

== Summary ==

Error: dim checkpatch failed
354674e79934 dma-buf: Require VM_PFNMAP vma for mmap
-:15: WARNING:TYPO_SPELLING: 'useable' may be misspelled - perhaps 'usable'?
#15: 
temptation to assume that a struct page is always present and useable
  ^^^

-:34: WARNING:TYPO_SPELLING: 'entires' may be misspelled - perhaps 'entries'?
#34: 
>From auditing the various functions to insert pfn pte entires
  ^^^

-:41: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#41: 
References: 
https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/

-:76: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 4 warnings, 0 checks, 16 lines checked

Re: [Intel-gfx] [PATCH 1/6] drm/i915/uc: Introduce GSC FW

[Ceraolo Spurio, Daniele]

On 11/22/2022 1:03 AM, Jani Nikula wrote:

On Mon, 21 Nov 2022, Daniele Ceraolo Spurio  
wrote:

On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.

Similarly to the other FWs, the GSC FW path can be overriden via
modparam. The modparam can also be used to disable the GSC FW loading by
setting it to an empty string.

Note that the new structure has been called intel_gsc_uc to avoid
confusion with the existing intel_gsc, which instead represents the heci
gsc interfaces.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/Makefile |  3 +-
  drivers/gpu/drm/i915/gt/intel_gt.h|  5 ++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 70 +++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 36 
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 17 ++
  drivers/gpu/drm/i915/gt/uc/intel_uc.h |  3 +
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 25 +++-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  7 ++-
  drivers/gpu/drm/i915/i915_params.c|  3 +
  drivers/gpu/drm/i915/i915_params.h|  1 +
  10 files changed, 164 insertions(+), 6 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 01974b82d205..92d37cf71e16 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -205,7 +205,8 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_guc_submission.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
- gt/uc/intel_huc_fw.o
+ gt/uc/intel_huc_fw.o \
+ gt/uc/intel_gsc_uc.o

Comment near the top of the file:

# Please keep these build lists sorted!


My bad, dumb mistake.



  
  # graphics system controller (GSC) support

  i915-y += gt/intel_gsc.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index e0365d556248..d2f4fbde5f9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -39,6 +39,11 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
return container_of(huc, struct intel_gt, uc.huc);
  }
  
+static inline struct intel_gt *gsc_uc_to_gt(struct intel_gsc_uc *gsc_uc)

+{
+   return container_of(gsc_uc, struct intel_gt, uc.gsc);
+}
+
  static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
  {
return container_of(gsc, struct intel_gt, gsc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
new file mode 100644
index ..65cbf1ce9fa1
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include "gt/intel_gt.h"
+#include "intel_gsc_uc.h"
+#include "i915_drv.h"
+
+static bool gsc_engine_supported(struct intel_gt *gt)
+{
+   intel_engine_mask_t mask;
+
+   /*
+* We reach here from i915_driver_early_probe for the primary GT before
+* its engine mask is set, so we use the device info engine mask for it.
+* For other GTs we expect the GT-specific mask to be set before we
+* call this function.
+*/
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);
+
+   if (gt_is_root(gt))
+   mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
+   else
+   mask = gt->info.engine_mask;
+
+   return __HAS_ENGINE(mask, GSC0);
+}
+
+void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
+{
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+
+   /* we can arrive here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence check device info's
+* engine mask
+*/
+   if (!gsc_engine_supported(gsc_uc_to_gt(gsc))){
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+   return;
+   }
+}
+
+int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
+{
+   struct drm_i915_private *i915 = gsc_uc_to_gt(gsc)->i915;
+   int err;
+
+   err = intel_uc_fw_init(>fw);
+   if (err)
+   goto out;
+
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOADABLE);
+
+   return 0;
+
+out:
+   i915_probe_error(i915, "failed with %d\n", err);
+   return err;
+}
+
+void intel_gsc_uc_fini(struct intel_gsc_uc *gsc)
+{
+   if (!intel_uc_fw_is_loadable(>fw))
+   return;
+
+   intel_uc_fw_fini(>fw);
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
new file mode 100644
index ..ea2b1c0713b8
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
@@ -0,0 +1,36 @@
+/* 

Re: [Intel-gfx] [PATCH 3/6] drm/i915/gsc: GSC firmware loading

[Ceraolo Spurio, Daniele]

On 11/22/2022 11:01 AM, Rodrigo Vivi wrote:

On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:

GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.

The GSC is not reset as part of GT reset, so we only need to load it on
first boot and S3/S4 exit.

Note that the GSC load takes a lot of time (up to a few hundred ms).
This patch loads it serially as part of driver init/resume, but, given
that GSC is only required for PM and content-protection features
(media C6, PXP, HDCP), we could move the load to a worker thread to unblock
non-CP userspace submissions earlier. This will be done as a follow up
step, because there are extra init steps required to actually make use of
the GSC (including a mei component) and it will be cleaner (and easier to
review) if we implement the async load once all the pieces we need for GSC
to work are in place. A TODO has been added to the code to mark this
intention.

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  14 +-
  drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
  drivers/gpu/drm/i915/gt/intel_gt.c   |  11 ++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 186 +++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  13 ++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  35 +++-
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|   7 +
  drivers/gpu/drm/i915/gt/uc/intel_uc.c|  15 ++
  drivers/gpu/drm/i915/gt/uc/intel_uc.h|   2 +
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
  13 files changed, 307 insertions(+), 7 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 92d37cf71e16..1d45a6f451fa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -206,6 +206,7 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
  gt/uc/intel_huc_fw.o \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o
  
  # graphics system controller (GSC) support

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 0d812f4d787d..f77eb4009aba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -232,10 +232,22 @@ void i915_gem_resume(struct drm_i915_private *i915)
 * guarantee that the context image is complete. So let's just reset
 * it and start again.
 */
-   for_each_gt(gt, i915, i)
+   for_each_gt(gt, i915, i) {
if (intel_gt_resume(gt))
goto err_wedged;
  
+		/*

+* TODO: this is a long operation (up to ~200ms) and we don't
+* need to complete it before driver load/resume is done, so it
+* should be handled in a separate thread to unlock userspace
+* submission. However, there are a couple of other pieces that
+* are required for full GSC support that will complicate things
+* a bit, and it is easier to move everything to a worker at the
+* same time, so keep it here for now.
+*/
+   intel_uc_init_hw_late(>uc);
+   }
+
ret = lmem_restore(i915, I915_TTM_BACKUP_ALLOW_GPU);
GEM_WARN_ON(ret);
  
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h b/drivers/gpu/drm/i915/gt/intel_engine.h

index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
  #define I915_GEM_HWS_MIGRATE  (0x42 * sizeof(u32))
  #define I915_GEM_HWS_PXP  0x60
  #define I915_GEM_HWS_PXP_ADDR (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
  #define I915_GEM_HWS_SCRATCH  0x80
  
  #define I915_HWS_CSB_BUF0_INDEX		0x10

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..49ebda141266 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
  #define INSTR_CLIENT_SHIFT  29
  #define   INSTR_MI_CLIENT   0x0
  #define   INSTR_BC_CLIENT   0x2
+#define   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: make default_lists const data

[Patchwork]

== Series Details ==

Series: drm/i915/guc: make default_lists const data
URL   : https://patchwork.freedesktop.org/series/111201/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111201v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/index.html

Participating hosts (33 -> 32)
--

  Missing(1): fi-rkl-11600 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111201v1:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@hangcheck:
- {bat-adlp-6}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html

  
Known issues


  Here are the changes found in Patchwork_111201v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: NOTRUN -> [DMESG-FAIL][4] ([i915#5334])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][6] ([i915#7073]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][8] ([i915#6471]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][10] ([i915#4983]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][12] ([i915#6298]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111201v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6471]: https://gitlab.freedesktop.org/drm/intel/issues/6471
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7073]: https://gitlab.freedesktop.org/drm/intel/issues/7073
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346


Build changes
-

  * Linux: CI_DRM_12418 -> Patchwork_111201v1

  CI-20190529: 20190529
  CI_DRM_12418: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7071: 0801475083ccb938b1d3b358502ff97fdb435585 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111201v1: 

Re: [Intel-gfx] [PATCH] dma-buf: Require VM_PFNMAP vma for mmap

[Daniel Vetter]

On Tue, 22 Nov 2022 at 19:50, Jason Gunthorpe  wrote:
>
> On Tue, Nov 22, 2022 at 07:08:25PM +0100, Daniel Vetter wrote:
> > On Tue, 22 Nov 2022 at 19:04, Jason Gunthorpe  wrote:
> > >
> > > On Tue, Nov 22, 2022 at 06:08:00PM +0100, Daniel Vetter wrote:
> > > > tldr; DMA buffers aren't normal memory, expecting that you can use
> > > > them like that (like calling get_user_pages works, or that they're
> > > > accounting like any other normal memory) cannot be guaranteed.
> > > >
> > > > Since some userspace only runs on integrated devices, where all
> > > > buffers are actually all resident system memory, there's a huge
> > > > temptation to assume that a struct page is always present and useable
> > > > like for any more pagecache backed mmap. This has the potential to
> > > > result in a uapi nightmare.
> > > >
> > > > To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
> > > > blocks get_user_pages and all the other struct page based
> > > > infrastructure for everyone. In spirit this is the uapi counterpart to
> > > > the kernel-internal CONFIG_DMABUF_DEBUG.
> > > >
> > > > Motivated by a recent patch which wanted to swich the system dma-buf
> > > > heap to vm_insert_page instead of vm_insert_pfn.
> > > >
> > > > v2:
> > > >
> > > > Jason brought up that we also want to guarantee that all ptes have the
> > > > pte_special flag set, to catch fast get_user_pages (on architectures
> > > > that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
> > > > still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.
> > > >
> > > > From auditing the various functions to insert pfn pte entires
> > > > (vm_insert_pfn_prot, remap_pfn_range and all it's callers like
> > > > dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
> > > > this should be the correct flag to check for.
> > >
> > > I didn't look at how this actually gets used, but it is a bit of a
> > > pain to insert a lifetime controlled object like a struct page as a
> > > special PTE/VM_PFNMAP
> > >
> > > How is the lifetime model implemented here? How do you know when
> > > userspace has finally unmapped the page?
> >
> > The vma has a filp which is the refcounted dma_buf. With dma_buf you
> > never get an individual page it's always the entire object. And it's
> > up to the allocator how exactly it wants to use or not use the page's
> > refcount. So if gup goes in and elevates the refcount, you can break
> > stuff, which is why I'm doing this.
>
> But how does move work?

You nuke all the ptes. Drivers that move have slightly more than a
bare struct file, they also have a struct address_space so that
invalidate_mapping_range() works. Refaulting and any coherency issues
when a refault races against a dma-buf migration is up to the
driver/exporter to handle correctly. None rely on struct page like mm/
moving stuff around for compaction/ksm/numa-balancing/whateverr.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v3,1/4] i915: Move list_count() to list.h for broader use

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/4] i915: Move list_count() to list.h for 
broader use
URL   : https://patchwork.freedesktop.org/series/111206/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  VDSOarch/x86/entry/vdso/vdso64.so.dbg
arch/x86/entry/vdso/vgetcpu.o: In function `list_count':
/home/kbuild/kernel/./include/linux/list.h:667: multiple definition of 
`list_count'
arch/x86/entry/vdso/vclock_gettime.o:/home/kbuild/kernel/./include/linux/list.h:667:
 first defined here
objdump: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
  OBJCOPY arch/x86/entry/vdso/vdso64.so
objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
arch/x86/entry/vdso/Makefile:139: recipe for target 
'arch/x86/entry/vdso/vdso64.so' failed
make[4]: *** [arch/x86/entry/vdso/vdso64.so] Error 1
scripts/Makefile.build:500: recipe for target 'arch/x86/entry/vdso' failed
make[3]: *** [arch/x86/entry/vdso] Error 2
scripts/Makefile.build:500: recipe for target 'arch/x86/entry' failed
make[2]: *** [arch/x86/entry] Error 2
scripts/Makefile.build:500: recipe for target 'arch/x86' failed
make[1]: *** [arch/x86] Error 2
Makefile:1992: recipe for target '.' failed
make: *** [.] Error 2

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/guc: make default_lists const data

[Patchwork]

== Series Details ==

Series: drm/i915/guc: make default_lists const data
URL   : https://patchwork.freedesktop.org/series/111201/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for 
intel_gt_mcr_wait_for_reg_fw(). Prototype was for intel_gt_mcr_wait_for_reg() 
instead
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for 
intel_gt_mcr_wait_for_reg_fw(). Prototype was for intel_gt_mcr_wait_for_reg() 
instead

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/ttm: Clean up page shift operation

[Patchwork]

== Series Details ==

Series: drm/ttm: Clean up page shift operation
URL   : https://patchwork.freedesktop.org/series/81/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12415_full -> Patchwork_81v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_81v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][1] -> [FAIL][2] ([i915#6268])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12415/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-tglb8/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12415/shard-iclb1/igt@gem_exec_balan...@parallel-out-fence.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-iclb7/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2846])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12415/shard-glk7/igt@gem_exec_f...@basic-deadline.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12415/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12415/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([i915#6453])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12415/shard-iclb2/igt@gem_exec_whis...@basic-queues-forked-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-iclb5/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-skl7/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_userptr_blits@input-checking:
- shard-tglb: NOTRUN -> [DMESG-WARN][14] ([i915#4991])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-tglb6/igt@gem_userptr_bl...@input-checking.html

  * igt@gen7_exec_parse@chained-batch:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-tglb6/igt@gen7_exec_pa...@chained-batch.html

  * igt@gen9_exec_parse@bb-secure:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#2527] / [i915#2856])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-tglb6/igt@gen9_exec_pa...@bb-secure.html

  * 
igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-2:
- shard-glk:  NOTRUN -> [INCOMPLETE][17] ([i915#5584])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-2.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#5286])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-tglb6/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-0.html

  * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-skl7/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#111615] / [i915#3689])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_81v1/shard-tglb6/igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs.html

  * igt@kms_chamelium@hdmi-hpd:
- shard-skl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [21]: 

Re: [Intel-gfx] [PATCH 3/6] drm/i915/gsc: GSC firmware loading

[Rodrigo Vivi]

On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:
> GSC FW is loaded by submitting a dedicated command via the GSC engine.
> The memory area used for loading the FW is then re-purposed as local
> memory for the GSC itself, so we use a separate allocation instead of
> using the one where we keep the firmware stored for reload.
> 
> The GSC is not reset as part of GT reset, so we only need to load it on
> first boot and S3/S4 exit.
> 
> Note that the GSC load takes a lot of time (up to a few hundred ms).
> This patch loads it serially as part of driver init/resume, but, given
> that GSC is only required for PM and content-protection features
> (media C6, PXP, HDCP), we could move the load to a worker thread to unblock
> non-CP userspace submissions earlier. This will be done as a follow up
> step, because there are extra init steps required to actually make use of
> the GSC (including a mei component) and it will be cleaner (and easier to
> review) if we implement the async load once all the pieces we need for GSC
> to work are in place. A TODO has been added to the code to mark this
> intention.
> 
> Bspec: 63347, 65346
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> Cc: John Harrison 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  14 +-
>  drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
>  drivers/gpu/drm/i915/gt/intel_gt.c   |  11 ++
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 186 +++
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  13 ++
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  35 +++-
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|   7 +
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c|  15 ++
>  drivers/gpu/drm/i915/gt/uc/intel_uc.h|   2 +
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
>  13 files changed, 307 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
>  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 92d37cf71e16..1d45a6f451fa 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -206,6 +206,7 @@ i915-y += gt/uc/intel_uc.o \
> gt/uc/intel_huc.o \
> gt/uc/intel_huc_debugfs.o \
> gt/uc/intel_huc_fw.o \
> +   gt/uc/intel_gsc_fw.o \
> gt/uc/intel_gsc_uc.o
>  
>  # graphics system controller (GSC) support
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..f77eb4009aba 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -232,10 +232,22 @@ void i915_gem_resume(struct drm_i915_private *i915)
>* guarantee that the context image is complete. So let's just reset
>* it and start again.
>*/
> - for_each_gt(gt, i915, i)
> + for_each_gt(gt, i915, i) {
>   if (intel_gt_resume(gt))
>   goto err_wedged;
>  
> + /*
> +  * TODO: this is a long operation (up to ~200ms) and we don't
> +  * need to complete it before driver load/resume is done, so it
> +  * should be handled in a separate thread to unlock userspace
> +  * submission. However, there are a couple of other pieces that
> +  * are required for full GSC support that will complicate things
> +  * a bit, and it is easier to move everything to a worker at the
> +  * same time, so keep it here for now.
> +  */
> + intel_uc_init_hw_late(>uc);
> + }
> +
>   ret = lmem_restore(i915, I915_TTM_BACKUP_ALLOW_GPU);
>   GEM_WARN_ON(ret);
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index cbc8b857d5f7..0e24af5efee9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, 
> int reg, u32 value)
>  #define I915_GEM_HWS_MIGRATE (0x42 * sizeof(u32))
>  #define I915_GEM_HWS_PXP 0x60
>  #define I915_GEM_HWS_PXP_ADDR(I915_GEM_HWS_PXP * sizeof(u32))
> +#define I915_GEM_HWS_GSC 0x62
> +#define I915_GEM_HWS_GSC_ADDR(I915_GEM_HWS_GSC * sizeof(u32))
>  #define I915_GEM_HWS_SCRATCH 0x80
>  
>  #define I915_HWS_CSB_BUF0_INDEX  0x10
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index f50ea92910d9..49ebda141266 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -21,6 +21,7 @@
>  #define 

[Intel-gfx] [PATCH v2 4/4] Revert "drm/i915: Improve on suspend / resume time with VT-d enabled"

[Andi Shyti]

This reverts commit 2ef6efa79fecd5e3457b324155d35524d95f2b6b.

Checking the presence if the IRST (Intel Rapid Start Technology)
through the ACPI to decide whether to rebuild or not the GGTT
puts us at the mercy of the boot firmware and we need to
unnecessarily rely on third parties.

Because now we avoid adding scratch pages to the entire GGTT we
don't need this hack anymore.

Signed-off-by: Andi Shyti 
Cc: Thomas Hellström 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 69 ++--
 drivers/gpu/drm/i915/gt/intel_gtt.h  | 24 --
 drivers/gpu/drm/i915/i915_driver.c   | 16 ---
 3 files changed, 13 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 5ccec5c9206d2..9d76a573255f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -26,13 +26,6 @@
 #include "intel_gtt.h"
 #include "gen8_ppgtt.h"
 
-static inline bool suspend_retains_ptes(struct i915_address_space *vm)
-{
-   return GRAPHICS_VER(vm->i915) >= 8 &&
-   !HAS_LMEM(vm->i915) &&
-   vm->is_ggtt;
-}
-
 static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
   unsigned long color,
   u64 *start,
@@ -104,23 +97,6 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
return 0;
 }
 
-/*
- * Return the value of the last GGTT pte cast to an u64, if
- * the system is supposed to retain ptes across resume. 0 otherwise.
- */
-static u64 read_last_pte(struct i915_address_space *vm)
-{
-   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
-   gen8_pte_t __iomem *ptep;
-
-   if (!suspend_retains_ptes(vm))
-   return 0;
-
-   GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
-   ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
-   return readq(ptep);
-}
-
 /**
  * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
  * @vm: The VM to suspend the mappings for
@@ -184,10 +160,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
i915_gem_object_unlock(obj);
}
 
-   if (!suspend_retains_ptes(vm))
-   vm->clear_range(vm, 0, vm->total);
-   else
-   i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
+   vm->clear_range(vm, 0, vm->total);
 
vm->skip_pte_rewrite = save_skip_rewrite;
 
@@ -536,8 +509,6 @@ static int init_ggtt(struct i915_ggtt *ggtt)
struct drm_mm_node *entry;
int ret;
 
-   ggtt->pte_lost = true;
-
/*
 * GuC requires all resources that we're sharing with it to be placed in
 * non-WOPCM memory. If GuC is not present or not in use we still need a
@@ -1236,20 +1207,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
 {
struct i915_vma *vma;
bool write_domain_objs = false;
-   bool retained_ptes;
 
drm_WARN_ON(>i915->drm, !vm->is_ggtt && !vm->is_dpt);
 
-   /*
-* First fill our portion of the GTT with scratch pages if
-* they were not retained across suspend.
-*/
-   retained_ptes = suspend_retains_ptes(vm) &&
-   !i915_vm_to_ggtt(vm)->pte_lost &&
-   !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte != 
read_last_pte(vm));
-
-   if (!retained_ptes)
-   vm->clear_range(vm, 0, vm->total);
+   /* First fill our portion of the GTT with scratch pages */
+   vm->clear_range(vm, 0, vm->total);
 
/* clflush objects bound into the GGTT and rebind them. */
list_for_each_entry(vma, >bound_list, vm_link) {
@@ -1258,16 +1220,16 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
atomic_read(>flags) & I915_VMA_BIND_MASK;
 
GEM_BUG_ON(!was_bound);
-   if (!retained_ptes) {
-   /*
-* Clear the bound flags of the vma resource to allow
-* ptes to be repopulated.
-*/
-   vma->resource->bound_flags = 0;
-   vma->ops->bind_vma(vm, NULL, vma->resource,
-  obj ? obj->cache_level : 0,
-  was_bound);
-   }
+
+   /*
+* Clear the bound flags of the vma resource to allow
+* ptes to be repopulated.
+*/
+   vma->resource->bound_flags = 0;
+   vma->ops->bind_vma(vm, NULL, vma->resource,
+  obj ? obj->cache_level : 0,
+  was_bound);
+
if (obj) { /* only used during resume => exclusive access */
write_domain_objs |= fetch_and_zero(>write_domain);
obj->read_domains |= I915_GEM_DOMAIN_GTT;
@@ -1295,8 +1257,3 @@ 

[Intel-gfx] [PATCH v2 3/4] drm/i915: Refine VT-d scanout workaround

[Andi Shyti]

From: Chris Wilson 

VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.

If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.

Signed-off-by: Chris Wilson 
Signed-off-by: Tejas Upadhyay 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
 drivers/gpu/drm/i915/gt/intel_ggtt.c   | 25 +-
 drivers/gpu/drm/i915/i915_vma.c|  9 
 3 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce6800..882b91519f92b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -17,6 +17,8 @@
 #include "i915_gem_object.h"
 #include "i915_vma.h"
 
+#define VTD_GUARD (168u * I915_GTT_PAGE_SIZE) /* 168 or tile-row PTE padding */
+
 static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -424,6 +426,17 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
 
+   /* VT-d may overfetch before/after the vma, so pad with scratch */
+   if (intel_scanout_needs_vtd_wa(i915)) {
+   unsigned int guard = VTD_GUARD;
+
+   if (i915_gem_object_is_tiled(obj))
+   guard = max(guard,
+   i915_gem_object_get_tile_row_size(obj));
+
+   flags |= PIN_OFFSET_GUARD | guard;
+   }
+
/*
 * As the user may map the buffer once pinned in the display plane
 * (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 133710258eae6..5ccec5c9206d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -367,27 +367,6 @@ static void nop_clear_range(struct i915_address_space *vm,
 {
 }
 
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
-   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
-   unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
-   unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
-   const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
-   gen8_pte_t __iomem *gtt_base =
-   (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
-   const int max_entries = ggtt_total_entries(ggtt) - first_entry;
-   int i;
-
-   if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
-   num_entries = max_entries;
-
-   for (i = 0; i < num_entries; i++)
-   gen8_set_pte(_base[i], scratch_pte);
-}
-
 static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
 {
/*
@@ -959,8 +938,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
-   if (intel_scanout_needs_vtd_wa(i915))
-   ggtt->vm.clear_range = gen8_ggtt_clear_range;
 
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
 
@@ -1121,7 +1098,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
ggtt->vm.clear_range = nop_clear_range;
-   if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+   if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 457e35e03895f..840c7daf8bb70 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -677,6 +677,10 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
i915_vma_offset(vma) != (flags & PIN_OFFSET_MASK))
return true;
 
+   if (flags & PIN_OFFSET_GUARD &&
+   

[Intel-gfx] [PATCH v2 2/4] drm/i915: Introduce guard pages to i915_vma

[Andi Shyti]

From: Chris Wilson 

Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that surround
our object.

The biggest connundrum is how exactly to mix requesting a fixed address
with guard pages, particularly through the existing uABI. The user does
not know about guard pages, so such must be transparent to the user, and
so the execobj.offset must be that of the object itself excluding the
guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages.
The caveat is that some placements will be impossible with guard pages,
as wrap arounds need to be avoided, and the vma itself will require a
larger node. We must not report EINVAL but ENOSPC as these are unavailable
locations within the GTT rather than conflicting user requirements.

In the next patch, we start using guard pages for scanout objects. While
these are limited to GGTT vma, on a few platforms these vma (or at least
an alias of the vma) is shared with userspace, so we may leak the
existence of such guards if we are not careful to ensure that the
execobj.offset is transparent and excludes the guards. (On such platforms
like ivb, without full-ppgtt, userspace has to use relocations so the
presence of more untouchable regions within its GTT such be of no further
issue.)

Signed-off-by: Chris Wilson 
Signed-off-by: Tejas Upadhyay 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  3 ++-
 drivers/gpu/drm/i915/i915_vma.c  | 27 ++--
 drivers/gpu/drm/i915/i915_vma.h  |  5 +++--
 drivers/gpu/drm/i915/i915_vma_resource.c |  4 ++--
 drivers/gpu/drm/i915/i915_vma_resource.h |  7 +-
 drivers/gpu/drm/i915/i915_vma_types.h|  3 ++-
 7 files changed, 46 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 8145851ad23d5..133710258eae6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -287,8 +287,11 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
 
gte = (gen8_pte_t __iomem *)ggtt->gsm;
-   gte += vma_res->start / I915_GTT_PAGE_SIZE;
-   end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE;
+   gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE;
+   end = gte + vma_res->guard / I915_GTT_PAGE_SIZE;
+   while (gte < end)
+   gen8_set_pte(gte++, vm->scratch[0]->encode);
+   end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE;
 
for_each_sgt_daddr(addr, iter, vma_res->bi.pages)
gen8_set_pte(gte++, pte_encode | addr);
@@ -338,9 +341,12 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
dma_addr_t addr;
 
gte = (gen6_pte_t __iomem *)ggtt->gsm;
-   gte += vma_res->start / I915_GTT_PAGE_SIZE;
-   end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE;
+   gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE;
 
+   end = gte + vma_res->guard / I915_GTT_PAGE_SIZE;
+   while (gte < end)
+   iowrite32(vm->scratch[0]->encode, gte++);
+   end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma_res->bi.pages)
iowrite32(vm->pte_encode(addr, level, flags), gte++);
GEM_BUG_ON(gte > end);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8c2f57eb5ddaa..2434197830523 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 #define PIN_HIGH   BIT_ULL(5)
 #define PIN_OFFSET_BIASBIT_ULL(6)
 #define PIN_OFFSET_FIXED   BIT_ULL(7)
-#define PIN_VALIDATE   BIT_ULL(8) /* validate placement only, no need 
to call unpin() */
+#define PIN_OFFSET_GUARD   BIT_ULL(8)
+#define PIN_VALIDATE   BIT_ULL(9) /* validate placement only, no need 
to call unpin() */
 
 #define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */
 #define PIN_USER   BIT_ULL(11) /* I915_VMA_LOCAL_BIND */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 2232118babeb3..457e35e03895f 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -419,7 +419,7 @@ i915_vma_resource_init_from_vma(struct i915_vma_resource 
*vma_res,
   obj->mm.rsgt, i915_gem_object_is_readonly(obj),
   i915_gem_object_is_lmem(obj), obj->mm.region,
   vma->ops, vma->private, __i915_vma_offset(vma),
-

[Intel-gfx] [PATCH v2 1/4] drm/i915: Wrap all access to i915_vma.node.start|size

[Andi Shyti]

From: Chris Wilson 

We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.

The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.

Signed-off-by: Chris Wilson 
Signed-off-by: Tejas Upadhyay 
Co-developed-by: Thomas Hellström 
Signed-off-by: Thomas Hellström 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++--
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c|  4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../i915/gem/selftests/i915_gem_client_blt.c  | 23 +
 .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++---
 .../drm/i915/gem/selftests/i915_gem_mman.c|  2 +-
 .../drm/i915/gem/selftests/igt_gem_utils.c|  7 +--
 drivers/gpu/drm/i915/gt/gen7_renderclear.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  3 +-
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |  2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |  8 +--
 drivers/gpu/drm/i915/gt/selftest_execlists.c  | 18 +++
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  | 15 +++---
 drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 +++---
 .../drm/i915/gt/selftest_ring_submission.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++---
 .../gpu/drm/i915/gt/selftest_workarounds.c|  8 +--
 drivers/gpu/drm/i915/i915_cmd_parser.c|  4 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_perf.c  |  2 +-
 drivers/gpu/drm/i915/i915_vma.c   | 25 -
 drivers/gpu/drm/i915/i915_vma.h   | 51 +--
 drivers/gpu/drm/i915/i915_vma_resource.h  | 10 ++--
 drivers/gpu/drm/i915/selftests/i915_request.c | 20 
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |  8 +--
 29 files changed, 180 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 5575d7abdc092..03ed4607a46d2 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -286,7 +286,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
 
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
-   (unsigned long)(ggtt->gmadr.start + vma->node.start);
+   (unsigned long)(ggtt->gmadr.start + 
i915_ggtt_offset(vma));
info->fix.smem_len = vma->size;
}
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 29e9e8d5b6fec..86956b902c978 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -379,22 +379,25 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 
*entry,
 const struct i915_vma *vma,
 unsigned int flags)
 {
-   if (vma->node.size < entry->pad_to_size)
+   const u64 start = i915_vma_offset(vma);
+   const u64 size = i915_vma_size(vma);
+
+   if (size < entry->pad_to_size)
return true;
 
-   if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
+   if (entry->alignment && !IS_ALIGNED(start, entry->alignment))
return true;
 
if (flags & EXEC_OBJECT_PINNED &&
-   vma->node.start != entry->offset)
+   start != entry->offset)
return true;
 
if (flags & __EXEC_OBJECT_NEEDS_BIAS &&
-   vma->node.start < BATCH_OFFSET_BIAS)
+   start < BATCH_OFFSET_BIAS)
return true;
 
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
-   (vma->node.start + vma->node.size + 4095) >> 32)
+   (start + size + 4095) >> 32)
return true;
 
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
@@ -440,7 +443,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
int err;
 
if (vma->node.size)
-   pin_flags = vma->node.start;
+   pin_flags =  __i915_vma_offset(vma);
else
pin_flags = entry->offset & PIN_OFFSET_MASK;
 
@@ -663,8 +666,8 @@ static int 

[Intel-gfx] [PATCH v2 0/4] Add guard padding around i915_vma

[Andi Shyti]

Hi,

This series adds guards around vma's but setting a pages at the
beginning and at the end that work as padding.

The first user of the vma guard are scanout objects which don't
need anymore to add scratch to all the unused ggtt's and speeding
up up considerably the boot and resume by several hundreds of
milliseconds up to over a full second in slower machines.

Because of this we don't need anymore 2ef6efa79fec ("drm/i915:
Improve on suspend / resume time with VT-d enabled") which gets
reverted.

Changelog
=
v1 -> v2:
 - Revert 2ef6efa79fec ("drm/i915: Improve on suspend / resume
   time with VT-d enabled") 

Andi

Andi Shyti (1):
  Revert "drm/i915: Improve on suspend / resume time with VT-d enabled"

Chris Wilson (3):
  drm/i915: Wrap all access to i915_vma.node.start|size
  drm/i915: Introduce guard pages to i915_vma
  drm/i915: Refine VT-d scanout workaround

 drivers/gpu/drm/i915/display/intel_fbdev.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  13 +++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  33 +++---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c|   4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   2 +-
 .../i915/gem/selftests/i915_gem_client_blt.c  |  23 ++--
 .../drm/i915/gem/selftests/i915_gem_context.c |  15 ++-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   2 +-
 .../drm/i915/gem/selftests/igt_gem_utils.c|   7 +-
 drivers/gpu/drm/i915/gt/gen7_renderclear.c|   2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 108 --
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |   3 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  24 
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |   2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   2 +-
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |   8 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |  18 +--
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  15 +--
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  16 +--
 .../drm/i915/gt/selftest_ring_submission.c|   2 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c|  12 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|   8 +-
 drivers/gpu/drm/i915/i915_cmd_parser.c|   4 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   2 +-
 drivers/gpu/drm/i915/i915_driver.c|  16 ---
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +-
 drivers/gpu/drm/i915/i915_perf.c  |   2 +-
 drivers/gpu/drm/i915/i915_vma.c   |  59 +++---
 drivers/gpu/drm/i915/i915_vma.h   |  52 -
 drivers/gpu/drm/i915/i915_vma_resource.c  |   4 +-
 drivers/gpu/drm/i915/i915_vma_resource.h  |  17 ++-
 drivers/gpu/drm/i915/i915_vma_types.h |   3 +-
 drivers/gpu/drm/i915/selftests/i915_request.c |  20 ++--
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |   8 +-
 36 files changed, 259 insertions(+), 256 deletions(-)

-- 
2.38.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: Update DG2 DMC version to v2.08 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: Update DG2 DMC version to v2.08 (rev2)
URL   : https://patchwork.freedesktop.org/series/64/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12418 -> Patchwork_64v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/index.html

Participating hosts (33 -> 32)
--

  Missing(1): fi-hsw-4770 

Known issues


  Here are the changes found in Patchwork_64v2 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}:   [DMESG-WARN][1] ([i915#6434]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][3] ([i915#6471]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@hangcheck:
- {bat-adlm-1}:   [INCOMPLETE][5] ([i915#4983]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12418/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6471]: https://gitlab.freedesktop.org/drm/intel/issues/6471
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346


Build changes
-

  * Linux: CI_DRM_12418 -> Patchwork_64v2

  CI-20190529: 20190529
  CI_DRM_12418: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7071: 0801475083ccb938b1d3b358502ff97fdb435585 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_64v2: 22789b788bcaf35826550836b0ad6872d6e85ca6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

e2ce3d2a3646 drm/i915/dmc: Update DG2 DMC version to v2.08

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_64v2/index.html

[Intel-gfx] ✗ Fi.CI.BUILD: failure for docs: updated rules for topic/core-for-CI commit management

[Patchwork]

== Series Details ==

Series: docs: updated rules for topic/core-for-CI commit management
URL   : https://patchwork.freedesktop.org/series/98/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/98/revisions/1/mbox/ not 
applied
Applying: docs: updated rules for topic/core-for-CI commit management
error: sha1 information is lacking or useless (drm-tip.rst).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 docs: updated rules for topic/core-for-CI commit management
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [PATCH 2/6] drm/i915/gsc: Skip the version check when fetching the GSC FW

[Rodrigo Vivi]

On Mon, Nov 21, 2022 at 03:16:13PM -0800, Daniele Ceraolo Spurio wrote:
> The current exectation from the FW side is that the driver will query
> the GSC FW version after the FW is loaded, similarly to what the mei
> driver does on DG2. However, we're discussing with the FW team if there
> is a way to extract the version from the bin file before loading, so we
> can keep the code the same as for older FWs.
> 
> Since the GSC FW version is not currently required for functionality and
> is only needed for debug purposes, we can skip the FW version for now at
> fetch time and add it later on when we've agreed on the approach.
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> Cc: John Harrison 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 29 +++-
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index 5b2e4503aee7..3df52fd59edc 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -564,6 +564,26 @@ static int check_ccs_header(struct intel_gt *gt,
>   return 0;
>  }
>  
> +static int check_fw_header(struct intel_gt *gt,
> +const struct firmware *fw,
> +struct intel_uc_fw *uc_fw)
> +{
> + int err = 0;
> +
> + /* GSC FW version is queried after the FW is loaded */
> + if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
> + return 0;
> +
> + if (uc_fw->loaded_via_gsc)
> + err = check_gsc_manifest(fw, uc_fw);
> + else
> + err = check_ccs_header(gt, fw, uc_fw);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
>  /**
>   * intel_uc_fw_fetch - fetch uC firmware
>   * @uc_fw: uC firmware
> @@ -633,14 +653,11 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
>   if (err)
>   goto fail;
>  
> - if (uc_fw->loaded_via_gsc)
> - err = check_gsc_manifest(fw, uc_fw);
> - else
> - err = check_ccs_header(gt, fw, uc_fw);
> + err = check_fw_header(gt, fw, uc_fw);
>   if (err)
>   goto fail;
>  
> - if (uc_fw->file_wanted.major_ver) {
> + if (uc_fw->file_wanted.major_ver && uc_fw->file_selected.major_ver) {
>   /* Check the file's major version was as it claimed */
>   if (uc_fw->file_selected.major_ver != 
> uc_fw->file_wanted.major_ver) {
>   drm_notice(>drm, "%s firmware %s: unexpected 
> version: %u.%u != %u.%u\n",
> @@ -657,7 +674,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
>   }
>   }
>  
> - if (old_ver) {
> + if (old_ver && uc_fw->file_selected.major_ver) {
>   /* Preserve the version that was really wanted */
>   memcpy(_fw->file_wanted, _ideal, 
> sizeof(uc_fw->file_wanted));
>  
> -- 
> 2.37.3
> 

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT

[Teres Alexis, Alan Previn]

On Tue, 2022-11-22 at 12:57 -0500, Vivi, Rodrigo wrote:
> 
> 
[Alan:snip]

> As I had told I don't have a strong preference, as long as it keep clean
> and without these many helpers of something "on_gt"...
> 
> If this stays inside the gt, just make sure that you call for all the gts,
> but then you inside the functions you can skip if pxp not enabled... without
> asking if enabled on_gt... 
> 
I think we have here conflicting requests. The "consumers" of pxp feature are 
gem-execbuf, gem-context, gem-create (and
even display, for checking). Are we okay with making these callers be aware of 
"if mtl, ensure i call intel_pxp_foo with
the media-tile's pxp, agnostic to the request, context or buffer i am dealing 
with now". If you are okay with this, then
we can make this stay inside gt without "enabled on_gt" functions. But if dont 
want to polute such low level backend
awareness into those upper layers, we need them to call something more global 
like "intel_gpu_has_pxp_enabled" or
"intel_gpu_has_pxp_started" at the least with an i915 param. So that these 
callers dont need to worry about it. Or
intel_pxp_enabled has to internally check with gt we are being passed with and 
verify we are on the correct gt to - but
you said you dont want to have an "enabled on_gt" inside the pxp folder since 
pxp is a subset of gt. The only thing i
can think of is just a rename  - i.e. instead of "intel_pxp_enabled_on_gt", 
have a "intel_gpu_has_pxp_enabled(i915)" -
but it would reside in the pxp folder. Would this work?

> > 
> > ...alan

Re: [Intel-gfx] [PATCH v3 1/4] i915: Move list_count() to list.h for broader use

[kernel test robot]

Hi Andy,

I love your patch! Yet something to improve:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on usb/usb-next usb/usb-linus drm-intel/for-linux-next 
drm-intel/for-linux-next-fixes linus/master v6.1-rc6 next-20221122]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/i915-Move-list_count-to-list-h-for-broader-use/20221122-233657
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
patch link:
https://lore.kernel.org/r/20221122153516.52577-1-andriy.shevchenko%40linux.intel.com
patch subject: [PATCH v3 1/4] i915: Move list_count() to list.h for broader use
config: s390-defconfig
compiler: s390-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/3d217ef769536f160f5c20224aeb0f9070bdfdcf
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Andy-Shevchenko/i915-Move-list_count-to-list-h-for-broader-use/20221122-233657
git checkout 3d217ef769536f160f5c20224aeb0f9070bdfdcf
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=s390 prepare

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   scripts/genksyms/parse.y: warning: 9 shift/reduce conflicts [-Wconflicts-sr]
   scripts/genksyms/parse.y: warning: 5 reduce/reduce conflicts [-Wconflicts-rr]
   scripts/genksyms/parse.y: note: rerun with option '-Wcounterexamples' to 
generate conflict counterexamples
   In file included from include/linux/preempt.h:11,
from include/linux/percpu.h:6,
from include/linux/context_tracking_state.h:5,
from include/linux/hardirq.h:5,
from include/linux/kvm_host.h:7,
from arch/s390/kernel/asm-offsets.c:11:
   include/linux/list.h:662:8: warning: no previous prototype for 'list_count' 
[-Wmissing-prototypes]
 662 | size_t list_count(struct list_head *head)
 |^~
   In file included from include/linux/preempt.h:11,
from arch/s390/include/asm/timex.h:13,
from arch/s390/kernel/vdso64/getcpu.c:6:
   include/linux/list.h:662:8: warning: no previous prototype for 'list_count' 
[-Wmissing-prototypes]
 662 | size_t list_count(struct list_head *head)
 |^~
   In file included from include/linux/rculist.h:10,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from arch/s390/include/asm/syscall.h:13,
from arch/s390/include/asm/vdso/gettimeofday.h:9,
from include/vdso/datapage.h:137,
from 
arch/s390/kernel/vdso64/../../../../lib/vdso/gettimeofday.c:5,
from arch/s390/kernel/vdso64/vdso64_generic.c:2:
   include/linux/list.h:662:8: warning: no previous prototype for 'list_count' 
[-Wmissing-prototypes]
 662 | size_t list_count(struct list_head *head)
 |^~
   s390-linux-ld: arch/s390/kernel/vdso64/getcpu.o: in function `list_count':
>> include/linux/list.h:663: multiple definition of `list_count'; 
>> arch/s390/kernel/vdso64/vdso64_generic.o:include/linux/list.h:663: first 
>> defined here
   make[2]: *** [arch/s390/kernel/vdso64/Makefile:50: 
arch/s390/kernel/vdso64/vdso64.so.dbg] Error 1
   make[2]: Target 'include/generated/vdso64-offsets.h' not remade because of 
errors.
   make[1]: *** [arch/s390/Makefile:159: vdso_prepare] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:231: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +663 include/linux/list.h

   557  
   558  /**
   559   * list_next_entry - get the next element in list
   560   * @pos:the type * to cursor
   561   * @member: the name of the list_head within the struct.
   562   */
   563  #define list_next_entry(pos, member) \
   564  list_entry((pos)->member.next, typeof(*(pos)), member)
   565  
   566  /**
   567   * list_next_entry_circular - get the next element in list
   568   * @pos:the type * to cursor.
   569   * @head:   the list head to take the element from.
   570   * @member: the name of the list_head within the struct.
   571   *
   572   * Wraparound if pos is the last element (return 

[Intel-gfx] [PATCH v3 1/2] drm/i915/dg2: Introduce Wa_18018764978

[Matt Atwood]

Wa_18018764978 applies to specific steppings of DG2 (G10 C0+,
G11 and G12 A0+). Clean up style in function at the same time.

Bspec: 66622

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 80a979e6f6bec..74379d3c5a4de 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -457,6 +457,9 @@
 #define GEN8_L3CNTLREG _MMIO(0x7034)
 #define   GEN8_ERRDETBCTRL (1 << 9)
 
+#define PSS_MODE2  _MMIO(0x703c)
+#define   SCOREBOARD_STALL_FLUSH_CONTROL   REG_BIT(5)
+
 #define GEN7_SC_INSTDONE   _MMIO(0x7100)
 #define GEN12_SC_INSTDONE_EXTRA_MMIO(0x7104)
 #define GEN12_SC_INSTDONE_EXTRA2   _MMIO(0x7108)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 2afb4f80a954d..ce2be9470c36c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -771,8 +771,13 @@ static void dg2_ctx_workarounds_init(struct 
intel_engine_cs *engine,
 
/* Wa_14014947963:dg2 */
if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_B0, STEP_FOREVER) ||
-   IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915))
-   wa_masked_field_set(wal, VF_PREEMPTION, 
PREEMPTION_VERTEX_COUNT, 0x4000);
+IS_DG2_G11(engine->i915) || 
IS_DG2_G12(engine->i915))
+wa_masked_field_set(wal, VF_PREEMPTION, 
PREEMPTION_VERTEX_COUNT, 0x4000);
+
+   /* Wa_18018764978:dg2 */
+   if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_C0, STEP_FOREVER) ||
+IS_DG2_G11(engine->i915) || 
IS_DG2_G12(engine->i915))
+wa_masked_en(wal, PSS_MODE2, 
SCOREBOARD_STALL_FLUSH_CONTROL);
 
/* Wa_15010599737:dg2 */
wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
-- 
2.38.1