date:20221205

From: Pallavi Mishra 

It's a noop on all new platforms starting from MTL.
Refer: (e7737b67ab46) drm/i915/uapi: reject caching ioctls for discrete

v2:
1. block get caching ioctl
2. return ENODEV similar to DGFX
3. update the doc in i915_drm.h

Cc: Lucas De Marchi 
Cc: Matt Roper 
Cc: Joonas Lahtinen 

Signed-off-by: Pallavi Mishra 
Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 ++--
 include/uapi/drm/i915_drm.h| 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce680..cf817ee0aa01 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -291,7 +291,7 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
int err = 0;
 
-   if (IS_DGFX(to_i915(dev)))
+   if (IS_DGFX(to_i915(dev)) || GRAPHICS_VER_FULL(to_i915(dev)) >= 
IP_VER(12, 70))
return -ENODEV;
 
rcu_read_lock();
@@ -329,7 +329,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void 
*data,
enum i915_cache_level level;
int ret = 0;
 
-   if (IS_DGFX(i915))
+   if (IS_DGFX(i915) || GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
return -ENODEV;
 
switch (args->caching) {
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8df261c5ab9b..3467fd879427 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1626,6 +1626,9 @@ struct drm_i915_gem_busy {
  * - Everything else is always allocated and mapped as write-back, with the
  *   guarantee that everything is also coherent with the GPU.
  *
+ * Starting from MTL even on integrated platforms set/get caching is no longer
+ * supported and object will be mapped as write-combined only.
+ *
  * Note that this is likely to change in the future again, where we might need
  * more flexibility on future devices, so making this all explicit as part of a
  * new _i915_gem_create_ext extension is probable.
-- 
2.25.1

[Intel-gfx] [PATCH 3/4] drm/i915/mtl: Define new PTE encode for MTL

Add a separate PTE encode function for MTL. The number of PAT registers
have increased to 16 on MTL. All 16 PAT registers are available for
PPGTT mapped pages, but only the lower 4 are available for GGTT mapped
pages.

BSPEC: 63884

Cc: Lucas De Marchi 
Cc: Matt Roper 
Co-developed-by: Fei Yang 
Signed-off-by: Fei Yang 
Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 33 +++-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 32 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  | 13 +--
 4 files changed, 78 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 31e838eee2ef..4197b43150cc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
 }
 
+static u64 mtl_pte_encode(dma_addr_t addr,
+ enum i915_cache_level level,
+ u32 flags)
+{
+   gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+   if (unlikely(flags & PTE_READ_ONLY))
+   pte &= ~GEN8_PAGE_RW;
+
+   if (flags & PTE_LM)
+   pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
+
+   switch (level) {
+   case I915_CACHE_NONE:
+   pte |= GEN12_PPGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_LLC:
+   case I915_CACHE_L3_LLC:
+   pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_WT:
+   pte |= GEN12_PPGTT_PTE_PAT0;
+   break;
+   }
+
+   return pte;
+}
+
 static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
 {
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 */
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
-   ppgtt->vm.pte_encode = gen8_pte_encode;
+   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+   ppgtt->vm.pte_encode = mtl_pte_encode;
+   else
+   ppgtt->vm.pte_encode = gen8_pte_encode;
 
ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.h 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.h
index f541d19264b4..c48f1fc32909 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.h
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.h
@@ -19,4 +19,8 @@ u64 gen8_ggtt_pte_encode(dma_addr_t addr,
 enum i915_cache_level level,
 u32 flags);
 
+u64 mtl_ggtt_pte_encode(dma_addr_t addr,
+   enum i915_cache_level level,
+   u32 flags);
+
 #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 82203ad85b0e..3b6f1f6f780a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -246,6 +246,33 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
}
 }
 
+u64 mtl_ggtt_pte_encode(dma_addr_t addr,
+   enum i915_cache_level level,
+   u32 flags)
+{
+   gen8_pte_t pte = addr | GEN8_PAGE_PRESENT;
+
+   GEM_BUG_ON(addr & ~GEN12_GGTT_PTE_ADDR_MASK);
+
+   if (flags & PTE_LM)
+   pte |= GEN12_GGTT_PTE_LM;
+
+   switch (level) {
+   case I915_CACHE_NONE:
+   pte |= MTL_GGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_LLC:
+   case I915_CACHE_L3_LLC:
+   pte |= MTL_GGTT_PTE_PAT0 | MTL_GGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_WT:
+   pte |= MTL_GGTT_PTE_PAT0;
+   break;
+   }
+
+   return pte;
+}
+
 u64 gen8_ggtt_pte_encode(dma_addr_t addr,
 enum i915_cache_level level,
 u32 flags)
@@ -993,7 +1020,10 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.vma_ops.bind_vma= intel_ggtt_bind_vma;
ggtt->vm.vma_ops.unbind_vma  = intel_ggtt_unbind_vma;
 
-   ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   ggtt->vm.pte_encode = mtl_ggtt_pte_encode;
+   else
+   ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
 
return ggtt_probe_common(ggtt, size);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 8a3e0a6793dd..4bb7a4005452 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -88,9 +88,18 @@ typedef u64 gen8_pte_t;
 #define BYT_PTE_SNOOPED_BY_CPU_CACHES  REG_BIT(2)
 #define BYT_PTE_WRITEABLE  REG_BIT(1)
 
+#define GEN12_PPGTT_PTE_PAT3BIT_ULL(62)
 #define GEN12_PPGTT_PTE_LM BIT_ULL(11)
-
-#define

[Intel-gfx] [PATCH 2/4] drm/i915: Reference pte_encode through vm pointer

New platforms will use different encode functions.

Cc: Lucas De Marchi 
Cc: Matt Roper 
Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/display/intel_dpt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 10 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index ad1a37b515fb..cb8ed9bfb240 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -298,7 +298,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
vm->vma_ops.bind_vma= dpt_bind_vma;
vm->vma_ops.unbind_vma  = dpt_unbind_vma;
 
-   vm->pte_encode = gen8_ggtt_pte_encode;
+   vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
 
dpt->obj = dpt_obj;
 
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..31e838eee2ef 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -427,7 +427,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
  u32 flags)
 {
struct i915_page_directory *pd;
-   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+   const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level, 
flags);
gen8_pte_t *vaddr;
 
pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
@@ -580,7 +580,7 @@ static void gen8_ppgtt_insert_huge(struct 
i915_address_space *vm,
   enum i915_cache_level cache_level,
   u32 flags)
 {
-   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+   const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
unsigned int rem = sg_dma_len(iter->sg);
u64 start = vma_res->start;
 
@@ -743,7 +743,7 @@ static void gen8_ppgtt_insert_entry(struct 
i915_address_space *vm,
GEM_BUG_ON(pt->is_compact);
 
vaddr = px_vaddr(pt);
-   vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+   vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
drm_clflush_virt_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
 }
 
@@ -773,7 +773,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct 
i915_address_space *vm,
}
 
vaddr = px_vaddr(pt);
-   vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+   vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
 }
 
 static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
@@ -820,7 +820,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
pte_flags |= PTE_LM;
 
vm->scratch[0]->encode =
-   gen8_pte_encode(px_dma(vm->scratch[0]),
+   vm->pte_encode(px_dma(vm->scratch[0]),
I915_CACHE_NONE, pte_flags);
 
for (i = 1; i <= vm->top; i++) {
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 7644738b9cdb..82203ad85b0e 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -273,7 +273,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space 
*vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)ggtt->gsm + offset / I915_GTT_PAGE_SIZE;
 
-   gen8_set_pte(pte, gen8_ggtt_pte_encode(addr, level, flags));
+   gen8_set_pte(pte, ggtt->vm.pte_encode(addr, level, flags));
 
ggtt->invalidate(ggtt);
 }
@@ -283,8 +283,8 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 enum i915_cache_level level,
 u32 flags)
 {
-   const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, flags);
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+   const gen8_pte_t pte_encode = ggtt->vm.pte_encode(0, level, flags);
gen8_pte_t __iomem *gte;
gen8_pte_t __iomem *end;
struct sgt_iter iter;
-- 
2.25.1

[Intel-gfx] [PATCH 1/4] drm/i915/mtl: Define MOCS and PAT tables for MTL

From: Madhumitha Tolakanahalli Pradeep 


On MTL due to the introduction of L4 cache, coherency and cacheability
selections are different and also GT can no longer allocate on LLC. The
MOCS/PAT tables needs an update.

BSpec: 44509, 45101, 44235

Cc: Matt Roper 
Cc: Lucas De Marchi 
Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/gt/intel_gtt.c | 23 +++-
 drivers/gpu/drm/i915/gt/intel_gtt.h |  9 +++
 drivers/gpu/drm/i915/gt/intel_mocs.c| 76 +++--
 drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
 drivers/gpu/drm/i915/i915_pci.c |  1 +
 5 files changed, 105 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index e37164a60d37..428849248c34 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -467,6 +467,25 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
 }
 
