[PATCH v3 2/5] drm/i915: use pat_index instead of cache_level

[fei . yang]

From: Fei Yang 

Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.

>From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity.

For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For such simple cases, using cache_level
would help simplify the code.

Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/display/intel_dpt.c  | 12 +--
 drivers/gpu/drm/i915/gem/i915_gem_domain.c| 43 ++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 52 +++-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  4 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 25 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 16 ++--
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  | 10 ++-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 71 
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h  |  3 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 82 +--
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 20 ++---
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 47 ++-
 drivers/gpu/drm/i915/gt/intel_migrate.h   | 13 ++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 ++-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  8 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++-
 drivers/gpu/drm/i915/i915_debugfs.c   | 55 ++---
 drivers/gpu/drm/i915/i915_gem.c   | 16 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 +-
 drivers/gpu/drm/i915/i915_vma.c   | 16 ++--
 drivers/gpu/drm/i915/i915_vma.h   |  2 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  2 -
 drivers/gpu/drm/i915/selftests/i915_gem.c |  5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++--
 .../drm/i915/selftests/intel_memory_region.c  |  4 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  8 +-
 36 files changed, 394 insertions(+), 239 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index c5eacfdba1a5..7c5fddb203ba 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -43,24 +43,24 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)
 static void dpt_insert_page(struct i915_address_space *vm,
dma_addr_t addr,
u64 offset,
-   enum i915_cache_level level,
+   unsigned int pat_index,
u32 flags)
 {
struct i915_dpt *dpt = i915_vm_to_dpt(vm);
gen8_pte_t __iomem *base = dpt->iomem;
 
gen8_set_pte(base + offset / I915_GTT_PAGE_SIZE,
-vm->pte_encode(addr, level, flags));
+vm->pte_encode(addr, pat_index, flags));
 }
 
 static void dpt_insert_entries(struct i915_address_space *vm,
   struct i915_vma_resource *vma_res,
-  enum i915_cache_level level,
+  unsigned int pat_index,
   u32 flags)
 {
struct i915_dpt *dpt = i915_vm_to_dpt(vm);
gen8_pte_t __iomem *base = dpt->iomem;
-   const gen8_pte_t pte_encode = vm->pte_encode(0, level, flags);
+   const gen8_pte_t pte_encode = vm->pte_encode(0, pat_index, flags);
struct sgt_iter sgt_iter;
dma_addr_t addr;
int i;
@@ -83,7 +83,7 @@ static void dpt_clear_range(struct i915_address_space *vm,
 static void dpt_bind_vma(struct i915_address_space *vm,
 struct i915_vm_pt_stash *stash,
 

[PATCH v3 4/5] drm/i915/mtl: end support for set caching ioctl

[fei . yang]

From: Fei Yang 

The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
cache. For userspace components needing to fine tune the caching policy
for BO's, a follow up patch will extend the GEM_CREATE uAPI to allow
them specify caching mode at BO creation time.

Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 9 -
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 17375935ce1e..dcd6056ef90d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -336,6 +336,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void 
*data,
if (IS_DGFX(i915))
return -ENODEV;
 
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   return -EOPNOTSUPP;
+
switch (args->caching) {
case I915_CACHING_NONE:
level = I915_CACHE_NONE;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 37d1efcd3ca6..cad4a6017f4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -601,7 +601,14 @@ static int shmem_object_init(struct intel_memory_region 
*mem,
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
 
-   if (HAS_LLC(i915))
+   /*
+* MTL doesn't snoop CPU cache by default for GPU access (namely
+* 1-way coherency). However some UMD's are currently depending on
+* that. Make 1-way coherent the default setting for MTL. A follow
+* up patch will extend the GEM_CREATE uAPI to allow UMD's specify
+* caching mode at BO creation time
+*/
+   if (HAS_LLC(i915) || (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)))
/* On some devices, we can have the GPU use the LLC (the CPU
 * cache) for about a 10% performance improvement
 * compared to uncached.  Graphics requests other than
-- 
2.25.1

[PATCH v3 3/5] drm/i915: make sure correct pte encode is used

[fei . yang]

From: Fei Yang 

PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.

Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index ee52e5833c50..81b7725812ce 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,9 +55,9 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
 }
 
-static u64 mtl_pte_encode(dma_addr_t addr,
- unsigned int pat_index,
- u32 flags)
+static u64 gen12_pte_encode(dma_addr_t addr,
+   unsigned int pat_index,
+   u32 flags)
 {
gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
 
@@ -994,8 +994,8 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 */
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
-   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
-   ppgtt->vm.pte_encode = mtl_pte_encode;
+   if (GRAPHICS_VER(gt->i915) >= 12)
+   ppgtt->vm.pte_encode = gen12_pte_encode;
else
ppgtt->vm.pte_encode = gen8_pte_encode;
 
-- 
2.25.1

[PATCH v3 1/5] drm/i915: preparation for using PAT index

[fei . yang]

From: Fei Yang 

This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.

Preparing the transition by adding some platform dependent data structures
and helper functions to translate the cache_level to pat_index.

cachelevel_to_pat: a platform dependent array mapping cache_level to
   pat_index.

max_pat_index: the maximum PAT index recommended in hardware specification
   Needed for validating the PAT index passed in from user
   space.

i915_gem_get_pat_index: function to convert cache_level to PAT index.

obj_to_i915(obj): macro moved to header file for wider usage.

I915_MAX_CACHE_LEVEL: upper bound of i915_cache_level for the
  convenience of coding.

Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  9 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  4 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 -
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  6 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  6 ++
 drivers/gpu/drm/i915/i915_pci.c   | 79 ---
 drivers/gpu/drm/i915/intel_device_info.h  |  5 ++
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  9 +++
 9 files changed, 110 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 4666bb82f312..8c70a0ec7d2f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -45,6 +45,15 @@ static struct kmem_cache *slab_objects;
 
 static const struct drm_gem_object_funcs i915_gem_object_funcs;
 
+unsigned int i915_gem_get_pat_index(struct drm_i915_private *i915,
+   enum i915_cache_level level)
+{
+   if (drm_WARN_ON(>drm, level >= I915_MAX_CACHE_LEVEL))
+   return 0;
+
+   return INTEL_INFO(i915)->cachelevel_to_pat[level];
+}
+
 struct drm_i915_gem_object *i915_gem_object_alloc(void)
 {
struct drm_i915_gem_object *obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 885ccde9dc3c..4c92e17b4337 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,6 +20,8 @@
 
 enum intel_region_id;
 
+#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
+
 static inline bool i915_gem_object_size_2big(u64 size)
 {
struct drm_i915_gem_object *obj;
@@ -30,6 +32,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
return false;
 }
 
+unsigned int i915_gem_get_pat_index(struct drm_i915_private *i915,
+   enum i915_cache_level level);
 void i915_gem_init__objects(struct drm_i915_private *i915);
 
 void i915_objects_module_exit(void);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 830c11431ee8..41b35abccf88 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -194,6 +194,7 @@ enum i915_cache_level {
 * engine.
 */
I915_CACHE_WT,
+   I915_MAX_CACHE_LEVEL,
 };
 
 enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index b1672e054b21..214763942aa2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -460,8 +460,6 @@ void i915_gem_shrinker_taints_mutex(struct drm_i915_private 
*i915,
fs_reclaim_release(GFP_KERNEL);
 }
 
-#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
-
 /**
  * i915_gem_object_make_unshrinkable - Hide the object from the shrinker. By
  * default all object types that support shrinking(see IS_SHRINKABLE), will 
also
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4c9a2f2db908..4c6b760d4774 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -78,6 +78,12 @@ static u64 mtl_pte_encode(dma_addr_t addr,
case I915_CACHE_WT:
pte |= GEN12_PPGTT_PTE_PAT0;
break;
+   default:
+   /* This should never happen. Added to deal with the compile
+* error due to the addition of I915_MAX_CACHE_LEVEL. Will
+* be removed by the pat_index patch.
+*/
+   break;
}
 
return pte;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 20915edc8bd9..c8390d03fce2 100644
--- 

[PATCH v3 5/5] drm/i915: Allow user to set cache at BO creation

[fei . yang]

From: Fei Yang 

To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.

Cc: Chris Wilson 
Cc: Matt Roper 
Cc: Andi Shyti 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 include/uapi/drm/i915_drm.h| 36 ++
 tools/include/uapi/drm/i915_drm.h  | 36 ++
 4 files changed, 114 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index bfe1dbda4cb7..723c3ddd6c74 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -245,6 +245,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   unsigned int pat_index;
 };
 
 static void repr_placements(char *buf, size_t size,
@@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
 
+static int ext_set_pat(struct i915_user_extension __user *base, void *data)
+{
+   struct create_ext *ext_data = data;
+   struct drm_i915_private *i915 = ext_data->i915;
+   struct drm_i915_gem_create_ext_set_pat ext;
+   unsigned int max_pat_index;
+
+   BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
+offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
+
+   if (copy_from_user(, base, sizeof(ext)))
+   return -EFAULT;
+
+   max_pat_index = INTEL_INFO(i915)->max_pat_index;
+
+   if (ext.pat_index > max_pat_index) {
+   drm_dbg(>drm, "PAT index is invalid: %u\n",
+   ext.pat_index);
+   return -EINVAL;
+   }
+
+   ext_data->pat_index = ext.pat_index;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
 };
 
+#define PAT_INDEX_NOT_SET  0x
 /**
  * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle to 
it.
  * @dev: drm device pointer
@@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
 
+   ext_data.pat_index = PAT_INDEX_NOT_SET;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
   create_extensions,
   ARRAY_SIZE(create_extensions),
@@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (IS_ERR(obj))
return PTR_ERR(obj);
 
+   if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
+   i915_gem_object_set_pat_index(obj, ext_data.pat_index);
+   /* Mark pat_index is set by UMD */
+   obj->cache_level = I915_CACHE_INVAL;
+   }
+
return i915_gem_publish(obj, file, >size, >handle);
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 27c948350b5b..61651f7e5806 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -209,6 +209,12 @@ bool i915_gem_object_can_bypass_llc(struct 
drm_i915_gem_object *obj)
if (!(obj->flags & I915_BO_ALLOC_USER))
return false;
 
+   /*
+* Always flush cache for UMD objects at creation time.
+*/
+   if (obj->cache_level == I915_CACHE_INVAL)
+   return true;
+
/*
 * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
 * possible for userspace to bypass the GTT caching bits set by the
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index dba7c5a5b25e..03c5c314846e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3630,9 +3630,13 @@ struct drm_i915_gem_create_ext {
 *
 * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see
 * struct drm_i915_gem_create_ext_protected_content.
+*
+* For 

[PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation

[fei . yang]

From: Fei Yang 

The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.

This series is focusing on uAPI changes,
1. end support for set caching ioctl [PATCH 4/5]
2. add set_pat extension for gem_create [PATCH 5/5]

v2: drop one patch that was merged separately
341ad0e8e254 drm/i915/mtl: Add PTE encode function
v3: rebase on https://patchwork.freedesktop.org/series/117082/

Fei Yang (5):
  drm/i915: preparation for using PAT index
  drm/i915: use pat_index instead of cache_level
  drm/i915: make sure correct pte encode is used
  drm/i915/mtl: end support for set caching ioctl
  drm/i915: Allow user to set cache at BO creation

 drivers/gpu/drm/i915/display/intel_dpt.c  | 12 +--
 drivers/gpu/drm/i915/gem/i915_gem_create.c| 36 +
 drivers/gpu/drm/i915/gem/i915_gem_domain.c| 46 ++-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 67 +++-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  8 ++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 26 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  9 ++-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 16 ++--
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  | 10 ++-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 73 +
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h  |  3 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 76 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 20 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 47 ++-
 drivers/gpu/drm/i915/gt/intel_migrate.h   | 13 ++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 +--
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  8 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++-
 drivers/gpu/drm/i915/i915_debugfs.c   | 55 ++---
 drivers/gpu/drm/i915/i915_gem.c   | 16 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 +-
 drivers/gpu/drm/i915/i915_pci.c   | 79 ---
 drivers/gpu/drm/i915/i915_vma.c   | 16 ++--
 drivers/gpu/drm/i915/i915_vma.h   |  2 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  2 -
 drivers/gpu/drm/i915/intel_device_info.h  |  5 ++
 drivers/gpu/drm/i915/selftests/i915_gem.c |  5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++--
 .../drm/i915/selftests/intel_memory_region.c  |  4 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  9 +++
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  8 +-
 include/uapi/drm/i915_drm.h   | 36 +
 tools/include/uapi/drm/i915_drm.h | 36 +
 44 files changed, 621 insertions(+), 243 deletions(-)

-- 
2.25.1

[PATCH v3 1/3] drm/i915: preparation for using PAT index

[fei . yang]

From: Fei Yang 

This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.

Preparing the transition by adding some platform dependent data structures
and helper functions to translate the cache_level to pat_index.

cachelevel_to_pat: a platform dependent array mapping cache_level to
   pat_index.

max_pat_index: the maximum PAT index recommended in hardware specification
   Needed for validating the PAT index passed in from user
   space.

i915_gem_get_pat_index: function to convert cache_level to PAT index.

obj_to_i915(obj): macro moved to header file for wider usage.

I915_MAX_CACHE_LEVEL: upper bound of i915_cache_level for the
  convenience of coding.

Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  9 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  4 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 -
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  6 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  6 ++
 drivers/gpu/drm/i915/i915_pci.c   | 79 ---
 drivers/gpu/drm/i915/intel_device_info.h  |  5 ++
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  9 +++
 9 files changed, 110 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 4666bb82f312..8c70a0ec7d2f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -45,6 +45,15 @@ static struct kmem_cache *slab_objects;
 
 static const struct drm_gem_object_funcs i915_gem_object_funcs;
 
+unsigned int i915_gem_get_pat_index(struct drm_i915_private *i915,
+   enum i915_cache_level level)
+{
+   if (drm_WARN_ON(>drm, level >= I915_MAX_CACHE_LEVEL))
+   return 0;
+
+   return INTEL_INFO(i915)->cachelevel_to_pat[level];
+}
+
 struct drm_i915_gem_object *i915_gem_object_alloc(void)
 {
struct drm_i915_gem_object *obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 885ccde9dc3c..4c92e17b4337 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,6 +20,8 @@
 
 enum intel_region_id;
 
+#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
+
 static inline bool i915_gem_object_size_2big(u64 size)
 {
struct drm_i915_gem_object *obj;
@@ -30,6 +32,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
return false;
 }
 
+unsigned int i915_gem_get_pat_index(struct drm_i915_private *i915,
+   enum i915_cache_level level);
 void i915_gem_init__objects(struct drm_i915_private *i915);
 
 void i915_objects_module_exit(void);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 830c11431ee8..41b35abccf88 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -194,6 +194,7 @@ enum i915_cache_level {
 * engine.
 */
I915_CACHE_WT,
+   I915_MAX_CACHE_LEVEL,
 };
 
 enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index b1672e054b21..214763942aa2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -460,8 +460,6 @@ void i915_gem_shrinker_taints_mutex(struct drm_i915_private 
*i915,
fs_reclaim_release(GFP_KERNEL);
 }
 
-#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
-
 /**
  * i915_gem_object_make_unshrinkable - Hide the object from the shrinker. By
  * default all object types that support shrinking(see IS_SHRINKABLE), will 
also
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4c9a2f2db908..4c6b760d4774 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -78,6 +78,12 @@ static u64 mtl_pte_encode(dma_addr_t addr,
case I915_CACHE_WT:
pte |= GEN12_PPGTT_PTE_PAT0;
break;
+   default:
+   /* This should never happen. Added to deal with the compile
+* error due to the addition of I915_MAX_CACHE_LEVEL. Will
+* be removed by the pat_index patch.
+*/
+   break;
}
 
return pte;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 20915edc8bd9..c8390d03fce2 100644
--- 

[PATCH v3 3/3] drm/i915: make sure correct pte encode is used

[fei . yang]

From: Fei Yang 

PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.

Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index ee52e5833c50..81b7725812ce 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,9 +55,9 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
 }
 
-static u64 mtl_pte_encode(dma_addr_t addr,
- unsigned int pat_index,
- u32 flags)
+static u64 gen12_pte_encode(dma_addr_t addr,
+   unsigned int pat_index,
+   u32 flags)
 {
gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
 
@@ -994,8 +994,8 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 */
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
-   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
-   ppgtt->vm.pte_encode = mtl_pte_encode;
+   if (GRAPHICS_VER(gt->i915) >= 12)
+   ppgtt->vm.pte_encode = gen12_pte_encode;
else
ppgtt->vm.pte_encode = gen8_pte_encode;
 
-- 
2.25.1

[PATCH v3 0/3] drm/i915: use pat_index instead of cache_level

[fei . yang]

From: Fei Yang 

This patch set was posted at
https://patchwork.freedesktop.org/series/116868/
Change title since the PTE patch was merged separately.

These patches are extracted from series
https://patchwork.freedesktop.org/series/115980/

This series refactor the cache policy programming so that the PTE
encode functions can be unified across all GEN12 platforms. This
refactor is also important in implementing the design which allows
uerspace to directly set cache policy for each Buffer Object.

v2: drop one patch that was merged separately
341ad0e8e254 drm/i915/mtl: Add PTE encode function
v3: disable {get, set}_caching ioctl

Fei Yang (3):
  drm/i915: preparation for using PAT index
  drm/i915: use pat_index instead of cache_level
  drm/i915: make sure correct pte encode is used

 drivers/gpu/drm/i915/display/intel_dpt.c  | 12 +--
 drivers/gpu/drm/i915/gem/i915_gem_domain.c| 43 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 61 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  8 ++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 26 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 16 ++--
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  | 10 ++-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 73 +
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h  |  3 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 76 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 20 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 47 ++-
 drivers/gpu/drm/i915/gt/intel_migrate.h   | 13 ++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 +--
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  8 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++-
 drivers/gpu/drm/i915/i915_debugfs.c   | 55 ++---
 drivers/gpu/drm/i915/i915_gem.c   | 16 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 +-
 drivers/gpu/drm/i915/i915_pci.c   | 79 ---
 drivers/gpu/drm/i915/i915_vma.c   | 16 ++--
 drivers/gpu/drm/i915/i915_vma.h   |  2 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  2 -
 drivers/gpu/drm/i915/intel_device_info.h  |  5 ++
 drivers/gpu/drm/i915/selftests/i915_gem.c |  5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++--
 .../drm/i915/selftests/intel_memory_region.c  |  4 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  9 +++
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  8 +-
 40 files changed, 496 insertions(+), 242 deletions(-)

-- 
2.25.1

[PATCH v3 2/3] drm/i915: use pat_index instead of cache_level

[fei . yang]

From: Fei Yang 

Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.

>From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity.

For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For such simple cases, using cache_level
would help simplify the code.

Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/display/intel_dpt.c  | 12 +--
 drivers/gpu/drm/i915/gem/i915_gem_domain.c| 43 ++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 52 +++-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  4 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 25 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 16 ++--
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  | 10 ++-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 71 
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h  |  3 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 82 +--
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 20 ++---
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 47 ++-
 drivers/gpu/drm/i915/gt/intel_migrate.h   | 13 ++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 ++-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  8 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++-
 drivers/gpu/drm/i915/i915_debugfs.c   | 55 ++---
 drivers/gpu/drm/i915/i915_gem.c   | 16 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 +-
 drivers/gpu/drm/i915/i915_vma.c   | 16 ++--
 drivers/gpu/drm/i915/i915_vma.h   |  2 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  2 -
 drivers/gpu/drm/i915/selftests/i915_gem.c |  5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++--
 .../drm/i915/selftests/intel_memory_region.c  |  4 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  8 +-
 36 files changed, 394 insertions(+), 239 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index c5eacfdba1a5..7c5fddb203ba 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -43,24 +43,24 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)
 static void dpt_insert_page(struct i915_address_space *vm,
dma_addr_t addr,
u64 offset,
-   enum i915_cache_level level,
+   unsigned int pat_index,
u32 flags)
 {
struct i915_dpt *dpt = i915_vm_to_dpt(vm);
gen8_pte_t __iomem *base = dpt->iomem;
 
gen8_set_pte(base + offset / I915_GTT_PAGE_SIZE,
-vm->pte_encode(addr, level, flags));
+vm->pte_encode(addr, pat_index, flags));
 }
 
 static void dpt_insert_entries(struct i915_address_space *vm,
   struct i915_vma_resource *vma_res,
-  enum i915_cache_level level,
+  unsigned int pat_index,
   u32 flags)
 {
struct i915_dpt *dpt = i915_vm_to_dpt(vm);
gen8_pte_t __iomem *base = dpt->iomem;
-   const gen8_pte_t pte_encode = vm->pte_encode(0, level, flags);
+   const gen8_pte_t pte_encode = vm->pte_encode(0, pat_index, flags);
struct sgt_iter sgt_iter;
dma_addr_t addr;
int i;
@@ -83,7 +83,7 @@ static void dpt_clear_range(struct i915_address_space *vm,
 static void dpt_bind_vma(struct i915_address_space *vm,
 struct i915_vm_pt_stash *stash,
 

RE: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Ye, 
> Tony
> Sent: perjantai 28. huhtikuuta 2023 6.11
> To: Ceraolo Spurio, Daniele ; intel-
> g...@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; dri-
> de...@lists.freedesktop.org; Zhang, Carl 
> Subject: Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication 
> for
> MTL
> 
> Acked-by: Tony Ye 
CI results would be also good to look at before... 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/index.html?
For some reason no single MTL tests and many aborts...

> 
> Thanks,
> 
> Tony
> 
> On 4/27/2023 7:34 PM, Daniele Ceraolo Spurio wrote:
> > The HuC loading and authentication flow is once again changing and a
> > new "clear-media only" authentication step is introduced. The flow is
> > as
> > follows:
> >
> > 1) The HuC is loaded via DMA - same as all non-GSC HuC binaries.
> >
> > 2) The HuC is authenticated by the GuC - this is the same step as
> > performed for all non-GSC HuC binaries and re-uses the same code, but
> > it is now resulting in a partial authentication that only allows
> > clear-media workloads.
> >
> > 3) The HuC is fully authenticated for all workloads by the GSC - this
> > is done via a new PXP command, submitted via the GSCCS.
> >
> > The advantage of this new flow is that we can start processing
> > clear-media workloads without having to wait for the GSC to be ready,
> > which can take several seconds.
> >
> > As part of this change, the HuC status getparam has been updated with
> > a new value to indicate a partial authentication. Note tha the media
> > driver is checking for value > 0 for clear media workloads, so no
> > changes are required in userspace for that to work.
> >
> > The SW proxy series [1] has been included, squashed in a single patch,
> > as some of some of the patches in this series depend on it. This is
> > not a functional dependencies, the patches just touch the same code;
> > the proxy patches are planned to be merged first, so it is easier to
> > base the new patches on top of it to avoid having to rebase them later.
> >
> > [1]https://patchwork.freedesktop.org/series/115806/
> > Cc: Alan Previn
> > Cc: Tony Ye
> >
> > Daniele Ceraolo Spurio (8):
> >DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
> >drm/i915/uc: perma-pin firmwares
> >drm/i915/huc: Parse the GSC-enabled HuC binary
> >drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
> >drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
> >drm/i915/mtl/huc: auth HuC via GSC
> >drm/i915/mtl/huc: Use the media gt for the HuC getparam
> >drm/i915/huc: define HuC FW version for MTL
> >
> >   drivers/gpu/drm/i915/Makefile |   1 +
> >   drivers/gpu/drm/i915/gt/intel_ggtt.c  |   3 +
> >   drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
> >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
> >   .../drm/i915/gt/uc/intel_gsc_meu_headers.h|  74 +++
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  89 +++-
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
> >   .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |   2 +-
> >   .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 +---
> >   drivers/gpu/drm/i915/gt/uc/intel_huc.h|  26 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 214 -
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   6 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_print.h  |  21 +
> >   drivers/gpu/drm/i915/gt/uc/intel_uc.c |  10 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_uc.h |   2 +
> >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 120 ++---
> >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   9 +-
> >   drivers/gpu/drm/i915/i915_getparam.c  |   6 +-
> >   drivers/gpu/drm/i915/i915_reg.h   |   3 +
> >   .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  14 +-
> >   drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |   2 +-
> >   drivers/misc/mei/Kconfig  |   2 +-
> >   drivers/misc/mei/Makefile |   1 +
> >   drivers/misc/mei/gsc_proxy/Kconfig|  14 +
> >   drivers/misc/mei/gsc_proxy/Makefile   |   7 +
> >   drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
> >   include/drm/i915_component.h  |   3 +-
> >   include/drm/i915_gsc_proxy_mei_interface.h|  53 +++
> >   include/uapi/drm/i915_drm.h   |   3 +-
> >   33 files changed, 1428 insertions(+), 134 deletions(-)
> >   create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
> >   create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
> >   create mode 100644 

Re: [PATCH 0/8] drm/i915: HuC loading and authentication for MTL

[Ye, Tony]

Acked-by: Tony Ye 

Thanks,

Tony

On 4/27/2023 7:34 PM, Daniele Ceraolo Spurio wrote:

The HuC loading and authentication flow is once again changing and a new
"clear-media only" authentication step is introduced. The flow is as
follows:

1) The HuC is loaded via DMA - same as all non-GSC HuC binaries.

2) The HuC is authenticated by the GuC - this is the same step as
performed for all non-GSC HuC binaries and re-uses the same code, but
it is now resulting in a partial authentication that only allows
clear-media workloads.

3) The HuC is fully authenticated for all workloads by the GSC - this
is done via a new PXP command, submitted via the GSCCS.

The advantage of this new flow is that we can start processing
clear-media workloads without having to wait for the GSC to be ready,
which can take several seconds.

As part of this change, the HuC status getparam has been updated with a
new value to indicate a partial authentication. Note tha the media
driver is checking for value > 0 for clear media workloads, so no
changes are required in userspace for that to work.

The SW proxy series [1] has been included, squashed in a single patch,
as some of some of the patches in this series depend on it. This is not
a functional dependencies, the patches just touch the same code; the
proxy patches are planned to be merged first, so it is easier to base
the new patches on top of it to avoid having to rebase them later.

[1]https://patchwork.freedesktop.org/series/115806/
Cc: Alan Previn
Cc: Tony Ye

Daniele Ceraolo Spurio (8):
   DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
   drm/i915/uc: perma-pin firmwares
   drm/i915/huc: Parse the GSC-enabled HuC binary
   drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
   drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
   drm/i915/mtl/huc: auth HuC via GSC
   drm/i915/mtl/huc: Use the media gt for the HuC getparam
   drm/i915/huc: define HuC FW version for MTL

  drivers/gpu/drm/i915/Makefile |   1 +
  drivers/gpu/drm/i915/gt/intel_ggtt.c  |   3 +
  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
  .../drm/i915/gt/uc/intel_gsc_meu_headers.h|  74 +++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
  drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  89 +++-
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
  .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |   2 +-
  .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
  drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 +---
  drivers/gpu/drm/i915/gt/uc/intel_huc.h|  26 +-
  drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 214 -
  drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   6 +-
  drivers/gpu/drm/i915/gt/uc/intel_huc_print.h  |  21 +
  drivers/gpu/drm/i915/gt/uc/intel_uc.c |  10 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc.h |   2 +
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 120 ++---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   9 +-
  drivers/gpu/drm/i915/i915_getparam.c  |   6 +-
  drivers/gpu/drm/i915/i915_reg.h   |   3 +
  .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  14 +-
  drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |   2 +-
  drivers/misc/mei/Kconfig  |   2 +-
  drivers/misc/mei/Makefile |   1 +
  drivers/misc/mei/gsc_proxy/Kconfig|  14 +
  drivers/misc/mei/gsc_proxy/Makefile   |   7 +
  drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
  include/drm/i915_component.h  |   3 +-
  include/drm/i915_gsc_proxy_mei_interface.h|  53 +++
  include/uapi/drm/i915_drm.h   |   3 +-
  33 files changed, 1428 insertions(+), 134 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
  create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
  create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
  create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
  create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h

Re: [PATCH] Documentation: vkms: clarify devres managed refernce cleanup

[Brandon Ross Pollack]

