[Intel-gfx] ✓ Fi.CI.IGT: success for i915/mtl: Enable idle messaging for GSC CS

[Patchwork]

== Series Details ==

Series: i915/mtl: Enable idle messaging for GSC CS
URL   : https://patchwork.freedesktop.org/series/110349/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110349v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@dmabuf@all@dma_fence_chain:
- shard-skl:  NOTRUN -> [INCOMPLETE][1] ([i915#6949])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-skl6/igt@dmabuf@all@dma_fence_chain.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl:  [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +1 similar 
issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-apl3/igt@gem_ctx_isolation@preservation...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-iclb3/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html

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

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb3/igt@gem_huc_c...@huc-copy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_softpin@noreloc-s3:
- shard-apl:  [PASS][14] -> [INCOMPLETE][15] ([i915#7236])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-apl1/igt@gem_soft...@noreloc-s3.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-apl1/igt@gem_soft...@noreloc-s3.html

  * igt@gen9_exec_parse@allowed-all:
- shard-skl:  [PASS][16] -> [DMESG-WARN][17] ([i915#5566] / 
[i915#716])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/igt@gen9_exec_pa...@allowed-all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-skl6/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_pm_backlight@fade:
- shard-iclb: [PASS][18] -> [DMESG-WARN][19] ([i915#402])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@i915_pm_backli...@fade.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-iclb1/igt@i915_pm_backli...@fade.html

  * igt@i915_selftest@live@gt_pm:
- shard-skl:  NOTRUN -> [DMESG-FAIL][20] ([i915#1886])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-skl4/igt@i915_selftest@live@gt_pm.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#5286])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-iclb5/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-90:
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#110725] / [fdo#111614])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v1/shard-iclb5/igt@kms_big...@x-tiled-64bpp-rotate-90.html

  * igt@kms_big_fb@yf-tiled-8bpp-rotate-180:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#110723])
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Introduce Wa_18017747507 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Introduce Wa_18017747507 (rev2)
URL   : https://patchwork.freedesktop.org/series/110323/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110323v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 27)
--

  Additional (1): fi-tgl-dsi 
  Missing(14): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 fi-cfl-guc bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 
bat-dg2-11 bat-jsl-1 

Known issues


  Here are the changes found in Patchwork_110323v2 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_12325/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

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

  
 Possible fixes 

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

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

  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6856]: https://gitlab.freedesktop.org/drm/intel/issues/6856
  [i915#7073]: https://gitlab.freedesktop.org/drm/intel/issues/7073
  [i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_110323v2

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110323v2: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

62662bd13a08 drm/i915/dg2: Introduce Wa_18017747507

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/mtl: Enable idle messaging for GSC CS

[Patchwork]

== Series Details ==

Series: i915/mtl: Enable idle messaging for GSC CS
URL   : https://patchwork.freedesktop.org/series/110349/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110349v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 26)
--

  Missing(14): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 bat-adlp-4 bat-adln-1 fi-pnv-d510 bat-rplp-1 bat-rpls-1 bat-rpls-2 
bat-dg2-11 bat-jsl-1 


Changes
---

  No changes found


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_110349v1

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110349v1: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b691bb7c508d drm/i915/mtl: Enable Idle Messaging for GSC CS
971e0d423635 drm/i915/mtl: add initial definitions for GSC CS

== Logs ==

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

Re: [Intel-gfx] [PATCH 00/10] Connect VFIO to IOMMUFD

[Nicolin Chen]

On Tue, Nov 01, 2022 at 11:04:38AM +0800, Yi Liu wrote:
> On 2022/11/1 07:24, Jason Gunthorpe wrote:
> > On Mon, Oct 31, 2022 at 08:25:39PM +0800, Yi Liu wrote:
> > > > There is something wrong with the test suite that it isn't covering
> > > > the above, I'm going to look into that today.
> > > 
> > > sounds to be the cause. I didn't see any significant change in vfio_main.c
> > > that may fail gvt. So should the iommufd changes. Then we will re-run the
> > > test after your update.:-)
> > 
> > I updated the github with all the changes made so far, it is worth
> > trying again!
> 
> gvt is still failing with below call trace in host side. vfio_unpin_pages()
> is still in problem. Any idea on it?

> [  206.464318] WARNING: CPU: 9 PID: 3362 at
> drivers/iommu/iommufd/device.c:591 iommufd_access_pin_pages+0x337/0x360

Judging from this WARNING, and since gvt (mdev) needs pin_pages(),
I assume this might be a fix, though Jason's latest change for the
iova_alignment seems to be added for CONFIG_IOMMUFD_TEST only.

--
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 72a289c5f8c9..185075528d5e 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -120,6 +120,7 @@ static void vfio_emulated_unmap(void *data, unsigned long 
iova,
 }
 
 static const struct iommufd_access_ops vfio_user_ops = {
+   .needs_pin_pages = 1,
.unmap = vfio_emulated_unmap,
 };
 
--

Perhaps you can try it first to see if we can test the rest part of
the routine for now, till Jason acks tomorrow.

Thanks
Nic

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915/mtl: Enable idle messaging for GSC CS

[Patchwork]

== Series Details ==

Series: i915/mtl: Enable idle messaging for GSC CS
URL   : https://patchwork.freedesktop.org/series/110349/
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.DOCS: warning for i915/mtl: Enable idle messaging for GSC CS

[Patchwork]

== Series Details ==

Series: i915/mtl: Enable idle messaging for GSC CS
URL   : https://patchwork.freedesktop.org/series/110349/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

[Intel-gfx] [PATCH 2/2] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Badal Nilawar]

From: Vinay Belgaumkar 

By defaut idle mesaging is disabled for GSC CS so to unblock RC6
entry on media tile idle messaging need to be enabled.

Bspec: 71496

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Vinay Belgaumkar 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_engine_pm.c | 12 
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b0a4a2dbe3ee..8d391f8fd861 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -15,6 +15,7 @@
 #include "intel_rc6.h"
 #include "intel_ring.h"
 #include "shmem_utils.h"
+#include "intel_gt_regs.h"
 
 static void dbg_poison_ce(struct intel_context *ce)
 {
@@ -271,10 +272,21 @@ static const struct intel_wakeref_ops wf_ops = {
 
 void intel_engine_init__pm(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *i915 = engine->i915;
struct intel_runtime_pm *rpm = engine->uncore->rpm;
 
intel_wakeref_init(>wakeref, rpm, _ops);
intel_engine_init_heartbeat(engine);
+
+   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
+   intel_uncore_write(engine->gt->uncore,
+  RC_PSMI_CTRL_GSCCS,
+  _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
+   drm_dbg(>drm,
+   "Set GSC CS Idle Reg to: 0x%x",
+   intel_uncore_read(engine->gt->uncore, 
RC_PSMI_CTRL_GSCCS));
+   }
+
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index f4624262dc81..176902a9f2a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -908,6 +908,9 @@
 #define  MSG_IDLE_FW_MASK  REG_GENMASK(13, 9)
 #define  MSG_IDLE_FW_SHIFT 9
 
+#defineRC_PSMI_CTRL_GSCCS  _MMIO(0x11a050)
+#define IDLE_MSG_DISABLE   BIT(0)
+
 #define FORCEWAKE_MEDIA_GEN9   _MMIO(0xa270)
 #define FORCEWAKE_RENDER_GEN9  _MMIO(0xa278)
 
-- 
2.25.1

[Intel-gfx] [PATCH 1/2] drm/i915/mtl: add initial definitions for GSC CS

[Badal Nilawar]

From: Daniele Ceraolo Spurio 

Starting on MTL, the GSC is no longer managed with direct MMIO access,
but we instead have a dedicated command streamer for it. As a first step
for adding support for this CS, add the required definitions.
Note that, although it is now a CS, the GSC retains its old
class:instance value (OTHER_CLASS instance 6)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
 drivers/gpu/drm/i915/gt/intel_engine_user.c  | 1 +
 drivers/gpu/drm/i915/i915_reg.h  | 1 +
 4 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3b7d750ad054..e0fbfac03979 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -244,6 +244,13 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 12, .base = GEN12_COMPUTE3_RING_BASE }
}
},
+   [GSC0] = {
+   .class = OTHER_CLASS,
+   .instance = OTHER_GSC_INSTANCE,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = MTL_GSC_RING_BASE }
+   }
+   },
 };
 
 /**
@@ -324,6 +331,7 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 class)
case VIDEO_DECODE_CLASS:
case VIDEO_ENHANCEMENT_CLASS:
case COPY_ENGINE_CLASS:
+   case OTHER_CLASS:
if (GRAPHICS_VER(gt->i915) < 8)
return 0;
return GEN8_LR_CONTEXT_OTHER_SIZE;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 6b5d4ea22b67..4fd54fb8810f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -136,6 +136,7 @@ enum intel_engine_id {
CCS2,
CCS3,
 #define _CCS(n) (CCS0 + (n))
+   GSC0,
I915_NUM_ENGINES
 #define INVALID_ENGINE ((enum intel_engine_id)-1)
 };
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 46a174f8aa00..79312b734690 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -140,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
[COPY_ENGINE_CLASS] = "bcs",
[VIDEO_DECODE_CLASS] = "vcs",
[VIDEO_ENHANCEMENT_CLASS] = "vecs",
+   [OTHER_CLASS] = "other",
[COMPUTE_CLASS] = "ccs",
};
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1c0da50c0dc7..d056c3117ef2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -970,6 +970,7 @@
 #define GEN11_VEBOX2_RING_BASE 0x1d8000
 #define XEHP_VEBOX3_RING_BASE  0x1e8000
 #define XEHP_VEBOX4_RING_BASE  0x1f8000
+#define MTL_GSC_RING_BASE  0x11a000
 #define GEN12_COMPUTE0_RING_BASE   0x1a000
 #define GEN12_COMPUTE1_RING_BASE   0x1c000
 #define GEN12_COMPUTE2_RING_BASE   0x1e000
-- 
2.25.1

[Intel-gfx] [PATCH 0/2] i915/mtl: Enable idle messaging for GSC CS

[Badal Nilawar]

This series includes code change to enable idle messaging for GSC CS.
This series depends on: 

https://patchwork.freedesktop.org/patch/509102/

In order to compile this series included 1 patch from above series, 
authored by Daniele Ceraolo Spurio, to this series. 
Please do not review patch 1. Only patch 2 need to be reviewed.
 
Cc: Daniele Ceraolo Spurio 
Cc: Vinay Belgaumkar 

Daniele Ceraolo Spurio (1):
  drm/i915/mtl: add initial definitions for GSC CS

Vinay Belgaumkar (1):
  drm/i915/mtl: Enable Idle Messaging for GSC CS

 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  8 
 drivers/gpu/drm/i915/gt/intel_engine_pm.c| 12 
 drivers/gpu/drm/i915/gt/intel_engine_types.h |  1 +
 drivers/gpu/drm/i915/gt/intel_engine_user.c  |  1 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  3 +++
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 6 files changed, 26 insertions(+)

-- 
2.25.1

Re: [Intel-gfx] [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND

[Sripada, Radhakrishna]

> -Original Message-
> From: Kahola, Mika 
> Sent: Friday, October 14, 2022 5:47 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Atwood, Matthew S
> ; Roper, Matthew D
> ; De Marchi, Lucas ;
> Souza, Jose ; Sripada, Radhakrishna
> 
> Subject: [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND
> 
> Display14 introduces a new way to instruct the PUnit with
> power and bandwidth requirements of DE. Add the functionality
> to program the registers and handle waits using interrupts.
> The current wait time for timeouts is programmed for 10 msecs to
> factor in the worst case scenarios. Changes made to use REG_BIT
> for a register that we touched(GEN8_DE_MISC_IER _MMIO).
> 
> Bspec: 66451, 64636, 64602, 64603
> 
> Cc: Matt Atwood 
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> 
> Signed-off-by: José Roberto de Souza 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c   |   4 +-
>  drivers/gpu/drm/i915/display/intel_bw.h   |   2 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  14 +
>  .../drm/i915/display/intel_display_power.c|   8 +
>  drivers/gpu/drm/i915/i915_drv.h   |  12 +
>  drivers/gpu/drm/i915/i915_irq.c   |  22 +-
>  drivers/gpu/drm/i915/i915_reg.h   |  33 +-
>  drivers/gpu/drm/i915/intel_pm.c   | 286 ++
>  drivers/gpu/drm/i915/intel_pm.h   |  35 +++
>  9 files changed, 411 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 4ace026b29bd..6c467b6f2234 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -716,8 +716,8 @@ static unsigned int intel_bw_num_active_planes(struct
> drm_i915_private *dev_priv
>   return num_active_planes;
>  }
> 
> -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> -const struct intel_bw_state *bw_state)
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state)
>  {
>   unsigned int data_rate = 0;
>   enum pipe pipe;
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index cb7ee3a24a58..b3eb82a71e6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
>  int intel_bw_atomic_check(struct intel_atomic_state *state);
>  void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> const struct intel_crtc_state *crtc_state);
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state);
>  int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask);
>  int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0a8749753e6e..5ce33319b70d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1079,6 +1079,9 @@ intel_get_crtc_new_encoder(const struct
> intel_atomic_state *state,
>   num_encoders++;
>   }
> 
> + if (!encoder)
> + return NULL;
> +
>   drm_WARN(encoder->base.dev, num_encoders != 1,
>"%d encoders for pipe %c\n",
>num_encoders, pipe_name(master_crtc->pipe));
> @@ -6898,6 +6901,10 @@ static int intel_atomic_check(struct drm_device
> *dev,
>   ret = intel_modeset_calc_cdclk(state);
>   if (ret)
>   return ret;
> +
> + ret = intel_pmdemand_atomic_check(state);
> + if (ret)
> + goto fail;
>   }
> 
>   ret = intel_atomic_check_crtcs(state);
> @@ -7521,6 +7528,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>   }
> 
>   intel_sagv_pre_plane_update(state);
> + intel_pmdemand_pre_plane_update(state);
> 
>   /* Complete the events for pipes that have now been disabled */
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> @@ -7622,6 +7630,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>   intel_verify_planes(state);
> 
>   intel_sagv_post_plane_update(state);
> + intel_pmdemand_post_plane_update(state);
> 
>   drm_atomic_helper_commit_hw_done(>base);
> 
> @@ -8353,6 +8362,7 @@ void intel_init_display_hooks(struct drm_i915_private
> *dev_priv)
>   intel_color_init_hooks(dev_priv);
>   intel_init_cdclk_hooks(dev_priv);
>   intel_audio_hooks_init(dev_priv);
> + intel_init_pmdemand(dev_priv);
> 
>   

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: Do both crawl and squash 
when changing cdclk
URL   : https://patchwork.freedesktop.org/series/110347/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110347v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/igt@gen9_exec_pa...@allowed-single.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/shard-skl10/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-a-edp-1:
- shard-skl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-a-edp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/shard-skl5/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-a-edp-1.html

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
- shard-iclb: [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/shard-iclb6/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html

  * igt@kms_plane_multiple@tiling-x@pipe-c-edp-1:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb7/igt@kms_plane_multiple@tilin...@pipe-c-edp-1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/shard-tglb8/igt@kms_plane_multiple@tilin...@pipe-c-edp-1.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33]) -> ([FAIL][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], 
[PASS][55], [PASS][56], [PASS][57], [PASS][58]) ([i915#4392])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk8/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk8/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk8/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk6/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk5/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk5/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk5/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk3/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk3/boot.html
   [27]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Remove excessive line feeds in state dumps

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Remove excessive line feeds in state dumps
URL   : https://patchwork.freedesktop.org/series/110343/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110343v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload-with-fault-injection:
- shard-snb:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/shard-snb4/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_cursor_crc@cursor-offscreen-64x21@pipe-b-edp-1:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb2/igt@kms_cursor_crc@cursor-offscreen-64...@pipe-b-edp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/shard-tglb8/igt@kms_cursor_crc@cursor-offscreen-64...@pipe-b-edp-1.html

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
- shard-iclb: [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html

  * igt@kms_sequence@queue-busy@edp-1-pipe-a:
- shard-skl:  [PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/igt@kms_sequence@queue-b...@edp-1-pipe-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/shard-skl3/igt@kms_sequence@queue-b...@edp-1-pipe-a.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-skl:  ([PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) -> 
([PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[FAIL][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [FAIL][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], 
[PASS][55]) ([i915#5032])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl5/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [28]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: Do both crawl and squash 
when changing cdclk
URL   : https://patchwork.freedesktop.org/series/110347/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110347v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 29)
--

  Additional (1): fi-rkl-11600 
  Missing(12): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#7056])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][7] ([i915#4817])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#4103])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#109285] / [i915#4098])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4098])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-icl-u2:  [DMESG-WARN][17] ([i915#2867]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [18]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Remove excessive line feeds in state dumps

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Remove excessive line feeds in state dumps
URL   : https://patchwork.freedesktop.org/series/110343/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110343v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 29)
--

  Additional (1): fi-rkl-11600 
  Missing(12): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][5] ([i915#4817])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4103])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([fdo#109285] / [i915#4098])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#1072]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3555] / [i915#4098])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-icl-u2:  [DMESG-WARN][15] ([i915#2867]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110343v1/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html

  
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more
URL   : https://patchwork.freedesktop.org/series/110341/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110341v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_atomic_transition@modeset-transition-nonblocking-fencing@1x-outputs:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb1/igt@kms_atomic_transition@modeset-transition-nonblocking-fenc...@1x-outputs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-tglb8/igt@kms_atomic_transition@modeset-transition-nonblocking-fenc...@1x-outputs.html

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-iclb6/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@dmabuf@all@dma_fence_chain:
- shard-skl:  NOTRUN -> [INCOMPLETE][5] ([i915#6949])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-skl9/igt@dmabuf@all@dma_fence_chain.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-iclb5/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html

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

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb3/igt@gem_huc_c...@huc-copy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-skl3/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gen9_exec_parse@allowed-all:
- shard-skl:  [PASS][14] -> [DMESG-WARN][15] ([i915#5566] / 
[i915#716])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/igt@gen9_exec_pa...@allowed-all.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-skl3/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_module_load@load:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#6227])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-skl3/igt@i915_module_l...@load.html

  * igt@i915_pm_backlight@fade:
- shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#402])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@i915_pm_backli...@fade.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-iclb6/igt@i915_pm_backli...@fade.html

  * igt@i915_pm_sseu@full-enable:
- shard-skl:  NOTRUN -> [FAIL][19] ([i915#6991])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/shard-skl3/igt@i915_pm_s...@full-enable.html

  * igt@i915_selftest@live@gt_pm:
- 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev2)
URL   : https://patchwork.freedesktop.org/series/110326/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110326v2


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 28)
--

  Additional (1): fi-rkl-11600 
  Missing(13): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#3282])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3012])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][9] ([i915#4817])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#109285] / [i915#4098])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v2/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   

Re: [Intel-gfx] [PATCH 00/10] Connect VFIO to IOMMUFD

[Jason Gunthorpe]

On Mon, Oct 31, 2022 at 08:25:39PM +0800, Yi Liu wrote:
> > There is something wrong with the test suite that it isn't covering
> > the above, I'm going to look into that today.
> 
> sounds to be the cause. I didn't see any significant change in vfio_main.c
> that may fail gvt. So should the iommufd changes. Then we will re-run the
> test after your update.:-)

I updated the github with all the changes made so far, it is worth
trying again!

Thanks,
Jason

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev2)
URL   : https://patchwork.freedesktop.org/series/110326/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'

[Intel-gfx] [PATCH 2/2] drm/i915/display: Add CDCLK Support for MTL

[Anusha Srivatsa]

As per bSpec MTL has 38.4 MHz Reference clock.
Adding the cdclk tables and cdclk_funcs that MTL
will use.

v2: Revert to using bxt_get_cdclk()

BSpec: 65243

Cc: Clint Taylor 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Clint Taylor 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d79cf282faa8..54ac7f9a1253 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1345,6 +1345,16 @@ static const struct intel_cdclk_vals dg2_cdclk_table[] = 
{
{}
 };
 
+static const struct intel_cdclk_vals mtl_cdclk_table[] = {
+   { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 16, 
.waveform = 0xad5a },
+   { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 16, 
.waveform = 0xb6b6 },
+   { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34, 
.waveform = 0x },
+   {}
+};
+
 static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk)
 {
const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
@@ -3159,6 +3169,13 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
 }
 
+static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
+   .get_cdclk = bxt_get_cdclk,
+   .set_cdclk = bxt_set_cdclk,
+   .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+   .calc_voltage_level = tgl_calc_voltage_level,
+};
+
 static const struct intel_cdclk_funcs tgl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
@@ -3294,7 +3311,10 @@ static const struct intel_cdclk_funcs i830_cdclk_funcs = 
{
  */
 void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
 {
-   if (IS_DG2(dev_priv)) {
+   if (IS_METEORLAKE(dev_priv)) {
+   dev_priv->display.funcs.cdclk = _cdclk_funcs;
+   dev_priv->display.cdclk.table = mtl_cdclk_table;
+   } else if (IS_DG2(dev_priv)) {
dev_priv->display.funcs.cdclk = _cdclk_funcs;
dev_priv->display.cdclk.table = dg2_cdclk_table;
} else if (IS_ALDERLAKE_P(dev_priv)) {
-- 
2.25.1

[Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk

[Anusha Srivatsa]

From: Ville Syrjälä 

For MTL, changing cdclk from between certain frequencies has
both squash and crawl. Use the current cdclk config and
the new(desired) cdclk config to construtc a mid cdclk config.
Set the cdclk twice:
- Current cdclk -> mid cdclk
- mid cdclk -> desired cdclk

v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
change via modeset for platforms that support squash_crawl sequences(Ville)

v3: Add checks for:
- scenario where only slow clock is used and
cdclk is actually 0 (bringing up display).
- PLLs are on before looking up the waveform.
- Squash and crawl capability checks.(Ville)

v4: Rebase
- Move checks to be more consistent (Ville)
- Add comments (Bala)
v5:
- Further small changes. Move checks around.
- Make if-else better looking (Ville)

Cc: Balasubramani Vivekanandan 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 156 +
 1 file changed, 128 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index eada931cb1c8..d79cf282faa8 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1716,37 +1716,74 @@ static void dg2_cdclk_squash_program(struct 
drm_i915_private *i915,
intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
 }
 
-static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_config *cdclk_config,
- enum pipe pipe)
+static int cdclk_squash_divider(u16 waveform)
+{
+   return hweight16(waveform ?: 0x);
+}
+
+static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
+  const struct intel_cdclk_config 
*old_cdclk_config,
+  const struct intel_cdclk_config 
*new_cdclk_config,
+  struct intel_cdclk_config *mid_cdclk_config)
+{
+   u16 old_waveform, new_waveform, mid_waveform;
+   int size = 16;
+   int div = 2;
+
+   /* Return if both Squash and Crawl are not present */
+   if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
+   return false;
+
+   old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
+   new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
+
+   /* Return if Squash only or Crawl only is the desired action */
+   if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
+   old_cdclk_config->vco == new_cdclk_config->vco ||
+   old_waveform == new_waveform)
+   return false;
+
+   *mid_cdclk_config = *new_cdclk_config;
+
+   /* Populate the mid_cdclk_config accordingly.
+* - If moving to a higher cdclk, the desired action is squashing.
+* The mid cdclk config should have the new (squash) waveform.
+* - If moving to a lower cdclk, the desired action is crawling.
+* The mid cdclk config should have the new vco.
+*/
+
+   if (cdclk_squash_divider(new_waveform) > 
cdclk_squash_divider(old_waveform)) {
+   mid_cdclk_config->vco = old_cdclk_config->vco;
+   mid_waveform = new_waveform;
+   } else {
+   mid_cdclk_config->vco = new_cdclk_config->vco;
+   mid_waveform = old_waveform;
+   }
+
+   mid_cdclk_config->cdclk = 
DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
+   mid_cdclk_config->vco, size 
* div);
+
+   /* make sure the mid clock came out sane */
+
+   drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
+   min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
+   drm_WARN_ON(>drm, mid_cdclk_config->cdclk >
+   i915->display.cdclk.max_cdclk_freq);
+   drm_WARN_ON(>drm, cdclk_squash_waveform(i915, 
mid_cdclk_config->cdclk) !=
+   mid_waveform);
+
+   return true;
+}
+
+static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
+  const struct intel_cdclk_config *cdclk_config,
+  enum pipe pipe)
 {
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
u32 val;
u16 waveform;
int clock;
-   int ret;
-
-   /* Inform power controller of upcoming frequency change. */
-   if (DISPLAY_VER(dev_priv) >= 11)
-   ret = skl_pcode_request(_priv->uncore, 
SKL_PCODE_CDCLK_CONTROL,
-   SKL_CDCLK_PREPARE_FOR_CHANGE,
-   SKL_CDCLK_READY_FOR_CHANGE,
-   SKL_CDCLK_READY_FOR_CHANGE, 3);
-   else
-   /*
-* BSpec requires us to wait up to 150usec, but that leads to
-* timeouts; the 2ms used here is based on experiment.
-*/
-   

Re: [Intel-gfx] [PATCH 10/10] iommufd: Allow iommufd to supply /dev/vfio/vfio

[Alex Williamson]

On Fri, 28 Oct 2022 15:44:36 -0300
Jason Gunthorpe  wrote:

> On Wed, Oct 26, 2022 at 03:31:33PM -0600, Alex Williamson wrote:
> > On Tue, 25 Oct 2022 15:50:45 -0300
> > Jason Gunthorpe  wrote:
> >   
> > > If the VFIO container is compiled out, give a kconfig option for iommufd
> > > to provide the miscdev node with the same name and permissions as vfio
> > > uses.
> > > 
> > > The compatibility node supports the same ioctls as VFIO and automatically
> > > enables the VFIO compatible pinned page accounting mode.  
> > 
> > I think I'd like to see some sort of breadcrumb when /dev/vfio/vfio is
> > provided by something other than the vfio container code.  If we intend
> > to include this before P2P is resolved, that breadcrumb   
> 
> I don't belive I can get P2P done soon enough. I plan to do it after
> this is merged. Right now these two series are taking all my time.
> 
> > (dmesg I'm guessing) might also list any known limitations of the
> > compatibility to save time with debugging.  Thanks,  
> 
> Yes, that makes sense.
> 
> Do you want a dmesg at module load time, on every open, or a sysfs
> something? What seems like it would make it into a bug report?

I think dmesg at module load time should probably be ok, every open
seems like harassment and sysfs would require updated support in
various bug reporting tools.  Users are often terrible about reporting
full dmesg in bugs, but they do often filter it for "IOMMU" or "VFIO",
so keep that in mind when crafting the log message.  Thanks,

Alex

Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

[Alex Williamson]

On Fri, 28 Oct 2022 15:40:09 -0300
Jason Gunthorpe  wrote:

> On Wed, Oct 26, 2022 at 03:24:42PM -0600, Alex Williamson wrote:
> > On Tue, 25 Oct 2022 15:17:10 -0300
> > Jason Gunthorpe  wrote:
> >   
> > > This legacy module knob has become uAPI, when set on the vfio_iommu_type1
> > > it disables some security protections in the iommu drivers. Move the
> > > storage for this knob to vfio_main.c so that iommufd can access it too.  
> > 
> > I don't really understand this, we're changing the behavior of the
> > iommufd_device_attach() operation based on the modules options of
> > vfio_iommu_type1,   
> 
> The specific reason it was done is that we had a misconfigured test VM
> in the farm that needed it, and that VM has since been fixed. But it
> did highlight we should try to preserve this in some way.
> 
> > which may not be loaded or even compiled into the
> > kernel.  Our compatibility story falls apart when VFIO_CONTAINER is not
> > set, iommufd sneaks in to usurp /dev/vfio/vfio, and the user's module
> > options for type1 go unprocessed.  
> 
> There are two aspects here, trying to preseve the
> allow_unsafe_interrupts knob as it is already as some ABI in the best
> way we can.
> 
> And the second is how do we make this work in the new world where
> there may be no type 1 module at all. This patch is not trying to
> address that topic. I am expecting a range of small adjustments before
> VFIO_CONTAINER=n becomes really fully viable.
> 
> > I hate to suggest that type1 becomes a module that does nothing more
> > than maintain consistency of this variable when the full type1 isn't
> > available, but is that what we need to do?  
> 
> It is one idea, it depends how literal you want to be on "module
> parameters are ABI". IMHO it is a weak form of ABI and the need of
> this paramter in particular is not that common in modern times, AFAIK.
> 
> So perhaps we just also expose it through vfio.ko and expect people to
> migrate. That would give a window were both options are available.

That might be best.  Ultimately this is an opt-out of a feature that
has security implications, so I'd rather error on the side of requiring
the user to re-assert that opt-out.  It seems the potential good in
eliminating stale or unnecessary options outweighs any weak claims of
preserving an ABI for a module that's no longer in service.

However, I'd question whether vfio is the right place for that new
module option.  As proposed, vfio is only passing it through to
iommufd, where an error related to lack of the hardware feature is
masked behind an -EPERM by the time it gets back to vfio, making any
sort of advisory to the user about the module option convoluted.  It
seems like iommufd should own the option to opt-out universally, not
just through the vfio use case.  Thanks,

Alex

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Introduce Wa_18017747507

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Introduce Wa_18017747507
URL   : https://patchwork.freedesktop.org/series/110323/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110323v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
- shard-iclb: [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/shard-iclb1/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html

  
 Suppressed 

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

  * igt@gem_exec_gttfill@all:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/shard-rkl-2/igt@gem_exec_gttf...@all.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-3:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/shard-dg1-19/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-3.html

  * igt@perf_pmu@render-node-busy@vecs0:
- {shard-dg1}:[PASS][5] -> [FAIL][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-dg1-13/igt@perf_pmu@render-node-b...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/shard-dg1-19/igt@perf_pmu@render-node-b...@vecs0.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-snb:  ([PASS][7], [PASS][8], [PASS][9], [PASS][10], 
[PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], 
[PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], 
[PASS][29], [PASS][30], [PASS][31]) -> ([PASS][32], [PASS][33], [PASS][34], 
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [FAIL][40], 
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], 
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], 
[PASS][53], [PASS][54], [PASS][55], [PASS][56]) ([i915#4338])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [27]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more
URL   : https://patchwork.freedesktop.org/series/110341/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110341v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Additional (1): fi-rkl-11600 
  Missing(2): fi-cml-u2 fi-icl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][11] ([i915#4817])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#4103])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-2:
- fi-bdw-5557u:   [PASS][15] -> [INCOMPLETE][16] ([i915#146])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-2.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#1072]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4098])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][20] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110341v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  * 

[Intel-gfx] [PATCH i-g-t] tests/sysfs: Update timeslice/preemption for new range limits

[John . C . Harrison]

From: John Harrison 

Guc submission imposes new range limits on certain scheduling
parameters. The idempotent sections of the timeslice duration and
pre-emption timeout tests was exceeding those limits and so would fail.

Reduce the excessively large value (654s) to one which does not
overflow (54s). Also add an assert that the write of the new value
actually succeeds.

Signed-off-by: John Harrison 
---
 tests/i915/sysfs_preempt_timeout.c| 4 ++--
 tests/i915/sysfs_timeslice_duration.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/i915/sysfs_preempt_timeout.c 
b/tests/i915/sysfs_preempt_timeout.c
index 515038281638..5e0a7d96299f 100644
--- a/tests/i915/sysfs_preempt_timeout.c
+++ b/tests/i915/sysfs_preempt_timeout.c
@@ -68,7 +68,7 @@ static void set_preempt_timeout(int engine, unsigned int 
value)
 {
unsigned int delay;
 
-   igt_sysfs_printf(engine, ATTR, "%u", value);
+   igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
igt_sysfs_scanf(engine, ATTR, "%u", );
igt_assert_eq(delay, value);
 }
@@ -82,7 +82,7 @@ static int wait_for_reset(int fence)
 
 static void test_idempotent(int i915, int engine)
 {
-   unsigned int delays[] = { 0, 1, 1000, 1234, 654321 };
+   unsigned int delays[] = { 0, 1, 1000, 1234, 54321 };
unsigned int saved;
 
/* Quick test that store/show reports the same values */
diff --git a/tests/i915/sysfs_timeslice_duration.c 
b/tests/i915/sysfs_timeslice_duration.c
index 8a2f1c2f2ece..95dc377785a5 100644
--- a/tests/i915/sysfs_timeslice_duration.c
+++ b/tests/i915/sysfs_timeslice_duration.c
@@ -79,7 +79,7 @@ static void set_timeslice(int engine, unsigned int value)
 {
unsigned int delay;
 
-   igt_sysfs_printf(engine, ATTR, "%u", value);
+   igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
igt_sysfs_scanf(engine, ATTR, "%u", );
igt_assert_eq(delay, value);
 }
@@ -93,7 +93,7 @@ static int wait_for_reset(int fence)
 
 static void test_idempotent(int i915, int engine)
 {
-   const unsigned int delays[] = { 0, 1, 1234, 654321 };
+   const unsigned int delays[] = { 0, 1, 1234, 54321 };
unsigned int saved;
 
/* Quick test to verify the kernel reports the same values as we write 
*/
-- 
2.37.3

Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation

[jim . cromie]

On Mon, Oct 31, 2022 at 7:07 AM Ville Syrjälä
 wrote:
>
> On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> > On Thu, Oct 27, 2022 at 2:10 PM Ville Syrjälä
> >  wrote:
> > >
> > > On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> > > > On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> > > >  wrote:
> > > > >
> > > > > On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > > > > > On Thu, Oct 27, 2022 at 9:08 AM Jason Baron  
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/21/22 05:18, Jani Nikula wrote:
> > > > > > > > On Thu, 20 Oct 2022, Ville Syrjälä 
> > > > > > > >  wrote:
> > > > > > > >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> > > > > > > >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> > > > > > >  hi Greg, Dan, Jason, DRM-folk,
> > > > > > > 
> > > > > > >  heres follow-up to V6:
> > > > > > >    rebased on driver-core/driver-core-next for -v6 applied 
> > > > > > >  bits (thanks)
> > > > > > >    rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> > > > > > > 
> > > > > > >  It excludes:
> > > > > > >    nouveau parts (immature)
> > > > > > >    tracefs parts (I missed --to=Steve on v6)
> > > > > > >    split _ddebug_site and de-duplicate experiment (way 
> > > > > > >  unready)
> > > > > > > 
> > > > > > >  IOW, its the remaining commits of V6 on which Dan gave his 
> > > > > > >  Reviewed-by.
> > > > > > > 
> > > > > > >  If these are good to apply, I'll rebase and repost the rest 
> > > > > > >  separately.
> > > > > > > >>>
> > > > > > > >>> All now queued up, thanks.
> > > > > > > >>
> > > > > > > >> This stuff broke i915 debugs. When I first load i915 no debug 
> > > > > > > >> prints are
> > > > > > > >> produced. If I then go fiddle around in 
> > > > > > > >> /sys/module/drm/parameters/debug
> > > > > > > >> the debug prints start to suddenly work.
> > > > > > > >
> > > > > > > > Wait what? I always assumed the default behaviour would stay 
> > > > > > > > the same,
> > > > > > > > which is usually how we roll. It's a regression in my books. 
> > > > > > > > We've got a
> > > > > > > > CI farm that's not very helpful in terms of dmesg logging right 
> > > > > > > > now
> > > > > > > > because of this.
> > > > > > > >
> > > > > > > > BR,
> > > > > > > > Jani.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > That doesn't sound good - so you are saying that prior to this 
> > > > > > > change some
> > > > > > > of the drm debugs were default enabled. But now you have to 
> > > > > > > manually enable
> > > > > > > them?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > -Jason
> > > > > >
> > > > > >
> > > > > > Im just seeing this now.
> > > > > > Any new details ?
> > > > >
> > > > > No. We just disabled it as BROKEN for now. I was just today thinking
> > > > > about sending that patch out if no solutin is forthcoming soon since
> > > > > we need this working before 6.1 is released.
> > > > >
> > > > > Pretty sure you should see the problem immediately with any driver
> > > > > (at least if it's built as a module, didn't try builtin). Or at least
> > > > > can't think what would make i915 any more special.
> > > > >
> > > >
> > > > So, I should note -
> > > > 99% of my time & energy on this dyndbg + drm patchset
> > > > has been done using virtme,
> > > > so my world-view (and dev-hack-test env) has been smaller, simpler
> > > > maybe its been fatally simplistic.
> > > >
> > > > ive just rebuilt v6.0  (before the trouble)
> > > > and run it thru my virtual home box,
> > > > I didnt see any unfamiliar drm-debug output
> > > > that I might have inadvertently altered somehow
> > > >
> > > > I have some real HW I can put a reference kernel on,0
> > > > to look for the missing output, but its all gonna take some time,
> > > > esp to tighten up my dev-test-env
> > > >
> > > > in the meantime, there is:
> > > >
> > > > config DRM_USE_DYNAMIC_DEBUG
> > > > bool "use dynamic debug to implement drm.debug"
> > > > default y
> > > > depends on DRM
> > > > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> > > > depends on JUMP_LABEL
> > > > help
> > > >   Use dynamic-debug to avoid drm_debug_enabled() runtime overheads.
> > > >   Due to callsite counts in DRM drivers (~4k in amdgpu) and 56
> > > >   bytes per callsite, the .data costs can be substantial, and
> > > >   are therefore configurable.
> > > >
> > > > Does changing the default fix things for i915 dmesg ?
> > >
> > > I think we want to mark it BROKEN in addition to make sure no one
> >
> > Ok, I get the distinction now.
> > youre spelling that
> >   depends on BROKEN
> >
> > I have a notional explanation, and a conflating commit:
> >
> > can you eliminate
> > git log -p ccc2b496324c13e917ef05f563626f4e7826bef1
> >
> > as the cause ?
>
> Reverting that doesn't help.
>

thanks for eliminating it.

> >
> > I do need to 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more
URL   : https://patchwork.freedesktop.org/series/110341/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more
URL   : https://patchwork.freedesktop.org/series/110341/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./drivers/gpu/drm/i915/intel_uncore.h:333:1: warning: trying to copy 
expression type 31

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use intel_crtc_needs_modeset() more
URL   : https://patchwork.freedesktop.org/series/110341/
State : warning

== Summary ==

Error: dim checkpatch failed
b5bd37c4172e drm/i915: Use intel_crtc_needs_modeset() more
8f0008b80c98 drm/i915: Switch intel_connector_needs_modeset() to drm types
-:41: WARNING:LONG_LINE: line length of 108 exceeds 100 columns
#41: FILE: drivers/gpu/drm/i915/display/intel_atomic.c:188:
+
drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc)));

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

[Intel-gfx] [PATCH] drm/i915/guc: Remove excessive line feeds in state dumps

[John . C . Harrison]

From: John Harrison 

Some of the GuC state dump messages were adding extra line feeds. When
printing via a DRM printer to dmesg, for example, that messes up the
log formatting as it loses any prefixing from the printer. Given that
the extra line feeds are just in the middle of random bits of GuC
state, there isn't any real need for them. So just remove them
completely.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 27b09ba1d295f..1bcd61bb50f89 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -871,14 +871,14 @@ void intel_guc_load_status(struct intel_guc *guc, struct 
drm_printer *p)
u32 status = intel_uncore_read(uncore, GUC_STATUS);
u32 i;
 
-   drm_printf(p, "\nGuC status 0x%08x:\n", status);
+   drm_printf(p, "GuC status 0x%08x:\n", status);
drm_printf(p, "\tBootrom status = 0x%x\n",
   (status & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT);
drm_printf(p, "\tuKernel status = 0x%x\n",
   (status & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT);
drm_printf(p, "\tMIA Core status = 0x%x\n",
   (status & GS_MIA_MASK) >> GS_MIA_SHIFT);
-   drm_puts(p, "\nScratch registers:\n");
+   drm_puts(p, "Scratch registers:\n");
for (i = 0; i < 16; i++) {
drm_printf(p, "\t%2d: \t0x%x\n",
   i, intel_uncore_read(uncore, 
SOFT_SCRATCH(i)));
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 4ccb29f9ac55c..4dbdac8002e32 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4901,7 +4901,7 @@ void intel_guc_submission_print_info(struct intel_guc 
*guc,
 
drm_printf(p, "GuC Number Outstanding Submission G2H: %u\n",
   atomic_read(>outstanding_submission_g2h));
-   drm_printf(p, "GuC tasklet count: %u\n\n",
+   drm_printf(p, "GuC tasklet count: %u\n",
   atomic_read(_engine->tasklet.count));
 
spin_lock_irqsave(_engine->lock, flags);
@@ -4949,7 +4949,7 @@ static inline void guc_log_context(struct drm_printer *p,
   atomic_read(>pin_count));
drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
   atomic_read(>guc_id.ref));
-   drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
+   drm_printf(p, "\t\tSchedule State: 0x%x\n",
   ce->guc_state.sched_state);
 }
 
@@ -4978,7 +4978,7 @@ void intel_guc_submission_print_context_info(struct 
intel_guc *guc,
   
READ_ONCE(*ce->parallel.guc.wq_head));
drm_printf(p, "\t\tWQI Tail: %u\n",
   
READ_ONCE(*ce->parallel.guc.wq_tail));
-   drm_printf(p, "\t\tWQI Status: %u\n\n",
+   drm_printf(p, "\t\tWQI Status: %u\n",
   
READ_ONCE(*ce->parallel.guc.wq_status));
}
 
@@ -4986,7 +4986,7 @@ void intel_guc_submission_print_context_info(struct 
intel_guc *guc,
emit_bb_start_parent_no_preempt_mid_batch) {
u8 i;
 
-   drm_printf(p, "\t\tChildren Go: %u\n\n",
+   drm_printf(p, "\t\tChildren Go: %u\n",
   get_children_go_value(ce));
for (i = 0; i < ce->parallel.number_children; 
++i)
drm_printf(p, "\t\tChildren Join: %u\n",
-- 
2.37.3

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hwmon: Don't use FIELD_PREP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Don't use FIELD_PREP (rev2)
URL   : https://patchwork.freedesktop.org/series/110301/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110301v2


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 40)
--

  Additional (2): fi-kbl-soraka fi-rkl-11600 
  Missing(2): fi-cml-u2 fi-hsw-4770 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110301v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3012])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110301v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@i915_selftest@live@mman:
- fi-rkl-guc: [PASS][12] -> [INCOMPLETE][13] ([i915#6794])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-rkl-guc/igt@i915_selftest@l...@mman.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110301v2/fi-rkl-guc/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][14] ([i915#4817])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110301v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#111827]) +7 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110301v2/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#4103])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110301v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109285] / [i915#4098])
   [18]: 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/mtl: Add C10 and C20 phy support (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add C10 and C20 phy support (rev2)
URL   : https://patchwork.freedesktop.org/series/109714/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/109714/revisions/2/mbox/ not 
applied
warning: quoted CRLF detected
Applying: drm/i915/mtl: Initial DDI port setup
Applying: drm/i915/mtl: Add DP rates
Applying: drm/i915/mtl: Create separate reg file for PICA registers
Applying: drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
Applying: drm/i915/mtl: Add C10 phy programming for HDMI
Applying: drm/i915/mtl: Add vswing programming for C10 phys
error: corrupt patch at line 30
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0006 drm/i915/mtl: Add vswing programming for C10 phys
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: Do both crawl and squash 
when changing cdclk (rev2)
URL   : https://patchwork.freedesktop.org/series/110275/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/110275/revisions/2/mbox/ not 
applied
Applying: drm/i915/display: Do both crawl and squash when changing cdclk
Applying: drm/i915/display: Add CDCLK Support for MTL
error: patch fragment without header at line 16: @@ -3294,7 +3311,10 @@ static 
const struct intel_cdclk_funcs i830_cdclk_funcs = {
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 drm/i915/display: Add CDCLK Support for MTL
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] [PATCH 2/2] drm/i915: Switch intel_connector_needs_modeset() to drm types

[Ville Syrjala]

From: Ville Syrjälä 

intel_connector_needs_modeset() currently uses a mix of drm_
and intel_ types. But it doesn't actually need anything from
the intel_ stuff, so seems better to switch the whole thing
over to the drm_ types. Should help anyone who wants to steal
it as well :)

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_atomic.c  | 11 +--
 drivers/gpu/drm/i915/display/intel_atomic.h  |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  2 +-
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 6621aa245caf..f3fe2889bde3 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -175,18 +175,17 @@ intel_digital_connector_duplicate_state(struct 
drm_connector *connector)
  * @connector: the connector
  */
 bool
-intel_connector_needs_modeset(struct intel_atomic_state *state,
+intel_connector_needs_modeset(struct drm_atomic_state *state,
  struct drm_connector *connector)
 {
const struct drm_connector_state *old_conn_state, *new_conn_state;
 
-   old_conn_state = drm_atomic_get_old_connector_state(>base, 
connector);
-   new_conn_state = drm_atomic_get_new_connector_state(>base, 
connector);
+   old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+   new_conn_state = drm_atomic_get_new_connector_state(state, connector);
 
return old_conn_state->crtc != new_conn_state->crtc ||
-  (new_conn_state->crtc &&
-   
drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_state(>base,
-   
new_conn_state->crtc)));
+   (new_conn_state->crtc &&
+
drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc)));
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h 
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 1dc439983dd9..8829b6f58aee 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -33,7 +33,7 @@ int intel_digital_connector_atomic_check(struct drm_connector 
*conn,
 struct drm_atomic_state *state);
 struct drm_connector_state *
 intel_digital_connector_duplicate_state(struct drm_connector *connector);
-bool intel_connector_needs_modeset(struct intel_atomic_state *state,
+bool intel_connector_needs_modeset(struct drm_atomic_state *state,
   struct drm_connector *connector);
 bool intel_any_crtc_needs_modeset(struct intel_atomic_state *state);
 struct intel_digital_connector_state *
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2d91c59a827d..1a16625ce058 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1517,7 +1517,7 @@ static void intel_encoders_update_prepare(struct 
intel_atomic_state *state)
struct intel_encoder *encoder;
struct intel_crtc *crtc;
 
-   if (!intel_connector_needs_modeset(state, connector))
+   if (!intel_connector_needs_modeset(>base, connector))
continue;
 
intel_connector = to_intel_connector(connector);
@@ -1546,7 +1546,7 @@ static void intel_encoders_update_complete(struct 
intel_atomic_state *state)
struct intel_encoder *encoder;
struct intel_crtc *crtc;
 
-   if (!intel_connector_needs_modeset(state, connector))
+   if (!intel_connector_needs_modeset(>base, connector))
continue;
 
intel_connector = to_intel_connector(connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7400d6b4c587..7c740463e9b6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5028,7 +5028,7 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
if (DISPLAY_VER(dev_priv) < 9)
return 0;
 
-   if (!intel_connector_needs_modeset(state, conn))
+   if (!intel_connector_needs_modeset(>base, conn))
return 0;
 
if (conn->has_tile) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cd4e61026d98..1220776eafc3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -269,7 +269,7 @@ intel_dp_mst_atomic_master_trans_check(struct 
intel_connector *connector,
if (DISPLAY_VER(dev_priv) < 12)
return  0;
 
-   if 

[Intel-gfx] [PATCH 1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Ville Syrjala]

From: Ville Syrjälä 

Prefer our own intel_crtc_needs_modeset() wrapper to
drm_atomic_crtc_needs_modeset() whenever we are dealing
with the intel_ types instead of drm_ types. Makes things
a bit neater in general.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_color.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_fbc.c |  2 +-
 drivers/gpu/drm/i915/display/skl_watermark.c |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 11 +--
 6 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index eada931cb1c8..8a9031012d74 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2755,7 +2755,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state 
*state)
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
 
-   if (drm_atomic_crtc_needs_modeset(_state->uapi))
+   if (intel_crtc_needs_modeset(crtc_state))
pipe = INVALID_PIPE;
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 4bb113c39f4b..1bd074431d89 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1240,7 +1240,7 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
struct intel_plane *plane;
 
if (!new_crtc_state->hw.active ||
-   drm_atomic_crtc_needs_modeset(_crtc_state->uapi))
+   intel_crtc_needs_modeset(new_crtc_state))
return 0;
 
if (new_crtc_state->gamma_enable == old_crtc_state->gamma_enable &&
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b9393f9fc764..2d91c59a827d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5930,7 +5930,7 @@ int intel_modeset_all_pipes(struct intel_atomic_state 
*state,
return PTR_ERR(crtc_state);
 
if (!crtc_state->hw.active ||
-   drm_atomic_crtc_needs_modeset(_state->uapi))
+   intel_crtc_needs_modeset(crtc_state))
continue;
 
drm_dbg_kms(_priv->drm, "[CRTC:%d:%s] Full modeset due to 
%s\n",
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 3f24f326b989..b5ee5ea0d010 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1183,7 +1183,7 @@ static bool intel_fbc_can_flip_nuke(struct 
intel_atomic_state *state,
const struct drm_framebuffer *old_fb = old_plane_state->hw.fb;
const struct drm_framebuffer *new_fb = new_plane_state->hw.fb;
 
-   if (drm_atomic_crtc_needs_modeset(_crtc_state->uapi))
+   if (intel_crtc_needs_modeset(new_crtc_state))
return false;
 
if (!intel_fbc_is_ok(old_plane_state) ||
diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c 
b/drivers/gpu/drm/i915/display/skl_watermark.c
index d58e667016e4..e0766d1be966 100644
--- a/drivers/gpu/drm/i915/display/skl_watermark.c
+++ b/drivers/gpu/drm/i915/display/skl_watermark.c
@@ -2744,7 +2744,7 @@ static int skl_wm_add_affected_planes(struct 
intel_atomic_state *state,
 * power well the hardware state will go out of sync
 * with the software state.
 */
-   if (!drm_atomic_crtc_needs_modeset(_crtc_state->uapi) &&
+   if (!intel_crtc_needs_modeset(new_crtc_state) &&
skl_plane_selected_wm_equals(plane,
 
_crtc_state->wm.skl.optimal,
 
_crtc_state->wm.skl.optimal))
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee34e2785636..73c88b1c9545 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1426,7 +1426,7 @@ static int g4x_compute_intermediate_wm(struct 
intel_atomic_state *state,
enum plane_id plane_id;
 
if (!new_crtc_state->hw.active ||
-   drm_atomic_crtc_needs_modeset(_crtc_state->uapi)) {
+   intel_crtc_needs_modeset(new_crtc_state)) {
*intermediate = *optimal;
 
intermediate->cxsr = false;
@@ -1914,7 +1914,6 @@ static int vlv_compute_pipe_wm(struct intel_atomic_state 
*state,
 {
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
-   bool needs_modeset = drm_atomic_crtc_needs_modeset(_state->uapi);
const struct intel_plane_state *old_plane_state;
const struct intel_plane_state 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/hwmon: Don't use FIELD_PREP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Don't use FIELD_PREP (rev2)
URL   : https://patchwork.freedesktop.org/series/110301/
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 drm/i915/hwmon: Don't use FIELD_PREP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Don't use FIELD_PREP (rev2)
URL   : https://patchwork.freedesktop.org/series/110301/
State : warning

== Summary ==

Error: dim checkpatch failed
6a7780f724ae drm/i915/hwmon: Don't use FIELD_PREP
-:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible 
side-effects?
#46: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:70:
+#define __REG_FIELD_PREP_CHK(__mask, __val) \
+   (BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
+BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + \
+BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0)))

-:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__val' - possible 
side-effects?
#46: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:70:
+#define __REG_FIELD_PREP_CHK(__mask, __val) \
+   (BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
+BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + \
+BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0)))

-:50: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#50: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:74:
+BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0)))

-:52: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible 
side-effects?
#52: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:76:
+#define __REG_FIELD_PREP(__mask, __val) \
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask

-:55: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible 
side-effects?
#55: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:79:
+#define REG_FIELD_PREP(__mask, __val) \
+   (__REG_FIELD_PREP(__mask, __val) + __REG_FIELD_PREP_CHK(__mask, __val))

-:55: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__val' - possible 
side-effects?
#55: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:79:
+#define REG_FIELD_PREP(__mask, __val) \
+   (__REG_FIELD_PREP(__mask, __val) + __REG_FIELD_PREP_CHK(__mask, __val))

total: 0 errors, 1 warnings, 5 checks, 31 lines checked

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6
URL   : https://patchwork.freedesktop.org/series/110326/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110326v1


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 28)
--

  Additional (1): fi-kbl-soraka 
  Missing(13): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][5] -> [SKIP][6] ([fdo#109271]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html

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

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

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-2:
- fi-bdw-5557u:   [PASS][11] -> [INCOMPLETE][12] ([i915#146])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-2.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v1/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-2.html

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

  
 Possible fixes 

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6
URL   : https://patchwork.freedesktop.org/series/110326/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'

Re: [Intel-gfx] [PATCH 06/20] drm/i915/mtl: Add vswing programming for C10 phys

[Taylor, Clinton A]

to fix the FIXME in intel_cx0_phy_set_signal_levels() we need the following 
patch snipet to be incorporated into this patch.


@@ -331,18 +331,14 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder 
*encoder,
    }
  }

- intel_cx0_write(i915, encoder->port, master_lane, PHY_C10_VDR_CONTROL(1),
- C10_VDR_CTRL_MASTER_LANE | C10_VDR_CTRL_UPDATE_CFG,
+ intel_cx0_write(i915, encoder->port, !master_lane, PHY_C10_VDR_CONTROL(1),
+ C10_VDR_CTRL_MSGBUS_ACCESS | C10_VDR_CTRL_UPDATE_CFG,
  MB_WRITE_COMMITTED);
-#if 0
- /*
-  * FIXME: Revisit this code to see why we can't update
-  * config on Lane 1
-  */
- intel_cx0_rmw(i915, encoder->port, !master_lane, PHY_C10_VDR_CONTROL(1),
- C10_VDR_CTRL_MSGBUS_ACCESS | C10_VDR_CTRL_UPDATE_CFG, 
C10_VDR_CTRL_UPDATE_CFG,
+
+ intel_cx0_write(i915, encoder->port, master_lane, PHY_C10_VDR_CONTROL(1),
+ C10_VDR_CTRL_MSGBUS_ACCESS | C10_VDR_CTRL_MASTER_LANE | 
C10_VDR_CTRL_UPDATE_CFG,
  MB_WRITE_COMMITTED);
-#endif
+
  intel_cx0_phy_transaction_end(encoder, wakeref);
 }

Sorry for the top post - webmail
-Clint


From: Kahola, Mika 
Sent: Friday, October 14, 2022 5:47 AM
To: intel-gfx@lists.freedesktop.org 
Cc: Kahola, Mika ; Sripada, Radhakrishna 
; Deak, Imre ; Shankar, 
Uma ; Taylor, Clinton A 
Subject: [PATCH 06/20] drm/i915/mtl: Add vswing programming for C10 phys

From: Radhakrishna Sripada 

C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.

Bspec: 65449

Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 143 --
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   2 +
 .../gpu/drm/i915/display/intel_cx0_reg_defs.h |   6 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   4 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|  36 -
 .../drm/i915/display/intel_ddi_buf_trans.h|   6 +
 .../i915/display/intel_display_power_map.c|   1 +
 7 files changed, 185 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index dc033174c9c0..ef874986940d 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -6,10 +6,14 @@
 #include "i915_reg_defs.h"
 #include "intel_cx0_phy.h"
 #include "intel_cx0_reg_defs.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_panel.h"
+#include "intel_psr.h"
+#include "intel_uncore.h"

 bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
 {
@@ -19,6 +23,15 @@ bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum 
phy phy)
 return false;
 }

+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+   bool enabled;
+
+   enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+   drm_WARN_ON(>drm, !enabled);
+}
+
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
 {
 enum phy phy = intel_port_to_phy(i915, port);
@@ -108,6 +121,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915, 
enum port port,
 int i, status;
 u32 val;

+   assert_dc_off(i915);
+
 for (i = 0; i < 3; i++) {
 status = __intel_cx0_read(i915, port, lane, addr, );

@@ -191,6 +206,8 @@ static void __intel_cx0_write(struct drm_i915_private 
*i915, enum port port,
 enum phy phy = intel_port_to_phy(i915, port);
 int i, status;

+   assert_dc_off(i915);
+
 for (i = 0; i < 3; i++) {
 status = __intel_cx0_write_once(i915, port, lane, addr, data, 
committed);

@@ -240,6 +257,84 @@ static void intel_cx0_rmw(struct drm_i915_private *i915, 
enum port port,
 }
 }

+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder 
*encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_pause(intel_dp);
+   return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder, 
intel_wakeref_t wakeref)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_resume(intel_dp);
+   intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
+}
+
+void intel_cx0_phy_set_signal_levels(struct 

Re: [Intel-gfx] [RFC 00/17] DRM scheduling cgroup controller

[Tejun Heo]

Hello,

On Thu, Oct 27, 2022 at 03:32:00PM +0100, Tvrtko Ursulin wrote:
> Looking at what's available in cgroups world now, I have spotted the
> blkio.prio.class control. For my current use case (lower GPU scheduling of
> background/unfocused windows) that would also work. Even if starting with
> just two possible values - 'no-change' and 'idle' (to follow the IO
> controller naming).

I wouldn't follow that example. That's only meaningful within the context of
bfq and it probabaly shouldn't have been merged in the first place.

> How would you view that as a proposal? It would be a bit tougher "sell" to
> the DRM community, perhaps, given that many drivers do have scheduling
> priority, but the concept of scheduling class is not really there.
> Nevertheless a concept of normal-vs-background could be plausible in my
> mind. It could be easily implemented by using the priority controls
> available in many drivers.

I don't feel great about that.

* The semantics aren't clearly defined. While not immediately obvious in the
  interface, the task nice levels have definite mappings to weight values
  and thus clear meanings. I don't think it's a good idea to leave the
  interface semantics open to interpretation.

* Maybe GPUs are better but my experience with optional hardware features in
  the storage world has been that vendors diverge wildly and unexpectedly to
  the point many features are mostly useless. There are fewer GPU vendors
  and more software effort behind each, so maybe the situation is better but
  I think it'd be helpul to keep some skepticism.

* Even when per-vendor or per-driver features are consistent enough to be
  useful, they often aren't thought through enough to be truly useful. e.g.
  nvme has priority features but they aren't really that useful because they
  can't do much without congestion control on the issuer side and once you
  have congestion control on the issuer side which is usually a lot more
  complex (e.g. dealing with work-conserving hierarchical weight
  distributions, priority inversions and so on), you can achieve most of
  what you need in terms of resource control from the issuer side anyway.

So, I'd much prefer to have a fuller solution on the kernel side which
integrates per-vendor/driver features where they make sense.

> > >drm.budget_supported
> > >   One of:
> > >1) 'yes' - when all DRM clients in the group support the functionality.
> > >2) 'no' - when at least one of the DRM clients does not support the
> > >  functionality.
> > >3) 'n/a' - when there are no DRM clients in the group.
> > 
> > Yeah, I'm not sure about this. This isn't a per-cgroup property to begin
> > with and I'm not sure 'no' meaning at least one device not supporting is
> > intuitive. The distinction between 'no' and 'n/a' is kinda weird too. Please
> > drop this.
> 
> The idea actually is for this to be per-cgroup and potentially change
> dynamically. It implements the concept of "observability", how I have,
> perhaps clumsily, named it.
> 
> This is because we can have a mix of DRM file descriptors in a cgroup, not
> all of which support the proposed functionality. So I wanted to have
> something by which the administrator can observe the status of the group.
> 
> For instance seeing some clients do not support the feature could be signal
> that things have been misconfigured, or that appeal needs to be made for
> driver X to start supporting the feature. Seeing a "no" there in other words
> is a signal that budgeting may not really work as expected and needs to be
> investigated.

I still don't see how this is per-cgroup given that it's indicating whether
the driver supports some feature. Also, the eventual goal would be
supporting the same control mechanisms across most (if not all) GPUs, right?

> > Rather than doing it hierarchically on the spot, it's usually a lot cheaper
> > and easier to calculate the flattened hierarchical weight per leaf cgroup
> > and divide the bandwidth according to the eventual portions. For an example,
> > please take a look at block/blk-iocost.c.
> 
> This seems exactly what I had in mind (but haven't implemented it yet). So
> in this RFC I have budget splitting per group where each tree level adds up
> to "100%" and the thing which I have not implemented is "borrowing" or
> yielding (how blk-iocost.c calls it, or donating) unused budgets to
> siblings.
> 
> I am very happy to hear my idea is the right one and someone already
> implemented it. Thanks for this pointer!

The budget donation thing in iocost is necessary only because it wants to
make the hot path local to the cgroup because io control has to support very
high decision rate. For time-slicing GPU, it's likely that following the
current hierarchical weight on the spot is enough.

Thanks.

-- 
tejun

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Introduce Wa_18017747507

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Introduce Wa_18017747507
URL   : https://patchwork.freedesktop.org/series/110323/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110323v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): fi-cml-u2 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.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_12325/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@lmem0:
- {bat-dg2-11}:   [DMESG-FAIL][6] ([fdo#103375]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}:   [DMESG-WARN][8] ([i915#2867]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}:   [FAIL][10] ([fdo#103375]) -> [PASS][11] +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}:   [DMESG-WARN][12] ([i915#2867]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [WARN][14] ([i915#7346]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-rpls-2/igt@i915_pm_...@module-reload.html

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-dp-3:
- {bat-dg2-11}:   [FAIL][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-dp-3:
- {bat-dg2-11}:   [FAIL][20] ([i915#6818]) -> [PASS][21] +2 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-dp-3.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-dp-3.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-icl-u2:  [DMESG-WARN][22] ([i915#2867]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html

  
  

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Media GT and Render GT share common GGTT

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Media GT and Render GT share common GGTT
URL   : https://patchwork.freedesktop.org/series/110321/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110321v1


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 31)
--

  Additional (3): fi-kbl-soraka fi-rkl-11600 fi-tgl-dsi 
  Missing(12): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-ilk-650: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-ilk-650/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-ilk-650/igt@i915_module_l...@load.html
- fi-bxt-dsi: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-bxt-dsi/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-bxt-dsi/igt@i915_module_l...@load.html
- fi-blb-e6850:   [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-blb-e6850/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-blb-e6850/igt@i915_module_l...@load.html
- fi-rkl-11600:   NOTRUN -> [DMESG-WARN][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-rkl-11600/igt@i915_module_l...@load.html
- fi-skl-6600u:   [PASS][8] -> [INCOMPLETE][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-skl-6600u/igt@i915_module_l...@load.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-skl-6600u/igt@i915_module_l...@load.html
- fi-icl-u2:  [PASS][10] -> [DMESG-WARN][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@i915_module_l...@load.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-icl-u2/igt@i915_module_l...@load.html
- fi-apl-guc: [PASS][12] -> [DMESG-WARN][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-apl-guc/igt@i915_module_l...@load.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-apl-guc/igt@i915_module_l...@load.html
- fi-bdw-gvtdvm:  [PASS][14] -> [DMESG-WARN][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
- fi-pnv-d510:[PASS][16] -> [DMESG-WARN][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-pnv-d510/igt@i915_module_l...@load.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-pnv-d510/igt@i915_module_l...@load.html
- fi-snb-2520m:   [PASS][18] -> [DMESG-WARN][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-snb-2520m/igt@i915_module_l...@load.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-snb-2520m/igt@i915_module_l...@load.html
- fi-glk-j4005:   [PASS][20] -> [DMESG-WARN][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-glk-j4005/igt@i915_module_l...@load.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-glk-j4005/igt@i915_module_l...@load.html
- fi-rkl-guc: [PASS][22] -> [DMESG-WARN][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-rkl-guc/igt@i915_module_l...@load.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-rkl-guc/igt@i915_module_l...@load.html
- fi-skl-guc: [PASS][24] -> [DMESG-WARN][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-skl-guc/igt@i915_module_l...@load.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-skl-guc/igt@i915_module_l...@load.html
- fi-skl-6700k2:  [PASS][26] -> [DMESG-WARN][27]
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-skl-6700k2/igt@i915_module_l...@load.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v1/fi-skl-6700k2/igt@i915_module_l...@load.html
- fi-kbl-7567u: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Media GT and Render GT share common GGTT

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Media GT and Render GT share common GGTT
URL   : https://patchwork.freedesktop.org/series/110321/
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 drm/i915/selftest: Fix gt_pm live_gt_clocks test

[Patchwork]

== Series Details ==

Series: drm/i915/selftest: Fix gt_pm live_gt_clocks test
URL   : https://patchwork.freedesktop.org/series/110318/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110318v1


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 30)
--

  Additional (2): fi-kbl-soraka fi-rkl-11600 
  Missing(12): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rps@basic-api:
- fi-cfl-8109u:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-cfl-8109u/igt@i915_pm_...@basic-api.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-cfl-8109u/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#3012])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][11] ([i915#5334])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
- fi-apl-guc: [PASS][12] -> [DMESG-FAIL][13] ([i915#5334])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

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

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][17] ([i915#4817])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110318v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915/mtl: add initial definitions for GSC CS

[Matt Roper]

On Mon, Oct 31, 2022 at 09:43:33AM -0700, Ceraolo Spurio, Daniele wrote:
> 
> 
> On 10/31/2022 9:26 AM, Matt Roper wrote:
> > On Thu, Oct 27, 2022 at 03:15:50PM -0700, Daniele Ceraolo Spurio wrote:
> > > Starting on MTL, the GSC is no longer managed with direct MMIO access,
> > > but we instead have a dedicated command streamer for it. As a first step
> > > for adding support for this CS, add the required definitions.
> > > Note that, although it is now a CS, the GSC retains its old
> > > class:instance value (OTHER_CLASS instance 6)
> > > 
> > > Signed-off-by: Daniele Ceraolo Spurio 
> > > Cc: Matt Roper 
> > Now that we have an OTHER_CLASS engine, I think we also need to deal
> > with the class -> reg mapping table in mmio_invalidate_full().  I think
> > the register we want is 0xCF04?
> 
> I missed that. Looks like the the situation is a bit more complex than just
> adding the new register, because on pre-MTL platforms CF04 is the compute
> class invalidation register. On MTL as you said CF04 is marked as the GSC CS
> invalidation register, but I can't find the compute one. Do you know if it
> re-uses the render one or something like that?
> Given that there seem to be non-GSC related changes as well, IMO this should
> probably be a separate patch to specifically handle the TLB inval changes on
> MTL.

Yeah, makes sense; we can follow up with separate patches for this.

+Cc Fei since he's done a lot of work on TLB invalidation and may know
what happens to compute class invalidation on MTL when the GSC takes
over that register.


Matt

> 
> Daniele
> 
> > 
> > Matt
> > 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 
> > >   drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> > >   drivers/gpu/drm/i915/gt/intel_engine_user.c  | 1 +
> > >   drivers/gpu/drm/i915/i915_reg.h  | 1 +
> > >   4 files changed, 11 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > index 3b7d750ad054..e0fbfac03979 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > @@ -244,6 +244,13 @@ static const struct engine_info intel_engines[] = {
> > >   { .graphics_ver = 12, .base = 
> > > GEN12_COMPUTE3_RING_BASE }
> > >   }
> > >   },
> > > + [GSC0] = {
> > > + .class = OTHER_CLASS,
> > > + .instance = OTHER_GSC_INSTANCE,
> > > + .mmio_bases = {
> > > + { .graphics_ver = 12, .base = MTL_GSC_RING_BASE }
> > > + }
> > > + },
> > >   };
> > >   /**
> > > @@ -324,6 +331,7 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 
> > > class)
> > >   case VIDEO_DECODE_CLASS:
> > >   case VIDEO_ENHANCEMENT_CLASS:
> > >   case COPY_ENGINE_CLASS:
> > > + case OTHER_CLASS:
> > >   if (GRAPHICS_VER(gt->i915) < 8)
> > >   return 0;
> > >   return GEN8_LR_CONTEXT_OTHER_SIZE;
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> > > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > index 6b5d4ea22b67..4fd54fb8810f 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > @@ -136,6 +136,7 @@ enum intel_engine_id {
> > >   CCS2,
> > >   CCS3,
> > >   #define _CCS(n) (CCS0 + (n))
> > > + GSC0,
> > >   I915_NUM_ENGINES
> > >   #define INVALID_ENGINE ((enum intel_engine_id)-1)
> > >   };
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> > > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > index 46a174f8aa00..79312b734690 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > @@ -140,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
> > >   [COPY_ENGINE_CLASS] = "bcs",
> > >   [VIDEO_DECODE_CLASS] = "vcs",
> > >   [VIDEO_ENHANCEMENT_CLASS] = "vecs",
> > > + [OTHER_CLASS] = "other",
> > >   [COMPUTE_CLASS] = "ccs",
> > >   };
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 1c0da50c0dc7..d056c3117ef2 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -970,6 +970,7 @@
> > >   #define GEN11_VEBOX2_RING_BASE  0x1d8000
> > >   #define XEHP_VEBOX3_RING_BASE   0x1e8000
> > >   #define XEHP_VEBOX4_RING_BASE   0x1f8000
> > > +#define MTL_GSC_RING_BASE0x11a000
> > >   #define GEN12_COMPUTE0_RING_BASE0x1a000
> > >   #define GEN12_COMPUTE1_RING_BASE0x1c000
> > >   #define GEN12_COMPUTE2_RING_BASE0x1e000
> > > -- 
> > > 2.37.3
> > > 
> 

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[John Harrison]

On 10/31/2022 05:51, Tvrtko Ursulin wrote:

On 31/10/2022 10:09, Tvrtko Ursulin wrote:

On 28/10/2022 20:46, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

Update the worker to abort if a reset is in progress rather than
waiting for it to complete. It will still acquire the reset lock in
the case where a reset was not already in progress. So the processing
is still safe from corruption, but the deadlock can no longer occur.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 15 
++-

  drivers/gpu/drm/i915/gt/intel_reset.h |  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 --
  3 files changed, 19 insertions(+), 3 deletions(-)

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

index 3159df6cdd492..2f48c6e4420ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,7 +1407,7 @@ void intel_gt_handle_error(struct intel_gt *gt,
  intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
-int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+static int _intel_gt_reset_trylock(struct intel_gt *gt, int *srcu, 
bool retry)

  {
  might_lock(>reset.backoff_srcu);
  might_sleep();
@@ -1416,6 +1416,9 @@ int intel_gt_reset_trylock(struct intel_gt 
*gt, int *srcu)

  while (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
  rcu_read_unlock();
+    if (!retry)
+    return -EBUSY;
+
  if (wait_event_interruptible(gt->reset.queue,
   !test_bit(I915_RESET_BACKOFF,
 >reset.flags)))


Would it be more obvious to rename the existing semantics to 
intel_gt_reset_interruptible(), while the flavour you add in this 
patch truly is trylock? I am not sure, since it's all a bit special, 
but trylock sure feels confusing if it can sleep forever...
To me, it would seem totally more obvious to have a function called 
'trylock' not wait forever until it can manage to acquire the lock. 
However, according to '2caffbf1176256 drm/i915: Revoke mmaps and prevent 
access to fence registers across reset', the current behaviour is 
exactly how the code was originally written and intended. It hasn't just 
mutated into some confused evolution a thousand patches later. So I 
figure there is some subtle but important reason why it was named how it 
is named and yet does what it does. Therefore it seemed safest to not 
change it unnecessarily.




Oh and might_sleep() shouldn't be there with the trylock version - I 
mean any flavour of the real trylock.
You mean if the code is split into two completely separate functions? Or 
do you just mean to wrap the might_sleep() call with 'if(!retry)'?


And just to be totally clear, the unconditional call to rcu_read_lock() 
is not something that can sleep? One doesn't need a might_sleep() before 
doing that lock?


John.




Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Add CDCLK Support for MTL

[Taylor, Clinton A]

See below

-Original Message-
From: Srivatsa, Anusha  
Sent: Friday, October 28, 2022 2:32 PM
To: intel-gfx@lists.freedesktop.org
Cc: Srivatsa, Anusha ; Taylor, Clinton A 

Subject: [PATCH 2/2] drm/i915/display: Add CDCLK Support for MTL

As per bSpec MTL has 38.4 MHz Reference clock.
Addin gthe cdclk tables and cdclk_funcs that MTL will use.

Spelling issue here. With this fixed
Reviewed-by: Clint Taylor 

-Clint


v2: Revert to using bxt_get_cdclk()

BSpec: 65243

Cc: Clint Taylor 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d79cf282faa8..54ac7f9a1253 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1345,6 +1345,16 @@ static const struct intel_cdclk_vals dg2_cdclk_table[] = 
{
{}
 };
 
+static const struct intel_cdclk_vals mtl_cdclk_table[] = {
+   { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 16, 
.waveform = 0xad5a },
+   { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 16, 
.waveform = 0xb6b6 },
+   { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34, 
.waveform = 0x },
+   {}
+};
+
 static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk)  {
const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table; 
@@ -3159,6 +3169,13 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
 }
 
+static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
+   .get_cdclk = bxt_get_cdclk,
+   .set_cdclk = bxt_set_cdclk,
+   .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+   .calc_voltage_level = tgl_calc_voltage_level, };
+
 static const struct intel_cdclk_funcs tgl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
@@ -3294,7 +3311,10 @@ static const struct intel_cdclk_funcs i830_cdclk_funcs = 
{
  */
 void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)  {
-   if (IS_DG2(dev_priv)) {
+   if (IS_METEORLAKE(dev_priv)) {
+   dev_priv->display.funcs.cdclk = _cdclk_funcs;
+   dev_priv->display.cdclk.table = mtl_cdclk_table;
+   } else if (IS_DG2(dev_priv)) {
dev_priv->display.funcs.cdclk = _cdclk_funcs;
dev_priv->display.cdclk.table = dg2_cdclk_table;
} else if (IS_ALDERLAKE_P(dev_priv)) {
--
2.25.1

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

[Matt Roper]

On Mon, Oct 31, 2022 at 06:01:11PM +0530, Aravind Iddamsetty wrote:
> On XE_LPM+ platforms the media engines are carved out into a separate
> GT but have a common GGTMMADR address range which essentially makes
> the GGTT address space to be shared between media and render GT.

While this is all true, I feel like this description is lacking a bit of
explanation for why/how that translates into the code changes below.
For example you should elaborate on the areas this impacts, such as the
need to invalidate both GTs' TLBs, retire requests for both GTs, etc.

Also, the movement of the PAT setup should be noted and explained as
well since it differs from how you approached the other changes here.

> 
> BSPEC: 63834
> 
> Cc: Matt Roper 
> Signed-off-by: Aravind Iddamsetty 
> ---
>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 49 +++---
>  drivers/gpu/drm/i915/gt/intel_gt.c| 15 +-
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  3 ++
>  drivers/gpu/drm/i915/i915_driver.c| 19 +--
>  drivers/gpu/drm/i915/i915_gem_evict.c | 63 +--
>  drivers/gpu/drm/i915/i915_vma.c   |  5 +-
>  drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
>  drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 +
>  9 files changed, 115 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 2518cebbf931..f5c2f3c58627 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -196,10 +196,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
>  
>  void i915_ggtt_suspend(struct i915_ggtt *ggtt)
>  {
> + struct intel_gt *gt;
> +
>   i915_ggtt_suspend_vm(>vm);
>   ggtt->invalidate(ggtt);
>  
> - intel_gt_check_and_clear_faults(ggtt->vm.gt);
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_gt_check_and_clear_faults(gt);
>  }
>  
>  void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> @@ -214,27 +217,36 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
>  
>  static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
>  {
> - struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> + struct intel_uncore *uncore;
> + struct intel_gt *gt;
>  
> - /*
> -  * Note that as an uncached mmio write, this will flush the
> -  * WCB of the writes into the GGTT before it triggers the invalidate.
> -  */
> - intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> + list_for_each_entry(gt, >gt_list, ggtt_link) {
> + uncore = gt->uncore;
> + /*
> +  * Note that as an uncached mmio write, this will flush the
> +  * WCB of the writes into the GGTT before it triggers the 
> invalidate.
> +  */
> + intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, 
> GFX_FLSH_CNTL_EN);

This isn't a GT register, so writing it for each GT doesn't do anything
different than just writing it once.  But actually it doesn't look like
this is even a register we should be writing to anymore since Xe_HP.
The GFX_FLSH_CNTL register no longer lives here.

> + }
>  }
>  
>  static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
>  {
> - struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>   struct drm_i915_private *i915 = ggtt->vm.i915;
>  
>   gen8_ggtt_invalidate(ggtt);
>  
> - if (GRAPHICS_VER(i915) >= 12)
> - intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
> -   GEN12_GUC_TLB_INV_CR_INVALIDATE);
> - else
> - intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + if (GRAPHICS_VER(i915) >= 12) {
> + struct intel_gt *gt;
> +
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_uncore_write_fw(gt->uncore,
> +   GEN12_GUC_TLB_INV_CR,
> +   GEN12_GUC_TLB_INV_CR_INVALIDATE);
> + } else {
> + intel_uncore_write_fw(ggtt->vm.gt->uncore,
> +   GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + }
>  }
>  
>  u64 gen8_ggtt_pte_encode(dma_addr_t addr,
> @@ -986,8 +998,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>  
>   ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>  
> - setup_private_pat(ggtt->vm.gt);
> -
>   return ggtt_probe_common(ggtt, size);
>  }
>  
> @@ -1186,7 +1196,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct 
> intel_gt *gt)
>   (u64)ggtt->mappable_end >> 20);
>   drm_dbg(>drm, "DSM size = %lluM\n",
>   (u64)resource_size(_graphics_stolen_res) >> 20);
> -
> + INIT_LIST_HEAD(>gt_list);
>   return 0;
>  }
>  
> @@ -1296,9 +1306,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
>  
>  void i915_ggtt_resume(struct i915_ggtt *ggtt)
>  {
> + struct 

Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler

[Dixit, Ashutosh]

On Sun, 30 Oct 2022 23:37:59 -0700, Gwan-gyeong Mun wrote:
>

Hi GG,

> On 10/31/22 7:19 AM, Dixit, Ashutosh wrote:
> > On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> >> b/drivers/gpu/drm/i915/i915_hwmon.c
> >> index 9e9781493025..c588a17f97e9 100644
> >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> >> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
> >> i915_reg_t rgadr,
> >>
> >>   static void
> >>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> >> -u32 field_msk, int nshift,
> >> -unsigned int scale_factor, long lval)
> >> +int nshift, unsigned int scale_factor, long lval)
> >>   {
> >>u32 nval;
> >> -  u32 bits_to_clear;
> >> -  u32 bits_to_set;
> >>
> >>/* Computation in 64-bits to avoid overflow. Round to nearest. */
> >>nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> >>
> >> -  bits_to_clear = field_msk;
> >> -  bits_to_set = FIELD_PREP(field_msk, nval);
> >> -
> >>hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> >> -  bits_to_clear, bits_to_set);
> >> +  PKG_PWR_LIM_1,
> >> +  REG_FIELD_PREP(PKG_PWR_LIM_1, 
> >> nval));
> >
> > I registered my objection to this patch already here:
> >
> > https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.di...@intel.com/
> >
> > the crux of which is "hwm_field_scale_and_write() pairs with
> > hwm_field_read_and_scale() (they are basically a set/get pair) so it is
> > desirable they have identical arguments. This patch breaks that symmetry".
> >
> > We can merge this patch now but the moment a second caller of
> > hwm_field_scale_and_write arrives this patch will need to be reverted.
> >
> > I have also posted my preferred way (as I previously indiecated) of fixing
> > this issue here (if this needs to be fixed in i915):
> >
> > https://patchwork.freedesktop.org/series/110301/
> >
> The given link (https://patchwork.freedesktop.org/series/110301/) is an
> inline function that reduces the checks of REG_FIELD_PREP() and pursues the
> same functionality.
> It's not a good idea to add and use duplicate new inline functions with
> reduced functionality under different names.

See if you like v2 better :-)

> +/* FIELD_PREP and REG_FIELD_PREP require a compile time constant mask */
> +static u32 hwm_field_prep(u32 mask, u32 val)
> +{
> + return (val << __bf_shf(mask)) & mask;
> +}
> +
>  static void
>  hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
>   i915_reg_t reg, u32 clear, u32 set)
> @@ -112,7 +118,7 @@  hwm_field_scale_and_write(struct hwm_drvdata *ddat,
> i915_reg_t rgadr,
>   nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
>   bits_to_clear = field_msk;
> - bits_to_set = FIELD_PREP(field_msk, nval);
> + bits_to_set = hwm_field_prep(field_msk, nval);
>
>   hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>   bits_to_clear, bits_to_set);
>
>
> The patch
> (https://patchwork.freedesktop.org/patch/509248/?series=110094=5) that
> fixed the build error in a simplified form was added as there is only one
> place that calls the hwm_field_scale_and_write() function at this time.
>
> If more places that use the hwm_field_scale_and_write() function are added
> in the future, how about changing the interface that calls this function as
> Jani previously suggested?

Sorry, which interface change which Jani suggested are you referring to? I
don't recall seeing anything but maybe I am mistaken.

Thanks.
--
Ashutosh

> > IMO it would be a mistake to use REG_FIELD_PREP or FIELD_PREP here since
> > here the mask comes in as a function argument whereas REG_FIELD_PREP and
> > FIELD_PREP require that mask to be a compile time constant.

[Intel-gfx] [PATCH] drm/i915/hwmon: Don't use FIELD_PREP

[Ashutosh Dixit]

FIELD_PREP and REG_FIELD_PREP have checks requiring a compile time constant
mask. When the mask comes in as the argument of a function these checks can
can fail depending on the compiler (gcc vs clang), optimization level,
etc. Use a simpler version of FIELD_PREP which skips these checks. The
checks are not needed because the mask is formed using REG_GENMASK (so is
actually a compile time constant).

v2: Split REG_FIELD_PREP into a macro with checks and one without and use
the one without checks in i915_hwmon.c (Gwan-gyeong Mun)

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7354
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_hwmon.c|  2 +-
 drivers/gpu/drm/i915/i915_reg_defs.h | 17 +++--
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9e97814930254..ae435b035229a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -112,7 +112,7 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
 
bits_to_clear = field_msk;
-   bits_to_set = FIELD_PREP(field_msk, nval);
+   bits_to_set = __REG_FIELD_PREP(field_msk, nval);
 
hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
bits_to_clear, bits_to_set);
diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h 
b/drivers/gpu/drm/i915/i915_reg_defs.h
index f1859046a9c48..dddacc8d48928 100644
--- a/drivers/gpu/drm/i915/i915_reg_defs.h
+++ b/drivers/gpu/drm/i915/i915_reg_defs.h
@@ -67,12 +67,17 @@
  *
  * @return: @__val masked and shifted into the field defined by @__mask.
  */
-#define REG_FIELD_PREP(__mask, __val)  
\
-   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
\
-  BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
-  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
\
-  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
-  BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0
+#define __REG_FIELD_PREP_CHK(__mask, __val) \
+   (BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
+BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + \
+BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0)))
+
+#define __REG_FIELD_PREP(__mask, __val) \
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask
+
+#define REG_FIELD_PREP(__mask, __val) \
+   (__REG_FIELD_PREP(__mask, __val) + __REG_FIELD_PREP_CHK(__mask, __val))
 
 /**
  * REG_FIELD_GET() - Extract a u32 bitfield value
-- 
2.38.0

Re: [Intel-gfx] [PATCH 1/5] drm/i915/mtl: add initial definitions for GSC CS

[Ceraolo Spurio, Daniele]

On 10/31/2022 9:26 AM, Matt Roper wrote:

On Thu, Oct 27, 2022 at 03:15:50PM -0700, Daniele Ceraolo Spurio wrote:

Starting on MTL, the GSC is no longer managed with direct MMIO access,
but we instead have a dedicated command streamer for it. As a first step
for adding support for this CS, add the required definitions.
Note that, although it is now a CS, the GSC retains its old
class:instance value (OTHER_CLASS instance 6)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 

Now that we have an OTHER_CLASS engine, I think we also need to deal
with the class -> reg mapping table in mmio_invalidate_full().  I think
the register we want is 0xCF04?


I missed that. Looks like the the situation is a bit more complex than 
just adding the new register, because on pre-MTL platforms CF04 is the 
compute class invalidation register. On MTL as you said CF04 is marked 
as the GSC CS invalidation register, but I can't find the compute one. 
Do you know if it re-uses the render one or something like that?
Given that there seem to be non-GSC related changes as well, IMO this 
should probably be a separate patch to specifically handle the TLB inval 
changes on MTL.


Daniele



Matt


---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 
  drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
  drivers/gpu/drm/i915/gt/intel_engine_user.c  | 1 +
  drivers/gpu/drm/i915/i915_reg.h  | 1 +
  4 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3b7d750ad054..e0fbfac03979 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -244,6 +244,13 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 12, .base = GEN12_COMPUTE3_RING_BASE }
}
},
+   [GSC0] = {
+   .class = OTHER_CLASS,
+   .instance = OTHER_GSC_INSTANCE,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = MTL_GSC_RING_BASE }
+   }
+   },
  };
  
  /**

@@ -324,6 +331,7 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 class)
case VIDEO_DECODE_CLASS:
case VIDEO_ENHANCEMENT_CLASS:
case COPY_ENGINE_CLASS:
+   case OTHER_CLASS:
if (GRAPHICS_VER(gt->i915) < 8)
return 0;
return GEN8_LR_CONTEXT_OTHER_SIZE;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 6b5d4ea22b67..4fd54fb8810f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -136,6 +136,7 @@ enum intel_engine_id {
CCS2,
CCS3,
  #define _CCS(n) (CCS0 + (n))
+   GSC0,
I915_NUM_ENGINES
  #define INVALID_ENGINE ((enum intel_engine_id)-1)
  };
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 46a174f8aa00..79312b734690 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -140,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
[COPY_ENGINE_CLASS] = "bcs",
[VIDEO_DECODE_CLASS] = "vcs",
[VIDEO_ENHANCEMENT_CLASS] = "vecs",
+   [OTHER_CLASS] = "other",
[COMPUTE_CLASS] = "ccs",
};
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index 1c0da50c0dc7..d056c3117ef2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -970,6 +970,7 @@
  #define GEN11_VEBOX2_RING_BASE0x1d8000
  #define XEHP_VEBOX3_RING_BASE 0x1e8000
  #define XEHP_VEBOX4_RING_BASE 0x1f8000
+#define MTL_GSC_RING_BASE  0x11a000
  #define GEN12_COMPUTE0_RING_BASE  0x1a000
  #define GEN12_COMPUTE1_RING_BASE  0x1c000
  #define GEN12_COMPUTE2_RING_BASE  0x1e000
--
2.37.3

Re: [Intel-gfx] [PATCH 1/5] drm/i915/mtl: add initial definitions for GSC CS

[Matt Roper]

On Thu, Oct 27, 2022 at 03:15:50PM -0700, Daniele Ceraolo Spurio wrote:
> Starting on MTL, the GSC is no longer managed with direct MMIO access,
> but we instead have a dedicated command streamer for it. As a first step
> for adding support for this CS, add the required definitions.
> Note that, although it is now a CS, the GSC retains its old
> class:instance value (OTHER_CLASS instance 6)
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Matt Roper 

Now that we have an OTHER_CLASS engine, I think we also need to deal
with the class -> reg mapping table in mmio_invalidate_full().  I think
the register we want is 0xCF04?

Matt

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 
>  drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
>  drivers/gpu/drm/i915/gt/intel_engine_user.c  | 1 +
>  drivers/gpu/drm/i915/i915_reg.h  | 1 +
>  4 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 3b7d750ad054..e0fbfac03979 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -244,6 +244,13 @@ static const struct engine_info intel_engines[] = {
>   { .graphics_ver = 12, .base = GEN12_COMPUTE3_RING_BASE }
>   }
>   },
> + [GSC0] = {
> + .class = OTHER_CLASS,
> + .instance = OTHER_GSC_INSTANCE,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = MTL_GSC_RING_BASE }
> + }
> + },
>  };
>  
>  /**
> @@ -324,6 +331,7 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 
> class)
>   case VIDEO_DECODE_CLASS:
>   case VIDEO_ENHANCEMENT_CLASS:
>   case COPY_ENGINE_CLASS:
> + case OTHER_CLASS:
>   if (GRAPHICS_VER(gt->i915) < 8)
>   return 0;
>   return GEN8_LR_CONTEXT_OTHER_SIZE;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 6b5d4ea22b67..4fd54fb8810f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -136,6 +136,7 @@ enum intel_engine_id {
>   CCS2,
>   CCS3,
>  #define _CCS(n) (CCS0 + (n))
> + GSC0,
>   I915_NUM_ENGINES
>  #define INVALID_ENGINE ((enum intel_engine_id)-1)
>  };
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 46a174f8aa00..79312b734690 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -140,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
>   [COPY_ENGINE_CLASS] = "bcs",
>   [VIDEO_DECODE_CLASS] = "vcs",
>   [VIDEO_ENHANCEMENT_CLASS] = "vecs",
> + [OTHER_CLASS] = "other",
>   [COMPUTE_CLASS] = "ccs",
>   };
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1c0da50c0dc7..d056c3117ef2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -970,6 +970,7 @@
>  #define GEN11_VEBOX2_RING_BASE   0x1d8000
>  #define XEHP_VEBOX3_RING_BASE0x1e8000
>  #define XEHP_VEBOX4_RING_BASE0x1f8000
> +#define MTL_GSC_RING_BASE0x11a000
>  #define GEN12_COMPUTE0_RING_BASE 0x1a000
>  #define GEN12_COMPUTE1_RING_BASE 0x1c000
>  #define GEN12_COMPUTE2_RING_BASE 0x1e000
> -- 
> 2.37.3
> 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uapi: expose GTT alignment

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: expose GTT alignment
URL   : https://patchwork.freedesktop.org/series/110313/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12323_full -> Patchwork_110313v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-dg1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@dmabuf@all@dma_fence_chain:
- shard-skl:  NOTRUN -> [INCOMPLETE][1] ([i915#6949])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-skl10/igt@dmabuf@all@dma_fence_chain.html

  * igt@gem_exec_fair@basic-deadline:
- shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2846])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-tglb2/igt@gem_exec_f...@basic-deadline.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-tglb6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-apl7/igt@gem_workarou...@suspend-resume.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-apl6/igt@gem_workarou...@suspend-resume.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#5566] / 
[i915#716]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-glk8/igt@gen9_exec_pa...@allowed-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-glk8/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#3989] / [i915#454])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-iclb8/igt@i915_pm...@dc6-psr.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-iclb7/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271]) +89 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-skl1/igt@i915_pm_...@modeset-non-lpsp-stress-no-wait.html

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

  * igt@kms_chamelium@dp-hpd-for-each-pipe:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +4 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-skl1/igt@kms_chamel...@dp-hpd-for-each-pipe.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-apl:  [PASS][16] -> [FAIL][17] ([i915#2346])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-apl1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-apl6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2346]) +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-glk5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-glk9/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([i915#2411])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/shard-tglb6/igt@kms_fbcon_...@fbc-suspend.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/shard-tglb5/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@plain-flip-fb-recreate@a-edp1:
- shard-skl:  [PASS][22] -> [FAIL][23] ([i915#2122])
   [22]: 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/mtl: add GSC CS interrupt support

[Ceraolo Spurio, Daniele]

On 10/31/2022 5:55 AM, Tvrtko Ursulin wrote:


On 28/10/2022 18:00, Ceraolo Spurio, Daniele wrote:

On 10/28/2022 1:38 AM, Tvrtko Ursulin wrote:


On 27/10/2022 23:15, Daniele Ceraolo Spurio wrote:

The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out of OTHER_CLASS, so we need to handle that appropriately.

Signed-off-by: Daniele Ceraolo Spurio 


Cc: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_gt_irq.c | 78 
++

  1 file changed, 43 insertions(+), 35 deletions(-)

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

index f26882fdc24c..34ff1ee7e931 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -81,35 +81,27 @@ gen11_other_irq_handler(struct intel_gt *gt, 
const u8 instance,

    instance, iir);
  }
  -static void
-gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
- const u8 instance, const u16 iir)
+static struct intel_gt *pick_gt(struct intel_gt *gt, u8 class, u8 
instance)

  {
-    struct intel_engine_cs *engine;
-
-    /*
- * Platforms with standalone media have their media engines in 
another

- * GT.
- */
-    if (MEDIA_VER(gt->i915) >= 13 &&
-    (class == VIDEO_DECODE_CLASS || class == 
VIDEO_ENHANCEMENT_CLASS)) {

-    if (!gt->i915->media_gt)
-    goto err;
+    struct intel_gt *media_gt = gt->i915->media_gt;
  -    gt = gt->i915->media_gt;
+    /* we expect the non-media gt to be passed in */
+    GEM_BUG_ON(gt == media_gt);
+
+    if (!media_gt)
+    return gt;
+
+    switch (class) {
+    case VIDEO_DECODE_CLASS:
+    case VIDEO_ENHANCEMENT_CLASS:
+    return media_gt;
+    case OTHER_CLASS:
+    if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))

+    return media_gt;
+    fallthrough;
+    default:
+    return gt;
  }
-
-    if (instance <= MAX_ENGINE_INSTANCE)
-    engine = gt->engine_class[class][instance];
-    else
-    engine = NULL;
-
-    if (likely(engine))
-    return intel_engine_cs_irq(engine, iir);
-
-err:
-    WARN_ONCE(1, "unhandled engine interrupt class=0x%x, 
instance=0x%x\n",

-  class, instance);
  }
    static void
@@ -118,12 +110,24 @@ gen11_gt_identity_handler(struct intel_gt 
*gt, const u32 identity)

  const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
  const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
  const u16 intr = GEN11_INTR_ENGINE_INTR(identity);
+    struct intel_engine_cs *engine;
    if (unlikely(!intr))
  return;
  -    if (class <= COPY_ENGINE_CLASS || class == COMPUTE_CLASS)
-    return gen11_engine_irq_handler(gt, class, instance, intr);
+    /*
+ * Platforms with standalone media have the media and GSC 
engines in

+ * another GT.
+ */
+    gt = pick_gt(gt, class, instance);
+
+    if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE)
+    engine = gt->engine_class[class][instance];
+    else
+    engine = NULL;
+
+    if (engine)
+    return intel_engine_cs_irq(engine, intr);


Drive by observation - you could fold the above two ifs into one 
since engine appears unused afterwards.


engine can be NULL in both branches of the if statement, so to get a 
unified if we'd have to do something like:


if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE) {
     struct intel_engine_cs *engine = 
gt->engine_class[class][instance];

     if (engine)
             return intel_engine_cs_irq(engine, intr);
}

Is this what you are suggesting?


Right, two ifs are needed after all. Well at least it would avoid the 
pointless engine = NULL assignment. Up to you.


Absence of any out-of-range class/instance logging is intentional?


There is already a log further down in this function.

Daniele



Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 0/6] drm/i915: Fix up and test RING_TIMESTAMP on gen4-6

[Lionel Landwerlin]

On 31/10/2022 15:56, Ville Syrjala wrote:

From: Ville Syrjälä 

Correct the ring timestamp frequency for gen4/5, and run the
relevant selftests for gen4-6.

I've posted at least most of this before, but stuff changed
in the meantinme so it needed a rebase.

Ville Syrjälä (6):
   drm/i915: Fix cs timestamp frequency for ctg/elk/ilk
   drm/i915: Stop claiming cs timestamp frquency on gen2/3
   drm/i915: Fix cs timestamp frequency for cl/bw
   drm/i915/selftests: Run MI_BB perf selftests on SNB
   drm/i915/selftests: Test RING_TIMESTAMP on gen4/5
   drm/i915/selftests: Run the perf MI_BB tests on gen4/5

  .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 38 ---
  drivers/gpu/drm/i915/gt/selftest_engine_cs.c  | 22 +--
  drivers/gpu/drm/i915/gt/selftest_gt_pm.c  | 36 --
  3 files changed, 67 insertions(+), 29 deletions(-)


Reviewed-by: Lionel Landwerlin 

[Intel-gfx] [PATCH 5/6] drm/i915/selftests: Test RING_TIMESTAMP on gen4/5

[Ville Syrjala]

From: Ville Syrjälä 

Now that we actually know the cs timestamp frequency on gen4/5
let's run the corresponding test.

On g4x/ilk we must read the udw of the 64bit timestamp
register. Details in {g4x,gen5)_read_clock_frequency().

The one extra caveat is that on i965 (or at least CL, don't
recall if I ever tested on BW) we must read the register
twice to get an up to date value. For some unknown reason
the first read tends to return a stale value.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 36 ++--
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index be94f863bdef..b46425aeb2f0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -36,6 +36,19 @@ static int cmp_u32(const void *A, const void *B)
return 0;
 }
 
+static u32 read_timestamp(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *i915 = engine->i915;
+
+   /* On i965 the first read tends to give a stale value */
+   ENGINE_READ_FW(engine, RING_TIMESTAMP);
+
+   if (GRAPHICS_VER(i915) == 5 || IS_G4X(i915))
+   return ENGINE_READ_FW(engine, RING_TIMESTAMP_UDW);
+   else
+   return ENGINE_READ_FW(engine, RING_TIMESTAMP);
+}
+
 static void measure_clocks(struct intel_engine_cs *engine,
   u32 *out_cycles, ktime_t *out_dt)
 {
@@ -45,13 +58,13 @@ static void measure_clocks(struct intel_engine_cs *engine,
 
for (i = 0; i < 5; i++) {
local_irq_disable();
-   cycles[i] = -ENGINE_READ_FW(engine, RING_TIMESTAMP);
+   cycles[i] = -read_timestamp(engine);
dt[i] = ktime_get();
 
udelay(1000);
 
dt[i] = ktime_sub(ktime_get(), dt[i]);
-   cycles[i] += ENGINE_READ_FW(engine, RING_TIMESTAMP);
+   cycles[i] += read_timestamp(engine);
local_irq_enable();
}
 
@@ -78,25 +91,6 @@ static int live_gt_clocks(void *arg)
if (GRAPHICS_VER(gt->i915) < 4) /* Any CS_TIMESTAMP? */
return 0;
 
-   if (GRAPHICS_VER(gt->i915) == 5)
-   /*
-* XXX CS_TIMESTAMP low dword is dysfunctional?
-*
-* Ville's experiments indicate the high dword still works,
-* but at a correspondingly reduced frequency.
-*/
-   return 0;
-
-   if (GRAPHICS_VER(gt->i915) == 4)
-   /*
-* XXX CS_TIMESTAMP appears gibberish
-*
-* Ville's experiments indicate that it mostly appears 'stuck'
-* in that we see the register report the same cycle count
-* for a couple of reads.
-*/
-   return 0;
-
intel_gt_pm_get(gt);
intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_ALL);
 
-- 
2.37.4

[Intel-gfx] [PATCH 4/6] drm/i915/selftests: Run MI_BB perf selftests on SNB

[Ville Syrjala]

From: Ville Syrjälä 

SNB does have the RING_TIMESTAMP register on the RCS engine.
Run the MI_BB perf tests on it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
index 1b75f478d1b8..b11152f87627 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
@@ -125,7 +125,7 @@ static int perf_mi_bb_start(void *arg)
enum intel_engine_id id;
int err = 0;
 
-   if (GRAPHICS_VER(gt->i915) < 7) /* for per-engine CS_TIMESTAMP */
+   if (GRAPHICS_VER(gt->i915) < 6) /* for per-engine CS_TIMESTAMP */
return 0;
 
perf_begin(gt);
@@ -135,6 +135,9 @@ static int perf_mi_bb_start(void *arg)
u32 cycles[COUNT];
int i;
 
+   if (GRAPHICS_VER(engine->i915) < 7 && engine->id != RCS0)
+   continue;
+
intel_engine_pm_get(engine);
 
batch = create_empty_batch(ce);
@@ -249,7 +252,7 @@ static int perf_mi_noop(void *arg)
enum intel_engine_id id;
int err = 0;
 
-   if (GRAPHICS_VER(gt->i915) < 7) /* for per-engine CS_TIMESTAMP */
+   if (GRAPHICS_VER(gt->i915) < 6) /* for per-engine CS_TIMESTAMP */
return 0;
 
perf_begin(gt);
@@ -259,6 +262,9 @@ static int perf_mi_noop(void *arg)
u32 cycles[COUNT];
int i;
 
+   if (GRAPHICS_VER(engine->i915) < 7 && engine->id != RCS0)
+   continue;
+
intel_engine_pm_get(engine);
 
base = create_empty_batch(ce);
-- 
2.37.4

[Intel-gfx] [PATCH 2/6] drm/i915: Stop claiming cs timestamp frquency on gen2/3

[Ville Syrjala]

From: Ville Syrjälä 

Gen2/3 have no TIMESTAMP registers to sample so no point in thinking
we have any frequency for it either.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c 
b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
index ebb7a5b3e87c..23a27e49b898 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
@@ -139,7 +139,7 @@ static u32 g4x_read_clock_frequency(struct intel_uncore 
*uncore)
return 10 / 1024;
 }
 
-static u32 gen2_read_clock_frequency(struct intel_uncore *uncore)
+static u32 gen4_read_clock_frequency(struct intel_uncore *uncore)
 {
/*
 * PRMs say:
@@ -163,8 +163,10 @@ static u32 read_clock_frequency(struct intel_uncore 
*uncore)
return gen5_read_clock_frequency(uncore);
else if (IS_G4X(uncore->i915))
return g4x_read_clock_frequency(uncore);
+   else if (GRAPHICS_VER(uncore->i915) == 4)
+   return gen4_read_clock_frequency(uncore);
else
-   return gen2_read_clock_frequency(uncore);
+   return 0;
 }
 
 void intel_gt_init_clock_frequency(struct intel_gt *gt)
-- 
2.37.4

[Intel-gfx] [PATCH 3/6] drm/i915: Fix cs timestamp frequency for cl/bw

[Ville Syrjala]

From: Ville Syrjälä 

Despite what the spec says the TIMESTAMP register seems to
tick once every hrawclk (confirmed on i965gm and g35).

v2: Rebase

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

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c 
b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
index 23a27e49b898..2a6a4ca7fdad 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
@@ -147,8 +147,10 @@ static u32 gen4_read_clock_frequency(struct intel_uncore 
*uncore)
 * "The value in this register increments once every 16
 *  hclks." (through the “Clocking Configuration”
 *  (“CLKCFG”) MCHBAR register)
+*
+* Testing on actual hardware has shown there is no /16.
 */
-   return RUNTIME_INFO(uncore->i915)->rawclk_freq * 1000 / 16;
+   return RUNTIME_INFO(uncore->i915)->rawclk_freq * 1000;
 }
 
 static u32 read_clock_frequency(struct intel_uncore *uncore)
-- 
2.37.4

[Intel-gfx] [PATCH 6/6] drm/i915/selftests: Run the perf MI_BB tests on gen4/5

[Ville Syrjala]

From: Ville Syrjälä 

Now that we know the ring timestamp frequency on gen4/5 we
can run the perf tests that depend on sampling the timestamp.

On g4x/ilk we must read the udw of the 64bit timestamp
register. Details in {g4x,gen5)_read_clock_frequency().

When executing the read via the CS i965 doesn't seem to need
the double read trick that CPU mmio reads need.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
index b11152f87627..881b64f3e7b9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
@@ -39,6 +39,16 @@ static int perf_end(struct intel_gt *gt)
return igt_flush_test(gt->i915);
 }
 
+static i915_reg_t timestamp_reg(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *i915 = engine->i915;
+
+   if (GRAPHICS_VER(i915) == 5 || IS_G4X(i915))
+   return RING_TIMESTAMP_UDW(engine->mmio_base);
+   else
+   return RING_TIMESTAMP(engine->mmio_base);
+}
+
 static int write_timestamp(struct i915_request *rq, int slot)
 {
struct intel_timeline *tl =
@@ -55,7 +65,7 @@ static int write_timestamp(struct i915_request *rq, int slot)
if (GRAPHICS_VER(rq->engine->i915) >= 8)
cmd++;
*cs++ = cmd;
-   *cs++ = i915_mmio_reg_offset(RING_TIMESTAMP(rq->engine->mmio_base));
+   *cs++ = i915_mmio_reg_offset(timestamp_reg(rq->engine));
*cs++ = tl->hwsp_offset + slot * sizeof(u32);
*cs++ = 0;
 
@@ -125,7 +135,7 @@ static int perf_mi_bb_start(void *arg)
enum intel_engine_id id;
int err = 0;
 
-   if (GRAPHICS_VER(gt->i915) < 6) /* for per-engine CS_TIMESTAMP */
+   if (GRAPHICS_VER(gt->i915) < 4) /* Any CS_TIMESTAMP? */
return 0;
 
perf_begin(gt);
@@ -252,7 +262,7 @@ static int perf_mi_noop(void *arg)
enum intel_engine_id id;
int err = 0;
 
-   if (GRAPHICS_VER(gt->i915) < 6) /* for per-engine CS_TIMESTAMP */
+   if (GRAPHICS_VER(gt->i915) < 4) /* Any CS_TIMESTAMP? */
return 0;
 
perf_begin(gt);
-- 
2.37.4

[Intel-gfx] [PATCH 1/6] drm/i915: Fix cs timestamp frequency for ctg/elk/ilk

[Ville Syrjala]

From: Ville Syrjälä 

On ilk the UDW of TIMESTAMP increments every 1000 ns,
LDW is mbz. In order to represent that we'd need 52 bits,
but we only have 32 bits. Even worse most things want to
only deal with 32 bits of timestamp. So let's just set
up the timestamp frequency as if we only had the UDW.

On ctg/elk 63:20 of TIMESTAMP increments every 1/4 ns, 19:0
are mbz. To make life simpler let's ignore the LDW and set up
timestamp frequency based on the UDW only (increments every
1024 ns).

v2: Rebase

Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 28 +--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c 
b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
index 3f656d3dba9a..ebb7a5b3e87c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c
@@ -107,7 +107,7 @@ static u32 gen9_read_clock_frequency(struct intel_uncore 
*uncore)
return freq;
 }
 
-static u32 gen5_read_clock_frequency(struct intel_uncore *uncore)
+static u32 gen6_read_clock_frequency(struct intel_uncore *uncore)
 {
/*
 * PRMs say:
@@ -119,6 +119,26 @@ static u32 gen5_read_clock_frequency(struct intel_uncore 
*uncore)
return 1250;
 }
 
+static u32 gen5_read_clock_frequency(struct intel_uncore *uncore)
+{
+   /*
+* 63:32 increments every 1000 ns
+* 31:0 mbz
+*/
+   return 10 / 1000;
+}
+
+static u32 g4x_read_clock_frequency(struct intel_uncore *uncore)
+{
+   /*
+* 63:20 increments every 1/4 ns
+* 19:0 mbz
+*
+* -> 63:32 increments every 1024 ns
+*/
+   return 10 / 1024;
+}
+
 static u32 gen2_read_clock_frequency(struct intel_uncore *uncore)
 {
/*
@@ -137,8 +157,12 @@ static u32 read_clock_frequency(struct intel_uncore 
*uncore)
return gen11_read_clock_frequency(uncore);
else if (GRAPHICS_VER(uncore->i915) >= 9)
return gen9_read_clock_frequency(uncore);
-   else if (GRAPHICS_VER(uncore->i915) >= 5)
+   else if (GRAPHICS_VER(uncore->i915) >= 6)
+   return gen6_read_clock_frequency(uncore);
+   else if (GRAPHICS_VER(uncore->i915) == 5)
return gen5_read_clock_frequency(uncore);
+   else if (IS_G4X(uncore->i915))
+   return g4x_read_clock_frequency(uncore);
else
return gen2_read_clock_frequency(uncore);
 }
-- 
2.37.4

[Intel-gfx] [PATCH 0/6] drm/i915: Fix up and test RING_TIMESTAMP on gen4-6

[Ville Syrjala]

From: Ville Syrjälä 

Correct the ring timestamp frequency for gen4/5, and run the
relevant selftests for gen4-6.

I've posted at least most of this before, but stuff changed
in the meantinme so it needed a rebase.

Ville Syrjälä (6):
  drm/i915: Fix cs timestamp frequency for ctg/elk/ilk
  drm/i915: Stop claiming cs timestamp frquency on gen2/3
  drm/i915: Fix cs timestamp frequency for cl/bw
  drm/i915/selftests: Run MI_BB perf selftests on SNB
  drm/i915/selftests: Test RING_TIMESTAMP on gen4/5
  drm/i915/selftests: Run the perf MI_BB tests on gen4/5

 .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 38 ---
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  | 22 +--
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c  | 36 --
 3 files changed, 67 insertions(+), 29 deletions(-)

-- 
2.37.4

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add MC6 Wa_14017210380 for SAMedia

[Nilawar, Badal]

Hi Rodrigo,

On 31-10-2022 15:19, Rodrigo Vivi wrote:

On Sat, Oct 29, 2022 at 12:59:35AM +0530, Badal Nilawar wrote:

This workaround is added for Media Tile of MTL A step. It is to help
pcode workaround which handles the hardware bug seen on CXL splitter
during package C2/C3 transitins due to MC6 entry/exit. As a part of
workaround pcode expect kmd to send mailbox message "media busy" when
components of Media tile is in use and "media not busy" when not in use.
As per workaround description gucrc need to be disabled so enabled
host based RC for Media tile.

HSD: 14017210380

Cc: Rodrigo Vivi 
Cc: Radhakrishna Sripada 
Cc: Vinay Belgaumkar 
Cc: Chris Wilson 
Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 33 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 -
  drivers/gpu/drm/i915/i915_drv.h   |  4 +++
  drivers/gpu/drm/i915/i915_reg.h   |  9 +++
  4 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index f553e2173bda..398dbeb298ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,10 +19,37 @@
  #include "intel_rc6.h"
  #include "intel_rps.h"
  #include "intel_wakeref.h"
+#include "intel_pcode.h"
  #include "pxp/intel_pxp_pm.h"
  
  #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
  
+/*

+ * Wa_14017210380: mtl
+ */
+
+static bool mtl_needs_media_mc6_wa(struct intel_gt *gt)


+Ashutosh since we recently discussed about the term "MC6".

in that discussion we have concluded to not introduce a new term
since it is not used in any kind of spec and might only bring
more doubts then answers, although "Render" in the media gt
makes no sense as well.

In the end, most of the code is common and is called as rc6.
so we should maybe s/mc6/media_rc6 here?

Sure I will make above change and resend the patch.


The rest of the patch looks good to me. But we need to check the IGT
failure on a pm related test that failed... just to be sure.

Failures reported in IGT so far are not related to this change.

Regards,
Badal



+{
+   return (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA);
+}
+
+static void mtl_mc6_wa_media_busy(struct intel_gt *gt)
+{
+   if (mtl_needs_media_mc6_wa(gt))
+   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
+ PCODE_MBOX_GT_STATE_MEDIA_BUSY,
+ PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+}
+
+static void mtl_mc6_wa_media_not_busy(struct intel_gt *gt)
+{
+   if (mtl_needs_media_mc6_wa(gt))
+   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
+ PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
+ PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+}
+
  static void user_forcewake(struct intel_gt *gt, bool suspend)
  {
int count = atomic_read(>user_wakeref);
@@ -70,6 +97,9 @@ static int __gt_unpark(struct intel_wakeref *wf)
  
  	GT_TRACE(gt, "\n");
  
+	/* Wa_14017210380: mtl */

+   mtl_mc6_wa_media_busy(gt);
+
/*
 * It seems that the DMC likes to transition between the DC states a lot
 * when there are no connected displays (no active power domains) during
@@ -119,6 +149,9 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_BUG_ON(!wakeref);
intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
  
+	/* Wa_14017210380: mtl */

+   mtl_mc6_wa_media_not_busy(gt);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c

index 8f8dd05835c5..cc6356ff84a5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -11,9 +11,20 @@
  
  static bool __guc_rc_supported(struct intel_guc *guc)

  {
+   struct intel_gt *gt = guc_to_gt(guc);
+
+   /*
+* Wa_14017210380: mtl
+* Do not enable gucrc to avoid additional interrupts which
+* may disrupt pcode wa.
+*/
+   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA)
+   return false;
+
/* GuC RC is unavailable for pre-Gen12 */
return guc->submission_supported &&
-   GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
+   GRAPHICS_VER(gt->i915) >= 12;
  }
  
  static bool __guc_rc_selected(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 05b3300cc4ed..659b92382ff2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -740,6 +740,10 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \
(IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
  
+#define IS_MTL_GRAPHICS_STEP(__i915, variant, 

Re: [Intel-gfx] [PATCH v2 14/21] drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use _info postfix

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info()
> as part of unifying the naming within fbdev helpers. Adapt drivers. No
> functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

[Intel-gfx] [PATCH] drm/i915/dg2: Introduce Wa_18017747507

[Wayne Boyer]

WA 18017747507 applies to all DG2 skus.

BSpec: 56035, 46121, 68173

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

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index f4624262dc81..27b2641e1a53 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -501,6 +501,9 @@
 #define VF_PREEMPTION  _MMIO(0x83a4)
 #define   PREEMPTION_VERTEX_COUNT  REG_GENMASK(15, 0)
 
+#define VFG_PREEMPTION_CHICKEN _MMIO(0x83b4)
+#define  POLYGON_TRIFAN_LINELOOP_DISABLE   REG_BIT(4)
+
 #define GEN8_RC6_CTX_INFO  _MMIO(0x8504)
 
 #define XEHP_SQCM  MCR_REG(0x8724)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 2a35e7e66625..3cdf5c24dbc5 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2975,6 +2975,9 @@ general_render_compute_wa_init(struct intel_engine_cs 
*engine, struct i915_wa_li
 * Wa_22015475538:dg2
 */
wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
+
+   /* Wa_18017747507:dg2 */
+   wa_masked_en(wal, VFG_PREEMPTION_CHICKEN, 
POLYGON_TRIFAN_LINELOOP_DISABLE);
}
 }
 
-- 
2.37.3

Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation

[Ville Syrjälä]

On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 2:10 PM Ville Syrjälä
>  wrote:
> >
> > On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> > >  wrote:
> > > >
> > > > On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > > > > On Thu, Oct 27, 2022 at 9:08 AM Jason Baron  wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 10/21/22 05:18, Jani Nikula wrote:
> > > > > > > On Thu, 20 Oct 2022, Ville Syrjälä 
> > > > > > >  wrote:
> > > > > > >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> > > > > > >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> > > > > >  hi Greg, Dan, Jason, DRM-folk,
> > > > > > 
> > > > > >  heres follow-up to V6:
> > > > > >    rebased on driver-core/driver-core-next for -v6 applied bits 
> > > > > >  (thanks)
> > > > > >    rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> > > > > > 
> > > > > >  It excludes:
> > > > > >    nouveau parts (immature)
> > > > > >    tracefs parts (I missed --to=Steve on v6)
> > > > > >    split _ddebug_site and de-duplicate experiment (way unready)
> > > > > > 
> > > > > >  IOW, its the remaining commits of V6 on which Dan gave his 
> > > > > >  Reviewed-by.
> > > > > > 
> > > > > >  If these are good to apply, I'll rebase and repost the rest 
> > > > > >  separately.
> > > > > > >>>
> > > > > > >>> All now queued up, thanks.
> > > > > > >>
> > > > > > >> This stuff broke i915 debugs. When I first load i915 no debug 
> > > > > > >> prints are
> > > > > > >> produced. If I then go fiddle around in 
> > > > > > >> /sys/module/drm/parameters/debug
> > > > > > >> the debug prints start to suddenly work.
> > > > > > >
> > > > > > > Wait what? I always assumed the default behaviour would stay the 
> > > > > > > same,
> > > > > > > which is usually how we roll. It's a regression in my books. 
> > > > > > > We've got a
> > > > > > > CI farm that's not very helpful in terms of dmesg logging right 
> > > > > > > now
> > > > > > > because of this.
> > > > > > >
> > > > > > > BR,
> > > > > > > Jani.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > That doesn't sound good - so you are saying that prior to this 
> > > > > > change some
> > > > > > of the drm debugs were default enabled. But now you have to 
> > > > > > manually enable
> > > > > > them?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > -Jason
> > > > >
> > > > >
> > > > > Im just seeing this now.
> > > > > Any new details ?
> > > >
> > > > No. We just disabled it as BROKEN for now. I was just today thinking
> > > > about sending that patch out if no solutin is forthcoming soon since
> > > > we need this working before 6.1 is released.
> > > >
> > > > Pretty sure you should see the problem immediately with any driver
> > > > (at least if it's built as a module, didn't try builtin). Or at least
> > > > can't think what would make i915 any more special.
> > > >
> > >
> > > So, I should note -
> > > 99% of my time & energy on this dyndbg + drm patchset
> > > has been done using virtme,
> > > so my world-view (and dev-hack-test env) has been smaller, simpler
> > > maybe its been fatally simplistic.
> > >
> > > ive just rebuilt v6.0  (before the trouble)
> > > and run it thru my virtual home box,
> > > I didnt see any unfamiliar drm-debug output
> > > that I might have inadvertently altered somehow
> > >
> > > I have some real HW I can put a reference kernel on,0
> > > to look for the missing output, but its all gonna take some time,
> > > esp to tighten up my dev-test-env
> > >
> > > in the meantime, there is:
> > >
> > > config DRM_USE_DYNAMIC_DEBUG
> > > bool "use dynamic debug to implement drm.debug"
> > > default y
> > > depends on DRM
> > > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> > > depends on JUMP_LABEL
> > > help
> > >   Use dynamic-debug to avoid drm_debug_enabled() runtime overheads.
> > >   Due to callsite counts in DRM drivers (~4k in amdgpu) and 56
> > >   bytes per callsite, the .data costs can be substantial, and
> > >   are therefore configurable.
> > >
> > > Does changing the default fix things for i915 dmesg ?
> >
> > I think we want to mark it BROKEN in addition to make sure no one
> 
> Ok, I get the distinction now.
> youre spelling that
>   depends on BROKEN
> 
> I have a notional explanation, and a conflating commit:
> 
> can you eliminate
> git log -p ccc2b496324c13e917ef05f563626f4e7826bef1
> 
> as the cause ?

Reverting that doesn't help.

> 
> 
> 
> commit ccc2b496324c13e917ef05f563626f4e7826bef1
> Author: Jim Cromie 
> Date:   Sun Sep 11 23:28:51 2022 -0600
> 
> drm_print: prefer bare printk KERN_DEBUG on generic fn
> 
> drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
> which is a generic/service fn.  The callsite is compile-time enabled
> by DEBUG in both DYNAMIC_DEBUG=y/n 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)

[Gupta, Anshuman]

Pushed to drm-intel-gt-next.
Thanks for review.
Br,
Anshuman Gupta.

> -Original Message-
> From: Gupta, Anshuman
> Sent: Monday, October 31, 2022 5:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/dgfx: Grab wakeref at
> i915_ttm_unmap_virtual (rev4)
> 
> 
> 
> On 10/31/2022 2:09 PM, Patchwork wrote:
> > *Patch Details*
> > *Series:*   drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
> (rev4)
> > *URL:*  https://patchwork.freedesktop.org/series/108972/
> > 
> > *State:*failure
> > *Details:*
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/index.html
> >  > l>
> >
> >
> >   CI Bug Log - changes from CI_DRM_12310_full ->
> > Patchwork_108972v4_full
> >
> >
> > Summary
> >
> > *FAILURE*
> >
> > Serious unknown changes coming with Patchwork_108972v4_full
> absolutely
> > need to be verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_108972v4_full, please notify your bug team to
> > allow them to document this new failure mode, which will reduce false
> > positives in CI.
> >
> >
> > Participating hosts (11 -> 10)
> >
> > Missing (1): pig-glk-j5005
> >
> >
> > Possible new issues
> >
> > Here are the unknown changes that may have been introduced in
> > Patchwork_108972v4_full:
> >
> >
> >   IGT changes
> >
> >
> > Possible regressions
> >
> >   *
> Below failures are unrelated to this series.
> Br,
> Anshuman Gupta.
> >
> > igt@i915_pipe_stress@stress-xrgb-untiled:
> >
> >   o shard-tglb: PASS
> >  tglb1/igt@i915_pipe_str...@stress-xrgb-untiled.html> -> DMESG-
> WARN  tglb8/igt@i915_pipe_str...@stress-xrgb-untiled.html>
> >   *
> >
> > igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
> >
> >   o shard-iclb: PASS
> >
> >  > @kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
> > > -> FAIL
> >  > b7/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-siz
> > e.html>
> >
> >
> > Warnings
> >
> >   * igt@runner@aborted:
> >   o shard-skl: (FAIL
> >
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>, FAIL
> >  > run...@aborted.html>) (i915#3002
> >  / i915#4312
> >  / i915#6949
> > ) -> (FAIL
> >  > 7/igt@run...@aborted.html>, FAIL
> >  > 1/igt@run...@aborted.html>, FAIL
> >  > 7/igt@run...@aborted.html>, FAIL
> >  > 9/igt@run...@aborted.html>, FAIL
> >  > 7/igt@run...@aborted.html>, FAIL
> >  > 9/igt@run...@aborted.html>, FAIL
> >  > 7/igt@run...@aborted.html>) (i915#3002
> >  / i915#4312
> > )
> >
> >
> > Known issues
> >
> > Here are the changes found in Patchwork_108972v4_full that come from
> > known issues:
> >
> >
> >   IGT changes
> >
> >
> > Issues hit
> >
> >   *
> >
> > igt@feature_discovery@psr2:
> >
> >   o shard-iclb: PASS
> >  iclb2/igt@feature_discov...@psr2.html> -> SKIP  ci.01.org/tree/drm-tip/Patchwork_108972v4/shard-

Re: [Intel-gfx] [PATCH 3/5] drm/i915/mtl: add GSC CS interrupt support

[Tvrtko Ursulin]

On 28/10/2022 18:00, Ceraolo Spurio, Daniele wrote:

On 10/28/2022 1:38 AM, Tvrtko Ursulin wrote:


On 27/10/2022 23:15, Daniele Ceraolo Spurio wrote:

The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out of OTHER_CLASS, so we need to handle that appropriately.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_gt_irq.c | 78 ++
  1 file changed, 43 insertions(+), 35 deletions(-)

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

index f26882fdc24c..34ff1ee7e931 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -81,35 +81,27 @@ gen11_other_irq_handler(struct intel_gt *gt, 
const u8 instance,

    instance, iir);
  }
  -static void
-gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
- const u8 instance, const u16 iir)
+static struct intel_gt *pick_gt(struct intel_gt *gt, u8 class, u8 
instance)

  {
-    struct intel_engine_cs *engine;
-
-    /*
- * Platforms with standalone media have their media engines in 
another

- * GT.
- */
-    if (MEDIA_VER(gt->i915) >= 13 &&
-    (class == VIDEO_DECODE_CLASS || class == 
VIDEO_ENHANCEMENT_CLASS)) {

-    if (!gt->i915->media_gt)
-    goto err;
+    struct intel_gt *media_gt = gt->i915->media_gt;
  -    gt = gt->i915->media_gt;
+    /* we expect the non-media gt to be passed in */
+    GEM_BUG_ON(gt == media_gt);
+
+    if (!media_gt)
+    return gt;
+
+    switch (class) {
+    case VIDEO_DECODE_CLASS:
+    case VIDEO_ENHANCEMENT_CLASS:
+    return media_gt;
+    case OTHER_CLASS:
+    if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))

+    return media_gt;
+    fallthrough;
+    default:
+    return gt;
  }
-
-    if (instance <= MAX_ENGINE_INSTANCE)
-    engine = gt->engine_class[class][instance];
-    else
-    engine = NULL;
-
-    if (likely(engine))
-    return intel_engine_cs_irq(engine, iir);
-
-err:
-    WARN_ONCE(1, "unhandled engine interrupt class=0x%x, 
instance=0x%x\n",

-  class, instance);
  }
    static void
@@ -118,12 +110,24 @@ gen11_gt_identity_handler(struct intel_gt *gt, 
const u32 identity)

  const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
  const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
  const u16 intr = GEN11_INTR_ENGINE_INTR(identity);
+    struct intel_engine_cs *engine;
    if (unlikely(!intr))
  return;
  -    if (class <= COPY_ENGINE_CLASS || class == COMPUTE_CLASS)
-    return gen11_engine_irq_handler(gt, class, instance, intr);
+    /*
+ * Platforms with standalone media have the media and GSC 
engines in

+ * another GT.
+ */
+    gt = pick_gt(gt, class, instance);
+
+    if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE)
+    engine = gt->engine_class[class][instance];
+    else
+    engine = NULL;
+
+    if (engine)
+    return intel_engine_cs_irq(engine, intr);


Drive by observation - you could fold the above two ifs into one since 
engine appears unused afterwards.


engine can be NULL in both branches of the if statement, so to get a 
unified if we'd have to do something like:


if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE) {
         struct intel_engine_cs *engine = 
gt->engine_class[class][instance];

         if (engine)
                 return intel_engine_cs_irq(engine, intr);
}

Is this what you are suggesting?


Right, two ifs are needed after all. Well at least it would avoid the 
pointless engine = NULL assignment. Up to you.


Absence of any out-of-range class/instance logging is intentional?

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[Tvrtko Ursulin]

On 31/10/2022 10:09, Tvrtko Ursulin wrote:


On 28/10/2022 20:46, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

Update the worker to abort if a reset is in progress rather than
waiting for it to complete. It will still acquire the reset lock in
the case where a reset was not already in progress. So the processing
is still safe from corruption, but the deadlock can no longer occur.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 15 ++-
  drivers/gpu/drm/i915/gt/intel_reset.h |  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 --
  3 files changed, 19 insertions(+), 3 deletions(-)

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

index 3159df6cdd492..2f48c6e4420ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,7 +1407,7 @@ void intel_gt_handle_error(struct intel_gt *gt,
  intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
-int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+static int _intel_gt_reset_trylock(struct intel_gt *gt, int *srcu, 
bool retry)

  {
  might_lock(>reset.backoff_srcu);
  might_sleep();
@@ -1416,6 +1416,9 @@ int intel_gt_reset_trylock(struct intel_gt *gt, 
int *srcu)

  while (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
  rcu_read_unlock();
+    if (!retry)
+    return -EBUSY;
+
  if (wait_event_interruptible(gt->reset.queue,
   !test_bit(I915_RESET_BACKOFF,
 >reset.flags)))


Would it be more obvious to rename the existing semantics to 
intel_gt_reset_interruptible(), while the flavour you add in this patch 
truly is trylock? I am not sure, since it's all a bit special, but 
trylock sure feels confusing if it can sleep forever...


Oh and might_sleep() shouldn't be there with the trylock version - I 
mean any flavour of the real trylock.


Regards,

Tvrtko

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uapi: expose GTT alignment

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: expose GTT alignment
URL   : https://patchwork.freedesktop.org/series/110313/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12323 -> Patchwork_110313v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 39)
--

  Missing(2): fi-bxt-dsi fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#4890])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +11 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/fi-apl-guc/igt@kms_psr@sprite_plane_onoff.html

  * igt@runner@aborted:
- fi-icl-u2:  NOTRUN -> [FAIL][8] ([i915#4312])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/fi-icl-u2/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [INCOMPLETE][9] ([i915#7056]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [WARN][11] ([i915#7346]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][13] ([i915#4785]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- {bat-dg2-9}:[INCOMPLETE][15] ([i915#7349]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-1}:   [INCOMPLETE][17] ([i915#6257]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/bat-rpls-1/igt@i915_selftest@l...@requests.html

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

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [DMESG-FAIL][21] ([i915#6997]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110313v1/bat-adln-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_selftest@live@workarounds:
- {bat-adlm-1}:   [INCOMPLETE][23] -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12323/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
   [24]: 

Re: [Intel-gfx] [PATCH i-g-t] tests/i915/query: use 48B_ADDRESS in upload

[Das, Nirmoy]

Reviewed-by: |Nirmoy Das |

On 10/31/2022 1:17 PM, Matthew Auld wrote:

Our working set could be larger than 4G here.

Closes:https://gitlab.freedesktop.org/drm/intel/-/issues/6671
Signed-off-by: Matthew Auld
Cc: Nirmoy Das
---
  tests/i915/i915_query.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index 4e43c7cd..e725e04e 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -625,10 +625,14 @@ static void upload(int fd, struct igt_list_head *handles, 
uint32_t num_handles)
  sizeof(struct drm_i915_gem_exec_object2));
  
  	i = 0;

-   igt_list_for_each_entry(iter, handles, link)
-   exec[i++].handle = iter->handle;
+   igt_list_for_each_entry(iter, handles, link) {
+   exec[i].handle = iter->handle;
+   exec[i].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   i++;
+   }
  
  	exec[i].handle = batch_create_size(fd, 4096);

+   exec[i].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
  
  	execbuf.buffers_ptr = to_user_pointer(exec);

execbuf.buffer_count = num_handles + 1;

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)

[Gupta, Anshuman]

On 10/27/2022 6:30 PM, Patchwork wrote:

== Series Details ==

Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)
URL   : https://patchwork.freedesktop.org/series/108972/
State : warning

== Summary ==

Error: dim checkpatch failed
d83d4490c920 drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm
-:69: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#69: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1105:
+   list_add(>userfault_link, 
_i915(obj->base.dev)->runtime_pm.lmem_userfault_list);

Code if block is more readable in single line.


total: 0 errors, 1 warnings, 0 checks, 147 lines checked
721d116886f7 drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
-:44: 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
#44: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:564:
+   GEM_BUG_ON(!obj->userfault_count);

-:155: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
Above is a false alarm, there is already an existing comment about the 
lock usages.

Br,
Anshuman Gupta.

#155: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:67:
+   spinlock_t lmem_userfault_lock;

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915/gvt: remove hardcoded value on crc32_start calculation

[Patchwork]

== Series Details ==

Series: i915/gvt: remove hardcoded value on crc32_start calculation
URL   : https://patchwork.freedesktop.org/series/110310/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12322_full -> Patchwork_110310v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_universal_plane@universal-plane-pipe-c-sanity:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/shard-tglb2/igt@kms_universal_pl...@universal-plane-pipe-c-sanity.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-tglb8/igt@kms_universal_pl...@universal-plane-pipe-c-sanity.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][4] ([i915#2846])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-apl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/shard-glk6/igt@gem_exec_fair@basic-n...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-glk6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk:  NOTRUN -> [FAIL][7] ([i915#2842]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-glk9/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-skl:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-skl6/igt@gem_lmem_swapp...@basic.html
- shard-iclb: NOTRUN -> [SKIP][9] ([i915#4613])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-iclb5/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-apl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-apl8/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([i915#7299])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/shard-skl6/igt@gem_workarou...@suspend-resume-fd.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-skl1/igt@gem_workarou...@suspend-resume-fd.html

  * igt@gen9_exec_parse@bb-oversize:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#2856])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-iclb5/igt@gen9_exec_pa...@bb-oversize.html

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

  * igt@i915_selftest@live@hangcheck:
- shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#5591])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/shard-tglb5/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-tglb2/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_atomic@plane-primary-overlay-mutable-zpos:
- shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271]) +38 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-glk9/igt@kms_ato...@plane-primary-overlay-mutable-zpos.html

  * igt@kms_big_fb@linear-8bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111614])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/shard-tglb7/igt@kms_big...@linear-8bpp-rotate-90.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-tglb: [PASS][19] -> [FAIL][20] 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/uapi: expose GTT alignment

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: expose GTT alignment
URL   : https://patchwork.freedesktop.org/series/110313/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

Re: [Intel-gfx] [PATCH v2 13/21] drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info postfix

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as
> part of unifying the naming within fbdev helpers. Adapt drivers. No
> functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 12/21] drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Rename struct drm_fb_helper.fbdev to info. The current name is
> misleading as it overlaps with generic fbdev naming conventions.
> Adapt to the usual naming in fbdev drivers by calling the field
> 'info'. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Agreed. I got confused by this naming in the past.

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH 00/10] Connect VFIO to IOMMUFD

[Yi Liu]

On 2022/10/31 20:18, Jason Gunthorpe wrote:

On Mon, Oct 31, 2022 at 06:38:45PM +0800, Yi Liu wrote:

Hi Jason,

On 2022/10/26 02:17, Jason Gunthorpe wrote:

This series provides an alternative container layer for VFIO implemented
using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
not be compiled in.

At this point iommufd can be injected by passing in a iommfd FD to
VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd
to obtain the compat IOAS and then connect up all the VFIO drivers as
appropriate.

This is temporary stopping point, a following series will provide a way to
directly open a VFIO device FD and directly connect it to IOMMUFD using
native ioctls that can expose the IOMMUFD features like hwpt, future
vPASID and dynamic attachment.

This series, in compat mode, has passed all the qemu tests we have
available, including the test suites for the Intel GVT mdev. Aside from
the temporary limitation with P2P memory this is belived to be fully
compatible with VFIO.

This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd


In our side, we found the gvt-g test failed. Guest i915 driver stuck at
init phase. While with your former version  (commit ID
a249441ba6fd9d658f4a1b568453e3a742d12686), gvt-g test is passing.


Oh, I didn't realize you grabbed such an older version for this testing..


yeah, this was grabbed before your posting. :-)


noticed there a quite a few change in iommufd/pages.c from last version.
We are internally tracing in the gvt-g side, may also good to have your
attention.


syzkaller just ran into this that I was starting to investigate:

@@ -1505,7 +1505,7 @@ int iopt_pages_fill_xarray(struct iopt_pages *pages, 
unsigned long start_index,
 int rc;
  
 pfn_reader_user_init(, pages);

-   user.upages_len = last_index - start_index + 1;
+   user.upages_len = (last_index - start_index + 1) * sizeof(*out_pages);
 interval_tree_for_each_double_span(, >access_itree,

It would certainly hit gvt - but you should get WARN_ON's not hangs

There is something wrong with the test suite that it isn't covering
the above, I'm going to look into that today.


sounds to be the cause. I didn't see any significant change in vfio_main.c
that may fail gvt. So should the iommufd changes. Then we will re-run the
test after your update.:-)

--
Regards,
Yi Liu

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)

[Gupta, Anshuman]

On 10/31/2022 2:09 PM, Patchwork wrote:

*Patch Details*
*Series:*   drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)
*URL:*	https://patchwork.freedesktop.org/series/108972/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/index.html 




  CI Bug Log - changes from CI_DRM_12310_full -> Patchwork_108972v4_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_108972v4_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108972v4_full, please notify your bug team to 
allow them

to document this new failure mode, which will reduce false positives in CI.


Participating hosts (11 -> 10)

Missing (1): pig-glk-j5005


Possible new issues

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



  IGT changes


Possible regressions

  *

Below failures are unrelated to this series.
Br,
Anshuman Gupta.


igt@i915_pipe_stress@stress-xrgb-untiled:

  o shard-tglb: PASS


 -> DMESG-WARN 

  *

igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:

  o shard-iclb: PASS


 -> FAIL 



Warnings

  * igt@runner@aborted:
  o shard-skl: (FAIL
, FAIL 
, FAIL , 
FAIL , FAIL 
, FAIL , 
FAIL , FAIL 
) (i915#3002  / i915#4312 
 / i915#6949 ) -> (FAIL 
, FAIL 
, FAIL 
, FAIL 
, FAIL 
, FAIL 
, FAIL 
) (i915#3002  / i915#4312 
)


Known issues

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



  IGT changes


Issues hit

  *

igt@feature_discovery@psr2:

  o shard-iclb: PASS


 -> SKIP 

 (i915#658 )
  *

igt@gem_exec_balancer@parallel-bb-first:

  o shard-iclb: PASS


 -> SKIP 

 (i915#4525 )
  *

igt@gen9_exec_parse@allowed-single:

  o shard-apl: PASS


 -> DMESG-WARN 

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

[Aravind Iddamsetty]

On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range which essentially makes
the GGTT address space to be shared between media and render GT.

BSPEC: 63834

Cc: Matt Roper 
Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 49 +++---
 drivers/gpu/drm/i915/gt/intel_gt.c| 15 +-
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  3 ++
 drivers/gpu/drm/i915/i915_driver.c| 19 +--
 drivers/gpu/drm/i915/i915_gem_evict.c | 63 +--
 drivers/gpu/drm/i915/i915_vma.c   |  5 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 +
 9 files changed, 115 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 2518cebbf931..f5c2f3c58627 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -196,10 +196,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
 
 void i915_ggtt_suspend(struct i915_ggtt *ggtt)
 {
+   struct intel_gt *gt;
+
i915_ggtt_suspend_vm(>vm);
ggtt->invalidate(ggtt);
 
-   intel_gt_check_and_clear_faults(ggtt->vm.gt);
+   list_for_each_entry(gt, >gt_list, ggtt_link)
+   intel_gt_check_and_clear_faults(gt);
 }
 
 void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -214,27 +217,36 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
 
 static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
 {
-   struct intel_uncore *uncore = ggtt->vm.gt->uncore;
+   struct intel_uncore *uncore;
+   struct intel_gt *gt;
 
-   /*
-* Note that as an uncached mmio write, this will flush the
-* WCB of the writes into the GGTT before it triggers the invalidate.
-*/
-   intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   list_for_each_entry(gt, >gt_list, ggtt_link) {
+   uncore = gt->uncore;
+   /*
+* Note that as an uncached mmio write, this will flush the
+* WCB of the writes into the GGTT before it triggers the 
invalidate.
+*/
+   intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, 
GFX_FLSH_CNTL_EN);
+   }
 }
 
 static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
 {
-   struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct drm_i915_private *i915 = ggtt->vm.i915;
 
gen8_ggtt_invalidate(ggtt);
 
-   if (GRAPHICS_VER(i915) >= 12)
-   intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
- GEN12_GUC_TLB_INV_CR_INVALIDATE);
-   else
-   intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+   if (GRAPHICS_VER(i915) >= 12) {
+   struct intel_gt *gt;
+
+   list_for_each_entry(gt, >gt_list, ggtt_link)
+   intel_uncore_write_fw(gt->uncore,
+ GEN12_GUC_TLB_INV_CR,
+ GEN12_GUC_TLB_INV_CR_INVALIDATE);
+   } else {
+   intel_uncore_write_fw(ggtt->vm.gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+   }
 }
 
 u64 gen8_ggtt_pte_encode(dma_addr_t addr,
@@ -986,8 +998,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 
ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
 
-   setup_private_pat(ggtt->vm.gt);
-
return ggtt_probe_common(ggtt, size);
 }
 
@@ -1186,7 +1196,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct 
intel_gt *gt)
(u64)ggtt->mappable_end >> 20);
drm_dbg(>drm, "DSM size = %lluM\n",
(u64)resource_size(_graphics_stolen_res) >> 20);
-
+   INIT_LIST_HEAD(>gt_list);
return 0;
 }
 
@@ -1296,9 +1306,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
 
 void i915_ggtt_resume(struct i915_ggtt *ggtt)
 {
+   struct intel_gt *gt;
bool flush;
 
-   intel_gt_check_and_clear_faults(ggtt->vm.gt);
+   list_for_each_entry(gt, >gt_list, ggtt_link)
+   intel_gt_check_and_clear_faults(gt);
 
flush = i915_ggtt_resume_vm(>vm);
 
@@ -1307,9 +1319,6 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
if (flush)
wbinvd_on_all_cpus();
 
-   if (GRAPHICS_VER(ggtt->vm.i915) >= 8)
-   setup_private_pat(ggtt->vm.gt);
-
intel_ggtt_restore_fences(ggtt);
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2e796ffad911..d72efb74563a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -110,9 +110,17 @@ static int intel_gt_probe_lmem(struct intel_gt *gt)
 
 int intel_gt_assign_ggtt(struct intel_gt *gt)
 {
-   gt->ggtt = drmm_kzalloc(>i915->drm, 

Re: [Intel-gfx] [PATCH v2 11/21] drm/fb-helper: Cleanup include statements in header file

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Only include what we have to.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
Nice cleanup.

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 10/21] drm/tve200: Include

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Include  for of_match_ptr().
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 09/21] drm/panel-ili9341: Include

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Include  for devm_of_find_backlight().
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 08/21] drm/rockchip: Don't set struct drm_driver.output_poll_changed

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.output_poll_changed. It's used to restore
> the fbdev console. But as rockchip uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See the
> functions drm_kms_helper_hotplug_event() and
> drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.
> 
> v2:
>   * fix commit description (Christian)
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 07/21] drm/logicvc: Don't set struct drm_driver.output_poll_changed

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.output_poll_changed. It's used to restore
> the fbdev console. But as logicvc uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See the
> functions drm_kms_helper_hotplug_event() and
> drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.
> 
> v2:
>   * fix commit description (Christian)
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH 00/10] Connect VFIO to IOMMUFD

[Jason Gunthorpe]

On Mon, Oct 31, 2022 at 06:38:45PM +0800, Yi Liu wrote:
> Hi Jason,
> 
> On 2022/10/26 02:17, Jason Gunthorpe wrote:
> > This series provides an alternative container layer for VFIO implemented
> > using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
> > not be compiled in.
> > 
> > At this point iommufd can be injected by passing in a iommfd FD to
> > VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd
> > to obtain the compat IOAS and then connect up all the VFIO drivers as
> > appropriate.
> > 
> > This is temporary stopping point, a following series will provide a way to
> > directly open a VFIO device FD and directly connect it to IOMMUFD using
> > native ioctls that can expose the IOMMUFD features like hwpt, future
> > vPASID and dynamic attachment.
> > 
> > This series, in compat mode, has passed all the qemu tests we have
> > available, including the test suites for the Intel GVT mdev. Aside from
> > the temporary limitation with P2P memory this is belived to be fully
> > compatible with VFIO.
> > 
> > This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd
> 
> In our side, we found the gvt-g test failed. Guest i915 driver stuck at
> init phase. While with your former version  (commit ID
> a249441ba6fd9d658f4a1b568453e3a742d12686), gvt-g test is passing. 

Oh, I didn't realize you grabbed such an older version for this testing..

> noticed there a quite a few change in iommufd/pages.c from last version.
> We are internally tracing in the gvt-g side, may also good to have your
> attention.

syzkaller just ran into this that I was starting to investigate:

@@ -1505,7 +1505,7 @@ int iopt_pages_fill_xarray(struct iopt_pages *pages, 
unsigned long start_index,
int rc;
 
pfn_reader_user_init(, pages);
-   user.upages_len = last_index - start_index + 1;
+   user.upages_len = (last_index - start_index + 1) * sizeof(*out_pages);
interval_tree_for_each_double_span(, >access_itree,

It would certainly hit gvt - but you should get WARN_ON's not hangs

There is something wrong with the test suite that it isn't covering
the above, I'm going to look into that today.

Jason

[Intel-gfx] [PATCH i-g-t] tests/i915/query: use 48B_ADDRESS in upload

[Matthew Auld]

Our working set could be larger than 4G here.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6671
Signed-off-by: Matthew Auld 
Cc: Nirmoy Das 
---
 tests/i915/i915_query.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index 4e43c7cd..e725e04e 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -625,10 +625,14 @@ static void upload(int fd, struct igt_list_head *handles, 
uint32_t num_handles)
  sizeof(struct drm_i915_gem_exec_object2));
 
i = 0;
-   igt_list_for_each_entry(iter, handles, link)
-   exec[i++].handle = iter->handle;
+   igt_list_for_each_entry(iter, handles, link) {
+   exec[i].handle = iter->handle;
+   exec[i].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   i++;
+   }
 
exec[i].handle = batch_create_size(fd, 4096);
+   exec[i].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 
execbuf.buffers_ptr = to_user_pointer(exec);
execbuf.buffer_count = num_handles + 1;
-- 
2.38.1

Re: [Intel-gfx] [PATCH v2 06/21] drm/ingenic: Don't set struct drm_driver.output_poll_changed

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.output_poll_changed. It's used to restore
> the fbdev console. But as ingenic uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See the
> functions drm_kms_helper_hotplug_event() and
> drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.
> 
> v2:
>   * fix commit description (Christian, Sergey)
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 05/21] drm/imx/dcss: Don't set struct drm_driver.output_poll_changed

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.output_poll_changed. It's used to restore
> the fbdev console. But as DCSS uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See the
> functions drm_kms_helper_hotplug_event() and
> drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.
> 
> v2:
>   * fix commit description (Christian)
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 04/21] drm/amdgpu: Don't set struct drm_driver.output_poll_changed

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.output_poll_changed. It's used to restore
> the fbdev console. But as amdgpu uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See the
> functions drm_kms_helper_hotplug_event() and
> drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.
> 
> v2:
>   * fix commit description (Christian)
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 04/21] drm/amdgpu: Don't set struct drm_driver.output_poll_changed

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.output_poll_changed. It's used to restore
> the fbdev console. But as amdgpu uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See the
> functions drm_kms_helper_hotplug_event() and
> drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.
> 
> v2:
>   * fix commit description (Christian)
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

Do you think that the fbdev helpers kernel doc has to be updated to mention
that drm_fb_helper_lastclose() and drm_fb_helper_output_poll_changed() are
not needed when generic fbdev emulation is used? Because by reading that is
not clear that's the case:

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_fb_helper.c#L86

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 03/21] drm/vboxvideo: Don't set struct drm_driver.lastclose

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.lastclose. It's used to restore the
> fbdev console. But as vboxvideo uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See
> the call to drm_client_dev_restore() in drm_lastclose().
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 02/21] drm/mcde: Don't set struct drm_driver.lastclose

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.lastclose. It's used to restore the
> fbdev console. But as mcde uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See
> the call to drm_client_dev_restore() in drm_lastclose().
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH v2 01/21] drm/komeda: Don't set struct drm_driver.lastclose

[Javier Martinez Canillas]

On 10/24/22 13:19, Thomas Zimmermann wrote:
> Don't set struct drm_driver.lastclose. It's used to restore the
> fbdev console. But as komeda uses generic fbdev emulation, the
> console is being restored by the DRM client helpers already. See
> the call to drm_client_dev_restore() in drm_lastclose().
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

[Intel-gfx] [PATCH] drm/i915/selftest: Fix gt_pm live_gt_clocks test

[Anshuman Gupta]

While reading the engine timestamps there can be uncontrollable
concurrent mmio access via other i915 child drivers and by GuC,
which may cause mmio latency to read the engine timestamps,
Account such latency to calculate time to read engine timestamp.

Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index be94f863bdef..4f299590ae62 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -50,8 +50,8 @@ static void measure_clocks(struct intel_engine_cs *engine,
 
udelay(1000);
 
-   dt[i] = ktime_sub(ktime_get(), dt[i]);
cycles[i] += ENGINE_READ_FW(engine, RING_TIMESTAMP);
+   dt[i] = ktime_sub(ktime_get(), dt[i]);
local_irq_enable();
}
 
-- 
2.25.1

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

Hi Dave & Daniel,

Here goes first drm-intel-gt-next pull req towards 6.2.

We have a fix for #6222 (kernel memory corruption issue) and fix for
display regression after resume. A missing W/A for Gen12 iGPUs and
extension of compute pre-emption timeout to 7.5 seconds to account for
compute corner cases. Improvements to GuC compute error capture,
scheduling hysteresis and SLPC. Fixes to EHL MOCS tables. Better docs
for I915_PARAM_HUC_STATUS and pre-emption control policy. Extending the
grace period for full GPU reset timeout to 60 seconds to better capture
logs or recover, as opposed to just giving up on whole device in 5 seconds.

We're starting to add HWMON metrics for recent devices. More MTL
enabling, DG2 workarounds, DG2 HuC support, OA for DG2 is enabled. Small
bar enabling, PS64 support added for DG2 page tables. ptrace support for
local memory objects, local-memory migration for display surfaces.

Note that there is drm/drm-next backmerge and then MEI subsystem patches
around GSC/PXP which are intertwined with i915 change so merged here as
agreed with Tomas and Greg.

Additionally the usual amount of refactoring, cleanups, debugging
improvements and static checker fixes.

Regards, Joonas

PS. Once you have pulled this, I will backmerge drm-next to bring in
more dependencies for upcoming patches.

***

drm-intel-gt-next-2022-10-31:

- Start adding HWMON metrics (Dale, Ashutosh, Riana, Badal)

  See Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

Cross-subsystem Changes:

- MEI subsystem patches for GSC/PXP (Vitaly, Tomas)
* R-b'd by Greg, agreed to merge via drm-intel-gt-next
- Backmerge of drm/drm-next to pull misc/mei changes for DG2 HuC

Driver Changes:

- Fix for #6222: Kernel memory corruption when running piglit with OA
  enabled (Chris)
- Add Wa_1806527549 for Gen12 iGPU (Gustavo)
- Fix display problems after resume regression (Thomas)
- Extend pre-emption timeout to 7.5 seconds on compute capable engines
  on Gen12 (John)
- Add error compute registers to GuC error capture list (Alan)
- Delay disabling guc_id scheduling for better hysteresis (Matt B)
- Use platform min/max frequency with GuC SLPC (Vinay)
- Meteorlake (MTL) enabling (Ashutosh, Matt R, Aravind)
- Add more DG2 workarounds (Matt A)
- DG2 HuC loading (Daniele)
- Enable OA support for DG2 (Umesh, Vinay, Lionel)
- Better document I915_PARAM_HUC_STATUS error codes (Daniele)
- Enable compute scheduling on DG2 (John)
- Small bar enabling for dGPU (Matt A)
- Enable PS64 support for DG2 (Matt A)
- Handle migration to local-memory for display surfaces (Matt A)
- Update MOCS table for EHL (Tejas)
- Limit GuC scheduling properties to avoid overflow (John)
- Update forcewake domain for CCS register ranges for PVC (Matt R)
- Implement access_memory for local memory to enable ptrace (Matt A)
- Document and future-proof preemption control policy (Matt R)
- Restrict forced preemption to the active context (Chris)
- Move scratch page into system memory on all platforms (Chris)
- Flush to global observation point before breadcrumb write (Prathap, Nirmoy)
- Bump the reset-failure timeout to 60s (Chris)

- Codebase restructuring for more clarity (Lucas, Jani, Vinay, Nirmoy,
  Ville, Andrzej)
- Stop abusing swiotlb_max_segment (Robert, Christoph)
- Fix a potential UAF at device unload (Nirmoy, Chris)
- Fix revocation of non-persistent contexts with GuC (Tvrtko)
- Fix GuC error capture sizing estimation and reporting (Alan)
- Make failure to setup stolen non-fatal on dGPU (Lucas)
- Fixes to perf_limit_reasons and add to debugfs (Ashutosh, Tilak)
- Release build fix for GuC log size removal (John)
- Cleanup partial engine discovery failures (Chris)
- Do not cleanup obj with NULL bo->resource (Nirmoy)
- Split GAM and MSLICE steering (Matt R)
- Flush GEM contexts on driver release (Janusz, Chris)
- Multi GT suspend and resume enabling (Tvrtko)
- Use i915_vm_put on ppgtt_create error paths (Chris)

- Remove leftover code from previous cleanups (Niranjana, Nirmoy,
  Gwan-gyeong, Matt A, Andi, Alan, Karolina)
- Selftest and debugging improvements (Tvrtko, Nirmoy, Riana, Vinay)
- Static checker fixups (Colin, Nathan)
- Documentation improvements (Lucas)

The following changes since commit 7860d720a84c74b2761c6b7995392a798ab0a3cb:

  drm/msm: Fix build break with recent mm tree (2022-09-30 10:13:49 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-10-31

for you to fetch changes up to 876e9047a91839ee5be0ba099036d19883e52ca2:

  drm/i915/mtl: Add missing steering table terminators (2022-10-28 17:36:56 
-0700)


- Start adding HWMON metrics (Dale, Ashutosh, Riana, Badal)

  See Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

Cross-subsystem Changes:

- MEI subsystem patches for GSC/PXP (Vitaly, Tomas)
* R-b'd by Greg, agreed to merge via drm-intel-gt-next
- Backmerge of drm/drm-next to pull 

Re: [Intel-gfx] [PATCH 00/10] Connect VFIO to IOMMUFD

[Yi Liu]

Hi Jason,

On 2022/10/26 02:17, Jason Gunthorpe wrote:

This series provides an alternative container layer for VFIO implemented
using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
not be compiled in.

At this point iommufd can be injected by passing in a iommfd FD to
VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd
to obtain the compat IOAS and then connect up all the VFIO drivers as
appropriate.

This is temporary stopping point, a following series will provide a way to
directly open a VFIO device FD and directly connect it to IOMMUFD using
native ioctls that can expose the IOMMUFD features like hwpt, future
vPASID and dynamic attachment.

This series, in compat mode, has passed all the qemu tests we have
available, including the test suites for the Intel GVT mdev. Aside from
the temporary limitation with P2P memory this is belived to be fully
compatible with VFIO.

This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd


In our side, we found the gvt-g test failed. Guest i915 driver stuck at
init phase. While with your former version  (commit ID 
a249441ba6fd9d658f4a1b568453e3a742d12686), gvt-g test is passing. I

noticed there a quite a few change in iommufd/pages.c from last version.
We are internally tracing in the gvt-g side, may also good to have your
attention.


It requires the iommufd series:

https://lore.kernel.org/r/0-v3-402a7d6459de+24b-iommufd_...@nvidia.com

Jason Gunthorpe (10):
   vfio: Move vfio_device driver open/close code to a function
   vfio: Move vfio_device_assign_container() into
 vfio_device_first_open()
   vfio: Rename vfio_device_assign/unassign_container()
   vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
   vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for
 vfio_file_enforced_coherent()
   vfio-iommufd: Allow iommufd to be used in place of a container fd
   vfio-iommufd: Support iommufd for physical VFIO devices
   vfio-iommufd: Support iommufd for emulated VFIO devices
   vfio: Make vfio_container optionally compiled
   iommufd: Allow iommufd to supply /dev/vfio/vfio

  drivers/gpu/drm/i915/gvt/kvmgt.c  |   3 +
  drivers/iommu/iommufd/Kconfig |  12 +
  drivers/iommu/iommufd/main.c  |  35 +-
  drivers/s390/cio/vfio_ccw_ops.c   |   3 +
  drivers/s390/crypto/vfio_ap_ops.c |   3 +
  drivers/vfio/Kconfig  |  38 ++-
  drivers/vfio/Makefile |   5 +-
  drivers/vfio/container.c  | 136 ++--
  drivers/vfio/fsl-mc/vfio_fsl_mc.c |   3 +
  drivers/vfio/iommufd.c| 161 +
  .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c|   6 +
  drivers/vfio/pci/mlx5/main.c  |   3 +
  drivers/vfio/pci/vfio_pci.c   |   3 +
  drivers/vfio/platform/vfio_amba.c |   3 +
  drivers/vfio/platform/vfio_platform.c |   3 +
  drivers/vfio/vfio.h   | 100 +-
  drivers/vfio/vfio_iommu_type1.c   |   5 +-
  drivers/vfio/vfio_main.c  | 318 ++
  include/linux/vfio.h  |  39 +++
  19 files changed, 681 insertions(+), 198 deletions(-)
  create mode 100644 drivers/vfio/iommufd.c


base-commit: 3bec937e94942a6aee8854be1c1f5cc2b92d15e2


--
Regards,
Yi Liu

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/gvt: remove hardcoded value on crc32_start calculation

[Patchwork]

== Series Details ==

Series: i915/gvt: remove hardcoded value on crc32_start calculation
URL   : https://patchwork.freedesktop.org/series/110310/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12322 -> Patchwork_110310v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 39)
--

  Additional (2): fi-cfl-8700k fi-elk-e7500 
  Missing(1): fi-rkl-11600 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-elk-e7500:   NOTRUN -> [SKIP][3] ([fdo#109271]) +20 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/fi-elk-e7500/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  NOTRUN -> [INCOMPLETE][4] ([i915#4890])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/fi-icl-u2/igt@i915_selftest@l...@execlists.html

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

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-elk-e7500:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/fi-elk-e7500/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-cfl-8700k:   NOTRUN -> [SKIP][8] ([fdo#109271]) +10 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/fi-cfl-8700k/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([i915#3546])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}:   [DMESG-WARN][10] ([i915#2867]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_tiled_blits@basic:
- fi-pnv-d510:[SKIP][12] ([fdo#109271]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [DMESG-WARN][14] ([i915#5537]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_lrc:
- fi-icl-u2:  [DMESG-FAIL][16] ([i915#4890]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/fi-icl-u2/igt@i915_selftest@live@gt_lrc.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110310v1/fi-icl-u2/igt@i915_selftest@live@gt_lrc.html

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-bdw-5557u:   [INCOMPLETE][20] ([i915#146]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12322/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [21]: 

[Intel-gfx] [PATCH] drm/i915/uapi: expose GTT alignment

[Matthew Auld]

On some platforms we potentially have different alignment restrictions
depending on the memory type. We also now have different alignment
restrictions for the same region across different kernel versions.
Extend the region query to return the minimum required GTT alignment.

Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19398

Testcase: igt@gem_create@create-ext-placement-alignment
Testcase: igt@i915_query@query-regions-sanity-check
Suggested-by: Lionel Landwerlin 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Michal Mrozek 
Cc: Thomas Hellström 
Cc: Stuart Summers 
Cc: Jordan Justen 
Cc: Yang A Shi 
Cc: Nirmoy Das 
Cc: Niranjana Vishwanathapura 
Reviewed-by: Nirmoy Das 
Acked-by: Jordan Justen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221004114915.221708-2-matthew.a...@intel.com
---
 drivers/gpu/drm/i915/i915_query.c |  1 +
 include/uapi/drm/i915_drm.h   | 29 +++--
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 6ec9c9fb7b0d..111377f210ed 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -498,6 +498,7 @@ static int query_memregion_info(struct drm_i915_private 
*i915,
info.region.memory_class = mr->type;
info.region.memory_instance = mr->instance;
info.probed_size = mr->total;
+   info.gtt_alignment = mr->min_page_size;
 
if (mr->type == INTEL_MEMORY_LOCAL)
info.probed_cpu_visible_size = mr->io_size;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8df261c5ab9b..c346b1923d11 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3356,8 +3356,33 @@ struct drm_i915_memory_region_info {
/** @region: The class:instance pair encoding */
struct drm_i915_gem_memory_class_instance region;
 
-   /** @rsvd0: MBZ */
-   __u32 rsvd0;
+   union {
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+   /**
+* @gtt_alignment:
+*
+* The minimum required GTT alignment for this type of memory.
+* When allocating a GTT address it must be aligned to this
+* value or larger. On some platforms the kernel might opt to
+* using 64K pages for I915_MEMORY_CLASS_DEVICE, where 64K GTT
+* pages can then be used if we also use 64K GTT alignment.
+*
+* NOTE: If this is zero then this must be an older
+* kernel which lacks support for this field.
+*
+* Side note: For larger objects (especially for
+* I915_MEMORY_CLASS_DEVICE), like 2M+ in size, userspace should
+* consider potentially bumping the GTT alignment to say 2M,
+* which could potentially increase the likelihood of the kernel
+* being able to utilise 2M GTT pages underneath, if the layout
+* of the physical pages allows it.  On some configurations we
+* can then also use a more efficient page-table layout, if we
+* can't use the more desirable 2M GTT page, so long as we know
+* that the entire page-table will be used by this object.
+*/
+   __u32 gtt_alignment;
+   };
 
/**
 * @probed_size: Memory probed by the driver
-- 
2.38.1

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Only initialize GSC in tile 0

[Rodrigo Vivi]

On Mon, Oct 31, 2022 at 05:48:07AM -0400, Winkler, Tomas wrote:
> 
> > 
> > On Mon, Oct 31, 2022 at 07:51:17AM +0200, Alexander Usyskin wrote:
> > > From: José Roberto de Souza 
> > >
> > > For multi-tile setups the GSC operational only on the tile 0.
> > > Skip GSC auxiliary device creation for all other tiles.
> > >
> > > Cc: Tomas Winkler 
> > > Cc: Vitaly Lubart 
> > > Signed-off-by: José Roberto de Souza 
> > > Signed-off-by: Alexander Usyskin 
> > > ---
> > >  drivers/gpu/drm/i915/gt/intel_gt.c | 8 ++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > index 2e796ffad911..92ad8cd45ddb 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > @@ -456,7 +456,10 @@ void intel_gt_chipset_flush(struct intel_gt *gt)
> > >
> > >  void intel_gt_driver_register(struct intel_gt *gt)  {
> > > - intel_gsc_init(>gsc, gt->i915);
> > > + if (gt->info.id == 0)
> > > + intel_gsc_init(>gsc, gt->i915);
> > > + else
> > > + drm_dbg(>i915->drm, "Not initializing gsc for remote
> > tiles\n");
> > 
> > It looks to me that we need to move the gsc out of the intel_gt instead of
> > workaround the initialization.
> 
> The interrupts are handled by gt, so where this should go ? 
> 

Ouch, I've seen it now. But still this patch brings me more doubts...

is gsc really a per-gt thing? if not why the gsc irq is in the gt domain?
if yes why the one in the second tile not operational?

if it is not a per-tile thing and only the irq is in a bad spot we could
still move it outside gt and make the irq to be redirected.

well, if it is really a per tile thing but it is fused of, do we have hw
ways to detect that?

if it is really a tile thing and we don't have better ways to identify
we might want to do with this patch, but add a bit more information on the
reasons and also double checking if by avoiding the initialization we are
sure that we are not going to reach any case of attempting to utilize the
un-initialized gsc.