+static void mtl_setup_private_ppat(struct intel_uncore *uncore)
+{
+   intel_uncore_write(uncore, GEN12_PAT_INDEX(0),
+  MTL_PPAT_L4_0_WB);
+   intel_uncore_write(uncore, GEN12_PAT_INDEX(1),
+  MTL_PPAT_L4_1_WT | MTL_2_COH_1W);
+   intel_uncore_write(uncore, GEN12_PAT_INDEX(2),
+  MTL_PPAT_L4_3_UC | MTL_2_COH_1W);
+   intel_uncore_write(uncore, GEN12_PAT_INDEX(3),
+  MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
+   intel_uncore_write(uncore, GEN12_PAT_INDEX(4),
+  MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
+
+   /*
+* Remaining PAT entries are left at the hardware-default
+* fully-cached setting
+*/
+}
+
 static void tgl_setup_private_ppat(struct intel_uncore *uncore)
 {
/* TGL doesn't support LLC or AGE settings */
@@ -602,7 +621,9 @@ void setup_private_pat(struct intel_gt *gt)
 
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
 
-   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
+   if (IS_METEORLAKE(i915))
+   mtl_setup_private_ppat(uncore);
+   else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
xehp_setup_private_ppat(gt);
else if (GRAPHICS_VER(i915) >= 12)
tgl_setup_private_ppat(uncore);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index d1900fec6cd1..8a3e0a6793dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -147,6 +147,15 @@ typedef u64 gen8_pte_t;
 #define GEN8_PDE_IPS_64K BIT(11)
 #define GEN8_PDE_PS_2M   BIT(7)
 
+#define MTL_PPAT_L4_CACHE_POLICY_MASK  REG_GENMASK(3, 2)
+#define MTL_PAT_INDEX_COH_MODE_MASKREG_GENMASK(1, 0)
+#define MTL_PPAT_L4_3_UC   REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
+#define MTL_PPAT_L4_1_WT   REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
+#define MTL_PPAT_L4_0_WB   REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
+#define MTL_3_COH_2W   REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 3)
+#define MTL_2_COH_1W   REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 2)
+#define MTL_0_COH_NON  REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 0)
+
 enum i915_cache_level;
 
 struct drm_i915_gem_object;
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 69b489e8dfed..89570f137b2c 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -40,6 +40,10 @@ struct drm_i915_mocs_table {
 #define LE_COS(value)  ((value) << 15)
 #define LE_SSE(value)  ((value) << 17)
 
+/* Defines for the tables (GLOB_MOCS_0 - GLOB_MOCS_16) */
+#define _L4_CACHEABILITY(value)((value) << 2)
+#define IG_PAT(value)  ((value) << 8)
+
 /* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
 #define L3_ESC(value)  ((value) << 0)
 #define L3_SCC(value)  ((value) << 1)
@@ -50,6 +54,7 @@ struct drm_i915_mocs_table {
 /* Helper defines */
 #define GEN9_NUM_MOCS_ENTRIES  64  /* 63-64 are reserved, but configured. */
 #define PVC_NUM_MOCS_ENTRIES   3
+#define MTL_NUM_MOCS_ENTRIES   16
 
 /* (e)LLC caching options */
 /*
@@ -73,6 +78,12 @@ struct drm_i915_mocs_table {
 #define L3_2_RESERVED  _L3_CACHEABILITY(2)
 #define L3_3_WB_L3_CACHEABILITY(3)
 
+/* L4 caching options */
+#define L4_0_WB_L4_CACHEABILITY(0)
+#define L4_1_WT_L4_CACHEABILITY(1)
+#define L4_2_RESERVED  _L4_CACHEABILITY(2)
+#define L4_3_UC_L4_CACHEABILITY(3)
+
 #define MOCS_ENTRY(__idx, __control_value, __l3cc_value) \
[__idx] = { \
.control_value = __control_value, \
@@ -416,6 +427,57 @@ static const struct drm_i915_mocs_entry pvc_mocs_table[] = 
{
MOCS_ENTRY(2, 0, L3_3_WB),
 };
 
+static const struct drm_i915_mocs_entry mtl_mocs_table[] = {
+   /* Error - Reserved

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for GSC FW loading (rev3)

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev3)
URL   : https://patchwork.freedesktop.org/series/70/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12471_full -> Patchwork_70v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-dg1 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-apl:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [FAIL][50]) ([i915#4386])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl1/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl1/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl2/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl2/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl3/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl7/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl8/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl8/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl8/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl3/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl3/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl3/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl3/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/shard-apl2/boot.html
   [43]:

Re: [Intel-gfx] [Intel-gfx 6/6] drm/i915/guc: Move guc_log_relay_chan debugfs path to uc



On Mon, 2022-12-05 at 18:04 -0800, Alan Previn Teres Alexis wrote:
> On Wed, 2022-07-20 at 12:08 -0700, Dixit, Ashutosh wrote:
> > On Mon, 09 May 2022 14:01:51 -0700, Alan Previn wrote:
> > > 
> > > All other GuC Relay Logging debugfs handles including recent
> > > additions are under the 'i915/gt/uc/path' so let's also move
> > > 'guc_log_relay_chan' to its proper home
> Alan:[snip]
> 
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > > index 793a06a16874..f6578565fed6 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > > @@ -419,8 +419,11 @@ static int guc_log_relay_create(struct intel_guc_log 
> > > *log)
> > >*/
> > >   n_subbufs = intel_guc_log_relay_subbuf_count(log);
> > > 
> > > + if (!guc->dbgfs_node)
> > > + return -ENOENT;
> > 
> > Once again, why is this check needed? The patch is otherwise fine.
> > 
> 
> Because on i915 upstream today, we do have a code path where that dbgfs_node 
> is not being populated and i assume that
> would be the case if config file disables debugfs? And without that we don't 
> support guc-relay-logging.
> 
Alan: Scratch that - its not needed.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for GSC FW loading (rev3)

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev3)
URL   : https://patchwork.freedesktop.org/series/70/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12471 -> Patchwork_70v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 43)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-adlp-4: [PASS][1] -> [DMESG-WARN][2] ([i915#2867])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/bat-adlp-4/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/bat-adlp-4/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +11 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

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

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

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

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

  
 Possible fixes 

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [DMESG-FAIL][10] ([i915#5334]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-kbl-soraka:  [INCOMPLETE][12] -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/fi-kbl-soraka/igt@i915_selftest@live@late_gt_pm.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v3/fi-kbl-soraka/igt@i915_selftest@live@late_gt_pm.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#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594


Build changes
-

  * Linux: CI_DRM_12471 -> Patchwork_70v3

  CI-20190529: 20190529
  CI_DRM_12471: 7f8dc69dce0e934751fe31c01a6b6baa0c65bf23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7083: c001793d5f22deb01918b6ba52af829794582df1 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_70v3: 7f8dc69dce0e934751fe31c01a6b6baa0c65bf23 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ee1e3939eaa6 drm/i915/mtl: MTL has one GSC CS on the media GT
e15969f278e5 drm/i915/gsc: Disable GSC engine and power well if FW is not 
selected
bbaa650e7920 drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
068927e5d0eb drm/i915/gsc: GSC firmware loading
8aa23f9f1fc5 drm/i915/gsc: Skip the version check when fetching the GSC FW
0a5151b9feca drm/i915/uc: Introduce GSC FW

== Logs ==

For more details see:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for GSC FW loading (rev3)

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev3)
URL   : https://patchwork.freedesktop.org/series/70/
State : warning

== Summary ==

Error: dim checkpatch failed
ed465c9fce3c drm/i915/uc: Introduce GSC FW
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:10: WARNING:TYPO_SPELLING: 'overriden' may be misspelled - perhaps 
'overridden'?
#10: 
Similarly to the other FWs, the GSC FW path can be overriden via
   ^

-:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#72: 
new file mode 100644

-:98: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#98: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c:22:
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);

-:116: ERROR:SPACING: space required before the open brace '{'
#116: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c:40:
+   if (!gsc_engine_supported(gsc_uc_to_gt(gsc))){

-:184: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#184: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h:32:
+   GEM_BUG_ON(__intel_uc_fw_status(>fw) == 
INTEL_UC_FIRMWARE_SELECTED);

-:289: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#289: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:22:
+   GEM_BUG_ON(type >= INTEL_UC_FW_NUM_TYPES);

-:356: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#356: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:67:
 };
+#define INTEL_UC_FW_NUM_TYPES 3

-:378: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#378: FILE: drivers/gpu/drm/i915/i915_params.c:196:
+i915_param_named_unsafe(gsc_firmware_path, charp, 0400,
+   "GSC firmware path to use instead of the default one");

total: 1 errors, 5 warnings, 2 checks, 306 lines checked
d8313266cd68 drm/i915/gsc: Skip the version check when fetching the GSC FW
9fab7ec4f2c8 drm/i915/gsc: GSC firmware loading
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:70: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#70: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:440:
+#define   HECI1_FW_LIMIT_VALID (1<<31)
  ^

-:76: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#76: 
new file mode 100644

-:474: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#474: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:937:
+   GEM_BUG_ON(!intel_uc_fw_is_loadable(uc_fw));

total: 0 errors, 2 warnings, 1 checks, 428 lines checked
360e91d9e2f2 drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
-:135: WARNING:RETURN_VOID: void function return statements are not generally 
useful
#135: FILE: drivers/gpu/drm/i915/intel_uncore.c:2759:
+   return;
+}

total: 0 errors, 1 warnings, 0 checks, 133 lines checked
04b4f509a3bd drm/i915/gsc: Disable GSC engine and power well if FW is not 
selected
611fc700c1fd drm/i915/mtl: MTL has one GSC CS on the media GT

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add support for GSC FW loading (rev3)

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev3)
URL   : https://patchwork.freedesktop.org/series/70/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for DRM_USE_DYNAMIC_DEBUG regression

== Series Details ==

Series: DRM_USE_DYNAMIC_DEBUG regression
URL   : https://patchwork.freedesktop.org/series/111651/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12471_full -> Patchwork_111651v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-mmap-gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-tglb3/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-mmap-gtt.html

  
 Suppressed 

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

  * igt@gem_create@create-clear@smem0:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-rkl-4/igt@gem_create@create-cl...@smem0.html

  * igt@perf_pmu@busy-idle-check-all@vcs0:
- {shard-dg1}:NOTRUN -> [FAIL][4] +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-dg1-17/igt@perf_pmu@busy-idle-check-...@vcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@hang:
- shard-skl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +128 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-skl5/igt@gem_ctx_persiste...@hang.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-iclb2/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-iclb8/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html

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

  * igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html

  * igt@gem_spin_batch@spin-each:
- shard-skl:  [PASS][12] -> [FAIL][13] ([i915#2898])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-skl9/igt@gem_spin_ba...@spin-each.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-skl2/igt@gem_spin_ba...@spin-each.html

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

  * igt@i915_pipe_stress@stress-xrgb-ytiled:
- shard-skl:  NOTRUN -> [FAIL][15] ([i915#7036])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/shard-skl5/igt@i915_pipe_str...@stress-xrgb-ytiled.html

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

  * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +5 
similar issues
   [18]:

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

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

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

v2: use REG_* for register fields definitions (Rodrigo), move to WQ
immediately

v3: mark worker function as static

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 187 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  69 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|   6 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
 10 files changed, 313 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 69f6e9af1b56..dfa211451a1d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -189,6 +189,7 @@ i915-y += \
 
 # general-purpose microcontroller (GuC) support
 i915-y += \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
 #define I915_GEM_HWS_PXP   0x60
 #define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..49ebda141266 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
 #define INSTR_CLIENT_SHIFT  29
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
+#define   INSTR_GSC_CLIENT  0x2 /* MTL+ */
 #define   INSTR_RC_CLIENT   0x3
 #define INSTR_SUBCLIENT_SHIFT   27
 #define INSTR_SUBCLIENT_MASK0x1800
@@ -432,6 +433,12 @@
 #define COLOR_BLT ((0x2<<29)|(0x40<<22))
 #define SRC_COPY_BLT  ((0x2<<29)|(0x43<<22))
 
+#define GSC_INSTR(opcode, data, flags) \
+   (__INSTR(INSTR_GSC_CLIENT) | (opcode) << 22 | (data) << 9 | (flags))
+
+#define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
+#define   HECI1_FW_LIMIT_VALID (1<<31)
+
 /*
  * Used to convert any address to canonical form.
  * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
new file mode 100644
index ..f88069ab71ab
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_fw.h"
+
+#define GSC_FW_STATUS_REG  _MMIO(0x116C40)
+#define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
+#define   GSC_FW_CURRENT_STATE_RESET   0
+#define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
+
+static bool gsc_is_in_reset(struct intel_uncore *uncore)
+{
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_CURRENT_STATE_RESET;
+}
+
+bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return fw_status & GSC_FW_INIT_COMPLETE_BIT;
+}
+
+static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
+{
+   u32 offset = i915_ggtt_offset(gsc->local);
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 4);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = GSC_FW_LOAD;
+   *cs++ = lower_32_bits(offset);
+

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

2022-12-05 Thread Ceraolo Spurio, Daniele





On 12/5/2022 4:03 PM, Alan Previn wrote:

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readibility and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

This promotion comes with two noteworthy changes:

1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.

2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).

Changes from prior revs:
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
  support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
  with that, do additional validity check on i915->pxp for
  intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
  and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
  flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
  through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
  after i915 loading failed without pxp being allocated, check
  i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
  because : [1] introduction of 'ctrl_gt' means we correct this
  for MTL's upcoming series now. [2] Also, this has little impact
  globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
  ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
  pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
  pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
  from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
  and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
  and creating a number of convoluted helpers that takes in i915 as
  input and redirects to the correct intel_gt or takes any intel_gt
  and internally replaces with the

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

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_12471_full -> Patchwork_111650v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 11)
--

  Additional (2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@perf_pmu@busy-idle-check-all@vcs0:
- {shard-dg1}:NOTRUN -> [FAIL][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-dg1-15/igt@perf_pmu@busy-idle-check-...@vcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@hang:
- shard-skl:  NOTRUN -> [SKIP][2] ([fdo#109271]) +150 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-skl5/igt@gem_ctx_persiste...@hang.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html

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

  * igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-skl:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-skl2/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html

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

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

  * igt@i915_pipe_stress@stress-xrgb-ytiled:
- shard-skl:  NOTRUN -> [FAIL][10] ([i915#7036])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-skl7/igt@i915_pipe_str...@stress-xrgb-ytiled.html

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

  * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-skl5/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-apl8/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@hdmi-hpd-storm-disable:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-apl8/igt@kms_chamel...@hdmi-hpd-storm-disable.html

  * igt@kms_color_chamelium@ctm-max:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-skl7/igt@kms_color_chamel...@ctm-max.html

  * igt@kms_content_protection@lic@pipe-a-dp-1:
- shard-apl:  NOTRUN -> [TIMEOUT][17] ([i915#7173])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/shard-apl8/igt@kms_content_protection@l...@pipe-a-dp-1.html

  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#79]) +1 similar issue
   [18]:

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

2022-12-05 Thread Yedireswarapu, SaiX Nandan

Hi,

Issue re-reported, https://patchwork.freedesktop.org/series/111373/
Bug filed for this issue, https://gitlab.freedesktop.org/drm/intel/-/issues/7647


Thanks,
Y Sai Nandan

From: Nautiyal, Ankit K 
Sent: Monday, December 5, 2022 5:49 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 
; Yedireswarapu, SaiX Nandan 

Subject: Re: ✗ Fi.CI.IGT: failure for Align DDI_BUF_CTL Active timeouts with 
Bspec updates (rev4)


Hi Lakshmi, Sai,

The below failure is not related to the patch, it seems to be a known issue: 
https://gitlab.freedesktop.org/drm/intel/-/issues/7452

igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip:

  *   shard-skl: 
PASS
 -> 
INCOMPLETE



Regards,

Ankit
On 12/5/2022 1:02 PM, Patchwork wrote:
Patch Details
Series:
Align DDI_BUF_CTL Active timeouts with Bspec updates (rev4)
URL:
https://patchwork.freedesktop.org/series/111373/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/index.html
CI Bug Log - changes from CI_DRM_12465_full -> Patchwork_111373v4_full
Summary

FAILURE

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

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

Participating hosts (12 -> 14)

Additional (2): shard-rkl shard-dg1

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip:

 *   shard-skl: 
PASS
 -> 
INCOMPLETE

Warnings

  *   igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:

 *   shard-skl: 
SKIP
 (fdo#109271) -> 
INCOMPLETE

  *   igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:

 *   shard-glk: 
FAIL
 (i915#2346) -> 
FAIL

Suppressed

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

  *   igt@i915_suspend@basic-s3-without-i915:

 *   {shard-tglu-10}: NOTRUN -> 
INCOMPLETE

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

 *   {shard-tglu-9}: NOTRUN -> 
SKIP
 +42 similar issues

Known issues

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

IGT changes
Issues hit

  *   igt@feature_discovery@psr2:

 *   shard-iclb: 
PASS
 -> 
SKIP
 (i915#658)

  *   igt@gem_create@create-massive:

 *   shard-skl: NOTRUN -> 
DMESG-WARN
 (i915#4991)

  *   igt@gem_exec_balancer@parallel-contexts:

 *   shard-iclb: 
PASS
 -> 
SKIP
 (i915#4525) +1 similar 
issue

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

 *   shard-glk:

[Intel-gfx] ✓ Fi.CI.IGT: success for Align DDI_BUF_CTL Active timeouts with Bspec updates (rev4)

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_12465_full -> Patchwork_111373v4_full


Summary
---

  **WARNING**

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

  

Participating hosts (12 -> 14)
--

  Additional (2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-skl:  [SKIP][1] ([fdo#109271]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12465/shard-skl6/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-skl6/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk:  [FAIL][3] ([i915#2346]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12465/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  
 Suppressed 

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

  * igt@i915_suspend@basic-s3-without-i915:
- {shard-tglu-10}:NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-tglu-10/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_vblank@pipe-c-ts-continuation-idle-hang:
- {shard-tglu-9}: NOTRUN -> [SKIP][6] +42 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-tglu-9/igt@kms_vbl...@pipe-c-ts-continuation-idle-hang.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#658])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12465/shard-iclb2/igt@feature_discov...@psr2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-iclb7/igt@feature_discov...@psr2.html

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

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12465/shard-iclb2/igt@gem_exec_balan...@parallel-contexts.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-iclb6/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12465/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

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

  * igt@gem_spin_batch@legacy@default:
- shard-apl:  [PASS][16] -> [FAIL][17] ([i915#2898])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12465/shard-apl3/igt@gem_spin_batch@leg...@default.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111373v4/shard-apl3/igt@gem_spin_batch@leg...@default.html

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

[Intel-gfx] ✓ Fi.CI.BAT: success for DRM_USE_DYNAMIC_DEBUG regression

== Series Details ==

Series: DRM_USE_DYNAMIC_DEBUG regression
URL   : https://patchwork.freedesktop.org/series/111651/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12471 -> Patchwork_111651v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 42)
--

  Additional (1): fi-hsw-4770 
  Missing(3): bat-dg2-11 fi-rkl-11600 fi-tgl-dsi 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +11 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

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

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

  
 Possible fixes 

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [DMESG-FAIL][10] ([i915#5334]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-kbl-soraka:  [INCOMPLETE][12] -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/fi-kbl-soraka/igt@i915_selftest@live@late_gt_pm.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111651v1/fi-kbl-soraka/igt@i915_selftest@live@late_gt_pm.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#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#7056]: https://gitlab.freedesktop.org/drm/intel/issues/7056
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346


Build changes
-

  * Linux: CI_DRM_12471 -> Patchwork_111651v1

  CI-20190529: 20190529
  CI_DRM_12471: 7f8dc69dce0e934751fe31c01a6b6baa0c65bf23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7083: c001793d5f22deb01918b6ba52af829794582df1 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111651v1: 7f8dc69dce0e934751fe31c01a6b6baa0c65bf23 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

581b33202eed dyndbg: miss-on HACK
002ac0c5cef5 dyndbg: mess-w-dep-class
9af76c6a6aff dyndbg: ddebug_sanity()
edefdd520046 dyndbg: unwrap __ddebug_add_module inner function NOTYET
d6f5201f2fca drm_print: fix stale macro-name in comment
2f336eae2d14 dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements
73d8e0796c76 dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args
8730bdab5ee7 dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
6f1175135daa dyndbg-API:

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Add support for GSC FW loading (rev2)

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev2)
URL   : https://patchwork.freedesktop.org/series/70/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.o
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c:13:6: error: no previous prototype 
for ‘gsc_work’ [-Werror=missing-prototypes]
 void gsc_work(struct work_struct *work)
  ^~~~
cc1: all warnings being treated as errors
scripts/Makefile.build:250: recipe for target 
'drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.o' failed
make[5]: *** [drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.o] Error 1
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed
make[4]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed
make[3]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed
make[2]: *** [drivers/gpu] Error 2
scripts/Makefile.build:500: recipe for target 'drivers' failed
make[1]: *** [drivers] Error 2
Makefile:1992: recipe for target '.' failed
make: *** [.] Error 2

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DRM_USE_DYNAMIC_DEBUG regression

== Series Details ==

Series: DRM_USE_DYNAMIC_DEBUG regression
URL   : https://patchwork.freedesktop.org/series/111651/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DRM_USE_DYNAMIC_DEBUG regression

== Series Details ==

Series: DRM_USE_DYNAMIC_DEBUG regression
URL   : https://patchwork.freedesktop.org/series/111651/
State : warning

== Summary ==

Error: dim checkpatch failed
8d78d81edb74 test-dyndbg: fixup CLASSMAP usage error
a526555f2fee test-dyndbg: show that DEBUG enables prdbgs at compiletime
69a3d199c77b dyndbg: fix readback value on LEVEL_NAMES interfaces
-:43: WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars 
of sha1> ("")' - ie: 'Fixes: b9400852c080 ("dyndbg: add drm.debug 
style (drm/parameters/debug) bitmap support")'
#43: 
Fixes: b9400852c080 (dyndbg: add drm.debug style (drm/parameters/debug) bitmap 
support)

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
554c7d4e3228 dyndbg: replace classmap list with a vector
6363d68be8a0 dyndbg: make ddebug_apply_class_bitmap more selective
cb8c90d8fccb dyndbg: dynamic_debug_init - use pointer inequality, not strcmp
ef959da3c2ac dyndbg: drop NUM_TYPE_ARRAY
03750f80b032 dyndbg: reduce verbose/debug clutter
f0f3d3b03b78 dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with 
DYNDBG_CLASSMAP(_DEFINE|_USE)
-:46: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#46: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:194:
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",

-:68: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#68: FILE: drivers/gpu/drm/display/drm_dp_helper.c:46:
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",

-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/drm_crtc_helper.c:55:
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",

-:111: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#111: FILE: drivers/gpu/drm/drm_print.c:60:
+DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",

-:125: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#125: FILE: drivers/gpu/drm/i915/i915_params.c:34:
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",

-:147: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#147: FILE: drivers/gpu/drm/nouveau/nouveau_drm.c:76:
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",

-:202: WARNING:TYPO_SPELLING: 'wierd' may be misspelled - perhaps 'weird'?
#202: FILE: include/linux/dynamic_debug.h:117:
+ * it should help regularize the admittedly wierd sharing by identical
 ^

total: 0 errors, 1 warnings, 6 checks, 188 lines checked
b3c275ffb38c dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
-:106: WARNING:TYPO_SPELLING: 'doesnt' may be misspelled - perhaps 'doesn't'?
#106: 
but doesnt alter any callsites.
^^

-:170: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#170: FILE: include/linux/dynamic_debug.h:120:
+};
+/**

-:180: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_var' - possible 
side-effects?
#180: FILE: include/linux/dynamic_debug.h:128:
+#define DYNDBG_CLASSMAP_USE_(_var, _uname, ...)
\
+   extern struct ddebug_class_map _var[];  \
+   static struct ddebug_class_user __used  \
+   __section("__dyndbg_class_refs") _uname = { \
+   .user_mod_name = KBUILD_MODNAME,\
+   .map = _var,\
+   }

-:208: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#208: FILE: kernel/module/main.c:2115:
+   sizeof(*info->dyndbg.class_refs), 
>dyndbg.num_class_refs);

-:208: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#208: FILE: kernel/module/main.c:2115:
+   info->dyndbg.class_refs = section_objs(info, "__dyndbg_class_refs",
+   sizeof(*info->dyndbg.class_refs), 
>dyndbg.num_class_refs);

-:220: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#220: FILE: lib/dynamic_debug.c:46:
+extern struct ddebug_class_user __start___dyndbg_class_refs[];

-:221: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#221: FILE: lib/dynamic_debug.c:47:
+extern struct ddebug_class_user __stop___dyndbg_class_refs[];

-:304: CHECK:BRACES: braces {} should be used on all arms of this statement
#304: FILE: lib/dynamic_debug.c:1222:
+   if (!strncmp(cm->mod_name, dcp->map->mod_name, strlen(cm->mod_name))) {
[...]
+   } else
[...]

-:307: CHECK:BRACES: Unbalanced braces around else statement
#307: FILE: lib/dynamic_debug.c:1225:
+   } else

-:378: CHECK:BRACES: Blank lines aren't

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v9,1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

== Series Details ==

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

== Summary ==

CI Bug Log - changes from CI_DRM_12471 -> Patchwork_111650v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 29)
--

  Missing(15): fi-kbl-soraka fi-rkl-11600 bat-kbl-2 bat-adls-5 fi-tgl-dsi 
bat-dg1-5 fi-bsw-n3050 bat-dg2-8 bat-adlp-9 bat-dg2-9 bat-adlp-6 bat-adlp-4 
bat-jsl-3 bat-dg2-11 fi-bsw-nick 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][3] ([i915#2867]) -> [PASS][4] +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@hangcheck:
- fi-adl-ddr5:[DMESG-WARN][5] ([i915#5591]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12471/fi-adl-ddr5/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111650v1/fi-adl-ddr5/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).

  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591


Build changes
-

  * Linux: CI_DRM_12471 -> Patchwork_111650v1

  CI-20190529: 20190529
  CI_DRM_12471: 7f8dc69dce0e934751fe31c01a6b6baa0c65bf23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7083: c001793d5f22deb01918b6ba52af829794582df1 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111650v1: 7f8dc69dce0e934751fe31c01a6b6baa0c65bf23 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f6c8c50321e3 drm/i915/pxp: Promote pxp subsystem to top-level of i915

== Logs ==

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

Re: [Intel-gfx] [Intel-gfx 6/6] drm/i915/guc: Move guc_log_relay_chan debugfs path to uc


On Wed, 2022-07-20 at 12:08 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:51 -0700, Alan Previn wrote:
> > 
> > All other GuC Relay Logging debugfs handles including recent
> > additions are under the 'i915/gt/uc/path' so let's also move
> > 'guc_log_relay_chan' to its proper home
Alan:[snip]

> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > index 793a06a16874..f6578565fed6 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > @@ -419,8 +419,11 @@ static int guc_log_relay_create(struct intel_guc_log 
> > *log)
> >  */
> > n_subbufs = intel_guc_log_relay_subbuf_count(log);
> > 
> > +   if (!guc->dbgfs_node)
> > +   return -ENOENT;
> 
> Once again, why is this check needed? The patch is otherwise fine.
> 

Because on i915 upstream today, we do have a code path where that dbgfs_node is 
not being populated and i assume that
would be the case if config file disables debugfs? And without that we don't 
support guc-relay-logging.

Re: [Intel-gfx] [Intel-gfx 5/6] drm/i915/guc: Rename GuC log relay debugfs descriptively

> 
Alan:snip
> 

> >  void intel_guc_log_debugfs_register(struct intel_guc_log *log,
> > @@ -204,7 +204,7 @@ void intel_guc_log_debugfs_register(struct 
> > intel_guc_log *log,
> > { "guc_log_dump", _log_dump_fops, NULL },
> > { "guc_load_err_log_dump", _load_err_log_dump_fops, NULL },
> > { "guc_log_level", _log_level_fops, NULL },
> > -   { "guc_log_relay", _log_relay_fops, NULL },
> > +   { "guc_log_relay_ctl", _log_relay_ctl_fops, NULL },
> 
> Even though debugfs, any issue with changing the file name from the uapi
> point of view? Any scripts etc. which will need to be updated?
> 
> 
Alan: Actually, relay logging tool in the IGT would need to change but upstream 
version of that tool has been broken for
a long while now nothing new can break on top of above change. I didnt see any 
other comments on this patch - let me
know if missed something else - as i will attempt to post this again tonight.

Re: [Intel-gfx] [Intel-gfx 3/6] drm/i915/guc: Add a helper for log buffer size



On Tue, 2022-07-19 at 19:49 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:48 -0700, Alan Previn wrote:
> > 
Alan: [snip]
Alan: This patch is not needed any longer because it was also part of another 
re-factor related to error-capture and
debug-log-sizing management changes that got merged earlier this year.

Re: [Intel-gfx] [Intel-gfx 4/6] drm/i915/guc: Provide debugfs for log relay sub-buf info

It's been a while - trying to resurrect this now.



On Tue, 2022-07-19 at 20:40 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:49 -0700, Alan Previn wrote:
> > 
> > 
Alan: [snip]

> > +#define GUC_LOG_RELAY_SUBBUF_COUNT 8
> > +u32 intel_guc_log_relay_subbuf_count(struct intel_guc_log *log)
> > +{
> > +   return GUC_LOG_RELAY_SUBBUF_COUNT;
> > +}
> 
> uapi wise, instead of exposing guc_log_size and subbuf_count, why not
> expose subbuf_size and subbuf_count?

To combine addressing your request + consistency with existing knobs (all of 
which are dedicated for guc-relay-logging),
I'll go ahead and change it to guc_log_relay_subbuf_size_get and 
guc_log_relay_subbuf_count_get.
> 
> > +static int guc_log_relay_buf_size_get(void *data, u64 *val)
> > +{
> > +   struct intel_guc_log *log = data;
> > +
> > +   if (!log)
> > +   return -ENODEV;
> > +   if (!log->vma)
> > +   return -ENODEV;
> 
> Why are these checks needed? Hasn't log been initialized and attached at
> intel_gt_debugfs_register_files()/debugfs_create_file() time itself?
> 
> Also if needed let's do:
> 
>   if (!log || !log->vma)
>   return -ENODEV;
> 
Alan: You are right, we don't to check log but might need to check log->vma: 
its been a long time - i can vaguely
remember but i recall some weird behavior if the user space was holding on to 
relay logging handles and still calling in
while driver is being unloaded. I'll have to retest this and see if its 
something to care about or consider as a user
error. But even there, we can shorten it to if(!log->vma) as the minimum. (of 
course even if there was a bug, the
debugfs path should eventually get released as part of the i915 unload but just 
a tiny bit later after the guc resources
are freed). Same comment here applies to two more comments you provided. Needs 
to be tested.

> 
Alan: [snip]

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

== Series Details ==

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

== Summary ==

Error: dim checkpatch failed
c366ae879c50 drm/i915/pxp: Promote pxp subsystem to top-level of i915
-:114: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#114: 
References: 
https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.ale...@intel.com

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

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

Now that we have the GSC FW support code as a user to the GSC CS, we
can add the relevant flag to the engine mask. Note that the engine will
still be disabled until we define the GSC FW binary file.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 414b4bfd514b..3f803c1280c0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1125,7 +1125,7 @@ static const struct intel_gt_definition xelpmp_extra_gt[] 
= {
.type = GT_MEDIA,
.name = "Standalone Media GT",
.gsi_offset = MTL_MEDIA_GSI_BASE,
-   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2) | BIT(GSC0),
},
{}
 };
-- 
2.37.3

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

From: Jonathan Cavitt 

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

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

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

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d670..99c4b866addd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -894,6 +894,24 @@ static intel_engine_mask_t init_engine_mask(struct 
intel_gt *gt)
engine_mask_apply_compute_fuses(gt);
engine_mask_apply_copy_fuses(gt);
 
+   /*
+* The only use of the GSC CS is to load and communicate with the GSC
+* FW, so we have no use for it if we don't have the FW.
+*
+* IMPORTANT: in cases where we don't have the GSC FW, we have a
+* catch-22 situation that breaks media C6 due to 2 requirements:
+* 1) once turned on, the GSC power well will not go to sleep unless the
+*GSC FW is loaded.
+* 2) to enable idling (which is required for media C6) we need to
+*initialize the IDLE_MSG register for the GSC CS and do at least 1
+*submission, which will wake up the GSC power well.
+*/
+   if (__HAS_ENGINE(info->engine_mask, GSC0) && 
!intel_uc_wants_gsc_uc(>uc)) {
+   drm_notice(>i915->drm,
+  "No GSC FW selected, disabling GSC CS and media 
C6\n");
+   info->engine_mask &= ~BIT(GSC0);
+   }
+
return info->engine_mask;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 3bfb4af0df78..cb45e4a4ace4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2701,6 +2701,9 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
if (fw_domains & BIT(domain_id))
fw_domain_fini(uncore, domain_id);
}
+
+   if ((fw_domains & BIT(FW_DOMAIN_ID_GSC)) && !HAS_ENGINE(gt, GSC0))
+   fw_domain_fini(uncore, FW_DOMAIN_ID_GSC);
 }
 
 /*
-- 
2.37.3

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

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

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

v2: rename FLR function, add comment to explain FLR impact (Rodrigo),
better explain why GSC needs FLR (Alan)

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Alan Previn 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 23 +
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++
 drivers/gpu/drm/i915/intel_uncore.c   | 58 +++
 drivers/gpu/drm/i915/intel_uncore.h   | 13 +
 4 files changed, 97 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index f88069ab71ab..e73d4440c5e8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -166,6 +166,29 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
 
+   /*
+* GSC is only killed by an FLR, so we need to trigger one on unload to
+* make sure we stop it. This is because we assign a chunk of memory to
+* the GSC as part of the FW load , so we need to make sure it stops
+* using it when we release it to the system on driver unload. Note that
+* this is not a problem of the unload per-se, because the GSC will not
+* touch that memory unless there are requests for it coming from the
+* driver; therefore, no accesses will happen while i915 is not loaded,
+* but if we re-load the driver then the GSC might wake up and try to
+* access that old memory location again.
+* Given that an FLR is a very disruptive action (see the FLR function
+* for details), we want to do it as the last action before releasing
+* the access to the MMIO bar, which means we need to do it as part of
+* the primary uncore cleanup.
+* An alternative approach to the FLR would be to use a memory location
+* that survives driver unload, like e.g. stolen memory, and keep the
+* GSC loaded across reloads. However, this requires us to make sure we
+* preserve that memory location on unload and then determine and
+* reserve its offset on each subsequent load, which is not trivial, so
+* it is easier to just kill everything and start fresh.
+*/
+   intel_uncore_set_flr_on_fini(>i915->uncore);
+
err = gsc_fw_load(gsc);
if (err)
goto fail;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b90fe6a28f7..b95d533652a4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -118,6 +118,9 @@
 
 #define GU_CNTL_MMIO(0x101010)
 #define   LMEM_INITREG_BIT(7)
+#define   DRIVERFLRREG_BIT(31)
+#define GU_DEBUG   _MMIO(0x101018)
+#define   DRIVERFLR_STATUS REG_BIT(31)
 
 #define GEN6_STOLEN_RESERVED   _MMIO(0x1082C0)
 #define GEN6_STOLEN_RESERVED_ADDR_MASK (0xFFF << 20)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8006a6c61466..3bfb4af0df78 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2703,6 +2703,61 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
}
 }
 
+/*
+ * The driver-initiated FLR is the highest level of reset that we can trigger
+ * from within the driver. It is different from the PCI FLR in that it doesn't
+ * fully reset the SGUnit and doesn't modify the PCI config space and therefore
+ * it doesn't require a re-enumeration of the PCI BARs. However, the
+ * driver-initiated FLR does still cause a reset of both GT and display and a
+ * memory wipe of local and stolen memory, so recovery would require a full HW
+ * re-init and saving/restoring (or re-populating) the wiped memory. Since we
+ * perform the FLR as the very last action before releasing access to the HW
+ * during the driver release flow, we don't attempt recovery at all, because
+ * if/when a new instance of i915 is bound to the device it will do a full
+ * re-init anyway.
+ */
+static void driver_initiated_flr(struct intel_uncore *uncore)
+{
+   struct drm_i915_private *i915 = uncore->i915;
+   const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
*/
+   int ret;
+
+

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

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

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

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

v2: re-order Makefile list to be properly sorted (Jani, Alan), better
comment (alan)

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

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 01974b82d205..69f6e9af1b56 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -188,9 +188,8 @@ i915-y += \
  i915_vma_resource.o
 
 # general-purpose microcontroller (GuC) support
-i915-y += gt/uc/intel_uc.o \
- gt/uc/intel_uc_debugfs.o \
- gt/uc/intel_uc_fw.o \
+i915-y += \
+ gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
  gt/uc/intel_guc_capture.o \
@@ -205,7 +204,10 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_guc_submission.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
- gt/uc/intel_huc_fw.o
+ gt/uc/intel_huc_fw.o \
+ gt/uc/intel_uc.o \
+ gt/uc/intel_uc_debugfs.o \
+ gt/uc/intel_uc_fw.o
 
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index e0365d556248..d2f4fbde5f9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -39,6 +39,11 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
return container_of(huc, struct intel_gt, uc.huc);
 }
 
+static inline struct intel_gt *gsc_uc_to_gt(struct intel_gsc_uc *gsc_uc)
+{
+   return container_of(gsc_uc, struct intel_gt, uc.gsc);
+}
+
 static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
 {
return container_of(gsc, struct intel_gt, gsc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
new file mode 100644
index ..65cbf1ce9fa1
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include "gt/intel_gt.h"
+#include "intel_gsc_uc.h"
+#include "i915_drv.h"
+
+static bool gsc_engine_supported(struct intel_gt *gt)
+{
+   intel_engine_mask_t mask;
+
+   /*
+* We reach here from i915_driver_early_probe for the primary GT before
+* its engine mask is set, so we use the device info engine mask for it.
+* For other GTs we expect the GT-specific mask to be set before we
+* call this function.
+*/
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);
+
+   if (gt_is_root(gt))
+   mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
+   else
+   mask = gt->info.engine_mask;
+
+   return __HAS_ENGINE(mask, GSC0);
+}
+
+void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
+{
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+
+   /* we can arrive here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence check device info's
+* engine mask
+*/
+   if (!gsc_engine_supported(gsc_uc_to_gt(gsc))){
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+   return;
+   }
+}
+
+int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
+{
+   struct drm_i915_private *i915 = gsc_uc_to_gt(gsc)->i915;
+   int err;
+
+   err = intel_uc_fw_init(>fw);
+   if (err)
+   goto out;
+
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOADABLE);
+
+   return 0;
+
+out:
+   i915_probe_error(i915, "failed with %d\n", err);
+   return err;
+}
+
+void intel_gsc_uc_fini(struct intel_gsc_uc *gsc)
+{
+

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

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

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

v2: use REG_* for register fields definitions (Rodrigo), move to WQ
immediately

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 187 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  69 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|   6 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
 10 files changed, 313 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 69f6e9af1b56..dfa211451a1d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -189,6 +189,7 @@ i915-y += \
 
 # general-purpose microcontroller (GuC) support
 i915-y += \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
 #define I915_GEM_HWS_PXP   0x60
 #define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..49ebda141266 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
 #define INSTR_CLIENT_SHIFT  29
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
+#define   INSTR_GSC_CLIENT  0x2 /* MTL+ */
 #define   INSTR_RC_CLIENT   0x3
 #define INSTR_SUBCLIENT_SHIFT   27
 #define INSTR_SUBCLIENT_MASK0x1800
@@ -432,6 +433,12 @@
 #define COLOR_BLT ((0x2<<29)|(0x40<<22))
 #define SRC_COPY_BLT  ((0x2<<29)|(0x43<<22))
 
+#define GSC_INSTR(opcode, data, flags) \
+   (__INSTR(INSTR_GSC_CLIENT) | (opcode) << 22 | (data) << 9 | (flags))
+
+#define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
+#define   HECI1_FW_LIMIT_VALID (1<<31)
+
 /*
  * Used to convert any address to canonical form.
  * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
new file mode 100644
index ..f88069ab71ab
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_fw.h"
+
+#define GSC_FW_STATUS_REG  _MMIO(0x116C40)
+#define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
+#define   GSC_FW_CURRENT_STATE_RESET   0
+#define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
+
+static bool gsc_is_in_reset(struct intel_uncore *uncore)
+{
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_CURRENT_STATE_RESET;
+}
+
+bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return fw_status & GSC_FW_INIT_COMPLETE_BIT;
+}
+
+static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
+{
+   u32 offset = i915_ggtt_offset(gsc->local);
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 4);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = GSC_FW_LOAD;
+   *cs++ = lower_32_bits(offset);
+   *cs++ = upper_32_bits(offset);

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

The current exectation from the FW side is that the driver will query
the GSC FW version after the FW is loaded, similarly to what the mei
driver does on DG2. However, we're discussing with the FW team if there
is a way to extract the version from the bin file before loading, so we
can keep the code the same as for older FWs.

Since the GSC FW version is not currently required for functionality and
is only needed for debug purposes, we can skip the FW version for now at
fetch time and add it later on when we've agreed on the approach.

v2: rebased on uc_fw version struct changes.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Reviewed-by: Rodrigo Vivi  #v1
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 29 +++-
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 1d6249d4b8ef..78ab60c07a2b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -655,6 +655,26 @@ static bool guc_check_version_range(struct intel_uc_fw 
*uc_fw)
return true;
 }
 
+static int check_fw_header(struct intel_gt *gt,
+  const struct firmware *fw,
+  struct intel_uc_fw *uc_fw)
+{
+   int err = 0;
+
+   /* GSC FW version is queried after the FW is loaded */
+   if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
+   return 0;
+
+   if (uc_fw->loaded_via_gsc)
+   err = check_gsc_manifest(fw, uc_fw);
+   else
+   err = check_ccs_header(gt, fw, uc_fw);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 /**
  * intel_uc_fw_fetch - fetch uC firmware
  * @uc_fw: uC firmware
@@ -724,17 +744,14 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (err)
goto fail;
 
-   if (uc_fw->loaded_via_gsc)
-   err = check_gsc_manifest(fw, uc_fw);
-   else
-   err = check_ccs_header(gt, fw, uc_fw);
+   err = check_fw_header(gt, fw, uc_fw);
if (err)
goto fail;
 
if (uc_fw->type == INTEL_UC_FW_TYPE_GUC && 
!guc_check_version_range(uc_fw))
goto fail;
 
-   if (uc_fw->file_wanted.ver.major) {
+   if (uc_fw->file_wanted.ver.major && uc_fw->file_selected.ver.major) {
/* Check the file's major version was as it claimed */
if (uc_fw->file_selected.ver.major != 
uc_fw->file_wanted.ver.major) {
drm_notice(>drm, "%s firmware %s: unexpected 
version: %u.%u != %u.%u\n",
@@ -751,7 +768,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
}
}
 
-   if (old_ver) {
+   if (old_ver && uc_fw->file_selected.ver.major) {
/* Preserve the version that was really wanted */
memcpy(_fw->file_wanted, _ideal, 
sizeof(uc_fw->file_wanted));
 
-- 
2.37.3

[Intel-gfx] [PATCH v2 0/6] drm/i915: Add support for GSC FW loading

Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).

The loading happens via a submission to the GSC engine. All subsequent
communication with the FW will also happen via the engine, although no
further messages are implemented as part of this series.

This series also adds the GSC engine flag to the MTL platform, with the
engine being runtime disabled if the FW is not selected, which makes the
FW definition (not included in the series) the ultimate enabler for the
whole GSC block.

Note that just loading the FW is not enough for it to be fully
functional. We'll also need to establish and handle a communication
channel between GSC and CSME (a.k.a. SW proxy). This will require a new
mei component to handle the CSME side of things, so it will be pushed as
a separate series.

v2: Use wq to load the GSC, address minor review comments.

Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 

Daniele Ceraolo Spurio (5):
  drm/i915/uc: Introduce GSC FW
  drm/i915/gsc: Skip the version check when fetching the GSC FW
  drm/i915/gsc: GSC firmware loading
  drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
  drm/i915/mtl: MTL has one GSC CS on the media GT

Jonathan Cavitt (1):
  drm/i915/gsc: Disable GSC engine and power well if FW is not selected

 drivers/gpu/drm/i915/Makefile|  11 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  18 ++
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/intel_gt.h   |   5 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 210 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c| 137 
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  47 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  23 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|   3 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  78 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   8 +-
 drivers/gpu/drm/i915/i915_params.c   |   3 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_uncore.c  |  61 ++
 drivers/gpu/drm/i915/intel_uncore.h  |  13 ++
 19 files changed, 626 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

-- 
2.37.3

[Intel-gfx] [RFC PATCH 17/17] dyndbg: miss-on HACK

dont break the loop, to see multiple clients.  the 3 client records
are differently wrong.
---
 lib/dynamic_debug.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 3ef1c0a1f0cd..a26eaa348731 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -629,6 +629,7 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
return matches;
 }
 
@@ -1321,8 +1322,8 @@ static void ddebug_attach_client_module_classes(struct 
ddebug_table *dt, struct
 */
v2pr_info("break on %d/%d\n", i, di->num_class_refs);
dt->num_class_refs = 1;
-   break;
-   }
+   } else
+   v2pr_info("miss on %d/%d\n", i, di->num_class_refs);
}
 }
 
-- 
2.38.1

[Intel-gfx] [RFC PATCH 13/17] drm_print: fix stale macro-name in comment

Cited commit uses stale macro name, fix this, and explain better.

When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug.  This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the macro args: DRM_UT_* list must be kept in sync
and in order.

Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
drivers.")
Signed-off-by: Jim Cromie 
---
. emphasize ABI non-change despite enum val change - Jani Nikula
. reorder to back of patchset to follow API name changes.
---
 include/drm/drm_print.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 6a27e8f26770..7695ba31b3a4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
char *prefix)
  *
  */
 enum drm_debug_category {
-   /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+   /*
+* Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
+* the enum-values define BIT()s in drm.debug, so are ABI.
+*/
/**
 * @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
 * drm_memory.c, ...
-- 
2.38.1

[Intel-gfx] [RFC PATCH 12/17] dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements

patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.

changes here:

0- Add William Swanson's public domain map macro:
   https://github.com/swansontec/map-macro/blob/master/map.h
   this makes 1 possible.

1- classnames were formerly specified as strings: "DRM_UT_CORE"
   now they are the actual enum const symbols: DRM_UT_CORE
   direct use of symbols is tighter, more comprehensible by tools, grep

2- drop _base arg.
   _base was the value of the 1st classname
   that is now available due to 1, no need to require it 2x

So take _base out of the API/kdoc.  Note that the macro impl keeps the
_base arg so that it can be used to set classmap.base, but reuses it
in the MAP-stringify _base, __VA_ARGS__ expression.

Also cleanup the API usage comment in test_dynamic_debug.c, and since
comments in test-code might not be noticed, restate that here.

Using the CLASSMAP api:

  - class-specifications are enum consts/symbols,
like DRM_UT_CORE, DRM_UT_KMS, etc.
their values define bit positions to drm.debug (as before)

  - they are stringified and accepted at >control
echo class DRM_UT_CORE +p >control

  - multiple class-maps must share the per-module: 0-62 class_id space
(by setting initial enum values to non-overlapping subranges)

todo: fixup the 'i' prefix, a quick/dirty avoidance of MAP.

NOTE: test_dynamic_debug.c also has this helper macro to wire a
classmap to a drm.debug style parameter; its easier to just use it as
a model/template as needed, rather than try to make it general enough
to be an official API helper.

 define DD_SYS_WRAP(_model, _flags) \
static unsigned long bits_##_model; \
static struct ddebug_class_param _flags##_model = { \
.bits = _##_model, \
.flags = #_flags,   \
.map = _##_model,   \
};  \
module_param_cb(_flags##_##_model, _ops_dyndbg_classes, 
&_flags##_model, 0600)

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_print.c   | 22 +++---
 include/drm/drm_print.h   |  1 +
 include/linux/dynamic_debug.h | 17 ++-
 include/linux/map.h   | 54 +++
 lib/test_dynamic_debug.c  | 43 ++--
 5 files changed, 95 insertions(+), 42 deletions(-)
 create mode 100644 include/linux/map.h

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4b697e18238d..07c25241e8cc 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,17 +56,17 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each 
bit enables a debug cat
 module_param_named(debug, __drm_debug, ulong, 0600);
 #else
 /* classnames must match vals of enum drm_debug_category */
-DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS,
+  DRM_UT_CORE,
+  DRM_UT_DRIVER,
+  DRM_UT_KMS,
+  DRM_UT_PRIME,
+  DRM_UT_ATOMIC,
+  DRM_UT_VBL,
+  DRM_UT_STATE,
+  DRM_UT_LEASE,
+  DRM_UT_DP,
+  DRM_UT_DRMRES);
 
 static struct ddebug_class_param drm_debug_bitmap = {
.bits = &__drm_debug,
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..6a27e8f26770 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -333,6 +333,7 @@ static inline bool drm_debug_enabled_raw(enum 
drm_debug_category category)
})
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+//extern struct ddebug_class_map drm_debug_classes[];
 /*
  * the drm.debug API uses dyndbg, so each drm_*dbg macro/callsite gets
  * a descriptor, and only enabled callsites are reachable.  They use
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 0088fc354c98..6f53a687cb32 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -7,6 +7,7 @@
 #endif
 
 #include 
+#include 
 
 /*
  * An instance of this structure is created in a special
@@ -92,18 +93,16 @@ struct ddebug_class_map {
 };
 
 /**
- * DYNDBG_CLASSMAP_DEFINE - define debug-classes used by a module.
- * @_var:   name of the classmap, exported for

[Intel-gfx] [RFC PATCH 09/17] dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with DYNDBG_CLASSMAP(_DEFINE|_USE)

DECLARE_DYNDBG_CLASSMAPs job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf.  Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap).  Modules wanting a drm.debug
style knob need to create the kparam, and call module_param_cb() to
wire the sysfs node to the classmap.  DRM does this is in drm_print.c

In DRM, multiple modules declare identical DRM_UT_* classmaps, so that
the class'd prdbgs are modified across those modules in a coordinated
way across the subsystem, by either explicit class DRM_UT_* queries to
>control, or by writes to /sys/module/drm/parameters/debug (drm.debug)

This coordination-by-identical-declarations is weird, so this patch
splits the macro into _DEFINE and _USE flavors.  This distinction
follows the "define-once, declare-many-uses" principle, so it improves
the api; _DEFINE is used once to specify the classmap, and multiple
users _USE the single definition explicitly.

Currently the latter just reuses the former, and still needs all the
same args, but that can be tuned later; the _DEFINE can initialize an
(extern/global) struct classmap, and _USE can, well use/reference
that struct.

Also wrap DYNDBG_CLASSMAP_USEs with ifdef DRM_USE_DYNAMIC_DEBUG to
balance with the one around drm_print's use of DYNDBG_CLASSMAP_DEFINE.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +++-
 drivers/gpu/drm/display/drm_dp_helper.c |  4 +++-
 drivers/gpu/drm/drm_crtc_helper.c   |  4 +++-
 drivers/gpu/drm/drm_print.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +++-
 include/linux/dynamic_debug.h   | 20 
 lib/test_dynamic_debug.c| 32 -
 8 files changed, 48 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bf2d50c8c92a..0075184b5d93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -188,7 +188,8 @@ int amdgpu_vcnfw_log;
 
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -199,6 +200,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..8fa7a88299e7 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -41,7 +41,8 @@
 
 #include "drm_dp_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -52,6 +53,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 struct dp_aux_backlight {
struct backlight_device *base;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 7d86020b5244..2f747c9c8f60 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,7 +51,8 @@
 
 #include "drm_crtc_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -62,6 +63,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 /**
  * DOC: overview
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 5b93c11895bb..4b697e18238d 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,7 +56,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 module_param_named(debug, __drm_debug, ulong, 0600);
 #else
 /* classnames must match vals of enum drm_debug_category */

[Intel-gfx] [RFC PATCH 11/17] dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args

Drop macro args after _var.  Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward.  Keep only the _var arg, which is the extern'd struct
classmap with all the class info.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +-
 drivers/gpu/drm/display/drm_dp_helper.c | 12 +-
 drivers/gpu/drm/drm_crtc_helper.c   | 12 +-
 drivers/gpu/drm/i915/i915_params.c  | 12 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 12 +-
 include/linux/dynamic_debug.h   | 30 ++---
 6 files changed, 22 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0075184b5d93..7bcc22ef5d49 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -189,17 +189,7 @@ int amdgpu_vcnfw_log;
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 struct amdgpu_mgpu_info mgpu_info = {
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8fa7a88299e7..3bc188cb1116 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -42,17 +42,7 @@
 #include "drm_dp_helper_internal.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 struct dp_aux_backlight {
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 2f747c9c8f60..5fb83336b015 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -52,17 +52,7 @@
 #include "drm_crtc_helper_internal.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5b2542ae364..e959d0384ead 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -30,17 +30,7 @@
 #include "i915_drv.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 #define i915_param_named(name, T, perm, desc) \
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2963cf5b0807..609edeb2a117 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -72,17 +72,7 @@
 #include "nouveau_dmem.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");

[Intel-gfx] [RFC PATCH 15/17] dyndbg: ddebug_sanity()

It appears that, at least for builtin drm,i915 loadable amdgpu, data
in the class_refs section is not properly linked, this works partway
towards isolating the problem.

The "NO CLI" name test is failing.
 This version of the report fails with a non-canonical address:
 // v2pr_info("NO CLI name on: %s\n", cli->map->mod_name);

[0.109299] dyndbg: add-module: main 6 sites 1.3
[0.109595] general protection fault, probably for non-canonical address 
0x726576697264: 

fwiw:
  $ perl -e ' $a = pack "H8", "726576697264"; print "a:<$a>\n"'
  a:

These records are added to __dyndbg_class_refs section by
DYNDBG_CLASSMAP_USE

This patch adds ddebug_sanity(), and calls it 3 times to characterize
what goes wrong and when.  It turns out that its contents are wrong
immediately, in 1st step of dynamic_debug_init().

[0.107327] dyndbg: classes
[0.107537] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[0.107592] dyndbg: class-refs
[0.107823] dyndbg: class-ref[0]: cli:834fc508 map:8293e35e 
nm: nm:(null)
[0.108554] dyndbg: class-ref[1]: cli:834fc518 map:8293fe86 
nm:834fc4c8 nm:
[0.108590] dyndbg: class-ref[2]: cli:834fc528 map:829785aa 
nm:834fc4c8 nm:

Those maps are wrong:

class-refs should all ref the same map, ie class[0]: module:drm.
the nm:s should also show module names of 3 builtin clients of drm.
So things must end poorly.

modprobing the loadable module does better:

bash-5.2# modprobe amdgpu
[ 6645.212706] AMD-Vi: AMD IOMMUv2 functionality not available on this system - 
This is not a bug.
[ 6645.653124] dyndbg: add-module: amdgpu 4425 sites 0.1
[ 6645.653582] dyndbg: classes
[ 6645.653830] dyndbg: class-refs
[ 6645.654124] dyndbg: class-ref[0]: cli:c0a31b90 map:834fc4c8 
nm:c08bc176 nm:amdgpu
[ 6645.654936] dyndbg: classes
[ 6645.655188] dyndbg: class-refs
[ 6645.655450] dyndbg: class-ref[0]: cli:c0a31b90 map:834fc4c8 
nm:c08bc176 nm:amdgpu
[ 6645.656246] dyndbg: class_ref[0] amdgpu -> drm
[ 6645.656613] dyndbg: amdgpu needs drm, 0x0
[ 6645.656953] dyndbg: apply bitmap: 0x0 to: 0x0
[ 6645.657322] dyndbg: break on 0/1
[ 6645.657592] dyndbg: 4425 debug prints in module amdgpu

Here, the maps are correct; they ref the class[0] module:drm above.
That said, apply bitmap is wrong.

Signed-off-by: Jim Cromie 

---

[1.210094] dyndbg: add-module: drm 302 sites 1.3
[1.210496] dyndbg: classes
[1.210674] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.211290] dyndbg: class-refs
[1.211548] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.211674] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.212464] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.212675] dyndbg: classes start: class[0]: module:drm base:0 len:10 ty:0
[1.213257] dyndbg: builtin class: module:drm base:0 len:10 ty:0
[1.213675] dyndbg: controlling kp: drm.drm.debug
[1.214087] dyndbg: module:drm attached 1 classes
[1.214490] dyndbg: classes
[1.214674] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.215291] dyndbg: class-refs
[1.215552] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.215674] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.216430] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.216674] dyndbg: NO CLI 8293e376 726576697264
[1.217149] dyndbg: 302 debug prints in module drm
[1.217549] dyndbg: add-module: drm_kms_helper 95 sites 1.3
[1.217674] dyndbg: classes
[1.217913] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.218525] dyndbg: class-refs
[1.218674] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.219486] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.219674] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.220469] dyndbg: classes
[1.220674] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.221324] dyndbg: class-refs
[1.221606] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.221674] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.222472] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.222674] dyndbg: NO CLI 8293e376 726576697264
[1.223173] dyndbg:  95 debug prints in module drm_kms_helper
[1.223675] dyndbg: add-module: drm_display_helper 150 sites 1.3
[

[Intel-gfx] [RFC PATCH 14/17] dyndbg: unwrap __ddebug_add_module inner function NOTYET

The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn.  Its one-time purpose was subsumed
into the ddebug_info record, which is used in dynamic_debug_init() as
a cursor to load the builtin _ddebug[] table.

TODO: cited commit gives another reason for base, to provide an index
in support of de-duplicating column data.  Refresh that patchset to
see if its still true.

Fixes: 6afa31514977 ("dyndbg: unwrap __ddebug_add_module inner function")

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 45b8414fa130..02f36c553835 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1329,8 +1329,7 @@ static void ddebug_attach_client_module_classes(struct 
ddebug_table *dt, struct
  * Allocate a new ddebug_table for the given module
  * and add it to the global list.
  */
-static int __ddebug_add_module(struct _ddebug_info *di, unsigned int base,
-  const char *modname)
+int ddebug_add_module(struct _ddebug_info *di, const char *modname)
 {
struct ddebug_table *dt;
 
@@ -1372,11 +1371,6 @@ static int __ddebug_add_module(struct _ddebug_info *di, 
unsigned int base,
return 0;
 }
 
-int ddebug_add_module(struct _ddebug_info *di, const char *modname)
-{
-   return __ddebug_add_module(di, 0, modname);
-}
-
 /* helper for ddebug_dyndbg_(boot|module)_param_cb */
 static int ddebug_dyndbg_param_cb(char *param, char *val,
const char *modname, int on_err)
@@ -1519,7 +1513,7 @@ static int __init dynamic_debug_init(void)
mod_ct++;
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-   ret = __ddebug_add_module(, i - mod_sites, modname);
+   ret = ddebug_add_module(, modname);
if (ret)
goto out_err;
 
@@ -1530,7 +1524,7 @@ static int __init dynamic_debug_init(void)
}
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-   ret = __ddebug_add_module(, i - mod_sites, modname);
+   ret = ddebug_add_module(, modname);
if (ret)
goto out_err;
 
-- 
2.38.1

[Intel-gfx] [RFC PATCH 08/17] dyndbg: reduce verbose/debug clutter

currently, for verbose=3, this is logged:

[ 3832.333424] dyndbg: parsed: func="" file="" module="amdgpu" format="" 
lineno=0-0 class=DRM_UT_PRIME
[ 3832.333888] dyndbg: no matches for query
[ 3832.334093] dyndbg: no-match: func="" file="" module="amdgpu" format="" 
lineno=0-0 class=DRM_UT_PRIME
[ 3832.334570] dyndbg: processed 1 queries, with 0 matches, 0 errs

This patch removes 2nd & 3rd lines;
 3 differs from 1 only by status
 2 is just status, retold in 4, with more info.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a0dc681cd215..445f25ef2461 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -265,9 +265,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
 
-   if (!nfound && verbose)
-   pr_info("no matches for query\n");
-
return nfound;
 }
 
@@ -536,7 +533,7 @@ static int ddebug_exec_query(char *query_string, const char 
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
 #define MAXWORDS 9
-   int nwords, nfound;
+   int nwords;
char *words[MAXWORDS];
 
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -554,10 +551,7 @@ static int ddebug_exec_query(char *query_string, const 
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
-   nfound = ddebug_change(, );
-   vpr_info_dq(, nfound ? "applied" : "no-match");
-
-   return nfound;
+   return ddebug_change(, );
 }
 
 /* handle multiple queries in query string, continue on error, return
-- 
2.38.1

[Intel-gfx] [RFC PATCH 16/17] dyndbg: mess-w-dep-class

for loadable drm, helpers, and drivers, dependent-load is failing to
apply changes, needs more investigation.
---
 lib/dynamic_debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 46684aa7284d..3ef1c0a1f0cd 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1248,14 +1248,14 @@ static void ddebug_find_kparam(struct ddebug_class_map 
*cm)
 
 static void ddebug_param_load_dependent_class(const struct ddebug_class_user 
*cli)
 {
-   unsigned long new_bits, old_bits = 0;
+   unsigned long *new_bits, old_bits = 0;
 
-   new_bits = *cli->map->dc_parm->bits;
+   new_bits = cli->map->dc_parm->bits;
 
vpr_info("%s needs %s, 0x%lx\n", cli->user_mod_name,
-cli->map->mod_name, new_bits);
+cli->map->mod_name, *new_bits);
 
-   ddebug_apply_class_bitmap(cli->map->dc_parm, _bits, _bits, 
cli->user_mod_name);
+   ddebug_apply_class_bitmap(cli->map->dc_parm, new_bits, _bits, 
cli->user_mod_name);
 }
 
 static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
-- 
2.38.1

[Intel-gfx] [RFC PATCH 10/17] dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)

Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE variants, lets
differentiate them according to their separate jobs.

Dyndbg's existing __dyndbg_classes[] section does:

. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.

This patch adds __dyndbg_class_refs[] section:

. catalogs references/uses of the above classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. maps the client module to classmap definitions
  this allows dyndbg to propagate drm.debug to the client module.

The distinction of the 2 roles yields 2 gains:

It follows the define-once-declare-elsewhere pattern that K gave us,
dumping the weird coordinated-changes-by-identical-classmaps API.

It should help solve the chicken-egg problem that drm.debug-on-dyndbg
has; the _USEr module must propagate the drm.debug setting once the
using module has loaded.

The new DYNDBG_CLASSMAP macros add records to the sections:

DYNDBG_CLASSMAP_DEFINE:
  invoked by drm_print, just once per sub-system.
  defines the classmap, names "DRM_UT_*", maps to class_id's
  authorizes dyndbg to exert >control
  populates __dyndbg_classes[] "section", __used.
  exports the classmap.

DYNDBG_CLASSMAP_USE:
  invoked by modules using classmaps defined & exported elsewhere
  populates __dyndbg_class_refs[] "section", __used.
  maps client-module name to the extern'd classmap.
  no client-name yet, but will need it.

also:

struct ddebug_info gets 2 new fields to encapsulate the new section:
  class_refs, num_class_refs.
  set by dynamic_debug_init() for builtins.
  or by kernel/module/main:load_info() for loadable modules.

. struct ddebug_class_user
  contains: user-module-name, ref to classmap-defn
  dyndbg finds drm-driver's use of a classmap, gets/applies its settings

. struct ddebug_class_map gets .knob ptr to ddebug_class_param.
  compiled null, init'd under ddebug_add_module()
  allows finding drm.debug setting.

. vmlinux.lds.h additions: linker symbols, KEEP for new section

dynamic_debug.c:

ddebug_attach_module_classes():
  as before
  foreach __dyndbg_classes: ddebug_find_kparam(classmap*)

ddebug_attach_client_module_classes():
  foreach __dyndbg_class_refs: ddebug_param_load_dependent_class(classmap*)
  called after list-add to ddebug-tables.

ddebug_load_dependent_class():

This applies >controls to the module, it needs the module to be
present in the ddebug-tables list so that ddebug_change can apply the
changes to it.  So in ddebug_add_module, call 2nd fn *after* adding
the ddebug_table to the list.

ddebug_find_kparam(classmap*):

Finds the kernel-param / sysfs-node that controls the classmap, by
verifying that dyndbg's kparam-ops are used by the kparam.  The found
kparams arg is our ddebug_class_param, and has a ref to the state-var
under the sysfs-node.

ddebug_match_attach_kparam():

tests that kparam.ops == dyndbg's, then casts arg to
ddebug_class_param, and tests modnames for equality.

ddebug_param_load_dependent_class(struct ddebug_class_user*):

Called on class_refs entries, these classmaps have already been seen
by ddebug_find_kparam() which has wired the classmap.knob to the kparam.
So this fn just calls ddebug_apply_class_bitmap() on the state-var.

ddebug_find_valid_class():

This helps ddebug_change(), doing the search over classmaps, looking
for the class given to >control.  So now it searches over
__dyndbg_class_refs[] after __dyndbg_classes[].

Thats the theory anyway.  things are still broken (differently) for
both builtins and loadables.  For loadables, the >control is applied,
but doesnt alter any callsites.

Signed-off-by: Jim Cromie 
---
 include/asm-generic/vmlinux.lds.h |   3 +
 include/linux/dynamic_debug.h |  41 ++---
 kernel/module/main.c  |   2 +
 lib/dynamic_debug.c   | 137 +++---
 4 files changed, 157 insertions(+), 26 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 3dc5824141cd..7100701fb68c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -363,6 +363,9 @@
__start___dyndbg_classes = .;   \
KEEP(*(__dyndbg_classes))   \
__stop___dyndbg_classes = .;\
+   __start___dyndbg_class_refs = .;\
+   KEEP(*(__dyndbg_class_refs))\
+   __stop___dyndbg_class_refs = .; \
__start___dyndbg = .;   \
KEEP(*(__dyndbg))   \
__stop___dyndbg = .;\
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index

[Intel-gfx] [RFC PATCH 07/17] dyndbg: drop NUM_TYPE_ARRAY

ARRAY_SIZE works here, since array decl is complete.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -104,11 +104,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base,  \
.map_type = _maptype,   \
-   .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+   .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames,   \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
 /* encapsulate linker provided built-in (or module) dyndbg data */
 struct _ddebug_info {
-- 
2.38.1

[Intel-gfx] [RFC PATCH 06/17] dyndbg: dynamic_debug_init - use pointer inequality, not strcmp

dynamic_debug_init() currently uses strcmp to find the module
boundaries in the builtin _ddebug[] table.

The table is filled by the linker; for its content, pointer inequality
works, is faster, and communicates the data properties more tightly.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 5d609ff0d559..a0dc681cd215 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1410,7 +1410,7 @@ static int __init dynamic_debug_init(void)
 
for (; iter < __stop___dyndbg; iter++, i++, mod_sites++) {
 
-   if (strcmp(modname, iter->modname)) {
+   if (modname != iter->modname) {
mod_ct++;
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-- 
2.38.1

[Intel-gfx] [RFC PATCH 05/17] dyndbg: make ddebug_apply_class_bitmap more selective

ddebug_apply_class_bitmap() currently applies the class settings to
all modules, make it more selective, by adding query_module param.

The fn now calls ddebug_exec_queries(query, NULL), where NULL is
query_modname wildcard ("*" does the same).  So just expose the
parameter, and alter users to explicitly pass the wildcard value.

This allows its more selective use later; for propagating drm.debug
settings to dependent modules when/just-after they load.  Doing this
propagation with "*" is fine, but would match with all previously
loaded modules, creating more dynamic_debug.verbose=3 logging
activity.

No functional change.

Signed-off-by: Jim Cromie 
---

after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.

bash-5.2# lsmod
Module  Size  Used by
i915 3133440  0
drm_buddy  20480  1 i915
ttm90112  1 i915
i2c_algo_bit   16384  1 i915
video  61440  1 i915
wmi32768  1 video
drm_display_helper200704  1 i915
drm_kms_helper208896  2 drm_display_helper,i915
drm   606208  5 
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344  2 drm_display_helper,i915
---
 lib/dynamic_debug.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index fd5296dbb40f..5d609ff0d559 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -600,7 +600,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits)
+unsigned long *new_bits, unsigned long 
*old_bits,
+const char *query_modname)
 {
 #define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -617,7 +618,7 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
 test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
 
-   ct = ddebug_exec_queries(query, NULL);
+   ct = ddebug_exec_queries(query, query_modname);
matches += ct;
 
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
@@ -678,7 +679,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -688,7 +689,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -751,7 +752,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -764,7 +765,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);
*dcp->lvl = inrep;
break;
default:
-- 
2.38.1

[Intel-gfx] [RFC PATCH 02/17] test-dyndbg: show that DEBUG enables prdbgs at compiletime

Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined.  Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:

[   15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[   15.293189] dyndbg:  32 debug prints in module test_dynamic_debug
[   15.293715] test_dd: init start
[   15.293716] test_dd: doing categories
[   15.293716] test_dd: LOW msg
...
[   15.293733] test_dd: L6 msg
[   15.293733] test_dd: L7 msg
[   15.293733] test_dd: init done

NOTES:

As is observable above, define DEBUG enables all prdbgs, including
those in mod_init-fn, and more notably, the "class"d ones (callsites
with non-default class_ids).

This differs from the >control interface, which in order to properly
protect a client's class'd prdbgs, requires a "class FOO" in queries
to change them.  Note that the DEBUG is in the module source file.

This yields an occaisional surprise; the following disables all the
compile-time enabled plain prdbgs, but leaves the class'd ones
enabled.

 :#> modprobe test_dynamic_debug dyndbg==_

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index a01f0193a419..9d48689dc0ab 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -8,6 +8,8 @@
 
 #define pr_fmt(fmt) "test_dd: " fmt
 
+#define DEBUG
+
 #include 
 
 /* run tests by reading or writing sysfs node: do_prints */
-- 
2.38.1

[Intel-gfx] [RFC PATCH 03/17] dyndbg: fix readback value on LEVEL_NAMES interfaces

Since sysfs knobs should generally read-back what was just written
(unless theres a good reason to do otherwise), this result (using
test_dynamic_debug.ko) is suboptimal:

  echo L3 > p_level_names
  cat p_level_names
  4

Fix this with a -1 offset in LEVEL_NAMES readback.

NOTE:

Calling this a BUG is debatable, and the above is slightly inaccurate
wrt "read-back"; whats written is a LEVEL_NAME (a string).  Whats read
back is an integer, giving the 'edge' of the 'low-pass-filter'

The actual test looks like:

RTT: L4 -> p_level_names : 4 :: DOING: levels 4-1
[   17.509594] dyndbg: "L4" > p_level_names:0x4
[   17.510115] dyndbg: apply: 0x1f to: 0xf
[   17.510506] dyndbg: query 0: "class L4 +p" mod:*
[   17.510992] dyndbg: split into words: "class" "L4" "+p"
[   17.511521] dyndbg: op='+'
[   17.511811] dyndbg: flags=0x1
[   17.512127] dyndbg: *flagsp=0x1 *maskp=0x
[   17.512604] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=L4
[   17.513414] dyndbg: applied: func="" file="" module="" format="" lineno=0-0 
class=L4
[   17.514204] dyndbg: processed 1 queries, with 1 matches, 0 errs
[   17.514809] dyndbg: bit_4: 1 matches on class: L4 -> 0x1f
[   17.515355] dyndbg: p_level_names: changed bit-4: "L4" f->1f
[   17.515933] dyndbg: total matches: 1
crap [[ 5 != 4 ]]

This -1 adjustment just reports the edge consistently with its
input-mapping.

Fixes: b9400852c080 (dyndbg: add drm.debug style (drm/parameters/debug) bitmap 
support)

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 009f2ead09c1..48ca1387a409 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -794,6 +794,8 @@ int param_get_dyndbg_classes(char *buffer, const struct 
kernel_param *kp)
return scnprintf(buffer, PAGE_SIZE, "0x%lx\n", *dcp->bits);
 
case DD_CLASS_TYPE_LEVEL_NAMES:
+   return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl - 1);
+
case DD_CLASS_TYPE_LEVEL_NUM:
return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
default:
-- 
2.38.1

[Intel-gfx] [RFC PATCH 04/17] dyndbg: replace classmap list with a vector

Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_class_map drops list link.

struct ddebug_table drops the maps list-head, and gets: classes &
num_classes for the start-addy, and length. num_classes is placed to
improve struct packing.

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.

This isn't technically a bugfix, but IMO simplifies later fixes for
the chicken-egg post-init enablement regression.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  1 -
 lib/dynamic_debug.c   | 61 ++-
 2 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 41682278d2e8..bf47bcfad8e6 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -81,7 +81,6 @@ enum class_map_type {
 };
 
 struct ddebug_class_map {
-   struct list_head link;
struct module *mod;
const char *mod_name;   /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 48ca1387a409..fd5296dbb40f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, >maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -1109,9 +,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, >table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1195,30 +1198,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+

[Intel-gfx] [RFC PATCH 01/17] test-dyndbg: fixup CLASSMAP usage error

more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  Basically, I coded in an error, and
forgot to verify it and remove it.

RFC:

This patch fixes a bad usage of DEFINE_DYNDBG_CLASSMAP(), showing that
it is too error-prone.  As noted in test-dynamic-debug.c comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist) used in DEFINE_DYNAMIC_DEBUG_CLASSMAP(), on
__VA_ARGS__ a 2nd time.  Then, DRM would pass DRM_UT_* ; all the
categories, in order, and not their stringifications, which created
all the usage complications above.

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.38.1

[Intel-gfx] [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression

Hi everyone,

DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*

Regression is due to a chicken-egg problem loading modules; on
`modprobe i915`, drm is loaded 1st, and drm.debug is set.  When
drm_debug_enabled() tested __drm_debug at runtime, that just worked.

But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
post-load enablement of drm_dbg/dyndbg callsites (static-keys), via
dyndbg's callback on __drm_debug.  Since all drm-drivers need drm.ko,
it is loaded 1st, then drm.debug=X is applied, then drivers load, but
too late for drm_dbgs to be enabled.

STATUS

For all-loadable drm,i915,amdgpu configs, it almost works, but
propagating drm.debug to dependent modules doesnt actually apply,
though the motions are there.  This is not the problem I want to chase
here.

The more basic trouble is:

For builtin drm + helpers, things are broken pretty early; at the
beginning of dynamic_debug_init().  As the ddebug_sanity() commit-msg
describes in some detail, the records added by _USE fail to reference
the struct ddebug_class_map created and exported by _DEFINE, but get
separate addresses to "other" data that segv's when used as the
expected pointer. FWIW, the pointer val starts with "revi".

OVERVIEW

DECLARE_DYNDBG_CLASSMAP is broken: it is one-size-fits-all-poorly.
It muddles the distinction between a (single) definition, and multiple
references.  Something exported should suffice.

The core of this patchset splits it into:

DYNDBG_CLASSMAP_DEFINE  used once per subsystem to define each classmap
DYNDBG_CLASSMAP_USE declare dependence on a DEFINEd classmap

This makes the weird coordinated-changes-by-identical-classmaps
"feature" unnecessary; the DEFINE can export the var, and USE refers
to the exported var.

So this patchset adds another section: __dyndbg_class_refs.

It is like __dyndbg_classes; it is scanned under ddebug_add_module(),
and attached to each module's ddebug_table.  Once attached, it can be
used like classes to validate and apply class FOO >control queries.

It also maps the class user -> definer explicitly, so that when the
module is loaded, the section scan can find the kernel-param that is
wired to dyndbg's kparam-callback, and apply its state-var, forex:
__drm_debug to the just loaded helper/driver module.

Theres plenty to address Im sure.

Jim Cromie (17):
  test-dyndbg: fixup CLASSMAP usage error
  test-dyndbg: show that DEBUG enables prdbgs at compiletime
  dyndbg: fix readback value on LEVEL_NAMES interfaces
  dyndbg: replace classmap list with a vector
  dyndbg: make ddebug_apply_class_bitmap more selective
  dyndbg: dynamic_debug_init - use pointer inequality, not strcmp
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: reduce verbose/debug clutter
  dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with
DYNDBG_CLASSMAP(_DEFINE|_USE)
  dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
  dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args
  dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements
  drm_print: fix stale macro-name in comment
  dyndbg: unwrap __ddebug_add_module inner function NOTYET
  dyndbg: ddebug_sanity()
  dyndbg: mess-w-dep-class
  dyndbg: miss-on HACK

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  14 +-
 drivers/gpu/drm/display/drm_dp_helper.c |  14 +-
 drivers/gpu/drm/drm_crtc_helper.c   |  14 +-
 drivers/gpu/drm/drm_print.c |  22 +--
 drivers/gpu/drm/i915/i915_params.c  |  14 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  14 +-
 include/asm-generic/vmlinux.lds.h   |   3 +
 include/drm/drm_print.h |   6 +-
 include/linux/dynamic_debug.h   |  57 --
 include/linux/map.h |  54 ++
 kernel/module/main.c|   2 +
 lib/dynamic_debug.c | 240 +++-
 lib/test_dynamic_debug.c|  47 ++---
 13 files changed, 344 insertions(+), 157 deletions(-)
 create mode 100644 include/linux/map.h

-- 
2.38.1

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/pxp: Trigger the global teardown for before suspending

2022-12-05 Thread Juston Li

On Mon, 2022-11-28 at 16:48 -0800, Alan Previn wrote:
> A driver bug was recently discovered where the security firmware was
> receiving internal HW signals indicating that session key expirations
> had occurred. Architecturally, the firmware was expecting a response
> from the GuC to acknowledge the event with the firmware side.
> However the OS was in a suspended state and GuC had been reset.
> 
> Internal specifications actually required the driver to ensure
> that all active sessions be properly cleaned up in such cases where
> the system is suspended and the GuC potentially unable to respond.
> 
> This patch adds the global teardown code in i915's suspend_prepare
> code path.
> 
> Signed-off-by: Alan Previn 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 +-
> --
>  drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c  |  2 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  9 ++-
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.h |  5 ++
>  5 files changed, 64 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 5efe61f67546..659410ae1b89 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -198,6 +198,55 @@ static bool pxp_component_bound(struct intel_pxp
> *pxp)
> return bound;
>  }
>  
> +static int __pxp_global_teardown_locked(struct intel_pxp *pxp, bool
> terminate_for_cleanup)
> +{
> +   if (terminate_for_cleanup) {
> +   if (!pxp->arb_is_valid)
> +   return 0;
> +   /*
> +    * To ensure synchronous and coherent session
> teardown completion
> +    * in response to suspend or shutdown triggers, don't
> user a worker.
> +    */
> +   intel_pxp_mark_termination_in_progress(pxp);
> +   intel_pxp_terminate(pxp, false);
> +   } else {
> +   if (pxp->arb_is_valid)
> +   return 0;
> +   /*
> +    * If we are not in final termination, and the arb-
> session is currently
> +    * inactive, we are doing a reset and restart due to
> some runtime event.
> +    * Use the worker that was designed for this.
> +    */
> +   pxp_queue_termination(pxp);
> +   }
> +
> +   if (!wait_for_completion_timeout(>termination,
> msecs_to_jiffies(250)))
> +   return -ETIMEDOUT;
> +
> +   return 0;
> +}
> +
> +void intel_pxp_end(struct intel_pxp *pxp)
> +{
> +   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
> +   intel_wakeref_t wakeref;
> +
> +   if (!intel_pxp_is_enabled(pxp))
> +   return;
> +
> +   wakeref = intel_runtime_pm_get(>runtime_pm);
> +
> +   mutex_lock(>arb_mutex);
> +
> +   if (__pxp_global_teardown_locked(pxp, true))
> +   drm_dbg(&(pxp_to_gt(pxp))->i915->drm, "PXP end timed
> out\n");
> +
> +   mutex_unlock(>arb_mutex);
> +
> +   intel_pxp_fini_hw(pxp);
> +   intel_runtime_pm_put(>runtime_pm, wakeref);
> +}
> +
>  /*
>   * the arb session is restarted from the irq work when we receive
> the
>   * termination completion interrupt
> @@ -214,16 +263,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
>  
> mutex_lock(>arb_mutex);
>  
> -   if (pxp->arb_is_valid)
> -   goto unlock;
> -
> -   pxp_queue_termination(pxp);
> -
> -   if (!wait_for_completion_timeout(>termination,
> -   msecs_to_jiffies(250))) {
> -   ret = -ETIMEDOUT;
> +   ret = __pxp_global_teardown_locked(pxp, false);
> +   if (ret)
> goto unlock;
> -   }
>  
> /* make sure the compiler doesn't optimize the double access
> */
> barrier();
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index bbeb8ed8e211..a06b65850246 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -26,6 +26,7 @@ void intel_pxp_mark_termination_in_progress(struct
> intel_pxp *pxp);
>  void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> arb_session_id);
>  
>  int intel_pxp_start(struct intel_pxp *pxp);
> +void intel_pxp_end(struct intel_pxp *pxp);
>  
>  int intel_pxp_key_check(struct intel_pxp *pxp,
> struct drm_i915_gem_object *obj,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> index 6a7d4e2ee138..36af52c28e63 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -14,7 +14,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp
> *pxp)
> if (!intel_pxp_is_enabled(pxp))
> return;
>  
> -   pxp->arb_is_valid = false;
> +   intel_pxp_end(pxp);
>  
>

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for DRM - avoid regression in -rc, fix comment

2022-12-05 Thread jim . cromie

On Mon, Dec 5, 2022 at 9:18 AM Patchwork
 wrote:
>
> == Series Details ==
>
> Series: DRM - avoid regression in -rc, fix comment
> URL   : https://patchwork.freedesktop.org/series/111631/
> State : failure
>
> == Summary ==
>
> Error: patch 
> https://patchwork.freedesktop.org/api/1.0/series/111631/revisions/1/mbox/ not 
> applied

whats the right upstream to avoid  misapplies ?

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

2022-12-05 Thread Alan Previn

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readibility and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

This promotion comes with two noteworthy changes:

1. Exported pxp functions that are called by external subsystems
   (such as intel_pxp_enabled/active) will have to check implicitly
   if i915->pxp is valid as that structure will not be allocated
   for HW that doesn't support PXP.

2. Since GT is now considered a soft-dependency of PXP we are
   ensuring that GT init happens before PXP init and vice versa
   for fini. This causes a minor ordering change whereby we previously
   called intel_pxp_suspend after intel_uc_suspend but now is before
   i915_gem_suspend_late but the change is required for correct
   dependency flows. Additionally, this re-order change doesn't
   have any impact because at that point in either case, the top level
   entry to i915 won't observe any PXP events (since the GPU was
   quiesced during suspend_prepare). Also, any PXP event doesn't
   really matter when we disable the PXP HW (global GT irqs are
   already off anyway, so even if there was a bug that generated
   spurious events we wouldn't see it and we would just clean it
   up on resume which is okay since the default fallback action
   for PXP would be to keep the sessions off at this suspend stage).

Changes from prior revs:
   v8: - Remove pxp_to_gt macro (Daniele).
   - Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
 support GSC-FW on it. (Daniele).
   - Leave i915->pxp as NULL if we dont support PXP and in line
 with that, do additional validity check on i915->pxp for
 intel_pxp_is_supported/enabled/active (Daniele).
   - Remove unncessary include header from intel_gt_debugfs.c
 and check drm_minor i915->drm.primary (Daniele).
   - Other cosmetics / minor issues / more comments on suspend
 flow order change (Daniele).
   v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
 through out instead of local variable newpxp. (Rodrigo)
   - In the case intel_pxp_fini is called during driver unload but
 after i915 loading failed without pxp being allocated, check
 i915->pxp before referencing it. (Alan)
   v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
 because : [1] introduction of 'ctrl_gt' means we correct this
 for MTL's upcoming series now. [2] Also, this has little impact
 globally as its only used by PXP-internal callers at the moment.
   - Change intel_pxp_init/fini to take in i915 as its input to avoid
 ptr-to-ptr in init/fini calls.(Jani).
   - Remove the backpointer from pxp->i915 since we can use
 pxp->ctrl_gt->i915 if we need it. (Rodrigo).
   v5: - Switch from series to single patch (Rodrigo).
   - change function name from pxp_get_kcr_owner_gt to
 pxp_get_ctrl_gt.
   - Fix CI BAT failure by removing redundant call to intel_pxp_fini
 from driver-remove.
   - NOTE: remaining open still persists on using ptr-to-ptr
 and back-ptr.
   v4: - Instead of maintaining intel_pxp as an intel_gt structure member
 and creating a number of convoluted helpers that takes in i915 as
 input and redirects to the correct intel_gt or takes any intel_gt
 and internally replaces with the correct intel_gt, promote it to
 be a top-level i915 structure.
   v3: - Rename gt level

Re: [Intel-gfx] [PATCH] drm/i915/gen12: Apply recommended L3 hashing mask

On Mon, Dec 05, 2022 at 04:33:29PM -0300, Gustavo Sousa wrote:
> On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> > The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> > literal value of 0x2FC0100F for this register.  The register's hardware
> > default value is 0x2FC0108F, so this translates to just clearing one
> > bit.
> > 
> > Take this opportunity to also clean up the register definition and
> > re-write its existing bits/fields in the preferred notation.
> > 
> > Bspec: 31870
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 +
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 
> >  2 files changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 61a5c9a83b1b..f8eb807b56f9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -958,10 +958,11 @@
> >  #define   GEN7_DISABLE_SAMPLER_PREFETCH(1 << 30)
> >  
> >  #define GEN8_GARBCNTL  _MMIO(0xb004)
> > -#define   GEN9_GAPS_TSV_CREDIT_DISABLE (1 << 7)
> > -#define   GEN11_ARBITRATION_PRIO_ORDER_MASK(0x3f << 22)
> > -#define   GEN11_HASH_CTRL_EXCL_MASK(0x7f << 0)
> > -#define   GEN11_HASH_CTRL_EXCL_BIT0(1 << 0)
> > +#define   GEN11_ARBITRATION_PRIO_ORDER_MASKREG_GENMASK(27, 22)
> > +#define   GEN12_BUS_HASH_CTL_BIT_EXC   REG_BIT(7)
> > +#define   GEN9_GAPS_TSV_CREDIT_DISABLE REG_BIT(7)
> > +#define   GEN11_HASH_CTRL_EXCL_MASKREG_GENMASK(6, 0)
> > +#define   GEN11_HASH_CTRL_EXCL_BIT0
> > REG_FIELD_PREP(GEN11_HASH_CTRL_EXCL_MASK, 0x1)
> >  
> >  #define GEN9_SCRATCH_LNCF1 _MMIO(0xb008)
> >  #define   GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLE  REG_BIT(0)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 85822ebb0d64..2f13a92f77d3 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -2937,6 +2937,10 @@ add_render_compute_tuning_settings(struct 
> > drm_i915_private *i915,
> > if (INTEL_INFO(i915)->tuning_thread_rr_after_dep)
> > wa_mcr_masked_field_set(wal, GEN9_ROW_CHICKEN4, 
> > THREAD_EX_ARB_MODE,
> > THREAD_EX_ARB_MODE_RR_AFTER_DEP);
> > +
> > +   if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 
> > 50)) {
> > +   wa_write_clr(wal, GEN8_GARBCNTL, GEN12_BUS_HASH_CTL_BIT_EXC);
> > +   }
> 
> Removing the unnecessary braces as pointed out by dim checkpatch,
> 
> Reviewed-by: Gustavo Sousa 

Dropped the braces and applied to drm-intel-gt-next.  Thanks for the
review.


Matt

> 
> >  }
> >  
> >  /*
> > -- 
> > 2.38.1
> > 

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915/vrr: Be more careful with the bits in TRANS_VRR_CTL

On Fri, Dec 02, 2022 at 03:44:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> On mtl (at least) clearing the guardband bits in the same write
> as the enable bit gets cleared seems to cause an immediate FIFO
> underrun. Thus is seems that we need to first clear just the
> enable bit, then wait for the VRR live status to indicate the
> transcoder has exited VRR mode (this step is documented in Bspec
> as well), and finally we can clear out the rest of the TRANS_VRR_CTL
> for good measure.
> 
> I did this without any RMWs in case we want to toggle VRR on/off
> via DSB in the future, and as we know DSB can't read registers.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 40 +++-
>  1 file changed, 25 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 753e7b211708..5ff6aed9575e 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -161,31 +161,36 @@ intel_vrr_compute_config(struct intel_crtc_state 
> *crtc_state,
>   crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
>  }
>  
> -void intel_vrr_enable(struct intel_encoder *encoder,
> -   const struct intel_crtc_state *crtc_state)
> +static u32 trans_vrr_ctl(const struct intel_crtc_state *crtc_state)
>  {
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - u32 trans_vrr_ctl;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
>  
> - if (!crtc_state->vrr.enable)
> - return;
> -
> - if (DISPLAY_VER(dev_priv) >= 13)
> - trans_vrr_ctl = VRR_CTL_VRR_ENABLE |
> - VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
> + if (DISPLAY_VER(i915) >= 13)
> + return VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
>   XELPD_VRR_CTL_VRR_GUARDBAND(crtc_state->vrr.guardband);
>   else
> - trans_vrr_ctl = VRR_CTL_VRR_ENABLE |
> - VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
> + return VRR_CTL_IGN_MAX_SHIFT | VRR_CTL_FLIP_LINE_EN |
>   VRR_CTL_PIPELINE_FULL(crtc_state->vrr.pipeline_full) |
>   VRR_CTL_PIPELINE_FULL_OVERRIDE;
> +}
> +
> +void intel_vrr_enable(struct intel_encoder *encoder,
> +   const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> + if (!crtc_state->vrr.enable)
> + return;
>  
>   intel_de_write(dev_priv, TRANS_VRR_VMIN(cpu_transcoder), 
> crtc_state->vrr.vmin - 1);
>   intel_de_write(dev_priv, TRANS_VRR_VMAX(cpu_transcoder), 
> crtc_state->vrr.vmax - 1);
> - intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), trans_vrr_ctl);
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), 
> trans_vrr_ctl(crtc_state));
>   intel_de_write(dev_priv, TRANS_VRR_FLIPLINE(cpu_transcoder), 
> crtc_state->vrr.flipline - 1);
>   intel_de_write(dev_priv, TRANS_PUSH(cpu_transcoder), TRANS_PUSH_EN);
> +
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
> +VRR_CTL_VRR_ENABLE | trans_vrr_ctl(crtc_state));
>  }
>  
>  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
> @@ -222,8 +227,13 @@ void intel_vrr_disable(const struct intel_crtc_state 
> *old_crtc_state)
>   if (!old_crtc_state->vrr.enable)
>   return;
>  
> - intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), 0);
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
> +trans_vrr_ctl(old_crtc_state));
> + intel_de_wait_for_clear(dev_priv, TRANS_VRR_STATUS(cpu_transcoder),
> + VRR_STATUS_VRR_EN_LIVE, 1000);
> +
>   intel_de_write(dev_priv, TRANS_PUSH(cpu_transcoder), 0);
> + intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), 0);
>  }
>  
>  void intel_vrr_get_config(struct intel_crtc *crtc,
> -- 
> 2.37.4
>

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



On Mon, 2022-12-05 at 11:53 -0800, Ceraolo Spurio, Daniele wrote:
> 
Alan:[snip]
> >   
> > ext_data->flags |= I915_BO_PROTECTED;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 29e9e8d5b6fe..ed74d173a092 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -869,7 +869,7 @@ static struct i915_vma *eb_lookup_vma(struct 
> > i915_execbuffer *eb, u32 handle)
> >  */
> > if (i915_gem_context_uses_protected_content(eb->gem_context) &&
> > i915_gem_object_is_protected(obj)) {
> > -   err = intel_pxp_key_check(>gt->pxp, obj, true);
> > +   err = intel_pxp_key_check(vm->gt->i915->pxp, obj, true);
> 
> nit: eb->i915->pxp is one less pointer jump
> 
Alan: okay
Alan:[snip]
> 

> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > index dd53641f3637..7876f4c3d0f1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > @@ -99,7 +99,6 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
> > intel_sseu_debugfs_register(gt, root);
> >   
> > intel_uc_debugfs_register(>uc, root);
> > -   intel_pxp_debugfs_register(>pxp, root);
> 
> Nit: the pxp header inclusion can now be removed from this file.
> 
Alan: okay - will fix.
Alan:[snip]

> 
> > +
> > +bool intel_pxp_is_supported(const struct intel_pxp *pxp)
> > +{
> > +   return (IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp->ctrl_gt &&
> > +   INTEL_INFO(pxp->ctrl_gt->i915)->has_pxp && 
> > VDBOX_MASK(pxp->ctrl_gt));
> >   }
> >   
> >   bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> > @@ -130,7 +142,7 @@ static void pxp_init_full(struct intel_pxp *pxp)
> > if (ret)
> > goto out_context;
> >   
> > -   drm_info(>i915->drm, "Protected Xe Path (PXP) protected content 
> > support initialized\n");
> > +   drm_info(>i915->drm, "Protected Xe Path v7B (PXP) protected content 
> > support initialized\n");
> 
> This looks like a leftover debug addition
> 
Alan: ooops - yeah this was not supposed to be part of the change - my mistake.
Alan:[snip]

> > -void intel_pxp_init(struct intel_pxp *pxp)
> > +static struct intel_gt *pxp_get_ctrl_gt(struct drm_i915_private *i915)
> >   {
> > -   struct intel_gt *gt = pxp_to_gt(pxp);
> > +   struct intel_gt *gt = NULL;
> > +   int i = 0;
> > +
> > +   for_each_gt(gt, i915, i) {
> > +   /* There can be only one GT that supports PXP */
> > +   if (HAS_ENGINE(gt, GSC0))
> > +   return gt;
> > +   }
> 
> Note that the GSC engine will be disabled if the GSC FW is not 
> available, so in that case falling back to the root GT will be an error. 
> Maybe just change the below check to be:
> 
> /*
>   * The GSC engine can be turned off, but on platform that
>   * can have it we don't want to fall back to root GT.
>   * On older platforms we rely instead on the mei PXP module.
>   */
> if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && !915->media_gt)
> 
Alan: okay - makes sense. will do.
Alan:[snip]

> 
> >   
> > /* we rely on the mei PXP module */
> > -   if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> > -   return;
> > +   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> > +   return >gt0;
> > +
> > +   return NULL;
> > +}
> > +
> > +int intel_pxp_init(struct drm_i915_private *i915)
> > +{
> > +   i915->pxp = kzalloc(sizeof(*i915->pxp), GFP_KERNEL);
> > +   if (!i915->pxp)
> > +   return -ENOMEM;
> 
> A failure in intel_pxp_init is non-fatal, so we can exit here without 
> allocating i915->pxp and still complete driver load (although it's very 
> unlikely). This means that functions that can be called from outside the 
> PXP subsystem need to check if the pxp structure is allocated.
> 

Alan: Okay - this is a good catch - but in that case of kernel memory 
allocation failure, would it make sense to fail
the driver load instead? (considering its obviously a more serious system wide 
issue?).

> > +
> > +   i915->pxp->ctrl_gt = pxp_get_ctrl_gt(i915);
> > +   if (!i915->pxp->ctrl_gt)
> > +   return -ENODEV;
> 
> I would do a kfree here, so the only pointer that needs to be checked is 
> i915->pxp (i.e., guarantee that if i915->pxp is valid then 
> i915->pxp->ctrl_gt is also valid), otherwise pxp_to_gt could return NULL 
> when passing in a valid PXP pointer; although I think that all the calls 
> to pxp_to_gt are guarded via a pxp_is_enabled/supported check, it's not 
> intuitive for that function to return NULL (all other callers of that 
> type that we have do always return a valid pointer).
> 
Alan: okay sure - I guess this would also align well with a future where more 
and more subsystem structures are
allocated (as we try to reduce i915 build times by controlling the 
header-include-hierarchy) and therefore a null
subsystem

Re: [Intel-gfx] [PATCH 3/4] drm/i915/vrr: Reorder transcoder vs. vrr enable/disable

On Fri, Dec 02, 2022 at 03:44:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> On mtl it looks like disabling VRR after the transcoder has
> been disabled can cause the pipe/transcoder to get stuck
> when re-enabled in non-vrr mode. Reversing the order seems to
> help.
> 
> Bspec is extremely confused about the VRR enable/disable sequence
> anyway, and this now more closely matches the non-modeset VRR
> sequence, whereas the full modeset sequence still claims that
> the original order is fine. But since we eventually want to toggle
> VRR without a full modeset anyway this seems like the better order
> to follow.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 5f9a2410fc4c..69595cbb2766 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2726,10 +2726,10 @@ static void intel_ddi_post_disable(struct 
> intel_atomic_state *state,
>   if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
>   intel_crtc_vblank_off(old_crtc_state);
>  
> - intel_disable_transcoder(old_crtc_state);
> -
>   intel_vrr_disable(old_crtc_state);
>  
> + intel_disable_transcoder(old_crtc_state);
> +
>   intel_ddi_disable_transcoder_func(old_crtc_state);
>  
>   intel_dsc_disable(old_crtc_state);
> @@ -2946,13 +2946,13 @@ static void intel_enable_ddi(struct 
> intel_atomic_state *state,
>   if (!intel_crtc_is_bigjoiner_slave(crtc_state))
>   intel_ddi_enable_transcoder_func(encoder, crtc_state);
>  
> - intel_vrr_enable(encoder, crtc_state);
> -
>   /* Enable/Disable DP2.0 SDP split config before transcoder */
>   intel_audio_sdp_split_update(encoder, crtc_state);
>  
>   intel_enable_transcoder(crtc_state);
>  
> + intel_vrr_enable(encoder, crtc_state);
> +
>   intel_crtc_vblank_on(crtc_state);
>  
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> -- 
> 2.37.4
>

Re: [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+

On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We are miscalculating both the guardband value, and the resulting
> vblank exit length on adl+. This means that our start of vblank
> (double buffered register latch point) is incorrect, and we also
> think that it's not where it actually is (hence vblank evasion/etc.
> may not work properly). Fix up the calculations to match the real
> hardware behaviour (as reverse engineered by intel_display_poller).
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 6655dd2c1684..753e7b211708 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -78,10 +78,10 @@ static int intel_vrr_vblank_exit_length(const struct 
> intel_crtc_state *crtc_stat
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>  
> - /* The hw imposes the extra scanline before frame start */
>   if (DISPLAY_VER(i915) >= 13)
> - return crtc_state->vrr.guardband + crtc_state->framestart_delay 
> + 1;
> + return crtc_state->vrr.guardband;

This makes sense since with guardband, there is no framestart delay

>   else
> + /* The hw imposes the extra scanline before frame start */
>   return crtc_state->vrr.pipeline_full + 
> crtc_state->framestart_delay + 1;
>  }
>  
> @@ -151,7 +151,7 @@ intel_vrr_compute_config(struct intel_crtc_state 
> *crtc_state,
>* number of scan lines. Assuming 0 for no DSB.
>*/
>   crtc_state->vrr.guardband =
> - crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay;
> + crtc_state->vrr.vmin + 1 - adjusted_mode->crtc_vdisplay;

Why are we adding + 1 here? The bspec says guardband should be :
Guardband = Vmin - Vactive - Window2 where in our case Window2 = 0
If we need that + 1 to get this working, then perhaps we need to update
Bspec?

I kind of want to see if this is still breaking if we dont have that +
1?

Manasi

>   } else {
>   crtc_state->vrr.pipeline_full =
>   min(255, crtc_state->vrr.vmin - 
> adjusted_mode->crtc_vdisplay -
> -- 
> 2.37.4
>

Re: [Intel-gfx] [PATCH 1/4] drm/i915/vrr: Make registers latch in a consitent place on icl/tgl

On Fri, Dec 02, 2022 at 03:44:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Account for the framestart delay when calculating the "pipeline full"
> value for icl/tgl vrr. This puts the start of vblank (ie. where the
> double bufferd registers get latched) to a consistent place regardless
> of what framestart delay value is used. framestart delay does not
> change where start of vblank occurs in non-vrr mode and I can't see
> any reason why we'd want different behaviour in vrr mode.
> 
> Currently framestart delay is always set to 1, and the hardcoded 4
> scanlines in the code means we're currently delaying the start of
> vblank by three extra lines. And with framestart delay set to 4 we'd
> have no extra delay.
> 
> Signed-off-by: Ville Syrjälä 

So now basically if we want to delay the vblank, then we will need to
update framestart_delay to somethin other than 1.
Currently with framestart_delay = 1, there is no vblank delay, its just
vrr.vmin - vdisplay so the vblank start right after?

Is this the correct understanding?

Anyway, if this logic is validated to work then should be fine.
Basically this will only impact display <13, so as long as we dont
regress anything on TGL then we should be good.

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 7b1357e82b69..6655dd2c1684 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -153,18 +153,9 @@ intel_vrr_compute_config(struct intel_crtc_state 
> *crtc_state,
>   crtc_state->vrr.guardband =
>   crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay;
>   } else {
> - /*
> -  * FIXME: s/4/framestart_delay/ to get consistent
> -  * earliest/latest points for register latching regardless
> -  * of the framestart_delay used?
> -  *
> -  * FIXME: this really needs the extra scanline to provide 
> consistent
> -  * behaviour for all framestart_delay values. Otherwise with
> -  * framestart_delay==4 we will end up extending the min vblank 
> by
> -  * one extra line.
> -  */
>   crtc_state->vrr.pipeline_full =
> - min(255, crtc_state->vrr.vmin - 
> adjusted_mode->crtc_vdisplay - 4 - 1);
> + min(255, crtc_state->vrr.vmin - 
> adjusted_mode->crtc_vdisplay -
> + crtc_state->framestart_delay - 1);
>   }
>  
>   crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
> -- 
> 2.37.4
>

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

2022-12-05 Thread Christian König


Am 30.11.22 um 15:06 schrieb Daniel Vetter:

On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
 wrote:

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

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


+ Matt

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

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

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

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

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

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

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

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

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


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

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

Generally lock_timeout() is a design bug. It's either
lock_interruptible (or maybe lock_killable) or try_lock, but
lock_timeout is just duct-tape. I haven't dug in to figure out what
should be here, but it smells fishy.


Independent of this discussion could I get an rb for removing 
ttm_bo_wait() from i915?


Exactly hiding this timeout inside TTM is what always made me quite 
nervous here.


Regards,
Christian.


-Daniel

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

2022-12-05 Thread Ceraolo Spurio, Daniele

On 12/2/2022 3:28 PM, Alan Previn wrote:

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readibility and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

Changes from prior revs:
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring

References:
https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.ale...@intel.com
Signed-off-by: Alan Previn
---
.../drm/i915/display/skl_universal_plane.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 5 --
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 1 -
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 8 --
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 -
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c

Re: [Intel-gfx] [PATCH] drm/i915/gen12: Apply recommended L3 hashing mask

2022-12-05 Thread Gustavo Sousa

On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> literal value of 0x2FC0100F for this register.  The register's hardware
> default value is 0x2FC0108F, so this translates to just clearing one
> bit.
> 
> Take this opportunity to also clean up the register definition and
> re-write its existing bits/fields in the preferred notation.
> 
> Bspec: 31870
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 61a5c9a83b1b..f8eb807b56f9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -958,10 +958,11 @@
>  #define   GEN7_DISABLE_SAMPLER_PREFETCH  (1 << 30)
>  
>  #define GEN8_GARBCNTL_MMIO(0xb004)
> -#define   GEN9_GAPS_TSV_CREDIT_DISABLE   (1 << 7)
> -#define   GEN11_ARBITRATION_PRIO_ORDER_MASK  (0x3f << 22)
> -#define   GEN11_HASH_CTRL_EXCL_MASK  (0x7f << 0)
> -#define   GEN11_HASH_CTRL_EXCL_BIT0  (1 << 0)
> +#define   GEN11_ARBITRATION_PRIO_ORDER_MASK  REG_GENMASK(27, 22)
> +#define   GEN12_BUS_HASH_CTL_BIT_EXC REG_BIT(7)
> +#define   GEN9_GAPS_TSV_CREDIT_DISABLE   REG_BIT(7)
> +#define   GEN11_HASH_CTRL_EXCL_MASK  REG_GENMASK(6, 0)
> +#define   GEN11_HASH_CTRL_EXCL_BIT0  
> REG_FIELD_PREP(GEN11_HASH_CTRL_EXCL_MASK, 0x1)
>  
>  #define GEN9_SCRATCH_LNCF1   _MMIO(0xb008)
>  #define   GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLEREG_BIT(0)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 85822ebb0d64..2f13a92f77d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2937,6 +2937,10 @@ add_render_compute_tuning_settings(struct 
> drm_i915_private *i915,
>   if (INTEL_INFO(i915)->tuning_thread_rr_after_dep)
>   wa_mcr_masked_field_set(wal, GEN9_ROW_CHICKEN4, 
> THREAD_EX_ARB_MODE,
>   THREAD_EX_ARB_MODE_RR_AFTER_DEP);
> +
> + if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 
> 50)) {
> + wa_write_clr(wal, GEN8_GARBCNTL, GEN12_BUS_HASH_CTL_BIT_EXC);
> + }

Removing the unnecessary braces as pointed out by dim checkpatch,

Reviewed-by: Gustavo Sousa 

>  }
>  
>  /*
> -- 
> 2.38.1
>

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hwmon: Silence "mailbox access failed" warning in snb_pcode_read (rev2)

== Series Details ==

Series: drm/i915/hwmon: Silence "mailbox access failed" warning in 
snb_pcode_read (rev2)
URL   : https://patchwork.freedesktop.org/series/111599/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12467_full -> Patchwork_111599v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (14 -> 14)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  
 Suppressed 

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

  * igt@kms_content_protection@legacy:
- {shard-tglu-9}: NOTRUN -> [SKIP][2] +19 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-tglu-9/igt@kms_content_protect...@legacy.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@drm_fdinfo@virtual-busy-idle:
- shard-skl:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#5608]) +1 
similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-skl3/igt@drm_fdi...@virtual-busy-idle.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#6268])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12467/shard-tglb1/igt@gem_ctx_e...@basic-nohangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-tglb5/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-tglb: NOTRUN -> [FAIL][7] ([i915#6117])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-tglb6/igt@gem_exec_balan...@parallel-ordering.html
- shard-iclb: NOTRUN -> [SKIP][8] ([i915#4525])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-iclb6/igt@gem_exec_balan...@parallel-ordering.html

  * igt@gem_exec_endless@dispatch@vcs0:
- shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#3778])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12467/shard-tglb2/igt@gem_exec_endless@dispa...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-tglb5/igt@gem_exec_endless@dispa...@vcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][11] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-apl8/igt@gem_exec_f...@basic-deadline.html
- shard-skl:  NOTRUN -> [FAIL][12] ([i915#2846])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-skl7/igt@gem_exec_f...@basic-deadline.html

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

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

  * igt@gem_lmem_swapping@verify:
- shard-glk:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-glk8/igt@gem_lmem_swapp...@verify.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][17] ([i915#2658])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/shard-skl7/igt@gem_pr...@exhaustion.html

  * igt@gem_spin_batch@legacy@bsd1:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#2898])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12467/shard-skl4/igt@gem_spin_batch@leg...@bsd1.html
   [19]:

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

2022-12-05 Thread Ceraolo Spurio, Daniele





On 12/5/2022 11:04 AM, Teres Alexis, Alan Previn wrote:


On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:

On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:




Alan: [snip]


@@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
  {
struct drm_i915_private *i915 = to_i915(dev);
  
+	intel_pxp_suspend_prepare(i915->pxp);

+
/*
 * NB intel_display_suspend() may issue new requests after we've
 * ostensibly marked the GPU as ready-to-sleep here. We need to
@@ -1248,6 +1258,8 @@ static int i915_drm_suspend_late(struct drm_device *dev, 
bool hibernation)
  
  	disable_rpm_wakeref_asserts(rpm);
  
+	intel_pxp_suspend(dev_priv->pxp);

+

Before this patch the pxp_suspend was done right after uc_suspend.
Right now, the uc_suspend will happen couple lines below.




Okay - I see this 2nd level flow change but this has no functional change. I 
have gone through the codes and whether
intel_pxp_suspend came in after i915_gem_suspend_late or the middle of 
gt_suspend_late (after us_suspend), it does not
make any difference. intel_pxp_suspend only disables display-control-events on 
KCR register and disables CRYPTO-IRQ
registers. GuC or HuC is only ever doing any PXP related work if it receives 
workloads via exec-buf (kernel side PXP
workload subsmission is limited to arb-session creation today OR, in future, 
teardown-flows at suspend_prepare - this is
upcoming change in flight). That said, since the GT is already quiesced in 
suspend_prepare, therefore HuC or GuC should
be not doing anything inside of i915_suspend_late whether its before 
i915_gem_suspend_late or before uc_suspend.



If this is okay, why can't we move already the pxp_suspend to the
suspend function and need to keep this in the suspend late?


We can - but i dont see any difference in doing so functionally speaking - i do 
however prefer minimizing the code flow
changes to


Or we don't change the flow at all, or we already fix the unbalanced
thing.
I believe the first option is better and changing the flow in a
separated patch is better.


Actually, I rather fix the symmetry at the this level: As part of this feature 
to promote PXP - Gt becomes a dependency
of PXP. So at init, we ensure GT is init first and then we init PXP. Therefore 
we should do the opposite for fini -
ensure PXP fini is done first and the cleanup the GT. That why the move above. 
But as the global i915 level we are
keeping it within suspend_late - after everything was quiesced in 
suspend_prepare.


Specially because I don't understand if huc has any dependency on
the pxp. Maybe that was the original reason why that function end up there
at first place.

I believe Daniele is the right one to let us know that.


I spoke to Daniele and he confirmed what i explained above.


Yup, can confirm. Might be worth adding a note to the commit message 
that GT is now considered a soft-dependency of PXP and that the 
suspend_late function calls have been re-ordered accordingly, but that 
this re-order doesn't have any impact apart from code flow because at 
that point in time there can't be any PXP events, so it doesn't really 
matter when we disable the PXP HW (global irqs are off anyway, so even 
if there was a bug that generated spurious event we wouldn't see it and 
we would just clean it up on resume).


I also agree that moving calls between different suspend stages should 
be left to a separate patch.


Daniele


i915_gem_suspend_late(dev_priv);

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



On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
> On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> > 
> > 
> > 

Alan: [snip]

> > @@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
> >  {
> > struct drm_i915_private *i915 = to_i915(dev);
> >  
> > +   intel_pxp_suspend_prepare(i915->pxp);
> > +
> > /*
> >  * NB intel_display_suspend() may issue new requests after we've
> >  * ostensibly marked the GPU as ready-to-sleep here. We need to
> > @@ -1248,6 +1258,8 @@ static int i915_drm_suspend_late(struct drm_device 
> > *dev, bool hibernation)
> >  
> > disable_rpm_wakeref_asserts(rpm);
> >  
> > +   intel_pxp_suspend(dev_priv->pxp);
> > +
> 
> Before this patch the pxp_suspend was done right after uc_suspend.
> Right now, the uc_suspend will happen couple lines below.
> 
> 
> 
Okay - I see this 2nd level flow change but this has no functional change. I 
have gone through the codes and whether
intel_pxp_suspend came in after i915_gem_suspend_late or the middle of 
gt_suspend_late (after us_suspend), it does not
make any difference. intel_pxp_suspend only disables display-control-events on 
KCR register and disables CRYPTO-IRQ
registers. GuC or HuC is only ever doing any PXP related work if it receives 
workloads via exec-buf (kernel side PXP
workload subsmission is limited to arb-session creation today OR, in future, 
teardown-flows at suspend_prepare - this is
upcoming change in flight). That said, since the GT is already quiesced in 
suspend_prepare, therefore HuC or GuC should
be not doing anything inside of i915_suspend_late whether its before 
i915_gem_suspend_late or before uc_suspend.


> If this is okay, why can't we move already the pxp_suspend to the
> suspend function and need to keep this in the suspend late?
> 
We can - but i dont see any difference in doing so functionally speaking - i do 
however prefer minimizing the code flow
changes to 

> Or we don't change the flow at all, or we already fix the unbalanced
> thing.
> I believe the first option is better and changing the flow in a
> separated patch is better.
> 
Actually, I rather fix the symmetry at the this level: As part of this feature 
to promote PXP - Gt becomes a dependency
of PXP. So at init, we ensure GT is init first and then we init PXP. Therefore 
we should do the opposite for fini -
ensure PXP fini is done first and the cleanup the GT. That why the move above. 
But as the global i915 level we are
keeping it within suspend_late - after everything was quiesced in 
suspend_prepare.

> Specially because I don't understand if huc has any dependency on
> the pxp. Maybe that was the original reason why that function end up there
> at first place.
> 
> I believe Daniele is the right one to let us know that.
> 
I spoke to Daniele and he confirmed what i explained above.

> > i915_gem_suspend_late(dev_priv);
> >  
> >

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

2022-12-05 Thread Michal Wajdeczko




On 05.12.2022 14:16, Tvrtko Ursulin wrote:
> 
> On 02/12/2022 20:14, John Harrison wrote:
> 
 and while for dbg level messages it doesn't matter, I assume we should
 be consistent for err/warn/info messages (as those will eventually show
 up to the end user) so let maintainers decide here what is
 expectation here
>>>
>>> Could we have some examples pasted here, of the end result of this
>>> series, for all message "categories" (origins, macros, whatever)?
>>
>> GT initialisation:
>> gt_err(gt, "Failed to allocate scratch page\n");
>> i915 :00:02.0: [drm] GT0: Failed to allocate scratch page
>>
>> G2H notification handler:
>> guc_err(guc, "notification: Invalid length %u for deregister done\n",
>> len);
>> i915 :00:02.0: [drm] GT0: GuC notification: Invalid length 0 for
>> deregister done

please note that today this message is coded as:

drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
-> i915 :00:02.0: [drm] Invalid length %u

which makes this rather an example of meaningless log

> 
> I'm not liking the inconsistency between gt_err and guc_err where with
> latter callers either need to start the message with lower case because
> of the unstructured "GuC " prefix added. Which then reads bad if callers
> do guc_err(guc, "Error X happend").
> 
> Looks like Michal was pointing out the same thing, AFAIU at least when
> re-reading the thread now.
> 
> Why wouldn't this work:
> 
> guc_err(guc, "Invalid length %u for deregister done notification\n", len);
> i915 :00:02.0: [drm] GT0: GuC: Invalid length 0 for deregister done
> notification

+1

> 
> Or if the use case for adding custom prefixes is strong then maybe
> consider:
> 
> guc_err(guc, "notification", "Invalid length 0 for deregister done");
> i915 :00:02.0: [drm] GT0: GuC notification: Invalid length 0 for
> deregister done
> 
> guc_err(guc, "", "Error X");
> i915 :00:02.0: [drm] GT0: GuC: Error X

-1

this will make logging macros too different from others (unless we
hide/use prefixes inside macros only, but I'm not sure there is any ROI)

> 
>> CTB initialisation:
>> ct_probe_error(ct, "Failed to control/%s CTB (%pe)\n",
>> str_enable_disable(enable), ERR_PTR(err));
>> i915 :00:02.0: [drm] GT0: GuC CT Failed to control/enable CTB
>> (EINVAL)
> 
> Okay same as above.
> 
>> Random meaningless (to me) message that is apparently a display thing:
>> drm_dbg_kms(_priv->drm, "disabling %s\n", pll->info->name);
>> i915 :00:02.0: [drm:intel_disable_shared_dpll [i915]] disabling
>> PORT PLL B
> 
> Plan is to not touch outside gt/.
> 
>> I'm sure you can extrapolate to all other forms of dbg, notice, info,
>> etc. without me having to manually type each one out, given that they
>> are all identical.
>>
>> Personally, I think the above should be just:
>> gt_err(gt, "Failed to allocate scratch page\n");
>> i915 :00:02.0: [drm] GT0: Failed to allocate scratch page
>>
>> gt_err(guc_to_gt(guc), "G2H: Invalid length for deregister done:
>> %u\n", len);
>> i915 :00:02.0: [drm] GT0: G2H: Invalid length for deregister done: 0

that's probably should be:

"Invalid length for G2H deregister done: %u\n

and it will still just look fine if we auto append the 'GuC' prefix:

i915 :00:02.0: [drm] GT0: GuC: Invalid length for G2H deregister

>>
>> gt_probe_error(ct_to_gt(ct), "Failed to %s CT %d buffer (%pe)\n",
>> str_enable_disable(enable), send ? "SEND" : "RECV", ERR_PTR(err));
>> i915 :00:02.0: [drm] GT0: Failed to enable CT SEND buffer (EINVAL)

having "GuC/CT" prefix here will also look fine:

i915 :00:02.0: [drm] GT0: GuC: Failed to enable CT SEND buffer
i915 :00:02.0: [drm] GT0: GuC: CT: Failed to enable SEND buffer
i915 :00:02.0: [drm] GT0: CT: Failed to enable SEND buffer

> 
> We could but it seems we agreed some weeks ago to consolidate the
> existing CT_ERROR macros and such in this exercise. At least no
> objections were raised to that plan.
> 
> If now we want to go back on that, and if you want to have
> guc_to_gt(guc) in all gt/uc/ call sites that's fine by me, but please
> get some acks and consensus from people who work in that area. And under
> that option someone would also need to convert the CT code to new macros.

while the main goal of this series was to have GT# appended to the log
messages but we also wanted to simplify the use of the logging macros by
passing the component pointer directly (with extra *bonus* that allows
to auto append component specific prefix, if any, like CT macros do)

IMHO adding guc_xxx() macros with "GuC:" prefix will do the trick and
since many of the existing GuC related logs are already broken or
incomplete, we might fix them accordingly.

In other words in addition to gt_xxx() I still want additional guc_xxx()
macros (as it will allow us to fix related messages) and ct_xxx() macros
(as we already have CT_xxx so no need to change anything)

Michal

> 
> Regards,
> 
> Tvrtko
> 
>> drm_dbg_kms(_priv->drm, "disabling %s\n",

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Check full IP version when applying hw steering semaphore

2022-12-05 Thread Tvrtko Ursulin




On 05/12/2022 16:27, Matt Roper wrote:

On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:


On 02/12/2022 22:49, Rodrigo Vivi wrote:

On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:

When determining whether the platform has a hardware-level steering
semaphore (i.e., MTL and beyond), we need to use GRAPHICS_VER_FULL() to
compare the full version rather than just the major version number
returned by GRAPHICS_VER().

Reported-by: kernel test robot 
Fixes: 3100240bf846 ("drm/i915/mtl: Add hardware-level lock for steering")
Cc: Balasubramani Vivekanandan 
Signed-off-by: Matt Roper 


Reviewed-by: Rodrigo Vivi 

---
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 087e4ac5b68d..41a237509dcf 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -367,7 +367,7 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long 
*flags)
 * driver threads, but also with hardware/firmware agents.  A dedicated
 * locking register is used.
 */
-   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))


Ouch, tricky class of bugs... Anyone has an idea how to maybe coerce the 
compiler into spotting them for us, cheaply?


I believe clang can already notice these problems with
Wtautological-constant-out-of-range-compare (which is how the kernel
test robot finds them):

>> drivers/gpu/drm/i915/gt/intel_gt_mcr.c:370:29: warning: result of 
comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
+is always false [-Wtautological-constant-out-of-range-compare]
   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
   ~~ ^  ~~
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c:410:29: warning: result of 
comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
+is always false [-Wtautological-constant-out-of-range-compare]
   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
   ~~ ^  ~~
   2 warnings generated.


Hah.. curios how IS_ENABLED then works on clang builds. Maybe it has 
some special handling for that flavour of "always false".



Unfortunately gcc doesn't seem to have anything equivalent as far as I
can see.



This one is undefined behaviour I think so not good:

-#define IP_VER(ver, rel)   ((ver) << 8 | (rel))
+typedef void * i915_full_ver_t;
+
+#define IP_VER(ver, rel) (i915_full_ver_t)(unsigned long)((ver) << 8 | (rel))


Hmm, so by casting it into a pointer, you're hoping to trigger a
"comparison of pointer and integer without cast" warning on misuse?
That's a good idea, but as you noted, the C99 spec says comparison of
pointers is only guaranteed to work if both are pointers into the same
structure/array, otherwise the results are technically undefined.


"error: comparison between pointer and integer" - it works, but yes it 
is undefined. Only == and != are allowed on random void * pointers.


Since you say clang builds report the problem we are good I guess.

Regards,

Tvrtko

Re: [Intel-gfx] No Mesa DRI Intel 945G in Debian Bookworm since Feb. 2022 package change

2022-12-05 Thread Emma Anholt

Debian packaging apparently just decided not to include i915g in the
transition?  Not our fault.

On Mon, Dec 5, 2022 at 9:59 AM Rodrigo Vivi  wrote:

> Cc: mesa-dev ml
>
> On Sat, Dec 03, 2022 at 03:00:44AM -0500, Felix Miata wrote:
> > From libgl1-mesa-dri:amd64 changelog:
> > mesa (22.0.0~rc2-1) experimental; urgency=medium
> >
> >   * New upstream release candidate.
> >   * path_max.diff: Refreshed.
> >   * rules: Drop classic drivers (r100, r200, nouveau_vieux, i915, i965).
> >
> >  -- Timo Aaltonen   Thu, 17 Feb 2022
> 22:04:03 +0200
> >
> > # xdriinfo
> > libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so:
> cannot open shared object file: No such file or directory (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
> > libGL error: failed to load driver: i915
> > Screen 0: swrast
> >
> > # pinxi -GSaz --vs --zl --hostname
> > pinxi 3.3.23-05 (2022-11-07)
> > System:
> >   Host: gx62b Kernel: 5.19.0-2-amd64 arch: x86_64 bits: 64 compiler: gcc
> > v: 11.3.0 parameters: root=LABEL= ipv6.disable=1
> net.ifnames=0
> > biosdevname=0 plymouth.enable=0 noresume mitigations=auto
> consoleblank=0
> >   Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v:
> 3.0
> > vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux bookworm/sid
> > Graphics:
> >   Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915
> > v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports:
> > active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772
> > class-ID: 0300
> >   Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
> > dri: swrast gpu: i915 display-ID: :0 screens: 1
> >   Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm
> (30.00x10.00")
> > s-diag: 803mm (31.62")
> >   Monitor-1: DVI-D-1 pos: primary,left model: NEC EA243WM serial:
> 
> > built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
> > size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10
> modes:
> > max: 1920x1200 min: 640x480
> >   Monitor-2: VGA-1 pos: right model: Dell P2213 serial:  built:
> 2012
> > res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm
> (18.62x11.65")
> > diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
> >   API: OpenGL v: 4.5 Mesa 22.2.4 renderer: llvmpipe (LLVM 15.0.5 128
> bits)
> > direct render: Yes
> >
> > In Bullseye:
> > ...
> >   API: OpenGL v: 1.4 Mesa 20.3.5 renderer: Mesa DRI Intel 945G
> > direct render: Yes
> > # xdriinfo
> > Screen 0: i915
> >
> > What are Bookworm users supposed to do to make Mesa DRI work correctly
> > now that i915_dri.so is missing? Did it get moved to some other .deb
> > I can't ID? I don't think Crocus is supposed to work on Gen3. At least,
> > export MESA_LOADER_DRIVER_OVERRIDE=crocus in
> /etc/X11/Xsession.d/10-crocus.sh
> > doesn't help.
> >
> > In openSUSE Tumbleweed in 22.2.4 i915 is still included in its Mesa-dri
> > package, and Mesa DRI Intel 945G is working as expected.
> > --
> > Evolution as taught in public schools is, like religion,
> >   based on faith, not based on science.
> >
> >  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> >
> > Felix Miata
>

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

2022-12-05 Thread Tvrtko Ursulin




On 05/12/2022 15:52, Matt Roper wrote:

On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:


On 28/11/2022 23:30, Matt Roper wrote:

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

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

v2:
   - Extend hardware semaphore timeout and add a taint for CI if it ever
 happens (this would imply misbehaving hardware/firmware).  (Mika)
   - Add "MTL_" prefix to new steering semaphore register.  (Mika)

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

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index aa070ae57f11..087e4ac5b68d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -347,10 +347,9 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
* @flags: storage to save IRQ flags to
*
* Performs locking to protect the steering for the duration of an MCR
- * operation.  Depending on the platform, this may be a software lock
- * (gt->mcr_lock) or a hardware lock (i.e., a register that synchronizes
- * access not only for the driver, but also for external hardware and
- * firmware agents).
+ * operation.  On MTL and beyond, a hardware lock will also be taken to
+ * serialize access not only for the driver, but also for external hardware and
+ * firmware agents.
*
* Context: Takes gt->mcr_lock.  uncore->lock should *not* be held when this
*  function is called, although it may be acquired after this
@@ -359,12 +358,40 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
   void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
   {
unsigned long __flags;
+   int err = 0;
lockdep_assert_not_held(>uncore->lock);
+   /*
+* Starting with MTL, we need to coordinate not only with other
+* driver threads, but also with hardware/firmware agents.  A dedicated
+* locking register is used.
+*/
+   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   err = wait_for(intel_uncore_read_fw(gt->uncore,
+   MTL_STEER_SEMAPHORE) == 
0x1, 100);
+


If two i915 threads enter here what happens? (Given hw locking is done
before the spinlock.)


The second thread will see a '0' when it reads the register, indicating
that something else (sw, fw, or hw) already has it locked.  As soon as
the first thread drops the lock, the next read will return '1' and allow
the second thread to proceed.


I was worried if there was a concept of request originator, but this 
then sounds good.


Regards,

Tvrtko


+   /*
+* Even on platforms with a hardware lock, we'll continue to grab
+* a software spinlock too for lockdep purposes.  If the hardware lock
+* was already acquired, there should never be contention on the
+* software lock.
+*/
spin_lock_irqsave(>mcr_lock, __flags);
*flags = __flags;
+
+   /*
+* In theory we should never fail to acquire the HW semaphore; this
+* would indicate some hardware/firmware is misbehaving and not
+* releasing it properly.
+*/
+   if (err == -ETIMEDOUT) {
+   drm_err_ratelimited(>i915->drm,
+   "GT%u hardware MCR steering semaphore timed 
out",
+   gt->info.id);
+   add_taint_for_CI(gt->i915, TAINT_WARN);  /* CI is now 
unreliable */
+   }
   }
   /**
@@ -379,6 +406,9 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long 
*flags)
   void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags)
   {
spin_unlock_irqrestore(>mcr_lock, flags);
+
+   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 0x1);
   }
   /**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 784152548472..1618d46cb8c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -67,6 +67,7 @@
   #define GMD_ID_MEDIA _MMIO(MTL_MEDIA_GSI_BASE +

Re: [Intel-gfx] No Mesa DRI Intel 945G in Debian Bookworm since Feb. 2022 package change

2022-12-05 Thread Rodrigo Vivi

Cc: mesa-dev ml

On Sat, Dec 03, 2022 at 03:00:44AM -0500, Felix Miata wrote:
> From libgl1-mesa-dri:amd64 changelog:
> mesa (22.0.0~rc2-1) experimental; urgency=medium
> 
>   * New upstream release candidate.
>   * path_max.diff: Refreshed.
>   * rules: Drop classic drivers (r100, r200, nouveau_vieux, i915, i965).
> 
>  -- Timo Aaltonen   Thu, 17 Feb 2022 22:04:03 
> +0200
> 
> # xdriinfo
> libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so: 
> cannot open shared object file: No such file or directory (search paths 
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
> libGL error: failed to load driver: i915
> Screen 0: swrast
> 
> # pinxi -GSaz --vs --zl --hostname
> pinxi 3.3.23-05 (2022-11-07)
> System:
>   Host: gx62b Kernel: 5.19.0-2-amd64 arch: x86_64 bits: 64 compiler: gcc
> v: 11.3.0 parameters: root=LABEL= ipv6.disable=1 net.ifnames=0
> biosdevname=0 plymouth.enable=0 noresume mitigations=auto consoleblank=0
>   Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
> vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux bookworm/sid
> Graphics:
>   Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915
> v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports:
> active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772
> class-ID: 0300
>   Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
> dri: swrast gpu: i915 display-ID: :0 screens: 1
>   Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
> s-diag: 803mm (31.62")
>   Monitor-1: DVI-D-1 pos: primary,left model: NEC EA243WM serial: 
> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
> size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
> max: 1920x1200 min: 640x480
>   Monitor-2: VGA-1 pos: right model: Dell P2213 serial:  built: 2012
> res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65")
> diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
>   API: OpenGL v: 4.5 Mesa 22.2.4 renderer: llvmpipe (LLVM 15.0.5 128 bits)
> direct render: Yes
> 
> In Bullseye:
> ...
>   API: OpenGL v: 1.4 Mesa 20.3.5 renderer: Mesa DRI Intel 945G
> direct render: Yes
> # xdriinfo
> Screen 0: i915
> 
> What are Bookworm users supposed to do to make Mesa DRI work correctly
> now that i915_dri.so is missing? Did it get moved to some other .deb
> I can't ID? I don't think Crocus is supposed to work on Gen3. At least,
> export MESA_LOADER_DRIVER_OVERRIDE=crocus in /etc/X11/Xsession.d/10-crocus.sh
> doesn't help.
> 
> In openSUSE Tumbleweed in 22.2.4 i915 is still included in its Mesa-dri
> package, and Mesa DRI Intel 945G is working as expected.
> -- 
> Evolution as taught in public schools is, like religion,
>   based on faith, not based on science.
> 
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> 
> Felix Miata

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

2022-12-05 Thread Rodrigo Vivi

On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected
> contexts and protected buffers can be subscribed by process
> workloads on any tile. However, depending on the platform,
> only one of the tiles is used for control events pertaining to PXP
> operation (such as creating the arbitration session and session
> tear-down).
> 
> PXP as a global feature is accessible via batch buffer instructions
> on any engine/tile and the coherency across tiles is handled implicitly
> by the HW. In fact, for the foreseeable future, we are expecting this
> single-control-tile for the PXP subsystem.
> 
> In MTL, it's the standalone media tile (not the root tile) because
> it contains the VDBOX and KCR engine (among the assets PXP relies on
> for those events).
> 
> Looking at the current code design, each tile is represented by the
> intel_gt structure while the intel_pxp structure currently hangs off the
> intel_gt structure.
> 
> Keeping the intel_pxp structure within the intel_gt structure makes some
> internal functionalities more straight forward but adds code complexity to
> code readibility and maintainibility to many external-to-pxp subsystems
> which may need to pick the correct intel_gt structure. An example of this
> would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
> which should be viewed as a global level inquiry, not a per-gt inquiry.
> 
> That said, this series promotes the intel_pxp structure into the
> drm_i915_private structure making it a top-level subsystem and the PXP
> subsystem will select the control gt internally and keep a pointer to
> it for internal reference.
> 
> Changes from prior revs:
>v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
>  through out instead of local variable newpxp. (Rodrigo)
>- In the case intel_pxp_fini is called during driver unload but
>  after i915 loading failed without pxp being allocated, check
>  i915->pxp before referencing it. (Alan)
>v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
>  because : [1] introduction of 'ctrl_gt' means we correct this
>  for MTL's upcoming series now. [2] Also, this has little impact
>  globally as its only used by PXP-internal callers at the moment.
>- Change intel_pxp_init/fini to take in i915 as its input to avoid
>  ptr-to-ptr in init/fini calls.(Jani).
>- Remove the backpointer from pxp->i915 since we can use
>  pxp->ctrl_gt->i915 if we need it. (Rodrigo).
>v5: - Switch from series to single patch (Rodrigo).
>- change function name from pxp_get_kcr_owner_gt to
>  pxp_get_ctrl_gt.
>- Fix CI BAT failure by removing redundant call to intel_pxp_fini
>  from driver-remove.
>- NOTE: remaining open still persists on using ptr-to-ptr
>  and back-ptr.
>v4: - Instead of maintaining intel_pxp as an intel_gt structure member
>  and creating a number of convoluted helpers that takes in i915 as
>  input and redirects to the correct intel_gt or takes any intel_gt
>  and internally replaces with the correct intel_gt, promote it to
>  be a top-level i915 structure.
>v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
>  supported/ active_on_gt" (Daniele)
>- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
>  supported as the new intel_pxp_is_supported_on_gt to check for
>  PXP feature support vs the tee support for huc authentication.
>  Fix pxp-debugfs-registration to use only the former to decide
>  support. (Daniele)
>- Couple minor optimizations.
>v2: - Avoid introduction of new device info or gt variables and use
>  existing checks / macros to differentiate the correct GT->PXP
>  control ownership (Daniele Ceraolo Spurio)
>- Don't reuse the updated global-checkers for per-GT callers (such
>  as other files within PXP) to avoid unnecessary GT-reparsing,
>  expose a replacement helper like the prior ones. (Daniele).
>v1: - Add one more patch to the series for the intel_pxp suspend/resume
>  for similar refactoring
> 
> References: 
> https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.ale...@intel.com
> Signed-off-by: Alan Previn 
> ---
>  .../drm/i915/display/skl_universal_plane.c|  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  6 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c|  2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c|  5 --
>  drivers/gpu/drm/i915/gt/intel_gt_debugfs.c|  1 -
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |  8 --
>

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

Below failure is not related to PXP (PXP is not supported on SKL).
Additionally, towards the end of dmesg seems like gt got wedged when attempting 
a completely different igt selftest which bailed on a timeout causing locking 
issues.
...alan

On Sat, 2022-12-03 at 10:18 +, Patchwork wrote:
Patch Details
Series: series starting with [v8,1/1] drm/i915/pxp: Promote pxp subsystem to 
top-level of i915
URL:https://patchwork.freedesktop.org/series/111598/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111598v1/index.html
CI Bug Log - changes from CI_DRM_12463_full -> Patchwork_111598v1_full
Summary

FAILURE

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

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

Participating hosts (14 -> 14)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180:
 *   shard-skl: 
PASS
 -> 
INCOMPLETE


Suppressed

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

  *   igt@kms_concurrent@pipe-c:
 *   {shard-tglu-9}: NOTRUN -> 
SKIP
 +44 similar issues

Known issues

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

IGT changes
Issues hit

  *   igt@gem_eio@in-flight-suspend:

 *   shard-apl: 
PASS
 -> 
DMESG-WARN
 (i915#180)
  *   igt@gem_exec_balancer@parallel-contexts:

 *   shard-iclb: 
PASS
 -> 
SKIP
 (i915#4525)
  *   igt@gem_exec_endless@dispatch@vcs0:

 *   shard-iclb: 
PASS
 -> 
TIMEOUT
 (i915#3778)
  *   igt@gem_exec_fair@basic-none-share@rcs0:

 *   shard-tglb: 
PASS
 -> 
FAIL
 (i915#2842)

 *   shard-glk: NOTRUN -> 
FAIL
 (i915#2842)

  *   igt@gem_exec_whisper@basic-contexts-priority:

 *   shard-iclb: 
PASS
 -> 
INCOMPLETE
 (i915#6755)
  *   igt@gem_huc_copy@huc-copy:

 *   shard-tglb: 
PASS
 -> 
SKIP
 (i915#2190)
  *   igt@gem_lmem_swapping@smem-oom:

 *   shard-glk: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#4613) +1 similar 
issue
  *   igt@gen9_exec_parse@allowed-all:

 *   shard-skl: 
PASS
 ->

Re: [Intel-gfx] [PATCH 1/5] drm/i915/backlight: use VLV_DISPLAY_BASE for VLV/CHV backlight registers

2022-12-05 Thread Rodrigo Vivi

On Mon, Dec 05, 2022 at 04:17:16PM +0200, Jani Nikula wrote:
> On Mon, 05 Dec 2022, Jani Nikula  wrote:
> > Since the VLV/CHV backlight registers are only used on VLV/CHV, there's
> > no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's
> > VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv
> > references.
> 
> Hmm, I spotted this, but looks like I didn't spot that none of the
> *other* backlight register apparently aren't used on VLV/CHV.
> 
> Could we just drop DISPLAY_MMIO_BASE() from them altogether?

That would be neat. I hope Ville agrees.

Did you use any sed or coccinele on patch 3?

Feel free to use:

Reviewed-by: Rodrigo Vivi 

for the series, if you decide to go with it and have this
extra removal on a following up work.

> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Jani Nikula 
> > ---
> >  .../drm/i915/display/intel_backlight_regs.h   | 21 ---
> >  1 file changed, 9 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_backlight_regs.h 
> > b/drivers/gpu/drm/i915/display/intel_backlight_regs.h
> > index 344eb8096bd2..02bd1f8201bf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_backlight_regs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_backlight_regs.h
> > @@ -8,20 +8,17 @@
> >  
> >  #include "intel_display_reg_defs.h"
> >  
> > -#define _VLV_BLC_PWM_CTL2_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61250)
> > -#define _VLV_BLC_PWM_CTL2_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61350)
> > -#define VLV_BLC_PWM_CTL2(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL2_A, \
> > -_VLV_BLC_PWM_CTL2_B)
> > +#define _VLV_BLC_PWM_CTL2_A(VLV_DISPLAY_BASE + 0x61250)
> > +#define _VLV_BLC_PWM_CTL2_B(VLV_DISPLAY_BASE + 0x61350)
> > +#define VLV_BLC_PWM_CTL2(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL2_A, 
> > _VLV_BLC_PWM_CTL2_B)
> >  
> > -#define _VLV_BLC_PWM_CTL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61254)
> > -#define _VLV_BLC_PWM_CTL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61354)
> > -#define VLV_BLC_PWM_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL_A, \
> > -   _VLV_BLC_PWM_CTL_B)
> > +#define _VLV_BLC_PWM_CTL_A (VLV_DISPLAY_BASE + 0x61254)
> > +#define _VLV_BLC_PWM_CTL_B (VLV_DISPLAY_BASE + 0x61354)
> > +#define VLV_BLC_PWM_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL_A, 
> > _VLV_BLC_PWM_CTL_B)
> >  
> > -#define _VLV_BLC_HIST_CTL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61260)
> > -#define _VLV_BLC_HIST_CTL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61360)
> > -#define VLV_BLC_HIST_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_HIST_CTL_A, \
> > -_VLV_BLC_HIST_CTL_B)
> > +#define _VLV_BLC_HIST_CTL_A(VLV_DISPLAY_BASE + 0x61260)
> > +#define _VLV_BLC_HIST_CTL_B(VLV_DISPLAY_BASE + 0x61360)
> > +#define VLV_BLC_HIST_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_HIST_CTL_A, 
> > _VLV_BLC_HIST_CTL_B)
> >  
> >  /* Backlight control */
> >  #define BLC_PWM_CTL2   _MMIO(DISPLAY_MMIO_BASE(dev_priv) + 0x61250) /* 
> > 965+ only */
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Silence "mailbox access failed" warning in snb_pcode_read (rev2)

== Series Details ==

Series: drm/i915/hwmon: Silence "mailbox access failed" warning in 
snb_pcode_read (rev2)
URL   : https://patchwork.freedesktop.org/series/111599/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12467 -> Patchwork_111599v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 44)
--

  Additional (4): fi-kbl-soraka fi-adl-ddr5 bat-atsm-1 bat-adls-5 
  Missing(1): bat-dg1-6 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-adls-5}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/bat-adls-5/igt@i915_susp...@basic-s3-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-adl-ddr5:NOTRUN -> [SKIP][2] ([i915#7456])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/fi-adl-ddr5/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +7 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][4] -> [FAIL][5] ([i915#7229])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12467/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

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

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

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

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

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

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

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

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

  * igt@i915_selftest@live@hangcheck:
- fi-adl-ddr5:NOTRUN -> [DMESG-WARN][15] ([i915#5591])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/fi-adl-ddr5/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_chamelium@dp-edid-read:
- fi-adl-ddr5:NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111599v2/fi-adl-ddr5/igt@kms_chamel...@dp-edid-read.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
-

Re: [Intel-gfx] [PATCH i-g-t v2 1/2] lib/dmabuf_sync_file: move common stuff into lib

2022-12-05 Thread Matthew Auld


On 05/12/2022 16:31, Kamil Konieczny wrote:

Hi Matt,

after re-reading I have few more nits.

On 2022-12-02 at 12:02:41 +, Matthew Auld wrote:

So we can use this across different tests.

v2
   - Add docs for everything (Petri)
   - Add missing copyright and fix headers slightly (Kamil)

Signed-off-by: Matthew Auld 
Cc: Kamil Konieczny 
Cc: Petri Latvala 
Cc: Andrzej Hajda 
Cc: Nirmoy Das 
---
  .../igt-gpu-tools/igt-gpu-tools-docs.xml  |   1 +
  lib/dmabuf_sync_file.c| 211 ++
  lib/dmabuf_sync_file.h|  26 +++
  lib/meson.build   |   1 +
  tests/dmabuf_sync_file.c  | 133 +--
  5 files changed, 243 insertions(+), 129 deletions(-)
  create mode 100644 lib/dmabuf_sync_file.c
  create mode 100644 lib/dmabuf_sync_file.h

diff --git a/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml 
b/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
index 1ce842f4..102c8a89 100644
--- a/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
+++ b/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
@@ -15,6 +15,7 @@
  


  API Reference
+
  
  
  
diff --git a/lib/dmabuf_sync_file.c b/lib/dmabuf_sync_file.c
new file mode 100644
index ..bcce2486
--- /dev/null
+++ b/lib/dmabuf_sync_file.c
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "igt.h"
+#include "igt_vgem.h"
+#include "sw_sync.h"
+
+#include "dmabuf_sync_file.h"
+
+/**
+ * SECTION: dmabuf_sync_file
+ * @short_description: DMABUF importing/exporting fencing support library
+ * @title: DMABUF Sync File
+ * @include: dmabuf_sync_file.h
+ */
+
+struct igt_dma_buf_sync_file {
+   __u32 flags;
+   __s32 fd;
+};
+
+#define IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct 
igt_dma_buf_sync_file)
+#define IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct 
igt_dma_buf_sync_file)
+
+/**
+ * has_dmabuf_export_sync_file:
+ * @fd: The open drm fd
+ *
+ * Check if the kernel supports exporting a sync file from dmabuf.
+ */
+bool has_dmabuf_export_sync_file(int fd)
+{
+   struct vgem_bo bo;
+   int dmabuf, ret;
+   struct igt_dma_buf_sync_file arg;
+
+   bo.width = 1;
+   bo.height = 1;
+   bo.bpp = 32;
+   vgem_create(fd, );
+
+   dmabuf = prime_handle_to_fd(fd, bo.handle);
+   gem_close(fd, bo.handle);
+
+   arg.flags = DMA_BUF_SYNC_WRITE;
+   arg.fd = -1;
+
+   ret = igt_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE, );
+   close(dmabuf);
+   igt_assert(ret == 0 || errno == ENOTTY);


imho we should not explode here, it was ok in test but in lib
we should just return false in case of unexpected error, you can
add igt_debug if you think it will help.
This may lead to change in place where you use it, like
igt_require(has_dmabuf_export_sync_file(fd));


Yup, makes sense. Will fix.




+
+   return ret == 0;
+}
+
+/**
+ * dmabuf_export_sync_file:
+ * @dmabuf: The dmabuf fd
+ * @flags: The flags to control the behaviour
+ *
+ * Take a snapshot of the current dma-resv fences in the dmabuf, and export as 
a
+ * syncfile. The @flags should at least specify either DMA_BUF_SYNC_WRITE or
+ * DMA_BUF_SYNC_READ, depending on if we care about the read or write fences.
+ */
+int dmabuf_export_sync_file(int dmabuf, uint32_t flags)


As you do not check for errors so this should be
int __dmabuf_export_sync_file(int dmabuf, uint32_t flags)


do_ioctl() is doing an igt_assert_eq(ioctl(...), 0). Or what do you mean 
by not checking for errors?





+{
+   struct igt_dma_buf_sync_file arg;
+
+   arg.flags = flags;
+   arg.fd = -1;
+   do_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE, );
+
+   return arg.fd;
+}
+
+/**
+ * has_dmabuf_import_sync_file:
+ * @fd: The open drm fd
+ *
+ * Check if the kernel supports importing a sync file into a dmabuf.
+ */
+bool has_dmabuf_import_sync_file(int fd)
+{
+   struct vgem_bo bo;
+   int dmabuf, timeline, fence, ret;
+   struct igt_dma_buf_sync_file arg;
+
+   bo.width = 1;
+   bo.height = 1;
+   bo.bpp = 32;
+   vgem_create(fd, );
+
+   dmabuf = prime_handle_to_fd(fd, bo.handle);
+   gem_close(fd, bo.handle);
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_timeline_create_fence(timeline, 1);
+   sw_sync_timeline_inc(timeline, 1);
+
+   arg.flags = DMA_BUF_SYNC_RW;
+   arg.fd = fence;
+
+   ret = igt_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE, );
+   close(dmabuf);
+   close(fence);
+   igt_assert(ret == 0 || errno == ENOTTY);


Same here, return false instead of assert.


+
+   return ret == 0;
+}
+
+/**
+ * dmabuf_import_sync_file:
+ * @dmabuf: The dmabuf fd
+ * @flags: The flags to control the behaviour
+ * @sync_fd: The sync file (i.e our fence) to import
+ *
+ * Import the sync file @sync_fd, into the dmabuf.

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Check full IP version when applying hw steering semaphore

On Sat, Dec 03, 2022 at 08:38:41AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/mtl: Check full IP version when applying hw steering 
> semaphore
> URL   : https://patchwork.freedesktop.org/series/111595/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12463_full -> Patchwork_111595v1_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.

Applied to drm-intel-gt-next.  Thanks Rodrigo for the review.


Matt

> 
>   
> 
> Participating hosts (14 -> 11)
> --
> 
>   Missing(3): shard-tglu-9 shard-tglu-10 shard-tglu 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_111595v1_full:
> 
> ### IGT changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a4:
> - {shard-dg1}:NOTRUN -> [FAIL][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-dg1-18/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a4.html
> 
>   * {igt@v3d/v3d_perfmon@get-values-valid-perfmon}:
> - {shard-dg1}:NOTRUN -> [SKIP][2]
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-dg1-15/igt@v3d/v3d_perf...@get-values-valid-perfmon.html
> 
>   
> New tests
> -
> 
>   New tests have been introduced between CI_DRM_12463_full and 
> Patchwork_111595v1_full:
> 
> ### New IGT tests (1) ###
> 
>   * igt@kms_flip_tiling:
> - Statuses :
> - Exec time: [None] s
> 
>   
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_111595v1_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_exec@basic-nohangcheck:
> - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#6268])
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12463/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-tglb5/igt@gem_ctx_e...@basic-nohangcheck.html
> 
>   * igt@gem_exec_balancer@parallel-contexts:
> - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12463/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-iclb5/igt@gem_exec_balan...@parallel-contexts.html
> 
>   * igt@gem_exec_fair@basic-none-share@rcs0:
> - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12463/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html
> 
>   * igt@gem_huc_copy@huc-copy:
> - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12463/shard-tglb5/igt@gem_huc_c...@huc-copy.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-tglb6/igt@gem_huc_c...@huc-copy.html
> 
>   * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
> - shard-skl:  [PASS][12] -> [WARN][13] ([i915#1804])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12463/shard-skl9/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-skl6/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
> 
>   * igt@i915_selftest@live@execlists:
> - shard-skl:  [PASS][14] -> [INCOMPLETE][15] ([i915#7156])
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12463/shard-skl4/igt@i915_selftest@l...@execlists.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-skl10/igt@i915_selftest@l...@execlists.html
> 
>   * igt@kms_big_fb@y-tiled-32bpp-rotate-180:
> - shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271]) +70 similar 
> issues
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-skl1/igt@kms_big...@y-tiled-32bpp-rotate-180.html
> 
>   * igt@kms_big_fb@yf-tiled-16bpp-rotate-0:
> - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#111615])
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111595v1/shard-tglb6/igt@kms_big...@yf-tiled-16bpp-rotate-0.html
> 
>   * igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs:
> - shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111615] / [i915#3689])
>[18]: 
>

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Silence "mailbox access failed" warning in snb_pcode_read (rev2)

== Series Details ==

Series: drm/i915/hwmon: Silence "mailbox access failed" warning in 
snb_pcode_read (rev2)
URL   : https://patchwork.freedesktop.org/series/111599/
State : warning

== Summary ==

Error: dim checkpatch failed
686d5a838376 drm/i915/hwmon: Silence "mailbox access failed" warning in 
snb_pcode_read
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
herring which has resulted in a couple of bugs being filed. Therefore silence

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

Re: [Intel-gfx] [PATCH i-g-t v2 1/2] lib/dmabuf_sync_file: move common stuff into lib

2022-12-05 Thread Kamil Konieczny

Hi Matt,

after re-reading I have few more nits.

On 2022-12-02 at 12:02:41 +, Matthew Auld wrote:
> So we can use this across different tests.
> 
> v2
>   - Add docs for everything (Petri)
>   - Add missing copyright and fix headers slightly (Kamil)
> 
> Signed-off-by: Matthew Auld 
> Cc: Kamil Konieczny 
> Cc: Petri Latvala 
> Cc: Andrzej Hajda 
> Cc: Nirmoy Das 
> ---
>  .../igt-gpu-tools/igt-gpu-tools-docs.xml  |   1 +
>  lib/dmabuf_sync_file.c| 211 ++
>  lib/dmabuf_sync_file.h|  26 +++
>  lib/meson.build   |   1 +
>  tests/dmabuf_sync_file.c  | 133 +--
>  5 files changed, 243 insertions(+), 129 deletions(-)
>  create mode 100644 lib/dmabuf_sync_file.c
>  create mode 100644 lib/dmabuf_sync_file.h
> 
> diff --git a/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml 
> b/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
> index 1ce842f4..102c8a89 100644
> --- a/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
> +++ b/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
> @@ -15,6 +15,7 @@
>  
>
>  API Reference
> +
>  
>  
>  
> diff --git a/lib/dmabuf_sync_file.c b/lib/dmabuf_sync_file.c
> new file mode 100644
> index ..bcce2486
> --- /dev/null
> +++ b/lib/dmabuf_sync_file.c
> @@ -0,0 +1,211 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#include "igt.h"
> +#include "igt_vgem.h"
> +#include "sw_sync.h"
> +
> +#include "dmabuf_sync_file.h"
> +
> +/**
> + * SECTION: dmabuf_sync_file
> + * @short_description: DMABUF importing/exporting fencing support library
> + * @title: DMABUF Sync File
> + * @include: dmabuf_sync_file.h
> + */
> +
> +struct igt_dma_buf_sync_file {
> + __u32 flags;
> + __s32 fd;
> +};
> +
> +#define IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct 
> igt_dma_buf_sync_file)
> +#define IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct 
> igt_dma_buf_sync_file)
> +
> +/**
> + * has_dmabuf_export_sync_file:
> + * @fd: The open drm fd
> + *
> + * Check if the kernel supports exporting a sync file from dmabuf.
> + */
> +bool has_dmabuf_export_sync_file(int fd)
> +{
> + struct vgem_bo bo;
> + int dmabuf, ret;
> + struct igt_dma_buf_sync_file arg;
> +
> + bo.width = 1;
> + bo.height = 1;
> + bo.bpp = 32;
> + vgem_create(fd, );
> +
> + dmabuf = prime_handle_to_fd(fd, bo.handle);
> + gem_close(fd, bo.handle);
> +
> + arg.flags = DMA_BUF_SYNC_WRITE;
> + arg.fd = -1;
> +
> + ret = igt_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE, );
> + close(dmabuf);
> + igt_assert(ret == 0 || errno == ENOTTY);

imho we should not explode here, it was ok in test but in lib
we should just return false in case of unexpected error, you can
add igt_debug if you think it will help.
This may lead to change in place where you use it, like
igt_require(has_dmabuf_export_sync_file(fd));

> +
> + return ret == 0;
> +}
> +
> +/**
> + * dmabuf_export_sync_file:
> + * @dmabuf: The dmabuf fd
> + * @flags: The flags to control the behaviour
> + *
> + * Take a snapshot of the current dma-resv fences in the dmabuf, and export 
> as a
> + * syncfile. The @flags should at least specify either DMA_BUF_SYNC_WRITE or
> + * DMA_BUF_SYNC_READ, depending on if we care about the read or write fences.
> + */
> +int dmabuf_export_sync_file(int dmabuf, uint32_t flags)

As you do not check for errors so this should be 
int __dmabuf_export_sync_file(int dmabuf, uint32_t flags)

> +{
> + struct igt_dma_buf_sync_file arg;
> +
> + arg.flags = flags;
> + arg.fd = -1;
> + do_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE, );
> +
> + return arg.fd;
> +}
> +
> +/**
> + * has_dmabuf_import_sync_file:
> + * @fd: The open drm fd
> + *
> + * Check if the kernel supports importing a sync file into a dmabuf.
> + */
> +bool has_dmabuf_import_sync_file(int fd)
> +{
> + struct vgem_bo bo;
> + int dmabuf, timeline, fence, ret;
> + struct igt_dma_buf_sync_file arg;
> +
> + bo.width = 1;
> + bo.height = 1;
> + bo.bpp = 32;
> + vgem_create(fd, );
> +
> + dmabuf = prime_handle_to_fd(fd, bo.handle);
> + gem_close(fd, bo.handle);
> +
> + timeline = sw_sync_timeline_create();
> + fence = sw_sync_timeline_create_fence(timeline, 1);
> + sw_sync_timeline_inc(timeline, 1);
> +
> + arg.flags = DMA_BUF_SYNC_RW;
> + arg.fd = fence;
> +
> + ret = igt_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE, );
> + close(dmabuf);
> + close(fence);
> + igt_assert(ret == 0 || errno == ENOTTY);

