[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add MOCS tables for XeHP SDV and DG2 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Add MOCS tables for XeHP SDV and DG2 (rev2)
URL   : https://patchwork.freedesktop.org/series/94344/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20961


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-rkl-11600:   [PASS][2] -> [SKIP][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@fbdev@write:
- fi-rkl-11600:   [PASS][5] -> [SKIP][6] ([i915#2582]) +4 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@fb...@write.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@fb...@write.html

  * igt@i915_pm_rpm@basic-rte:
- fi-rkl-11600:   [PASS][7] -> [SKIP][8] ([fdo#109308]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@i915_pm_...@basic-rte.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@i915_pm_...@basic-rte.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   [PASS][9] -> [SKIP][10] ([fdo#111825]) +7 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3669]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-rkl-11600:   [PASS][12] -> [SKIP][13] ([i915#3180])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-rkl-11600:   [PASS][14] -> [SKIP][15] ([i915#3919]) +9 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@prime_vgem@basic-fence-flip:
- fi-rkl-11600:   [PASS][16] -> [SKIP][17] ([i915#1845])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][18] ([i915#1993]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][20] ([i915#3921]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20961/fi-snb-2600/igt@i915_selftest@l...@hangch

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add MOCS tables for XeHP SDV and DG2

[Patchwork]

== Series Details ==

Series: drm/i915: Add MOCS tables for XeHP SDV and DG2
URL   : https://patchwork.freedesktop.org/series/94344/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20960


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-rkl-11600:   [PASS][2] -> [SKIP][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@fbdev@write:
- fi-rkl-11600:   [PASS][7] -> [SKIP][8] ([i915#2582]) +4 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@fb...@write.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@fb...@write.html

  * igt@i915_pm_rpm@basic-rte:
- fi-rkl-11600:   [PASS][9] -> [SKIP][10] ([fdo#109308]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@i915_pm_...@basic-rte.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][11] -> [INCOMPLETE][12] ([i915#2940])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   [PASS][13] -> [SKIP][14] ([fdo#111825]) +7 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3669]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-rkl-11600:   [PASS][16] -> [SKIP][17] ([i915#3180])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-rkl-11600:   [PASS][18] -> [SKIP][19] ([i915#3919]) +9 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20960/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@prime_vgem@basic-fence-flip:
- fi-rkl-11600:   [PASS][20] -> [SKIP][21] ([i915#1845])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html
   [21]: 
http

[Intel-gfx] ✗ Fi.CI.BAT: failure for Clean up GuC CI failures, simplify locking, and kernel DOC (rev10)

[Patchwork]

== Series Details ==

Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev10)
URL   : https://patchwork.freedesktop.org/series/93704/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20959


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-rkl-11600:   [PASS][2] -> [SKIP][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
New tests
-

  New tests have been introduced between CI_DRM_10550 and Patchwork_20959:

### New IGT tests (1) ###

  * igt@i915_selftest@live@guc:
- Statuses : 37 pass(s)
- Exec time: [0.40, 5.01] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@fbdev@write:
- fi-rkl-11600:   [PASS][5] -> [SKIP][6] ([i915#2582]) +4 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@fb...@write.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@fb...@write.html

  * igt@i915_pm_rpm@basic-rte:
- fi-rkl-11600:   [PASS][7] -> [SKIP][8] ([fdo#109308]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@i915_pm_...@basic-rte.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-y:   [PASS][9] -> [DMESG-FAIL][10] ([i915#541])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   [PASS][11] -> [SKIP][12] ([fdo#111825]) +7 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#3669]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-rkl-11600:   [PASS][14] -> [SKIP][15] ([i915#3180])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-rkl-11600:   [PASS][16] -> [SKIP][17] ([i915#3919]) +9 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@prime_vgem@basic-fence-flip:
- fi-rkl-11600:   [PASS][18] -> [SKIP][19] ([i915#1845])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20959/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][20] ([i915#1

[Intel-gfx] [PATCH 1/2] drm/i915/xehpsdv: Define MOCS table for XeHP SDV

[Matt Roper]

From: Lucas De Marchi 

Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
memory for L3 destined transaction" and L3_LKP to "enable Lookup for
uncacheable accesses".

Bspec: 45101
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Lucas De Marchi 
Signed-off-by: Stuart Summers 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 35 +++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index e96afd7beb49..133cfe07cb9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -42,6 +42,8 @@ struct drm_i915_mocs_table {
 #define L3_ESC(value)  ((value) << 0)
 #define L3_SCC(value)  ((value) << 1)
 #define _L3_CACHEABILITY(value)((value) << 4)
+#define L3_GLBGO(value)((value) << 6)
+#define L3_LKUP(value) ((value) << 7)
 
 /* Helper defines */
 #define GEN9_NUM_MOCS_ENTRIES  64  /* 63-64 are reserved, but configured. */
@@ -315,6 +317,31 @@ static const struct drm_i915_mocs_entry dg1_mocs_table[] = 
{
MOCS_ENTRY(63, 0, L3_1_UC),
 };
 
+static const struct drm_i915_mocs_entry xehpsdv_mocs_table[] = {
+   /* wa_1608975824 */
+   MOCS_ENTRY(0, 0, L3_3_WB | L3_LKUP(1)),
+
+   /* UC - Coherent; GO:L3 */
+   MOCS_ENTRY(1, 0, L3_1_UC | L3_LKUP(1)),
+   /* UC - Coherent; GO:Memory */
+   MOCS_ENTRY(2, 0, L3_1_UC | L3_GLBGO(1) | L3_LKUP(1)),
+   /* UC - Non-Coherent; GO:Memory */
+   MOCS_ENTRY(3, 0, L3_1_UC | L3_GLBGO(1)),
+   /* UC - Non-Coherent; GO:L3 */
+   MOCS_ENTRY(4, 0, L3_1_UC),
+
+   /* WB */
+   MOCS_ENTRY(5, 0, L3_3_WB | L3_LKUP(1)),
+
+   /* HW Reserved - SW program but never use. */
+   MOCS_ENTRY(48, 0, L3_3_WB | L3_LKUP(1)),
+   MOCS_ENTRY(49, 0, L3_1_UC | L3_LKUP(1)),
+   MOCS_ENTRY(60, 0, L3_1_UC),
+   MOCS_ENTRY(61, 0, L3_1_UC),
+   MOCS_ENTRY(62, 0, L3_1_UC),
+   MOCS_ENTRY(63, 0, L3_1_UC),
+};
+
 enum {
HAS_GLOBAL_MOCS = BIT(0),
HAS_ENGINE_MOCS = BIT(1),
@@ -344,7 +371,13 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
memset(table, 0, sizeof(struct drm_i915_mocs_table));
 
table->unused_entries_index = I915_MOCS_PTE;
-   if (IS_DG1(i915)) {
+   if (IS_XEHPSDV(i915)) {
+   table->size = ARRAY_SIZE(xehpsdv_mocs_table);
+   table->table = xehpsdv_mocs_table;
+   table->uc_index = 2;
+   table->n_entries = GEN9_NUM_MOCS_ENTRIES;
+   table->unused_entries_index = 5;
+   } else if (IS_DG1(i915)) {
table->size = ARRAY_SIZE(dg1_mocs_table);
table->table = dg1_mocs_table;
table->uc_index = 1;
-- 
2.25.4

[Intel-gfx] [PATCH 2/2] drm/i915/dg2: Define MOCS table for DG2

[Matt Roper]

Bspec: 45101, 45427
Cc: Ramalingam C 
Signed-off-by: Matt Roper 
Reviewed-by: Matt Atwood 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 37 +++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 133cfe07cb9f..d66be8457d26 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -342,6 +342,30 @@ static const struct drm_i915_mocs_entry 
xehpsdv_mocs_table[] = {
MOCS_ENTRY(63, 0, L3_1_UC),
 };
 
+static const struct drm_i915_mocs_entry dg2_mocs_table[] = {
+   /* UC - Coherent; GO:L3 */
+   MOCS_ENTRY(0, 0, L3_1_UC | L3_LKUP(1)),
+   /* UC - Coherent; GO:Memory */
+   MOCS_ENTRY(1, 0, L3_1_UC | L3_GLBGO(1) | L3_LKUP(1)),
+   /* UC - Non-Coherent; GO:Memory */
+   MOCS_ENTRY(2, 0, L3_1_UC | L3_GLBGO(1)),
+
+   /* WB - LC */
+   MOCS_ENTRY(3, 0, L3_3_WB | L3_LKUP(1)),
+};
+
+static const struct drm_i915_mocs_entry dg2_mocs_table_g10_ax[] = {
+   /* Wa_14011441408: Set Go to Memory for MOCS#0 */
+   MOCS_ENTRY(0, 0, L3_1_UC | L3_GLBGO(1) | L3_LKUP(1)),
+   /* UC - Coherent; GO:Memory */
+   MOCS_ENTRY(1, 0, L3_1_UC | L3_GLBGO(1) | L3_LKUP(1)),
+   /* UC - Non-Coherent; GO:Memory */
+   MOCS_ENTRY(2, 0, L3_1_UC | L3_GLBGO(1)),
+
+   /* WB - LC */
+   MOCS_ENTRY(3, 0, L3_3_WB | L3_LKUP(1)),
+};
+
 enum {
HAS_GLOBAL_MOCS = BIT(0),
HAS_ENGINE_MOCS = BIT(1),
@@ -371,7 +395,18 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
memset(table, 0, sizeof(struct drm_i915_mocs_table));
 
table->unused_entries_index = I915_MOCS_PTE;
-   if (IS_XEHPSDV(i915)) {
+   if (IS_DG2(i915)) {
+   if (IS_DG2_GT_STEP(i915, G10, STEP_A0, STEP_B0)) {
+   table->size = ARRAY_SIZE(dg2_mocs_table_g10_ax);
+   table->table = dg2_mocs_table_g10_ax;
+   } else {
+   table->size = ARRAY_SIZE(dg2_mocs_table);
+   table->table = dg2_mocs_table;
+   }
+   table->uc_index = 1;
+   table->n_entries = GEN9_NUM_MOCS_ENTRIES;
+   table->unused_entries_index = 3;
+   } else if (IS_XEHPSDV(i915)) {
table->size = ARRAY_SIZE(xehpsdv_mocs_table);
table->table = xehpsdv_mocs_table;
table->uc_index = 2;
-- 
2.25.4

[Intel-gfx] [PATCH 0/2] drm/i915: Add MOCS tables for XeHP SDV and DG2

[Matt Roper]

Now that Ayaz's MOCS initialization series has landed on
drm-intel-gt-next, we can add the new MOCS tables for XeHP SDV and DG2.

[1] https://patchwork.freedesktop.org/series/94315/

Lucas De Marchi (1):
  drm/i915/xehpsdv: Define MOCS table for XeHP SDV

Matt Roper (1):
  drm/i915/dg2: Define MOCS table for DG2

 drivers/gpu/drm/i915/gt/intel_mocs.c | 70 +++-
 1 file changed, 69 insertions(+), 1 deletion(-)

-- 
2.25.4

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support

[Souza, Jose]

On Fri, 2021-09-03 at 22:09 +, Souza, Jose wrote:
> On Thu, 2021-09-02 at 21:42 +0300, Gwan-gyeong Mun wrote:
> > 
> > On 8/25/21 3:58 AM, José Roberto de Souza wrote:
> > > By now all the userspace applications should have migrated to atomic
> > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > 
> > > With that we can kill frontbuffer rendering support in i915 for
> > > modern platforms.
> > > 
> > > So here converting legacy APIs into atomic commits so it can be
> > > properly handled by driver i915.
> > > 
> > > Several IGT tests will fail with this changes, because some tests
> > > were stressing those frontbuffer rendering scenarios that no userspace
> > > should be using by now, fixes to IGT should be sent soon.
> > > 
> > > v2:
> > > - return earlier to not set fb_tracking.busy/flip_bits
> > > - added a warn on to make sure we are not setting the busy/flip_bits
> > > 
> > > Cc: Daniel Vetter 
> > > Cc: Gwan-gyeong Mun 
> > > Cc: Ville Syrjälä 
> > > Cc: Jani Nikula 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >   drivers/gpu/drm/i915/display/intel_cursor.c|  6 ++
> > >   drivers/gpu/drm/i915/display/intel_fb.c|  8 +++-
> > >   .../gpu/drm/i915/display/intel_frontbuffer.c   | 18 ++
> > >   drivers/gpu/drm/i915/i915_drv.h|  2 ++
> > >   4 files changed, 29 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> > > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > index c7618fef01439..5aa996c3b7980 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > @@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> > >  u32 src_w, u32 src_h,
> > >  struct drm_modeset_acquire_ctx *ctx)
> > >   {
> > > + struct drm_i915_private *i915 = to_i915(_crtc->dev);
> > >   struct intel_plane *plane = to_intel_plane(_plane);
> > >   struct intel_crtc *crtc = to_intel_crtc(_crtc);
> > >   struct intel_plane_state *old_plane_state =
> > > @@ -633,12 +634,9 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> > >* PSR2 selective fetch also requires the slow path as
> > >* PSR2 plane and transcoder registers can only be updated 
> > > during
> > >* vblank.
> > > -  *
> > > -  * FIXME bigjoiner fastpath would be good
> > >*/
> > >   if (!crtc_state->hw.active || 
> > > intel_crtc_needs_modeset(crtc_state) ||
> > > - crtc_state->update_pipe || crtc_state->bigjoiner ||
> > > - crtc_state->enable_psr2_sel_fetch)
> > > + crtc_state->update_pipe || !HAS_FRONTBUFFER_RENDERING(i915))
> > >   goto slow;
> > >   
> > >   /*
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> > > b/drivers/gpu/drm/i915/display/intel_fb.c
> > > index e4b8602ec0cd2..3eb60785c9f29 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > > @@ -3,6 +3,7 @@
> > >* Copyright © 2021 Intel Corporation
> > >*/
> > >   
> > > +#include 
> > >   #include 
> > >   #include 
> > >   
> > > @@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct 
> > > drm_framebuffer *fb,
> > >   unsigned int num_clips)
> > >   {
> > >   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > > + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> > >   
> > >   i915_gem_object_flush_if_display(obj);
> > > - intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
> > >   
> > > + if (!HAS_FRONTBUFFER_RENDERING(i915))
> > > + return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
> > > +  num_clips);
> > Hi,
> > Even if the userspace informs us of the dirty (damage) region of the 
> > front buffer being used, GEN9 to GEN12 still uses the HW Tracking 
> > function for PSR and FBC.
> > And if you look at the description of the intel_psr_flush() function, 
> > you can see that there are the following restrictions.
> > 
> > "Since the hardware frontbuffer tracking has gaps we need to integrate 
> > with the software frontbuffer tracking."
> > 
> > If this restriction is still valid from GEN9 to GEN12, even if the 
> > existing frontbuffer tracking function is not used, when 
> > intel_user_framebuffer_dirty() is called, in the case of PSR, 
> > psr_force_hw_tracking_exit() is called or intel_psr_exit() and 
> > schedule_work(psr.work) seems to be required.
> 
> As this will trigger calls to the functions that write the plane registers 
> PSR HW tracking and FBC tracking will understand a page flip happened even
> if going from and to the same surface.
> 
> But will double check it.

Yep, no issues with PSR or FBC. HW understand as a flip and it is properly 
handled

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev10)

[Patchwork]

== Series Details ==

Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev10)
URL   : https://patchwork.freedesktop.org/series/93704/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev10)

[Patchwork]

== Series Details ==

Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev10)
URL   : https://patchwork.freedesktop.org/series/93704/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7a92435f3439 drm/i915/guc: Fix blocked context accounting
4cbb7ec8d2a5 drm/i915/guc: Fix outstanding G2H accounting
a09678f24d4a drm/i915/guc: Unwind context requests in reverse order
2b55e7be2440 drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
92ea1c87dd5d drm/i915/guc: Process all G2H message at once in work queue
28d3a1c4f1ab drm/i915/guc: Workaround reset G2H is received after schedule done 
G2H
ae1b3d67cd6b Revert "drm/i915/gt: Propagate change in error status to children 
on unhold"
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 3761baae908a ("Revert "drm/i915: 
Propagate errors on awaiting already signaled fences"")'
#8: 
from one client ending up in another. In commit 3761baae908a ("Revert

-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#27: 
References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting 
already signaled fences"")'

total: 1 errors, 1 warnings, 0 checks, 10 lines checked
c1bd72699e71 drm/i915/guc: Kick tasklet after queuing a request
-:8: WARNING:TYPO_SPELLING: 'inteface' may be misspelled - perhaps 'interface'?
#8: 
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new 
inteface")
 


total: 0 errors, 1 warnings, 0 checks, 7 lines checked
28f1e6d22bad drm/i915/guc: Don't enable scheduling on a banned context, guc_id 
invalid, not registered
c2d27d762bc5 drm/i915/guc: Copy whole golden context, set engine state size of 
subset
1bc44c377df9 drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
-:108: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#108: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 233 lines checked
2aa269f239b4 drm/i915/guc: Take context ref when cancelling request
10a7e5916e04 drm/i915/guc: Don't touch guc_state.sched_state without a lock
6c78bd32a97b drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
f098b2e26fba drm/i915: Allocate error capture in nowait context
475206e6d350 drm/i915/guc: Flush G2H work queue during reset
73970752f37c drm/i915/guc: Release submit fence from an irq_work
3c6373fb6529 drm/i915/guc: Move guc_blocked fence to struct guc_state
4be2eae80738 drm/i915/guc: Rework and simplify locking
759636cf75ee drm/i915/guc: Proper xarray usage for contexts_lookup
f53a65c0952c drm/i915/guc: Drop pin count check trick between sched_disable and 
re-pin
52980a2d7174 drm/i915/guc: Move GuC priority fields in context under guc_active
8e4a0506fc20 drm/i915/guc: Move fields protected by guc->contexts_lock into sub 
structure
6635fe9c9ffb drm/i915/guc: Drop guc_active move everything into guc_state
58856727d06e drm/i915/guc: Add GuC kernel doc

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/display: Some code improvements and code style fixes for DRRS (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm/i915/display: Some code improvements 
and code style fixes for DRRS (rev2)
URL   : https://patchwork.freedesktop.org/series/94342/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20958


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-rkl-11600:   [PASS][2] -> [SKIP][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@fbdev@write:
- fi-rkl-11600:   [PASS][5] -> [SKIP][6] ([i915#2582]) +4 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@fb...@write.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@fb...@write.html

  * igt@i915_pm_rpm@basic-rte:
- fi-rkl-11600:   [PASS][7] -> [SKIP][8] ([fdo#109308]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@i915_pm_...@basic-rte.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@i915_pm_...@basic-rte.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   [PASS][9] -> [SKIP][10] ([fdo#111825]) +7 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3669]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-rkl-11600:   [PASS][12] -> [SKIP][13] ([i915#3180])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-rkl-11600:   [PASS][14] -> [SKIP][15] ([i915#3919]) +9 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@prime_vgem@basic-fence-flip:
- fi-rkl-11600:   [PASS][16] -> [SKIP][17] ([i915#1845])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][18] ([i915#1993]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20958/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][20] ([i915#3921]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pa

[Intel-gfx] [PATCH v5 07/25] Revert "drm/i915/gt: Propagate change in error status to children on unhold"

[Daniele Ceraolo Spurio]

From: Matthew Brost 

Propagating errors to dependent fences is broken and can lead to errors
from one client ending up in another. In commit 3761baae908a ("Revert
"drm/i915: Propagate errors on awaiting already signaled fences""), we
attempted to get rid of fence error propagation but missed the case
added in commit 8e9f84cf5cac ("drm/i915/gt: Propagate change in error
status to children on unhold"). Revert that one too. This error was
found by an up-and-coming selftest which triggers a reset during
request cancellation and verifies that subsequent requests complete
successfully.

v2:
 (Daniel Vetter)
  - Use revert
v3:
 (Jason)
  - Update commit message

v4 (Daniele):
 - fix checkpatch error in commit message.

References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting 
already signaled fences"")'
Signed-off-by: Matthew Brost 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index de5f9c86b9a4..cafb0608ffb4 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2140,10 +2140,6 @@ static void __execlists_unhold(struct i915_request *rq)
if (p->flags & I915_DEPENDENCY_WEAK)
continue;
 
-   /* Propagate any change in error status */
-   if (rq->fence.error)
-   i915_request_set_error_once(w, rq->fence.error);
-
if (w->engine != rq->engine)
continue;
 
-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/display: Some code improvements and code style fixes for DRRS

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm/i915/display: Some code improvements 
and code style fixes for DRRS
URL   : https://patchwork.freedesktop.org/series/94342/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20957


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-rkl-11600:   [PASS][2] -> [SKIP][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@fbdev@write:
- fi-rkl-11600:   [PASS][7] -> [SKIP][8] ([i915#2582]) +4 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@fb...@write.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@fb...@write.html

  * igt@i915_pm_rpm@basic-rte:
- fi-rkl-11600:   [PASS][9] -> [SKIP][10] ([fdo#109308]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@i915_pm_...@basic-rte.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-7500u:   [PASS][11] -> [INCOMPLETE][12] ([i915#151])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-kbl-7500u/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   [PASS][13] -> [SKIP][14] ([fdo#111825]) +7 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3669]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-rkl-11600:   [PASS][16] -> [SKIP][17] ([i915#3180])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-rkl-11600:   [PASS][18] -> [SKIP][19] ([i915#3919]) +9 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20957/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@prime_vgem@basic-fence-flip:
- fi-rkl-11600:   [PASS][20] -> [SKIP][21] ([i915#1845])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@pr

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_s: Remove require_force_probe protection

[Patchwork]

== Series Details ==

Series: drm/i915/adl_s: Remove require_force_probe protection
URL   : https://patchwork.freedesktop.org/series/94338/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550_full -> Patchwork_20955_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb6/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][2] ([i915#1839])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-iclb3/igt@feature_discov...@display-2x.html

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

  * igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-hostile.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb8/igt@gem_...@unwedge-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb6/igt@gem_...@unwedge-stress.html

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb:  NOTRUN -> [SKIP][17] ([fdo#109271]) +328 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb7/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-iclb3/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-apl7/igt@gem_pr...@exhaustion.html
- shard-skl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-skl10/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][21] ([i915#2658]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-kbl7/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#768])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-iclb3/igt@gem_render_c...@yf-tiled-to-vebox-x-tiled.html

  * igt@gem_softpin@evict-snoop:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109312])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-t

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support

[Souza, Jose]

On Thu, 2021-09-02 at 21:42 +0300, Gwan-gyeong Mun wrote:
> 
> On 8/25/21 3:58 AM, José Roberto de Souza wrote:
> > By now all the userspace applications should have migrated to atomic
> > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > 
> > With that we can kill frontbuffer rendering support in i915 for
> > modern platforms.
> > 
> > So here converting legacy APIs into atomic commits so it can be
> > properly handled by driver i915.
> > 
> > Several IGT tests will fail with this changes, because some tests
> > were stressing those frontbuffer rendering scenarios that no userspace
> > should be using by now, fixes to IGT should be sent soon.
> > 
> > v2:
> > - return earlier to not set fb_tracking.busy/flip_bits
> > - added a warn on to make sure we are not setting the busy/flip_bits
> > 
> > Cc: Daniel Vetter 
> > Cc: Gwan-gyeong Mun 
> > Cc: Ville Syrjälä 
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >   drivers/gpu/drm/i915/display/intel_cursor.c|  6 ++
> >   drivers/gpu/drm/i915/display/intel_fb.c|  8 +++-
> >   .../gpu/drm/i915/display/intel_frontbuffer.c   | 18 ++
> >   drivers/gpu/drm/i915/i915_drv.h|  2 ++
> >   4 files changed, 29 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index c7618fef01439..5aa996c3b7980 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> >u32 src_w, u32 src_h,
> >struct drm_modeset_acquire_ctx *ctx)
> >   {
> > +   struct drm_i915_private *i915 = to_i915(_crtc->dev);
> > struct intel_plane *plane = to_intel_plane(_plane);
> > struct intel_crtc *crtc = to_intel_crtc(_crtc);
> > struct intel_plane_state *old_plane_state =
> > @@ -633,12 +634,9 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> >  * PSR2 selective fetch also requires the slow path as
> >  * PSR2 plane and transcoder registers can only be updated during
> >  * vblank.
> > -*
> > -* FIXME bigjoiner fastpath would be good
> >  */
> > if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
> > -   crtc_state->update_pipe || crtc_state->bigjoiner ||
> > -   crtc_state->enable_psr2_sel_fetch)
> > +   crtc_state->update_pipe || !HAS_FRONTBUFFER_RENDERING(i915))
> > goto slow;
> >   
> > /*
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index e4b8602ec0cd2..3eb60785c9f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -3,6 +3,7 @@
> >* Copyright © 2021 Intel Corporation
> >*/
> >   
> > +#include 
> >   #include 
> >   #include 
> >   
> > @@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct 
> > drm_framebuffer *fb,
> > unsigned int num_clips)
> >   {
> > struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > +   struct drm_i915_private *i915 = to_i915(obj->base.dev);
> >   
> > i915_gem_object_flush_if_display(obj);
> > -   intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
> >   
> > +   if (!HAS_FRONTBUFFER_RENDERING(i915))
> > +   return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
> > +num_clips);
> Hi,
> Even if the userspace informs us of the dirty (damage) region of the 
> front buffer being used, GEN9 to GEN12 still uses the HW Tracking 
> function for PSR and FBC.
> And if you look at the description of the intel_psr_flush() function, 
> you can see that there are the following restrictions.
> 
> "Since the hardware frontbuffer tracking has gaps we need to integrate 
> with the software frontbuffer tracking."
> 
> If this restriction is still valid from GEN9 to GEN12, even if the 
> existing frontbuffer tracking function is not used, when 
> intel_user_framebuffer_dirty() is called, in the case of PSR, 
> psr_force_hw_tracking_exit() is called or intel_psr_exit() and 
> schedule_work(psr.work) seems to be required.

As this will trigger calls to the functions that write the plane registers PSR 
HW tracking and FBC tracking will understand a page flip happened even
if going from and to the same surface.

But will double check it.

> 
> In the case of FBC, it seems that calls to FBC deactive / FBC activate 
> should be added.
> 
> If GEN9 to GEN12 do not have the above restrictions, please ignore this 
> comment.
> 
> G.G.
> > +
> > +   intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
> > return 0;
> >   }
> >   
> > diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
> > b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> 

[Intel-gfx] [PATCH v3 2/3] drm/i915/display: Share code between intel_drrs_flush and intel_drrs_invalidate

[José Roberto de Souza]

Both functions are pretty much equal, with minor changes that can be
handled by a single parameter.

v3:
- not scheduling work from invalidate operations

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_drrs.c | 82 +--
 1 file changed, 32 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index fa0411341a0da..15e5f91cf331d 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -299,18 +299,9 @@ static void intel_drrs_downclock_work(struct work_struct 
*work)
mutex_unlock(&dev_priv->drrs.mutex);
 }
 
-/**
- * intel_drrs_invalidate - Disable Idleness DRRS
- * @dev_priv: i915 device
- * @frontbuffer_bits: frontbuffer plane tracking bits
- *
- * This function gets called everytime rendering on the given planes start.
- * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
- *
- * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
- */
-void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
-  unsigned int frontbuffer_bits)
+static void intel_drrs_frontbuffer_update(struct drm_i915_private *dev_priv,
+ unsigned int frontbuffer_bits,
+ bool invalidate)
 {
struct intel_dp *intel_dp;
struct drm_crtc *crtc;
@@ -333,16 +324,42 @@ void intel_drrs_invalidate(struct drm_i915_private 
*dev_priv,
pipe = to_intel_crtc(crtc)->pipe;
 
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
-   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
+   if (invalidate)
+   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
+   else
+   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
 
-   /* invalidate means busy screen hence upclock */
+   /* flush/invalidate means busy screen hence upclock */
if (frontbuffer_bits)
intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
 DRRS_HIGH_RR);
 
+   /*
+* flush also means no more activity hence schedule downclock, if all
+* other fbs are quiescent too
+*/
+   if (!invalidate && !dev_priv->drrs.busy_frontbuffer_bits)
+   schedule_delayed_work(&dev_priv->drrs.work,
+ msecs_to_jiffies(1000));
mutex_unlock(&dev_priv->drrs.mutex);
 }
 
+/**
+ * intel_drrs_invalidate - Disable Idleness DRRS
+ * @dev_priv: i915 device
+ * @frontbuffer_bits: frontbuffer plane tracking bits
+ *
+ * This function gets called everytime rendering on the given planes start.
+ * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
+ *
+ * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
+ */
+void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
+  unsigned int frontbuffer_bits)
+{
+   intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, true);
+}
+
 /**
  * intel_drrs_flush - Restart Idleness DRRS
  * @dev_priv: i915 device
@@ -358,42 +375,7 @@ void intel_drrs_invalidate(struct drm_i915_private 
*dev_priv,
 void intel_drrs_flush(struct drm_i915_private *dev_priv,
  unsigned int frontbuffer_bits)
 {
-   struct intel_dp *intel_dp;
-   struct drm_crtc *crtc;
-   enum pipe pipe;
-
-   if (dev_priv->drrs.type == DRRS_NOT_SUPPORTED)
-   return;
-
-   cancel_delayed_work(&dev_priv->drrs.work);
-
-   mutex_lock(&dev_priv->drrs.mutex);
-
-   intel_dp = dev_priv->drrs.dp;
-   if (!intel_dp) {
-   mutex_unlock(&dev_priv->drrs.mutex);
-   return;
-   }
-
-   crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
-   pipe = to_intel_crtc(crtc)->pipe;
-
-   frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
-   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
-
-   /* flush means busy screen hence upclock */
-   if (frontbuffer_bits)
-   intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
-DRRS_HIGH_RR);
-
-   /*
-* flush also means no more activity hence schedule downclock, if all
-* other fbs are quiescent too
-*/
-   if (!dev_priv->drrs.busy_frontbuffer_bits)
-   schedule_delayed_work(&dev_priv->drrs.work,
- msecs_to_jiffies(1000));
-   mutex_unlock(&dev_priv->drrs.mutex);
+   intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, false);
 }
 
 /**
-- 
2.33.0

[Intel-gfx] [PATCH v3 3/3] drm/i915/display: Prepare DRRS for frontbuffer rendering drop

[José Roberto de Souza]

Frontbuffer rendering will be dropped for modern platforms but
before that we to prepare DRRS for it.

intel_drrs_flush and intel_drrs_invalidate will not be called
for platforms that will not support frontbuffer rendering so DRRS
needs another way to be notified about to page flips so it can change
between high and low refresh rates as needed.

Reviewed-by: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 ++
 drivers/gpu/drm/i915/display/intel_drrs.c| 9 +
 drivers/gpu/drm/i915/display/intel_drrs.h| 4 
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 1f447ba776c79..134c792e1dbda 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -52,6 +52,7 @@
 #include "display/intel_dp_mst.h"
 #include "display/intel_dpll.h"
 #include "display/intel_dpll_mgr.h"
+#include "display/intel_drrs.h"
 #include "display/intel_dsi.h"
 #include "display/intel_dvo.h"
 #include "display/intel_fb.h"
@@ -2379,6 +2380,7 @@ static void intel_post_plane_update(struct 
intel_atomic_state *state,
hsw_enable_ips(new_crtc_state);
 
intel_fbc_post_update(state, crtc);
+   intel_drrs_page_flip(state, crtc);
 
if (needs_nv12_wa(old_crtc_state) &&
!needs_nv12_wa(new_crtc_state))
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 15e5f91cf331d..c1439fcb5a959 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -378,6 +378,15 @@ void intel_drrs_flush(struct drm_i915_private *dev_priv,
intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, false);
 }
 
+void intel_drrs_page_flip(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   unsigned int frontbuffer_bits = INTEL_FRONTBUFFER_ALL_MASK(crtc->pipe);
+
+   intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, false);
+}
+
 /**
  * intel_drrs_init - Init basic DRRS work and mutex.
  * @connector: eDP connector
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.h 
b/drivers/gpu/drm/i915/display/intel_drrs.h
index 73be7e9a43691..9ec9c447211af 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.h
+++ b/drivers/gpu/drm/i915/display/intel_drrs.h
@@ -9,6 +9,8 @@
 #include 
 
 struct drm_i915_private;
+struct intel_atomic_state;
+struct intel_crtc;
 struct intel_crtc_state;
 struct intel_connector;
 struct intel_dp;
@@ -23,6 +25,8 @@ void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
   unsigned int frontbuffer_bits);
 void intel_drrs_flush(struct drm_i915_private *dev_priv,
  unsigned int frontbuffer_bits);
+void intel_drrs_page_flip(struct intel_atomic_state *state,
+ struct intel_crtc *crtc);
 void intel_drrs_compute_config(struct intel_dp *intel_dp,
   struct intel_crtc_state *pipe_config,
   int output_bpp, bool constant_n);
-- 
2.33.0

[Intel-gfx] [PATCH v3 1/3] drm/i915/display: Some code improvements and code style fixes for DRRS

[José Roberto de Souza]

It started as a code style fix for the lines above 100 col but it
turned out to simplifications to intel_drrs_set_state().
Now it receives the desired refresh rate type, high or low.

v3:
- Fixed the mode refesh rate debug message

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_drrs.c | 58 ---
 1 file changed, 20 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index a2b65eca14418..fa0411341a0da 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -89,19 +89,13 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
 
 static void intel_drrs_set_state(struct drm_i915_private *dev_priv,
 const struct intel_crtc_state *crtc_state,
-int refresh_rate)
+enum drrs_refresh_rate_type refresh_type)
 {
struct intel_dp *intel_dp = dev_priv->drrs.dp;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   enum drrs_refresh_rate_type index = DRRS_HIGH_RR;
+   struct drm_display_mode *mode;
 
-   if (refresh_rate <= 0) {
-   drm_dbg_kms(&dev_priv->drm,
-   "Refresh rate should be positive non-zero.\n");
-   return;
-   }
-
-   if (intel_dp == NULL) {
+   if (!intel_dp) {
drm_dbg_kms(&dev_priv->drm, "DRRS not supported.\n");
return;
}
@@ -117,15 +111,8 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
return;
}
 
-   if 
(drm_mode_vrefresh(intel_dp->attached_connector->panel.downclock_mode) ==
-   refresh_rate)
-   index = DRRS_LOW_RR;
-
-   if (index == dev_priv->drrs.refresh_rate_type) {
-   drm_dbg_kms(&dev_priv->drm,
-   "DRRS requested for previously set 
RR...ignoring\n");
+   if (refresh_type == dev_priv->drrs.refresh_rate_type)
return;
-   }
 
if (!crtc_state->hw.active) {
drm_dbg_kms(&dev_priv->drm,
@@ -134,7 +121,7 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
}
 
if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv)) {
-   switch (index) {
+   switch (refresh_type) {
case DRRS_HIGH_RR:
intel_dp_set_m_n(crtc_state, M1_N1);
break;
@@ -151,7 +138,7 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
u32 val;
 
val = intel_de_read(dev_priv, reg);
-   if (index > DRRS_HIGH_RR) {
+   if (refresh_type == DRRS_LOW_RR) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
else
@@ -165,10 +152,14 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
intel_de_write(dev_priv, reg, val);
}
 
-   dev_priv->drrs.refresh_rate_type = index;
+   dev_priv->drrs.refresh_rate_type = refresh_type;
 
+   if (refresh_type == DRRS_LOW_RR)
+   mode = intel_dp->attached_connector->panel.downclock_mode;
+   else
+   mode = intel_dp->attached_connector->panel.fixed_mode;
drm_dbg_kms(&dev_priv->drm, "eDP Refresh Rate set to : %dHz\n",
-   refresh_rate);
+   drm_mode_vrefresh(mode));
 }
 
 static void
@@ -216,13 +207,7 @@ intel_drrs_disable_locked(struct intel_dp *intel_dp,
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
-   if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR) {
-   int refresh;
-
-   refresh = 
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode);
-   intel_drrs_set_state(dev_priv, crtc_state, refresh);
-   }
-
+   intel_drrs_set_state(dev_priv, crtc_state, DRRS_HIGH_RR);
dev_priv->drrs.dp = NULL;
 }
 
@@ -290,6 +275,7 @@ static void intel_drrs_downclock_work(struct work_struct 
*work)
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), drrs.work.work);
struct intel_dp *intel_dp;
+   struct drm_crtc *crtc;
 
mutex_lock(&dev_priv->drrs.mutex);
 
@@ -306,12 +292,8 @@ static void intel_drrs_downclock_work(struct work_struct 
*work)
if (dev_priv->drrs.busy_frontbuffer_bits)
goto unlock;
 
-   if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR) {
-   struct drm_crtc *crtc = 
dp_to_dig_port(intel_dp)->base.base.crtc;
-
-   intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
-
drm_mode_vrefresh(intel_dp->attached_connector->panel

Re: [Intel-gfx] [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug

[jim . cromie]

On Fri, Sep 3, 2021 at 5:15 AM Tvrtko Ursulin
 wrote:
>
>
> On 31/08/2021 21:21, Jim Cromie wrote:
> > drm's debug system writes 10 distinct categories of messages to syslog
> > using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
> > DRM_DEBUG*(8 names).  There are thousands of these callsites, each
> > categorized in this systematized way.
> >
> > These callsites can be enabled at runtime by their category, each
> > controlled by a bit in drm.debug (/sys/modules/drm/parameter/debug).
> > In the current "basic" implementation, drm_debug_enabled() tests these
> > bits in __drm_debug each time an API[1] call is executed; while cheap
> > individually, the costs accumulate with uptime.
> >
> > This patch uses dynamic-debug with jump-label to patch enabled calls
> > onto their respective NOOP slots, avoiding all runtime bit-checks of
> > __drm_debug by drm_debug_enabled().
> >
> > Dynamic debug has no concept of category, but we can emulate one by
> > replacing enum categories with a set of prefix-strings; "drm:core:",
> > "drm:kms:" "drm:driver:" etc, and prepend them (at compile time) to
> > the given formats.
> >
> > Then we can use:
> >`echo module drm format "^drm:core: " +p > control`
> >
> > to enable the whole category with one query.
>
> Probably stupid question - enabling stuff at boot time still works as
> described in Documentation/admin-guide/dynamic-debug-howto.rst?
>

yes.  its turned on in earlyinit, and cmdline args are a processed then,
and when modules are added


> Second question, which perhaps has been covered in the past so apologies
> if redundant - what is the advantage of allowing this to be
> configurable, versus perhaps always enabling it? Like what would be the
> reasons someone wouldn't just want to have CONFIG_DYNAMIC_DEBUG compiled
> in? Kernel binary size?
>

Im unaware of anything on this topic, but I can opine :-)
Its been configurable since I saw it and thought "jump-labels are cool!"

code is small
[jimc@frodo local-i915m]$ size lib/dynamic_debug.o
   textdata bss dec hex filename
  240168041  64   321217d79 lib/dynamic_debug.o

Its data tables are big, particularly the __dyndbg section
builtins:
dyndbg: 108 debug prints in module mptcp
dyndbg:   2 debug prints in module i386
dyndbg:   2 debug prints in module xen
dyndbg:   2 debug prints in module fixup
dyndbg:   7 debug prints in module irq
dyndbg: 3039 prdebugs in 283 modules, 11 KiB in ddebug tables, 166 kiB
in __dyndbg section

bash-5.1#
bash-5.1# for m in i915 amdgpu ; do modprobe $m dyndbg=+_ ; done
dyndbg: 384 debug prints in module drm
dyndbg: 211 debug prints in module drm_kms_helper
dyndbg:   2 debug prints in module ttm
dyndbg:   8 debug prints in module video
dyndbg: 1727 debug prints in module i915
dyndbg: processed 1 queries, with 3852 matches, 0 errs
dyndbg: 3852 debug prints in module amdgpu
[drm] amdgpu kernel modesetting enabled.
amdgpu: CRAT table disabled by module option
amdgpu: Virtual CRAT table created for CPU
amdgpu: Topology: Add CPU node
bash-5.1#

At 56 bytes / callsite, it adds up.
And teaching DRM to use it enlarges its use dramatically,
not just in drm itself, but in many drivers

amdgpu has 3852 callsite, (vs 3039 in my kernel), so it has ~240kb.
It has extra (large chunks generated by macros) to trim,
but i915 has ~1700, and drm has ~380

I have WIP to reduce the table space, by splitting it into 2 separate ones;
guts and decorations (module, function, file pointers).
The decoration recs are redundant, 45% are copies of previous
(function changes fastest)
It needs much rework, but it should get 20% overall.
decorations are 24/56 of footprint.








> Regards,
>
> Tvrtko
>
> >
> > This conversion yields many new prdbg callsites:
> >
> >dyndbg: 195 debug prints in module drm_kms_helper
> >dyndbg: 298 debug prints in module drm
> >dyndbg: 1630 debug prints in module i915
> >dyndbg: ~3500 debug prints in module amdgpu
> >
> > CONFIG_DRM_USE_DYNAMIC_DEBUG enables this, and is available if
> > CONFIG_DYNAMIC_DEBUG or CONFIG_DYNAMIC_DEBUG_CORE is chosen, and if
> > CONFIG_JUMP_LABEL is enabled; this because its required to get the
> > promised optimizations.
> >
> > The "basic" -> "dyndbg" switchover is layered into the macro scheme
> >
> > A. A "prefix" version of DRM_UT_ map, named DRM_DBG_CAT_
> >
> > "basic":  DRM_DBG_CAT_  <===  DRM_UT_.  Identity map.
> > "dyndbg":
> > #define DRM_DBG_CAT_KMS"drm:kms: "
> > #define DRM_DBG_CAT_PRIME  "drm:prime: "
> > #define DRM_DBG_CAT_ATOMIC "drm:atomic: "
> >
> > In v3, had older name, DRM_DBG_CLASS_ was countered, I had
> > agreed, but this seems better still; CATEGORY is already DRM's
> > term-of-art, and adding a near-synonym 'CLASS' only adds ambiguity.
> >
> > DRM_UT_* are preserved, since theyre used elsewhere.  We can probably
> > reduce their use further, but thats a separate thing.
> >
> > B. drm_dev_dbg() & drm_debug() are interposed with macros
> >
> > basic:  

Re: [Intel-gfx] [PATCH v2 5/8] drm/i915/display: Share code between intel_drrs_flush and intel_drrs_invalidate

[Souza, Jose]

On Thu, 2021-09-02 at 18:57 +0300, Gwan-gyeong Mun wrote:
> 
> On 8/25/21 3:58 AM, José Roberto de Souza wrote:
> > Both functions are pretty much equal, with minor changes that can be
> > handled by a single parameter.
> > 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >   drivers/gpu/drm/i915/display/intel_drrs.c | 82 +--
> >   1 file changed, 32 insertions(+), 50 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
> > b/drivers/gpu/drm/i915/display/intel_drrs.c
> > index 5eb5033242575..8583da4e82434 100644
> > --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> > @@ -312,18 +312,9 @@ static void intel_drrs_downclock_work(struct 
> > work_struct *work)
> > mutex_unlock(&dev_priv->drrs.mutex);
> >   }
> >   
> > -/**
> > - * intel_drrs_invalidate - Disable Idleness DRRS
> > - * @dev_priv: i915 device
> > - * @frontbuffer_bits: frontbuffer plane tracking bits
> > - *
> > - * This function gets called everytime rendering on the given planes start.
> > - * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
> > - *
> > - * Dirty frontbuffers relevant to DRRS are tracked in 
> > busy_frontbuffer_bits.
> > - */
> > -void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
> > -  unsigned int frontbuffer_bits)
> > +static void intel_drrs_frontbuffer_update(struct drm_i915_private 
> > *dev_priv,
> > + unsigned int frontbuffer_bits,
> > + bool invalidate)
> >   {
> > struct intel_dp *intel_dp;
> > struct drm_crtc *crtc;
> > @@ -346,16 +337,42 @@ void intel_drrs_invalidate(struct drm_i915_private 
> > *dev_priv,
> > pipe = to_intel_crtc(crtc)->pipe;
> >   
> > frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> > -   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
> > +   if (invalidate)
> > +   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
> > +   else
> > +   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
> >   
> > -   /* invalidate means busy screen hence upclock */
> > +   /* flush/invalidate means busy screen hence upclock */
> > if (frontbuffer_bits)
> > intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
> >  DRRS_HIGH_RR);
> >   
> > +   /*
> > +* flush also means no more activity hence schedule downclock, if all
> > +* other fbs are quiescent too
> > +*/
> > +   if (!dev_priv->drrs.busy_frontbuffer_bits)
> > +   schedule_delayed_work(&dev_priv->drrs.work,
> > + msecs_to_jiffies(1000));
> This line of code was previously only used in the intel_drrs_flush() 
> function,
> In the case of the intel_drrs_invalidate() call scenario, it is not 
> confirmed whether dev_priv->drrs.busy_frontbuffer_bits is always true to 
> me. If it's not always true, it looks like you also need to check for 
> "not invalidate".
> Please ignore this comment if I'm wrong.

Huum yeah if there is a invalidate in another pipe that could delay the work to 
be executed or execute it without needing it.

Will change it to: if (!invalidate && !dev_priv->drrs.busy_frontbuffer_bit) It 
should handle this cases above.

Thanks for the catch again.

> 
> > mutex_unlock(&dev_priv->drrs.mutex);
> >   }
> >   
> > +/**
> > + * intel_drrs_invalidate - Disable Idleness DRRS
> > + * @dev_priv: i915 device
> > + * @frontbuffer_bits: frontbuffer plane tracking bits
> > + *
> > + * This function gets called everytime rendering on the given planes start.
> > + * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
> > + *
> > + * Dirty frontbuffers relevant to DRRS are tracked in 
> > busy_frontbuffer_bits.
> > + */
> > +void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
> > +  unsigned int frontbuffer_bits)
> > +{
> > +   intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, true);
> > +}
> > +
> >   /**
> >* intel_drrs_flush - Restart Idleness DRRS
> >* @dev_priv: i915 device
> > @@ -371,42 +388,7 @@ void intel_drrs_invalidate(struct drm_i915_private 
> > *dev_priv,
> >   void intel_drrs_flush(struct drm_i915_private *dev_priv,
> >   unsigned int frontbuffer_bits)
> >   {
> > -   struct intel_dp *intel_dp;
> > -   struct drm_crtc *crtc;
> > -   enum pipe pipe;
> > -
> > -   if (dev_priv->drrs.type == DRRS_NOT_SUPPORTED)
> > -   return;
> > -
> > -   cancel_delayed_work(&dev_priv->drrs.work);
> > -
> > -   mutex_lock(&dev_priv->drrs.mutex);
> > -
> > -   intel_dp = dev_priv->drrs.dp;
> > -   if (!intel_dp) {
> > -   mutex_unlock(&dev_priv->drrs.mutex);
> > -   return;
> > -   }
> > -
> > -   crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
> > -   pipe = to_intel_crtc(crtc)->pipe;
> > -
> > -   frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> > -   dev_priv->drrs.busy_f

[Intel-gfx] ✗ Fi.CI.BAT: failure for Clean up GuC CI failures, simplify locking, and kernel DOC (rev9)

[Patchwork]

== Series Details ==

Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev9)
URL   : https://patchwork.freedesktop.org/series/93704/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20956


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@kms_f...@basic-flip-vs-dpms.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-rkl-11600:   [PASS][2] -> [SKIP][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
New tests
-

  New tests have been introduced between CI_DRM_10550 and Patchwork_20956:

### New IGT tests (1) ###

  * igt@i915_selftest@live@guc:
- Statuses : 36 pass(s)
- Exec time: [0.40, 5.05] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@fbdev@write:
- fi-rkl-11600:   [PASS][5] -> [SKIP][6] ([i915#2582]) +4 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@fb...@write.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@fb...@write.html

  * igt@i915_pm_rpm@basic-rte:
- fi-rkl-11600:   [PASS][7] -> [SKIP][8] ([fdo#109308]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@i915_pm_...@basic-rte.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[PASS][9] -> [DMESG-FAIL][10] ([i915#2927] / 
[i915#3428])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   [PASS][11] -> [SKIP][12] ([fdo#111825]) +7 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#3669]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-rkl-11600:   [PASS][14] -> [SKIP][15] ([i915#3180])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-rkl-11600:   [PASS][16] -> [SKIP][17] ([i915#3919]) +9 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@prime_vgem@basic-fence-flip:
- fi-rkl-11600:   [PASS][18] -> [SKIP][19] ([i915#1845])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20956/fi-rkl-11600/igt@prime_v...@basic-fence-flip.html

  * igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][20] ([fdo#109271] / [i915#1436] / 
[

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gtt: add some flushing for the 64K GTT path

[Patchwork]

== Series Details ==

Series: drm/i915/gtt: add some flushing for the 64K GTT path
URL   : https://patchwork.freedesktop.org/series/94332/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550_full -> Patchwork_20954_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
- shard-iclb: [PASS][1] -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb4/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#1839])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-iclb8/igt@feature_discov...@display-2x.html

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

  * igt@gem_ctx_persistence@engines-hostile-preempt:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-snb7/igt@gem_ctx_persiste...@engines-hostile-preempt.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb8/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-tglb2/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb6/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-iclb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-kbl7/igt@gem_exec_f...@basic-deadline.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html

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

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-iclb8/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_mmap_gtt@big-copy-odd:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#1888] / [i915#307])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-skl1/igt@gem_mmap_...@big-copy-odd.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-skl4/igt@gem_mmap_...@big-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#307])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/shard-iclb7/

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/display: Some code improvements and code style fixes for DRRS

[Souza, Jose]

On Thu, 2021-09-02 at 18:15 +0300, Gwan-gyeong Mun wrote:
> 
> On 8/25/21 3:58 AM, José Roberto de Souza wrote:
> > It started as a code style fix for the lines above 100 col but it
> > turned out to simplifications to intel_drrs_set_state().
> > Now it receives the desired refresh rate type, high or low.
> > 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >   drivers/gpu/drm/i915/display/intel_drrs.c | 60 ---
> >   1 file changed, 21 insertions(+), 39 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
> > b/drivers/gpu/drm/i915/display/intel_drrs.c
> > index 1aa9793521158..5eb5033242575 100644
> > --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> > @@ -91,7 +91,7 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
> >* intel_drrs_set_state - program registers for RR switch to take effect
> >* @dev_priv: i915 device
> >* @crtc_state: a pointer to the active intel_crtc_state
> > - * @refresh_rate: RR to be programmed
> > + * @refresh_type: high or low refresh rate to be programmed
> >*
> >* This function gets called when refresh rate (RR) has to be changed from
> >* one frequency to another. Switches can be between high and low RR
> > @@ -102,19 +102,13 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
> >*/
> >   static void intel_drrs_set_state(struct drm_i915_private *dev_priv,
> >  const struct intel_crtc_state *crtc_state,
> > -int refresh_rate)
> > +enum drrs_refresh_rate_type refresh_type)
> >   {
> > struct intel_dp *intel_dp = dev_priv->drrs.dp;
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > -   enum drrs_refresh_rate_type index = DRRS_HIGH_RR;
> > +   struct drm_display_mode *mode;
> >   
> > -   if (refresh_rate <= 0) {
> > -   drm_dbg_kms(&dev_priv->drm,
> > -   "Refresh rate should be positive non-zero.\n");
> > -   return;
> > -   }
> > -
> > -   if (intel_dp == NULL) {
> > +   if (!intel_dp) {
> > drm_dbg_kms(&dev_priv->drm, "DRRS not supported.\n");
> > return;
> > }
> > @@ -130,15 +124,8 @@ static void intel_drrs_set_state(struct 
> > drm_i915_private *dev_priv,
> > return;
> > }
> >   
> > -   if 
> > (drm_mode_vrefresh(intel_dp->attached_connector->panel.downclock_mode) ==
> > -   refresh_rate)
> > -   index = DRRS_LOW_RR;
> > -
> > -   if (index == dev_priv->drrs.refresh_rate_type) {
> > -   drm_dbg_kms(&dev_priv->drm,
> > -   "DRRS requested for previously set 
> > RR...ignoring\n");
> > +   if (refresh_type == dev_priv->drrs.refresh_rate_type)
> > return;
> > -   }
> >   
> > if (!crtc_state->hw.active) {
> > drm_dbg_kms(&dev_priv->drm,
> > @@ -147,7 +134,7 @@ static void intel_drrs_set_state(struct 
> > drm_i915_private *dev_priv,
> > }
> >   
> > if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv)) {
> > -   switch (index) {
> > +   switch (refresh_type) {
> > case DRRS_HIGH_RR:
> > intel_dp_set_m_n(crtc_state, M1_N1);
> > break;
> > @@ -164,7 +151,7 @@ static void intel_drrs_set_state(struct 
> > drm_i915_private *dev_priv,
> > u32 val;
> >   
> > val = intel_de_read(dev_priv, reg);
> > -   if (index > DRRS_HIGH_RR) {
> > +   if (refresh_type == DRRS_LOW_RR) {
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
> > else
> > @@ -178,10 +165,14 @@ static void intel_drrs_set_state(struct 
> > drm_i915_private *dev_priv,
> > intel_de_write(dev_priv, reg, val);
> > }
> > 
> > -   dev_priv->drrs.refresh_rate_type = index;
> > +   dev_priv->drrs.refresh_rate_type = refresh_type;
> >   
> > +   if (refresh_type == DRRS_LOW_RR)
> > +   mode = intel_dp->attached_connector->panel.fixed_mode;
> > +   else
> > +   mode = intel_dp->attached_connector->panel.downclock_mode;
> For DRRS_LOW_RR refresh_type, panel.downclock_mode has to be used, and 
> for DRR_HIGH_RR, panel.fixed_mode has to be used.
> It should be modified as follows.
>   if (refresh_type == DRRS_LOW_RR)
>   mode = intel_dp->attached_connector->panel.downclock_mode;
>   else
>   mode = intel_dp->attached_connector->panel.fixed_mode;
> 
> Except for this, the rest of the code looks good to me.


Thanks for catching this, will fix it.

> 
> 
> > drm_dbg_kms(&dev_priv->drm, "eDP Refresh Rate set to : %dHz\n",
> > -   refresh_rate);
> > +   drm_mode_vrefresh(mode));
> >   }
> >   
> >   static void
> > @@ -229,13 +220,7 @@ intel_drrs_disable_locked(struct intel_dp *intel_dp,
> >   {
> > struct

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915/bios: remove vbt ddi_port_info caching

[Souza, Jose]

On Fri, 2021-09-03 at 14:04 +0300, Jani Nikula wrote:
> On Wed, 01 Sep 2021, Jani Nikula  wrote:
> > v2 of https://patchwork.freedesktop.org/series/93957/ with the CI issues
> > fixed (fingers crossed!).
> 
> José, I'd like to get an ack from you on this before applying. I know
> it's bound conflict with your in flight series. Thoughts?
> 

If you are okay in adding more data at the end of intel_bios_encoder_data we 
should be fine.
Information from other VBT blocks will need to be added to 
intel_bios_encoder_data.

It will badly conflict with series but any redundant byte saved is worthy.

> BR,
> Jani.
> 
> > 
> > BR,
> > Jani.
> > 
> > Jani Nikula (7):
> >   drm/i915/bios: use hdmi level shift directly from child data
> >   drm/i915/bios: use max tmds clock directly from child data
> >   drm/i915/bios: use dp max link rate directly from child data
> >   drm/i915/bios: use alternate aux channel directly from child data
> >   drm/i915/bios: move ddc pin mapping code next to ddc pin sanitize
> >   drm/i915/bios: use ddc pin directly from child data
> >   drm/i915/bios: get rid of vbt ddi_port_info
> > 
> >  drivers/gpu/drm/i915/display/intel_bios.c | 372 +++---
> >  drivers/gpu/drm/i915/i915_drv.h   |  18 +-
> >  2 files changed, 187 insertions(+), 203 deletions(-)
> 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev9)

[Patchwork]

== Series Details ==

Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev9)
URL   : https://patchwork.freedesktop.org/series/93704/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev9)

[Patchwork]

== Series Details ==

Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev9)
URL   : https://patchwork.freedesktop.org/series/93704/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6d1bb5d22544 drm/i915/guc: Fix blocked context accounting
6398818fa78a drm/i915/guc: Fix outstanding G2H accounting
ae3e89ed3612 drm/i915/guc: Unwind context requests in reverse order
11d540e486e2 drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
92ad0bd9b3d8 drm/i915/guc: Process all G2H message at once in work queue
a59bbb7b3cdc drm/i915/guc: Workaround reset G2H is received after schedule done 
G2H
9970134653d7 Revert "drm/i915/gt: Propagate change in error status to children 
on unhold"
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 3761baae908a ("Revert "drm/i915: 
Propagate errors on awaiting already signaled fences"")'
#8: 
errors from one client ending up in another.  In 3761baae908a (Revert

-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 8e9f84cf5cac ("drm/i915/gt: 
Propagate change in error status to children on unhold")'
#11: 
added in 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status

-:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#24: 
References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting 
already signaled fences"")'

total: 2 errors, 1 warnings, 0 checks, 10 lines checked
a6d892a7d614 drm/i915/guc: Kick tasklet after queuing a request
-:8: WARNING:TYPO_SPELLING: 'inteface' may be misspelled - perhaps 'interface'?
#8: 
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new 
inteface")
 


total: 0 errors, 1 warnings, 0 checks, 7 lines checked
15ba8d2ce3be drm/i915/guc: Don't enable scheduling on a banned context, guc_id 
invalid, not registered
94da8fb5cc3b drm/i915/guc: Copy whole golden context, set engine state size of 
subset
e69b4cd9f3ff drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
-:108: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#108: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 233 lines checked
20823e2bde52 drm/i915/guc: Take context ref when cancelling request
6931ae8d5e0e drm/i915/guc: Don't touch guc_state.sched_state without a lock
d08163d1ed9c drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
0986fcfd8f76 drm/i915: Allocate error capture in nowait context
f58b28354082 drm/i915/guc: Flush G2H work queue during reset
26610960d6be drm/i915/guc: Release submit fence from an irq_work
418ef38c9838 drm/i915/guc: Move guc_blocked fence to struct guc_state
c2e82cfc3fc3 drm/i915/guc: Rework and simplify locking
2bb8ddcd69d2 drm/i915/guc: Proper xarray usage for contexts_lookup
fad172840a74 drm/i915/guc: Drop pin count check trick between sched_disable and 
re-pin
4de5b9c32773 drm/i915/guc: Move GuC priority fields in context under guc_active
a726f9c8709b drm/i915/guc: Move fields protected by guc->contexts_lock into sub 
structure
dc0c36c784e7 drm/i915/guc: Drop guc_active move everything into guc_state
45b764f2d15f drm/i915/guc: Add GuC kernel doc

[Intel-gfx] [PATCH v5 25/25] drm/i915/guc: Add GuC kernel doc

[Daniele Ceraolo Spurio]

From: Matthew Brost 

Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.

v2:
 - Drop guc_active.lock DOC
v3:
 - Fixup a few kernel doc comments (Daniele)
v4 (Daniele):
 - Implement doc suggestions from John
 - Add kerneldoc for all members of the GuC structure and pull the file
   in i915.rst
v5 (Daniele):
 - Implement new doc suggestions from John

Signed-off-by: Matthew Brost 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: John Harrison 
---
 Documentation/gpu/i915.rst|   2 +
 drivers/gpu/drm/i915/gt/intel_context_types.h |  43 +---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  75 ++---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 100 ++
 drivers/gpu/drm/i915/i915_request.h   |  21 ++--
 5 files changed, 181 insertions(+), 60 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 101dde3eb1ea..311e10400708 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -495,6 +495,8 @@ GuC
 .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
:doc: GuC
 
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h
+
 GuC Firmware Layout
 ~~~
 
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 5285d660eacf..930569a1a01f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -156,40 +156,51 @@ struct intel_context {
u8 wa_bb_page; /* if set, page num reserved for context workarounds */
 
struct {
-   /** lock: protects everything in guc_state */
+   /** @lock: protects everything in guc_state */
spinlock_t lock;
/**
-* sched_state: scheduling state of this context using GuC
+* @sched_state: scheduling state of this context using GuC
 * submission
 */
u32 sched_state;
/*
-* fences: maintains of list of requests that have a submit
-* fence related to GuC submission
+* @fences: maintains a list of requests that are currently
+* being fenced until a GuC operation completes
 */
struct list_head fences;
-   /* GuC context blocked fence */
+   /**
+* @blocked: fence used to signal when the blocking of a
+* context's submissions is complete.
+*/
struct i915_sw_fence blocked;
-   /* GuC committed requests */
+   /** @number_committed_requests: number of committed requests */
int number_committed_requests;
-   /** requests: active requests on this context */
+   /** @requests: list of active requests on this context */
struct list_head requests;
-   /*
-* GuC priority management
-*/
+   /** @prio: the context's current guc priority */
u8 prio;
+   /**
+* @prio_count: a counter of the number requests in flight in
+* each priority bucket
+*/
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_state;
 
struct {
-   /* GuC LRC descriptor ID */
+   /**
+* @id: handle which is used to uniquely identify this context
+* with the GuC, protected by guc->contexts_lock
+*/
u16 id;
-
-   /* GuC LRC descriptor reference count */
+   /**
+* @ref: the number of references to the guc_id, when
+* transitioning in and out of zero protected by
+* guc->contexts_lock
+*/
atomic_t ref;
-
-   /*
-* GuC ID link - in list when unpinned but guc_id still valid 
in GuC
+   /**
+* @link: in guc->guc_id_list when the guc_id has no refs but is
+* still valid, protected by guc->contexts_lock
 */
struct list_head link;
} guc_id;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 2e27fe59786b..5dd174babf7a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -22,74 +22,121 @@
 
 struct __guc_ads_blob;
 
-/*
- * Top level structure of GuC. It handles firmware loading and manages client
- * pool. intel_guc owns a intel_guc_client to replace the legacy ExecList
- * submission.
+/**
+ * struct intel_guc - Top level structure of GuC.
+ *
+ * It handles firmware loading and manages client pool. intel_guc owns an
+ * i915_sched_engine for submission

Re: [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories

[jim . cromie]

On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
 wrote:
>
>
> On 31/08/2021 21:21, Jim Cromie wrote:
> > The gvt component of this driver has ~120 pr_debugs, in 9 categories
> > quite similar to those in DRM.  Following the interface model of
> > drm.debug, add a parameter to map bits to these categorizations.
> >
> > DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
> >   "dyndbg bitmap desc",
> >   { "gvt:cmd: ",  "command processing" },
> >   { "gvt:core: ", "core help" },
> >   { "gvt:dpy: ",  "display help" },
> >   { "gvt:el: ",   "help" },
> >   { "gvt:irq: ",  "help" },
> >   { "gvt:mm: ",   "help" },
> >   { "gvt:mmio: ", "help" },
> >   { "gvt:render: ", "help" },
> >   { "gvt:sched: " "help" });
> >

BTW, Ive dropped the help field, its already handled, dont need to clutter.


> > The actual patch has a few details different, cmd_help() macro emits
> > the initialization construct.
> >
> > if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added
> > cflags, by gvt/Makefile.
> >
> > Signed-off-by: Jim Cromie 
> > ---
> > v5:
> > . static decl of vector of bit->class descriptors - Emil.V
> > . relocate gvt-makefile chunk from elsewhere
> > v7:
> > . move ccflags addition up to i915/Makefile from i915/gvt
> > ---
> >   drivers/gpu/drm/i915/Makefile  |  4 
> >   drivers/gpu/drm/i915/i915_params.c | 35 ++
>
> Can this work if put under gvt/ or at least intel_gvt.h|c?
>

I thought it belonged here more, at least according to the name of the
config.var

CONFIG_DRM_USE_DYNAMIC_DEBUG.

I suppose its not a great name, its narrow purpose is to swap
drm-debug api to use dyndbg.   drm-evrything already "uses"
dyndbg if CONFIG_DYNAMIC_DEBUG=y, those gvt/pr_debugs in particular.

Theres also CONFIG_DYNAMIC_DEBUG_CORE=y,
which drm basically ignores currently.

So with the name CONFIG_DRM_USE_DYNAMIC_DEBUG
it seemed proper to arrange for that  to be true on DD-CORE=y builds,
by adding -DDYNAMIC_DEBUG_MODULE

Does that make some sense ?
How to best resolve the frictions ?
new CONFIG names ?

> >   2 files changed, 39 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 4f22cac1c49b..5a4e371a3ec2 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -30,6 +30,10 @@ CFLAGS_display/intel_fbdev.o = $(call 
> > cc-disable-warning, override-init)
> >
> >   subdir-ccflags-y += -I$(srctree)/$(src)
> >
> > +#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
> > +ccflags-y += -DDYNAMIC_DEBUG_MODULE
> > +#endif
>
> Ignores whether CONFIG_DRM_I915_GVT is enabled or not?
>

not intentionally.
I think theres 2 things youre noting:

1 - make frag into gvt/Makefile
I had it there earlier, not sure why I moved it up.
maybe some confusion on proper scope of the flag.


2 - move new declaration code in i915-param.c inside the gvt ifdef

Im good with that.
I'll probably copy the ifdef wrapper down rather than move the decl up.
ie:

#if __and(IS_ENABLED(CONFIG_DRM_I915_GVT),
  IS_ENABLED(CONFIG_DRM_USE_DYNAMIC_DEBUG))

unsigned long __gvt_debug;
EXPORT_SYMBOL(__gvt_debug);


> > +
> >   # Please keep these build lists sorted!
> >
> >   # core driver code
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index e07f4cfea63a..e645e149485e 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -265,3 +265,38 @@ void i915_params_free(struct i915_params *params)
> >   I915_PARAMS_FOR_EACH(FREE);
> >   #undef FREE
> >   }
> > +
> > +#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
> > +/* todo: needs DYNAMIC_DEBUG_MODULE in some cases */
> > +
> > +unsigned long __gvt_debug;
> > +EXPORT_SYMBOL(__gvt_debug);
> > +
> > +#define _help(key)   "\t\"" key "\"\t: help for " key "\n"
> > +
> > +#define I915_GVT_CATEGORIES(name) \
> > + " Enable debug output via /sys/module/i915/parameters/" #name   \
> > + ", where each bit enables a debug category.\n"  \
> > + _help("gvt:cmd:")   \
> > + _help("gvt:core:")  \
> > + _help("gvt:dpy:")   \
> > + _help("gvt:el:")\
> > + _help("gvt:irq:")   \
> > + _help("gvt:mm:")\
> > + _help("gvt:mmio:")  \
> > + _help("gvt:render:")\
> > + _help("gvt:sched:")
> > +
> > +DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
> > + I915_GVT_CATEGORIES(debug_gvt),
> > + _DD_cat_("gvt:cmd:"),
> > + _DD_cat_("gvt:core:"),
> > + _DD_cat_("

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_s: Remove require_force_probe protection

[Patchwork]

== Series Details ==

Series: drm/i915/adl_s: Remove require_force_probe protection
URL   : https://patchwork.freedesktop.org/series/94338/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20955


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][2] ([i915#1993]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][4] ([i915#3921]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [FAIL][6] ([i915#3449]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
  [i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


Participating hosts (45 -> 38)
--

  Missing(7): fi-rkl-11600 bat-adls-5 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10550 -> Patchwork_20955

  CI-20190529: 20190529
  CI_DRM_10550: 07f6ce3dba287a2aa8a62cdd3b7d46ea0676007f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20955: 61c59049f078c498c7aef94d7e2769c1e8aa5a08 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

61c59049f078 drm/i915/adl_s: Remove require_force_probe protection

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Mark GPU wedging on driver unregister unrecoverable (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Mark GPU wedging on driver unregister unrecoverable (rev2)
URL   : https://patchwork.freedesktop.org/series/94247/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10550_full -> Patchwork_20953_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
- shard-iclb: [PASS][1] -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb4/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#1839])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@feature_discov...@display-2x.html

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

  * igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hostile.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#3063])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb3/igt@gem_...@in-flight-contexts-10ms.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb8/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-tglb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2849])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][14] ([fdo#112283])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-apl6/igt@gem_pr...@exhaustion.html
- shard-skl:  NOTRUN -> [WARN][16] ([i915#2658])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-skl3/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][17] ([i915#2658]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-kbl3/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#768])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gem_render_c...@yf-tiled-to-vebox-x-tiled.html

  * igt@gem_softpin@evict-snoop:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gem_soft...@evict-snoop.html

  * igt@gem_workarounds@suspend-resume:
- shard-skl:  [PASS][20] -> [INCOMPLETE][21] ([i915#198])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-skl7/igt@gem_workarou...@suspend-resume.html
   [21]: 

[Intel-gfx] [PATCH] drm/i915/adl_s: Remove require_force_probe protection

[Talla Raviteja Goud]

From: ravitejax 

Removing force probe protection from ADLS platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.

For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html?

Cc: Lucas De Marchi 
Signed-off-by: ravitejax 
---
 drivers/gpu/drm/i915/i915_pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 03a820955458..d4a6a9dcf182 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -912,7 +912,6 @@ static const struct intel_device_info adl_s_info = {
GEN12_FEATURES,
PLATFORM(INTEL_ALDERLAKE_S),
.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
-   .require_force_probe = 1,
.display.has_hti = 1,
.display.has_psr_hw_tracking = 0,
.platform_engine_mask =
-- 
2.30.2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: add some flushing for the 64K GTT path

[Patchwork]

== Series Details ==

Series: drm/i915/gtt: add some flushing for the 64K GTT path
URL   : https://patchwork.freedesktop.org/series/94332/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20954


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-jsl-1}: [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-jsl-1/igt@i915_selftest@live@gt_heartbeat.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/fi-jsl-1/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4] ([i915#2940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#3958])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#1436] / 
[i915#3428])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/fi-bsw-nick/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][8] ([i915#1993]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [FAIL][10] ([i915#3449]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20954/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (45 -> 39)
--

  Missing(6): bat-adls-5 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-bdw-samus 
bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10550 -> Patchwork_20954

  CI-20190529: 20190529
  CI_DRM_10550: 07f6ce3dba287a2aa8a62cdd3b7d46ea0676007f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20954: 4325ead850834dd14f126f8d160d202bc9b18200 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

4325ead85083 drm/i915/gtt: add some flushing for the 64K GTT path

== Logs ==

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

[Imre Deak]

On Fri, Sep 03, 2021 at 06:39:14PM +0300, Imre Deak wrote:
> On Fri, Sep 03, 2021 at 06:03:30PM +0300, Ville Syrjälä wrote:
> > On Fri, Sep 03, 2021 at 02:10:17PM +0300, Jani Nikula wrote:
> > > On Mon, 22 Mar 2021, Ville Syrjälä  wrote:
> > > > On Fri, Mar 19, 2021 at 07:08:40PM -, Patchwork wrote:
> > > >> == Series Details ==
> > > >> 
> > > >> Series: drm/i915: Enable TPS3/4 on all platforms that support them
> > > >> URL   : https://patchwork.freedesktop.org/series/88186/
> > > >> State : success
> > > >> 
> > > >> == Summary ==
> > > >> 
> > > >> CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815
> > > >> 
> > > >> 
> > > >> Summary
> > > >> ---
> > > >> 
> > > >>   **SUCCESS**
> > > >
> > > > That's a bit odd considering the link training still fails with this.
> > > > Did we convert some erorrs to debugs perhaps, or maybe this never
> > > > got flagged as an error?
> > > >
> > > > <7>[8.235008] i915 :00:02.0: [drm:intel_dp_start_link_train 
> > > > [i915]] Using LINK_RATE_SET value 03
> > > > <7>[8.236203] i915 :00:02.0: [drm:intel_dp_set_signal_levels 
> > > > [i915]] Using vswing level 0, pre-emphasis level 0, at DPRX
> > > > <7>[8.236341] i915 :00:02.0: 
> > > > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI 
> > > > A/PHY A] Using DP training pattern TPS1
> > > > <7>[8.237373] i915 :00:02.0: [drm:intel_dp_link_train_phy 
> > > > [i915]] clock recovery OK
> > > > <7>[8.237460] i915 :00:02.0: 
> > > > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI 
> > > > A/PHY A] Using DP training pattern TPS4
> > > > <7>[8.239054] i915 :00:02.0: 
> > > > [drm:intel_dp_dump_link_status.isra.4 [i915]] ln0_1:0x0 ln2_3:0x0 
> > > > align:0x80 sink:0x0 adj_req0_1:0x0 adj_req2_3:0x0
> > > > <7>[8.239135] i915 :00:02.0: [drm:intel_dp_link_train_phy 
> > > > [i915]] Clock recovery check failed, cannot continue channel 
> > > > equalization
> > > > <7>[8.239218] i915 :00:02.0: [drm:intel_dp_link_train_phy 
> > > > [i915]] [CONNECTOR:308:eDP-1] Link Training failed at link rate = 
> > > > 27, lane count = 2, at DPRX
> > > >
> > > > So CR lock is lost as soon as we switch to TPS4. I really wonder if the 
> > > > sink
> > > > actually even implements TPS4, and maybe when we write TPS4 to the DPCD 
> > > > reg
> > > > it starts to expect some other pattern? Should be semi-easy to confirm
> > > > I guess...
> > > >
> > > > One thing I was pondering is whether we're detecting TPS4 vs. TPS3 
> > > > differently
> > > > that eg. Windows. Based on some trawling it looks to me that for some 
> > > > reason
> > > > Windows uses the EDP_DPCD_REV>=0x4 check rather than DPCD_REV>=0x14 on 
> > > > eDP
> > > > panels when checking for TPS4 suppport. Unfortunately following that
> > > > convention here wouldn't help us:
> > > >
> > > > <7>[6.835706] i915 :00:02.0: [drm:intel_dp_init_connector 
> > > > [i915]] eDP DPCD: 04 fb ff
> > > > <7>[8.234921] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: Base 
> > > > DPCD: 14 0a 82 41 00 00 01 c0 02 00 00 00 0f 09 80
> > > > <7>[8.234943] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 
> > > > 14 0a 82 c1 00 00 01 c0 02 00 00 00 0f 09 80
> > > 
> > > Should try this in combination with [1]?
> > > 
> > > BR,
> > > Jani.
> > > 
> > > 
> > > [1] 
> > > https://patchwork.freedesktop.org/patch/msgid/20210719235927.283173-1-khaled.almahall...@intel.com
> > 
> > Couldn't hurt I suppose. Although those bits should default to 0, unless
> > the BIOS/something mucks them up for whatever reason.
> 
> I tried the two patches (I assume the above failure was on shards-iclb2)
> and it still fails. The panel reports that it supports TPS4 while it
> doesn't support TPS3, which is a bit odd. I also tried if LT works with
> TPS3, but that also fails.
> 
> Still checking if this panel works on other hosts.

Tried it on the above and another ICL and TGL both on Linux and Windows,
link training fails. I assume this panel only supports TPS2, the DPCD/FW
(or the panel) is just buggy. I wonder if it's possible to reflash the
FW on it.

For now I replaced it on shards-iclb2 with another 4k panel with TPS4
support with that LT passes with the two patches applied.

--Imre

> This panel could be simply buggy (wrong FW on it?). I found two other panels 
> in
> CI with TPS4:
> CI_DRM_10549/fi-icl-u2/0/boot.log:<7> i915 :00:02.0: 
> [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 00 c4 c1 00 00 01 c0 
> 02 00 00 00 00 0b 00
> CI_DRM_10549/fi-tgl-y/0/boot.log:<7> i915 :00:02.0: 
> [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 00 c4 c1 00 00 01 c0 
> 02 00 00 00 00 0b 00
> 
> On fi-icl-u2 LT passes with TPS4, on fi-tgl-y only TPS3 is used (no HBR3
> support there).
> 
> We could either quirk this panel, or fall back to TPS2/3 if LT failed
> with TPS4.
> 
> The EDP_DPCD_REV>=0x4 check as a dependency for TP

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark GPU wedging on driver unregister unrecoverable (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Mark GPU wedging on driver unregister unrecoverable (rev2)
URL   : https://patchwork.freedesktop.org/series/94247/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20953


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][2] -> [INCOMPLETE][3] ([i915#2940])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_mocs:
- fi-tgl-1115g4:  [PASS][4] -> [DMESG-WARN][5] ([i915#2867]) +15 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html

  * igt@runner@aborted:
- fi-bsw-n3050:   NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#1436] / 
[i915#3428])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][7] ([i915#1993]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][9] ([i915#3921]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [FAIL][11] ([i915#3449]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][13] ([fdo#109271]) -> [FAIL][14] ([i915#3049])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3049]: https://gitlab.freedesktop.org/drm/intel/issues/3049
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


Participating hosts (45 -> 39)
--

  Missing(6): bat-adls-5 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-bdw-samus 
bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10550 -> Patchwork_20953

  CI-20190529: 20190529
  CI_DRM_10550: 07f6ce3dba287a2aa8a62cdd3b7d46ea0676007f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20953: df132f9480a64ce30fde22ca8fc4b3fe3490eaf6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

df132f9480a6 drm/i915: Mark GPU wedging on driver unregister unrecoverable

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Flush buffer pools on driver remove (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Flush buffer pools on driver remove (rev3)
URL   : https://patchwork.freedesktop.org/series/91177/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10549_full -> Patchwork_20952_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-3x:
- shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-tglb5/igt@feature_discov...@display-3x.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][2] ([i915#180])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-apl3/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html

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

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][6] -> [SKIP][7] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-apl2/igt@gem_exec_fair@basic-none-sh...@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_20952/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-root:
- shard-tglb: NOTRUN -> [SKIP][13] ([fdo#112283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-tglb5/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_exec_schedule@u-semaphore-user:
- shard-snb:  NOTRUN -> [SKIP][14] ([fdo#109271]) +146 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-snb2/igt@gem_exec_sched...@u-semaphore-user.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][15] -> [SKIP][16] ([i915#2190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-tglb8/igt@gem_huc_c...@huc-copy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][17] ([i915#2724])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-snb2/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][18] -> [DMESG-WARN][19] ([i915#1436] / 
[i915#716])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-skl7/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#1904])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-tglb5/igt@i915_pm...@dc3co-vpb-simulation.html

  * igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271]) +160 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-apl1/igt@i915_pm_...@modeset-lpsp-stress.html

  * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111644] / [i915#1397] / 
[i915#2411])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/shard-tglb5/igt@i915_pm_...@modeset-non-lpsp-stress-no-wait.html

  * igt@kms_big_fb@linear-16bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP]

Re: [Intel-gfx] [PATCH] drm/i915/gtt: add some flushing for the 64K GTT path

[Mika Kuoppala]

Matthew Auld  writes:

> If we need to mark the PDE as operating in 64K GTT mode, we should be
> paranoid and flush the extra writes, like we already do for the PTEs. On
> some platforms the clflush can apparently add the just the right amount
> of magical delay to force the GPU to see the updated entry.
>
> Signed-off-by: Matthew Auld 
> Cc: Mika Kuoppala 

Makes sense to follow the same pattern as the other writes.

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index 6e0e52eeb87a..6a5af995f5b1 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -548,6 +548,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma,
> I915_GTT_PAGE_SIZE_2M {
>   vaddr = px_vaddr(pd);
>   vaddr[maybe_64K] |= GEN8_PDE_IPS_64K;
> + clflush_cache_range(vaddr, PAGE_SIZE);
>   page_size = I915_GTT_PAGE_SIZE_64K;
>  
>   /*
> @@ -568,6 +569,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma,
>   for (i = 1; i < index; i += 16)
>   memset64(vaddr + i, encode, 15);
>  
> + clflush_cache_range(vaddr, PAGE_SIZE);
>   }
>   }
>  
> -- 
> 2.26.3

[Intel-gfx] [PATCH] drm/i915/gtt: add some flushing for the 64K GTT path

[Matthew Auld]

If we need to mark the PDE as operating in 64K GTT mode, we should be
paranoid and flush the extra writes, like we already do for the PTEs. On
some platforms the clflush can apparently add the just the right amount
of magical delay to force the GPU to see the updated entry.

Signed-off-by: Matthew Auld 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 6e0e52eeb87a..6a5af995f5b1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -548,6 +548,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma,
  I915_GTT_PAGE_SIZE_2M {
vaddr = px_vaddr(pd);
vaddr[maybe_64K] |= GEN8_PDE_IPS_64K;
+   clflush_cache_range(vaddr, PAGE_SIZE);
page_size = I915_GTT_PAGE_SIZE_64K;
 
/*
@@ -568,6 +569,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma,
for (i = 1; i < index; i += 16)
memset64(vaddr + i, encode, 15);
 
+   clflush_cache_range(vaddr, PAGE_SIZE);
}
}
 
-- 
2.26.3

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

[Imre Deak]

On Fri, Sep 03, 2021 at 06:03:30PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 03, 2021 at 02:10:17PM +0300, Jani Nikula wrote:
> > On Mon, 22 Mar 2021, Ville Syrjälä  wrote:
> > > On Fri, Mar 19, 2021 at 07:08:40PM -, Patchwork wrote:
> > >> == Series Details ==
> > >> 
> > >> Series: drm/i915: Enable TPS3/4 on all platforms that support them
> > >> URL   : https://patchwork.freedesktop.org/series/88186/
> > >> State : success
> > >> 
> > >> == Summary ==
> > >> 
> > >> CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815
> > >> 
> > >> 
> > >> Summary
> > >> ---
> > >> 
> > >>   **SUCCESS**
> > >
> > > That's a bit odd considering the link training still fails with this.
> > > Did we convert some erorrs to debugs perhaps, or maybe this never
> > > got flagged as an error?
> > >
> > > <7>[8.235008] i915 :00:02.0: [drm:intel_dp_start_link_train 
> > > [i915]] Using LINK_RATE_SET value 03
> > > <7>[8.236203] i915 :00:02.0: [drm:intel_dp_set_signal_levels 
> > > [i915]] Using vswing level 0, pre-emphasis level 0, at DPRX
> > > <7>[8.236341] i915 :00:02.0: 
> > > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI 
> > > A/PHY A] Using DP training pattern TPS1
> > > <7>[8.237373] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> > > clock recovery OK
> > > <7>[8.237460] i915 :00:02.0: 
> > > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI 
> > > A/PHY A] Using DP training pattern TPS4
> > > <7>[8.239054] i915 :00:02.0: 
> > > [drm:intel_dp_dump_link_status.isra.4 [i915]] ln0_1:0x0 ln2_3:0x0 
> > > align:0x80 sink:0x0 adj_req0_1:0x0 adj_req2_3:0x0
> > > <7>[8.239135] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> > > Clock recovery check failed, cannot continue channel equalization
> > > <7>[8.239218] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> > > [CONNECTOR:308:eDP-1] Link Training failed at link rate = 27, lane 
> > > count = 2, at DPRX
> > >
> > > So CR lock is lost as soon as we switch to TPS4. I really wonder if the 
> > > sink
> > > actually even implements TPS4, and maybe when we write TPS4 to the DPCD 
> > > reg
> > > it starts to expect some other pattern? Should be semi-easy to confirm
> > > I guess...
> > >
> > > One thing I was pondering is whether we're detecting TPS4 vs. TPS3 
> > > differently
> > > that eg. Windows. Based on some trawling it looks to me that for some 
> > > reason
> > > Windows uses the EDP_DPCD_REV>=0x4 check rather than DPCD_REV>=0x14 on eDP
> > > panels when checking for TPS4 suppport. Unfortunately following that
> > > convention here wouldn't help us:
> > >
> > > <7>[6.835706] i915 :00:02.0: [drm:intel_dp_init_connector [i915]] 
> > > eDP DPCD: 04 fb ff
> > > <7>[8.234921] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: Base 
> > > DPCD: 14 0a 82 41 00 00 01 c0 02 00 00 00 0f 09 80
> > > <7>[8.234943] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 
> > > 0a 82 c1 00 00 01 c0 02 00 00 00 0f 09 80
> > 
> > Should try this in combination with [1]?
> > 
> > BR,
> > Jani.
> > 
> > 
> > [1] 
> > https://patchwork.freedesktop.org/patch/msgid/20210719235927.283173-1-khaled.almahall...@intel.com
> 
> Couldn't hurt I suppose. Although those bits should default to 0, unless
> the BIOS/something mucks them up for whatever reason.

I tried the two patches (I assume the above failure was on shards-iclb2)
and it still fails. The panel reports that it supports TPS4 while it
doesn't support TPS3, which is a bit odd. I also tried if LT works with
TPS3, but that also fails.

Still checking if this panel works on other hosts.

This panel could be simply buggy (wrong FW on it?). I found two other panels in
CI with TPS4:
CI_DRM_10549/fi-icl-u2/0/boot.log:<7> i915 :00:02.0: 
[drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 00 c4 c1 00 00 01 c0 02 
00 00 00 00 0b 00
CI_DRM_10549/fi-tgl-y/0/boot.log:<7> i915 :00:02.0: 
[drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 00 c4 c1 00 00 01 c0 02 
00 00 00 00 0b 00

On fi-icl-u2 LT passes with TPS4, on fi-tgl-y only TPS3 is used (no HBR3
support there).

We could either quirk this panel, or fall back to TPS2/3 if LT failed
with TPS4.

The EDP_DPCD_REV>=0x4 check as a dependency for TPS4, seems to match the
eDP spec:

"""
Use of DPCD Rev. 1.4 extends the new DP v1.3 capabilities to eDP v1.4a
(and higher) devices, including features as HBR3 and TPS4.
Identification of an eDP v1.4a (and higher) Sink device is indicated by
a value of 04h (and higher) in the EDP_DPCD_REV register (DPCD Address
00700h).
"""

> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Ramalingam C]

Thanks Ayaz for the patches and all the review efforts. Merged the patches.

-Ram

On 2021-09-03 at 19:11:24 +0530, Kattamanchi, JaswanthX wrote:
> Hi Ayaz,
> 
> Re-reported
> 
> Patch : https://patchwork.freedesktop.org/series/94315/
> 
> Regards,
> Jaswanth Kattamanchi
> 
> -Original Message-
> From: Siddiqui, Ayaz A 
> Sent: Friday, September 3, 2021 6:29 PM
> To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 
> ; Illipilli, TejasreeX 
> ; Kattamanchi, JaswanthX 
> 
> Cc: Szwichtenberg, Radoslaw ; Meena, Mahesh 
> ; C, Ramalingam ; De Marchi, 
> Lucas ; Roper, Matthew D 
> Subject: RE: [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to 
> L3_WB
> 
> Hi,
>  I see a failure reported on IGT-CI for this series for SKL,
> 
>  igt@gem_ctx_isolation@preservation-s3@rcs0:
> shard-skl: PASS -> DMESG-WARN
> 
> Changes set in this series are applicable for gen12 onward platforms except 
> TGL/RKL.
> 
> So above failure look like a false alarm to me.
> 
> Regards
> -Ayaz
> 
> > -Original Message-
> > From: Siddiqui, Ayaz A 
> > Sent: Friday, September 3, 2021 2:52 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Siddiqui, Ayaz A 
> > Subject: [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to
> > L3_WB
> >
> > Gen >= 12 onwards MOCS table doesn't have a setting for PTE so
> > I915_MOCS_PTE is not a valid index and it will have different MOCS
> > values are based on the platform.
> >
> > To detect these kinds of misprogramming, all the unspecified and
> > reserved MOCS indexes are set to WB_L3. TGL/RKL unspecified MOCS
> > indexes are pointing to L3 UC are kept intact to avoid API break.
> >
> > This series also contains patches to program BLIT_CCTL and CMD_CCTL
> > registers to UC.
> > Since we are quite late to update MOCS table for TGL so added a new
> > MOCS table for ADL family.
> >
> > V2:
> >  1. Added CMD_CCTL to GUC regset list so that it can be restored
> > after engine reset.
> >  2. Checkpatch warning removal.
> >
> > V3:
> >  1. Changed implementation to have a framework only.
> >  2. Added register type for proper application.
> >  3. moved CMD_CCTL programming to a separate patch.
> >  4. Added L3CC initialization during gt reset so that MOCS indexes are
> > set before GuC initialization.
> >  5. Removed Renderer check for L3CC verification in selftest.
> >
> > V4:
> >  1. Moved register programming in Workaorund section as fake workaround.
> >  2. Removed seperate ADL mocs table, new logic is to set unused index as
> > L3_WB for gen12 platform except TGL/RKL.
> >
> > V5:
> >  1. Final version reviewed by Matt Roper  2. Removed "drm/i915/selftest:
> > Remove Renderer class check for l3cc table read" form series,
> > this patch will be taken care of in different series.
> >
> > Ayaz A Siddiqui (4):
> >   drm/i915/gt: Add support of mocs propagation
> >   drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward
> >   drm/i915/gt: Set BLIT_CCTL reg to un-cached
> >   drm/i915/gt: Initialize unused MOCS entries with device specific
> > values
> >
> > Sreedhar Telukuntla (1):
> >   drm/i915/gt: Initialize L3CC table in mocs init
> >
> >  drivers/gpu/drm/i915/gt/intel_gt.c  |  2 +
> >  drivers/gpu/drm/i915/gt/intel_gt_types.h|  4 ++
> >  drivers/gpu/drm/i915/gt/intel_mocs.c| 72 ++---
> >  drivers/gpu/drm/i915/gt/intel_mocs.h|  1 +
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 70
> > +++-
> >  drivers/gpu/drm/i915/i915_reg.h | 26 
> >  6 files changed, 151 insertions(+), 24 deletions(-)
> >
> > --
> > 2.26.2
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush buffer pools on driver remove (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Flush buffer pools on driver remove (rev3)
URL   : https://patchwork.freedesktop.org/series/91177/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10549 -> Patchwork_20952


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> [FAIL][3] ([i915#2426] / [i915#3363])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/fi-bxt-dsi/igt@run...@aborted.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [DMESG-WARN][4] ([i915#3925]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][6] ([i915#3921]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20952/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925


Participating hosts (46 -> 38)
--

  Missing(8): fi-kbl-soraka bat-adls-5 fi-hsw-4200u bat-dg1-5 fi-bsw-cyan 
bat-adlp-4 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10549 -> Patchwork_20952

  CI-20190529: 20190529
  CI_DRM_10549: cd8e346a0b56ce66f94a9908c7a068bbee8f1829 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20952: 45ef64e45e0c12ffb4cd6e201ea8e357b498e31d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

45ef64e45e0c drm/i915: Flush buffer pools on driver remove

== Logs ==

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

[Ville Syrjälä]

On Fri, Sep 03, 2021 at 02:10:17PM +0300, Jani Nikula wrote:
> On Mon, 22 Mar 2021, Ville Syrjälä  wrote:
> > On Fri, Mar 19, 2021 at 07:08:40PM -, Patchwork wrote:
> >> == Series Details ==
> >> 
> >> Series: drm/i915: Enable TPS3/4 on all platforms that support them
> >> URL   : https://patchwork.freedesktop.org/series/88186/
> >> State : success
> >> 
> >> == Summary ==
> >> 
> >> CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815
> >> 
> >> 
> >> Summary
> >> ---
> >> 
> >>   **SUCCESS**
> >
> > That's a bit odd considering the link training still fails with this.
> > Did we convert some erorrs to debugs perhaps, or maybe this never
> > got flagged as an error?
> >
> > <7>[8.235008] i915 :00:02.0: [drm:intel_dp_start_link_train [i915]] 
> > Using LINK_RATE_SET value 03
> > <7>[8.236203] i915 :00:02.0: [drm:intel_dp_set_signal_levels 
> > [i915]] Using vswing level 0, pre-emphasis level 0, at DPRX
> > <7>[8.236341] i915 :00:02.0: 
> > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY 
> > A] Using DP training pattern TPS1
> > <7>[8.237373] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> > clock recovery OK
> > <7>[8.237460] i915 :00:02.0: 
> > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY 
> > A] Using DP training pattern TPS4
> > <7>[8.239054] i915 :00:02.0: [drm:intel_dp_dump_link_status.isra.4 
> > [i915]] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x0 
> > adj_req2_3:0x0
> > <7>[8.239135] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> > Clock recovery check failed, cannot continue channel equalization
> > <7>[8.239218] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> > [CONNECTOR:308:eDP-1] Link Training failed at link rate = 27, lane 
> > count = 2, at DPRX
> >
> > So CR lock is lost as soon as we switch to TPS4. I really wonder if the sink
> > actually even implements TPS4, and maybe when we write TPS4 to the DPCD reg
> > it starts to expect some other pattern? Should be semi-easy to confirm
> > I guess...
> >
> > One thing I was pondering is whether we're detecting TPS4 vs. TPS3 
> > differently
> > that eg. Windows. Based on some trawling it looks to me that for some reason
> > Windows uses the EDP_DPCD_REV>=0x4 check rather than DPCD_REV>=0x14 on eDP
> > panels when checking for TPS4 suppport. Unfortunately following that
> > convention here wouldn't help us:
> >
> > <7>[6.835706] i915 :00:02.0: [drm:intel_dp_init_connector [i915]] 
> > eDP DPCD: 04 fb ff
> > <7>[8.234921] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: Base DPCD: 
> > 14 0a 82 41 00 00 01 c0 02 00 00 00 0f 09 80
> > <7>[8.234943] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 
> > 0a 82 c1 00 00 01 c0 02 00 00 00 0f 09 80
> 
> Should try this in combination with [1]?
> 
> BR,
> Jani.
> 
> 
> [1] 
> https://patchwork.freedesktop.org/patch/msgid/20210719235927.283173-1-khaled.almahall...@intel.com

Couldn't hurt I suppose. Although those bits should default to 0, unless
the BIOS/something mucks them up for whatever reason.

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH RESEND] drm/i915: Mark GPU wedging on driver unregister unrecoverable

[Janusz Krzysztofik]

GPU wedged flag now set on driver unregister to prevent from further
using the GPU can be then cleared unintentionally when calling
__intel_gt_unset_wedged() still before the flag is finally marked
unrecoverable.  We need to have it marked unrecoverable earlier.
Implement that by replacing a call to intel_gt_set_wedged() in
intel_gt_driver_unregister() with intel_gt_set_wedged_on_fini().

With the above in place, intel_gt_set_wedged_on_fini() is now called
twice on driver remove, second time from __intel_gt_disable().  This
seems harmless, while dropping intel_gt_set_wedged_on_fini() from
__intel_gt_disable() proved to break some driver probe error unwind
paths as well as mock selftest exit path.

Signed-off-by: Janusz Krzysztofik 
Cc: Michał Winiarski 
---
Resending with Cc: dri-de...@lists.freedesktop.org as requested.

Thanks,
Janusz

 drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 62d40c986642..173b53cb2b47 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -750,7 +750,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
 * all in-flight requests so that we can quickly unbind the active
 * resources.
 */
-   intel_gt_set_wedged(gt);
+   intel_gt_set_wedged_on_fini(gt);
 
/* Scrub all HW state upon release */
with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-- 
2.25.1

[Intel-gfx] [PATCH RESEND] drm/i915: Flush buffer pools on driver remove

[Janusz Krzysztofik]

In preparation for clean driver release, attempts to drain work queues
and release freed objects are taken at driver remove time.  However, GT
buffer pools are now not flushed before the driver release phase.
Since unused objects may stay there for up to one second, some may
survive until driver release is attempted.  That can potentially
explain sporadic then hardly reproducible issues observed at driver
release time, like non-zero shrink counter or outstanding address space
areas.

Flush buffer pools on GT remove as a fix.  On driver release, don't
flush the pools again, just assert that the flush was called and
nothing added more in between.

Signed-off-by: Janusz Krzysztofik 
Cc: Chris Wilson 
---
Resending with Cc: dri-de...@lists.freedesktop.org as requested, and a
typo in commit description fixed.

Thanks,
Janusz

 drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++
 drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 62d40c986642..8f322a4ecd87 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -737,6 +737,8 @@ void intel_gt_driver_remove(struct intel_gt *gt)
intel_uc_driver_remove(>->uc);
 
intel_engines_release(gt);
+
+   intel_gt_flush_buffer_pool(gt);
 }
 
 void intel_gt_driver_unregister(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c 
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index aa0a59c5b614..acc49c56a9f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -245,8 +245,6 @@ void intel_gt_fini_buffer_pool(struct intel_gt *gt)
struct intel_gt_buffer_pool *pool = >->buffer_pool;
int n;
 
-   intel_gt_flush_buffer_pool(gt);
-
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++)
GEM_BUG_ON(!list_empty(&pool->cache_list[n]));
 }
-- 
2.25.1

Re: [Intel-gfx] [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Kattamanchi, JaswanthX]

Hi Ayaz,

Re-reported

Patch : https://patchwork.freedesktop.org/series/94315/

Regards,
Jaswanth Kattamanchi

-Original Message-
From: Siddiqui, Ayaz A  
Sent: Friday, September 3, 2021 6:29 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 
; Illipilli, TejasreeX 
; Kattamanchi, JaswanthX 

Cc: Szwichtenberg, Radoslaw ; Meena, Mahesh 
; C, Ramalingam ; De Marchi, 
Lucas ; Roper, Matthew D 
Subject: RE: [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to L3_WB

Hi,
 I see a failure reported on IGT-CI for this series for SKL,

 igt@gem_ctx_isolation@preservation-s3@rcs0:
shard-skl: PASS -> DMESG-WARN

Changes set in this series are applicable for gen12 onward platforms except 
TGL/RKL.

So above failure look like a false alarm to me.

Regards
-Ayaz

> -Original Message-
> From: Siddiqui, Ayaz A 
> Sent: Friday, September 3, 2021 2:52 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Siddiqui, Ayaz A 
> Subject: [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to 
> L3_WB
> 
> Gen >= 12 onwards MOCS table doesn't have a setting for PTE so 
> I915_MOCS_PTE is not a valid index and it will have different MOCS 
> values are based on the platform.
> 
> To detect these kinds of misprogramming, all the unspecified and 
> reserved MOCS indexes are set to WB_L3. TGL/RKL unspecified MOCS 
> indexes are pointing to L3 UC are kept intact to avoid API break.
> 
> This series also contains patches to program BLIT_CCTL and CMD_CCTL 
> registers to UC.
> Since we are quite late to update MOCS table for TGL so added a new 
> MOCS table for ADL family.
> 
> V2:
>  1. Added CMD_CCTL to GUC regset list so that it can be restored
> after engine reset.
>  2. Checkpatch warning removal.
> 
> V3:
>  1. Changed implementation to have a framework only.
>  2. Added register type for proper application.
>  3. moved CMD_CCTL programming to a separate patch.
>  4. Added L3CC initialization during gt reset so that MOCS indexes are
> set before GuC initialization.
>  5. Removed Renderer check for L3CC verification in selftest.
> 
> V4:
>  1. Moved register programming in Workaorund section as fake workaround.
>  2. Removed seperate ADL mocs table, new logic is to set unused index as
> L3_WB for gen12 platform except TGL/RKL.
> 
> V5:
>  1. Final version reviewed by Matt Roper  2. Removed "drm/i915/selftest:
> Remove Renderer class check for l3cc table read" form series,
> this patch will be taken care of in different series.
> 
> Ayaz A Siddiqui (4):
>   drm/i915/gt: Add support of mocs propagation
>   drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward
>   drm/i915/gt: Set BLIT_CCTL reg to un-cached
>   drm/i915/gt: Initialize unused MOCS entries with device specific
> values
> 
> Sreedhar Telukuntla (1):
>   drm/i915/gt: Initialize L3CC table in mocs init
> 
>  drivers/gpu/drm/i915/gt/intel_gt.c  |  2 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h|  4 ++
>  drivers/gpu/drm/i915/gt/intel_mocs.c| 72 ++---
>  drivers/gpu/drm/i915/gt/intel_mocs.h|  1 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 70
> +++-
>  drivers/gpu/drm/i915/i915_reg.h | 26 
>  6 files changed, 151 insertions(+), 24 deletions(-)
> 
> --
> 2.26.2

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL   : https://patchwork.freedesktop.org/series/94315/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10549_full -> Patchwork_20950_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#1839])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb7/igt@feature_discov...@display-2x.html

  * igt@feature_discovery@display-3x:
- shard-tglb: NOTRUN -> [SKIP][2] ([i915#1839])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-tglb5/igt@feature_discov...@display-3x.html

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

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][4] ([i915#180]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html
- shard-skl:  [PASS][5] -> [DMESG-WARN][6] ([i915#3848])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-skl2/igt@gem_ctx_isolation@preservation...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-skl5/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl4/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][12] -> [FAIL][13] ([i915#2842] / [i915#3468])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][15] -> [SKIP][16] ([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb:  NOTRUN -> [SKIP][19] ([fdo#109271]) +257 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#112283])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb7/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_params@secure-non-root:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#112283])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-tglb5/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#768])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb7/igt@gem_render_c...@yf-tiled-to-vebox-x-tiled.html

  * igt@gem_softpin@evict-snoop:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109312])
   [23]: 
https://intel-gf

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/request: fix early tracepoints

[Patchwork]

== Series Details ==

Series: drm/i915/request: fix early tracepoints
URL   : https://patchwork.freedesktop.org/series/94317/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10549_full -> Patchwork_20951_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#1839])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-iclb7/igt@feature_discov...@display-2x.html

  * igt@feature_discovery@display-3x:
- shard-tglb: NOTRUN -> [SKIP][2] ([i915#1839])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-tglb1/igt@feature_discov...@display-3x.html

  * igt@feature_discovery@display-4x:
- shard-apl:  NOTRUN -> [SKIP][3] ([fdo#109271]) +209 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-apl2/igt@feature_discov...@display-4x.html

  * igt@gem_ctx_isolation@preservation-s3@vcs1:
- shard-kbl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs1.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs1.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl4/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-glk9/igt@gem_exec_fair@basic-p...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-tglb1/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#112283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-iclb7/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_params@secure-non-root:
- shard-tglb: NOTRUN -> [SKIP][16] ([fdo#112283])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-tglb1/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_exec_schedule@u-semaphore-user:
- shard-snb:  NOTRUN -> [SKIP][17] ([fdo#109271]) +223 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-snb7/igt@gem_exec_sched...@u-semaphore-user.html

  * igt@gem_exec_whisper@basic-fds-forked:
- shard-glk:  [PASS][18] -> [DMESG-WARN][19] ([i915#118] / 
[i915#95])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-glk8/igt@gem_exec_whis...@basic-fds-forked.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-glk3/igt@gem_exec_whis...@basic-fds-forked.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-apl1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#2428])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy-xy.html
- shard-glk:  [PASS][23] -> [FAIL][24] ([i915#1888] / [i915#307])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-glk4/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-t

Re: [Intel-gfx] [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Siddiqui, Ayaz A]

Hi,
 I see a failure reported on IGT-CI for this series for SKL,

 igt@gem_ctx_isolation@preservation-s3@rcs0:
shard-skl: PASS -> DMESG-WARN

Changes set in this series are applicable for gen12 onward platforms except 
TGL/RKL.

So above failure look like a false alarm to me.

Regards
-Ayaz

> -Original Message-
> From: Siddiqui, Ayaz A 
> Sent: Friday, September 3, 2021 2:52 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Siddiqui, Ayaz A 
> Subject: [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to
> L3_WB
> 
> Gen >= 12 onwards MOCS table doesn't have a setting for PTE so
> I915_MOCS_PTE is not a valid index and it will have different MOCS values
> are based on the platform.
> 
> To detect these kinds of misprogramming, all the unspecified and reserved
> MOCS indexes are set to WB_L3. TGL/RKL unspecified MOCS indexes are
> pointing to L3 UC are kept intact to avoid API break.
> 
> This series also contains patches to program BLIT_CCTL and CMD_CCTL
> registers to UC.
> Since we are quite late to update MOCS table for TGL so added a new MOCS
> table for ADL family.
> 
> V2:
>  1. Added CMD_CCTL to GUC regset list so that it can be restored
> after engine reset.
>  2. Checkpatch warning removal.
> 
> V3:
>  1. Changed implementation to have a framework only.
>  2. Added register type for proper application.
>  3. moved CMD_CCTL programming to a separate patch.
>  4. Added L3CC initialization during gt reset so that MOCS indexes are
> set before GuC initialization.
>  5. Removed Renderer check for L3CC verification in selftest.
> 
> V4:
>  1. Moved register programming in Workaorund section as fake workaround.
>  2. Removed seperate ADL mocs table, new logic is to set unused index as
> L3_WB for gen12 platform except TGL/RKL.
> 
> V5:
>  1. Final version reviewed by Matt Roper  2. Removed "drm/i915/selftest:
> Remove Renderer class check for l3cc table read" form series,
> this patch will be taken care of in different series.
> 
> Ayaz A Siddiqui (4):
>   drm/i915/gt: Add support of mocs propagation
>   drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward
>   drm/i915/gt: Set BLIT_CCTL reg to un-cached
>   drm/i915/gt: Initialize unused MOCS entries with device specific
> values
> 
> Sreedhar Telukuntla (1):
>   drm/i915/gt: Initialize L3CC table in mocs init
> 
>  drivers/gpu/drm/i915/gt/intel_gt.c  |  2 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h|  4 ++
>  drivers/gpu/drm/i915/gt/intel_mocs.c| 72 ++---
>  drivers/gpu/drm/i915/gt/intel_mocs.h|  1 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 70
> +++-
>  drivers/gpu/drm/i915/i915_reg.h | 26 
>  6 files changed, 151 insertions(+), 24 deletions(-)
> 
> --
> 2.26.2

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

[Petri Latvala]

On Fri, Sep 03, 2021 at 12:29:51PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/09/2021 01:31, jim.cro...@gmail.com wrote:
> > 
> > 
> > On Tue, Aug 31, 2021 at 5:38 PM Patchwork
> >  > > wrote:
> > 
> > __
> > *Patch Details*
> > *Series:*   use DYNAMIC_DEBUG to implement DRM.debug (rev2)
> > *URL:*  https://patchwork.freedesktop.org/series/93914/
> > 
> > *State:*failure
> > *Details:*
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/index.html
> > 
> > 
> > 
> >   CI Bug Log - changes from CI_DRM_10541_full -> Patchwork_20931_full
> > 
> > 
> > Summary
> > 
> > *FAILURE*
> > 
> > Serious unknown changes coming with Patchwork_20931_full absolutely
> > need to be
> > verified manually.
> > 
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_20931_full, please notify your bug team to
> > allow them
> > to document this new failure mode, which will reduce false positives
> > in CI.
> > 
> > 
> > hi Team !
> > 
> > I think I need a bit of orientation.
> > 
> > 
> > Possible new issues
> > 
> > Here are the unknown changes that may have been introduced in
> > Patchwork_20931_full:
> > 
> > 
> >   IGT changes
> > 
> > 
> > Possible regressions
> > 
> >   * igt@gem_exec_schedule@u-submit-golden-slice@vcs0:
> >   o shard-skl: NOTRUN -> INCOMPLETE
> > 
> > 
> > 
> > 
> > Warnings
> > 
> >   * igt@i915_pm_dc@dc9-dpms:
> >   o shard-skl: SKIP
> > 
> > 
> > ([fdo#109271]) -> FAIL
> > 
> > 
> > 
> > 
> > 
> > Im assuming the FAIL is the sticking point,
> 
> Both INCOMPLETE and FAIL will cause a failure to be declared, but in this 
> case it looks to me this series is not at fault.
> 
> 1)
> 
> The gem_exec_schedule failure looks like a test runner timeout issue (and 
> apparently test does not handle well running the the fence timeout enabled).
> 
> @Petri - does the below look like IGT runner running our of time budget for 
> the test run? Would it log
> 
> [1051.943629] [114/138] ( 11s left) gem_exec_schedule (u-submit-golden-slice)
> Starting subtest: u-submit-golden-slice
> Starting dynamic subtest: rcs0
> Dynamic subtest rcs0: SUCCESS (80.175s)
> Starting dynamic subtest: bcs0
> Dynamic subtest bcs0: SUCCESS (80.195s)
> Starting dynamic subtest: vcs0
> Dynamic subtest vcs0: SUCCESS (80.243s)
> Starting dynamic subtest: vecs0
> 
> Interesting part is that according to dmesg it never got to the vecs0 dynamic 
> subtest - any idea what happened there?

Yep, we ran out of time. We still had 11 seconds left to execute
something but then that test took centuries.


> 
> 2)
> 
> I915_pm_dc I'd say you just gotten unlucky that test went from always 
> skipping on SKL to trying to run it and then it failed. But I don't know 
> enough about the test to tell you why. Adding Jigar and Anshuman as test 
> author and reviewer who might be able to shed some light here.
> 
> Regards,
> 
> Tvrtko
> 
> > I found code that seemed to be relevant
> > 
> > [jimc@frodo igt-ci-tags.git]$ git remote -v
> > origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git
> >  (fetch)
> > origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git
> >  (push)
> > 
> > I built it, got an error, threw that to google,
> > found a patch on i-g-t from
> > commit 1ff3e5ae99ceb66d2926d58635d0379ce971065a (HEAD -> master)
> > Author: Lyude Paul mailto:ly...@redhat.com>>
> > Date:   Mon Apr 15 14:57:23 2019 -0400
> > 
> > and applied it
> > it fixed the one problem
> > 
> > then I looked at previous head
> > 
> > commit f052e49a43cc9704ea5f240df15dd9d3dfed68ab (origin/master, origin/HEAD)
> > Author: Simon Ser mailto:simon@intel.com>>
> > Date:   Wed Apr 24 19:15:26 2019 +0300
> > 
> > It sure seems that tree is stale.

That tree's master ref does not get updated. It's only for storing tags.

That test result comparison was too long to fit into patchwork so the
build information at the bottom is missing, but the BAT results have
it:

IGT_6193: 080869f804cb86b25a38889e5ce9a870571cd8c4 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git



-- 
Petri Latvala

Re: [Intel-gfx] i915 with Dell XPS 9310

[Saarinen, Jani]

Hi, 
Please report actual bug using instructions: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs ?

Br,
Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



> -Original Message-
> From: Intel-gfx  On Behalf Of wi nk
> Sent: perjantai 3. syyskuuta 2021 15.38
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] i915 with Dell XPS 9310
> 
> Hello all,
> 
>I've been following recent kernels on this dell laptop for almost a year 
> now to work
> through some issues with the ath11k module.  I've been experiencing random
> occasional video artifacts for most of that time.  These artifacts would 
> cause the
> i915 module to report some kind of underrun (sorry I don't have those logs any
> longer).  At some point around 5.10 the artifacts turned into full panics 
> that needed a
> reboot instead of some waiting and jiggling.  Kalle reported here:
> http://lists.infradead.org/pipermail/ath11k/2021-August/001451.html
> that there was a commit he could revert to fix it.  I was unable to reproduce 
> that fix
> by reverting it.
> 
> I'm now running 5.14.0 and it seems to have changed behavior again.
> Instead of the machine hard locking (ie: no caps lock even), it seems to 
> recover after
> a bit and then I can see this in dmesg:
> 
> [226387.152234] DMAR: DRHD: handling fault status reg 3 [226387.152244] DMAR:
> [DMA Write NO_PASID] Request device [0x00:0x02.0] fault addr 0xf0afc000 [fault
> reason 0x07] Next page table ptr is invalid [226402.058857] i915 :00:02.0:
> [drm] GPU HANG: ecode 12:0: [226402.058876] i915 :00:02.0: [drm]
> Resetting rcs0 for stopped heartbeat on rcs0 [276353.590922] clocksource:
> timekeeping watchdog on CPU4: hpet retried 2 times before success
> 
> 
> 
> [345312.963065] DMAR: DRHD: handling fault status reg 3 [345312.963077] DMAR:
> [DMA Write NO_PASID] Request device [0x00:0x02.0] fault addr 0xf21ec000 [fault
> reason 0x07] Next page table ptr is invalid [345323.814583] Asynchronous wait 
> on
> fence
> :00:02.0:gnome-shell[2707]:1a15a6 timed out
> (hint:intel_atomic_commit_ready [i915]) [345327.672581] i915 :00:02.0: 
> [drm]
> GPU HANG: ecode 12:1:85db, in signal-desktop [26051] [345327.672606] i915
> :00:02.0: [drm] Resetting rcs0 for stopped heartbeat on rcs0 
> [345327.672656]
> i915 :00:02.0: [drm] signal-desktop[26051] context reset due to GPU hang
> 
> I'm not sure what the DMAR messages are about, I included them in case they're
> relevant.  How can I debug this further?  I'll gladly enable whatever is 
> needed :)
> 
> Thanks!

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use Transparent Hugepages when IOMMU is enabled

[Tvrtko Ursulin]

On 29/07/2021 15:06, Daniel Vetter wrote:

On Thu, Jul 29, 2021 at 3:34 PM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets just do that.

To err on the side of safety we keep the current default in cases where
IOMMU is not active, and only when it is default to the "huge=within_size"
mode. Although there probably would be wins to enable them throughout,
more extensive testing across benchmarks and platforms would need to be
done.

With the patch and IOMMU enabled my local testing on a small Skylake part
shows OglVSTangent regression being reduced from ~14% (IOMMU on versus
IOMMU off) to ~2% (same comparison but with THP on).

v2:
  * Add Kconfig dependency to transparent hugepages and some help text.
  * Move to helper for easier handling of kernel build options.

v3:
  * Drop Kconfig. (Daniel)

References: b901bb89324a ("drm/i915/gemfs: enable THP")
References: 9987da4b5dcf ("drm/i915: Disable THP until we have a GPU read BW 
W/A")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/430
Co-developed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Cc: Eero Tamminen 
Cc: Tvrtko Ursulin 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Rodrigo Vivi  # v1


On both patches: Acked-by: Daniel Vetter 


Eero's testing results at 
https://gitlab.freedesktop.org/drm/intel/-/issues/430 are looking good - 
seem to show this to be a net win for at least Gen9 and Gen12 platforms.


Is the ack enough to merge in this case or I should look for an r-b as well?

Regards,

Tvrtko


---
  drivers/gpu/drm/i915/gem/i915_gemfs.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c 
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 5e6e8c91ab38..dbdbdc344d87 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -6,7 +6,6 @@

  #include 
  #include 
-#include 

  #include "i915_drv.h"
  #include "i915_gemfs.h"
@@ -15,6 +14,7 @@ int i915_gemfs_init(struct drm_i915_private *i915)
  {
 struct file_system_type *type;
 struct vfsmount *gemfs;
+   char *opts;

 type = get_fs_type("tmpfs");
 if (!type)
@@ -26,10 +26,26 @@ int i915_gemfs_init(struct drm_i915_private *i915)
  *
  * One example, although it is probably better with a per-file
  * control, is selecting huge page allocations ("huge=within_size").
-* Currently unused due to bandwidth issues (slow reads) on Broadwell+.
+* However, we only do so to offset the overhead of iommu lookups
+* due to bandwidth issues (slow reads) on Broadwell+.
  */

-   gemfs = kern_mount(type);
+   opts = NULL;
+   if (intel_vtd_active()) {
+   if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
+   static char huge_opt[] = "huge=within_size"; /* r/w */
+
+   opts = huge_opt;
+   drm_info(&i915->drm,
+"Transparent Hugepage mode '%s'\n",
+opts);
+   } else {
+   drm_notice(&i915->drm,
+  "Transparent Hugepage support is recommended for 
optimal performance when IOMMU is enabled!\n");
+   }
+   }
+
+   gemfs = vfs_kern_mount(type, SB_KERNMOUNT, type->name, opts);
 if (IS_ERR(gemfs))
 return PTR_ERR(gemfs);

--
2.30.2

[Intel-gfx] i915 with Dell XPS 9310

[wi nk]

Hello all,

   I've been following recent kernels on this dell laptop for almost a
year now to work through some issues with the ath11k module.  I've
been experiencing random occasional video artifacts for most of that
time.  These artifacts would cause the i915 module to report some kind
of underrun (sorry I don't have those logs any longer).  At some point
around 5.10 the artifacts turned into full panics that needed a reboot
instead of some waiting and jiggling.  Kalle reported here:
http://lists.infradead.org/pipermail/ath11k/2021-August/001451.html
that there was a commit he could revert to fix it.  I was unable to
reproduce that fix by reverting it.

I'm now running 5.14.0 and it seems to have changed behavior again.
Instead of the machine hard locking (ie: no caps lock even), it seems
to recover after a bit and then I can see this in dmesg:

[226387.152234] DMAR: DRHD: handling fault status reg 3
[226387.152244] DMAR: [DMA Write NO_PASID] Request device
[0x00:0x02.0] fault addr 0xf0afc000 [fault reason 0x07] Next page
table ptr is invalid
[226402.058857] i915 :00:02.0: [drm] GPU HANG: ecode 12:0:
[226402.058876] i915 :00:02.0: [drm] Resetting rcs0 for stopped
heartbeat on rcs0
[276353.590922] clocksource: timekeeping watchdog on CPU4: hpet
retried 2 times before success



[345312.963065] DMAR: DRHD: handling fault status reg 3
[345312.963077] DMAR: [DMA Write NO_PASID] Request device
[0x00:0x02.0] fault addr 0xf21ec000 [fault reason 0x07] Next page
table ptr is invalid
[345323.814583] Asynchronous wait on fence
:00:02.0:gnome-shell[2707]:1a15a6 timed out
(hint:intel_atomic_commit_ready [i915])
[345327.672581] i915 :00:02.0: [drm] GPU HANG: ecode
12:1:85db, in signal-desktop [26051]
[345327.672606] i915 :00:02.0: [drm] Resetting rcs0 for stopped
heartbeat on rcs0
[345327.672656] i915 :00:02.0: [drm] signal-desktop[26051] context
reset due to GPU hang

I'm not sure what the DMAR messages are about, I included them in case
they're relevant.  How can I debug this further?  I'll gladly enable
whatever is needed :)

Thanks!

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/request: fix early tracepoints

[Patchwork]

== Series Details ==

Series: drm/i915/request: fix early tracepoints
URL   : https://patchwork.freedesktop.org/series/94317/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10549 -> Patchwork_20951


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [DMESG-WARN][3] ([i915#3925]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][5] ([i915#3921]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20951/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925


Participating hosts (46 -> 38)
--

  Missing(8): fi-kbl-soraka bat-adls-5 fi-hsw-4200u bat-dg1-5 fi-bsw-cyan 
bat-adlp-4 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10549 -> Patchwork_20951

  CI-20190529: 20190529
  CI_DRM_10549: cd8e346a0b56ce66f94a9908c7a068bbee8f1829 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20951: c82cbcd35cf9beef272fa314c267c0ced70adbc5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c82cbcd35cf9 drm/i915/request: fix early tracepoints

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/request: fix early tracepoints

[Patchwork]

== Series Details ==

Series: drm/i915/request: fix early tracepoints
URL   : https://patchwork.freedesktop.org/series/94317/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c82cbcd35cf9 drm/i915/request: fix early tracepoints
-:40: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 855e39e65cfc ("drm/i915: 
Initialise basic fence before acquiring seqno")'
#40: 
commit 855e39e65cfc33a73724f1cc644ffc5754864a20

-:49: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 12ca695d2c1e ("drm/i915: Do not 
share hwsp across contexts any more, v8.")'
#49: 
commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL   : https://patchwork.freedesktop.org/series/94315/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10549_full -> Patchwork_20950_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-skl2/igt@gem_ctx_isolation@preservation...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-skl5/igt@gem_ctx_isolation@preservation...@rcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#1839])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb7/igt@feature_discov...@display-2x.html

  * igt@feature_discovery@display-3x:
- shard-tglb: NOTRUN -> [SKIP][4] ([i915#1839])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-tglb5/igt@feature_discov...@display-3x.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-snb5/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][6] ([i915#180]) +1 similar 
issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl4/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][12] -> [FAIL][13] ([i915#2842] / [i915#3468])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][15] -> [SKIP][16] ([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb:  NOTRUN -> [SKIP][19] ([fdo#109271]) +257 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#112283])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/shard-iclb7/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_params@secure-non-root:
- shard-tgl

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

[Tvrtko Ursulin]

On 03/09/2021 01:31, jim.cro...@gmail.com wrote:



On Tue, Aug 31, 2021 at 5:38 PM Patchwork 
> wrote:


__
*Patch Details*
*Series:*   use DYNAMIC_DEBUG to implement DRM.debug (rev2)
*URL:*  https://patchwork.freedesktop.org/series/93914/

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



  CI Bug Log - changes from CI_DRM_10541_full -> Patchwork_20931_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_20931_full absolutely
need to be
verified manually.

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


hi Team !

I think I need a bit of orientation.


Possible new issues

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


  IGT changes


Possible regressions

  * igt@gem_exec_schedule@u-submit-golden-slice@vcs0:
  o shard-skl: NOTRUN -> INCOMPLETE




Warnings

  * igt@i915_pm_dc@dc9-dpms:
  o shard-skl: SKIP


([fdo#109271]) -> FAIL





Im assuming the FAIL is the sticking point,


Both INCOMPLETE and FAIL will cause a failure to be declared, but in this case 
it looks to me this series is not at fault.

1)

The gem_exec_schedule failure looks like a test runner timeout issue (and 
apparently test does not handle well running the the fence timeout enabled).

@Petri - does the below look like IGT runner running our of time budget for the 
test run? Would it log

[1051.943629] [114/138] ( 11s left) gem_exec_schedule (u-submit-golden-slice)
Starting subtest: u-submit-golden-slice
Starting dynamic subtest: rcs0
Dynamic subtest rcs0: SUCCESS (80.175s)
Starting dynamic subtest: bcs0
Dynamic subtest bcs0: SUCCESS (80.195s)
Starting dynamic subtest: vcs0
Dynamic subtest vcs0: SUCCESS (80.243s)
Starting dynamic subtest: vecs0

Interesting part is that according to dmesg it never got to the vecs0 dynamic 
subtest - any idea what happened there?

2)

I915_pm_dc I'd say you just gotten unlucky that test went from always skipping 
on SKL to trying to run it and then it failed. But I don't know enough about 
the test to tell you why. Adding Jigar and Anshuman as test author and reviewer 
who might be able to shed some light here.

Regards,

Tvrtko


I found code that seemed to be relevant

[jimc@frodo igt-ci-tags.git]$ git remote -v
origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git 
 (fetch)
origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git 
 (push)


I built it, got an error, threw that to google,
found a patch on i-g-t from
commit 1ff3e5ae99ceb66d2926d58635d0379ce971065a (HEAD -> master)
Author: Lyude Paul mailto:ly...@redhat.com>>
Date:   Mon Apr 15 14:57:23 2019 -0400

and applied it
it fixed the one problem

then I looked at previous head

commit f052e49a43cc9704ea5f240df15dd9d3dfed68ab (origin/master, origin/HEAD)
Author: Simon Ser mailto:simon@intel.com>>
Date:   Wed Apr 24 19:15:26 2019 +0300

It sure seems that tree is stale.

I dont need to fix this anyway, a later rev got past this one,
but it would be nice to know whats current



Suppressed

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

  *

igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:

  o {shard-rkl}: NOTRUN -> SKIP


+5 similar issues
  *

igt@kms_vblank@pipe-c-ts-continuation-idle:

  o {shard-rkl}: SKIP


([i915#1845]) -> SKIP


+3 similar issues


Known issues

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


  IGT changes


Issues hit

[Intel-gfx] [PATCH] drm/i915/request: fix early tracepoints

[Matthew Auld]

Currently we blow up in trace_dma_fence_init, when calling into
get_driver_name or get_timeline_name, since both the engine and context
might be NULL(or contain some garbage address) in the case of newly
allocated slab objects via the request ctor. Note that we also use
SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately
freed, but delay freeing the underlying page by an RCU grace period.
With this scheme requests can be re-allocated, at the same time as they
are also being read by some lockless RCU lookup mechanism.

One possible fix, since we don't yet have a fully initialised request
when in the ctor, is just setting the context/engine as NULL and adding
some extra handling in get_driver_name etc. And since the ctor is only
called for new slab objects(i.e allocate new page and call the ctor for
each object) it's safe to reset the context/engine prior to calling into
dma_fence_init, since we can be certain that no one is doing an RCU
lookup which might depend on peeking at the engine/context, like in
active_engine(), since the object can't yet be externally visible.

In the recycled case(which might also be externally visible) the request
refcount always transitions from 0->1 after we set the context/engine
etc, which should ensure it's valid to dereference the engine for
example, when doing an RCU list-walk, so long as we can also increment
the refcount first. If the refcount is already zero, then the request is
considered complete/released.  If it's non-zero, then the request might
be in the process of being re-allocated, or potentially still in flight,
however after successfully incrementing the refcount, it's possible to
carefully inspect the request state, to determine if the request is
still what we were looking for. Note that all externally visible
requests returned to the cache must have zero refcount.

An alternative fix then is to instead move the dma_fence_init out from
the request ctor. Originally this was how it was done, but it was moved
in:

commit 855e39e65cfc33a73724f1cc644ffc5754864a20
Author: Chris Wilson 
Date:   Mon Feb 3 09:41:48 2020 +

drm/i915: Initialise basic fence before acquiring seqno

where it looks like intel_timeline_get_seqno() relied on some of the
rq->fence state, but that is no longer the case since:

commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc
Author: Maarten Lankhorst 
Date:   Tue Mar 23 16:49:50 2021 +0100

drm/i915: Do not share hwsp across contexts any more, v8.

intel_timeline_get_seqno() could also be cleaned up slightly by dropping
the request argument.

Moving dma_fence_init back out of the ctor, should ensure we have enough
of the request initialised in case of trace_dma_fence_init.
Functionally this should be the same, and is effectively what we were
already open coding before, except now we also assign the fence->lock
and fence->ops, but since these are invariant for recycled
requests(which might be externally visible), and will therefore already
hold the same value, it shouldn't matter. We still leave the
spin_lock_init() in the ctor, since we can't re-init the rq->lock in
case it is already held.

Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno")
Signed-off-by: Matthew Auld 
Cc: Michael Mason 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_request.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index ce446716d092..79da5eca60af 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -829,8 +829,6 @@ static void __i915_request_ctor(void *arg)
i915_sw_fence_init(&rq->submit, submit_notify);
i915_sw_fence_init(&rq->semaphore, semaphore_notify);
 
-   dma_fence_init(&rq->fence, &i915_fence_ops, &rq->lock, 0, 0);
-
rq->capture_list = NULL;
 
init_llist_head(&rq->execute_cb);
@@ -905,17 +903,12 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->ring = ce->ring;
rq->execution_mask = ce->engine->mask;
 
-   kref_init(&rq->fence.refcount);
-   rq->fence.flags = 0;
-   rq->fence.error = 0;
-   INIT_LIST_HEAD(&rq->fence.cb_list);
-
ret = intel_timeline_get_seqno(tl, rq, &seqno);
if (ret)
goto err_free;
 
-   rq->fence.context = tl->fence_context;
-   rq->fence.seqno = seqno;
+   dma_fence_init(&rq->fence, &i915_fence_ops, &rq->lock,
+  tl->fence_context, seqno);
 
RCU_INIT_POINTER(rq->timeline, tl);
rq->hwsp_seqno = tl->hwsp_seqno;
-- 
2.26.3

Re: [Intel-gfx] [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug

[Tvrtko Ursulin]

On 31/08/2021 21:21, Jim Cromie wrote:

drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names).  There are thousands of these callsites, each
categorized in this systematized way.

These callsites can be enabled at runtime by their category, each
controlled by a bit in drm.debug (/sys/modules/drm/parameter/debug).
In the current "basic" implementation, drm_debug_enabled() tests these
bits in __drm_debug each time an API[1] call is executed; while cheap
individually, the costs accumulate with uptime.

This patch uses dynamic-debug with jump-label to patch enabled calls
onto their respective NOOP slots, avoiding all runtime bit-checks of
__drm_debug by drm_debug_enabled().

Dynamic debug has no concept of category, but we can emulate one by
replacing enum categories with a set of prefix-strings; "drm:core:",
"drm:kms:" "drm:driver:" etc, and prepend them (at compile time) to
the given formats.

Then we can use:
   `echo module drm format "^drm:core: " +p > control`

to enable the whole category with one query.


Probably stupid question - enabling stuff at boot time still works as 
described in Documentation/admin-guide/dynamic-debug-howto.rst?


Second question, which perhaps has been covered in the past so apologies 
if redundant - what is the advantage of allowing this to be 
configurable, versus perhaps always enabling it? Like what would be the 
reasons someone wouldn't just want to have CONFIG_DYNAMIC_DEBUG compiled 
in? Kernel binary size?


Regards,

Tvrtko



This conversion yields many new prdbg callsites:

   dyndbg: 195 debug prints in module drm_kms_helper
   dyndbg: 298 debug prints in module drm
   dyndbg: 1630 debug prints in module i915
   dyndbg: ~3500 debug prints in module amdgpu

CONFIG_DRM_USE_DYNAMIC_DEBUG enables this, and is available if
CONFIG_DYNAMIC_DEBUG or CONFIG_DYNAMIC_DEBUG_CORE is chosen, and if
CONFIG_JUMP_LABEL is enabled; this because its required to get the
promised optimizations.

The "basic" -> "dyndbg" switchover is layered into the macro scheme

A. A "prefix" version of DRM_UT_ map, named DRM_DBG_CAT_

"basic":  DRM_DBG_CAT_  <===  DRM_UT_.  Identity map.
"dyndbg":
#define DRM_DBG_CAT_KMS"drm:kms: "
#define DRM_DBG_CAT_PRIME  "drm:prime: "
#define DRM_DBG_CAT_ATOMIC "drm:atomic: "

In v3, had older name, DRM_DBG_CLASS_ was countered, I had
agreed, but this seems better still; CATEGORY is already DRM's
term-of-art, and adding a near-synonym 'CLASS' only adds ambiguity.

DRM_UT_* are preserved, since theyre used elsewhere.  We can probably
reduce their use further, but thats a separate thing.

B. drm_dev_dbg() & drm_debug() are interposed with macros

basic:forward to renamed fn, with args preserved
enabled:  redirect to pr_debug, dev_dbg, with CATEGORY format catenated

This is where drm_debug_enabled() is avoided.  The prefix is prepended
at compile-time, no category at runtime.

C. API[1] uses DRM_DBG_CAT_s

these already use (B), now they use (A) too, to get the correct token
type for "basic" and "dyndbg" configs.

D. use DEFINE_DYNAMIC_DEBUG_CATEGORIES()

This defines the map using DRM_CAT_s, and creates the /sysfs
bitmap to control those categories.

NOTES:

Because the dyndbg callback is watching __drm_debug, it is coherent
with drm_debug_enabled() and its remaining users; the switchover
should be transparent.

Code Review is expected to catch the lack of correspondence between
bit=>prefix definitions (the selector) and the prefixes used in the
API[1] layer above pr_debug()

I've coded the search-prefixes/categories with a trailing space, which
excludes any sub-categories added later.  This convention protects any
"drm:atomic:fail:" callsites from getting stomped on by `echo 0 > debug`.
Other categories could differ, but we need some default.

Dyndbg requires that the prefix be in the compiled-in format string;
run-time prefixing evades callsite selection by category.

pr_debug("%s: ...", __func__, ...) // not ideal

With "lineno X" in a query, its possible to enable single callsites,
but it is tedious, and useless in a category context.

Unfortunately __func__ is not a macro, and cannot be catenated at
preprocess/compile time.

Signed-off-by: Jim Cromie 
---
v5:
. use DEFINE_DYNAMIC_DEBUG_CATEGORIES in drm_print.c
. s/DRM_DBG_CLASS_/DRM_DBG_CAT_/ - dont need another term
. default=y in KBuild entry - per @DanVet
. move some commit-log prose to dyndbg commit
. add-prototyes to (param_get/set)_dyndbg
. more wrinkles found by 
. relocate ratelimit chunk from elsewhere
v6:
. add kernel doc
. fix cpp paste, drop '#'
v7:
. change __drm_debug to long, to fit with DEFINE_DYNAMIC_DEBUG_CATEGORIES
. add -DDYNAMIC_DEBUG_MODULE to ccflags if DRM_USE_DYNAMIC_DEBUG
---
  drivers/gpu/drm/Kconfig |  13 
  drivers/gpu/drm/Makefile|   3 +
  drivers/gpu/drm/drm_print.c |  53 +
  include/drm/drm_print.h | 144 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

[Jani Nikula]

On Mon, 22 Mar 2021, Ville Syrjälä  wrote:
> On Fri, Mar 19, 2021 at 07:08:40PM -, Patchwork wrote:
>> == Series Details ==
>> 
>> Series: drm/i915: Enable TPS3/4 on all platforms that support them
>> URL   : https://patchwork.freedesktop.org/series/88186/
>> State : success
>> 
>> == Summary ==
>> 
>> CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815
>> 
>> 
>> Summary
>> ---
>> 
>>   **SUCCESS**
>
> That's a bit odd considering the link training still fails with this.
> Did we convert some erorrs to debugs perhaps, or maybe this never
> got flagged as an error?
>
> <7>[8.235008] i915 :00:02.0: [drm:intel_dp_start_link_train [i915]] 
> Using LINK_RATE_SET value 03
> <7>[8.236203] i915 :00:02.0: [drm:intel_dp_set_signal_levels [i915]] 
> Using vswing level 0, pre-emphasis level 0, at DPRX
> <7>[8.236341] i915 :00:02.0: 
> [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY A] 
> Using DP training pattern TPS1
> <7>[8.237373] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> clock recovery OK
> <7>[8.237460] i915 :00:02.0: 
> [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY A] 
> Using DP training pattern TPS4
> <7>[8.239054] i915 :00:02.0: [drm:intel_dp_dump_link_status.isra.4 
> [i915]] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x0 adj_req2_3:0x0
> <7>[8.239135] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> Clock recovery check failed, cannot continue channel equalization
> <7>[8.239218] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
> [CONNECTOR:308:eDP-1] Link Training failed at link rate = 27, lane count 
> = 2, at DPRX
>
> So CR lock is lost as soon as we switch to TPS4. I really wonder if the sink
> actually even implements TPS4, and maybe when we write TPS4 to the DPCD reg
> it starts to expect some other pattern? Should be semi-easy to confirm
> I guess...
>
> One thing I was pondering is whether we're detecting TPS4 vs. TPS3 differently
> that eg. Windows. Based on some trawling it looks to me that for some reason
> Windows uses the EDP_DPCD_REV>=0x4 check rather than DPCD_REV>=0x14 on eDP
> panels when checking for TPS4 suppport. Unfortunately following that
> convention here wouldn't help us:
>
> <7>[6.835706] i915 :00:02.0: [drm:intel_dp_init_connector [i915]] eDP 
> DPCD: 04 fb ff
> <7>[8.234921] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: Base DPCD: 
> 14 0a 82 41 00 00 01 c0 02 00 00 00 0f 09 80
> <7>[8.234943] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 0a 
> 82 c1 00 00 01 c0 02 00 00 00 0f 09 80

Should try this in combination with [1]?

BR,
Jani.


[1] 
https://patchwork.freedesktop.org/patch/msgid/20210719235927.283173-1-khaled.almahall...@intel.com


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories

[Tvrtko Ursulin]

On 31/08/2021 21:21, Jim Cromie wrote:

The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM.  Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.

DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"dyndbg bitmap desc",
{ "gvt:cmd: ",  "command processing" },
{ "gvt:core: ", "core help" },
{ "gvt:dpy: ",  "display help" },
{ "gvt:el: ",   "help" },
{ "gvt:irq: ",  "help" },
{ "gvt:mm: ",   "help" },
{ "gvt:mmio: ", "help" },
{ "gvt:render: ", "help" },
{ "gvt:sched: " "help" });

The actual patch has a few details different, cmd_help() macro emits
the initialization construct.

if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added
cflags, by gvt/Makefile.

Signed-off-by: Jim Cromie 
---
v5:
. static decl of vector of bit->class descriptors - Emil.V
. relocate gvt-makefile chunk from elsewhere
v7:
. move ccflags addition up to i915/Makefile from i915/gvt
---
  drivers/gpu/drm/i915/Makefile  |  4 
  drivers/gpu/drm/i915/i915_params.c | 35 ++


Can this work if put under gvt/ or at least intel_gvt.h|c?


  2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f22cac1c49b..5a4e371a3ec2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -30,6 +30,10 @@ CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, 
override-init)
  
  subdir-ccflags-y += -I$(srctree)/$(src)
  
+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG

+ccflags-y += -DDYNAMIC_DEBUG_MODULE
+#endif


Ignores whether CONFIG_DRM_I915_GVT is enabled or not?


+
  # Please keep these build lists sorted!
  
  # core driver code

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index e07f4cfea63a..e645e149485e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -265,3 +265,38 @@ void i915_params_free(struct i915_params *params)
I915_PARAMS_FOR_EACH(FREE);
  #undef FREE
  }
+
+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
+/* todo: needs DYNAMIC_DEBUG_MODULE in some cases */
+
+unsigned long __gvt_debug;
+EXPORT_SYMBOL(__gvt_debug);
+
+#define _help(key) "\t\"" key "\"\t: help for " key "\n"
+
+#define I915_GVT_CATEGORIES(name) \
+   " Enable debug output via /sys/module/i915/parameters/" #name \
+   ", where each bit enables a debug category.\n"\
+   _help("gvt:cmd:") \
+   _help("gvt:core:")\
+   _help("gvt:dpy:") \
+   _help("gvt:el:")  \
+   _help("gvt:irq:") \
+   _help("gvt:mm:")  \
+   _help("gvt:mmio:")\
+   _help("gvt:render:")  \
+   _help("gvt:sched:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
+   I915_GVT_CATEGORIES(debug_gvt),
+   _DD_cat_("gvt:cmd:"),
+   _DD_cat_("gvt:core:"),
+   _DD_cat_("gvt:dpy:"),
+   _DD_cat_("gvt:el:"),
+   _DD_cat_("gvt:irq:"),
+   _DD_cat_("gvt:mm:"),
+   _DD_cat_("gvt:mmio:"),
+   _DD_cat_("gvt:render:"),
+   _DD_cat_("gvt:sched:"));
+
+#endif


So just the foundation - no actual use sites I mean? How would these be 
used from the code?


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915/bios: remove vbt ddi_port_info caching

[Jani Nikula]

On Wed, 01 Sep 2021, Jani Nikula  wrote:
> v2 of https://patchwork.freedesktop.org/series/93957/ with the CI issues
> fixed (fingers crossed!).

José, I'd like to get an ack from you on this before applying. I know
it's bound conflict with your in flight series. Thoughts?

BR,
Jani.

>
> BR,
> Jani.
>
> Jani Nikula (7):
>   drm/i915/bios: use hdmi level shift directly from child data
>   drm/i915/bios: use max tmds clock directly from child data
>   drm/i915/bios: use dp max link rate directly from child data
>   drm/i915/bios: use alternate aux channel directly from child data
>   drm/i915/bios: move ddc pin mapping code next to ddc pin sanitize
>   drm/i915/bios: use ddc pin directly from child data
>   drm/i915/bios: get rid of vbt ddi_port_info
>
>  drivers/gpu/drm/i915/display/intel_bios.c | 372 +++---
>  drivers/gpu/drm/i915/i915_drv.h   |  18 +-
>  2 files changed, 187 insertions(+), 203 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 07/19] drm/i915: vma is always backed by an object.

[Tvrtko Ursulin]

On 03/09/2021 10:31, Maarten Lankhorst wrote:

Op 31-08-2021 om 12:29 schreef Tvrtko Ursulin:


On 31/08/2021 10:34, Maarten Lankhorst wrote:

Op 31-08-2021 om 11:18 schreef Tvrtko Ursulin:


On 30/08/2021 13:09, Maarten Lankhorst wrote:

vma->obj and vma->resv are now never NULL, and some checks can be removed.


Is the direction here compatible with SVM / VM_BIND?



Yeah, it should be. The changes here make the obj->resv->lock the main lock, so 
it should at least simplify locking for VM_BIND.


Hm but what will vma->obj point to in case of SVM, when there is no GEM BO?


Probably to one of the bo's in i915_vm, or a dummy bo that least shares the 
vm_resv object, similar to the aliasing gtt handling.


As a long term or short term solution? Worried that would waste a lot of 
SLAB space just for convenience (whole struct drm_i915_gem_object just 
to store a single pointer to a dma_resv object, if I got that right), 
while it should be possible to come up with a cleaner design.


Even for the upcoming page granularity work we will need multiple VMAs 
point to single GEM bo in ppgtt and that, when SVM is considered, could 
for instance mean that VMAs should instead be backed by some new backing 
store objects, which in turn may (or may not) point to GEM BOs.


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Release i915_gem_context from a worker

[Tvrtko Ursulin]

On 02/09/2021 21:02, Daniel Vetter wrote:

On Thu, Sep 2, 2021 at 6:20 PM Tvrtko Ursulin
 wrote:

On 02/09/2021 16:05, Daniel Vetter wrote:

On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
 wrote:



On 13/08/2021 21:30, Daniel Vetter wrote:

The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme for that. Otherwise all other callers are
from process context, and generally fairly benign locking context.


There is reset which definitely isn't process context.


gpu reset runs in process context. The tasklet context is the
engines_notify I'm talking about above.


I haven't looked very deeply but please double check the path from
execlists_submission_tasklet -> execlists_reset -> intel_engine_reset ->
__intel_engine_reset -> execlists_reset_rewind -> execlists_reset_csb ->
execlists_reset_active -> __i915_request_reset -> mark_guilty ->
i915_gem_context_put.


Thanks for pointing this out, I'll add it to the commit message.

More stuff to fix, yay.


Otherwise I did not really get from the commit message is this patch
fixing an existing problem or preparing something for the future. If the
former then as I wrote above - I am pretty sure there are call sites
from the tasklet already.

Regards,

Tvrtko


Unfortunately untangling that requires some major surgery, and we have
a few i915_gem_context reference counting bugs that need fixing, and
they blow in the current hardirq calling context, so we need a
stop-gap measure.


I guess this para wasn't clear, but subsequent patches fix the
refcount bugs and need this prep patch here.


So up to where in the series are those fixes and where other stuff
follows? Worth spliting and having cover letters perhaps? Is the fixing
part applicable to the existing code or only comes to play with the
syncobj single timeline changes?


There's Fixes: lines. One is timeline syncobj, the other is 2 years old.


So first two patches are standalone and fix the immediate bug? Could you 
describe the composition and doings of the series in a cover letter so 
it's possible to have an overview of chunk of work tackled?


Regards,

Tvrtko


-Daniel



Regards,

Tvrtko


-Daniel



Put a FIXME comment in when this should be removable again.

Signed-off-by: Daniel Vetter 
Cc: Jon Bloomfield 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
Cc: "Thomas Hellström" 
Cc: Matthew Auld 
Cc: Lionel Landwerlin 
Cc: Dave Airlie 
Cc: Jason Ekstrand 
---
drivers/gpu/drm/i915/gem/i915_gem_context.c   | 13 +++--
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 12 
2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd169cf2f75a..051bc357ff65 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -986,9 +986,10 @@ static struct i915_gem_engines *user_engines(struct 
i915_gem_context *ctx,
return err;
}

-void i915_gem_context_release(struct kref *ref)
+static void i915_gem_context_release_work(struct work_struct *work)
{
- struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
+ struct i915_gem_context *ctx = container_of(work, typeof(*ctx),
+ release_work);

trace_i915_context_free(ctx);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
@@ -1002,6 +1003,13 @@ void i915_gem_context_release(struct kref *ref)
kfree_rcu(ctx, rcu);
}

+void i915_gem_context_release(struct kref *ref)
+{
+ struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
+
+ queue_work(ctx->i915->wq, &ctx->release_work);
+}
+
static inline struct i915_gem_engines *
__context_engines_static(const struct i915_gem_context *ctx)
{
@@ -1303,6 +1311,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
ctx->sched = pc->sched;
mutex_init(&ctx->mutex);
INIT_LIST_HEAD(&ctx->link);
+ INIT_WORK(&ctx->release_work, i915_gem_context_release_work);

spin_lock_init(&ctx->stale.lock);
INIT_LIST_HEAD(&ctx->stale.engines);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 94c03a97cb77..0c38789bd4a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -288,6 +288,18 @@ struct i915_gem_context {
 */
struct kref ref;

+ /**
+  * @release_work:
+  *
+  * Work item for deferred cleanup, since i915_gem_context_put() tends to
+  * be called from hardirq context.
+  *
+  * FIXME: The only real reason for this is &i915_gem_engines.fence, all
+  * other callers are from process context and need at most some mild
+  * shuffling to pull the i915_gem_contex

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL   : https://patchwork.freedesktop.org/series/94315/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10549 -> Patchwork_20950


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [PASS][2] -> [INCOMPLETE][3] ([i915#2940])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: NOTRUN -> [DMESG-WARN][4] ([i915#3958])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#1436] / 
[i915#2722] / [i915#3428])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/fi-bsw-kefka/igt@run...@aborted.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [DMESG-WARN][6] ([i915#3925]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10549/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20950/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (46 -> 38)
--

  Missing(8): bat-adls-5 fi-hsw-4200u bat-dg1-5 fi-bsw-cyan bat-adlp-4 
fi-bdw-samus fi-bsw-nick bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10549 -> Patchwork_20950

  CI-20190529: 20190529
  CI_DRM_10549: cd8e346a0b56ce66f94a9908c7a068bbee8f1829 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20950: e01543cc506e1d2393043b1a9d8816c343bd53c2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e01543cc506e drm/i915/gt: Initialize L3CC table in mocs init
effcee0badb7 drm/i915/gt: Initialize unused MOCS entries with device specific 
values
7e4b1d648a16 drm/i915/gt: Set BLIT_CCTL reg to un-cached
32be00b75838 drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward
a878ef44120d drm/i915/gt: Add support of mocs propagation

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/bios: get rid of vbt ddi_port_info

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:40 PM, Jani Nikula wrote:

We can finally remove the extra caching in ddi_port_info. Good riddance.

v2: Rebased

Cc: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 63 +--
  drivers/gpu/drm/i915/i915_drv.h   |  7 +--
  2 files changed, 25 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 0c16a848a6e4..052f27c0fb0c 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1580,16 +1580,16 @@ static u8 map_ddc_pin(struct drm_i915_private *i915, u8 
vbt_pin)
  
  static enum port get_port_by_ddc_pin(struct drm_i915_private *i915, u8 ddc_pin)

  {
-   const struct ddi_vbt_port_info *info;
+   const struct intel_bios_encoder_data *devdata;
enum port port;
  
  	if (!ddc_pin)

return PORT_NONE;
  
  	for_each_port(port) {

-   info = &i915->vbt.ddi_port_info[port];
+   devdata = i915->vbt.ports[port];
  
-		if (info->devdata && ddc_pin == info->devdata->child.ddc_pin)

+   if (devdata && ddc_pin == devdata->child.ddc_pin)
return port;
}
  
@@ -1600,7 +1600,6 @@ static void sanitize_ddc_pin(struct intel_bios_encoder_data *devdata,

 enum port port)
  {
struct drm_i915_private *i915 = devdata->i915;
-   struct ddi_vbt_port_info *info;
struct child_device_config *child;
u8 mapped_ddc_pin;
enum port p;
@@ -1637,8 +1636,7 @@ static void sanitize_ddc_pin(struct 
intel_bios_encoder_data *devdata,
 * there are real machines (eg. Asrock B250M-HDV) where VBT has both
 * port A and port E with the same AUX ch and we must pick port E :(
 */
-   info = &i915->vbt.ddi_port_info[p];
-   child = &info->devdata->child;
+   child = &i915->vbt.ports[p]->child;
  
  	child->device_type &= ~DEVICE_TYPE_TMDS_DVI_SIGNALING;

child->device_type |= DEVICE_TYPE_NOT_HDMI_OUTPUT;
@@ -1648,16 +1646,16 @@ static void sanitize_ddc_pin(struct 
intel_bios_encoder_data *devdata,
  
  static enum port get_port_by_aux_ch(struct drm_i915_private *i915, u8 aux_ch)

  {
-   const struct ddi_vbt_port_info *info;
+   const struct intel_bios_encoder_data *devdata;
enum port port;
  
  	if (!aux_ch)

return PORT_NONE;
  
  	for_each_port(port) {

-   info = &i915->vbt.ddi_port_info[port];
+   devdata = i915->vbt.ports[port];
  
-		if (info->devdata && aux_ch == info->devdata->child.aux_channel)

+   if (devdata && aux_ch == devdata->child.aux_channel)
return port;
}
  
@@ -1668,7 +1666,6 @@ static void sanitize_aux_ch(struct intel_bios_encoder_data *devdata,

enum port port)
  {
struct drm_i915_private *i915 = devdata->i915;
-   struct ddi_vbt_port_info *info;
struct child_device_config *child;
enum port p;
  
@@ -1691,8 +1688,7 @@ static void sanitize_aux_ch(struct intel_bios_encoder_data *devdata,

 * there are real machines (eg. Asrock B250M-HDV) where VBT has both
 * port A and port E with the same AUX ch and we must pick port E :(
 */
-   info = &i915->vbt.ddi_port_info[p];
-   child = &info->devdata->child;
+   child = &i915->vbt.ports[p]->child;
  
  	child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;

child->aux_channel = 0;
@@ -1938,7 +1934,6 @@ static void parse_ddi_port(struct drm_i915_private *i915,
   struct intel_bios_encoder_data *devdata)
  {
const struct child_device_config *child = &devdata->child;
-   struct ddi_vbt_port_info *info;
bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb, 
supports_tbt;
int dp_boost_level, dp_max_link_rate, hdmi_boost_level, 
hdmi_level_shift, max_tmds_clock;
enum port port;
@@ -1954,9 +1949,7 @@ static void parse_ddi_port(struct drm_i915_private *i915,
return;
}
  
-	info = &i915->vbt.ddi_port_info[port];

-
-   if (info->devdata) {
+   if (i915->vbt.ports[port]) {
drm_dbg_kms(&i915->drm,
"More than one child device for port %c in VBT, using 
the first.\n",
port_name(port));
@@ -2019,7 +2012,7 @@ static void parse_ddi_port(struct drm_i915_private *i915,
"Port %c VBT DP max link rate: %d\n",
port_name(port), dp_max_link_rate);
  
-	info->devdata = devdata;

+   i915->vbt.ports[port] = devdata;
  }
  
  static void parse_ddi_ports(struct drm_i915_private *i915)

@@ -2557,12 +2550,8 @@ bool intel_bios_is_port_present(struct drm_i915_private 
*i915, enum port port)
[PORT_F] = { DVO_PORT_DPF, 

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/bios: use ddc pin directly from child data

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:40 PM, Jani Nikula wrote:

Avoid extra caching of the data. This is slightly more subtle than one
would think. For one thing, we explicitly ignore 0 value in child device
ddc pin; this is specified as N/A and does not warrant a warning. For
another, we start looking for ddc pin collisions in sanitize using
unmapped pin numbering.

v2: Check !devdata in intel_bios_alternate_ddc_pin()

Cc: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 49 +--
  drivers/gpu/drm/i915/i915_drv.h   |  2 -
  2 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index b4113506b3b8..0c16a848a6e4 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1589,28 +1589,43 @@ static enum port get_port_by_ddc_pin(struct 
drm_i915_private *i915, u8 ddc_pin)
for_each_port(port) {
info = &i915->vbt.ddi_port_info[port];
  
-		if (info->devdata && ddc_pin == info->alternate_ddc_pin)

+   if (info->devdata && ddc_pin == info->devdata->child.ddc_pin)
return port;
}
  
  	return PORT_NONE;

  }
  
-static void sanitize_ddc_pin(struct drm_i915_private *i915,

+static void sanitize_ddc_pin(struct intel_bios_encoder_data *devdata,
 enum port port)
  {
-   struct ddi_vbt_port_info *info = &i915->vbt.ddi_port_info[port];
+   struct drm_i915_private *i915 = devdata->i915;
+   struct ddi_vbt_port_info *info;
struct child_device_config *child;
+   u8 mapped_ddc_pin;
enum port p;
  
-	p = get_port_by_ddc_pin(i915, info->alternate_ddc_pin);

+   if (!devdata->child.ddc_pin)
+   return;
+
+   mapped_ddc_pin = map_ddc_pin(i915, devdata->child.ddc_pin);
+   if (!intel_gmbus_is_valid_pin(i915, mapped_ddc_pin)) {
+   drm_dbg_kms(&i915->drm,
+   "Port %c has invalid DDC pin %d, "
+   "sticking to defaults\n",
+   port_name(port), mapped_ddc_pin);
+   devdata->child.ddc_pin = 0;
+   return;
+   }
+
+   p = get_port_by_ddc_pin(i915, devdata->child.ddc_pin);
if (p == PORT_NONE)
return;
  
  	drm_dbg_kms(&i915->drm,

"port %c trying to use the same DDC pin (0x%x) as port %c, "
"disabling port %c DVI/HDMI support\n",
-   port_name(port), info->alternate_ddc_pin,
+   port_name(port), mapped_ddc_pin,
port_name(p), port_name(p));
  
  	/*

@@ -1628,7 +1643,7 @@ static void sanitize_ddc_pin(struct drm_i915_private 
*i915,
child->device_type &= ~DEVICE_TYPE_TMDS_DVI_SIGNALING;
child->device_type |= DEVICE_TYPE_NOT_HDMI_OUTPUT;
  
-	info->alternate_ddc_pin = 0;

+   child->ddc_pin = 0;
  }
  
  static enum port get_port_by_aux_ch(struct drm_i915_private *i915, u8 aux_ch)

@@ -1966,20 +1981,8 @@ static void parse_ddi_port(struct drm_i915_private *i915,
supports_typec_usb, supports_tbt,
devdata->dsc != NULL);
  
-	if (is_dvi) {

-   u8 ddc_pin;
-
-   ddc_pin = map_ddc_pin(i915, child->ddc_pin);
-   if (intel_gmbus_is_valid_pin(i915, ddc_pin)) {
-   info->alternate_ddc_pin = ddc_pin;
-   sanitize_ddc_pin(i915, port);
-   } else {
-   drm_dbg_kms(&i915->drm,
-   "Port %c has invalid DDC pin %d, "
-   "sticking to defaults\n",
-   port_name(port), ddc_pin);
-   }
-   }
+   if (is_dvi)
+   sanitize_ddc_pin(devdata, port);
  
  	if (is_dp)

sanitize_aux_ch(devdata, port);
@@ -2993,8 +2996,12 @@ int intel_bios_dp_max_link_rate(struct intel_encoder 
*encoder)
  int intel_bios_alternate_ddc_pin(struct intel_encoder *encoder)
  {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   const struct intel_bios_encoder_data *devdata = 
i915->vbt.ddi_port_info[encoder->port].devdata;
+
+   if (!devdata || !devdata->child.ddc_pin)
+   return 0;
  
-	return i915->vbt.ddi_port_info[encoder->port].alternate_ddc_pin;

+   return map_ddc_pin(i915, devdata->child.ddc_pin);
  }
  
  bool intel_bios_encoder_supports_typec_usb(const struct intel_bios_encoder_data *devdata)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 032d59119407..744181cbe21c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -638,8 +638,6 @@ i915_fence_timeout(const struct drm_i915_private *i915)
  struct ddi_vbt_port_info {
/* Non-NULL if port pr

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/bios: move ddc pin mapping code next to ddc pin sanitize

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:40 PM, Jani Nikula wrote:

Move code around to avoid a forward declaration in the future.

Cc: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 154 +++---
  1 file changed, 77 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 69d7da66f168..b4113506b3b8 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1501,6 +1501,83 @@ static u8 translate_iboost(u8 val)
return mapping[val];
  }
  
+static const u8 cnp_ddc_pin_map[] = {

+   [0] = 0, /* N/A */
+   [DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT,
+   [DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT,
+   [DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */
+   [DDC_BUS_DDI_F] = GMBUS_PIN_3_BXT, /* sic */
+};
+
+static const u8 icp_ddc_pin_map[] = {
+   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
+   [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
+   [TGL_DDC_BUS_DDI_C] = GMBUS_PIN_3_BXT,
+   [ICL_DDC_BUS_PORT_1] = GMBUS_PIN_9_TC1_ICP,
+   [ICL_DDC_BUS_PORT_2] = GMBUS_PIN_10_TC2_ICP,
+   [ICL_DDC_BUS_PORT_3] = GMBUS_PIN_11_TC3_ICP,
+   [ICL_DDC_BUS_PORT_4] = GMBUS_PIN_12_TC4_ICP,
+   [TGL_DDC_BUS_PORT_5] = GMBUS_PIN_13_TC5_TGP,
+   [TGL_DDC_BUS_PORT_6] = GMBUS_PIN_14_TC6_TGP,
+};
+
+static const u8 rkl_pch_tgp_ddc_pin_map[] = {
+   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
+   [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
+   [RKL_DDC_BUS_DDI_D] = GMBUS_PIN_9_TC1_ICP,
+   [RKL_DDC_BUS_DDI_E] = GMBUS_PIN_10_TC2_ICP,
+};
+
+static const u8 adls_ddc_pin_map[] = {
+   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
+   [ADLS_DDC_BUS_PORT_TC1] = GMBUS_PIN_9_TC1_ICP,
+   [ADLS_DDC_BUS_PORT_TC2] = GMBUS_PIN_10_TC2_ICP,
+   [ADLS_DDC_BUS_PORT_TC3] = GMBUS_PIN_11_TC3_ICP,
+   [ADLS_DDC_BUS_PORT_TC4] = GMBUS_PIN_12_TC4_ICP,
+};
+
+static const u8 gen9bc_tgp_ddc_pin_map[] = {
+   [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
+   [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
+   [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
+};
+
+static u8 map_ddc_pin(struct drm_i915_private *i915, u8 vbt_pin)
+{
+   const u8 *ddc_pin_map;
+   int n_entries;
+
+   if (IS_ALDERLAKE_S(i915)) {
+   ddc_pin_map = adls_ddc_pin_map;
+   n_entries = ARRAY_SIZE(adls_ddc_pin_map);
+   } else if (INTEL_PCH_TYPE(i915) >= PCH_DG1) {
+   return vbt_pin;
+   } else if (IS_ROCKETLAKE(i915) && INTEL_PCH_TYPE(i915) == PCH_TGP) {
+   ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
+   n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
+   } else if (HAS_PCH_TGP(i915) && DISPLAY_VER(i915) == 9) {
+   ddc_pin_map = gen9bc_tgp_ddc_pin_map;
+   n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
+   } else if (INTEL_PCH_TYPE(i915) >= PCH_ICP) {
+   ddc_pin_map = icp_ddc_pin_map;
+   n_entries = ARRAY_SIZE(icp_ddc_pin_map);
+   } else if (HAS_PCH_CNP(i915)) {
+   ddc_pin_map = cnp_ddc_pin_map;
+   n_entries = ARRAY_SIZE(cnp_ddc_pin_map);
+   } else {
+   /* Assuming direct map */
+   return vbt_pin;
+   }
+
+   if (vbt_pin < n_entries && ddc_pin_map[vbt_pin] != 0)
+   return ddc_pin_map[vbt_pin];
+
+   drm_dbg_kms(&i915->drm,
+   "Ignoring alternate pin: VBT claims DDC pin %d, which is not 
valid for this platform\n",
+   vbt_pin);
+   return 0;
+}
+
  static enum port get_port_by_ddc_pin(struct drm_i915_private *i915, u8 
ddc_pin)
  {
const struct ddi_vbt_port_info *info;
@@ -1606,83 +1683,6 @@ static void sanitize_aux_ch(struct 
intel_bios_encoder_data *devdata,
child->aux_channel = 0;
  }
  
-static const u8 cnp_ddc_pin_map[] = {

-   [0] = 0, /* N/A */
-   [DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT,
-   [DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT,
-   [DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */
-   [DDC_BUS_DDI_F] = GMBUS_PIN_3_BXT, /* sic */
-};
-
-static const u8 icp_ddc_pin_map[] = {
-   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
-   [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
-   [TGL_DDC_BUS_DDI_C] = GMBUS_PIN_3_BXT,
-   [ICL_DDC_BUS_PORT_1] = GMBUS_PIN_9_TC1_ICP,
-   [ICL_DDC_BUS_PORT_2] = GMBUS_PIN_10_TC2_ICP,
-   [ICL_DDC_BUS_PORT_3] = GMBUS_PIN_11_TC3_ICP,
-   [ICL_DDC_BUS_PORT_4] = GMBUS_PIN_12_TC4_ICP,
-   [TGL_DDC_BUS_PORT_5] = GMBUS_PIN_13_TC5_TGP,
-   [TGL_DDC_BUS_PORT_6] = GMBUS_PIN_14_TC6_TGP,
-};
-
-static const u8 rkl_pch_tgp_ddc_pin_map[] = {
-   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
-   [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
-   [RKL_DDC_BUS_DDI_D] = GMBUS_PIN_9_TC1_ICP,
-   [RKL_DDC_BUS_DDI_E] = GMBUS_PIN_10_TC2_ICP,
-};
-
-static const u8 adls_ddc_pin_map[] = {
-   [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
-   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL   : https://patchwork.freedesktop.org/series/94315/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34:expected struct 
i915_address_space *vm
+drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34:got struct 
i915_address_space [noderef] __rcu *vm
+drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34: warning: incorrect type 
in argument 1 (different address spaces)
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:expected struct 
i915_address_space [noderef] __rcu *vm
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:got struct 
i915_address_space *
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25: warning: incorrect 
type in assignment (different address spaces)
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:expected struct 
i915_address_space *vm
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:got struct 
i915_address_space [noderef] __rcu *vm
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34: warning: incorrect 
type in argument 1 (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'g

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

[Maarten Lankhorst]

drm-misc-next-fixes-2021-09-03:
drm-misc-next-fixes for v5.15:
- Fix ttm_bo_move_memcpy() when ttm_resource is subclassed.
- Small fixes to panfrost, mgag200, vc4.
- Small ttm compilation fixes.
The following changes since commit 2819cf0e7dbe45a2bccf2f6c60fe6a27b299cc3e:

  Merge tag 'drm-misc-next-2021-08-12' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-08-16 12:57:33 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-09-03

for you to fetch changes up to efcefc7127290e7e9fa98dea029163ad8eda8fb3:

  drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource 
(2021-08-31 10:48:26 +0200)


drm-misc-next-fixes for v5.15:
- Fix ttm_bo_move_memcpy() when ttm_resource is subclassed.
- Small fixes to panfrost, mgag200, vc4.
- Small ttm compilation fixes.


Alyssa Rosenzweig (3):
  drm/panfrost: Simplify lock_region calculation
  drm/panfrost: Use u64 for size in lock_region
  drm/panfrost: Clamp lock region to Bifrost minimum

Colin Ian King (1):
  drm/mgag200: Fix uninitialized variable delta

Jason Ekstrand (2):
  drm/ttm: ttm_bo_device is now ttm_device
  drm/ttm: Include pagemap.h from ttm_tt.h

Jiapeng Chong (1):
  drm/vc4: hdmi: make vc4_hdmi_codec_pdata static

Thomas Hellström (1):
  drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

 Documentation/gpu/drm-mm.rst |  2 +-
 drivers/gpu/drm/mgag200/mgag200_pll.c|  1 +
 drivers/gpu/drm/panfrost/panfrost_mmu.c  | 31 +++
 drivers/gpu/drm/panfrost/panfrost_regs.h |  2 ++
 drivers/gpu/drm/ttm/ttm_bo_util.c|  7 +++
 drivers/gpu/drm/ttm/ttm_tt.c |  1 -
 drivers/gpu/drm/vc4/vc4_hdmi.c   |  2 +-
 include/drm/ttm/ttm_tt.h |  3 ++-
 8 files changed, 21 insertions(+), 28 deletions(-)

Re: [Intel-gfx] [PATCH 14/19] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind

[Maarten Lankhorst]

Op 30-08-2021 om 14:10 schreef Maarten Lankhorst:
> We want to remove more members of i915_vma, which requires the locking to be
> held more often.
>
> Start requiring gem object lock for i915_vma_unbind, as it's one of the
> callers that may unpin pages.
>
> Some special care is needed when evicting, because the last reference to the
> object may be held by the VMA, so after __i915_vma_unbind, vma may be garbage,
> and we need to cache vma->obj before unlocking.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  | 14 +++-
>  .../gpu/drm/i915/gem/selftests/huge_pages.c   |  4 +-
>  .../i915/gem/selftests/i915_gem_client_blt.c  |  2 +-
>  .../drm/i915/gem/selftests/i915_gem_mman.c|  6 ++
>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 46 ++--
>  drivers/gpu/drm/i915/i915_drv.h   |  7 +-
>  drivers/gpu/drm/i915/i915_gem.c   | 29 +++-
>  drivers/gpu/drm/i915/i915_gem_evict.c | 74 +--
>  drivers/gpu/drm/i915/i915_vma.c   | 27 ++-
>  drivers/gpu/drm/i915/i915_vma.h   |  1 +
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 22 +++---
>  drivers/gpu/drm/i915/selftests/i915_vma.c |  2 +-
>  13 files changed, 195 insertions(+), 41 deletions(-)

This patch breaks the selftests because lockdep doesn't like nested trylocks, 
and eviction needed some love.

I've split it out, and will resubmit this part, rest can still be reviewed as 
it doesn't affect that.

Re: [Intel-gfx] [PATCH 07/19] drm/i915: vma is always backed by an object.

[Maarten Lankhorst]

Op 31-08-2021 om 12:29 schreef Tvrtko Ursulin:
>
> On 31/08/2021 10:34, Maarten Lankhorst wrote:
>> Op 31-08-2021 om 11:18 schreef Tvrtko Ursulin:
>>>
>>> On 30/08/2021 13:09, Maarten Lankhorst wrote:
 vma->obj and vma->resv are now never NULL, and some checks can be removed.
>>>
>>> Is the direction here compatible with SVM / VM_BIND?
>>
>>
>> Yeah, it should be. The changes here make the obj->resv->lock the main lock, 
>> so it should at least simplify locking for VM_BIND.
>
> Hm but what will vma->obj point to in case of SVM, when there is no GEM BO? 

Probably to one of the bo's in i915_vm, or a dummy bo that least shares the 
vm_resv object, similar to the aliasing gtt handling.

[Intel-gfx] [PATCH V5 5/5] drm/i915/gt: Initialize L3CC table in mocs init

[Ayaz A Siddiqui]

From: Sreedhar Telukuntla 

Initialize the L3CC table as part of mocs initialization to program
LNCFCMOCSx registers so that the mocs settings are available for
selection for subsequent memory transactions in the driver load path.

We need to keep L3CC initialization in intel_mocs_init_engine() also
so that in execlists submission, these registers can be rewritten
during engine reset.

Reviewed-by: Matt Roper 
Signed-off-by: Sreedhar Telukuntla 
Signed-off-by: Ayaz A Siddiqui 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 552bfd1c113b1..e96afd7beb499 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -481,10 +481,9 @@ static u32 l3cc_combine(u16 low, u16 high)
 0; \
 i++)
 
-static void init_l3cc_table(struct intel_engine_cs *engine,
+static void init_l3cc_table(struct intel_uncore *uncore,
const struct drm_i915_mocs_table *table)
 {
-   struct intel_uncore *uncore = engine->uncore;
unsigned int i;
u32 l3cc;
 
@@ -509,7 +508,7 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
init_mocs_table(engine, &table);
 
if (flags & HAS_RENDER_L3CC && engine->class == RENDER_CLASS)
-   init_l3cc_table(engine, &table);
+   init_l3cc_table(engine->uncore, &table);
 }
 
 static u32 global_mocs_offset(void)
@@ -536,6 +535,14 @@ void intel_mocs_init(struct intel_gt *gt)
flags = get_mocs_settings(gt->i915, &table);
if (flags & HAS_GLOBAL_MOCS)
__init_mocs_table(gt->uncore, &table, global_mocs_offset());
+
+   /*
+* Initialize the L3CC table as part of mocs initalization to make
+* sure the LNCFCMOCSx registers are programmed for the subsequent
+* memory transactions including guc transactions
+*/
+   if (flags & HAS_RENDER_L3CC)
+   init_l3cc_table(gt->uncore, &table);
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
-- 
2.26.2

[Intel-gfx] [PATCH V5 4/5] drm/i915/gt: Initialize unused MOCS entries with device specific values

[Ayaz A Siddiqui]

Historically we've initialized all undefined/reserved entries in
a platform's MOCS table to the contents of table entry #1 (i.e.,
I915_MOCS_PTE).
Going forward, we can't assume that table entry #1 will always
contain suitable values to use for undefined/reserved table
indices. We'll allow a platform-specific table index to be
selected at table initialization time in these cases.

This new mechanism to select L3 WB entry will be applicable for
all the Gen12+ platforms except TGL and RKL.

Since TGL and RLK are already in production so their mocs settings
are intact to avoid ABI break.

Reviewed-by: Matt Roper 
Signed-off-by: Ayaz A Siddiqui 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 46 
 1 file changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 7ccac15d9a331..552bfd1c113b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
unsigned int n_entries;
const struct drm_i915_mocs_entry *table;
u8 uc_index;
+   u8 unused_entries_index;
 };
 
 /* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
@@ -89,18 +90,25 @@ struct drm_i915_mocs_table {
  *
  * Entries not part of the following tables are undefined as far as
  * userspace is concerned and shouldn't be relied upon.  For Gen < 12
- * they will be initialized to PTE. Gen >= 12 onwards don't have a setting for
- * PTE and will be initialized to an invalid value.
+ * they will be initialized to PTE. Gen >= 12 don't have a setting for
+ * PTE and those platforms except TGL/RKL will be initialized L3 WB to
+ * catch accidental use of reserved and unused mocs indexes.
  *
  * The last few entries are reserved by the hardware. For ICL+ they
  * should be initialized according to bspec and never used, for older
  * platforms they should never be written to.
  *
- * NOTE: These tables are part of bspec and defined as part of hardware
+ * NOTE1: These tables are part of bspec and defined as part of hardware
  *   interface for ICL+. For older platforms, they are part of kernel
  *   ABI. It is expected that, for specific hardware platform, existing
  *   entries will remain constant and the table will only be updated by
  *   adding new entries, filling unused positions.
+ *
+ * NOTE2: For GEN >= 12 except TGL and RKL, reserved and unspecified MOCS
+ *   indices have been set to L3 WB. These reserved entries should never
+ *   be used, they may be changed to low performant variants with better
+ *   coherency in the future if more entries are needed.
+ *   For TGL/RKL, all the unspecified MOCS indexes are mapped to L3 UC.
  */
 #define GEN9_MOCS_ENTRIES \
MOCS_ENTRY(I915_MOCS_UNCACHED, \
@@ -283,17 +291,9 @@ static const struct drm_i915_mocs_entry icl_mocs_table[] = 
{
 };
 
 static const struct drm_i915_mocs_entry dg1_mocs_table[] = {
-   /* Error */
-   MOCS_ENTRY(0, 0, L3_0_DIRECT),
 
/* UC */
MOCS_ENTRY(1, 0, L3_1_UC),
-
-   /* Reserved */
-   MOCS_ENTRY(2, 0, L3_0_DIRECT),
-   MOCS_ENTRY(3, 0, L3_0_DIRECT),
-   MOCS_ENTRY(4, 0, L3_0_DIRECT),
-
/* WB - L3 */
MOCS_ENTRY(5, 0, L3_3_WB),
/* WB - L3 50% */
@@ -343,16 +343,22 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
 
memset(table, 0, sizeof(struct drm_i915_mocs_table));
 
+   table->unused_entries_index = I915_MOCS_PTE;
if (IS_DG1(i915)) {
table->size = ARRAY_SIZE(dg1_mocs_table);
table->table = dg1_mocs_table;
table->uc_index = 1;
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
+   table->uc_index = 1;
+   table->unused_entries_index = 5;
} else if (GRAPHICS_VER(i915) >= 12) {
table->size  = ARRAY_SIZE(tgl_mocs_table);
table->table = tgl_mocs_table;
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->uc_index = 3;
+   /* For TGL/RKL, Can't be changed now for ABI reasons */
+   if (!IS_TIGERLAKE(i915) && !IS_ROCKETLAKE(i915))
+   table->unused_entries_index = 2;
} else if (GRAPHICS_VER(i915) == 11) {
table->size  = ARRAY_SIZE(icl_mocs_table);
table->table = icl_mocs_table;
@@ -398,16 +404,16 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
 }
 
 /*
- * Get control_value from MOCS entry taking into account when it's not used:
- * I915_MOCS_PTE's value is returned in this case.
+ * Get control_value from MOCS entry taking into account when it's not used
+ * then if unused_entries_index is non-zero then its value will be returned
+ * otherwise I915_MOCS_PTE's value is returned in this case.
  */
 static u32 get_entry_control(const struct drm_i915_mocs_table *table,
 

[Intel-gfx] [PATCH V5 3/5] drm/i915/gt: Set BLIT_CCTL reg to un-cached

[Ayaz A Siddiqui]

Blitter commands which do not have MOCS fields rely on
cacheability of BlitterCacheControlRegister which was mapped
to index 0 by default.Once we changed the MOCS value of
index 0 to L3 WB, tests like gem_linear_blits started failing
due to a change in cacheability from UC to WB.

Program and place the BlitterCacheControlRegister in
build_aux_regs().

Reviewed-by: Matt Roper 
Signed-off-by: Ayaz A Siddiqui 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 -
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index ef7255a44b9a1..c314d4917b6b4 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -675,6 +675,41 @@ static void fakewa_disable_nestedbb_mode(struct 
intel_engine_cs *engine,
wa_masked_dis(wal, RING_MI_MODE(engine->mmio_base), TGL_NESTED_BB_EN);
 }
 
+static void gen12_ctx_gt_mocs_init(struct intel_engine_cs *engine,
+  struct i915_wa_list *wal)
+{
+   u8 mocs;
+
+   /*
+* Some blitter commands do not have a field for MOCS, those
+* commands will use MOCS index pointed by BLIT_CCTL.
+* BLIT_CCTL registers are needed to be programmed to un-cached.
+*/
+   if (engine->class == COPY_ENGINE_CLASS) {
+   mocs = engine->gt->mocs.uc_index;
+   wa_write_clr_set(wal,
+BLIT_CCTL(engine->mmio_base),
+BLIT_CCTL_MASK,
+BLIT_CCTL_MOCS(mocs, mocs));
+   }
+}
+
+/*
+ * gen12_ctx_gt_fake_wa_init() aren't programmingan official workaround
+ * defined by the hardware team, but it programming general context registers.
+ * Adding those context register programming in context workaround
+ * allow us to use the wa framework for proper application and validation.
+ */
+static void
+gen12_ctx_gt_fake_wa_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
+{
+   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+   fakewa_disable_nestedbb_mode(engine, wal);
+
+   gen12_ctx_gt_mocs_init(engine, wal);
+}
+
 static void
 __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
   struct i915_wa_list *wal,
@@ -685,8 +720,12 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
wa_init_start(wal, name, engine->name);
 
/* Applies to all engines */
-   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55))
-   fakewa_disable_nestedbb_mode(engine, wal);
+   /*
+* Fake workarounds are not the actual workaround but
+* programming of context registers using workaround framework.
+*/
+   if (GRAPHICS_VER(i915) >= 12)
+   gen12_ctx_gt_fake_wa_init(engine, wal);
 
if (engine->class != RENDER_CLASS)
goto done;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c68b4cf3d7188..c2853cc005ee6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2572,6 +2572,15 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
(REG_FIELD_PREP(CMD_CCTL_WRITE_OVERRIDE_MASK, (write) << 1) | \
 REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, (read) << 1))
 
+#define BLIT_CCTL(base) _MMIO((base) + 0x204)
+#define   BLIT_CCTL_DST_MOCS_MASK   REG_GENMASK(14, 8)
+#define   BLIT_CCTL_SRC_MOCS_MASK   REG_GENMASK(6, 0)
+#define   BLIT_CCTL_MASK (BLIT_CCTL_DST_MOCS_MASK | \
+ BLIT_CCTL_SRC_MOCS_MASK)
+#define   BLIT_CCTL_MOCS(dst, src)\
+   (REG_FIELD_PREP(BLIT_CCTL_DST_MOCS_MASK, (dst) << 1) | \
+REG_FIELD_PREP(BLIT_CCTL_SRC_MOCS_MASK, (src) << 1))
+
 #define RING_RESET_CTL(base)   _MMIO((base) + 0xd0)
 #define   RESET_CTL_CAT_ERROR REG_BIT(2)
 #define   RESET_CTL_READY_TO_RESET REG_BIT(1)
-- 
2.26.2

[Intel-gfx] [PATCH V5 2/5] drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward

[Ayaz A Siddiqui]

Cache-control registers for Command Stream(CMD_CCTL) are used
to set catchability for memory writes and reads outputted by
Command Streamers on Gen12 onward platforms.

These registers need to point un-cached(UC) MOCS index.

Reviewed-by: Matt Roper 
Signed-off-by: Ayaz A Siddiqui 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 +
 drivers/gpu/drm/i915/i915_reg.h | 17 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 94e1937f8d296..ef7255a44b9a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1640,6 +1640,31 @@ void intel_engine_apply_whitelist(struct intel_engine_cs 
*engine)
   i915_mmio_reg_offset(RING_NOPID(base)));
 }
 
+/*
+ * engine_fake_wa_init(), a place holder to program the registers
+ * which are not part of an official workaround defined by the
+ * hardware team.
+ * Adding programming of those register inside workaround will
+ * allow utilizing wa framework to proper application and verification.
+ */
+static void
+engine_fake_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
+{
+   u8 mocs;
+
+   /*
+* RING_CMD_CCTL are need to be programed to un-cached
+* for memory writes and reads outputted by Command
+* Streamers on Gen12 onward platforms.
+*/
+   if (GRAPHICS_VER(engine->i915) >= 12) {
+   mocs = engine->gt->mocs.uc_index;
+   wa_masked_field_set(wal,
+   RING_CMD_CCTL(engine->mmio_base),
+   CMD_CCTL_MOCS_MASK,
+   CMD_CCTL_MOCS_OVERRIDE(mocs, mocs));
+   }
+}
 static void
 rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
 {
@@ -2080,6 +2105,8 @@ engine_init_workarounds(struct intel_engine_cs *engine, 
struct i915_wa_list *wal
if (I915_SELFTEST_ONLY(GRAPHICS_VER(engine->i915) < 4))
return;
 
+   engine_fake_wa_init(engine, wal);
+
if (engine->class == RENDER_CLASS)
rcs_engine_wa_init(engine, wal);
else
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 313432ed61964..c68b4cf3d7188 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2555,6 +2555,23 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define RING_HWS_PGA(base) _MMIO((base) + 0x80)
 #define RING_ID(base)  _MMIO((base) + 0x8c)
 #define RING_HWS_PGA_GEN6(base)_MMIO((base) + 0x2080)
+
+#define RING_CMD_CCTL(base)_MMIO((base) + 0xc4)
+/*
+ * CMD_CCTL read/write fields take a MOCS value and _not_ a table index.
+ * The lsb of each can be considered a separate enabling bit for encryption.
+ * 6:0 == default MOCS value for reads  =>  6:1 == table index for reads.
+ * 13:7 == default MOCS value for writes => 13:8 == table index for writes.
+ * 15:14 == Reserved => 31:30 are set to 0.
+ */
+#define CMD_CCTL_WRITE_OVERRIDE_MASK REG_GENMASK(13, 7)
+#define CMD_CCTL_READ_OVERRIDE_MASK REG_GENMASK(6, 0)
+#define CMD_CCTL_MOCS_MASK (CMD_CCTL_WRITE_OVERRIDE_MASK | \
+   CMD_CCTL_READ_OVERRIDE_MASK)
+#define CMD_CCTL_MOCS_OVERRIDE(write, read)  \
+   (REG_FIELD_PREP(CMD_CCTL_WRITE_OVERRIDE_MASK, (write) << 1) | \
+REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, (read) << 1))
+
 #define RING_RESET_CTL(base)   _MMIO((base) + 0xd0)
 #define   RESET_CTL_CAT_ERROR REG_BIT(2)
 #define   RESET_CTL_READY_TO_RESET REG_BIT(1)
-- 
2.26.2

[Intel-gfx] [PATCH V5 1/5] drm/i915/gt: Add support of mocs propagation

[Ayaz A Siddiqui]

Now there are lots of Command and registers that require mocs index
programming.
So propagating mocs_index from mocs to gt so that it can be
used directly without having platform-specific checks.

V2:
Changed 'i915_mocs_index_gt' to anonymous structure.

Cc: CQ Tang
Reviewed-by: Matt Roper 
Signed-off-by: Ayaz A Siddiqui 
---
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 ++
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  4 
 drivers/gpu/drm/i915/gt/intel_mocs.c | 13 +
 drivers/gpu/drm/i915/gt/intel_mocs.h |  1 +
 4 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 62d40c9866427..2aeaae036a6f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -682,6 +682,8 @@ int intel_gt_init(struct intel_gt *gt)
goto err_pm;
}
 
+   set_mocs_index(gt);
+
err = intel_engines_init(gt);
if (err)
goto err_engines;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index a81e21bf1bd1a..6fdcde64c1800 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -192,6 +192,10 @@ struct intel_gt {
 
unsigned long mslice_mask;
} info;
+
+   struct {
+   u8 uc_index;
+   } mocs;
 };
 
 enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 582c4423b95d6..7ccac15d9a331 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -22,6 +22,7 @@ struct drm_i915_mocs_table {
unsigned int size;
unsigned int n_entries;
const struct drm_i915_mocs_entry *table;
+   u8 uc_index;
 };
 
 /* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
@@ -340,14 +341,18 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
 {
unsigned int flags;
 
+   memset(table, 0, sizeof(struct drm_i915_mocs_table));
+
if (IS_DG1(i915)) {
table->size = ARRAY_SIZE(dg1_mocs_table);
table->table = dg1_mocs_table;
+   table->uc_index = 1;
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
} else if (GRAPHICS_VER(i915) >= 12) {
table->size  = ARRAY_SIZE(tgl_mocs_table);
table->table = tgl_mocs_table;
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
+   table->uc_index = 3;
} else if (GRAPHICS_VER(i915) == 11) {
table->size  = ARRAY_SIZE(icl_mocs_table);
table->table = icl_mocs_table;
@@ -504,6 +509,14 @@ static u32 global_mocs_offset(void)
return i915_mmio_reg_offset(GEN12_GLOBAL_MOCS(0));
 }
 
+void set_mocs_index(struct intel_gt *gt)
+{
+   struct drm_i915_mocs_table table;
+
+   get_mocs_settings(gt->i915, &table);
+   gt->mocs.uc_index = table.uc_index;
+}
+
 void intel_mocs_init(struct intel_gt *gt)
 {
struct drm_i915_mocs_table table;
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h 
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index d83274f5163bd..8a09d64b115f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -36,5 +36,6 @@ struct intel_gt;
 
 void intel_mocs_init(struct intel_gt *gt);
 void intel_mocs_init_engine(struct intel_engine_cs *engine);
+void set_mocs_index(struct intel_gt *gt);
 
 #endif
-- 
2.26.2

[Intel-gfx] [PATCH V5 0/5] drm/i915/gt: Initialize unused MOCS entries to L3_WB

[Ayaz A Siddiqui]

Gen >= 12 onwards MOCS table doesn't have a setting for PTE
so I915_MOCS_PTE is not a valid index and it will have different
MOCS values are based on the platform.

To detect these kinds of misprogramming, all the unspecified and
reserved MOCS indexes are set to WB_L3. TGL/RKL unspecified MOCS
indexes are pointing to L3 UC are kept intact to avoid API break.

This series also contains patches to program BLIT_CCTL and
CMD_CCTL registers to UC.
Since we are quite late to update MOCS table for TGL so added
a new MOCS table for ADL family.

V2:
 1. Added CMD_CCTL to GUC regset list so that it can be restored
after engine reset.
 2. Checkpatch warning removal.

V3:
 1. Changed implementation to have a framework only.
 2. Added register type for proper application.
 3. moved CMD_CCTL programming to a separate patch.
 4. Added L3CC initialization during gt reset so that MOCS indexes are
set before GuC initialization.
 5. Removed Renderer check for L3CC verification in selftest.

V4:
 1. Moved register programming in Workaorund section as fake workaround.
 2. Removed seperate ADL mocs table, new logic is to set unused index as
L3_WB for gen12 platform except TGL/RKL.

V5:
 1. Final version reviewed by Matt Roper
 2. Removed "drm/i915/selftest: Remove Renderer class check for l3cc table 
read" form series,
this patch will be taken care of in different series.

Ayaz A Siddiqui (4):
  drm/i915/gt: Add support of mocs propagation
  drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward
  drm/i915/gt: Set BLIT_CCTL reg to un-cached
  drm/i915/gt: Initialize unused MOCS entries with device specific
values

Sreedhar Telukuntla (1):
  drm/i915/gt: Initialize L3CC table in mocs init

 drivers/gpu/drm/i915/gt/intel_gt.c  |  2 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h|  4 ++
 drivers/gpu/drm/i915/gt/intel_mocs.c| 72 ++---
 drivers/gpu/drm/i915/gt/intel_mocs.h|  1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 70 +++-
 drivers/gpu/drm/i915/i915_reg.h | 26 
 6 files changed, 151 insertions(+), 24 deletions(-)

-- 
2.26.2

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/bios: use alternate aux channel directly from child data

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:40 PM, Jani Nikula wrote:

Avoid extra caching of the data.

v2: Check for !info->devdata in intel_bios_port_aux_ch() (Ankit)

Cc: José Roberto de Souza 
Cc: Ankit Nautiyal 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 26 +++
  drivers/gpu/drm/i915/i915_drv.h   |  1 -
  2 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 10b2beddc121..69d7da66f168 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1565,28 +1565,29 @@ static enum port get_port_by_aux_ch(struct 
drm_i915_private *i915, u8 aux_ch)
for_each_port(port) {
info = &i915->vbt.ddi_port_info[port];
  
-		if (info->devdata && aux_ch == info->alternate_aux_channel)

+   if (info->devdata && aux_ch == info->devdata->child.aux_channel)
return port;
}
  
  	return PORT_NONE;

  }
  
-static void sanitize_aux_ch(struct drm_i915_private *i915,

+static void sanitize_aux_ch(struct intel_bios_encoder_data *devdata,
enum port port)
  {
-   struct ddi_vbt_port_info *info = &i915->vbt.ddi_port_info[port];
+   struct drm_i915_private *i915 = devdata->i915;
+   struct ddi_vbt_port_info *info;
struct child_device_config *child;
enum port p;
  
-	p = get_port_by_aux_ch(i915, info->alternate_aux_channel);

+   p = get_port_by_aux_ch(i915, devdata->child.aux_channel);
if (p == PORT_NONE)
return;
  
  	drm_dbg_kms(&i915->drm,

"port %c trying to use the same AUX CH (0x%x) as port %c, "
"disabling port %c DP support\n",
-   port_name(port), info->alternate_aux_channel,
+   port_name(port), devdata->child.aux_channel,
port_name(p), port_name(p));
  
  	/*

@@ -1602,7 +1603,7 @@ static void sanitize_aux_ch(struct drm_i915_private *i915,
child = &info->devdata->child;
  
  	child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;

-   info->alternate_aux_channel = 0;
+   child->aux_channel = 0;
  }
  
  static const u8 cnp_ddc_pin_map[] = {

@@ -1980,11 +1981,8 @@ static void parse_ddi_port(struct drm_i915_private *i915,
}
}
  
-	if (is_dp) {

-   info->alternate_aux_channel = child->aux_channel;
-
-   sanitize_aux_ch(i915, port);
-   }
+   if (is_dp)
+   sanitize_aux_ch(devdata, port);
  
  	hdmi_level_shift = _intel_bios_hdmi_level_shift(devdata);

if (hdmi_level_shift >= 0) {
@@ -2863,7 +2861,7 @@ enum aux_ch intel_bios_port_aux_ch(struct 
drm_i915_private *i915,
&i915->vbt.ddi_port_info[port];
enum aux_ch aux_ch;
  
-	if (!info->alternate_aux_channel) {

+   if (!info->devdata || !info->devdata->child.aux_channel) {
aux_ch = (enum aux_ch)port;
  
  		drm_dbg_kms(&i915->drm,

@@ -2879,7 +2877,7 @@ enum aux_ch intel_bios_port_aux_ch(struct 
drm_i915_private *i915,
 * ADL-S VBT uses PHY based mapping. Combo PHYs A,B,C,D,E
 * map to DDI A,TC1,TC2,TC3,TC4 respectively.
 */
-   switch (info->alternate_aux_channel) {
+   switch (info->devdata->child.aux_channel) {
case DP_AUX_A:
aux_ch = AUX_CH_A;
break;
@@ -2940,7 +2938,7 @@ enum aux_ch intel_bios_port_aux_ch(struct 
drm_i915_private *i915,
aux_ch = AUX_CH_I;
break;
default:
-   MISSING_CASE(info->alternate_aux_channel);
+   MISSING_CASE(info->devdata->child.aux_channel);
aux_ch = AUX_CH_A;
break;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 586b5368d4fc..032d59119407 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -639,7 +639,6 @@ struct ddi_vbt_port_info {
/* Non-NULL if port present. */
struct intel_bios_encoder_data *devdata;
  
-	u8 alternate_aux_channel;

u8 alternate_ddc_pin;
  };
  

Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/bios: use dp max link rate directly from child data

[Nautiyal, Ankit K]

A small nitpick below:

Otherwise the patch looks good to me.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:40 PM, Jani Nikula wrote:

Avoid extra caching of the data.

Cc: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 28 ++-
  drivers/gpu/drm/i915/i915_drv.h   |  2 --
  2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 253a528ba61a..10b2beddc121 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1815,6 +1815,17 @@ static int parse_bdb_216_dp_max_link_rate(const int 
vbt_max_link_rate)
}
  }
  
+static int _intel_bios_dp_max_link_rate(const struct intel_bios_encoder_data *devdata)

+{
+   if (!devdata || devdata->i915->vbt.version < 216)
+   return 0;
+
+   if (devdata->i915->vbt.version >= 230)
+   return 
parse_bdb_230_dp_max_link_rate(devdata->child.dp_max_link_rate);
+   else
+   return 
parse_bdb_216_dp_max_link_rate(devdata->child.dp_max_link_rate);


Can do away with else.

Regards,

Ankit


+}
+
  static void sanitize_device_type(struct intel_bios_encoder_data *devdata,
 enum port port)
  {
@@ -1913,7 +1924,7 @@ static void parse_ddi_port(struct drm_i915_private *i915,
const struct child_device_config *child = &devdata->child;
struct ddi_vbt_port_info *info;
bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb, 
supports_tbt;
-   int dp_boost_level, hdmi_boost_level, hdmi_level_shift, max_tmds_clock;
+   int dp_boost_level, dp_max_link_rate, hdmi_boost_level, 
hdmi_level_shift, max_tmds_clock;
enum port port;
  
  	port = dvo_port_to_port(i915, child->dvo_port);

@@ -2001,17 +2012,11 @@ static void parse_ddi_port(struct drm_i915_private 
*i915,
"Port %c VBT HDMI boost level: %d\n",
port_name(port), hdmi_boost_level);
  
-	/* DP max link rate for GLK+ */

-   if (i915->vbt.version >= 216) {
-   if (i915->vbt.version >= 230)
-   info->dp_max_link_rate = 
parse_bdb_230_dp_max_link_rate(child->dp_max_link_rate);
-   else
-   info->dp_max_link_rate = 
parse_bdb_216_dp_max_link_rate(child->dp_max_link_rate);
-
+   dp_max_link_rate = _intel_bios_dp_max_link_rate(devdata);
+   if (dp_max_link_rate)
drm_dbg_kms(&i915->drm,
"Port %c VBT DP max link rate: %d\n",
-   port_name(port), info->dp_max_link_rate);
-   }
+   port_name(port), dp_max_link_rate);
  
  	info->devdata = devdata;

  }
@@ -2982,8 +2987,9 @@ int intel_bios_encoder_hdmi_boost_level(const struct 
intel_bios_encoder_data *de
  int intel_bios_dp_max_link_rate(struct intel_encoder *encoder)
  {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   const struct intel_bios_encoder_data *devdata = 
i915->vbt.ddi_port_info[encoder->port].devdata;
  
-	return i915->vbt.ddi_port_info[encoder->port].dp_max_link_rate;

+   return _intel_bios_dp_max_link_rate(devdata);
  }
  
  int intel_bios_alternate_ddc_pin(struct intel_encoder *encoder)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8b4a31265978..586b5368d4fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -641,8 +641,6 @@ struct ddi_vbt_port_info {
  
  	u8 alternate_aux_channel;

u8 alternate_ddc_pin;
-
-   int dp_max_link_rate;   /* 0 for not limited by VBT */
  };
  
  enum psr_lines_to_wait {

Re: [Intel-gfx] [PATCH v2 2/7] drm/i915/bios: use max tmds clock directly from child data

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:40 PM, Jani Nikula wrote:

Avoid extra caching of the data.

Cc: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 52 +++
  drivers/gpu/drm/i915/i915_drv.h   |  2 -
  2 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index afb5fcd9dd0c..253a528ba61a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1876,6 +1876,24 @@ static int _intel_bios_hdmi_level_shift(const struct 
intel_bios_encoder_data *de
return devdata->child.hdmi_level_shifter_value;
  }
  
+static int _intel_bios_max_tmds_clock(const struct intel_bios_encoder_data *devdata)

+{
+   if (!devdata || devdata->i915->vbt.version < 204)
+   return 0;
+
+   switch (devdata->child.hdmi_max_data_rate) {
+   default:
+   MISSING_CASE(devdata->child.hdmi_max_data_rate);
+   fallthrough;
+   case HDMI_MAX_DATA_RATE_PLATFORM:
+   return 0;
+   case HDMI_MAX_DATA_RATE_297:
+   return 297000;
+   case HDMI_MAX_DATA_RATE_165:
+   return 165000;
+   }
+}
+
  static bool is_port_valid(struct drm_i915_private *i915, enum port port)
  {
/*
@@ -1895,7 +1913,7 @@ static void parse_ddi_port(struct drm_i915_private *i915,
const struct child_device_config *child = &devdata->child;
struct ddi_vbt_port_info *info;
bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb, 
supports_tbt;
-   int dp_boost_level, hdmi_boost_level, hdmi_level_shift;
+   int dp_boost_level, hdmi_boost_level, hdmi_level_shift, max_tmds_clock;
enum port port;
  
  	port = dvo_port_to_port(i915, child->dvo_port);

@@ -1964,30 +1982,11 @@ static void parse_ddi_port(struct drm_i915_private 
*i915,
port_name(port), hdmi_level_shift);
}
  
-	if (i915->vbt.version >= 204) {

-   int max_tmds_clock;
-
-   switch (child->hdmi_max_data_rate) {
-   default:
-   MISSING_CASE(child->hdmi_max_data_rate);
-   fallthrough;
-   case HDMI_MAX_DATA_RATE_PLATFORM:
-   max_tmds_clock = 0;
-   break;
-   case HDMI_MAX_DATA_RATE_297:
-   max_tmds_clock = 297000;
-   break;
-   case HDMI_MAX_DATA_RATE_165:
-   max_tmds_clock = 165000;
-   break;
-   }
-
-   if (max_tmds_clock)
-   drm_dbg_kms(&i915->drm,
-   "Port %c VBT HDMI max TMDS clock: %d kHz\n",
-   port_name(port), max_tmds_clock);
-   info->max_tmds_clock = max_tmds_clock;
-   }
+   max_tmds_clock = _intel_bios_max_tmds_clock(devdata);
+   if (max_tmds_clock)
+   drm_dbg_kms(&i915->drm,
+   "Port %c VBT HDMI max TMDS clock: %d kHz\n",
+   port_name(port), max_tmds_clock);
  
  	/* I_boost config for SKL and above */

dp_boost_level = intel_bios_encoder_dp_boost_level(devdata);
@@ -2950,8 +2949,9 @@ enum aux_ch intel_bios_port_aux_ch(struct 
drm_i915_private *i915,
  int intel_bios_max_tmds_clock(struct intel_encoder *encoder)
  {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   const struct intel_bios_encoder_data *devdata = 
i915->vbt.ddi_port_info[encoder->port].devdata;
  
-	return i915->vbt.ddi_port_info[encoder->port].max_tmds_clock;

+   return _intel_bios_max_tmds_clock(devdata);
  }
  
  /* This is an index in the HDMI/DVI DDI buffer translation table, or -1 */

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 67a9f07550d4..8b4a31265978 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -639,8 +639,6 @@ struct ddi_vbt_port_info {
/* Non-NULL if port present. */
struct intel_bios_encoder_data *devdata;
  
-	int max_tmds_clock;

-
u8 alternate_aux_channel;
u8 alternate_ddc_pin;
  

Re: [Intel-gfx] [PATCH v2 1/7] drm/i915/bios: use hdmi level shift directly from child data

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 9/1/2021 9:39 PM, Jani Nikula wrote:

Avoid extra caching of the data.

Cc: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_bios.c | 26 +--
  drivers/gpu/drm/i915/i915_drv.h   |  4 
  2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index e86e6ed2d3bf..afb5fcd9dd0c 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1868,6 +1868,14 @@ intel_bios_encoder_supports_edp(const struct 
intel_bios_encoder_data *devdata)
devdata->child.device_type & DEVICE_TYPE_INTERNAL_CONNECTOR;
  }
  
+static int _intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data *devdata)

+{
+   if (!devdata || devdata->i915->vbt.version < 158)
+   return -1;
+
+   return devdata->child.hdmi_level_shifter_value;
+}
+
  static bool is_port_valid(struct drm_i915_private *i915, enum port port)
  {
/*
@@ -1887,7 +1895,7 @@ static void parse_ddi_port(struct drm_i915_private *i915,
const struct child_device_config *child = &devdata->child;
struct ddi_vbt_port_info *info;
bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb, 
supports_tbt;
-   int dp_boost_level, hdmi_boost_level;
+   int dp_boost_level, hdmi_boost_level, hdmi_level_shift;
enum port port;
  
  	port = dvo_port_to_port(i915, child->dvo_port);

@@ -1949,15 +1957,11 @@ static void parse_ddi_port(struct drm_i915_private 
*i915,
sanitize_aux_ch(i915, port);
}
  
-	if (i915->vbt.version >= 158) {

-   /* The VBT HDMI level shift values match the table we have. */
-   u8 hdmi_level_shift = child->hdmi_level_shifter_value;
+   hdmi_level_shift = _intel_bios_hdmi_level_shift(devdata);
+   if (hdmi_level_shift >= 0) {
drm_dbg_kms(&i915->drm,
"Port %c VBT HDMI level shift: %d\n",
-   port_name(port),
-   hdmi_level_shift);
-   info->hdmi_level_shift = hdmi_level_shift;
-   info->hdmi_level_shift_set = true;
+   port_name(port), hdmi_level_shift);
}
  
  	if (i915->vbt.version >= 204) {

@@ -2950,13 +2954,13 @@ int intel_bios_max_tmds_clock(struct intel_encoder 
*encoder)
return i915->vbt.ddi_port_info[encoder->port].max_tmds_clock;
  }
  
+/* This is an index in the HDMI/DVI DDI buffer translation table, or -1 */

  int intel_bios_hdmi_level_shift(struct intel_encoder *encoder)
  {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
-   const struct ddi_vbt_port_info *info =
-   &i915->vbt.ddi_port_info[encoder->port];
+   const struct intel_bios_encoder_data *devdata = 
i915->vbt.ddi_port_info[encoder->port].devdata;
  
-	return info->hdmi_level_shift_set ? info->hdmi_level_shift : -1;

+   return _intel_bios_hdmi_level_shift(devdata);
  }
  
  int intel_bios_encoder_dp_boost_level(const struct intel_bios_encoder_data *devdata)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be2392bbcecc..67a9f07550d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -641,10 +641,6 @@ struct ddi_vbt_port_info {
  
  	int max_tmds_clock;
  
-	/* This is an index in the HDMI/DVI DDI buffer translation table. */

-   u8 hdmi_level_shift;
-   u8 hdmi_level_shift_set:1;
-
u8 alternate_aux_channel;
u8 alternate_ddc_pin;
  

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm

[Tvrtko Ursulin]

On 02/09/2021 15:20, Daniel Vetter wrote:

The important part isn't so much that this does an rcu lookup - that's
more an implementation detail, which will also be removed.

The thing that makes this different from other functions is that it's
gettting you the vm that batchbuffers will run in for that gem
context, which is either a full ppgtt stored in gem->ctx, or the ggtt.

We'll make more use of this function later on.

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Cc: Jon Bloomfield 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
Cc: "Thomas Hellström" 
Cc: Matthew Auld 
Cc: Lionel Landwerlin 
Cc: Dave Airlie 
Cc: Jason Ekstrand 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.h   | 2 +-
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c   | 4 ++--
  drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
  drivers/gpu/drm/i915/gt/selftest_execlists.c  | 2 +-
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c  | 2 +-
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++--
  drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
  7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 18060536b0c2..da6e8b506d96 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -155,7 +155,7 @@ i915_gem_context_vm(struct i915_gem_context *ctx)
  }
  
  static inline struct i915_address_space *

-i915_gem_context_get_vm_rcu(struct i915_gem_context *ctx)
+i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
  {
struct i915_address_space *vm;
  
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c

index a094f3ce1a90..6c68fe26bb32 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1456,7 +1456,7 @@ static int igt_tmpfs_fallback(void *arg)
struct i915_gem_context *ctx = arg;
struct drm_i915_private *i915 = ctx->i915;
struct vfsmount *gemfs = i915->mm.gemfs;
-   struct i915_address_space *vm = i915_gem_context_get_vm_rcu(ctx);
+   struct i915_address_space *vm = i915_gem_context_get_eb_vm(ctx);
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
u32 *vaddr;
@@ -1512,7 +1512,7 @@ static int igt_shrink_thp(void *arg)
  {
struct i915_gem_context *ctx = arg;
struct drm_i915_private *i915 = ctx->i915;
-   struct i915_address_space *vm = i915_gem_context_get_vm_rcu(ctx);
+   struct i915_address_space *vm = i915_gem_context_get_eb_vm(ctx);


Problem here (and probably elsewhere) is that this test does no "eb", 
nor even submits any requests for execution.


More so, execbuf path does currently rely on intel_context->vm which is 
always set. So I really wonder how it would look, what I touched on 
elsewhere in the thread, if we instead made ctx->vm always point to 
something. It would align the rules between intel_context and GEM 
context and may end up with a more consistent situation.


Regards,

Tvrtko


struct drm_i915_gem_object *obj;
struct i915_gem_engines_iter it;
struct intel_context *ce;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 4d2758718d21..fc7fb33a3a52 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1528,7 +1528,7 @@ static int write_to_scratch(struct i915_gem_context *ctx,
  
  	intel_gt_chipset_flush(engine->gt);
  
-	vm = i915_gem_context_get_vm_rcu(ctx);

+   vm = i915_gem_context_get_eb_vm(ctx);
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
@@ -1607,7 +1607,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
if (GRAPHICS_VER(i915) >= 8) {
const u32 GPR0 = engine->mmio_base + 0x600;
  
-		vm = i915_gem_context_get_vm_rcu(ctx);

+   vm = i915_gem_context_get_eb_vm(ctx);
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c 
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index f12ffe797639..b3863abc51f5 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -3493,7 +3493,7 @@ static int smoke_submit(struct preempt_smoke *smoke,
if (batch) {
struct i915_address_space *vm;
  
-		vm = i915_gem_context_get_vm_rcu(ctx);

+   vm = i915_gem_context_get_eb_vm(ctx);
vma = i915_vma_instance(batch, vm, NULL);
i915_vm_put(vm);
if (IS_ERR(vma))
diff --git a/drivers/gpu/drm/i

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] drm/i915: Release i915_gem_context from a worker (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [01/11] drm/i915: Release i915_gem_context from a 
worker (rev3)
URL   : https://patchwork.freedesktop.org/series/94285/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10548_full -> Patchwork_20949_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][2] -> [TIMEOUT][3] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-iclb2/igt@gem_...@unwedge-stress.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][4] -> [FAIL][5] ([i915#2842]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
- shard-apl:  NOTRUN -> [FAIL][6] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-iclb4/igt@gem_exec_fair@basic-p...@bcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb6/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2849])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#307])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy-odd.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-skl3/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-snb:  NOTRUN -> [WARN][16] ([i915#2658]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-snb6/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@linear-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb1/igt@gem_render_c...@linear-to-vebox-yf-tiled.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][18] ([i915#2724])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-snb6/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen9_exec_parse@cmd-crossing-page:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#2856])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb1/igt@gen9_exec_pa...@cmd-crossing-page.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-skl2/igt@i915_pm...@dc3co-vpb-simulation.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#454])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10548/shard-iclb1/igt@i915_pm...@dc6-psr.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-iclb4/igt@i915_pm...@dc6-psr.html
- shard-skl:  NOTRUN -> [FAIL][23] ([i915#454])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20949/shard-skl6/igt@i915_pm...@dc6-psr.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][24] -> [FAI