Re: [Intel-gfx] [PATCH] drm/i915/psr: Add continuous full frame bit together with single

[Hogander, Jouni]

Hello Jose,

Thank you for your comments. Please see my responses below and check
the new version I have sent.

On Tue, 2022-11-29 at 19:46 +0200, Jouni Högander wrote:
> On Tue, 2022-11-29 at 14:00 +, Souza, Jose wrote:
> > On Tue, 2022-11-29 at 09:51 +0200, Jouni Högander wrote:
> > > Currently we are observing occasionally display flickering or
> > > complete
> > > freeze. This is narrowed down to be caused by single full frame
> > > update
> > > (SFF).
> > > 
> > > SFF bit after it's written gets cleared by HW in subsequent
> > > vblank
> > > i.e. when the update is sent to the panel. SFF bit is required to
> > > be
> > > written together with partial frame update (PFU) bit. After the
> > > SFF
> > > bit gets cleared by the HW psr2 man trk ctl register still
> > > contains
> > > PFU bit. If there is subsequent update for any reason we will end
> > > up
> > > having selective update/fetch configuration where start line is 0
> > > and
> > > end line is 0.
> > > 
> > 
> > How did you get this information(start and end line 0)?
> 
> If you consider what is written into psr2 man trk ctl register in
> case
> of full frame update in intel_psr2_program_trans_man_trk_ctl and in 
> _psr_flush_handle:
> 
> SFF = 1
> PFU = 1
> Start line = 0
> End line = 0 
> 
> On next vblank SFF is cleared by the hw. After that we have:
> 
> PFU = 1
> Start line = 0
> End line = 0
> 
> which is basically selective update with start and endline as 0. If
> there is an update with this configration we are observing
> freeze/flicker. I can use CFF instead of SFF as a workaround. I also
> checked that configuring start and end lines as a full frame is also
> fixing the issue. I choose to come out with the first one.
> 
> > 
> > >  Also selective fetch configuration for the planes is
> > > not properly performed. This seems to be causing problems with
> > > some
> > > panels.
> > > 
> > > Using CFF without SFF doesn't work either because it may happen
> > > that
> > > psr2 man track ctl register is overwritten by next update before
> > > vblank triggers sending the update. This is causing problems to
> > > psr_invalidate/flush. Using CFF and SFF together solves the
> > > problems
> > > as SFF is cleared only by HW in subsequent vblank.
> > 
> > This looks dangerous, have you checked with HW engineers if setting
> > both could cause any issue?
> 
> Yes, this make sense, I will check this.

I got confirmation from HW folks:

"There are no restrictions on setting both bits simultaneously (HW
simply OR's the two bits together)."

> 
> > At the SFF write you could get what is the current vblank counter
> > and
> > properly handle future PSR2_MAN_TRK_CTL writes.
> 
> Is vblank counter updated with that granularity? E.g. if you have
> psr_invalidate/psr_flush sequence there is an update, but vblank
> interrupts are not enabled? In legacy cursor update there is also an
> update without vblank interrupts getting enabled. How vblank counter
> works when vblank interrupt is disabled?
> 

I did experiments with vblank counter. It could be actually possible to
to use it, but to my opinion new strategy keeping CFF bit enabled
unless there is a selective update is much simpler. It solves this
problem, takes care of current flickering/freeze issue and also takes
care of HSD 14014971508.

> > 
> > > 
> > > Fix the flickering/freeze issue by adding continuous full frame
> > > with
> > > single full frame update and switch to partial frame update only
> > > when
> > > selective update area is properly calculated and configured.
> > > 
> > > This is also workaround for HSD 14014971508
> > 
> > Please use versions in your patches, you had 2 patches in the
> > previous approach with the same subject but no versioning and no
> > information about what
> > changed between versions.
> 
> First one was sent to trybot and then to intel-gfx. In this one I
> changed the subject. So I was thinking it's ok to leave out
> versioning.
> I will add versioning when sending again.
> 
> > 
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: José Roberto de Souza 
> > > Cc: Mika Kahola 
> > > 
> > > Reported-by: Lee Shawn C 
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 19 ++
> > > -
> > >  1 file changed, 10 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 5b678916e6db..88388201684e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1510,7 +1510,8 @@ static void
> > > psr_force_hw_tracking_exit(struct
> > > intel_dp *intel_dp)
> > >    PSR2_MAN_TRK_CTL(intel_dp-
> > > > psr.transcoder),
> > >   
> > > man_trk_ctl_enable_bit_get(dev_priv)
> > > > 
> > >   
> > > man_trk_ctl_partial_frame_bit_get(dev_priv) |
> > > - 
> > > 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: wait on timeout before retry include sw delay (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: wait on timeout before retry include sw delay (rev2)
URL   : https://patchwork.freedesktop.org/series/111303/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12457 -> Patchwork_111303v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 36)
--

  Additional (1): bat-atsm-1 
  Missing(3): bat-rpls-1 fi-ilk-m540 fi-kbl-x1275 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-atsm-1}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v2/bat-atsm-1/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [INCOMPLETE][5] ([i915#2940]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v2/fi-ehl-2/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}:   [DMESG-FAIL][7] ([i915#5334] / [i915#7433]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v2/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][9] ([i915#4983]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}:   [DMESG-FAIL][11] ([i915#4258]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v2/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][13] ([i915#4983]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v2/bat-rpls-2/igt@i915_selftest@l...@reset.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_12457/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_111303v2/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#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#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [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#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
  [i915#5334]: 

[Intel-gfx] [PATCH v2] drm/i915/psr: Add continuous full frame bit together with single

[Jouni Högander]

Currently we are observing occasionally display flickering or complete
freeze. This is narrowed down to be caused by single full frame update
(SFF).

SFF bit after it's written gets cleared by HW in subsequent vblank
i.e. when the update is sent to the panel. SFF bit is required to be
written together with partial frame update (PFU) bit. After the SFF
bit gets cleared by the HW psr2 man trk ctl register still contains
PFU bit. If there is subsequent update for any reason we will end up
having selective update/fetch configuration where start line is 0 and
end line is 0. Also selective fetch configuration for the planes is
not properly performed. This seems to be causing problems with some
panels.

Using CFF without SFF doesn't work either because it may happen that
psr2 man track ctl register is overwritten by next update before
vblank triggers sending the update. This is causing problems to
psr_invalidate/flush. Using CFF and SFF together solves the problems
as SFF is cleared only by HW in subsequent vblank and the update gets
sent.

Fix the flickering/freeze issue by keeping CFF bit as set when PSR2 is
enabled unless there is a properly configured selective update via
atomic commit.

v2:
 - Improve commit message and comments
 - No functional changes

This is also workaround for HSD 14014971508

Cc: Ville Syrjälä 
Cc: José Roberto de Souza 
Cc: Mika Kahola 

Reported-by: Lee Shawn C 
Signed-off-by: Jouni Högander 
Tested-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 5b678916e6db..619d532bf322 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1510,7 +1510,8 @@ static void psr_force_hw_tracking_exit(struct intel_dp 
*intel_dp)
   PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
   man_trk_ctl_enable_bit_get(dev_priv) |
   man_trk_ctl_partial_frame_bit_get(dev_priv) |
-  man_trk_ctl_single_full_frame_bit_get(dev_priv));
+  man_trk_ctl_single_full_frame_bit_get(dev_priv) |
+  man_trk_ctl_continuos_full_frame(dev_priv));
 
/*
 * Display WA #0884: skl+
@@ -1624,11 +1625,8 @@ static void psr2_man_trk_ctl_calc(struct 
intel_crtc_state *crtc_state,
val |= man_trk_ctl_partial_frame_bit_get(dev_priv);
 
if (full_update) {
-   /*
-* Not applying Wa_14014971508:adlp as we do not support the
-* feature that requires this workaround.
-*/
val |= man_trk_ctl_single_full_frame_bit_get(dev_priv);
+   val |= man_trk_ctl_continuos_full_frame(dev_priv);
goto exit;
}
 
@@ -2307,12 +2305,15 @@ static void _psr_flush_handle(struct intel_dp *intel_dp)
/* can we turn CFF off? */
if (intel_dp->psr.busy_frontbuffer_bits == 0) {
u32 val = man_trk_ctl_enable_bit_get(dev_priv) |
- 
man_trk_ctl_partial_frame_bit_get(dev_priv) |
- 
man_trk_ctl_single_full_frame_bit_get(dev_priv);
+   
man_trk_ctl_partial_frame_bit_get(dev_priv) |
+   
man_trk_ctl_single_full_frame_bit_get(dev_priv) |
+   
man_trk_ctl_continuos_full_frame(dev_priv);
 
/*
-* turn continuous full frame off and do a 
single
-* full frame
+* Set psr2_sel_fetch_cff_enabled as false to 
allow selective
+* updates. Still keep cff bit enabled as we 
don't have proper
+* SU configuration in case update is sent for 
any reason after
+* sff bit gets cleared by the HW on next 
vblank.
 */
intel_de_write(dev_priv, 
PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
   val);
-- 
2.34.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: wait on timeout before retry include sw delay (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: wait on timeout before retry include sw delay (rev2)
URL   : https://patchwork.freedesktop.org/series/111303/
State : warning

== Summary ==

Error: dim checkpatch failed
7b8a6c674948 drm/i915/dp: Change aux_ctl reg read to polling read
-:35: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#35: FILE: drivers/gpu/drm/i915/display/intel_dp_aux.c:49:
+   msleep(1);

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

[Intel-gfx] [PATCHv2] drm/i915/dp: Change aux_ctl reg read to polling read

[Arun R Murthy]

The busy timeout logic checks for the AUX BUSY, then waits for the
timeout period and then after timeout reads the register for BUSY set
and fails.
Instead replace interrupt with polling so as to read the AUX CTL
register often before the timeout period.

v2: replace interrupt with polling read

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 24 -
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 664bebdecea7..22c0a59850df 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -40,20 +40,24 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
const unsigned int timeout_ms = 10;
u32 status;
-   bool done;
-
-#define C (((status = intel_uncore_read_notrace(>uncore, ch_ctl)) & 
DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
- msecs_to_jiffies_timeout(timeout_ms));
+   int try;
 
+   for (try = 0; try < 10; try++) {
+   status = intel_uncore_read_notrace(>uncore, ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
+   break;
+   msleep(1);
+   }
/* just trace the final value */
trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
 
-   if (!done)
-   drm_err(>drm,
-   "%s: did not complete or timeout within %ums (status 
0x%08x)\n",
-   intel_dp->aux.name, timeout_ms, status);
-#undef C
+   if (try == 3) {
+   status = intel_uncore_read_notrace(>uncore, ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) != 0)
+   drm_err(>drm,
+   "%s: did not complete or timeout within %ums 
(status 0x%08x)\n",
+   intel_dp->aux.name, timeout_ms, status);
+   }
 
return status;
 }
-- 
2.25.1

Re: [Intel-gfx] [PATCH 11/13] Revert "drm/i915: Disable DSB usage for now"

[Nautiyal, Ankit K]

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

This reverts commit 99510e1afb4863a225207146bd988064c5fd0629.

DSB is now getting disabled locally in the color management
code so we don't need to apply this big hammer via the device
info (not that we have other DSB users at the moment).

Signed-off-by: Ville Syrjälä 


LGTM.

Reviewed-by: Ankit Nautiyal 


---
  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 414b4bfd514b..d8f0f512c944 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -889,7 +889,7 @@ static const struct intel_device_info jsl_info = {
TGL_CURSOR_OFFSETS, \
.has_global_mocs = 1, \
.has_pxp = 1, \
-   .display.has_dsb = 0 /* FIXME: LUT load is broken with DSB */
+   .display.has_dsb = 1
  
  static const struct intel_device_info tgl_info = {

GEN12_FEATURES,

Re: [Intel-gfx] [PATCH 10/13] drm/i915: Disable DSB usage specifically for LUTs

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

The DSB has problem loading the LUTs at the moment. Some
of that is due to the palette anti collision logic, some
due to what seem real hw issues. Disable it the whole
thing locally in the color management code for now.

Note that we currently have this weird situation where on
adl+ we load parts of the LUT with DSB and parts with mmio.
That is due to the fact that only some parts of the LUT code
are using the DSB register write functions (ivb_load_lut_ext*()),
while the rest is using pure mmio (bdw_load_lut_10()). So now
we'll go back to pure mmio temporarily, until the DSB issues
get fixed (at which point we should be going for pure DSB).

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 2715f1b617e1..9978d21f1634 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1394,6 +1394,9 @@ void intel_color_prepare_commit(struct intel_crtc_state 
*crtc_state)
  {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
  
+	/* FIXME DSB has issues loading LUTs, disable it for now */

+   return;
+
crtc_state->dsb = intel_dsb_prepare(crtc);
  }
  

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Make DSB lower level

[Nautiyal, Ankit K]

Patch looks good to me.

There are couple of minor nitpicks mentioned inline.

In any case this is:

Reviewed-by: Ankit Nautiyal 

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

We could have many different uses for the DSB(s) during a
single commit, so the current approach of passing the whole
crtc_state to the DSB functions is far too high level. Lower
the abstraction a little bit so each DSB user can decide where
to stick the command buffer/etc.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 17 +++--
  drivers/gpu/drm/i915/display/intel_dsb.c   | 79 ++
  drivers/gpu/drm/i915/display/intel_dsb.h   | 13 ++--
  3 files changed, 55 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 5a8652407f30..2715f1b617e1 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -842,7 +842,7 @@ static void ilk_lut_write(const struct intel_crtc_state 
*crtc_state,
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
  
  	if (crtc_state->dsb)

-   intel_dsb_reg_write(crtc_state, reg, val);
+   intel_dsb_reg_write(crtc_state->dsb, reg, val);
else
intel_de_write_fw(i915, reg, val);
  }
@@ -853,7 +853,7 @@ static void ilk_lut_write_indexed(const struct 
intel_crtc_state *crtc_state,
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
  
  	if (crtc_state->dsb)

-   intel_dsb_indexed_reg_write(crtc_state, reg, val);
+   intel_dsb_indexed_reg_write(crtc_state->dsb, reg, val);
else
intel_de_write_fw(i915, reg, val);
  }
@@ -1273,7 +1273,8 @@ static void icl_load_luts(const struct intel_crtc_state 
*crtc_state)
break;
}
  
-	intel_dsb_commit(crtc_state);

+   if (crtc_state->dsb)
+   intel_dsb_commit(crtc_state->dsb);
  }
  
  static u32 chv_cgm_degamma_ldw(const struct drm_color_lut *color)

@@ -1391,12 +1392,18 @@ void intel_color_commit_arm(const struct 
intel_crtc_state *crtc_state)
  
  void intel_color_prepare_commit(struct intel_crtc_state *crtc_state)

  {
-   intel_dsb_prepare(crtc_state);
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+   crtc_state->dsb = intel_dsb_prepare(crtc);
  }
  
  void intel_color_cleanup_commit(struct intel_crtc_state *crtc_state)

  {
-   intel_dsb_cleanup(crtc_state);
+   if (!crtc_state->dsb)
+   return;
+
+   intel_dsb_cleanup(crtc_state->dsb);
+   crtc_state->dsb = NULL;
  }
  
  static bool intel_can_preload_luts(const struct intel_crtc_state *new_crtc_state)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index b4f0356c2463..ab74bfc89465 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -24,8 +24,10 @@ enum dsb_id {
  
  struct intel_dsb {

enum dsb_id id;
+


Is this extra line required?



u32 *cmd_buf;
struct i915_vma *vma;
+   struct intel_crtc *crtc;
  
  	/*

 * free_pos will point the first free entry position
@@ -113,7 +115,7 @@ static bool intel_dsb_disable_engine(struct 
drm_i915_private *i915,
  /**
   * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
   * increment register.
- * @crtc_state: intel_crtc_state structure
+ * @dsb: DSB context
   * @reg: register address.
   * @val: value.
   *
@@ -123,11 +125,10 @@ static bool intel_dsb_disable_engine(struct 
drm_i915_private *i915,
   * is done through mmio write.
   */
  
-void intel_dsb_indexed_reg_write(const struct intel_crtc_state *crtc_state,

+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
 i915_reg_t reg, u32 val)
  {
-   struct intel_dsb *dsb = crtc_state->dsb;
-   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct intel_crtc *crtc = dsb->crtc;
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 *buf = dsb->cmd_buf;
u32 reg_val;
@@ -195,12 +196,11 @@ void intel_dsb_indexed_reg_write(const struct 
intel_crtc_state *crtc_state,
   * and rest all erroneous condition register programming is done
   * through mmio write.
   */
-void intel_dsb_reg_write(const struct intel_crtc_state *crtc_state,
+void intel_dsb_reg_write(struct intel_dsb *dsb,
 i915_reg_t reg, u32 val)
  {
-   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct intel_crtc *crtc = dsb->crtc;
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_dsb *dsb = crtc_state->dsb;
u32 *buf = dsb->cmd_buf;
  
  	if (drm_WARN_ON(_priv->drm, dsb->free_pos >= DSB_BUF_SIZE)) {

@@ -217,17 +217,14 @@ void intel_dsb_reg_write(const struct 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Align DDI_BUF_CTL Active timeouts with Bspec updates (rev3)

[Patchwork]

== Series Details ==

Series: Align DDI_BUF_CTL Active timeouts with Bspec updates (rev3)
URL   : https://patchwork.freedesktop.org/series/111373/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12457 -> Patchwork_111373v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_111373v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_111373v3, 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_111373v3/index.html

Participating hosts (38 -> 34)
--

  Additional (1): bat-atsm-1 
  Missing(5): fi-ilk-m540 bat-dg1-7 fi-tgl-dsi fi-kbl-x1275 bat-rpls-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@dmabuf:
- fi-glk-dsi: [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-glk-dsi/igt@i915_selftest@l...@dmabuf.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v3/fi-glk-dsi/igt@i915_selftest@l...@dmabuf.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [INCOMPLETE][4] ([i915#2940]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v3/fi-ehl-2/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][6] ([i915#4983]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v3/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}:   [DMESG-FAIL][8] ([i915#4258]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v3/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][10] ([i915#4983]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v3/bat-rpls-2/igt@i915_selftest@l...@reset.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_12457/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_111373v3/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#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#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [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#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#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#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: 

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Move the DSB->mmio fallback into the LUT code

[Nautiyal, Ankit K]

Makes sense to me.

Reviewed-by: Ankit Nautiyal 


On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

The use of DSB has to be done differently on a case by case basis.
So no way this kind of blind mmio fallback in the guts of the DSB
code will work properly. Move it at least one level up into the
LUT loading code. Not sure if this is the way we want do the
DSB vs. mmio handling in the end, but at least it's a bit
closer than what we had before. 

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 94 ++
  drivers/gpu/drm/i915/display/intel_dsb.c   | 18 +
  2 files changed, 62 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index bd7e781d9d07..5a4f794e1d08 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -836,6 +836,28 @@ static void i965_load_luts(const struct intel_crtc_state 
*crtc_state)
}
  }
  
+static void ilk_lut_write(const struct intel_crtc_state *crtc_state,

+ i915_reg_t reg, u32 val)
+{
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+   if (crtc_state->dsb)
+   intel_dsb_reg_write(crtc_state, reg, val);
+   else
+   intel_de_write_fw(i915, reg, val);
+}
+
+static void ilk_lut_write_indexed(const struct intel_crtc_state *crtc_state,
+ i915_reg_t reg, u32 val)
+{
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+   if (crtc_state->dsb)
+   intel_dsb_indexed_reg_write(crtc_state, reg, val);
+   else
+   intel_de_write_fw(i915, reg, val);
+}
+
  static void ilk_load_lut_8(struct intel_crtc *crtc,
   const struct drm_property_blob *blob)
  {
@@ -958,9 +980,9 @@ static void ivb_load_lut_ext_max(const struct 
intel_crtc_state *crtc_state)
enum pipe pipe = crtc->pipe;
  
  	/* Program the max register to clamp values > 1.0. */

-   intel_dsb_reg_write(crtc_state, PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
-   intel_dsb_reg_write(crtc_state, PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
-   intel_dsb_reg_write(crtc_state, PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
+   ilk_lut_write(crtc_state, PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
+   ilk_lut_write(crtc_state, PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
+   ilk_lut_write(crtc_state, PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
  }
  
  static void glk_load_lut_ext2_max(const struct intel_crtc_state *crtc_state)

@@ -969,9 +991,9 @@ static void glk_load_lut_ext2_max(const struct 
intel_crtc_state *crtc_state)
enum pipe pipe = crtc->pipe;
  
  	/* Program the max register to clamp values > 1.0. */

-   intel_dsb_reg_write(crtc_state, PREC_PAL_EXT2_GC_MAX(pipe, 0), 1 << 16);
-   intel_dsb_reg_write(crtc_state, PREC_PAL_EXT2_GC_MAX(pipe, 1), 1 << 16);
-   intel_dsb_reg_write(crtc_state, PREC_PAL_EXT2_GC_MAX(pipe, 2), 1 << 16);
+   ilk_lut_write(crtc_state, PREC_PAL_EXT2_GC_MAX(pipe, 0), 1 << 16);
+   ilk_lut_write(crtc_state, PREC_PAL_EXT2_GC_MAX(pipe, 1), 1 << 16);
+   ilk_lut_write(crtc_state, PREC_PAL_EXT2_GC_MAX(pipe, 2), 1 << 16);
  }
  
  static void ivb_load_luts(const struct intel_crtc_state *crtc_state)

@@ -1118,9 +1140,9 @@ ivb_load_lut_max(const struct intel_crtc_state 
*crtc_state,
enum pipe pipe = crtc->pipe;
  
  	/* FIXME LUT entries are 16 bit only, so we can prog 0x max */

-   intel_dsb_reg_write(crtc_state, PREC_PAL_GC_MAX(pipe, 0), color->red);
-   intel_dsb_reg_write(crtc_state, PREC_PAL_GC_MAX(pipe, 1), color->green);
-   intel_dsb_reg_write(crtc_state, PREC_PAL_GC_MAX(pipe, 2), color->blue);
+   ilk_lut_write(crtc_state, PREC_PAL_GC_MAX(pipe, 0), color->red);
+   ilk_lut_write(crtc_state, PREC_PAL_GC_MAX(pipe, 1), color->green);
+   ilk_lut_write(crtc_state, PREC_PAL_GC_MAX(pipe, 2), color->blue);
  }
  
  static void

@@ -1139,23 +1161,23 @@ icl_program_gamma_superfine_segment(const struct 
intel_crtc_state *crtc_state)
 * 9 entries, corresponding to values 0, 1/(8 * 128 * 256),
 * 2/(8 * 128 * 256) ... 8/(8 * 128 * 256).
 */
-   intel_dsb_reg_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
-   PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
-   intel_dsb_reg_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
-   PAL_PREC_AUTO_INCREMENT |
-   PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
+   ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
+ PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
+   ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
+ PAL_PREC_AUTO_INCREMENT |
+ PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
  
  	for (i = 0; i < 9; i++) {

const struct 

Re: [Intel-gfx] [PATCH 06/13] drm/i915: Document LUT "max" register precision

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Document the precision of the LUT "max" registers, just
so we don't have to dig through the spec so much.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_reg.h | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 22fb9fd78483..cd0a445814c7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3620,7 +3620,7 @@
  
  #define  _PIPEAGCMAX   0x70010

  #define  _PIPEBGCMAX   0x71010
-#define PIPEGCMAX(pipe, i) _MMIO_PIPE2(pipe, _PIPEAGCMAX + (i) * 4)
+#define PIPEGCMAX(pipe, i) _MMIO_PIPE2(pipe, _PIPEAGCMAX + (i) * 4) /* 
u1.16 */
  
  #define _PIPE_ARB_CTL_A			0x70028 /* icl+ */

  #define PIPE_ARB_CTL(pipe)_MMIO_PIPE2(pipe, _PIPE_ARB_CTL_A)
@@ -5304,7 +5304,7 @@
  
  #define  _PREC_PIPEAGCMAX  0x4d000

  #define  _PREC_PIPEBGCMAX  0x4d010
-#define PREC_PIPEGCMAX(pipe, i)_MMIO(_PIPE(pipe, _PIPEAGCMAX, 
_PIPEBGCMAX) + (i) * 4)
+#define PREC_PIPEGCMAX(pipe, i)_MMIO(_PIPE(pipe, _PIPEAGCMAX, 
_PIPEBGCMAX) + (i) * 4) /* u1.16 */
  
  #define _GAMMA_MODE_A		0x4a480

  #define _GAMMA_MODE_B 0x4ac80
@@ -7551,9 +7551,9 @@ enum skl_power_gate {
  
  #define PREC_PAL_INDEX(pipe)		_MMIO_PIPE(pipe, _PAL_PREC_INDEX_A, _PAL_PREC_INDEX_B)

  #define PREC_PAL_DATA(pipe)   _MMIO_PIPE(pipe, _PAL_PREC_DATA_A, 
_PAL_PREC_DATA_B)
-#define PREC_PAL_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
_PAL_PREC_GC_MAX_B) + (i) * 4)
-#define PREC_PAL_EXT_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
-#define PREC_PAL_EXT2_GC_MAX(pipe, i)  _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT2_GC_MAX_A, _PAL_PREC_EXT2_GC_MAX_B) + (i) * 4)
+#define PREC_PAL_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
_PAL_PREC_GC_MAX_B) + (i) * 4) /* u1.16 */
+#define PREC_PAL_EXT_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4) /* u3.16 */
+#define PREC_PAL_EXT2_GC_MAX(pipe, i)  _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT2_GC_MAX_A, _PAL_PREC_EXT2_GC_MAX_B) + (i) * 4) /* glk+, u3.16 */
  
  #define _PRE_CSC_GAMC_INDEX_A	0x4A484

  #define _PRE_CSC_GAMC_INDEX_B 0x4AC84

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Standardize auto-increment LUT load procedure

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Various gamma units on various platforms have some problems loading
the LUT index and auto-increment bit at the same time. We have to
do this in two steps. The first known case was the glk degamma LUT,
but at least ADL has another known case.

We're not going to suffer too badly from a couple of extra register
writes here, so let's just standardize on this practice for all
auto-increment LUT loads/reads. This way we never have to worry about
this specific issue again. And for good measure always reset the
index back to zero at the end (we already did this in a few places).

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index c960c2aaf328..bd7e781d9d07 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -934,6 +934,8 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
  
+	intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),

+ prec_index);
intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
  PAL_PREC_AUTO_INCREMENT |
  prec_index);
@@ -1138,7 +1140,10 @@ icl_program_gamma_superfine_segment(const struct 
intel_crtc_state *crtc_state)
 * 2/(8 * 128 * 256) ... 8/(8 * 128 * 256).
 */
intel_dsb_reg_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
-   PAL_PREC_AUTO_INCREMENT);
+   PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
+   intel_dsb_reg_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
+   PAL_PREC_AUTO_INCREMENT |
+   PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
  
  	for (i = 0; i < 9; i++) {

const struct drm_color_lut *entry = [i];
@@ -1148,6 +1153,9 @@ icl_program_gamma_superfine_segment(const struct 
intel_crtc_state *crtc_state)
intel_dsb_indexed_reg_write(crtc_state, 
PREC_PAL_MULTI_SEG_DATA(pipe),
ilk_lut_12p4_udw(entry));
}
+
+   intel_dsb_reg_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
+   PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
  }
  
  static void

@@ -1170,6 +1178,8 @@ icl_program_gamma_multi_segment(const struct 
intel_crtc_state *crtc_state)
 * PAL_PREC_INDEX[0] and PAL_PREC_INDEX[1] map to seg2[1],
 * seg2[0] being unused by the hardware.
 */
+   intel_dsb_reg_write(crtc_state, PREC_PAL_INDEX(pipe),
+   PAL_PREC_INDEX_VALUE(0));
intel_dsb_reg_write(crtc_state, PREC_PAL_INDEX(pipe),
PAL_PREC_AUTO_INCREMENT |
PAL_PREC_INDEX_VALUE(0));
@@ -1202,6 +1212,9 @@ icl_program_gamma_multi_segment(const struct 
intel_crtc_state *crtc_state)
ilk_lut_12p4_udw(entry));
}
  
