[Intel-gfx] [PATCH v3 2/5] drm/i915: use pat_index instead of cache_level
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,
[Intel-gfx] [PATCH v3 4/5] drm/i915/mtl: end support for set caching ioctl
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
[Intel-gfx] [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation
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
[Intel-gfx] [PATCH v3 5/5] drm/i915: Allow user to set cache at BO creation
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
[Intel-gfx] [PATCH v3 1/5] drm/i915: preparation for using PAT index
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
---
[Intel-gfx] [PATCH v3 3/5] drm/i915: make sure correct pte encode is used
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
[Intel-gfx] [PATCH v3 2/3] drm/i915: use pat_index instead of cache_level
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,
[Intel-gfx] [PATCH v3 1/3] drm/i915: preparation for using PAT index
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
---
[Intel-gfx] [PATCH v3 3/3] drm/i915: make sure correct pte encode is used
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
[Intel-gfx] [PATCH v3 0/3] drm/i915: use pat_index instead of cache_level
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
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: Add MTL PXP Support (rev9)
== Series Details ==
Series: drm/i915/pxp: Add MTL PXP Support (rev9)
URL : https://patchwork.freedesktop.org/series/112647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_112647v9_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_112647v9_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#2842]) +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-apl3/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][4] -> [FAIL][5] ([i915#8400])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-snb6/igt@i915_pm_...@reset.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-snb1/igt@i915_pm_...@reset.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271]) +25 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-apl3/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-glk7/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][8] ([i915#7173])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-apl3/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271]) +26 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-snb6/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-a-vga-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-glk7/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][11] ([i915#7461] / [i915#8234]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][13] ([i915#6268]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html
- {shard-tglu}: [FAIL][15] ([i915#6268]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-tglu-6/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@hibernate:
- shard-apl: [ABORT][17] ([i915#8213]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_...@hibernate.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-apl3/igt@gem_...@hibernate.html
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][19] ([i915#5784]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-12/igt@gem_...@reset-stress.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-dg1-18/igt@gem_...@reset-stress.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][21] ([i915#2846]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-7/igt@gem_exec_f...@basic-deadline.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/shard-rkl-4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][23] ([i915#2842]) -> [PASS][24]
[23]:
Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL
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
[Intel-gfx] ✓ Fi.CI.IGT: success for fdinfo: Enable some support for GuC based client busyness (rev2)
== Series Details ==
Series: fdinfo: Enable some support for GuC based client busyness (rev2)
URL : https://patchwork.freedesktop.org/series/116120/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116120v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116120v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@drm_fdinfo@isolation@vecs0:
- {shard-dg1}:NOTRUN -> [SKIP][1] +39 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-dg1-12/igt@drm_fdinfo@isolat...@vecs0.html
* igt@drm_fdinfo@virtual-busy-all:
- {shard-dg1}:[SKIP][2] ([i915#5563]) -> [SKIP][3] +7 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-17/igt@drm_fdi...@virtual-busy-all.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-dg1-13/igt@drm_fdi...@virtual-busy-all.html
Known issues
Here are the changes found in Patchwork_116120v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [PASS][4] -> [ABORT][5] ([i915#7461])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk2/igt@gem_barrier_race@remote-requ...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-glk2/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-glk7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-apl2/igt@gem_huc_c...@huc-copy.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271]) +25 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-apl2/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271]) +6 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-glk3/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][13] ([i915#7173])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-apl2/igt@kms_content_protection@ato...@pipe-a-dp-1.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0-25@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271]) +21 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-snb1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0...@pipe-a-hdmi-a-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-glk3/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#7742]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@drm_fdinfo@virtual-idle:
- {shard-dg1}:[SKIP][18] ([i915#5563]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-17/igt@drm_fdi...@virtual-idle.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/shard-dg1-13/igt@drm_fdi...@virtual-idle.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][20] ([i915#7461] /
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)
== Series Details ==
Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for
efficient freq (rev3)
URL : https://patchwork.freedesktop.org/series/116957/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116957v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116957v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@perf_pmu@frequency:
- {shard-dg1}:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@perf_...@frequency.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-dg1-13/igt@perf_...@frequency.html
Known issues
Here are the changes found in Patchwork_116957v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [PASS][3] -> [ABORT][4] ([i915#7461])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk2/igt@gem_barrier_race@remote-requ...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-glk6/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-apl1/igt@gem_huc_c...@huc-copy.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-1:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2521])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk6/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-glk3/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +25 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-apl1/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271]) +6 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-glk3/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][14] ([i915#7173])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-apl1/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#2346])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
*
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271]) +21 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-snb1/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-...@pipe-b-hdmi-a-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#658])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/shard-glk3/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#7742]) -> [PASS][20] +1 similar
issue
[19]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: HuC loading and authentication for MTL
== Series Details == Series: drm/i915: HuC loading and authentication for MTL URL : https://patchwork.freedesktop.org/series/117080/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_117080v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_117080v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_117080v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/index.html Participating hosts (38 -> 35) -- Missing(3): bat-mtlp-8 fi-snb-2520m bat-mtlp-6 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_117080v1: ### IGT changes ### Possible regressions * igt@gem_huc_copy@huc-copy: - bat-dg2-8: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@gem_huc_c...@huc-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-dg2-8/igt@gem_huc_c...@huc-copy.html - bat-dg2-9: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-9/igt@gem_huc_c...@huc-copy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-dg2-9/igt@gem_huc_c...@huc-copy.html - bat-atsm-1: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-atsm-1/igt@gem_huc_c...@huc-copy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-atsm-1/igt@gem_huc_c...@huc-copy.html - bat-dg2-11: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-11/igt@gem_huc_c...@huc-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-dg2-11/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-atsm-1/igt@i915_hang...@error-state-basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html - bat-dg2-9: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-9/igt@i915_hang...@error-state-basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-dg2-9/igt@i915_hang...@error-state-basic.html - bat-dg2-8: [PASS][13] -> [ABORT][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@i915_hang...@error-state-basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-dg2-8/igt@i915_hang...@error-state-basic.html - bat-dg2-11: [PASS][15] -> [ABORT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-11/igt@i915_hang...@error-state-basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/bat-dg2-11/igt@i915_hang...@error-state-basic.html Known issues Here are the changes found in Patchwork_117080v1 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-glk-j4005: [FAIL][17] ([i915#7916]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@core_hotunplug@unbind-rebind: - fi-kbl-8809g: [ABORT][19] -> [ABORT][20] ([i915#8397]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html * igt@i915_suspend@basic-s3-without-i915: - fi-tgl-1115g4: [INCOMPLETE][21] ([i915#7443] / [i915#8102]) -> [INCOMPLETE][22] ([i915#8102]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html [i915#7443]: https://gitlab.freedesktop.org/drm/intel/issues/7443 [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916 [i915#8102]: https://gitlab.freedesktop.org/drm/intel/issues/8102 [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397 Build changes - * Linux: CI_DRM_13071 -> Patchwork_117080v1 CI-20190529: 20190529 CI_DRM_13071:
Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL
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
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: HuC loading and authentication for MTL
== Series Details == Series: drm/i915: HuC loading and authentication for MTL URL : https://patchwork.freedesktop.org/series/117080/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: HuC loading and authentication for MTL
== Series Details ==
Series: drm/i915: HuC loading and authentication for MTL
URL : https://patchwork.freedesktop.org/series/117080/
State : warning
== Summary ==
Error: dim checkpatch failed
0ce1e3ea75ee DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:133: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#133:
new file mode 100644
-:138: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#138: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c:1:
+#include "intel_gsc_proxy.h"
-:140: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#140: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c:3:
+// SPDX-License-Identifier: MIT
-:278: WARNING:MEMORY_BARRIER: memory barrier without comment
#278: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c:141:
+ wmb();
-:321: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#321: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c:184:
+
+}
total: 0 errors, 4 warnings, 1 checks, 988 lines checked
d626311e03a1 drm/i915/uc: perma-pin firmwares
-:114: ERROR:SPACING: space prohibited before that close parenthesis ')'
#114: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:117:
+intel_uc_ops_function(resume_mappings, resume_mappings, void, );
total: 1 errors, 0 warnings, 0 checks, 196 lines checked
243c17062287 drm/i915/huc: Parse the GSC-enabled HuC binary
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:21: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#21:
new file mode 100644
-:411: WARNING:LINE_SPACING: Missing a blank line after declarations
#411: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:623:
+ u32 delta = uc_fw->dma_start_offset;
+ __check_ccs_header(gt, fw->data + delta, fw->size - delta,
uc_fw);
total: 0 errors, 2 warnings, 0 checks, 379 lines checked
444c00ae6339 drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
-:56: ERROR:SPACING: space required after that ',' (ctx:VxV)
#56: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:321:
+ huc_err(huc," HW in legacy mode, but we have an incompatible
meu blob\n");
^
total: 1 errors, 0 warnings, 0 checks, 131 lines checked
956cd2b7b0be drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
-:47: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of
BUG() or variants
#47: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:128:
+ GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
-:298: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'base' may be better as
'(base)' to avoid precedence issues
#298: FILE: drivers/gpu/drm/i915/i915_reg.h:944:
+#define HECI_FWSTS5(base) _MMIO(base + 0xc68)
total: 0 errors, 1 warnings, 1 checks, 258 lines checked
6340719ed1b3 drm/i915/mtl/huc: auth HuC via GSC
-:9: WARNING:TYPO_SPELLING: 'fuction' may be misspelled - perhaps 'function'?
#9:
The intel_huc_auth fuction is also updated to handle both authentication
^^^
-:83: WARNING:LINE_SPACING: Missing a blank line after declarations
#83: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:359:
+ struct i915_vma *vma = intel_guc_allocate_vma(>uc.guc,
SZ_8K);
+ if (IS_ERR(vma)) {
-:155: ERROR:SPACING: space required before the open parenthesis '('
#155: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:479:
+ switch(type) {
total: 1 errors, 2 warnings, 0 checks, 328 lines checked
83b98c868a5c drm/i915/mtl/huc: Use the media gt for the HuC getparam
c7c054ca0cad drm/i915/huc: define HuC FW version for MTL
[Intel-gfx] [PATCH 7/8] drm/i915/mtl/huc: Use the media gt for the HuC getparam
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
[Intel-gfx] [PATCH 6/8] drm/i915/mtl/huc: auth HuC via GSC
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
[Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL
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
[Intel-gfx] [PATCH 8/8] drm/i915/huc: define HuC FW version for MTL
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
[Intel-gfx] [PATCH 5/8] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
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
[Intel-gfx] [PATCH 4/8] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
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;
[Intel-gfx] [PATCH 3/8] drm/i915/huc: Parse the GSC-enabled HuC binary
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
[Intel-gfx] [PATCH 2/8] drm/i915/uc: perma-pin firmwares
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,
[Intel-gfx] [PATCH 1/8] DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
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
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Hugepage manager and test for MTL (rev3)
== Series Details ==
Series: drm/i915: Hugepage manager and test for MTL (rev3)
URL : https://patchwork.freedesktop.org/series/116995/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116995v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116995v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-10/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-tglu-10/igt@gem_barrier_race@remote-requ...@rcs0.html
Known issues
Here are the changes found in Patchwork_116995v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@gem_huc_c...@huc-copy.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271]) +25 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-glk8/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][8] ([i915#7173])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271]) +37 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-snb6/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-a-vga-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-glk8/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][15] ([i915#7461] / [i915#8234]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-dg1-12/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][17] ([i915#6268]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@hibernate:
- shard-apl: [ABORT][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_...@hibernate.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/shard-apl4/igt@gem_...@hibernate.html
*
[Intel-gfx] [CI] PR for HuC v8.4.5 for MTL
The following changes since commit fab149657d8d029c06179dd006b59b2f3594f916: Group all Conexant V4L devices together (2023-04-27 09:15:55 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware mtl_huc_8.4.5 for you to fetch changes up to 2cae62ee3cc08ad2d6271a5664f18462294d62be: i915: add HuC v8.4.5 for MTL (2023-04-27 17:39:43 -0700) Daniele Ceraolo Spurio (1): i915: add HuC v8.4.5 for MTL WHENCE | 3 +++ i915/mtl_huc_gsc.bin | Bin 0 -> 626688 bytes 2 files changed, 3 insertions(+) create mode 100755 i915/mtl_huc_gsc.bin
[Intel-gfx] ✗ Fi.CI.IGT: failure for mtl: add support for pmdemand (rev4)
== Series Details ==
Series: mtl: add support for pmdemand (rev4)
URL : https://patchwork.freedesktop.org/series/116949/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116949v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_116949v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_116949v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116949v4_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk8/igt@kms_cursor_leg...@2x-cursor-vs-flip-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-glk7/igt@kms_cursor_leg...@2x-cursor-vs-flip-atomic.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@i915_selftest@live@workarounds:
- {shard-dg1}:[PASS][5] -> [ABORT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@i915_selftest@l...@workarounds.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-dg1-13/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_116949v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl3/igt@gem_huc_c...@huc-copy.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +25 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl3/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][13] ([i915#7173])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-apl3/igt@kms_content_protection@ato...@pipe-a-dp-1.html
*
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271]) +21 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-snb1/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-...@pipe-b-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][17] ([i915#7461] / [i915#8234]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/shard-dg1-12/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_eio@hibernate:
- shard-apl: [ABORT][19] -> [PASS][20]
[19]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev9)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev9) URL : https://patchwork.freedesktop.org/series/112647/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_112647v9 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/index.html Participating hosts (38 -> 36) -- Missing(2): bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_112647v9 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#8384]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@reset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [PASS][3] -> [FAIL][4] ([i915#7932]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-glk-j4005: [FAIL][5] ([i915#7916]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@core_hotunplug@unbind-rebind: - fi-kbl-8809g: [ABORT][7] -> [ABORT][8] ([i915#8397]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384 [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397 Build changes - * Linux: CI_DRM_13071 -> Patchwork_112647v9 CI-20190529: 20190529 CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_112647v9: b9458e7075652669ec0e04abe039a5ed001701fe @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits e8198913fb52 drm/i915/pxp: Enable PXP with MTL-GSC-CS 011a5305fc2e drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component 2376e499100c drm/i915/uapi/pxp: Add a GET_PARAM for PXP 1ec1cc5c4289 drm/i915/pxp: Add ARB session creation and cleanup 7dbb00a61263 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages 3419de8797ba drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC 0bfe806a36ed drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation e72c1f99d86c drm/i915/pxp: Add GSC-CS back-end resource init and cleanup == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v9/index.html
Re: [Intel-gfx] [PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
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
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev9)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev9) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev9)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev9) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim checkpatch failed e93c6f73e145 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:99: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #99: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 173 lines checked c4038c750253 drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:109: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #109: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 153 lines checked 89dc3a6ba479 drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC 35ffeec3fe80 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages -:109: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #109: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:43: + GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE)); total: 0 errors, 1 warnings, 0 checks, 326 lines checked 8f8dbe8a8d33 drm/i915/pxp: Add ARB session creation and cleanup 7ba97b08f8de drm/i915/uapi/pxp: Add a GET_PARAM for PXP -:24: WARNING:TYPO_SPELLING: 'similiar' may be misspelled - perhaps 'similar'? #24: similiar checks. total: 0 errors, 1 warnings, 0 checks, 96 lines checked 0a11a1c36145 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component 0d4594ea1808 drm/i915/pxp: Enable PXP with MTL-GSC-CS
[Intel-gfx] ✓ Fi.CI.BAT: success for fdinfo: Enable some support for GuC based client busyness (rev2)
== Series Details ==
Series: fdinfo: Enable some support for GuC based client busyness (rev2)
URL : https://patchwork.freedesktop.org/series/116120/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116120v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/index.html
Participating hosts (38 -> 37)
--
Additional (1): fi-kbl-soraka
Missing(2): bat-mtlp-8 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116120v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [FAIL][3] ([i915#7916])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [FAIL][4] ([i915#7913] / [i915#8383])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@migrate:
- bat-atsm-1: [PASS][5] -> [FAIL][6] ([i915#6268] / [i915#7913])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- bat-rplp-1: [PASS][7] -> [FAIL][8] ([i915#7913])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rplp-1/igt@i915_selftest@l...@slpc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rplp-1/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271]) +16 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][10] ([i915#7828])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#1845])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][12] ([i915#6687]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [FAIL][14] ([i915#7916]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][16] ([i915#7920]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-mtlp-6/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: [FAIL][18] ([i915#6997]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Warnings
* igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g: [ABORT][20] -> [ABORT][21] ([i915#8397])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v2/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]:
[Intel-gfx] [PATCH v9 5/8] drm/i915/pxp: Add ARB session creation and cleanup
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
+
[Intel-gfx] [PATCH v9 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS
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),
[Intel-gfx] [PATCH v9 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
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
[Intel-gfx] [PATCH v9 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
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)
[Intel-gfx] [PATCH v9 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
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 =
[Intel-gfx] [PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
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
[Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
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
[Intel-gfx] [PATCH v9 0/8] drm/i915/pxp: Add MTL PXP Support
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
[Intel-gfx] [PATCH v9 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
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
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fdinfo: Enable some support for GuC based client busyness (rev2)
== Series Details == Series: fdinfo: Enable some support for GuC based client busyness (rev2) URL : https://patchwork.freedesktop.org/series/116120/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)
== Series Details == Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3) URL : https://patchwork.freedesktop.org/series/116957/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116957v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/index.html Participating hosts (38 -> 37) -- Additional (1): fi-kbl-soraka Missing(2): bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_116957v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [FAIL][3] ([i915#7913] / [i915#8383]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][4] -> [ABORT][5] ([i915#8384]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@reset.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +16 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-glk-j4005: [FAIL][9] ([i915#7916]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@slpc: - bat-adln-1: [FAIL][11] ([i915#6997]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-adln-1/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/bat-adln-1/igt@i915_selftest@l...@slpc.html Warnings * igt@core_hotunplug@unbind-rebind: - fi-kbl-8809g: [ABORT][13] -> [ABORT][14] ([i915#8397]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#8383]: https://gitlab.freedesktop.org/drm/intel/issues/8383 [i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384 [i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397 Build changes - * Linux: CI_DRM_13071 -> Patchwork_116957v3 CI-20190529: 20190529 CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116957v3: b9458e7075652669ec0e04abe039a5ed001701fe @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 4794ebe681d1 drm/i915/selftest: Update the SLPC selftest 3e9db6645c0c drm/i915/guc/slpc: Provide sysfs for efficient freq == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116957v3/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)
== Series Details == Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3) URL : https://patchwork.freedesktop.org/series/116957/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2)
== Series Details ==
Series: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()
(rev2)
URL : https://patchwork.freedesktop.org/series/116947/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116947v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_116947v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_116947v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116947v2_full:
### IGT changes ###
Possible regressions
* igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1:
- shard-apl: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl1/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl3/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html
Known issues
Here are the changes found in Patchwork_116947v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-glk8/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl1/igt@gem_huc_c...@huc-copy.html
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb: [PASS][8] -> [FAIL][9] ([i915#8295])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-snb5/igt@gem_pp...@blt-vs-render-ctxn.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-snb6/igt@gem_pp...@blt-vs-render-ctxn.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271]) +25 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl1/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271]) +6 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-glk6/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][12] ([i915#7173])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-apl1/igt@kms_content_protection@ato...@pipe-a-dp-1.html
*
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +5 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-snb1/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-...@pipe-b-hdmi-a-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-glk6/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][17] ([i915#7461] / [i915#8234]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/shard-dg1-17/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][19] ([i915#6268])
[Intel-gfx] [PATCH 0/2] fdinfo: Enable some support for GuC based client busyness
Export context runtime into the fdinfo framework to enable per client busyness for GuC back-end. v2: Fix zeroed busyness values v3: Include review comments from Ashutosh Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (2): i915/pmu: Add support for total context runtime for GuC back-end drm/i915/fdinfo: Enable fdinfo for GuC backends drivers/gpu/drm/i915/gt/intel_context.c | 5 ++- drivers/gpu/drm/i915/gt/intel_context.h | 2 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++ .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 +++ drivers/gpu/drm/i915/i915_drm_client.c| 6 +--- 5 files changed, 39 insertions(+), 7 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end
GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
in the context image. This value is saved/restored on context switches.
KMD accumulates these values into a 64 bit counter taking care of any
overflows as needed. This count provides the basis for client specific
busyness in the fdinfo interface.
KMD accumulation happens just before the context is unpinned and when
context switches out. This works for execlist back-end since execlist
scheduling has visibility into context switches. With GuC mode, KMD does
not have visibility into context switches and this counter is
accumulated only when context is unpinned. Context is unpinned once the
context scheduling is successfully disabled. Disabling context
scheduling is an asynchronous operation. Also if a context is servicing
frequent requests, scheduling may never be disabled on it.
For GuC mode, since updates to the context runtime may be delayed, add
hooks to update the context runtime in a worker thread as well as when
a user queries for it.
Limitation:
- If a context is never switched out or runs for a long period of time,
the runtime value of CTX_TIMESTAMP may never be updated, so the
counter value may be unreliable. This patch does not support such
cases. Such support must be available from the GuC FW and it is WIP.
This patch is an extract from previous work authored by John/Umesh here -
https://patchwork.freedesktop.org/patch/496441/?series=105085=4
v2: (Ashutosh)
- Drop COPS_RUNTIME_ACTIVE_TOTAL
- s/guc_context_update_clks/__guc_context_update_stats
- Pin context before accessing in guc_timestamp_ping
- In guc_context_unpin, use spinlock to serialize access to runtime stats
Signed-off-by: Umesh Nerlige Ramappa
Co-developed-by: John Harrison
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 +++
4 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2aa63ec521b8..a53b26178f0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -578,10 +578,13 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
child->parallel.parent = parent;
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
u64 total, active;
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
+
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
total *= ce->engine->gt->clock_period_ns;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 48f888c3da08..43ed92f8dc83 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -375,7 +375,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e36670f2e626..aceaac28a33e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -58,6 +58,8 @@ struct intel_context_ops {
void (*sched_disable)(struct intel_context *ce);
+ void (*update_stats)(struct intel_context *ce);
+
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index ee3e8352637f..c869ddc73e69 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1402,13 +1402,34 @@ static void __update_guc_busyness_stats(struct
intel_guc *guc)
spin_unlock_irqrestore(>timestamp.lock, flags);
}
+static void __guc_context_update_stats(struct intel_context *ce)
+{
+ struct intel_guc *guc = ce_to_guc(ce);
+ unsigned long flags;
+
+ spin_lock_irqsave(>timestamp.lock, flags);
+ lrc_update_runtime(ce);
+ spin_unlock_irqrestore(>timestamp.lock, flags);
+}
+
+static void guc_context_update_stats(struct intel_context *ce)
+{
+ if (!intel_context_pin_if_active(ce))
+ return;
+
+ __guc_context_update_stats(ce);
+ intel_context_unpin(ce);
+}
+
static void guc_timestamp_ping(struct work_struct *wrk)
{
struct intel_guc *guc = container_of(wrk,
[Intel-gfx] [PATCH 2/2] drm/i915/fdinfo: Enable fdinfo for GuC backends
Enable fdinfo for GuC based platforms with the exception that long running contexts will not provide reliable busyness data unless they switch out at some reasonable point in time. Link: https://gitlab.freedesktop.org/drm/intel/issues/8303 Signed-off-by: Umesh Nerlige Ramappa --- drivers/gpu/drm/i915/i915_drm_client.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c index e8fa172ebe5e..d18d0a3ed905 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.c +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -147,11 +147,7 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file *f) PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); seq_printf(m, "drm-client-id:\t%u\n", client->id); - /* -* Temporarily skip showing client engine information with GuC submission till -* fetching engine busyness is implemented in the GuC submission backend -*/ - if (GRAPHICS_VER(i915) < 8 || intel_uc_uses_guc_submission(>gt0.uc)) + if (GRAPHICS_VER(i915) < 8) return; for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) -- 2.36.1
Re: [Intel-gfx] [PATCH v4 9/9] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Wed, 26 Apr 2023 07:54:19 -0700
Yi Liu wrote:
> This is the way user to invoke hot-reset for the devices opened by cdev
> interface. User should check the flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE
> in the output of VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl before doing
> hot-reset for cdev devices.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 66 +++-
> include/uapi/linux/vfio.h| 22 +++
> 2 files changed, 79 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 43858d471447..f70e3b948b16 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -180,7 +180,8 @@ static void vfio_pci_probe_mmaps(struct
> vfio_pci_core_device *vdev)
> struct vfio_pci_group_info;
> static void vfio_pci_dev_set_try_reset(struct vfio_device_set *dev_set);
> static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> - struct vfio_pci_group_info *groups);
> + struct vfio_pci_group_info *groups,
> + struct iommufd_ctx *iommufd_ctx);
>
> /*
> * INTx masking requires the ability to disable INTx signaling via
> PCI_COMMAND
> @@ -1364,8 +1365,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> if (ret)
> return ret;
>
> - /* Somewhere between 1 and count is OK */
> - if (!array_count || array_count > count)
> + if (array_count > count)
> return -EINVAL;
Doesn't this need a || vfio_device_cdev_opened(vdev) test as well?
It's invalid to pass fds for a cdev device. Presumably it would fail
later collecting group fds as well, but might as well enforce the
semantics early.
>
> group_fds = kcalloc(array_count, sizeof(*group_fds), GFP_KERNEL);
> @@ -1414,7 +1414,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> info.count = array_count;
> info.files = files;
>
> - ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, );
> + ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, , NULL);
>
> hot_reset_release:
> for (file_idx--; file_idx >= 0; file_idx--)
> @@ -1429,6 +1429,7 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> {
> unsigned long minsz = offsetofend(struct vfio_pci_hot_reset, count);
> struct vfio_pci_hot_reset hdr;
> + struct iommufd_ctx *iommufd;
> bool slot = false;
>
> if (copy_from_user(, arg, minsz))
> @@ -1443,7 +1444,12 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> else if (pci_probe_reset_bus(vdev->pdev->bus))
> return -ENODEV;
>
> - return vfio_pci_ioctl_pci_hot_reset_groups(vdev, hdr.count, slot, arg);
> + if (hdr.count)
> + return vfio_pci_ioctl_pci_hot_reset_groups(vdev, hdr.count,
> slot, arg);
> +
> + iommufd = vfio_iommufd_physical_ictx(>vdev);
> +
> + return vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, NULL, iommufd);
Why did we need to store iommufd in a variable?
> }
>
> static int vfio_pci_ioctl_ioeventfd(struct vfio_pci_core_device *vdev,
> @@ -2415,6 +2421,9 @@ static bool vfio_dev_in_groups(struct
> vfio_pci_core_device *vdev,
> {
> unsigned int i;
>
> + if (!groups)
> + return false;
> +
> for (i = 0; i < groups->count; i++)
> if (vfio_file_has_dev(groups->files[i], >vdev))
> return true;
> @@ -2488,13 +2497,38 @@ static int vfio_pci_dev_set_pm_runtime_get(struct
> vfio_device_set *dev_set)
> return ret;
> }
>
> +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> + struct iommufd_ctx *iommufd_ctx)
> +{
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(>vdev);
> + struct iommu_group *iommu_group;
> +
> + if (!iommufd_ctx)
> + return false;
> +
> + if (iommufd == iommufd_ctx)
> + return true;
> +
> + iommu_group = iommu_group_get(vdev->vdev.dev);
> + if (!iommu_group)
> + return false;
> +
> + /*
> + * Try to check if any device within iommu_group is bound with
> + * the input iommufd_ctx.
> + */
> + return vfio_devset_iommufd_has_group(vdev->vdev.dev_set,
> + iommufd_ctx, iommu_group);
> +}
This last test makes this not do what the function name suggests it
does. If it were true, the device is not in the iommufd_ctx, it simply
cannot be within another iommu ctx.
> +
> /*
> * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> * therefore we need to zap and hold the vma_lock for
Re: [Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND
Quoting Vinod Govindapillai (2023-04-27 12:00:15)
>From: Mika Kahola
>
>Display14 introduces a new way to instruct the PUnit with
>power and bandwidth requirements of DE. Add the functionality
>to program the registers and handle waits using interrupts.
>The current wait time for timeouts is programmed for 10 msecs to
>factor in the worst case scenarios. Changes made to use REG_BIT
>for a register that we touched(GEN8_DE_MISC_IER _MMIO).
>
>Wa_14016740474 is added which applies to Xe_LPD+ display
>
>v2: checkpatch warning fixes, simplify program pmdemand part
>
>v3: update to dbufs and pipes values to pmdemand register(stan)
>Removed the macro usage in update_pmdemand_values()
>
>Bspec: 66451, 64636, 64602, 64603
>Cc: Matt Atwood
>Cc: Matt Roper
>Cc: Lucas De Marchi
>Cc: Gustavo Sousa
>Signed-off-by: José Roberto de Souza
>Signed-off-by: Radhakrishna Sripada
>Signed-off-by: Gustavo Sousa
>Signed-off-by: Mika Kahola
>Signed-off-by: Vinod Govindapillai
>---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_display.c | 7 +
> .../gpu/drm/i915/display/intel_display_core.h | 6 +
> .../drm/i915/display/intel_display_driver.c | 7 +
> .../drm/i915/display/intel_display_power.c| 8 +
> drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
> drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 +
> drivers/gpu/drm/i915/i915_irq.c | 21 +-
> drivers/gpu/drm/i915/i915_reg.h | 36 +-
> 9 files changed, 562 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
>
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 9af76e376ca9..eb899fa86e51 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -281,7 +281,8 @@ i915-y += \
>display/i9xx_wm.o \
>display/skl_scaler.o \
>display/skl_universal_plane.o \
>- display/skl_watermark.o
>+ display/skl_watermark.o \
>+ display/intel_pmdemand.o
> i915-$(CONFIG_ACPI) += \
>display/intel_acpi.o \
>display/intel_opregion.o
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index bf391a6cd8d6..f98e235fadc6 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -99,6 +99,7 @@
> #include "intel_pcode.h"
> #include "intel_pipe_crc.h"
> #include "intel_plane_initial.h"
>+#include "intel_pmdemand.h"
> #include "intel_pps.h"
> #include "intel_psr.h"
> #include "intel_sdvo.h"
>@@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
>return ret;
>}
>
>+ ret = intel_pmdemand_atomic_check(state);
>+ if (ret)
>+ goto fail;
>+
>ret = intel_atomic_check_crtcs(state);
>if (ret)
>goto fail;
>@@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct
>intel_atomic_state *state)
>}
>
>intel_sagv_pre_plane_update(state);
>+ intel_pmdemand_pre_plane_update(state);
>
>/* Complete the events for pipes that have now been disabled */
>for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
>@@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct
>intel_atomic_state *state)
>intel_verify_planes(state);
>
>intel_sagv_post_plane_update(state);
>+ intel_pmdemand_post_plane_update(state);
>
>drm_atomic_helper_commit_hw_done(>base);
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
>b/drivers/gpu/drm/i915/display/intel_display_core.h
>index 9f66d734edf6..9471a052aa57 100644
>--- a/drivers/gpu/drm/i915/display/intel_display_core.h
>+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
>@@ -345,6 +345,12 @@ struct intel_display {
>struct intel_global_obj obj;
>} dbuf;
>
>+ struct {
>+ wait_queue_head_t waitqueue;
>+ struct mutex lock;
>+ struct intel_global_obj obj;
>+ } pmdemand;
>+
>struct {
>/*
> * dkl.phy_lock protects against concurrent access of the
>diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
>b/drivers/gpu/drm/i915/display/intel_display_driver.c
>index 60ce10fc7205..79853d8c3240 100644
>--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
>+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
>@@ -47,6 +47,7 @@
> #include "intel_opregion.h"
> #include "intel_overlay.h"
> #include "intel_plane_initial.h"
>+#include "intel_pmdemand.h"
> #include "intel_pps.h"
> #include "intel_quirks.h"
> #include "intel_vga.h"
>@@ -211,6 +212,8 @@ int intel_display_driver_probe_noirq(struct
>drm_i915_private *i915)
>if (ret < 0)
>goto cleanup_vga;
>
>+ intel_pmdemand_init(i915);
>+
>intel_power_domains_init_hw(i915, false);
>
Re: [Intel-gfx] [PATCH v4 8/9] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
On Thu, 27 Apr 2023 14:04:05 -0600
Alex Williamson wrote:
> On Wed, 26 Apr 2023 07:54:18 -0700
> Yi Liu wrote:
>
> > This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the bound
> > iommufd of the cdev device to check the ownership of the other affected
> > devices and set a flag to tell user if the cdev device is resettable
> > with a zero-length fd array.
> >
> > For each of the affected devices, if it is bound to the iommufd of the
> > cdev device, _INFO reports a valid dev_id > 0; if it is not opened by
> > the calling user, but it is in the iommu_group of a device that is bound
> > to the iommufd of the cdev device, reports dev_id == 0; If the device is
> > un-owned device, configured within a different iommufd, or opened outside
> > of the vfio device cdev API, the _INFO ioctl shall report dev_id==-1 for
> > such affected devices. dev_id >=0 doesn't block hot-reset, while
> > dev_id == -1 will block hot-reset.
> >
> > This adds flag VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID to tell the user
> > dev_id is returned and adds flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE to
> > tell user if the cdev device is resettable or not.
> >
> > Suggested-by: Jason Gunthorpe
> > Suggested-by: Alex Williamson
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 101 ---
> > include/uapi/linux/vfio.h| 39 +++-
> > 2 files changed, 132 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > b/drivers/vfio/pci/vfio_pci_core.c
> > index 39e7823088e7..43858d471447 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -766,6 +766,51 @@ static int vfio_pci_get_irq_count(struct
> > vfio_pci_core_device *vdev, int irq_typ
> > return 0;
> > }
> >
> > +static struct vfio_device *
> > +vfio_pci_find_device_in_devset(struct vfio_device_set *dev_set,
> > + struct pci_dev *pdev)
> > +{
> > + struct vfio_device *cur;
> > +
> > + lockdep_assert_held(_set->lock);
> > +
> > + list_for_each_entry(cur, _set->device_list, dev_set_list)
> > + if (cur->dev == >dev)
> > + return cur;
> > + return NULL;
> > +}
>
> Couldn't this just as easily take a struct device arg and live in
> vfio/vfio_main.?
>
> > +
> > +/*
> > + * Check if a given iommu_group has been bound to an iommufd within a
> > + * devset. Returns true if there is device in the devset which is in
> > + * the input iommu_group and meanwhile bound to the input iommufd.
> > + * Otherwise, returns false.
> > + */
> > +static bool
> > +vfio_devset_iommufd_has_group(struct vfio_device_set *dev_set,
> > + struct iommufd_ctx *iommufd,
> > + struct iommu_group *iommu_group)
> > +{
> > + struct vfio_device *cur;
> > + struct iommu_group *grp;
> > + bool found = false;
> > +
> > + lockdep_assert_held(_set->lock);
> > +
> > + list_for_each_entry(cur, _set->device_list, dev_set_list) {
> > + grp = iommu_group_get(cur->dev);
> > + if (!grp)
> > + continue;
> > + iommu_group_put(grp);
> > + if (iommu_group == grp &&
> > + iommufd == vfio_iommufd_physical_ictx(cur)) {
> > + found = true;
> > + break;
> > + }
> > + }
> > + return found;
> > +}
>
> And should this live in vfio/iommufd.c? I'd change the variables to
> vdev and group for consistency elsewhere (yeah, I see cur from removed
> code below). We also don't need the found variable, we can simply
> return true from within the loop and false outside of the loop. The
> group variable could also be scoped within the loop.
>
> > +
> > static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
> > {
> > (*(int *)data)++;
> > @@ -776,13 +821,20 @@ struct vfio_pci_fill_info {
> > int max;
> > int cur;
> > struct vfio_pci_dependent_device *devices;
> > + struct vfio_device *vdev;
> > + bool devid;
> > + bool resettable;
>
> See other current threads on list about using bitfields.
>
> > };
> >
> > static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> > {
> > struct vfio_pci_fill_info *fill = data;
> > + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(fill->vdev);
> > + struct vfio_device_set *dev_set = fill->vdev->dev_set;
>
> Curious that we didn't added iommufd and dev_set fields to
> vfio_pci_fill_info instead. Both vars can be scoped within the devid
> branch below.
>
> > struct iommu_group *iommu_group;
> >
> > + lockdep_assert_held(_set->lock);
> > +
> > if (fill->cur == fill->max)
> > return -EAGAIN; /* Something changed, try again */
> >
> > @@ -790,7 +842,34 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev,
> > void *data)
> > if (!iommu_group)
> > return -EPERM; /* Cannot reset non-isolated devices */
> >
>
Re: [Intel-gfx] [PATCH v4 8/9] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
On Wed, 26 Apr 2023 07:54:18 -0700
Yi Liu wrote:
> This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the bound
> iommufd of the cdev device to check the ownership of the other affected
> devices and set a flag to tell user if the cdev device is resettable
> with a zero-length fd array.
>
> For each of the affected devices, if it is bound to the iommufd of the
> cdev device, _INFO reports a valid dev_id > 0; if it is not opened by
> the calling user, but it is in the iommu_group of a device that is bound
> to the iommufd of the cdev device, reports dev_id == 0; If the device is
> un-owned device, configured within a different iommufd, or opened outside
> of the vfio device cdev API, the _INFO ioctl shall report dev_id==-1 for
> such affected devices. dev_id >=0 doesn't block hot-reset, while
> dev_id == -1 will block hot-reset.
>
> This adds flag VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID to tell the user
> dev_id is returned and adds flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE to
> tell user if the cdev device is resettable or not.
>
> Suggested-by: Jason Gunthorpe
> Suggested-by: Alex Williamson
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 101 ---
> include/uapi/linux/vfio.h| 39 +++-
> 2 files changed, 132 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 39e7823088e7..43858d471447 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -766,6 +766,51 @@ static int vfio_pci_get_irq_count(struct
> vfio_pci_core_device *vdev, int irq_typ
> return 0;
> }
>
> +static struct vfio_device *
> +vfio_pci_find_device_in_devset(struct vfio_device_set *dev_set,
> +struct pci_dev *pdev)
> +{
> + struct vfio_device *cur;
> +
> + lockdep_assert_held(_set->lock);
> +
> + list_for_each_entry(cur, _set->device_list, dev_set_list)
> + if (cur->dev == >dev)
> + return cur;
> + return NULL;
> +}
Couldn't this just as easily take a struct device arg and live in
vfio/vfio_main.?
> +
> +/*
> + * Check if a given iommu_group has been bound to an iommufd within a
> + * devset. Returns true if there is device in the devset which is in
> + * the input iommu_group and meanwhile bound to the input iommufd.
> + * Otherwise, returns false.
> + */
> +static bool
> +vfio_devset_iommufd_has_group(struct vfio_device_set *dev_set,
> + struct iommufd_ctx *iommufd,
> + struct iommu_group *iommu_group)
> +{
> + struct vfio_device *cur;
> + struct iommu_group *grp;
> + bool found = false;
> +
> + lockdep_assert_held(_set->lock);
> +
> + list_for_each_entry(cur, _set->device_list, dev_set_list) {
> + grp = iommu_group_get(cur->dev);
> + if (!grp)
> + continue;
> + iommu_group_put(grp);
> + if (iommu_group == grp &&
> + iommufd == vfio_iommufd_physical_ictx(cur)) {
> + found = true;
> + break;
> + }
> + }
> + return found;
> +}
And should this live in vfio/iommufd.c? I'd change the variables to
vdev and group for consistency elsewhere (yeah, I see cur from removed
code below). We also don't need the found variable, we can simply
return true from within the loop and false outside of the loop. The
group variable could also be scoped within the loop.
> +
> static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
> {
> (*(int *)data)++;
> @@ -776,13 +821,20 @@ struct vfio_pci_fill_info {
> int max;
> int cur;
> struct vfio_pci_dependent_device *devices;
> + struct vfio_device *vdev;
> + bool devid;
> + bool resettable;
See other current threads on list about using bitfields.
> };
>
> static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> {
> struct vfio_pci_fill_info *fill = data;
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(fill->vdev);
> + struct vfio_device_set *dev_set = fill->vdev->dev_set;
Curious that we didn't added iommufd and dev_set fields to
vfio_pci_fill_info instead. Both vars can be scoped within the devid
branch below.
> struct iommu_group *iommu_group;
>
> + lockdep_assert_held(_set->lock);
> +
> if (fill->cur == fill->max)
> return -EAGAIN; /* Something changed, try again */
>
> @@ -790,7 +842,34 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev, void
> *data)
> if (!iommu_group)
> return -EPERM; /* Cannot reset non-isolated devices */
>
> - fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> + if (fill->devid) {
> + struct vfio_device *vdev;
> +
> + /*
> + * Report devid for the affected devices:
> + * - valid
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hugepage manager and test for MTL (rev3)
== Series Details ==
Series: drm/i915: Hugepage manager and test for MTL (rev3)
URL : https://patchwork.freedesktop.org/series/116995/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116995v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/index.html
Participating hosts (38 -> 37)
--
Additional (1): fi-kbl-soraka
Missing(2): bat-mtlp-8 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116995v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [FAIL][3] ([i915#7913] / [i915#8383])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +16 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][5] ([i915#7828])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][6] -> [FAIL][7] ([i915#7932])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][8] ([i915#1845])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][9] ([i915#6687]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [FAIL][11] ([i915#7916]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][13] ([i915#7920]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/bat-mtlp-6/igt@i915_selftest@l...@requests.html
Warnings
* igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g: [ABORT][15] -> [ABORT][16] ([i915#8397])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4: [INCOMPLETE][17] ([i915#7443] / [i915#8102]) ->
[INCOMPLETE][18] ([i915#8102])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116995v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7443]:
Re: [Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end
On Wed, Apr 26, 2023 at 05:51:24PM -0700, Dixit, Ashutosh wrote:
On Wed, 26 Apr 2023 17:11:27 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh,
On Mon, Apr 24, 2023 at 10:41:41AM -0700, Dixit, Ashutosh wrote:
> On Tue, 04 Apr 2023 17:14:32 -0700, Umesh Nerlige Ramappa wrote:
>
>> GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
>> in the context image. This value is saved/restored on context switches.
>> KMD accumulates these values into a 64 bit counter taking care of any
>> overflows as needed. This count provides the basis for client specific
>> busyness in the fdinfo interface.
>>
>> KMD accumulation happens just before the context is unpinned and when
>> context switches out. This works for execlist back-end since execlist
>> scheduling has visibility into context switches. With GuC mode, KMD does
>> not have visibility into context switches and this counter is
>> accumulated only when context is unpinned. Context is unpinned once the
>> context scheduling is successfully disabled. Disabling context
>> scheduling is an asynchronous operation.
>
> This means guc_context_unpin() is called asynchronously, correct? From
> guc_context_sched_disable()?
correct
>
>> Also if a context is servicing frequent requests, scheduling may never be
>> disabled on it.
>>
>> For GuC mode, since updates to the context runtime may be delayed, add
>> hooks to update the context runtime in a worker thread as well as when
>> a user queries for it.
>>
>> Limitation:
>> - If a context is never switched out or runs for a long period of time,
>> the runtime value of CTX_TIMESTAMP may never be updated, so the
>> counter value may be unreliable. This patch does not support such
>> cases. Such support must be available from the GuC FW and it is WIP.
>>
>> This patch is an extract from previous work authored by John/Umesh here -
>> https://patchwork.freedesktop.org/patch/496441/?series=105085=4
>>
>> Signed-off-by: Umesh Nerlige Ramappa
>> Co-developed-by: John Harrison
>> Signed-off-by: John Harrison
>> ---
>> drivers/gpu/drm/i915/gt/intel_context.c | 12 +--
>> drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
>> drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +++
>> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 33 +++
>> 4 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
>> index 2aa63ec521b8..e01f222e9e42 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
>> @@ -578,16 +578,24 @@ void intel_context_bind_parent_child(struct
intel_context *parent,
>>child->parallel.parent = parent;
>> }
>>
>> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
>> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
>> {
>>u64 total, active;
>>
>> + if (ce->ops->update_stats)
>> + ce->ops->update_stats(ce);
>> +
>>total = ce->stats.runtime.total;
>>if (ce->ops->flags & COPS_RUNTIME_CYCLES)
>>total *= ce->engine->gt->clock_period_ns;
>>
>>active = READ_ONCE(ce->stats.active);
>> - if (active)
>> + /*
>> + * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
>> + * already provides the total active time of the context,
>
> Where is this done in the GuC case? I looked but couldn't find it (at least
> in this version of the patch, it is there in the old version).
In this case, the backend is not providing the total active time, I guess I
should drop this logic provided ce->stats.active is 0 for GuC mode.
Yes, I think best to skip the active part in this patch since this is a
temporary/inaccurate solution.
>
>> + * so skip this calculation when this flag is set.
>> + */
>> + if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
>>active = intel_context_clock() - active;
>>
>>return total + active;
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
>> index 0a8d553da3f4..720809523e2d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
>> @@ -368,7 +368,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
>>clear_bit(CONTEXT_NOPREEMPT, >flags);
>> }
>>
>> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
>> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
>> u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
>>
>> static inline u64 intel_context_clock(void)
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
>> index e36670f2e626..58b0294d359d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
>> @@ -38,6 +38,9 @@ struct intel_context_ops
Re: [Intel-gfx] [PATCH v4 5/9] vfio: Mark cdev usage in vfio_device
On Wed, 26 Apr 2023 07:54:15 -0700
Yi Liu wrote:
> Use it to differentiate whether to report group_id or dev_id in revised
> VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. Though it is not set at this
> moment introducing it now allows us to get hot reset ready for cdev.
>
> Signed-off-by: Yi Liu
> ---
> include/linux/vfio.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 4ee613924435..298f4ef16be7 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -63,6 +63,7 @@ struct vfio_device {
> bool iommufd_attached;
> #endif
> bool noiommu;
> + bool cdev_opened;
> };
>
> /**
> @@ -140,6 +141,12 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device
> *vdev, u32 *pt_id);
> ((int (*)(struct vfio_device *vdev, u32 *pt_id)) NULL)
> #endif
>
> +static inline bool vfio_device_cdev_opened(struct vfio_device *device)
> +{
> + lockdep_assert_held(>dev_set->lock);
> + return device->cdev_opened;
> +}
The lockdep test doesn't make much sense here, the method of opening
the device can't change from an ioctl called on the device, which is
the only path using this. If there needs to be a placeholder for
future code, it should probably statically return false here and we can
save adding the structure field and locking checks based on the
semantics of how the field is actually used later. Thanks,
Alex
Re: [Intel-gfx] [PATCH v4 1/9] vfio: Determine noiommu in vfio_device registration
On Thu, 27 Apr 2023 07:05:37 +
"Liu, Yi L" wrote:
> > From: Tian, Kevin
> > Sent: Thursday, April 27, 2023 2:36 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, April 26, 2023 10:54 PM
> > >
> > > -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev)
> > > +static inline int vfio_device_set_noiommu(struct vfio_device *device)
> > > {
> > > - return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> > > -vdev->group->type == VFIO_NO_IOMMU;
> > > + device->noiommu = IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> > > + device->group->type == VFIO_NO_IOMMU;
> > > + return 0;
> >
> > Just void. this can't fail.
>
> Hmmm. Yes, before below commit, it cannot fail. Maybe this can be
> converted to int later.
>
> https://lore.kernel.org/kvm/20230426150321.454465-22-yi.l@intel.com/T/#u
AFAICT with the comments on the next patch, this change is not at all
justified within this series and should be dropped. Thanks,
Alex
Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
On Thu, 27 Apr 2023 06:59:17 +
"Liu, Yi L" wrote:
> > From: Tian, Kevin
> > Sent: Thursday, April 27, 2023 2:39 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, April 26, 2023 10:54 PM
> > > @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
> > > unsigned long iova,
> > > {
> > > struct vfio_device *vdev = data;
> > >
> > > - if (vdev->ops->dma_unmap)
> > > + /* noiommu devices cannot do map/unmap */
> > > + if (vdev->noiommu && vdev->ops->dma_unmap)
> > > vdev->ops->dma_unmap(vdev, iova, length);
> >
> > Is it necessary? All mdev devices implementing @dma_unmap won't
> > set noiommu flag.
>
> Hmmm. Yes, and all the devices set noiommu is not implementing @dma_unmap
> as far as I see. Maybe this noiommu check can be removed.
Not to mention that the polarity of the noiommu test is backwards here!
This also seems to be the only performance path where noiommu is tested
and therefore I believe the only actual justification of the previous
patch.
> > Instead in the future if we allow noiommu userspace to pin pages
> > we'd need similar logic too.
>
> I'm not quite sure about it so far. For mdev devices, the device driver
> may use vfio_pin_pages/vfio_dma_rw () to pin page. Hence such drivers
> need to listen to dma_unmap() event. But for noiommu users, does the
> device driver also participate in the page pin? At least for vfio-pci driver,
> it does not, or maybe it will in the future when enabling noiommu
> userspace to pin pages. It looks to me such userspace should order
> the DMA before calling ioctl to unpin page instead of letting device
> driver listen to unmap.
Whoa, noiommu is inherently unsafe an only meant to expose the vfio
device interface for userspace drivers that are going to do unsafe
things regardless. Enabling noiommu to work with mdev, pin pages, or
anything else should not be on our agenda. Userspaces relying on niommu
get the minimum viable interface and must impose a minuscule
incremental maintenance burden. The only reason we're spending so much
effort on it here is to make iommufd noiommu support equivalent to
group/container noiommu support. We should stop at that. Thanks,
Alex
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
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
[Intel-gfx] ✓ Fi.CI.BAT: success for mtl: add support for pmdemand (rev4)
== Series Details ==
Series: mtl: add support for pmdemand (rev4)
URL : https://patchwork.freedesktop.org/series/116949/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116949v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/index.html
Participating hosts (38 -> 36)
--
Missing(2): bat-mtlp-8 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116949v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][1] -> [FAIL][2] ([i915#7932]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [FAIL][3] ([i915#7916]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][5] ([i915#7920]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/bat-mtlp-6/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: [FAIL][7] ([i915#6997]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Warnings
* igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g: [ABORT][9] -> [ABORT][10] ([i915#8397])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397
Build changes
-
* Linux: CI_DRM_13071 -> Patchwork_116949v4
CI-20190529: 20190529
CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116949v4: b9458e7075652669ec0e04abe039a5ed001701fe @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
72ff61a5f452 drm/i915/display: provision to suppress drm_warn in
intel_get_crtc_new_encoder
c5df808bc840 drm/i915/mtl: Add support for PM DEMAND
ca6f9668a8ee drm/i915/mtl: find best QGV point and configure sagv
b5d9b3816438 drm/i915: modify max_bw to return index to intel_bw_info
80e5807febdc drm/i915: extract intel_bw_check_qgv_points()
1f73baa912be drm/i915: store the peak bw per QGV point
9866a15853f6 drm/i915: update the QGV point frequency calculations
1cff5f944d75 drm/i915: fix the derating percentage for MTL
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v4/index.html
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
(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).
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for mtl: add support for pmdemand (rev4)
== Series Details == Series: mtl: add support for pmdemand (rev4) URL : https://patchwork.freedesktop.org/series/116949/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mtl: add support for pmdemand (rev4)
== Series Details == Series: mtl: add support for pmdemand (rev4) URL : https://patchwork.freedesktop.org/series/116949/ State : warning == Summary == Error: dim checkpatch failed 874300201d54 drm/i915: fix the derating percentage for MTL 0351498e12a8 drm/i915: update the QGV point frequency calculations a19eee5cbb59 drm/i915: store the peak bw per QGV point 7165b8529aef drm/i915: extract intel_bw_check_qgv_points() 08a7346302d0 drm/i915: modify max_bw to return index to intel_bw_info 0f2930d76473 drm/i915/mtl: find best QGV point and configure sagv 5bd2838f8dfc drm/i915/mtl: Add support for PM DEMAND Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:97: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #97: FILE: drivers/gpu/drm/i915/display/intel_display_core.h:350: + struct mutex lock; -:170: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #170: new file mode 100644 -:281: CHECK:LINE_SPACING: Please don't use multiple blank lines #281: FILE: drivers/gpu/drm/i915/display/intel_pmdemand.c:107: + + -:734: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #734: FILE: drivers/gpu/drm/i915/i915_reg.h:4519: +#define XELPDP_PMDEMAND_QCLK_GV_BW(x) REG_FIELD_PREP(XELPDP_PMDEMAND_QCLK_GV_BW_MASK, x) -:736: WARNING:LONG_LINE: line length of 109 exceeds 100 columns #736: FILE: drivers/gpu/drm/i915/i915_reg.h:4521: +#define XELPDP_PMDEMAND_VOLTAGE_INDEX(x) REG_FIELD_PREP(XELPDP_PMDEMAND_VOLTAGE_INDEX_MASK, x) -:738: WARNING:LONG_LINE: line length of 109 exceeds 100 columns #738: FILE: drivers/gpu/drm/i915/i915_reg.h:4523: +#define XELPDP_PMDEMAND_QCLK_GV_INDEX(x) REG_FIELD_PREP(XELPDP_PMDEMAND_QCLK_GV_INDEX_MASK, x) -:740: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #740: FILE: drivers/gpu/drm/i915/i915_reg.h:4525: +#define XELPDP_PMDEMAND_PIPES(x) REG_FIELD_PREP(XELPDP_PMDEMAND_PIPES_MASK, x) -:742: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #742: FILE: drivers/gpu/drm/i915/i915_reg.h:4527: +#define XELPDP_PMDEMAND_DBUFS(x) REG_FIELD_PREP(XELPDP_PMDEMAND_DBUFS_MASK, x) -:748: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #748: FILE: drivers/gpu/drm/i915/i915_reg.h:4533: +#define XELPDP_PMDEMAND_CDCLK_FREQ(x) REG_FIELD_PREP(XELPDP_PMDEMAND_CDCLK_FREQ_MASK, x) -:750: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #750: FILE: drivers/gpu/drm/i915/i915_reg.h:4535: +#define XELPDP_PMDEMAND_DDICLK_FREQ(x) REG_FIELD_PREP(XELPDP_PMDEMAND_DDICLK_FREQ_MASK, x) -:752: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #752: FILE: drivers/gpu/drm/i915/i915_reg.h:4537: +#define XELPDP_PMDEMAND_SCALERS(x) REG_FIELD_PREP(XELPDP_PMDEMAND_SCALERS_MASK, x) total: 0 errors, 9 warnings, 2 checks, 680 lines checked 0f22628358d0 drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder
[Intel-gfx] ✗ Fi.CI.BAT: failure for Introduce sink_format and other fixes
== Series Details ==
Series: Introduce sink_format and other fixes
URL : https://patchwork.freedesktop.org/series/117056/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13071 -> Patchwork_117056v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117056v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117056v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/index.html
Participating hosts (38 -> 36)
--
Missing(2): bat-mtlp-8 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117056v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@workarounds:
- bat-adlm-1: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_117056v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [PASS][3] -> [FAIL][4] ([i915#7932])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [FAIL][5] ([i915#7916]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][7] ([i915#7920]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html
Warnings
* igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g: [ABORT][9] -> [ABORT][10] ([i915#8397])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397
Build changes
-
* Linux: CI_DRM_13071 -> Patchwork_117056v1
CI-20190529: 20190529
CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_117056v1: b9458e7075652669ec0e04abe039a5ed001701fe @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
29ccc1a911bb drm/i915/dp: Rearrange check for illegal mode and comments in
mode_valid
902e2b51e8ab drm/i915/dp: Add helper to get sink_format
51801e2939b5 drm/i915/display: Use sink_format instead of ycbcr420_output flag
2525d109de1b drm/i915/dp: Configure PCON for conversion of output_format to
YCbCr444
4a2e03229361 drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state
sink_format
a782b8fdbafa drm/i915/display: Add new member to configure PCON color conversion
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117056v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce sink_format and other fixes
== Series Details == Series: Introduce sink_format and other fixes URL : https://patchwork.freedesktop.org/series/117056/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
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 > > > - Jordan still wants the extension query > Yes, I do, but so far it doesn't appear that any kernel devs think > it's a reasonable request. > > As I read through your emails about this pxp situation, it seems like > a separate issue. When I encountered the 8s delay, it was on MTL, and > apparently some firmware issue meant it was never going to work. So, I > thought this was a case of it either being supported, or never being > supported. alan: this might be because of an older patch version in internal tree - which I'm trying hard to fix to follow latest upstream - but keep getting delays and conflicts - but thats unrelated to this upstream POV > Now I'm seeing from your emails that in some cases it might be > supported, but just not ready yet. In that case a status which is > directly tied to pxp seems valuable. (But, yuck, how did we get into > this situation? :) alan: thanks for the go ahead on this PXP's uniquely different-issue (and i must agree, 'yukcy' situation). How did we get here? we are trying to debug this - its interesting to see the same kernel with the same configs much faster on ADL vs MTL but the MTL case is suffering because the mei-heci-parent driver is getting loaded much later (which IS common to ADL) - this delayed parent driver is causing the delay on the gsc-proxy component MTL. From parent load to gsc-proxy bin+init is relatively fast (~few hundred milisecs). But I believe it seems to only be happenning on select OS stacks (our ChromeOS fork is definitely seeing this). > 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:snip
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix error capture for virtual engines
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.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2)
== Series Details ==
Series: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()
(rev2)
URL : https://patchwork.freedesktop.org/series/116947/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116947v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/index.html
Participating hosts (38 -> 36)
--
Missing(2): bat-mtlp-8 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116947v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@slpc:
- bat-rplp-1: [PASS][1] -> [FAIL][2] ([i915#7913])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rplp-1/igt@i915_selftest@l...@slpc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rplp-1/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][3] ([i915#7828])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][4] ([i915#1845])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][5] ([i915#6687]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [FAIL][7] ([i915#7916]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][9] ([i915#7920]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/bat-mtlp-6/igt@i915_selftest@l...@requests.html
Warnings
* igt@core_hotunplug@unbind-rebind:
- fi-kbl-8809g: [ABORT][11] -> [ABORT][12] ([i915#8397])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#8397]: https://gitlab.freedesktop.org/drm/intel/issues/8397
Build changes
-
* Linux: CI_DRM_13071 -> Patchwork_116947v2
CI-20190529: 20190529
CI_DRM_13071: b9458e7075652669ec0e04abe039a5ed001701fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7273: f40ef4b058466219968b7792d22ff0648b82396b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116947v2: b9458e7075652669ec0e04abe039a5ed001701fe @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
b5d23433d39e drm/i915/dsi: Use unconditional msleep() instead of
intel_dsi_msleep()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116947v2/index.html
Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
> -Original Message-
> From: Kahola, Mika
> Sent: Wednesday, April 26, 2023 4:43 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
>
> > -Original Message-
> > From: Sripada, Radhakrishna
> > Sent: Monday, April 24, 2023 11:56 PM
> > To: Kahola, Mika
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
> >
> > On Thu, Apr 20, 2023 at 03:40:39PM +0300, Mika Kahola wrote:
> > > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > > The PLL settings are based on table, not for algorithmic alternative.
> > > For DP 1.4 only MPLLB is in use.
> > >
> > > Once register settings are done, we read back C20 HW state.
> > >
> > > BSpec: 64568
> > >
> > > Signed-off-by: Mika Kahola
> > > Signed-off-by: Arun R Murthy
> > > Signed-off-by: Ankit Nautiyal
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 623 +-
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.h | 8 +-
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> > > .../drm/i915/display/intel_display_types.h| 1 +
> > > drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.h | 1 +
> > > 6 files changed, 628 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index dd96bf5e179e..61428c5145e5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -11,6 +11,7 @@
> > > #include "intel_de.h"
> > > #include "intel_display_types.h"
> > > #include "intel_dp.h"
> > > +#include "intel_hdmi.h"
> > > #include "intel_panel.h"
> > > #include "intel_psr.h"
> > > #include "intel_tc.h"
> > > @@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct
> > drm_i915_private *i915, enum port port,
> > > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > > 1); }
> > >
> > > +static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port
> > port,
> > > +int lane, u16 addr)
> > > +{
> > > + u16 val;
> > > +
> > > + assert_dc_off(i915);
> > > +
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >> 8,
> > 0);
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff,
> > > +1);
> > > +
> > > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > > + val <<= 8;
> > > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > > +
> > > + return val;
> > > +}
> > > +
> > > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port
> > > port,
> > > int lane, u16 addr, u8 clear, u8 set, bool
> > > committed) {
> > @@
> > > -659,6 +677,199 @@ static const struct intel_c10pll_state * const
> > mtl_c10_edp_tables[] = {
> > > NULL,
> > > };
> > >
> > > +/* C20 basic DP 1.4 tables */
> > > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > > + .link_bit_rate = 162000,
> > > + .clock = 162000,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x5800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > + 0x0005, /* cmn cfg1 */
> > > + 0x, /* cmn cfg2 */
> > > + 0x, /* cmn cfg3 */
> > > + },
> > > + .mpllb = { 0x50a8, /* mpllb cfg0 */
> > > + 0x2120, /* mpllb cfg1 */
> > > + 0xcd9a, /* mpllb cfg2 */
> > > + 0xbfc1, /* mpllb cfg3 */
> > > + 0x5ab8, /* mpllb cfg4 */
> > > + 0x4c34, /* mpllb cfg5 */
> > > + 0x2000, /* mpllb cfg6 */
> > > + 0x0001, /* mpllb cfg7 */
> > > + 0x6000, /* mpllb cfg8 */
> > > + 0x, /* mpllb cfg9 */
> > > + 0x, /* mpllb cfg10 */
> > > + },
> > > +};
> > > +
> > > +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> > > + .link_bit_rate = 27,
> > > + .clock = 27,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x4800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > + 0x0005, /* cmn cfg1 */
> > > + 0x, /* cmn cfg2 */
> > > + 0x, /* cmn cfg3 */
> > > + },
> > > + .mpllb = { 0x308c, /* mpllb cfg0 */
> > > + 0x2110, /* mpllb cfg1 */
> > > + 0xcc9c, /* mpllb cfg2 */
> > > + 0xbfc1, /* mpllb cfg3 */
> > > + 0x489a, /* mpllb cfg4 */
> > This should be 0x4b9a ^ for mpllb cfg4 according to the consolidated table.
> Yes. Perhaps this has changed since the time of writing.
>
> >
> > > + 0x3f81, /* mpllb cfg5 */
> > > + 0x2000, /* mpllb cfg6 */
> > > +
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915_pm_freq_api: Add some basic SLPC igt tests
On Thu, 27 Apr 2023 09:24:58 -0700, Kamil Konieczny wrote: > > Hi Ashutosh, > > On 2023-04-26 at 13:40:28 -0700, Dixit, Ashutosh wrote: > > On Tue, 25 Apr 2023 09:24:04 -0700, Vinay Belgaumkar wrote: > > > > > > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c > > > new file mode 100644 > > > index ..17adacbc > > > --- /dev/null > > > +++ b/tests/i915/i915_pm_freq_api.c > > > @@ -0,0 +1,153 @@ > > > +// SPDX-License-Identifier: MIT > > > +/* > > > + * Copyright © 2023 Intel Corporation > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include "drmtest.h" > > > > The series is merged but before merging I removed all the #include's above, > > they are not needed. > > Please do not do this, at least send it to trybot and look at > GitLab.Pipeline status. There are platforms where compilation > failed due to missing fcntl.h, see > https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/137 > > It is fixed now with > https://patchwork.freedesktop.org/series/117047/ Hi Kamil, agreed, sorry about that. Lesson learnt. Thanks for fixing it quickly. Ashutosh
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915_pm_freq_api: Add some basic SLPC igt tests
Hi Ashutosh, On 2023-04-26 at 13:40:28 -0700, Dixit, Ashutosh wrote: > On Tue, 25 Apr 2023 09:24:04 -0700, Vinay Belgaumkar wrote: > > > > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c > > new file mode 100644 > > index ..17adacbc > > --- /dev/null > > +++ b/tests/i915/i915_pm_freq_api.c > > @@ -0,0 +1,153 @@ > > +// SPDX-License-Identifier: MIT > > +/* > > + * Copyright © 2023 Intel Corporation > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "drmtest.h" > > The series is merged but before merging I removed all the #include's above, > they are not needed. Please do not do this, at least send it to trybot and look at GitLab.Pipeline status. There are platforms where compilation failed due to missing fcntl.h, see https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/137 It is fixed now with https://patchwork.freedesktop.org/series/117047/ Regards, Kamil > > > +#include "i915/gem.h" > > +#include "igt_sysfs.h" > > +#include "igt.h" > > Thanks. > -- > Ashutosh
Re: [Intel-gfx] [PATCH 12/13] drm/i915/mtl: Pin assignment for TypeC
On Thu, Apr 20, 2023 at 03:40:49PM +0300, Mika Kahola wrote:
> From: Anusha Srivatsa
>
> Unlike previous platforms that used PORT_TX_DFLEXDPSP
> for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
> from which the max_lanes has to be calculated.
>
> Bspec: 50235, 65380
>
Reviewed-by: Matt Atwood
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Jose Roberto de Souza
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 28 +
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index b192265a3d78..4fca711a58bc 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -16,6 +16,10 @@
> #include "intel_mg_phy_regs.h"
> #include "intel_tc.h"
>
> +#define DP_PIN_ASSIGNMENT_C 0x3
> +#define DP_PIN_ASSIGNMENT_D 0x4
> +#define DP_PIN_ASSIGNMENT_E 0x5
> +
> enum tc_port_mode {
> TC_PORT_DISCONNECTED,
> TC_PORT_TBT_ALT,
> @@ -281,6 +285,27 @@ u32 intel_tc_port_get_pin_assignment_mask(struct
> intel_digital_port *dig_port)
> DP_PIN_ASSIGNMENT_SHIFT(tc->phy_fia_idx);
> }
>
> +static int mtl_tc_port_get_pin_assignment_mask(struct intel_digital_port
> *dig_port)
> +{
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + intel_wakeref_t wakeref;
> + u32 pin_mask;
> +
> + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> + pin_mask = intel_tc_port_get_pin_assignment_mask(dig_port);
> +
> + switch (pin_mask) {
> + default:
> + MISSING_CASE(pin_mask);
> + fallthrough;
> + case DP_PIN_ASSIGNMENT_D:
> + return 2;
> + case DP_PIN_ASSIGNMENT_C:
> + case DP_PIN_ASSIGNMENT_E:
> + return 4;
> + }
> +}
> +
> int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> @@ -294,6 +319,9 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
>
> assert_tc_cold_blocked(tc);
>
> + if (DISPLAY_VER(i915) >= 14)
> + return mtl_tc_port_get_pin_assignment_mask(dig_port);
> +
> lane_mask = 0;
> with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> lane_mask = intel_tc_port_get_lane_mask(dig_port);
> --
> 2.34.1
>
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Expose RPS thresholds in sysfs
== Series Details ==
Series: Expose RPS thresholds in sysfs
URL : https://patchwork.freedesktop.org/series/117054/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/gpu/drm/i915/gt/intel_rps.o
In file included from ./include/linux/interrupt.h:6,
from ./include/drm/drm_util.h:35,
from ./drivers/gpu/drm/i915/display/intel_display.h:28,
from drivers/gpu/drm/i915/gt/intel_rps.c:10:
drivers/gpu/drm/i915/gt/intel_rps.c: In function ‘intel_rps_enable’:
drivers/gpu/drm/i915/gt/intel_rps.c:1562:14: error: ‘struct ’ has no
member named ‘threshold_up’
1562 |rps->power.threshold_up,
| ^
./include/linux/kernel.h:337:40: note: in definition of macro
‘__trace_printk_check_format’
337 | trace_printk_check_format(fmt, ##args); \
|^~~~
./include/linux/kernel.h:374:3: note: in expansion of macro ‘do_trace_printk’
374 | do_trace_printk(fmt, ##__VA_ARGS__); \
| ^~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro
‘trace_printk’
119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
|^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
18 | GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev), \
| ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro
‘GT_TRACE’
1557 | GT_TRACE(rps_to_gt(rps),
| ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1563:14: error: ‘struct ’ has no
member named ‘threshold_down’
1563 |rps->power.threshold_down);
| ^
./include/linux/kernel.h:337:40: note: in definition of macro
‘__trace_printk_check_format’
337 | trace_printk_check_format(fmt, ##args); \
|^~~~
./include/linux/kernel.h:374:3: note: in expansion of macro ‘do_trace_printk’
374 | do_trace_printk(fmt, ##__VA_ARGS__); \
| ^~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro
‘trace_printk’
119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
|^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
18 | GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev), \
| ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro
‘GT_TRACE’
1557 | GT_TRACE(rps_to_gt(rps),
| ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1562:14: error: ‘struct ’ has no
member named ‘threshold_up’
1562 |rps->power.threshold_up,
| ^
./include/linux/kernel.h:388:50: note: in definition of macro ‘do_trace_printk’
388 | __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
| ^~~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro
‘trace_printk’
119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
|^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
18 | GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev), \
| ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro
‘GT_TRACE’
1557 | GT_TRACE(rps_to_gt(rps),
| ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1563:14: error: ‘struct ’ has no
member named ‘threshold_down’
1563 |rps->power.threshold_down);
| ^
./include/linux/kernel.h:388:50: note: in definition of macro ‘do_trace_printk’
388 | __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
| ^~~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro
‘trace_printk’
119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
|^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
18 | GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev), \
| ^
drivers/gpu/drm/i915/gt/intel_rps.c:1557:2: note: in expansion of macro
‘GT_TRACE’
1557 | GT_TRACE(rps_to_gt(rps),
| ^~~~
drivers/gpu/drm/i915/gt/intel_rps.c:1562:14: error: ‘struct ’ has no
member named ‘threshold_up’
1562 |rps->power.threshold_up,
| ^
./include/linux/kernel.h:390:36: note: in definition of macro ‘do_trace_printk’
390 | __trace_printk(_THIS_IP_, fmt, ##args); \
|^~~~
./drivers/gpu/drm/i915/i915_gem.h:119:24: note: in expansion of macro
‘trace_printk’
119 | #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
|^~~~
drivers/gpu/drm/i915/gt/intel_gt.h:18:2: note: in expansion of macro ‘GEM_TRACE’
18 | GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev), \
|
Re: [Intel-gfx] [PATCH 11/13] drm/i915/mtl: TypeC HPD live status query
On Thu, Apr 20, 2023 at 03:40:48PM +0300, Mika Kahola wrote:
> From: Imre Deak
>
> The HPD live status for MTL has to be read from different set of
> registers. MTL deserves a new function for this purpose
> and cannot reuse the existing HPD live status detection
>
Reviewed-by: Matt Atwood
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Imre Deak
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 30 -
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 951b12ac51dc..b192265a3d78 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -886,6 +886,34 @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> * XELPDP TC PHY handlers
> * --
> */
> +static u32 xelpdp_tc_phy_hpd_live_status(struct intel_tc_port *tc)
> +{
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + struct intel_digital_port *dig_port = tc->dig_port;
> + enum hpd_pin hpd_pin = dig_port->base.hpd_pin;
> + u32 pica_isr_bits = i915->display.hotplug.hpd[hpd_pin];
> + u32 pch_isr_bit = i915->display.hotplug.pch_hpd[hpd_pin];
> + intel_wakeref_t wakeref;
> + u32 pica_isr;
> + u32 pch_isr;
> + u32 mask = 0;
> +
> + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref) {
> + pica_isr = intel_de_read(i915, PICAINTERRUPT_ISR);
> + pch_isr = intel_de_read(i915, SDEISR);
> + }
> +
> + if (pica_isr & (pica_isr_bits & XELPDP_DP_ALT_HOTPLUG_MASK))
> + mask |= BIT(TC_PORT_DP_ALT);
> + if (pica_isr & (pica_isr_bits & XELPDP_TBT_HOTPLUG_MASK))
> + mask |= BIT(TC_PORT_TBT_ALT);
> +
> + if (tc->legacy_port && (pch_isr & pch_isr_bit))
> + mask |= BIT(TC_PORT_LEGACY);
> +
> + return mask;
> +}
> +
> static bool
> xelpdp_tc_phy_tcss_power_is_enabled(struct intel_tc_port *tc)
> {
> @@ -1039,7 +1067,7 @@ static void xelpdp_tc_phy_disconnect(struct
> intel_tc_port *tc)
>
> static const struct intel_tc_phy_ops xelpdp_tc_phy_ops = {
> .cold_off_domain = tgl_tc_phy_cold_off_domain,
> - .hpd_live_status = adlp_tc_phy_hpd_live_status,
> + .hpd_live_status = xelpdp_tc_phy_hpd_live_status,
> .is_ready = adlp_tc_phy_is_ready,
> .is_owned = xelpdp_tc_phy_is_owned,
> .get_hw_state = xelpdp_tc_phy_get_hw_state,
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 10/13] drm/i915/mtl: Power up TCSS
On Thu, Apr 20, 2023 at 03:40:47PM +0300, Mika Kahola wrote:
> Add register writes to enable powering up Type-C subsystem i.e. TCSS.
> For MeteorLake we need to request TCSS to power up and check the TCSS
> power state after 500 us.
>
> In addition, for PICA we need to set/clear the Type-C PHY ownnership
> bit when Type-C device is connected/disconnected.
>
Reviewed-by: Matt Atwood
> Signed-off-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 19 ++
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 4 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_tc.c | 199 ++-
> 5 files changed, 216 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index dc005e61..97d80adb921f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2884,6 +2884,25 @@ void intel_mtl_pll_disable(struct intel_encoder
> *encoder)
> intel_cx0pll_disable(encoder);
> }
>
> +enum icl_port_dpll_id
> +intel_mtl_port_pll_type(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + /*
> + * TODO: Determine the PLL type from the SW state, once MTL PLL
> + * handling is done via the standard shared DPLL framework.
> + */
> + u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
> + u32 clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
> +
> + if (clock == XELPDP_DDI_CLOCK_SELECT_MAXPCLK ||
> + clock == XELPDP_DDI_CLOCK_SELECT_DIV18CLK)
> + return ICL_PORT_DPLL_MG_PHY;
> + else
> + return ICL_PORT_DPLL_DEFAULT;
> +}
> +
> void intel_c10pll_state_verify(struct intel_atomic_state *state,
> struct intel_crtc_state *new_crtc_state)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> index c1b8f7980f69..f99809af257d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> @@ -16,12 +16,16 @@
> struct drm_i915_private;
> struct intel_encoder;
> struct intel_crtc_state;
> +enum icl_port_dpll_id;
> enum phy;
>
> bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy);
> void intel_mtl_pll_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state);
> void intel_mtl_pll_disable(struct intel_encoder *encoder);
> +enum icl_port_dpll_id
> +intel_mtl_port_pll_type(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state);
> void intel_c10pll_readout_hw_state(struct intel_encoder *encoder, struct
> intel_c10pll_state *pll_state);
> int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct
> intel_encoder *encoder);
> void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 8f0f858cde31..55f36d9d509c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4784,6 +4784,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> if (DISPLAY_VER(dev_priv) >= 14) {
> encoder->enable_clock = intel_mtl_pll_enable;
> encoder->disable_clock = intel_mtl_pll_disable;
> + encoder->port_pll_type = intel_mtl_port_pll_type;
> encoder->get_config = mtl_ddi_get_config;
> } else if (IS_DG2(dev_priv)) {
> encoder->enable_clock = intel_mpllb_enable;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1c264c17b6e4..e70bdf0e06f3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1757,7 +1757,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv,
> enum phy phy)
> if (IS_DG2(dev_priv))
> /* DG2's "TC1" output uses a SNPS PHY */
> return false;
> - else if (IS_ALDERLAKE_P(dev_priv))
> + else if (IS_ALDERLAKE_P(dev_priv) || IS_METEORLAKE(dev_priv))
> return phy >= PHY_F && phy <= PHY_I;
> else if (IS_TIGERLAKE(dev_priv))
> return phy >= PHY_D && phy <= PHY_I;
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 3b60995e9dfb..951b12ac51dc 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -5,6 +5,7 @@
>
> #include "i915_drv.h"
> #include "i915_reg.h"
>
Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation
> 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: [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers
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: [Intel-gfx] [PATCH 13/13] drm/i915/mtl: Enable TC ports
On 4/20/23 05:40, Mika Kahola wrote:
Finally, we can enable TC ports for Meteorlake.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e70bdf0e06f3..dc777c3b1b1a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7587,9 +7587,12 @@ void intel_setup_outputs(struct drm_i915_private
*dev_priv)
return;
if (IS_METEORLAKE(dev_priv)) {
- /* TODO: initialize TC ports as well */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
+ intel_ddi_init(dev_priv, PORT_TC1);
+ intel_ddi_init(dev_priv, PORT_TC2);
+ intel_ddi_init(dev_priv, PORT_TC3);
+ intel_ddi_init(dev_priv, PORT_TC4);
Reviewed-by: Clint Taylor
-Clint
} else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
Re: [Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations
On Thu, Apr 27, 2023 at 06:00:10PM +0300, Vinod Govindapillai wrote: > >From MTL onwwards, pcode locks the QGV point based on peak BW of > the intended QGV point passed by the driver. So the peak BW > calculation must match the value expected by the pcode. Update > the calculations as per the Bspec. > > Bspec: 64636 > > Signed-off-by: Vinod Govindapillai > --- > drivers/gpu/drm/i915/display/intel_bw.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c > b/drivers/gpu/drm/i915/display/intel_bw.c > index ab405c48ca3a..25ae4e5834d3 100644 > --- a/drivers/gpu/drm/i915/display/intel_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > @@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct > drm_i915_private *dev_priv, > val2 = intel_uncore_read(_priv->uncore, >MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); > dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); > - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); > + sp->dclk = (16667 * dclk + 500) / 1000; Don't hand roll rounding. > sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); > sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); > > -- > 2.34.1 -- Ville Syrjälä Intel
[Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND
From: Mika Kahola
Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).
Wa_14016740474 is added which applies to Xe_LPD+ display
v2: checkpatch warning fixes, simplify program pmdemand part
v3: update to dbufs and pipes values to pmdemand register(stan)
Removed the macro usage in update_pmdemand_values()
Bspec: 66451, 64636, 64602, 64603
Cc: Matt Atwood
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Gustavo Sousa
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Gustavo Sousa
Signed-off-by: Mika Kahola
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 7 +
.../gpu/drm/i915/display/intel_display_core.h | 6 +
.../drm/i915/display/intel_display_driver.c | 7 +
.../drm/i915/display/intel_display_power.c| 8 +
drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 +
drivers/gpu/drm/i915/i915_irq.c | 21 +-
drivers/gpu/drm/i915/i915_reg.h | 36 +-
9 files changed, 562 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..eb899fa86e51 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -281,7 +281,8 @@ i915-y += \
display/i9xx_wm.o \
display/skl_scaler.o \
display/skl_universal_plane.o \
- display/skl_watermark.o
+ display/skl_watermark.o \
+ display/intel_pmdemand.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
display/intel_opregion.o
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..f98e235fadc6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -99,6 +99,7 @@
#include "intel_pcode.h"
#include "intel_pipe_crc.h"
#include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
#include "intel_pps.h"
#include "intel_psr.h"
#include "intel_sdvo.h"
@@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
return ret;
}
+ ret = intel_pmdemand_atomic_check(state);
+ if (ret)
+ goto fail;
+
ret = intel_atomic_check_crtcs(state);
if (ret)
goto fail;
@@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
}
intel_sagv_pre_plane_update(state);
+ intel_pmdemand_pre_plane_update(state);
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_verify_planes(state);
intel_sagv_post_plane_update(state);
+ intel_pmdemand_post_plane_update(state);
drm_atomic_helper_commit_hw_done(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 9f66d734edf6..9471a052aa57 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,12 @@ struct intel_display {
struct intel_global_obj obj;
} dbuf;
+ struct {
+ wait_queue_head_t waitqueue;
+ struct mutex lock;
+ struct intel_global_obj obj;
+ } pmdemand;
+
struct {
/*
* dkl.phy_lock protects against concurrent access of the
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 60ce10fc7205..79853d8c3240 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -47,6 +47,7 @@
#include "intel_opregion.h"
#include "intel_overlay.h"
#include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
#include "intel_pps.h"
#include "intel_quirks.h"
#include "intel_vga.h"
@@ -211,6 +212,8 @@ int intel_display_driver_probe_noirq(struct
drm_i915_private *i915)
if (ret < 0)
goto cleanup_vga;
+ intel_pmdemand_init(i915);
+
intel_power_domains_init_hw(i915, false);
if (!HAS_DISPLAY(i915))
@@ -240,6 +243,10 @@ int intel_display_driver_probe_noirq(struct
drm_i915_private
[Intel-gfx] [PATCH v3 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder
While configuring pmdemand parameters, there could be
intel_get_crtc_new_encoder call where encoders could be 0. To avoid
invoking drm_warn in such cases, use a parameter to indicate drm_warn
should be suppressed.
v2: checkpatch warning fixes
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
drivers/gpu/drm/i915/display/intel_display.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dpll.c| 8
drivers/gpu/drm/i915/display/intel_pch_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_pmdemand.c| 2 +-
drivers/gpu/drm/i915/display/intel_snps_phy.c| 2 +-
7 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 83180074b512..e91fdd5a26c3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1879,7 +1879,7 @@ void intel_c10pll_state_verify(struct intel_atomic_state
*state,
!intel_crtc_needs_fastset(new_crtc_state))
return;
- encoder = intel_get_crtc_new_encoder(state, new_crtc_state);
+ encoder = intel_get_crtc_new_encoder(state, new_crtc_state, true);
phy = intel_port_to_phy(i915, encoder->port);
if (!intel_is_c10phy(i915, phy))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f98e235fadc6..4cadda4acce4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -763,7 +763,8 @@ bool intel_has_pending_fb_unpin(struct drm_i915_private
*dev_priv)
*/
struct intel_encoder *
intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
- const struct intel_crtc_state *crtc_state)
+ const struct intel_crtc_state *crtc_state,
+ bool warn)
{
const struct drm_connector_state *connector_state;
const struct drm_connector *connector;
@@ -782,9 +783,10 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state
*state,
num_encoders++;
}
- drm_WARN(state->base.dev, num_encoders != 1,
-"%d encoders for pipe %c\n",
-num_encoders, pipe_name(master_crtc->pipe));
+ if (warn)
+ drm_WARN(state->base.dev, num_encoders != 1,
+"%d encoders for pipe %c\n",
+num_encoders, pipe_name(master_crtc->pipe));
return encoder;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba..4620ed991ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -501,7 +501,8 @@ bool intel_plane_uses_fence(const struct intel_plane_state
*plane_state);
struct intel_encoder *
intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
- const struct intel_crtc_state *crtc_state);
+ const struct intel_crtc_state *crtc_state,
+ bool warn);
void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane);
void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index a9fbef0fa817..9d30f273130e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -940,7 +940,7 @@ static int hsw_crtc_compute_clock(struct intel_atomic_state
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
if (DISPLAY_VER(dev_priv) < 11 &&
@@ -969,7 +969,7 @@ static int hsw_crtc_get_shared_dpll(struct
intel_atomic_state *state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
@@ -984,7 +984,7 @@ static int dg2_crtc_compute_clock(struct intel_atomic_state
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: find best QGV point and configure sagv
>From MTL onwards, we need to find the best QGV point based on
the required data rate and pass the peak BW of that point to
the punit to lock the corresponding QGV point.
Bspec: 64636
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 87 -
drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index a7f501131bb6..70fa469c3c20 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,85 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
}
+static int mtl_find_qgv_points(struct drm_i915_private *i915,
+ unsigned int data_rate,
+ unsigned int num_active_planes,
+ const struct intel_bw_state *old_bw_state,
+ struct intel_bw_state *new_bw_state)
+{
+ unsigned int best_rate = UINT_MAX;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ unsigned int qgv_peak_bw = 0;
+ int i;
+ int ret;
+
+ ret = intel_atomic_lock_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+
+ /*
+* If SAGV cannot be enabled, disable the pcode SAGV by passing all 1's
+* for qgv peak bw in PM Demand request. So assign UINT_MAX if SAGV is
+* not enabled. PM Demand code will clamp the value for the register
+*/
+ if (!intel_can_enable_sagv(i915, new_bw_state)) {
+ new_bw_state->qgv_point_peakbw = UINT_MAX;
+ drm_dbg_kms(>drm, "No SAGV, use UINT_MAX as peak bw.");
+ goto out;
+ }
+
+ /*
+* Find the best QGV point by comparing the data_rate with max data rate
+* offered per plane group
+*/
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int bw_index =
+ tgl_max_bw_index(i915, num_active_planes, i);
+ unsigned int max_data_rate;
+
+ if (bw_index > ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[bw_index].deratedbw[i];
+
+ if (max_data_rate < data_rate)
+ continue;
+
+ if (max_data_rate - data_rate < best_rate) {
+ best_rate = max_data_rate - data_rate;
+ qgv_peak_bw = i915->display.bw.max[bw_index].peakbw[i];
+ }
+
+ drm_dbg_kms(>drm, "QGV point %d: max bw %d required %d
qgv_peak_bw: %d\n",
+ i, max_data_rate, data_rate, qgv_peak_bw);
+ }
+
+ drm_dbg_kms(>drm, "Matching peaks QGV bw: %d for required data
rate: %d\n",
+ qgv_peak_bw, data_rate);
+
+ /*
+* The display configuration cannot be supported if no QGV point
+* satisfying the require data rate is found
+*/
+ if (qgv_peak_bw == 0) {
+ drm_dbg_kms(>drm, "No QGV points for bw %d for display
configuration(%d active planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ /* MTL PM DEMAND expects QGV BW parameter in multiples of 100 mbps */
+ new_bw_state->qgv_point_peakbw = qgv_peak_bw / 100;
+
+out:
+ if (new_bw_state->qgv_point_peakbw != old_bw_state->qgv_point_peakbw) {
+ ret = intel_atomic_serialize_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int icl_find_qgv_points(struct drm_i915_private *i915,
unsigned int data_rate,
unsigned int num_active_planes,
@@ -927,8 +1006,12 @@ static int intel_bw_check_qgv_points(struct
drm_i915_private *i915,
data_rate = DIV_ROUND_UP(data_rate, 1000);
- return icl_find_qgv_points(i915, data_rate, num_active_planes,
- old_bw_state, new_bw_state);
+ if (DISPLAY_VER(i915) >= 14)
+ return mtl_find_qgv_points(i915, data_rate, num_active_planes,
+ old_bw_state, new_bw_state);
+ else
+ return icl_find_qgv_points(i915, data_rate, num_active_planes,
+ old_bw_state, new_bw_state);
}
static bool intel_bw_state_changed(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index f20292143745..fc32f1eace85 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -34,6 +34,12 @@ struct intel_bw_state {
/* bitmask of active pipes */
[Intel-gfx] [PATCH v3 5/8] drm/i915: modify max_bw to return index to intel_bw_info
MTL uses the peak BW of a QGV point to lock the required QGV
point instead of the QGV index. Instead of passing the deratedbw
of the selected bw_info, return the index to the selected
bw_info so that either deratedbw or peakbw can be used based on
the platform.
v2: use idx to store index returned by max_bw_index functions
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index a3b8512ebe8a..a7f501131bb6 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -592,8 +592,8 @@ static void dg2_get_bw_info(struct drm_i915_private *i915)
i915->display.sagv.status = I915_SAGV_NOT_CONTROLLED;
}
-static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
- int num_planes, int qgv_point)
+static unsigned int icl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
{
int i;
@@ -614,14 +614,14 @@ static unsigned int icl_max_bw(struct drm_i915_private
*dev_priv,
return UINT_MAX;
if (num_planes >= bi->num_planes)
- return bi->deratedbw[qgv_point];
+ return i;
}
return 0;
}
-static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
- int num_planes, int qgv_point)
+static unsigned int tgl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
{
int i;
@@ -642,10 +642,10 @@ static unsigned int tgl_max_bw(struct drm_i915_private
*dev_priv,
return UINT_MAX;
if (num_planes <= bi->num_planes)
- return bi->deratedbw[qgv_point];
+ return i;
}
- return dev_priv->display.bw.max[0].deratedbw[qgv_point];
+ return 0;
}
static unsigned int adl_psf_bw(struct drm_i915_private *dev_priv,
@@ -822,12 +822,19 @@ static int icl_find_qgv_points(struct drm_i915_private
*i915,
return ret;
for (i = 0; i < num_qgv_points; i++) {
+ unsigned int idx;
unsigned int max_data_rate;
if (DISPLAY_VER(i915) > 11)
- max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+ idx = tgl_max_bw_index(i915, num_active_planes, i);
else
- max_data_rate = icl_max_bw(i915, num_active_planes, i);
+ idx = icl_max_bw_index(i915, num_active_planes, i);
+
+ if (idx > ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[idx].deratedbw[i];
+
/*
* We need to know which qgv point gives us
* maximum bandwidth in order to disable SAGV
--
2.34.1
[Intel-gfx] [PATCH v3 4/8] drm/i915: extract intel_bw_check_qgv_points()
Extract intel_bw_check_qgv_points() from intel_bw_atomic_check
to facilitate future platform variations in handling SAGV
configurations.
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 235 +---
1 file changed, 130 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index f5b6cd7f83b8..a3b8512ebe8a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,128 @@ intel_atomic_get_bw_state(struct intel_atomic_state
*state)
return to_intel_bw_state(bw_state);
}
+static int icl_find_qgv_points(struct drm_i915_private *i915,
+ unsigned int data_rate,
+ unsigned int num_active_planes,
+ const struct intel_bw_state *old_bw_state,
+ struct intel_bw_state *new_bw_state)
+{
+ unsigned int max_bw_point = 0;
+ unsigned int max_bw = 0;
+ unsigned int num_psf_gv_points =
i915->display.bw.max[0].num_psf_gv_points;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ u16 psf_points = 0;
+ u16 qgv_points = 0;
+ int i;
+ int ret;
+
+ ret = intel_atomic_lock_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int max_data_rate;
+
+ if (DISPLAY_VER(i915) > 11)
+ max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+ else
+ max_data_rate = icl_max_bw(i915, num_active_planes, i);
+ /*
+* We need to know which qgv point gives us
+* maximum bandwidth in order to disable SAGV
+* if we find that we exceed SAGV block time
+* with watermarks. By that moment we already
+* have those, as it is calculated earlier in
+* intel_atomic_check,
+*/
+ if (max_data_rate > max_bw) {
+ max_bw_point = i;
+ max_bw = max_data_rate;
+ }
+ if (max_data_rate >= data_rate)
+ qgv_points |= BIT(i);
+
+ drm_dbg_kms(>drm, "QGV point %d: max bw %d required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ for (i = 0; i < num_psf_gv_points; i++) {
+ unsigned int max_data_rate = adl_psf_bw(i915, i);
+
+ if (max_data_rate >= data_rate)
+ psf_points |= BIT(i);
+
+ drm_dbg_kms(>drm, "PSF GV point %d: max bw %d"
+ " required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ /*
+* BSpec states that we always should have at least one allowed point
+* left, so if we couldn't - simply reject the configuration for obvious
+* reasons.
+*/
+ if (qgv_points == 0) {
+ drm_dbg_kms(>drm, "No QGV points provide sufficient
memory"
+ " bandwidth %d for display configuration(%d active
planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ if (num_psf_gv_points > 0 && psf_points == 0) {
+ drm_dbg_kms(>drm, "No PSF GV points provide sufficient
memory"
+ " bandwidth %d for display configuration(%d active
planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ /*
+* Leave only single point with highest bandwidth, if
+* we can't enable SAGV due to the increased memory latency it may
+* cause.
+*/
+ if (!intel_can_enable_sagv(i915, new_bw_state)) {
+ qgv_points = BIT(max_bw_point);
+ drm_dbg_kms(>drm, "No SAGV, using single QGV point %d\n",
+ max_bw_point);
+ }
+
+ /*
+* We store the ones which need to be masked as that is what PCode
+* actually accepts as a parameter.
+*/
+ new_bw_state->qgv_points_mask =
+ ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ ADLS_PCODE_REQ_PSF_PT(psf_points)) &
+ icl_qgv_points_mask(i915);
+
+ /*
+* If the actual mask had changed we need to make sure that
+* the commits are serialized(in case this is a nomodeset, nonblocking)
+*/
+ if (new_bw_state->qgv_points_mask != old_bw_state->qgv_points_mask) {
+ ret = intel_atomic_serialize_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int intel_bw_check_qgv_points(struct drm_i915_private *i915,
+
[Intel-gfx] [PATCH v3 3/8] drm/i915: store the peak bw per QGV point
In MTL onwards, pcode locks the GV point based on the peak BW
of a QGV point. So store the peak BW of all the QGV points.
Bspec: 64636
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 7 +--
drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 25ae4e5834d3..f5b6cd7f83b8 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -534,10 +534,13 @@ static int tgl_get_bw_info(struct drm_i915_private
*dev_priv, const struct intel
bi->deratedbw[j] = min(maxdebw,
bw * (100 - sa->derating) / 100);
+ bi->peakbw[j] = sp->dclk * num_channels *
+ qi.channel_width / 8;
drm_dbg_kms(_priv->drm,
- "BW%d / QGV %d: num_planes=%d
deratedbw=%u\n",
- i, j, bi->num_planes, bi->deratedbw[j]);
+ "BW%d / QGV %d: num_planes=%d deratedbw=%u
peakbw: %u\n",
+ i, j, bi->num_planes, bi->deratedbw[j],
+ bi->peakbw[j]);
}
for (j = 0; j < qi.num_psf_points; j++) {
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index e36f88a39b86..9f66d734edf6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -314,6 +314,8 @@ struct intel_display {
unsigned int deratedbw[I915_NUM_QGV_POINTS];
/* for each PSF GV point */
unsigned int psf_bw[I915_NUM_PSF_GV_POINTS];
+ /* Peak BW for each QGV point */
+ unsigned int peakbw[I915_NUM_QGV_POINTS];
u8 num_qgv_points;
u8 num_psf_gv_points;
u8 num_planes;
--
2.34.1
[Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations
>From MTL onwwards, pcode locks the QGV point based on peak BW of the intended QGV point passed by the driver. So the peak BW calculation must match the value expected by the pcode. Update the calculations as per the Bspec. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c index ab405c48ca3a..25ae4e5834d3 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv, val2 = intel_uncore_read(_priv->uncore, MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); + sp->dclk = (16667 * dclk + 500) / 1000; sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); -- 2.34.1
[Intel-gfx] [PATCH v3 0/8] mtl: add support for pmdemand
pmdemand support patches for MTL SAGV configuration support for MTL v2: added one missing patch in the previous version v3: chekcpatch warning fixes update index handling for the icl/tgl QGV point handling program pmdemand code simplified v4: update to debufs and pipe values pmdemand regiters removed the macro usage in update_pmdemand_values Mika Kahola (1): drm/i915/mtl: Add support for PM DEMAND Vinod Govindapillai (7): drm/i915: fix the derating percentage for MTL drm/i915: update the QGV point frequency calculations drm/i915: store the peak bw per QGV point drm/i915: extract intel_bw_check_qgv_points() drm/i915: modify max_bw to return index to intel_bw_info drm/i915/mtl: find best QGV point and configure sagv drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_bw.c | 350 +- drivers/gpu/drm/i915/display/intel_bw.h | 6 + drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 17 +- drivers/gpu/drm/i915/display/intel_display.h | 3 +- .../gpu/drm/i915/display/intel_display_core.h | 8 + .../drm/i915/display/intel_display_driver.c | 7 + .../drm/i915/display/intel_display_power.c| 8 + drivers/gpu/drm/i915/display/intel_dpll.c | 8 +- .../gpu/drm/i915/display/intel_pch_display.c | 2 +- drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++ drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 + drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 21 +- drivers/gpu/drm/i915/i915_reg.h | 36 +- 16 files changed, 819 insertions(+), 133 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h -- 2.34.1
[Intel-gfx] [PATCH v3 1/8] drm/i915: fix the derating percentage for MTL
Follow the values from bspec for the percentage overhead for
efficiency in MTL BW calculations.
Bspec: 64631
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 597d5816ad1b..ab405c48ca3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -379,7 +379,7 @@ static const struct intel_sa_info mtl_sa_info = {
.deburst = 32,
.deprogbwlimit = 38, /* GB/s */
.displayrtids = 256,
- .derating = 20,
+ .derating = 10,
};
static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct
intel_sa_info *sa)
--
2.34.1
Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation
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
[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: find best QGV point and configure sagv
>From MTL onwards, we need to find the best QGV point based on
the required data rate and pass the peak BW of that point to
the punit to lock the corresponding QGV point.
Bspec: 64636
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 87 -
drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index a7f501131bb6..70fa469c3c20 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,85 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
}
+static int mtl_find_qgv_points(struct drm_i915_private *i915,
+ unsigned int data_rate,
+ unsigned int num_active_planes,
+ const struct intel_bw_state *old_bw_state,
+ struct intel_bw_state *new_bw_state)
+{
+ unsigned int best_rate = UINT_MAX;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ unsigned int qgv_peak_bw = 0;
+ int i;
+ int ret;
+
+ ret = intel_atomic_lock_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+
+ /*
+* If SAGV cannot be enabled, disable the pcode SAGV by passing all 1's
+* for qgv peak bw in PM Demand request. So assign UINT_MAX if SAGV is
+* not enabled. PM Demand code will clamp the value for the register
+*/
+ if (!intel_can_enable_sagv(i915, new_bw_state)) {
+ new_bw_state->qgv_point_peakbw = UINT_MAX;
+ drm_dbg_kms(>drm, "No SAGV, use UINT_MAX as peak bw.");
+ goto out;
+ }
+
+ /*
+* Find the best QGV point by comparing the data_rate with max data rate
+* offered per plane group
+*/
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int bw_index =
+ tgl_max_bw_index(i915, num_active_planes, i);
+ unsigned int max_data_rate;
+
+ if (bw_index > ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[bw_index].deratedbw[i];
+
+ if (max_data_rate < data_rate)
+ continue;
+
+ if (max_data_rate - data_rate < best_rate) {
+ best_rate = max_data_rate - data_rate;
+ qgv_peak_bw = i915->display.bw.max[bw_index].peakbw[i];
+ }
+
+ drm_dbg_kms(>drm, "QGV point %d: max bw %d required %d
qgv_peak_bw: %d\n",
+ i, max_data_rate, data_rate, qgv_peak_bw);
+ }
+
+ drm_dbg_kms(>drm, "Matching peaks QGV bw: %d for required data
rate: %d\n",
+ qgv_peak_bw, data_rate);
+
+ /*
+* The display configuration cannot be supported if no QGV point
+* satisfying the require data rate is found
+*/
+ if (qgv_peak_bw == 0) {
+ drm_dbg_kms(>drm, "No QGV points for bw %d for display
configuration(%d active planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ /* MTL PM DEMAND expects QGV BW parameter in multiples of 100 mbps */
+ new_bw_state->qgv_point_peakbw = qgv_peak_bw / 100;
+
+out:
+ if (new_bw_state->qgv_point_peakbw != old_bw_state->qgv_point_peakbw) {
+ ret = intel_atomic_serialize_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int icl_find_qgv_points(struct drm_i915_private *i915,
unsigned int data_rate,
unsigned int num_active_planes,
@@ -927,8 +1006,12 @@ static int intel_bw_check_qgv_points(struct
drm_i915_private *i915,
data_rate = DIV_ROUND_UP(data_rate, 1000);
- return icl_find_qgv_points(i915, data_rate, num_active_planes,
- old_bw_state, new_bw_state);
+ if (DISPLAY_VER(i915) >= 14)
+ return mtl_find_qgv_points(i915, data_rate, num_active_planes,
+ old_bw_state, new_bw_state);
+ else
+ return icl_find_qgv_points(i915, data_rate, num_active_planes,
+ old_bw_state, new_bw_state);
}
static bool intel_bw_state_changed(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index f20292143745..fc32f1eace85 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -34,6 +34,12 @@ struct intel_bw_state {
/* bitmask of active pipes */
[Intel-gfx] [PATCH v3 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder
While configuring pmdemand parameters, there could be
intel_get_crtc_new_encoder call where encoders could be 0. To avoid
invoking drm_warn in such cases, use a parameter to indicate drm_warn
should be suppressed.
v2: checkpatch warning fixes
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
drivers/gpu/drm/i915/display/intel_display.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dpll.c| 8
drivers/gpu/drm/i915/display/intel_pch_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_pmdemand.c| 2 +-
drivers/gpu/drm/i915/display/intel_snps_phy.c| 2 +-
7 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 83180074b512..e91fdd5a26c3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1879,7 +1879,7 @@ void intel_c10pll_state_verify(struct intel_atomic_state
*state,
!intel_crtc_needs_fastset(new_crtc_state))
return;
- encoder = intel_get_crtc_new_encoder(state, new_crtc_state);
+ encoder = intel_get_crtc_new_encoder(state, new_crtc_state, true);
phy = intel_port_to_phy(i915, encoder->port);
if (!intel_is_c10phy(i915, phy))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f98e235fadc6..4cadda4acce4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -763,7 +763,8 @@ bool intel_has_pending_fb_unpin(struct drm_i915_private
*dev_priv)
*/
struct intel_encoder *
intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
- const struct intel_crtc_state *crtc_state)
+ const struct intel_crtc_state *crtc_state,
+ bool warn)
{
const struct drm_connector_state *connector_state;
const struct drm_connector *connector;
@@ -782,9 +783,10 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state
*state,
num_encoders++;
}
- drm_WARN(state->base.dev, num_encoders != 1,
-"%d encoders for pipe %c\n",
-num_encoders, pipe_name(master_crtc->pipe));
+ if (warn)
+ drm_WARN(state->base.dev, num_encoders != 1,
+"%d encoders for pipe %c\n",
+num_encoders, pipe_name(master_crtc->pipe));
return encoder;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba..4620ed991ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -501,7 +501,8 @@ bool intel_plane_uses_fence(const struct intel_plane_state
*plane_state);
struct intel_encoder *
intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
- const struct intel_crtc_state *crtc_state);
+ const struct intel_crtc_state *crtc_state,
+ bool warn);
void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane);
void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index a9fbef0fa817..9d30f273130e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -940,7 +940,7 @@ static int hsw_crtc_compute_clock(struct intel_atomic_state
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
if (DISPLAY_VER(dev_priv) < 11 &&
@@ -969,7 +969,7 @@ static int hsw_crtc_get_shared_dpll(struct
intel_atomic_state *state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
@@ -984,7 +984,7 @@ static int dg2_crtc_compute_clock(struct intel_atomic_state
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
[Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND
From: Mika Kahola
Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).
Wa_14016740474 is added which applies to Xe_LPD+ display
v2: checkpatch warning fixes, simplify program pmdemand part
v3: update to dbufs and pipes values to pmdemand register(stan)
Removed the macro usage in update_pmdemand_values()
Bspec: 66451, 64636, 64602, 64603
Cc: Matt Atwood
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Gustavo Sousa
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Gustavo Sousa
Signed-off-by: Mika Kahola
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 7 +
.../gpu/drm/i915/display/intel_display_core.h | 6 +
.../drm/i915/display/intel_display_driver.c | 7 +
.../drm/i915/display/intel_display_power.c| 8 +
drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 +
drivers/gpu/drm/i915/i915_irq.c | 21 +-
drivers/gpu/drm/i915/i915_reg.h | 36 +-
9 files changed, 562 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..eb899fa86e51 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -281,7 +281,8 @@ i915-y += \
display/i9xx_wm.o \
display/skl_scaler.o \
display/skl_universal_plane.o \
- display/skl_watermark.o
+ display/skl_watermark.o \
+ display/intel_pmdemand.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
display/intel_opregion.o
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..f98e235fadc6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -99,6 +99,7 @@
#include "intel_pcode.h"
#include "intel_pipe_crc.h"
#include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
#include "intel_pps.h"
#include "intel_psr.h"
#include "intel_sdvo.h"
@@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
return ret;
}
+ ret = intel_pmdemand_atomic_check(state);
+ if (ret)
+ goto fail;
+
ret = intel_atomic_check_crtcs(state);
if (ret)
goto fail;
@@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
}
intel_sagv_pre_plane_update(state);
+ intel_pmdemand_pre_plane_update(state);
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_verify_planes(state);
intel_sagv_post_plane_update(state);
+ intel_pmdemand_post_plane_update(state);
drm_atomic_helper_commit_hw_done(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 9f66d734edf6..9471a052aa57 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,12 @@ struct intel_display {
struct intel_global_obj obj;
} dbuf;
+ struct {
+ wait_queue_head_t waitqueue;
+ struct mutex lock;
+ struct intel_global_obj obj;
+ } pmdemand;
+
struct {
/*
* dkl.phy_lock protects against concurrent access of the
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 60ce10fc7205..79853d8c3240 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -47,6 +47,7 @@
#include "intel_opregion.h"
#include "intel_overlay.h"
#include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
#include "intel_pps.h"
#include "intel_quirks.h"
#include "intel_vga.h"
@@ -211,6 +212,8 @@ int intel_display_driver_probe_noirq(struct
drm_i915_private *i915)
if (ret < 0)
goto cleanup_vga;
+ intel_pmdemand_init(i915);
+
intel_power_domains_init_hw(i915, false);
if (!HAS_DISPLAY(i915))
@@ -240,6 +243,10 @@ int intel_display_driver_probe_noirq(struct
drm_i915_private
[Intel-gfx] [PATCH v3 4/8] drm/i915: extract intel_bw_check_qgv_points()
Extract intel_bw_check_qgv_points() from intel_bw_atomic_check
to facilitate future platform variations in handling SAGV
configurations.
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 235 +---
1 file changed, 130 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index f5b6cd7f83b8..a3b8512ebe8a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -802,6 +802,128 @@ intel_atomic_get_bw_state(struct intel_atomic_state
*state)
return to_intel_bw_state(bw_state);
}
+static int icl_find_qgv_points(struct drm_i915_private *i915,
+ unsigned int data_rate,
+ unsigned int num_active_planes,
+ const struct intel_bw_state *old_bw_state,
+ struct intel_bw_state *new_bw_state)
+{
+ unsigned int max_bw_point = 0;
+ unsigned int max_bw = 0;
+ unsigned int num_psf_gv_points =
i915->display.bw.max[0].num_psf_gv_points;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ u16 psf_points = 0;
+ u16 qgv_points = 0;
+ int i;
+ int ret;
+
+ ret = intel_atomic_lock_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int max_data_rate;
+
+ if (DISPLAY_VER(i915) > 11)
+ max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+ else
+ max_data_rate = icl_max_bw(i915, num_active_planes, i);
+ /*
+* We need to know which qgv point gives us
+* maximum bandwidth in order to disable SAGV
+* if we find that we exceed SAGV block time
+* with watermarks. By that moment we already
+* have those, as it is calculated earlier in
+* intel_atomic_check,
+*/
+ if (max_data_rate > max_bw) {
+ max_bw_point = i;
+ max_bw = max_data_rate;
+ }
+ if (max_data_rate >= data_rate)
+ qgv_points |= BIT(i);
+
+ drm_dbg_kms(>drm, "QGV point %d: max bw %d required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ for (i = 0; i < num_psf_gv_points; i++) {
+ unsigned int max_data_rate = adl_psf_bw(i915, i);
+
+ if (max_data_rate >= data_rate)
+ psf_points |= BIT(i);
+
+ drm_dbg_kms(>drm, "PSF GV point %d: max bw %d"
+ " required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ /*
+* BSpec states that we always should have at least one allowed point
+* left, so if we couldn't - simply reject the configuration for obvious
+* reasons.
+*/
+ if (qgv_points == 0) {
+ drm_dbg_kms(>drm, "No QGV points provide sufficient
memory"
+ " bandwidth %d for display configuration(%d active
planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ if (num_psf_gv_points > 0 && psf_points == 0) {
+ drm_dbg_kms(>drm, "No PSF GV points provide sufficient
memory"
+ " bandwidth %d for display configuration(%d active
planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ /*
+* Leave only single point with highest bandwidth, if
+* we can't enable SAGV due to the increased memory latency it may
+* cause.
+*/
+ if (!intel_can_enable_sagv(i915, new_bw_state)) {
+ qgv_points = BIT(max_bw_point);
+ drm_dbg_kms(>drm, "No SAGV, using single QGV point %d\n",
+ max_bw_point);
+ }
+
+ /*
+* We store the ones which need to be masked as that is what PCode
+* actually accepts as a parameter.
+*/
+ new_bw_state->qgv_points_mask =
+ ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ ADLS_PCODE_REQ_PSF_PT(psf_points)) &
+ icl_qgv_points_mask(i915);
+
+ /*
+* If the actual mask had changed we need to make sure that
+* the commits are serialized(in case this is a nomodeset, nonblocking)
+*/
+ if (new_bw_state->qgv_points_mask != old_bw_state->qgv_points_mask) {
+ ret = intel_atomic_serialize_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int intel_bw_check_qgv_points(struct drm_i915_private *i915,
+
[Intel-gfx] [PATCH v3 5/8] drm/i915: modify max_bw to return index to intel_bw_info
MTL uses the peak BW of a QGV point to lock the required QGV
point instead of the QGV index. Instead of passing the deratedbw
of the selected bw_info, return the index to the selected
bw_info so that either deratedbw or peakbw can be used based on
the platform.
v2: use idx to store index returned by max_bw_index functions
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index a3b8512ebe8a..a7f501131bb6 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -592,8 +592,8 @@ static void dg2_get_bw_info(struct drm_i915_private *i915)
i915->display.sagv.status = I915_SAGV_NOT_CONTROLLED;
}
-static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
- int num_planes, int qgv_point)
+static unsigned int icl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
{
int i;
@@ -614,14 +614,14 @@ static unsigned int icl_max_bw(struct drm_i915_private
*dev_priv,
return UINT_MAX;
if (num_planes >= bi->num_planes)
- return bi->deratedbw[qgv_point];
+ return i;
}
return 0;
}
-static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
- int num_planes, int qgv_point)
+static unsigned int tgl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
{
int i;
@@ -642,10 +642,10 @@ static unsigned int tgl_max_bw(struct drm_i915_private
*dev_priv,
return UINT_MAX;
if (num_planes <= bi->num_planes)
- return bi->deratedbw[qgv_point];
+ return i;
}
- return dev_priv->display.bw.max[0].deratedbw[qgv_point];
+ return 0;
}
static unsigned int adl_psf_bw(struct drm_i915_private *dev_priv,
@@ -822,12 +822,19 @@ static int icl_find_qgv_points(struct drm_i915_private
*i915,
return ret;
for (i = 0; i < num_qgv_points; i++) {
+ unsigned int idx;
unsigned int max_data_rate;
if (DISPLAY_VER(i915) > 11)
- max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+ idx = tgl_max_bw_index(i915, num_active_planes, i);
else
- max_data_rate = icl_max_bw(i915, num_active_planes, i);
+ idx = icl_max_bw_index(i915, num_active_planes, i);
+
+ if (idx > ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[idx].deratedbw[i];
+
/*
* We need to know which qgv point gives us
* maximum bandwidth in order to disable SAGV
--
2.34.1
[Intel-gfx] [PATCH v3 3/8] drm/i915: store the peak bw per QGV point
In MTL onwards, pcode locks the GV point based on the peak BW
of a QGV point. So store the peak BW of all the QGV points.
Bspec: 64636
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 7 +--
drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 25ae4e5834d3..f5b6cd7f83b8 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -534,10 +534,13 @@ static int tgl_get_bw_info(struct drm_i915_private
*dev_priv, const struct intel
bi->deratedbw[j] = min(maxdebw,
bw * (100 - sa->derating) / 100);
+ bi->peakbw[j] = sp->dclk * num_channels *
+ qi.channel_width / 8;
drm_dbg_kms(_priv->drm,
- "BW%d / QGV %d: num_planes=%d
deratedbw=%u\n",
- i, j, bi->num_planes, bi->deratedbw[j]);
+ "BW%d / QGV %d: num_planes=%d deratedbw=%u
peakbw: %u\n",
+ i, j, bi->num_planes, bi->deratedbw[j],
+ bi->peakbw[j]);
}
for (j = 0; j < qi.num_psf_points; j++) {
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index e36f88a39b86..9f66d734edf6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -314,6 +314,8 @@ struct intel_display {
unsigned int deratedbw[I915_NUM_QGV_POINTS];
/* for each PSF GV point */
unsigned int psf_bw[I915_NUM_PSF_GV_POINTS];
+ /* Peak BW for each QGV point */
+ unsigned int peakbw[I915_NUM_QGV_POINTS];
u8 num_qgv_points;
u8 num_psf_gv_points;
u8 num_planes;
--
2.34.1
[Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations
>From MTL onwwards, pcode locks the QGV point based on peak BW of the intended QGV point passed by the driver. So the peak BW calculation must match the value expected by the pcode. Update the calculations as per the Bspec. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c index ab405c48ca3a..25ae4e5834d3 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv, val2 = intel_uncore_read(_priv->uncore, MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); + sp->dclk = (16667 * dclk + 500) / 1000; sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); -- 2.34.1
[Intel-gfx] [PATCH v3 1/8] drm/i915: fix the derating percentage for MTL
Follow the values from bspec for the percentage overhead for
efficiency in MTL BW calculations.
Bspec: 64631
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 597d5816ad1b..ab405c48ca3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -379,7 +379,7 @@ static const struct intel_sa_info mtl_sa_info = {
.deburst = 32,
.deprogbwlimit = 38, /* GB/s */
.displayrtids = 256,
- .derating = 20,
+ .derating = 10,
};
static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct
intel_sa_info *sa)
--
2.34.1
[Intel-gfx] [PATCH v3 0/8] mtl: add support for pmdeman
pmdemand support patches for MTL SAGV configuration support for MTL v2: added one missing patch in the previous version v3: chekcpatch warning fixes update index handling for the icl/tgl QGV point handling program pmdemand code simplified v4: update to debufs and pipe values pmdemand regiters removed the macro usage in update_pmdemand_values Mika Kahola (1): drm/i915/mtl: Add support for PM DEMAND Vinod Govindapillai (7): drm/i915: fix the derating percentage for MTL drm/i915: update the QGV point frequency calculations drm/i915: store the peak bw per QGV point drm/i915: extract intel_bw_check_qgv_points() drm/i915: modify max_bw to return index to intel_bw_info drm/i915/mtl: find best QGV point and configure sagv drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_bw.c | 350 +- drivers/gpu/drm/i915/display/intel_bw.h | 6 + drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 17 +- drivers/gpu/drm/i915/display/intel_display.h | 3 +- .../gpu/drm/i915/display/intel_display_core.h | 8 + .../drm/i915/display/intel_display_driver.c | 7 + .../drm/i915/display/intel_display_power.c| 8 + drivers/gpu/drm/i915/display/intel_dpll.c | 8 +- .../gpu/drm/i915/display/intel_pch_display.c | 2 +- drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++ drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 + drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 21 +- drivers/gpu/drm/i915/i915_reg.h | 36 +- 16 files changed, 819 insertions(+), 133 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h -- 2.34.1