On Thu, Apr 27, 2023 at 7:02 PM Daniel Vetter  wrote:
>
> On Tue, Apr 25, 2023 at 08:02:40AM +, Brandon Pollack wrote:
> > added documentation to drm_dev_unregister clarifying that devres managed
> > devices allocated with devm_drm_dev_alloc do not require calls to
> > drm_dev_put.
> >
> > Signed-off-by: Brandon Pollack 
> >
> > ---
> >
> > This is my first patch to any tree.  I've tried my best to read as many
> > kernel docs etc as possible (wip). This took me a moment to realize so I
> > figured it was as good a candidate as any for a first patch (at the very
> > least to make sure I have the whole patching process figured out).  I
> > hope to make more janitorial changes as I continue to learn leading up
> > to the work I hope to do.
> >
> > We're hoping to add multiple display hotplug output support to VKMS for
> > testing purposes.  Some work has been done already, but we'll be taking
> > over moving forward.  Our intent is to remain involved and assist in
> > maintaining these changes.
> >
> > Looking forward to your comments/advice (now and henceforth!)
>
> Looking good!
>
> Reviewed-by: Daniel Vetter 
>
> Since you're @chromium.org I'm assuming that one of the cros committers
> will push this to drm-misc-next. If not please holler.
> -Daniel

I'm actually working in relative isolation on this (I'm located in
Tokyo) so please go ahead.  I'll get in touch with some of those folks
soon :)

>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index cee0cc522ed9..12687dd9e1ac 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -969,7 +969,9 @@ EXPORT_SYMBOL(drm_dev_register);
> >   *
> >   * Unregister the DRM device from the system. This does the reverse of
> >   * drm_dev_register() but does not deallocate the device. The caller must 
> > call
> > - * drm_dev_put() to drop their final reference.
> > + * drm_dev_put() to drop their final reference, unless it is managed with 
> > devres
> > + * (as devices allocated with devm_drm_dev_alloc() are), in which case 
> > there is
> > + * already an unwind action registered.
> >   *
> >   * A special form of unregistering for hotpluggable devices is 
> > drm_dev_unplug(),
> >   * which can be called while there are still open users of @dev.
> > --
> > 2.40.0.634.g4ca3ef3211-goog
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH v3 0/3] drm/vkms: Add support for multiple pipes

[Brandon Ross Pollack]

I'm adding the original offer of those changes.  We talked recently
and they have the intent to push forward and merge them.  I'm still
getting up to speed a bit, but I will probably have a stronger opinion
by early next week.


On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad  wrote:
>
> Hi Brandon, Xie,
>
> Thanks for reaching out, and for the heads-up. I need to take a closer
> look, but by glancing over it, using configFS would be really awesome.
> Think we could really benefit from having that in our CI and being able
> to customize the entire pipeline. I'm totally for that.
>
> It looks like it requires some infra work so I guess landing that might
> require quite a bit of time. Not sure if there are recent updates for it.
>
> My changes are quite trivial and much more focused on just having
> multiple virtual displays, so IDK, I've submitted a version that seems
> to work, so I guess others should or would decide if we should drop mine
> and focus on the configFS series, or we should go with configFS as a
> follow-up. Would have liked to get something in the tree so we can at
> least have something to work with.
>
> Thoughts on the matter on how should we go about it?
>
> On 4/26/23 05:06, Brandon Ross Pollack wrote:
> > We're doing/planning on doing similar or related work here at chromium.
> >
> > https://patchwork.kernel.org/project/dri-devel/list/?series=662676=both
> >  
> > 
> >
> > Here's the stuff we have now (we're currently rebasing and touching it
> > up, myself and @Yi Xie  will be taking over
> > this work.
> >
> > Our plans are to add configFS changes and DRI VKMS changes to be able to
> > add and remove virtual displays at runtime (among other things needed
> > for our own testing purposes for our Exo wayland implementation).
> >
> > We're still learning how this all works and comes together, but it is
> > worth letting you know "us too"
> >
> > We can chat more and see where we overlap and can learn from each other :)
> >
> > On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad  > > wrote:
> >
> > With multiple pipe available we can perform management of outputs at
> > a more granular level, such that we're able to turn off or on several
> > outputs at a time, or combinations that arise from doing that.
> >
> > The Weston project use VKMS when running its test suite in CI, and we
> > have now uses cases which would need to ability to set-up the outputs
> > DPMS/state individually, rather than globally -- which would affect all
> > outputs. This an attempt on fixing that by giving the possibility to
> > create more than one pipe, and thus allowing to run tests that could
> > exercise code paths in the compositor related to management of outputs.
> >
> > v3:
> >- Apply the series against drm-misc-next (Maíra Canal)
> >- Add a lower range check to avoid passing negative values to
> >max_pipes (Maíra Canal)
> >
> > v2:
> >- Replace 'outputs' with 'pipes' as to use the proper terminology
> >  (Thomas Zimmermann, Maíra Canal)
> >- Fixed passing wrong possible_crtc bitmask when initializing the
> >  write back connector which address kms_writeback failure (Maíra
> > Canal)
> >- Add a feat. note about moving overlay planes between CRTCs
> > (Melissa Wen)
> >
> > Marius Vlad (3):
> >vkms: Pass the correct bitmask for possible crtcs
> >vkms: Add support for multiple pipes
> >Documentation/gpu/vkms.rst: Added a note about plane migration
> >
> >   Documentation/gpu/vkms.rst|  5 +++--
> >   drivers/gpu/drm/vkms/vkms_crtc.c  |  3 +--
> >   drivers/gpu/drm/vkms/vkms_drv.c   | 31 +--
> >   drivers/gpu/drm/vkms/vkms_drv.h   | 12 ---
> >   drivers/gpu/drm/vkms/vkms_output.c|  7 +++---
> >   drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++---
> >   6 files changed, 53 insertions(+), 29 deletions(-)
> >
> > --
> > 2.39.2
> >

[PATCH 8/8] drm/i915/huc: define HuC FW version for MTL

[Daniele Ceraolo Spurio]

Follow the same logic as DG2, so just a meu binary with no version number.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3338dd45e78b..796f54a62eef 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -102,6 +102,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
fw_def(SKYLAKE,  0, guc_mmp(skl,  70, 1, 1))
 
 #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp, huc_gsc) \
+   fw_def(METEORLAKE,   0, huc_gsc(mtl)) \
fw_def(DG2,  0, huc_gsc(dg2)) \
fw_def(ALDERLAKE_P,  0, huc_raw(tgl)) \
fw_def(ALDERLAKE_P,  0, huc_mmp(tgl,  7, 9, 3)) \
-- 
2.40.0

[PATCH 7/8] drm/i915/mtl/huc: Use the media gt for the HuC getparam

[Daniele Ceraolo Spurio]

On MTL, for obvious reasons, HuC is only available on the media tile.
We already disable SW support for HuC on the root gt due to the
absence of VCS engines, but we also need to update the getparam to point
to the HuC struct in the media GT.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/i915_getparam.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..7aa47550e4f2 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -98,7 +98,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = sseu->min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
-   value = intel_huc_check_status(_gt(i915)->uc.huc);
+   /* On platform with a media GT, the HuC is on that GT */
+   if (i915->media_gt)
+   value = intel_huc_check_status(>media_gt->uc.huc);
+   else
+   value = intel_huc_check_status(_gt(i915)->uc.huc);
if (value < 0)
return value;
break;
-- 
2.40.0

[PATCH 6/8] drm/i915/mtl/huc: auth HuC via GSC

[Daniele Ceraolo Spurio]

The full authentication via the GSC requires an heci packet submission
to the GSC FW via the GSC CS. The GSC has new PXP command for this
(literally called NEW_HUC_AUTH).
The intel_huc_auth fuction is also updated to handle both authentication
types.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 24 -
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 50 +++---
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  6 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 94 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  2 +-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |  2 +-
 9 files changed, 173 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index af542e3cb3e9..b6d0ee1660b2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -29,13 +29,29 @@ static void gsc_work(struct work_struct *work)
 
if (actions & GSC_ACTION_FW_LOAD) {
ret = intel_gsc_uc_fw_upload(gsc);
-   if (ret == -EEXIST) /* skip proxy if not a new load */
-   actions &= ~GSC_ACTION_FW_LOAD;
-   else if (ret)
+   if (!ret)
+   /* setup proxy on a new load */
+   actions |= GSC_ACTION_SW_PROXY;
+   else if (ret != -EEXIST)
goto out_put;
+
+   /*
+* The HuC auth can be done both before or after the proxy init;
+* if done after, a proxy request will be issued and must be
+* serviced before the authentication can complete.
+* Since this worker also handles proxy requests, we can't
+* perform an action that requires the proxy from within it and
+* then stall waiting for it, because we'd be blocking the
+* service path. Therefore, it is easier for us to load HuC
+* first and do proxy later. The GSC will ack the HuC auth and
+* then send the HuC proxy request as part of the proxy init
+* flow.
+*/
+   if (intel_uc_uses_huc(>uc))
+   intel_huc_auth(>uc.huc, INTEL_HUC_AUTH_BY_GSC);
}
 