Same here, return false instead of assert.

> +
> + return ret == 0;
> +}
> +
> +/**
> + * dmabuf_import_sync_file:
> + * @dmabuf: The dmabuf fd
> + * @flags: The flags to control the behaviour
> + * @sync_fd: The sync file (i.e our fence) to import
> + *
> + * Import the sync

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Check full IP version when applying hw steering semaphore

On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:
> 
> On 02/12/2022 22:49, Rodrigo Vivi wrote:
> > On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
> > > When determining whether the platform has a hardware-level steering
> > > semaphore (i.e., MTL and beyond), we need to use GRAPHICS_VER_FULL() to
> > > compare the full version rather than just the major version number
> > > returned by GRAPHICS_VER().
> > > 
> > > Reported-by: kernel test robot 
> > > Fixes: 3100240bf846 ("drm/i915/mtl: Add hardware-level lock for steering")
> > > Cc: Balasubramani Vivekanandan 
> > > Signed-off-by: Matt Roper 
> > 
> > Reviewed-by: Rodrigo Vivi 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > index 087e4ac5b68d..41a237509dcf 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > @@ -367,7 +367,7 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned 
> > > long *flags)
> > >* driver threads, but also with hardware/firmware agents.  A 
> > > dedicated
> > >* locking register is used.
> > >*/
> > > - if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> > > + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> 
> Ouch, tricky class of bugs... Anyone has an idea how to maybe coerce the 
> compiler into spotting them for us, cheaply?

