[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable GuC submission by default on DG1 (rev2)

[Patchwork]

== Series Details ==

Series: Enable GuC submission by default on DG1 (rev2)
URL   : https://patchwork.freedesktop.org/series/93325/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10541 -> Patchwork_20932


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][6] -> [INCOMPLETE][7] ([i915#3920])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20932/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-rkl-guc: [PASS][9] -> [SKIP][10] ([i915#3919])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20932/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20932/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@cursor_plane_move:
- fi-kbl-8809g:   NOTRUN -> [SKIP][12] ([fdo#109271]) +35 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20932/fi-kbl-8809g/igt@kms_psr@cursor_plane_move.html

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-8809g:   [INCOMPLETE][14] ([i915#155]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-kbl-8809g/igt@gem_exec_susp...@basic-s3.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20932/fi-kbl-8809g/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload:
- {fi-tgl-dsi}:   [DMESG-WARN][16] ([i915#1982]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-tgl-dsi/igt@i915_module_l...@reload.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20932/fi-tgl-dsi/igt@i915_module_l...@reload.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2927]: https://gitlab.freedesktop.org

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable GuC submission by default on DG1 (rev2)

[Patchwork]

== Series Details ==

Series: Enable GuC submission by default on DG1 (rev2)
URL   : https://patchwork.freedesktop.org/series/93325/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6980dea021fa drm/i915: Do not define vma on stack
8e2a5b71ad3f drm/i915/guc: put all guc objects in lmem when available
86c5db967bd1 drm/i915/guc: Add DG1 GuC / HuC firmware defs
c88604227edc drm/i915/guc: Enable GuC submission by default on DG1
97b71fbd31ae Me: Allow relocs on DG1 for CI
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:19: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 1 errors, 1 warnings, 0 checks, 8 lines checked
4ec48c0b396e Me: Workaround LMEM blow up
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:19: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 1 errors, 1 warnings, 0 checks, 8 lines checked
edda215da5e9 Me: Dump GuC log to dmesg on SLPC load failure
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:17: CHECK:SPACING: No space is necessary after a cast
#17: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c:267:
+(intel_engine_mask_t) ~0U);

-:56: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#56: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:1999:
+   if (!buf) {
+   drm_err(&i915->drm, "Failed to allocate buffer for error 
capture!\n");

-:68: WARNING:LINE_SPACING: Missing a blank line after declarations
#68: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2011:
+   ssize_t got = i915_gpu_coredump_copy_to_buffer(error, buf, 
pos_err, buf_size - 1);
+   if (got <= 0)

-:91: CHECK:BRACES: braces {} should be used on all arms of this statement
#91: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2034:
+   if (count > MAX_CHUNK) {
[...]
+   } else
[...]

-:97: WARNING:LINE_SPACING: Missing a blank line after declarations
#97: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2040:
+   char chr = ptr[pos];
+   ptr[pos] = 0;

-:104: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#104: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2047:
+   drm_info(&i915->drm, "Capture 
%c%s%c\n", tag[0], ptr2, tag[1]);

-:107: CHECK:BRACES: Unbalanced braces around else statement
#107: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2050:
+   } else

-:139: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 1 errors, 5 warnings, 3 checks, 118 lines checked

[Intel-gfx] [PATCH 4/7] drm/i915/guc: Enable GuC submission by default on DG1

[John . C . Harrison]

From: Matthew Brost 

Enable GuC submission by default on DG1

Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index b104fb7607eb..d94ff12fdb95 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -35,7 +35,7 @@ static void uc_expand_default_options(struct intel_uc *uc)
}
 
/* Intermediate platforms are HuC authentication only */
-   if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+   if (IS_ALDERLAKE_S(i915)) {
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
return;
}
-- 
2.25.1

[Intel-gfx] [PATCH 3/7] drm/i915/guc: Add DG1 GuC / HuC firmware defs

[John . C . Harrison]

From: Matthew Brost 

Add DG1 GuC / HuC firmware defs

Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index f8cb00ffb506..a685d563df72 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -51,6 +51,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
 #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
fw_def(ALDERLAKE_P, 0, guc_def(adlp, 62, 0, 3), huc_def(tgl, 7, 9, 3)) \
fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 9, 3)) \
+   fw_def(DG1, 0, guc_def(dg1, 62, 0, 0), huc_def(dg1,  7, 9, 3)) \
fw_def(ROCKETLAKE,  0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 9, 3)) \
fw_def(TIGERLAKE,   0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 9, 3)) \
fw_def(JASPERLAKE,  0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
-- 
2.25.1

[Intel-gfx] [PATCH 0/7] [CI] Enable GuC submission by default on DG1

[John . C . Harrison]

From: John Harrison 

Minimum set of patches to enable GuC submission on DG1 and enable it by
default.

A little difficult to test as IGTs do not work with DG1 due to a bunch
of uAPI features being disabled (e.g. relocations, caching memory
options, etc...). Hence extra patches at the end to enable some
features / add debugging info.

Signed-off-by: Matthew Brost 
Signed-off-by: John Harrison 


Daniele Ceraolo Spurio (1):
  drm/i915/guc: put all guc objects in lmem when available

Matthew Brost (5):
  drm/i915/guc: Add DG1 GuC / HuC firmware defs
  drm/i915/guc: Enable GuC submission by default on DG1
  Me: Allow relocs on DG1 for CI
  Me: Workaround LMEM blow up
  Me: Dump GuC log to dmesg on SLPC load failure

Venkata Sandeep Dhanalakota (1):
  drm/i915: Do not define vma on stack

 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  | 26 +
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h  |  4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  9 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 13 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  3 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 14 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 90 ++---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  2 +
 drivers/gpu/drm/i915/i915_gpu_error.c | 99 ++-
 drivers/gpu/drm/i915/i915_gpu_error.h |  3 +
 12 files changed, 244 insertions(+), 23 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH 5/7] Me: Allow relocs on DG1 for CI

[John . C . Harrison]

From: Matthew Brost 

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

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8290bdadd167..a530a65e6f2a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -489,7 +489,7 @@ static bool platform_has_relocs_enabled(const struct 
i915_execbuffer *eb)
 */
if (GRAPHICS_VER(eb->i915) < 12 || IS_TIGERLAKE(eb->i915) ||
IS_ROCKETLAKE(eb->i915) || IS_ALDERLAKE_S(eb->i915) ||
-   IS_ALDERLAKE_P(eb->i915))
+   IS_ALDERLAKE_P(eb->i915) || IS_DG1(eb->i915))
return true;
 
return false;
-- 
2.25.1

[Intel-gfx] [PATCH 2/7] drm/i915/guc: put all guc objects in lmem when available

[John . C . Harrison]

From: Daniele Ceraolo Spurio 

The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocated during driver load and if we have issues with lmem at that point
something is seriously wrong with the system, so no point in trying to
handle it.

Cc: Matthew Auld 
Cc: Abdiel Janulgue 
Cc: Michal Wajdeczko 
Cc: Vinay Belgaumkar 
Cc: Radoslaw Szwichtenberg 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  | 26 
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h  |  4 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  9 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 13 ++--
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 14 -
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 75 +--
 6 files changed, 128 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index eb345305dc52..034226c5d4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -103,6 +103,32 @@ __i915_gem_object_create_lmem_with_ps(struct 
drm_i915_private *i915,
 size, page_size, flags);
 }
 
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem_from_data(struct drm_i915_private *i915,
+ const void *data, size_t size)
+{
+   struct drm_i915_gem_object *obj;
+   void *map;
+
+   obj = i915_gem_object_create_lmem(i915,
+ round_up(size, PAGE_SIZE),
+ I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(obj))
+   return obj;
+
+   map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
+   if (IS_ERR(map)) {
+   i915_gem_object_put(obj);
+   return map;
+   }
+
+   memcpy(map, data, size);
+
+   i915_gem_object_unpin_map(obj);
+
+   return obj;
+}
+
 struct drm_i915_gem_object *
 i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index 4ee81fc66302..1b88ea13435c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -23,6 +23,10 @@ bool i915_gem_object_is_lmem(struct drm_i915_gem_object 
*obj);
 
 bool __i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
 
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem_from_data(struct drm_i915_private *i915,
+ const void *data, size_t size);
+
 struct drm_i915_gem_object *
 __i915_gem_object_create_lmem_with_ps(struct drm_i915_private *i915,
  resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index fbfcae727d7f..8ffb689066f6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -3,6 +3,7 @@
  * Copyright © 2014-2019 Intel Corporation
  */
 
+#include "gem/i915_gem_lmem.h"
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_irq.h"
 #include "gt/intel_gt_pm_irq.h"
@@ -647,7 +648,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
u64 flags;
int ret;
 
-   obj = i915_gem_object_create_shmem(gt->i915, size);
+   if (HAS_LMEM(gt->i915))
+   obj = i915_gem_object_create_lmem(gt->i915, size,
+ I915_BO_ALLOC_CPU_CLEAR |
+ I915_BO_ALLOC_CONTIGUOUS);
+   else
+   obj = i915_gem_object_create_shmem(gt->i915, size);
+
if (IS_ERR(obj))
return ERR_CAST(obj);
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 76fe766ad1bc..196424be0998 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -41,18 +41,21 @@ static void guc_prepare_xfer(struct intel_uncore *uncore)
 }
 
 /* Copy RSA signature from the fw image to HW for verification */
-static void guc_xfer_rsa(struct intel_uc_fw *guc_fw,
-struct intel_uncore *uncore)
+static int guc_xfer_rsa(struct intel_uc_fw *guc_fw,
+   struct intel_uncore *uncore)
 {
u32 rsa[UOS_RSA_SCRATCH_COUNT];
size_t copied;
int i;
 
copied = intel_uc_fw_copy_rsa(guc_fw, rsa, sizeof(rsa));
-   GEM_BUG_ON(copied < sizeof(rsa));
+   if (copied < sizeof(rsa))
+   return -ENOMEM;
 
for (i = 0; i < UOS_RSA_SCRATCH_COUNT; i++)
intel_uncore_write(uncore, UOS_RSA_SCRATCH(i), rsa[i]);
+
+   return 0;
 }

[Intel-gfx] [PATCH 1/7] drm/i915: Do not define vma on stack

[John . C . Harrison]

From: Venkata Sandeep Dhanalakota 

Defining vma on stack can cause stack overflow, if
vma gets populated with new fields.

Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Signed-off-by: Venkata Sandeep Dhanalakota 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  2 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3a16d08608a5..f632dbd32b42 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -413,20 +413,20 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
 {
struct drm_i915_gem_object *obj = uc_fw->obj;
struct i915_ggtt *ggtt = __uc_fw_to_gt(uc_fw)->ggtt;
-   struct i915_vma dummy = {
-   .node.start = uc_fw_ggtt_offset(uc_fw),
-   .node.size = obj->base.size,
-   .pages = obj->mm.pages,
-   .vm = &ggtt->vm,
-   };
+   struct i915_vma *dummy = &uc_fw->dummy;
+
+   dummy->node.start = uc_fw_ggtt_offset(uc_fw);
+   dummy->node.size = obj->base.size;
+   dummy->pages = obj->mm.pages;
+   dummy->vm = &ggtt->vm;
 
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
-   GEM_BUG_ON(dummy.node.size > ggtt->uc_fw.size);
+   GEM_BUG_ON(dummy->node.size > ggtt->uc_fw.size);
 
/* uc_fw->obj cache domains were not controlled across suspend */
-   drm_clflush_sg(dummy.pages);
+   drm_clflush_sg(dummy->pages);
 
-   ggtt->vm.insert_entries(&ggtt->vm, &dummy, I915_CACHE_NONE, 0);
+   ggtt->vm.insert_entries(&ggtt->vm, dummy, I915_CACHE_NONE, 0);
 }
 
 static void uc_fw_unbind_ggtt(struct intel_uc_fw *uc_fw)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index 99bb1fe1af66..693cc0ebcd63 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -10,6 +10,7 @@
 #include "intel_uc_fw_abi.h"
 #include "intel_device_info.h"
 #include "i915_gem.h"
+#include "i915_vma.h"
 
 struct drm_printer;
 struct drm_i915_private;
@@ -75,6 +76,7 @@ struct intel_uc_fw {
bool user_overridden;
size_t size;
struct drm_i915_gem_object *obj;
+   struct i915_vma dummy;
 
/*
 * The firmware build process will generate a version header file with 
major and
-- 
2.25.1

[Intel-gfx] [PATCH 7/7] Me: Dump GuC log to dmesg on SLPC load failure

[John . C . Harrison]

From: Matthew Brost 

---
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c |  3 +
 drivers/gpu/drm/i915/i915_gpu_error.c   | 97 +
 drivers/gpu/drm/i915/i915_gpu_error.h   |  3 +
 3 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 65a3e7fdb2b2..9b52cae16ebb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -262,6 +262,9 @@ static int slpc_reset(struct intel_guc_slpc *slpc)
if (wait_for(slpc_is_running(slpc), SLPC_RESET_TIMEOUT_MS)) {
drm_err(&i915->drm, "SLPC not enabled! State = %s\n",
slpc_get_state_string(slpc));
+
+   intel_klog_error_capture(guc_to_gt(guc),
+(intel_engine_mask_t) ~0U);
return -EIO;
}
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a61e23deeb00..55e58810a381 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1969,3 +1969,100 @@ void i915_disable_error_state(struct drm_i915_private 
*i915, int err)
i915->gpu_error.first_error = ERR_PTR(err);
spin_unlock_irq(&i915->gpu_error.lock);
 }
+
+void intel_klog_error_capture(struct intel_gt *gt,
+ intel_engine_mask_t engine_mask)
+{
+   struct drm_i915_private *i915 = gt->i915;
+   struct i915_gpu_coredump *error;
+   intel_wakeref_t wakeref;
+   size_t buf_size = PAGE_SIZE * 128;
+   size_t pos_err;
+   char *buf, *ptr, *next;
+
+   error = READ_ONCE(i915->gpu_error.first_error);
+   if (error) {
+   drm_err(&i915->drm, "Clearing existing error capture 
first...\n");
+   i915_reset_error_state(i915);
+   }
+
+   with_intel_runtime_pm(&i915->runtime_pm, wakeref)
+   error = i915_gpu_coredump(gt, engine_mask);
+
+   if (IS_ERR(error)) {
+   drm_err(&i915->drm, "Failed to capture error capture: %ld!\n", 
PTR_ERR(error));
+   return;
+   }
+
+   buf = kvmalloc(buf_size, GFP_KERNEL);
+   if (!buf) {
+   drm_err(&i915->drm, "Failed to allocate buffer for error 
capture!\n");
+   return;
+   }
+
+   drm_info(&i915->drm, "Dumping i915 error capture...\n");
+
+   /* Largest string length safe to print via dmesg */
+#  define MAX_CHUNK800
+
+   pos_err = 0;
+   while (1) {
+   ssize_t got = i915_gpu_coredump_copy_to_buffer(error, buf, 
pos_err, buf_size - 1);
+   if (got <= 0)
+   break;
+
+   buf[got] = 0;
+   pos_err += got;
+
+   ptr = buf;
+   while (got > 0) {
+   size_t count;
+   char tag[2];
+
+   next = strnchr(ptr, got, '\n');
+   if (next) {
+   count = next - ptr;
+   *next = 0;
+   tag[0] = '>';
+   tag[1] = '<';
+   } else {
+   count = got;
+   tag[0] = '}';
+   tag[1] = '{';
+   }
+
+   if (count > MAX_CHUNK) {
+   size_t pos;
+   char *ptr2 = ptr;
+
+   for (pos = MAX_CHUNK; pos < count; pos += 
MAX_CHUNK) {
+   char chr = ptr[pos];
+   ptr[pos] = 0;
+   drm_info(&i915->drm, "Capture }%s{\n", 
ptr2);
+   ptr[pos] = chr;
+   ptr2 = ptr + pos;
+   }
+
+   if (ptr2 < (ptr + count))
+   drm_info(&i915->drm, "Capture 
%c%s%c\n", tag[0], ptr2, tag[1]);
+   else if (tag[0] == '>')
+   drm_info(&i915->drm, "Capture ><\n");
+   } else
+   drm_info(&i915->drm, "Capture %c%s%c\n", 
tag[0], ptr, tag[1]);
+
+   ptr = next;
+   got -= count;
+   if (next) {
+   ptr++;
+   got--;
+   }
+   }
+
+   if (got)
+   drm_info(&i915->drm, "Got %zd bytes remaining!\n", got);
+   }
+
+   kvfree(buf);
+
+   drm_info(&i915->drm, "Dumped %zd bytes\n", pos_err);
+}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/driv

[Intel-gfx] [PATCH 6/7] Me: Workaround LMEM blow up

[John . C . Harrison]

From: Matthew Brost 

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

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b9f66dbd46bb..a61e23deeb00 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1068,7 +1068,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
if (ret)
break;
}
-   } else if (__i915_gem_object_is_lmem(vma->obj)) {
+   } else if (i915_gem_object_is_lmem(vma->obj)) {
struct intel_memory_region *mem = vma->obj->mm.region;
dma_addr_t dma;
 
-- 
2.25.1

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

[Patchwork]

== Series Details ==

Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2)
URL   : https://patchwork.freedesktop.org/series/93914/
State : failure

== Summary ==

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.

  

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:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-skl10/igt@gem_exec_schedule@u-submit-golden-sl...@vcs0.html

  
 Warnings 

  * igt@i915_pm_dc@dc9-dpms:
- shard-skl:  [SKIP][2] ([fdo#109271]) -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/shard-skl6/igt@i915_pm...@dc9-dpms.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-skl8/igt@i915_pm...@dc9-dpms.html

  
 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:
- {shard-rkl}:NOTRUN -> [SKIP][4] +5 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-rkl-2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-max.html

  * igt@kms_vblank@pipe-c-ts-continuation-idle:
- {shard-rkl}:[SKIP][5] ([i915#1845]) -> [SKIP][6] +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/shard-rkl-5/igt@kms_vbl...@pipe-c-ts-continuation-idle.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-rkl-6/igt@kms_vbl...@pipe-c-ts-continuation-idle.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][7] ([i915#3002]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-snb2/igt@gem_cre...@create-massive.html

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

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

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][11] -> [SKIP][12] ([fdo#109271]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html

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

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

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-apl1/igt@gem_pr...@exhaustion.html
- shard-snb:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-s

Re: [Intel-gfx] [PATCH v7 10/17] drm/i915/pxp: interfaces for using protected objects

[Daniele Ceraolo Spurio]

+}
+
+void intel_pxp_invalidate(struct intel_pxp *pxp)
+{
+   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+   struct i915_gem_context *ctx, *cn;
+
+   /* ban all contexts marked as protected */
+   spin_lock_irq(&i915->gem.contexts.lock);
+   list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+
+   if (!kref_get_unless_zero(&ctx->ref))
+   continue;
+
+   if (likely(!i915_gem_context_uses_protected_content(ctx))) {
+   i915_gem_context_put(ctx);
+   continue;
+   }
+
+   spin_unlock_irq(&i915->gem.contexts.lock);
+
+   /*
+* By the time we get here, the HW keys are already long gone,
+* so any batch using them that's already on the engines is very
+* likely a lost cause (and it has probably already hung the
+* engine). Therefore, we skip attempting to pull the running
+* context out of the HW and we prioritize bringing the session
+* back as soon as possible.
+* For each context we ban we increase the ctx->guilty_count, so
+* that userspace can see that all the intel contexts have been
+* banned (on a non-recoverable gem context, guilty intel
+* contexts are banned immediately on reset, so we report the
+* same way here).

hmm... but guilty specifically means that they indeed caused the GPU hang.
does the umd really need this indication? any other way of doing this?


The request from Daniel was to re-use the existing interface and AFAICT 
the guilty_count is the only one we have for this. The alternative would 
be to add a new flag (like I had in the previous version of this patch), 
but that was shot down already. Lionel can probably comment more on the 
UMD requirements for this since it was a request from the mesa side.




+*/
+   for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
+   if (!intel_context_ban(ce, NULL))
+   atomic_inc(&ctx->guilty_count);
+   i915_gem_context_unlock_engines(ctx);
+
+   /*
+* The context has been killed, no need to keep the wakeref.
+* This is safe from races because the only other place this
+* is touched is context_close and we're holding a ctx ref
+*/

The comments make sense, but maybe we should avoid the optimization here,
but maybe we should avoid the optimization and just keep it locked?


The lock released above the comment and the one taken after the pm_put 
are different ones, so even if we don't release the wakeref here we 
still need to do the same locking steps. Or did you mean something 
different with keeping it locked?


Thanks,
Daniele




+   if (ctx->pxp_wakeref) {
+   intel_runtime_pm_put(&i915->runtime_pm,
+ctx->pxp_wakeref);
+   ctx->pxp_wakeref = 0;
+   }
+
+   spin_lock_irq(&i915->gem.contexts.lock);
+   list_safe_reset_next(ctx, cn, link);
+   i915_gem_context_put(ctx);
+   }
+   spin_unlock_irq(&i915->gem.contexts.lock);
+}
+
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 8f1e86caa53f..f942bdd2af0c 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -9,6 +9,8 @@
  #include "gt/intel_gt_types.h"
  #include "intel_pxp_types.h"
  
+struct drm_i915_gem_object;

+
  static inline struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
  {
return container_of(pxp, struct intel_gt, pxp);
@@ -33,6 +35,10 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
  
  void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);

  int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp);
+
+int intel_pxp_key_check(struct intel_pxp *pxp, struct drm_i915_gem_object 
*obj);
+
+void intel_pxp_invalidate(struct intel_pxp *pxp);
  #else
  static inline void intel_pxp_init(struct intel_pxp *pxp)
  {
@@ -46,6 +52,12 @@ static inline int intel_pxp_wait_for_arb_start(struct 
intel_pxp *pxp)
  {
return -ENODEV;
  }
+
+static inline int intel_pxp_key_check(struct intel_pxp *pxp,
+ struct drm_i915_gem_object *obj)
+{
+   return -ENODEV;
+}
  #endif
  
  #endif /* __INTEL_PXP_H__ */

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 67c30e534d50..c6a5e4197e40 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -72,6 +72,9 @@ static int pxp_create_arb_se

[Intel-gfx] ✓ Fi.CI.BAT: success for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

[Patchwork]

== Series Details ==

Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2)
URL   : https://patchwork.freedesktop.org/series/93914/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10541 -> Patchwork_20931


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


  Here are the changes found in Patchwork_20931 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_20931/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][3] -> [DMESG-FAIL][4] ([i915#165])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@cursor_plane_move:
- fi-kbl-8809g:   NOTRUN -> [SKIP][7] ([fdo#109271]) +35 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/fi-kbl-8809g/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-8809g:   [INCOMPLETE][8] ([i915#155]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-kbl-8809g/igt@gem_exec_susp...@basic-s3.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/fi-kbl-8809g/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload:
- {fi-tgl-dsi}:   [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/fi-tgl-dsi/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/fi-tgl-dsi/igt@i915_module_l...@reload.html

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

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

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (44 -> 36)
--

  Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10541 -> Patchwork_20931

  CI-20190529: 20190529
  CI_DRM_10541: 70a34f6275072b4374d7c730270c1fb1c88f8708 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6193: 080869f804cb86b25a38889e5ce9a870571cd8c4 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20931: fce7761a8b024a62b2ab2f906d27410574310816 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fce7761a8b02 nouveau: fold multiple DRM_DEBUG

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

[Patchwork]

== Series Details ==

Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2)
URL   : https://patchwork.freedesktop.org/series/93914/
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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/a

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

[Patchwork]

== Series Details ==

Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2)
URL   : https://patchwork.freedesktop.org/series/93914/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7bd3d881384d dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks
-:210: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fsname' - possible 
side-effects?
#210: FILE: include/linux/dynamic_debug.h:269:
+#define DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, _var, _desc, ...)  \
+   MODULE_PARM_DESC(fsname, _desc);\
+   static struct dyndbg_bitmap_param ddcats_##_var =   \
+   { .bits = &_var, .map = { __VA_ARGS__, { .prefix = NULL }}};\
+   module_param_cb(fsname, ¶m_ops_dyndbg, &ddcats_##_var, 0644)

-:210: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '_var' may be better as 
'(_var)' to avoid precedence issues
#210: FILE: include/linux/dynamic_debug.h:269:
+#define DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, _var, _desc, ...)  \
+   MODULE_PARM_DESC(fsname, _desc);\
+   static struct dyndbg_bitmap_param ddcats_##_var =   \
+   { .bits = &_var, .map = { __VA_ARGS__, { .prefix = NULL }}};\
+   module_param_cb(fsname, ¶m_ops_dyndbg, &ddcats_##_var, 0644)

-:216: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pfx' - possible 
side-effects?
#216: FILE: include/linux/dynamic_debug.h:275:
+#define _DD_cat_(pfx)  { .prefix = pfx, .help = "help for " pfx }

-:217: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pfx' - possible 
side-effects?
#217: FILE: include/linux/dynamic_debug.h:276:
+#define _DD_cat_help_(pfx) "\t   " pfx "\t- help for " pfx "\n"

-:286: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#286: FILE: lib/dynamic_debug.c:615:
+   for (i = 0; map->prefix && i < BITS_PER_LONG; map++, i++) {
+

-:325: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#325: FILE: lib/dynamic_debug.c:654:
+};
+/* support DEFINE_DYNAMIC_DEBUG_CATEGORIES users */

total: 0 errors, 0 warnings, 6 checks, 163 lines checked
1c13851cf592 dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes
-:47: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#47: FILE: drivers/gpu/drm/i915/gvt/debug.h:39:
+   pr_debug("gvt:core: "fmt, ##args)

-:51: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#51: FILE: drivers/gpu/drm/i915/gvt/debug.h:42:
+   pr_debug("gvt:irq: "fmt, ##args)

-:55: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#55: FILE: drivers/gpu/drm/i915/gvt/debug.h:45:
+   pr_debug("gvt:mm: "fmt, ##args)

-:59: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#59: FILE: drivers/gpu/drm/i915/gvt/debug.h:48:
+   pr_debug("gvt:mmio: "fmt, ##args)

-:63: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#63: FILE: drivers/gpu/drm/i915/gvt/debug.h:51:
+   pr_debug("gvt:dpy: "fmt, ##args)

-:67: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#67: FILE: drivers/gpu/drm/i915/gvt/debug.h:54:
+   pr_debug("gvt:el: "fmt, ##args)

-:71: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#71: FILE: drivers/gpu/drm/i915/gvt/debug.h:57:
+   pr_debug("gvt:sched: "fmt, ##args)

-:75: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#75: FILE: drivers/gpu/drm/i915/gvt/debug.h:60:
+   pr_debug("gvt:render: "fmt, ##args)

-:79: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between 
elements
#79: FILE: drivers/gpu/drm/i915/gvt/debug.h:63:
+   pr_debug("gvt:cmd: "fmt, ##args)

total: 0 errors, 0 warnings, 9 checks, 39 lines checked
312e15521c4c i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create 
"gvt:core:" etc categories
-:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'key' - possible side-effects?
#61: FILE: drivers/gpu/drm/i915/i915_params.c:275:
+#define _help(key) "\t\"" key "\"\t: help for " key "\n"

total: 0 errors, 0 warnings, 1 checks, 48 lines checked
31b744887a91 amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES
-:33: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'key' - possible side-effects?
#33: FILE: drivers/gpu/drm/amd/display/dc/core/dc_debug.c:46:
+#define _help_(key)"\t   " key "\t- help for " key "\n"

-:54: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#54: FILE: drivers/gpu/drm/amd/display/dc/core/dc_debug.c:67:
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_dc, __debug_dc,
+   DC_DYNDBG_BITMAP_DESC(debug_dc),

total: 0 errors, 0 warnings, 2 checks, 51 lines checked
8afc3d40447e drm_print: add choice to use dynamic debug in drm-debug
-:188: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#188: FILE: drivers/gpu/drm/drm_print.c:61:
+DEFINE_DYNAMIC_DEBUG_

Re: [Intel-gfx] [PATCH v7 10/17] drm/i915/pxp: interfaces for using protected objects

[Rodrigo Vivi]

On Fri, Aug 27, 2021 at 06:27:31PM -0700, Daniele Ceraolo Spurio wrote:
> This api allow user mode to create protected buffers and to mark
> contexts as making use of such objects. Only when using contexts
> marked in such a way is the execution guaranteed to work as expected.
> 
> Contexts can only be marked as using protected content at creation time
> (i.e. the parameter is immutable) and they must be both bannable and not
> recoverable. Given that the protected session gets invalidated on
> suspend, contexts created this way hold a runtime pm wakeref until
> they're either destroyed or invalidated.
> 
> All protected objects and contexts will be considered invalid when the
> PXP session is destroyed and all new submissions using them will be
> rejected. All intel contexts within the invalidated gem contexts will be
> marked banned. Userspace can detect that an invalidation has occurred via
> the RESET_STATS ioctl, where we report it the same way as a ban due to a
> hang.
> 
> v5: squash patches, rebase on proto_ctx, update kerneldoc
> 
> v6: rebase on obj create_ext changes
> 
> v7: Use session counter to check if an object it valid, hold wakeref in
> context, don't add a new flag to RESET_STATS (Daniel)
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Bommu Krishnaiah 
> Cc: Rodrigo Vivi 
> Cc: Chris Wilson 
> Cc: Lionel Landwerlin 
> Cc: Jason Ekstrand 
> Cc: Daniel Vetter 
> Reviewed-by: Rodrigo Vivi  #v5
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 98 ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |  6 ++
>  .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
>  drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18 
>  drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 +
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ++
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  8 ++
>  .../gpu/drm/i915/gem/selftests/mock_context.c |  4 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 83 
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  | 12 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  6 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  9 ++
>  include/uapi/drm/i915_drm.h   | 55 ++-
>  14 files changed, 371 insertions(+), 35 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..f411e26768fd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -77,6 +77,8 @@
>  #include "gt/intel_gpu_commands.h"
>  #include "gt/intel_ring.h"
>  
> +#include "pxp/intel_pxp.h"
> +
>  #include "i915_gem_context.h"
>  #include "i915_trace.h"
>  #include "i915_user_extensions.h"
> @@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private 
> *i915,
>   return 0;
>  }
>  
> -static void proto_context_close(struct i915_gem_proto_context *pc)
> +static void proto_context_close(struct drm_i915_private *i915,
> + struct i915_gem_proto_context *pc)
>  {
>   int i;
>  
> + if (pc->pxp_wakeref)
> + intel_runtime_pm_put(&i915->runtime_pm, pc->pxp_wakeref);
>   if (pc->vm)
>   i915_vm_put(pc->vm);
>   if (pc->user_engines) {
> @@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct 
> drm_i915_private *i915,
>   return 0;
>  }
>  
> +static int proto_context_set_protected(struct drm_i915_private *i915,
> +struct i915_gem_proto_context *pc,
> +bool protected)
> +{
> + int ret = 0;
> +
> + if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
> + ret = -ENODEV;
> + } else if (!protected) {
> + pc->uses_protected_content = false;
> + } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
> +!(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
> + ret = -EPERM;
> + } else {
> + pc->uses_protected_content = true;
> +
> + /*
> +  * protected context usage requires the PXP session to be up,
> +  * which in turn requires the device to be active.
> +  */
> + pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> + ret = intel_pxp_wait_for_arb_start(&i915->gt.pxp);
> + }
> +
> + return ret;
> +}
> +
>  static struct i915_gem_proto_context *
>  proto_context_create(struct drm_i915_private *i915, unsigned int flags)
>  {
> @@ -269,7 +301,7 @@ proto_context_create(struct drm_i915_private *i915, 
> unsigned int flags)
>   return pc;
>  
>  proto_close:
> - proto_context_close(pc);
> + proto_context_close(i915, pc);
>   return err;
>  }
>  
> @@ -693,6 +725,8 @@ static int set_proto_ctx_param(struct 
> drm_i915_file_private *fpriv,
>   ret = -EPERM

Re: [Intel-gfx] [PATCH v7 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

[Daniele Ceraolo Spurio]

On 8/31/2021 2:08 PM, Rodrigo Vivi wrote:

On Fri, Aug 27, 2021 at 06:27:26PM -0700, Daniele Ceraolo Spurio wrote:

From: "Huang, Sean Z" 

Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.

v2: fix locking, don't pollute dev_priv (Chris)

v3: wait for mei PXP component to be bound.

v4: drop the wait, as the component might be bound after i915 load
completes. We'll instead check when sending a tee message.

v5: fix an issue with mei_pxp module removal

Signed-off-by: Huang, Sean Z 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Reviewed-by: Rodrigo Vivi  #v4
---
  drivers/gpu/drm/i915/Makefile  |  3 +-
  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 13 
  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   | 76 ++
  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h   | 14 
  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  6 ++
  5 files changed, 111 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 157644ef5886..cc9fe99ca5c5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -282,7 +282,8 @@ i915-y += i915_perf.o
  
  # Protected execution platform (PXP) support

  i915-$(CONFIG_DRM_I915_PXP) += \
-   pxp/intel_pxp.o
+   pxp/intel_pxp.o \
+   pxp/intel_pxp_tee.o
  
  # Post-mortem debug and GPU hang state capture

  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 7b2053902146..400deaea2d8a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -3,6 +3,7 @@
   * Copyright(c) 2020 Intel Corporation.
   */
  #include "intel_pxp.h"
+#include "intel_pxp_tee.h"
  #include "gt/intel_context.h"
  #include "i915_drv.h"
  
@@ -50,7 +51,16 @@ void intel_pxp_init(struct intel_pxp *pxp)

if (ret)
return;
  
+	ret = intel_pxp_tee_component_init(pxp);

+   if (ret)
+   goto out_context;
+
drm_info(>->i915->drm, "Protected Xe Path (PXP) protected content support 
initialized\n");
+
+   return;
+
+out_context:
+   destroy_vcs_context(pxp);
  }
  
  void intel_pxp_fini(struct intel_pxp *pxp)

@@ -58,5 +68,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
  
+	intel_pxp_tee_component_fini(pxp);

+
destroy_vcs_context(pxp);
+
  }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
new file mode 100644
index ..2f28f34c721d
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+
+#include 
+#include "drm/i915_pxp_tee_interface.h"
+#include "drm/i915_component.h"
+#include "i915_drv.h"
+#include "intel_pxp.h"
+#include "intel_pxp_tee.h"
+
+static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
+{
+   return &kdev_to_i915(i915_kdev)->gt.pxp;
+}
+
+/**
+ * i915_pxp_tee_component_bind - bind function to pass the function pointers 
to pxp_tee
+ * @i915_kdev: pointer to i915 kernel device
+ * @tee_kdev: pointer to tee kernel device
+ * @data: pointer to pxp_tee_master containing the function pointers
+ *
+ * This bind function is called during the system boot or resume from system 
sleep.
+ *
+ * Return: return 0 if successful.
+ */
+static int i915_pxp_tee_component_bind(struct device *i915_kdev,
+  struct device *tee_kdev, void *data)
+{
+   struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+
+   pxp->pxp_component = data;
+   pxp->pxp_component->tee_dev = tee_kdev;
+
+   return 0;
+}
+
+static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
+ struct device *tee_kdev, void *data)
+{
+   struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+
+   pxp->pxp_component = NULL;
+}
+
+static const struct component_ops i915_pxp_tee_component_ops = {
+   .bind   = i915_pxp_tee_component_bind,
+   .unbind = i915_pxp_tee_component_unbind,
+};
+
+int intel_pxp_tee_component_init(struct intel_pxp *pxp)
+{
+   int ret;
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   struct drm_i915_private *i915 = gt->i915;
+
+   ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
+ I915_COMPONENT_PXP);
+   if (ret < 0) {
+   drm_err(&i915->drm, "Failed to add PXP component (%d)\n", ret);
+   return ret;
+   }
+
+   pxp->pxp_component_added = true;
+
+   return 0;
+}
+
+void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
+{
+   st

Re: [Intel-gfx] [PATCH v7 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

[Rodrigo Vivi]

On Fri, Aug 27, 2021 at 06:27:26PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z" 
> 
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (default) session.
> 
> v2: fix locking, don't pollute dev_priv (Chris)
> 
> v3: wait for mei PXP component to be bound.
> 
> v4: drop the wait, as the component might be bound after i915 load
> completes. We'll instead check when sending a tee message.
> 
> v5: fix an issue with mei_pxp module removal
> 
> Signed-off-by: Huang, Sean Z 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> Reviewed-by: Rodrigo Vivi  #v4
> ---
>  drivers/gpu/drm/i915/Makefile  |  3 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 13 
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   | 76 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h   | 14 
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  6 ++
>  5 files changed, 111 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 157644ef5886..cc9fe99ca5c5 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -282,7 +282,8 @@ i915-y += i915_perf.o
>  
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> - pxp/intel_pxp.o
> + pxp/intel_pxp.o \
> + pxp/intel_pxp_tee.o
>  
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 7b2053902146..400deaea2d8a 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -3,6 +3,7 @@
>   * Copyright(c) 2020 Intel Corporation.
>   */
>  #include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
>  #include "gt/intel_context.h"
>  #include "i915_drv.h"
>  
> @@ -50,7 +51,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
>   if (ret)
>   return;
>  
> + ret = intel_pxp_tee_component_init(pxp);
> + if (ret)
> + goto out_context;
> +
>   drm_info(>->i915->drm, "Protected Xe Path (PXP) protected content 
> support initialized\n");
> +
> + return;
> +
> +out_context:
> + destroy_vcs_context(pxp);
>  }
>  
>  void intel_pxp_fini(struct intel_pxp *pxp)
> @@ -58,5 +68,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
>   if (!intel_pxp_is_enabled(pxp))
>   return;
>  
> + intel_pxp_tee_component_fini(pxp);
> +
>   destroy_vcs_context(pxp);
> +
>  }
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> new file mode 100644
> index ..2f28f34c721d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include 
> +#include "drm/i915_pxp_tee_interface.h"
> +#include "drm/i915_component.h"
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> +
> +static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> +{
> + return &kdev_to_i915(i915_kdev)->gt.pxp;
> +}
> +
> +/**
> + * i915_pxp_tee_component_bind - bind function to pass the function pointers 
> to pxp_tee
> + * @i915_kdev: pointer to i915 kernel device
> + * @tee_kdev: pointer to tee kernel device
> + * @data: pointer to pxp_tee_master containing the function pointers
> + *
> + * This bind function is called during the system boot or resume from system 
> sleep.
> + *
> + * Return: return 0 if successful.
> + */
> +static int i915_pxp_tee_component_bind(struct device *i915_kdev,
> +struct device *tee_kdev, void *data)
> +{
> + struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> +
> + pxp->pxp_component = data;
> + pxp->pxp_component->tee_dev = tee_kdev;
> +
> + return 0;
> +}
> +
> +static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
> +   struct device *tee_kdev, void *data)
> +{
> + struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> +
> + pxp->pxp_component = NULL;
> +}
> +
> +static const struct component_ops i915_pxp_tee_component_ops = {
> + .bind   = i915_pxp_tee_component_bind,
> + .unbind = i915_pxp_tee_component_unbind,
> +};
> +
> +int intel_pxp_tee_component_init(struct intel_pxp *pxp)
> +{
> + int ret;
> + struct intel_gt *gt = pxp_to_gt(pxp);
> + struct drm_i915_private *i915 = gt->i915;
> +
> + ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
> +   I915_COMPONENT_PXP);
> + if (ret < 0) {
> + drm_err(&i915->drm, "Failed to add PXP component (%d)\n", ret);
> +  

Re: [Intel-gfx] [PATCH 8/8] drm/i915/perf: Map OA buffer to user space for gen12 performance query

[Umesh Nerlige Ramappa]

On Tue, Aug 31, 2021 at 02:55:37PM +0200, Daniel Vetter wrote:

On Mon, Aug 30, 2021 at 12:38:51PM -0700, Umesh Nerlige Ramappa wrote:

i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggered reports within oa buffer.

Triggering reports into the OA buffer is achieved by writing into a
a trigger register. Optionally an unused counter/register is set with a
marker value such that a triggered report can be identified in the OA
buffer. Reports are usually triggered at the start and end of work that
is measured.

Since OA buffer is large and queries can be frequent, an efficient way
to look for triggered reports is required. By knowing the current head
and tail offsets into the OA buffer, it is easier to determine the
locality of the reports of interest.

Current perf OA interface does not expose head/tail information to the
user and it filters out invalid reports before sending data to user.
Also considering limited size of user buffer used during a query,
creating a 1:1 copy of the OA buffer at the user space added undesired
complexity.

The solution was to map the OA buffer to user space provided

(1) that it is accessed from a privileged user.
(2) OA report filtering is not used.

These 2 conditions would satisfy the safety criteria that the current
perf interface addresses.


This is a perf improvement. Please include benchmark numbers to justify
it.


OA supports 2 mechanisms of perf measurements.

1) query interface where perf countes can be queried.
2) OA buffer use case where counter-snapshots are captured periodically 
and analyzed for performance.


This patch series is actually just (1) query interface implementation 
for discrete and not a perf improvement.


The old mechanism to query OA report (MI_REPORT_PERF_COUNT) is not 
available for all engines. In the new mechanism, a query is triggered 
from a batch by writing to a whitelisted OA trigger register. Once a 
query is triggered, the resulting report is captured in the OA buffer.  
To locate the report quickly, the batch also captures the OA HW tail 
pointer before/after writing to the trigger register. This gives the 
user a window/locality in the OA buffer where the report of interest 
lies.  

For this new mechanism, the current interface to read reports from the 
OA buffer is inefficient since the reads are sequential and reports are 
copied to user buffer.


mmap provides an accurate and faster way to fetch the queried reports 
based on locality.


Note that mmap does not replace the OA buffer use case from (2) which 
still reads reports sequentially to analyze performance.






To enable the query:
- Add an ioctl to expose head and tail to the user
- Add an ioctl to return size and offset of the OA buffer
- Map the OA buffer to the user space

v2:
- Improve commit message (Chris)
- Do not mmap based on gem object filp. Instead, use perf_fd and support
  mmap syscall (Chris)
- Pass non-zero offset in mmap to enforce the right object is
  mapped (Chris)
- Do not expose gpu_address (Chris)
- Verify start and length of vma for page alignment (Lionel)
- Move SQNTL config out (Lionel)

v3: (Chris)
- Omit redundant checks
- Return VM_FAULT_SIGBUS is old stream is closed
- Maintain reference counts to stream in vm_open and vm_close
- Use switch to identify object to be mapped

v4: Call kref_put on closing perf fd (Chris)
v5:
- Strip access to OA buffer from unprivileged child of a privileged
  parent. Use VM_DONTCOPY
- Enforce MAP_PRIVATE by checking for VM_MAYSHARE

v6:
(Chris)
- Use len of -1 in unmap_mapping_range
- Don't use stream->oa_buffer.vma->obj in vm_fault_oa
- Use kernel block comment style
- do_mmap gets a reference to the file and puts it in do_munmap, so
  no need to maintain a reference to i915_perf_stream. Hence, remove
  vm_open/vm_close and stream->closed hooks/checks.
(Umesh)
- Do not allow mmap if SAMPLE_OA_REPORT is not set during
  i915_perf_open_ioctl.
- Drop ioctl returning head/tail since this information is already
  whitelisted. Remove hooks to read head register.

v7: (Chris)
- unmap before destroy
- change ioctl argument struct

v8: Documentation and more checks (Chris)
v9: Fix comment style (Umesh)
v10: Update uapi comment (Ashutosh)

Signed-off-by: Piotr Maciejewski 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +
 drivers/gpu/drm/i915/i915_perf.c | 126 ++-
 include/uapi/drm/i915_drm.h  |  33 ++
 4 files changed, 161 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 5130e8ed9564..84cdce2ee447 100644
--- a/drivers/gpu/drm/i915

[Intel-gfx] [PATCH v7 8/8] nouveau: fold multiple DRM_DEBUG_DRIVERs together

[Jim Cromie]

With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes.
We can combine 12 into one here and save ~620 bytes.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +--
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ba4cd5f83725..0f45399535bf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1245,19 +1245,29 @@ nouveau_drm_pci_table[] = {
 
 static void nouveau_display_options(void)
 {
-   DRM_DEBUG_DRIVER("Loading Nouveau with parameters:\n");
-
-   DRM_DEBUG_DRIVER("... tv_disable   : %d\n", nouveau_tv_disable);
-   DRM_DEBUG_DRIVER("... ignorelid: %d\n", nouveau_ignorelid);
-   DRM_DEBUG_DRIVER("... duallink : %d\n", nouveau_duallink);
-   DRM_DEBUG_DRIVER("... nofbaccel: %d\n", nouveau_nofbaccel);
-   DRM_DEBUG_DRIVER("... config   : %s\n", nouveau_config);
-   DRM_DEBUG_DRIVER("... debug: %s\n", nouveau_debug);
-   DRM_DEBUG_DRIVER("... noaccel  : %d\n", nouveau_noaccel);
-   DRM_DEBUG_DRIVER("... modeset  : %d\n", nouveau_modeset);
-   DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
-   DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
-   DRM_DEBUG_DRIVER("... hdmimhz  : %d\n", nouveau_hdmimhz);
+   DRM_DEBUG_DRIVER("Loading Nouveau with parameters:\n"
+"... tv_disable   : %d\n"
+"... ignorelid: %d\n"
+"... duallink : %d\n"
+"... nofbaccel: %d\n"
+"... config   : %s\n"
+"... debug: %s\n"
+"... noaccel  : %d\n"
+"... modeset  : %d\n"
+"... runpm: %d\n"
+"... vram_pushbuf : %d\n"
+"... hdmimhz  : %d\n"
+, nouveau_tv_disable
+, nouveau_ignorelid
+, nouveau_duallink
+, nouveau_nofbaccel
+, nouveau_config
+, nouveau_debug
+, nouveau_noaccel
+, nouveau_modeset
+, nouveau_runtime_pm
+, nouveau_vram_pushbuf
+, nouveau_hdmimhz);
 }
 
 static const struct dev_pm_ops nouveau_pm_ops = {
-- 
2.31.1

[Intel-gfx] [PATCH v7 7/8] amdgpu_ucode: reduce number of pr_debug calls

[Jim Cromie]

There are blocks of DRM_DEBUG calls, consolidate their args into
single calls.  With dynamic-debug in use, each callsite consumes 56
bytes of callsite data, and this patch removes about 65 calls, so
it saves ~3.5kb.

no functional changes.

RFC: this creates multi-line log messages, does that break any syslog
conventions ?

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 293 --
 1 file changed, 158 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 2834981f8c08..14a9fef1f4c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -30,17 +30,26 @@
 
 static void amdgpu_ucode_print_common_hdr(const struct common_firmware_header 
*hdr)
 {
-   DRM_DEBUG("size_bytes: %u\n", le32_to_cpu(hdr->size_bytes));
-   DRM_DEBUG("header_size_bytes: %u\n", 
le32_to_cpu(hdr->header_size_bytes));
-   DRM_DEBUG("header_version_major: %u\n", 
le16_to_cpu(hdr->header_version_major));
-   DRM_DEBUG("header_version_minor: %u\n", 
le16_to_cpu(hdr->header_version_minor));
-   DRM_DEBUG("ip_version_major: %u\n", le16_to_cpu(hdr->ip_version_major));
-   DRM_DEBUG("ip_version_minor: %u\n", le16_to_cpu(hdr->ip_version_minor));
-   DRM_DEBUG("ucode_version: 0x%08x\n", le32_to_cpu(hdr->ucode_version));
-   DRM_DEBUG("ucode_size_bytes: %u\n", le32_to_cpu(hdr->ucode_size_bytes));
-   DRM_DEBUG("ucode_array_offset_bytes: %u\n",
- le32_to_cpu(hdr->ucode_array_offset_bytes));
-   DRM_DEBUG("crc32: 0x%08x\n", le32_to_cpu(hdr->crc32));
+   DRM_DEBUG("size_bytes: %u\n"
+ "header_size_bytes: %u\n"
+ "header_version_major: %u\n"
+ "header_version_minor: %u\n"
+ "ip_version_major: %u\n"
+ "ip_version_minor: %u\n"
+ "ucode_version: 0x%08x\n"
+ "ucode_size_bytes: %u\n"
+ "ucode_array_offset_bytes: %u\n"
+ "crc32: 0x%08x\n",
+ le32_to_cpu(hdr->size_bytes),
+ le32_to_cpu(hdr->header_size_bytes),
+ le16_to_cpu(hdr->header_version_major),
+ le16_to_cpu(hdr->header_version_minor),
+ le16_to_cpu(hdr->ip_version_major),
+ le16_to_cpu(hdr->ip_version_minor),
+ le32_to_cpu(hdr->ucode_version),
+ le32_to_cpu(hdr->ucode_size_bytes),
+ le32_to_cpu(hdr->ucode_array_offset_bytes),
+ le32_to_cpu(hdr->crc32));
 }
 
 void amdgpu_ucode_print_mc_hdr(const struct common_firmware_header *hdr)
@@ -55,9 +64,9 @@ void amdgpu_ucode_print_mc_hdr(const struct 
common_firmware_header *hdr)
const struct mc_firmware_header_v1_0 *mc_hdr =
container_of(hdr, struct mc_firmware_header_v1_0, 
header);
 
-   DRM_DEBUG("io_debug_size_bytes: %u\n",
- le32_to_cpu(mc_hdr->io_debug_size_bytes));
-   DRM_DEBUG("io_debug_array_offset_bytes: %u\n",
+   DRM_DEBUG("io_debug_size_bytes: %u\n"
+ "io_debug_array_offset_bytes: %u\n",
+ le32_to_cpu(mc_hdr->io_debug_size_bytes),
  le32_to_cpu(mc_hdr->io_debug_array_offset_bytes));
} else {
DRM_ERROR("Unknown MC ucode version: %u.%u\n", version_major, 
version_minor);
@@ -82,13 +91,17 @@ void amdgpu_ucode_print_smc_hdr(const struct 
common_firmware_header *hdr)
switch (version_minor) {
case 0:
v2_0_hdr = container_of(hdr, struct 
smc_firmware_header_v2_0, v1_0.header);
-   DRM_DEBUG("ppt_offset_bytes: %u\n", 
le32_to_cpu(v2_0_hdr->ppt_offset_bytes));
-   DRM_DEBUG("ppt_size_bytes: %u\n", 
le32_to_cpu(v2_0_hdr->ppt_size_bytes));
+   DRM_DEBUG("ppt_offset_bytes: %u\n"
+ "ppt_size_bytes: %u\n",
+ le32_to_cpu(v2_0_hdr->ppt_offset_bytes),
+ le32_to_cpu(v2_0_hdr->ppt_size_bytes));
break;
case 1:
v2_1_hdr = container_of(hdr, struct 
smc_firmware_header_v2_1, v1_0.header);
-   DRM_DEBUG("pptable_count: %u\n", 
le32_to_cpu(v2_1_hdr->pptable_count));
-   DRM_DEBUG("pptable_entry_offset: %u\n", 
le32_to_cpu(v2_1_hdr->pptable_entry_offset));
+   DRM_DEBUG("pptable_count: %u\n"
+ "pptable_entry_offset: %u\n",
+ le32_to_cpu(v2_1_hdr->pptable_count),
+ le32_to_cpu(v2_1_hdr->pptable_entry_offset));
break;
default:
break;
@@ -111,10 +124,12 @@ void am

[Intel-gfx] [PATCH v7 6/8] drm_print: instrument drm_debug_enabled

[Jim Cromie]

Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches.  Then add a pr_debug("todo: ...") into the "dyndbg"
branch.

Then convert the "dyndbg" branch's code to a macro, so that its
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabled() itself.

This gives us unique callsite info for the 8 remaining users of
drm_debug_enabled(), and lets us enable them individually to see how
much logging traffic they generate.  The oft-visited callsites can
then be reviewed for runtime cost and possible optimizations.

Heres what we get:

bash-5.1# modprobe drm
dyndbg: 384 debug prints in module drm
bash-5.1# grep todo: /proc/dynamic_debug/control
drivers/gpu/drm/drm_edid.c:1843 [drm]connector_bad_edid =_ "todo: maybe avoid 
via dyndbg\012"
drivers/gpu/drm/drm_print.c:309 [drm]___drm_dbg =p "todo: maybe avoid via 
dyndbg\012"
drivers/gpu/drm/drm_print.c:286 [drm]__drm_dev_dbg =p "todo: maybe avoid via 
dyndbg\012"
drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid 
via dyndbg\012"
drivers/gpu/drm/drm_vblank.c:787 
[drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid 
via dyndbg\012"
drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: 
maybe avoid via dyndbg\012"
drivers/gpu/drm/drm_atomic_uapi.c:1457 [drm]drm_mode_atomic_ioctl =_ "todo: 
maybe avoid via dyndbg\012"
drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via 
dyndbg\012"

At quick glance, edid won't qualify, drm_print might, drm_vblank is
strongest chance, maybe atomic-ioctl too.

Signed-off-by: Jim Cromie 
---
 include/drm/drm_print.h | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 973443040561..03f9ae83fade 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -378,6 +378,11 @@ enum drm_debug_category {
 #define DRM_DBG_CAT_DP DRM_UT_DP
 #define DRM_DBG_CAT_DRMRES DRM_UT_DRMRES
 
+static inline bool drm_debug_enabled(enum drm_debug_category category)
+{
+   return unlikely(__drm_debug & category);
+}
+
 #else /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
 
 /* join prefix+format in cpp so dyndbg can see it */
@@ -397,12 +402,13 @@ enum drm_debug_category {
 #define DRM_DBG_CAT_DP "drm:dp: "
 #define DRM_DBG_CAT_DRMRES "drm:res: " /* not in MODULE_PARM_DESC */
 
-#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
+#define drm_debug_enabled(category)\
+   ({  \
+   pr_debug("todo: maybe avoid via dyndbg\n"); \
+   unlikely(__drm_debug & category);   \
+   })
 
-static inline bool drm_debug_enabled(enum drm_debug_category category)
-{
-   return unlikely(__drm_debug & category);
-}
+#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
 
 /*
  * struct device based logging
-- 
2.31.1

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

[Jim Cromie]

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.

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 
 4 files changed, 166 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7ff89690a976..97e38d86fd27 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -57,6 +57,19 @@ config DRM_DEBUG_MM
 
  If in doubt, say "N".
 
+config DRM_USE_DYNAMIC_DEBUG
+   bool "use dynamic debug to implement drm.debug"
+   default y
+   depends on DRM
+   depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
+   depends on JUM

[Intel-gfx] [PATCH v7 4/8] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES

[Jim Cromie]

logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these use DRM debug API, so are controllable using drm.debug,
but others use bare pr_debug("$prefix: .."), each with a different
class-prefix matching "^\[\w+\]:"

Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create a /sys debug_dc
parameter, modinfos, and to specify a map from bits -> categorized
pr_debugs to be controlled.

Signed-off-by: Jim Cromie 
---
 .../gpu/drm/amd/display/dc/core/dc_debug.c| 44 ++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
index 21be2a684393..9fd43254db88 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
@@ -36,8 +36,50 @@
 
 #include "resource.h"
 
-#define DC_LOGGER_INIT(logger)
+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
+/* define a drm.debug style dyndbg pr-debug control point */
+#include 
+
+unsigned long __debug_dc;
+EXPORT_SYMBOL(__debug_dc);
+
+#define _help_(key)"\t   " key "\t- help for " key "\n"
+
+/* Id like to do these inside DEFINE_DYNAMIC_DEBUG_CATEGORIES, if possible */
+#define DC_DYNDBG_BITMAP_DESC(name)\
+   "Control pr_debugs via /sys/module/amdgpu/parameters/" #name\
+   ", where each bit controls a debug category.\n" \
+   _help_("[SURFACE]:")\
+   _help_("[CURSOR]:") \
+   _help_("[PFLIP]:")  \
+   _help_("[VBLANK]:") \
+   _help_("[HW_LINK_TRAINING]:")   \
+   _help_("[HW_AUDIO]:")   \
+   _help_("[SCALER]:") \
+   _help_("[BIOS]:")   \
+   _help_("[BANDWIDTH_CALCS]:")\
+   _help_("[DML]:")\
+   _help_("[IF_TRACE]:")   \
+   _help_("[GAMMA]:")  \
+   _help_("[SMU_MSG]:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_dc, __debug_dc,
+   DC_DYNDBG_BITMAP_DESC(debug_dc),
+   _DD_cat_("[CURSOR]:"),
+   _DD_cat_("[PFLIP]:"),
+   _DD_cat_("[VBLANK]:"),
+   _DD_cat_("[HW_LINK_TRAINING]:"),
+   _DD_cat_("[HW_AUDIO]:"),
+   _DD_cat_("[SCALER]:"),
+   _DD_cat_("[BIOS]:"),
+   _DD_cat_("[BANDWIDTH_CALCS]:"),
+   _DD_cat_("[DML]:"),
+   _DD_cat_("[IF_TRACE]:"),
+   _DD_cat_("[GAMMA]:"),
+   _DD_cat_("[SMU_MSG]:"));
+#endif
 
+#define DC_LOGGER_INIT(logger)
 
 #define SURFACE_TRACE(...) do {\
if (dc->debug.surface_trace) \
-- 
2.31.1

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

[Jim Cromie]

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 ++
 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
+
 # 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
-- 
2.31.1

[Intel-gfx] [PATCH v7 2/8] dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes

[Jim Cromie]

Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the extra quoting needed otherwise:

  $> echo format "^gvt: core:" +p >control

Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched for.

Consider a generic drm-debug example:

  # turn off ATOMIC reports
  echo format "^drm:atomic: " -p > control

  # turn off all ATOMIC:* reports, including any sub-categories
  echo format "^drm:atomic:" -p > control

  # turn on ATOMIC:FAIL: reports
  echo format "^drm:atomic:fail: " +p > control

Removing embedded spaces in the class-prefixes simplifies the
corresponding match-prefix.  This means that "quoted" match-prefixes
are only needed when the trailing space is desired, in order to
exclude explicitly sub-categorized pr-debugs; in this example,
"drm:atomic:fail:".

RFC: maybe the prefix catenation should paste in the " " class-prefix
terminator explicitly.  A pr_debug_() flavor could exclude the " ",
allowing ad-hoc sub-categorization by appending for example, "fail:"
to "drm:atomic:" without the default " " insertion.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/i915/gvt/debug.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
index c6027125c1ec..b4021f41c546 100644
--- a/drivers/gpu/drm/i915/gvt/debug.h
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -36,30 +36,30 @@ do {
\
 } while (0)
 
 #define gvt_dbg_core(fmt, args...) \
-   pr_debug("gvt: core: "fmt, ##args)
+   pr_debug("gvt:core: "fmt, ##args)
 
 #define gvt_dbg_irq(fmt, args...) \
-   pr_debug("gvt: irq: "fmt, ##args)
+   pr_debug("gvt:irq: "fmt, ##args)
 
 #define gvt_dbg_mm(fmt, args...) \
-   pr_debug("gvt: mm: "fmt, ##args)
+   pr_debug("gvt:mm: "fmt, ##args)
 
 #define gvt_dbg_mmio(fmt, args...) \
-   pr_debug("gvt: mmio: "fmt, ##args)
+   pr_debug("gvt:mmio: "fmt, ##args)
 
 #define gvt_dbg_dpy(fmt, args...) \
-   pr_debug("gvt: dpy: "fmt, ##args)
+   pr_debug("gvt:dpy: "fmt, ##args)
 
 #define gvt_dbg_el(fmt, args...) \
-   pr_debug("gvt: el: "fmt, ##args)
+   pr_debug("gvt:el: "fmt, ##args)
 
 #define gvt_dbg_sched(fmt, args...) \
-   pr_debug("gvt: sched: "fmt, ##args)
+   pr_debug("gvt:sched: "fmt, ##args)
 
 #define gvt_dbg_render(fmt, args...) \
-   pr_debug("gvt: render: "fmt, ##args)
+   pr_debug("gvt:render: "fmt, ##args)
 
 #define gvt_dbg_cmd(fmt, args...) \
-   pr_debug("gvt: cmd: "fmt, ##args)
+   pr_debug("gvt:cmd: "fmt, ##args)
 
 #endif
-- 
2.31.1

[Intel-gfx] [PATCH v7 1/8] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks

[Jim Cromie]

DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
allows users to define a drm.debug style (bitmap) sysfs interface, and
to specify the desired mapping from bits[0-N] to the format-prefix'd
pr_debug()s to be controlled.

DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"i915/gvt bitmap desc",
/**
 * search-prefixes, passed to dd-exec_queries
 * defines bits 0-N in order.
 * leading ^ is tacitly inserted (by callback currently)
 * trailing space used here excludes subcats.
 * helper macro needs more work
 * macro to autogen ++$i, 0x%x$i ?
 */
_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: "));

dynamic_debug.c: add 2 new elements:

 - int param_set_dyndbg()
 - int param_get_dyndbg()
 - struct kernel_param_ops param_ops_dyndbg

Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are
non-static and exported.

get/set use an augmented kernel_param; the arg refs a new struct
dyndbg_bitmap_param containing:

- the map (array, indexed by bitpos) of format-prefix strings, which
  define the set/category of prdbgs to be changed per each bit.

- pointer to the user's ulong holding the bits/state.
  by sharing state, we coordinate with code that still uses it directly

This will allow drm-debug to be converted incrementally, while still
using __drm_debug & drm_debug_enabled() in other parts.

param_set_dyndbg() compares new vs old bits, and only updates prdbgs
on changes.  This maximally preserves the underlying state, which may
have been customized via later `echo $cmd >control`.  So if a user
really wants to know that all prdbgs are set precisely, they must
pre-clear then set.

TLDR: this also doesn't affect the decorator flags "mflt" set per prdbg.

dynamic_debug.h:

Add DEFINE_DYNAMIC_DEBUG_CATEGORIES() described above, and a stub
throwing a BUILD_BUG (RFC) when used without DYNAMIC_DEBUG support.
Add structs dyndbg_bitdesc, dyndbg_bitmap_param to support the macro.

Note that it also calls MODULE_PARM_DESC for the user, but expects the
user to catenate all the bit-descriptions together (as is done in
drm.debug), and in the following uses in amdgpu, i915.

The intent is to regenerate this output from per-bit help given in
VA_ARGS, including a bit_label(); but this can wait.

Also externs the struct kernel_param param_ops_dyndbg symbol, as is
done in moduleparams.h for all the STANDARD params.

USAGE NOTES:

Using dyndbg to query on "format ^$prefix" requires that the prefix be
present in the compiled-in format string; where run-time prefixing is
used, that format would be "%s...", which is not usefully selectable.

Using DEFINE_DYNAMIC_DEBUG_CATEGORIES wo support gets a BUILD_BUG.
ISTM there is already action at a declarative distance, nobody needs
mystery as to why the /sysfs thingy didn't appear.

Dyndbg is completely agnostic wrt the categorization scheme used, in
order to play well with any prefix convention already in use in the
codebase.  Ad-hoc categories and sub-categories are implicitly
allowed, author discipline and review is expected.

Here are some examples:

"1","2","3" 2 doesn't imply 1.
otherwize, sorta like printk levels
"1:","2:","3:"  are better, avoiding [1-9]\d+ ambiguity
"hi:","mid:","low:" are reasonable, and imply independence
"todo:","rfc:","fixme:" might be handy
"A:".."Z:"  uhm, yeah

Hierarchical classes/categories are natural:

"drm::"is used in a later commit
"drm:::"  is a natural extension.
"drm:atomic:fail:"  has been proposed, sounds directly useful

NB: in a real sense we abandon enum strictures here, and lose some
compiler help, on spelling errs for example.  Obviously "drm:" != "DRM:".

Some properties of a hierarchical category deserve explication:

Trailing spaces matter !

With 1..3-space ("drm: ", "drm:atomic: ", "drm:atomic:fail: "), the
":" doesn't terminate the search-space, the trailing space does.  So a
"drm:" search spec will match all DRM categories & subcategories, and
will not be useful in an interface where all categories are already
controlled together.  That said, "drm:atomic:" & "drm:atomic: " are
different, and both are useful in cases.

Ad-Hoc sub-categories:

These have a caveat wrt wrapper macros adding prefixes like
"drm:atomic: "; the trailing space in the prefix means that
drm_dbg_atomic("fail: ...") pastes as "drm:atomic: fail: ", which
obviously isn't ideal wrt clear and simple bitmaps.

A possible solution is to have a FOO_() version of every FOO() macro
which (anti-mnemonically) elides the trailing space, which is normally
inserted by a newer FOO().

IE: drm_dbg_atomic_("fail: ..."); // trailing _ means ad-hoc subcat

Summarizing:

 -

[Intel-gfx] [PATCH v7 0/8] use DYNAMIC_DEBUG to implement DRM.debug

[Jim Cromie]

Hi Jason, DRM folks,

In DRM-debug currently, drm_debug_enabled() is called a lot to decide
whether or not to write debug messages.  Each test is cheap, but costs
continue with uptime.  DYNAMIC_DEBUG "dyndbg", when built with
JUMP_LABEL, replaces each of those tests with a patchable NOOP, for
"zero cost when off" debugs.

this is v7:
- drops RFC distractions -JBaron
- drops patch-1: kp->data addition in moduleparams.h not needed -JBaron
- rework dyndbg callbacks to use kp->arg instead -JBaron
- fixes for problem configs reported -lkp 
- others noted per patch below ---

Broadly, this patchset does 3 things:

Adds DEFINE_DYNAMIC_DEBUG_CATEGORIES, which defines a mapping from
bits to "categorized" pr_debugs, a sysfs interface, and callbacks to
implement the bits as dynamic_debug >controls.  This is modelled after
DRM's debug interface.

Uses the new macro in amdgpu & i915 to control existing pr_debugs
according to their ad-hoc categorizations.

Adapts the drm-debug API (~20 macros) to configurably "replace"
drm_dbg & drm_dev_dbg with pr_debug & dev_dbg, which avoids
drm_debug_enabled() overheads.  DEFINE_DYNAMIC_DEBUG_CATEGORIES is
used to create the controlling bitmap, which is wired to __drm_debug
var so remaining drm_debug_enabled() users stay in sync.

on a virtual box:
bash-5.1# for m in i915 amdgpu nouveau; do modprobe $m; done
[43833.332326] dyndbg: 384 debug prints in module drm
[43833.609577] dyndbg: 211 debug prints in module drm_kms_helper
[43833.707124] dyndbg:   2 debug prints in module ttm
[43837.471166] dyndbg: 1727 debug prints in module i915
[43838.030774] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel 
[43838.031905] AMD-Vi: AMD IOMMUv2 functionality not available on this system
[43846.209583] dyndbg: 3852 debug prints in module amdgpu
[43846.261391] [drm] amdgpu kernel modesetting enabled.
[43846.262512] amdgpu: CRAT table not found
[43846.263264] amdgpu: Virtual CRAT table created for CPU
[43846.264293] amdgpu: Topology: Add CPU node
[43846.743781] dyndbg:   3 debug prints in module wmi
[43852.517497] dyndbg:  92 debug prints in module nouveau

There are a few multi-second delays there, just before dyndbg
initializes the large blocks of debug prints.


Jim Cromie (8):
  dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks
  dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes
  i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:"
etc categories
  amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES
  drm_print: add choice to use dynamic debug in drm-debug
  drm_print: instrument drm_debug_enabled
  amdgpu_ucode: reduce number of pr_debug calls
  nouveau: fold multiple DRM_DEBUG_DRIVERs together

 drivers/gpu/drm/Kconfig   |  13 +
 drivers/gpu/drm/Makefile  |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 293 ++
 .../gpu/drm/amd/display/dc/core/dc_debug.c|  44 ++-
 drivers/gpu/drm/drm_print.c   |  53 +++-
 drivers/gpu/drm/i915/Makefile |   4 +
 drivers/gpu/drm/i915/gvt/debug.h  |  18 +-
 drivers/gpu/drm/i915/i915_params.c|  35 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c |  36 ++-
 include/drm/drm_print.h   | 150 +++--
 include/linux/dynamic_debug.h |  60 
 lib/dynamic_debug.c   |  79 -
 12 files changed, 582 insertions(+), 206 deletions(-)

-- 
2.31.1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)

[Patchwork]

== Series Details ==

Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)
URL   : https://patchwork.freedesktop.org/series/94161/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10540_full -> Patchwork_20930_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs:
- {shard-rkl}:[SKIP][1] ([i915#1845]) -> [SKIP][2] +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10540/shard-rkl-5/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-rkl-6/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- {shard-rkl}:NOTRUN -> [SKIP][3] +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-rkl-6/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-max.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10540/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10540/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-tglb: NOTRUN -> [SKIP][10] ([fdo#109313])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-tglb7/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_suspend@basic-s3:
- shard-kbl:  NOTRUN -> [DMESG-WARN][11] ([i915#180])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-kbl6/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#307])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10540/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-odd.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-odd.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-apl6/igt@gem_pwr...@basic-exhaustion.html

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

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

  * igt@gen9_exec_parse@bb-start-far:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#2856])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-iclb4/igt@gen9_exec_pa...@bb-start-far.html
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#2856])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-tglb7/igt@gen9_exec_pa...@bb-start-far.html

  * igt@i915_pm_rpm@gem-mmap-type@fixed:
- shard-kbl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3976])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-kbl2/igt@i915_pm_rpm@gem-mmap-t...@fixed.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  NOTRUN -> [INCOMPLETE][20] ([i915#3921])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/shard-snb6/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_big_fb@y-ti

Re: [Intel-gfx] [PATCH 27/27] drm/i915/guc: Drop static inline functions intel_guc_submission.c

[John Harrison]

Subject should be 'drop .. functions *from* intel...'.


On 8/25/2021 20:23, Matthew Brost wrote:

s/static inline/static/g + fix function argument alignment to make
checkpatch happy.

Why?



Signed-off-by: Matthew Brost 
---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 116 +-
  1 file changed, 57 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3fe45eca95ff..f921763eb7a4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -144,7 +144,7 @@ guc_create_virtual(struct intel_engine_cs **siblings, 
unsigned int count);
  #define SCHED_STATE_BLOCKED   BIT(SCHED_STATE_BLOCKED_SHIFT)
  #define SCHED_STATE_BLOCKED_MASK  (0xfff << SCHED_STATE_BLOCKED_SHIFT)
  
-static inline void init_sched_state(struct intel_context *ce)

+static void init_sched_state(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
@@ -161,14 +161,14 @@ static bool sched_state_is_init(struct intel_context *ce)
 ~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
  }
  
-static inline bool

+static bool
  context_wait_for_deregister_to_register(struct intel_context *ce)
Could probably un-linewrap most of these split declarations and still 
stay under the line length limit.




  {
return ce->guc_state.sched_state &
SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
  }
  
-static inline void

+static void
  set_context_wait_for_deregister_to_register(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
@@ -176,7 +176,7 @@ set_context_wait_for_deregister_to_register(struct 
intel_context *ce)
SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
  }
  
-static inline void

+static void
  clr_context_wait_for_deregister_to_register(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
@@ -184,111 +184,111 @@ clr_context_wait_for_deregister_to_register(struct 
intel_context *ce)
~SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
  }
  
-static inline bool

+static bool
  context_destroyed(struct intel_context *ce)
  {
return ce->guc_state.sched_state & SCHED_STATE_DESTROYED;
  }
  
-static inline void

+static void
  set_context_destroyed(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
  }
  
-static inline bool context_pending_disable(struct intel_context *ce)

+static bool context_pending_disable(struct intel_context *ce)
  {
return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
  }
  
-static inline void set_context_pending_disable(struct intel_context *ce)

+static void set_context_pending_disable(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_PENDING_DISABLE;
  }
  
-static inline void clr_context_pending_disable(struct intel_context *ce)

+static void clr_context_pending_disable(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state &= ~SCHED_STATE_PENDING_DISABLE;
  }
  
-static inline bool context_banned(struct intel_context *ce)

+static bool context_banned(struct intel_context *ce)
  {
return ce->guc_state.sched_state & SCHED_STATE_BANNED;
  }
  
-static inline void set_context_banned(struct intel_context *ce)

+static void set_context_banned(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_BANNED;
  }
  
-static inline void clr_context_banned(struct intel_context *ce)

+static void clr_context_banned(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state &= ~SCHED_STATE_BANNED;
  }
  
-static inline bool context_enabled(struct intel_context *ce)

+static bool context_enabled(struct intel_context *ce)
  {
return ce->guc_state.sched_state & SCHED_STATE_ENABLED;
  }
  
-static inline void set_context_enabled(struct intel_context *ce)

+static void set_context_enabled(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_ENABLED;
  }
  
-static inline void clr_context_enabled(struct intel_context *ce)

+static void clr_context_enabled(struct intel_context *ce)
  {
lockdep_assert_held(&ce->guc_state.lock);
ce->guc_state.sched_state &= ~SCHED_STATE_ENABLED;
  }
  
-static inline bool context_pending_enable(struct intel_context *ce)

+static bool context_pending_enable(struct intel_context *ce)
  {
return ce->guc_state.sched_state & SCHED_STATE_PENDING_ENABLE;
  }
  
-static inline void set_context_pending_enable(struct intel_context *ce)

Re: [Intel-gfx] [PATCH 26/27] drm/i915/guc: Add GuC kernel doc

[John Harrison]

On 8/25/2021 20:23, Matthew Brost wrote:

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:
  (Daniele)
  - Fixup a few kernel doc comments

Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/intel_context_types.h |  44 +---
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  19 +++-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 101 ++
  drivers/gpu/drm/i915/i915_request.h   |  18 ++--
  4 files changed, 132 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 5285d660eacf..920ed92f4382 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -156,40 +156,52 @@ 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 are currently being

requests *that* are


+* fenced until a GuC operation completes
 */
struct list_head fences;
-   /* GuC context blocked fence */
+   /**
+* @blocked: fence used to signal when the blocking of a
+* contexts submissions is complete.

context's

'submissions are' or 'submission is'?


+*/
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 contexts current guc priority */

context's


u8 prio;
+   /**
+* @prio_count: a counter of the number requests inflight in

in flight


+* each priority bucket
+*/
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_state;
  
  	struct {

-   /* GuC LRC descriptor ID */
+   /**
+* @id: unique handle which is used to communicate information
+* with the GuC about this context, protected by

"used to communicate information" seems an odd way to say it. Maybe:
  @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..112dd29a63fe 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -41,6 +41,10 @@ struct intel_guc {
spinlock_t irq_lock;
unsigned int msg_enabled_mask;
  
+	/**

+* @outstanding_submission_g2h: number of outstanding G2H related to GuC

"G2H responses"?

Maybe even "GuC to Host responses"? Do we explain anywhere at a higher 
level what G2H (or H2G) means?




+* submission, used to determine if the GT is idle
+*/
atomic_t outstanding_submission_g2h;
  
  	struct {

@@ -49,12 +53,16 @@ struct intel_guc {
void (*disable)(struct intel_guc *guc);
} interrupts;
  
-	/*

-* contexts_lock protects the pool of free guc ids and a linked list of
-* guc ids available to be stolen
+   /**
+* @contexts_lock: protects guc_ids, guc_i

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Fix the mman selftest (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Fix the mman selftest (rev2)
URL   : https://patchwork.freedesktop.org/series/94062/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10539_full -> Patchwork_20928_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20928_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20928_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_20928_full:

### IGT changes ###

 Possible regressions 

  * igt@sysfs_heartbeat_interval@mixed@vcs0:
- shard-skl:  [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-skl9/igt@sysfs_heartbeat_interval@mi...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-skl6/igt@sysfs_heartbeat_interval@mi...@vcs0.html

  
 Suppressed 

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

  * igt@i915_pm_rps@reset:
- {shard-rkl}:NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-2/igt@i915_pm_...@reset.html

  * igt@kms_cursor_crc@pipe-c-cursor-max-size-random:
- {shard-rkl}:[SKIP][4] ([fdo#112022]) -> [SKIP][5] +39 similar 
issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-5/igt@kms_cursor_...@pipe-c-cursor-max-size-random.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-1/igt@kms_cursor_...@pipe-c-cursor-max-size-random.html

  * igt@kms_cursor_legacy@pipe-c-forked-bo:
- {shard-rkl}:[PASS][6] -> [SKIP][7] +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_cursor_leg...@pipe-c-forked-bo.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-1/igt@kms_cursor_leg...@pipe-c-forked-bo.html

  * igt@kms_cursor_legacy@pipe-d-torture-bo:
- {shard-rkl}:[SKIP][8] ([i915#533]) -> [SKIP][9] +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-5/igt@kms_cursor_leg...@pipe-d-torture-bo.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-1/igt@kms_cursor_leg...@pipe-d-torture-bo.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- {shard-rkl}:[SKIP][10] ([i915#1849]) -> [SKIP][11] +19 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-5/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- {shard-rkl}:NOTRUN -> [SKIP][12] +4 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-max.html

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- {shard-rkl}:[SKIP][13] ([i915#3558]) -> [SKIP][14] +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_plane_multi...@atomic-pipe-c-tiling-none.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-1/igt@kms_plane_multi...@atomic-pipe-c-tiling-none.html

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- {shard-rkl}:[SKIP][15] ([i915#1849] / [i915#3558]) -> [SKIP][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-2/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-5/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html

  * igt@kms_tv_load_detect@load-detect:
- {shard-rkl}:[SKIP][17] ([fdo#109309]) -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_tv_load_det...@load-detect.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-rkl-5/igt@kms_tv_load_det...@load-detect.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][19] ([i915#3002]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-snb6/igt@gem_cre...@create-massive.html
- shard-kbl:  NOTRUN -> [DMESG-WARN][20] ([i915#3002])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/shard-kbl3/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

[Tvrtko Ursulin]

On 31/08/2021 16:43, Patchwork wrote:

*Patch Details*
*Series:*	series starting with [1/2] drm/i915/debugfs: Do not report 
currently active engine when describing objects
*URL:*	https://patchwork.freedesktop.org/series/94202/ 


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




  CI Bug Log - changes from CI_DRM_10539_full -> Patchwork_20929_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_20929_full absolutely need 
to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20929_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_20929_full:



  IGT changes


Possible regressions

  *

igt@gem_softpin@noreloc-s3:

  o shard-apl: NOTRUN -> INCOMPLETE


  *
igt@sysfs_heartbeat_interval@mixed@vcs0:

  o shard-skl: PASS


-> WARN




(sysfs_heartbeat_interval:2559) [thread:2590] 
intel_allocator_msgchannel-WARNING: Error: Identifier removed
(sysfs_heartbeat_interval:2559) [thread:2590] intel_allocator-WARNING: Error 
receiving request in thread, ret = -1 [Identifier removed]
Dynamic subtest vcs0: SUCCESS (5.382s)

No idea - Zbysek?

Regards,

Tvrtko




Suppressed

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

  *

igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs:

  o {shard-rkl}: SKIP


([i915#1845]) -> SKIP


+10 similar issues
  *

igt@kms_cursor_crc@pipe-c-cursor-max-size-random:

  o {shard-rkl}: SKIP


([fdo#112022]) -> SKIP


+47 similar issues
  *

igt@kms_cursor_legacy@pipe-c-torture-move:

  o {shard-rkl}: PASS


-> SKIP


+4 similar issues
  *

igt@kms_cursor_legacy@pipe-d-torture-bo:

  o {shard-rkl}: SKIP


([i915#533]) -> SKIP


+3 similar issues
  *

igt@kms_pipe_crc_basic@read-crc-pipe-c:

  o {shard-rkl}: SKIP


([i915#1849]) -> SKIP


+25 similar issues
  *

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

  o {shard-rkl}: NOTRUN -> SKIP


+4 similar issues
  *

igt@kms_plane_multiple@atomic-pipe-c-tiling-none:

  o {shard-rkl}: SKIP


([i915#3558]) -> SKIP


+1 similar issue
  *

igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:

  o {shard-rkl}: SKIP


([i915#1849] / [i915#3558]) -> SKIP

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)

[Vudum, Lakshminarayana]

Re-reported.

From: Thomas Hellström 
Sent: Tuesday, August 31, 2021 6:29 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)



On 8/31/21 3:19 PM, Patchwork wrote:
Patch Details
Series:

drm/i915/gem: Fix the mman selftest (rev2)

URL:

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

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/index.html

CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20928
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20928, 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_20928/index.html

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:

 *   fi-rkl-guc: 
PASS
 -> 
SKIP


Lakshmi, this failure is unrelated.

Thanks,

Thomas

Re: [Intel-gfx] [PATCH 5/5] drm/i915/debugfs: pass intel_connector to intel_connector_debugfs_add()

[kernel test robot]

Hi Jani,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20210831]
[cannot apply to v5.14]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-display-debugfs-cleanups/20210830-205450
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a014-20210831 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 
4b1fde8a2b681dad2ce0c082a5d6422caa06b0bc)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/3398bb6468f037af818548e7987e8fd062278824
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Jani-Nikula/drm-i915-display-debugfs-cleanups/20210830-205450
git checkout 3398bb6468f037af818548e7987e8fd062278824
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/display/intel_connector.c:127:30: error: incompatible 
>> pointer types passing 'struct intel_connector *' to parameter of type 
>> 'struct drm_connector *' [-Werror,-Wincompatible-pointer-types]
   intel_connector_debugfs_add(intel_connector);
   ^~~
   drivers/gpu/drm/i915/display/intel_display_debugfs.h:15:56: note: passing 
argument to parameter 'connector' here
   void intel_connector_debugfs_add(struct drm_connector *connector);
  ^
   1 error generated.
--
>> drivers/gpu/drm/i915/display/intel_display_debugfs.c:2447:6: error: 
>> conflicting types for 'intel_connector_debugfs_add'
   void intel_connector_debugfs_add(struct intel_connector *intel_connector)
^
   drivers/gpu/drm/i915/display/intel_display_debugfs.h:15:6: note: previous 
declaration is here
   void intel_connector_debugfs_add(struct drm_connector *connector);
^
   1 error generated.


vim +127 drivers/gpu/drm/i915/display/intel_connector.c

   112  
   113  int intel_connector_register(struct drm_connector *connector)
   114  {
   115  struct intel_connector *intel_connector = 
to_intel_connector(connector);
   116  int ret;
   117  
   118  ret = intel_backlight_device_register(intel_connector);
   119  if (ret)
   120  goto err;
   121  
   122  if (i915_inject_probe_failure(to_i915(connector->dev))) {
   123  ret = -EFAULT;
   124  goto err_backlight;
   125  }
   126  
 > 127  intel_connector_debugfs_add(intel_connector);
   128  
   129  return 0;
   130  
   131  err_backlight:
   132  intel_backlight_device_unregister(intel_connector);
   133  err:
   134  return ret;
   135  }
   136  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)

[Patchwork]

== Series Details ==

Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)
URL   : https://patchwork.freedesktop.org/series/94161/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10540 -> Patchwork_20930


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


  Here are the changes found in Patchwork_20930 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_20930/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

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

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

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

  
 Possible fixes 

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

  * igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [DMESG-FAIL][10] ([i915#3928]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10540/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20930/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#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#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3690]: https://gitlab.freedesktop.org/drm/intel/issues/3690
  [i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (43 -> 35)
--

  Missing(8): fi-ilk-m540 bat-dg1-6 bat-dg1-5 fi-skl-guc fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10540 -> Patchwork_20930

  CI-20190529: 20190529
  CI_DRM_10540: 8eff208fe95db1015e8fe0e4026065e6f0fa7d30 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6193: 080869f804cb86b25a38889e5ce9a870571cd8c4 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20930: db849e26e74799e360e55ec39bc240e4f1b2d95c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

db849e26e747 drm/i915/edp: use MSO pixel overlap from DisplayID data
fd20bedfadd9 drm/i915/edp: postpone MSO init until after EDID read
9570941e69a9 drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO
c30e221ed86a drm/edid: abstract OUI conversion to 24-bit int
f4d0b48dd388 drm/displayid: add DisplayID v2.0 data blocks and primary use cases
c1b9800976a8 drm/displayid: re-align data block macros

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/debugfs: Do not report currently 
active engine when describing objects
URL   : https://patchwork.freedesktop.org/series/94202/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10539_full -> Patchwork_20929_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20929_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20929_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_20929_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_softpin@noreloc-s3:
- shard-apl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-apl7/igt@gem_soft...@noreloc-s3.html

  * igt@sysfs_heartbeat_interval@mixed@vcs0:
- shard-skl:  [PASS][2] -> [WARN][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-skl9/igt@sysfs_heartbeat_interval@mi...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-skl9/igt@sysfs_heartbeat_interval@mi...@vcs0.html

  
 Suppressed 

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

  * igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs:
- {shard-rkl}:[SKIP][4] ([i915#1845]) -> [SKIP][5] +10 similar 
issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-6/igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs.html

  * igt@kms_cursor_crc@pipe-c-cursor-max-size-random:
- {shard-rkl}:[SKIP][6] ([fdo#112022]) -> [SKIP][7] +47 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-5/igt@kms_cursor_...@pipe-c-cursor-max-size-random.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-2/igt@kms_cursor_...@pipe-c-cursor-max-size-random.html

  * igt@kms_cursor_legacy@pipe-c-torture-move:
- {shard-rkl}:[PASS][8] -> [SKIP][9] +4 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_cursor_leg...@pipe-c-torture-move.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-6/igt@kms_cursor_leg...@pipe-c-torture-move.html

  * igt@kms_cursor_legacy@pipe-d-torture-bo:
- {shard-rkl}:[SKIP][10] ([i915#533]) -> [SKIP][11] +3 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-5/igt@kms_cursor_leg...@pipe-d-torture-bo.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-2/igt@kms_cursor_leg...@pipe-d-torture-bo.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- {shard-rkl}:[SKIP][12] ([i915#1849]) -> [SKIP][13] +25 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-5/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- {shard-rkl}:NOTRUN -> [SKIP][14] +4 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-max.html

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- {shard-rkl}:[SKIP][15] ([i915#3558]) -> [SKIP][16] +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-1/igt@kms_plane_multi...@atomic-pipe-c-tiling-none.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-2/igt@kms_plane_multi...@atomic-pipe-c-tiling-none.html

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- {shard-rkl}:[SKIP][17] ([i915#1849] / [i915#3558]) -> [SKIP][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/shard-rkl-2/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/shard-rkl-2/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-1.30@execution@built-in-functions@vs-acosh-vec4 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][19] +6 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/pig-icl-1065g7/spec@glsl-1.30@execution@built-in-functi...@vs-acosh-vec4.html

  * spec@glsl-1.30@execution@built-in-functions@vs-op-bitxor-not-abs-int-ivec2 
(NEW):
- {pig

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Fix the mman selftest (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Fix the mman selftest (rev2)
URL   : https://patchwork.freedesktop.org/series/94062/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20928


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([fdo#109315])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

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

  * 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_20928/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#1155])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([fdo#111827]) +8 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-rkl-guc: [PASS][11] -> [SKIP][12] ([i915#3919])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([i915#3301])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
  [i915#3919]: https://gitlab.freedesktop.org/drm/intel/issues/3919
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


Participating hosts (43 -> 36)
--

  Additional (1): fi-tgl-1115g4 
  Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan 
fi-ctg-p86

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)

[Patchwork]

== Series Details ==

Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)
URL   : https://patchwork.freedesktop.org/series/94161/
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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./dr

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

[Daniel Vetter]

On Tue, Aug 31, 2021 at 02:16:56PM +0200, Daniel Vetter wrote:
> On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
> > Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> > > 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.
> > >
> > > 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.
> > >
> > > Put a FIXME comment in when this should be removable again.
> > >
> > > v2: Fix mock_context(), noticed by intel-gfx-ci.
> > >
> > > 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 
> > >  drivers/gpu/drm/i915/gem/selftests/mock_context.c |  1 +
> > >  3 files changed, 24 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_context_put() call out of a spinlock.
> > > +  */
> > > + struct work_struct release_work;
> > > +
> > >   /**
> > >* @rcu: rcu_head for deferred freeing.
> > >*/
> > > diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c 
> > > b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > > index fee070df1c97..067d68a6fe4c 100644
> > > --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > > +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > > @@ -23,6 +23,7 @@ mock_context(struct drm_i915_private *i915,
> > >   kref_init(&ctx->ref);
> > >   INIT_LIST_HEAD(&ctx->link);
> > >   ctx->i915 = i915;
> > > + INIT_WORK(&ctx->release_work, i915_gem_context_release_work);
> > >  
> > >   mutex_init(&ctx->mutex);
> > >  
> > 
> > 
> > Is the workqueue really needed? I'm not sure you could still race in
> > drm_syncobj_free when refcount is zero, so in that case removing locking
> > from _release would work as well as a workqueue.
> > 
> > Something like below would keep the drm_sync_obj_put hardirq safe.
> > 
> > I assume when freeing, th

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/debugfs: Do not report currently 
active engine when describing objects
URL   : https://patchwork.freedesktop.org/series/94202/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20929


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([fdo#109315])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * 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_20929/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#1155])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([fdo#111827]) +8 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([fdo#109285])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#1072]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([i915#3301])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20929/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


Participating hosts (43 -> 36)
--

  Additional (1): fi-tgl-1115g4 
  Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10539 -> Patchwork_20929

  CI-20190529: 20190529
  CI_DRM_10539: 9b8b4f7fc4d04c114e4cc7ae17ad2ed1406a321f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6192: b7de28791dd197d01de1512ab5960c6162564815 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20929: e71d4c66c2cdc798cff4fc8cd14814f9d95747d4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e71d4c66c2cd drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup
f3ad459c7334 drm/i915/debugfs: Do not report currently active engine when 
describing objects

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

[Jani Nikula]

On Tue, 31 Aug 2021, Jani Nikula  wrote:
> On Mon, 30 Aug 2021, Ville Syrjälä  wrote:
>> Don't we need to check the OUI to make sure the block is the right
>> type? I don't have the v2 spec at hand atm, but I presume a vendor
>> specific block could contain all kinds of different things?
>
> You're right.

I resent the entire series because I added an OUI helper patch. I don't
think patchwork could handle that as an in-reply-to update.

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

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH v2 6/6] drm/i915/edp: use MSO pixel overlap from DisplayID data

[Jani Nikula]

Now that we have MSO pixel overlap in display info, use it.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index df402f63b741..baf21f9aa40e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2420,6 +2420,8 @@ static void intel_edp_mso_mode_fixup(struct 
intel_connector *connector,
 static void intel_edp_mso_init(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   struct intel_connector *connector = intel_dp->attached_connector;
+   struct drm_display_info *info = &connector->base.display_info;
u8 mso;
 
if (intel_dp->edp_dpcd[0] < DP_EDP_14)
@@ -2438,8 +2440,9 @@ static void intel_edp_mso_init(struct intel_dp *intel_dp)
}
 
if (mso) {
-   drm_dbg_kms(&i915->drm, "Sink MSO %ux%u configuration\n",
-   mso, drm_dp_max_lane_count(intel_dp->dpcd) / mso);
+   drm_dbg_kms(&i915->drm, "Sink MSO %ux%u configuration, pixel 
overlap %u\n",
+   mso, drm_dp_max_lane_count(intel_dp->dpcd) / mso,
+   info->mso_pixel_overlap);
if (!HAS_MSO(i915)) {
drm_err(&i915->drm, "No source MSO support, 
disabling\n");
mso = 0;
@@ -2447,7 +2450,7 @@ static void intel_edp_mso_init(struct intel_dp *intel_dp)
}
 
intel_dp->mso_link_count = mso;
-   intel_dp->mso_pixel_overlap = 0; /* FIXME: read from DisplayID v2.0 */
+   intel_dp->mso_pixel_overlap = mso ? info->mso_pixel_overlap : 0;
 }
 
 static bool
-- 
2.30.2

[Intel-gfx] [PATCH v2 5/6] drm/i915/edp: postpone MSO init until after EDID read

[Jani Nikula]

MSO will require segment pixel overlap information from the
EDID. Postpone MSO init until after we've read and cached the EDID.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 64e8151d13a4..df402f63b741 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2536,8 +2536,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
 */
intel_edp_init_source_oui(intel_dp, true);
 
-   intel_edp_mso_init(intel_dp);
-
return true;
 }
 
@@ -4804,6 +4802,9 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
if (fixed_mode)
downclock_mode = intel_drrs_init(intel_connector, fixed_mode);
 
+   /* MSO requires information from the EDID */
+   intel_edp_mso_init(intel_dp);
+
/* multiply the mode clock and horizontal timings for MSO */
intel_edp_mso_mode_fixup(intel_connector, fixed_mode);
intel_edp_mso_mode_fixup(intel_connector, downclock_mode);
-- 
2.30.2

[Intel-gfx] [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

[Jani Nikula]

The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.

DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID extension
blocks. DisplayID v2.0 does not have such a section, perhaps implying
that DisplayID v2.0 data should not be included in EDID extensions, but
rather in a "pure" DisplayID structure at its own DDC address pair
A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3.

However, in practice, displays out in the field have embedded DisplayID
v2.0 data blocks in EDID extensions, including, in particular, some eDP
MSO displays, where a pure DisplayID structure is not available at all.

Parse the MSO data from the DisplayID data block. Do it as part of
drm_add_display_info(), extending it to parse also DisplayID data to
avoid requiring extra calls to update the information.

v2: Check for VESA OUI (Ville)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c  | 72 +
 include/drm/drm_connector.h | 12 +++
 include/drm/drm_displayid.h | 13 +++
 3 files changed, 97 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 92974b1478bc..c45c225267ca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -5145,6 +5146,71 @@ void drm_get_monitor_range(struct drm_connector 
*connector,
  info->monitor_range.max_vfreq);
 }
 
+static void drm_parse_vesa_mso_data(struct drm_connector *connector,
+   const struct displayid_block *block)
+{
+   struct displayid_vesa_vendor_specific_block *vesa =
+   (struct displayid_vesa_vendor_specific_block *)block;
+   struct drm_display_info *info = &connector->display_info;
+
+   if (block->num_bytes < 3) {
+   drm_dbg_kms(connector->dev, "Unexpected vendor block size %u\n",
+   block->num_bytes);
+   return;
+   }
+
+   if (oui(vesa->oui[0], vesa->oui[1], vesa->oui[2]) != VESA_IEEE_OUI)
+   return;
+
+   if (sizeof(*vesa) != sizeof(*block) + block->num_bytes) {
+   drm_dbg_kms(connector->dev, "Unexpected VESA vendor block 
size\n");
+   return;
+   }
+
+   switch (FIELD_GET(DISPLAYID_VESA_MSO_MODE, vesa->mso)) {
+   default:
+   drm_dbg_kms(connector->dev, "Reserved MSO mode value\n");
+   fallthrough;
+   case 0:
+   info->mso_stream_count = 0;
+   break;
+   case 1:
+   info->mso_stream_count = 2; /* 2 or 4 links */
+   break;
+   case 2:
+   info->mso_stream_count = 4; /* 4 links */
+   break;
+   }
+
+   if (!info->mso_stream_count) {
+   info->mso_pixel_overlap = 0;
+   return;
+   }
+
+   info->mso_pixel_overlap = FIELD_GET(DISPLAYID_VESA_MSO_OVERLAP, 
vesa->mso);
+   if (info->mso_pixel_overlap > 8) {
+   drm_dbg_kms(connector->dev, "Reserved MSO pixel overlap value 
%u\n",
+   info->mso_pixel_overlap);
+   info->mso_pixel_overlap = 8;
+   }
+
+   drm_dbg_kms(connector->dev, "MSO stream count %u, pixel overlap %u\n",
+   info->mso_stream_count, info->mso_pixel_overlap);
+}
+
+static void drm_update_mso(struct drm_connector *connector, const struct edid 
*edid)
+{
+   const struct displayid_block *block;
+   struct displayid_iter iter;
+
+   displayid_iter_edid_begin(edid, &iter);
+   displayid_iter_for_each(block, &iter) {
+   if (block->tag == DATA_BLOCK_2_VENDOR_SPECIFIC)
+   drm_parse_vesa_mso_data(connector, block);
+   }
+   displayid_iter_end(&iter);
+}
+
 /* A connector has no EDID information, so we've got no EDID to compute quirks 
from. Reset
  * all of the values which would have been set from EDID
  */
@@ -5168,6 +5234,9 @@ drm_reset_display_info(struct drm_connector *connector)
 
info->non_desktop = 0;
memset(&info->monitor_range, 0, sizeof(info->monitor_range));
+
+   info->mso_stream_count = 0;
+   info->mso_pixel_overlap = 0;
 }
 
 u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
*edid)
@@ -5246,6 +5315,9 @@ u32 drm_add_display_info(struct drm_connector *connector, 
const struct edid *edi
info->color_formats |= DRM_COLOR_FORMAT_YCRCB444;
if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB422)
info->color_formats |= DRM_COLOR_FORMAT_YCRCB422;
+
+   drm_update_mso(connector, edid);
+
return quirks;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 79fa34e5ccdb..379746d3266f 100

[Intel-gfx] [PATCH v2 3/6] drm/edid: abstract OUI conversion to 24-bit int

[Jani Nikula]

Replace the open coded OUI conversion from three bytes to a 24-bit int,
as we'll be adding one more user shortly. No functional changes.

Side note: CTA-861 format has the OUI bytes in reverse order.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6325877c5fd6..92974b1478bc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -49,6 +49,11 @@
(((edid)->version > (maj)) || \
 ((edid)->version == (maj) && (edid)->revision > (min)))
 
+static int oui(u8 first, u8 second, u8 third)
+{
+   return (first << 16) | (second << 8) | third;
+}
+
 #define EDID_EST_TIMINGS 16
 #define EDID_STD_TIMINGS 8
 #define EDID_DETAILED_TIMINGS 4
@@ -4113,32 +4118,24 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
 
 static bool cea_db_is_hdmi_vsdb(const u8 *db)
 {
-   int hdmi_id;
-
if (cea_db_tag(db) != VENDOR_BLOCK)
return false;
 
if (cea_db_payload_len(db) < 5)
return false;
 
-   hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
-
-   return hdmi_id == HDMI_IEEE_OUI;
+   return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
 }
 
 static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
 {
-   unsigned int oui;
-
if (cea_db_tag(db) != VENDOR_BLOCK)
return false;
 
if (cea_db_payload_len(db) < 7)
return false;
 
-   oui = db[3] << 16 | db[2] << 8 | db[1];
-
-   return oui == HDMI_FORUM_IEEE_OUI;
+   return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
 }
 
 static bool cea_db_is_vcdb(const u8 *db)
-- 
2.30.2

[Intel-gfx] [PATCH v2 2/6] drm/displayid: add DisplayID v2.0 data blocks and primary use cases

[Jani Nikula]

DisplayID v2.0 changes the data block identifiers and product types (now
called primary use cases).

Signed-off-by: Jani Nikula 
---
 include/drm/drm_displayid.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index 0ed9445b5482..79771091771a 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -26,6 +26,10 @@
 
 struct edid;
 
+/* DisplayID Structure versions */
+#define DISPLAY_ID_STRUCTURE_VER_120x12
+#define DISPLAY_ID_STRUCTURE_VER_200x20
+
 /* DisplayID Structure v1r2 Data Blocks */
 #define DATA_BLOCK_PRODUCT_ID  0x00
 #define DATA_BLOCK_DISPLAY_PARAMETERS  0x01
@@ -48,6 +52,20 @@ struct edid;
 #define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
 #define DATA_BLOCK_CTA 0x81
 
+/* DisplayID Structure v2r0 Data Blocks */
+#define DATA_BLOCK_2_PRODUCT_ID0x20
+#define DATA_BLOCK_2_DISPLAY_PARAMETERS0x21
+#define DATA_BLOCK_2_TYPE_7_DETAILED_TIMING0x22
+#define DATA_BLOCK_2_TYPE_8_ENUMERATED_TIMING  0x23
+#define DATA_BLOCK_2_TYPE_9_FORMULA_TIMING 0x24
+#define DATA_BLOCK_2_DYNAMIC_VIDEO_TIMING  0x25
+#define DATA_BLOCK_2_DISPLAY_INTERFACE_FEATURES0x26
+#define DATA_BLOCK_2_STEREO_DISPLAY_INTERFACE  0x27
+#define DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY0x28
+#define DATA_BLOCK_2_CONTAINER_ID  0x29
+#define DATA_BLOCK_2_VENDOR_SPECIFIC   0x7e
+#define DATA_BLOCK_2_CTA_DISPLAY_ID0x81
+
 /* DisplayID Structure v1r2 Product Type */
 #define PRODUCT_TYPE_EXTENSION 0
 #define PRODUCT_TYPE_TEST  1
@@ -57,6 +75,17 @@ struct edid;
 #define PRODUCT_TYPE_REPEATER  5
 #define PRODUCT_TYPE_DIRECT_DRIVE  6
 
+/* DisplayID Structure v2r0 Display Product Primary Use Case (~Product Type) */
+#define PRIMARY_USE_EXTENSION  0
+#define PRIMARY_USE_TEST   1
+#define PRIMARY_USE_GENERIC2
+#define PRIMARY_USE_TV 3
+#define PRIMARY_USE_DESKTOP_PRODUCTIVITY   4
+#define PRIMARY_USE_DESKTOP_GAMING 5
+#define PRIMARY_USE_PRESENTATION   6
+#define PRIMARY_USE_HEAD_MOUNTED_VR7
+#define PRIMARY_USE_HEAD_MOUNTED_AR8
+
 struct displayid_header {
u8 rev;
u8 bytes;
-- 
2.30.2

[Intel-gfx] [PATCH v2 1/6] drm/displayid: re-align data block macros

[Jani Nikula]

Make the values easier to read. Also add DisplayID Structure version and
revision information (this is different from the spec version).

Signed-off-by: Jani Nikula 
---
 include/drm/drm_displayid.h | 57 +++--
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index ec64d141f578..0ed9445b5482 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -26,35 +26,36 @@
 
 struct edid;
 
-#define DATA_BLOCK_PRODUCT_ID 0x00
-#define DATA_BLOCK_DISPLAY_PARAMETERS 0x01
-#define DATA_BLOCK_COLOR_CHARACTERISTICS 0x02
-#define DATA_BLOCK_TYPE_1_DETAILED_TIMING 0x03
-#define DATA_BLOCK_TYPE_2_DETAILED_TIMING 0x04
-#define DATA_BLOCK_TYPE_3_SHORT_TIMING 0x05
-#define DATA_BLOCK_TYPE_4_DMT_TIMING 0x06
-#define DATA_BLOCK_VESA_TIMING 0x07
-#define DATA_BLOCK_CEA_TIMING 0x08
-#define DATA_BLOCK_VIDEO_TIMING_RANGE 0x09
-#define DATA_BLOCK_PRODUCT_SERIAL_NUMBER 0x0a
-#define DATA_BLOCK_GP_ASCII_STRING 0x0b
-#define DATA_BLOCK_DISPLAY_DEVICE_DATA 0x0c
-#define DATA_BLOCK_INTERFACE_POWER_SEQUENCING 0x0d
-#define DATA_BLOCK_TRANSFER_CHARACTERISTICS 0x0e
-#define DATA_BLOCK_DISPLAY_INTERFACE 0x0f
-#define DATA_BLOCK_STEREO_DISPLAY_INTERFACE 0x10
-#define DATA_BLOCK_TILED_DISPLAY 0x12
-#define DATA_BLOCK_CTA 0x81
+/* DisplayID Structure v1r2 Data Blocks */
+#define DATA_BLOCK_PRODUCT_ID  0x00
+#define DATA_BLOCK_DISPLAY_PARAMETERS  0x01
+#define DATA_BLOCK_COLOR_CHARACTERISTICS   0x02
+#define DATA_BLOCK_TYPE_1_DETAILED_TIMING  0x03
+#define DATA_BLOCK_TYPE_2_DETAILED_TIMING  0x04
+#define DATA_BLOCK_TYPE_3_SHORT_TIMING 0x05
+#define DATA_BLOCK_TYPE_4_DMT_TIMING   0x06
+#define DATA_BLOCK_VESA_TIMING 0x07
+#define DATA_BLOCK_CEA_TIMING  0x08
+#define DATA_BLOCK_VIDEO_TIMING_RANGE  0x09
+#define DATA_BLOCK_PRODUCT_SERIAL_NUMBER   0x0a
+#define DATA_BLOCK_GP_ASCII_STRING 0x0b
+#define DATA_BLOCK_DISPLAY_DEVICE_DATA 0x0c
+#define DATA_BLOCK_INTERFACE_POWER_SEQUENCING  0x0d
+#define DATA_BLOCK_TRANSFER_CHARACTERISTICS0x0e
+#define DATA_BLOCK_DISPLAY_INTERFACE   0x0f
+#define DATA_BLOCK_STEREO_DISPLAY_INTERFACE0x10
+#define DATA_BLOCK_TILED_DISPLAY   0x12
+#define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
+#define DATA_BLOCK_CTA 0x81
 
-#define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
-
-#define PRODUCT_TYPE_EXTENSION 0
-#define PRODUCT_TYPE_TEST 1
-#define PRODUCT_TYPE_PANEL 2
-#define PRODUCT_TYPE_MONITOR 3
-#define PRODUCT_TYPE_TV 4
-#define PRODUCT_TYPE_REPEATER 5
-#define PRODUCT_TYPE_DIRECT_DRIVE 6
+/* DisplayID Structure v1r2 Product Type */
+#define PRODUCT_TYPE_EXTENSION 0
+#define PRODUCT_TYPE_TEST  1
+#define PRODUCT_TYPE_PANEL 2
+#define PRODUCT_TYPE_MONITOR   3
+#define PRODUCT_TYPE_TV4
+#define PRODUCT_TYPE_REPEATER  5
+#define PRODUCT_TYPE_DIRECT_DRIVE  6
 
 struct displayid_header {
u8 rev;
-- 
2.30.2

[Intel-gfx] [PATCH v2 0/6] drm/displayid: VESA vendor block and drm/i915 MSO use of it

[Jani Nikula]

v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI
check and an OUI helper patch added.

Jani Nikula (6):
  drm/displayid: re-align data block macros
  drm/displayid: add DisplayID v2.0 data blocks and primary use cases
  drm/edid: abstract OUI conversion to 24-bit int
  drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO
  drm/i915/edp: postpone MSO init until after EDID read
  drm/i915/edp: use MSO pixel overlap from DisplayID data

 drivers/gpu/drm/drm_edid.c  |  89 ++---
 drivers/gpu/drm/i915/display/intel_dp.c |  14 ++--
 include/drm/drm_connector.h |  12 +++
 include/drm/drm_displayid.h | 101 +---
 4 files changed, 172 insertions(+), 44 deletions(-)

-- 
2.30.2

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/debugfs: Do not report currently 
active engine when describing objects
URL   : https://patchwork.freedesktop.org/series/94202/
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/lin

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)

[Thomas Hellström]

On 8/31/21 3:19 PM, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   drm/i915/gem: Fix the mman selftest (rev2)
*URL:* 	https://patchwork.freedesktop.org/series/94062/ 


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




  CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20928


Summary

*FAILURE*

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20928, 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_20928/index.html



Possible new issues

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



  IGT changes


Possible regressions

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
  o fi-rkl-guc: PASS


-> SKIP





Lakshmi, this failure is unrelated.

Thanks,

Thomas

[Intel-gfx] [PATCH 2/2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.

Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between the two GPUs, which
results in deadlocks because semaphore target location in HWSP is neither
shared between the two, nor mapped in both GGTT spaces.

To fix it the patch adds an additional check to a couple of relevant code
paths in order to prevent using semaphores for inter-engine
synchronisation when relevant objects are not in the same GGTT space.

v2:
 * Avoid adding rq->i915. (Chris)

v3:
 * Use GGTT which describes the limit more precisely.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_request.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index ce446716d092..e671f4e993cb 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1152,6 +1152,12 @@ __emit_semaphore_wait(struct i915_request *to,
return 0;
 }
 
+static bool
+can_use_semaphore_wait(struct i915_request *to, struct i915_request *from)
+{
+   return to->engine->gt->ggtt == from->engine->gt->ggtt;
+}
+
 static int
 emit_semaphore_wait(struct i915_request *to,
struct i915_request *from,
@@ -1160,6 +1166,9 @@ emit_semaphore_wait(struct i915_request *to,
const intel_engine_mask_t mask = READ_ONCE(from->engine)->mask;
struct i915_sw_fence *wait = &to->submit;
 
+   if (!can_use_semaphore_wait(to, from))
+   goto await_fence;
+
if (!intel_context_use_semaphores(to->context))
goto await_fence;
 
@@ -1263,7 +1272,8 @@ __i915_request_await_execution(struct i915_request *to,
 * immediate execution, and so we must wait until it reaches the
 * active slot.
 */
-   if (intel_engine_has_semaphores(to->engine) &&
+   if (can_use_semaphore_wait(to, from) &&
+   intel_engine_has_semaphores(to->engine) &&
!i915_request_has_initial_breadcrumb(to)) {
err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
if (err < 0)
-- 
2.30.2

[Intel-gfx] [PATCH 1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

It is not very useful to have code which tries to report a rapidly
transient state which will not report anything majority of the time,
especially since it is currently only used from
/i915_gem_framebuffers.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 -
 drivers/gpu/drm/i915/i915_debugfs.c|  5 -
 2 files changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 48112b9d76df..3043fcbd31bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -503,23 +503,6 @@ i915_gem_object_finish_access(struct drm_i915_gem_object 
*obj)
i915_gem_object_unpin_pages(obj);
 }
 
-static inline struct intel_engine_cs *
-i915_gem_object_last_write_engine(struct drm_i915_gem_object *obj)
-{
-   struct intel_engine_cs *engine = NULL;
-   struct dma_fence *fence;
-
-   rcu_read_lock();
-   fence = dma_resv_get_excl_unlocked(obj->base.resv);
-   rcu_read_unlock();
-
-   if (fence && dma_fence_is_i915(fence) && !dma_fence_is_signaled(fence))
-   engine = to_request(fence)->engine;
-   dma_fence_put(fence);
-
-   return engine;
-}
-
 void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
 unsigned int cache_level);
 void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 04351a851586..1795af81bf41 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -139,7 +139,6 @@ void
 i915_debugfs_describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   struct intel_engine_cs *engine;
struct i915_vma *vma;
int pin_count = 0;
 
@@ -229,10 +228,6 @@ i915_debugfs_describe_obj(struct seq_file *m, struct 
drm_i915_gem_object *obj)
seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
if (i915_gem_object_is_framebuffer(obj))
seq_printf(m, " (fb)");
-
-   engine = i915_gem_object_last_write_engine(obj);
-   if (engine)
-   seq_printf(m, " (%s)", engine->name);
 }
 
 static int i915_gem_object_info(struct seq_file *m, void *data)
-- 
2.30.2

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Fix the mman selftest (rev2)
URL   : https://patchwork.freedesktop.org/series/94062/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20928


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-rkl-guc: [PASS][1] -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10539/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

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

  * 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_20928/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#1155])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([i915#3301])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20928/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

[Tvrtko Ursulin]

On 31/08/2021 13:43, Daniel Vetter wrote:

On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:


On 30/08/2021 09:26, Daniel Vetter wrote:

On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:


On 27/08/2021 15:39, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.

Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between the two GPUs, which
results in deadlocks because semaphore target location in HWSP is neither
shared between the two, nor mapped in both GGTT spaces.

To fix it the patch adds an additional check to a couple of relevant code
paths in order to prevent using semaphores for inter-engine
synchronisation between different driver instances.

Patch also moves singly used i915_gem_object_last_write_engine to be
private in its only calling unit (debugfs), while modifying it to only
show activity belonging to the respective driver instance.

What remains in this problem space is the question of the GEM busy ioctl.
We have a somewhat ambigous comment there saying only status of native
fences will be reported, which could be interpreted as either i915, or
native to the drm fd. For now I have decided to leave that as is, meaning
any i915 instance activity continues to be reported.

v2:
* Avoid adding rq->i915. (Chris)

Signed-off-by: Tvrtko Ursulin 


Can't we just delete semaphore code and done?
- GuC won't have it
- media team benchmarked on top of softpin media driver, found no
difference


You have S-curve for saturated workloads or something else? How thorough and
which media team I guess.

 From memory it was a nice win for some benchmarks (non-saturated ones), but
as I have told you previously, we haven't been putting numbers in commit
messages since it wasn't allowed. I may be able to dig out some more details
if I went trawling through GEM channel IRC logs, although probably not the
actual numbers since those were usually on pastebin. Or you go an talk with
Chris since he probably remembers more details. Or you just decide you don't
care and remove it. I wouldn't do that without putting the complete story in
writing, but it's your call after all.


Media has also changed, they're not using relocations anymore.


Meaning you think it changes the benchmarking story? When coupled with 
removal of GPU relocations then possibly yes.



Unless there's solid data performance tuning of any kind that gets in the
way simply needs to be removed. Yes this is radical, but the codebase is
in a state to require this.

So either way we'd need to rebenchmark this if it's really required. Also


Therefore can you share what benchmarks have been done or is it secret? 
 As said, I think the non-saturated case was the more interesting one here.



if we really need this code still someone needs to fix the design, the
current code is making layering violations an art form.

>

Anyway, without the debugfs churn it is more or less two line patch to fix
igfx + dgfx hybrid setup. So while mulling it over this could go in. I'd
just refine it to use a GGTT check instead of GT. And unless DG1 ends up
being GuC only.


The minimal robust fix here is imo to stop us from upcasting dma_fence to
i915_request if it's not for our device. Not sprinkle code here into the
semaphore code. We shouldn't even get this far with foreign fences.


Device check does not work for multi-tile. It was one of my earlier 
attempts before I realized the problem. You'll see v3 which I think 
handles all the cases.


You also forgot to comment on the question lower in the email. I'll just 
send a patch which removes that anyway so you can comment there.


Regards,

Tvrtko


-Daniel




- pre-gen8 semaphore code was also silently ditched and no one cared

Plus removing semaphore code would greatly simplify conversion to
drm/sched.


---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 --
drivers/gpu/drm/i915/i915_debugfs.c| 39 --
drivers/gpu/drm/i915/i915_request.c| 12 ++-
3 files changed, 47 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 48112b9d76df..3043fcbd31bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -503,23 +503,6 @@ i915_gem_object_finish_access(struct drm_i915_gem_object 
*obj)
i915_gem_object_unpin_pages(obj);
}
-static inline struct intel_engine_cs *
-i915_gem_object_last_write_engine(struct drm_i915_gem_object *obj)
-{
-   struct intel_engine_cs *engine = NULL;
-   struct dma_fence *fence;
-
-   rcu_read_lock();
-   fence = dma_resv_get_excl_unlocked(obj->base.resv);
-   rcu_read_unlock();
-
-   if (fence && dma_fence_is_i915(fence) && !dma_f

Re: [Intel-gfx] [PATCH 8/8] drm/i915/perf: Map OA buffer to user space for gen12 performance query

[Daniel Vetter]

On Mon, Aug 30, 2021 at 12:38:51PM -0700, Umesh Nerlige Ramappa wrote:
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
> implementation for query, but Gen12+ requires a new approach for query
> based on triggered reports within oa buffer.
> 
> Triggering reports into the OA buffer is achieved by writing into a
> a trigger register. Optionally an unused counter/register is set with a
> marker value such that a triggered report can be identified in the OA
> buffer. Reports are usually triggered at the start and end of work that
> is measured.
> 
> Since OA buffer is large and queries can be frequent, an efficient way
> to look for triggered reports is required. By knowing the current head
> and tail offsets into the OA buffer, it is easier to determine the
> locality of the reports of interest.
> 
> Current perf OA interface does not expose head/tail information to the
> user and it filters out invalid reports before sending data to user.
> Also considering limited size of user buffer used during a query,
> creating a 1:1 copy of the OA buffer at the user space added undesired
> complexity.
> 
> The solution was to map the OA buffer to user space provided
> 
> (1) that it is accessed from a privileged user.
> (2) OA report filtering is not used.
> 
> These 2 conditions would satisfy the safety criteria that the current
> perf interface addresses.

This is a perf improvement. Please include benchmark numbers to justify
it.

> 
> To enable the query:
> - Add an ioctl to expose head and tail to the user
> - Add an ioctl to return size and offset of the OA buffer
> - Map the OA buffer to the user space
> 
> v2:
> - Improve commit message (Chris)
> - Do not mmap based on gem object filp. Instead, use perf_fd and support
>   mmap syscall (Chris)
> - Pass non-zero offset in mmap to enforce the right object is
>   mapped (Chris)
> - Do not expose gpu_address (Chris)
> - Verify start and length of vma for page alignment (Lionel)
> - Move SQNTL config out (Lionel)
> 
> v3: (Chris)
> - Omit redundant checks
> - Return VM_FAULT_SIGBUS is old stream is closed
> - Maintain reference counts to stream in vm_open and vm_close
> - Use switch to identify object to be mapped
> 
> v4: Call kref_put on closing perf fd (Chris)
> v5:
> - Strip access to OA buffer from unprivileged child of a privileged
>   parent. Use VM_DONTCOPY
> - Enforce MAP_PRIVATE by checking for VM_MAYSHARE
> 
> v6:
> (Chris)
> - Use len of -1 in unmap_mapping_range
> - Don't use stream->oa_buffer.vma->obj in vm_fault_oa
> - Use kernel block comment style
> - do_mmap gets a reference to the file and puts it in do_munmap, so
>   no need to maintain a reference to i915_perf_stream. Hence, remove
>   vm_open/vm_close and stream->closed hooks/checks.
> (Umesh)
> - Do not allow mmap if SAMPLE_OA_REPORT is not set during
>   i915_perf_open_ioctl.
> - Drop ioctl returning head/tail since this information is already
>   whitelisted. Remove hooks to read head register.
> 
> v7: (Chris)
> - unmap before destroy
> - change ioctl argument struct
> 
> v8: Documentation and more checks (Chris)
> v9: Fix comment style (Umesh)
> v10: Update uapi comment (Ashutosh)
> 
> Signed-off-by: Piotr Maciejewski 
> Signed-off-by: Umesh Nerlige Ramappa 
> Reviewed-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c |   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +
>  drivers/gpu/drm/i915/i915_perf.c | 126 ++-
>  include/uapi/drm/i915_drm.h  |  33 ++
>  4 files changed, 161 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 5130e8ed9564..84cdce2ee447 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -213,7 +213,7 @@ compute_partial_view(const struct drm_i915_gem_object 
> *obj,
>   return view;
>  }
>  
> -static vm_fault_t i915_error_to_vmf_fault(int err)
> +vm_fault_t i915_error_to_vmf_fault(int err)
>  {
>   switch (err) {
>   default:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> index efee9e0d2508..1190a3a228ea 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> @@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct 
> drm_i915_gem_object *obj);
>  
>  void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
>  
> +vm_fault_t i915_error_to_vmf_fault(int err);
> +
>  #endif
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index de3d1738aabe..1f8d4f3a2148 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -192,10 +192,12 @@
>   */
>  
>  #include 
> +#include 
>  #includ

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

[Daniel Vetter]

On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
> 
> On 30/08/2021 09:26, Daniel Vetter wrote:
> > On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 27/08/2021 15:39, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin 
> > > > 
> > > > In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
> > > > when rendering is done on Intel dgfx and scanout/composition on Intel
> > > > igfx.
> > > > 
> > > > Before this patch the driver was not quite ready for that setup, mainly
> > > > because it was able to emit a semaphore wait between the two GPUs, which
> > > > results in deadlocks because semaphore target location in HWSP is 
> > > > neither
> > > > shared between the two, nor mapped in both GGTT spaces.
> > > > 
> > > > To fix it the patch adds an additional check to a couple of relevant 
> > > > code
> > > > paths in order to prevent using semaphores for inter-engine
> > > > synchronisation between different driver instances.
> > > > 
> > > > Patch also moves singly used i915_gem_object_last_write_engine to be
> > > > private in its only calling unit (debugfs), while modifying it to only
> > > > show activity belonging to the respective driver instance.
> > > > 
> > > > What remains in this problem space is the question of the GEM busy 
> > > > ioctl.
> > > > We have a somewhat ambigous comment there saying only status of native
> > > > fences will be reported, which could be interpreted as either i915, or
> > > > native to the drm fd. For now I have decided to leave that as is, 
> > > > meaning
> > > > any i915 instance activity continues to be reported.
> > > > 
> > > > v2:
> > > >* Avoid adding rq->i915. (Chris)
> > > > 
> > > > Signed-off-by: Tvrtko Ursulin 
> > 
> > Can't we just delete semaphore code and done?
> > - GuC won't have it
> > - media team benchmarked on top of softpin media driver, found no
> >difference
> 
> You have S-curve for saturated workloads or something else? How thorough and
> which media team I guess.
> 
> From memory it was a nice win for some benchmarks (non-saturated ones), but
> as I have told you previously, we haven't been putting numbers in commit
> messages since it wasn't allowed. I may be able to dig out some more details
> if I went trawling through GEM channel IRC logs, although probably not the
> actual numbers since those were usually on pastebin. Or you go an talk with
> Chris since he probably remembers more details. Or you just decide you don't
> care and remove it. I wouldn't do that without putting the complete story in
> writing, but it's your call after all.

Media has also changed, they're not using relocations anymore.

Unless there's solid data performance tuning of any kind that gets in the
way simply needs to be removed. Yes this is radical, but the codebase is
in a state to require this.

So either way we'd need to rebenchmark this if it's really required. Also
if we really need this code still someone needs to fix the design, the
current code is making layering violations an art form.

> Anyway, without the debugfs churn it is more or less two line patch to fix
> igfx + dgfx hybrid setup. So while mulling it over this could go in. I'd
> just refine it to use a GGTT check instead of GT. And unless DG1 ends up
> being GuC only.

The minimal robust fix here is imo to stop us from upcasting dma_fence to
i915_request if it's not for our device. Not sprinkle code here into the
semaphore code. We shouldn't even get this far with foreign fences.
-Daniel

> 
> > - pre-gen8 semaphore code was also silently ditched and no one cared
> > 
> > Plus removing semaphore code would greatly simplify conversion to
> > drm/sched.
> > 
> > > > ---
> > > >drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 --
> > > >drivers/gpu/drm/i915/i915_debugfs.c| 39 
> > > > --
> > > >drivers/gpu/drm/i915/i915_request.c| 12 ++-
> > > >3 files changed, 47 insertions(+), 21 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > > > index 48112b9d76df..3043fcbd31bd 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > > > @@ -503,23 +503,6 @@ i915_gem_object_finish_access(struct 
> > > > drm_i915_gem_object *obj)
> > > > i915_gem_object_unpin_pages(obj);
> > > >}
> > > > -static inline struct intel_engine_cs *
> > > > -i915_gem_object_last_write_engine(struct drm_i915_gem_object *obj)
> > > > -{
> > > > -   struct intel_engine_cs *engine = NULL;
> > > > -   struct dma_fence *fence;
> > > > -
> > > > -   rcu_read_lock();
> > > > -   fence = dma_resv_get_excl_unlocked(obj->base.resv);
> > > > -   rcu_read_unlock();
> > > > -
> > > > -   if (fence && dma_fence_is_i915(fence) && 
> > > > !dma_fence_is_signaled(fence))
> > > > -   engine = to_request(fence)->engi

[Intel-gfx] [PATCH v2] drm/i915/gem: Fix the mman selftest

[Thomas Hellström]

Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so
for that mmap type, use __i915_gem_object_create_user() instead of
i915_gem_object_create_internal(), as we really want to tests objects
mmap-able by user-space.

This also means that the out-of-space error happens at object creation
and returns -ENXIO rather than -ENOSPC, so fix the code up to expect
that on out-of-offset-space errors.

Finally only use I915_MMAP_TYPE_FIXED for LMEM and SMEM for now if
testing on LMEM-capable devices. For stolen LMEM, we still take the
same path as for integrated, as that haven't been moved over to TTM yet,
and user-space should not be able to create out of stolen LMEM anyway.

v2:
 - Check the presence of the obj->ops->mmap_offset callback rather than
   hardcoding the supported mmap regions in can_mmap() (Maarten Lankhorst)

Fixes: 7961c5b60f23 ("drm/i915: Add TTM offset argument to mmap.")
Cc: Maarten Lankhorst 
Signed-off-by: Thomas Hellström 
Reviewed-by: Maarten Lankhorst 
---
 .../drm/i915/gem/selftests/i915_gem_mman.c| 26 ++-
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index b20f5621f62b..a2c34e5a1c54 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -581,6 +581,20 @@ static enum i915_mmap_type default_mapping(struct 
drm_i915_private *i915)
return I915_MMAP_TYPE_GTT;
 }
 
+static struct drm_i915_gem_object *
+create_sys_or_internal(struct drm_i915_private *i915,
+  unsigned long size)
+{
+   if (HAS_LMEM(i915)) {
+   struct intel_memory_region *sys_region =
+   i915->mm.regions[INTEL_REGION_SMEM];
+
+   return __i915_gem_object_create_user(i915, size, &sys_region, 
1);
+   }
+
+   return i915_gem_object_create_internal(i915, size);
+}
+
 static bool assert_mmap_offset(struct drm_i915_private *i915,
   unsigned long size,
   int expected)
@@ -589,7 +603,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
*i915,
u64 offset;
int ret;
 
-   obj = i915_gem_object_create_internal(i915, size);
+   obj = create_sys_or_internal(i915, size);
if (IS_ERR(obj))
return expected && expected == PTR_ERR(obj);
 
@@ -633,6 +647,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
struct drm_mm_node *hole, *next;
int loop, err = 0;
u64 offset;
+   int enospc = HAS_LMEM(i915) ? -ENXIO : -ENOSPC;
 
/* Disable background reaper */
disable_retire_worker(i915);
@@ -683,14 +698,14 @@ static int igt_mmap_offset_exhaustion(void *arg)
}
 
/* Too large */
-   if (!assert_mmap_offset(i915, 2 * PAGE_SIZE, -ENOSPC)) {
+   if (!assert_mmap_offset(i915, 2 * PAGE_SIZE, enospc)) {
pr_err("Unexpectedly succeeded in inserting too large object 
into single page hole\n");
err = -EINVAL;
goto out;
}
 
/* Fill the hole, further allocation attempts should then fail */
-   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   obj = create_sys_or_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
pr_err("Unable to create object for reclaimed hole\n");
@@ -703,7 +718,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
goto err_obj;
}
 
-   if (!assert_mmap_offset(i915, PAGE_SIZE, -ENOSPC)) {
+   if (!assert_mmap_offset(i915, PAGE_SIZE, enospc)) {
pr_err("Unexpectedly succeeded in inserting object into no 
holes!\n");
err = -EINVAL;
goto err_obj;
@@ -839,10 +854,9 @@ static int wc_check(struct drm_i915_gem_object *obj)
 
 static bool can_mmap(struct drm_i915_gem_object *obj, enum i915_mmap_type type)
 {
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
 
-   if (HAS_LMEM(i915))
+   if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
return false;
-- 
2.31.1

Re: [Intel-gfx] [PATCH v8 7/7] drm: remove drm_file.master_lookup_lock

[Daniel Vetter]

On Tue, Aug 31, 2021 at 02:02:39PM +0800, Desmond Cheong Zhi Xi wrote:
> On 26/8/21 9:21 pm, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 10:01:22AM +0800, Desmond Cheong Zhi Xi wrote:
> > > Previously, master_lookup_lock was introduced in
> > > commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
> > > spinlock") to serialize accesses to drm_file.master. This then allowed
> > > us to write drm_file_get_master in commit 56f0729a510f ("drm: protect
> > > drm_master pointers in drm_lease.c").
> > > 
> > > The rationale behind introducing a new spinlock at the time was that
> > > the other lock that could have been used (drm_device.master_mutex) was
> > > the outermost lock, so embedding calls to drm_file_get_master and
> > > drm_is_current_master in various functions easily caused us to invert
> > > the lock hierarchy.
> > > 
> > > Following the conversion of master_mutex into a rwsem, and its use to
> > > plug races with modesetting rights, we've untangled some lock
> > > hierarchies and removed the need for using drm_file_get_master and the
> > > unlocked version of drm_is_current_master in multiple places.
> > > 
> > > Hence, we can take this opportunity to clean up the locking design by
> > > replacing master_lookup_lock with drm_device.master_rwsem.
> > > 
> > > Signed-off-by: Desmond Cheong Zhi Xi 
> > > ---
> > >   drivers/gpu/drm/drm_auth.c | 19 +++
> > >   drivers/gpu/drm/drm_file.c |  1 -
> > >   drivers/gpu/drm/drm_internal.h |  1 +
> > >   drivers/gpu/drm/drm_ioctl.c|  4 ++--
> > >   drivers/gpu/drm/drm_lease.c| 18 --
> > >   include/drm/drm_file.h |  9 +
> > >   6 files changed, 19 insertions(+), 33 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > index f2b2f197052a..232416119407 100644
> > > --- a/drivers/gpu/drm/drm_auth.c
> > > +++ b/drivers/gpu/drm/drm_auth.c
> > > @@ -61,10 +61,9 @@
> > >* trusted clients.
> > >*/
> > > -static bool drm_is_current_master_locked(struct drm_file *fpriv)
> > > +bool drm_is_current_master_locked(struct drm_file *fpriv)
> > >   {
> > > - lockdep_assert_once(lockdep_is_held(&fpriv->master_lookup_lock) ||
> > > - lockdep_is_held(&fpriv->minor->dev->master_rwsem));
> > > + lockdep_assert_held_once(&fpriv->minor->dev->master_rwsem);
> > >   return fpriv->is_master && drm_lease_owner(fpriv->master) == 
> > > fpriv->minor->dev->master;
> > >   }
> > > @@ -83,9 +82,9 @@ bool drm_is_current_master(struct drm_file *fpriv)
> > >   {
> > >   bool ret;
> > > - spin_lock(&fpriv->master_lookup_lock);
> > > + down_read(&fpriv->minor->dev->master_rwsem);
> > 
> > Looking at the 3 patches and the need to have a locked version of pretty
> > much everything I'm wondering: Can't we just drop the spinlock completely,
> > and everywhere we've taking it thus far replace it with a
> > lockdep_assert_held_once?
> > 
> > The thing is, if there's any path left that doesn't hold the rwsem in at
> > least read mode we have a bug. And the right way to fix such a bug is to
> > grab the rwsem sufficiently high up in the callchain. That way I think we
> > should be able to avoid all these tedious changes to everything, including
> > touching i915 and vmwgfx drivers.
> > 
> > Or am I missing something big time?
> > -Daniel
> > 
> 
> Thanks for taking a look at all the patches and for the suggestions, Daniel.
> 
> Just my two cents. I think it makes sense to replace the lock with the
> lockdep assertion. This avoids the weirdness with the lock being taken both
> as an outer lock and sometimes as a deeply embedded inner lock.
> 
> But we'll probably have to fix some stuff because I don't think we always
> hold the rwsem in the places where the spinlock is grabbed (i.e. when
> drm_is_current_master or drm_file_get_master is called).

Yeah right I forgot about that again when coming up with this idea. All
the ioctl that read kms state need a read lock too. Maybe those ioctl
could just grab the master rwsem themselves? This should work now that
we've untangled the drm_global_mutex situation I think.

> I'll split the series as suggested so we can test things up to PATCH 4
> ("drm: avoid races with modesetting rights"). For the rest of the series to
> remove the spinlock, I'll take a closer look and probably send out a patch
> later this week.

Sounds great!
-Daniel


> 
> Best wishes,
> Desmond
> 
> > >   ret = drm_is_current_master_locked(fpriv);
> > > - spin_unlock(&fpriv->master_lookup_lock);
> > > + up_read(&fpriv->minor->dev->master_rwsem);
> > >   return ret;
> > >   }
> > > @@ -120,7 +119,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
> > >   DRM_DEBUG("%u\n", auth->magic);
> > >   down_write(&dev->master_rwsem);
> > > - if (unlikely(!drm_is_current_master(file_priv))) {
> > > + if (unlikely(!drm_is_current_master_locked(file_priv))) {
> > >   up_write(&dev->mast

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with drm/i915: Release i915_gem_context from a worker (rev4)

[Patchwork]

== Series Details ==

Series: series starting with drm/i915: Release i915_gem_context from a worker 
(rev4)
URL   : https://patchwork.freedesktop.org/series/93693/
State : failure

== Summary ==

Applying: drm/i915: Release i915_gem_context from a worker
Applying: drm/i915: Release ctx->syncobj on final put, not on ctx close
Applying: drm/i915: Keep gem ctx->vm alive until the final put
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gem/i915_gem_context.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_context.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/gem/i915_gem_context.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0003 drm/i915: Keep gem ctx->vm alive until the final put
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Daniel Vetter]

On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
> Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> > 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.
> >
> > 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.
> >
> > Put a FIXME comment in when this should be removable again.
> >
> > v2: Fix mock_context(), noticed by intel-gfx-ci.
> >
> > 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 
> >  drivers/gpu/drm/i915/gem/selftests/mock_context.c |  1 +
> >  3 files changed, 24 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_context_put() call out of a spinlock.
> > +*/
> > +   struct work_struct release_work;
> > +
> > /**
> >  * @rcu: rcu_head for deferred freeing.
> >  */
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c 
> > b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > index fee070df1c97..067d68a6fe4c 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > @@ -23,6 +23,7 @@ mock_context(struct drm_i915_private *i915,
> > kref_init(&ctx->ref);
> > INIT_LIST_HEAD(&ctx->link);
> > ctx->i915 = i915;
> > +   INIT_WORK(&ctx->release_work, i915_gem_context_release_work);
> >  
> > mutex_init(&ctx->mutex);
> >  
> 
> 
> Is the workqueue really needed? I'm not sure you could still race in
> drm_syncobj_free when refcount is zero, so in that case removing locking
> from _release would work as well as a workqueue.
> 
> Something like below would keep the drm_sync_obj_put hardirq safe.
> 
> I assume when freeing, the  cb list is supposed to be empty, so I added a 
> WARN_ON just to be sure, otherwise we should just tear down the list without 
> locking too.
> 
> This should be a better alternative for patch 1.

This isn't enough, because the problem

[Intel-gfx] [PATCH] drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups

[Daniel Vetter]

We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.

Note that this semantically reverts

commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson 
Date:   Fri Aug 30 19:03:25 2019 +0100

drm/i915: Use RCU for unlocked vm_idr lookup

except we have the conversion from idr to xarray in between.

v2: kref_get_unless_zero is no longer required (Maarten)

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/i915_drv.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be2392bbcecc..d89ff55d8fc8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1874,11 +1874,11 @@ i915_gem_vm_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
 {
struct i915_address_space *vm;
 
-   rcu_read_lock();
+   xa_lock(&file_priv->vm_xa);
vm = xa_load(&file_priv->vm_xa, id);
-   if (vm && !kref_get_unless_zero(&vm->ref))
-   vm = NULL;
-   rcu_read_unlock();
+   if (vm)
+   kref_get(&vm->ref);
+   xa_unlock(&file_priv->vm_xa);
 
return vm;
 }
-- 
2.33.0

Re: [Intel-gfx] [PATCH] drm/i915/gem: Fix the mman selftest

[Thomas Hellström]

On 8/31/21 11:45 AM, Maarten Lankhorst wrote:

Op 26-08-2021 om 09:24 schreef Thomas Hellström:

Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so
for that mmap type, use __i915_gem_object_create_user() instead of
i915_gem_object_create_internal(), as we really want to tests objects
mmap-able by user-space.

This also means that the out-of-space error happens at object creation
and returns -ENXIO rather than -ENOSPC, so fix the code up to expect
that on out-of-offset-space errors.

Finally only use I915_MMAP_TYPE_FIXED for LMEM and SMEM for now if
testing on LMEM-capable devices. For stolen LMEM, we still take the
same path as for integrated, as that haven't been moved over to TTM yet,
and user-space should not be able to create out of stolen LMEM anyway.

Fixes: 7961c5b60f23 ("drm/i915: Add TTM offset argument to mmap.")
Cc: Maarten Lankhorst 
Signed-off-by: Thomas Hellström 
---
  .../drm/i915/gem/selftests/i915_gem_mman.c| 26 +++
  1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index b20f5621f62b..68da25e66b69 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -581,6 +581,20 @@ static enum i915_mmap_type default_mapping(struct 
drm_i915_private *i915)
return I915_MMAP_TYPE_GTT;
  }
  
+static struct drm_i915_gem_object *

+create_sys_or_internal(struct drm_i915_private *i915,
+  unsigned long size)
+{
+   if (HAS_LMEM(i915)) {
+   struct intel_memory_region *sys_region =
+   i915->mm.regions[INTEL_REGION_SMEM];
+
+   return __i915_gem_object_create_user(i915, size, &sys_region, 
1);
+   }
+
+   return i915_gem_object_create_internal(i915, size);
+}
+
  static bool assert_mmap_offset(struct drm_i915_private *i915,
   unsigned long size,
   int expected)
@@ -589,7 +603,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
*i915,
u64 offset;
int ret;
  
-	obj = i915_gem_object_create_internal(i915, size);

+   obj = create_sys_or_internal(i915, size);
if (IS_ERR(obj))
return expected && expected == PTR_ERR(obj);
  
@@ -633,6 +647,7 @@ static int igt_mmap_offset_exhaustion(void *arg)

struct drm_mm_node *hole, *next;
int loop, err = 0;
u64 offset;
+   int enospc = HAS_LMEM(i915) ? -ENXIO : -ENOSPC;
  
  	/* Disable background reaper */

disable_retire_worker(i915);
@@ -683,14 +698,14 @@ static int igt_mmap_offset_exhaustion(void *arg)
}
  
  	/* Too large */

-   if (!assert_mmap_offset(i915, 2 * PAGE_SIZE, -ENOSPC)) {
+   if (!assert_mmap_offset(i915, 2 * PAGE_SIZE, enospc)) {
pr_err("Unexpectedly succeeded in inserting too large object into 
single page hole\n");
err = -EINVAL;
goto out;
}
  
  	/* Fill the hole, further allocation attempts should then fail */

-   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   obj = create_sys_or_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
pr_err("Unable to create object for reclaimed hole\n");
@@ -703,7 +718,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
goto err_obj;
}
  
-	if (!assert_mmap_offset(i915, PAGE_SIZE, -ENOSPC)) {

+   if (!assert_mmap_offset(i915, PAGE_SIZE, enospc)) {
pr_err("Unexpectedly succeeded in inserting object into no 
holes!\n");
err = -EINVAL;
goto err_obj;
@@ -842,7 +857,8 @@ static bool can_mmap(struct drm_i915_gem_object *obj, enum 
i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
  
-	if (HAS_LMEM(i915))

+   if (HAS_LMEM(i915) && (obj->mm.region->id == INTEL_REGION_SMEM ||
+  obj->mm.region->id == INTEL_REGION_LMEM))

Ooh just noticed, make the whole line "if (obj->ops->mmap_offset)" instead to 
match i915_gem_mman.c?


Ah, right. I'll fix that up.

/Thomas



Otherwise looks good.

Reviewed-by: Maarten Lankhorst 


return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
return false;

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

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

Regards,

Tvrtko



I also have some patches on top to remove i915_vma->active, which was 1 of the 
requirements for VM_BIND iirc.

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with drm/i915: Release i915_gem_context from a worker (rev3)

[Patchwork]

== Series Details ==

Series: series starting with drm/i915: Release i915_gem_context from a worker 
(rev3)
URL   : https://patchwork.freedesktop.org/series/93693/
State : failure

== Summary ==

Applying: drm/i915: Release i915_gem_context from a worker
Applying: drm/i915: Release ctx->syncobj on final put, not on ctx close
Applying: drm/i915: Keep gem ctx->vm alive until the final put
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gem/i915_gem_context.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_context.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/gem/i915_gem_context.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0003 drm/i915: Keep gem ctx->vm alive until the final put
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [PATCH v3 0/2] GPD Win Max display fixes

[Anisse Astier]

On Tue, Aug 31, 2021 at 11:33 AM Jani Nikula  wrote:
>
> On Tue, 17 Aug 2021, Anisse Astier  wrote:
> > This patch series is for making the GPD Win Max display usable with
> > Linux.
> >
> > The GPD Win Max is a small laptop, and its eDP panel does not send an
> > EDID over DPCD; the EDID is instead available in the intel opregion, in
> > mailbox #5 [1]
> >
> > The first patch is based on Jani's patch series [2] adding support for
> > the opregion, with changes. I've changed authorship, but I'd be glad to
> > revert it
>
> If you don't mind, please just add:
>
> Co-developed-by: Jani Nikula 

I don't mind at all, I think you should be first author for this
series, I just didn't feel like giving you the blame for the bugs
after this many modifications, without asking first. Will be in next
iteration.

Anisse


>
>
> Thanks,
> Jani.
>
> >
> > The second patch is just to fix the orientation of the panel.
> >
> > Changes since v1:
> >  - rebased on drm-tip
> >  - squashed patch 1 & 2
> >  - picked up Reviewed-by from Hans de Goede (thanks for the review)
> >
> > Changes since v2:
> >  - rebased on drm-tip
> >  - updated commit message
> >
> > When v2 was initially sent [3] Ville Syrjälä suggested that it might be
> > a good idea to use the ACPI _DDC method instead to get the EDID, to
> > cover a wider range of hardware. Unfortunately, it doesn't seem
> > available on GPD Win Max, so I think this work should be done
> > independently, and this patch series considered separately.
> >
> > [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454
> > [2]: 
> > https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
> > [3]: 
> > https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-ani...@astier.eu/
> >
> >
> > Anisse Astier (2):
> >   drm/i915/opregion: add support for mailbox #5 EDID
> >   drm: Add orientation quirk for GPD Win Max
> >
> >  .../gpu/drm/drm_panel_orientation_quirks.c|  6 ++
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +
> >  drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
> >  drivers/gpu/drm/i915/display/intel_opregion.h |  8 +++
> >  4 files changed, 85 insertions(+), 1 deletion(-)
>
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/gem: Fix the mman selftest

[Maarten Lankhorst]

Op 26-08-2021 om 09:24 schreef Thomas Hellström:
> Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so
> for that mmap type, use __i915_gem_object_create_user() instead of
> i915_gem_object_create_internal(), as we really want to tests objects
> mmap-able by user-space.
>
> This also means that the out-of-space error happens at object creation
> and returns -ENXIO rather than -ENOSPC, so fix the code up to expect
> that on out-of-offset-space errors.
>
> Finally only use I915_MMAP_TYPE_FIXED for LMEM and SMEM for now if
> testing on LMEM-capable devices. For stolen LMEM, we still take the
> same path as for integrated, as that haven't been moved over to TTM yet,
> and user-space should not be able to create out of stolen LMEM anyway.
>
> Fixes: 7961c5b60f23 ("drm/i915: Add TTM offset argument to mmap.")
> Cc: Maarten Lankhorst 
> Signed-off-by: Thomas Hellström 
> ---
>  .../drm/i915/gem/selftests/i915_gem_mman.c| 26 +++
>  1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index b20f5621f62b..68da25e66b69 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -581,6 +581,20 @@ static enum i915_mmap_type default_mapping(struct 
> drm_i915_private *i915)
>   return I915_MMAP_TYPE_GTT;
>  }
>  
> +static struct drm_i915_gem_object *
> +create_sys_or_internal(struct drm_i915_private *i915,
> +unsigned long size)
> +{
> + if (HAS_LMEM(i915)) {
> + struct intel_memory_region *sys_region =
> + i915->mm.regions[INTEL_REGION_SMEM];
> +
> + return __i915_gem_object_create_user(i915, size, &sys_region, 
> 1);
> + }
> +
> + return i915_gem_object_create_internal(i915, size);
> +}
> +
>  static bool assert_mmap_offset(struct drm_i915_private *i915,
>  unsigned long size,
>  int expected)
> @@ -589,7 +603,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
> *i915,
>   u64 offset;
>   int ret;
>  
> - obj = i915_gem_object_create_internal(i915, size);
> + obj = create_sys_or_internal(i915, size);
>   if (IS_ERR(obj))
>   return expected && expected == PTR_ERR(obj);
>  
> @@ -633,6 +647,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
>   struct drm_mm_node *hole, *next;
>   int loop, err = 0;
>   u64 offset;
> + int enospc = HAS_LMEM(i915) ? -ENXIO : -ENOSPC;
>  
>   /* Disable background reaper */
>   disable_retire_worker(i915);
> @@ -683,14 +698,14 @@ static int igt_mmap_offset_exhaustion(void *arg)
>   }
>  
>   /* Too large */
> - if (!assert_mmap_offset(i915, 2 * PAGE_SIZE, -ENOSPC)) {
> + if (!assert_mmap_offset(i915, 2 * PAGE_SIZE, enospc)) {
>   pr_err("Unexpectedly succeeded in inserting too large object 
> into single page hole\n");
>   err = -EINVAL;
>   goto out;
>   }
>  
>   /* Fill the hole, further allocation attempts should then fail */
> - obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + obj = create_sys_or_internal(i915, PAGE_SIZE);
>   if (IS_ERR(obj)) {
>   err = PTR_ERR(obj);
>   pr_err("Unable to create object for reclaimed hole\n");
> @@ -703,7 +718,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
>   goto err_obj;
>   }
>  
> - if (!assert_mmap_offset(i915, PAGE_SIZE, -ENOSPC)) {
> + if (!assert_mmap_offset(i915, PAGE_SIZE, enospc)) {
>   pr_err("Unexpectedly succeeded in inserting object into no 
> holes!\n");
>   err = -EINVAL;
>   goto err_obj;
> @@ -842,7 +857,8 @@ static bool can_mmap(struct drm_i915_gem_object *obj, 
> enum i915_mmap_type type)
>   struct drm_i915_private *i915 = to_i915(obj->base.dev);
>   bool no_map;
>  
> - if (HAS_LMEM(i915))
> + if (HAS_LMEM(i915) && (obj->mm.region->id == INTEL_REGION_SMEM ||
> +obj->mm.region->id == INTEL_REGION_LMEM))

Ooh just noticed, make the whole line "if (obj->ops->mmap_offset)" instead to 
match i915_gem_mman.c?

Otherwise looks good.

Reviewed-by: Maarten Lankhorst 

>   return type == I915_MMAP_TYPE_FIXED;
>   else if (type == I915_MMAP_TYPE_FIXED)
>   return false;

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

[Maarten Lankhorst]

Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> 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.
>
> 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.
>
> Put a FIXME comment in when this should be removable again.
>
> v2: Fix mock_context(), noticed by intel-gfx-ci.
>
> 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 
>  drivers/gpu/drm/i915/gem/selftests/mock_context.c |  1 +
>  3 files changed, 24 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_context_put() call out of a spinlock.
> +  */
> + struct work_struct release_work;
> +
>   /**
>* @rcu: rcu_head for deferred freeing.
>*/
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> index fee070df1c97..067d68a6fe4c 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -23,6 +23,7 @@ mock_context(struct drm_i915_private *i915,
>   kref_init(&ctx->ref);
>   INIT_LIST_HEAD(&ctx->link);
>   ctx->i915 = i915;
> + INIT_WORK(&ctx->release_work, i915_gem_context_release_work);
>  
>   mutex_init(&ctx->mutex);
>  


Is the workqueue really needed? I'm not sure you could still race in 
drm_syncobj_free when refcount is zero, so in that case removing locking from 
_release would work as well as a workqueue.

Something like below would keep the drm_sync_obj_put hardirq safe.

I assume when freeing, the  cb list is supposed to be empty, so I added a 
WARN_ON just to be sure, otherwise we should just tear down the list without 
locking too.

This should be a better alternative for patch 1.
8<---
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index c9a9d74f338c..9d561decd97e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -462,7 +462,13 @@ void drm_syncobj_free(struct kref *kref)
struct 

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

[Maarten Lankhorst]

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.

I also have some patches on top to remove i915_vma->active, which was 1 of the 
requirements for VM_BIND iirc.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: update locking for modesetting (rev7)

[Patchwork]

== Series Details ==

Series: drm: update locking for modesetting (rev7)
URL   : https://patchwork.freedesktop.org/series/93864/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10538_full -> Patchwork_20925_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#3070])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-iclb3/igt@gem_...@in-flight-contexts-immediate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-iclb1/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  NOTRUN -> [DMESG-WARN][5] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-kbl3/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

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

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  NOTRUN -> [FAIL][9] ([i915#2842] / [i915#3468])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-kbl2/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#118] / 
[i915#95])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-glk9/igt@gem_exec_whis...@basic-contexts-priority-all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html

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

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2428])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#307])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/shard-iclb5/igt@gem_mmap_...@cpuset-medium-copy.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-iclb5/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_pread@exhaustion:
- shard-snb:  NOTRUN -> [WARN][23] ([i915#2658])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/shard-snb7/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][24] ([i915#2658])
   [24]: 
https://intel-gfx-ci.0

Re: [Intel-gfx] [PATCH v3 0/2] GPD Win Max display fixes

[Jani Nikula]

On Tue, 17 Aug 2021, Anisse Astier  wrote:
> This patch series is for making the GPD Win Max display usable with
> Linux.
>
> The GPD Win Max is a small laptop, and its eDP panel does not send an
> EDID over DPCD; the EDID is instead available in the intel opregion, in
> mailbox #5 [1]
>
> The first patch is based on Jani's patch series [2] adding support for
> the opregion, with changes. I've changed authorship, but I'd be glad to
> revert it

If you don't mind, please just add:

Co-developed-by: Jani Nikula 


Thanks,
Jani.

>
> The second patch is just to fix the orientation of the panel.
>
> Changes since v1:
>  - rebased on drm-tip
>  - squashed patch 1 & 2
>  - picked up Reviewed-by from Hans de Goede (thanks for the review)
>
> Changes since v2:
>  - rebased on drm-tip
>  - updated commit message
>
> When v2 was initially sent [3] Ville Syrjälä suggested that it might be
> a good idea to use the ACPI _DDC method instead to get the EDID, to
> cover a wider range of hardware. Unfortunately, it doesn't seem
> available on GPD Win Max, so I think this work should be done
> independently, and this patch series considered separately.
>
> [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454
> [2]: 
> https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
> [3]: 
> https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-ani...@astier.eu/
>
>
> Anisse Astier (2):
>   drm/i915/opregion: add support for mailbox #5 EDID
>   drm: Add orientation quirk for GPD Win Max
>
>  .../gpu/drm/drm_panel_orientation_quirks.c|  6 ++
>  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +
>  drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
>  drivers/gpu/drm/i915/display/intel_opregion.h |  8 +++
>  4 files changed, 85 insertions(+), 1 deletion(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/opregion: add support for mailbox #5 EDID

[Jani Nikula]

On Tue, 17 Aug 2021, Anisse Astier  wrote:
> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> used for the embedded display. Add support for using it via by adding
> the EDID to the list of available modes on the connector, and use it for
> eDP when available.
>
> If a panel's EDID is broken, there may be an override EDID set in the
> ACPI OpRegion mailbox #5. Use it if available.
>
> Fixes the GPD Win Max laptop display, which seems to only use this
> mechanism to provide a proper EDID for its eDP screen. It would have
> been better to provide the EDID through the ACPI _DDC method instead, to
> have a more generic solution, but it seems the designers of this system
> did not consider it, and shipped the firmware without it.

The question is whether the opregion EDID should be used for override or
fallback. The patch at hand is kind of neither, it just unconditionally
adds the modes from the opregion EDID to the connector. For your
display, they apparently end up also being the only mode(s), with one of
them being used as the fixed mode. (Otherwise the orientation quirk
wouldn't work.)

What does drm_get_edid() return for you? Maybe we should do something
like this instead:
 
mutex_lock(&dev->mode_config.mutex);
edid = drm_get_edid(connector, &intel_dp->aux.ddc);
+   if (!edid)
+   edid = intel_opregion_get_edid(intel_connector);
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
drm_connector_update_edid_property(connector, edid);

This way we'll actually use all the other bits in the EDID, not just the
modes. And if it needs to become override rather than fallback, the
solution is:

mutex_lock(&dev->mode_config.mutex);
-   edid = drm_get_edid(connector, &intel_dp->aux.ddc);
+   edid = intel_opregion_get_edid(intel_connector);
+   if (!edid)
+   edid = drm_get_edid(connector, &intel_dp->aux.ddc);
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
drm_connector_update_edid_property(connector, edid);

In any case, I think it's just plain wrong to use both the display and
opregion EDIDs at the same time. It's probably all around safer to start
with fallback.

Please find some further comments inline.

> Based on original patch series by: Jani Nikula 
> https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
>
> Changes since Jani Nikula's series:
>  - EDID is copied and validated with drm_edid_is_valid
>  - Mode is now added via drm_add_edid_modes instead of using override
>mechanism
>  - squashed the two patches
>
> Cc: Jani Nikula 
> Cc: Uma Shankar 
> Cc: Ville Syrjälä 
> Signed-off-by: Anisse Astier 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +
>  drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
>  drivers/gpu/drm/i915/display/intel_opregion.h |  8 +++
>  3 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 75d4ebc66941..f9254c0df1a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5183,6 +5183,9 @@ static bool intel_edp_init_connector(struct intel_dp 
> *intel_dp,
>   goto out_vdd_off;
>   }
>  
> + /* Set up override EDID, if any, from ACPI OpRegion */
> + intel_opregion_edid_probe(intel_connector);
> +
>   mutex_lock(&dev->mode_config.mutex);
>   edid = drm_get_edid(connector, &intel_dp->aux.ddc);
>   if (edid) {
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 3855fba70980..b1b87ed758ba 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -196,6 +196,8 @@ struct opregion_asle_ext {
>  #define ASLE_IUER_WINDOWS_BTN(1 << 1)
>  #define ASLE_IUER_POWER_BTN  (1 << 0)
>  
> +#define ASLE_PHED_EDID_VALID_MASK0x3
> +
>  /* Software System Control Interrupt (SWSCI) */
>  #define SWSCI_SCIC_INDICATOR (1 << 0)
>  #define SWSCI_SCIC_MAIN_FUNCTION_SHIFT   1
> @@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   opregion->asle->ardy = ASLE_ARDY_NOT_READY;
>   }
>  
> - if (mboxes & MBOX_ASLE_EXT)
> + if (mboxes & MBOX_ASLE_EXT) {
>   drm_dbg(&dev_priv->drm, "ASLE extension supported\n");
> + opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
> + }
>  
>   if (intel_load_vbt_firmware(dev_priv) == 0)
>   goto out;
> @@ -1037,6 +1041,68 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
>   return ret - 1;
>  }
>  
> +/**
> + * intel_opregion_edid_probe - Add EDID from ACPI OpRegion mailbox #5
> + * @intel_connector: eDP connector
> + *
> + * Th

Re: [Intel-gfx] [PATCH 10/11] drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups

[Maarten Lankhorst]

Op 13-08-2021 om 22:30 schreef Daniel Vetter:
> We don't need the absolute speed of rcu for this. And
> i915_address_space in general dont need rcu protection anywhere else,
> after we've made gem contexts and engines a lot more immutable.
>
> Note that this semantically reverts
>
> commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
> Author: Chris Wilson 
> Date:   Fri Aug 30 19:03:25 2019 +0100
>
> drm/i915: Use RCU for unlocked vm_idr lookup
>
> except we have the conversion from idr to xarray in between.
>
> 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/i915_drv.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 005b1cec7007..e37fac8fac0c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1881,11 +1881,11 @@ i915_gem_vm_lookup(struct drm_i915_file_private 
> *file_priv, u32 id)
>  {
>   struct i915_address_space *vm;
>  
> - rcu_read_lock();
> + xa_lock(&file_priv->vm_xa);
>   vm = xa_load(&file_priv->vm_xa, id);
>   if (vm && !kref_get_unless_zero(&vm->ref))
>   vm = NULL;
I think this could be a plain i915_vm_get now, kref_get_unless_zero is not 
guarded by RCU any more.
> - rcu_read_unlock();
> + xa_unlock(&file_priv->vm_xa);
>  
>   return vm;
>  }

Apart from that, all looks good.

With this fix, for patch 2-11:

Reviewed-by: Maarten Lankhorst 

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

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

Regards,

Tvrtko


Signed-off-by: Maarten Lankhorst 
---
  drivers/gpu/drm/i915/gt/intel_context.c   |  2 +-
  .../gpu/drm/i915/gt/intel_ring_submission.c   |  2 +-
  drivers/gpu/drm/i915/i915_vma.c   | 48 ---
  drivers/gpu/drm/i915/i915_vma.h   |  3 --
  4 files changed, 22 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 745e84c72c90..d3ad16df3ca2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -219,7 +219,7 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
 */
  
  	err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj, ww);

-   if (!err && ce->ring->vma->obj)
+   if (!err)
err = i915_gem_object_lock(ce->ring->vma->obj, ww);
if (!err && ce->state)
err = i915_gem_object_lock(ce->state->obj, ww);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 3c65efcb7bed..cc31ccc13bfb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1354,7 +1354,7 @@ int intel_ring_submission_setup(struct intel_engine_cs 
*engine)
err = i915_gem_object_lock(timeline->hwsp_ggtt->obj, &ww);
if (!err && gen7_wa_vma)
err = i915_gem_object_lock(gen7_wa_vma->obj, &ww);
-   if (!err && engine->legacy.ring->vma->obj)
+   if (!err)
err = i915_gem_object_lock(engine->legacy.ring->vma->obj, &ww);
if (!err)
err = intel_timeline_pin(timeline, &ww);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index f9ac33e0bac9..ad5d52b33eb6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -40,12 +40,12 @@
  
  static struct kmem_cache *slab_vmas;
  
-struct i915_vma *i915_vma_alloc(void)

+static struct i915_vma *i915_vma_alloc(void)
  {
return kmem_cache_zalloc(slab_vmas, GFP_KERNEL);
  }
  
-void i915_vma_free(struct i915_vma *vma)

+static void i915_vma_free(struct i915_vma *vma)
  {
return kmem_cache_free(slab_vmas, vma);
  }
@@ -426,10 +426,8 @@ int i915_vma_bind(struct i915_vma *vma,
  
  		work->base.dma.error = 0; /* enable the queue_work() */
  
-		if (vma->obj) {

-   __i915_gem_object_pin_pages(vma->obj);
-   work->pinned = i915_gem_object_get(vma->obj);
-   }
+   __i915_gem_object_pin_pages(vma->obj);
+   work->pinned = i915_gem_object_get(vma->obj);
} else {
vma->ops->bind_vma(vma->vm, NULL, vma, cache_level, bind_flags);
}
@@ -670,7 +668,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
}
  
  	color = 0;

-   if (vma->obj && i915_vm_has_cache_coloring(vma->vm))
+   if (i915_vm_has_cache_coloring(vma->vm))
color = vma->obj->cache_level;
  
  	if (flags & PIN_OFFSET_FIXED) {

@@ -795,17 +793,14 @@ static bool try_qad_pin(struct i915_vma *vma, unsigned 
int flags)
  static int vma_get_pages(struct i915_vma *vma)
  {
int err = 0;
-   bool pinned_pages = false;
+   bool pinned_pages = true;
  
  	if (atomic_add_unless(&vma->pages_count, 1, 0))

return 0;
  
-	if (vma->obj) {

-   err = i915_gem_object_pin_pages(vma->obj);
-   if (err)
-   return err;
-   pinned_pages = true;
-   }
+   err = i915_gem_object_pin_pages(vma->obj);
+   if (err)
+   return err;
  
  	/* Allocations ahoy! */

if (mutex_lock_interruptible(&vma->pages_mutex)) {
@@ -838,8 +833,8 @@ static void __vma_put_pages(struct i915_vma *vma, unsigned 
int count)
if (atomic_sub_return(count, &vma->pages_count) == 0) {
vma->ops->clear_pages(vma);
GEM_BUG_ON(vma->pages);
-   if (vma->obj)
-   i915_gem_object_unpin_pages(vma->obj);
+
+   i915_gem_object_unpin_pages(vma->obj);
}
mutex_unlock(&vma->pages_mutex);
  }
@@ -875,7 +870,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
int err;
  
  #ifdef CONFIG_PROVE_LOCKING

-   if (debug_locks && !WARN_ON(!ww) && vma->resv)
+   if (debug_locks && !WARN_ON(!ww))
assert_vma_held(vma);
  #endif
  
@@ -983,7 +978,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
  
  	GEM_BUG_ON(!vma->pages);

err = i915_vma_bind(vma,
-   vma->obj ? vma->obj->cache_level : 0,
+   vma->obj->cache_level,
 

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

[Tvrtko Ursulin]

On 30/08/2021 09:26, Daniel Vetter wrote:

On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:


On 27/08/2021 15:39, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.

Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between the two GPUs, which
results in deadlocks because semaphore target location in HWSP is neither
shared between the two, nor mapped in both GGTT spaces.

To fix it the patch adds an additional check to a couple of relevant code
paths in order to prevent using semaphores for inter-engine
synchronisation between different driver instances.

Patch also moves singly used i915_gem_object_last_write_engine to be
private in its only calling unit (debugfs), while modifying it to only
show activity belonging to the respective driver instance.

What remains in this problem space is the question of the GEM busy ioctl.
We have a somewhat ambigous comment there saying only status of native
fences will be reported, which could be interpreted as either i915, or
native to the drm fd. For now I have decided to leave that as is, meaning
any i915 instance activity continues to be reported.

v2:
   * Avoid adding rq->i915. (Chris)

Signed-off-by: Tvrtko Ursulin 


Can't we just delete semaphore code and done?
- GuC won't have it
- media team benchmarked on top of softpin media driver, found no
   difference


You have S-curve for saturated workloads or something else? How thorough 
and which media team I guess.


From memory it was a nice win for some benchmarks (non-saturated ones), 
but as I have told you previously, we haven't been putting numbers in 
commit messages since it wasn't allowed. I may be able to dig out some 
more details if I went trawling through GEM channel IRC logs, although 
probably not the actual numbers since those were usually on pastebin. Or 
you go an talk with Chris since he probably remembers more details. Or 
you just decide you don't care and remove it. I wouldn't do that without 
putting the complete story in writing, but it's your call after all.


Anyway, without the debugfs churn it is more or less two line patch to 
fix igfx + dgfx hybrid setup. So while mulling it over this could go in. 
I'd just refine it to use a GGTT check instead of GT. And unless DG1 
ends up being GuC only.



- pre-gen8 semaphore code was also silently ditched and no one cared

Plus removing semaphore code would greatly simplify conversion to
drm/sched.


---
   drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 --
   drivers/gpu/drm/i915/i915_debugfs.c| 39 --
   drivers/gpu/drm/i915/i915_request.c| 12 ++-
   3 files changed, 47 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 48112b9d76df..3043fcbd31bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -503,23 +503,6 @@ i915_gem_object_finish_access(struct drm_i915_gem_object 
*obj)
i915_gem_object_unpin_pages(obj);
   }
-static inline struct intel_engine_cs *
-i915_gem_object_last_write_engine(struct drm_i915_gem_object *obj)
-{
-   struct intel_engine_cs *engine = NULL;
-   struct dma_fence *fence;
-
-   rcu_read_lock();
-   fence = dma_resv_get_excl_unlocked(obj->base.resv);
-   rcu_read_unlock();
-
-   if (fence && dma_fence_is_i915(fence) && !dma_fence_is_signaled(fence))
-   engine = to_request(fence)->engine;
-   dma_fence_put(fence);
-
-   return engine;
-}
-
   void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
 unsigned int cache_level);
   void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 04351a851586..55fd6191eb32 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -135,13 +135,46 @@ static const char *stringify_vma_type(const struct 
i915_vma *vma)
return "ppgtt";
   }
+static char *
+last_write_engine(struct drm_i915_private *i915,
+ struct drm_i915_gem_object *obj)
+{
+   struct intel_engine_cs *engine;
+   struct dma_fence *fence;
+   char *res = NULL;
+
+   rcu_read_lock();
+   fence = dma_resv_get_excl_unlocked(obj->base.resv);
+   rcu_read_unlock();
+
+   if (!fence || dma_fence_is_signaled(fence))
+   goto out;
+
+   if (!dma_fence_is_i915(fence)) {
+   res = "";
+   goto out;
+   }
+
+   engine = to_request(fence)->engine;
+   if (engine->gt->i915 != i915) {
+   res = "";
+   goto out;
+   }
+
+   res = engine->n

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: update locking for modesetting (rev7)

[Patchwork]

== Series Details ==

Series: drm: update locking for modesetting (rev7)
URL   : https://patchwork.freedesktop.org/series/93864/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10538 -> Patchwork_20925


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


  Here are the changes found in Patchwork_20925 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_20925/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  
 Possible fixes 

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

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][4] ([i915#1888]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10538/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20925/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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


Participating hosts (44 -> 36)
--

  Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10538 -> Patchwork_20925

  CI-20190529: 20190529
  CI_DRM_10538: 031f5dcf3ec226bcd0d5f700347780d51cddd2eb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6191: e9292b533691784f46eeb9bae522ca7a8710c920 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20925: aa1dc5ecd4c1fe7724951e573e95f8d5c76c9719 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

aa1dc5ecd4c1 drm: avoid races with modesetting rights
561f815dc062 drm: lock drm_global_mutex earlier in the ioctl handler
488e5f613522 drm: convert drm_device.master_mutex into a rwsem
3fccaf2012dc drm: fix null ptr dereference in drm_master_release

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

[Jani Nikula]

On Mon, 30 Aug 2021, Ville Syrjälä  wrote:
> On Mon, Aug 30, 2021 at 01:29:01PM +0300, Jani Nikula wrote:
>> The VESA Organization Vendor-Specific Data Block, defined in VESA
>> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
>> stream count and segment pixel overlap.
>> 
>> DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
>> describing how DisplayID sections may be embedded in EDID extension
>> blocks. DisplayID v2.0 does not have such a section, perhaps implying
>> that DisplayID v2.0 data should not be included in EDID extensions, but
>> rather in a "pure" DisplayID structure at its own DDC address pair
>> A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3.
>> 
>> However, in practice, displays out in the field have embedded DisplayID
>> v2.0 data blocks in EDID extensions, including, in particular, some eDP
>> MSO displays, where a pure DisplayID structure is not available at all.
>> 
>> Parse the MSO data from the DisplayID data block. Do it as part of
>> drm_add_display_info(), extending it to parse also DisplayID data to
>> avoid requiring extra calls to update the information.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_edid.c  | 63 +
>>  include/drm/drm_connector.h | 12 +++
>>  include/drm/drm_displayid.h | 11 +++
>>  3 files changed, 86 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 6325877c5fd6..7e8083068f3f 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -28,6 +28,7 @@
>>   * DEALINGS IN THE SOFTWARE.
>>   */
>>  
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -5148,6 +5149,62 @@ void drm_get_monitor_range(struct drm_connector 
>> *connector,
>>info->monitor_range.max_vfreq);
>>  }
>>  
>> +static void drm_parse_vesa_mso_data(struct drm_connector *connector,
>> +const struct displayid_block *block)
>> +{
>> +struct displayid_vesa_vendor_specific_block *vesa =
>> +(struct displayid_vesa_vendor_specific_block *)block;
>> +struct drm_display_info *info = &connector->display_info;
>> +
>> +if (sizeof(*vesa) != sizeof(*block) + block->num_bytes) {
>> +drm_dbg_kms(connector->dev, "Unexpected VESA vendor block 
>> size\n");
>> +return;
>> +}
>> +
>> +switch (FIELD_GET(DISPLAYID_VESA_MSO_MODE, vesa->mso)) {
>> +default:
>> +drm_dbg_kms(connector->dev, "Reserved MSO mode value\n");
>> +fallthrough;
>> +case 0:
>> +info->mso_stream_count = 0;
>> +break;
>> +case 1:
>> +info->mso_stream_count = 2; /* 2 or 4 links */
>> +break;
>> +case 2:
>> +info->mso_stream_count = 4; /* 4 links */
>> +break;
>> +}
>> +
>> +if (!info->mso_stream_count) {
>> +info->mso_pixel_overlap = 0;
>> +return;
>> +}
>> +
>> +info->mso_pixel_overlap = FIELD_GET(DISPLAYID_VESA_MSO_OVERLAP, 
>> vesa->mso);
>> +if (info->mso_pixel_overlap > 8) {
>> +drm_dbg_kms(connector->dev, "Reserved MSO pixel overlap value 
>> %u\n",
>> +info->mso_pixel_overlap);
>> +info->mso_pixel_overlap = 8;
>> +}
>> +
>> +drm_dbg_kms(connector->dev, "MSO stream count %u, pixel overlap %u\n",
>> +info->mso_stream_count, info->mso_pixel_overlap);
>> +}
>> +
>> +static void drm_update_mso(struct drm_connector *connector, const struct 
>> edid *edid)
>> +{
>> +const struct displayid_block *block;
>> +struct displayid_iter iter;
>> +
>> +displayid_iter_edid_begin(edid, &iter);
>> +displayid_iter_for_each(block, &iter) {
>> +if (block->tag == DATA_BLOCK_2_VENDOR_SPECIFIC)
>
> Don't we need to check the OUI to make sure the block is the right
> type? I don't have the v2 spec at hand atm, but I presume a vendor
> specific block could contain all kinds of different things?

You're right.

BR,
Jani.

>
>> +drm_parse_vesa_mso_data(connector, block);
>> +}
>> +displayid_iter_end(&iter);
>> +}
>> +
>>  /* A connector has no EDID information, so we've got no EDID to compute 
>> quirks from. Reset
>>   * all of the values which would have been set from EDID
>>   */
>> @@ -5171,6 +5228,9 @@ drm_reset_display_info(struct drm_connector *connector)
>>  
>>  info->non_desktop = 0;
>>  memset(&info->monitor_range, 0, sizeof(info->monitor_range));
>> +
>> +info->mso_stream_count = 0;
>> +info->mso_pixel_overlap = 0;
>>  }
>>  
>>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
>> *edid)
>> @@ -5249,6 +5309,9 @@ u32 drm_add_display_info(struct drm_connector 
>> *connector, const struct edid *edi
>>  info->color_formats |= DRM_COLOR_FORMAT_YCRCB444;
>>  if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB422)
>>  info->co

[Intel-gfx] [PATCH v10 4/4] drm: avoid races with modesetting rights

[Desmond Cheong Zhi Xi]

In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.

However, there are other places where modesetting rights can race. A
time-of-check-to-time-of-use error can occur if an ioctl that changes
the modeset has its rights revoked after it validates its permissions,
but before it completes.

There are four places where modesetting permissions can change:

- DROP_MASTER ioctl removes rights for a master and its leases

- REVOKE_LEASE ioctl revokes rights for a specific lease

- SET_MASTER ioctl sets the device master if the master role hasn't
been acquired yet

- drm_open which can create a new master for a device if one does not
currently exist

These races can be avoided using drm_device.master_rwsem: users that
perform modesetting should hold a read lock on the new
drm_device.master_rwsem, and users that change these permissions
should hold a write lock.

To avoid deadlocks with master_rwsem, for ioctls that need to check
for modesetting permissions, but also need to hold a write lock on
master_rwsem to protect some other attribute (or recurses to some
function that holds a write lock, like drm_mode_create_lease_ioctl
which eventually calls drm_master_open), we remove the DRM_MASTER flag
and push the master_rwsem lock and permissions check into the ioctl.

Reported-by: Daniel Vetter 
Signed-off-by: Desmond Cheong Zhi Xi 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_auth.c  |  4 
 drivers/gpu/drm/drm_ioctl.c | 20 +++-
 drivers/gpu/drm/drm_lease.c | 35 ---
 include/drm/drm_device.h|  6 ++
 4 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 73ade0513ccb..65065f7e1499 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -120,6 +120,10 @@ int drm_authmagic(struct drm_device *dev, void *data,
DRM_DEBUG("%u\n", auth->magic);
 
down_write(&dev->master_rwsem);
+   if (unlikely(!drm_is_current_master(file_priv))) {
+   up_write(&dev->master_rwsem);
+   return -EACCES;
+   }
file = idr_find(&file_priv->master->magic_map, auth->magic);
if (file) {
file->authenticated = 1;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index fe9c4c0264a9..f6a8aa6c53b3 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -386,6 +386,10 @@ static int drm_setversion(struct drm_device *dev, void 
*data, struct drm_file *f
int if_version, retcode = 0;
 
down_write(&dev->master_rwsem);
+   if (unlikely(!drm_is_current_master(file_priv))) {
+   retcode = -EACCES;
+   goto unlock;
+   }
if (sv->drm_di_major != -1) {
if (sv->drm_di_major != DRM_IF_MAJOR ||
sv->drm_di_minor < 0 || sv->drm_di_minor > DRM_IF_MINOR) {
@@ -420,8 +424,9 @@ static int drm_setversion(struct drm_device *dev, void 
*data, struct drm_file *f
sv->drm_di_minor = DRM_IF_MINOR;
sv->drm_dd_major = dev->driver->major;
sv->drm_dd_minor = dev->driver->minor;
-   up_write(&dev->master_rwsem);
 
+unlock:
+   up_write(&dev->master_rwsem);
return retcode;
 }
 
@@ -574,12 +579,12 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SET_CLIENT_CAP, drm_setclientcap, 0),
-   DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
+   DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, 0),
 
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_BLOCK, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_UNBLOCK, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
-   DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic, DRM_MASTER),
+   DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic, 0),
 
DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_ADD_MAP, drm_legacy_addmap_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_RM_MAP, drm_legacy_rmmap_ioctl, 
DRM_AUTH),
@@ -706,10 +711,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
0),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, 0),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl, 
DRM_MASTER),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl, 
0),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessee

[Intel-gfx] [PATCH v10 3/4] drm: lock drm_global_mutex earlier in the ioctl handler

[Desmond Cheong Zhi Xi]

In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.

To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl permissions.

Signed-off-by: Desmond Cheong Zhi Xi 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 9fc00e36c5d6..fe9c4c0264a9 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -767,24 +767,27 @@ long drm_ioctl_kernel(struct file *file, drm_ioctl_t 
*func, void *kdata,
 {
struct drm_file *file_priv = file->private_data;
struct drm_device *dev = file_priv->minor->dev;
+   bool locked_ioctl;
int retcode;
 
if (drm_dev_is_unplugged(dev))
return -ENODEV;
 
+   /* Enforce sane locking for modern driver ioctls. */
+   locked_ioctl = (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)) &&
+   !(flags & DRM_UNLOCKED));
+   if (locked_ioctl)
+   mutex_lock(&drm_global_mutex);
+
retcode = drm_ioctl_permit(flags, file_priv);
if (unlikely(retcode))
-   return retcode;
+   goto out;
 
-   /* Enforce sane locking for modern driver ioctls. */
-   if (likely(!drm_core_check_feature(dev, DRIVER_LEGACY)) ||
-   (flags & DRM_UNLOCKED))
-   retcode = func(dev, kdata, file_priv);
-   else {
-   mutex_lock(&drm_global_mutex);
-   retcode = func(dev, kdata, file_priv);
+   retcode = func(dev, kdata, file_priv);
+
+out:
+   if (locked_ioctl)
mutex_unlock(&drm_global_mutex);
-   }
return retcode;
 }
 EXPORT_SYMBOL(drm_ioctl_kernel);
-- 
2.25.1

[Intel-gfx] [PATCH v10 2/4] drm: convert drm_device.master_mutex into a rwsem

[Desmond Cheong Zhi Xi]

drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map

There is a clear separation between functions that read or change
these attributes. Hence, convert master_mutex into a rwsem to enable
concurrent readers.

Signed-off-by: Desmond Cheong Zhi Xi 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_auth.c| 35 ++-
 drivers/gpu/drm/drm_debugfs.c |  4 ++--
 drivers/gpu/drm/drm_drv.c |  3 +--
 drivers/gpu/drm/drm_ioctl.c   | 10 +-
 include/drm/drm_auth.h|  6 +++---
 include/drm/drm_device.h  | 10 ++
 include/drm/drm_file.h| 12 ++--
 7 files changed, 41 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 60a6b21474b1..73ade0513ccb 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -64,7 +64,7 @@
 static bool drm_is_current_master_locked(struct drm_file *fpriv)
 {
lockdep_assert_once(lockdep_is_held(&fpriv->master_lookup_lock) ||
-   lockdep_is_held(&fpriv->minor->dev->master_mutex));
+   lockdep_is_held(&fpriv->minor->dev->master_rwsem));
 
return fpriv->is_master && drm_lease_owner(fpriv->master) == 
fpriv->minor->dev->master;
 }
@@ -96,7 +96,7 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
struct drm_auth *auth = data;
int ret = 0;
 
-   mutex_lock(&dev->master_mutex);
+   down_write(&dev->master_rwsem);
if (!file_priv->magic) {
ret = idr_alloc(&file_priv->master->magic_map, file_priv,
1, 0, GFP_KERNEL);
@@ -104,7 +104,7 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
file_priv->magic = ret;
}
auth->magic = file_priv->magic;
-   mutex_unlock(&dev->master_mutex);
+   up_write(&dev->master_rwsem);
 
DRM_DEBUG("%u\n", auth->magic);
 
@@ -119,13 +119,13 @@ int drm_authmagic(struct drm_device *dev, void *data,
 
DRM_DEBUG("%u\n", auth->magic);
 
-   mutex_lock(&dev->master_mutex);
+   down_write(&dev->master_rwsem);
file = idr_find(&file_priv->master->magic_map, auth->magic);
if (file) {
file->authenticated = 1;
idr_replace(&file_priv->master->magic_map, NULL, auth->magic);
}
-   mutex_unlock(&dev->master_mutex);
+   up_write(&dev->master_rwsem);
 
return file ? 0 : -EINVAL;
 }
@@ -167,7 +167,7 @@ static int drm_new_set_master(struct drm_device *dev, 
struct drm_file *fpriv)
struct drm_master *old_master;
struct drm_master *new_master;
 
-   lockdep_assert_held_once(&dev->master_mutex);
+   lockdep_assert_held_once(&dev->master_rwsem);
 
WARN_ON(fpriv->is_master);
old_master = fpriv->master;
@@ -249,7 +249,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
 {
int ret;
 
-   mutex_lock(&dev->master_mutex);
+   down_write(&dev->master_rwsem);
 
ret = drm_master_check_perm(dev, file_priv);
if (ret)
@@ -281,7 +281,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
 
drm_set_master(dev, file_priv, false);
 out_unlock:
-   mutex_unlock(&dev->master_mutex);
+   up_write(&dev->master_rwsem);
return ret;
 }
 
@@ -298,7 +298,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
 {
int ret;
 
-   mutex_lock(&dev->master_mutex);
+   down_write(&dev->master_rwsem);
 
ret = drm_master_check_perm(dev, file_priv);
if (ret)
@@ -321,8 +321,9 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
}
 
drm_drop_master(dev, file_priv);
+
 out_unlock:
-   mutex_unlock(&dev->master_mutex);
+   up_write(&dev->master_rwsem);
return ret;
 }
 
@@ -334,7 +335,7 @@ int drm_master_open(struct drm_file *file_priv)
/* if there is no current master make this fd it, but do not create
 * any master object for render clients
 */
-   mutex_lock(&dev->master_mutex);
+   down_write(&dev->master_rwsem);
if (!dev->master) {
ret = drm_new_set_master(dev, file_priv);
} else {
@@ -342,7 +343,7 @@ int drm_master_open(struct drm_file *file_priv)
file_priv->master = drm_master_get(dev->master);
spin_unlock(&file_priv->master_lookup_lock);
}
-   mutex_unlock(&dev->master_mutex);
+   up_write(&dev->master_rwsem);
 
return ret;
 }
@@ -352,7 +353,7 @@ void drm_master_release(struct drm_file *file_priv)
struct drm_device *dev = file_priv->minor->dev;
struct drm_master *master;
 
-   mutex_lock(&dev->master_mutex);
+   down_write(&dev->master_rwsem);
  

[Intel-gfx] [PATCH v10 1/4] drm: fix null ptr dereference in drm_master_release

[Desmond Cheong Zhi Xi]

drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:

1. Error path in drm_open_helper
  drm_open():
drm_open_helper():
  drm_master_open():
drm_new_set_master(); <--- returns -ENOMEM,
   drm_file.master not set
  drm_file_free():
drm_master_release(); <--- NULL ptr dereference
   (file_priv->master->magic_map)

2. Error path in mock_drm_getfile
  mock_drm_getfile():
anon_inode_getfile(); <--- returns error, drm_file.master not set
drm_file_free():
  drm_master_release(); <--- NULL ptr dereference
 (file_priv->master->magic_map)

3. In drm_client_close, as drm_client_open doesn't set up a master

drm_file.master is set up in drm_open_helper through the call to
drm_master_open, so we mirror it with a call to drm_master_release in
drm_close_helper, and remove drm_master_release from drm_file_free to
avoid the null ptr dereference.

Fixes: 7eeaeb90a6a5 ("drm/file: Don't set master on in-kernel clients")
Signed-off-by: Desmond Cheong Zhi Xi 
Cc: sta...@vger.kernel.org
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_file.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ed25168619fc..90b62f360da1 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -282,9 +282,6 @@ void drm_file_free(struct drm_file *file)
 
drm_legacy_ctxbitmap_flush(dev, file);
 
-   if (drm_is_primary_client(file))
-   drm_master_release(file);
-
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
 
@@ -305,6 +302,9 @@ static void drm_close_helper(struct file *filp)
list_del(&file_priv->lhead);
mutex_unlock(&dev->filelist_mutex);
 
+   if (drm_is_primary_client(file_priv))
+   drm_master_release(file_priv);
+
drm_file_free(file_priv);
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v10 0/4] drm: update locking for modesetting

[Desmond Cheong Zhi Xi]

Sorry for the noise, rebasing on top of drm-misc-next. Please ignore the
v9 series.

Hi,

I updated the patch set with some suggestions by Daniel Vetter, and
dropped the patches after patch 4 so that we can stick the landing for
avoiding races with modesetting rights before dealing with the tricky
spinlock.

Overall, this series fixes races with modesetting rights, and converts
drm_device.master_mutex into master_rwsem.

- Patch 1: Fix a potential null ptr dereference in drm_master_release

- Patch 2: Convert master_mutex into rwsem (avoids creating a new lock)

- Patch 3: Update global mutex locking in the ioctl handler (avoids
deadlock when grabbing read lock on master_rwsem in drm_ioctl_kernel)

- Patch 4: Plug races with drm modesetting rights

v9 -> v10:
- Rebase on top of drm-misc-next, caught by Intel-gfx CI

v8 -> v9 (suggested by Daniel Vetter):
- Drop patches 5-7 to handle it in another series
- Add the appropriate Fixes: tag for the null ptr dereference fix
(patch 1)
- Create a locked_ioctl bool to clarify locking/unlocking patterns in
the ioctl handler (patch 3)
- Clarify the kernel doc for master_rwsem (patch 4)

v7 -> v8:
- Avoid calling drm_lease_held in drm_mode_setcrtc and
drm_wait_vblank_ioctl, caught by Intel-gfx CI

v6 -> v7:
- Export __drm_mode_object_find for loadable modules, caught by the
Intel-gfx CI

v5 -> v6:
- Fix recursive locking on master_rwsem, caught by the Intel-gfx CI

v4 -> v5:
- Avoid calling drm_file_get_master while holding on to the modeset
mutex, caught by the Intel-gfx CI

v3 -> v4 (suggested by Daniel Vetter):
- Drop a patch that added an unnecessary master_lookup_lock in
drm_master_release
- Drop a patch that addressed a non-existent race in
drm_is_current_master_locked
- Remove fixes for non-existent null ptr dereferences
- Protect drm_master.magic_map,unique{_len} with master_rwsem instead of
master_lookup_lock
- Drop the patch that moved master_lookup_lock into struct drm_device
- Drop a patch to export task_work_add
- Revert the check for the global mutex in the ioctl handler to use
drm_core_check_feature instead of drm_dev_needs_global_mutex
- Push down master_rwsem locking for selected ioctls to avoid lock
hierarchy inversions, and to allow us to hold write locks on
master_rwsem instead of flushing readers
- Remove master_lookup_lock by replacing it with master_rwsem

v2 -> v3:
- Unexport drm_master_flush, as suggested by Daniel Vetter.
- Merge master_mutex and master_rwsem, as suggested by Daniel Vetter.
- Export task_work_add, reported by kernel test robot.
- Make master_flush static, reported by kernel test robot.
- Move master_lookup_lock into struct drm_device.
- Add a missing lock on master_lookup_lock in drm_master_release.
- Fix a potential race in drm_is_current_master_locked.
- Fix potential null ptr dereferences in drm_{auth, ioctl}.
- Protect magic_map,unique{_len} with  master_lookup_lock.
- Convert master_mutex into a rwsem.
- Update global mutex locking in the ioctl handler.

v1 -> v2 (suggested by Daniel Vetter):
- Address an additional race when drm_open runs.
- Switch from SRCU to rwsem to synchronise readers and writers.
- Implement drm_master_flush with task_work so that flushes can be
queued to run before returning to userspace without creating a new
DRM_MASTER_FLUSH ioctl flag.

Best wishes,
Desmond

Desmond Cheong Zhi Xi (4):
  drm: fix null ptr dereference in drm_master_release
  drm: convert drm_device.master_mutex into a rwsem
  drm: lock drm_global_mutex earlier in the ioctl handler
  drm: avoid races with modesetting rights

 drivers/gpu/drm/drm_auth.c| 39 
 drivers/gpu/drm/drm_debugfs.c |  4 +--
 drivers/gpu/drm/drm_drv.c |  3 +--
 drivers/gpu/drm/drm_file.c|  6 ++---
 drivers/gpu/drm/drm_ioctl.c   | 49 ++-
 drivers/gpu/drm/drm_lease.c   | 35 +
 include/drm/drm_auth.h|  6 ++---
 include/drm/drm_device.h  | 16 +---
 include/drm/drm_file.h| 12 -
 9 files changed, 104 insertions(+), 66 deletions(-)

-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource (rev2)

[Patchwork]

== Series Details ==

Series: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource 
(rev2)
URL   : https://patchwork.freedesktop.org/series/94154/
State : failure

== Summary ==

Applying: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/ttm/ttm_bo_util.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/ttm/ttm_bo_util.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo_util.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct 
ttm_resource
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] [PATCH v2] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

[Thomas Hellström]

The code was making a copy of a struct ttm_resource. However,
recently the struct ttm_resources were allowed to be subclassed and
also were allowed to be malloced, hence the driver could end up assuming
the copy we handed it was subclassed and worse, the original could have
been freed at this point.

Fix this by using the original struct ttm_resource before it is
potentially freed in ttm_bo_move_sync_cleanup()

v2: Base on drm-misc-next-fixes rather than drm-tip.

Reported-by: Ben Skeggs 
Reported-by: Dave Airlie 
Cc: Christian König 
Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based 
iomem")
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 763fa6f4e07d..1c5ffe2935af 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -143,7 +143,6 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_resource *src_mem = bo->resource;
struct ttm_resource_manager *src_man =
ttm_manager_type(bdev, src_mem->mem_type);
-   struct ttm_resource src_copy = *src_mem;
union {
struct ttm_kmap_iter_tt tt;
struct ttm_kmap_iter_linear_io io;
@@ -173,11 +172,11 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
}
 
ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
-   src_copy = *src_mem;
-   ttm_bo_move_sync_cleanup(bo, dst_mem);
 
if (!src_iter->ops->maps_tt)
-   ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, &src_copy);
+   ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
+   ttm_bo_move_sync_cleanup(bo, dst_mem);
+
 out_src_iter:
if (!dst_iter->ops->maps_tt)
ttm_kmap_iter_linear_io_fini(&_dst_iter.io, bdev, dst_mem);
-- 
2.31.1