-   if (actions & (GSC_ACTION_FW_LOAD | GSC_ACTION_SW_PROXY)) {
+   if (actions & GSC_ACTION_SW_PROXY) {
if (!intel_gsc_uc_fw_init_done(gsc)) {
gt_err(gt, "Proxy request received with GSC not 
loaded!\n");
goto out_put;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index ea0da06e2f39..edcfa990239d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -98,7 +98,7 @@ void intel_gsc_uc_heci_cmd_emit_mtl_header(struct 
intel_gsc_mtl_header *header,
   u64 host_session_id)
 {
host_session_id &= ~HOST_SESSION_MASK;
-   if (heci_client_id == HECI_MEADDRESS_PXP)
+   if (host_session_id && heci_client_id == HECI_MEADDRESS_PXP)
host_session_id |= HOST_SESSION_PXP_SINGLE;
 
header->validity_marker = GSC_HECI_VALIDITY_MARKER;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index cc3c9cb2319c..21621d7439ba 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -347,20 +347,34 @@ static int check_huc_loading_mode(struct intel_huc *huc)
 
 int intel_huc_init(struct intel_huc *huc)
 {
+   struct intel_gt *gt = huc_to_gt(huc);
int err;
 
err = check_huc_loading_mode(huc);
if (err)
goto out;
 
+   if (HAS_ENGINE(gt, GSC0)) {
+   struct i915_vma *vma = intel_guc_allocate_vma(>uc.guc, 
SZ_8K);
+   if (IS_ERR(vma)) {
+   huc_info(huc, "Failed to allocate heci pkt\n");
+   goto out;
+   }
+
+   huc->heci_pkt = vma;
+   }
+
err = intel_uc_fw_init(>fw);
if (err)
-   goto out;
+   goto out_pkt;
 
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOADABLE);
 
return 0;
 
+out_pkt:
+   if (huc->heci_pkt)
+   i915_vma_unpin_and_release(>heci_pkt, 0);
 out:
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
huc_info(huc, "initialization failed %pe\n", ERR_PTR(err));
@@ -375,6 +389,9 @@ void intel_huc_fini(struct intel_huc *huc)
 */
delayed_huc_load_fini(huc);
 
+   if 

[PATCH 5/8] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow

[Daniele Ceraolo Spurio]

Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully authenticated only after the GSC auth
step.

To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 94 +--
 drivers/gpu/drm/i915/gt/uc/intel_huc.h| 16 +++-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c |  4 +-
 drivers/gpu/drm/i915/i915_reg.h   |  3 +
 include/uapi/drm/i915_drm.h   |  3 +-
 5 files changed, 91 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index c189ede4ef55..cc3c9cb2319c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
 #include "intel_huc.h"
 #include "intel_huc_print.h"
 #include "i915_drv.h"
+#include "i915_reg.h"
 
 #include 
 #include 
@@ -106,7 +107,7 @@ static enum hrtimer_restart 
huc_delayed_load_timer_callback(struct hrtimer *hrti
 {
struct intel_huc *huc = container_of(hrtimer, struct intel_huc, 
delayed_load.timer);
 
-   if (!intel_huc_is_authenticated(huc)) {
+   if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +125,7 @@ static void huc_delayed_load_start(struct intel_huc *huc)
 {
ktime_t delay;
 
-   GEM_BUG_ON(intel_huc_is_authenticated(huc));
+   GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
 
/*
 * On resume we don't have to wait for MEI-GSC to be re-probed, but we
@@ -284,13 +285,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
 
if (GRAPHICS_VER(i915) >= 11) {
-   huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
-   huc->status.mask = HUC_LOAD_SUCCESSFUL;
-   huc->status.value = HUC_LOAD_SUCCESSFUL;
+   huc->status[INTEL_HUC_AUTH_BY_GUC].reg = 
GEN11_HUC_KERNEL_LOAD_INFO;
+   huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+   huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_LOAD_SUCCESSFUL;
} else {
-   huc->status.reg = HUC_STATUS2;
-   huc->status.mask = HUC_FW_VERIFIED;
-   huc->status.value = HUC_FW_VERIFIED;
+   huc->status[INTEL_HUC_AUTH_BY_GUC].reg = HUC_STATUS2;
+   huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_FW_VERIFIED;
+   huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_FW_VERIFIED;
+   }
+
+   if (IS_DG2(i915)) {
+   huc->status[INTEL_HUC_AUTH_BY_GSC].reg = 
GEN11_HUC_KERNEL_LOAD_INFO;
+   huc->status[INTEL_HUC_AUTH_BY_GSC].mask = HUC_LOAD_SUCCESSFUL;
+   huc->status[INTEL_HUC_AUTH_BY_GSC].value = HUC_LOAD_SUCCESSFUL;
+   } else {
+   huc->status[INTEL_HUC_AUTH_BY_GSC].reg = 
HECI_FWSTS5(MTL_GSC_HECI1_BASE);
+   huc->status[INTEL_HUC_AUTH_BY_GSC].mask = 
HECI_FWSTS5_HUC_AUTH_DONE;
+   huc->status[INTEL_HUC_AUTH_BY_GSC].value = 
HECI_FWSTS5_HUC_AUTH_DONE;
}
 }
 
@@ -381,28 +392,39 @@ void intel_huc_suspend(struct intel_huc *huc)
delayed_huc_load_complete(huc);
 }
 
-int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
+static const char *auth_mode_string(struct intel_huc *huc,
+   enum intel_huc_authentication_type type)
+{
+   bool partial = !huc->loaded_via_gsc && huc->fw.is_meu_binary &&
+  type == INTEL_HUC_AUTH_BY_GUC;
+
+   return partial ? "clear media" : "all workloads";
+}
+
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc,
+enum intel_huc_authentication_type type)
 {
struct intel_gt *gt = huc_to_gt(huc);
int ret;
 
ret = __intel_wait_for_register(gt->uncore,
-   huc->status.reg,
-   huc->status.mask,
-   huc->status.value,
+   huc->status[type].reg,
+   huc->status[type].mask,
+   huc->status[type].value,
2, 50, NULL);
 
/* mark the load process as complete even if the wait failed */
delayed_huc_load_complete(huc);
 
if (ret) {
-   huc_err(huc, "firmware 

[PATCH 4/8] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so

[Daniele Ceraolo Spurio]

In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "MEU binary" for
clarity, while the latter is now based on the fuse instead of the binary
format. This way, all the legacy load paths are automatically taken
(including the auth by GuC) without having to implement further code
changes.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 27 ++-
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  4 +++-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 14 ++--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  2 +-
 5 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 062ff914b274..c189ede4ef55 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
 static int check_huc_loading_mode(struct intel_huc *huc)
 {
struct intel_gt *gt = huc_to_gt(huc);
-   bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
-   bool hw_uses_gsc = false;
+   bool fw_is_meu = huc->fw.is_meu_binary;
 
/*
 * The fuse for HuC load via GSC is only valid on platforms that have
 * GuC deprivilege.
 */
if (HAS_GUC_DEPRIVILEGE(gt->i915))
-   hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+   huc->loaded_via_gsc = intel_uncore_read(gt->uncore, 
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
 
-   if (fw_needs_gsc != hw_uses_gsc) {
-   huc_err(huc, "mismatch between FW (%s) and HW (%s) load 
modes\n",
-   HUC_LOAD_MODE_STRING(fw_needs_gsc), 
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+   if (huc->loaded_via_gsc && !fw_is_meu) {
+   huc_err(huc, "HW requires a MEU blob, but we found a legacy 
one\n");
return -ENOEXEC;
}
 
-   /* make sure we can access the GSC via the mei driver if we need it */
+   /*
+* Newer meu blobs contain the old FW structure inside. If we found
+* that, we can use it to load the legacy way.
+*/
+   if (!huc->loaded_via_gsc && fw_is_meu && !huc->fw.dma_start_offset) {
+   huc_err(huc," HW in legacy mode, but we have an incompatible 
meu blob\n");
+   return -ENOEXEC;
+   }
+
+   /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && 
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
-   fw_needs_gsc) {
+   !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
huc_info(huc, "can't load due to missing MEI modules\n");
return -EIO;
}
 
-   huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+   huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(huc->loaded_via_gsc));
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index db555b3c1f56..345e1b9aa062 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -39,6 +39,8 @@ struct intel_huc {
struct notifier_block nb;
enum intel_huc_delayed_load_status status;
} delayed_load;
+
+   bool loaded_via_gsc;
 };
 
 int intel_huc_sanitize(struct intel_huc *huc);
@@ -73,7 +75,7 @@ static inline bool intel_huc_is_used(struct intel_huc *huc)
 
 static inline bool intel_huc_is_loaded_by_gsc(const struct intel_huc *huc)
 {
-   return huc->fw.loaded_via_gsc;
+   return huc->loaded_via_gsc;
 }
 
 static inline bool intel_huc_wait_required(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index f1c973e1c676..88ad2c322c4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -34,7 +34,7 @@ int intel_huc_fw_get_binary_info(struct intel_uc_fw *huc_fw, 
const void *data, s
size_t min_size = sizeof(*header);
int i;
 
-   if (!huc_fw->loaded_via_gsc) {
+   if (!huc_fw->is_meu_binary) {
huc_err(huc, "Invalid FW type MEU parsing!\n");
return -EINVAL;
}
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 da6fcfe1d80a..3338dd45e78b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -180,7 +180,7 @@ struct __packed uc_fw_blob {
u8 major;
u8 minor;

[PATCH 2/8] drm/i915/uc: perma-pin firmwares

[Daniele Ceraolo Spurio]

Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Given that we use dummy vmas for the pinning, we do need to explicitly
re-pin on resume because the automated helper won't cover us.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  3 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  7 -
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c|  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  8 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 36 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  5 +++-
 8 files changed, 53 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 20915edc8bd9..ab71ed11de79 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1322,6 +1322,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
ggtt->vm.scratch_range(>vm, ggtt->error_capture.start,
   ggtt->error_capture.size);
 
+   list_for_each_entry(gt, >gt_list, ggtt_link)
+   intel_uc_resume_mappings(>uc);
+
ggtt->invalidate(ggtt);
 
if (flush)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 64bff01026e8..af542e3cb3e9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -80,7 +80,12 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
 {
struct intel_gt *gt = gsc_uc_to_gt(gsc);
 
-   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+   /*
+* GSC FW needs to be copied to a dedicated memory allocations for
+* loading (see gsc->local), so we don't need to GGTT map the FW image
+* itself into GGTT.
+*/
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC, false);
INIT_WORK(>work, gsc_work);
 
/* we can arrive here from i915_driver_early_probe for primary
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c9f20385f6a0..2eb891b270ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -164,7 +164,7 @@ void intel_guc_init_early(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
 
-   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC);
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC, true);
intel_guc_ct_init_early(>ct);
intel_guc_log_init_early(>log);
intel_guc_submission_init_early(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index aefdaa62da99..9721761373fb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -276,7 +276,7 @@ void intel_huc_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
struct intel_gt *gt = huc_to_gt(huc);
 
-   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC);
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC, true);
 
/*
 * we always init the fence as already completed, even if HuC is not
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 996168312340..b6adfda3761e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -697,6 +697,12 @@ void intel_uc_suspend(struct intel_uc *uc)
}
 }
 
+static void __uc_resume_mappings(struct intel_uc *uc)
+{
+   intel_uc_fw_resume_mapping(>guc.fw);
+   intel_uc_fw_resume_mapping(>huc.fw);
+}
+
 static int __uc_resume(struct intel_uc *uc, bool enable_communication)
 {
struct intel_guc *guc = >guc;
@@ -764,4 +770,6 @@ static const struct intel_uc_ops uc_ops_on = {
 
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
+
+   .resume_mappings = __uc_resume_mappings,
 };
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 5d0f1bcc381e..c2783e6e752b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -24,6 +24,7 @@ struct intel_uc_ops {
void (*fini)(struct intel_uc *uc);
int (*init_hw)(struct intel_uc *uc);
void (*fini_hw)(struct intel_uc *uc);
+   void (*resume_mappings)(struct intel_uc *uc);
 };
 
 struct intel_uc {
@@ -113,6 +114,7 @@ intel_uc_ops_function(init, init, int, 0);
 intel_uc_ops_function(fini, fini, void, );
 intel_uc_ops_function(init_hw, init_hw, int, 0);
 intel_uc_ops_function(fini_hw, fini_hw, 

[PATCH 3/8] drm/i915/huc: Parse the GSC-enabled HuC binary

[Daniele Ceraolo Spurio]

The new binaries that support the 2-step authentication have contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the meu
manifest of the GSC binary. The manifest consist of a partition header
followed by entries, one of which contains the offset we're looking for.
Since we're now parsing the entries, we can extract the HuC version
that way instead of using hardcoded offsets.

Note that the meu structure will be re-used for parsing the GSC binary,
so they've been added in their own header.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 .../drm/i915/gt/uc/intel_gsc_meu_headers.h|  74 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc.c|  11 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 116 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   5 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h  |  21 
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  71 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   2 +
 7 files changed, 253 insertions(+), 47 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
new file mode 100644
index ..df9c482a8052
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_MEU_H_
+#define _INTEL_GSC_MEU_H_
+
+#include 
+
+/* Code partition structures */
+struct intel_gsc_cpt_directory_header_v2 {
+   u32 header_marker;
+#define INTEL_GSC_CPT_HEADER_MARKER 0x44504324
+
+   u32 num_of_entries;
+   u8 header_version;
+   u8 entry_version;
+   u8 header_length; /* in bytes */
+   u8 flags;
+   u32 partition_name;
+   u32 crc32;
+} __packed;
+
+struct intel_gsc_cpt_directory_entry {
+   u8 name[12];
+
+   /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+   u32 offset;
+#define INTEL_GSC_CPT_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPT_ENTRY_HUFFMAN_COMP BIT(25)
+
+   /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+   u32 length;
+
+   u8 reserved[4];
+} __packed;
+
+struct intel_gsc_meu_version {
+   u16 major;
+   u16 minor;
+   u16 hotfix;
+   u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+   u32 header_type; /* 0x4 for manifest type */
+   u32 header_length; /* in dwords */
+   u32 header_version;
+   u32 flags;
+   u32 vendor;
+   u32 date;
+   u32 size; /* In dwords, size of entire manifest (header + extensions) */
+   u32 header_id;
+   u32 internal_data;
+   struct intel_gsc_meu_version fw_version;
+   u32 security_version;
+   struct intel_gsc_meu_version meu_kit_version;
+   u32 meu_manifest_version;
+   u8 general_data[4];
+   u8 reserved3[56];
+   u32 modulus_size; /* in dwords */
+   u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 9721761373fb..062ff914b274 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
 #include 
 
 #include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
 #include "intel_guc_reg.h"
 #include "intel_huc.h"
+#include "intel_huc_print.h"
 #include "i915_drv.h"
 
 #include 
 #include 
 
-#define huc_printk(_huc, _level, _fmt, ...) \
-   gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...)   huc_printk((_huc), err, _fmt, 
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...)  huc_printk((_huc), warn, _fmt, 
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt, 
##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...)  huc_printk((_huc), info, _fmt, 
##__VA_ARGS__)
-#define huc_dbg(_huc, _fmt, ...)   huc_printk((_huc), dbg, _fmt, 
##__VA_ARGS__)
-#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt, 
##__VA_ARGS__)
-
 /**
  * DOC: HuC
  *
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 534b0aa43316..f1c973e1c676 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -5,11 +5,127 @@
 
 #include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
+#include "intel_gsc_meu_headers.h"
 #include "intel_huc.h"
 #include "intel_huc_fw.h"
+#include 

[PATCH 1/8] DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy

[Daniele Ceraolo Spurio]

This is a squash of the GSC proxy series, which is being reviewed
separately [1]. It's being included here because some of the patches in
this series depend on it. This is not a functional dependencies, the
patches just touch the same code and the proxy patches are planned to be
merged first, so it is easier to base the new patches on top of it.

[1] https://patchwork.freedesktop.org/series/115806/
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  66 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
 drivers/misc/mei/Kconfig  |   2 +-
 drivers/misc/mei/Makefile |   1 +
 drivers/misc/mei/gsc_proxy/Kconfig|  14 +
 drivers/misc/mei/gsc_proxy/Makefile   |   7 +
 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
 include/drm/i915_component.h  |   3 +-
 include/drm/i915_gsc_proxy_mei_interface.h|  53 +++
 15 files changed, 830 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h
 create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
 create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
 create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
 create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..f2ac803e35b4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -194,6 +194,7 @@ i915-y += \
 # general-purpose microcontroller (GuC) support
 i915-y += \
  gt/uc/intel_gsc_fw.o \
+ gt/uc/intel_gsc_proxy.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_gsc_uc_heci_cmd_submit.o\
  gt/uc/intel_guc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c0f3ff4746ad..95e59ed6651d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -16,6 +16,7 @@
 #include "intel_uncore.h"
 #include "intel_rps.h"
 #include "pxp/intel_pxp_irq.h"
+#include "uc/intel_gsc_proxy.h"
 
 static void guc_irq_handler(struct intel_guc *guc, u16 iir)
 {
@@ -82,6 +83,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
instance,
if (instance == OTHER_GSC_INSTANCE)
return intel_gsc_irq_handler(gt, iir);
 
+   if (instance == OTHER_GSC_HECI_2_INSTANCE)
+   return intel_gsc_proxy_irq_handler(>uc.gsc, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
  instance, iir);
 }
@@ -101,6 +105,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
+   if (instance == OTHER_GSC_HECI_2_INSTANCE)
+   return media_gt;
if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
return media_gt;
fallthrough;
@@ -257,6 +263,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
u32 irqs = GT_RENDER_USER_INTERRUPT;
u32 guc_mask = intel_uc_wants_guc(>uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
+   u32 heci_mask = 0;
u32 dmask;
u32 smask;
 
@@ -268,10 +275,16 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
dmask = irqs << 16 | irqs;
smask = irqs << 16;
 
-   if (HAS_ENGINE(gt, GSC0))
+   if (HAS_ENGINE(gt, GSC0)) {
+   /*
+* the heci2 interrupt is enabled via the same register as the
+* GSC interrupt, but it has its own mask register.
+*/
gsc_mask = irqs;
-   else if (HAS_HECI_GSC(gt->i915))
+   heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/
+   } else if (HAS_HECI_GSC(gt->i915)) {
gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
+   }
 
BUILD_BUG_ON(irqs & 0x);
 
@@ -281,7 +294,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (CCS_MASK(gt))
intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, smask);
if (gsc_mask)
-   intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 
gsc_mask);
+   intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 
gsc_mask | heci_mask);
 
/* Unmask irqs on RCS, BCS, VCS and VECS engines. */
intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask);
@@ -309,6 +322,9 @@ void 

[PATCH 0/8] drm/i915: HuC loading and authentication for MTL

[Daniele Ceraolo Spurio]

The HuC loading and authentication flow is once again changing and a new
"clear-media only" authentication step is introduced. The flow is as
follows:

1) The HuC is loaded via DMA - same as all non-GSC HuC binaries.

2) The HuC is authenticated by the GuC - this is the same step as
performed for all non-GSC HuC binaries and re-uses the same code, but
it is now resulting in a partial authentication that only allows
clear-media workloads.

3) The HuC is fully authenticated for all workloads by the GSC - this
is done via a new PXP command, submitted via the GSCCS.

The advantage of this new flow is that we can start processing
clear-media workloads without having to wait for the GSC to be ready,
which can take several seconds.

As part of this change, the HuC status getparam has been updated with a
new value to indicate a partial authentication. Note tha the media
driver is checking for value > 0 for clear media workloads, so no
changes are required in userspace for that to work.

The SW proxy series [1] has been included, squashed in a single patch,
as some of some of the patches in this series depend on it. This is not
a functional dependencies, the patches just touch the same code; the
proxy patches are planned to be merged first, so it is easier to base
the new patches on top of it to avoid having to rebase them later.

[1] https://patchwork.freedesktop.org/series/115806/
Cc: Alan Previn 
Cc: Tony Ye 

Daniele Ceraolo Spurio (8):
  DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
  drm/i915/uc: perma-pin firmwares
  drm/i915/huc: Parse the GSC-enabled HuC binary
  drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
  drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
  drm/i915/mtl/huc: auth HuC via GSC
  drm/i915/mtl/huc: Use the media gt for the HuC getparam
  drm/i915/huc: define HuC FW version for MTL

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |   3 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
 .../drm/i915/gt/uc/intel_gsc_meu_headers.h|  74 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  89 +++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |   2 +-
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 +---
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  26 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 214 -
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h  |  21 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  10 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |   2 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 120 ++---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   9 +-
 drivers/gpu/drm/i915/i915_getparam.c  |   6 +-
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  14 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |   2 +-
 drivers/misc/mei/Kconfig  |   2 +-
 drivers/misc/mei/Makefile |   1 +
 drivers/misc/mei/gsc_proxy/Kconfig|  14 +
 drivers/misc/mei/gsc_proxy/Makefile   |   7 +
 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
 include/drm/i915_component.h  |   3 +-
 include/drm/i915_gsc_proxy_mei_interface.h|  53 +++
 include/uapi/drm/i915_drm.h   |   3 +-
 33 files changed, 1428 insertions(+), 134 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
 create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
 create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
 create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
 create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h

-- 
2.40.0

Re: [PATCH] drm/probe_helper: fix the warning reported when calling drm_kms_helper_poll_disable during suspend

[zongmin zhou]

On Wed, 2023-04-26 at 16:10 +0300, Dmitry Baryshkov wrote:
> On Wed, 26 Apr 2023 at 12:09, zongmin zhou 
> wrote:
> > 
> > On Sun, 2023-04-23 at 22:51 +0200, Janne Grunau wrote:
> > > On 2023-04-20 23:07:01 +0300, Dmitry Baryshkov wrote:
> > > > On Thu, 20 Apr 2023 at 23:01, Janne Grunau 
> > > > wrote:
> > > > > 
> > > > > On 2023-03-28 10:31:29 +0800, Zongmin Zhou wrote:
> > > > > > When drivers call drm_kms_helper_poll_disable from
> > > > > > their device suspend implementation without enabled output
> > > > > > polling before,
> > > > > > following warning will be reported,due to work->func not be
> > > > > > initialized:
> > > > > 
> > > > > we see the same warning with the wpork in progress kms driver
> > > > > for
> > > > > apple
> > > > > silicon SoCs. The connectors do not need to polled so the
> > > > > driver
> > > > > never
> > > > > calls drm_kms_helper_poll_init().
> > > > > 
> > > > > > [   55.141361] WARNING: CPU: 3 PID: 372 at
> > > > > > kernel/workqueue.c:3066 __flush_work+0x22f/0x240
> > > > > > [   55.141382] Modules linked in: nls_iso8859_1
> > > > > > snd_hda_codec_generic ledtrig_audio snd_hda_intel
> > > > > > snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec
> > > > > > snd_hda_core
> > > > > > snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
> > > > > > snd_rawmidi
> > > > > > snd_seq intel_rapl_msr intel_rapl_common bochs
> > > > > > drm_vram_helper
> > > > > > drm_ttm_helper snd_seq_device nfit ttm crct10dif_pclmul
> > > > > > snd_timer ghash_clmulni_intel binfmt_misc sha512_ssse3
> > > > > > aesni_intel drm_kms_helper joydev input_leds syscopyarea
> > > > > > crypto_simd snd cryptd sysfillrect sysimgblt mac_hid
> > > > > > serio_raw
> > > > > > soundcore qemu_fw_cfg sch_fq_codel msr parport_pc ppdev lp
> > > > > > parport drm ramoops reed_solomon pstore_blk pstore_zone
> > > > > > efi_pstore virtio_rng ip_tables x_tables autofs4
> > > > > > hid_generic
> > > > > > usbhid hid ahci virtio_net i2c_i801 crc32_pclmul psmouse
> > > > > > virtio_scsi libahci i2c_smbus lpc_ich xhci_pci net_failover
> > > > > > virtio_blk xhci_pci_renesas failover
> > > > > > [   55.141430] CPU: 3 PID: 372 Comm: kworker/u16:9 Not
> > > > > > tainted
> > > > > > 6.2.0-rc6+ #16
> > > > > > [   55.141433] Hardware name: QEMU Standard PC (Q35 + ICH9,
> > > > > > 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org
> > > > > > 04/01/2014
> > > > > > [   55.141435] Workqueue: events_unbound async_run_entry_fn
> > > > > > [   55.141441] RIP: 0010:__flush_work+0x22f/0x240
> > > > > > [   55.141444] Code: 8b 43 28 48 8b 53 30 89 c1 e9 f9 fe ff
> > > > > > ff
> > > > > > 4c 89 f7 e8 b5 95 d9 00 e8 00 53 08 00 45 31 ff e9 11 ff ff
> > > > > > ff
> > > > > > 0f 0b e9 0a ff ff ff <0f> 0b 45 31 ff e9 00 ff ff ff e8 e2
> > > > > > 54
> > > > > > d8 00 66 90 90 90 90 90 90
> > > > > > [   55.141446] RSP: 0018:ff59221940833c18 EFLAGS: 00010246
> > > > > > [   55.141449] RAX:  RBX: 
> > > > > > RCX:
> > > > > > 9b72bcbe
> > > > > > [   55.141450] RDX: 0001 RSI: 0001
> > > > > > RDI:
> > > > > > ff3ea01e4265e330
> > > > > > [   55.141451] RBP: ff59221940833c90 R08: 
> > > > > > R09:
> > > > > > 8080808080808080
> > > > > > [   55.141453] R10: ff3ea01e42b3caf4 R11: 000f
> > > > > > R12:
> > > > > > ff3ea01e4265e330
> > > > > > [   55.141454] R13: 0001 R14: ff3ea01e505e5e80
> > > > > > R15:
> > > > > > 0001
> > > > > > [   55.141455] FS:  ()
> > > > > > GS:ff3ea01fb7cc() knlGS:
> > > > > > [   55.141456] CS:  0010 DS:  ES:  CR0:
> > > > > > 80050033
> > > > > > [   55.141458] CR2: 563543ad1546 CR3: 00010ee82005
> > > > > > CR4:
> > > > > > 00771ee0
> > > > > > [   55.141464] DR0:  DR1: 
> > > > > > DR2:
> > > > > > 
> > > > > > [   55.141465] DR3:  DR6: fffe0ff0
> > > > > > DR7:
> > > > > > 0400
> > > > > > [   55.141466] PKRU: 5554
> > > > > > [   55.141467] Call Trace:
> > > > > > [   55.141469]  
> > > > > > [   55.141472]  ? pcie_wait_cmd+0xdf/0x220
> > > > > > [   55.141478]  ? mptcp_seq_show+0xe0/0x180
> > > > > > [   55.141484]  __cancel_work_timer+0x124/0x1b0
> > > > > > [   55.141487]  cancel_delayed_work_sync+0x17/0x20
> > > > > > [   55.141490]  drm_kms_helper_poll_disable+0x26/0x40
> > > > > > [drm_kms_helper]
> > > > > > [   55.141516]  drm_mode_config_helper_suspend+0x25/0x90
> > > > > > [drm_kms_helper]
> > > > > > [   55.141531]  ? __pm_runtime_resume+0x64/0x90
> > > > > > [   55.141536]  bochs_pm_suspend+0x16/0x20 [bochs]
> > > > > > [   55.141540]  pci_pm_suspend+0x8b/0x1b0
> > > > > > [   55.141545]  ? __pfx_pci_pm_suspend+0x10/0x10
> > > > > > [   55.141547]  dpm_run_callback+0x4c/0x160
> > > > > > [   55.141550]  __device_suspend+0x14c/0x4c0
> > > > > > [   55.141553]  async_suspend+0x24/0xa0
> > > > > > [   55.141555]  

Re: Disabling -Warray-bounds for gcc-13 too

[Kees Cook]

On April 27, 2023 3:50:06 PM PDT, Karol Herbst  wrote:
>On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul  wrote:
>>
>> Hey Linus, Kees. Responses below
>>
>> On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
>> > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds 
>> >  wrote:
>> > > Kees,
>> > >  I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
>> > > in the process I got gcc-13 which is not WERROR-clean because we only
>> > > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
>> > > has all the same issues.
>> > >
>> > > And I want to be able to do my arm64 builds with WERROR on still...
>> > >
>> > > I guess it never made much sense to hope it was going to go away
>> > > without having a confirmation, so I just changed it to be gcc-11+.
>> >
>> > Yeah, that's fine. GCC 13 released without having a fix for at least one 
>> > (hopefully last) known array-bounds vs jump threading bug:
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
>> >
>> > > And one of them is from you.
>> > >
>> > > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
>> > > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
>> > > changes
>> > >
>> > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
>> > >
>> > > to
>> > >
>> > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 
>> > > dpcd[DP_RECEIVER_CAP_SIZE],
>> > >
>> > > and then does
>> > >
>> > >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
>> > >
>> > > where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE 
>> > > is 15.
>> >
>> > Yeah, it was an incomplete fix. I sent the other half here, but it fell 
>> > through the cracks:
>> > https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
>>
>> Thanks for bringing this to our attention, yeah this definitely just looks
>> like it got missed somewhere down the line. It looks like Karol responded
>> already so I assume the patch is in the pipeline now, but let me know if
>> there's anything else you need.
>>
>
>uhm, I didn't push anything, but I can push it through drm-misct asap,
>just wanted to ask if somebody wants to pick a quicker route. But I
>guess not?

If you can pick it up, that would be great. There's no rush. :)



-- 
Kees Cook

Re: [PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

[Teres Alexis, Alan Previn]

On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> Add helper functions into a new file for heci-packet-submission.
> The helpers will handle generating the MTL GSC-CS Memory-Header
> and submission of the Heci-Cmd-Packet instructions to the engine.
> 
> 
alan: I accidentally forgot to carry Daniele's RB forward from rev8.
Repasting as this patch did not change:

Reviewed-by: Daniele Ceraolo Spurio 

[PATCH v9 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

[Alan Previn]

Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.

Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.

We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
 - a buffer for the HECI packet that contains PXP FW commands
 - a batch-buffer that contains the engine instruction for
   sending the HECI packet to the GSC firmware.

Thus, add the allocation and freeing of these buffers in gsccs
init and fini.

The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw returned. Thus,
add a wrapper to continuously retry send_message while
replaying the gsc_message_handle. Retries need to follow the
arch-spec count and delay until GSC-FW replies with the real
SUCCESS or timeout after that spec'd delay.

The GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking. Thus,
allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   3 +-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |   3 +
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 240 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|   4 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|   6 +
 5 files changed, 254 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 3f60cbc011c1..0db216a031af 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -50,7 +50,8 @@ struct intel_gsc_mtl_header {
 * we distinguish the flags using OUTFLAG or INFLAG
 */
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDINGBIT(0)
+#define GSC_INFLAG_MSG_CLEANUP BIT(1)
 
u32 status;
 } __packed;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..c65ada99e54f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,9 @@
 /* PXP-Cmd-Op definitions */
 #define PXP43_CMDID_START_HUC_AUTH 0x003A
 
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
+
 /* PXP-Input-Packet: HUC-Authentication */
 struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index bad55719a7ac..16e3b73d0653 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,23 +6,232 @@
 #include "gem/i915_gem_internal.h"
 
 #include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_types.h"
 
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+  void *msg_in, size_t msg_in_size,
+  void *msg_out, size_t msg_out_size_max,
+  size_t *msg_out_len,
+  u64 *gsc_msg_handle_retry)
+{
+   struct intel_gt *gt = pxp->ctrl_gt;
+   struct drm_i915_private *i915 = gt->i915;
+   struct gsccs_session_resources *exec_res =  >gsccs_res;
+   struct intel_gsc_mtl_header *header = exec_res->pkt_vaddr;
+   struct intel_gsc_heci_non_priv_pkt pkt;
+   size_t max_msg_size;
+   u32 reply_size;
+   int ret;
+
+   if (!exec_res->ce)
+   return -ENODEV;
+
+   max_msg_size = PXP43_MAX_HECI_INOUT_SIZE - sizeof(*header);
+
+   if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+   return -ENOSPC;
+
+   if (!exec_res->pkt_vma || !exec_res->bb_vma)
+   return -ENOENT;
+
+   GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));
+
+   mutex_lock(>tee_mutex);
+
+   memset(header, 0, sizeof(*header));
+   intel_gsc_uc_heci_cmd_emit_mtl_header(header, HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec_res->host_session_handle);
+
+   /* check if this is a host-session-handle cleanup call (empty packet) */
+   if (!msg_in && !msg_out)
+   header->flags |= GSC_INFLAG_MSG_CLEANUP;
+
+   /* copy caller provided gsc message 

[PATCH v9 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS

[Alan Previn]

Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.

Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_pci.c  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 18 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c |  6 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  2 +-
 5 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5fcc9cfed671..f59122e33465 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1152,6 +1152,7 @@ static const struct intel_device_info mtl_info = {
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
+   .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f143eadbc253..bb2e15329f34 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -289,6 +289,14 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
 }
 
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp)
+{
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   return GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   return 250;
+}
+
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
int timeout;
@@ -302,10 +310,7 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
@@ -325,10 +330,7 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 17e6dbc86b38..17254c3f1267 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,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_get_readiness_status(struct intel_pxp *pxp);
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..e07c5b380789 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
 
 #include "intel_pxp.h"
 #include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_types.h"
 
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
 {
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp->ctrl_gt;
+   int timeout_ms;
 
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,10 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp, 
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
 
+   timeout_ms = intel_pxp_get_backend_timeout_ms(pxp);
+
if (!wait_for_completion_timeout(>termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
 
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index e4d8242302c5..0a3e66b0265e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp, 
u32 id, bool in_pla
  KCR_SIP(pxp->kcr_base),
   

[PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

[Alan Previn]

Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.

NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
 1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
 2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
 3- PXP: This series.

NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.

NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
   common helpers come in:
 - On MTL, when an i915 subsystem needs to send a command request
   to the security firmware, it will send that via the GSC-
   engine-command-streamer.
 - However those commands, (lets call them "gsc_specific_fw_api"
   calls), are not understood by the GSC command streamer hw.
 - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
   passes it along to the GSC firmware.
 - The GSC FW on the other hand needs additional metadata to know
   which usage service is being called (PXP, HDCP, proxy, etc) along
   with session specific info. Thus an extra header called GSC-CS
   HECI Memory Header, (C) in below diagram is prepended before
   the FW specific API, (D).
 - Thus, the structural layout of the request submitted would
   need to look like the diagram below (for non-priv PXP).
 - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
   PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
   will populate blob (C) while additional helpers, different for
   PPGGTT (this patch) vs GGTT (HDCP series) will populate
   blobs (A) and (B) below.
  ___
 (A)  |  MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
  | |   |
  |_|   |
  | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,|   |
  ||   pkt-addr-out, pkt-size-out)  |
  || MI_BATCH_BUFFER_END|   |   |
  |||   |   |
  | |   |
  |_|   |
|
-
|
   \|/
  __V___
  |   _|
  |(C)|   ||
  |   | struct intel_gsc_mtl_header { ||
  |   |   validity marker ||
  |   |   heci_clent_id   ||
  |   |   ... ||
  |   |  }||
  |   |___||
  |(D)|   ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   | ...   ||
  |   | For an example, see   ||
  |   | 'struct pxp43_create_arb_in' at   ||
  |   | intel_pxp_cmd_interface_43.h  ||
  |   |   ||
  |   | } ||
  |   |  Struture depends on command type ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   |___||
  ||

That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).

Signed-off-by: Alan Previn 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  23 
 2 files changed, 125 

[PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Alan Previn]

Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second range
after the kernel starts (which sees MESA's init appear in the
middle of this range as the compositor comes up). To avoid
unncessary delays experienced by the UMD for get-caps purposes,
add a GET_PARAM for I915_PARAM_PXP_SUPPORT.

However, some failures can still occur after all the depedencies
are met (such as firmware init flow failure, bios configurations
or SOC fusing not allowing PXP enablement). Those scenarios will
only be known to user space when it attempts creating a PXP context
and is documented in the GEM UAPI headers.

While making this change, create a helper that is common to both
GET_PARAM caller and intel_pxp_start since the latter does
similiar checks.

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/i915_getparam.c |  7 +++
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 +---
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 include/uapi/drm/i915_drm.h  | 19 ++
 4 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..6f11d7eaa91a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,8 @@
 #include "gem/i915_gem_mman.h"
 #include "gt/intel_engine_user.h"
 
+#include "pxp/intel_pxp.h"
+
 #include "i915_cmd_parser.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
@@ -102,6 +104,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+   case I915_PARAM_PXP_STATUS:
+   value = intel_pxp_get_readiness_status(i915->pxp);
+   if (value < 0)
+   return value;
+   break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
 * earlier versions as 0, in effect their value is undefined as
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index b600d68de2a4..f143eadbc253 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -358,23 +358,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
 }
 
 /*
- * the arb session is restarted from the irq work when we receive the
- * termination completion interrupt
+ * this helper is used by both intel_pxp_start and by
+ * the GET_PARAM IOCTL that user space calls. Thus, the
+ * return values here should match the UAPI spec.
  */
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
 {
-   int ret = 0;
-
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
 
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
-   return -ENXIO;
+   return 2;
} else {
if (wait_for(pxp_component_bound(pxp), 250))
-   return -ENXIO;
+   return 2;
}
+   return 1;
+}
+
+/*
+ * the arb session is restarted from the irq work when we receive the
+ * termination completion interrupt
+ */
+int intel_pxp_start(struct intel_pxp *pxp)
+{
+   int ret = 0;
+
+   ret = intel_pxp_get_readiness_status(pxp);
+   if (ret < 0)
+   return ret;
+   else if (ret > 1)
+   return -EIO; /* per UAPI spec, user may retry later */
 
mutex_lock(>arb_mutex);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3ded0890cd27..17e6dbc86b38 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_fini_hw(struct intel_pxp *pxp);
 void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
 void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 
arb_session_id);
 
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b15dd9cc2ffb..f4efbb2db0c5 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -771,6 +771,25 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
 
+/*
+ * Query the status of PXP support in i915.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV = PXP support is not available on the GPU device or in the
+ *   kernel due to missing component drivers or kernel 

[PATCH v9 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component

[Alan Previn]

On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.

Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 15 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c|  3 ++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 4bc276daca16..8dc41de3f6f7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -10,6 +10,7 @@
 #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
+#include "intel_pxp.h"
 #include "intel_pxp_cmd_interface_42.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
@@ -422,10 +423,22 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
 
 void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
 {
+   intel_wakeref_t wakeref;
+
gsccs_destroy_execution_resource(pxp);
+   with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_fini_hw(pxp);
 }
 
 int intel_pxp_gsccs_init(struct intel_pxp *pxp)
 {
-   return gsccs_allocate_execution_resource(pxp);
+   int ret;
+   intel_wakeref_t wakeref;
+
+   ret = gsccs_allocate_execution_resource(pxp);
+   if (!ret) {
+   with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_init_hw(pxp);
+   }
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
 * The PXP component gets automatically unbound when we go into S3 and
 * re-bound after we come out, so in that scenario we can defer the
 * hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
 */
-   if (!pxp->pxp_component)
+   if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
 
intel_pxp_init_hw(pxp);
-- 
2.39.0

[PATCH v9 5/8] drm/i915/pxp: Add ARB session creation and cleanup

[Alan Previn]

Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.

While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
that describe the possible error values when creating a context
with I915_CONTEXT_PARAM_PROTECTED_CONTENT:
   Since the first merge of PXP support on ADL, i915 returns -ENXIO
   if a dependency such as firmware or component driver was yet to
   be loaded or returns -EIO if the creation attempt failed when
   requested by the PXP firmware (specific firmware error responses
   are reported in dmesg).

Add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.

For both cases, in the back-end gsccs functions for sending messages
to the firmware inspect the GSC-CS-Mem-Header's pending-bit which
means the GSC firmware is busy and we should retry.

Given the last hw requirement, lets also update functions in
front-end layer that wait for session creation or teardown
completion to use new worst case timeout periods.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  10 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h |   1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  27 +++-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  21 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 130 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|  12 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  11 +-
 include/uapi/drm/i915_drm.h   |  15 ++
 8 files changed, 220 insertions(+), 7 deletions(-)

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 236673c02f9a..013dfe284a28 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -13,6 +13,7 @@
 #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_PROXY_STATE_NORMAL5
 #define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
 
 static bool gsc_is_in_reset(struct intel_uncore *uncore)
@@ -31,6 +32,15 @@ bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
return fw_status & GSC_FW_INIT_COMPLETE_BIT;
 }
 
+bool intel_gsc_uc_fw_proxy_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 REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_PROXY_STATE_NORMAL;
+}
+
 static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
 {
u32 offset = i915_ggtt_offset(gsc->local);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index f4c1106bb2a9..fff8928218df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -13,5 +13,6 @@ struct intel_uncore;
 
 int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 8949d4be7882..b600d68de2a4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -291,6 +291,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
 
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -300,7 +302,12 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   timeout = 250;
+
+   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
 
return 0;
@@ -308,6 +315,8 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
 
 static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -316,7 +325,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   

[PATCH v9 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation

[Alan Previn]

Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:

1. Updating 'pick-gt' to get the media tile for
   KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
   (init, status-checking, etc.).

While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 
 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  6 
 5 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c0f3ff4746ad..7727eadb0672 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -101,7 +101,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
-   if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
+   if ((instance == OTHER_GSC_INSTANCE || instance == 
OTHER_KCR_INSTANCE) &&
+   HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f93aa171aa1e..8949d4be7882 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
 #include "intel_pxp.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
 #include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
 }
 
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+   u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES) 
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+   intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
 
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, true);
 }
 
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, false);
 }
 
 static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
 
+   if (pxp->ctrl_gt->type == GT_MEDIA)
+   pxp->kcr_base = MTL_KCR_BASE;
+   else
+   pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
 
ret = create_vcs_context(pxp);
@@ -369,14 +376,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
 
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_enable(pxp->ctrl_gt);
+   kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_disable(pxp->ctrl_gt);
-
+   kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
 }
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define KCR_GLOBAL_TERMINATE(base) 

[PATCH v9 0/8] drm/i915/pxp: Add MTL PXP Support

[Alan Previn]

This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created when protected contexts are created.

In this series, the front end behaviors and interfaces (uapi) remain
the same. We add backend support for MTL but with MTL we directly use
the GSC-CS engine on the MTL GPU device to send messages to the PXP
(a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format
of the message is slightly different with a 2-layer packetization
that is explained in detail in Patch #3. Also, the second layer
which is the actual PXP firmware packet is now rev'd to version 4.3
for MTL that is defined in Patch #5.

Take note that Patch #4 adds the buffer allocation and gsccs-send-
message without actually being called by the arb-creation code
which gets added in Patch #5. Additionally, a seperate series being
reviewed is introducing a change for session teardown (in pxp front-
end layer that will need backend support by both legacy and gsccs).
If we squash all of these together (buffer-alloc, send-message,
arb-creation and, in future, session-termination), the single patch
will be rather large. That said, we are keeping Patch #4 and #5
separate for now, but at merge time, we can squash them together
if maintainer requires it.

Changes from prior revs:
   v1 : - fixed when building with CONFIG_PXP disabled.
- more alignment with gsc_mtl_header structure from the HDCP
   v2 : - (all following changes as per reviews from Daniele)
- squashed Patch #1 from v1 into the next one.
- replaced unnecessary "uses_gsccs" boolean in the pxp
  with "HAS_ENGINE(pxp->ctrl_gt, GSC0)".
- moved the stashing of gsccs resources from a dynamically
  allocated opaque handle to an explicit sub-struct in
  'struct intel_pxp'.
- moved the buffer object allocations from Patch #1 of this
  series to Patch #5 (but keep the context allocation in
  Patch #1).
- used the kernel default ppgtt for the gsccs context.
- optimized the buffer allocation and deallocation code
  and drop the need to stash the drm_i915_gem_object.
- use a macro with the right mmio reg base (depending
  on root-tile vs media-tile) along with common relative
  offset to access all KCR registers thus minimizing
  changes to the KCR register access codes.
- fixed bugs in the heci packet request submission code
  in Patch #3 (of this series)
- add comments in the mtl-gsc-heci-header regarding the
  host-session-handle.
- re-use tee-mutex instead of introducing a gsccs specific
  cmd mutex.
- minor cosmetic improvements in Patch #5.
- before creating arb session, ensure intel_pxp_start
  first ensures the GSC FW is up and running.
- use 2 second timeout for the pending-bit scenario when
  sending command to GSC-FW as per specs.
- simplify intel_pxp_get_irq_gt with addition comments
- redo Patch #7 to minimize the changes without introducing
  a common  abstraction helper for suspend/resume/init/fini
  codes that have to change the kcr power state.
   v3 : - rebase onto latest drm-tip with the updated firmware
  session invalidation flow
- on Patch#1: move 'mutex_init(>tee_mutex)' to a common
  init place in intel_pxp_init since its needed everywhere
  (Daniele)
- on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);"
  (Daniele)
- on Patch#2: move the introduction of host_session_handle to
  Patch#4 where it starts getting used.
- on Patch#4: move host-session-handle initialization to the
  allocate-resources during gsccs-init (away from Patch#5)
  and add the required call to PXP-firmware to cleanup the
  host-session-handle in destroy-resources during gsccs-fini
- on Patch#5: add dispatching of arb session termination
  firmware cmd during session teardown (as per latest
  upstream flows)
   v4 : - Added proper initialization and cleanup of host-session-handle
  that the gsc firmware expects.
- Fix the stream-session-key invalidation instruction for MTL.
   v5 : - In Patch #4, move the tee_mutex locking to after we check for
  valid vma allocations.
- In Patch #5, wait for intel_huc_is_authenticated instead of
  intel_uc_fw_is_running(gsc-fw) before starting ARB session.
- In Patch #5, increase the necessary timeouts at the top-level
  (PXP arb session creation / termination) to accomodate SLA of
  GSC firmware when busy with pending-bit responses.
- In Patch #5, remove redundant host_session_handle init 

[PATCH v9 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup

[Alan Previn]

For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.

Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.

Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 20 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 63 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  2 -
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  8 +++
 6 files changed, 117 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..523fc9dda428 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -342,6 +342,7 @@ i915-y += \
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+   pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..f93aa171aa1e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
 #include "i915_drv.h"
 
 #include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
 
-   ret = intel_pxp_tee_component_init(pxp);
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   ret = intel_pxp_gsccs_init(pxp);
+   else
+   ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
 
@@ -165,9 +169,12 @@ static struct intel_gt 
*find_gt_for_required_protected_content(struct drm_i915_p
/*
 * For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
 * on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC and HUC firmware are coming online
 */
-   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+   intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw) &&
+   intel_uc_fw_is_loadable(>media_gt->uc.huc.fw))
return i915->media_gt;
 
/*
@@ -207,7 +214,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
 
+   /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+   mutex_init(>pxp->tee_mutex);
 
/*
 * If full PXP feature is not available but HuC is loaded by GSC on 
pre-MTL
@@ -229,7 +238,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
 
i915->pxp->arb_is_valid = false;
 
-   intel_pxp_tee_component_fini(i915->pxp);
+   if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+   intel_pxp_gsccs_fini(i915->pxp);
+   else
+   intel_pxp_tee_component_fini(i915->pxp);
 
destroy_vcs_context(i915->pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..bad55719a7ac
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+   struct gsccs_session_resources *exec_res = >gsccs_res;
+
+   if (exec_res->ce)
+   intel_context_put(exec_res->ce);
+
+   memset(exec_res, 0, sizeof(*exec_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+   struct intel_gt *gt = 

Re: Disabling -Warray-bounds for gcc-13 too

[Karol Herbst]

On Fri, Apr 28, 2023 at 1:27 AM Lyude Paul  wrote:
>
> On Fri, 2023-04-28 at 00:50 +0200, Karol Herbst wrote:
> > On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul  wrote:
> > >
> > > Hey Linus, Kees. Responses below
> > >
> > > On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > > > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds 
> > > >  wrote:
> > > > > Kees,
> > > > >  I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > > > > in the process I got gcc-13 which is not WERROR-clean because we only
> > > > > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> > > > > has all the same issues.
> > > > >
> > > > > And I want to be able to do my arm64 builds with WERROR on still...
> > > > >
> > > > > I guess it never made much sense to hope it was going to go away
> > > > > without having a confirmation, so I just changed it to be gcc-11+.
> > > >
> > > > Yeah, that's fine. GCC 13 released without having a fix for at least 
> > > > one (hopefully last) known array-bounds vs jump threading bug:
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
> > > >
> > > > > And one of them is from you.
> > > > >
> > > > > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> > > > > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> > > > > changes
> > > > >
> > > > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > > > >
> > > > > to
> > > > >
> > > > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 
> > > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > > >
> > > > > and then does
> > > > >
> > > > >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> > > > >
> > > > > where that 'args.dp.dpcd' is a 16-byte array, and 
> > > > > DP_RECEIVER_CAP_SIZE is 15.
> > > >
> > > > Yeah, it was an incomplete fix. I sent the other half here, but it fell 
> > > > through the cracks:
> > > > https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
> > >
> > > Thanks for bringing this to our attention, yeah this definitely just looks
> > > like it got missed somewhere down the line. It looks like Karol responded
> > > already so I assume the patch is in the pipeline now, but let me know if
> > > there's anything else you need.
> > >
> >
> > uhm, I didn't push anything, but I can push it through drm-misct asap,
> > just wanted to ask if somebody wants to pick a quicker route. But I
> > guess not?
>
> Ah whoops, I misunderstood! Yeah I would say we should just go ahead and push
> it since I don't see any indication here that anyone else has.
>

okay, will do so tomorrow then.

> >
> > > >
> > > >
> > > >
> > > > >
> > > >
> > > > > I think it's all entirely harmless from a code generation standpoint,
> > > > > because the 15-byte field will be padded out to 16 bytes in the
> > > > > structure that contains it, but it's most definitely buggy.
> > > >
> > > > Right; between this, that GCC 13 wasn't released yet, and I had no 
> > > > feedback from NV folks, I didn't chase down landing that fix.
> > > >
> > > > >
> > > > > So that warning does find real cases of wrong code. But when those
> > > > > real cases are hidden by hundreds of lines of unfixable false
> > > > > positives, we don't have much choice.
> > > >
> > > > Yup, totally agreed. The false positives I've looked at all seem to be 
> > > > similar to the outstanding jump threading bug, so I'm hoping once that 
> > > > gets fixed we'll finally have a good signal with that warning enabled. 
> > > > :)
> > > >
> > > > -Kees
> > > >
> > > >
> > >
> > > --
> > > Cheers,
> > >  Lyude Paul (she/her)
> > >  Software Engineer at Red Hat
> > >
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>

[PATCH] drm/msm/dp: add module parameter for PSR

[Abhinav Kumar]

On sc7280 where eDP is the primary display, PSR is causing
IGT breakage even for basic test cases like kms_atomic and
kms_atomic_transition. Most often the issue starts with below
stack so providing that as reference

Call trace:
 dpu_encoder_assign_crtc+0x64/0x6c
 dpu_crtc_enable+0x188/0x204
 drm_atomic_helper_commit_modeset_enables+0xc0/0x274
 msm_atomic_commit_tail+0x1a8/0x68c
 commit_tail+0xb0/0x160
 drm_atomic_helper_commit+0x11c/0x124
 drm_atomic_commit+0xb0/0xdc
 drm_atomic_connector_commit_dpms+0xf4/0x110
 drm_mode_obj_set_property_ioctl+0x16c/0x3b0
 drm_connector_property_set_ioctl+0x4c/0x74
 drm_ioctl_kernel+0xec/0x15c
 drm_ioctl+0x264/0x408
 __arm64_sys_ioctl+0x9c/0xd4
 invoke_syscall+0x4c/0x110
 el0_svc_common+0x94/0xfc
 do_el0_svc+0x3c/0xb0
 el0_svc+0x2c/0x7c
 el0t_64_sync_handler+0x48/0x114
 el0t_64_sync+0x190/0x194
---[ end trace  ]---
[drm-dp] dp_ctrl_push_idle: PUSH_IDLE pattern timedout

Other basic use-cases still seem to work fine hence add a
a module parameter to allow toggling psr enable/disable till
PSR related issues are hashed out with IGT.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 628b0e248db6..dba43167de66 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -28,6 +28,10 @@
 #include "dp_audio.h"
 #include "dp_debug.h"
 
+static bool psr_enabled = false;
+module_param(psr_enabled, bool, 0);
+MODULE_PARM_DESC(psr_enabled, "enable PSR for eDP and DP displays");
+
 #define HPD_STRING_SIZE 30
 
 enum {
@@ -407,7 +411,7 @@ static int dp_display_process_hpd_high(struct 
dp_display_private *dp)
 
edid = dp->panel->edid;
 
-   dp->dp_display.psr_supported = dp->panel->psr_cap.version;
+   dp->dp_display.psr_supported = dp->panel->psr_cap.version && 
psr_enabled;
 
dp->audio_supported = drm_detect_monitor_audio(edid);
dp_panel_handle_sink_request(dp->panel);
-- 
2.40.1

Re: Disabling -Warray-bounds for gcc-13 too

[Lyude Paul]

On Fri, 2023-04-28 at 00:50 +0200, Karol Herbst wrote:
> On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul  wrote:
> > 
> > Hey Linus, Kees. Responses below
> > 
> > On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds 
> > >  wrote:
> > > > Kees,
> > > >  I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > > > in the process I got gcc-13 which is not WERROR-clean because we only
> > > > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> > > > has all the same issues.
> > > > 
> > > > And I want to be able to do my arm64 builds with WERROR on still...
> > > > 
> > > > I guess it never made much sense to hope it was going to go away
> > > > without having a confirmation, so I just changed it to be gcc-11+.
> > > 
> > > Yeah, that's fine. GCC 13 released without having a fix for at least one 
> > > (hopefully last) known array-bounds vs jump threading bug:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
> > > 
> > > > And one of them is from you.
> > > > 
> > > > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> > > > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> > > > changes
> > > > 
> > > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > > > 
> > > > to
> > > > 
> > > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 
> > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > > 
> > > > and then does
> > > > 
> > > >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> > > > 
> > > > where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE 
> > > > is 15.
> > > 
> > > Yeah, it was an incomplete fix. I sent the other half here, but it fell 
> > > through the cracks:
> > > https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
> > 
> > Thanks for bringing this to our attention, yeah this definitely just looks
> > like it got missed somewhere down the line. It looks like Karol responded
> > already so I assume the patch is in the pipeline now, but let me know if
> > there's anything else you need.
> > 
> 
> uhm, I didn't push anything, but I can push it through drm-misct asap,
> just wanted to ask if somebody wants to pick a quicker route. But I
> guess not?

Ah whoops, I misunderstood! Yeah I would say we should just go ahead and push
it since I don't see any indication here that anyone else has.

> 
> > > 
> > > 
> > > 
> > > > 
> > > 
> > > > I think it's all entirely harmless from a code generation standpoint,
> > > > because the 15-byte field will be padded out to 16 bytes in the
> > > > structure that contains it, but it's most definitely buggy.
> > > 
> > > Right; between this, that GCC 13 wasn't released yet, and I had no 
> > > feedback from NV folks, I didn't chase down landing that fix.
> > > 
> > > > 
> > > > So that warning does find real cases of wrong code. But when those
> > > > real cases are hidden by hundreds of lines of unfixable false
> > > > positives, we don't have much choice.
> > > 
> > > Yup, totally agreed. The false positives I've looked at all seem to be 
> > > similar to the outstanding jump threading bug, so I'm hoping once that 
> > > gets fixed we'll finally have a good signal with that warning enabled. :)
> > > 
> > > -Kees
> > > 
> > > 
> > 
> > --
> > Cheers,
> >  Lyude Paul (she/her)
> >  Software Engineer at Red Hat
> > 
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: Disabling -Warray-bounds for gcc-13 too

[Karol Herbst]

On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul  wrote:
>
> Hey Linus, Kees. Responses below
>
> On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds 
> >  wrote:
> > > Kees,
> > >  I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > > in the process I got gcc-13 which is not WERROR-clean because we only
> > > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> > > has all the same issues.
> > >
> > > And I want to be able to do my arm64 builds with WERROR on still...
> > >
> > > I guess it never made much sense to hope it was going to go away
> > > without having a confirmation, so I just changed it to be gcc-11+.
> >
> > Yeah, that's fine. GCC 13 released without having a fix for at least one 
> > (hopefully last) known array-bounds vs jump threading bug:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
> >
> > > And one of them is from you.
> > >
> > > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> > > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> > > changes
> > >
> > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > >
> > > to
> > >
> > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >
> > > and then does
> > >
> > >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> > >
> > > where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE is 
> > > 15.
> >
> > Yeah, it was an incomplete fix. I sent the other half here, but it fell 
> > through the cracks:
> > https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
>
> Thanks for bringing this to our attention, yeah this definitely just looks
> like it got missed somewhere down the line. It looks like Karol responded
> already so I assume the patch is in the pipeline now, but let me know if
> there's anything else you need.
>

uhm, I didn't push anything, but I can push it through drm-misct asap,
just wanted to ask if somebody wants to pick a quicker route. But I
guess not?

> >
> >
> >
> > >
> >
> > > I think it's all entirely harmless from a code generation standpoint,
> > > because the 15-byte field will be padded out to 16 bytes in the
> > > structure that contains it, but it's most definitely buggy.
> >
> > Right; between this, that GCC 13 wasn't released yet, and I had no feedback 
> > from NV folks, I didn't chase down landing that fix.
> >
> > >
> > > So that warning does find real cases of wrong code. But when those
> > > real cases are hidden by hundreds of lines of unfixable false
> > > positives, we don't have much choice.
> >
> > Yup, totally agreed. The false positives I've looked at all seem to be 
> > similar to the outstanding jump threading bug, so I'm hoping once that gets 
> > fixed we'll finally have a good signal with that warning enabled. :)
> >
> > -Kees
> >
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>

Re: Disabling -Warray-bounds for gcc-13 too

[Lyude Paul]

Hey Linus, Kees. Responses below

On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> On April 23, 2023 10:36:24 AM PDT, Linus Torvalds 
>  wrote:
> > Kees,
> >  I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > in the process I got gcc-13 which is not WERROR-clean because we only
> > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> > has all the same issues.
> > 
> > And I want to be able to do my arm64 builds with WERROR on still...
> > 
> > I guess it never made much sense to hope it was going to go away
> > without having a confirmation, so I just changed it to be gcc-11+.
> 
> Yeah, that's fine. GCC 13 released without having a fix for at least one 
> (hopefully last) known array-bounds vs jump threading bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
> 
> > And one of them is from you.
> > 
> > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> > changes
> > 
> > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > 
> > to
> > 
> > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > 
> > and then does
> > 
> >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> > 
> > where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE is 
> > 15.
> 
> Yeah, it was an incomplete fix. I sent the other half here, but it fell 
> through the cracks:
> https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/

Thanks for bringing this to our attention, yeah this definitely just looks
like it got missed somewhere down the line. It looks like Karol responded
already so I assume the patch is in the pipeline now, but let me know if
there's anything else you need.

> 
> 
> 
> > 
> 
> > I think it's all entirely harmless from a code generation standpoint,
> > because the 15-byte field will be padded out to 16 bytes in the
> > structure that contains it, but it's most definitely buggy.
> 
> Right; between this, that GCC 13 wasn't released yet, and I had no feedback 
> from NV folks, I didn't chase down landing that fix.
> 
> > 
> > So that warning does find real cases of wrong code. But when those
> > real cases are hidden by hundreds of lines of unfixable false
> > positives, we don't have much choice.
> 
> Yup, totally agreed. The false positives I've looked at all seem to be 
> similar to the outstanding jump threading bug, so I'm hoping once that gets 
> fixed we'll finally have a good signal with that warning enabled. :)
> 
> -Kees
> 
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [PATCH v2 10/13] drm/msm: mdss: Add SM6375 support

[Marijn Suijten]

On 2023-04-21 00:31:19, Konrad Dybcio wrote:
> Add support for MDSS on SM6375.
> 
> Signed-off-by: Konrad Dybcio 

Reviewed-by: Marijn Suijten 

(After reusing sm6350 data, as suggested by Dmitry)

> ---
>  drivers/gpu/drm/msm/msm_mdss.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 4e3a5f0c303c..f2470ce699f7 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -546,6 +546,15 @@ static const struct msm_mdss_data sm6350_data = {
>   .highest_bank_bit = 1,
>  };
>  
> +static const struct msm_mdss_data sm6375_data = {
> + .ubwc_version = UBWC_2_0,
> + .ubwc_dec_version = UBWC_2_0,
> + .ubwc_swizzle = 6,
> + .ubwc_static = 0x1e,
> + /* Possibly 0 for LPDDR3 */
> + .highest_bank_bit = 1,
> +};
> +
>  static const struct msm_mdss_data sm8150_data = {
>   .ubwc_version = UBWC_3_0,
>   .ubwc_dec_version = UBWC_3_0,
> @@ -580,6 +589,7 @@ static const struct of_device_id mdss_dt_match[] = {
>   { .compatible = "qcom,sc8280xp-mdss", .data = _data },
>   { .compatible = "qcom,sm6115-mdss", .data = _data },
>   { .compatible = "qcom,sm6350-mdss", .data = _data },
> + { .compatible = "qcom,sm6375-mdss", .data = _data },
>   { .compatible = "qcom,sm8150-mdss", .data = _data },
>   { .compatible = "qcom,sm8250-mdss", .data = _data },
>   { .compatible = "qcom,sm8350-mdss", .data = _data },
> 
> -- 
> 2.40.0
> 

Re: [PATCH v2 08/13] drm/msm: mdss: Add SM6350 support

[Marijn Suijten]

On 2023-04-21 00:31:17, Konrad Dybcio wrote:
> Add support for MDSS on SM6350.
> 
> Signed-off-by: Konrad Dybcio 

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/msm_mdss.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index e8c93731aaa1..4e3a5f0c303c 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -538,6 +538,14 @@ static const struct msm_mdss_data sdm845_data = {
>   .highest_bank_bit = 2,
>  };
>  
> +static const struct msm_mdss_data sm6350_data = {
> + .ubwc_version = UBWC_2_0,
> + .ubwc_dec_version = UBWC_2_0,
> + .ubwc_swizzle = 6,
> + .ubwc_static = 0x1e,
> + .highest_bank_bit = 1,
> +};
> +
>  static const struct msm_mdss_data sm8150_data = {
>   .ubwc_version = UBWC_3_0,
>   .ubwc_dec_version = UBWC_3_0,
> @@ -571,6 +579,7 @@ static const struct of_device_id mdss_dt_match[] = {
>   { .compatible = "qcom,sc8180x-mdss", .data = _data },
>   { .compatible = "qcom,sc8280xp-mdss", .data = _data },
>   { .compatible = "qcom,sm6115-mdss", .data = _data },
> + { .compatible = "qcom,sm6350-mdss", .data = _data },
>   { .compatible = "qcom,sm8150-mdss", .data = _data },
>   { .compatible = "qcom,sm8250-mdss", .data = _data },
>   { .compatible = "qcom,sm8350-mdss", .data = _data },
> 
> -- 
> 2.40.0
> 

Re: [Freedreno] [PATCH] drm/msm/dpu: always program dsc active bits

[Marijn Suijten]

On 2023-04-14 16:51:52, Abhinav Kumar wrote:
> On 4/14/2023 4:11 PM, Marijn Suijten wrote:
> > On 2023-04-14 10:57:45, Abhinav Kumar wrote:
> >> On 4/14/2023 10:34 AM, Marijn Suijten wrote:
> >>> On 2023-04-14 08:48:43, Abhinav Kumar wrote:
>  On 4/14/2023 12:35 AM, Marijn Suijten wrote:
> > On 2023-04-12 10:33:15, Abhinav Kumar wrote:
> > [..]
> >>> What happens if a device boots without DSC panel connected?  Will
> >>> CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of 
> >>> the
> >>> DSC blocks?  Or could this flush uninitialized state to the block?
> >>
> >> If we bootup without DSC panel connected, the kernel's cfg->dsc will be
> >> 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont 
> >> flush
> >> any DSC blocks.
> >
> > Ack, that makes sense.  However, if I connect a DSC panel, then
> > disconnect it (now the register should be non-zero, but cfg->dsc will be
> > zero), and then replug a non-DSC panel multiple times, it'll get flushed
> > every time because we never clear CTL_DSC_FLUSH after that?
> 
>  If we remove it after kernel starts, that issue is there even today
>  without that change because DSI is not a hot-pluggable display so a
>  teardown wont happen when you plug out the panel. How will cfg->dsc be 0
>  then? In that case, its not a valid test as there was no indication to
>  DRM that display was disconnected so we cannot tear it down.
> >>>
> >>> The patch description itself describes hot-pluggable displays, which I
> >>> believe is the upcoming DSC support for DP?  You ask how cfg->dsc can
> >>> become zero, but this is **exactly** what the patch description
> >>> describes, and what this patch is removing the `if` for.  If we are not
> >>> allowed to discuss that scenario because it is not currently supported,
> >>> neither should we allow to apply this patch.
> >>>
> >>> With that in mind, can you re-answer the question?
> >>
> >> I didnt follow what needs to be re-answered.
> >>
> >> This patch is being sent in preparation of the DSC over DP support. This
> >> does not handle non-hotpluggable displays.
> > 
> > Good, because my question is specifically about *hotpluggable*
> > displays/panels like the upcoming DSC support for DP.  After all there
> > would be no point in me suggesting to connect and disconnect
> > non-hotpluggable displays and expect something sensible to happen,
> > wouldn't it?  Allow me to copy-paste the question again for convenience,
> > with some minor wording changes:
> > 
> > However, if I connect a DSC DP display, then disconnect it (now the
> > register should be non-zero, but cfg->dsc will be zero), and then
> > connect and reconnect a non-DSC DP display multiple times, it'll get
> > flushed every time because we never clear CTL_DSC_FLUSH after that?
> > 
> > And the missing part is: would multiple flushes be harmful in this case?
> 
> Well, you kept asking about "DSC panel" , that made me think you were 
> asking about a non-hotpluggable MIPI DSI DSC panel and not DP DSC 
> monitor. On many boards, panels can be removed/connected back to their 
> daughter card. The term "panel" confused me a bit.
> 
> Now answering your question.
> 
> Yes, it will get flushed once every hotplug thats not too bad but 
> importantly DSC wont be active as CTL_DSC_ACTIVE will be set to 0 so it 
> wont cause any issue.
> 
> 
> >> I do not think dynamic switch
> >> between DSC and non-DSC of non-hotpluggable displays needs to be
> >> discussed here as its not handled at all with or without this patch.
> >>
> >> We wanted to get early reviews on the patch. If you want this patch to
> >> be absorbed when rest of DSC over DP lands, I have no concerns with
> >> that. I wont pick this up for fixes and we will land this together with
> >> the rest of DP over DSC.
> > 
> > I don't mind when and where this lands, just want to have the semantics
> > clear around persisting the value of CTL_DSC_FLUSh in the register.
> > 
> > Regardless, this patch doesn't sound like a fix but a workaround until
> > reset_intf_cfg() is fixed to be called at the right point, and extended
> > to clear CTL_DSC_ACTIVE and flush the DSCs.  Perhaps it shouldn't have a
> > Fixes: tag for that reason, as you intend to reinstate this
> > if (cfg->dsc) condition when that is done?
> > 
> 
> Its certainly fixing the use-case of DSC to non-DSC switching. So it is 
> a fix.
> 
> But yes not the best fix possible. We have to improve it by moving this 
> to reset_intf_cfg() as I already committed to.

Ack, thanks for confirming this all and working on that, sounds good!

- Marijn

Re: [PATCH v2 3/4] drm/msm/dpu: remove GC related code from dpu catalog

[Marijn Suijten]

On 2023-04-27 13:20:28, Abhinav Kumar wrote:


> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> @@ -127,12 +127,10 @@ enum {
> >>   /**
> >>    * DSPP sub-blocks
> >>    * @DPU_DSPP_PCC Panel color correction block
> >> - * @DPU_DSPP_GC  Gamma correction block
> >>    * @DPU_DSPP_IGC Inverse gamma correction block
> >>    */
> >>   enum {
> >>   DPU_DSPP_PCC = 0x1,
> >> -    DPU_DSPP_GC,
> >>   DPU_DSPP_IGC,
> > 
> > Don't we need to remove this one too (in the previous patch)?
> 
> Yes, we should. I thought of it right after sending this. will push a v3 
> which fixes it in the prev patch.

Yes please.  Don't forget to mention that dpu_dspp_sub_blks didn't even
have an igc member describing the block.

- Marijn

> >>   DPU_DSPP_MAX
> >>   };
> >> @@ -433,22 +431,18 @@ struct dpu_sspp_sub_blks {
> >>    * @maxwidth:   Max pixel width supported by this mixer
> >>    * @maxblendstages: Max number of blend-stages supported
> >>    * @blendstage_base:    Blend-stage register base offset
> >> - * @gc: gamma correction block
> >>    */
> >>   struct dpu_lm_sub_blks {
> >>   u32 maxwidth;
> >>   u32 maxblendstages;
> >>   u32 blendstage_base[MAX_BLOCKS];
> >> -    struct dpu_pp_blk gc;
> >>   };
> >>   /**
> >>    * struct dpu_dspp_sub_blks: Information of DSPP block
> >> - * @gc : gamma correction block
> >>    * @pcc: pixel color correction block
> >>    */
> >>   struct dpu_dspp_sub_blks {
> >> -    struct dpu_pp_blk gc;
> >>   struct dpu_pp_blk pcc;
> >>   };
> > 

Re: [PATCH v2 4/4] drm/msm/dpu: drop DSPP_MSM8998_MASK from hw catalog

[Marijn Suijten]

On 2023-04-26 12:22:46, Abhinav Kumar wrote:
> Since GC and IGC masks have now been dropped DSPP_MSM8998_MASK
> is same as DSPP_SC7180_MASK. Since DSPP_SC7180_MASK is used more
> than DSPP_MSM8998_MASK, lets drop the latter.
> 
> Signed-off-by: Abhinav Kumar 

Fair enough, I'd use the oldest SoC but that'd require many more
unnecessary rename changes (or even better: we inline these flags at
some point, and drop .id fields from those already present in sblk).

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c  | 2 --
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index 2b3ae84057df..5f6e4715aa04 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -127,9 +127,9 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
>  };
>  
>  static const struct dpu_dspp_cfg msm8998_dspp[] = {
> - DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_MSM8998_MASK,
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
>_dspp_sblk),
> - DSPP_BLK("dspp_1", DSPP_1, 0x56000, DSPP_MSM8998_MASK,
> + DSPP_BLK("dspp_1", DSPP_1, 0x56000, DSPP_SC7180_MASK,
>_dspp_sblk),
>  };
>  
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index badfc3680485..2cabba0bb513 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -91,8 +91,6 @@
>  
>  #define MERGE_3D_SM8150_MASK (0)
>  
> -#define DSPP_MSM8998_MASK BIT(DPU_DSPP_PCC)
> -
>  #define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
>  
>  #define INTF_SDM845_MASK (0)
> -- 
> 2.40.1
> 

Re: [PATCH v2 2/4] drm/msm/dpu: remove DPU_DSPP_IGC handling in dspp flush

[Marijn Suijten]

DSPP*

On 2023-04-26 12:22:44, Abhinav Kumar wrote:
> Inverse gamma correction blocks (IGC) are not used today so lets
> remove the usage of DPU_DSPP_IGC in the dspp flush to make it easier

DSPP*

> to remove IGC from the catalog.
> 
> We can add this back when IGC is properly supported in DPU with
> one of the standard DRM properties.
> 
> Signed-off-by: Abhinav Kumar 

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 57adaebab563..b2a1f83ac72c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -330,9 +330,6 @@ static void 
> dpu_hw_ctl_update_pending_flush_dspp_sub_blocks(
>   return;
>  
>   switch (dspp_sub_blk) {
> - case DPU_DSPP_IGC:
> - ctx->pending_dspp_flush_mask[dspp - DSPP_0] |= BIT(2);
> - break;
>   case DPU_DSPP_PCC:
>   ctx->pending_dspp_flush_mask[dspp - DSPP_0] |= BIT(4);
>   break;
> -- 
> 2.40.1
> 

Re: [PATCH v2 1/4] drm/msm/dpu: remove DPU_DSPP_GC handling in dspp flush

[Marijn Suijten]

On 2023-04-26 12:22:43, Abhinav Kumar wrote:
> Gamma correction blocks (GC) are not used today so lets remove
> the usage of DPU_DSPP_GC in the dspp flush to make it easier
> to remove GC from the catalog.
> 
> We can add this back when GC is properly supported in DPU with
> one of the standard DRM properties.
> 
> Signed-off-by: Abhinav Kumar 
> Reviewed-by: Dmitry Baryshkov 
> Link: 
> https://lore.kernel.org/r/20230421224721.12738-1-quic_abhin...@quicinc.com

This links to v1.  I don't think you should have this here `b4` should
add it when the definitive series is applied to a tree.

Regardless:

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index bbdc95ce374a..57adaebab563 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -336,9 +336,6 @@ static void 
> dpu_hw_ctl_update_pending_flush_dspp_sub_blocks(
>   case DPU_DSPP_PCC:
>   ctx->pending_dspp_flush_mask[dspp - DSPP_0] |= BIT(4);
>   break;
> - case DPU_DSPP_GC:
> - ctx->pending_dspp_flush_mask[dspp - DSPP_0] |= BIT(5);
> - break;
>   default:
>   return;
>   }
> -- 
> 2.40.1
> 

Re: [PATCH v2 3/4] drm/msm/dpu: remove GC related code from dpu catalog

[Abhinav Kumar]

On 4/27/2023 8:57 AM, Dmitry Baryshkov wrote:

On 26/04/2023 22:22, Abhinav Kumar wrote:

Since Gamma Correction (GC) block is currently unused, drop
related code from the dpu hardware catalog otherwise this
becomes a burden to carry across chipsets in the catalog.

Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
Link: 
https://lore.kernel.org/r/20230421224721.12738-2-quic_abhin...@quicinc.com 


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 +---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 6 --
  2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

index 03f162af1a50..badfc3680485 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -91,7 +91,7 @@
  #define MERGE_3D_SM8150_MASK (0)
-#define DSPP_MSM8998_MASK BIT(DPU_DSPP_PCC) | BIT(DPU_DSPP_GC)
+#define DSPP_MSM8998_MASK BIT(DPU_DSPP_PCC)
  #define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
@@ -449,8 +449,6 @@ static const struct dpu_lm_sub_blks 
qcm2290_lm_sblk = {

  static const struct dpu_dspp_sub_blks msm8998_dspp_sblk = {
  .pcc = {.id = DPU_DSPP_PCC, .base = 0x1700,
  .len = 0x90, .version = 0x10007},
-    .gc = { .id = DPU_DSPP_GC, .base = 0x17c0,
-    .len = 0x90, .version = 0x10007},
  };
  static const struct dpu_dspp_sub_blks sc7180_dspp_sblk = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h

index 71584cd56fd7..e0dcef04bc61 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -127,12 +127,10 @@ enum {
  /**
   * DSPP sub-blocks
   * @DPU_DSPP_PCC Panel color correction block
- * @DPU_DSPP_GC  Gamma correction block
   * @DPU_DSPP_IGC Inverse gamma correction block
   */
  enum {
  DPU_DSPP_PCC = 0x1,
-    DPU_DSPP_GC,
  DPU_DSPP_IGC,


Don't we need to remove this one too (in the previous patch)?


Yes, we should. I thought of it right after sending this. will push a v3 
which fixes it in the prev patch.





  DPU_DSPP_MAX
  };
@@ -433,22 +431,18 @@ struct dpu_sspp_sub_blks {
   * @maxwidth:   Max pixel width supported by this mixer
   * @maxblendstages: Max number of blend-stages supported
   * @blendstage_base:    Blend-stage register base offset
- * @gc: gamma correction block
   */
  struct dpu_lm_sub_blks {
  u32 maxwidth;
  u32 maxblendstages;
  u32 blendstage_base[MAX_BLOCKS];
-    struct dpu_pp_blk gc;
  };
  /**
   * struct dpu_dspp_sub_blks: Information of DSPP block
- * @gc : gamma correction block
   * @pcc: pixel color correction block
   */
  struct dpu_dspp_sub_blks {
-    struct dpu_pp_blk gc;
  struct dpu_pp_blk pcc;
  };

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

> Fix the email Sign-off email != Sender email issue, resubmit and I'll
> be able to apply this.

You can pick the email from my tag “Signed-off-by” up also directly
as an ordinary patch author email, can't you?

Regards,
Markus

Re: [GIT PULL] fbdev fixes and updates for v6.4-rc1

[pr-tracker-bot]

The pull request you sent on Wed, 26 Apr 2023 20:40:07 +0200:

> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git 
> tags/fbdev-for-6.4-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/725a345b2ee3c24f9ac2078eb73667e22a1b7214

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH v3 29/65] clk: socfpga: gate: Add a determine_rate hook

[Dinh Nguyen]

Hi Maxime,

On 4/25/23 09:48, Maxime Ripard wrote:

Hi Dinh,

On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:

On 4/4/23 05:11, Maxime Ripard wrote:

The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.

This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.

The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.

So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().

The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise. __clk_mux_determine_rate() has the exact same behavior when
CLK_SET_RATE_NO_REPARENT is set.

And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.

Signed-off-by: Maxime Ripard 
---
   drivers/clk/socfpga/clk-gate.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 32ccda960f28..cbba8462a09e 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw 
*hwclk,
   static struct clk_ops gateclk_ops = {
.recalc_rate = socfpga_clk_recalc_rate,
+   .determine_rate = __clk_mux_determine_rate,
.get_parent = socfpga_clk_get_parent,
.set_parent = socfpga_clk_set_parent,
   };
@@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node)
init.name = clk_name;
init.ops = ops;
-   init.flags = 0;
+   init.flags = CLK_SET_RATE_NO_REPARENT;
init.num_parents = of_clk_parent_fill(node, parent_name, 
SOCFPGA_MAX_PARENTS);
if (init.num_parents < 2) {



This patch broke SoCFPGA boot serial port. The characters are mangled.


Do you have any other access to that board? If so, could you dump
clk_summary in debugfs with and without that patch?



That dump from the clk_summary are identical for both cases.

Re: [PATCH v3] drm/amdgpu: add a missing lock for AMDGPU_SCHED

[Alex Deucher]

Applied.  Thanks!

Alex

On Wed, Apr 26, 2023 at 6:55 PM Chia-I Wu  wrote:
>
> mgr->ctx_handles should be protected by mgr->lock.
>
> v2: improve commit message
> v3: add a Fixes tag
>
> Signed-off-by: Chia-I Wu 
> Reviewed-by: Christian König 
> Fixes: 52c6a62c64fac ("drm/amdgpu: add interface for editing a foreign 
> process's priority v3")
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
> index e9b45089a28a6..863b2a34b2d64 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
> @@ -38,6 +38,7 @@ static int amdgpu_sched_process_priority_override(struct 
> amdgpu_device *adev,
>  {
> struct fd f = fdget(fd);
> struct amdgpu_fpriv *fpriv;
> +   struct amdgpu_ctx_mgr *mgr;
> struct amdgpu_ctx *ctx;
> uint32_t id;
> int r;
> @@ -51,8 +52,11 @@ static int amdgpu_sched_process_priority_override(struct 
> amdgpu_device *adev,
> return r;
> }
>
> -   idr_for_each_entry(>ctx_mgr.ctx_handles, ctx, id)
> +   mgr = >ctx_mgr;
> +   mutex_lock(>lock);
> +   idr_for_each_entry(>ctx_handles, ctx, id)
> amdgpu_ctx_priority_override(ctx, priority);
> +   mutex_unlock(>lock);
>
> fdput(f);
> return 0;
> --
> 2.40.1.495.gc816e09b53d-goog
>

Re: [PATCH v2 net-next 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller

[Justin Chen]

On Thu, Apr 27, 2023 at 10:16 AM Rob Herring  wrote:
>
> On Wed, Apr 26, 2023 at 11:54:28AM -0700, Justin Chen wrote:
> > From: Florian Fainelli 
> >
> > Add a binding document for the Broadcom ASP 2.0 Ethernet
> > controller.
> >
> > Signed-off-by: Florian Fainelli 
> > Signed-off-by: Justin Chen 
> > ---
> >  .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 145 
> > +
> >  1 file changed, 145 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml 
> > b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> > new file mode 100644
> > index ..818d91692e6e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> > @@ -0,0 +1,145 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Broadcom ASP 2.0 Ethernet controller
> > +
> > +maintainers:
> > +  - Justin Chen 
> > +  - Florian Fainelli 
> > +
> > +description: Broadcom Ethernet controller first introduced with 72165
> > +
> > +properties:
> > +  '#address-cells':
> > +const: 1
> > +  '#size-cells':
> > +const: 1
> > +
> > +  compatible:
> > +enum:
> > +  - brcm,asp-v2.0
> > +  - brcm,bcm72165-asp-v2.0
> > +  - brcm,asp-v2.1
> > +  - brcm,bcm74165-asp-v2.1
>
> You have 1 SoC per version, so what's the point of versions? If you have
> more coming, then fine, but I'd expect it to be something like this:
>
> compatible = "brcm,bcm74165-asp-v2.1", "brcm,asp-v2.1";
>
> Also, the version in the SoC specific compatible is redundant. Just
> "brcm,bcm74165-asp" is enough.
>
> v2.1 is not compatible with v2.0? What that means is would a client/OS
> that only understands what v2.0 is work with v2.1 h/w? If so, you should
> have fallback compatible.
>
v2.1 is not compatible with v2.0 unfortunately. So no, a client/OS
that only understands v2.0 will not work with v2.1 h/w.

> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  ranges: true
> > +
> > +  interrupts:
> > +minItems: 1
> > +items:
> > +  - description: RX/TX interrupt
> > +  - description: Port 0 Wake-on-LAN
> > +  - description: Port 1 Wake-on-LAN
> > +
> > +  clocks:
> > +maxItems: 1
> > +
> > +  ethernet-ports:
>
> The ethernet-switch.yaml schema doesn't work for you?
>
Technically it is not a switch. But it might work... If we use port to
reference the unimac and reg to reference the ethernet channel. I
rather not though, just cause it is not a switch, so calling it an
ethernet-switch is confusing.

> > +type: object
> > +properties:
> > +  '#address-cells':
> > +const: 1
> > +  '#size-cells':
> > +const: 0
> > +
> > +patternProperties:
> > +  "^port@[0-9]+$":
> > +type: object
> > +
> > +$ref: ethernet-controller.yaml#
> > +
> > +properties:
> > +  reg:
> > +maxItems: 1
> > +description: Port number
> > +
> > +  channel:
> > +maxItems: 1
> > +description: ASP channel number
>
> Not a standard property, so it needs a type and vendor prefix. However,
> what's the difference between channel and port? Can the port numbers
> correspond to the channels?
>
Port refers to the unimac. In our case we currently have a maximum of
2. Channel refers to the ethernet hardware channel proper, in which we
have many. So yes, you can have a port correlate to any channel.

> > +
> > +required:
> > +  - reg
> > +  - channel
> > +
> > +additionalProperties: false
> > +
> > +patternProperties:
> > +  "^mdio@[0-9a-f]+$":
> > +type: object
> > +$ref: "brcm,unimac-mdio.yaml"
>
> Drop quotes.
>
> > +
> > +description:
> > +  ASP internal UniMAC MDIO bus
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - clocks
> > +  - ranges
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +#include 
> > +#include 
> > +
> > +ethernet@9c0 {
> > +compatible = "brcm,asp-v2.0";
> > +reg = <0x9c0 0x1fff14>;
> > +interrupts = ;
> > +ranges;
> > +clocks = < 14>;
> > +#address-cells = <1>;
> > +#size-cells = <1>;
> > +
> > +mdio@c614 {
> > +compatible = "brcm,asp-v2.0-mdio";
> > +reg = <0xc614 0x8>;
>
> You have 1:1 ranges, is that really what you want? That means 0xc614 is
> an absolute address.
Ack, will fix.

Thanks for the review,
Justin

>
> > +reg-names = "mdio";
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +phy0: ethernet-phy@1 {
> > +reg = <1>;
> > +};
> > +   };
> > +
> > +mdio@ce14 {
> > +  

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Lionel Landwerlin]

On 27/04/2023 21:19, Teres Alexis, Alan Previn wrote:

(fixed email addresses again - why is my Evolution client deteorating??)

On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote:

On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:

On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:

alan:snip

Can you tell that pxp is in progress, but not ready yet, as a separate
state from 'it will never work on this platform'? If so, maybe the
status could return something like:

0: It's never going to work
1: It's ready to use
2: It's starting and should work soon

I could see an argument for treating that as a case where we could
still advertise protected content support, but if we try to use it we
might be in for a nasty delay.


alan: IIRC Lionel seemed okay with any permutation that would allow it to not
get blocked. Daniele did ask for something similiar to what u mentioned above
but he said that is non-blocking. But since both you AND Daniele have mentioned
the same thing, i shall re-rev this and send that change out today.
I notice most GET_PARAMS use -ENODEV for "never gonna work" so I will stick 
with that.
but 1 = ready to use and 2 = starting and should work sounds good. so '0' will 
never
be returned - we just look for a positive value (from user space). I will also
make a PR for mesa side as soon as i get it tested. thanks for reviewing btw.

alan: I also realize with these final touch-ups, we can go back to the original
pxp-context-creation timeout of 250 milisecs like it was on ADL since the user
space component will have this new param to check on (so even farther down from
1 sec on the last couple of revs).

Jordan, Lional - i am thinking of creating the PR on MESA side to take advantage
of GET_PARAM on both get-caps AND runtime creation (latter will be useful to 
ensure
no unnecesssary delay experienced by Mesa stuck in kernel call - which 
practically
never happenned in ADL AFAIK):

1. MESA PXP get caps:
- use GET_PARAM (any positive number shall mean its supported).
2. MESA app-triggered PXP context creation (i.e. if caps was supported):
- use GET_PARAM to wait until positive number switches from "2" to "1".
- now call context creation. So at this point if it fails, we know its
  an actual failure.

you guys okay with above? (i'll re-rev this kernel series first and wait on your
ack or feedback before i create/ test/ submit a PR for Mesa side).



Sounds good.

Thanks,


-Lionel

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Teres Alexis, Alan Previn]

(fixed email addresses again - why is my Evolution client deteorating??)

On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote:
> On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:
> > On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:
> alan:snip
> > Can you tell that pxp is in progress, but not ready yet, as a separate
> > state from 'it will never work on this platform'? If so, maybe the
> > status could return something like:
> > 
> > 0: It's never going to work
> > 1: It's ready to use
> > 2: It's starting and should work soon
> > 
> > I could see an argument for treating that as a case where we could
> > still advertise protected content support, but if we try to use it we
> > might be in for a nasty delay.
> > 
> alan: IIRC Lionel seemed okay with any permutation that would allow it to not
> get blocked. Daniele did ask for something similiar to what u mentioned above
> but he said that is non-blocking. But since both you AND Daniele have 
> mentioned
> the same thing, i shall re-rev this and send that change out today.
> I notice most GET_PARAMS use -ENODEV for "never gonna work" so I will stick 
> with that.
> but 1 = ready to use and 2 = starting and should work sounds good. so '0' 
> will never
> be returned - we just look for a positive value (from user space). I will also
> make a PR for mesa side as soon as i get it tested. thanks for reviewing btw.

alan: I also realize with these final touch-ups, we can go back to the original
pxp-context-creation timeout of 250 milisecs like it was on ADL since the user
space component will have this new param to check on (so even farther down from
1 sec on the last couple of revs).

Jordan, Lional - i am thinking of creating the PR on MESA side to take advantage
of GET_PARAM on both get-caps AND runtime creation (latter will be useful to 
ensure
no unnecesssary delay experienced by Mesa stuck in kernel call - which 
practically
never happenned in ADL AFAIK):

1. MESA PXP get caps: 
- use GET_PARAM (any positive number shall mean its supported).
2. MESA app-triggered PXP context creation (i.e. if caps was supported):
- use GET_PARAM to wait until positive number switches from "2" to "1".
- now call context creation. So at this point if it fails, we know its
  an actual failure.

you guys okay with above? (i'll re-rev this kernel series first and wait on your
ack or feedback before i create/ test/ submit a PR for Mesa side).

[PATCH] drm: Switch i2c drivers back to use .probe()

[Uwe Kleine-König]

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.

Signed-off-by: Uwe Kleine-König 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c   | 2 +-
 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c   | 2 +-
 drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
 drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
 drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
 drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
 drivers/gpu/drm/bridge/ite-it6505.c  | 2 +-
 drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
 drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
 drivers/gpu/drm/bridge/lontium-lt9211.c  | 2 +-
 drivers/gpu/drm/bridge/lontium-lt9611.c  | 2 +-
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c   | 2 +-
 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
 drivers/gpu/drm/bridge/parade-ps8622.c   | 2 +-
 drivers/gpu/drm/bridge/parade-ps8640.c   | 2 +-
 drivers/gpu/drm/bridge/sii902x.c | 2 +-
 drivers/gpu/drm/bridge/sii9234.c | 2 +-
 drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
 drivers/gpu/drm/bridge/tc358767.c| 2 +-
 drivers/gpu/drm/bridge/tc358768.c| 2 +-
 drivers/gpu/drm/bridge/tc358775.c| 2 +-
 drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
 drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
 drivers/gpu/drm/bridge/ti-tfp410.c   | 2 +-
 drivers/gpu/drm/i2c/tda9950.c| 2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c   | 2 +-
 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
 drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
 32 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ddceafa7b637..2254457ab5d0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1393,7 +1393,7 @@ static struct i2c_driver adv7511_driver = {
.of_match_table = adv7511_of_ids,
},
.id_table = adv7511_i2c_ids,
-   .probe_new = adv7511_probe,
+   .probe = adv7511_probe,
.remove = adv7511_remove,
 };
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 3577c532abb4..72ab2ab77081 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -815,7 +815,7 @@ static struct i2c_driver anx6345_driver = {
   .name = "anx6345",
   .of_match_table = of_match_ptr(anx6345_match_table),
  },
-   .probe_new = anx6345_i2c_probe,
+   .probe = anx6345_i2c_probe,
.remove = anx6345_i2c_remove,
.id_table = anx6345_id,
 };
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index a3a38bbe2786..06a3e3243e19 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -1389,7 +1389,7 @@ static struct i2c_driver anx78xx_driver = {
   .name = "anx7814",
   .of_match_table = of_match_ptr(anx78xx_match_table),
  },
-   .probe_new = anx78xx_i2c_probe,
+   .probe = anx78xx_i2c_probe,
.remove = anx78xx_i2c_remove,
.id_table = anx78xx_id,
 };
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 6846199a2ee1..0a97364ba8ea 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2753,7 +2753,7 @@ static struct i2c_driver anx7625_driver = {
.of_match_table = anx_match_table,
.pm = _pm_ops,
},
-   .probe_new = anx7625_i2c_probe,
+   .probe = anx7625_i2c_probe,
.remove = anx7625_i2c_remove,
 
.id_table = anx7625_id,
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c 
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index 0e37840cd7a8..8bfce21d6b90 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ 

[PATCH v2 9/9] drm/msm: Wire up comm/cmdline override for fdinfo

[Rob Clark]

From: Rob Clark 

Also store the override strings in drm_file so that fdinfo can display
them.  We still need to keep our original copy as we could need these
override strings after the device file has been closed and drm_file
freed.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 24 +++-
 drivers/gpu/drm/msm/msm_drv.c   |  2 ++
 drivers/gpu/drm/msm/msm_gpu.h   | 10 ++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index bb38e728864d..a20c2622a61f 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "adreno_gpu.h"
 #include "a6xx_gpu.h"
 #include "msm_gem.h"
@@ -398,7 +399,8 @@ int adreno_set_param(struct msm_gpu *gpu, struct 
msm_file_private *ctx,
switch (param) {
case MSM_PARAM_COMM:
case MSM_PARAM_CMDLINE: {
-   char *str, **paramp;
+   char *str, *str2, **paramp;
+   struct drm_file *file = ctx->file;
 
str = kmalloc(len + 1, GFP_KERNEL);
if (!str)
@@ -412,6 +414,13 @@ int adreno_set_param(struct msm_gpu *gpu, struct 
msm_file_private *ctx,
/* Ensure string is null terminated: */
str[len] = '\0';
 
+   /*
+* We need a 2nd copy for drm_file.. this copy can't replace
+* our internal copy in the ctx, because we may need it for
+* recovery/devcoredump after the file is already closed.
+*/
+   str2 = kstrdup(str, GFP_KERNEL);
+
mutex_lock(>lock);
 
if (param == MSM_PARAM_COMM) {
@@ -425,6 +434,19 @@ int adreno_set_param(struct msm_gpu *gpu, struct 
msm_file_private *ctx,
 
mutex_unlock(>lock);
 
+   mutex_lock(>override_lock);
+
+   if (param == MSM_PARAM_COMM) {
+   paramp = >override_comm;
+   } else {
+   paramp = >override_cmdline;
+   }
+
+   kfree(*paramp);
+   *paramp = str2;
+
+   mutex_unlock(>override_lock);
+
return 0;
}
case MSM_PARAM_SYSPROF:
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 81a1371c0307..3a74b5653e96 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -581,6 +581,7 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
rwlock_init(>queuelock);
 
kref_init(>ref);
+   ctx->file = file;
msm_submitqueue_init(dev, ctx);
 
ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
@@ -603,6 +604,7 @@ static int msm_open(struct drm_device *dev, struct drm_file 
*file)
 
 static void context_close(struct msm_file_private *ctx)
 {
+   ctx->file = NULL;
msm_submitqueue_close(ctx);
msm_file_private_put(ctx);
 }
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 7a4fa1b8655b..671ce89e61b0 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -359,6 +359,16 @@ struct msm_file_private {
struct kref ref;
int seqno;
 
+   /**
+* @file: link back to the associated drm_file
+*
+* Note that msm_file_private can outlive the drm_file, ie.
+* after the drm_file is closed but before jobs submitted have
+* been cleaned up.  After the drm_file is closed this will be
+* NULL.
+*/
+   struct drm_file *file;
+
/**
 * sysprof:
 *
-- 
2.39.2

[PATCH v2 7/9] drm/doc: Relax fdinfo string constraints

[Rob Clark]

From: Rob Clark 

The restriction about no whitespace, etc, really only applies to the
usage of strings in keys.  Values can contain anything (other than
newline).

Signed-off-by: Rob Clark 
Acked-by: Tvrtko Ursulin 
---
 Documentation/gpu/drm-usage-stats.rst | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index bfc14150452c..58dc0d3f8c58 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -24,7 +24,7 @@ File format specification
 - All keys shall be prefixed with `drm-`.
 - Whitespace between the delimiter and first non-whitespace character shall be
   ignored when parsing.
-- Neither keys or values are allowed to contain whitespace characters.
+- Keys are not allowed to contain whitespace characters.
 - Numerical key value pairs can end with optional unit string.
 - Data type of the value is fixed as defined in the specification.
 
@@ -39,12 +39,13 @@ Data types
 --
 
 -  - Unsigned integer without defining the maximum value.
--  - String excluding any above defined reserved characters or whitespace.
+-  - String excluding any above defined reserved characters or 
whitespace.
+-  - String.
 
 Mandatory fully standardised keys
 -
 
-- drm-driver: 
+- drm-driver: 
 
 String shall contain the name this driver registered as via the respective
 `struct drm_driver` data structure.
@@ -75,10 +76,10 @@ the above described criteria in order to associate data to 
individual clients.
 Utilization
 ^^^
 
-- drm-engine-:  ns
+- drm-engine-:  ns
 
 GPUs usually contain multiple execution engines. Each shall be given a stable
-and unique name (str), with possible values documented in the driver specific
+and unique name (keystr), with possible values documented in the driver 
specific
 documentation.
 
 Value shall be in specified time units which the respective GPU engine spent
@@ -90,19 +91,19 @@ larger value within a reasonable period. Upon observing a 
value lower than what
 was previously read, userspace is expected to stay with that larger previous
 value until a monotonic update is seen.
 
-- drm-engine-capacity-: 
+- drm-engine-capacity-: 
 
 Engine identifier string must be the same as the one specified in the
-drm-engine- tag and shall contain a greater than zero number in case the
+drm-engine- tag and shall contain a greater than zero number in case 
the
 exported engine corresponds to a group of identical hardware engines.
 
 In the absence of this tag parser shall assume capacity of one. Zero capacity
 is not allowed.
 
-- drm-cycles-: 
+- drm-cycles-: 
 
 Engine identifier string must be the same as the one specified in the
-drm-engine- tag and shall contain the number of busy cycles for the given
+drm-engine- tag and shall contain the number of busy cycles for the 
given
 engine.
 
 Values are not required to be constantly monotonic if it makes the driver
@@ -111,12 +112,12 @@ larger value within a reasonable period. Upon observing a 
value lower than what
 was previously read, userspace is expected to stay with that larger previous
 value until a monotonic update is seen.
 
-- drm-maxfreq-:  [Hz|MHz|KHz]
+- drm-maxfreq-:  [Hz|MHz|KHz]
 
 Engine identifier string must be the same as the one specified in the
-drm-engine- tag and shall contain the maximum frequency for the given
-engine.  Taken together with drm-cycles-, this can be used to calculate
-percentage utilization of the engine, whereas drm-engine- only reflects
+drm-engine- tag and shall contain the maximum frequency for the given
+engine.  Taken together with drm-cycles-, this can be used to calculate
+percentage utilization of the engine, whereas drm-engine- only reflects
 time active without considering what frequency the engine is operating as a
 percentage of it's maximum frequency.
 
-- 
2.39.2

[PATCH v2 8/9] drm/fdinfo: Add comm/cmdline override fields

[Rob Clark]

From: Rob Clark 

These are useful in particular for VM scenarios where the process which
has opened to drm device file is just a proxy for the real user in a VM
guest.

Signed-off-by: Rob Clark 
---
 Documentation/gpu/drm-usage-stats.rst | 18 ++
 drivers/gpu/drm/drm_file.c| 15 +++
 include/drm/drm_file.h| 19 +++
 3 files changed, 52 insertions(+)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index 58dc0d3f8c58..e4877cf8089c 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -73,6 +73,24 @@ scope of each device, in which case `drm-pdev` shall be 
present as well.
 Userspace should make sure to not double account any usage statistics by using
 the above described criteria in order to associate data to individual clients.
 
+- drm-comm-override: 
+
+Returns the client executable override string.  Some drivers support letting
+userspace override this in cases where the userspace is simply a "proxy".
+Such as is the case with virglrenderer drm native context, where the host
+process is just forwarding command submission, etc, from guest userspace.
+This allows the proxy to make visible the executable name of the actual
+app in the VM guest.
+
+- drm-cmdline-override: 
+
+Returns the client cmdline override string.  Some drivers support letting
+userspace override this in cases where the userspace is simply a "proxy".
+Such as is the case with virglrenderer drm native context, where the host
+process is just forwarding command submission, etc, from guest userspace.
+This allows the proxy to make visible the cmdline of the actual app in the
+VM guest.
+
 Utilization
 ^^^
 
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 9321eb0bf020..d7514c313af1 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -178,6 +178,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
spin_lock_init(>master_lookup_lock);
mutex_init(>event_read_lock);
 
+   mutex_init(>override_lock);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, file);
 
@@ -292,6 +294,8 @@ void drm_file_free(struct drm_file *file)
WARN_ON(!list_empty(>event_list));
 
put_pid(file->pid);
+   kfree(file->override_comm);
+   kfree(file->override_cmdline);
kfree(file);
 }
 
@@ -995,6 +999,17 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
   PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
}
 
+   mutex_lock(>override_lock);
+   if (file->override_comm) {
+   drm_printf(, "drm-comm-override:\t%s\n",
+  file->override_comm);
+   }
+   if (file->override_cmdline) {
+   drm_printf(, "drm-cmdline-override:\t%s\n",
+  file->override_cmdline);
+   }
+   mutex_unlock(>override_lock);
+
if (dev->driver->show_fdinfo)
dev->driver->show_fdinfo(, file);
 }
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 1339e925af52..604d05fa6f0c 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -370,6 +370,25 @@ struct drm_file {
 */
struct drm_prime_file_private prime;
 
+   /**
+* @comm: Overridden task comm
+*
+* Accessed under override_lock
+*/
+   char *override_comm;
+
+   /**
+* @cmdline: Overridden task cmdline
+*
+* Accessed under override_lock
+*/
+   char *override_cmdline;
+
+   /**
+* @override_lock: Serialize access to override_comm and 
override_cmdline
+*/
+   struct mutex override_lock;
+
/* private: */
 #if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
-- 
2.39.2

[PATCH v2 5/9] drm: Add fdinfo memory stats

[Rob Clark]

From: Rob Clark 

Add support to dump GEM stats to fdinfo.

v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
v4: more kerneldoc

Signed-off-by: Rob Clark 
Reviewed-by: Emil Velikov 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/drm-usage-stats.rst | 54 +++
 drivers/gpu/drm/drm_file.c| 99 ++-
 include/drm/drm_file.h| 19 +
 include/drm/drm_gem.h | 30 
 4 files changed, 189 insertions(+), 13 deletions(-)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index 552195fb1ea3..bfc14150452c 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -52,6 +52,9 @@ String shall contain the name this driver registered as via 
the respective
 Optional fully standardised keys
 
 
+Identification
+^^
+
 - drm-pdev: 
 
 For PCI devices this should contain the PCI slot address of the device in
@@ -69,6 +72,9 @@ scope of each device, in which case `drm-pdev` shall be 
present as well.
 Userspace should make sure to not double account any usage statistics by using
 the above described criteria in order to associate data to individual clients.
 
+Utilization
+^^^
+
 - drm-engine-:  ns
 
 GPUs usually contain multiple execution engines. Each shall be given a stable
@@ -93,18 +99,6 @@ exported engine corresponds to a group of identical hardware 
engines.
 In the absence of this tag parser shall assume capacity of one. Zero capacity
 is not allowed.
 
-- drm-memory-:  [KiB|MiB]
-
-Each possible memory type which can be used to store buffer objects by the
-GPU in question shall be given a stable and unique name to be returned as the
-string here.
-
-Value shall reflect the amount of storage currently consumed by the buffer
-object belong to this client, in the respective memory region.
-
-Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
-indicating kibi- or mebi-bytes.
-
 - drm-cycles-: 
 
 Engine identifier string must be the same as the one specified in the
@@ -126,6 +120,42 @@ percentage utilization of the engine, whereas 
drm-engine- only reflects
 time active without considering what frequency the engine is operating as a
 percentage of it's maximum frequency.
 
+Memory
+^^
+
+- drm-memory-:  [KiB|MiB]
+
+Each possible memory type which can be used to store buffer objects by the
+GPU in question shall be given a stable and unique name to be returned as the
+string here.  The name "memory" is reserved to refer to normal system memory.
+
+Value shall reflect the amount of storage currently consumed by the buffer
+object belong to this client, in the respective memory region.
+
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
+indicating kibi- or mebi-bytes.
+
+- drm-shared-:  [KiB|MiB]
+
+The total size of buffers that are shared with another file (ie. have more
+than a single handle).
+
+- drm-private-:  [KiB|MiB]
+
+The total size of buffers that are not shared with another file.
+
+- drm-resident-:  [KiB|MiB]
+
+The total size of buffers that are resident in system memory.
+
+- drm-purgeable-:  [KiB|MiB]
+
+The total size of buffers that are purgeable.
+
+- drm-active-:  [KiB|MiB]
+
+The total size of buffers that are active on one or more rings.
+
 Implementation Details
 ==
 
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 6d5bdd684ae2..9321eb0bf020 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -871,9 +872,105 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
 }
 EXPORT_SYMBOL(drm_send_event);
 
+static void print_size(struct drm_printer *p, const char *stat,
+  const char *region, size_t sz)
+{
+   const char *units[] = {"", " KiB", " MiB"};
+   unsigned u;
+
+   for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+   if (sz < SZ_1K)
+   break;
+   sz = div_u64(sz, SZ_1K);
+   }
+
+   drm_printf(p, "drm-%s-%s:\t%zu%s\n", stat, region, sz, units[u]);
+}
+
+/**
+ * drm_print_memory_stats - A helper to print memory stats
+ * @p: The printer to print output to
+ * @stats: The collected memory stats
+ * @supported_status: Bitmask of optional stats which are available
+ * @region: The memory region
+ *
+ */
+void drm_print_memory_stats(struct drm_printer *p,
+   const struct drm_memory_stats *stats,
+   enum drm_gem_object_status supported_status,
+   const char *region)
+{
+   print_size(p, "total", region, stats->private + stats->shared);
+   print_size(p, "shared", region, stats->shared);
+   print_size(p, "active", region, stats->active);
+
+ 

[PATCH v2 3/9] drm/msm: Switch to fdinfo helper

[Rob Clark]

From: Rob Clark 

Now that we have a common helper, use it.

Signed-off-by: Rob Clark 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/msm_drv.c | 11 +--
 drivers/gpu/drm/msm/msm_gpu.c |  2 --
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9b6f17b1261f..1e941aa77609 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1043,23 +1043,21 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
DRM_RENDER_ALLOW),
 };
 
-static void msm_fop_show_fdinfo(struct seq_file *m, struct file *f)
+static void msm_show_fdinfo(struct drm_printer *p, struct drm_file *file)
 {
-   struct drm_file *file = f->private_data;
struct drm_device *dev = file->minor->dev;
struct msm_drm_private *priv = dev->dev_private;
-   struct drm_printer p = drm_seq_file_printer(m);
 
if (!priv->gpu)
return;
 
-   msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, );
+   msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, p);
 }
 
 static const struct file_operations fops = {
.owner = THIS_MODULE,
DRM_GEM_FOPS,
-   .show_fdinfo = msm_fop_show_fdinfo,
+   .show_fdinfo = drm_show_fdinfo,
 };
 
 static const struct drm_driver msm_driver = {
@@ -1069,7 +1067,7 @@ static const struct drm_driver msm_driver = {
DRIVER_MODESET |
DRIVER_SYNCOBJ,
.open   = msm_open,
-   .postclose   = msm_postclose,
+   .postclose  = msm_postclose,
.lastclose  = drm_fb_helper_lastclose,
.dumb_create= msm_gem_dumb_create,
.dumb_map_offset= msm_gem_dumb_map_offset,
@@ -1080,6 +1078,7 @@ static const struct drm_driver msm_driver = {
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = msm_debugfs_init,
 #endif
+   .show_fdinfo= msm_show_fdinfo,
.ioctls = msm_ioctls,
.num_ioctls = ARRAY_SIZE(msm_ioctls),
.fops   = ,
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index b1647b851018..52db90e34ead 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -151,8 +151,6 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
 void msm_gpu_show_fdinfo(struct msm_gpu *gpu, struct msm_file_private *ctx,
 struct drm_printer *p)
 {
-   drm_printf(p, "drm-driver:\t%s\n", gpu->dev->driver->name);
-   drm_printf(p, "drm-client-id:\t%u\n", ctx->seqno);
drm_printf(p, "drm-engine-gpu:\t%llu ns\n", ctx->elapsed_ns);
drm_printf(p, "drm-cycles-gpu:\t%llu\n", ctx->cycles);
drm_printf(p, "drm-maxfreq-gpu:\t%u Hz\n", gpu->fast_rate);
-- 
2.39.2

[PATCH v2 4/9] drm/amdgpu: Switch to fdinfo helper

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |  2 +-
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index f5ffca24def4..6c0e0c614b94 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2752,7 +2752,7 @@ static const struct file_operations 
amdgpu_driver_kms_fops = {
.compat_ioctl = amdgpu_kms_compat_ioctl,
 #endif
 #ifdef CONFIG_PROC_FS
-   .show_fdinfo = amdgpu_show_fdinfo
+   .show_fdinfo = drm_show_fdinfo,
 #endif
 };
 
@@ -2807,6 +2807,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
.release = _driver_release_kms,
+   .show_fdinfo = amdgpu_show_fdinfo,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 99a7855ab1bc..c2fdd5e448d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -53,9 +53,8 @@ static const char *amdgpu_ip_name[AMDGPU_HW_IP_NUM] = {
[AMDGPU_HW_IP_VCN_JPEG] =   "jpeg",
 };
 
-void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
+void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file)
 {
-   struct drm_file *file = f->private_data;
struct amdgpu_device *adev = drm_to_adev(file->minor->dev);
struct amdgpu_fpriv *fpriv = file->driver_priv;
struct amdgpu_vm *vm = >vm;
@@ -86,18 +85,15 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
 * **
 */
 
-   seq_printf(m, "pasid:\t%u\n", fpriv->vm.pasid);
-   seq_printf(m, "drm-driver:\t%s\n", file->minor->dev->driver->name);
-   seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", domain, bus, dev, fn);
-   seq_printf(m, "drm-client-id:\t%Lu\n", vm->immediate.fence_context);
-   seq_printf(m, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
-   seq_printf(m, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
-   seq_printf(m, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
+   drm_printf(p, "pasid:\t%u\n", fpriv->vm.pasid);
+   drm_printf(p, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
+   drm_printf(p, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
+   drm_printf(p, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
 
-   seq_printf(m, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
+   drm_printf(p, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
   ktime_to_ns(usage[hw_ip]));
}
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
index e86834bfea1d..0398f5a159ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
@@ -37,6 +37,6 @@
 #include "amdgpu_ids.h"
 
 uint32_t amdgpu_get_ip_count(struct amdgpu_device *adev, int id);
-void amdgpu_show_fdinfo(struct seq_file *m, struct file *f);
+void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file);
 
 #endif
-- 
2.39.2

[PATCH v2 6/9] drm/msm: Add memory stats to fdinfo

[Rob Clark]

From: Rob Clark 

Use the new helper to export stats about memory usage.

v2: Drop unintended hunk
v3: Rebase

Signed-off-by: Rob Clark 
Reviewed-by: Emil Velikov 
---
 drivers/gpu/drm/msm/msm_drv.c |  2 ++
 drivers/gpu/drm/msm/msm_gem.c | 15 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1e941aa77609..81a1371c0307 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1052,6 +1052,8 @@ static void msm_show_fdinfo(struct drm_printer *p, struct 
drm_file *file)
return;
 
msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, p);
+
+   drm_show_memory_stats(p, file);
 }
 
 static const struct file_operations fops = {
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index cd39b9d8abdb..20cfd86d2b32 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1090,6 +1090,20 @@ int msm_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
return ret;
 }
 
+static enum drm_gem_object_status msm_gem_status(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   enum drm_gem_object_status status = 0;
+
+   if (msm_obj->pages)
+   status |= DRM_GEM_OBJECT_RESIDENT;
+
+   if (msm_obj->madv == MSM_MADV_DONTNEED)
+   status |= DRM_GEM_OBJECT_PURGEABLE;
+
+   return status;
+}
+
 static const struct vm_operations_struct vm_ops = {
.fault = msm_gem_fault,
.open = drm_gem_vm_open,
@@ -1104,6 +1118,7 @@ static const struct drm_gem_object_funcs 
msm_gem_object_funcs = {
.vmap = msm_gem_prime_vmap,
.vunmap = msm_gem_prime_vunmap,
.mmap = msm_gem_object_mmap,
+   .status = msm_gem_status,
.vm_ops = _ops,
 };
 
-- 
2.39.2

[PATCH v2 2/9] drm: Add common fdinfo helper

[Rob Clark]

From: Rob Clark 

Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats.  This also ensures consistent behavior
across drivers for standardised fields.

v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo

Reviewed-by: Daniel Vetter 
Signed-off-by: Rob Clark 
---
 Documentation/gpu/drm-usage-stats.rst | 10 +++-
 drivers/gpu/drm/drm_file.c| 35 +++
 include/drm/drm_drv.h |  7 ++
 include/drm/drm_file.h|  4 +++
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index 72d069e5dacb..552195fb1ea3 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -126,7 +126,15 @@ percentage utilization of the engine, whereas 
drm-engine- only reflects
 time active without considering what frequency the engine is operating as a
 percentage of it's maximum frequency.
 
+Implementation Details
+==
+
+Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
+implement _driver.show_fdinfo if they wish to provide any stats which
+are not provided by drm_show_fdinfo().  But even driver specific stats should
+be documented above and where possible, aligned with other drivers.
+
 Driver specific implementations
-===
+---
 
 :ref:`i915-usage-stats`
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..6d5bdd684ae2 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
  */
 struct drm_file *drm_file_alloc(struct drm_minor *minor)
 {
+   static atomic64_t ident = ATOMIC_INIT(0);
struct drm_device *dev = minor->dev;
struct drm_file *file;
int ret;
@@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (!file)
return ERR_PTR(-ENOMEM);
 
+   /* Get a unique identifier for fdinfo: */
+   file->client_id = atomic64_inc_return();
file->pid = get_pid(task_pid(current));
file->minor = minor;
 
@@ -868,6 +871,38 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
 }
 EXPORT_SYMBOL(drm_send_event);
 
+/**
+ * drm_show_fdinfo - helper for drm file fops
+ * @seq_file: output stream
+ * @f: the device file instance
+ *
+ * Helper to implement fdinfo, for userspace to query usage stats, etc, of a
+ * process using the GPU.  See also _driver.show_fdinfo.
+ *
+ * For text output format description please see 
Documentation/gpu/drm-usage-stats.rst
+ */
+void drm_show_fdinfo(struct seq_file *m, struct file *f)
+{
+   struct drm_file *file = f->private_data;
+   struct drm_device *dev = file->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
+   drm_printf(, "drm-client-id:\t%llu\n", file->client_id);
+
+   if (dev_is_pci(dev->dev)) {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+   drm_printf(, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+  pci_domain_nr(pdev->bus), pdev->bus->number,
+  PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+   }
+
+   if (dev->driver->show_fdinfo)
+   dev->driver->show_fdinfo(, file);
+}
+EXPORT_SYMBOL(drm_show_fdinfo);
+
 /**
  * mock_drm_getfile - Create a new struct file for the drm device
  * @minor: drm minor to wrap (e.g. #drm_device.primary)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5b86bb7603e7..5edf2a13733b 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -401,6 +401,13 @@ struct drm_driver {
   struct drm_device *dev, uint32_t handle,
   uint64_t *offset);
 
+   /**
+* @show_fdinfo:
+*
+* Print device specific fdinfo.  See 
Documentation/gpu/drm-usage-stats.rst.
+*/
+   void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
+
/** @major: driver major number */
int major;
/** @minor: driver minor number */
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0d1f853092ab..6de6d0e9c634 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -258,6 +258,9 @@ struct drm_file {
/** @pid: Process that opened this file. */
struct pid *pid;
 
+   /** @client_id: A unique id for fdinfo */
+   u64 client_id;
+
/** @magic: Authentication magic, see @authenticated. */
drm_magic_t magic;
 
@@ -437,6 +440,7 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e);
 void drm_send_event_timestamp_locked(struct drm_device *dev,
 struct 

[PATCH v2 1/9] drm/docs: Fix usage stats typos

[Rob Clark]

From: Rob Clark 

Fix a couple missing ':'s.

Signed-off-by: Rob Clark 
Reviewed-by: Rodrigo Vivi 
---
 Documentation/gpu/drm-usage-stats.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..72d069e5dacb 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -105,7 +105,7 @@ object belong to this client, in the respective memory 
region.
 Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
 indicating kibi- or mebi-bytes.
 
-- drm-cycles- 
+- drm-cycles-: 
 
 Engine identifier string must be the same as the one specified in the
 drm-engine- tag and shall contain the number of busy cycles for the given
@@ -117,7 +117,7 @@ larger value within a reasonable period. Upon observing a 
value lower than what
 was previously read, userspace is expected to stay with that larger previous
 value until a monotonic update is seen.
 
-- drm-maxfreq-  [Hz|MHz|KHz]
+- drm-maxfreq-:  [Hz|MHz|KHz]
 
 Engine identifier string must be the same as the one specified in the
 drm-engine- tag and shall contain the maximum frequency for the given
-- 
2.39.2

[PATCH v2 0/9] drm: fdinfo memory stats

[Rob Clark]

From: Rob Clark 

Similar motivation to other similar recent attempt[1].  But with an
attempt to have some shared code for this.  As well as documentation.

It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.  But this seems like a reasonable start.

Basic gputop support: https://patchwork.freedesktop.org/series/116236/
And already nvtop support: https://github.com/Syllo/nvtop/pull/204

I've combined the separate series to add comm/cmdline override onto
the end of this, simply out of convenience (they would otherwise
conflict in a bunch of places).

v2: Extend things to allow for multiple regions other than just system
"memory", make drm_show_memory_stats() a helper so that, drivers
can use it or not based on their needs (but in either case, re-
use drm_print_memory_stats()

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


Rob Clark (9):
  drm/docs: Fix usage stats typos
  drm: Add common fdinfo helper
  drm/msm: Switch to fdinfo helper
  drm/amdgpu: Switch to fdinfo helper
  drm: Add fdinfo memory stats
  drm/msm: Add memory stats to fdinfo
  drm/doc: Relax fdinfo string constraints
  drm/fdinfo: Add comm/cmdline override fields
  drm/msm: Wire up comm/cmdline override for fdinfo

 Documentation/gpu/drm-usage-stats.rst  | 109 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  16 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |   2 +-
 drivers/gpu/drm/drm_file.c | 147 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  24 +++-
 drivers/gpu/drm/msm/msm_drv.c  |  15 ++-
 drivers/gpu/drm/msm/msm_gem.c  |  15 +++
 drivers/gpu/drm/msm/msm_gpu.c  |   2 -
 drivers/gpu/drm/msm/msm_gpu.h  |  10 ++
 include/drm/drm_drv.h  |   7 +
 include/drm/drm_file.h |  42 ++
 include/drm/drm_gem.h  |  30 +
 13 files changed, 375 insertions(+), 47 deletions(-)

-- 
2.39.2

Re: [PATCH v4 18/22] drm/msm/dpu: Describe TEAR interrupt registers for DSI interfaces

[Dmitry Baryshkov]

On 27/04/2023 01:37, Marijn Suijten wrote:

All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block.  Wire up the IRQ register
masks in the interrupt table for enabling, reading and clearing them.

Signed-off-by: Marijn Suijten 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 28 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  4 
  2 files changed, 32 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v4 07/22] drm/msm/dpu: Set PINGPONG block length to zero for DPU >= 7.0.0

[Dmitry Baryshkov]

On 27/04/2023 01:37, Marijn Suijten wrote:

Despite downstream DTS stating otherwise, the PINGPONG block has no
registers starting with DPU revision 7.0.0.  TEAR registers are gone
since DPU 5.0.0 after being moved to the INTF block, and DSC registers
are gone since 7.0.0, leaving only the dither sub-block.

A future patch, part of the DSC 1.2 series, should disable DSC functions
on the PINGPONG block for all DPU >= 7.0.0 hardware.

Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
Signed-off-by: Marijn Suijten 
---
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 12 ++--
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   |  8 
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++--
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 16 
  4 files changed, 24 insertions(+), 24 deletions(-)


https://patchwork.freedesktop.org/patch/534306/?series=116327=2

--
With best wishes
Dmitry

Re: [PATCH 0/5] fbdev: Move framebuffer I/O helpers to

[Sam Ravnborg]

Hi Thomas,

On Thu, Apr 27, 2023 at 09:22:47AM +0200, Thomas Zimmermann wrote:
> Hi Sam
> 
> Am 26.04.23 um 21:21 schrieb Sam Ravnborg:
> > Hi Thomas.
> > 
> > On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote:
> > > Fbdev provides helpers for framebuffer I/O, such as fb_readl(),
> > > fb_writel() or fb_memcpy_to_fb(). The implementation of each helper
> > > depends on the architecture. It's still all located in fbdev's main
> > > header file . Move all of it into each archtecture's
> > > , with shared code in .
> > 
> > For once I think this cleanup is moving things in the wrong direction.
> > 
> > The fb_* helpers predates the generic io.h support and try to
> > add a generic layer for read read / write operations.
> > 
> > The right fix would be to migrate fb_* to use the io helpers
> > we have today - so we use the existing way to handle the architecture
> > specific details.
> 
> I looked through the existing versions of the fb_() I/O helpers. They can
> apparently be implemented with the regular helpers of similar names.
> 
> I'm not sure, but even Sparc looks compatible. At least these sbus_
> functions seem to be equivalent to the __raw_() I/O helpers of similar
> names.

> Do you still have that Sparc emulator?
I used qemu the last time I played with sparc and saved the instructions
somewhere how to redo it - but that would use to bohcs driver only I think.
I have saprc machines, but none of these are easy to get operational.
We can always ask on sparclinux to get some testing feedback.

> 
> > 
> >  From a quick look there seems to be some challenges but the current
> > helpers that re-do part of io.h is not the way forward and hiding them
> > in arch/include/asm/fb.h seems counter productive.
> 
> Which challenges did you see?
sparc was the main thing - but maybe I did not look close enough.
And then I tried to map the macros to some of the more highlevel ones
from io.h, but as Arnd says the __raw* is the way to go here.

Sam

Re: [PATCH v2 net-next 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller

[Rob Herring]

On Wed, Apr 26, 2023 at 11:54:28AM -0700, Justin Chen wrote:
> From: Florian Fainelli 
> 
> Add a binding document for the Broadcom ASP 2.0 Ethernet
> controller.
> 
> Signed-off-by: Florian Fainelli 
> Signed-off-by: Justin Chen 
> ---
>  .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 145 
> +
>  1 file changed, 145 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> 
> diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml 
> b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> new file mode 100644
> index ..818d91692e6e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> @@ -0,0 +1,145 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom ASP 2.0 Ethernet controller
> +
> +maintainers:
> +  - Justin Chen 
> +  - Florian Fainelli 
> +
> +description: Broadcom Ethernet controller first introduced with 72165
> +
> +properties:
> +  '#address-cells':
> +const: 1
> +  '#size-cells':
> +const: 1
> +
> +  compatible:
> +enum:
> +  - brcm,asp-v2.0
> +  - brcm,bcm72165-asp-v2.0
> +  - brcm,asp-v2.1
> +  - brcm,bcm74165-asp-v2.1

You have 1 SoC per version, so what's the point of versions? If you have 
more coming, then fine, but I'd expect it to be something like this:

compatible = "brcm,bcm74165-asp-v2.1", "brcm,asp-v2.1";

Also, the version in the SoC specific compatible is redundant. Just 
"brcm,bcm74165-asp" is enough.

v2.1 is not compatible with v2.0? What that means is would a client/OS 
that only understands what v2.0 is work with v2.1 h/w? If so, you should 
have fallback compatible.

> +
> +  reg:
> +maxItems: 1
> +
> +  ranges: true
> +
> +  interrupts:
> +minItems: 1
> +items:
> +  - description: RX/TX interrupt
> +  - description: Port 0 Wake-on-LAN
> +  - description: Port 1 Wake-on-LAN
> +
> +  clocks:
> +maxItems: 1
> +
> +  ethernet-ports:

The ethernet-switch.yaml schema doesn't work for you?

> +type: object
> +properties:
> +  '#address-cells':
> +const: 1
> +  '#size-cells':
> +const: 0
> +
> +patternProperties:
> +  "^port@[0-9]+$":
> +type: object
> +
> +$ref: ethernet-controller.yaml#
> +
> +properties:
> +  reg:
> +maxItems: 1
> +description: Port number
> +
> +  channel:
> +maxItems: 1
> +description: ASP channel number

Not a standard property, so it needs a type and vendor prefix. However, 
what's the difference between channel and port? Can the port numbers 
correspond to the channels?

> +
> +required:
> +  - reg
> +  - channel
> +
> +additionalProperties: false
> +
> +patternProperties:
> +  "^mdio@[0-9a-f]+$":
> +type: object
> +$ref: "brcm,unimac-mdio.yaml"

Drop quotes.

> +
> +description:
> +  ASP internal UniMAC MDIO bus
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - ranges
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +ethernet@9c0 {
> +compatible = "brcm,asp-v2.0";
> +reg = <0x9c0 0x1fff14>;
> +interrupts = ;
> +ranges;
> +clocks = < 14>;
> +#address-cells = <1>;
> +#size-cells = <1>;
> +
> +mdio@c614 {
> +compatible = "brcm,asp-v2.0-mdio";
> +reg = <0xc614 0x8>;

You have 1:1 ranges, is that really what you want? That means 0xc614 is 
an absolute address.

> +reg-names = "mdio";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +phy0: ethernet-phy@1 {
> +reg = <1>;
> +};
> +   };
> +
> +mdio@ce14 {
> +compatible = "brcm,asp-v2.0-mdio";
> +reg = <0xce14 0x8>;
> +reg-names = "mdio";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +phy1: ethernet-phy@1 {
> +reg = <1>;
> +};
> +};
> +
> +ethernet-ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +channel = <8>;
> +phy-mode = "rgmii";
> +phy-handle = <>;
> +};
> +
> +port@1 {
> +reg = <1>;
> +channel = <9>;
> +phy-mode = "rgmii";
> +phy-handle = <>;
> +};
> +};
> +};
> -- 
> 2.7.4
> 

Re: [PATCH v2 net-next 1/6] dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0

[Florian Fainelli]

On 4/27/23 10:03, Rob Herring wrote:

On Wed, Apr 26, 2023 at 11:54:27AM -0700, Justin Chen wrote:

The ASP 2.0 Ethernet controller uses a brcm unimac.

Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
  Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml 
b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
index 0be426ee1e44..6684810fcbf0 100644
--- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
@@ -22,6 +22,8 @@ properties:
- brcm,genet-mdio-v3
- brcm,genet-mdio-v4
- brcm,genet-mdio-v5
+  - brcm,asp-v2.0-mdio
+  - brcm,asp-v2.1-mdio


How many SoCs does each of these correspond to? SoC specific compatibles
are preferred to version numbers (because few vendors are disciplined
at versioning and also not changing versions with every Soc).


So far there is a 1:1 mapping between the number of versions and the 
number of SoCs, and the older SoC uses v2.0, while the newer one uses v2.1.

--
Florian

Re: [PATCH v2 net-next 1/6] dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0

[Rob Herring]

On Wed, Apr 26, 2023 at 11:54:27AM -0700, Justin Chen wrote:
> The ASP 2.0 Ethernet controller uses a brcm unimac.
> 
> Signed-off-by: Florian Fainelli 
> Signed-off-by: Justin Chen 
> ---
>  Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml 
> b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
> index 0be426ee1e44..6684810fcbf0 100644
> --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
> +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
> @@ -22,6 +22,8 @@ properties:
>- brcm,genet-mdio-v3
>- brcm,genet-mdio-v4
>- brcm,genet-mdio-v5
> +  - brcm,asp-v2.0-mdio
> +  - brcm,asp-v2.1-mdio

How many SoCs does each of these correspond to? SoC specific compatibles 
are preferred to version numbers (because few vendors are disciplined 
at versioning and also not changing versions with every Soc). 

>- brcm,unimac-mdio
>  
>reg:
> -- 
> 2.7.4
> 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix error capture for virtual engines

[Teres Alexis, Alan Previn]

On Fri, 2023-04-14 at 17:27 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> GuC based register dumps in error capture logs were basically broken
> for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
>   [IGT] gem_exec_balancer: starting subtest hang
>   [drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
>   [drm] GT0: GUC: No register capture node found for 0x1005 / 0xFEDC311D
>   [drm] GPU HANG: ecode 12:4:, in gem_exec_balanc [6388]
>   [IGT] gem_exec_balancer: exiting, ret=0
> 
> The test causes a hang on both engines of a virtual engine context.
> The engine instance zero hang gets a valid error capture but the
> non-instance-zero hang does not.
> 
> Fix that by scanning through the list of pending register captures
> when a hang notification for a virtual engine is received. That way,
> the hang can be assigned to the correct physical engine prior to
> starting the error capture process. So later on, when the error capture
> handler tries to find the engine register list, it looks for one on
> the correct engine.
> 
> Also, sneak in a missing blank line before a comment in the node
> search code.
> 
> Signed-off-by: John Harrison 

LGTM - thanks for fixing this! :D
Reviewed-by: Alan Previn 

A side conversation - potentially requring an unrelated future patch,...
i notice that the array "error->reset_engine_count[]" (which is being
used for error state reporting and as some verification in selftests) seem
to have a size indicating of engine-instance-count but the reading/wrting
of members of this array keep using the engine->uabi_class as index...
meaning its being used to track engine class reset counts? Maybe this is
an issue or i am misundertanding that. Either way, that issue is unrelated
to the intent of this patch - i just wanted to get that highlighted for
future action if needed. I can take that onus if its in fact an issue.

[PATCH v6] drm/sysfs: Link DRM connectors to corresponding Type-C connectors

[Won Chung]

Create a symlink pointing to USB Type-C connector for DRM connectors
when they are created. The link will be created only if the firmware is
able to describe the connection beween the two connectors.

Currently, even if a display uses a USB Type-C port, there is no way for
the userspace to find which port is used for which display. With the
symlink, display information would be accessible from Type-C connectors
and port information would be accessible from DRM connectors.

Associating the two subsystems, userspace would have potential to expose
and utilize more complex information. ChromeOS intend to use this
information for metrics collection. For example, we want to tell which
port is deriving which displays. Also, combined with USB PD information,
we can tell whether user is charging their device through display.
Chromium patch for parsing the symlink from the kernel is at
http://crrev.com/c/4317207.

We already have a framework in typec port-mapper.c where it goes through
component devices and runs the bind functions for those with matching
_PLD (physical location of device).
https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/port-mapper.c
Since _PLD is ACPI specific field, this linking would only work on ACPI
x86 as long as _PLD field for Type-C connectors and DRM connectors are
correctly added to the firmware.

Currently, USB ports and USB4 ports are added as components to create a
symlink with Type C connector.
USB:
https://lore.kernel.org/all/20211223082349.45616-1-heikki.kroge...@linux.intel.com/
USB4:
https://lore.kernel.org/all/20220418175932.1809770-3-wonch...@google.com/
So, we follow the same pattern in this patch.

Signed-off-by: Won Chung 
Acked-by: Heikki Krogerus 
Reviewed-by: Manasi Navare 
---
Changes from v5:
- Add more details to the error message

Changes from v4: (4 months ago)
- Update commit message with an actual use case from cros userspace
- Move component_add to before ddc check which possibly returns
- Rebased

Changes from v3:
- Append to the commit message on why this patch is needed

Changes from v2:
- Resend the patch to dri-devel list

Changes from v1:
- Fix multiple lines to single line


 drivers/gpu/drm/drm_sysfs.c | 40 +
 1 file changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 183130355997..bc869c6fa420 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -11,12 +11,14 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -96,6 +98,34 @@ static char *drm_devnode(const struct device *dev, umode_t 
*mode)
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
 }
 
+static int typec_connector_bind(struct device *dev,
+   struct device *typec_connector, void *data)
+{
+   int ret;
+
+   ret = sysfs_create_link(>kobj, _connector->kobj, 
"typec_connector");
+   if (ret)
+   return ret;
+
+   ret = sysfs_create_link(_connector->kobj, >kobj, 
"drm_connector");
+   if (ret)
+   sysfs_remove_link(>kobj, "typec_connector");
+
+   return ret;
+}
+
+static void typec_connector_unbind(struct device *dev,
+   struct device *typec_connector, void *data)
+{
+   sysfs_remove_link(_connector->kobj, "drm_connector");
+   sysfs_remove_link(>kobj, "typec_connector");
+}
+
+static const struct component_ops typec_connector_ops = {
+   .bind = typec_connector_bind,
+   .unbind = typec_connector_unbind,
+};
+
 static CLASS_ATTR_STRING(version, S_IRUGO, "drm 1.1.0 20060810");
 
 /**
@@ -353,9 +383,16 @@ int drm_sysfs_connector_add(struct drm_connector 
*connector)
 
connector->kdev = kdev;
 
+   if (dev_fwnode(kdev)) {
+   r = component_add(kdev, _connector_ops);
+   if (r)
+   drm_err(dev, "failed to add component to create link to 
typec connector\n");
+   }
+
if (connector->ddc)
return sysfs_create_link(>kdev->kobj,
 >ddc->dev.kobj, "ddc");
+
return 0;
 
 err_free:
@@ -371,6 +408,9 @@ void drm_sysfs_connector_remove(struct drm_connector 
*connector)
if (connector->ddc)
sysfs_remove_link(>kdev->kobj, "ddc");
 
+   if (dev_fwnode(connector->kdev))
+   component_del(connector->kdev, _connector_ops);
+
DRM_DEBUG("removing \"%s\" from sysfs\n",
  connector->name);
 
-- 
2.40.1.495.gc816e09b53d-goog

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

> On 26/04/2023 16:41, Yang, Fei wrote:
>>> On 26/04/2023 07:24, fei.y...@intel.com wrote:
 From: Fei Yang 

 The first three patches in this series are taken from
 https://patchwork.freedesktop.org/series/116868/
 These patches are included here because the last patch
 has dependency on the pat_index refactor.

 This series is focusing on uAPI changes,
 1. end support for set caching ioctl [PATCH 4/5]
 2. add set_pat extension for gem_create [PATCH 5/5]

 v2: drop one patch that was merged separately
  341ad0e8e254 drm/i915/mtl: Add PTE encode function
>>>
>>> Are the re-sends for stabilizing the series, or focusing on merge?
>>
>> v2 was sent just to drop one of patches that has already been merged.
>>
>>> If the latter then opens are:
>>>
>>> 1) Link to Mesa MR reviewed and ready to merge.
>>>
>>> 2) IGT reviewed.
>>>
>>> 3) I raised an open that get/set_caching should not "lie" but return an
>>> error if set pat extension has been used. I don't see a good reason not
>>> to do that.
>>
>> I don't think it's "lying" to the userspace. the comparison is only valid
>> for objects created by KMD because only such object uses the pat_index
>> from the cachelevel_to_pat table.
>
> Lets double check my understanding is correct. Userspace sequence of
> operations:
> 1)
> obj = gem_create()+set_pat(PAT_UC)
>
> 2a)
> get_caching(obj)
> What gets reported?

I see your point here. nice catch.
That should be handled by,
if (obj->cachel_level == I915_CACHE_INVAL) /* indicated pat-index is set by 
userspace */
  return -EOPNOTSUPP;
Will update the patch.

>
> 2b)
> set_caching(obj, I915_CACHE_LLC)
> What is the return code?

This will either return -EOPNOTSUPP, or ignored because set_pat extension was 
called.

>
> If answer to 2a is I915_CACHING_CACHED and to 2b) success, then please
> state a good reason why both shouldn't return an error.
>
>>
>>> + Joonas on this one.
>>>
>>> 4) Refactoring as done is not very pretty and I proposed an idea for a
>>> nicer approach. Feasible or not, open for discussion.
>>
>> Still digesting your proposal. but not sure how would you define things
>> like PAT_UC as that is platform dependent, not a constant.
>
> "PAT_UC" in my outline was purely a driver specific value, similarly as
> I915_CACHE_... are.

Okay. Then you were suggesting to add a translation table for 
pat_index-to-(PAT-UC/WB/WT)?
It's going to be a N:1 mapping.

> With the whole point that driver can ask if
> something is uncached, WT or whatever. Using the platform specific
> mapping table which converts platform specific obj->pat_index to driver
> representation of caching modes (PAT_UC etc).

Are you suggesting completely remove i915_cache_level and use (PAT-UC/WB/WT) 
instead?
Let's say a KMD object wants to be set as WB, how you get the exact pat_index 
to use?
Note that there are multiple PAT indices having caching mod WB, but they are 
different,
e.g. do you want just WB or WB with 1-way-coherency or WB with 2-way coherency?

Also, in case a checking of pat_index is needed, do we say WB with 
1-way-coherency is
equal to WB or not?

BTW, isn't PAT-UC/WB/WT the same kind of abstraction as enum i915_cache_level, 
I'm not
sure how that would simplify anything.

> Quite possible I missed some detail, but if I haven't then it could be
> a neat and lightweight solution.
>
> Regards,
>
> Tvrtko

Re: [PATCH v2] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2

[Jeff Layton]

On Wed, 2023-04-19 at 16:54 -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul 
> 
> Thanks!
> 
> On Wed, 2023-04-19 at 07:24 -0400, Jeff Layton wrote:
> > I've been experiencing some intermittent crashes down in the display
> > driver code. The symptoms are ususally a line like this in dmesg:
> > 
> > amdgpu :30:00.0: [drm] Failed to create MST payload for port 
> > 6d3a3885: -5
> > 
> > ...followed by an Oops due to a NULL pointer dereference.
> > 
> > Switch to using mgr->dev instead of state->dev since "state" can be
> > NULL in some cases.
> > 
> > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > Suggested-by: Jani Nikula 
> > Signed-off-by: Jeff Layton 
> > ---
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > I've been running this patch for a couple of days, but the problem
> > hasn't occurred again as of yet. It seems sane though as long as we can
> > assume that mgr->dev will be valid even when "state" is a NULL pointer.
> > 
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 38dab76ae69e..e2e21ce79510 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >  
> > /* Skip failed payloads */
> > if (payload->vc_start_slot == -1) {
> > -   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s 
> > failed, skipping part 2\n",
> > +   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s 
> > failed, skipping part 2\n",
> > payload->port->connector->name);
> > return -EIO;
> > }
> 

Thanks! BTW, I've had a couple more of these events in the last few
days:

[20199.446159] amdgpu :30:00.0: [drm] Failed to create MST payload for port 
556eb455: -5
[20199.508379] [drm] DM_MST: stopping TM on aconnector: 1c0c0284 [id: 
86]
[20200.064417] [drm] DM_MST: starting TM on aconnector: 1c0c0284 [id: 
86]

The patch prevents an Oops, but GNOME seems to decide that a different
monitor is primary and moves all of the windows on the desktop around (I
have 2 monitors). Mostly this seems to happen when I walk away from the
machine for a bit, so I suspect it's associated with the display going
to sleep.

At one point, Wayne said he might know the root cause of this. If there
are patches that you need help testing, I can do that. I'm having to
build my own kernels anyway until this patch makes it into the distros.
-- 
Jeff Layton 

Re: [PATCH v4 05/22] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo

[Neil Armstrong]

On 27/04/2023 00:37, Marijn Suijten wrote:

SM8550 exclusively has a DITHER sub-block inside the PINGPONG block and
no other registers, hence the DITHER name of the macro and a
corresponding PINGPONG block length of zero.  However, the PP_BLK_ macro
name was typo'd to DIPHER rather than DITHER.

Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Marijn Suijten 
Reviewed-by: Konrad Dybcio 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16 
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  2 +-
  2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 9e403034093fd..d0ab351b6a8b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -132,28 +132,28 @@ static const struct dpu_dspp_cfg sm8550_dspp[] = {
 _dspp_sblk),
  };
  static const struct dpu_pingpong_cfg sm8550_pp[] = {
-   PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-1),
-   PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-1),
-   PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
-1),
-   PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
-1),
-   PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
-1),
-   PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
-1),
-   PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3, 
sc7280_pp_sblk,
-1,
-1),
-   PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3, 
sc7280_pp_sblk,
-1,
-1),
  };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 03f162af1a50b..ca8a02debda98 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks sc7280_pp_sblk = {
.len = 0x20, .version = 0x2},
  };
  
-#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \

+#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0, \



Sorry for the typo!

Reviewed-by: Neil Armstrong 

Re: [PATCH v2 3/4] drm/msm/dpu: remove GC related code from dpu catalog

[Dmitry Baryshkov]

On 26/04/2023 22:22, Abhinav Kumar wrote:

Since Gamma Correction (GC) block is currently unused, drop
related code from the dpu hardware catalog otherwise this
becomes a burden to carry across chipsets in the catalog.

Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20230421224721.12738-2-quic_abhin...@quicinc.com
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 +---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 6 --
  2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 03f162af1a50..badfc3680485 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -91,7 +91,7 @@
  
  #define MERGE_3D_SM8150_MASK (0)
  
-#define DSPP_MSM8998_MASK BIT(DPU_DSPP_PCC) | BIT(DPU_DSPP_GC)

+#define DSPP_MSM8998_MASK BIT(DPU_DSPP_PCC)
  
  #define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
  
@@ -449,8 +449,6 @@ static const struct dpu_lm_sub_blks qcm2290_lm_sblk = {

  static const struct dpu_dspp_sub_blks msm8998_dspp_sblk = {
.pcc = {.id = DPU_DSPP_PCC, .base = 0x1700,
.len = 0x90, .version = 0x10007},
-   .gc = { .id = DPU_DSPP_GC, .base = 0x17c0,
-   .len = 0x90, .version = 0x10007},
  };
  
  static const struct dpu_dspp_sub_blks sc7180_dspp_sblk = {

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 71584cd56fd7..e0dcef04bc61 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -127,12 +127,10 @@ enum {
  /**
   * DSPP sub-blocks
   * @DPU_DSPP_PCC Panel color correction block
- * @DPU_DSPP_GC  Gamma correction block
   * @DPU_DSPP_IGC Inverse gamma correction block
   */
  enum {
DPU_DSPP_PCC = 0x1,
-   DPU_DSPP_GC,
DPU_DSPP_IGC,


Don't we need to remove this one too (in the previous patch)?


DPU_DSPP_MAX
  };
@@ -433,22 +431,18 @@ struct dpu_sspp_sub_blks {
   * @maxwidth:   Max pixel width supported by this mixer
   * @maxblendstages: Max number of blend-stages supported
   * @blendstage_base:Blend-stage register base offset
- * @gc: gamma correction block
   */
  struct dpu_lm_sub_blks {
u32 maxwidth;
u32 maxblendstages;
u32 blendstage_base[MAX_BLOCKS];
-   struct dpu_pp_blk gc;
  };
  
  /**

   * struct dpu_dspp_sub_blks: Information of DSPP block
- * @gc : gamma correction block
   * @pcc: pixel color correction block
   */
  struct dpu_dspp_sub_blks {
-   struct dpu_pp_blk gc;
struct dpu_pp_blk pcc;
  };
  


--
With best wishes
Dmitry

Re: [PATCH v2 4/4] drm/msm/dpu: drop DSPP_MSM8998_MASK from hw catalog

[Dmitry Baryshkov]

On 26/04/2023 22:22, Abhinav Kumar wrote:

Since GC and IGC masks have now been dropped DSPP_MSM8998_MASK
is same as DSPP_SC7180_MASK. Since DSPP_SC7180_MASK is used more
than DSPP_MSM8998_MASK, lets drop the latter.

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 ++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c  | 2 --
  2 files changed, 2 insertions(+), 4 deletions(-)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v2 2/4] drm/msm/dpu: remove DPU_DSPP_IGC handling in dspp flush

[Dmitry Baryshkov]

On 26/04/2023 22:22, Abhinav Kumar wrote:

Inverse gamma correction blocks (IGC) are not used today so lets
remove the usage of DPU_DSPP_IGC in the dspp flush to make it easier
to remove IGC from the catalog.

We can add this back when IGC is properly supported in DPU with
one of the standard DRM properties.

Signed-off-by: Abhinav Kumar 


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers

[Dmitry Baryshkov]

On 26/04/2023 19:29, Doug Anderson wrote:

Hi,

On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub  wrote:


Hi all,
This is v10 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v10.

Main change in v10 is handling the kernel test bot warnings.

Patches 1-4 focus on moving the common HDCP helpers to common DRM.
This introduces a slight change in the original intel flow
as it splits the unique driver protocol from the generic implementation.

Patches 5-7 split the HDCP flow on the i915 driver to make use of the common 
DRM helpers.

Patches 8-10 implement HDCP on MSM driver.

Thanks,
-Mark Yacoub

Sean Paul (10):
   drm/hdcp: Add drm_hdcp_atomic_check()
   drm/hdcp: Avoid changing crtc state in hdcp atomic check
   drm/hdcp: Update property value on content type and user changes
   drm/hdcp: Expand HDCP helper library for enable/disable/check
   drm/i915/hdcp: Consolidate HDCP setup/state cache
   drm/i915/hdcp: Retain hdcp_capable return codes
   drm/i915/hdcp: Use HDCP helpers for i915
   dt-bindings: msm/dp: Add bindings for HDCP registers
   arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
   drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

  .../bindings/display/msm/dp-controller.yaml   |7 +-
  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |8 +
  drivers/gpu/drm/display/drm_hdcp_helper.c | 1224 +
  drivers/gpu/drm/i915/display/intel_atomic.c   |8 +-
  drivers/gpu/drm/i915/display/intel_ddi.c  |   32 +-
  .../drm/i915/display/intel_display_debugfs.c  |   12 +-
  .../drm/i915/display/intel_display_types.h|   51 +-
  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  352 ++---
  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   16 +-
  drivers/gpu/drm/i915/display/intel_hdcp.c | 1060 +++---
  drivers/gpu/drm/i915/display/intel_hdcp.h |   48 +-
  drivers/gpu/drm/i915/display/intel_hdmi.c |  267 ++--
  drivers/gpu/drm/msm/Kconfig   |1 +
  drivers/gpu/drm/msm/Makefile  |1 +
  drivers/gpu/drm/msm/dp/dp_catalog.c   |  156 +++
  drivers/gpu/drm/msm/dp/dp_catalog.h   |   18 +
  drivers/gpu/drm/msm/dp/dp_debug.c |   46 +-
  drivers/gpu/drm/msm/dp/dp_debug.h |   11 +-
  drivers/gpu/drm/msm/dp/dp_display.c   |   39 +-
  drivers/gpu/drm/msm/dp/dp_display.h   |5 +
  drivers/gpu/drm/msm/dp/dp_drm.c   |   39 +-
  drivers/gpu/drm/msm/dp/dp_drm.h   |7 +
  drivers/gpu/drm/msm/dp/dp_hdcp.c  |  389 ++
  drivers/gpu/drm/msm/dp/dp_hdcp.h  |   33 +
  drivers/gpu/drm/msm/dp/dp_parser.c|   14 +
  drivers/gpu/drm/msm/dp/dp_parser.h|4 +
  drivers/gpu/drm/msm/dp/dp_reg.h   |   30 +-
  drivers/gpu/drm/msm/msm_atomic.c  |   19 +
  include/drm/display/drm_hdcp.h|  296 
  include/drm/display/drm_hdcp_helper.h |   23 +
  30 files changed, 2867 insertions(+), 1349 deletions(-)


Mark asked me if I had any advice for getting this patch series
landed. I haven't been following the patch series super closely, but
as I understand it:

1. The first several patches (the generic ones) seem fairly well
reviewed and haven't changed in any significant ways in a while. The
ideal place to land these would be drm-misc, I think.

2. The i915 patches also seem OK to land. The ideal place would be the
Intel DRM tree, I think.

3. The msm patches are not fully baked yet. Not only is there a kernel
bot complaint on patch #10, but Mark also said that comments from v6
haven't yet fully been addressed and he's talked with Dmitry on IRC
about this and has a plan to move forward.


The question becomes: can/should we land the generic and maybe the
i915 patches now while the msm patches are reworked. Do folks have an
opinion here? If we're OK landing some of the patches, I guess we have
a few options:

a) Just land the generic patches to drm-misc and put the i915 ones on
the backburner until drm-misc has made it to somewhere that the
drm-intel tree is based on. If we want to go this route and nobody
objects, I don't mind being the person who does the gruntwork of
actually landing them on drm-misc-next, though I certainly wouldn't
rush to make sure that nobody is unhappy with this idea.

b) Land the generic patches in some type of immutable branch so they
can be pulled into drm-misc and the Intel DRM tree. Someone more
senior to me would need to help with this, but if we really want to go
this way I can poke folks on IRC.

c) Land the generic and Intel patches in the Intel tree. The msm
patches would not be able to land until these trickled up the chain,
but the msm patches aren't fully ready yet anyway so maybe this is OK.

d) Land the generic and Intel patches in the drm-misc tree. If folks
are OK with this I can be the person to pull the trigger, but I'd want
to be very sure that Intel DRM 

Re: [PATCH] dt-bindings: display: simplify compatibles syntax

[Krzysztof Kozlowski]

On 27/04/2023 13:50, Neil Armstrong wrote:
> On 14/04/2023 12:42, Krzysztof Kozlowski wrote:
>> Lists (items) with one item should be just const or enum because it is
>> shorter and simpler.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>>
>> ---
>>
>> Rebased on next-20230406. I hope it applies cleanly...
>> ---
>>   .../display/bridge/analogix,anx7625.yaml  |  3 +--
>>   .../display/panel/sharp,lq101r1sx01.yaml  |  4 ++--
>>   .../bindings/display/solomon,ssd1307fb.yaml   | 24 +--
>>   3 files changed, 14 insertions(+), 17 deletions(-)
>>
> 
> Reviewed-by: Neil Armstrong 
> 
> Should I apply those patches ? Until now Rob finished by applying them.

Thanks. This and the mediatek display one were applied already by Rob.


Best regards,
Krzysztof

Re: [PATCH v2 07/13] drm/msm/dpu: Add SM6350 support

[Marijn Suijten]

On 2023-04-27 17:37:42, Marijn Suijten wrote:
> On 2023-04-21 00:31:16, Konrad Dybcio wrote:
> > Add SM6350 support to the DPU1 driver to enable display output.
> > 
> > Signed-off-by: Konrad Dybcio 
> > Signed-off-by: Konrad Dybcio 
> 
> After addressing the comments from Dmitry (CURSOR0->DMA1 and
> CURSOR1->DMA2), this is:
> 
> Reviewed-by: Marijn Suijten 
> 
> See below for some nits.

Actually found one glaring issue that might explain why INTF TE wasn't
working for you the other day!

> > ---
> >  .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 191 
> > +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   1 +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   3 +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   1 +
> >  4 files changed, 196 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h 
> > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> > new file mode 100644
> > index ..687a508cbaa6
> > --- /dev/null
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> > @@ -0,0 +1,191 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights 
> > reserved.
> > + * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
> > + * Copyright (c) 2023, Linaro Limited
> > + */
> > +
> > +#ifndef _DPU_6_4_SM6350_H
> > +#define _DPU_6_4_SM6350_H
> > +
> > +static const struct dpu_caps sm6350_dpu_caps = {
> > +   .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> > +   .max_mixer_blendstages = 0x7,
> > +   .qseed_type = DPU_SSPP_SCALER_QSEED4,
> 
> I thought it was QSEED3LITE, but doesn't really matter as both are
> handled similarly.  It'll anyway change when I resubmit:
> 
> https://lore.kernel.org/linux-arm-msm/20230215-sspp-scaler-version-v1-0-416b1500b...@somainline.org/T/#u
> 
> which should hardcode the register value directly, making this field
> superfluous.
> 
> > +   .has_src_split = true,
> > +   .has_dim_layer = true,
> > +   .has_idle_pc = true,
> > +   .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> > +   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > +};
> > +
> > +static const struct dpu_ubwc_cfg sm6350_ubwc_cfg = {
> > +   .ubwc_version = DPU_HW_UBWC_VER_20,
> > +   .ubwc_swizzle = 6,
> > +   .highest_bank_bit = 1,
> > +};
> > +
> > +static const struct dpu_mdp_cfg sm6350_mdp[] = {
> > +   {
> > +   .name = "top_0", .id = MDP_TOP,
> > +   .base = 0x0, .len = 0x494,
> > +   .features = 0,
> > +   .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> > +   .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> > +   .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> > +   .clk_ctrls[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> > +   .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
> > +   },
> > +};
> > +
> > +static const struct dpu_ctl_cfg sm6350_ctl[] = {
> > +   {
> > +   .name = "ctl_0", .id = CTL_0,
> > +   .base = 0x1000, .len = 0x1dc,
> > +   .features = BIT(DPU_CTL_ACTIVE_CFG),
> > +   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> > +   },
> > +   {
> > +   .name = "ctl_1", .id = CTL_1,
> > +   .base = 0x1200, .len = 0x1dc,
> > +   .features = BIT(DPU_CTL_ACTIVE_CFG),
> > +   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> > +   },
> > +   {
> > +   .name = "ctl_2", .id = CTL_2,
> > +   .base = 0x1400, .len = 0x1dc,
> > +   .features = BIT(DPU_CTL_ACTIVE_CFG),
> > +   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> > +   },
> > +   {
> > +   .name = "ctl_3", .id = CTL_3,
> > +   .base = 0x1600, .len = 0x1dc,
> > +   .features = BIT(DPU_CTL_ACTIVE_CFG),
> > +   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> > +   },
> > +};
> > +
> > +static const struct dpu_sspp_cfg sm6350_sspp[] = {
> > +   SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
> > +sc7180_vig_sblk_0, 0,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> > +   SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
> > +sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
> > +   SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
> > +sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
> > +   SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
> > +sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
> > +};
> > +
> > +static const struct dpu_lm_cfg sm6350_lm[] = {
> > +   LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
> > +   _lm_sblk, PINGPONG_0, LM_1, DSPP_0),
> > +   LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
> > +   _lm_sblk, PINGPONG_1, LM_0, 0),
> 
> These two entries are indented with two tabs and have one character too
> many to align with the opening parenthesis on the previous line.  Can we
> please settle on a single style, as this commit mostly uses 

Re: [PATCH v2 09/13] drm/msm/dpu: Add SM6375 support

[Marijn Suijten]

On 2023-04-21 00:31:18, Konrad Dybcio wrote:
> Add basic SM6375 support to the DPU1 driver to enable display output.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h |   5 -
>  .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 152 
> +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  14 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   1 +
>  5 files changed, 168 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> index 687a508cbaa6..d46b43964be6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> @@ -126,11 +126,6 @@ static const struct dpu_vbif_cfg sm6350_vbif[] = {
>   },
>  };
>  
> -static const struct dpu_qos_lut_entry sm6350_qos_linear_macrotile[] = {
> - {.fl = 0, .lut = 0x0011223344556677 },
> - {.fl = 0, .lut = 0x0011223445566777 },
> -};
> -
>  static const struct dpu_perf_cfg sm6350_perf_data = {
>   .max_bw_low = 420,
>   .max_bw_high = 510,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> new file mode 100644
> index ..19ca0051e072
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> @@ -0,0 +1,152 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Linaro Limited
> + */
> +
> +#ifndef _DPU_6_9_SM6375_H
> +#define _DPU_6_9_SM6375_H
> +
> +static const struct dpu_caps sm6375_dpu_caps = {
> + .max_mixer_width = 2048,
> + .max_mixer_blendstages = 0x4,
> + .qseed_type = DPU_SSPP_SCALER_QSEED4,
> + .has_dim_layer = true,
> + .has_idle_pc = true,
> + .max_linewidth = 2160,
> + .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> +};
> +
> +static const struct dpu_ubwc_cfg sm6375_ubwc_cfg = {
> + .ubwc_version = DPU_HW_UBWC_VER_20,
> + .ubwc_swizzle = 6,
> + .highest_bank_bit = 1,
> +};
> +
> +static const struct dpu_mdp_cfg sm6375_mdp[] = {
> + {
> + .name = "top_0", .id = MDP_TOP,
> + .base = 0x0, .len = 0x494,
> + .features = 0,
> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> + },
> +};
> +
> +static const struct dpu_ctl_cfg sm6375_ctl[] = {
> + {
> + .name = "ctl_0", .id = CTL_0,
> + .base = 0x1000, .len = 0x1dc,
> + .features = BIT(DPU_CTL_ACTIVE_CFG),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> + },
> +};
> +
> +static const struct dpu_sspp_cfg sm6375_sspp[] = {
> + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
> +  sm6115_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
> +  sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
> +};
> +
> +static const struct dpu_lm_cfg sm6375_lm[] = {
> + LM_BLK("lm_0", LM_0, 0x44000, MIXER_QCM2290_MASK,
> + _lm_sblk, PINGPONG_0, 0, DSPP_0),

Same indentation nit here as in SM6350.

> +};
> +
> +static const struct dpu_dspp_cfg sm6375_dspp[] = {
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
> +  _dspp_sblk),
> +};
> +
> +static const struct dpu_pingpong_cfg sm6375_pp[] = {
> + PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_MASK, 0, 
> sdm845_pp_sblk,
> +DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> +-1),
> +};
> +
> +static const struct dpu_intf_cfg sm6375_intf[] = {
> + INTF_BLK("intf_0", INTF_0, 0x0, 0x2c0, INTF_NONE, 0, 0, 0, 0, 0),
> + INTF_BLK_DSI_TE("intf_1", INTF_1, 0x6a800, 0x2c0, INTF_DSI, 0, 24, 
> INTF_SC7280_MASK,
> + DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> + DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
> + DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2)),
> +};
> +
> +static const struct dpu_vbif_cfg sm6375_vbif[] = {
> + {
> + .name = "vbif_0", .id = VBIF_RT,
> + .base = 0, .len = 0x2008,
> + .features = BIT(DPU_VBIF_QOS_REMAP),
> + .xin_halt_timeout = 0x4000,
> + .qos_rp_remap_size = 0x40,
> + .qos_rt_tbl = {
> + .npriority_lvl = ARRAY_SIZE(sdm845_rt_pri_lvl),
> + .priority_lvl = sdm845_rt_pri_lvl,
> + },
> + .qos_nrt_tbl = {
> + .npriority_lvl = ARRAY_SIZE(sdm845_nrt_pri_lvl),
> + .priority_lvl = sdm845_nrt_pri_lvl,
> + },
> + .memtype_count = 14,
> + .memtype = {3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3},
> + },
> +};
> +
> 

Re: [git pull] drm next fixes for 6.4-rc1

[pr-tracker-bot]

The pull request you sent on Thu, 27 Apr 2023 11:43:17 +1000:

> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/32f7ad0fbe7521de2a5e8f79c33d46110247fd7c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH v2 1/3] drm: Create support for Write-Only property blob

[Sean Paul]

On Thu, Apr 27, 2023 at 5:59 AM Daniel Vetter  wrote:
>
> On Fri, Apr 21, 2023 at 12:27:47PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub 
> >
> > [Why]
> > User space might need to inject data into the kernel without allowing it
> > to be read again by any user space.
> > An example of where this is particularly useful is secret keys fetched
> > by user space and injected into the kernel to enable content protection.
> >
> > [How]
> > Create a DRM_MODE_CREATE_BLOB_WRITE_ONLY flag used by user space to
> > create a blob and mark the blob as write only.
> > On reading back the blob, data will be not be copied if it's a write
> > only blob
>
> This makes no sense at all, why would you want to disallow reading?
> Userspace already knows the key, there's not much point in hiding it from
> userspace?

There are varying levels of trust amongst userspace applications. For
example, in CrOS we trust portions of Chrome to handle the key
securely, but would like to avoid access from other portions, or users
from exposing the key via modetest output. We could play whack-a-mole
and try to patch up all untrusted userspace, but that doesn't seem
like a scalable solution.

Sean

>
> Also for new uapi we need the igt patches and userspace, please link
> those.
> -Daniel
>
> >
> > Signed-off-by: Mark Yacoub 
> > ---
> >  drivers/gpu/drm/drm_property.c | 3 ++-
> >  include/drm/drm_property.h | 2 ++
> >  include/uapi/drm/drm_mode.h| 6 ++
> >  3 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> > index dfec479830e49..afedf7109d002 100644
> > --- a/drivers/gpu/drm/drm_property.c
> > +++ b/drivers/gpu/drm/drm_property.c
> > @@ -765,7 +765,7 @@ int drm_mode_getblob_ioctl(struct drm_device *dev,
> >   if (!blob)
> >   return -ENOENT;
> >
> > - if (out_resp->length == blob->length) {
> > + if (out_resp->length == blob->length && !blob->is_write_only) {
> >   if (copy_to_user(u64_to_user_ptr(out_resp->data),
> >blob->data,
> >blob->length)) {
> > @@ -800,6 +800,7 @@ int drm_mode_createblob_ioctl(struct drm_device *dev,
> >   ret = -EFAULT;
> >   goto out_blob;
> >   }
> > + blob->is_write_only = out_resp->flags & 
> > DRM_MODE_CREATE_BLOB_WRITE_ONLY;
> >
> >   /* Dropping the lock between create_blob and our access here is safe
> >* as only the same file_priv can remove the blob; at this point, it 
> > is
> > diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> > index 65bc9710a4702..700782f021b99 100644
> > --- a/include/drm/drm_property.h
> > +++ b/include/drm/drm_property.h
> > @@ -205,6 +205,7 @@ struct drm_property {
> >   *   _mode_config.property_blob_list.
> >   * @head_file: entry on the per-file blob list in _file.blobs list.
> >   * @length: size of the blob in bytes, invariant over the lifetime of the 
> > object
> > + * @is_write_only: user space can't read the blob data.
> >   * @data: actual data, embedded at the end of this structure
> >   *
> >   * Blobs are used to store bigger values than what fits directly into the 
> > 64
> > @@ -219,6 +220,7 @@ struct drm_property_blob {
> >   struct list_head head_global;
> >   struct list_head head_file;
> >   size_t length;
> > + bool is_write_only;
> >   void *data;
> >  };
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 46becedf5b2fc..10403c9a73082 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1168,6 +1168,9 @@ struct drm_format_modifier {
> >   __u64 modifier;
> >  };
> >
> > +#define DRM_MODE_CREATE_BLOB_WRITE_ONLY
> > \
> > + (1 << 0) /* data of the blob can't be read by user space */
> > +
> >  /**
> >   * struct drm_mode_create_blob - Create New blob property
> >   *
> > @@ -1181,6 +1184,9 @@ struct drm_mode_create_blob {
> >   __u32 length;
> >   /** @blob_id: Return: new property ID. */
> >   __u32 blob_id;
> > + /** Flags for special handling. */
> > + __u32 flags;
> > + __u32 pad;
> >  };
> >
> >  /**
> > --
> > 2.40.0.634.g4ca3ef3211-goog
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH v2 07/13] drm/msm/dpu: Add SM6350 support

[Marijn Suijten]

On 2023-04-21 00:31:16, Konrad Dybcio wrote:
> Add SM6350 support to the DPU1 driver to enable display output.
> 
> Signed-off-by: Konrad Dybcio 
> Signed-off-by: Konrad Dybcio 

After addressing the comments from Dmitry (CURSOR0->DMA1 and
CURSOR1->DMA2), this is:

Reviewed-by: Marijn Suijten 

See below for some nits.

> ---
>  .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 191 
> +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   3 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   1 +
>  4 files changed, 196 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> new file mode 100644
> index ..687a508cbaa6
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
> @@ -0,0 +1,191 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Linaro Limited
> + */
> +
> +#ifndef _DPU_6_4_SM6350_H
> +#define _DPU_6_4_SM6350_H
> +
> +static const struct dpu_caps sm6350_dpu_caps = {
> + .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> + .max_mixer_blendstages = 0x7,
> + .qseed_type = DPU_SSPP_SCALER_QSEED4,

I thought it was QSEED3LITE, but doesn't really matter as both are
handled similarly.  It'll anyway change when I resubmit:

https://lore.kernel.org/linux-arm-msm/20230215-sspp-scaler-version-v1-0-416b1500b...@somainline.org/T/#u

which should hardcode the register value directly, making this field
superfluous.

> + .has_src_split = true,
> + .has_dim_layer = true,
> + .has_idle_pc = true,
> + .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> + .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> +};
> +
> +static const struct dpu_ubwc_cfg sm6350_ubwc_cfg = {
> + .ubwc_version = DPU_HW_UBWC_VER_20,
> + .ubwc_swizzle = 6,
> + .highest_bank_bit = 1,
> +};
> +
> +static const struct dpu_mdp_cfg sm6350_mdp[] = {
> + {
> + .name = "top_0", .id = MDP_TOP,
> + .base = 0x0, .len = 0x494,
> + .features = 0,
> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> + .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
> + },
> +};
> +
> +static const struct dpu_ctl_cfg sm6350_ctl[] = {
> + {
> + .name = "ctl_0", .id = CTL_0,
> + .base = 0x1000, .len = 0x1dc,
> + .features = BIT(DPU_CTL_ACTIVE_CFG),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> + },
> + {
> + .name = "ctl_1", .id = CTL_1,
> + .base = 0x1200, .len = 0x1dc,
> + .features = BIT(DPU_CTL_ACTIVE_CFG),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> + },
> + {
> + .name = "ctl_2", .id = CTL_2,
> + .base = 0x1400, .len = 0x1dc,
> + .features = BIT(DPU_CTL_ACTIVE_CFG),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> + },
> + {
> + .name = "ctl_3", .id = CTL_3,
> + .base = 0x1600, .len = 0x1dc,
> + .features = BIT(DPU_CTL_ACTIVE_CFG),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> + },
> +};
> +
> +static const struct dpu_sspp_cfg sm6350_sspp[] = {
> + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
> +  sc7180_vig_sblk_0, 0,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
> +  sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
> + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
> +  sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
> + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
> +  sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
> +};
> +
> +static const struct dpu_lm_cfg sm6350_lm[] = {
> + LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
> + _lm_sblk, PINGPONG_0, LM_1, DSPP_0),
> + LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
> + _lm_sblk, PINGPONG_1, LM_0, 0),

These two entries are indented with two tabs and have one character too
many to align with the opening parenthesis on the previous line.  Can we
please settle on a single style, as this commit mostly uses tabs+spaces
to align with the opening parenthesis?

Dmitry vouched for `cino=(0` (when in unclosed parenthesis, align next
line with zero extra characters to the opening parenthesis), but I find
double tabs more convenient as it doesn't require reindenting when
changing the name of the 

Re: [PATCH RESEND v3 0/9] Add gamma lut support for mt8195

[AngeloGioacchino Del Regno]

Il 26/04/23 13:43, AngeloGioacchino Del Regno ha scritto:

Il 12/09/22 03:29, Jason-JH.Lin ha scritto:

Since the gamma_set_common() function for previous SoC,
such as  mt8173 and mt8183, is designed for 9bit-to-10bit
conversion.
mt8195 is using 10bit-to-12bit conversion, which is
not compatible with the previous function.

Thus, need to update the function to fit the need of mt8195.


Hello,
can you please respin and fix this series on the latest linux-next?

Besides, please test it carefully: as far as I can see, GNOME Night Light
(or others) are not working on MT8195 (color temperature/ccorr).
As for gamma itself, that's not working either; you can test it with a tool
that will create a color profile by applying a new VCGT table, please look
at [1] if you need tools.

We can confirm that color correction works on at least MT8192 (colord), so
it's MT8195 at fault.

[1]: https://github.com/zb3/gnome-gamma-tool



Nevermind. I've actually fixed this code and refactored it a bit as well.

I'll push my own version soon. No action required.

Regards,
Angelo

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Tue, Apr 25, 2023 at 4:16 PM Markus Elfring  wrote:
>
> > This patch seems to be a part of a series without being marked as such,
>
> The mentioned patch affects only a single function implementation.
>
>
> > this causes issues when importing this patch with maintainer tools
> > like b4 which automatically pull in the entire series and not
> > just the specific patch.
>
> It is a pity that there are special technical difficulties.
>
>
> > Either label the patch as being part of a series ( [PATCH 1/XX] ),
>
> Further software modules were similarly affected.
>
> See also:
> Reconsidering pointer dereferences before null pointer checks (with SmPL)
> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a...@web.de/
> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
>
>
> > or submit it separately.
>
> I thought that I did that (in principle).

You can have a look at LKML for the email message-id to see the whole
thread of patches.
https://lore.kernel.org/all/14636275-4d26-d639-5f6e-293fc6d1c...@web.de/#r

Or https://lore.kernel.org/all/$MSG_ID

Fix the email Sign-off email != Sender email issue, resubmit and I'll
be able to apply this.

Re: [PATCH] drm/scheduler: mark jobs without fence as canceled

[Luben Tuikov]

Hi Christian,

Patch is,
Reviewed-by: Luben Tuikov 

Regards,
Luben

On 2023-04-27 08:27, Christian König wrote:
> When no hw fence is provided for a job that means that the job didn't 
> executed.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 7849e2d7780e..b09cdacfd062 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -542,7 +542,7 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, 
> bool full_recovery)
>   DRM_DEV_ERROR(sched->dev, "fence add callback 
> failed (%d)\n",
> r);
>   } else
> - drm_sched_job_done(s_job, 0);
> + drm_sched_job_done(s_job, -ECANCELED);
>   }
>  
>   if (full_recovery) {

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

[Tvrtko Ursulin]

On 26/04/2023 16:41, Yang, Fei wrote:

 > On 26/04/2023 07:24, fei.y...@intel.com wrote:
 >> From: Fei Yang 
 >>
 >> The first three patches in this series are taken from
 >> https://patchwork.freedesktop.org/series/116868/
 >> These patches are included here because the last patch
 >> has dependency on the pat_index refactor.
 >>
 >> This series is focusing on uAPI changes,
 >> 1. end support for set caching ioctl [PATCH 4/5]
 >> 2. add set_pat extension for gem_create [PATCH 5/5]
 >>
 >> v2: drop one patch that was merged separately
 >>      341ad0e8e254 drm/i915/mtl: Add PTE encode function
 >
 > Are the re-sends for stabilizing the series, or focusing on merge?

v2 was sent just to drop one of patches that has already been merged.

 > If the latter then opens are:
 >
 > 1) Link to Mesa MR reviewed and ready to merge.
 >
 > 2) IGT reviewed.
 >
 > 3) I raised an open that get/set_caching should not "lie" but return an
 > error if set pat extension has been used. I don't see a good reason not
 > to do that.

I don't think it's "lying" to the userspace. the comparison is only valid
for objects created by KMD because only such object uses the pat_index
from the cachelevel_to_pat table.


Lets double check my understanding is correct. Userspace sequence of 
operations:


1)
obj = gem_create()+set_pat(PAT_UC)

2a)
get_caching(obj)

What gets reported?

2b)
set_caching(obj, I915_CACHE_LLC)

