[Intel-gfx] ✓ Fi.CI.BAT: success for Enable GuC submission by default on DG1
== Series Details ==
Series: Enable GuC submission by default on DG1
URL : https://patchwork.freedesktop.org/series/93325/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10440 -> Patchwork_20763
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20763/index.html
Known issues
Here are the changes found in Patchwork_20763 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] ([i915#155])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10440/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20763/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717
Participating hosts (37 -> 33)
--
Missing(4): fi-bdw-samus fi-bsw-cyan bat-jsl-1 fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10440 -> Patchwork_20763
CI-20190529: 20190529
CI_DRM_10440: 95b785be5ff0413ff419b30da574a7e3d353b33b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6159: 6135b9cc319ed965e3aafb5b2ae2abf4762a06b2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20763: a06cd563cc84d8dc74dd7ca041e09f3d410e229e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a06cd563cc84 drm/i915/guc: Enable GuC submission by default on DG1
dab0f2596b90 drm/i915/guc: Add DG1 GuC / HuC firmware defs
d90a57170211 drm/i915/guc: put all guc objects in lmem when available
9d575da473a3 drm/i915: Do not define vma on stack
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20763/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable GuC submission by default on DG1
== Series Details == Series: Enable GuC submission by default on DG1 URL : https://patchwork.freedesktop.org/series/93325/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1901:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1901:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1901:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/i915_gem_context.c:1410:34:expected struct i915_address_space *vm +drivers/gpu/drm/i915/gem/i915_gem_context.c:1410:34:got struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/i915_gem_context.c:1410:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:expected struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:got struct i915_address_space * +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:expected struct i915_address_space *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:got struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1268:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: co
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable GuC submission by default on DG1
== Series Details == Series: Enable GuC submission by default on DG1 URL : https://patchwork.freedesktop.org/series/93325/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9d575da473a3 drm/i915: Do not define vma on stack -:12: WARNING:BAD_SIGN_OFF: Non-standard signature: 'Signef-off-by:' - perhaps 'Signed-off-by:'? #12: Signef-off-by: Matthew Brost total: 0 errors, 1 warnings, 0 checks, 43 lines checked d90a57170211 drm/i915/guc: put all guc objects in lmem when available -:110: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #110: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c:45: +static int guc_xfer_rsa(struct intel_uc_fw *guc_fw, struct intel_uncore *uncore) total: 0 errors, 0 warnings, 1 checks, 234 lines checked dab0f2596b90 drm/i915/guc: Add DG1 GuC / HuC firmware defs -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 7 lines checked a06cd563cc84 drm/i915/guc: Enable GuC submission by default on DG1 -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] [PATCH 3/4] drm/i915/guc: Add DG1 GuC / HuC firmware defs
Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index f8cb00ffb506..a685d563df72 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -51,6 +51,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \ fw_def(ALDERLAKE_P, 0, guc_def(adlp, 62, 0, 3), huc_def(tgl, 7, 9, 3)) \ fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ + fw_def(DG1, 0, guc_def(dg1, 62, 0, 0), huc_def(dg1, 7, 9, 3)) \ fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \ -- 2.28.0
[Intel-gfx] [PATCH 2/4] drm/i915/guc: put all guc objects in lmem when available
From: Daniele Ceraolo Spurio
The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocated during driver load and if we have issues with lmem at that point
something is seriously wrong with the system, so no point in trying to
handle it.
Cc: Matthew Auld
Cc: Abdiel Janulgue
Cc: Michal Wajdeczko
Cc: Vinay Belgaumkar
Cc: Radoslaw Szwichtenberg
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 26
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 4 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 9 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 11 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 14 -
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 75 +--
6 files changed, 127 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index eb345305dc52..034226c5d4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -103,6 +103,32 @@ __i915_gem_object_create_lmem_with_ps(struct
drm_i915_private *i915,
size, page_size, flags);
}
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem_from_data(struct drm_i915_private *i915,
+ const void *data, size_t size)
+{
+ struct drm_i915_gem_object *obj;
+ void *map;
+
+ obj = i915_gem_object_create_lmem(i915,
+ round_up(size, PAGE_SIZE),
+ I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(obj))
+ return obj;
+
+ map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
+ if (IS_ERR(map)) {
+ i915_gem_object_put(obj);
+ return map;
+ }
+
+ memcpy(map, data, size);
+
+ i915_gem_object_unpin_map(obj);
+
+ return obj;
+}
+
struct drm_i915_gem_object *
i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index 4ee81fc66302..1b88ea13435c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -23,6 +23,10 @@ bool i915_gem_object_is_lmem(struct drm_i915_gem_object
*obj);
bool __i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem_from_data(struct drm_i915_private *i915,
+ const void *data, size_t size);
+
struct drm_i915_gem_object *
__i915_gem_object_create_lmem_with_ps(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 979128e28372..55160d3e401a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -3,6 +3,7 @@
* Copyright © 2014-2019 Intel Corporation
*/
+#include "gem/i915_gem_lmem.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
#include "gt/intel_gt_pm_irq.h"
@@ -630,7 +631,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size)
u64 flags;
int ret;
- obj = i915_gem_object_create_shmem(gt->i915, size);
+ if (HAS_LMEM(gt->i915))
+ obj = i915_gem_object_create_lmem(gt->i915, size,
+ I915_BO_ALLOC_CPU_CLEAR |
+ I915_BO_ALLOC_CONTIGUOUS);
+ else
+ obj = i915_gem_object_create_shmem(gt->i915, size);
+
if (IS_ERR(obj))
return ERR_CAST(obj);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 76fe766ad1bc..962be0c12208 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -41,7 +41,7 @@ static void guc_prepare_xfer(struct intel_uncore *uncore)
}
/* Copy RSA signature from the fw image to HW for verification */
-static void guc_xfer_rsa(struct intel_uc_fw *guc_fw,
+static int guc_xfer_rsa(struct intel_uc_fw *guc_fw,
struct intel_uncore *uncore)
{
u32 rsa[UOS_RSA_SCRATCH_COUNT];
@@ -49,10 +49,13 @@ static void guc_xfer_rsa(struct intel_uc_fw *guc_fw,
int i;
copied = intel_uc_fw_copy_rsa(guc_fw, rsa, sizeof(rsa));
- GEM_BUG_ON(copied < sizeof(rsa));
+ if (copied < sizeof(rsa))
+ return -ENOMEM;
for (i = 0; i < UOS_RSA_SCRATCH_COUNT; i++)
intel_uncore_write(uncore, UOS_RSA_SCRATCH(i), rsa[i]);
+
+ return 0;
}
/
[Intel-gfx] [PATCH 4/4] drm/i915/guc: Enable GuC submission by default on DG1
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index da57d18d9f6b..fc2fc8d111d8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -35,7 +35,7 @@ static void uc_expand_default_options(struct intel_uc *uc)
}
/* Intermediate platforms are HuC authentication only */
- if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+ if (IS_ALDERLAKE_S(i915)) {
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
return;
}
--
2.28.0
[Intel-gfx] [PATCH 0/4] Enable GuC submission by default on DG1
Minimum set of patches to enable GuC submission on DG1 and enable it by default. A little difficult to test as IGTs do not work with DG1 due to a bunch of uAPI features being disabled (e.g. relocations, caching memory options, etc...). Tested with the loading the driver and 'live' selftests. Submissions seem to work. Signed-off-by: Matthew Brost Daniele Ceraolo Spurio (1): drm/i915/guc: put all guc objects in lmem when available Matthew Brost (2): drm/i915/guc: Add DG1 GuC / HuC firmware defs drm/i915/guc: Enable GuC submission by default on DG1 Venkata Sandeep Dhanalakota (1): drm/i915: Do not define vma on stack drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 26 +++ drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 9 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 11 ++- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 14 +++- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 90 --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 + 8 files changed, 138 insertions(+), 20 deletions(-) -- 2.28.0
[Intel-gfx] [PATCH 1/4] drm/i915: Do not define vma on stack
From: Venkata Sandeep Dhanalakota
Defining vma on stack can cause stack overflow, if
vma gets populated with new fields.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signef-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3a16d08608a5..f632dbd32b42 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -413,20 +413,20 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
{
struct drm_i915_gem_object *obj = uc_fw->obj;
struct i915_ggtt *ggtt = __uc_fw_to_gt(uc_fw)->ggtt;
- struct i915_vma dummy = {
- .node.start = uc_fw_ggtt_offset(uc_fw),
- .node.size = obj->base.size,
- .pages = obj->mm.pages,
- .vm = &ggtt->vm,
- };
+ struct i915_vma *dummy = &uc_fw->dummy;
+
+ dummy->node.start = uc_fw_ggtt_offset(uc_fw);
+ dummy->node.size = obj->base.size;
+ dummy->pages = obj->mm.pages;
+ dummy->vm = &ggtt->vm;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
- GEM_BUG_ON(dummy.node.size > ggtt->uc_fw.size);
+ GEM_BUG_ON(dummy->node.size > ggtt->uc_fw.size);
/* uc_fw->obj cache domains were not controlled across suspend */
- drm_clflush_sg(dummy.pages);
+ drm_clflush_sg(dummy->pages);
- ggtt->vm.insert_entries(&ggtt->vm, &dummy, I915_CACHE_NONE, 0);
+ ggtt->vm.insert_entries(&ggtt->vm, dummy, I915_CACHE_NONE, 0);
}
static void uc_fw_unbind_ggtt(struct intel_uc_fw *uc_fw)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index 99bb1fe1af66..693cc0ebcd63 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -10,6 +10,7 @@
#include "intel_uc_fw_abi.h"
#include "intel_device_info.h"
#include "i915_gem.h"
+#include "i915_vma.h"
struct drm_printer;
struct drm_i915_private;
@@ -75,6 +76,7 @@ struct intel_uc_fw {
bool user_overridden;
size_t size;
struct drm_i915_gem_object *obj;
+ struct i915_vma dummy;
/*
* The firmware build process will generate a version header file with
major and
--
2.28.0
[Intel-gfx] ✗ Fi.CI.IGT: failure for fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
== Series Details == Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy URL : https://patchwork.freedesktop.org/series/93307/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20760_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20760_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20760_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20760_full: ### IGT changes ### Possible regressions * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html Known issues Here are the changes found in Patchwork_20760_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1888] / [i915#3160]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk5/igt@gem_cre...@create-clear.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-glk7/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-apl: [PASS][8] -> [SKIP][9] ([fdo#109271]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-apl6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-apl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-tglb3/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +440 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#1888] / [i915#307]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk7/igt@gem_mmap_...@cpuset-big-copy-odd.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-glk7/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#644]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_pread@exhaustion: - shard-snb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-snb2/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-iclb6/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][20] ([i915#3002]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/shard-apl6/igt@gem_userptr_bl...@input-checking.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i9
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Drop __rcu from gem_context->vm
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc3 next-20210730]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/remove-rcu-support-from-i915_address_space/20210802-234929
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-s002-20210802 (attached as .config)
compiler: gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-341-g8af24329-dirty
#
https://github.com/0day-ci/linux/commit/4a70c02a8b49ee9845e8222c55b4bf932e843224
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Daniel-Vetter/remove-rcu-support-from-i915_address_space/20210802-234929
git checkout 4a70c02a8b49ee9845e8222c55b4bf932e843224
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir
ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/i915/gem/i915_gem_context.c: note: in included file (through
drivers/gpu/drm/i915/gt/intel_gt_requests.h,
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c):
/usr/lib/gcc/x86_64-linux-gnu/10/include/stddef.h:406:9: sparse: sparse:
preprocessor token offsetof redefined
drivers/gpu/drm/i915/gem/i915_gem_context.c: note: in included file (through
include/uapi/linux/posix_types.h, include/uapi/linux/types.h,
include/linux/types.h, ...):
include/linux/stddef.h:17:9: sparse: this was the original definition
drivers/gpu/drm/i915/gem/i915_gem_context.c: note: in included file:
>> drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:698:33: sparse:
>> sparse: incompatible types in comparison expression (different address
>> spaces):
>> drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:698:33: sparse:
>> struct i915_address_space [noderef] __rcu *
>> drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:698:33: sparse:
>> struct i915_address_space *
vim +698 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
f2085c8e950d53 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c Chris
Wilson 2019-08-27 631
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 632 static int igt_ctx_exec(void *arg)
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 633 {
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 634 struct drm_i915_private *i915 = arg;
e0695db7298ec2 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2019-03-22 635 struct intel_engine_cs *engine;
6e1281412ab9e6 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-11-14 636 int err = -ENODEV;
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 637
0fdbe58c4a0f8c drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2018-07-06 638 /*
0fdbe58c4a0f8c drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2018-07-06 639 * Create a few different contexts (with different
mm) and write
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 640 * through each ctx/mm using the GPU making sure
those writes end
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 641 * up in the expected pages of our obj.
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 642 */
791ff39ae32a34 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2017-02-13 643
0fdbe58c4a0f8c drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2018-07-06 644 if (!DRIVER_CAPS(i915)->has_logical_contexts)
0fdbe58c4a0f8c drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2018-07-06 645 return 0;
0fdbe58c4a0f8c drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2018-07-06 646
51757cf4d7e6e1 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c Tvrtko
Ursulin 2019-10-22 647 for_each_uabi_engine(engine, i915) {
e0695db7298ec2 drivers/gpu/drm/i915/selftests/i915_gem_context.c Chris
Wilson 2019-03-22 648 struct drm_i915_gem_object *obj = NULL;
e0695db7298ec2 drivers/gpu/drm/i915/selftests/i915_gem_
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
== Series Details == Series: drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg URL : https://patchwork.freedesktop.org/series/93306/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20759_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20759_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#1888] / [i915#3160]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk5/igt@gem_cre...@create-clear.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-glk5/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@legacy-engines-hang@render: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-kbl7/igt@gem_ctx_persistence@legacy-engines-h...@render.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-kbl4/igt@gem_ctx_persistence@legacy-engines-h...@render.html - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb3/igt@gem_ctx_persistence@legacy-engines-h...@render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-tglb6/igt@gem_ctx_persistence@legacy-engines-h...@render.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] / [i915#3648]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb8/igt@gem_...@unwedge-stress.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-tglb5/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][10] ([i915#3354]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271]) +461 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][18] -> [SKIP][19] ([i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb3/igt@gem_huc_c...@huc-copy.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-tglb6/igt@gem_huc_c...@huc-copy.html - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-snb: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-snb6/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-iclb: NOTRUN -> [SKIP][22] ([i915#3297]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-iclb7/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][23] ([i915#3002]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-apl2/igt@gem_userptr_bl...@input-checking.html - shard-snb: NOTRUN -> [DMESG-WARN][24] ([i915#3002]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/shard-snb6/igt@gem_userptr_bl..
[Intel-gfx] ✓ Fi.CI.IGT: success for locking/lockdep, drm: apply new lockdep assert in drm_auth.c
== Series Details == Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c URL : https://patchwork.freedesktop.org/series/93304/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20757_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20757_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-hang@render: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#2410]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk7/igt@gem_ctx_persistence@legacy-engines-h...@render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-glk7/igt@gem_ctx_persistence@legacy-engines-h...@render.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-apl2/igt@gem_...@in-flight-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-apl2/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] / [i915#3648]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb8/igt@gem_...@unwedge-stress.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-tglb7/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] / [i915#2481] / [i915#3070]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-iclb6/igt@gem_...@unwedge-stress.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-iclb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-kbl2/igt@gem_exec_fair@basic-n...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-kbl6/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-tglb2/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-big-copy: - shard-iclb: NOTRUN -> [FAIL][20] ([i915#2428]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html * igt@gem_pread@exhaustion: - shard-snb: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-snb7/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][22] ([i915#2658]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-apl3/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-iclb: NOTRUN -> [SKIP][23] ([i915#3297]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/shard-iclb1/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_workarounds@suspend-resume-context: - shard-kbl: NOTRUN -> [DMESG-WARN][24] ([i915#180]) [24]: https://intel-gfx-ci.01.org/tree/drm-ti
Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
On Tue, Aug 03, 2021 at 12:16:30AM +0300, Souza, Jose wrote:
> On Tue, 2021-08-03 at 00:07 +0300, Imre Deak wrote:
> > On Mon, Aug 02, 2021 at 11:52:41PM +0300, Souza, Jose wrote:
> > > On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote:
> > > > CI test results/further experiments show that the workaround added in
> > > >
> > > > commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG
> > > > clock gating")
> > > >
> > > > can be applied only while DPLL0 is enabled. If it's disabled the
> > > > TRANS_CMTG_CHICKEN register is not accessible. Accordingly move the WA
> > > > to DPLL0 HW state sanitization and enabling.
> > > >
> > > > This fixes an issue where the WA won't get applied (and a WARN is thrown
> > > > due to an unexpected value in TRANS_CMTG_CHICKEN) if the driver is
> > > > loaded without DPLL0 being enabled: booting without BIOS enabling an
> > > > output with this PLL, or reloading the driver.
> > > >
> > > > While at it also add a debug print for the unexpected register value.
> > >
> > > Workaround do not mention nothing about this DPLL0 dependency, maybe
> > > would be nice to comment in HSD about this.
> >
> > Ok, can add comment.
> >
> > > Have you tried to check if the workaround applies if DPLL1 is enabled?
> > > We could comment DPLL0 out from the adlp_plls table.
> >
> > No, only DPLL0 makes it work, DPLL1 being enabled is not enough. You can
> > experiment with this by unloading the driver and simply enable/disable
> > DPLL0/1 (both power and enable flag) and try to read/modify/re-read the
> > CMTG_CHICKEN reg.
>
> Okay if you tested this it looks good to me.
>
> Reviewed-by: José Roberto de Souza
Thanks, added a question on the HSD ticket, let's wait for the response.
> > > > Cc: José Roberto de Souza
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 18 --
> > > > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 34 ++-
> > > > 2 files changed, 33 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 4ca354f154215..98f7fbede6226 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -13284,24 +13284,6 @@ static void intel_early_display_was(struct
> > > > drm_i915_private *dev_priv)
> > > > KBL_ARB_FILL_SPARE_13 |
> > > > KBL_ARB_FILL_SPARE_14,
> > > > KBL_ARB_FILL_SPARE_14);
> > > > }
> > > > -
> > > > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> > > > - u32 val;
> > > > -
> > > > - /*
> > > > -* Wa_16011069516:adl-p[a0]
> > > > -*
> > > > -* All CMTG regs are unreliable until CMTG clock gating
> > > > is
> > > > -* disabled, so we can only assume the default
> > > > CMTG_CHICKEN
> > > > -* reg value and sanity check this assumption with a
> > > > double
> > > > -* read, which presumably returns the correct value
> > > > even with
> > > > -* clock gating on.
> > > > -*/
> > > > - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> > > > - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> > > > - intel_de_write(dev_priv, TRANS_CMTG_CHICKEN,
> > > > DISABLE_DPT_CLK_GATING);
> > > > - drm_WARN_ON(&dev_priv->drm, val &
> > > > ~DISABLE_DPT_CLK_GATING);
> > > > - }
> > > > }
> > > >
> > > > static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private
> > > > *dev_priv,
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > > index 0d72917e5670f..5c91d125a3371 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > > @@ -3735,6 +3735,31 @@ static void icl_pll_enable(struct
> > > > drm_i915_private *dev_priv,
> > > > drm_err(&dev_priv->drm, "PLL %d not locked\n",
> > > > pll->info->id);
> > > > }
> > > >
> > > > +static void adlp_cmtg_clock_gating_wa(struct drm_i915_private *i915,
> > > > struct intel_shared_dpll *pll)
> > > > +{
> > > > + u32 val;
> > > > +
> > > > + if (!IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
> > > > + pll->info->id != DPLL_ID_ICL_DPLL0)
> > > > + return;
> > > > + /*
> > > > +* Wa_16011069516:adl-p[a0]
> > > > +*
> > > > +* All CMTG regs are unreliable until CMTG clock gating is
> > > > disabled,
> > > > +* so we can only assume the default TRANS_CMTG_CHICKEN reg
> > > > value and
> > > > +* sanity check this assumption with a double read, which
> > > > presumably
> > > > +* retur
Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
On Tue, 2021-08-03 at 00:07 +0300, Imre Deak wrote:
> On Mon, Aug 02, 2021 at 11:52:41PM +0300, Souza, Jose wrote:
> > On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote:
> > > CI test results/further experiments show that the workaround added in
> > >
> > > commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock
> > > gating")
> > >
> > > can be applied only while DPLL0 is enabled. If it's disabled the
> > > TRANS_CMTG_CHICKEN register is not accessible. Accordingly move the WA
> > > to DPLL0 HW state sanitization and enabling.
> > >
> > > This fixes an issue where the WA won't get applied (and a WARN is thrown
> > > due to an unexpected value in TRANS_CMTG_CHICKEN) if the driver is
> > > loaded without DPLL0 being enabled: booting without BIOS enabling an
> > > output with this PLL, or reloading the driver.
> > >
> > > While at it also add a debug print for the unexpected register value.
> >
> > Workaround do not mention nothing about this DPLL0 dependency, maybe
> > would be nice to comment in HSD about this.
>
> Ok, can add comment.
>
> > Have you tried to check if the workaround applies if DPLL1 is enabled?
> > We could comment DPLL0 out from the adlp_plls table.
>
> No, only DPLL0 makes it work, DPLL1 being enabled is not enough. You can
> experiment with this by unloading the driver and simply enable/disable
> DPLL0/1 (both power and enable flag) and try to read/modify/re-read the
> CMTG_CHICKEN reg.
Okay if you tested this it looks good to me.
Reviewed-by: José Roberto de Souza
>
> > > Cc: José Roberto de Souza
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 18 --
> > > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 34 ++-
> > > 2 files changed, 33 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 4ca354f154215..98f7fbede6226 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -13284,24 +13284,6 @@ static void intel_early_display_was(struct
> > > drm_i915_private *dev_priv)
> > >KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
> > >KBL_ARB_FILL_SPARE_14);
> > > }
> > > -
> > > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> > > - u32 val;
> > > -
> > > - /*
> > > - * Wa_16011069516:adl-p[a0]
> > > - *
> > > - * All CMTG regs are unreliable until CMTG clock gating is
> > > - * disabled, so we can only assume the default CMTG_CHICKEN
> > > - * reg value and sanity check this assumption with a double
> > > - * read, which presumably returns the correct value even with
> > > - * clock gating on.
> > > - */
> > > - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> > > - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> > > - intel_de_write(dev_priv, TRANS_CMTG_CHICKEN,
> > > DISABLE_DPT_CLK_GATING);
> > > - drm_WARN_ON(&dev_priv->drm, val & ~DISABLE_DPT_CLK_GATING);
> > > - }
> > > }
> > >
> > > static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > index 0d72917e5670f..5c91d125a3371 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > > @@ -3735,6 +3735,31 @@ static void icl_pll_enable(struct drm_i915_private
> > > *dev_priv,
> > > drm_err(&dev_priv->drm, "PLL %d not locked\n", pll->info->id);
> > > }
> > >
> > > +static void adlp_cmtg_clock_gating_wa(struct drm_i915_private *i915,
> > > struct intel_shared_dpll *pll)
> > > +{
> > > + u32 val;
> > > +
> > > + if (!IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
> > > + pll->info->id != DPLL_ID_ICL_DPLL0)
> > > + return;
> > > + /*
> > > + * Wa_16011069516:adl-p[a0]
> > > + *
> > > + * All CMTG regs are unreliable until CMTG clock gating is disabled,
> > > + * so we can only assume the default TRANS_CMTG_CHICKEN reg value and
> > > + * sanity check this assumption with a double read, which presumably
> > > + * returns the correct value even with clock gating on.
> > > + *
> > > + * Instead of the usual place for workarounds we apply this one here,
> > > + * since TRANS_CMTG_CHICKEN is only accessible while DPLL0 is enabled.
> > > + */
> > > + val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
> > > + val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
> > > + intel_de_write(i915, TRANS_CMTG_CHICKEN, DISABLE_DPT_CLK_GATING);
> > > + if (drm_WARN_ON(&i915->drm, val & ~DISABLE_DPT_CLK_GATING))
> > > + drm_dbg_kms(&i915->drm, "Unexpected flags in
> > > TRANS_CMTG_CHICKEN: %08x\n", val);
> > > +}
> > > +
> > > static v
Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
On Mon, Aug 02, 2021 at 11:52:41PM +0300, Souza, Jose wrote:
> On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote:
> > CI test results/further experiments show that the workaround added in
> >
> > commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock
> > gating")
> >
> > can be applied only while DPLL0 is enabled. If it's disabled the
> > TRANS_CMTG_CHICKEN register is not accessible. Accordingly move the WA
> > to DPLL0 HW state sanitization and enabling.
> >
> > This fixes an issue where the WA won't get applied (and a WARN is thrown
> > due to an unexpected value in TRANS_CMTG_CHICKEN) if the driver is
> > loaded without DPLL0 being enabled: booting without BIOS enabling an
> > output with this PLL, or reloading the driver.
> >
> > While at it also add a debug print for the unexpected register value.
>
> Workaround do not mention nothing about this DPLL0 dependency, maybe
> would be nice to comment in HSD about this.
Ok, can add comment.
> Have you tried to check if the workaround applies if DPLL1 is enabled?
> We could comment DPLL0 out from the adlp_plls table.
No, only DPLL0 makes it work, DPLL1 being enabled is not enough. You can
experiment with this by unloading the driver and simply enable/disable
DPLL0/1 (both power and enable flag) and try to read/modify/re-read the
CMTG_CHICKEN reg.
> > Cc: José Roberto de Souza
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 18 --
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 34 ++-
> > 2 files changed, 33 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 4ca354f154215..98f7fbede6226 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -13284,24 +13284,6 @@ static void intel_early_display_was(struct
> > drm_i915_private *dev_priv)
> > KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
> > KBL_ARB_FILL_SPARE_14);
> > }
> > -
> > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> > - u32 val;
> > -
> > - /*
> > -* Wa_16011069516:adl-p[a0]
> > -*
> > -* All CMTG regs are unreliable until CMTG clock gating is
> > -* disabled, so we can only assume the default CMTG_CHICKEN
> > -* reg value and sanity check this assumption with a double
> > -* read, which presumably returns the correct value even with
> > -* clock gating on.
> > -*/
> > - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> > - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> > - intel_de_write(dev_priv, TRANS_CMTG_CHICKEN,
> > DISABLE_DPT_CLK_GATING);
> > - drm_WARN_ON(&dev_priv->drm, val & ~DISABLE_DPT_CLK_GATING);
> > - }
> > }
> >
> > static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index 0d72917e5670f..5c91d125a3371 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -3735,6 +3735,31 @@ static void icl_pll_enable(struct drm_i915_private
> > *dev_priv,
> > drm_err(&dev_priv->drm, "PLL %d not locked\n", pll->info->id);
> > }
> >
> > +static void adlp_cmtg_clock_gating_wa(struct drm_i915_private *i915,
> > struct intel_shared_dpll *pll)
> > +{
> > + u32 val;
> > +
> > + if (!IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
> > + pll->info->id != DPLL_ID_ICL_DPLL0)
> > + return;
> > + /*
> > +* Wa_16011069516:adl-p[a0]
> > +*
> > +* All CMTG regs are unreliable until CMTG clock gating is disabled,
> > +* so we can only assume the default TRANS_CMTG_CHICKEN reg value and
> > +* sanity check this assumption with a double read, which presumably
> > +* returns the correct value even with clock gating on.
> > +*
> > +* Instead of the usual place for workarounds we apply this one here,
> > +* since TRANS_CMTG_CHICKEN is only accessible while DPLL0 is enabled.
> > +*/
> > + val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
> > + val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
> > + intel_de_write(i915, TRANS_CMTG_CHICKEN, DISABLE_DPT_CLK_GATING);
> > + if (drm_WARN_ON(&i915->drm, val & ~DISABLE_DPT_CLK_GATING))
> > + drm_dbg_kms(&i915->drm, "Unexpected flags in
> > TRANS_CMTG_CHICKEN: %08x\n", val);
> > +}
> > +
> > static void combo_pll_enable(struct drm_i915_private *dev_priv,
> > struct intel_shared_dpll *pll)
> > {
> > @@ -3764,6 +3789,8 @@ static void combo_pll_enable(struct drm_i915_private
> > *dev_priv,
> >
> > icl_pll_enable(dev_priv, pll, enable_reg
Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote:
> CI test results/further experiments show that the workaround added in
>
> commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock
> gating")
>
> can be applied only while DPLL0 is enabled. If it's disabled the
> TRANS_CMTG_CHICKEN register is not accessible. Accordingly move the WA
> to DPLL0 HW state sanitization and enabling.
>
> This fixes an issue where the WA won't get applied (and a WARN is thrown
> due to an unexpected value in TRANS_CMTG_CHICKEN) if the driver is
> loaded without DPLL0 being enabled: booting without BIOS enabling an
> output with this PLL, or reloading the driver.
>
> While at it also add a debug print for the unexpected register value.
Workaround do not mention nothing about this DPLL0 dependency, maybe would be
nice to comment in HSD about this.
Have you tried to check if the workaround applies if DPLL1 is enabled? We could
comment DPLL0 out from the adlp_plls table.
>
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 18 --
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 34 ++-
> 2 files changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4ca354f154215..98f7fbede6226 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13284,24 +13284,6 @@ static void intel_early_display_was(struct
> drm_i915_private *dev_priv)
>KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
>KBL_ARB_FILL_SPARE_14);
> }
> -
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> - u32 val;
> -
> - /*
> - * Wa_16011069516:adl-p[a0]
> - *
> - * All CMTG regs are unreliable until CMTG clock gating is
> - * disabled, so we can only assume the default CMTG_CHICKEN
> - * reg value and sanity check this assumption with a double
> - * read, which presumably returns the correct value even with
> - * clock gating on.
> - */
> - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> - val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
> - intel_de_write(dev_priv, TRANS_CMTG_CHICKEN,
> DISABLE_DPT_CLK_GATING);
> - drm_WARN_ON(&dev_priv->drm, val & ~DISABLE_DPT_CLK_GATING);
> - }
> }
>
> static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 0d72917e5670f..5c91d125a3371 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -3735,6 +3735,31 @@ static void icl_pll_enable(struct drm_i915_private
> *dev_priv,
> drm_err(&dev_priv->drm, "PLL %d not locked\n", pll->info->id);
> }
>
> +static void adlp_cmtg_clock_gating_wa(struct drm_i915_private *i915, struct
> intel_shared_dpll *pll)
> +{
> + u32 val;
> +
> + if (!IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
> + pll->info->id != DPLL_ID_ICL_DPLL0)
> + return;
> + /*
> + * Wa_16011069516:adl-p[a0]
> + *
> + * All CMTG regs are unreliable until CMTG clock gating is disabled,
> + * so we can only assume the default TRANS_CMTG_CHICKEN reg value and
> + * sanity check this assumption with a double read, which presumably
> + * returns the correct value even with clock gating on.
> + *
> + * Instead of the usual place for workarounds we apply this one here,
> + * since TRANS_CMTG_CHICKEN is only accessible while DPLL0 is enabled.
> + */
> + val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
> + val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
> + intel_de_write(i915, TRANS_CMTG_CHICKEN, DISABLE_DPT_CLK_GATING);
> + if (drm_WARN_ON(&i915->drm, val & ~DISABLE_DPT_CLK_GATING))
> + drm_dbg_kms(&i915->drm, "Unexpected flags in
> TRANS_CMTG_CHICKEN: %08x\n", val);
> +}
> +
> static void combo_pll_enable(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> {
> @@ -3764,6 +3789,8 @@ static void combo_pll_enable(struct drm_i915_private
> *dev_priv,
>
> icl_pll_enable(dev_priv, pll, enable_reg);
>
> + adlp_cmtg_clock_gating_wa(dev_priv, pll);
> +
> /* DVFS post sequence would be here. See the comment above. */
> }
>
> @@ -4273,7 +4300,12 @@ void intel_dpll_readout_hw_state(struct
> drm_i915_private *i915)
> static void sanitize_dpll_state(struct drm_i915_private *i915,
> struct intel_shared_dpll *pll)
> {
> - if (!pll->on || pll->active_mask)
> + if (!pll->on)
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
== Series Details ==
Series: drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
URL : https://patchwork.freedesktop.org/series/93318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10440 -> Patchwork_20762
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20762/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20762:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@requests:
- {fi-tgl-dsi}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10440/fi-tgl-dsi/igt@i915_selftest@l...@requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20762/fi-tgl-dsi/igt@i915_selftest@l...@requests.html
Known issues
Here are the changes found in Patchwork_20762 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_parallel@engines@userptr:
- fi-pnv-d510:[PASS][3] -> [INCOMPLETE][4] ([i915#299])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10440/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20762/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][5] -> [FAIL][6] ([i915#1888])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10440/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20762/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][7] ([i915#2403] / [i915#2505] /
[i915#2722])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20762/fi-pnv-d510/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#299]: https://gitlab.freedesktop.org/drm/intel/issues/299
Participating hosts (37 -> 32)
--
Missing(5): fi-kbl-soraka fi-hsw-4200u fi-bsw-cyan bat-jsl-1 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10440 -> Patchwork_20762
CI-20190529: 20190529
CI_DRM_10440: 95b785be5ff0413ff419b30da574a7e3d353b33b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6159: 6135b9cc319ed965e3aafb5b2ae2abf4762a06b2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20762: 31185812783debebc9c19772194bdd17d6bc0812 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
31185812783d drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20762/index.html
Re: [Intel-gfx] [PATCH i-g-t 1/1] i915/gem_scheduler: Ensure submission order in manycontexts
On Mon, Aug 02, 2021 at 09:59:01AM +0100, Tvrtko Ursulin wrote: > > > On 30/07/2021 19:06, Matthew Brost wrote: > > On Fri, Jul 30, 2021 at 10:58:38AM +0100, Tvrtko Ursulin wrote: > > > > > > On 27/07/2021 19:20, Matthew Brost wrote: > > > > With GuC submission contexts can get reordered (compared to submission > > > > order), if contexts get reordered the sequential nature of the batches > > > > releasing the next batch's semaphore in function timesliceN() get broken > > > > resulting in the test taking much longer than if should. e.g. Every > > > > contexts needs to be timesliced to release the next batch. Corking the > > > > first submission until all the batches have been submitted should ensure > > > > submission order. > > > > > > The explanation sounds suspect. > > > > > > Consider this comment from the test itself: > > > > > > /* > > >* Create a pair of interlocking batches, that ping pong > > >* between each other, and only advance one step at a time. > > >* We require the kernel to preempt at each semaphore and > > >* switch to the other batch in order to advance. > > >*/ > > > > > > I'd say the test does not rely on no re-ordering at all, but relies on > > > context switch on an unsatisfied semaphore. > > > > > > > Yes, let do a simple example with 5 batches. Batch 0 releases batch's > > semaphore 1, batch 1 releases batch's 2 semaphore, etc... If the batches > > are seen in order the test should take 40 timeslices (8 semaphores in > > each batch have to be released). > > > > If the batches are in the below order: > > 0 2 1 3 4 > > > > Now we have 72 timeslices. Now imagine with 67 batches completely out of > > order, the number timeslices can explode. > > Yes that part is clear, issue is to understand why is guc waiting for the > timeslice to expire.. > > > > In the commit you seem to acknowledge GuC does not do that but instead > > > ends > > > up waiting for the timeslice to expire, did I get that right? If so, why > > > > I think GuC waits for the timeslice to expire if a semaphore is > > unsatisfied, I have to double check on that. I thought that was what > > execlists were doing too but I now see it has a convoluted algorithm to > > yield the timeslice if subsequent request comes in and the ring is > > waiting on a timeslice. Let me check with GuC team and see if they can > > / are doing something similiar. I was thinking the only to switch a > > sempahore was clear CTX_CTRL_INHIBIT_SYN_CTX_SWITCH but that appears to > > be incorrect. > > .. so this will need clarifying with the firmware team. > They do not use the GT_WAIT_SEMAPHORE_INTERRUPT. However, we can clear CTX_CTRL_INHIBIT_SYN_CTX_SWITCH will result in more or less the same behavior as execlists but I'm suspect if that is the right solution. More on that below. > With execlists we enable and react on GT_WAIT_SEMAPHORE_INTERRUPT. If guc Because execlists does this, doesn't mean it is the spec or is correct. As far as I can tell this behavior is yet another thing just shoehorned into the execlists scheduler without a ton of thought or input from architecture about what the scheduler should look like or what the UMD needs actually are. If we change anything related to GuC scheduling there needs to be a clear need - again saying execlists does this is not an argument. There needs to be an agreement with architecture, the UMD teams, the i915 team, possibly the Windows team, and the GuC team before we make any changes. IMO the correct solution is to use tokens. Have uAPI interface which distributes tokens to the UMDs, the i915 clears context switch inhibit bit in the LRC if the user opted into tokens, and now semaphores switch out automatically and get rescheduled when the token is signaled. > does not, or can not, do that that could be worrying since userspace can and > does use semaphores legitimately so making it pay the timeslice penalty. > Well actually that has an effect to unrelated clients as well, not just the > semaphore user. Not buying this argument. Any user can submit a long running batch that always uses its full time slice and this affects unrelated clients. > > > For what is worth, after this change the run times of test are pretty > > similar for execlists & GuC on TGL. > > Yes, but the test was useful in this case since it found a weakness in guc > scheduling so it may not be the best approach to hide that. > Not a weakness, just a difference. Matt > Regards, > > Tvrtko > > > > > Matt > > > > > does the GuC does not do that and can we fix it? > > > > > > Regards, > > > > > > Tvrtko > > > > > > > > > > > Signed-off-by: Matthew Brost > > > > --- > > > >tests/i915/gem_exec_schedule.c | 16 +++- > > > >1 file changed, 15 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/tests/i915/gem_exec_schedule.c > > > > b/tests/i915/gem_exec_schedule.c > > > > index f03842478..41f2591a5 100644 > > > > --- a/tests/i915/gem_exec_schedule.c > > > >
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
== Series Details ==
Series: drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
URL : https://patchwork.freedesktop.org/series/93318/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
31185812783d drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#12:
commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock
gating")
total: 0 errors, 1 warnings, 0 checks, 76 lines checked
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_s: Update ADL-S PCI IDs
== Series Details == Series: drm/i915/adl_s: Update ADL-S PCI IDs URL : https://patchwork.freedesktop.org/series/93302/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20756_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20756_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] / [i915#3648]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb8/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-tglb6/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][8] ([i915#3354]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271]) +382 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_mmap_gtt@cpuset-big-copy: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#1888] / [i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-glk7/igt@gem_mmap_...@cpuset-big-copy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-glk5/igt@gem_mmap_...@cpuset-big-copy.html - shard-iclb: NOTRUN -> [FAIL][17] ([i915#2428]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy.html * igt@gem_pread@exhaustion: - shard-snb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-snb6/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-iclb3/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][20] ([i915#3002]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-snb2/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@allowed-all: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#2856]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-iclb3/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_sseu@full-enable: - shard-skl: [PASS][22] -> [FAIL][23] ([i915#3524]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/shard-skl1/igt@i915_pm_s...@full-enable.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/shard-skl2/igt@i915_pm_s...@full-enable.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][2
[Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled
CI test results/further experiments show that the workaround added in
commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock
gating")
can be applied only while DPLL0 is enabled. If it's disabled the
TRANS_CMTG_CHICKEN register is not accessible. Accordingly move the WA
to DPLL0 HW state sanitization and enabling.
This fixes an issue where the WA won't get applied (and a WARN is thrown
due to an unexpected value in TRANS_CMTG_CHICKEN) if the driver is
loaded without DPLL0 being enabled: booting without BIOS enabling an
output with this PLL, or reloading the driver.
While at it also add a debug print for the unexpected register value.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 18 --
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 34 ++-
2 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4ca354f154215..98f7fbede6226 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13284,24 +13284,6 @@ static void intel_early_display_was(struct
drm_i915_private *dev_priv)
KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
KBL_ARB_FILL_SPARE_14);
}
-
- if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
- u32 val;
-
- /*
-* Wa_16011069516:adl-p[a0]
-*
-* All CMTG regs are unreliable until CMTG clock gating is
-* disabled, so we can only assume the default CMTG_CHICKEN
-* reg value and sanity check this assumption with a double
-* read, which presumably returns the correct value even with
-* clock gating on.
-*/
- val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
- val = intel_de_read(dev_priv, TRANS_CMTG_CHICKEN);
- intel_de_write(dev_priv, TRANS_CMTG_CHICKEN,
DISABLE_DPT_CLK_GATING);
- drm_WARN_ON(&dev_priv->drm, val & ~DISABLE_DPT_CLK_GATING);
- }
}
static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 0d72917e5670f..5c91d125a3371 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3735,6 +3735,31 @@ static void icl_pll_enable(struct drm_i915_private
*dev_priv,
drm_err(&dev_priv->drm, "PLL %d not locked\n", pll->info->id);
}
+static void adlp_cmtg_clock_gating_wa(struct drm_i915_private *i915, struct
intel_shared_dpll *pll)
+{
+ u32 val;
+
+ if (!IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
+ pll->info->id != DPLL_ID_ICL_DPLL0)
+ return;
+ /*
+* Wa_16011069516:adl-p[a0]
+*
+* All CMTG regs are unreliable until CMTG clock gating is disabled,
+* so we can only assume the default TRANS_CMTG_CHICKEN reg value and
+* sanity check this assumption with a double read, which presumably
+* returns the correct value even with clock gating on.
+*
+* Instead of the usual place for workarounds we apply this one here,
+* since TRANS_CMTG_CHICKEN is only accessible while DPLL0 is enabled.
+*/
+ val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
+ val = intel_de_read(i915, TRANS_CMTG_CHICKEN);
+ intel_de_write(i915, TRANS_CMTG_CHICKEN, DISABLE_DPT_CLK_GATING);
+ if (drm_WARN_ON(&i915->drm, val & ~DISABLE_DPT_CLK_GATING))
+ drm_dbg_kms(&i915->drm, "Unexpected flags in
TRANS_CMTG_CHICKEN: %08x\n", val);
+}
+
static void combo_pll_enable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
@@ -3764,6 +3789,8 @@ static void combo_pll_enable(struct drm_i915_private
*dev_priv,
icl_pll_enable(dev_priv, pll, enable_reg);
+ adlp_cmtg_clock_gating_wa(dev_priv, pll);
+
/* DVFS post sequence would be here. See the comment above. */
}
@@ -4273,7 +4300,12 @@ void intel_dpll_readout_hw_state(struct drm_i915_private
*i915)
static void sanitize_dpll_state(struct drm_i915_private *i915,
struct intel_shared_dpll *pll)
{
- if (!pll->on || pll->active_mask)
+ if (!pll->on)
+ return;
+
+ adlp_cmtg_clock_gating_wa(i915, pll);
+
+ if (pll->active_mask)
return;
drm_dbg_kms(&i915->drm,
--
2.27.0
Re: [Intel-gfx] [PATCH v4 3/7] dyndbg: add dyndbg-bitmap definer and callbacks
On Mon, Aug 2, 2021 at 10:24 AM Emil Velikov wrote:
>
> Hi Jim,
>
> On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
>
> > +struct dyndbg_bitdesc {
> > + /* bitpos is inferred from index in containing array */
> > + char *prefix;
> > + char *help;
> AFAICT these two should also be constant, right?
>
>
> > +int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
> > +{
> > + unsigned int val;
> > + unsigned long changes, result;
> > + int rc, chgct = 0, totct = 0, bitpos, bitsmax;
> > + char query[OUR_QUERY_SIZE];
> > + struct dyndbg_bitdesc *bitmap = (struct dyndbg_bitdesc *) kp->data;
> > +
> > + // pr_info("set_dyndbg: instr: %s curr: %d\n", instr, *kp->arg);
> Left-over debug code, here and below?
yup, all fixed up locally, with a version that fully works.
thanks.
>
> -Emil
Re: [Intel-gfx] [PATCH v4 2/7] moduleparam: add data member to struct kernel_param
On Mon, Aug 2, 2021 at 10:18 AM Emil Velikov wrote:
>
> Hi Jim,
>
> On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
>
> > Use of this new data member will be rare, it might be worth redoing
> > this as a separate/sub-type to keep the base case.
> >
> > Signed-off-by: Jim Cromie
> > ---
> > include/linux/moduleparam.h | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> > index eed280fae433..e9495b1e794d 100644
> > --- a/include/linux/moduleparam.h
> > +++ b/include/linux/moduleparam.h
> > @@ -78,6 +78,7 @@ struct kernel_param {
> > const struct kparam_string *str;
> > const struct kparam_array *arr;
> > };
> > + void *data;
>
> Might as well make this "const void *" since it is a compile-time constant?
>
yes indeed. revising. thanks
> -Emil
[Intel-gfx] ✗ Fi.CI.BAT: failure for remove rcu support from i915_address_space
== Series Details ==
Series: remove rcu support from i915_address_space
URL : https://patchwork.freedesktop.org/series/93314/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10439 -> Patchwork_20761
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20761 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20761, 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_20761/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20761:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_20761 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka: NOTRUN -> [SKIP][7] ([fdo#109271]) +17 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html
* igt@i915_selftest@live@execlists:
- fi-kbl-7567u: [PASS][8] -> [INCOMPLETE][9] ([i915#2782] /
[i915#794])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-kbl-7567u/igt@i915_selftest@l...@execlists.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-kbl-7567u/igt@i915_selftest@l...@execlists.html
- fi-icl-y: [PASS][10] -> [INCOMPLETE][11] ([i915#2782])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-icl-y/igt@i915_selftest@l...@execlists.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8109u: NOTRUN -> [FAIL][12] ([i915#2426] / [i915#3363])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-cfl-8109u/igt@run...@aborted.html
- fi-icl-y: NOTRUN -> [FAIL][13] ([i915#2782] / [i915#3690])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-icl-y/igt@run...@aborted.html
- fi-kbl-7567u: NOTRUN -> [FAIL][14] ([i915#1436] / [i915#2426] /
[i915#3363])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-kbl-7567u/igt@run...@aborted.html
- fi-tgl-u2: NOTRUN -> [FAIL][15] ([i915#1436] / [i915#2966] /
[i915#3690])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-tgl-u2/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [INCOMPLETE][16] ([i915#2782] / [i915#2940]) ->
[PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- fi-kbl-soraka: [FAIL][18] ([i915#2122]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10439/fi-kbl-soraka/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20761/fi-kbl-soraka/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/i
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for remove rcu support from i915_address_space
== Series Details == Series: remove rcu support from i915_address_space URL : https://patchwork.freedesktop.org/series/93314/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -drivers/gpu/drm/i915/gem/i915_gem_context.c:1364:34:expected struct i915_address_space *vm -drivers/gpu/drm/i915/gem/i915_gem_context.c:1364:34:got struct i915_address_space [noderef] __rcu *vm -drivers/gpu/drm/i915/gem/i915_gem_context.c:1364:34: warning: incorrect type in argument 1 (different address spaces) -drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:expected struct i915_address_space [noderef] __rcu *vm -drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:got struct i915_address_space * -drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:expected struct i915_address_space *vm -drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:got struct i915_address_space [noderef] __rcu *vm -drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/display/intel_display.c:1901:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1901:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1901:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:698:33: error: incompatible types in comparison expression (different address spaces): +drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:698:33:struct i915_address_space * +drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:698:33:struct i915_address_space [noderef] __rcu * +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warnin
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for remove rcu support from i915_address_space
== Series Details ==
Series: remove rcu support from i915_address_space
URL : https://patchwork.freedesktop.org/series/93314/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a853815d3335 drm/i915: Drop code to handle set-vm races from execbuf
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
References: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running
contexts (v4)")
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ccbc1b97948a ("drm/i915/gem:
Don't allow changing the VM on running contexts (v4)")'
#17:
References: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running
contexts (v4)")
-:46: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 2 warnings, 0 checks, 12 lines checked
aa6df2fc9251 drm/i915: Rename i915_gem_context_get_vm_rcu to
i915_gem_context_get_eb_vm
-:148: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 80 lines checked
20c77ecc9eb2 drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam
-:54: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 23 lines checked
9e17d78e71b6 drm/i915: Add i915_gem_context_is_full_ppgtt
-:94: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 45 lines checked
fd4782224117 drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ccbc1b97948a ("drm/i915/gem:
Don't allow changing the VM on running contexts (v4)")'
#12:
commit ccbc1b97948ab671335e950271e39766729736c3
-:61: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 18 lines checked
7f70a2efa858 drm/i915: Drop __rcu from gem_context->vm
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ccbc1b97948a ("drm/i915/gem:
Don't allow changing the VM on running contexts (v4)")'
#11:
commit ccbc1b97948ab671335e950271e39766729736c3
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
i915_vm_open ofc. This also removes the final caller of context_get_vm_rcu
-:42: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a4e7ccdac38e ("drm/i915: Move
context management under GEM")'
#42:
commit a4e7ccdac38ec8335d9e4e2656c1a041c77feae1
-:345: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 2 errors, 2 warnings, 0 checks, 232 lines checked
1b7a4cebddcd drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit aabbe344dc3c ("drm/i915: Use RCU
for unlocked vm_idr lookup")'
#15:
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
-:52: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 13 lines checked
e446a68d6f87 drm/i915: Stop rcu support for i915_address_space
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
-:27: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit cf977e18610e ("drm/i915/gem:
Spring clean debugfs")'
#27:
commit cf977e18610e66e48c31619e7e0cfa871be9eada
-:35: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit db80a1294c23 ("drm/i915/gem:
Remove per-client stats from debugfs/i915_gem_objects")'
#35:
commit db80a1294c231b6ac725085f046bb2931e00c9db
-:47: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ccbc1b97948a ("drm/i915/gem:
Don't allow changing the VM on running contexts (v4)")'
#47:
commit ccbc1b97948ab671335e950271e39766729736c3
-:59: WARNING:TYPO_SPELLING: 'Preceeding' may be misspelled - perhaps
'Preceding'?
#59:
Preceeding patches removed all vestiges of rcu use from gem_ctx->vm
^^
-:64: ERROR:G
Re: [Intel-gfx] [PATCH v4 5/7] i915/gvt: control pr_debug("gvt:")s with bits in parameters/debug_gvt
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc",
> { "gvt: cmd: ", "command processing" },
> { "gvt: core: ", "core help" },
> { "gvt: dpy: ", "display help" },
> { "gvt: el: ", "help" },
> { "gvt: irq: ", "help" },
> { "gvt: mm: ", "help" },
> { "gvt: mmio: ", "help" },
> { "gvt: render: ", "help" },
> { "gvt: sched: " "help" });
>
Previous commit removed the space after the colon. The above example
needs updating.
This concludes a casual read-through on my end. Hope it helps o/
-Emil
Re: [Intel-gfx] [PATCH v4 3/7] dyndbg: add dyndbg-bitmap definer and callbacks
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> +struct dyndbg_bitdesc {
> + /* bitpos is inferred from index in containing array */
> + char *prefix;
> + char *help;
AFAICT these two should also be constant, right?
> +int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
> +{
> + unsigned int val;
> + unsigned long changes, result;
> + int rc, chgct = 0, totct = 0, bitpos, bitsmax;
> + char query[OUR_QUERY_SIZE];
> + struct dyndbg_bitdesc *bitmap = (struct dyndbg_bitdesc *) kp->data;
> +
> + // pr_info("set_dyndbg: instr: %s curr: %d\n", instr, *kp->arg);
Left-over debug code, here and below?
-Emil
Re: [Intel-gfx] [PATCH v4 2/7] moduleparam: add data member to struct kernel_param
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> Use of this new data member will be rare, it might be worth redoing
> this as a separate/sub-type to keep the base case.
>
> Signed-off-by: Jim Cromie
> ---
> include/linux/moduleparam.h | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index eed280fae433..e9495b1e794d 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -78,6 +78,7 @@ struct kernel_param {
> const struct kparam_string *str;
> const struct kparam_array *arr;
> };
> + void *data;
Might as well make this "const void *" since it is a compile-time constant?
-Emil
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs
Re-reported. -Original Message- From: Deak, Imre Sent: Monday, August 2, 2021 4:23 AM To: intel-gfx@lists.freedesktop.org; Gupta, Anshuman ; Vudum, Lakshminarayana Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs On Thu, Jul 29, 2021 at 10:27:29PM +, Patchwork wrote: > == Series Details == > > Series: lpsp with hdmi/dp outputs > URL : https://patchwork.freedesktop.org/series/93179/ > State : failure Thanks for the patch pushed it to -din, fixing some typos in the commit message and the playback domain name while applying. The SKL failure looks unrelated, since nothing changes there, maybe we are only missing the trace_clock=global kernel param on that machine. > > == Summary == > > CI Bug Log - changes from CI_DRM_10418_full -> Patchwork_20740_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20740_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20740_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20740_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: > - shard-skl: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl1/ig > t@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html > > > Known issues > > > Here are the changes found in Patchwork_20740_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@smoketest: > - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +5 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-snb6/ig > t@gem_ctx_persiste...@smoketest.html > > * igt@gem_eio@reset-stress: > - shard-skl: [PASS][4] -> [FAIL][5] ([i915#2771]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl1/igt@gem_...@reset-stress.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl4/ig > t@gem_...@reset-stress.html > > * igt@gem_exec_fair@basic-pace@bcs0: > - shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-iclb7/igt@gem_exec_fair@basic-p...@bcs0.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-iclb6/i > gt@gem_exec_fair@basic-p...@bcs0.html > > * igt@gem_exec_fair@basic-throttle@rcs0: > - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html > - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2849]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-iclb4/i > gt@gem_exec_fair@basic-throt...@rcs0.html > > * igt@gem_huc_copy@huc-copy: > - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-tglb5/igt@gem_huc_c...@huc-copy.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-tglb6/igt@gem_huc_c...@huc-copy.html > - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl2/ig > t@gem_huc_c...@huc-copy.html > > * igt@gem_mmap_gtt@cpuset-big-copy-odd: > - shard-glk: [PASS][15] -> [FAIL][16] ([i915#1888] / [i915#307]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-glk8/igt@gem_mmap_...@cpuset-big-copy-odd.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-glk1/ig > t@gem_mmap_...@cpuset-big-copy-odd.html > > * igt@gem_pread@exhaustion: > - shard-apl: NOTRUN -> [WARN][17] ([i915#2658]) +1 similar issue >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl2/ig > t@gem_pr...@exhaustion.html > > * igt@gen9_exec_parse@allowed-single: > - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1436] / > [i915#1982] / [i915#716]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/sha
[Intel-gfx] [PATCH 9/9] drm/i915: Split out intel_context_create_user
There's quite a fundamental difference between userspace contexts, and
kernel contexts. Latter all share intel_gt->vm, former get their vm
from gem_ctx->vm (on full ppgtt at least).
By splitting context creation for userspace from kernel-internal ones
we can make this all a bit more strict and WARN_ON if there's a vm
already set in intel_context_set_gem().
All this is only possible because gem_ctx cannot chance their VM
anymore since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +++-
.../gpu/drm/i915/gem/selftests/mock_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.c | 22 +--
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
5 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 2f3cc73d4710..13358e6749d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -746,7 +746,7 @@ static int intel_context_set_gem(struct intel_context *ce,
ce->ring_size = SZ_16K;
- i915_vm_put(ce->vm);
+ WARN_ON(ce->vm);
ce->vm = i915_gem_context_get_eb_vm(ctx);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
@@ -856,7 +856,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx,
GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
GEM_BUG_ON(e->engines[engine->legacy_idx]);
- ce = intel_context_create(engine);
+ ce = intel_context_create_user(engine);
if (IS_ERR(ce)) {
err = ERR_CAST(ce);
goto free_engines;
@@ -897,7 +897,7 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
switch (pe[n].type) {
case I915_GEM_ENGINE_TYPE_PHYSICAL:
- ce = intel_context_create(pe[n].engine);
+ ce = intel_context_create_user(pe[n].engine);
break;
case I915_GEM_ENGINE_TYPE_BALANCED:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bdf2b5785a81..54de94433365 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -30,15 +30,17 @@
struct eb_vma {
struct i915_vma *vma;
+ struct drm_i915_gem_object *obj;
unsigned int flags;
+ u32 handle;
+
/** This vma's place in the execbuf reservation list */
struct drm_i915_gem_exec_object2 *exec;
struct list_head bind_link;
struct list_head reloc_link;
struct hlist_node node;
- u32 handle;
};
enum {
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
index fee070df1c97..e5efda1058a3 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
@@ -124,7 +124,7 @@ live_context_for_engine(struct intel_engine_cs *engine,
struct file *file)
return ctx;
}
- ce = intel_context_create(engine);
+ ce = intel_context_create_user(engine);
if (IS_ERR(ce)) {
__free_engines(engines, 0);
return ERR_CAST(ce);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 745e84c72c90..9e33efb594dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -34,6 +34,23 @@ void intel_context_free(struct intel_context *ce)
call_rcu(&ce->rcu, rcu_context_free);
}
+/* for user contexts, callers must set ce->vm correctly */
+struct intel_context *
+intel_context_create_user(struct intel_engine_cs *engine)
+{
+ struct intel_context *ce;
+
+ ce = intel_context_alloc();
+ if (!ce)
+ return ERR_PTR(-ENOMEM);
+
+ intel_context_init(ce, engine);
+
+ trace_intel_context_create(ce);
+ return ce;
+}
+
+/* for kernel-internal users only, sets ce->vm to intel_gt.vm */
struct intel_context *
intel_context_create(struct intel_engine_cs *engine)
{
@@ -44,6 +61,8 @@ intel_context_create(struct intel_engine_cs *engine)
return ERR_PTR(-ENOMEM);
intel_context_init(ce, engine);
+ ce->vm = i915_vm_get(engine->gt->vm);
+
trace_
[Intel-gfx] [PATCH 8/9] drm/i915: Stop rcu support for i915_address_space
The full audit is quite a bit of work: - i915_dpt has very simple lifetime (somehow we create a display pagetable vm per object, so its _very_ simple, there's only ever a single vma in there), and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu. Aside: wtf is i915_dpt doing in the intel_display.c garbage collector as a new feature, instead of added as a separate file with some clean-ish interface. Also, i915_dpt unfortunately re-introduces some coding patterns from pre-dma_resv_lock conversion times. - i915_gem_proto_ctx is fully refcounted and no rcu, all protected by fpriv->proto_context_lock. - i915_gem_context is itself rcu protected, and that might leak to anything it points at. Before commit cf977e18610e66e48c31619e7e0cfa871be9eada Author: Chris Wilson Date: Wed Dec 2 11:21:40 2020 + drm/i915/gem: Spring clean debugfs and commit db80a1294c231b6ac725085f046bb2931e00c9db Author: Chris Wilson Date: Mon Jan 18 11:08:54 2021 + drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects we had a bunch of debugfs files that relied on rcu protecting everything, but those are gone now. The main one was removed even earlier with There doesn't seem to be anything left that's actually protecting stuff now that the ctx->vm itself is invariant. See commit ccbc1b97948ab671335e950271e39766729736c3 Author: Jason Ekstrand Date: Thu Jul 8 10:48:30 2021 -0500 drm/i915/gem: Don't allow changing the VM on running contexts (v4) Note that we drop the vm refcount before the final release of the gem context refcount, so this is all very dangerous even without rcu. Note that aside from later on creating new engines (a defunct feature) and debug output we're never looked at gem_ctx->vm for anything functional, hence why this is ok. Fingers crossed. Preceeding patches removed all vestiges of rcu use from gem_ctx->vm derferencing to make it clear it's really not used. The gem_ctx->rcu protection was introduced in commit a4e7ccdac38ec8335d9e4e2656c1a041c77feae1 Author: Chris Wilson Date: Fri Oct 4 14:40:09 2019 +0100 drm/i915: Move context management under GEM The commit message is somewhat entertaining because it fails to mention this fact completely, and compensates that by an in-commit changelog entry that claims that ctx->vm is protected by ctx->mutex. Which was the case _before_ this commit, but no longer after it. - intel_context holds a full reference. Unfortunately intel_context is also rcu protected and the reference to the ->vm is dropped before the rcu barrier - only the kfree is delayed. So again we need to check whether that leaks anywhere on the intel_context->vm. RCU is only used to protect intel_context sitting on the breadcrumb lists, which don't look at the vm anywhere, so we are fine. Nothing else relies on rcu protection of intel_context and hence is fully protected by the kref refcount alone, which protects intel_context->vm in turn. The breadcrumbs rcu usage was added in commit c744d50363b714783bbc88d986cc16def13710f7 Author: Chris Wilson Date: Thu Nov 26 14:04:06 2020 + drm/i915/gt: Split the breadcrumb spinlock between global and contexts its parent commit added the intel_context rcu protection: commit 14d1eaf08845c534963c83f754afe0cb14cb2512 Author: Chris Wilson Date: Thu Nov 26 14:04:05 2020 + drm/i915/gt: Protect context lifetime with RCU given some credence to my claim that I've actually caught them all. - drm_i915_gem_object's shares_resv_from pointer has a full refcount to the dma_resv, which is a sub-refcount that's released after the final i915_vm_put() has been called. Safe. Aside: Maybe we should have a struct dma_resv_shared which is just dma_resv + kref as a stand-alone thing. It's a pretty useful pattern which other drivers might want to copy. For a bit more context see commit 4d8151ae5329cf50781a02fd2298a909589a5bab Author: Thomas Hellström Date: Tue Jun 1 09:46:41 2021 +0200 drm/i915: Don't free shared locks while shared - the fpriv->vm_xa was relying on rcu_read_lock for lookup, but that was updated in a prep patch too to just be a spinlock-protected lookup. - intel_gt->vm is set at driver load in intel_gt_init() and released in intel_gt_driver_release(). There seems to be some issue that in some error paths this is called twice, but otherwise no rcu to be found anywhere. This was added in the below commit, which unfortunately doesn't explain why this complication exists. commit e6ba76480299a0d77c51d846f7467b1673aad25b Author: Chris Wilson Date: Sat Dec 21 16:03:24 2019 + drm/i915: Remove i915->kernel_cont
[Intel-gfx] [PATCH 7/9] drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups
We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.
Note that this semantically reverts
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson
Date: Fri Aug 30 19:03:25 2019 +0100
drm/i915: Use RCU for unlocked vm_idr lookup
except we have the conversion from idr to xarray in between.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1488d166d91c..df2d723c894a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1880,11 +1880,11 @@ i915_gem_vm_lookup(struct drm_i915_file_private
*file_priv, u32 id)
{
struct i915_address_space *vm;
- rcu_read_lock();
+ xa_lock(&file_priv->vm_xa);
vm = xa_load(&file_priv->vm_xa, id);
if (vm && !kref_get_unless_zero(&vm->ref))
vm = NULL;
- rcu_read_unlock();
+ xa_unlock(&file_priv->vm_xa);
return vm;
}
--
2.32.0
[Intel-gfx] [PATCH 6/9] drm/i915: Drop __rcu from gem_context->vm
It's been invariant since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
this just completes the deed. I've tried to split out prep work for
more careful review as much as possible, this is what's left:
- get_ppgtt gets simplified since we don't need to grab a temporary
reference - we can rely on the temporary reference for the gem_ctx
while we inspect the vm. The new vm_id still needs a full
i915_vm_open ofc. This also removes the final caller of context_get_vm_rcu
- A pile of selftests can now just look at ctx->vm instead of
rcu_dereference_protected( , true) or similar things.
- All callers of i915_gem_context_vm also disappear.
- I've changed the hugepage selftest to set scrub_64K without any
locking, because when we inspect that setting we're also not taking
any locks either. It works because it's a selftests that's careful
(single threaded gives you nice ordering) and not a live driver
where races can happen from anywhere.
These can only be split up further if we have some intermediate state
with a bunch more rcu_dereference_protected(ctx->vm, true), just to
shut up lockdep and sparse.
The conversion to __rcu happened in
commit a4e7ccdac38ec8335d9e4e2656c1a041c77feae1
Author: Chris Wilson
Date: Fri Oct 4 14:40:09 2019 +0100
drm/i915: Move context management under GEM
Note that we're not breaking the actual bugfix in there: The real
bugfix is pushing the i915_vm_relase onto a separate worker, to avoid
locking inversion issues. The rcu conversion was just thrown in for
entertainment value on top (no vm lookup isn't even close to anything
that's a hotpath where removing the single spinlock can be measured).
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 53 ++-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 14 ++---
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 24 -
drivers/gpu/drm/i915/i915_trace.h | 2 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
7 files changed, 21 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd24a1236682..2f3cc73d4710 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -735,44 +735,6 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
return ret;
}
-static struct i915_address_space *
-context_get_vm_rcu(struct i915_gem_context *ctx)
-{
- GEM_BUG_ON(!rcu_access_pointer(ctx->vm));
-
- do {
- struct i915_address_space *vm;
-
- /*
-* We do not allow downgrading from full-ppgtt [to a shared
-* global gtt], so ctx->vm cannot become NULL.
-*/
- vm = rcu_dereference(ctx->vm);
- if (!kref_get_unless_zero(&vm->ref))
- continue;
-
- /*
-* This ppgtt may have be reallocated between
-* the read and the kref, and reassigned to a third
-* context. In order to avoid inadvertent sharing
-* of this ppgtt with that third context (and not
-* src), we have to confirm that we have the same
-* ppgtt after passing through the strong memory
-* barrier implied by a successful
-* kref_get_unless_zero().
-*
-* Once we have acquired the current ppgtt of ctx,
-* we no longer care if it is released from ctx, as
-* it cannot be reallocated elsewhere.
-*/
-
- if (vm == rcu_access_pointer(ctx->vm))
- return rcu_pointer_handoff(vm);
-
- i915_vm_put(vm);
- } while (1);
-}
-
static int intel_context_set_gem(struct intel_context *ce,
struct i915_gem_context *ctx,
struct intel_sseu sseu)
@@ -1193,7 +1155,7 @@ static void context_close(struct i915_gem_context *ctx)
set_closed_name(ctx);
- vm = i915_gem_context_vm(ctx);
+ vm = ctx->vm;
if (vm)
i915_vm_close(vm);
@@ -1350,7 +1312,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
vm = &ppgtt->vm;
}
if (vm) {
- RCU_INIT_POINTER(ctx->vm, i915_vm_open(vm));
+ ctx->vm = i915_vm_open(vm);
/* i915_vm_open() tak
[Intel-gfx] [PATCH 5/9] drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem
Since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
the gem_ctx->vm can't change anymore. Plus we always set the
intel_context->vm, so might as well use the helper we have for that.
This makes it very clear that we always overwrite intel_context->vm
for userspace contexts, since the default is gt->vm, which is
explicitly reserved for kernel context use. It would be good to split
things up a bit further and avoid any possibility for an accident
where we run kernel stuff in userspace vm or the other way round.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a80b06c98dba..fd24a1236682 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -784,16 +784,8 @@ static int intel_context_set_gem(struct intel_context *ce,
ce->ring_size = SZ_16K;
- if (rcu_access_pointer(ctx->vm)) {
- struct i915_address_space *vm;
-
- rcu_read_lock();
- vm = context_get_vm_rcu(ctx); /* hmm */
- rcu_read_unlock();
-
- i915_vm_put(ce->vm);
- ce->vm = vm;
- }
+ i915_vm_put(ce->vm);
+ ce->vm = i915_gem_context_get_eb_vm(ctx);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine) &&
--
2.32.0
[Intel-gfx] [PATCH 4/9] drm/i915: Add i915_gem_context_is_full_ppgtt
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in ggtt mode, unlike intel_context->vm or gt->vm,
which is always set.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 7 +++
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6263563e15d6..a80b06c98dba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1581,7 +1581,7 @@ static int get_ppgtt(struct drm_i915_file_private
*file_priv,
int err;
u32 id;
- if (!rcu_access_pointer(ctx->vm))
+ if (!i915_gem_context_is_full_ppgtt(ctx))
return -ENODEV;
rcu_read_lock();
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index da6e8b506d96..37536a260e6e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -154,6 +154,13 @@ i915_gem_context_vm(struct i915_gem_context *ctx)
return rcu_dereference_protected(ctx->vm, lockdep_is_held(&ctx->mutex));
}
+static inline bool i915_gem_context_is_full_ppgtt(struct i915_gem_context *ctx)
+{
+ GEM_BUG_ON(!!rcu_access_pointer(ctx->vm) != HAS_FULL_PPGTT(ctx->i915));
+
+ return !!rcu_access_pointer(ctx->vm);
+}
+
static inline struct i915_address_space *
i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 69e47b97d786..bdf2b5785a81 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -749,7 +749,7 @@ static int eb_select_context(struct i915_execbuffer *eb)
return PTR_ERR(ctx);
eb->gem_context = ctx;
- if (rcu_access_pointer(ctx->vm))
+ if (i915_gem_context_is_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
return 0;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index d436ce7fa25c..5442b8e59629 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -838,7 +838,7 @@ static int igt_shared_ctx_exec(void *arg)
pr_err("Failed to fill dword %lu [%lu/%lu] with
gpu (%s) [full-ppgtt? %s], err=%d\n",
ndwords, dw, max_dwords(obj),
engine->name,
- yesno(!!rcu_access_pointer(ctx->vm)),
+
yesno(i915_gem_context_is_full_ppgtt(ctx)),
err);
intel_context_put(ce);
kernel_context_close(ctx);
@@ -1417,7 +1417,7 @@ static int igt_ctx_readonly(void *arg)
pr_err("Failed to fill dword %lu [%lu/%lu] with
gpu (%s) [full-ppgtt? %s], err=%d\n",
ndwords, dw, max_dwords(obj),
ce->engine->name,
- yesno(!!ctx_vm(ctx)),
+
yesno(i915_gem_context_is_full_ppgtt(ctx)),
err);
i915_gem_context_unlock_engines(ctx);
goto out_file;
--
2.32.0
[Intel-gfx] [PATCH 3/9] drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cff72679ad7c..6263563e15d6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2124,6 +2124,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_gem_context_param *args = data;
struct i915_gem_context *ctx;
+ struct i915_address_space *vm;
int ret = 0;
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
@@ -2133,12 +2134,10 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
switch (args->param) {
case I915_CONTEXT_PARAM_GTT_SIZE:
args->size = 0;
- rcu_read_lock();
- if (rcu_access_pointer(ctx->vm))
- args->value = rcu_dereference(ctx->vm)->total;
- else
- args->value = to_i915(dev)->ggtt.vm.total;
- rcu_read_unlock();
+ vm = i915_gem_context_get_eb_vm(ctx);
+ args->value = vm->total;
+ i915_vm_put(vm);
+
break;
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
--
2.32.0
[Intel-gfx] [PATCH 2/9] drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm
The important part isn't so much that this does an rcu lookup - that's
more an implementation detail, which will also be removed.
The thing that makes this different from other functions is that it's
gettting you the vm that batchbuffers will run in for that gem
context, which is either a full ppgtt stored in gem->ctx, or the ggtt.
We'll make more use of this function later on.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 18060536b0c2..da6e8b506d96 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -155,7 +155,7 @@ i915_gem_context_vm(struct i915_gem_context *ctx)
}
static inline struct i915_address_space *
-i915_gem_context_get_vm_rcu(struct i915_gem_context *ctx)
+i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
{
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index a094f3ce1a90..6c68fe26bb32 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1456,7 +1456,7 @@ static int igt_tmpfs_fallback(void *arg)
struct i915_gem_context *ctx = arg;
struct drm_i915_private *i915 = ctx->i915;
struct vfsmount *gemfs = i915->mm.gemfs;
- struct i915_address_space *vm = i915_gem_context_get_vm_rcu(ctx);
+ struct i915_address_space *vm = i915_gem_context_get_eb_vm(ctx);
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
u32 *vaddr;
@@ -1512,7 +1512,7 @@ static int igt_shrink_thp(void *arg)
{
struct i915_gem_context *ctx = arg;
struct drm_i915_private *i915 = ctx->i915;
- struct i915_address_space *vm = i915_gem_context_get_vm_rcu(ctx);
+ struct i915_address_space *vm = i915_gem_context_get_eb_vm(ctx);
struct drm_i915_gem_object *obj;
struct i915_gem_engines_iter it;
struct intel_context *ce;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 8eb5050f8cb3..d436ce7fa25c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1528,7 +1528,7 @@ static int write_to_scratch(struct i915_gem_context *ctx,
intel_gt_chipset_flush(engine->gt);
- vm = i915_gem_context_get_vm_rcu(ctx);
+ vm = i915_gem_context_get_eb_vm(ctx);
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
@@ -1607,7 +1607,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
if (GRAPHICS_VER(i915) >= 8) {
const u32 GPR0 = engine->mmio_base + 0x600;
- vm = i915_gem_context_get_vm_rcu(ctx);
+ vm = i915_gem_context_get_eb_vm(ctx);
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index f12ffe797639..b3863abc51f5 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -3493,7 +3493,7 @@ static int smoke_submit(struct preempt_smoke *smoke,
if (batch) {
struct i915_address_space *vm;
- vm = i915_gem_context_get_vm_rcu(ctx);
+ vm = i915_gem_context_get_eb_vm(ctx);
vma = i915_vma_instance(batch, vm, NULL);
i915_vm_put(vm);
if (IS_ERR(vma))
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 08f011f893b2..6023c418ee8a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -117,7 +117,7 @@ static struct i915_request *
hang_create_request(struct hang *h, struct intel_engine_cs *engine)
{
struct intel_gt *gt = h->gt;
- struct i915_address_space *vm = i915_gem_context_get_vm_rcu(h->ctx);
+ struct i915_address_space *vm = i915_gem_context_get_eb_vm(h->ctx);
st
[Intel-gfx] [PATCH 1/9] drm/i915: Drop code to handle set-vm races from execbuf
Changing the vm from a finalized gem ctx is no longer possible, which
means we don't have to check for that anymore.
I was pondering whether to keep the check as a WARN_ON, but things go
boom real bad real fast if the vm of a vma is wrong. Plus we'd need to
also get the ggtt vm for !full-ppgtt platforms. Ditching it all seemed
like a better idea.
References: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running
contexts (v4)")
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 538d9d2e52b7..69e47b97d786 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -775,11 +775,7 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
/* Check that the context hasn't been closed in the meantime */
err = -EINTR;
if (!mutex_lock_interruptible(&ctx->lut_mutex)) {
- struct i915_address_space *vm = rcu_access_pointer(ctx->vm);
-
- if (unlikely(vm && vma->vm != vm))
- err = -EAGAIN; /* user racing with ctx set-vm */
- else if (likely(!i915_gem_context_is_closed(ctx)))
+ if (likely(!i915_gem_context_is_closed(ctx)))
err = radix_tree_insert(&ctx->handles_vma, handle, vma);
else
err = -ENOENT;
--
2.32.0
[Intel-gfx] [PATCH 0/9] remove rcu support from i915_address_space
Hi all, Jason wanted to do that as part of the scheduler series, but I object since rcu is very, very hard to review when adding, and much, much harder even to review when removing. This is because simply looking for __rcu pointer annotations and rcu functions isn't enough, rcu is also relied upon in many datastructures which have internally and rcu_read_lock protection (or at least the required amount of barriers), like xarray. The other problem is that it inherits when chasing pointers, e.g. i915_gem_engines has an rcu pointer to intel_context, which has a non-rcu pointer to i915_address_space. But since we could look-up the entire chain under rcu i.e. engines->context[i]->vm this means more code to audit. The audit explodes pretty quickly. Anyway I'm reasonable confident I got them all in the current code, and slightly less confident that I managed to stitch together the full history. References to relevant commits throughout the series. Cheers, Daniel Daniel Vetter (9): drm/i915: Drop code to handle set-vm races from execbuf drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam drm/i915: Add i915_gem_context_is_full_ppgtt drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem drm/i915: Drop __rcu from gem_context->vm drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups drm/i915: Stop rcu support for i915_address_space drm/i915: Split out intel_context_create_user drivers/gpu/drm/i915/gem/i915_gem_context.c | 82 --- drivers/gpu/drm/i915/gem/i915_gem_context.h | 13 ++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 12 ++- .../gpu/drm/i915/gem/selftests/huge_pages.c | 8 +- .../drm/i915/gem/selftests/i915_gem_context.c | 32 +++- .../gpu/drm/i915/gem/selftests/mock_context.c | 2 +- drivers/gpu/drm/i915/gt/intel_context.c | 22 - drivers/gpu/drm/i915/gt/intel_context.h | 2 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 - drivers/gpu/drm/i915/gt/intel_gtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 4 +- drivers/gpu/drm/i915/i915_trace.h | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 4 +- 18 files changed, 79 insertions(+), 123 deletions(-) -- 2.32.0
[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_display.c
between commit:
b4bde5554f70 ("drm/i915/display: split DISPLAY_VER 9 and 10 in
intel_setup_outputs()")
from Linus' tree and commits:
cad83b405fe4 ("drm/i915/display: remove PORT_F workaround for CNL")
ec387b8ff8d7 ("drm/i915/display: split DISPLAY_VER 9 and 10 in
intel_setup_outputs()")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/gpu/drm/i915/display/intel_display.c
index 557871ee07db,3faedcb7ef42..
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
[Intel-gfx] ✓ Fi.CI.IGT: success for lpsp with hdmi/dp outputs
== Series Details == Series: lpsp with hdmi/dp outputs URL : https://patchwork.freedesktop.org/series/93179/ State : success == Summary == CI Bug Log - changes from CI_DRM_10418_full -> Patchwork_20740_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20740_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-snb6/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@reset-stress: - shard-skl: [PASS][2] -> [FAIL][3] ([i915#2771]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl1/igt@gem_...@reset-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl4/igt@gem_...@reset-stress.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-iclb7/igt@gem_exec_fair@basic-p...@bcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-iclb6/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2849]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-tglb5/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-tglb6/igt@gem_huc_c...@huc-copy.html - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl2/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#1888] / [i915#307]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-glk8/igt@gem_mmap_...@cpuset-big-copy-odd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-glk1/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][15] ([i915#2658]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl2/igt@gem_pr...@exhaustion.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][16] -> [DMESG-WARN][17] ([i915#1436] / [i915#1982] / [i915#716]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl5/igt@gen9_exec_pa...@allowed-single.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl1/igt@i915_module_l...@reload-with-fault-injection.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl4/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1937]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl1/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_pm_rpm@basic-rte: - shard-apl: NOTRUN -> [FAIL][21] ([i915#579]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl6/igt@i915_pm_...@basic-rte.html * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][22] ([i915#3722]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl8/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip: - shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3777]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl6/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip: - shard-kbl: NOTRUN -> [SKIP][24] ([fdo#109271]
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_device_info.c
between commit:
0f9ed3b2c9ec ("drm/i915/display/cnl+: Handle fused off DSC")
from the drm-intel-fixes tree and commit:
a4d082fc194a ("drm/i915: rename/remove CNL registers")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/gpu/drm/i915/intel_device_info.c
index e0a10f36acc1,305facedd284..
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
== Series Details ==
Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
URL : https://patchwork.freedesktop.org/series/93307/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20760
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/index.html
Known issues
Here are the changes found in Patchwork_20760 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_exec_parallel@engines@userptr:
- fi-pnv-d510:[PASS][2] -> [INCOMPLETE][3] ([i915#299])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][4] ([i915#2403] / [i915#2505] /
[i915#2722])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-pnv-d510/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: [SKIP][5] ([fdo#109271]) -> [PASS][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-7500u: [SKIP][7] ([fdo#109271]) -> [PASS][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-kbl-7500u/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-kbl-7500u/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-soraka: [SKIP][9] ([fdo#109271]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-kbl-soraka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-kbl-soraka/igt@i915_pm_...@basic-pci-d3-state.html
- fi-hsw-4770:[SKIP][11] ([fdo#109271]) -> [PASS][12] +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bxt-dsi: [SKIP][13] ([fdo#109271]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-bxt-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-bxt-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}: [SKIP][15] ([i915#579]) -> [PASS][16] +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-7500u: [FAIL][17] ([i915#579]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-kbl-7500u/igt@i915_pm_...@basic-rte.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-kbl-7500u/igt@i915_pm_...@basic-rte.html
- fi-cml-u2: [FAIL][19] ([i915#579]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-cml-u2/igt@i915_pm_...@basic-rte.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-cml-u2/igt@i915_pm_...@basic-rte.html
- fi-bxt-dsi: [FAIL][21] ([i915#579]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-bxt-dsi/igt@i915_pm_...@basic-rte.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-bxt-dsi/igt@i915_pm_...@basic-rte.html
- fi-hsw-4770:[FAIL][23] ([i915#579]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-hsw-4770/igt@i915_pm_...@basic-rte.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-hsw-4770/igt@i915_pm_...@basic-rte.html
- fi-tgl-1115g4: [FAIL][25] ([i915#579]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20760/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
- fi-cfl-guc: [FAIL][27] ([i915#579]) -> [PASS][28]
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-cfl-guc/igt@i915_pm_...@basic-rte.html
[28]:
https://intel-gfx-ci.01.org/
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
== Series Details ==
Series: drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
URL : https://patchwork.freedesktop.org/series/93306/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20759
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/index.html
Known issues
Here are the changes found in Patchwork_20759 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][2] -> [FAIL][3] ([i915#1372])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][4] ([i915#2782] / [i915#2940]) ->
[PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][6] ([i915#3303]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (37 -> 33)
--
Missing(4): fi-bdw-samus fi-bsw-cyan bat-jsl-1 fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10437 -> Patchwork_20759
CI-20190529: 20190529
CI_DRM_10437: fe234200649024b4fb5164d99eca74d62ae696d4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6159: 6135b9cc319ed965e3aafb5b2ae2abf4762a06b2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20759: fee101cc54244bb229d19fe4763546f0ec319242 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fee101cc5424 drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20759/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
== Series Details == Series: drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg URL : https://patchwork.freedesktop.org/series/93306/ State : warning == Summary == $ dim checkpatch origin/drm-tip fee101cc5424 drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: Dithering BPC, with valid values of 6, 8, 10 BPC, with Dithering bit enabled. total: 0 errors, 1 warnings, 0 checks, 60 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for locking/lockdep, drm: apply new lockdep assert in drm_auth.c
== Series Details ==
Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c
URL : https://patchwork.freedesktop.org/series/93304/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20757
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/index.html
Known issues
Here are the changes found in Patchwork_20757 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([i915#1372])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-tgl-1115g4: [PASS][3] -> [DMESG-WARN][4] ([i915#1887])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-tgl-1115g4/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/fi-tgl-1115g4/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@runner@aborted:
- fi-tgl-1115g4: NOTRUN -> [FAIL][5] ([i915#1602])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/fi-tgl-1115g4/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][6] ([i915#3303]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@runner@aborted:
- fi-bsw-nick:[FAIL][8] ([fdo#109271] / [i915#1436] / [i915#2722])
-> [FAIL][9] ([fdo#109271] / [i915#1436])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-bsw-nick/igt@run...@aborted.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/fi-bsw-nick/igt@run...@aborted.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#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1887]: https://gitlab.freedesktop.org/drm/intel/issues/1887
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (37 -> 33)
--
Missing(4): fi-bdw-samus fi-bsw-cyan bat-jsl-1 fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10437 -> Patchwork_20757
CI-20190529: 20190529
CI_DRM_10437: fe234200649024b4fb5164d99eca74d62ae696d4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6159: 6135b9cc319ed965e3aafb5b2ae2abf4762a06b2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20757: e5ac4247380127f8c096980bf09829f0ee291d4d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e5ac42473801 drm: add lockdep assert to drm_is_current_master_locked
60bc4f495a48 locking/lockdep: Provide lockdep_assert{, _once}() helpers
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20757/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for gpu/drm/i915: Remove duplicated include of intel_region_lmem.h
== Series Details == Series: gpu/drm/i915: Remove duplicated include of intel_region_lmem.h URL : https://patchwork.freedesktop.org/series/93305/ State : failure == Summary == Applying: gpu/drm/i915: Remove duplicated include of intel_region_lmem.h Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_region_lmem.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_region_lmem.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_region_lmem.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 gpu/drm/i915: Remove duplicated include of intel_region_lmem.h When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] [PATCH] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
Atm the EFI FB driver gets a runtime PM reference for the associated GFX
PCI device during driver probing and releases it only when removing the
driver.
When fbcon switches to the FB provided by the PCI device's driver (for
instance i915/drmfb), the EFI FB will get only unregistered without the
EFI FB driver getting unloaded, keeping the runtime PM reference
acquired during driver probing. This reference will prevent the PCI
driver from runtime suspending the device.
Fix this by releasing the RPM reference from the EFI FB's destroy hook,
called when the FB gets unregistered.
Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0")
Cc: Kai-Heng Feng
Signed-off-by: Imre Deak
---
drivers/video/fbdev/efifb.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 8ea8f079cde26..25cdea32b9633 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -47,6 +47,8 @@ static bool use_bgrt = true;
static bool request_mem_succeeded = false;
static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
+static struct pci_dev *efifb_pci_dev; /* dev with BAR covering the efifb */
+
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct fb_info
*info) {}
static void efifb_destroy(struct fb_info *info)
{
+ if (efifb_pci_dev)
+ pm_runtime_put(&efifb_pci_dev->dev);
+
if (info->screen_base) {
if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
iounmap(info->screen_base);
@@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */
-static struct pci_dev *efifb_pci_dev; /* dev with BAR covering the efifb */
static struct resource *bar_resource;
static u64 bar_offset;
@@ -603,8 +607,6 @@ static int efifb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
framebuffer_release(info);
- if (efifb_pci_dev)
- pm_runtime_put(&efifb_pci_dev->dev);
return 0;
}
--
2.27.0
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for locking/lockdep, drm: apply new lockdep assert in drm_auth.c
== Series Details == Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c URL : https://patchwork.freedesktop.org/series/93304/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c:37:6: warning: symbol 'amdgpu_kms_compat_ioctl' was not declared. Should it be static? +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1137:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1139:51: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1145:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1147:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1153:51: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1154:51: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1155:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1156:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1157:48: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1273:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1802:9: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1811:31: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1812:30: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1816:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1818:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1820:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1822:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1824:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1826:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1828:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1838:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1842:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1846:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1849:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1858:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2017:9: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2026:31: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2027:30: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2031:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2041:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2045:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2049:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2052:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2061:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2128:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2130:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2132:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2144:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2146:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2148:9: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2177:9: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2186:31: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:2187:30: warning: cast to restric
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for locking/lockdep, drm: apply new lockdep assert in drm_auth.c
== Series Details ==
Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c
URL : https://patchwork.freedesktop.org/series/93304/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
60bc4f495a48 locking/lockdep: Provide lockdep_assert{, _once}() helpers
-:30: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#30: FILE: include/linux/lockdep.h:309:
+#define lockdep_assert(cond) \
+ do { WARN_ON(debug_locks && !(cond)); } while (0)
-:37: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#37: FILE: include/linux/lockdep.h:312:
+#define lockdep_assert_once(cond) \
+ do { WARN_ON_ONCE(debug_locks && !(cond)); } while (0)
-:81: CHECK:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email comments
mismatch: 'From: Peter Zijlstra ' != 'Signed-off-by:
Peter Zijlstra (Intel) '
total: 0 errors, 2 warnings, 1 checks, 58 lines checked
e5ac42473801 drm: add lockdep assert to drm_is_current_master_locked
[Intel-gfx] [PATCH v2] drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
From: Ankit Nautiyal
Till DISPLAY12 the PIPE_MISC bits 5-7 are used to set the
Dithering BPC, with valid values of 6, 8, 10 BPC, with Dithering bit enabled.
Also, these bits are used in case of HW readout for pipe_bpp in case of
DSI.
For ADLP+ these bits are used to set the PORT OUTPUT BPC, with valid
values of: 6, 8, 10, 12 BPC, and need to be programmed whether
dithering is enabled or not.
This patch:
-corrects the bits 5-7 for PIPE MISC register for 12 BPC.
-renames the bits and mask to have generic names for these bits for
dithering bpc and port output bpc.
v2: Addressed the comments and suggestions from Uma Shankar:
-Add 'display' in subject
-Add Fixes tag in the commit message.
-Take care of DSI case which uses the bits for getting pipe_bpp.
Fixes: 756f85cffef2 ("drm/i915/bdw: Broadwell has PIPEMISC")
Cc: Paulo Zanoni (v1)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v3.13+
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 18 +-
drivers/gpu/drm/i915/i915_reg.h | 15 ++-
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 65ddb6c..9766b36 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5760,16 +5760,16 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
switch (crtc_state->pipe_bpp) {
case 18:
- val |= PIPEMISC_DITHER_6_BPC;
+ val |= PIPEMISC_6_BPC;
break;
case 24:
- val |= PIPEMISC_DITHER_8_BPC;
+ val |= PIPEMISC_8_BPC;
break;
case 30:
- val |= PIPEMISC_DITHER_10_BPC;
+ val |= PIPEMISC_10_BPC;
break;
case 36:
- val |= PIPEMISC_DITHER_12_BPC;
+ val |= PIPEMISC_12_BPC;
break;
default:
MISSING_CASE(crtc_state->pipe_bpp);
@@ -5822,14 +5822,14 @@ int bdw_get_pipemisc_bpp(struct intel_crtc *crtc)
tmp = intel_de_read(dev_priv, PIPEMISC(crtc->pipe));
- switch (tmp & PIPEMISC_DITHER_BPC_MASK) {
- case PIPEMISC_DITHER_6_BPC:
+ switch (tmp & PIPEMISC_BPC_MASK) {
+ case PIPEMISC_6_BPC:
return 18;
- case PIPEMISC_DITHER_8_BPC:
+ case PIPEMISC_8_BPC:
return 24;
- case PIPEMISC_DITHER_10_BPC:
+ case PIPEMISC_10_BPC:
return 30;
- case PIPEMISC_DITHER_12_BPC:
+ case PIPEMISC_12_BPC:
return 36;
default:
MISSING_CASE(tmp);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 943fe48..bbfe4f4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6166,11 +6166,16 @@ enum {
#define PIPEMISC_HDR_MODE_PRECISION (1 << 23) /* icl+ */
#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1 << 11)
#define PIPEMISC_PIXEL_ROUNDING_TRUNCREG_BIT(8) /* tgl+ */
-#define PIPEMISC_DITHER_BPC_MASK (7 << 5)
-#define PIPEMISC_DITHER_8_BPC(0 << 5)
-#define PIPEMISC_DITHER_10_BPC (1 << 5)
-#define PIPEMISC_DITHER_6_BPC(2 << 5)
-#define PIPEMISC_DITHER_12_BPC (3 << 5)
+/*
+ * For Display < 13, Bits 5-7 of PIPE MISC represent DITHER BPC.
+ * ADLP+, the bits 5-7 represent PORT OUTPUT BPC with valid values of:
+ * 6, 8, 10, 12 BPC.
+ */
+#define PIPEMISC_BPC_MASK(7 << 5)
+#define PIPEMISC_8_BPC (0 << 5)
+#define PIPEMISC_10_BPC (1 << 5)
+#define PIPEMISC_6_BPC (2 << 5)
+#define PIPEMISC_12_BPC (4 << 5) /* adlp+ */
#define PIPEMISC_DITHER_ENABLE (1 << 4)
#define PIPEMISC_DITHER_TYPE_MASK(3 << 2)
#define PIPEMISC_DITHER_TYPE_SP (0 << 2)
--
2.8.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_s: Update ADL-S PCI IDs
== Series Details ==
Series: drm/i915/adl_s: Update ADL-S PCI IDs
URL : https://patchwork.freedesktop.org/series/93302/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20756
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/index.html
Known issues
Here are the changes found in Patchwork_20756 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: [PASS][2] -> [FAIL][3] ([i915#1888])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][4] -> [FAIL][5] ([i915#3449])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][6] ([i915#2782] / [i915#2940]) ->
[PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][8] ([i915#3303]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10437/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
Participating hosts (37 -> 33)
--
Missing(4): fi-bdw-samus fi-bsw-cyan bat-jsl-1 fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10437 -> Patchwork_20756
CI-20190529: 20190529
CI_DRM_10437: fe234200649024b4fb5164d99eca74d62ae696d4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6159: 6135b9cc319ed965e3aafb5b2ae2abf4762a06b2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20756: 8ebaec949f2d4dcb8a80e49ab24a0703e44da540 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8ebaec949f2d drm/i915/adl_s: Update ADL-S PCI IDs
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20756/index.html
[Intel-gfx] [PATCH] gpu/drm/i915: Remove duplicated include of intel_region_lmem.h
Duplicate include header file "intel_region_lmem.h"
line 8: #include "intel_region_lmem.h"
line 12: #include "intel_region_lmem.h"
Signed-off-by: zhouchuangao
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index f7366b0..119eeec 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -9,7 +9,6 @@
#include "intel_region_ttm.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
-#include "intel_region_lmem.h"
static int init_fake_lmem_bar(struct intel_memory_region *mem)
{
--
2.7.4
Re: [Intel-gfx] [PATCH] drm/i915: Fix typo in comments and Kconfig.debug
Hello
Thanks for your reply. Exactly , the tools is base on codespell
But it seems not working well > iff
-Original Message-
From: Lucas De Marchi
Sent: 2021年7月31日 1:31
To: Cai,Huoqing
Cc: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix typo in comments and
Kconfig.debug
On Fri, Jul 30, 2021 at 05:49:18PM +0800, Cai Huoqing wrote:
>Fix typo:
>*iff ==> if
this is one that is hard to do automatically because it's also an abbreviation
for "if and only if". See https://en.wikipedia.org/wiki/If_and_only_if . In the
single place it was changed below, the abbreviation was intended.
I guess these fixes come from some tool. Mind mentioning in the commit message
what it is? I would have guessed codespell, but codespell doesn't have this
entry, so it must be something else.
Rest looks good. Thanks
Lucas De Marchi
>*specifc ==> specific
>*adjustement ==> adjustment
>*preferrably ==> preferably
>*forseeable ==> foreseeable
>*overwritting ==> overwriting
>*sempahores ==> semaphores
>*additonally ==> additionally
>*allcoated ==> allocated
>*contigious ==> contiguous
>*priorty ==> priority
>*priviliged ==> privileged
>*fullfilling ==> fulfilling
>*Timestmap ==> Timestamp
>*accesible ==> accessible
>*becaue ==> because
>*overriden ==> overridden
>*prarameter ==> parameter
>*the the ==> the
>
>Signed-off-by: Cai Huoqing
>---
> drivers/gpu/drm/i915/Kconfig.debug | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 6 +++---
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/i915/i915_pci.c | 4 ++--
> drivers/gpu/drm/i915/i915_perf.c| 4 ++--
> drivers/gpu/drm/i915/i915_pmu.h | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/i915_request.c | 4 ++--
> drivers/gpu/drm/i915/i915_vma.c | 4 ++--
> drivers/gpu/drm/i915/intel_pm.c | 10 +-
> drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
>drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
> 13 files changed, 23 insertions(+), 23 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/Kconfig.debug
>b/drivers/gpu/drm/i915/Kconfig.debug
>index 72a38f28393f..c444d97b7c9c 100644
>--- a/drivers/gpu/drm/i915/Kconfig.debug
>+++ b/drivers/gpu/drm/i915/Kconfig.debug
>@@ -2,7 +2,7 @@
> config DRM_I915_WERROR
> bool "Force GCC to throw an error instead of a warning when compiling"
> # As this may inadvertently break the build, only allow the user
>- # to shoot oneself in the foot iff they aim really hard
>+ # to shoot oneself in the foot if they aim really hard
> depends on EXPERT
> # We use the dependency on !COMPILE_TEST to not be enabled in
> # allmodconfig or allyesconfig configurations diff --git
>a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index 734a2fce1efe..3ae32edf367a 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -335,7 +335,7 @@ struct drm_i915_display_funcs { enum
>i915_cache_level {
> I915_CACHE_NONE = 0,
> I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */
>- I915_CACHE_L3_LLC, /* gen7+, L3 sits between the domain specifc
>+ I915_CACHE_L3_LLC, /* gen7+, L3 sits between the domain specific
> caches, eg sampler/render caches, and the
> large Last-Level-Cache. LLC is coherent with
> the CPU, but L3 is only visible to the GPU. */ @@
> -383,7
>+383,7 @@ struct intel_fbc {
> int src_h;
> bool visible;
> /*
>- * Display surface base address adjustement for
>+ * Display surface base address adjustment for
>* pageflips. Note that on gen4+ this only adjusts up
>* to a tile, offsets within a tile are handled in
>* the hw itself (with the TILEOFF register).
>@@ -795,7 +795,7 @@ struct drm_i915_private {
>*/
> struct resource dsm;
> /**
>- * Reseved portion of Data Stolen Memory
>+ * Reserved portion of Data Stolen Memory
>*/
> struct resource dsm_reserved;
>
>diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
>b/drivers/gpu/drm/i915/i915_gpu_error.c
>index 35c97c39f125..601401a510c5 100644
>--- a/drivers/gpu/drm/i915/i915_gpu_error.c
>+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
>@@ -1498,7 +1498,7 @@ gt_record_uc(struct intel_gt_coredump *gt,
> memcpy(&error_uc->huc_fw, &uc->huc.fw, sizeof(uc->huc.fw));
>
> /* Non-default firmware paths will be specified by the modparam.
>- * As modparams are generally accesible from the userspace make
>+ * As modparams are generally acces
[Intel-gfx] [RESEND PATCH v2 2/2] drm: add lockdep assert to drm_is_current_master_locked
In drm_is_current_master_locked, accessing drm_file.master should be
protected by either drm_file.master_lookup_lock or
drm_device.master_mutex. This was previously awkward to assert with
lockdep.
Following patch ("locking/lockdep: Provide lockdep_assert{,_once}()
helpers"), this assertion is now convenient. So we add in the
assertion and explain this lock design in the kerneldoc.
Signed-off-by: Desmond Cheong Zhi Xi
Acked-by: Boqun Feng
Acked-by: Waiman Long
Acked-by: Peter Zijlstra (Intel)
---
drivers/gpu/drm/drm_auth.c | 6 +++---
include/drm/drm_file.h | 4
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 9c24b8cc8e36..6f4d7ff23c80 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -63,9 +63,9 @@
static bool drm_is_current_master_locked(struct drm_file *fpriv)
{
- /* Either drm_device.master_mutex or drm_file.master_lookup_lock
-* should be held here.
-*/
+ lockdep_assert_once(lockdep_is_held(&fpriv->master_lookup_lock) ||
+ lockdep_is_held(&fpriv->minor->dev->master_mutex));
+
return fpriv->is_master && drm_lease_owner(fpriv->master) ==
fpriv->minor->dev->master;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 726cfe0ff5f5..a3acb7ac3550 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -233,6 +233,10 @@ struct drm_file {
* this only matches &drm_device.master if the master is the currently
* active one.
*
+* To update @master, both &drm_device.master_mutex and
+* @master_lookup_lock need to be held, therefore holding either of
+* them is safe and enough for the read side.
+*
* When dereferencing this pointer, either hold struct
* &drm_device.master_mutex for the duration of the pointer's use, or
* use drm_file_get_master() if struct &drm_device.master_mutex is not
--
2.25.1
[Intel-gfx] [RESEND PATCH v2 1/2] locking/lockdep: Provide lockdep_assert{, _once}() helpers
From: Peter Zijlstra
Extract lockdep_assert{,_once}() helpers to more easily write composite
assertions like, for example:
lockdep_assert(lockdep_is_held(&drm_device.master_mutex) ||
lockdep_is_held(&drm_file.master_lookup_lock));
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Desmond Cheong Zhi Xi
Acked-by: Boqun Feng
Acked-by: Waiman Long
Acked-by: Peter Zijlstra (Intel)
---
include/linux/lockdep.h | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 5cf387813754..9fe165beb0f9 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -306,31 +306,29 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
struct pin_cookie);
#define lockdep_depth(tsk) (debug_locks ? (tsk)->lockdep_depth : 0)
-#define lockdep_assert_held(l) do {\
- WARN_ON(debug_locks && \
- lockdep_is_held(l) == LOCK_STATE_NOT_HELD); \
- } while (0)
+#define lockdep_assert(cond) \
+ do { WARN_ON(debug_locks && !(cond)); } while (0)
-#define lockdep_assert_not_held(l) do {\
- WARN_ON(debug_locks && \
- lockdep_is_held(l) == LOCK_STATE_HELD); \
- } while (0)
+#define lockdep_assert_once(cond) \
+ do { WARN_ON_ONCE(debug_locks && !(cond)); } while (0)
-#define lockdep_assert_held_write(l) do {\
- WARN_ON(debug_locks && !lockdep_is_held_type(l, 0));\
- } while (0)
+#define lockdep_assert_held(l) \
+ lockdep_assert(lockdep_is_held(l) != LOCK_STATE_NOT_HELD)
-#define lockdep_assert_held_read(l)do {\
- WARN_ON(debug_locks && !lockdep_is_held_type(l, 1));\
- } while (0)
+#define lockdep_assert_not_held(l) \
+ lockdep_assert(lockdep_is_held(l) != LOCK_STATE_HELD)
-#define lockdep_assert_held_once(l)do {\
- WARN_ON_ONCE(debug_locks && !lockdep_is_held(l)); \
- } while (0)
+#define lockdep_assert_held_write(l) \
+ lockdep_assert(lockdep_is_held_type(l, 0))
-#define lockdep_assert_none_held_once()do {
\
- WARN_ON_ONCE(debug_locks && current->lockdep_depth);\
- } while (0)
+#define lockdep_assert_held_read(l)\
+ lockdep_assert(lockdep_is_held_type(l, 1))
+
+#define lockdep_assert_held_once(l)\
+ lockdep_assert_once(lockdep_is_held(l) != LOCK_STATE_NOT_HELD)
+
+#define lockdep_assert_none_held_once()\
+ lockdep_assert_once(!current->lockdep_depth)
#define lockdep_recursing(tsk) ((tsk)->lockdep_recursion)
@@ -407,6 +405,9 @@ extern int lock_is_held(const void *);
extern int lockdep_is_held(const void *);
#define lockdep_is_held_type(l, r) (1)
+#define lockdep_assert(c) do { } while (0)
+#define lockdep_assert_once(c) do { } while (0)
+
#define lockdep_assert_held(l) do { (void)(l); } while (0)
#define lockdep_assert_not_held(l) do { (void)(l); } while (0)
#define lockdep_assert_held_write(l) do { (void)(l); } while (0)
--
2.25.1
[Intel-gfx] [RESEND PATCH v2 0/2] locking/lockdep, drm: apply new lockdep assert in drm_auth.c
Hi all,
My bad for the resend. Adding cc: intel-gfx, and the maintainers and
mailing lists for include/drm/drm_file.h.
Following a discussion on the patch ("drm: use the lookup lock in
drm_is_current_master") [1], Peter Zijlstra proposed new lockdep_assert
helpers to make it convenient to compose lockdep checks together.
This series includes the patch that introduces the new lockdep helpers,
then utilizes these helpers in drm_is_current_master_locked in the
following patch.
v1 -> v2:
Patch 2:
- Updated the kerneldoc on the lock design of drm_file.master to explain
the use of lockdep_assert(). As suggested by Boqun Feng.
Link:
https://lore.kernel.org/lkml/20210722092929.244629-2-desmondcheon...@gmail.com/
[1]
Best wishes,
Desmond
Desmond Cheong Zhi Xi (1):
drm: add lockdep assert to drm_is_current_master_locked
Peter Zijlstra (1):
locking/lockdep: Provide lockdep_assert{,_once}() helpers
drivers/gpu/drm/drm_auth.c | 6 +++---
include/drm/drm_file.h | 4
include/linux/lockdep.h| 41 +++---
3 files changed, 28 insertions(+), 23 deletions(-)
--
2.25.1
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs
On Thu, Jul 29, 2021 at 10:27:29PM +, Patchwork wrote: > == Series Details == > > Series: lpsp with hdmi/dp outputs > URL : https://patchwork.freedesktop.org/series/93179/ > State : failure Thanks for the patch pushed it to -din, fixing some typos in the commit message and the playback domain name while applying. The SKL failure looks unrelated, since nothing changes there, maybe we are only missing the trace_clock=global kernel param on that machine. > > == Summary == > > CI Bug Log - changes from CI_DRM_10418_full -> Patchwork_20740_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20740_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20740_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20740_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: > - shard-skl: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html > > > Known issues > > > Here are the changes found in Patchwork_20740_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@smoketest: > - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +5 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-snb6/igt@gem_ctx_persiste...@smoketest.html > > * igt@gem_eio@reset-stress: > - shard-skl: [PASS][4] -> [FAIL][5] ([i915#2771]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl1/igt@gem_...@reset-stress.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl4/igt@gem_...@reset-stress.html > > * igt@gem_exec_fair@basic-pace@bcs0: > - shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-iclb7/igt@gem_exec_fair@basic-p...@bcs0.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-iclb6/igt@gem_exec_fair@basic-p...@bcs0.html > > * igt@gem_exec_fair@basic-throttle@rcs0: > - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html > - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2849]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html > > * igt@gem_huc_copy@huc-copy: > - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-tglb5/igt@gem_huc_c...@huc-copy.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-tglb6/igt@gem_huc_c...@huc-copy.html > - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl2/igt@gem_huc_c...@huc-copy.html > > * igt@gem_mmap_gtt@cpuset-big-copy-odd: > - shard-glk: [PASS][15] -> [FAIL][16] ([i915#1888] / [i915#307]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-glk8/igt@gem_mmap_...@cpuset-big-copy-odd.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-glk1/igt@gem_mmap_...@cpuset-big-copy-odd.html > > * igt@gem_pread@exhaustion: > - shard-apl: NOTRUN -> [WARN][17] ([i915#2658]) +1 similar issue >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-apl2/igt@gem_pr...@exhaustion.html > > * igt@gen9_exec_parse@allowed-single: > - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1436] / > [i915#1982] / [i915#716]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10418/shard-skl4/igt@gen9_exec_pa...@allowed-single.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20740/shard-skl5/igt@gen9_exec_pa...@allowed-single.html > > * igt@i915_module_load@reload-with-fault-injection: > - shard-skl: [PASS][20] -> [DMESG-WARN
[Intel-gfx] [PATCH] drm/i915/adl_s: Update ADL-S PCI IDs
Sync PCI IDs with Bspec. Bspec:53655 Signed-off-by: Tejas Upadhyay --- include/drm/i915_pciids.h | 4 1 file changed, 4 deletions(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index eee18fa53b54..8adb058dfc5a 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -637,13 +637,9 @@ /* ADL-S */ #define INTEL_ADLS_IDS(info) \ INTEL_VGA_DEVICE(0x4680, info), \ - INTEL_VGA_DEVICE(0x4681, info), \ INTEL_VGA_DEVICE(0x4682, info), \ - INTEL_VGA_DEVICE(0x4683, info), \ INTEL_VGA_DEVICE(0x4688, info), \ - INTEL_VGA_DEVICE(0x4689, info), \ INTEL_VGA_DEVICE(0x4690, info), \ - INTEL_VGA_DEVICE(0x4691, info), \ INTEL_VGA_DEVICE(0x4692, info), \ INTEL_VGA_DEVICE(0x4693, info) -- 2.31.1
Re: [Intel-gfx] [PATCH] drm/i915: Correct SFC_DONE register offset
Matt Roper writes:
> On Wed, Jul 28, 2021 at 06:05:57PM -0700, Matt Roper wrote:
>> On Wed, Jul 28, 2021 at 04:34:11PM -0700, Matt Roper wrote:
>> > The register offset for SFC_DONE was missing a '0' at the end, causing
>> > us to read from a non-existent register address. We only use this
>> > register in error state dumps so the mistake hasn't caused any real
>> > problems, but fixing it will hopefully make the error state dumps a bit
>> > more useful for debugging.
>> >
>> > Fixes: e50dbdbfd9fb ("drm/i915/tgl: Add SFC instdone to error state")
>> > Cc: Mika Kuoppala
>> > Signed-off-by: Matt Roper
>>
>> Hmm, actually on a closer look it appears this register may have been
>> removed completely from media version 12. It will return in media
>> version 13 at this offset, but for now I guess we should just drop it
>> completely.
>
> Nevermind; this register is still there on media version 12 (bspec
> 48109). The current register offset in the code is incorrect, so this
> patch is indeed valid.
Yes it is. Thanks,
Reviewed-by: Mika Kuoppala
>
>
> Matt
>
>>
>>
>> Matt
>>
>> > ---
>> > drivers/gpu/drm/i915/i915_reg.h | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 70eed4fe3fe3..49dd5e75429e 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -430,7 +430,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>> > #define GEN12_HCP_SFC_LOCK_ACK_BIT REG_BIT(1)
>> > #define GEN12_HCP_SFC_USAGE_BIT REG_BIT(0)
>> >
>> > -#define GEN12_SFC_DONE(n) _MMIO(0x1cc00 + (n) * 0x100)
>> > +#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
>> > #define GEN12_SFC_DONE_MAX4
>> >
>> > #define RING_PP_DIR_BASE(base)_MMIO((base) + 0x228)
>> > --
>> > 2.25.4
>> >
>>
>> --
>> Matt Roper
>> Graphics Software Engineer
>> VTT-OSGC Platform Enablement
>> Intel Corporation
>> (916) 356-2795
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Check if engine has heartbeat when closing a context
On 30/07/2021 19:13, John Harrison wrote: On 7/30/2021 02:49, Tvrtko Ursulin wrote: On 30/07/2021 01:13, John Harrison wrote: On 7/28/2021 17:34, Matthew Brost wrote: If an engine associated with a context does not have a heartbeat, ban it immediately. This is needed for GuC submission as a idle pulse doesn't kick the context off the hardware where it then can check for a heartbeat and ban the context. Pulse, that is a request with I915_PRIORITY_BARRIER, does not preempt a running normal priority context? Why does it matter then whether or not heartbeats are enabled - when heartbeat just ends up sending the same engine pulse (eventually, with raising priority)? The point is that the pulse is pointless. See the rest of my comments below, specifically "the context will get resubmitted to the hardware after the pulse completes". To re-iterate... Yes, it preempts the context. Yes, it does so whether heartbeats are enabled or not. But so what? Who cares? You have preempted a context. It is no longer running on the hardware. BUT IT IS STILL A VALID CONTEXT. It is valid yes, and it even may be the current ABI so another question is whether it is okay to change that. The backend scheduler will just resubmit it to the hardware as soon as the pulse completes. The only reason this works at all is because of the horrid hack in the execlist scheduler's back end implementation (in __execlists_schedule_in): if (unlikely(intel_context_is_closed(ce) && !intel_engine_has_heartbeat(engine))) intel_context_set_banned(ce); Right, is the above code then needed with this patch - when ban is immediately applied on the higher level? The actual back end scheduler is saying "Is this a zombie context? Is the heartbeat disabled? Then ban it". No other scheduler backend is going to have knowledge of zombie context status or of the heartbeat status. Nor are they going to call back into the higher levels of the i915 driver to trigger a ban operation. Certainly a hardware implemented scheduler is not going to be looking at private i915 driver information to decide whether to submit a context or whether to tell the OS to kill it off instead. For persistence to work with a hardware scheduler (or a non-Intel specific scheduler such as the DRM one), the handling of zombie contexts, banning, etc. *must* be done entirely in the front end. It cannot rely on any backend hacks. That means you can't rely on any fancy behaviour of pulses. If you want to ban a context then you must explicitly ban that context. If you want to ban it at some later point then you need to track it at the top level as a zombie and then explicitly ban that zombie at whatever later point. I am still trying to understand it all. If I go by the commit message: """ This is needed for GuC submission as a idle pulse doesn't kick the context off the hardware where it then can check for a heartbeat and ban the context. """ That did not explain things for me. Sentence does not appear to make sense. Now, it seems "kick off the hardware" is meant as revoke and not just preempt. Which is fine, perhaps just needs to be written more explicitly. But the part of checking for heartbeat after idle pulse does not compute for me. It is the heartbeat which emits idle pulses, not idle pulse emitting heartbeats. But anyway, I can buy the handling at the front end story completely. It makes sense. We just need to agree that a) it is okay to change the ABI and b) remove the backend check from execlists if it is not needed any longer. And if ABI change is okay then commit message needs to talk about it loudly and clearly. Or perhaps there is no ABI change? I am not really clear how does setting banned status propagate to the GuC backend. I mean at which point does i915 ends up passing that info to the firmware? Regards, Tvrtko It's worse than this. If the engine in question is an individual physical engine then sending a pulse (with sufficiently high priority) will pre-empt the engine and kick the context off. However, the GuC Why it is different for physical vs virtual, aren't both just schedulable contexts with different engine masks for what GuC is concerned? Oh, is it a matter of needing to send pulses to all engines which comprise a virtual one? It isn't different. It is totally broken for both. It is potentially more broken for virtual engines because of the question of which engine to pulse. But as stated above, the pulse is pointless anyway so the which engine question doesn't even matter. John. scheduler does not have hacks in it to check the state of the heartbeat or whether a context is actually a zombie or not. Thus, the context will get resubmitted to the hardware after the pulse completes and effectively nothing will have happened. I would assume that the DRM scheduler which we are meant to be switching to for execlist as well as G
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: document caching related bits
Matthew Auld writes:
> Try to document the object caching related bits, like cache_coherent and
> cache_dirty.
>
> v2(Ville):
> - As pointed out by Ville, fix the completely incorrect assumptions
>about the "partial" coherency on shared LLC platforms.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Ville Syrjälä
> Cc: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 173 +-
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> 2 files changed, 169 insertions(+), 13 deletions(-)
>
> 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 ef3de2ae9723..a809424bc8c1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -92,6 +92,76 @@ struct drm_i915_gem_object_ops {
> const char *name; /* friendly name for debug, e.g. lockdep classes */
> };
>
> +/**
> + * enum i915_cache_level - The supported GTT caching values for system memory
> + * pages.
> + *
> + * These translate to some special GTT PTE bits when binding pages into some
> + * address space. It also determines whether an object, or rather its pages
> are
> + * coherent with the GPU, when also reading or writing through the CPU cache
> + * with those pages.
> + *
> + * Userspace can also control this through struct drm_i915_gem_caching.
> + */
> +enum i915_cache_level {
> + /**
> + * @I915_CACHE_NONE:
> + *
> + * Not coherent with the CPU cache. If the cache is dirty and we need
> + * the underlying pages to be coherent with some later GPU access then
> + * we need to manually flush the pages.
> + *
> + * Note that on shared LLC platforms reads and writes through the CPU
> + * cache are still coherent even with this setting. See also
> + * &drm_i915_gem_object.cache_coherent for more details.
> + *
> + * Note that on platforms with a shared LLC this should ideally only be
> + * used for scanout surfaces, otherwise we end up over-flushing in some
> + * places.
> + */
> + I915_CACHE_NONE = 0,
> + /**
> + * @I915_CACHE_LLC:
> + *
> + * Coherent with the CPU cache. If the cache is dirty, then the GPU will
> + * ensure that access remains coherent, when both reading and writing
> + * through the CPU cache.
> + *
> + * Not used for scanout surfaces.
> + *
> + * Applies to both platforms with shared LLC(HAS_LLC), and snooping
> + * based platforms(HAS_SNOOP).
> + *
> + * This should be the default for platforms which share the LLC with the
> + * CPU. The only exception is scanout objects, where the display engine
> + * is not coherent with the LLC. For such objects I915_CACHE_NONE or
> + * I915_CACHE_WT should be used.
> + */
> + I915_CACHE_LLC,
> + /**
> + * @I915_CACHE_L3_LLC:
> + *
> + * Explicitly enable the Gfx L3 cache, with snooped LLC.
> + *
> + * The Gfx L3 sits between the domain specific caches, e.g
> + * sampler/render caches, and the larger LLC. LLC is coherent with the
> + * GPU, but L3 is only visible to the GPU, so likely needs to be flushed
> + * when the workload completes.
> + *
> + * Not used for scanout surfaces.
> + *
> + * Only exposed on some gen7 + GGTT. More recent hardware has dropped
> + * this.
> + */
This is stellar. Thanks!
-Mika
> + I915_CACHE_L3_LLC,
> + /**
> + * @I915_CACHE_WT:
> + *
> + * hsw:gt3e Write-through for scanout buffers.
> + */
> + I915_CACHE_WT,
> +};
> +
> enum i915_map_type {
> I915_MAP_WB = 0,
> I915_MAP_WC,
> @@ -228,14 +298,109 @@ struct drm_i915_gem_object {
> unsigned int mem_flags;
> #define I915_BO_FLAG_STRUCT_PAGE BIT(0) /* Object backed by struct pages */
> #define I915_BO_FLAG_IOMEM BIT(1) /* Object backed by IO memory */
> - /*
> - * Is the object to be mapped as read-only to the GPU
> - * Only honoured if hardware has relevant pte bit
> + /**
> + * @cache_level: The desired GTT caching level.
> + *
> + * See enum i915_cache_level for possible values, along with what
> + * each does.
>*/
> unsigned int cache_level:3;
> - unsigned int cache_coherent:2;
> + /**
> + * @cache_coherent:
> + *
> + * Track whether the pages are coherent with the GPU if reading or
> + * writing through the CPU caches. The largely depends on the
> + * @cache_level setting.
> + *
> + * On platforms which don't have the shared LLC(HAS_SNOOP), like on Atom
> + * platforms, coherency must be explicitly requested with some special
> + * GTT caching bits(see enum i915_cache_level). When enabling coherency
> + * it does come at a performance and power cost on such platforms. On
> + * the flip side the ker
Re: [Intel-gfx] [PATCH] drm: Fix oops in damage self-tests by mocking damage property
Op 30-07-2021 om 11:52 schreef Daniel Vetter:
> I've added a new check to make sure that drivers which insepct the
> damage property have it set up correctly, but somehow missed that this
> borke the damage selftest in the CI result noise.
>
> Fix it up by mocking enough of drm_device and drm_plane so we can call
> drm_plane_enable_fb_damage_clips() to make the new check happy.
>
> Since there's a lot of duplicated mock code already copy-pasted into
> each test I've also refactored this a bit to trim it down.
>
> Signed-off-by: Daniel Vetter
> Fixes: c7fcbf251397 ("drm/plane: check that fb_damage is set up when used")
> Cc: José Roberto de Souza (v1)
> Cc: Ville Syrjälä
> Cc: Gwan-gyeong Mun
> Cc: José Roberto de Souza
> Cc: Hans de Goede
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> ---
> .../drm/selftests/test-drm_damage_helper.c| 287 +-
> 1 file changed, 71 insertions(+), 216 deletions(-)
>
> diff --git a/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> index 9d2bcdf8bc29..1b585c13e042 100644
> --- a/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> +++ b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> @@ -6,9 +6,37 @@
> #define pr_fmt(fmt) "drm_damage_helper: " fmt
>
> #include
> +#include
> +#include
>
> #include "test-drm_modeset_common.h"
>
> +struct drm_driver mock_driver;
> +struct drm_device mock_device;
> +struct drm_object_properties mock_obj_props;
> +struct drm_plane mock_plane;
> +struct drm_property mock_prop;
> +
> +static void mock_setup(struct drm_plane_state *state)
> +{
> + static bool setup_done = false;
> +
> + state->plane = &mock_plane;
> +
> + if (setup_done)
> + return;
> +
> + /* just enough so that drm_plane_enable_fb_damage_clips() works */
> + mock_device.driver = &mock_driver;
> + mock_device.mode_config.prop_fb_damage_clips = &mock_prop;
> + mock_plane.dev = &mock_device;
> + mock_plane.base.properties = &mock_obj_props;
> + mock_prop.base.id = 1; /* 0 is an invalid id */
> + mock_prop.dev = &mock_device;
> +
> + drm_plane_enable_fb_damage_clips(&mock_plane);
> +}
> +
> static void set_plane_src(struct drm_plane_state *state, int x1, int y1, int
> x2,
> int y2)
> {
> @@ -70,23 +98,29 @@ static bool check_damage_clip(struct drm_plane_state
> *state, struct drm_rect *r,
> return true;
> }
>
> +const struct drm_framebuffer fb = {
> + .width = 2048,
> + .height = 2048
> +};
> +
> +/* common mocked structs many tests need */
> +#define MOCK_VARIABLES() \
> + struct drm_plane_state old_state; \
> + struct drm_plane_state state = { \
> + .crtc = ZERO_SIZE_PTR, \
> + .fb = (struct drm_framebuffer *) &fb, \
> + .visible = true, \
> + }; \
> + mock_setup(&old_state); \
> + mock_setup(&state);
> +
> int igt_damage_iter_no_damage(void *ignored)
> {
> struct drm_atomic_helper_damage_iter iter;
> - struct drm_plane_state old_state;
> struct drm_rect clip;
> uint32_t num_hits = 0;
>
> - struct drm_framebuffer fb = {
> - .width = 2048,
> - .height = 2048
> - };
> -
> - struct drm_plane_state state = {
> - .crtc = ZERO_SIZE_PTR,
> - .fb = &fb,
> - .visible = true,
> - };
> + MOCK_VARIABLES();
>
> /* Plane src same as fb size. */
> set_plane_src(&old_state, 0, 0, fb.width << 16, fb.height << 16);
> @@ -104,20 +138,10 @@ int igt_damage_iter_no_damage(void *ignored)
> int igt_damage_iter_no_damage_fractional_src(void *ignored)
> {
> struct drm_atomic_helper_damage_iter iter;
> - struct drm_plane_state old_state;
> struct drm_rect clip;
> uint32_t num_hits = 0;
>
> - struct drm_framebuffer fb = {
> - .width = 2048,
> - .height = 2048
> - };
> -
> - struct drm_plane_state state = {
> - .crtc = ZERO_SIZE_PTR,
> - .fb = &fb,
> - .visible = true,
> - };
> + MOCK_VARIABLES();
>
> /* Plane src has fractional part. */
> set_plane_src(&old_state, 0x3fffe, 0x3fffe,
> @@ -137,20 +161,10 @@ int igt_damage_iter_no_damage_fractional_src(void
> *ignored)
> int igt_damage_iter_no_damage_src_moved(void *ignored)
> {
> struct drm_atomic_helper_damage_iter iter;
> - struct drm_plane_state old_state;
> struct drm_rect clip;
> uint32_t num_hits = 0;
>
> - struct drm_framebuffer fb = {
> - .width = 2048,
> - .height = 2048
> - };
> -
> - struct drm_plane_state state = {
> - .crtc = ZERO_SIZE_PTR,
> - .fb = &fb,
> - .visible = true,
> - };
> + MOCK_VARIABLES();
>
> /* Plane src moved since old plane state. */
> set_plane_src(&old_state, 0, 0, 1024 << 16,
Re: [Intel-gfx] [PATCH i-g-t 1/1] i915/gem_scheduler: Ensure submission order in manycontexts
On 30/07/2021 19:06, Matthew Brost wrote:
On Fri, Jul 30, 2021 at 10:58:38AM +0100, Tvrtko Ursulin wrote:
On 27/07/2021 19:20, Matthew Brost wrote:
With GuC submission contexts can get reordered (compared to submission
order), if contexts get reordered the sequential nature of the batches
releasing the next batch's semaphore in function timesliceN() get broken
resulting in the test taking much longer than if should. e.g. Every
contexts needs to be timesliced to release the next batch. Corking the
first submission until all the batches have been submitted should ensure
submission order.
The explanation sounds suspect.
Consider this comment from the test itself:
/*
* Create a pair of interlocking batches, that ping pong
* between each other, and only advance one step at a time.
* We require the kernel to preempt at each semaphore and
* switch to the other batch in order to advance.
*/
I'd say the test does not rely on no re-ordering at all, but relies on
context switch on an unsatisfied semaphore.
Yes, let do a simple example with 5 batches. Batch 0 releases batch's
semaphore 1, batch 1 releases batch's 2 semaphore, etc... If the batches
are seen in order the test should take 40 timeslices (8 semaphores in
each batch have to be released).
If the batches are in the below order:
0 2 1 3 4
Now we have 72 timeslices. Now imagine with 67 batches completely out of
order, the number timeslices can explode.
Yes that part is clear, issue is to understand why is guc waiting for
the timeslice to expire..
In the commit you seem to acknowledge GuC does not do that but instead ends
up waiting for the timeslice to expire, did I get that right? If so, why
I think GuC waits for the timeslice to expire if a semaphore is
unsatisfied, I have to double check on that. I thought that was what
execlists were doing too but I now see it has a convoluted algorithm to
yield the timeslice if subsequent request comes in and the ring is
waiting on a timeslice. Let me check with GuC team and see if they can
/ are doing something similiar. I was thinking the only to switch a
sempahore was clear CTX_CTRL_INHIBIT_SYN_CTX_SWITCH but that appears to
be incorrect.
.. so this will need clarifying with the firmware team.
With execlists we enable and react on GT_WAIT_SEMAPHORE_INTERRUPT. If
guc does not, or can not, do that that could be worrying since userspace
can and does use semaphores legitimately so making it pay the timeslice
penalty. Well actually that has an effect to unrelated clients as well,
not just the semaphore user.
For what is worth, after this change the run times of test are pretty
similar for execlists & GuC on TGL.
Yes, but the test was useful in this case since it found a weakness in
guc scheduling so it may not be the best approach to hide that.
Regards,
Tvrtko
Matt
does the GuC does not do that and can we fix it?
Regards,
Tvrtko
Signed-off-by: Matthew Brost
---
tests/i915/gem_exec_schedule.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index f03842478..41f2591a5 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -597,12 +597,13 @@ static void timesliceN(int i915, const intel_ctx_cfg_t
*cfg,
struct drm_i915_gem_execbuffer2 execbuf = {
.buffers_ptr = to_user_pointer(&obj),
.buffer_count = 1,
- .flags = engine | I915_EXEC_FENCE_OUT,
+ .flags = engine | I915_EXEC_FENCE_OUT | I915_EXEC_FENCE_SUBMIT,
};
uint32_t *result =
gem_mmap__device_coherent(i915, obj.handle, 0, sz, PROT_READ);
const intel_ctx_t *ctx;
int fence[count];
+ IGT_CORK_FENCE(cork);
/*
* Create a pair of interlocking batches, that ping pong
@@ -614,6 +615,17 @@ static void timesliceN(int i915, const intel_ctx_cfg_t
*cfg,
igt_require(gem_scheduler_has_timeslicing(i915));
igt_require(intel_gen(intel_get_drm_devid(i915)) >= 8);
+ /*
+* With GuC submission contexts can get reordered (compared to
+* submission order), if contexts get reordered the sequential
+* nature of the batches releasing the next batch's semaphore gets
+* broken resulting in the test taking much longer than it should (e.g.
+* every context needs to be timesliced to release the next batch).
+* Corking the first submission until all batches have been
+* submitted should ensure submission order.
+*/
+ execbuf.rsvd2 = igt_cork_plug(&cork, i915);
+
/* No coupling between requests; free to timeslice */
for (int i = 0; i < count; i++) {
@@ -624,8 +636,10 @@ static void timesliceN(int i915, const intel_ctx_cfg_t
*cfg,
intel_ctx_destroy(i915, ctx);
fence[i] = execbuf.rsvd2 >> 32;
+
[Intel-gfx] [CI v2] drm/i915: Tweaked Wa_14010685332 for all PCHs
dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
state.
The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked
Wa_14010685332 sequence for every PCH since PCH_CNP.
v2:
- removed RKL from comment and simplified condition. [Rodrigo]
Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11
platforms")
Cc: Matt Roper
Cc: Rodrigo Vivi
Cc: Imre Deak
Signed-off-by: Anshuman Gupta
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_display_power.c| 16 +++---
drivers/gpu/drm/i915/i915_irq.c | 21 ---
2 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 02452237ad0b..c2a0238386d7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -6126,13 +6126,13 @@ void intel_display_power_suspend_late(struct
drm_i915_private *i915)
if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
IS_BROXTON(i915)) {
bxt_enable_dc9(i915);
- /* Tweaked Wa_14010685332:icp,jsp,mcc */
- if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
PCH_MCC)
- intel_de_rmw(i915, SOUTH_CHICKEN1,
-SBCLK_RUN_REFCLK_DIS,
SBCLK_RUN_REFCLK_DIS);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
hsw_enable_pc8(i915);
}
+
+ /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp,adp */
+ if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
+ intel_de_rmw(i915, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
SBCLK_RUN_REFCLK_DIS);
}
void intel_display_power_resume_early(struct drm_i915_private *i915)
@@ -6141,13 +6141,13 @@ void intel_display_power_resume_early(struct
drm_i915_private *i915)
IS_BROXTON(i915)) {
gen9_sanitize_dc_state(i915);
bxt_disable_dc9(i915);
- /* Tweaked Wa_14010685332:icp,jsp,mcc */
- if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
PCH_MCC)
- intel_de_rmw(i915, SOUTH_CHICKEN1,
SBCLK_RUN_REFCLK_DIS, 0);
-
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
hsw_disable_pc8(i915);
}
+
+ /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp,adp */
+ if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
+ intel_de_rmw(i915, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS, 0);
}
void intel_display_power_suspend(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 17d336218b67..9bc4f4a8e12e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3079,24 +3079,6 @@ static void valleyview_irq_reset(struct drm_i915_private
*dev_priv)
spin_unlock_irq(&dev_priv->irq_lock);
}
-static void cnp_display_clock_wa(struct drm_i915_private *dev_priv)
-{
- struct intel_uncore *uncore = &dev_priv->uncore;
-
- /*
-* Wa_14010685332:cnp/cmp,tgp,adp
-* TODO: Clarify which platforms this applies to
-* TODO: Figure out if this workaround can be applied in the s0ix
suspend/resume handlers as
-* on earlier platforms and whether the workaround is also needed for
runtime suspend/resume
-*/
- if (INTEL_PCH_TYPE(dev_priv) == PCH_CNP ||
- (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP && INTEL_PCH_TYPE(dev_priv) <
PCH_DG1)) {
- intel_uncore_rmw(uncore, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
-SBCLK_RUN_REFCLK_DIS);
- intel_uncore_rmw(uncore, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
0);
- }
-}
-
static void gen8_display_irq_reset(struct drm_i915_private *dev_priv)
{
struct intel_uncore *uncore = &dev_priv->uncore;
@@ -3130,7 +3112,6 @@ static void gen8_irq_reset(struct drm_i915_private
*dev_priv)
if (HAS_PCH_SPLIT(dev_priv))
ibx_irq_reset(dev_priv);
- cnp_display_clock_wa(dev_priv);
}
static void gen11_display_irq_reset(struct drm_i915_private *dev_priv)
@@ -3174,8 +3155,6 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
GEN3_IRQ_RESET(uncore, SDE);
-
- cnp_display_clock_wa(dev_priv);
}
static void gen11_irq_reset(struct drm_i915_private *dev_priv)
--
2.26.2
Re: [Intel-gfx] [PATCH v2 7/7] drm/connector: add ref to drm_connector_get in iter docs
Pushed this one doc patch with Daniel's R-b on IRC.