I believe clang can already notice these problems with
Wtautological-constant-out-of-range-compare (which is how the kernel
test robot finds them):

>> drivers/gpu/drm/i915/gt/intel_gt_mcr.c:370:29: warning: result of 
comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
+is always false [-Wtautological-constant-out-of-range-compare]
   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
   ~~ ^  ~~
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c:410:29: warning: result of 
comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
+is always false [-Wtautological-constant-out-of-range-compare]
   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
   ~~ ^  ~~
   2 warnings generated.

Unfortunately gcc doesn't seem to have anything equivalent as far as I
can see.

> 
> This one is undefined behaviour I think so not good:
> 
> -#define IP_VER(ver, rel)   ((ver) << 8 | (rel))
> +typedef void * i915_full_ver_t;
> +
> +#define IP_VER(ver, rel) (i915_full_ver_t)(unsigned long)((ver) << 8 | (rel))

Hmm, so by casting it into a pointer, you're hoping to trigger a
"comparison of pointer and integer without cast" warning on misuse?
That's a good idea, but as you noted, the C99 spec says comparison of
pointers is only guaranteed to work if both are pointers into the same
structure/array, otherwise the results are technically undefined.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > >   err = wait_for(intel_uncore_read_fw(gt->uncore,
> > >   
> > > MTL_STEER_SEMAPHORE) == 0x1, 100);
> > > @@ -407,7 +407,7 @@ void intel_gt_mcr_unlock(struct intel_gt *gt, 
> > > unsigned long flags)
> > >   {
> > >   spin_unlock_irqrestore(>mcr_lock, flags);
> > > - if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> > > + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> > >   intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 
> > > 0x1);
> > >   }
> > > -- 
> > > 2.38.1
> > > 

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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for DRM - avoid regression in -rc, fix comment