What is the return code?

If answer to 2a is I915_CACHING_CACHED and to 2b) success, then please 
state a good reason why both shouldn't return an error.




 > + Joonas on this one.
 >
 > 4) Refactoring as done is not very pretty and I proposed an idea for a
 > nicer approach. Feasible or not, open for discussion.

Still digesting your proposal. but not sure how would you define things
like PAT_UC as that is platform dependent, not a constant.


"PAT_UC" in my outline was purely a driver specific value, similarly as 
I915_CACHE_... are. With the whole point that driver can ask if 
something is uncached, WT or whatever. Using the platform specific 
mapping table which converts platform specific obj->pat_index to driver 
representation of caching modes (PAT_UC etc).


Quite possible I missed some detail, but if I haven't then it could be 
a neat and lightweight solution.


Regards,

Tvrtko

Re: [RFC 2/3] drm/msm: Rework get_comm_cmdline() helper

[Rob Clark]

On Thu, Apr 27, 2023 at 2:39 AM Daniel Vetter  wrote:
>
> On Fri, Apr 21, 2023 at 07:47:26AM -0700, Rob Clark wrote:
> > On Fri, Apr 21, 2023 at 2:33 AM Emil Velikov  
> > wrote:
> > >
> > > Greeting all,
> > >
> > > Sorry for the delay - Easter Holidays, food coma and all that :-)
> > >
> > > On Tue, 18 Apr 2023 at 15:31, Rob Clark  wrote:
> > > >
> > > > On Tue, Apr 18, 2023 at 1:34 AM Daniel Vetter  wrote:
> > > > >
> > > > > On Tue, Apr 18, 2023 at 09:27:49AM +0100, Tvrtko Ursulin wrote:
> > > > > >
> > > > > > On 17/04/2023 21:12, Rob Clark wrote:
> > > > > > > From: Rob Clark 
> > > > > > >
> > > > > > > Make it work in terms of ctx so that it can be re-used for fdinfo.
> > > > > > >
> > > > > > > Signed-off-by: Rob Clark 
> > > > > > > ---
> > > > > > >   drivers/gpu/drm/msm/adreno/adreno_gpu.c |  4 ++--
> > > > > > >   drivers/gpu/drm/msm/msm_drv.c   |  2 ++
> > > > > > >   drivers/gpu/drm/msm/msm_gpu.c   | 13 ++---
> > > > > > >   drivers/gpu/drm/msm/msm_gpu.h   | 12 ++--
> > > > > > >   drivers/gpu/drm/msm/msm_submitqueue.c   |  1 +
> > > > > > >   5 files changed, 21 insertions(+), 11 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> > > > > > > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > > index bb38e728864d..43c4e1fea83f 100644
> > > > > > > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > > @@ -412,7 +412,7 @@ int adreno_set_param(struct msm_gpu *gpu, 
> > > > > > > struct msm_file_private *ctx,
> > > > > > > /* Ensure string is null terminated: */
> > > > > > > str[len] = '\0';
> > > > > > > -   mutex_lock(>lock);
> > > > > > > +   mutex_lock(>lock);
> > > > > > > if (param == MSM_PARAM_COMM) {
> > > > > > > paramp = >comm;
> > > > > > > @@ -423,7 +423,7 @@ int adreno_set_param(struct msm_gpu *gpu, 
> > > > > > > struct msm_file_private *ctx,
> > > > > > > kfree(*paramp);
> > > > > > > *paramp = str;
> > > > > > > -   mutex_unlock(>lock);
> > > > > > > +   mutex_unlock(>lock);
> > > > > > > return 0;
> > > > > > > }
> > > > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c 
> > > > > > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > > > > index 3d73b98d6a9c..ca0e89e46e13 100644
> > > > > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > > > > @@ -581,6 +581,8 @@ static int context_init(struct drm_device 
> > > > > > > *dev, struct drm_file *file)
> > > > > > > rwlock_init(>queuelock);
> > > > > > > kref_init(>ref);
> > > > > > > +   ctx->pid = get_pid(task_pid(current));
> > > > > >
> > > > > > Would it simplify things for msm if DRM core had an up to date 
> > > > > > file->pid as
> > > > > > proposed in
> > > > > > https://patchwork.freedesktop.org/patch/526752/?series=109902=4 
> > > > > > ? It
> > > > > > gets updated if ioctl issuer is different than fd opener and this 
> > > > > > being
> > > > > > context_init here reminded me of it. Maybe you wouldn't have to 
> > > > > > track the
> > > > > > pid in msm?
> > > >
> > > > The problem is that we also need this for gpu devcore dumps, which
> > > > could happen after the drm_file is closed.  The ctx can outlive the
> > > > file.
> > > >
> > > I think we all kept forgetting about that. MSM had support for ages,
> > > while AMDGPU is the second driver to land support - just a release
> > > ago.
> > >
> > > > But the ctx->pid has the same problem as the existing file->pid when
> > > > it comes to Xorg.. hopefully over time that problem just goes away.
> > >
> > > Out of curiosity: what do you mean with "when it comes to Xorg" - the
> > > "was_master" handling or something else?
> >
> > The problem is that Xorg is the one to open the drm fd, and then
> > passes the fd to the client.. so the pid of drm_file is the Xorg pid,
> > not the client.  Making it not terribly informative.
> >
> > Tvrtko's patch he linked above would address that for drm_file, but
> > not for other driver internal usages.  Maybe it could be wired up as a
> > helper so that drivers don't have to re-invent that dance.  Idk, I
> > have to think about it.
> >
> > Btw, with my WIP drm sched fence signalling patch lockdep is unhappy
> > when gpu devcore dumps are triggered.  I'm still pondering how to
> > decouple the locking so that anything coming from fs (ie.
> > show_fdinfo()) is decoupled from anything that happens in the fence
> > signaling path.  But will repost this series once I get that sorted
> > out.
>
> So the cleanest imo is that you push most of the capturing into a worker
> that's entirely decoupled. If you have terminal context (i.e. on first
> hang they stop all further cmd submission, which is anyway what
> vk/arb_robustness want), then you don't have to capture at tdr time,
> because there's no subsequent batch that 

[PATCH v1 8/9] drm/bridge: tc358768: fix THS_TRAILCNT computation

[Francesco Dolcini]

From: Francesco Dolcini 

Correct computation of THS_TRAILCNT register.

This register must be set to a value that ensure that
THS_TRAIL > 60 ns + 4 x UI
 and
THS_TRAIL > 8 x UI
 and
THS_TRAIL < TEOT
 with
TEOT = 105 ns + (12 x UI)

with the actual value of THS_TRAIL being

(1 + THS_TRAILCNT) x ByteClk cycle + ((1 to 2) + 2) xHSBYTECLK cycle +
 - (PHY output delay)

with PHY output delay being about

(8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion.

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 854fc04f08d0..947c7dca567a 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -779,9 +779,10 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
dev_dbg(priv->dev, "TCLK_POSTCNT: 0x%x\n", val);
tc358768_write(priv, TC358768_TCLK_POSTCNT, val);
 
-   /* 60ns + 4*UI < THS_PREPARE < 105ns + 12*UI */
-   val = tc358768_ns_to_cnt(60 + tc358768_to_ns(15 * ui_nsk),
-dsibclk_nsk) - 5;
+   /* max(60ns + 4*UI, 8*UI) < THS_TRAILCNT < 105ns + 12*UI */
+   raw_val = tc358768_ns_to_cnt(60 + tc358768_to_ns(18 * ui_nsk),
+dsibclk_nsk) - 4;
+   val = clamp(raw_val, 0, 15);
dev_dbg(priv->dev, "THS_TRAILCNT: 0x%x\n", val);
tc358768_write(priv, TC358768_THS_TRAILCNT, val);
 
-- 
2.25.1

[PATCH v1 5/9] drm/bridge: tc358768: fix TCLK_TRAILCNT computation

[Francesco Dolcini]

From: Francesco Dolcini 

Correct computation of TCLK_TRAILCNT register.

The driver does not implement non-continuous clock mode, so the actual
value doesn't make a practical difference yet. However this change also
ensures that the value does not write to reserved registers bits in case
of under/overflow.

This register must be set to a value that ensures that

TCLK-TRAIL > 60ns
 and
TEOT <= (105 ns + 12 x UI)

with the actual value of TCLK-TRAIL being

(TCLK_TRAILCNT + (1 to 2)) xHSByteClkCycle +
 (2 + (1 to 2)) * HSBYTECLKCycle - (PHY output delay)

with PHY output delay being about

(2 to 3) x MIPIBitClk cycle in the BitClk conversion.

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index aff400c36066..360c7c65f8c4 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -638,6 +639,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
struct mipi_dsi_device *dsi_dev = priv->output.dev;
unsigned long mode_flags = dsi_dev->mode_flags;
u32 val, val2, lptxcnt, hact, data_type;
+   s32 raw_val;
const struct drm_display_mode *mode;
u32 dsibclk_nsk, dsiclk_nsk, ui_nsk, phy_delay_nsk;
u32 dsiclk, dsibclk, video_start;
@@ -749,9 +751,9 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
dev_dbg(priv->dev, "TCLK_HEADERCNT: 0x%x\n", val);
tc358768_write(priv, TC358768_TCLK_HEADERCNT, val);
 
-   /* TCLK_TRAIL > 60ns + 3*UI */
-   val = 60 + tc358768_to_ns(3 * ui_nsk);
-   val = tc358768_ns_to_cnt(val, dsibclk_nsk) - 5;
+   /* TCLK_TRAIL > 60ns AND TEOT <= 105 ns + 12*UI */
+   raw_val = tc358768_ns_to_cnt(60 + tc358768_to_ns(2 * ui_nsk), 
dsibclk_nsk) - 5;
+   val = clamp(raw_val, 0, 127);
dev_dbg(priv->dev, "TCLK_TRAILCNT: 0x%x\n", val);
tc358768_write(priv, TC358768_TCLK_TRAILCNT, val);
 
-- 
2.25.1

[PATCH v1 7/9] drm/bridge: tc358768: fix TXTAGOCNT computation

[Francesco Dolcini]

From: Francesco Dolcini 

Correct computation of TXTAGOCNT register.

This register must be set to a value that ensure that the
TTA-GO period = (4 x TLPX)

with the actual value of TTA-GO being

4 x (TXTAGOCNT + 1) x (HSByteClk cycle)

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 36e33cba59a2..854fc04f08d0 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -795,7 +795,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
 
/* TXTAGOCNT[26:16] RXTASURECNT[10:0] */
val = tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk * 4);
-   val = tc358768_ns_to_cnt(val, dsibclk_nsk) - 1;
+   val = tc358768_ns_to_cnt(val, dsibclk_nsk) / 4 - 1;
val2 = tc358768_ns_to_cnt(tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk),
  dsibclk_nsk) - 2;