+	intel_dsb_reg_write(crtc_state, PREC_PAL_INDEX(pipe),

+   PAL_PREC_INDEX_VALUE(0));
+
/* The last entry in the LUT is to be programmed in GCMAX */
entry = [256 * 8 * 128];
ivb_load_lut_max(crtc_state, entry);
@@ -2819,6 +2832,8 @@ static struct drm_property_blob *bdw_read_lut_10(struct 
intel_crtc *crtc,
  
  	lut = blob->data;
  
+	intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),

+ prec_index);
intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
  PAL_PREC_AUTO_INCREMENT |
  prec_index);
@@ -2947,6 +2962,8 @@ icl_read_lut_multi_segment(struct intel_crtc *crtc)
  
  	lut = blob->data;
  
+	intel_de_write_fw(i915, PREC_PAL_MULTI_SEG_INDEX(pipe),

+ PAL_PREC_MULTI_SEG_INDEX_VALUE(0));
intel_de_write_fw(i915, PREC_PAL_MULTI_SEG_INDEX(pipe),
  PAL_PREC_MULTI_SEG_AUTO_INCREMENT |
  PAL_PREC_MULTI_SEG_INDEX_VALUE(0));

Re: [Intel-gfx] [PATCH 04/13] drm/i915: Clean up various indexed LUT registers

[Nautiyal, Ankit K]

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Use REG_BIT() & co. for the LUT index registers, and also
use the REG_FIELD_PREP() stuff a bit more consistently when
generating the values for said registers.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 46 +++---
  drivers/gpu/drm/i915/i915_reg.h| 18 +
  2 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 956b221860e6..c960c2aaf328 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -910,7 +910,8 @@ static void ivb_load_lut_10(struct intel_crtc *crtc,
enum pipe pipe = crtc->pipe;
  
  	for (i = 0; i < lut_size; i++) {

-   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe), prec_index++);
+   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
+ prec_index + i);
intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
  ilk_lut_10([i]));
}
@@ -919,7 +920,8 @@ static void ivb_load_lut_10(struct intel_crtc *crtc,
 * Reset the index, otherwise it prevents the legacy palette to be
 * written properly.
 */
-   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe), 0);
+   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
+ PAL_PREC_INDEX_VALUE(0));
  }
  
  /* On BDW+ the index auto increment mode actually works */

@@ -933,7 +935,8 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
enum pipe pipe = crtc->pipe;
  
  	intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),

- prec_index | PAL_PREC_AUTO_INCREMENT);
+ PAL_PREC_AUTO_INCREMENT |
+ prec_index);
  
  	for (i = 0; i < lut_size; i++)

intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
@@ -943,7 +946,8 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
 * Reset the index, otherwise it prevents the legacy palette to be
 * written properly.
 */
-   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe), 0);
+   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
+ PAL_PREC_INDEX_VALUE(0));
  }
  
  static void ivb_load_lut_ext_max(const struct intel_crtc_state *crtc_state)

@@ -1049,9 +1053,11 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state,
 * ignore the index bits, so we need to reset it to index 0
 * separately.
 */
-   intel_de_write_fw(i915, PRE_CSC_GAMC_INDEX(pipe), 0);
intel_de_write_fw(i915, PRE_CSC_GAMC_INDEX(pipe),
- PRE_CSC_GAMC_AUTO_INCREMENT);
+ PRE_CSC_GAMC_INDEX_VALUE(0));
+   intel_de_write_fw(i915, PRE_CSC_GAMC_INDEX(pipe),
+ PRE_CSC_GAMC_AUTO_INCREMENT |
+ PRE_CSC_GAMC_INDEX_VALUE(0));
  
  	for (i = 0; i < lut_size; i++) {

/*
@@ -1165,7 +1171,9 @@ icl_program_gamma_multi_segment(const struct 
intel_crtc_state *crtc_state)
 * seg2[0] being unused by the hardware.
 */
intel_dsb_reg_write(crtc_state, PREC_PAL_INDEX(pipe),
-   PAL_PREC_AUTO_INCREMENT);
+   PAL_PREC_AUTO_INCREMENT |
+   PAL_PREC_INDEX_VALUE(0));
+
for (i = 1; i < 257; i++) {
entry = [i * 8];
intel_dsb_indexed_reg_write(crtc_state, PREC_PAL_DATA(pipe),
@@ -2756,7 +2764,8 @@ static struct drm_property_blob *ivb_read_lut_10(struct 
intel_crtc *crtc,
ilk_lut_10_pack([i], val);
}
  
-	intel_de_write_fw(dev_priv, PREC_PAL_INDEX(pipe), 0);

+   intel_de_write_fw(dev_priv, PREC_PAL_INDEX(pipe),
+ PAL_PREC_INDEX_VALUE(0));
  
  	return blob;

  }
@@ -2811,7 +2820,8 @@ static struct drm_property_blob *bdw_read_lut_10(struct 
intel_crtc *crtc,
lut = blob->data;
  
  	intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),

- prec_index | PAL_PREC_AUTO_INCREMENT);
+ PAL_PREC_AUTO_INCREMENT |
+ prec_index);
  
  	for (i = 0; i < lut_size; i++) {

u32 val = intel_de_read_fw(i915, PREC_PAL_DATA(pipe));
@@ -2819,7 +2829,8 @@ static struct drm_property_blob *bdw_read_lut_10(struct 
intel_crtc *crtc,
ilk_lut_10_pack([i], val);
}
  
-	intel_de_write_fw(i915, PREC_PAL_INDEX(pipe), 0);

+   intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
+ PAL_PREC_INDEX_VALUE(0));
  
  	return blob;

  }
@@ -2876,9 +2887,11 @@ static struct drm_property_blob 
*glk_read_degamma_lut(struct intel_crtc *crtc)
 * ignore the index bits, so we need to reset it to index 0
 * separately.
 */
-   intel_de_write_fw(dev_priv, 

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Clean up GAMMA_MODE defines

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Use REG_BIT() & co. for GAMMA_MODE bits.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_reg.h | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b1c314093737..52d289f55ce1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5309,14 +5309,14 @@
  #define _GAMMA_MODE_A 0x4a480
  #define _GAMMA_MODE_B 0x4ac80
  #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
-#define  PRE_CSC_GAMMA_ENABLE  (1 << 31)
-#define  POST_CSC_GAMMA_ENABLE (1 << 30)
-#define  GAMMA_MODE_MODE_MASK  (3 << 0)
-#define  GAMMA_MODE_MODE_8BIT  (0 << 0)
-#define  GAMMA_MODE_MODE_10BIT (1 << 0)
-#define  GAMMA_MODE_MODE_12BIT (2 << 0)
-#define  GAMMA_MODE_MODE_SPLIT (3 << 0) /* ivb-bdw */
-#define  GAMMA_MODE_MODE_12BIT_MULTI_SEG   (3 << 0) /* icl-tgl */
+#define  PRE_CSC_GAMMA_ENABLE  REG_BIT(31) /* icl+ */
+#define  POST_CSC_GAMMA_ENABLE REG_BIT(30) /* icl+ */
+#define  GAMMA_MODE_MODE_MASK  REG_GENMASK(1, 0)
+#define  GAMMA_MODE_MODE_8BIT  
REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 0)
+#define  GAMMA_MODE_MODE_10BIT 
REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 1)
+#define  GAMMA_MODE_MODE_12BIT 
REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 2)
+#define  GAMMA_MODE_MODE_SPLIT 
REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 3) /* ivb-bdw */
+#define  GAMMA_MODE_MODE_12BIT_MULTI_SEG   
REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 3) /* icl-tgl */
  
  /* Display Internal Timeout Register */

  #define RM_TIMEOUT_MMIO(0x42060)

Re: [Intel-gfx] [PATCH 01/13] drm/i915: Shorten GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED a bit

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 11/23/2022 8:56 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

s/GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED/GAMMA_MODE_MODE_12BIT_MULTI_SEG/
to make this thing slightly shorter.

Also fix up the platform comment while at it.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 10 +-
  drivers/gpu/drm/i915/i915_reg.h|  2 +-
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 842d58da3128..956b221860e6 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1212,7 +1212,7 @@ static void icl_load_luts(const struct intel_crtc_state 
*crtc_state)
case GAMMA_MODE_MODE_8BIT:
ilk_load_lut_8(crtc, post_csc_lut);
break;
-   case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
+   case GAMMA_MODE_MODE_12BIT_MULTI_SEG:
icl_program_gamma_superfine_segment(crtc_state);
icl_program_gamma_multi_segment(crtc_state);
ivb_load_lut_ext_max(crtc_state);
@@ -2091,7 +2091,7 @@ static u32 icl_gamma_mode(const struct intel_crtc_state 
*crtc_state)
else if (DISPLAY_VER(i915) >= 13)
gamma_mode |= GAMMA_MODE_MODE_10BIT;
else
-   gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED;
+   gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEG;
  
  	return gamma_mode;

  }