== Series Details ==

Series: DRM - avoid regression in -rc, fix comment
URL   : https://patchwork.freedesktop.org/series/111631/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/111631/revisions/1/mbox/ not 
applied
Applying: drm: mark CONFIG_DRM_USE_DYNAMIC_DEBUG as BROKEN for now
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/Kconfig
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/Kconfig
CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig
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: mark CONFIG_DRM_USE_DYNAMIC_DEBUG as BROKEN for now
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 1/2] drm: mark CONFIG_DRM_USE_DYNAMIC_DEBUG as BROKEN for now

CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression, due to a chicken-egg
initialization problem:

1- modprobe i915
   i915 needs drm.ko, which is loaded 1st

2- "modprobe drm drm.debug=0x1ff" (virtual/implied)
   drm.debug is set post-initialization, from boot-args etc

3- `modprobe i915` finishes

W/O drm.debug-on-dyndbg that just works, because drm_dbg* does
drm_debug_enabled() to check __drm_debug & DRM_UT_ before
printing.

But the whole point of CONFIG_DRM_USE_DYNAMIC_DEBUG is to avoid that
runtime test, by enabling (at end/after module_init) a static-key at
selected callsites in the just-loaded module.

And since drm.ko is loaded before all dependent modules, no other
modules are "just-loaded", and their drm.debug callsites are not
present yet, just those in drm.ko itself.