val = val << 16 | val2;
-- 
2.25.1

[PATCH v1 9/9] drm/bridge: tc358768: remove unused variable

[Francesco Dolcini]

From: Francesco Dolcini 

Remove the unused phy_delay_nsk variable, before it was wrongly used
to compute some register value, the fixed computation is no longer using
it and therefore can be removed.

Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 947c7dca567a..d3af42a16e69 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -641,7 +641,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
u32 val, val2, lptxcnt, hact, data_type;
s32 raw_val;
const struct drm_display_mode *mode;
-   u32 dsibclk_nsk, dsiclk_nsk, ui_nsk, phy_delay_nsk;
+   u32 dsibclk_nsk, dsiclk_nsk, ui_nsk;
u32 dsiclk, dsibclk, video_start;
const u32 internal_delay = 40;
int ret, i;
@@ -725,11 +725,9 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
  dsibclk);
dsiclk_nsk = (u32)div_u64((u64)10 * TC358768_PRECISION, dsiclk);
ui_nsk = dsiclk_nsk / 2;
-   phy_delay_nsk = dsibclk_nsk + 2 * dsiclk_nsk;
dev_dbg(priv->dev, "dsiclk_nsk: %u\n", dsiclk_nsk);
dev_dbg(priv->dev, "ui_nsk: %u\n", ui_nsk);
dev_dbg(priv->dev, "dsibclk_nsk: %u\n", dsibclk_nsk);
-   dev_dbg(priv->dev, "phy_delay_nsk: %u\n", phy_delay_nsk);
 