@@ -2283,7 +2283,7 @@ static int icl_post_csc_lut_precision(const struct 
intel_crtc_state *crtc_state)
return 8;
case GAMMA_MODE_MODE_10BIT:
return 10;
-   case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
+   case GAMMA_MODE_MODE_12BIT_MULTI_SEG:
return 16;
default:
MISSING_CASE(crtc_state->gamma_mode);
@@ -2455,7 +2455,7 @@ static bool icl_lut_equal(const struct intel_crtc_state 
*crtc_state,
  
  	/* hw readout broken except for the super fine segment :( */

if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) ==
-   GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED)
+   GAMMA_MODE_MODE_12BIT_MULTI_SEG)
check_size = 9;
  
  	return intel_lut_equal(blob1, blob2, check_size,

@@ -2971,7 +2971,7 @@ static void icl_read_luts(struct intel_crtc_state 
*crtc_state)
case GAMMA_MODE_MODE_10BIT:
crtc_state->post_csc_lut = bdw_read_lut_10(crtc, 
PAL_PREC_INDEX_VALUE(0));
break;
-   case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
+   case GAMMA_MODE_MODE_12BIT_MULTI_SEG:
crtc_state->post_csc_lut = icl_read_lut_multi_segment(crtc);
break;
default:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b90fe6a28f7..b1c314093737 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5316,7 +5316,7 @@
  #define  GAMMA_MODE_MODE_10BIT(1 << 0)
  #define  GAMMA_MODE_MODE_12BIT(2 << 0)
  #define  GAMMA_MODE_MODE_SPLIT(3 << 0) /* ivb-bdw */
-#define  GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0) /* icl + */
+#define  GAMMA_MODE_MODE_12BIT_MULTI_SEG   (3 << 0) /* icl-tgl */
  
  /* Display Internal Timeout Register */

  #define RM_TIMEOUT_MMIO(0x42060)

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

[Patchwork]

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_12455_full -> Patchwork_111482v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_backlight@fade-with-suspend:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl9/igt@i915_pm_backli...@fade-with-suspend.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-apl:  [PASS][2] -> [DMESG-FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-apl3/igt@i915_selftest@live@gt_heartbeat.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-apl3/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][4] ([i915#4991])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl10/igt@gem_cre...@create-massive.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-iclb2/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-iclb3/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-iclb5/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gen3_render_tiledy_blits:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +82 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl6/igt@gen3_render_tiledy_blits.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#3989] / [i915#454])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-iclb2/igt@i915_pm...@dc6-psr.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-iclb3/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- shard-skl:  [PASS][14] -> [WARN][15] ([i915#1804])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-skl1/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl10/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-skl:  [PASS][16] -> [DMESG-FAIL][17] ([i915#5334])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/shard-skl9/igt@i915_selftest@live@gt_heartbeat.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl6/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl6/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@hdmi-edid-read:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/shard-skl6/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1:
- shard-apl:  [PASS][20] -> [FAIL][21] ([i915#79])
   [20]: 

[Intel-gfx] [PATCH v2 1/2] drm/i915/ddi: Align timeout for DDI_BUF_CTL active with Bspec

[Ankit Nautiyal]

For Gen12+ wait for 1ms for Combo Phy and 3ms for TC Phy for
DDI_BUF_CTL to be active for TC phy. (Bspec:49190)

v2: Minor refactoring for better readability. (Imre)

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5f9a2410fc4c..c916bd3707c2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -185,6 +185,8 @@ void intel_wait_ddi_buf_idle(struct drm_i915_private 
*dev_priv,
 static void intel_wait_ddi_buf_active(struct drm_i915_private *dev_priv,
  enum port port)
 {
+   enum phy phy = intel_port_to_phy(dev_priv, port);
+   int timeout_us;
int ret;
 
/* Wait > 518 usecs for DDI_BUF_CTL to be non idle */
@@ -193,8 +195,19 @@ static void intel_wait_ddi_buf_active(struct 
drm_i915_private *dev_priv,
return;
}
 
+   if (DISPLAY_VER(dev_priv) >= 12) {
+   if (IS_DG2(dev_priv))
+   timeout_us = 1200;
+   else if (intel_phy_is_tc(dev_priv, phy))
+   timeout_us = 3000;
+   else
+   timeout_us = 1000;
+   } else {
+   timeout_us = 500;
+   }
+
ret = _wait_for(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
- DDI_BUF_IS_IDLE), IS_DG2(dev_priv) ? 1200 : 500, 10, 
10);
+ DDI_BUF_IS_IDLE), timeout_us, 10, 10);
 
if (ret)
drm_err(_priv->drm, "Timeout waiting for DDI BUF %c to get 
active\n",
-- 
2.25.1

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/mtl: Update OA mux whitelist for MTL

[Dixit, Ashutosh]

On Wed, 30 Nov 2022 17:05:34 -0800, Umesh Nerlige Ramappa wrote:
>
> 0x20cc (WAIT_FOR_RC6_EXIT on other platforms) is repurposed on MTL. Use
> a separate mux table to verify oa configs passed by user.

> I looked for WAIT_FOR_RC6_EXIT in the bspec and did not find it defined for
> MTL, so it's dropped completely. If you could confirm, that would be great.

Yup looks like it.

Reviewed-by: Ashutosh Dixit 


> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 8ed9af571de9..8369ae4b850d 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4318,6 +4318,17 @@ static const struct i915_range gen12_oa_mux_regs[] = {
>   {}
>  };
>
> +/*
> + * Ref: 14010536224:
> + * 0x20cc is repurposed on MTL, so use a separate array for MTL.
> + */
> +static const struct i915_range mtl_oa_mux_regs[] = {
> + { .start = 0x0d00, .end = 0x0d04 }, /* RPM_CONFIG[0-1] */
> + { .start = 0x0d0c, .end = 0x0d2c }, /* NOA_CONFIG[0-8] */
> + { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
> + { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
> +};
> +
>  static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
>  {
>   return reg_in_range_table(addr, gen7_oa_b_counters);
> @@ -4361,7 +4372,10 @@ static bool xehp_is_valid_b_counter_addr(struct 
> i915_perf *perf, u32 addr)
>
>  static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
>  {
> - return reg_in_range_table(addr, gen12_oa_mux_regs);
> + if (IS_METEORLAKE(perf->i915))
> + return reg_in_range_table(addr, mtl_oa_mux_regs);
> + else
> + return reg_in_range_table(addr, gen12_oa_mux_regs);
>  }
>
>  static u32 mask_reg_value(u32 reg, u32 val)
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs

[Dixit, Ashutosh]

On Wed, 30 Nov 2022 17:05:32 -0800, Umesh Nerlige Ramappa wrote:
>
> On MTL, gt->scratch was using stolen lmem. An MI_SRM to stolen lmem
> caused a hang that was attributed to saving and restoring the GPR
> registers used for noa_wait.
>
> Add an additional page in noa_wait BO to save/restore GPR registers for
> the noa_wait logic.

Mostly copying R-b's from https://patchwork.freedesktop.org/series/111411/ here.

Reviewed-by: Ashutosh Dixit 

>
> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_types.h |  6 --
>  drivers/gpu/drm/i915/i915_perf.c | 25 
>  2 files changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index c1d9cd255e06..13dffe0a3d20 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -296,12 +296,6 @@ enum intel_gt_scratch_field {
>
>   /* 8 bytes */
>   INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
> -
> - /* 6 * 8 bytes */
> - INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR = 2048,
> -
> - /* 4 bytes */
> - INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1 = 2096,
>  };
>
>  #endif /* __INTEL_GT_TYPES_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 00e09bb18b13..7790a88f10d8 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1842,8 +1842,7 @@ static u32 *save_restore_register(struct 
> i915_perf_stream *stream, u32 *cs,
>   for (d = 0; d < dword_count; d++) {
>   *cs++ = cmd;
>   *cs++ = i915_mmio_reg_offset(reg) + 4 * d;
> - *cs++ = intel_gt_scratch_offset(stream->engine->gt,
> - offset) + 4 * d;
> + *cs++ = i915_ggtt_offset(stream->noa_wait) + offset + 4 * d;
>   *cs++ = 0;
>   }
>
> @@ -1876,7 +1875,13 @@ static int alloc_noa_wait(struct i915_perf_stream 
> *stream)
> MI_PREDICATE_RESULT_2_ENGINE(base) :
> 
> MI_PREDICATE_RESULT_1(RENDER_RING_BASE);
>
> - bo = i915_gem_object_create_internal(i915, 4096);
> + /*
> +  * gt->scratch was being used to save/restore the GPR registers, but on
> +  * MTL the scratch uses stolen lmem. An MI_SRM to this memory region
> +  * causes an engine hang. Instead allocate an additional page here to
> +  * save/restore GPR registers
> +  */
> + bo = i915_gem_object_create_internal(i915, 8192);
>   if (IS_ERR(bo)) {
>   drm_err(>drm,
>   "Failed to allocate NOA wait batchbuffer\n");
> @@ -1910,14 +1915,19 @@ static int alloc_noa_wait(struct i915_perf_stream 
> *stream)
>   goto err_unpin;
>   }
>
> + stream->noa_wait = vma;
> +
> +#define GPR_SAVE_OFFSET 4096
> +#define PREDICATE_SAVE_OFFSET 4160
> +
>   /* Save registers. */
>   for (i = 0; i < N_CS_GPR; i++)
>   cs = save_restore_register(
>   stream, cs, true /* save */, CS_GPR(i),
> - INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
> + GPR_SAVE_OFFSET + 8 * i, 2);
>   cs = save_restore_register(
>   stream, cs, true /* save */, mi_predicate_result,
> - INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
> + PREDICATE_SAVE_OFFSET, 1);
>
>   /* First timestamp snapshot location. */
>   ts0 = cs;
> @@ -2033,10 +2043,10 @@ static int alloc_noa_wait(struct i915_perf_stream 
> *stream)
>   for (i = 0; i < N_CS_GPR; i++)
>   cs = save_restore_register(
>   stream, cs, false /* restore */, CS_GPR(i),
> - INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
> + GPR_SAVE_OFFSET + 8 * i, 2);
>   cs = save_restore_register(
>   stream, cs, false /* restore */, mi_predicate_result,
> - INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
> + PREDICATE_SAVE_OFFSET, 1);
>
>   /* And return to the ring. */
>   *cs++ = MI_BATCH_BUFFER_END;
> @@ -2046,7 +2056,6 @@ static int alloc_noa_wait(struct i915_perf_stream 
> *stream)
>   i915_gem_object_flush_map(bo);
>   __i915_gem_object_release_map(bo);
>
> - stream->noa_wait = vma;
>   goto out_ww;
>
>  err_unpin:
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch

[Dixit, Ashutosh]

On Wed, 30 Nov 2022 17:05:33 -0800, Umesh Nerlige Ramappa wrote:
>
> Similar to ACM, OA timestamp that is part of the OA report is shifted
> when compared to the CS timestamp. Add MTL to the WA.

Reviewed-by: Ashutosh Dixit 

>
> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 7790a88f10d8..8ed9af571de9 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -3136,8 +3136,11 @@ get_sseu_config(struct intel_sseu *out_sseu,
>   */
>  u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915)
>  {
> - /* Wa_18013179988:dg2 */
> - if (IS_DG2(i915)) {
> + /*
> +  * Wa_18013179988:dg2
> +  * Wa_14015846243:mtl
> +  */
> + if (IS_DG2(i915) || IS_METEORLAKE(i915)) {
>   intel_wakeref_t wakeref;
>   u32 reg, shift;
>
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

[Dixit, Ashutosh]

On Wed, 30 Nov 2022 17:05:35 -0800, Umesh Nerlige Ramappa wrote:
>
> Without an entry in oa_init_supported_formats, OA will not be functional
> in MTL. Enable OA support by enabling 32 bit OAG formats for MTL.

Reviewed-by: Ashutosh Dixit 

> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 8369ae4b850d..a735b9540113 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4772,6 +4772,7 @@ static void oa_init_supported_formats(struct i915_perf 
> *perf)
>   break;
>
>   case INTEL_DG2:
> + case INTEL_METEORLAKE:
>   oa_format_add(perf, I915_OAR_FORMAT_A32u40_A4u32_B8_C8);
>   oa_format_add(perf, I915_OA_FORMAT_A24u40_A14u32_B8_C8);
>   break;
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/pxp: Invalidate all PXP fw sessions during teardown

[Juston Li]

On Mon, 2022-11-28 at 16:48 -0800, Alan Previn wrote:
> A gap was recently discovered where if an application did not
> invalidate all of the stream keys (intentionally or not), and the
> driver did a full PXP global teardown on the GT subsystem, we
> find that future session creation would fail on the security
> firmware's side of the equation. i915 is the entity that needs
> ensure the sessions' state across both iGT and security firmware
> are at a known clean point when performing a full global teardown.
> 
> Architecturally speaking, i915 should inspect all active sessions
> and submit the invalidate-stream-key PXP command to the security
> firmware for each of them. However, for the upstream i915 driver
> we only support the arbitration session that can be created
> so that will be the only session we will cleanup.
> 
> Signed-off-by: Alan Previn 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  |  1 +
>  .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15 
>  .../i915/pxp/intel_pxp_cmd_interface_cmn.h    |  3 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  5 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 35
> +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h    |  2 ++
>  6 files changed, 61 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 2da309088c6d..bbeb8ed8e211 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -23,6 +23,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
>  void intel_pxp_fini_hw(struct intel_pxp *pxp);
>  
>  void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
> +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> arb_session_id);
>  
>  int intel_pxp_start(struct intel_pxp *pxp);
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> index 739f9072fa5f..26f7d9f01bf3 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> @@ -12,6 +12,9 @@
>  /* PXP-Opcode for Init Session */
>  #define PXP42_CMDID_INIT_SESSION 0x1e
>  
> +/* PXP-Opcode for Invalidate Stream Key */
> +#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
> +
>  /* PXP-Input-Packet: Init Session (Arb-Session) */
>  struct pxp42_create_arb_in {
> struct pxp_cmd_header header;
> @@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
> struct pxp_cmd_header header;
>  } __packed;
>  
> +/* PXP-Input-Packet: Invalidate Stream Key */
> +struct pxp42_inv_stream_key_in {
> +   struct pxp_cmd_header header;
> +   u32 rsvd[3];
> +} __packed;
> +
> +/* PXP-Output-Packet: Invalidate Stream Key */
> +struct pxp42_inv_stream_key_out {
> +   struct pxp_cmd_header header;
> +   u32 rsvd;
> +} __packed;
> +
>  #endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> index c2f23394f9b8..69e34ec49e78 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> @@ -27,6 +27,9 @@ struct pxp_cmd_header {
> union {
> u32 status; /* out */
> u32 stream_id; /* in */
> +#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
> +#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
> +#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
> };
> /* Length of the message (excluding the header) */
> u32 buffer_len;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> index 85572360c71a..8eb886d3f2a0 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> @@ -91,10 +91,13 @@ static int
> pxp_terminate_arb_session_and_global(struct intel_pxp *pxp)
>  {
> int ret;
> struct intel_gt *gt = pxp_to_gt(pxp);
> +   u32 active_sip_slots;
>  
> /* must mark termination in progress calling this function */
> GEM_WARN_ON(pxp->arb_is_valid);
>  
> +   active_sip_slots = intel_uncore_read(gt->uncore,
> GEN12_KCR_SIP);
> +
> /* terminate the hw sessions */
> ret = intel_pxp_terminate_session(pxp, ARB_SESSION);
> if (ret) {
> @@ -110,6 +113,8 @@ static int
> pxp_terminate_arb_session_and_global(struct intel_pxp *pxp)
>  
> intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
>  
> +   intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
> +
> return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index b0c9170b1395..202ea01cbb88 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -309,3 +309,38 @@ int 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add OAG 32 bit format support for MTL (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add OAG 32 bit format support for MTL (rev2)
URL   : https://patchwork.freedesktop.org/series/111512/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12457 -> Patchwork_111512v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 32)
--

  Missing(6): fi-ilk-m540 bat-dg1-7 bat-adlm-1 fi-kbl-x1275 fi-kbl-8809g 
bat-rpls-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [INCOMPLETE][4] ([i915#2940]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111512v2/fi-ehl-2/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][6] ([i915#4983]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111512v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][8] ([i915#4983]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111512v2/bat-rpls-2/igt@i915_selftest@l...@reset.html

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

  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#6949]: https://gitlab.freedesktop.org/drm/intel/issues/6949
  [i915#7073]: https://gitlab.freedesktop.org/drm/intel/issues/7073
  [i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125


Build changes
-

  * IGT: IGT_7076 -> IGTPW_8166
  * Linux: CI_DRM_12457 -> Patchwork_111512v2

  CI-20190529: 20190529
  CI_DRM_12457: 42273934c8b473fd88e6689a589e9b4050c46bec @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_8166: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8166/index.html
  IGT_7076: 888725538e0d6bbb941ac278d4afcbbbdad0 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111512v2: 42273934c8b473fd88e6689a589e9b4050c46bec @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

68907d893a9c drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL
4b69c78ee8bb drm/i915/mtl: Update OA mux whitelist for MTL
17595f238fd9 drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch
ef9ae95211b2 drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add OAG 32 bit format support for MTL (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add OAG 32 bit format support for MTL (rev2)
URL   : https://patchwork.freedesktop.org/series/111512/
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: failure for add guard padding around i915_vma (rev4)

[Patchwork]

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_12457 -> Patchwork_110720v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110720v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110720v4, 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_110720v4/index.html

Participating hosts (38 -> 35)
--

  Missing(3): fi-ilk-m540 fi-cfl-8700k fi-tgl-dsi 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-rkl-11600:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-rkl-11600/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-rkl-11600/igt@i915_module_l...@load.html
- fi-icl-u2:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-icl-u2/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-icl-u2/igt@i915_module_l...@load.html
- fi-apl-guc: [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-apl-guc/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-apl-guc/igt@i915_module_l...@load.html
- fi-glk-j4005:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-glk-j4005/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-glk-j4005/igt@i915_module_l...@load.html
- fi-rkl-guc: [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-rkl-guc/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-rkl-guc/igt@i915_module_l...@load.html
- fi-skl-guc: [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-skl-guc/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-skl-guc/igt@i915_module_l...@load.html
- bat-dg1-6:  [PASS][13] -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-dg1-6/igt@i915_module_l...@load.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/bat-dg1-6/igt@i915_module_l...@load.html
- fi-adl-ddr5:[PASS][15] -> [INCOMPLETE][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-adl-ddr5/igt@i915_module_l...@load.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-adl-ddr5/igt@i915_module_l...@load.html
- fi-kbl-x1275:   [PASS][17] -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-kbl-x1275/igt@i915_module_l...@load.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-kbl-x1275/igt@i915_module_l...@load.html
- fi-cfl-8109u:   [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-cfl-8109u/igt@i915_module_l...@load.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-cfl-8109u/igt@i915_module_l...@load.html
- fi-ivb-3770:[PASS][21] -> [INCOMPLETE][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-ivb-3770/igt@i915_module_l...@load.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-ivb-3770/igt@i915_module_l...@load.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-8809g:   [PASS][23] -> [DMESG-WARN][24] +2 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-kbl-8809g/igt@kms_force_connector_ba...@prune-stale-modes.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/fi-kbl-8809g/igt@kms_force_connector_ba...@prune-stale-modes.html

  
 Suppressed 

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

  * igt@i915_module_load@load:
- {bat-jsl-1}:[PASS][25] -> [INCOMPLETE][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-jsl-1/igt@i915_module_l...@load.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v4/bat-jsl-1/igt@i915_module_l...@load.html
- {fi-jsl-1}: [PASS][27] -> [INCOMPLETE][28]
   [27]: 

Re: [Intel-gfx] [PATCH v2 0/4] drm/i915/mtl: Add OAG 32 bit format support for MTL

[Umesh Nerlige Ramappa]

On Wed, Nov 30, 2022 at 05:05:31PM -0800, Umesh Nerlige Ramappa wrote:

Enable OA for MTL by adding 32-bit OA format support and relevant fixes.

Signed-off-by: Umesh Nerlige Ramappa 
Test-with: 20221129010522.994524-1-umesh.nerlige.rama...@intel.com


https://patchwork.freedesktop.org/series/111512/#rev1 and 
https://patchwork.freedesktop.org/series/111512/#rev1 are identical 
except that rev2 has a Test-with: in the cover letter. Forgot to add it 
in rev1.


Thanks,
Umesh



Umesh Nerlige Ramappa (4):
 drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs
 drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch
 drm/i915/mtl: Update OA mux whitelist for MTL
 drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

drivers/gpu/drm/i915/gt/intel_gt_types.h |  6 ---
drivers/gpu/drm/i915/i915_perf.c | 49 ++--
2 files changed, 38 insertions(+), 17 deletions(-)

--
2.36.1

[Intel-gfx] [PATCH v2 3/4] drm/i915/mtl: Update OA mux whitelist for MTL

[Umesh Nerlige Ramappa]

0x20cc (WAIT_FOR_RC6_EXIT on other platforms) is repurposed on MTL. Use
a separate mux table to verify oa configs passed by user.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8ed9af571de9..8369ae4b850d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4318,6 +4318,17 @@ static const struct i915_range gen12_oa_mux_regs[] = {
{}
 };
 
+/*
+ * Ref: 14010536224:
+ * 0x20cc is repurposed on MTL, so use a separate array for MTL.
+ */
+static const struct i915_range mtl_oa_mux_regs[] = {
+   { .start = 0x0d00, .end = 0x0d04 }, /* RPM_CONFIG[0-1] */
+   { .start = 0x0d0c, .end = 0x0d2c }, /* NOA_CONFIG[0-8] */
+   { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
+   { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
+};
+
 static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
 {
return reg_in_range_table(addr, gen7_oa_b_counters);
@@ -4361,7 +4372,10 @@ static bool xehp_is_valid_b_counter_addr(struct 
i915_perf *perf, u32 addr)
 
 static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
 {
-   return reg_in_range_table(addr, gen12_oa_mux_regs);
+   if (IS_METEORLAKE(perf->i915))
+   return reg_in_range_table(addr, mtl_oa_mux_regs);
+   else
+   return reg_in_range_table(addr, gen12_oa_mux_regs);
 }
 
 static u32 mask_reg_value(u32 reg, u32 val)
-- 
2.36.1

[Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

[Umesh Nerlige Ramappa]

Without an entry in oa_init_supported_formats, OA will not be functional
in MTL. Enable OA support by enabling 32 bit OAG formats for MTL.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8369ae4b850d..a735b9540113 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4772,6 +4772,7 @@ static void oa_init_supported_formats(struct i915_perf 
*perf)
break;
 
case INTEL_DG2:
+   case INTEL_METEORLAKE:
oa_format_add(perf, I915_OAR_FORMAT_A32u40_A4u32_B8_C8);
oa_format_add(perf, I915_OA_FORMAT_A24u40_A14u32_B8_C8);
break;
-- 
2.36.1

[Intel-gfx] [PATCH v2 1/4] drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs

[Umesh Nerlige Ramappa]

On MTL, gt->scratch was using stolen lmem. An MI_SRM to stolen lmem
caused a hang that was attributed to saving and restoring the GPR
registers used for noa_wait.

Add an additional page in noa_wait BO to save/restore GPR registers for
the noa_wait logic.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  6 --
 drivers/gpu/drm/i915/i915_perf.c | 25 
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index c1d9cd255e06..13dffe0a3d20 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -296,12 +296,6 @@ enum intel_gt_scratch_field {
 
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
-
-   /* 6 * 8 bytes */
-   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR = 2048,
-
-   /* 4 bytes */
-   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1 = 2096,
 };
 
 #endif /* __INTEL_GT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 00e09bb18b13..7790a88f10d8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1842,8 +1842,7 @@ static u32 *save_restore_register(struct i915_perf_stream 
*stream, u32 *cs,
for (d = 0; d < dword_count; d++) {
*cs++ = cmd;
*cs++ = i915_mmio_reg_offset(reg) + 4 * d;
-   *cs++ = intel_gt_scratch_offset(stream->engine->gt,
-   offset) + 4 * d;
+   *cs++ = i915_ggtt_offset(stream->noa_wait) + offset + 4 * d;
*cs++ = 0;
}
 
@@ -1876,7 +1875,13 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
  MI_PREDICATE_RESULT_2_ENGINE(base) :
  
MI_PREDICATE_RESULT_1(RENDER_RING_BASE);
 
-   bo = i915_gem_object_create_internal(i915, 4096);
+   /*
+* gt->scratch was being used to save/restore the GPR registers, but on
+* MTL the scratch uses stolen lmem. An MI_SRM to this memory region
+* causes an engine hang. Instead allocate an additional page here to
+* save/restore GPR registers
+*/
+   bo = i915_gem_object_create_internal(i915, 8192);
if (IS_ERR(bo)) {
drm_err(>drm,
"Failed to allocate NOA wait batchbuffer\n");
@@ -1910,14 +1915,19 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
goto err_unpin;
}
 
+   stream->noa_wait = vma;
+
+#define GPR_SAVE_OFFSET 4096
+#define PREDICATE_SAVE_OFFSET 4160
+
/* Save registers. */
for (i = 0; i < N_CS_GPR; i++)
cs = save_restore_register(
stream, cs, true /* save */, CS_GPR(i),
-   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
+   GPR_SAVE_OFFSET + 8 * i, 2);
cs = save_restore_register(
stream, cs, true /* save */, mi_predicate_result,
-   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
+   PREDICATE_SAVE_OFFSET, 1);
 
/* First timestamp snapshot location. */
ts0 = cs;
@@ -2033,10 +2043,10 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
for (i = 0; i < N_CS_GPR; i++)
cs = save_restore_register(
stream, cs, false /* restore */, CS_GPR(i),
-   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
+   GPR_SAVE_OFFSET + 8 * i, 2);
cs = save_restore_register(
stream, cs, false /* restore */, mi_predicate_result,
-   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
+   PREDICATE_SAVE_OFFSET, 1);
 
/* And return to the ring. */
*cs++ = MI_BATCH_BUFFER_END;
@@ -2046,7 +2056,6 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
i915_gem_object_flush_map(bo);
__i915_gem_object_release_map(bo);
 
-   stream->noa_wait = vma;
goto out_ww;
 
 err_unpin:
-- 
2.36.1

[Intel-gfx] [PATCH v2 2/4] drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch

[Umesh Nerlige Ramappa]

Similar to ACM, OA timestamp that is part of the OA report is shifted
when compared to the CS timestamp. Add MTL to the WA.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7790a88f10d8..8ed9af571de9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3136,8 +3136,11 @@ get_sseu_config(struct intel_sseu *out_sseu,
  */
 u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915)
 {
-   /* Wa_18013179988:dg2 */
-   if (IS_DG2(i915)) {
+   /*
+* Wa_18013179988:dg2
+* Wa_14015846243:mtl
+*/
+   if (IS_DG2(i915) || IS_METEORLAKE(i915)) {
intel_wakeref_t wakeref;
u32 reg, shift;
 
-- 
2.36.1

[Intel-gfx] [PATCH v2 0/4] drm/i915/mtl: Add OAG 32 bit format support for MTL

[Umesh Nerlige Ramappa]

Enable OA for MTL by adding 32-bit OA format support and relevant fixes.

Signed-off-by: Umesh Nerlige Ramappa 
Test-with: 20221129010522.994524-1-umesh.nerlige.rama...@intel.com

Umesh Nerlige Ramappa (4):
  drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs
  drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch
  drm/i915/mtl: Update OA mux whitelist for MTL
  drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

 drivers/gpu/drm/i915/gt/intel_gt_types.h |  6 ---
 drivers/gpu/drm/i915/i915_perf.c | 49 ++--
 2 files changed, 38 insertions(+), 17 deletions(-)

-- 
2.36.1

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

[Patchwork]

== Series Details ==

Series: add guard padding around i915_vma (rev4)
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.

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

[Patchwork]

== Series Details ==

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

== Summary ==

Error: dim checkpatch failed
6a062612120d drm/i915: Limit the display memory alignment to 32 bit instead of 
64
ab5c06d48524 drm/i915: Wrap all access to i915_vma.node.start|size
-:264: 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
#264: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c:475:
+   GEM_BUG_ON(i915_vma_offset(vma) != addr);

-:356: 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
#356: FILE: drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c:65:
+   GEM_BUG_ON(offset + (count - 1) * PAGE_SIZE > i915_vma_size(vma));

-:393: 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
#393: FILE: drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:223:
+   GEM_BUG_ON(vma->fence_size > i915_vma_size(vma));

-:787: 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
#787: FILE: drivers/gpu/drm/i915/i915_vma.c:450:
+   GEM_BUG_ON(vma->size > i915_vma_size(vma));

-:870: 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
#870: FILE: drivers/gpu/drm/i915/i915_vma.h:146:
+   GEM_BUG_ON(!drm_mm_node_allocated(>node));

-:892: 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
#892: FILE: drivers/gpu/drm/i915/i915_vma.h:168:
+   GEM_BUG_ON(!drm_mm_node_allocated(>node));

-: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:176:
+   GEM_BUG_ON(upper_32_bits(i915_vma_offset(vma)));

-:904: 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
#904: 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
a4f3a8fe82af drm/i915: Introduce guard pages to i915_vma
-:118: 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
#118: FILE: drivers/gpu/drm/i915/i915_vma.c:762:
+   GEM_BUG_ON(hweight64(flags & (PIN_OFFSET_GUARD | PIN_OFFSET_FIXED | 
PIN_OFFSET_BIAS)) > 1);

-:132: 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
#132: FILE: drivers/gpu/drm/i915/i915_vma.c:778:
+   GEM_BUG_ON(overflows_type(flags & PIN_OFFSET_MASK, u32));

-:140: 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
#140: FILE: drivers/gpu/drm/i915/i915_vma.c:786:
+   GEM_BUG_ON(2 * guard > end);

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

-:227: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_node' - possible 
side-effects?
#227: 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, 3 warnings, 2 checks, 206 lines checked
6b9ed1df2f64 drm/i915: Refine VT-d scanout workaround
0a415a58613e Revert "drm/i915: Improve on suspend / resume time with VT-d 
enabled"

[Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

[Umesh Nerlige Ramappa]

Without an entry in oa_init_supported_formats, OA will not be functional
in MTL. Enable OA support by enabling 32 bit OAG formats for MTL.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8369ae4b850d..a735b9540113 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4772,6 +4772,7 @@ static void oa_init_supported_formats(struct i915_perf 
*perf)
break;
 
case INTEL_DG2:
+   case INTEL_METEORLAKE:
oa_format_add(perf, I915_OAR_FORMAT_A32u40_A4u32_B8_C8);
oa_format_add(perf, I915_OA_FORMAT_A24u40_A14u32_B8_C8);
break;
-- 
2.36.1

[Intel-gfx] [PATCH v2 2/4] drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch

[Umesh Nerlige Ramappa]

Similar to ACM, OA timestamp that is part of the OA report is shifted
when compared to the CS timestamp. Add MTL to the WA.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7790a88f10d8..8ed9af571de9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3136,8 +3136,11 @@ get_sseu_config(struct intel_sseu *out_sseu,
  */
 u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915)
 {
-   /* Wa_18013179988:dg2 */
-   if (IS_DG2(i915)) {
+   /*
+* Wa_18013179988:dg2
+* Wa_14015846243:mtl
+*/
+   if (IS_DG2(i915) || IS_METEORLAKE(i915)) {
intel_wakeref_t wakeref;
u32 reg, shift;
 
-- 
2.36.1

[Intel-gfx] [PATCH v2 0/4] drm/i915/mtl: Add OAG 32 bit format support for MTL

[Umesh Nerlige Ramappa]

Enable OA for MTL by adding 32-bit OA format support and relevant fixes.

Signed-off-by: Umesh Nerlige Ramappa 

Umesh Nerlige Ramappa (4):
  drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs
  drm/i915/mtl: Add Wa_14015846243 to fix OA vs CS timestamp mismatch
  drm/i915/mtl: Update OA mux whitelist for MTL
  drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

 drivers/gpu/drm/i915/gt/intel_gt_types.h |  6 ---
 drivers/gpu/drm/i915/i915_perf.c | 49 ++--
 2 files changed, 38 insertions(+), 17 deletions(-)

-- 
2.36.1

[Intel-gfx] [PATCH v2 3/4] drm/i915/mtl: Update OA mux whitelist for MTL

[Umesh Nerlige Ramappa]

0x20cc (WAIT_FOR_RC6_EXIT on other platforms) is repurposed on MTL. Use
a separate mux table to verify oa configs passed by user.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8ed9af571de9..8369ae4b850d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4318,6 +4318,17 @@ static const struct i915_range gen12_oa_mux_regs[] = {
{}
 };
 
+/*
+ * Ref: 14010536224:
+ * 0x20cc is repurposed on MTL, so use a separate array for MTL.
+ */
+static const struct i915_range mtl_oa_mux_regs[] = {
+   { .start = 0x0d00, .end = 0x0d04 }, /* RPM_CONFIG[0-1] */
+   { .start = 0x0d0c, .end = 0x0d2c }, /* NOA_CONFIG[0-8] */
+   { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
+   { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
+};
+
 static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
 {
return reg_in_range_table(addr, gen7_oa_b_counters);
@@ -4361,7 +4372,10 @@ static bool xehp_is_valid_b_counter_addr(struct 
i915_perf *perf, u32 addr)
 
 static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
 {
-   return reg_in_range_table(addr, gen12_oa_mux_regs);
+   if (IS_METEORLAKE(perf->i915))
+   return reg_in_range_table(addr, mtl_oa_mux_regs);
+   else
+   return reg_in_range_table(addr, gen12_oa_mux_regs);
 }
 
 static u32 mask_reg_value(u32 reg, u32 val)
-- 
2.36.1

[Intel-gfx] [PATCH v2 1/4] drm/i915/mtl: Resize noa_wait BO size to save restore GPR regs

[Umesh Nerlige Ramappa]

On MTL, gt->scratch was using stolen lmem. An MI_SRM to stolen lmem
caused a hang that was attributed to saving and restoring the GPR
registers used for noa_wait.

Add an additional page in noa_wait BO to save/restore GPR registers for
the noa_wait logic.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  6 --
 drivers/gpu/drm/i915/i915_perf.c | 25 
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index c1d9cd255e06..13dffe0a3d20 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -296,12 +296,6 @@ enum intel_gt_scratch_field {
 
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
-
-   /* 6 * 8 bytes */
-   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR = 2048,
-
-   /* 4 bytes */
-   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1 = 2096,
 };
 
 #endif /* __INTEL_GT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 00e09bb18b13..7790a88f10d8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1842,8 +1842,7 @@ static u32 *save_restore_register(struct i915_perf_stream 
*stream, u32 *cs,
for (d = 0; d < dword_count; d++) {
*cs++ = cmd;
*cs++ = i915_mmio_reg_offset(reg) + 4 * d;
-   *cs++ = intel_gt_scratch_offset(stream->engine->gt,
-   offset) + 4 * d;
+   *cs++ = i915_ggtt_offset(stream->noa_wait) + offset + 4 * d;
*cs++ = 0;
}
 
@@ -1876,7 +1875,13 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
  MI_PREDICATE_RESULT_2_ENGINE(base) :
  
MI_PREDICATE_RESULT_1(RENDER_RING_BASE);
 
-   bo = i915_gem_object_create_internal(i915, 4096);
+   /*
+* gt->scratch was being used to save/restore the GPR registers, but on
+* MTL the scratch uses stolen lmem. An MI_SRM to this memory region
+* causes an engine hang. Instead allocate an additional page here to
+* save/restore GPR registers
+*/
+   bo = i915_gem_object_create_internal(i915, 8192);
if (IS_ERR(bo)) {
drm_err(>drm,
"Failed to allocate NOA wait batchbuffer\n");
@@ -1910,14 +1915,19 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
goto err_unpin;
}
 
+   stream->noa_wait = vma;
+
+#define GPR_SAVE_OFFSET 4096
+#define PREDICATE_SAVE_OFFSET 4160
+
/* Save registers. */
for (i = 0; i < N_CS_GPR; i++)
cs = save_restore_register(
stream, cs, true /* save */, CS_GPR(i),
-   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
+   GPR_SAVE_OFFSET + 8 * i, 2);
cs = save_restore_register(
stream, cs, true /* save */, mi_predicate_result,
-   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
+   PREDICATE_SAVE_OFFSET, 1);
 
/* First timestamp snapshot location. */
ts0 = cs;
@@ -2033,10 +2043,10 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
for (i = 0; i < N_CS_GPR; i++)
cs = save_restore_register(
stream, cs, false /* restore */, CS_GPR(i),
-   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
+   GPR_SAVE_OFFSET + 8 * i, 2);
cs = save_restore_register(
stream, cs, false /* restore */, mi_predicate_result,
-   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
+   PREDICATE_SAVE_OFFSET, 1);
 
/* And return to the ring. */
*cs++ = MI_BATCH_BUFFER_END;
@@ -2046,7 +2056,6 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
i915_gem_object_flush_map(bo);
__i915_gem_object_release_map(bo);
 
-   stream->noa_wait = vma;
goto out_ww;
 
 err_unpin:
-- 
2.36.1

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/mtl: Initial display workarounds

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/mtl: Initial display workarounds
URL   : https://patchwork.freedesktop.org/series/111507/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12457 -> Patchwork_111507v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 35)
--

  Missing(3): fi-ilk-m540 fi-tgl-dsi bat-dg1-6 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [INCOMPLETE][8] ([i915#2940]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111507v1/fi-ehl-2/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][10] ([i915#4983]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111507v1/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111507v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
- {bat-rpls-1}:   [DMESG-FAIL][14] ([i915#4983]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111507v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][16] ([i915#6298]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12457/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111507v1/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#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: 

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

[John Harrison]

On 11/23/2022 12:45, Michal Wajdeczko wrote:

On 23.11.2022 02:25, John Harrison wrote:

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

Hmm, I'm not sure that we should attempt to have such a flexible rule as
we shouldn't rely too much on actual format of the prefix as it could be
changed any time.  All we should know about final log message is that it
_will_ properly identify the "GT" or "GuC" that this log is related to.

So I would suggest to be just consistent and probably always start with
upper case, as that seems to be mostly used in kernel error logs, and
just make sure that any prefix will honor that (by including colon, or
braces), so this will always work like:

"[drm] *ERROR* GT0: Failed to foo (-EIO)"
"[drm] *ERROR* GT0: GUC: Failed to foo (-EIO)"
"[drm] *ERROR* GT0: GUC: CT: Failed to foo (-EIO)"

or

"[drm] *ERROR* GT0: Failed to foo (-EIO)"
"[drm] *ERROR* GT0: [GUC] Failed to foo (-EIO)"
"[drm] *ERROR* GT0: [GUC] CT: Failed to foo (-EIO)"

and even for:

"[drm] *ERROR* GT(root) Failed to foo (-EIO)"
"[drm] *ERROR* GuC(media) Failed to foo (-EIO)"
"[drm] *ERROR* GT0 [GuC:CT] Failed to foo (-EIO)"
All of which are hideous/complex/verbose/inconsistent. 'GT0: GUC: CT:'? 
Really? Or 'GT0: [GUC] CT:'? Why the random mix of separators? And how 
would you implement '[GUC:CT]' without having a CT definition that is 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/mtl: Initial display workarounds

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/mtl: Initial display workarounds
URL   : https://patchwork.freedesktop.org/series/111507/
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 series starting with [1/2] drm/i915/mtl: Initial display workarounds

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/mtl: Initial display workarounds
URL   : https://patchwork.freedesktop.org/series/111507/
State : warning

== Summary ==

Error: dim checkpatch failed
8c18d75df531 drm/i915/mtl: Initial display workarounds
-:122: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#122: FILE: drivers/gpu/drm/i915/i915_drv.h:730:
+#define IS_MTL_DISPLAY_STEP(__i915, since, until) \
+   (DISPLAY_VER(__i915) == 14 && \
+IS_DISPLAY_STEP(__i915, since, until))

total: 0 errors, 0 warnings, 1 checks, 89 lines checked
1f8e6e4fe341 drm/i915/mtl: Add initial gt workarounds
-:325: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#325: FILE: drivers/gpu/drm/i915/i915_drv.h:734:
+#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
+   (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
&& \
+IS_GRAPHICS_STEP(__i915, since, until))

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

Re: [Intel-gfx] [PATCH] drm/i915: fix exiting context timeout calculation

[John Harrison]

On 11/29/2022 00:43, Tvrtko Ursulin wrote:

On 28/11/2022 16:52, Andrzej Hajda wrote:

In case context is exiting preempt_timeout_ms is used for timeout,
but since introduction of DRM_I915_PREEMPT_TIMEOUT_COMPUTE it increases
to 7.5 seconds. Heartbeat occurs earlier but it is still 2.5s.

Fixes: d7a8680ec9fb21 ("drm/i915: Improve long running compute w/a 
for GuC submission")

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2410
Signed-off-by: Andrzej Hajda 
---
Hi all,

I am not sure what is expected solution here, and if my patch does not
actually reverts intentions of patch d7a8680ec9fb21. Feel free to 
propose

something better.
Other alternative would be to increase t/o in IGT tests, but I am not 
sure

if this is good direction.


Is it the hack with the FIXME marker from 47daf84a8bfb ("drm/i915: 
Make the heartbeat play nice with long pre-emption timeouts") that 
actually breaks things? (If IGT modifies the preempt timeout the 
heartbeat extension will not work as intended.)


If so, I think we agreed during review that was a weakness which needs 
to be addressed, but I would need to re-read the old threads to 
remember what was the plan. Regardless what it was it may be time is 
now to continue with those improvements.


What is the actual issue? Just that closing contexts are taking forever 
to actually close? That would be the whole point of the 
'context_is_exiting' patch. Which I still totally disagree with.


If the context is being closed 'gracefully' and it is intended that it 
should be allowed time to pre-empt without being killed via an engine 
reset then the 7.5s delay is required. That is the officially agreed 
upon timeout to allow compute capable contexts to reach a pre-emption 
point before they should be killed. If an IGT is failing because it 
enforces a shorter timeout then the IGT needs to be updated to account 
for the fact that i915 has to support slow compute workloads.


If the context is being closed 'forcefully' and should be killed 
immediately then you should be using the 'BANNED_PREEMPT_TIMEOUT' value 
not the sysfs/config value.


Regarding heartbeats...

The heartbeat period is 2.5s. But there are up to five heartbeat periods 
between the heartbeat starting and it declaring a hang. The patch you 
mention also introduced a check on the pre-emption timeout when the last 
period starts. If the pre-emption timeout is longer than the heartbeat 
period then the last period is extended to guarantee that a full 
pre-emption time is granted before declaring the hang.


Are you saying that a heartbeat timeout is occurring and killing the 
system? Or are you just worried that something doesn't align correctly?


John.


Regards,

Tvrtko



Regards
Andrzej
---
  drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c

index 49a8f10d76c77b..cd9e00f947 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1248,6 +1248,10 @@ static unsigned long 
active_preempt_timeout(struct intel_engine_cs *engine,

  /* Force a fast reset for terminated contexts (ignoring sysfs!) */
  if (unlikely(intel_context_is_banned(rq->context) || 
bad_request(rq)))

  return INTEL_CONTEXT_BANNED_PREEMPT_TIMEOUT_MS;
+    else if (unlikely(intel_context_is_exiting(rq->context)))
+    return min_t(typeof(unsigned long),
+ READ_ONCE(engine->props.preempt_timeout_ms),
+ CONFIG_DRM_I915_PREEMPT_TIMEOUT);
    return READ_ONCE(engine->props.preempt_timeout_ms);
  }

[Intel-gfx] [PATCH v4 4/5] 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 +-
 2 files changed, 14 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 850776a783ac7..9969e687ad857 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 784d4a8c43ba9..fa96d925c2596 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -376,27 +376,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)
 {
/*
@@ -968,8 +947,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;
 
@@ -1128,7 +1105,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;
-- 
2.38.1

[Intel-gfx] [PATCH v4 5/5] 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 fa96d925c2596..5896ac44010b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -27,13 +27,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,
@@ -105,23 +98,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
@@ -185,10 +161,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;
 
@@ -545,8 +518,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
@@ -1263,20 +1234,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) {
@@ -1285,16 +1247,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;
@@ -1321,8 +1283,3 @@ 

[Intel-gfx] [PATCH v4 3/5] 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  | 40 +++-
 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|  1 +
 7 files changed, 57 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 7644738b9cdbe..784d4a8c43ba9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -296,8 +296,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);
@@ -347,9 +350,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 fefee5fef38d3..3877847179710 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 v4 2/5] 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 
Reviewed-by: Tvrtko Ursulin 
---
 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 @@ 

[Intel-gfx] [PATCH v4 1/5] drm/i915: Limit the display memory alignment to 32 bit instead of 64

[Andi Shyti]

The coming commit "drm/i915: Introduce guard pages to i915_vma"
from Chris, was originally changing display_alignment to u32
from u64. The reason is that the display GGTT is and will be
limited o 4GB.

Put it in a separate patch and use "max(...)" instead of
"max_t(64, ...)" when asigning the value. We can safely use max
as we know beforehand that the comparison is between two u32
variables.

Signed-off-by: Chris Wilson 
Signed-off-by: Andi Shyti 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c  | 2 +-
 drivers/gpu/drm/i915/i915_vma_types.h   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 6900acbb1381c..1aca7552a85d0 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -91,7 +91,7 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
goto err;
}
 
-   vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
+   vma->display_alignment = max(vma->display_alignment, alignment);
 
i915_gem_object_flush_if_display(obj);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce6800..850776a783ac7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -444,7 +444,7 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
if (IS_ERR(vma))
return vma;
 
-   vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
+   vma->display_alignment = max(vma->display_alignment, alignment);
i915_vma_mark_scanout(vma);
 
i915_gem_object_flush_if_display_locked(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h 
b/drivers/gpu/drm/i915/i915_vma_types.h
index ec0f6c9f57d02..0375812792b9c 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -197,7 +197,6 @@ struct i915_vma {
struct i915_fence_reg *fence;
 
u64 size;
-   u64 display_alignment;
struct i915_page_sizes page_sizes;
 
/* mmap-offset associated with fencing for this vma */
@@ -205,6 +204,7 @@ struct i915_vma {
 
u32 fence_size;
u32 fence_alignment;
+   u32 display_alignment;
 
/**
 * Count of the number of times this vma has been opened by different
-- 
2.38.1

[Intel-gfx] [PATCH v4 0/5] 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.

Thanks Tvrtko and Chris for the review.

Andi

Changelog
=
v3 -> v4:
 - change the order of the patches: the 64->32 bit change of the
   memory alignment goes as first (Tvrtko).
 - Use roundup instead of ALIGN to round up the guard padding
   (Chris).
 - Restore the GEM_BUG_ON(2 * guard > end) as a paranoiac check
   and as mean of documentation (Chris).

v2 -> v3:
 - fix Tvrtko's comments: explain in a comment why the guard is
   is alligned as the vma and remove a GEM_BUG_ON() in case the
   the total padding was exceeding the size of the va.
 - the display_alignment is declared as u32 instead of a u64 in
   a separate patch.

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

Andi Shyti (2):
  drm/i915: Limit the display memory alignment to 32 bit instead of 64
  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_fb_pin.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  15 ++-
 .../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   |  63 +++---
 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 +-
 37 files changed, 264 insertions(+), 259 deletions(-)

-- 
2.38.1

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add support for 32 bit OAG formats in MTL

[Umesh Nerlige Ramappa]

On Wed, Nov 30, 2022 at 12:14:20PM -0800, Dixit, Ashutosh wrote:

On Wed, 30 Nov 2022 12:00:57 -0800, Umesh Nerlige Ramappa wrote:


On Tue, Nov 29, 2022 at 05:51:13PM -0800, Dixit, Ashutosh wrote:
> On Mon, 28 Nov 2022 17:21:46 -0800, Umesh Nerlige Ramappa wrote:
>>
>> +/*
>> + * Ref: 14010536224:
>> + * 0x20cc is repurposed on MTL, so use a separate array for MTL.
>
> Wondering if it was WAIT_FOR_RC6_EXIT (seen in gen12_oa_mux_regs) which
> moved elsewhere and if that needs to be added to the array below too?

WAIT_FOR_RC6_EXIT (0x20cc) moved elsewhere so it should be "removed" from
mtl oa mux array.


What I was saying was let's say WAIT_FOR_RC6_EXIT moved to 0xc0ffee so now
should 0xc0ffee be added to mtl_oa_mux_regs?


oh, sorry, I misread that.

I looked for WAIT_FOR_RC6_EXIT in the bspec and did not find it defined 
for MTL, so it's dropped completely. If you could confirm, that would be 
great.






>
>> + */
>> +static const struct i915_range mtl_oa_mux_regs[] = {
>> +  { .start = 0x0d00, .end = 0x0d04 }, /* RPM_CONFIG[0-1] */
>> +  { .start = 0x0d0c, .end = 0x0d2c }, /* NOA_CONFIG[0-8] */
>> +  { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
>> +  { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
>> +};
>> +
>>  static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
>>  {
>>return reg_in_range_table(addr, gen7_oa_b_counters);
>> @@ -4349,7 +4372,10 @@ static bool xehp_is_valid_b_counter_addr(struct 
i915_perf *perf, u32 addr)
>>
>>  static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
>>  {
>> -  return reg_in_range_table(addr, gen12_oa_mux_regs);
>> +  if (IS_METEORLAKE(perf->i915))
>> +  return reg_in_range_table(addr, mtl_oa_mux_regs);
>> +  else
>> +  return reg_in_range_table(addr, gen12_oa_mux_regs);
>
> But otherwise this is:
>
> Reviewed-by: Ashutosh Dixit 

I will break them into separate patches though. If the diff is identical, I
will carry over your R-b on the split patches. Please let me know if that's
a concern.


No I can quickly review again anyway.


got it, will not add the R-bs.

Thanks,
Umesh




> If you decide to split the patches, please add my R-b on all the split 
patches.


Thanks.
--
Ashutosh

[Intel-gfx] [PATCH 2/2] drm/i915/mtl: Add initial gt workarounds

[Matt Atwood]

From: Matt Roper 

This patch introduces initial workarounds for mtl platform

Bspec:66622

Signed-off-by: Matt Atwood 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   4 +-
 .../drm/i915/gt/intel_execlists_submission.c  |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  11 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 105 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   9 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  10 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_device_info.c  |   6 +
 9 files changed, 121 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d670..af88d8ab61c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1479,7 +1479,9 @@ static int __intel_engine_stop_cs(struct intel_engine_cs 
*engine,
 * Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 49a8f10d76c7..a91c912e35d6 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2992,7 +2992,9 @@ static void execlists_reset_prepare(struct 
intel_engine_cs *engine)
 * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
 * to wait for any pending mi force wakeups
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_engine_wait_for_pending_mi_fw(engine);
 
engine->execlists.reset_ccid = active_ccid(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index aa070ae57f11..0e90a8f86b27 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -164,8 +164,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
-   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
-intel_uncore_read(gt->uncore, XEHP_FUSE4));
+   /* Wa_14016747170:mtl-m[a0], mtl-p[a0] */
+   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore,
+  
MTL_GT_ACTIVITY_FACTOR));
+   else
+   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore, 
XEHP_FUSE4));
 
/*
 * Despite the register field being named "exclude mask" the
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 784152548472..c2c03b02f200 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -413,6 +413,7 @@
 #define   TBIMR_FAST_CLIP  REG_BIT(5)
 
 #define VFLSKPDMCR_REG(0x62a8)
+#define   VF_PREFETCH_TLB_DIS  REG_BIT(5)
 #define   DIS_OVER_FETCH_CACHE REG_BIT(1)
 #define   DIS_MULT_MISS_RD_SQUASH  REG_BIT(0)
 
@@ -1532,6 +1533,10 @@
 
 #define MTL_MEDIA_MC6  _MMIO(0x138048)
 
+/* Wa_14016747170:mtl-p[a0], mtl-m[a0] */
+#define MTL_GT_ACTIVITY_FACTOR _MMIO(0x138010)
+#define   MTL_GT_L3_EXC_MASK   REG_GENMASK(5, 3)
+
 #define GEN6_GT_THREAD_STATUS_REG  _MMIO(0x13805c)
 #define   GEN6_GT_THREAD_STATUS_CORE_MASK  0x7
 
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3e35facac2b4..2e3d5de0c522 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c

[Intel-gfx] [PATCH 1/2] drm/i915/mtl: Initial display workarounds

[Matt Atwood]

From: Jouni Högander 

This patch introduces initial workarounds for mtl platform

Bspec: 66624

Signed-off-by: Matt Atwood 
Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  3 ++-
 drivers/gpu/drm/i915/display/intel_psr.c  | 27 ---
 drivers/gpu/drm/i915/i915_drv.h   |  4 
 4 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index b5ee5ea0d010..8f269553d826 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1095,7 +1095,9 @@ static int intel_fbc_check_plane(struct 
intel_atomic_state *state,
}
 
/* Wa_14016291713 */
-   if (IS_DISPLAY_VER(i915, 12, 13) && crtc_state->has_psr) {
+   if ((IS_DISPLAY_VER(i915, 12, 13) ||
+IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
+   crtc_state->has_psr) {
plane_state->no_fbc_reason = "PSR1 enabled (Wa_14016291713)";
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e82f8a07e2b0..efa2da080f62 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -537,7 +537,8 @@ void hsw_write_infoframe(struct intel_encoder *encoder,
   0);
 
/* Wa_14013475917 */
-   if (DISPLAY_VER(dev_priv) == 13 && crtc_state->has_psr &&
+   if ((DISPLAY_VER(dev_priv) == 13 ||
+IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) && 
crtc_state->has_psr &&
type == DP_SDP_VSC)
return;
 
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 5b678916e6db..7982157fb1ff 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -797,7 +797,7 @@ static bool psr2_granularity_check(struct intel_dp 
*intel_dp,
return intel_dp->psr.su_y_granularity == 4;
 
/*
-* adl_p and display 14+ platforms has 1 line granularity.
+* adl_p and mtl platforms has 1 line granularity.
 * For other platforms with SW tracking we can adjust the y coordinates
 * to match sink requirement if multiple of 4.
 */
@@ -1170,11 +1170,14 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 PSR2_ADD_VERTICAL_LINE_COUNT);
 
/*
-* Wa_16014451276:adlp
+* Wa_16014451276:adlp,mtl[a0,b0]
 * All supported adlp panels have 1-based X granularity, this 
may
 * cause issues if non-supported panels are used.
 */
-   if (IS_ALDERLAKE_P(dev_priv))
+   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
+   intel_de_rmw(dev_priv, 
MTL_CHICKEN_TRANS(cpu_transcoder), 0,
+ADLP_1_BASED_X_GRANULARITY);
+   else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
 ADLP_1_BASED_X_GRANULARITY);
 
@@ -1185,8 +1188,12 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 TRANS_SET_CONTEXT_LATENCY_MASK,
 TRANS_SET_CONTEXT_LATENCY_VALUE(1));
 
-   /* Wa_16012604467:adlp */
-   if (IS_ALDERLAKE_P(dev_priv))
+   /* Wa_16012604467:adlp,mtl[a0,b0] */
+   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
+   intel_de_rmw(dev_priv,
+MTL_CLKGATE_DIS_TRANS(cpu_transcoder), 0,
+MTL_CLKGATE_DIS_TRANS_DMASC_GATING_DIS);
+   else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
 CLKGATE_DIS_MISC_DMASC_GATING_DIS);
 
@@ -1362,8 +1369,12 @@ static void intel_psr_disable_locked(struct intel_dp 
*intel_dp)
 
TRANS_SET_CONTEXT_LATENCY(intel_dp->psr.transcoder),
 TRANS_SET_CONTEXT_LATENCY_MASK, 0);
 
-   /* Wa_16012604467:adlp */
-   if (IS_ALDERLAKE_P(dev_priv))
+   /* Wa_16012604467:adlp,mtl[a0,b0] */
+   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
+   intel_de_rmw(dev_priv,
+
MTL_CLKGATE_DIS_TRANS(intel_dp->psr.transcoder),
+MTL_CLKGATE_DIS_TRANS_DMASC_GATING_DIS, 0);
+   else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
 

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

[Matt Roper]

On Wed, Nov 30, 2022 at 04:46:50PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: dedicated MCR locking and hardware semaphore (rev3)
> URL   : https://patchwork.freedesktop.org/series/111220/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12455 -> Patchwork_111220v3
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_111220v3 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_111220v3, 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_111220v3/index.html
> 
> Participating hosts (29 -> 32)
> --
> 
>   Additional (5): fi-kbl-7567u fi-glk-dsi fi-glk-j4005 fi-kbl-x1275 
> fi-kbl-8809g 
>   Missing(2): bat-dg1-6 fi-skl-6600u 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_111220v3:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_suspend@basic-s2idle-without-i915:
> - fi-elk-e7500:   [PASS][1] -> [WARN][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/fi-elk-e7500/igt@i915_susp...@basic-s2idle-without-i915.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-elk-e7500/igt@i915_susp...@basic-s2idle-without-i915.html

(i915_suspend:4706) igt_kmod-WARNING: Could not stop 1 audio process(es)

Not related to this series.


Matt

> 
>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@i915_selftest@live@hangcheck:
> - {fi-jsl-1}: [PASS][3] -> [INCOMPLETE][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_111220v3 that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_huc_copy@huc-copy:
> - fi-kbl-7567u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-7567u/igt@gem_huc_c...@huc-copy.html
> - fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
> - fi-glk-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
> - fi-glk-j4005:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html
> - fi-kbl-x1275:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html
> 
>   * igt@gem_lmem_swapping@basic:
> - fi-glk-j4005:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) 
> +3 similar issues
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html
> - fi-kbl-7567u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) 
> +3 similar issues
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-7567u/igt@gem_lmem_swapp...@basic.html
> 
>   * igt@gem_lmem_swapping@verify-random:
> - fi-glk-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) 
> +3 similar issues
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@gem_lmem_swapp...@verify-random.html
> - fi-kbl-x1275:   NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) 
> +3 similar issues
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html
> 
>   * igt@gem_tiled_blits@basic:
> - fi-glk-dsi: NOTRUN -> [SKIP][14] ([fdo#109271]) +12 similar 
> issues
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@gem_tiled_bl...@basic.html
> 
>   * igt@i915_module_load@reload:
> - fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][15] ([i915#6899])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-8809g/igt@i915_module_l...@reload.html
> 
>   * igt@kms_chamelium@dp-crc-fast:
> - fi-glk-dsi: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) 
> +8 similar issues
>[16]: 
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for More GuC firmware version improvements (rev3)

[John Harrison]

On 11/30/2022 01:47, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   More GuC firmware version improvements (rev3)
*URL:*  https://patchwork.freedesktop.org/series/111218/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/index.html



  CI Bug Log - changes from CI_DRM_12449_full -> Patchwork_111218v3_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_111218v3_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_111218v3_full, please notify your bug team to 
allow them
to document this new failure mode, which will reduce false positives 
in CI.



Participating hosts (10 -> 10)

No changes in participating hosts


Possible new issues

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



  IGT changes


Possible regressions

 *

igt@gem_busy@close-race:

  o shard-skl: PASS


-> FAIL


 *

igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt:

  o shard-tglb: PASS


-> INCOMPLETE


 *

igt@perf_pmu@module-unload:

  o shard-apl: PASS


-> INCOMPLETE



These issues are all on non-GuC platforms and these changes only affect 
GuC submission and firmware loading.


John.



 *


Known issues

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



  IGT changes


Issues hit

 *

igt@gem_ctx_isolation@preservation-s3@bcs0:

  o shard-skl: PASS


-> INCOMPLETE


(i915#4793 )
 *

igt@gem_exec_balancer@parallel-contexts:

  o shard-iclb: PASS


-> SKIP


(i915#4525 )
 *

igt@gem_exec_capture@pi@rcs0:

  o shard-skl: NOTRUN -> INCOMPLETE


(i915#3371 )
 *

igt@gem_exec_fair@basic-none-solo@rcs0:

  o shard-apl: PASS


-> FAIL


(i915#2842 )
 *

igt@gem_exec_fair@basic-pace-share@rcs0:

  o shard-tglb: PASS


-> FAIL


(i915#2842 )
 *

igt@gem_exec_whisper@basic-queues-priority:

  o shard-iclb: PASS


-> INCOMPLETE


(i915#6453 )
 *

igt@gem_lmem_swapping@parallel-random-verify:

  o shard-skl: NOTRUN -> SKIP


(fdo#109271
 /
i915#4613 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Look for a guilty context when an engine reset fails

[John Harrison]

On 11/30/2022 00:30, Tvrtko Ursulin wrote:

On 29/11/2022 21:12, john.c.harri...@intel.com wrote:

From: John Harrison 

Engine resets are supposed to never happen. But in the case when one


Engine resets or engine reset failures? Hopefully the latter.


Oops. Yes, that was meant to say "engine resets are never supposed to fail."


does (due to unknwon reasons that normally come down to a missing

unknwon -> unknown


w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

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..c82730804a1c4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4751,11 +4751,24 @@ static void reset_fail_worker_func(struct 
work_struct *w)

  guc->submission_state.reset_fail_mask = 0;
  spin_unlock_irqrestore(>submission_state.lock, flags);
  -    if (likely(reset_fail_mask))
+    if (likely(reset_fail_mask)) {
+    struct intel_engine_cs *engine;
+    enum intel_engine_id id;
+
+    /*
+ * GuC is toast at this point - it dead loops after sending 
the failed
+ * reset notification. So need to manually determine the 
guilty context.
+ * Note that it should be safe/reliable to do this here 
because the GuC

+ * is toast and will not be scheduling behind the KMD's back.
+ */
+    for_each_engine_masked(engine, gt, reset_fail_mask, id)
+    intel_guc_find_hung_context(engine);
+
  intel_gt_handle_error(gt, reset_fail_mask,
    I915_ERROR_CAPTURE,
    "GuC failed to reset engine mask=0x%x\n",
    reset_fail_mask);


If GuC is defined by ABI contract to be dead, should the flow be 
attempting to do a full GPU reset here, or maybe it happens somewhere 
else as a consequence anyway? (In which case is the engine reset here 
even needed?)
This is a full GT reset. i915 is not allowed to perform an engine reset 
when using GuC submission. Those can only be done by GuC. So any forced 
reset by i915 will be escalated to full GT internally.


John.



Regards,

Tvrtko


+    }
  }
    int intel_guc_engine_failure_process_msg(struct intel_guc *guc,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pvc: Implement recommended caching policy

[Patchwork]

== Series Details ==

Series: drm/i915/pvc: Implement recommended caching policy
URL   : https://patchwork.freedesktop.org/series/111491/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12456 -> Patchwork_111491v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

  Additional (2): fi-kbl-7567u fi-hsw-4770 
  Missing(2): fi-ilk-m540 bat-dg1-6 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +11 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

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

  * igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html

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

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [PASS][9] -> [FAIL][10] ([i915#6298])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  * igt@kms_psr@cursor_plane_move:
- fi-kbl-7567u:   NOTRUN -> [SKIP][11] ([fdo#109271]) +30 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/fi-kbl-7567u/igt@kms_psr@cursor_plane_move.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1072]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

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

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][15] ([i915#2582]) -> [PASS][16] +4 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/bat-rpls-2/igt@fb...@read.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][17] ([i915#7229]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
- {bat-rpls-2}:   [DMESG-WARN][19] ([i915#6434]) -> [PASS][20] +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/bat-rpls-2/igt@gem_exec_gttf...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111491v1/bat-rpls-2/igt@gem_exec_gttf...@basic.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-rpls-2}:   [INCOMPLETE][21] ([i915#4983]) -> 

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add support for 32 bit OAG formats in MTL

[Dixit, Ashutosh]

On Wed, 30 Nov 2022 12:00:57 -0800, Umesh Nerlige Ramappa wrote:
>
> On Tue, Nov 29, 2022 at 05:51:13PM -0800, Dixit, Ashutosh wrote:
> > On Mon, 28 Nov 2022 17:21:46 -0800, Umesh Nerlige Ramappa wrote:
> >>
> >> +/*
> >> + * Ref: 14010536224:
> >> + * 0x20cc is repurposed on MTL, so use a separate array for MTL.
> >
> > Wondering if it was WAIT_FOR_RC6_EXIT (seen in gen12_oa_mux_regs) which
> > moved elsewhere and if that needs to be added to the array below too?
>
> WAIT_FOR_RC6_EXIT (0x20cc) moved elsewhere so it should be "removed" from
> mtl oa mux array.

What I was saying was let's say WAIT_FOR_RC6_EXIT moved to 0xc0ffee so now
should 0xc0ffee be added to mtl_oa_mux_regs?

>
> >
> >> + */
> >> +static const struct i915_range mtl_oa_mux_regs[] = {
> >> +  { .start = 0x0d00, .end = 0x0d04 }, /* RPM_CONFIG[0-1] */
> >> +  { .start = 0x0d0c, .end = 0x0d2c }, /* NOA_CONFIG[0-8] */
> >> +  { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
> >> +  { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
> >> +};
> >> +
> >>  static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
> >>  {
> >>return reg_in_range_table(addr, gen7_oa_b_counters);
> >> @@ -4349,7 +4372,10 @@ static bool xehp_is_valid_b_counter_addr(struct 
> >> i915_perf *perf, u32 addr)
> >>
> >>  static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
> >>  {
> >> -  return reg_in_range_table(addr, gen12_oa_mux_regs);
> >> +  if (IS_METEORLAKE(perf->i915))
> >> +  return reg_in_range_table(addr, mtl_oa_mux_regs);
> >> +  else
> >> +  return reg_in_range_table(addr, gen12_oa_mux_regs);
> >
> > But otherwise this is:
> >
> > Reviewed-by: Ashutosh Dixit 
>
> I will break them into separate patches though. If the diff is identical, I
> will carry over your R-b on the split patches. Please let me know if that's
> a concern.

No I can quickly review again anyway.

> > If you decide to split the patches, please add my R-b on all the split 
> > patches.

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add support for 32 bit OAG formats in MTL

[Umesh Nerlige Ramappa]

On Tue, Nov 29, 2022 at 05:51:13PM -0800, Dixit, Ashutosh wrote:

On Mon, 28 Nov 2022 17:21:46 -0800, Umesh Nerlige Ramappa wrote:


+/*
+ * Ref: 14010536224:
+ * 0x20cc is repurposed on MTL, so use a separate array for MTL.


Wondering if it was WAIT_FOR_RC6_EXIT (seen in gen12_oa_mux_regs) which
moved elsewhere and if that needs to be added to the array below too?


WAIT_FOR_RC6_EXIT (0x20cc) moved elsewhere so it should be "removed" 
from mtl oa mux array.





+ */
+static const struct i915_range mtl_oa_mux_regs[] = {
+   { .start = 0x0d00, .end = 0x0d04 }, /* RPM_CONFIG[0-1] */
+   { .start = 0x0d0c, .end = 0x0d2c }, /* NOA_CONFIG[0-8] */
+   { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
+   { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
+};
+
 static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
 {
return reg_in_range_table(addr, gen7_oa_b_counters);
@@ -4349,7 +4372,10 @@ static bool xehp_is_valid_b_counter_addr(struct 
i915_perf *perf, u32 addr)

 static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
 {
-   return reg_in_range_table(addr, gen12_oa_mux_regs);
+   if (IS_METEORLAKE(perf->i915))
+   return reg_in_range_table(addr, mtl_oa_mux_regs);
+   else
+   return reg_in_range_table(addr, gen12_oa_mux_regs);


But otherwise this is:

Reviewed-by: Ashutosh Dixit 


I will break them into separate patches though. If the diff is 
identical, I will carry over your R-b on the split patches. Please let 
me know if that's a concern.


Thanks,
Umesh


If you decide to split the patches, please add my R-b on all the split patches.

Re: [Intel-gfx] [PATCH v3 0/2] mei: add timeout to send

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 18:43 +0100, Greg Kroah-Hartman wrote:
> On Wed, Nov 30, 2022 at 09:20:28AM -0500, Rodrigo Vivi wrote:
> > On Wed, Nov 16, 2022 at 02:47:33PM +0200, Alexander Usyskin wrote:
> > > When driver wakes up the firmware from the low power state,
> > > it is sending a memory ready message.
> > > The send is done via synchronous/blocking function to ensure
> > > that firmware is in ready state. However, in case of firmware
> > > undergoing reset send might be block forever.
> > > To address this issue a timeout is added to blocking
> > > write command on the internal bus.
> > > 
> > > Introduce the __mei_cl_send_timeout function to use instead of
> > > __mei_cl_send in cases where timeout is required.
> > > The mei_cl_write has only two callers and there is no need to
> > > split
> > > it into two functions.
> > > 
> > > V2: address review comments:
> > >  - split __mei_cl_send and __mei_cl_send_timeout
> > >  - add units to timeout KDoc
> > >  - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
> > > 
> > > V3: - split the state fix into separate patch
> > >     - document define unit
> > >     - expand timeout KDoc
> > 
> > These 2 patches looks good to me now.
> > 
> > Greg, whenever you review it, please let me know if it is
> > okay to me to push these through the drm-fixes, or if you
> > prefer these to the mei branches.
> 
> These have been in my tree for over a week now, sorry.  No one told
> me
> not to take them...
> 
> {sigh}

no worries at all. The important thing is that the users will get the
fix.
We can keep them in our topic/core-for-CI while our branches are out-
of-sync.

Thanks a lot,
Rodrigo.

> 
> greg k-h

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hdmi: SPD infoframe update for discrete

[Matt Roper]

On Tue, Nov 29, 2022 at 10:05:18PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/hdmi: SPD infoframe update for discrete
> URL   : https://patchwork.freedesktop.org/series/111450/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12446 -> Patchwork_111450v1
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_111450v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_111450v1, 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_111450v1/index.html
> 
> Participating hosts (35 -> 37)
> --
> 
>   Additional (3): bat-atsm-1 fi-tgl-dsi bat-dg1-5 
>   Missing(1): fi-rkl-11600 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_111450v1:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_suspend@basic-s3-without-i915:
> - fi-skl-6600u:   [PASS][1] -> [INCOMPLETE][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12446/fi-skl-6600u/igt@i915_susp...@basic-s3-without-i915.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/fi-skl-6600u/igt@i915_susp...@basic-s3-without-i915.html

Appears to be the same as
https://gitlab.freedesktop.org/drm/intel/-/issues/7614 , just on a
different platform.  Not related to this patch.

This v4 patch is functionally identical to v2 where BAT passed and
full-CI's only failure was also a false positive, so applied to
drm-intel-next.  Thanks for the patch.


Matt

> 
>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_exec_suspend@basic-s0@smem:
> - {bat-atsm-1}:   NOTRUN -> [INCOMPLETE][3]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-atsm-1/igt@gem_exec_suspend@basic...@smem.html
> 
>   * igt@i915_selftest@live@gt_engines:
> - {fi-tgl-dsi}:   NOTRUN -> [DMESG-WARN][4]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/fi-tgl-dsi/igt@i915_selftest@live@gt_engines.html
> 
>   * igt@i915_selftest@live@gt_lrc:
> - {fi-tgl-dsi}:   NOTRUN -> [INCOMPLETE][5]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
> 
>   * igt@i915_suspend@basic-s3-without-i915:
> - {bat-atsm-1}:   NOTRUN -> [SKIP][6]
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_111450v1 that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_lmem_swapping@basic:
> - fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
> similar issues
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
> 
>   * igt@gem_mmap@basic:
> - bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#4083])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-dg1-5/igt@gem_m...@basic.html
> 
>   * igt@gem_tiled_fence_blits@basic:
> - bat-dg1-5:  NOTRUN -> [SKIP][9] ([i915#4077]) +2 similar issues
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html
> 
>   * igt@gem_tiled_pread_basic:
> - bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4079]) +1 similar issue
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
> 
>   * igt@i915_pm_backlight@basic-brightness:
> - bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#7561])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
> 
>   * igt@i915_pm_rps@basic-api:
> - bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#6621])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
> 
>   * igt@i915_selftest@live@gt_heartbeat:
> - fi-apl-guc: NOTRUN -> [DMESG-FAIL][13] ([i915#5334])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
> 
>   * igt@kms_addfb_basic@basic-x-tiled-legacy:
> - bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4212]) +7 similar issues
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111450v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html
> 
>   * 

Re: [Intel-gfx] [PATCH v3 0/2] mei: add timeout to send

[Greg Kroah-Hartman]

On Wed, Nov 30, 2022 at 09:20:28AM -0500, Rodrigo Vivi wrote:
> On Wed, Nov 16, 2022 at 02:47:33PM +0200, Alexander Usyskin wrote:
> > When driver wakes up the firmware from the low power state,
> > it is sending a memory ready message.
> > The send is done via synchronous/blocking function to ensure
> > that firmware is in ready state. However, in case of firmware
> > undergoing reset send might be block forever.
> > To address this issue a timeout is added to blocking
> > write command on the internal bus.
> > 
> > Introduce the __mei_cl_send_timeout function to use instead of
> > __mei_cl_send in cases where timeout is required.
> > The mei_cl_write has only two callers and there is no need to split
> > it into two functions.
> > 
> > V2: address review comments:
> >  - split __mei_cl_send and __mei_cl_send_timeout
> >  - add units to timeout KDoc
> >  - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
> > 
> > V3: - split the state fix into separate patch
> > - document define unit
> > - expand timeout KDoc
> 
> These 2 patches looks good to me now.
> 
> Greg, whenever you review it, please let me know if it is
> okay to me to push these through the drm-fixes, or if you
> prefer these to the mei branches.

These have been in my tree for over a week now, sorry.  No one told me
not to take them...

{sigh}

greg k-h

Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 09:32 -0800, Matt Roper wrote:
> On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> > tile. PXP as a service for supporting workloads with protected
> 
> Drive-by comment:  we've been a bit inconsistent about terminology in
> the past, but my understanding is that we're trying to standardize on
> "GT" for the unit that MTL has two of, and keeping the term "tile"
> for
> the PVC-style unit that is a combination of (GT+lmem).

I agree that this gets really confusing... but it will be hard to
standardize this I'm afraid. Specially when we do the PVC-style-tile a
intel_gt struct and we apparently are doing the same on MTL, no?!

So, unless the topology gets organized in the code with a standard
name, it is hard to demand everyone to use the same one.

Besides that whenever we were discussing the pvc's one we all had
agreed that the term "tile" was bad, hence we focused on keep the
intel_gt ready for that.

Whenever I hear tile I think of the display buffer organization...
and there are other "tiles" examples iirc.

> 
> 
> Matt
> 
> > contexts and protected buffers can be subscribed by process
> > workloads on any tile. However, depending on the platform,
> > only one of the tiles is used for control events pertaining to PXP
> > operation (such as creating the arbitration session and session
> > tear-down).
> > 
> > PXP as a global feature is accessible via batch buffer instructions
> > on any engine/tile and the coherency across tiles is handled
> > implicitly
> > by the HW. In fact, for the foreseeable future, we are expecting
> > this
> > single-control-tile for the PXP subsystem.
> > 
> > In MTL, it's the standalone media tile (not the root tile) because
> > it contains the VDBOX and KCR engine (among the assets PXP relies
> > on
> > for those events).
> > 
> > Looking at the current code design, each tile is represented by the
> > intel_gt structure while the intel_pxp structure currently hangs
> > off the
> > intel_gt structure.
> > 
> > Keeping the intel_pxp structure within the intel_gt structure makes
> > some
> > internal functionalities more straight forward but adds code
> > complexity to
> > code readibility and maintainibility to many external-to-pxp
> > subsystems
> > which may need to pick the correct intel_gt structure. An example
> > of this
> > would be the intel_pxp_is_active or intel_pxp_is_enabled
> > functionality
> > which should be viewed as a global level inquiry, not a per-gt
> > inquiry.
> > 
> > That said, this series promotes the intel_pxp structure into the
> > drm_i915_private structure making it a top-level subsystem and the
> > PXP
> > subsystem will select the control gt internally and keep a pointer
> > to
> > it for internal reference.
> > 
> > Changes from prior revs:
> >    v5: - Switch from series to single patch (Rodrigo).
> >    - change function name from pxp_get_kcr_owner_gt to
> >  pxp_get_ctrl_gt.
> >    - Fix CI BAT failure by removing redundant call to
> > intel_pxp_fini
> >  from driver-remove.
> >    - NOTE: remaining open still persists on using ptr-to-ptr
> >  and back-ptr.
> >    v4: - Instead of maintaining intel_pxp as an intel_gt structure
> > member
> >  and creating a number of convoluted helpers that takes in
> > i915 as
> >  input and redirects to the correct intel_gt or takes any
> > intel_gt
> >  and internally replaces with the correct intel_gt, promote
> > it to
> >  be a top-level i915 structure.
> >    v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
> >  supported/ active_on_gt" (Daniele)
> >    - Upgrade _gt_supports_pxp to replace what was
> > intel_gtpxp_is
> >  supported as the new intel_pxp_is_supported_on_gt to check
> > for
> >  PXP feature support vs the tee support for huc
> > authentication.
> >  Fix pxp-debugfs-registration to use only the former to
> > decide
> >  support. (Daniele)
> >    - Couple minor optimizations.
> >    v2: - Avoid introduction of new device info or gt variables and
> > use
> >  existing checks / macros to differentiate the correct GT-
> > >PXP
> >  control ownership (Daniele Ceraolo Spurio)
> >    - Don't reuse the updated global-checkers for per-GT callers
> > (such
> >  as other files within PXP) to avoid unnecessary GT-
> > reparsing,
> >  expose a replacement helper like the prior ones.
> > (Daniele).
> >    v1: - Add one more patch to the series for the intel_pxp
> > suspend/resume
> >  for similar refactoring
> > 
> > Signed-off-by: Alan Previn 
> > ---
> >  .../drm/i915/display/skl_universal_plane.c    |  2 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  6 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_create.c    |  2 +-
> >  .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |  2 +-
> >  drivers/gpu/drm/i915/gt/intel_gt.c 

Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Matt Roper]

On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected

Drive-by comment:  we've been a bit inconsistent about terminology in
the past, but my understanding is that we're trying to standardize on
"GT" for the unit that MTL has two of, and keeping the term "tile" for
the PVC-style unit that is a combination of (GT+lmem).


Matt

> contexts and protected buffers can be subscribed by process
> workloads on any tile. However, depending on the platform,
> only one of the tiles is used for control events pertaining to PXP
> operation (such as creating the arbitration session and session
> tear-down).
> 
> PXP as a global feature is accessible via batch buffer instructions
> on any engine/tile and the coherency across tiles is handled implicitly
> by the HW. In fact, for the foreseeable future, we are expecting this
> single-control-tile for the PXP subsystem.
> 
> In MTL, it's the standalone media tile (not the root tile) because
> it contains the VDBOX and KCR engine (among the assets PXP relies on
> for those events).
> 
> Looking at the current code design, each tile is represented by the
> intel_gt structure while the intel_pxp structure currently hangs off the
> intel_gt structure.
> 
> Keeping the intel_pxp structure within the intel_gt structure makes some
> internal functionalities more straight forward but adds code complexity to
> code readibility and maintainibility to many external-to-pxp subsystems
> which may need to pick the correct intel_gt structure. An example of this
> would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
> which should be viewed as a global level inquiry, not a per-gt inquiry.
> 
> That said, this series promotes the intel_pxp structure into the
> drm_i915_private structure making it a top-level subsystem and the PXP
> subsystem will select the control gt internally and keep a pointer to
> it for internal reference.
> 
> Changes from prior revs:
>v5: - Switch from series to single patch (Rodrigo).
>- change function name from pxp_get_kcr_owner_gt to
>  pxp_get_ctrl_gt.
>- Fix CI BAT failure by removing redundant call to intel_pxp_fini
>  from driver-remove.
>- NOTE: remaining open still persists on using ptr-to-ptr
>  and back-ptr.
>v4: - Instead of maintaining intel_pxp as an intel_gt structure member
>  and creating a number of convoluted helpers that takes in i915 as
>  input and redirects to the correct intel_gt or takes any intel_gt
>  and internally replaces with the correct intel_gt, promote it to
>  be a top-level i915 structure.
>v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
>  supported/ active_on_gt" (Daniele)
>- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
>  supported as the new intel_pxp_is_supported_on_gt to check for
>  PXP feature support vs the tee support for huc authentication.
>  Fix pxp-debugfs-registration to use only the former to decide
>  support. (Daniele)
>- Couple minor optimizations.
>v2: - Avoid introduction of new device info or gt variables and use
>  existing checks / macros to differentiate the correct GT->PXP
>  control ownership (Daniele Ceraolo Spurio)
>- Don't reuse the updated global-checkers for per-GT callers (such
>  as other files within PXP) to avoid unnecessary GT-reparsing,
>  expose a replacement helper like the prior ones. (Daniele).
>v1: - Add one more patch to the series for the intel_pxp suspend/resume
>  for similar refactoring
> 
> Signed-off-by: Alan Previn 
> ---
>  .../drm/i915/display/skl_universal_plane.c|  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  6 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c|  2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c|  5 --
>  drivers/gpu/drm/i915/gt/intel_gt_debugfs.c|  1 -
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |  8 ---
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 -
>  drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c |  2 +-
>  drivers/gpu/drm/i915/i915_driver.c| 18 +
>  drivers/gpu/drm/i915/i915_drv.h   |  3 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 72 ++-
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  |  6 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c  |  8 ++-
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c  | 41 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h  |  4 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  | 10 ++-
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c   |  4 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  |  8 ++-
>  

Re: [Intel-gfx] [linux-gfx] [PATCH] drm/i915/pvc: Implement recommended caching policy

[Matt Roper]

On Wed, Nov 30, 2022 at 09:07:23AM -0800, Wayne Boyer wrote:
> As per the performance tuning guide, set the HOSTCACHEEN bit to
> implement the recommended caching policy on PVC.
> 
> Signed-off-by: Wayne Boyer 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 784152548472..f96570995cfc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -973,6 +973,7 @@
>  #define   GEN7_L3AGDIS   (1 << 19)
>  
>  #define XEHPC_LNCFMISCCFGREG0_MMIO(0xb01c)
> +#define   XEHPC_HOSTCACHEEN  REG_BIT(1)
>  #define   XEHPC_OVRLSCCC REG_BIT(0)
>  
>  #define GEN7_L3CNTLREG2  _MMIO(0xb020)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 1b0e40e68a9d..35e3f43e8b06 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2903,6 +2903,7 @@ add_render_compute_tuning_settings(struct 
> drm_i915_private *i915,
>   if (IS_PONTEVECCHIO(i915)) {
>   wa_write(wal, XEHPC_L3SCRUB,
>SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> + wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
>   }
>  
>   if (IS_DG2(i915)) {
> -- 
> 2.37.3
> 

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: dedicated MCR locking and hardware semaphore (rev2)

[Matt Roper]

On Tue, Nov 29, 2022 at 06:15:23AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: dedicated MCR locking and hardware semaphore (rev2)
> URL   : https://patchwork.freedesktop.org/series/111220/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12440_full -> Patchwork_111220v2_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_111220v2_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_111220v2_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (10 -> 10)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_111220v2_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_ctx_isolation@preservation-s3@bcs0:
> - shard-tglb: [PASS][1] -> [INCOMPLETE][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12440/shard-tglb3/igt@gem_ctx_isolation@preservation...@bcs0.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-tglb8/igt@gem_ctx_isolation@preservation...@bcs0.html

System never came back from suspend.  Not related to this series.

First three patches of the series applied to drm-intel-gt-next.


Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_111220v2_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_persistence@smoketest:
> - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#5099])
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12440/shard-iclb3/igt@gem_ctx_persiste...@smoketest.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb5/igt@gem_ctx_persiste...@smoketest.html
> 
>   * igt@gem_exec_balancer@parallel:
> - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar 
> issue
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12440/shard-iclb2/igt@gem_exec_balan...@parallel.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb8/igt@gem_exec_balan...@parallel.html
> 
>   * igt@gem_exec_fair@basic-pace@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
> 
>   * igt@gem_exec_params@secure-non-root:
> - shard-iclb: NOTRUN -> [SKIP][8] ([fdo#112283])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb8/igt@gem_exec_par...@secure-non-root.html
> 
>   * igt@gem_huc_copy@huc-copy:
> - shard-apl:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-apl7/igt@gem_huc_c...@huc-copy.html
> 
>   * igt@gem_lmem_swapping@heavy-verify-random:
> - shard-apl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-apl1/igt@gem_lmem_swapp...@heavy-verify-random.html
> 
>   * igt@gem_lmem_swapping@parallel-random-verify:
> - shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-skl10/igt@gem_lmem_swapp...@parallel-random-verify.html
> 
>   * igt@gem_lmem_swapping@verify-random-ccs:
> - shard-tglb: NOTRUN -> [SKIP][12] ([i915#4613])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-tglb6/igt@gem_lmem_swapp...@verify-random-ccs.html
> 
>   * igt@gem_pxp@create-protected-buffer:
> - shard-iclb: NOTRUN -> [SKIP][13] ([i915#4270])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb8/igt@gem_...@create-protected-buffer.html
> 
>   * igt@gem_render_copy@x-tiled-to-vebox-y-tiled:
> - shard-iclb: NOTRUN -> [SKIP][14] ([i915#768])
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb8/igt@gem_render_c...@x-tiled-to-vebox-y-tiled.html
> 
>   * igt@gem_userptr_blits@coherency-unsync:
> - shard-iclb: NOTRUN -> [SKIP][15] ([i915#3297]) +2 similar issues
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-iclb8/igt@gem_userptr_bl...@coherency-unsync.html
> 
>   * igt@gem_userptr_blits@input-checking:
> - shard-skl:  NOTRUN -> [DMESG-WARN][16] ([i915#4991])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v2/shard-skl9/igt@gem_userptr_bl...@input-checking.html
> 
>   * 

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

[Ceraolo Spurio, Daniele]

On 11/29/2022 3:48 PM, Teres Alexis, Alan Previn wrote:

Besides the nit below, just would like to echo the same thing Nikula said about 
not including the type definition in the
main uc header (which i know can be a bit more work especially if we go with 
allocation of the structure at init time
and using a ptr in the uc structure).


I had a stab at this and it is quite complicated due to the 
inter-dependencies between the headers. Even if I split out the type to 
its own header, I'd have to include it in the current one for the status 
checker functions to work, so there would be no gain. The whole 
infrastructure needs to be reworked so that the headers can be fully 
decoupled. I have a few ideas on how to go at that and I'll try to send 
out a few patches on the side to get that effort going.



That said,
Reviewed-by: Alan Previn 

On Mon, 2022-11-21 at 15:16 -0800, Ceraolo Spurio, Daniele wrote:

On MTL the GSC FW needs to be loaded on the media GT by the graphics


@@ -246,6 +253,10 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
int i;
bool found;
  
+	/* FW is not defined until all the support is in place */

Nit: perhaps a little bit more explanation would be better here for folks 
reading thru the codes


Not sure what extra explanation I can provide here. The reason we're not 
defining the blob is because the support code is not fully there, there 
is no need to go into details of what's actually missing as that will 
evolve with time. I can however rephrase this if you think the current 
sentence is not clear, would something like this work:
"GSC FW support is still not fully in place, so we're not defining the 
FW blob yet because we don't want the driver to attempt to load it until 
we're ready for it".


Daniele


+   if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
+   return;
+

[Intel-gfx] [linux-gfx] [PATCH] drm/i915/pvc: Implement recommended caching policy

[Wayne Boyer]

As per the performance tuning guide, set the HOSTCACHEEN bit to
implement the recommended caching policy on PVC.

Signed-off-by: Wayne Boyer 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 784152548472..f96570995cfc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -973,6 +973,7 @@
 #define   GEN7_L3AGDIS (1 << 19)
 
 #define XEHPC_LNCFMISCCFGREG0  _MMIO(0xb01c)
+#define   XEHPC_HOSTCACHEENREG_BIT(1)
 #define   XEHPC_OVRLSCCC   REG_BIT(0)
 
 #define GEN7_L3CNTLREG2_MMIO(0xb020)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 1b0e40e68a9d..35e3f43e8b06 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2903,6 +2903,7 @@ add_render_compute_tuning_settings(struct 
drm_i915_private *i915,
if (IS_PONTEVECCHIO(i915)) {
wa_write(wal, XEHPC_L3SCRUB,
 SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
+   wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
}
 
if (IS_DG2(i915)) {
-- 
2.37.3

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

[Patchwork]

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_12455 -> Patchwork_111220v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_111220v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_111220v3, 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_111220v3/index.html

Participating hosts (29 -> 32)
--

  Additional (5): fi-kbl-7567u fi-glk-dsi fi-glk-j4005 fi-kbl-x1275 
fi-kbl-8809g 
  Missing(2): bat-dg1-6 fi-skl-6600u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-elk-e7500:   [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/fi-elk-e7500/igt@i915_susp...@basic-s2idle-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-elk-e7500/igt@i915_susp...@basic-s2idle-without-i915.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12455/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-7567u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-7567u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-glk-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-glk-j4005:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html
- fi-kbl-7567u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-7567u/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-glk-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@gem_lmem_swapp...@verify-random.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_blits@basic:
- fi-glk-dsi: NOTRUN -> [SKIP][14] ([fdo#109271]) +12 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_module_load@reload:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][15] ([i915#6899])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-8809g/igt@i915_module_l...@reload.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-glk-dsi: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-glk-dsi/igt@kms_chamel...@dp-crc-fast.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111220v3/fi-kbl-x1275/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-7567u:   NOTRUN -> [SKIP][18] ([fdo#109271] / 

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

[Patchwork]

== Series Details ==

Series: i915: dedicated MCR locking and hardware semaphore (rev3)
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 series starting with [v5,1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use

[Patchwork]

== Series Details ==

Series: series starting with [v5,1/4] i915: Move list_count() to list.h as 
list_count_nodes() for broader use
URL   : https://patchwork.freedesktop.org/series/111482/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12455 -> Patchwork_111482v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (29 -> 32)
--

  Additional (5): fi-kbl-7567u fi-glk-dsi fi-glk-j4005 fi-kbl-x1275 
fi-kbl-8809g 
  Missing(2): bat-dg1-6 fi-skl-6600u 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-7567u:   NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-7567u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-glk-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-glk-j4005:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html
- fi-kbl-7567u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-7567u/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-glk-dsi: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-dsi/igt@gem_lmem_swapp...@verify-random.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_blits@basic:
- fi-glk-dsi: NOTRUN -> [SKIP][10] ([fdo#109271]) +12 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_module_load@reload:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][11] ([i915#6899])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-8809g/igt@i915_module_l...@reload.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-glk-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-dsi/igt@kms_chamel...@dp-crc-fast.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-x1275/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-glk-j4005:   NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-glk-j4005/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@vga-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-8809g/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-kbl-8809g:   NOTRUN -> [SKIP][17] ([fdo#109271]) +24 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-8809g/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_psr@cursor_plane_move:
- fi-kbl-7567u:   NOTRUN -> [SKIP][18] ([fdo#109271]) +30 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111482v1/fi-kbl-7567u/igt@kms_psr@cursor_plane_move.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-glk-j4005:   NOTRUN -> [SKIP][19] ([fdo#109271]) +9 

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915/mtl: Hold forcewake and MCR lock over PPAT setup

[Matt Roper]

On Wed, Nov 30, 2022 at 09:21:07PM +0530, Balasubramani Vivekanandan wrote:
> On 28.11.2022 15:30, Matt Roper wrote:
> > PPAT setup involves a series of multicast writes.  This can be optimized
> > slightly be acquiring forcewake and the steering lock just once for the
> > entire sequence.
> > 
> > Suggested-by: Balasubramani Vivekanandan 
> > 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +++
> >  1 file changed, 19 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > index 2ba3983984b9..288d9f118ee9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > @@ -482,14 +482,25 @@ static void tgl_setup_private_ppat(struct 
> > intel_uncore *uncore)
> >  
> >  static void xehp_setup_private_ppat(struct intel_gt *gt)
> >  {
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
> > -   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
> > +   enum forcewake_domains fw;
> > +   unsigned long flags;
> > +
> > +   fw = intel_uncore_forcewake_for_reg(gt->uncore, 
> > _MMIO(XEHP_PAT_INDEX(0).reg),
> > +   FW_REG_READ);
> 
> I am not completely aware of forcewake implementation. I am wondering if
> the last parameter should be FW_REG_WRITE since it is register write
> which is happening later.

Yep, good catch.  Using FW_REG_WRITE allows the driver to potentially
skip obtaining forcewake and waking the hardware if the registers being
written are "shadowed" so it's always good to use FW_REG_WRITE in places
where we're only writing and not reading.

In this case the specific registers in question don't appear to be part
of the shadow table for any affected platforms (e.g.,
dg2_shadowed_regs[] and such in intel_uncore.c), so FW_REG_WRITE will
still behave the same as FW_REG_READ here.  But it's always possible
that future platforms could decide to shadow these registers, so it's
good to fix anyway; I just sent an updated copy of this patch making
that change.


Matt

> 
> Regards,
> Bala
> 
> > +   intel_uncore_forcewake_get(gt->uncore, fw);
> > +
> > +   intel_gt_mcr_lock(gt, );
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
> > +   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
> > +   intel_gt_mcr_unlock(gt, flags);
> > +
> > +   intel_uncore_forcewake_put(gt->uncore, fw);
> >  }
> >  
> >  static void icl_setup_private_ppat(struct intel_uncore *uncore)
> > -- 
> > 2.38.1
> > 

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

[Intel-gfx] [PATCH v3 5/5] drm/i915/mtl: Hold forcewake and MCR lock over PPAT setup

[Matt Roper]

PPAT setup involves a series of multicast writes.  This can be optimized
slightly be acquiring forcewake and the steering lock just once for the
entire sequence.

v2:
 - We should use FW_REG_WRITE instead of FW_REG_READ.  (Bala)

Suggested-by: Balasubramani Vivekanandan 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2ba3983984b9..e37164a60d37 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -482,14 +482,25 @@ static void tgl_setup_private_ppat(struct intel_uncore 
*uncore)
 
 static void xehp_setup_private_ppat(struct intel_gt *gt)
 {
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
-   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
+   enum forcewake_domains fw;
+   unsigned long flags;
+
+   fw = intel_uncore_forcewake_for_reg(gt->uncore, 
_MMIO(XEHP_PAT_INDEX(0).reg),
+   FW_REG_WRITE);
+   intel_uncore_forcewake_get(gt->uncore, fw);
+
+   intel_gt_mcr_lock(gt, );
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
+   intel_gt_mcr_unlock(gt, flags);
+
+   intel_uncore_forcewake_put(gt->uncore, fw);
 }
 
 static void icl_setup_private_ppat(struct intel_uncore *uncore)
-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v5,1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use

[Patchwork]

== Series Details ==

Series: series starting with [v5,1/4] i915: Move list_count() to list.h as 
list_count_nodes() for broader use
URL   : https://patchwork.freedesktop.org/series/111482/
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 v2 5/5] drm/i915/mtl: Hold forcewake and MCR lock over PPAT setup

[Balasubramani Vivekanandan]

On 28.11.2022 15:30, Matt Roper wrote:
> PPAT setup involves a series of multicast writes.  This can be optimized
> slightly be acquiring forcewake and the steering lock just once for the
> entire sequence.
> 
> Suggested-by: Balasubramani Vivekanandan 
> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 2ba3983984b9..288d9f118ee9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -482,14 +482,25 @@ static void tgl_setup_private_ppat(struct intel_uncore 
> *uncore)
>  
>  static void xehp_setup_private_ppat(struct intel_gt *gt)
>  {
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
> - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
> + enum forcewake_domains fw;
> + unsigned long flags;
> +
> + fw = intel_uncore_forcewake_for_reg(gt->uncore, 
> _MMIO(XEHP_PAT_INDEX(0).reg),
> + FW_REG_READ);

I am not completely aware of forcewake implementation. I am wondering if
the last parameter should be FW_REG_WRITE since it is register write
which is happening later.

Regards,
Bala

> + intel_uncore_forcewake_get(gt->uncore, fw);
> +
> + intel_gt_mcr_lock(gt, );
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
> + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
> + intel_gt_mcr_unlock(gt, flags);
> +
> + intel_uncore_forcewake_put(gt->uncore, fw);
>  }
>  
>  static void icl_setup_private_ppat(struct intel_uncore *uncore)
> -- 
> 2.38.1
> 

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

[Balasubramani Vivekanandan]

On 28.11.2022 15:30, Matt Roper wrote:
> 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.
> 
> v2:
>  - Use irqsave/irqrestore spinlock calls; platforms using execlist
>submission rather than GuC submission can perform MCR accesses in
>interrupt context because reset -> errordump happens in a tasklet.
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Balasubramani Vivekanandan 
> Signed-off-by: Matt Roper 

Reviewed-by: Balasubramani Vivekanandan 

Regards,
Bala

> ---
>  drivers/gpu/drm/i915/gt/intel_gt.c  |  7 +-
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 79 +++--
>  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|  3 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 ++--
>  6 files changed, 101 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 7ef0edb2e37c..6847f3bd2b03 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -1079,6 +1079,7 @@ static void mmio_invalidate_full(struct intel_gt *gt)
>   enum intel_engine_id id;
>   const i915_reg_t *regs;
>   unsigned int num = 0;
> + unsigned long flags;
>  
>   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
>   regs = NULL;
> @@ -1099,7 +1100,8 @@ static void mmio_invalidate_full(struct intel_gt *gt)
>  
>   intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
>  
> - spin_lock_irq(>lock); /* serialise invalidate with GT reset */
> + intel_gt_mcr_lock(gt, );
> + spin_lock(>lock); /* serialise invalidate with GT reset */
>  
>   awake = 0;
>   for_each_engine(engine, gt, id) {
> @@ -1133,7 +1135,8 @@ static void mmio_invalidate_full(struct intel_gt *gt)
>IS_ALDERLAKE_P(i915)))
>   intel_uncore_write_fw(uncore, GEN12_OA_TLB_INV_CR, 1);
>  
> - spin_unlock_irq(>lock);
> + spin_unlock(>lock);
> + intel_gt_mcr_unlock(gt, flags);
>  
>   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..aa070ae57f11 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)) {
>   /*
> @@ -316,6 +319,7 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
>  {
>   struct intel_uncore *uncore = gt->uncore;
>   enum forcewake_domains fw_domains;
> + unsigned long flags;
>   u32 val;
>  
>   fw_domains = intel_uncore_forcewake_for_reg(uncore, mcr_reg_cast(reg),
> @@ -324,17 +328,59 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
>GEN8_MCR_SELECTOR,
>FW_REG_READ | 
> FW_REG_WRITE);
>  
> - spin_lock_irq(>lock);
> + intel_gt_mcr_lock(gt, );
> + spin_lock(>lock);
>   intel_uncore_forcewake_get__locked(uncore, fw_domains);
>  
>   val = rw_with_mcr_steering_fw(gt, reg, rw_flag, group, instance, value);
>  

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

[Balasubramani Vivekanandan]

On 28.11.2022 15:30, Matt Roper wrote:
> 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
> following patch.
> 
> Signed-off-by: Matt Roper 

Reviewed-by: Balasubramani Vivekanandan 

Regards,
Bala

> ---
>  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
> 

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

[Balasubramani Vivekanandan]

On 28.11.2022 15:30, Matt Roper wrote:
> 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 

Reviewed-by: Balasubramani Vivekanandan 

Regards,
Bala

> ---
>  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
> 

Re: [Intel-gfx] [PATCH v3 0/2] mei: add timeout to send

[Rodrigo Vivi]

On Wed, Nov 16, 2022 at 02:47:33PM +0200, Alexander Usyskin wrote:
> When driver wakes up the firmware from the low power state,
> it is sending a memory ready message.
> The send is done via synchronous/blocking function to ensure
> that firmware is in ready state. However, in case of firmware
> undergoing reset send might be block forever.
> To address this issue a timeout is added to blocking
> write command on the internal bus.
> 
> Introduce the __mei_cl_send_timeout function to use instead of
> __mei_cl_send in cases where timeout is required.
> The mei_cl_write has only two callers and there is no need to split
> it into two functions.
> 
> V2: address review comments:
>  - split __mei_cl_send and __mei_cl_send_timeout
>  - add units to timeout KDoc
>  - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
> 
> V3: - split the state fix into separate patch
> - document define unit
> - expand timeout KDoc

These 2 patches looks good to me now.

Greg, whenever you review it, please let me know if it is
okay to me to push these through the drm-fixes, or if you
prefer these to the mei branches.

Btw, Alexander, would we have a good "Fixes:" tag for these
patches?

Thanks,
Rodrigo.

> 
> Alexander Usyskin (2):
>   mei: add timeout to send
>   mei: bus-fixup: change pxp mode only if message was sent
> 
>  drivers/misc/mei/bus-fixup.c | 14 +-
>  drivers/misc/mei/bus.c   | 22 +-
>  drivers/misc/mei/client.c| 20 
>  drivers/misc/mei/client.h|  2 +-
>  drivers/misc/mei/main.c  |  2 +-
>  drivers/misc/mei/mei_dev.h   |  2 ++
>  6 files changed, 50 insertions(+), 12 deletions(-)
> 
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PULL] drm-misc-fixes

[Daniel Vetter]

On Wed, 30 Nov 2022 at 14:43, Maxime Ripard  wrote:
>
> Hi Maarten
>
> On Wed, Nov 30, 2022 at 02:16:05PM +0100, Maarten Lankhorst wrote:
> > A single fix to vmwgfx mks-guest-stats ioctl.
> > I lost my internet connection when pushing the tag, so I put together this 
> > mail
> > manually. I hope you remember where drm-misc is hosted. :)
>
> For reference, you can generate the mail content after the fact by using 
> something like:
>
> git request-pull drm/fixes drm-misc drm-misc-fixes-2022-11-30

Maarten, can you pls do that? Otherwise we can't feed the thing into
dim for processing, and have to do that also manually :-)
-Daniel

>
> Maxime



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 10:42 -0300, Gustavo Sousa wrote:
> On Thu, Nov 24, 2022 at 01:27:40PM -0300, Gustavo Sousa wrote:
> > Just a quick note: firmware PR hasn't been applied yet. Waiting...
> 
> Firmware PR merged into linux-firmware!

Thanks for the patch and the heads up.

Patch is now pushed to drm-intel-next and already cherry-picked to
drm-intel-next-fixes.

> 
> --
> Gustavo Sousa

Re: [Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait

[Daniel Vetter]

On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
 wrote:
> On 29/11/2022 18:05, Matthew Auld wrote:
> > On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> + Matt
> >>
> >> On 25/11/2022 10:21, Christian König wrote:
> >>> TTM is just wrapping core DMA functionality here, remove the mid-layer.
> >>> No functional change.
> >>>
> >>> Signed-off-by: Christian König 
> >>> ---
> >>>drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
> >>>1 file changed, 6 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> index 5247d88b3c13..d409a77449a3 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> @@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object 
> >>> *obj,
> >>>static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
> >>>{
> >>>struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> >>> - int err;
> >>> + long err;
> >>>
> >>>WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
> >>>
> >>> - err = ttm_bo_wait(bo, true, false);
> >>> - if (err)
> >>> + err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
> >>> + true, 15 * HZ);
> >>
> >> This 15 second stuck out a bit for me and then on a slightly deeper look
> >> it seems this timeout will "leak" into a few of i915 code paths. If we
> >> look at the difference between the legacy shmem and ttm backend I am not
> >> sure if the legacy one is blocking or not - but if it can block I don't
> >> think it would have an arbitrary timeout like this. Matt your thoughts?
> >
> > Not sure what is meant by leak here, but the legacy shmem must also
> > wait/block when unbinding each VMA, before calling truncate. It's the
>
> By "leak" I meant if 15s timeout propagates into some code paths visible
> from userspace which with a legacy backend instead have an indefinite
> wait. If we have that it's probably not very good to have this
> inconsistency, or to apply an arbitrary timeout to those path to start with.
>
> > same story for the ttm backend, except slightly more complicated in
> > that there might be no currently bound VMA, and yet the GPU could
> > still be accessing the pages due to async unbinds, kernel moves etc,
> > which the wait here (and in i915_ttm_shrink) is meant to protect
> > against. If the wait times out it should just fail gracefully. I guess
> > we could just use MAX_SCHEDULE_TIMEOUT here? Not sure if it really
> > matters though.
>
> Right, depends if it can leak or not to userspace and diverge between
> backends.

Generally lock_timeout() is a design bug. It's either
lock_interruptible (or maybe lock_killable) or try_lock, but
lock_timeout is just duct-tape. I haven't dug in to figure out what
should be here, but it smells fishy.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Andy Shevchenko]

Some of the existing users, and definitely will be new ones, want to
count existing nodes in the list. Provide a generic API for that by
moving code from i915 to list.h.

Reviewed-by: Lucas De Marchi 
Acked-by: Jani Nikula 
Signed-off-by: Andy Shevchenko 
---
v5: added tag (Lucas), renamed API to list_count_nodes() (LKP)
v4: fixed prototype when converting to static inline
v3: added tag (Jani), changed to be static inline (Mike)
v2: dropped the duplicate code in i915 (LKP)
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 15 ++-
 include/linux/list.h  | 15 +++
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1f7188129cd1..370164363b0d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2004,17 +2004,6 @@ static void print_request_ring(struct drm_printer *m, 
struct i915_request *rq)
}
 }
 
-static unsigned long list_count(struct list_head *list)
-{
-   struct list_head *pos;
-   unsigned long count = 0;
-
-   list_for_each(pos, list)
-   count++;
-
-   return count;
-}
-
 static unsigned long read_ul(void *p, size_t x)
 {
return *(unsigned long *)(p + x);
@@ -2189,8 +2178,8 @@ void intel_engine_dump(struct intel_engine_cs *engine,
spin_lock_irqsave(>sched_engine->lock, flags);
engine_dump_active_requests(engine, m);
 
-   drm_printf(m, "\tOn hold?: %lu\n",
-  list_count(>sched_engine->hold));
+   drm_printf(m, "\tOn hold?: %zu\n",
+  list_count_nodes(>sched_engine->hold));
spin_unlock_irqrestore(>sched_engine->lock, flags);
 
drm_printf(m, "\tMMIO base:  0x%08x\n", engine->mmio_base);
diff --git a/include/linux/list.h b/include/linux/list.h
index 61762054b4be..f10344dbad4d 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -655,6 +655,21 @@ static inline void list_splice_tail_init(struct list_head 
*list,
 !list_is_head(pos, (head)); \
 pos = n, n = pos->prev)
 
+/**
+ * list_count_nodes - count nodes in the list
+ * @head:  the head for your list.
+ */
+static inline size_t list_count_nodes(struct list_head *head)
+{
+   struct list_head *pos;
+   size_t count = 0;
+
+   list_for_each(pos, head)
+   count++;
+
+   return count;
+}
+
 /**
  * list_entry_is_head - test if the entry points to the head of the list
  * @pos:   the type * to cursor
-- 
2.35.1

[Intel-gfx] [PATCH v5 3/4] usb: gadget: udc: bcm63xx: Convert to use list_count_nodes()

[Andy Shevchenko]

The list API provides the list_count_nodes() to help with counting
existing nodes in the list. Utilise it.

Signed-off-by: Andy Shevchenko 
---
v5: used renamed API (LKP)
v4: no change
v3: no change
v2: no change
 drivers/usb/gadget/udc/bcm63xx_udc.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/udc/bcm63xx_udc.c 
b/drivers/usb/gadget/udc/bcm63xx_udc.c
index 2cdb07905bde..771ba1ffce95 100644
--- a/drivers/usb/gadget/udc/bcm63xx_udc.c
+++ b/drivers/usb/gadget/udc/bcm63xx_udc.c
@@ -2172,7 +2172,6 @@ static int bcm63xx_iudma_dbg_show(struct seq_file *s, 
void *p)
 
for (ch_idx = 0; ch_idx < BCM63XX_NUM_IUDMA; ch_idx++) {
struct iudma_ch *iudma = >iudma[ch_idx];
-   struct list_head *pos;
 
seq_printf(s, "IUDMA channel %d -- ", ch_idx);
switch (iudma_defaults[ch_idx].ep_type) {
@@ -2205,14 +2204,10 @@ static int bcm63xx_iudma_dbg_show(struct seq_file *s, 
void *p)
seq_printf(s, "  desc: %d/%d used", iudma->n_bds_used,
   iudma->n_bds);
 
-   if (iudma->bep) {
-   i = 0;
-   list_for_each(pos, >bep->queue)
-   i++;
-   seq_printf(s, "; %d queued\n", i);
-   } else {
+   if (iudma->bep)
+   seq_printf(s, "; %zu queued\n", 
list_count_nodes(>bep->queue));
+   else
seq_printf(s, "\n");
-   }
 
for (i = 0; i < iudma->n_bds; i++) {
struct bcm_enet_desc *d = >bd_ring[i];
-- 
2.35.1

[Intel-gfx] [PATCH v5 2/4] usb: gadget: hid: Convert to use list_count_nodes()

[Andy Shevchenko]

The list API provides the list_count_nodes() to help with counting
existing nodes in the list. Utilise it.

Signed-off-by: Andy Shevchenko 
---
v5: used renamed API (LKP)
v4: no change
v3: fixed typo in the commit message (Fabio)
 
v2: no change
 drivers/usb/gadget/legacy/hid.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 1187ee4f316a..133daf88162e 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -133,14 +133,11 @@ static struct usb_configuration config_driver = {
 static int hid_bind(struct usb_composite_dev *cdev)
 {
struct usb_gadget *gadget = cdev->gadget;
-   struct list_head *tmp;
struct hidg_func_node *n = NULL, *m, *iter_n;
struct f_hid_opts *hid_opts;
-   int status, funcs = 0;
-
-   list_for_each(tmp, _func_list)
-   funcs++;
+   int status, funcs;
 
+   funcs = list_count_nodes(_func_list);
if (!funcs)
return -ENODEV;
 
-- 
2.35.1

[Intel-gfx] [PATCH v5 4/4] xhci: Convert to use list_count_nodes()

[Andy Shevchenko]

The list API provides the list_count_nodes() to help with counting
existing nodes in the list. Utilise it.

Acked-by: Mathias Nyman 
Signed-off-by: Andy Shevchenko 
---
v5: used renamed API (LKP)
v4: added tag (Mathias)
v3: no change
v2: no change
 drivers/usb/host/xhci-ring.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ddc30037f9ce..aa4d34efecd2 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2528,7 +2528,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
union xhci_trb *ep_trb;
int status = -EINPROGRESS;
struct xhci_ep_ctx *ep_ctx;
-   struct list_head *tmp;
u32 trb_comp_code;
int td_num = 0;
bool handling_skipped_tds = false;
@@ -2582,10 +2581,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
}
 
/* Count current td numbers if ep->skip is set */
-   if (ep->skip) {
-   list_for_each(tmp, _ring->td_list)
-   td_num++;
-   }
+   if (ep->skip)
+   td_num += list_count_nodes(_ring->td_list);
 
/* Look for common error cases */
switch (trb_comp_code) {
-- 
2.35.1

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

[Gustavo Sousa]

Thank you both for the instructive feedback! :-)

--
Gustavo Sousa

Re: [Intel-gfx] [PULL] drm-misc-fixes

[Maxime Ripard]

Hi Maarten

On Wed, Nov 30, 2022 at 02:16:05PM +0100, Maarten Lankhorst wrote:
> A single fix to vmwgfx mks-guest-stats ioctl.
> I lost my internet connection when pushing the tag, so I put together this 
> mail
> manually. I hope you remember where drm-misc is hosted. :)

For reference, you can generate the mail content after the fact by using 
something like:

git request-pull drm/fixes drm-misc drm-misc-fixes-2022-11-30

Maxime


signature.asc
Description: PGP signature

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

[Gustavo Sousa]

On Thu, Nov 24, 2022 at 01:27:40PM -0300, Gustavo Sousa wrote:
> Just a quick note: firmware PR hasn't been applied yet. Waiting...

Firmware PR merged into linux-firmware!

--
Gustavo Sousa

Re: [Intel-gfx] [PATCH] drm/i915: Remove CONFIG_PM dependency from RC6.

[Vivi, Rodrigo]

On Wed, 2022-11-30 at 11:47 +, Tvrtko Ursulin wrote:
> 
> On 30/11/2022 02:29, Rodrigo Vivi wrote:
> > RC6 is a sleep state that doesn't depend on the cpu sleep,
> > or any of the APM or ACPI or anything related to the
> > CONFIG_PM.
> > 
> > A long time ago we have removed the module parameter
> > that allows the RC6 disablement. We want that feature enabled
> > everywhere. However, for some reason this CONFIG_PM was long
> > forgotten behind.
> > 
> > If we end up needing knobs to disable RC6 we should create
> > individual ones, rather than relying on this master one.
> 
> Digging in history shows 5ab3633d6907 ("drm/i915: make rc6 in sysfs 
> functions conditional") and then it appears the issue could still be 
> present, since we still use power_group_name which is NULL when
> !CONFIG_PM.

oh, indeed!
So, we should probably go with Paul's proposal:
https://lists.freedesktop.org/archives/intel-gfx/2022-November/311569.html
> 
> $ ls -l /sys/class/drm/card0/power/
> total 0
> -rw-r--r-- 1 root root 4096 Nov 30 11:45 async
> -rw-r--r-- 1 root root 4096 Nov 30 11:45 autosuspend_delay_ms
> -rw-r--r-- 1 root root 4096 Nov 30 11:45 control
> -r--r--r-- 1 root root 4096 Nov 30 11:45 rc6_enable
> -r--r--r-- 1 root root 4096 Nov 30 11:45 rc6_residency_ms
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_active_kids
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_active_time
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_enabled
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_status
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_suspended_time
> -r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_usage
> 
> Other than rc6 entries I guess come from somewhere else but I haven't
> looked from where exactly.


Ouch! Everything else here comes from the pci's pm_runtime.
Probably our bad decision was to add rc6 to it.
But we do need to stick to that.


> 
> Regards,
> 
> Tvrtko
> 
> > Cc: Paul Cercueil 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 --
> >   1 file changed, 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> > index cf71305ad586..77327ede18ad 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> > @@ -164,7 +164,6 @@ sysfs_gt_attribute_r_func(struct kobject *kobj,
> > struct attribute *attr,
> > 
> > NULL); \
> > INTEL_GT_ATTR_RO(_name)
> >   
> > -#ifdef CONFIG_PM
> >   static u32 get_residency(struct intel_gt *gt, enum
> > intel_rc6_res_type id)
> >   {
> > intel_wakeref_t wakeref;
> > @@ -329,11 +328,6 @@ static void intel_sysfs_rc6_init(struct
> > intel_gt *gt, struct kobject *kobj)
> >  gt->info.id, ERR_PTR(ret));
> > }
> >   }
> > -#else
> > -static void intel_sysfs_rc6_init(struct intel_gt *gt, struct
> > kobject *kobj)
> > -{
> > -}
> > -#endif /* CONFIG_PM */
> >   
> >   static u32 __act_freq_mhz_show(struct intel_gt *gt)
> >   {

[Intel-gfx] [PULL] drm-misc-fixes

[Maarten Lankhorst]

Hey Daniel and Dave,

A single fix to vmwgfx mks-guest-stats ioctl.
I lost my internet connection when pushing the tag, so I put together this mail
manually. I hope you remember where drm-misc is hosted. :)

Enjoy!
Maarten Lankhorst

drm-misc-fixes-2022-11-30:
drm-misc-fixes for v6.1-rc8/final:
- Single fix  for mks-guest-stats ioctl userpages pinning.

Dawei Li (1):
  drm/vmwgfx: Fix race issue calling pin_user_pages

 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait

[Tvrtko Ursulin]

On 29/11/2022 18:05, Matthew Auld wrote:

On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
 wrote:



+ Matt

On 25/11/2022 10:21, Christian König wrote:

TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.

Signed-off-by: Christian König 
---
   drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
   1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5247d88b3c13..d409a77449a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
   static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
   {
   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
- int err;
+ long err;

   WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);

- err = ttm_bo_wait(bo, true, false);
- if (err)
+ err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ true, 15 * HZ);


This 15 second stuck out a bit for me and then on a slightly deeper look
it seems this timeout will "leak" into a few of i915 code paths. If we
look at the difference between the legacy shmem and ttm backend I am not
sure if the legacy one is blocking or not - but if it can block I don't
think it would have an arbitrary timeout like this. Matt your thoughts?


Not sure what is meant by leak here, but the legacy shmem must also
wait/block when unbinding each VMA, before calling truncate. It's the


By "leak" I meant if 15s timeout propagates into some code paths visible 
from userspace which with a legacy backend instead have an indefinite 
wait. If we have that it's probably not very good to have this 
inconsistency, or to apply an arbitrary timeout to those path to start with.



same story for the ttm backend, except slightly more complicated in
that there might be no currently bound VMA, and yet the GPU could
still be accessing the pages due to async unbinds, kernel moves etc,
which the wait here (and in i915_ttm_shrink) is meant to protect
against. If the wait times out it should just fail gracefully. I guess
we could just use MAX_SCHEDULE_TIMEOUT here? Not sure if it really
matters though.


Right, depends if it can leak or not to userspace and diverge between 
backends.


Regards,

Tvrtko

Re: [Intel-gfx] PR for DG2 DMC v2.08

[Josh Boyer]

On Wed, Nov 23, 2022 at 9:03 AM Gustavo Sousa  wrote:
>
> The following changes since commit 391fb47caabaae8719fb72ba4891d1fc27ca1923:
>
>   amdgpu: update green sardine DMCUB firmware (2022-11-17 10:42:59 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.8
>
> for you to fetch changes up to 7f6279b3dd76ff955278fcd9e517eab85a4c97d6:
>
>   i915: Add DMC v2.08 for DG2 (2022-11-21 16:38:26 -0300)

Pulled and pushed out.  Minor conflict in WHENCE fixed up.

josh

> 
> Gustavo Sousa (1):
>   i915: Add DMC v2.08 for DG2
>
>  WHENCE   |   3 +++
>  i915/dg2_dmc_ver2_08.bin | Bin 0 -> 22540 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/dg2_dmc_ver2_08.bin

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove CONFIG_PM dependency from RC6.

[Patchwork]

== Series Details ==

Series: drm/i915: Remove CONFIG_PM dependency from RC6.
URL   : https://patchwork.freedesktop.org/series/111465/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12449_full -> Patchwork_111465v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@long-history:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-skl10/igt@gem_exec_fe...@long-history.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-skl1/igt@gem_exec_fe...@long-history.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-iclb8/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][5] ([i915#3371])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-skl9/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html

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

  * igt@gen7_exec_parse@basic-allocation:
- shard-tglb: NOTRUN -> [SKIP][9] ([fdo#109289])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-tglb3/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][10] -> [DMESG-WARN][11] ([i915#5566] / 
[i915#716])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-apl8/igt@gen9_exec_pa...@allowed-single.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-apl6/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][12] ([fdo#111615])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-tglb3/igt@kms_big...@yf-tiled-64bpp-rotate-270.html

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

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

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][15] ([i915#3689])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-tglb3/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][16] ([fdo#111615] / [i915#3689]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-tglb3/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html

  * igt@kms_ccs@pipe-d-bad-pixel-format-4_tiled_dg2_rc_ccs_cc:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +14 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111465v1/shard-skl9/igt@kms_ccs@pipe-d-bad-pixel-format-4_tiled_dg2_rc_ccs_cc.html

  * igt@kms_chamelium@dp-crc-single:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109284] / [fdo#111827]) +1 
similar issue
   

Re: [Intel-gfx] [PATCH] drm/i915: Remove CONFIG_PM dependency from RC6.

[Tvrtko Ursulin]

On 30/11/2022 02:29, Rodrigo Vivi wrote:

RC6 is a sleep state that doesn't depend on the cpu sleep,
or any of the APM or ACPI or anything related to the
CONFIG_PM.

A long time ago we have removed the module parameter
that allows the RC6 disablement. We want that feature enabled
everywhere. However, for some reason this CONFIG_PM was long
forgotten behind.

If we end up needing knobs to disable RC6 we should create
individual ones, rather than relying on this master one.


Digging in history shows 5ab3633d6907 ("drm/i915: make rc6 in sysfs 
functions conditional") and then it appears the issue could still be 
present, since we still use power_group_name which is NULL when !CONFIG_PM.


$ ls -l /sys/class/drm/card0/power/
total 0
-rw-r--r-- 1 root root 4096 Nov 30 11:45 async
-rw-r--r-- 1 root root 4096 Nov 30 11:45 autosuspend_delay_ms
-rw-r--r-- 1 root root 4096 Nov 30 11:45 control
-r--r--r-- 1 root root 4096 Nov 30 11:45 rc6_enable
-r--r--r-- 1 root root 4096 Nov 30 11:45 rc6_residency_ms
-r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_active_kids
-r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_active_time
-r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_enabled
-r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_status
-r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_suspended_time
-r--r--r-- 1 root root 4096 Nov 30 11:45 runtime_usage

Other than rc6 entries I guess come from somewhere else but I haven't 
looked from where exactly.


Regards,

Tvrtko


Cc: Paul Cercueil 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index cf71305ad586..77327ede18ad 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -164,7 +164,6 @@ sysfs_gt_attribute_r_func(struct kobject *kobj, struct 
attribute *attr,
 NULL); 
\
INTEL_GT_ATTR_RO(_name)
  
-#ifdef CONFIG_PM

  static u32 get_residency(struct intel_gt *gt, enum intel_rc6_res_type id)
  {
intel_wakeref_t wakeref;
@@ -329,11 +328,6 @@ static void intel_sysfs_rc6_init(struct intel_gt *gt, 
struct kobject *kobj)
 gt->info.id, ERR_PTR(ret));
}
  }
-#else
-static void intel_sysfs_rc6_init(struct intel_gt *gt, struct kobject *kobj)
-{
-}
-#endif /* CONFIG_PM */
  
  static u32 __act_freq_mhz_show(struct intel_gt *gt)

  {

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Patchwork]

== Series Details ==

Series: series starting with [v6,1/1] drm/i915/pxp: Promote pxp subsystem to 
top-level of i915
URL   : https://patchwork.freedesktop.org/series/111463/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12449_full -> Patchwork_111463v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@perf_pmu@enable-race@bcs0:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-tglb5/igt@perf_pmu@enable-r...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-tglb8/igt@perf_pmu@enable-r...@bcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html

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

  * igt@gen7_exec_parse@basic-allocation:
- shard-tglb: NOTRUN -> [SKIP][9] ([fdo#109289])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-tglb7/igt@gen7_exec_pa...@basic-allocation.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#3989] / [i915#454])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-iclb6/igt@i915_pm...@dc6-psr.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-iclb6/igt@i915_pm...@dc6-psr.html

  * igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][12] ([fdo#111615])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-tglb7/igt@kms_big...@yf-tiled-64bpp-rotate-270.html

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

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

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][15] ([i915#3689])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-tglb7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][16] ([fdo#111615] / [i915#3689]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-tglb7/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html

  * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +40 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111463v1/shard-skl4/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@dp-crc-single:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109284] / [fdo#111827]) +1 
similar issue
 

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Refactor dsc gen checks

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani 
> Nikula
> Sent: Thursday, November 10, 2022 4:54 PM
> To: Sharma, Swati2 ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dsc: Refactor dsc gen checks
> 
> On Thu, 10 Nov 2022, Swati Sharma  wrote:
> > Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc member.
> > Platforms supporting dsc has this flag enabled; no need of
> > DISPLAY_VER() check.
> >
> > Also, simplified intel_dsc_source_support() based on above changes.
> >
> > Suggested-by: Jani Nikula 
> > Signed-off-by: Swati Sharma 
> 
> Reviewed-by: Jani Nikula 

Pushed to drm-intel-next. Thanks for the patch and reviews.

Regards,
Uma Shankar
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  6 +++---
> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 11 ---
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  3 files changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 7400d6b4c587..f6f9257bd202 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1012,7 +1012,7 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> >  * Output bpp is stored in 6.4 format so right shift by 4 to get the
> >  * integer value since we support only integer values of bpp.
> >  */
> > -   if (DISPLAY_VER(dev_priv) >= 10 &&
> > +   if (HAS_DSC(dev_priv) &&
> > drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> > /*
> >  * TBD pass the connector BPC,
> > @@ -2906,7 +2906,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > intel_dp_set_max_sink_lane_count(intel_dp);
> >
> > /* Read the eDP DSC DPCD registers */
> > -   if (DISPLAY_VER(dev_priv) >= 10)
> > +   if (HAS_DSC(dev_priv))
> > intel_dp_get_dsc_sink_cap(intel_dp);
> >
> > /*
> > @@ -4691,7 +4691,7 @@ intel_dp_detect(struct drm_connector *connector,
> > }
> >
> > /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
> > -   if (DISPLAY_VER(dev_priv) >= 11)
> > +   if (HAS_DSC(dev_priv))
> > intel_dp_get_dsc_sink_cap(intel_dp);
> >
> > intel_dp_configure_mst(intel_dp);
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index 269f9792390d..7b4d300a4dd8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -344,16 +344,13 @@ bool intel_dsc_source_support(const struct
> intel_crtc_state *crtc_state)
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >
> > -   if (!RUNTIME_INFO(i915)->has_dsc)
> > +   if (!HAS_DSC(i915))
> > return false;
> >
> > -   if (DISPLAY_VER(i915) >= 12)
> > -   return true;
> > -
> > -   if (DISPLAY_VER(i915) >= 11 && cpu_transcoder != TRANSCODER_A)
> > -   return true;
> > +   if (DISPLAY_VER(i915) == 11 && cpu_transcoder == TRANSCODER_A)
> > +   return false;
> >
> > -   return false;
> > +   return true;
> >  }
> >
> >  static bool is_pipe_dsc(struct intel_crtc *crtc, enum transcoder
> > cpu_transcoder) diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 05b3300cc4ed..9d1fe5d6a104
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -484,6 +484,7 @@ static inline struct intel_gt *to_gt(struct 
> > drm_i915_private
> *i915)
> >  #define INTEL_REVID(dev_priv)  (to_pci_dev((dev_priv)->drm.dev)-
> >revision)
> >
> >  #define HAS_DSB(dev_priv)  (INTEL_INFO(dev_priv)->display.has_dsb)
> > +#define HAS_DSC(__i915)(RUNTIME_INFO(__i915)->has_dsc)
> >
> >  #define INTEL_DISPLAY_STEP(__i915)
> > (RUNTIME_INFO(__i915)->step.display_step)
> >  #define INTEL_GRAPHICS_STEP(__i915)
> > (RUNTIME_INFO(__i915)->step.graphics_step)
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add new CDCLK step for RPL-U

[Patchwork]

== Series Details ==

Series: Add new CDCLK step for RPL-U
URL   : https://patchwork.freedesktop.org/series/111472/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  CC [M]  drivers/gpu/drm/i915/display/intel_cdclk.o
drivers/gpu/drm/i915/display/intel_cdclk.c: In function 
‘intel_init_cdclk_hooks’:
drivers/gpu/drm/i915/display/intel_cdclk.c:3408:12: error: ‘struct 
drm_i915_private’ has no member named ‘cdclk’
dev_priv->cdclk.table = rplu_cdclk_table;
^~
scripts/Makefile.build:250: recipe for target 
'drivers/gpu/drm/i915/display/intel_cdclk.o' failed
make[5]: *** [drivers/gpu/drm/i915/display/intel_cdclk.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.IGT: failure for More GuC firmware version improvements (rev3)

[Patchwork]

== Series Details ==

Series: More GuC firmware version improvements (rev3)
URL   : https://patchwork.freedesktop.org/series/111218/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12449_full -> Patchwork_111218v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-skl7/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-skl10/igt@gem_b...@close-race.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-shrfb-pgflip-blt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-shrfb-pgflip-blt.html

  * igt@perf_pmu@module-unload:
- shard-apl:  [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-apl1/igt@perf_...@module-unload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-apl6/igt@perf_...@module-unload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#4793])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-skl1/igt@gem_ctx_isolation@preservation...@bcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-skl1/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#4525])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-iclb8/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][11] ([i915#3371])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-skl7/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_whisper@basic-queues-priority:
- shard-iclb: [PASS][16] -> [INCOMPLETE][17] ([i915#6453])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-iclb8/igt@gem_exec_whis...@basic-queues-priority.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-iclb2/igt@gem_exec_whis...@basic-queues-priority.html

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

  * igt@gen7_exec_parse@basic-allocation:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111218v3/shard-tglb5/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][20] -> [DMESG-WARN][21] ([i915#5566] / 
[i915#716])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12449/shard-apl8/igt@gen9_exec_pa...@allowed-single.html
   [21]: 

Re: [Intel-gfx] [PATCH v5 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Jani Nikula]

On Wed, 30 Nov 2022, "Teres Alexis, Alan Previn" 
 wrote:
> ++Nikula if he has suggestions on the bottom most comment.
>
> On Tue, 2022-11-29 at 16:28 -0500, Vivi, Rodrigo wrote:
>> On Mon, Nov 28, 2022 at 04:31:52PM -0800, Alan Previn wrote:
>> > Starting with MTL, there will be two GT-tiles, a render and media
>> > tile. PXP as a service for supporting workloads with protected
>> > contexts and protected buffers can be subscribed by process
>> > workloads on any tile. However, depending on the platform,
>> > only one of the tiles is used for control events pertaining to PXP
>> > operation (such as creating the arbitration session and session
>> > tear-down). In the case of MTL, this is the media-tile.
>>
>> Imho this patch shows that having the pxp under i915 instead of gt
>> is the right way to go.
>>
> Alan: yes, agreed.
>
>> but I have a few comments and doubts below...
>>
>> >
>> >
> Alan: [snip]
>
>> > @@ -138,31 +144,63 @@ static void pxp_init_full(struct intel_pxp *pxp)
>> > destroy_vcs_context(pxp);
>> >  }
>> >
>> > -void intel_pxp_init(struct intel_pxp *pxp)
>> > +static struct intel_gt *pxp_get_kcr_owner_gt(struct drm_i915_private 
>> > *i915)
>>
>> pxp_get_ctrl_gt or pxp_get_serving_gt sounds better in my opinion...
>> what's "owner"?
>>
> Alan: Sure- will change to pxp_get_ctrl_gt (as per the name in the header 
> file).
>
>> >  {
>> > -   struct intel_gt *gt = pxp_to_gt(pxp);
>> > +   struct intel_gt *gt = NULL;
>> > +   int i = 0;
>> > +
>> > +   for_each_gt(gt, i915, i) {
>> > +   /* There can be only one GT that supports PXP */
>> > +   if (HAS_ENGINE(gt, GSC0))
>> > +   return gt;
>> > +   }
>> >
>> > /* we rely on the mei PXP module */
>> > -   if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
>> > -   return;
>> > +   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP))
>> > +   return >gt0;
>> > +
>> > +   return NULL;
>> > +}
>> > +
>> > +int intel_pxp_init(struct intel_pxp **pxp_store_ptr)
>>
>> Please let's avoid the ** here and everywhere.
>>
> Alan: In order to to avoid causing the entire driver into a rebuild because 
> of any change in the intel_pxp structure,
> the only way to accomplish that is to use a ptr in i915. But using a ptr 
> means we allocate the memory at init time and
> free it at fini time and those 2 cases would require the ptr-to-ptr to ensure 
> we get the correct store. The only way i
> can avoid the ** is be passing i915 as the param and then populating the ptr 
> via i915->pxp. Would this work?

In general, one of two approaches should be used:

1) The caller takes care of storing/clearing the pointer:

struct intel_pxp *intel_pxp_init(void);
void intel_pxp_fini(struct intel_pxp *pxp);

2) The callee takes care of storing/clearing the pointer:

int intel_pxp_init(struct drm_i915_private *i915);
void intel_pxp_fini(struct drm_i915_private *i915);

Passing pointers to pointers is not as clean.

In this case, I'd choose 2) just because it's being called at the high
level, and it's pretty much in line with everything else.



BR,
Jani.


>
>> >
>> >
> Alan:[snip]
>
>> > @@ -12,12 +12,23 @@
>> >  #include 
>> >
>> >  struct intel_context;
>> > +struct intel_gt;
>> >  struct i915_pxp_component;
>> > +struct drm_i915_private;
>> >
>> >  /**
>> >   * struct intel_pxp - pxp state
>> >   */
>> >  struct intel_pxp {
>> > +   /** @i915: back poiner to i915*/
>> > +   struct drm_i915_private *i915;
>>
>> do you really need this pointer back here?
>> or using a container_of should be enough?
>>
> Alan: this is the same thing for above. We can use container_of if the caller 
> passes the ptr-to-ptr ... if caller only
> passes the pxp ptr, it will be passing, by reference, an allocated address. 
> The only way I can think of to avoid this
> is by dropping the ptr-to-ptr method and therefore pulling in the pxp type 
> header into drm_i915_private header file -
> which is againts the direction we are trying to head towards. (cc-ing Nikula 
> is he has some ideas on this)
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [RFC 2/2] drm/i915: Add additional check for 480Mhz step CDCLK

[Jani Nikula]

On Wed, 30 Nov 2022, Chaitanya Kumar Borah  
wrote:
> There are still RPL-U boards which does not support the 480Mhz step of
> CDCLK. We can differentiate these board by checking the CPUID Brand
> String. 480Mhz step is only supported in SKUs which does not contain
> the string "Genuine Intel" in the Brand string.
>
> BSpec: 55409
>
> Signed-off-by: Chaitanya Kumar Borah 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 9bfeb1abba47..1890e5135cfc 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -192,6 +192,19 @@ static bool is_rplu(struct drm_i915_private *dev_priv)
>   }
>  }
>  
> +static bool is_480mhz_step_valid(void)
> +{
> + struct cpuinfo_x86 *c;
> + unsigned int cpu = smp_processor_id();
> +
> + c = _data(cpu);
> +
> + if (c->x86_model_id[0] && !strstr(c->x86_model_id, "Genuine Intel"))
> + return true;

Ugh, this is super ugly.

The usual way to quirk this stuff is in display/intel_quirks.c. There
are two kinds of quirks, device and dmi. (And I realize that's one place
where we do have PCI IDs written, but it's for slightly different
purpose.)

If this really can't be done using quirks, and cpuinfo is the only way
(I doubt it), then we need to add the cpuinfo quirk to intel_quirks.c
and not sprinkle these around.

BR,
Jani.


> +
> + return false;
> +}
> +
>  static void i915gm_get_cdclk(struct drm_i915_private *dev_priv,
>struct intel_cdclk_config *cdclk_config)
>  {
> @@ -3389,8 +3402,9 @@ void intel_init_cdclk_hooks(struct drm_i915_private 
> *dev_priv)
>   /*
>* BSpec: 55409
>* 480 MHz supported on SKUs that have a RPL-U Device ID
> +  * and  CPUID Brand String that does not contain "Genuine 
> Intel".
>*/
> - else if (is_rplu(dev_priv))
> + else if (is_rplu(dev_priv) && is_480mhz_step_valid())
>   dev_priv->cdclk.table = rplu_cdclk_table;
>   else
>   dev_priv->display.cdclk.table = adlp_cdclk_table;

-- 
Jani Nikula, Intel Open Source Graphics Center