CC: 
Signed-off-by: Jim Cromie 
---
.v2 - default=N, cuz CI tests BROKEN stuff too. @ville.syrjala
---
 drivers/gpu/drm/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 34f5a092c99e..5adc8d5b6a40 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -53,7 +53,8 @@ config DRM_DEBUG_MM
 
 config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
-   default y
+   default n
+   depends on BROKEN   # chicken-egg initial enable problem
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
-- 
2.38.1

[Intel-gfx] [PATCH 2/2] drm_print: fix stale macro-name in comment

Cited commit uses stale macro name, fix this, and explain better.

When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug.  This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the macro args: DRM_UT_* list must be kept in sync
and in order.

Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
drivers.")
Signed-off-by: Jim Cromie 
---
. emphasize ABI non-change despite enum val change - Jani Nikula
. reorder to back of patchset to follow API name changes.
---
 include/drm/drm_print.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..e4c0c7e6d49d 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
char *prefix)
  *
  */
 enum drm_debug_category {
-   /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+   /*
+* Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
+* the enum-values define BIT()s in drm.debug, so are ABI.
+*/
/**
 * @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
 * drm_memory.c, ...
-- 
2.38.1

[Intel-gfx] [PATCH 0/2] DRM - avoid regression in -rc, fix comment

hi DRM-folks,

DRM_USE_DYNAMIC_DEBUG has regression, mark as BROKEN for now.
Also correct a comment.

Jim Cromie (2):
  drm: mark CONFIG_DRM_USE_DYNAMIC_DEBUG as BROKEN for now
  drm_print: fix stale macro-name in comment

 drivers/gpu/drm/Kconfig | 3 ++-
 include/drm/drm_print.h | 5 -
 2 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/backlight: drop implict dev_priv etc.

== Series Details ==

Series: drm/i915/backlight: drop implict dev_priv etc.
URL   : https://patchwork.freedesktop.org/series/111628/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12467 -> Patchwork_111628v1


Summary
---

  **FAILURE**

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

Participating hosts (41 -> 44)
--

  Additional (3): fi-kbl-soraka fi-adl-ddr5 bat-atsm-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  * igt@i915_selftest@live@workarounds:
- bat-dg1-6:  [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12467/bat-dg1-6/igt@i915_selftest@l...@workarounds.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/bat-dg1-6/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-adl-ddr5:NOTRUN -> [SKIP][4] ([i915#7456])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/fi-adl-ddr5/igt@debugfs_t...@basic-hwmon.html

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

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][6] ([i915#6179])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

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

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

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

  * igt@gem_tiled_pread_basic:
- fi-adl-ddr5:NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/fi-adl-ddr5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-adl-ddr5:NOTRUN -> [SKIP][11] ([i915#7561])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/fi-adl-ddr5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka:  NOTRUN -> [DMESG-WARN][12] ([i915#1982])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/fi-kbl-soraka/igt@i915_pm_...@module-reload.html

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

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

  * igt@i915_selftest@live@hangcheck:
- fi-adl-ddr5:NOTRUN -> [DMESG-WARN][17] ([i915#5591])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111628v1/fi-adl-ddr5/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827])
   [18]:

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

On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:
> 
> On 28/11/2022 23:30, Matt Roper wrote:
> > Starting with MTL, the driver needs to not only protect the steering
> > control register from simultaneous software accesses, but also protect
> > against races with hardware/firmware agents.  The hardware provides a
> > dedicated locking mechanism to support this via the MTL_STEER_SEMAPHORE
> > register.  Reading the register acts as a 'trylock' operation; the read
> > will return 0x1 if the lock is acquired or 0x0 if something else is
> > already holding the lock; once acquired, writing 0x1 to the register
> > will release the lock.
> > 
> > We'll continue to grab the software lock as well, just so lockdep can
> > track our locking; assuming the hardware lock is behaving properly,
> > there should never be any contention on the software lock in this case.
> > 
> > v2:
> >   - Extend hardware semaphore timeout and add a taint for CI if it ever
> > happens (this would imply misbehaving hardware/firmware).  (Mika)
> >   - Add "MTL_" prefix to new steering semaphore register.  (Mika)
> > 
> > Cc: Mika Kuoppala 
> > Signed-off-by: Matt Roper 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 38 ++---
> >   drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
> >   2 files changed, 35 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index aa070ae57f11..087e4ac5b68d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -347,10 +347,9 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
> >* @flags: storage to save IRQ flags to
> >*
> >* Performs locking to protect the steering for the duration of an MCR
> > - * operation.  Depending on the platform, this may be a software lock
> > - * (gt->mcr_lock) or a hardware lock (i.e., a register that synchronizes
> > - * access not only for the driver, but also for external hardware and
> > - * firmware agents).
> > + * operation.  On MTL and beyond, a hardware lock will also be taken to
> > + * serialize access not only for the driver, but also for external 
> > hardware and
> > + * firmware agents.
> >*
> >* Context: Takes gt->mcr_lock.  uncore->lock should *not* be held when 
> > this
> >*  function is called, although it may be acquired after this
> > @@ -359,12 +358,40 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
> >   void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
> >   {
> > unsigned long __flags;
> > +   int err = 0;
> > lockdep_assert_not_held(>uncore->lock);
> > +   /*
> > +* Starting with MTL, we need to coordinate not only with other
> > +* driver threads, but also with hardware/firmware agents.  A dedicated
> > +* locking register is used.
> > +*/
> > +   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> > +   err = wait_for(intel_uncore_read_fw(gt->uncore,
> > +   MTL_STEER_SEMAPHORE) == 
> > 0x1, 100);
> > +
> 
> If two i915 threads enter here what happens? (Given hw locking is done
> before the spinlock.)

The second thread will see a '0' when it reads the register, indicating
that something else (sw, fw, or hw) already has it locked.  As soon as
the first thread drops the lock, the next read will return '1' and allow
the second thread to proceed.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > +   /*
> > +* Even on platforms with a hardware lock, we'll continue to grab
> > +* a software spinlock too for lockdep purposes.  If the hardware lock
> > +* was already acquired, there should never be contention on the
> > +* software lock.
> > +*/
> > spin_lock_irqsave(>mcr_lock, __flags);
> > *flags = __flags;
> > +
> > +   /*
> > +* In theory we should never fail to acquire the HW semaphore; this
> > +* would indicate some hardware/firmware is misbehaving and not
> > +* releasing it properly.
> > +*/
> > +   if (err == -ETIMEDOUT) {
> > +   drm_err_ratelimited(>i915->drm,
> > +   "GT%u hardware MCR steering semaphore timed 
> > out",
> > +   gt->info.id);
> > +   add_taint_for_CI(gt->i915, TAINT_WARN);  /* CI is now 
> > unreliable */
> > +   }
> >   }
> >   /**
> > @@ -379,6 +406,9 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned 
> > long *flags)
> >   void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags)
> >   {
> > spin_unlock_irqrestore(>mcr_lock, flags);
> > +
> > +   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> > +   intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 0x1);
> >   }
> >   /**
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 784152548472..1618d46cb8c7 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: drop uncore locking around i8xx/i965 fbc nuke

== Series Details ==

Series: drm/i915/fbc: drop uncore locking around i8xx/i965 fbc nuke
URL   : https://patchwork.freedesktop.org/series/111626/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12466_full -> Patchwork_111626v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (14 -> 12)
--

  Missing(2): pig-skl-6260u pig-glk-j5005 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@syncobj-backward-timeline-chain-engines:
- shard-skl:  [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12466/shard-skl10/igt@gem_exec_fe...@syncobj-backward-timeline-chain-engines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111626v1/shard-skl10/igt@gem_exec_fe...@syncobj-backward-timeline-chain-engines.html

  
 Suppressed 

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

  * igt@kms_vblank@pipe-d-ts-continuation-dpms-rpm:
- {shard-tglu-9}: NOTRUN -> [SKIP][3] +43 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111626v1/shard-tglu-9/igt@kms_vbl...@pipe-d-ts-continuation-dpms-rpm.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#6268])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12466/shard-tglb1/igt@gem_ctx_e...@basic-nohangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111626v1/shard-tglb6/igt@gem_ctx_e...@basic-nohangcheck.html

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

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

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12466/shard-glk1/igt@gem_exec_fair@basic-n...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111626v1/shard-glk6/igt@gem_exec_fair@basic-n...@vecs0.html

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

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

  * igt@gem_lmem_swapping@random:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111626v1/shard-glk3/igt@gem_lmem_swapp...@random.html

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

  * igt@gem_userptr_blits@vma-merge:
- shard-glk:  NOTRUN -> [FAIL][16] ([i915#3318])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111626v1/shard-glk3/igt@gem_userptr_bl...@vma-merge.html

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

  * igt@i915_suspend@forcewake:
- shard-skl:  [PASS][18] -> [INCOMPLETE][19] ([i915#4817] / 
[i915#7233])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12466/shard-skl5/igt@i915_susp...@forcewake.html
   [19]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/backlight: drop implict dev_priv etc.

== Series Details ==

Series: drm/i915/backlight: drop implict dev_priv etc.
URL   : https://patchwork.freedesktop.org/series/111628/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for add guard padding around i915_vma (rev7)

2022-12-05 Thread Andi Shyti

On Sat, Dec 03, 2022 at 02:27:44AM -, Patchwork wrote:
> Patch Details
> 
> Series:  add guard padding around i915_vma (rev7)
> URL: https://patchwork.freedesktop.org/series/110720/
> State:   failure
> Details: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v7/index.html
> 
> CI Bug Log - changes from CI_DRM_12462_full -> Patchwork_110720v7_full
> 
> Summary
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_110720v7_full absolutely need to
> be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_110720v7_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
> 
> Participating hosts (13 -> 11)
> 
> Missing (2): shard-tglu shard-tglu-10
> 
> Possible new issues
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_110720v7_full:
> 
> IGT changes
> 
> Possible regressions
> 
>   • 
> igt@kms_atomic_transition@modeset-transition-nonblocking-fencing@1x-outputs:
>   □ shard-tglb: PASS -> INCOMPLETE

This looks unrelated

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: remove some limited use register access wrappers (rev2)

== Series Details ==

Series: drm/i915/gt: remove some limited use register access wrappers (rev2)
URL   : https://patchwork.freedesktop.org/series/111265/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12466_full -> Patchwork_111265v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (14 -> 11)
--

  Missing(3): shard-tglu-9 shard-tglu-10 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@perf@buffer-fill:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12466/shard-skl10/igt@p...@buffer-fill.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111265v2/shard-skl7/igt@p...@buffer-fill.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915/backlight: use VLV_DISPLAY_BASE for VLV/CHV backlight registers

On Mon, 05 Dec 2022, Jani Nikula  wrote:
> Since the VLV/CHV backlight registers are only used on VLV/CHV, there's
> no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's
> VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv
> references.

Hmm, I spotted this, but looks like I didn't spot that none of the
*other* backlight register apparently aren't used on VLV/CHV.

Could we just drop DISPLAY_MMIO_BASE() from them altogether?

BR,
Jani.

>
> Signed-off-by: Jani Nikula 
> ---
>  .../drm/i915/display/intel_backlight_regs.h   | 21 ---
>  1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight_regs.h 
> b/drivers/gpu/drm/i915/display/intel_backlight_regs.h
> index 344eb8096bd2..02bd1f8201bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_backlight_regs.h
> @@ -8,20 +8,17 @@
>  
>  #include "intel_display_reg_defs.h"
>  
> -#define _VLV_BLC_PWM_CTL2_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61250)
> -#define _VLV_BLC_PWM_CTL2_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61350)
> -#define VLV_BLC_PWM_CTL2(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL2_A, \
> -  _VLV_BLC_PWM_CTL2_B)
> +#define _VLV_BLC_PWM_CTL2_A  (VLV_DISPLAY_BASE + 0x61250)
> +#define _VLV_BLC_PWM_CTL2_B  (VLV_DISPLAY_BASE + 0x61350)
> +#define VLV_BLC_PWM_CTL2(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL2_A, 
> _VLV_BLC_PWM_CTL2_B)
>  
> -#define _VLV_BLC_PWM_CTL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61254)
> -#define _VLV_BLC_PWM_CTL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61354)
> -#define VLV_BLC_PWM_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL_A, \
> - _VLV_BLC_PWM_CTL_B)
> +#define _VLV_BLC_PWM_CTL_A   (VLV_DISPLAY_BASE + 0x61254)
> +#define _VLV_BLC_PWM_CTL_B   (VLV_DISPLAY_BASE + 0x61354)
> +#define VLV_BLC_PWM_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL_A, 
> _VLV_BLC_PWM_CTL_B)
>  
> -#define _VLV_BLC_HIST_CTL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61260)
> -#define _VLV_BLC_HIST_CTL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61360)
> -#define VLV_BLC_HIST_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_HIST_CTL_A, \
> -  _VLV_BLC_HIST_CTL_B)
> +#define _VLV_BLC_HIST_CTL_A  (VLV_DISPLAY_BASE + 0x61260)
> +#define _VLV_BLC_HIST_CTL_B  (VLV_DISPLAY_BASE + 0x61360)
> +#define VLV_BLC_HIST_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_HIST_CTL_A, 
> _VLV_BLC_HIST_CTL_B)
>  
>  /* Backlight control */
>  #define BLC_PWM_CTL2 _MMIO(DISPLAY_MMIO_BASE(dev_priv) + 0x61250) /* 965+ 
> only */

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH 0/5] drm/i915/backlight: drop implict dev_priv etc.