/* LP11 > 100us for D-PHY Rx Init */
val = tc358768_ns_to_cnt(100 * 1000, dsibclk_nsk) - 1;
-- 
2.25.1

[PATCH v1 6/9] drm/bridge: tc358768: fix THS_ZEROCNT computation

[Francesco Dolcini]

From: Francesco Dolcini 

Correct computation of THS_ZEROCNT register.

This register must be set to a value that ensure that
THS_PREPARE + THS_ZERO > 145ns + 10*UI

with the actual value of (THS_PREPARE + THS_ZERO) being

((1 to 2) + 1 + (TCLK_ZEROCNT + 1) + (3 to 4)) x ByteClk cycle +
  + HSByteClk x (2 + (1 to 2)) + (PHY delay)

with PHY delay being about

(8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion.

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 360c7c65f8c4..36e33cba59a2 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -760,9 +760,10 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
/* 40ns + 4*UI < THS_PREPARE < 85ns + 6*UI */
val = 50 + tc358768_to_ns(4 * ui_nsk);
val = tc358768_ns_to_cnt(val, dsibclk_nsk) - 1;
-   /* THS_ZERO > 145ns + 10*UI */
-   val2 = tc358768_ns_to_cnt(145 - tc358768_to_ns(ui_nsk), dsibclk_nsk);
-   val |= (val2 - tc358768_to_ns(phy_delay_nsk)) << 8;
+   /* THS_PREPARE + THS_ZERO > 145ns + 10*UI */
+   raw_val = tc358768_ns_to_cnt(145 - tc358768_to_ns(3 * ui_nsk), 
dsibclk_nsk) - 10;
+   val2 = clamp(raw_val, 0, 127);
+   val |= val2 << 8;
dev_dbg(priv->dev, "THS_HEADERCNT: 0x%x\n", val);
tc358768_write(priv, TC358768_THS_HEADERCNT, val);
 
-- 
2.25.1

[PATCH v1 2/9] drm/bridge: tc358768: fix PLL parameters computation

[Francesco Dolcini]

From: Francesco Dolcini 

According to Toshiba documentation the PLL input clock after the divider
should be not less than 4MHz, fix the PLL parameters computation
accordingly.

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 8f349bf4fc32..e9e3f9e02bba 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -334,13 +334,17 @@ static int tc358768_calc_pll(struct tc358768_priv *priv,
u32 fbd;
 
for (fbd = 0; fbd < 512; ++fbd) {
-   u32 pll, diff;
+   u32 pll, diff, pll_in;
 
pll = (u32)div_u64((u64)refclk * (fbd + 1), divisor);
 
if (pll >= max_pll || pll < min_pll)
continue;
 
+   pll_in = (u32)div_u64((u64)refclk, prd + 1);
+   if (pll_in < 400)
+   continue;
+
diff = max(pll, target_pll) - min(pll, target_pll);
 
if (diff < best_diff) {
-- 
2.25.1

[PATCH v1 1/9] drm/bridge: tc358768: always enable HS video mode

[Francesco Dolcini]

From: Francesco Dolcini 

Always enable HS video mode setting the TXMD bit, without this change no
video output is present with DSI sinks that are setting
MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge).

Previously the driver was enabling HS mode only when the DSI sink was
not explicitly setting the MIPI_DSI_MODE_LPM, however this is not
correct.

The MIPI_DSI_MODE_LPM is supposed to indicate that the sink is willing
to receive data in low power mode, however clearing the
TC358768_DSI_CONTROL_TXMD bit will make the TC358768 send video in
LP mode that is not the intended behavior.

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 7c0cbe84611b..8f349bf4fc32 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -866,8 +866,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge 
*bridge)
val = TC358768_DSI_CONFW_MODE_SET | TC358768_DSI_CONFW_ADDR_DSI_CONTROL;
val |= (dsi_dev->lanes - 1) << 1;
 
-   if (!(dsi_dev->mode_flags & MIPI_DSI_MODE_LPM))
-   val |= TC358768_DSI_CONTROL_TXMD;
+   val |= TC358768_DSI_CONTROL_TXMD;
 
if (!(mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
val |= TC358768_DSI_CONTROL_HSCKMD;
-- 
2.25.1

[PATCH v1 3/9] drm/bridge: tc358768: fix PLL target frequency

[Francesco Dolcini]

From: Francesco Dolcini 

Correctly compute the PLL target frequency, the current formula works
correctly only when the input bus width is 24bit, actually to properly
compute the PLL target frequency what is relevant is the bits-per-pixel
on the DSI link.

No regression expected since the DSI format is currently hard-coded as
MIPI_DSI_FMT_RGB888.

Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini 
---
 drivers/gpu/drm/bridge/tc358768.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index e9e3f9e02bba..dba1bf3912f1 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -146,6 +146,7 @@ struct tc358768_priv {
 
u32 pd_lines; /* number of Parallel Port Input Data Lines */
u32 dsi_lanes; /* number of DSI Lanes */
+   u32 dsi_bpp; /* number of Bits Per Pixel over DSI */
 
/* Parameters for PLL programming */
u32 fbd;/* PLL feedback divider */
@@ -284,12 +285,12 @@ static void tc358768_hw_disable(struct tc358768_priv 
*priv)
 
 static u32 tc358768_pll_to_pclk(struct tc358768_priv *priv, u32 pll_clk)
 {
-   return (u32)div_u64((u64)pll_clk * priv->dsi_lanes, priv->pd_lines);
+   return (u32)div_u64((u64)pll_clk * priv->dsi_lanes, priv->dsi_bpp);
 }
 
 static u32 tc358768_pclk_to_pll(struct tc358768_priv *priv, u32 pclk)
 {
-   return (u32)div_u64((u64)pclk * priv->pd_lines, priv->dsi_lanes);
+   return (u32)div_u64((u64)pclk * priv->dsi_bpp, priv->dsi_lanes);
 }
 
 static int tc358768_calc_pll(struct tc358768_priv *priv,
@@ -426,6 +427,7 @@ static int tc358768_dsi_host_attach(struct mipi_dsi_host 
*host,
priv->output.panel = panel;
 
priv->dsi_lanes = dev->lanes;
+   priv->dsi_bpp = mipi_dsi_pixel_format_to_bpp(dev->format);
 
/* get input ep (port0/endpoint0) */
ret = -EINVAL;
@@ -437,7 +439,7 @@ static int tc358768_dsi_host_attach(struct mipi_dsi_host 
*host,
}
 
if (ret)
-   priv->pd_lines = mipi_dsi_pixel_format_to_bpp(dev->format);
+   priv->pd_lines = priv->dsi_bpp;
 
drm_bridge_add(>bridge);
 
-- 
2.25.1