Dump a local branch I've had laying around for a while.

Jani Nikula (5):
  drm/i915/backlight: use VLV_DISPLAY_BASE for VLV/CHV backlight
registers
  drm/i915/backlight: get rid of the implicit dev_priv
  drm/i915/backlight: mass rename dev_priv to i915
  drm/i915/backlight: drop drm_device local variables in favor of i915
  drm/i915/backlight: convert DRM_DEBUG_KMS() to drm_dbg_kms()

 .../gpu/drm/i915/display/intel_backlight.c| 539 +-
 .../drm/i915/display/intel_backlight_regs.h   |  27 +-
 2 files changed, 271 insertions(+), 295 deletions(-)

-- 
2.34.1

[Intel-gfx] [PATCH 5/5] drm/i915/backlight: convert DRM_DEBUG_KMS() to drm_dbg_kms()

Fix the final straggler.

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

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 3599c7c8c007..8d8f9711aea8 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -866,8 +866,8 @@ static int intel_backlight_device_update_status(struct 
backlight_device *bd)
 
drm_modeset_lock(>drm.mode_config.connection_mutex, NULL);
 
-   DRM_DEBUG_KMS("updating intel_backlight, brightness=%d/%d\n",
- bd->props.brightness, bd->props.max_brightness);
+   drm_dbg_kms(>drm, "updating intel_backlight, brightness=%d/%d\n",
+   bd->props.brightness, bd->props.max_brightness);
intel_panel_set_backlight(connector->base.state, bd->props.brightness,
  bd->props.max_brightness);
 
-- 
2.34.1

[Intel-gfx] [PATCH 4/5] drm/i915/backlight: drop drm_device local variables in favor of i915

Prefer only having struct drm_i915_private *i915 around. Drop the
drm_device *dev locals.

Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_backlight.c| 22 +--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index c13b8a678063..3599c7c8c007 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -861,10 +861,11 @@ static void intel_panel_set_backlight(const struct 
drm_connector_state *conn_sta
 static int intel_backlight_device_update_status(struct backlight_device *bd)
 {
struct intel_connector *connector = bl_get_data(bd);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   struct drm_device *dev = connector->base.dev;
 
-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   drm_modeset_lock(>drm.mode_config.connection_mutex, NULL);
+
DRM_DEBUG_KMS("updating intel_backlight, brightness=%d/%d\n",
  bd->props.brightness, bd->props.max_brightness);
intel_panel_set_backlight(connector->base.state, bd->props.brightness,
@@ -886,28 +887,28 @@ static int intel_backlight_device_update_status(struct 
backlight_device *bd)
bd->props.power = FB_BLANK_POWERDOWN;
}
 
-   drm_modeset_unlock(>mode_config.connection_mutex);
+   drm_modeset_unlock(>drm.mode_config.connection_mutex);
+
return 0;
 }
 
 static int intel_backlight_device_get_brightness(struct backlight_device *bd)
 {
struct intel_connector *connector = bl_get_data(bd);
-   struct drm_device *dev = connector->base.dev;
-   struct drm_i915_private *i915 = to_i915(dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
intel_wakeref_t wakeref;
int ret = 0;
 
with_intel_runtime_pm(>runtime_pm, wakeref) {
u32 hw_level;
 
-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   drm_modeset_lock(>drm.mode_config.connection_mutex, NULL);
 
hw_level = intel_panel_get_backlight(connector);
ret = scale_hw_to_user(connector,
   hw_level, bd->props.max_brightness);
 
-   drm_modeset_unlock(>mode_config.connection_mutex);
+   drm_modeset_unlock(>drm.mode_config.connection_mutex);
}
 
return ret;
@@ -1467,18 +1468,17 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
 static int ext_pwm_setup_backlight(struct intel_connector *connector,
   enum pipe pipe)
 {
-   struct drm_device *dev = connector->base.dev;
-   struct drm_i915_private *i915 = to_i915(dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
const char *desc;
u32 level;
 
/* Get the right PWM chip for DSI backlight according to VBT */
if (connector->panel.vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
-   panel->backlight.pwm = pwm_get(dev->dev, "pwm_pmic_backlight");
+   panel->backlight.pwm = pwm_get(i915->drm.dev, 
"pwm_pmic_backlight");
desc = "PMIC";
} else {
-   panel->backlight.pwm = pwm_get(dev->dev, "pwm_soc_backlight");
+   panel->backlight.pwm = pwm_get(i915->drm.dev, 
"pwm_soc_backlight");
desc = "SoC";
}
 
-- 
2.34.1

[Intel-gfx] [PATCH 3/5] drm/i915/backlight: mass rename dev_priv to i915

With the implicit dev_priv usage gone, we can rename dev_priv to i915
throughout. Do some drive-by whitespace cleanups while at it.

Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_backlight.c| 517 +-
 1 file changed, 248 insertions(+), 269 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index b3c44b054d08..c13b8a678063 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -83,16 +83,16 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 
 u32 intel_backlight_invert_pwm_level(struct intel_connector *connector, u32 
val)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
 
-   drm_WARN_ON(_priv->drm, panel->backlight.pwm_level_max == 0);
+   drm_WARN_ON(>drm, panel->backlight.pwm_level_max == 0);
 
-   if (dev_priv->params.invert_brightness < 0)
+   if (i915->params.invert_brightness < 0)
return val;
 
-   if (dev_priv->params.invert_brightness > 0 ||
-   intel_has_quirk(dev_priv, QUIRK_INVERT_BRIGHTNESS)) {
+   if (i915->params.invert_brightness > 0 ||
+   intel_has_quirk(i915, QUIRK_INVERT_BRIGHTNESS)) {
return panel->backlight.pwm_level_max - val + 
panel->backlight.pwm_level_min;
}
 
@@ -111,10 +111,10 @@ void intel_backlight_set_pwm_level(const struct 
drm_connector_state *conn_state,
 
 u32 intel_backlight_level_to_pwm(struct intel_connector *connector, u32 val)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
 
-   drm_WARN_ON_ONCE(_priv->drm,
+   drm_WARN_ON_ONCE(>drm,
 panel->backlight.max == 0 || 
panel->backlight.pwm_level_max == 0);
 
val = scale(val, panel->backlight.min, panel->backlight.max,
@@ -125,14 +125,14 @@ u32 intel_backlight_level_to_pwm(struct intel_connector 
*connector, u32 val)
 
 u32 intel_backlight_level_from_pwm(struct intel_connector *connector, u32 val)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
 
-   drm_WARN_ON_ONCE(_priv->drm,
+   drm_WARN_ON_ONCE(>drm,
 panel->backlight.max == 0 || 
panel->backlight.pwm_level_max == 0);
 
-   if (dev_priv->params.invert_brightness > 0 ||
-   (dev_priv->params.invert_brightness == 0 && 
intel_has_quirk(dev_priv, QUIRK_INVERT_BRIGHTNESS)))
+   if (i915->params.invert_brightness > 0 ||
+   (i915->params.invert_brightness == 0 && intel_has_quirk(i915, 
QUIRK_INVERT_BRIGHTNESS)))
val = panel->backlight.pwm_level_max - (val - 
panel->backlight.pwm_level_min);
 
return scale(val, panel->backlight.pwm_level_min, 
panel->backlight.pwm_level_max,
@@ -141,32 +141,32 @@ u32 intel_backlight_level_from_pwm(struct intel_connector 
*connector, u32 val)
 
 static u32 lpt_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
 
-   return intel_de_read(dev_priv, BLC_PWM_PCH_CTL2) & 
BACKLIGHT_DUTY_CYCLE_MASK;
+   return intel_de_read(i915, BLC_PWM_PCH_CTL2) & 
BACKLIGHT_DUTY_CYCLE_MASK;
 }
 
 static u32 pch_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
 
-   return intel_de_read(dev_priv, BLC_PWM_CPU_CTL) & 
BACKLIGHT_DUTY_CYCLE_MASK;
+   return intel_de_read(i915, BLC_PWM_CPU_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
 }
 
 static u32 i9xx_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
u32 val;
 
-   val = intel_de_read(dev_priv, BLC_PWM_CTL(dev_priv)) & 
BACKLIGHT_DUTY_CYCLE_MASK;
-   if (DISPLAY_VER(dev_priv) < 4)
+   val = intel_de_read(i915, BLC_PWM_CTL(i915)) & 
BACKLIGHT_DUTY_CYCLE_MASK;
+   if (DISPLAY_VER(i915) < 4)
val >>= 1;
 
if (panel->backlight.combination_mode) {
u8 lbpc;
 
-   pci_read_config_byte(to_pci_dev(dev_priv->drm.dev), LBPC, 
);
+   pci_read_config_byte(to_pci_dev(i915->drm.dev), LBPC, );
val *= lbpc;
}
 
@@ -175,21 +175,20 @@ static u32 i9xx_get_backlight(struct intel_connector

[Intel-gfx] [PATCH 2/5] drm/i915/backlight: get rid of the implicit dev_priv

Pass the i915 pointer to the macros where needed.

Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_backlight.c| 38 +--
 .../drm/i915/display/intel_backlight_regs.h   |  6 +--
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 71af88a70461..b3c44b054d08 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -159,7 +159,7 @@ static u32 i9xx_get_backlight(struct intel_connector 
*connector, enum pipe unuse
struct intel_panel *panel = >panel;
u32 val;
 
-   val = intel_de_read(dev_priv, BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
+   val = intel_de_read(dev_priv, BLC_PWM_CTL(dev_priv)) & 
BACKLIGHT_DUTY_CYCLE_MASK;
if (DISPLAY_VER(dev_priv) < 4)
val >>= 1;
 
@@ -244,8 +244,8 @@ static void i9xx_set_backlight(const struct 
drm_connector_state *conn_state, u32
mask = BACKLIGHT_DUTY_CYCLE_MASK_PNV;
}
 
-   tmp = intel_de_read(dev_priv, BLC_PWM_CTL) & ~mask;
-   intel_de_write(dev_priv, BLC_PWM_CTL, tmp | level);
+   tmp = intel_de_read(dev_priv, BLC_PWM_CTL(dev_priv)) & ~mask;
+   intel_de_write(dev_priv, BLC_PWM_CTL(dev_priv), tmp | level);
 }
 
 static void vlv_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
@@ -383,8 +383,8 @@ static void i965_disable_backlight(const struct 
drm_connector_state *old_conn_st
 
intel_backlight_set_pwm_level(old_conn_state, val);
 
-   tmp = intel_de_read(dev_priv, BLC_PWM_CTL2);
-   intel_de_write(dev_priv, BLC_PWM_CTL2, tmp & ~BLM_PWM_ENABLE);
+   tmp = intel_de_read(dev_priv, BLC_PWM_CTL2(dev_priv));
+   intel_de_write(dev_priv, BLC_PWM_CTL2(dev_priv), tmp & ~BLM_PWM_ENABLE);
 }
 
 static void vlv_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 val)
@@ -585,10 +585,10 @@ static void i9xx_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
u32 ctl, freq;
 
-   ctl = intel_de_read(dev_priv, BLC_PWM_CTL);
+   ctl = intel_de_read(dev_priv, BLC_PWM_CTL(dev_priv));
if (ctl & BACKLIGHT_DUTY_CYCLE_MASK_PNV) {
drm_dbg_kms(_priv->drm, "backlight already enabled\n");
-   intel_de_write(dev_priv, BLC_PWM_CTL, 0);
+   intel_de_write(dev_priv, BLC_PWM_CTL(dev_priv), 0);
}
 
freq = panel->backlight.pwm_level_max;
@@ -601,8 +601,8 @@ static void i9xx_enable_backlight(const struct 
intel_crtc_state *crtc_state,
if (IS_PINEVIEW(dev_priv) && panel->backlight.active_low_pwm)
ctl |= BLM_POLARITY_PNV;
 
-   intel_de_write(dev_priv, BLC_PWM_CTL, ctl);
-   intel_de_posting_read(dev_priv, BLC_PWM_CTL);
+   intel_de_write(dev_priv, BLC_PWM_CTL(dev_priv), ctl);
+   intel_de_posting_read(dev_priv, BLC_PWM_CTL(dev_priv));
 
/* XXX: combine this into above write? */
intel_backlight_set_pwm_level(conn_state, level);
@@ -613,7 +613,7 @@ static void i9xx_enable_backlight(const struct 
intel_crtc_state *crtc_state,
 * that has backlight.
 */
if (DISPLAY_VER(dev_priv) == 2)
-   intel_de_write(dev_priv, BLC_HIST_CTL, BLM_HISTOGRAM_ENABLE);
+   intel_de_write(dev_priv, BLC_HIST_CTL(dev_priv), 
BLM_HISTOGRAM_ENABLE);
 }
 
 static void i965_enable_backlight(const struct intel_crtc_state *crtc_state,
@@ -625,11 +625,11 @@ static void i965_enable_backlight(const struct 
intel_crtc_state *crtc_state,
enum pipe pipe = to_intel_crtc(conn_state->crtc)->pipe;
u32 ctl, ctl2, freq;
 
-   ctl2 = intel_de_read(dev_priv, BLC_PWM_CTL2);
+   ctl2 = intel_de_read(dev_priv, BLC_PWM_CTL2(dev_priv));
if (ctl2 & BLM_PWM_ENABLE) {
drm_dbg_kms(_priv->drm, "backlight already enabled\n");
ctl2 &= ~BLM_PWM_ENABLE;
-   intel_de_write(dev_priv, BLC_PWM_CTL2, ctl2);
+   intel_de_write(dev_priv, BLC_PWM_CTL2(dev_priv), ctl2);
}
 
freq = panel->backlight.pwm_level_max;
@@ -637,16 +637,16 @@ static void i965_enable_backlight(const struct 
intel_crtc_state *crtc_state,
freq /= 0xff;
 
ctl = freq << 16;
-   intel_de_write(dev_priv, BLC_PWM_CTL, ctl);
+   intel_de_write(dev_priv, BLC_PWM_CTL(dev_priv), ctl);
 
ctl2 = BLM_PIPE(pipe);
if (panel->backlight.combination_mode)
ctl2 |= BLM_COMBINATION_MODE;
if (panel->backlight.active_low_pwm)
ctl2 |= BLM_POLARITY_I965;
-   intel_de_write(dev_priv, BLC_PWM_CTL2, ctl2);
-   intel_de_posting_read(dev_priv, BLC_PWM_CTL2);
-   intel_de_write(dev_priv, BLC_PWM_CTL2, ctl2 | BLM_PWM_ENABLE);
+   intel_de_write(dev_priv, BLC_PWM_CTL2(dev_priv), ctl2);
+   intel_de_posting_read(dev_priv,

[Intel-gfx] [PATCH 1/5] drm/i915/backlight: use VLV_DISPLAY_BASE for VLV/CHV backlight registers

Since the VLV/CHV backlight registers are only used on VLV/CHV, there's
no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's
VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv
references.

Signed-off-by: Jani Nikula 
---
 .../drm/i915/display/intel_backlight_regs.h   | 21 ---
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight_regs.h 
b/drivers/gpu/drm/i915/display/intel_backlight_regs.h
index 344eb8096bd2..02bd1f8201bf 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_backlight_regs.h
@@ -8,20 +8,17 @@
 
 #include "intel_display_reg_defs.h"
 
-#define _VLV_BLC_PWM_CTL2_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61250)
-#define _VLV_BLC_PWM_CTL2_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61350)
-#define VLV_BLC_PWM_CTL2(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL2_A, \
-_VLV_BLC_PWM_CTL2_B)
+#define _VLV_BLC_PWM_CTL2_A(VLV_DISPLAY_BASE + 0x61250)
+#define _VLV_BLC_PWM_CTL2_B(VLV_DISPLAY_BASE + 0x61350)
+#define VLV_BLC_PWM_CTL2(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL2_A, 
_VLV_BLC_PWM_CTL2_B)
 
-#define _VLV_BLC_PWM_CTL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61254)
-#define _VLV_BLC_PWM_CTL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61354)
-#define VLV_BLC_PWM_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL_A, \
-   _VLV_BLC_PWM_CTL_B)
+#define _VLV_BLC_PWM_CTL_A (VLV_DISPLAY_BASE + 0x61254)
+#define _VLV_BLC_PWM_CTL_B (VLV_DISPLAY_BASE + 0x61354)
+#define VLV_BLC_PWM_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_PWM_CTL_A, 
_VLV_BLC_PWM_CTL_B)
 
-#define _VLV_BLC_HIST_CTL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61260)
-#define _VLV_BLC_HIST_CTL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61360)
-#define VLV_BLC_HIST_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_HIST_CTL_A, \
-_VLV_BLC_HIST_CTL_B)
+#define _VLV_BLC_HIST_CTL_A(VLV_DISPLAY_BASE + 0x61260)
+#define _VLV_BLC_HIST_CTL_B(VLV_DISPLAY_BASE + 0x61360)
+#define VLV_BLC_HIST_CTL(pipe) _MMIO_PIPE(pipe, _VLV_BLC_HIST_CTL_A, 
_VLV_BLC_HIST_CTL_B)
 
 /* Backlight control */
 #define BLC_PWM_CTL2   _MMIO(DISPLAY_MMIO_BASE(dev_priv) + 0x61250) /* 965+ 
only */
-- 
2.34.1

Re: [Intel-gfx] [PATCH 1/9] drm/amdgpu: generally allow over-commit during BO allocation

2022-12-05 Thread Christian König


Am 25.11.22 um 19:18 schrieb Alex Deucher:

On Fri, Nov 25, 2022 at 5:21 AM Christian König
 wrote:

We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.

Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications which try to allocate/free
GTT in a loop and are otherwise only limited by the CPU speed.

The CS will wait for the cleanup of freed up BOs to satisfy the
various domain specific limits and so effectively throttle those
buggy applications down to a sane allocation behavior again.

Signed-off-by: Christian König 

This looks like a good bug fix and unrelated to the rest of this series.
Reviewed-by: Alex Deucher 


Yeah, this was just in the tree because I tried to address some bug report.

The TTM changes mitigated the bugs, but this patch here is the real 
underlying fix.


I've cherry picked it over to amd-staging-drm-next and pushed it.

Thanks,
Christian.




---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 16 +++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  6 +-
  2 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index a0780a4e3e61..62e98f1ad770 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -113,7 +113,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, 
unsigned long size,
 bp.resv = resv;
 bp.preferred_domain = initial_domain;
 bp.flags = flags;
-   bp.domain = initial_domain;
+   bp.domain = initial_domain | AMDGPU_GEM_DOMAIN_CPU;
 bp.bo_ptr_size = sizeof(struct amdgpu_bo);

 r = amdgpu_bo_create_user(adev, , );
@@ -332,20 +332,10 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void 
*data,
 }

 initial_domain = (u32)(0x & args->in.domains);
-retry:
 r = amdgpu_gem_object_create(adev, size, args->in.alignment,
-initial_domain,
-flags, ttm_bo_type_device, resv, );
+initial_domain, flags, ttm_bo_type_device,
+resv, );
 if (r && r != -ERESTARTSYS) {
-   if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
-   flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
-   goto retry;
-   }
-
-   if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
-   initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
-   goto retry;
-   }
 DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu, 
%d)\n",
 size, initial_domain, args->in.alignment, r);
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..919bbea2e3ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -581,11 +581,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
 bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;

 bo->tbo.bdev = >mman.bdev;
-   if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA |
- AMDGPU_GEM_DOMAIN_GDS))
-   amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
-   else
-   amdgpu_bo_placement_from_domain(bo, bp->domain);
+   amdgpu_bo_placement_from_domain(bo, bp->domain);
 if (bp->type == ttm_bo_type_kernel)
 bo->tbo.priority = 1;

--
2.34.1

Re: [Intel-gfx] [PATCH 3/9] drm/ttm: use per BO cleanup workers

2022-12-05 Thread Christian König


Am 29.11.22 um 22:14 schrieb Felix Kuehling:

On 2022-11-25 05:21, Christian König wrote:

Instead of a single worker going over the list of delete BOs in regular
intervals use a per BO worker which blocks for the resv object and
locking of the BO.

This not only simplifies the handling massively, but also results in
much better response time when cleaning up buffers.

Signed-off-by: Christian König 


Just thinking out loud: If I understand it correctly, this can cause a 
lot of sleeping worker threads when 
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is used and many BOs are freed 
at the same time. This happens e.g. when a KFD process terminates or 
crashes. I guess with a concurrency-managed workqueue this isn't going 
to be excessive. And since it's on a per device workqueue, it doesn't 
stall work items on the system work queue or from other devices.


Yes, exactly that. The last parameter to alloc_workqueue() limits how 
many work items can be sleeping.


I'm trying to understand why you set WQ_MEM_RECLAIM. This work queue 
is not about freeing ttm_resources but about freeing the BOs. But it 
affects freeing of ghost_objs that are holding the ttm_resources being 
freed.


Well if the BO is idle, but not immediately lockable we delegate freeing 
the backing pages in the TT object to those workers as well. It might 
even be a good idea to use a separate wq for this case.




If those assumptions all make sense, patches 1-3 are

Reviewed-by: Felix Kuehling 


Thanks,
Christian.





---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
  drivers/gpu/drm/i915/i915_gem.c    |   2 +-
  drivers/gpu/drm/i915/intel_region_ttm.c    |   2 +-
  drivers/gpu/drm/ttm/ttm_bo.c   | 112 -
  drivers/gpu/drm/ttm/ttm_bo_util.c  |   1 -
  drivers/gpu/drm/ttm/ttm_device.c   |  24 ++---
  include/drm/ttm/ttm_bo_api.h   |  18 +---
  include/drm/ttm/ttm_device.h   |   7 +-
  8 files changed, 57 insertions(+), 111 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index 2b1db37e25c1..74ccbd566777 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3984,7 +3984,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device 
*adev)

  amdgpu_fence_driver_hw_fini(adev);
    if (adev->mman.initialized)
-    flush_delayed_work(>mman.bdev.wq);
+    drain_workqueue(adev->mman.bdev.wq);
    if (adev->pm_sysfs_en)
  amdgpu_pm_sysfs_fini(adev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 8468ca9885fd..c38306f156d6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1099,7 +1099,7 @@ void i915_gem_drain_freed_objects(struct 
drm_i915_private *i915)

  {
  while (atomic_read(>mm.free_count)) {
  flush_work(>mm.free_work);
-    flush_delayed_work(>bdev.wq);
+    drain_workqueue(i915->bdev.wq);
  rcu_barrier();
  }
  }
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c

index cf89d0c2a2d9..657bbc16a48a 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -132,7 +132,7 @@ int intel_region_ttm_fini(struct 
intel_memory_region *mem)

  break;
    msleep(20);
-    flush_delayed_work(>i915->bdev.wq);
+    drain_workqueue(mem->i915->bdev.wq);
  }
    /* If we leaked objects, Don't free the region causing use 
after free */

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b77262a623e0..4749b65bedc4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -280,14 +280,13 @@ static int ttm_bo_cleanup_refs(struct 
ttm_buffer_object *bo,

  ret = 0;
  }
  -    if (ret || unlikely(list_empty(>ddestroy))) {
+    if (ret) {
  if (unlock_resv)
  dma_resv_unlock(bo->base.resv);
  spin_unlock(>bdev->lru_lock);
  return ret;
  }
  -    list_del_init(>ddestroy);
  spin_unlock(>bdev->lru_lock);
  ttm_bo_cleanup_memtype_use(bo);
  @@ -300,47 +299,21 @@ static int ttm_bo_cleanup_refs(struct 
ttm_buffer_object *bo,

  }
    /*
- * Traverse the delayed list, and call ttm_bo_cleanup_refs on all
- * encountered buffers.
+ * Block for the dma_resv object to become idle, lock the buffer and 
clean up

+ * the resource and tt object.
   */
-bool ttm_bo_delayed_delete(struct ttm_device *bdev, bool remove_all)
+static void ttm_bo_delayed_delete(struct work_struct *work)
  {
-    struct list_head removed;
-    bool empty;
-
-    INIT_LIST_HEAD();
-
-    spin_lock(>lru_lock);
-    while (!list_empty(>ddestroy)) {
-    struct ttm_buffer_object *bo;
-
-    bo = list_first_entry(>ddestroy, struct 
ttm_buffer_object,

-  ddestroy);
-    list_move_tail(>ddestroy, );
-    if

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

2022-12-05 Thread Tvrtko Ursulin




On 02/12/2022 20:14, John Harrison wrote:


and while for dbg level messages it doesn't matter, I assume we should
be consistent for err/warn/info messages (as those will eventually show
up to the end user) so let maintainers decide here what is 
expectation here


Could we have some examples pasted here, of the end result of this 
series, for all message "categories" (origins, macros, whatever)?


GT initialisation:
gt_err(gt, "Failed to allocate scratch page\n");
i915 :00:02.0: [drm] GT0: Failed to allocate scratch page

G2H notification handler:
guc_err(guc, "notification: Invalid length %u for deregister done\n", len);
i915 :00:02.0: [drm] GT0: GuC notification: Invalid length 0 for 
deregister done


I'm not liking the inconsistency between gt_err and guc_err where with latter callers either need 
to start the message with lower case because of the unstructured "GuC " prefix added. 
Which then reads bad if callers do guc_err(guc, "Error X happend").

Looks like Michal was pointing out the same thing, AFAIU at least when 
re-reading the thread now.

Why wouldn't this work:

guc_err(guc, "Invalid length %u for deregister done notification\n", len);
i915 :00:02.0: [drm] GT0: GuC: Invalid length 0 for deregister done 
notification

Or if the use case for adding custom prefixes is strong then maybe consider:

guc_err(guc, "notification", "Invalid length 0 for deregister done");
i915 :00:02.0: [drm] GT0: GuC notification: Invalid length 0 for deregister 
done

guc_err(guc, "", "Error X");
i915 :00:02.0: [drm] GT0: GuC: Error X


CTB initialisation:
ct_probe_error(ct, "Failed to control/%s CTB (%pe)\n", 
str_enable_disable(enable), ERR_PTR(err));

i915 :00:02.0: [drm] GT0: GuC CT Failed to control/enable CTB (EINVAL)


Okay same as above.


Random meaningless (to me) message that is apparently a display thing:
drm_dbg_kms(_priv->drm, "disabling %s\n", pll->info->name);
i915 :00:02.0: [drm:intel_disable_shared_dpll [i915]] disabling PORT 
PLL B


Plan is to not touch outside gt/.

I'm sure you can extrapolate to all other forms of dbg, notice, info, 
etc. without me having to manually type each one out, given that they 
are all identical.


Personally, I think the above should be just:
gt_err(gt, "Failed to allocate scratch page\n");
i915 :00:02.0: [drm] GT0: Failed to allocate scratch page

gt_err(guc_to_gt(guc), "G2H: Invalid length for deregister done: %u\n", 
len);

i915 :00:02.0: [drm] GT0: G2H: Invalid length for deregister done: 0

gt_probe_error(ct_to_gt(ct), "Failed to %s CT %d buffer (%pe)\n", 
str_enable_disable(enable), send ? "SEND" : "RECV", ERR_PTR(err));

i915 :00:02.0: [drm] GT0: Failed to enable CT SEND buffer (EINVAL)


We could but it seems we agreed some weeks ago to consolidate the existing 
CT_ERROR macros and such in this exercise. At least no objections were raised 
to that plan.

If now we want to go back on that, and if you want to have guc_to_gt(guc) in 
all gt/uc/ call sites that's fine by me, but please get some acks and consensus 
from people who work in that area. And under that option someone would also 
need to convert the CT code to new macros.

Regards,

Tvrtko


drm_dbg_kms(_priv->drm, "disabling %s\n", pll->info->name);
i915 :00:02.0: [drm:intel_disable_shared_dpll [i915-KMS]] disabling 
PORT PLL B
But presumably that requires finishing the plan of splitting out the 
display code into a separate driver. So for now, something like this 
would still be a massive improvement:

kms_dbg(dev_priv, "disabling %s\n", pll->info->name);
i915 :00:02.0: [drm:intel_disable_shared_dpll [i915]] KMS: disabling 
PORT PLL B


John.



Regards,

Tvrtko

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: drop uncore locking around i8xx/i965 fbc nuke