[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove short term pins from execbuf by requiring lock to unbind.
== Series Details == Series: drm/i915: Remove short term pins from execbuf by requiring lock to unbind. URL : https://patchwork.freedesktop.org/series/98137/ State : warning == Summary == $ dim checkpatch origin/drm-tip bc08f58eeb3f drm/i915: Remove unused bits of i915_vma/active api 91bcecf270f0 drm/i915: Change shrink ordering to use locking around unbinding. -:28: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #28: FILE: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:40: +static int drop_pages(struct drm_i915_gem_object *obj, + unsigned long shrink, bool trylock_vm) total: 0 errors, 0 warnings, 1 checks, 52 lines checked 316d336c98ea drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v3. 9d385c135ad3 drm/i915: Take object lock in i915_ggtt_pin if ww is not set c293606bcd36 drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2. e7fbd118c9b2 drm/i915: Ensure gem_contexts selftests work with unbind changes, v2. c9892c726d3c drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes. cc5dd7eac42f drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors 1631c2059017 drm/i915: Trylock the object when shrinking d1406f612444 drm/i915: Require object lock when freeing pages during destruction 97cc19bfa2a0 drm/i915: Add ww ctx to i915_gem_object_trylock 44fc65c4b062 drm/i915: Add locking to i915_gem_evict_vm() 8b8d9bb4ffaa drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something -:148: CHECK:LINE_SPACING: Please don't use multiple blank lines #148: FILE: drivers/gpu/drm/i915/i915_gem_evict.c:252: + total: 0 errors, 0 warnings, 1 checks, 364 lines checked d2242714f33e drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind, v2. -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: We want to remove more members of i915_vma, which requires the locking to be total: 0 errors, 1 warnings, 0 checks, 317 lines checked ece7fb471984 drm/i915: Remove assert_object_held_shared d5c98a7587ba drm/i915: Remove support for unlocked i915_vma unbind c54bb29dd0de drm/i915: Remove short-term pins from execbuf, v5.
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove short term pins from execbuf by requiring lock to unbind.
== Series Details == Series: drm/i915: Remove short term pins from execbuf by requiring lock to unbind. URL : https://patchwork.freedesktop.org/series/98137/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Remove short term pins from execbuf by requiring lock to unbind.
== Series Details == Series: drm/i915: Remove short term pins from execbuf by requiring lock to unbind. URL : https://patchwork.freedesktop.org/series/98137/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_gem_evict.c:110: warning: Function parameter or member 'ww' not described in 'i915_gem_evict_something' ./drivers/gpu/drm/i915/i915_gem_evict.c:281: warning: Function parameter or member 'ww' not described in 'i915_gem_evict_for_node' ./drivers/gpu/drm/i915/i915_gem_evict.c:393: warning: Function parameter or member 'ww' not described in 'i915_gem_evict_vm' ./drivers/gpu/drm/i915/i915_gem_gtt.c:100: warning: Function parameter or member 'ww' not described in 'i915_gem_gtt_reserve' ./drivers/gpu/drm/i915/i915_gem_gtt.c:192: warning: Function parameter or member 'ww' not described in 'i915_gem_gtt_insert'
Re: [Intel-gfx] [PATCH v4 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API
On 11/30/2021 6:46 PM, Christoph Hellwig wrote: > I still think this goes into the wrong direction. > > Something closer to your first version that also saves away the > gvt->mmio.mmio_attribute flags in the core i915 module, and which > splits the MMIO table into one that contains just the offset, size > and flags (core i915) and one that has the read-only mask and handlers > (gvt) would be much simpler and not create this super-tight coupling > between core i915 and gvt. > > Bonus points for moving your new intel_gvt_hw_state structure out > of struct intel_gvt and into struct i915_virtual_gpu. Hi Christoph: Sorry for the late reply as I am supporting the customers recently. I will refresh this after the christmas. Thanks, Zhi.
[Intel-gfx] ✗ Fi.CI.BUILD: failure for DG2 accelerated migration/clearing support (rev3)
== Series Details == Series: DG2 accelerated migration/clearing support (rev3) URL : https://patchwork.freedesktop.org/series/97544/ State : failure == Summary == Applying: drm/i915/gtt: allow overriding the pt alignment Applying: drm/i915/gtt: add xehpsdv_ppgtt_insert_entry Applying: drm/i915/migrate: add acceleration support for DG2 Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_migrate.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_migrate.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_migrate.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/i915/migrate: add acceleration support for DG2 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] ✓ Fi.CI.BAT: success for drm/i915: Remove short term pins from execbuf by requiring lock to unbind.
== Series Details == Series: drm/i915: Remove short term pins from execbuf by requiring lock to unbind. URL : https://patchwork.freedesktop.org/series/98137/ State : success == Summary == CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21861 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/index.html Participating hosts (43 -> 34) -- Additional (1): fi-pnv-d510 Missing(10): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-bdw-samus bat-jsl-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_21861 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-1115g4: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4] ([i915#4547]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html * igt@prime_vgem@basic-userptr: - fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +57 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/fi-pnv-d510/igt@prime_v...@basic-userptr.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: [FAIL][6] ([i915#1888]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_11009 -> Patchwork_21861 CI-20190529: 20190529 CI_DRM_11009: 9efbfd937cc876674559ddf8fb1897a00c10019b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6313: 1793ed798cc09966c27bf478781e0c1d6bb23bad @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21861: c54bb29dd0de9657c0becea36437f5bcca1b36fd @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c54bb29dd0de drm/i915: Remove short-term pins from execbuf, v5. d5c98a7587ba drm/i915: Remove support for unlocked i915_vma unbind ece7fb471984 drm/i915: Remove assert_object_held_shared d2242714f33e drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind, v2. 8b8d9bb4ffaa drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something 44fc65c4b062 drm/i915: Add locking to i915_gem_evict_vm() 97cc19bfa2a0 drm/i915: Add ww ctx to i915_gem_object_trylock d1406f612444 drm/i915: Require object lock when freeing pages during destruction 1631c2059017 drm/i915: Trylock the object when shrinking cc5dd7eac42f drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors c9892c726d3c drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes. e7fbd118c9b2 drm/i915: Ensure gem_contexts selftests work with unbind changes, v2. c293606bcd36 drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2. 9d385c135ad3 drm/i915: Take object lock in i915_ggtt_pin if ww is not set 316d336c98ea drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v3. 91bcecf270f0 drm/i915: Change shrink ordering to use locking around unbinding. bc08f58eeb3f drm/i915: Remove unused bits of i915_vma/active api == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/index.html
Re: [Intel-gfx] [PATCH] drm/i915/guc: Check for wedged before doing stuff
On 16/12/2021 20:30, John Harrison wrote:
On 12/16/2021 00:47, Tvrtko Ursulin wrote:
On 15/12/2021 22:45, john.c.harri...@intel.com wrote:
From: John Harrison
A fault injection probe test hit a BUG_ON in a GuC error path. It
showed that the GuC code could potentially attempt to do many things
when the device is actually wedged. So, add a check in to prevent that.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9739da6f..88f002c4d41b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1350,7 +1350,8 @@ submission_disabled(struct intel_guc *guc)
struct i915_sched_engine * const sched_engine = guc->sched_engine;
return unlikely(!sched_engine ||
- !__tasklet_is_enabled(&sched_engine->tasklet));
+ !__tasklet_is_enabled(&sched_engine->tasklet) ||
+ test_bit(I915_WEDGED, &guc_to_gt(guc)->reset.flags));
Or intel_gt_is_wedged ?
Hmm. I just copied the test from somewhere else. Is there any particular
reason why other bits of code would be doing the explicit test_bit
Lets see:
$ grep intel_gt_is_wedged . -r | wc -l
55
$ grep test_bit.*I915_WEDGED, . -r
./gt/intel_gt.h: !test_bit(I915_WEDGED, >->reset.flags));
./gt/intel_gt.h:return unlikely(test_bit(I915_WEDGED,
>->reset.flags));
./gt/intel_reset.c: if (test_bit(I915_WEDGED, >->reset.flags))
./gt/intel_reset.c: if (test_bit(I915_WEDGED, >->reset.flags))
./gt/intel_reset.c: if (!test_bit(I915_WEDGED, >->reset.flags))
./gt/intel_reset.c: if (!test_bit(I915_WEDGED, >->reset.flags))
./gt/uc/intel_guc_submission.c: test_bit(I915_WEDGED,
&guc_to_gt(guc)->reset.flags))) {
So outside the components which own the flag only GuC goes direct therefore you
might know better if there is a special reason for that.
The code there looks like this:
/* Reset called during driver load or during wedge? */
if (unlikely(!guc_submission_initialized(guc) ||
test_bit(I915_WEDGED, &guc_to_gt(guc)->reset.flags)))
return;
Perhaps that check and then one you are adding could even be partly the same?
rather than calling the helper? I see the helper has a BUG_ON. Can that
fire if called at the wrong time in the reset path?
The grep above suggests it should be safe. And looking at the assert it seems to check if
someone set the fatal wedge bit without setting the "normal" wedge eg. setting
it directly bypassing the helper. So should be fine.
Regards,
Tvrtko
[Intel-gfx] [PATCH v2 0/7] drm/i915: Asynchronous vma unbinding
This patch series introduces infrastructure for asynchronous vma unbinding. The single enabled use-case is initially at buffer object migration where we otherwise sync when unbinding vmas before migration. This in theory allows us to pipeline any number of migrations, but in practice the number is restricted by a sync wait when filling the migration context ring. We might want to look at that moving forward if needed. The other main use-case is to be able to pipeline vma evictions, for example with softpinning where a new vma wants to reuse the vm range of an already active vma. We can't support this just yet because we need dma_resv locking around vma eviction for that, which is under implementation. Patch 1 and 2 are mainly a fix and a subsequent rearrangement of code, Patch 3 is needed for consistent bind locking, Patch 4 introduces vma resource first for error capture purposes. Patch 5 changes the vm backend interface to take vma resources rather than vmas, Patch 6 introduces the async unbinding itself, and finally Patch 7 realizes we have duplicated functionality and removes the vma snapshots. v2: -- Some kernel test robot reports addressed. -- kmem cache for vma resources, See patch 6 -- Various fixes all over the place. See separate commit messages. Thomas Hellström (7): drm/i915: Avoid using the i915_fence_array when collecting dependencies drm/i915: Break out the i915_deps utility drm/i915: Require the vm mutex for i915_vma_bind() drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Use vma resources for async unbinding drm/i915: Use struct vma_resource instead of struct vma_snapshot drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_dpt.c | 27 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 67 ++- .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 304 ++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 72 ++-- drivers/gpu/drm/i915/gt/intel_gtt.c | 4 + drivers/gpu/drm/i915/gt/intel_gtt.h | 18 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 24 +- drivers/gpu/drm/i915/gt/intel_migrate.h | 9 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_deps.c | 244 +++ drivers/gpu/drm/i915/i915_deps.h | 46 +++ drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++-- drivers/gpu/drm/i915/i915_module.c| 3 + drivers/gpu/drm/i915/i915_request.c | 34 +- drivers/gpu/drm/i915/i915_request.h | 8 +- drivers/gpu/drm/i915/i915_vma.c | 213 +- drivers/gpu/drm/i915/i915_vma.h | 33 +- drivers/gpu/drm/i915/i915_vma_resource.c | 388 ++ drivers/gpu/drm/i915/i915_vma_resource.h | 232 +++ drivers/gpu/drm/i915/i915_vma_snapshot.c | 134 -- drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 - drivers/gpu/drm/i915/i915_vma_types.h | 5 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 159 --- drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +- 35 files changed, 1571 insertions(+), 840 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_deps.c create mode 100644 drivers/gpu/drm/i915/i915_deps.h create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h -- 2.31.1
[Intel-gfx] [PATCH v2 1/7] drm/i915: Avoid using the i915_fence_array when collecting dependencies
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us moving forward.
Have the gt migration code instead take a const struct i915_deps for
dependencies. This means we can skip the dma_fence_array creation
and instead pass the struct i915_deps instead to circumvent the
problem.
v2:
- Make the prev_deps() function static. (kernel test robot )
- Update the struct i915_deps kerneldoc.
Fixes: 5652df829b3c ("drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be
asynchronous")
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 129 +--
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 17 +++
drivers/gpu/drm/i915/gt/intel_migrate.c | 24 ++--
drivers/gpu/drm/i915/gt/intel_migrate.h | 9 +-
drivers/gpu/drm/i915/i915_request.c | 22
drivers/gpu/drm/i915/i915_request.h | 2 +
6 files changed, 91 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 80df9f592407..960145c8200f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,8 +3,6 @@
* Copyright © 2021 Intel Corporation
*/
-#include
-
#include
#include "i915_drv.h"
@@ -44,17 +42,12 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
#endif
/**
- * DOC: Set of utilities to dynamically collect dependencies and
- * eventually coalesce them into a single fence which is fed into
- * the GT migration code, since it only accepts a single dependency
- * fence.
- * The single fence returned from these utilities, in the case of
- * dependencies from multiple fence contexts, a struct dma_fence_array,
- * since the i915 request code can break that up and await the individual
- * fences.
+ * DOC: Set of utilities to dynamically collect dependencies into a
+ * structure which is fed into the GT migration code.
*
* Once we can do async unbinding, this is also needed to coalesce
- * the migration fence with the unbind fences.
+ * the migration fence with the unbind fences if these are coalesced
+ * post-migration.
*
* While collecting the individual dependencies, we store the refcounted
* struct dma_fence pointers in a realloc-managed pointer array, since
@@ -65,32 +58,13 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
* A struct i915_deps need to be initialized using i915_deps_init().
* If i915_deps_add_dependency() or i915_deps_add_resv() return an
* error code they will internally call i915_deps_fini(), which frees
- * all internal references and allocations. After a call to
- * i915_deps_to_fence(), or i915_deps_sync(), the struct should similarly
- * be viewed as uninitialized.
+ * all internal references and allocations.
*
* We might want to break this out into a separate file as a utility.
*/
#define I915_DEPS_MIN_ALLOC_CHUNK 8U
-/**
- * struct i915_deps - Collect dependencies into a single dma-fence
- * @single: Storage for pointer if the collection is a single fence.
- * @fence: Allocated array of fence pointers if more than a single fence;
- * otherwise points to the address of @single.
- * @num_deps: Current number of dependency fences.
- * @fences_size: Size of the @fences array in number of pointers.
- * @gfp: Allocation mode.
- */
-struct i915_deps {
- struct dma_fence *single;
- struct dma_fence **fences;
- unsigned int num_deps;
- unsigned int fences_size;
- gfp_t gfp;
-};
-
static void i915_deps_reset_fences(struct i915_deps *deps)
{
if (deps->fences != &deps->single)
@@ -163,7 +137,7 @@ static int i915_deps_grow(struct i915_deps *deps, struct
dma_fence *fence,
return ret;
}
-static int i915_deps_sync(struct i915_deps *deps,
+static int i915_deps_sync(const struct i915_deps *deps,
const struct ttm_operation_ctx *ctx)
{
struct dma_fence **fences = deps->fences;
@@ -183,7 +157,6 @@ static int i915_deps_sync(struct i915_deps *deps,
break;
}
- i915_deps_fini(deps);
return ret;
}
@@ -221,34 +194,6 @@ static int i915_deps_add_dependency(struct i915_deps *deps,
return i915_deps_grow(deps, fence, ctx);
}
-static struct dma_fence *i915_deps_to_fence(struct i915_deps *deps,
- const struct ttm_operation_ctx *ctx)
-{
- struct dma_fence_array *array;
-
- if (deps->num_deps == 0)
- return NULL;
-
- if (deps->num_deps == 1) {
- deps->num_deps = 0;
- return deps->fences[0];
- }
-
- /*
-* TODO: Alter the allocation mode here to not try too hard to
-* make things asy
[Intel-gfx] [PATCH v2 2/7] drm/i915: Break out the i915_deps utility
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 17 --
drivers/gpu/drm/i915/i915_deps.c | 244 +++
drivers/gpu/drm/i915/i915_deps.h | 46
drivers/gpu/drm/i915/i915_request.c | 2 +-
6 files changed, 293 insertions(+), 193 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_deps.c
create mode 100644 drivers/gpu/drm/i915/i915_deps.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6ddd2d2bbaaf..1b62b9f65196 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -163,6 +163,7 @@ i915-y += \
i915_active.o \
i915_buddy.o \
i915_cmd_parser.o \
+ i915_deps.o \
i915_gem_evict.o \
i915_gem_gtt.o \
i915_gem_ww.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 960145c8200f..e8a99e8cd129 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -5,6 +5,7 @@
#include
+#include "i915_deps.h"
#include "i915_drv.h"
#include "intel_memory_region.h"
#include "intel_region_ttm.h"
@@ -41,181 +42,6 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
}
#endif
-/**
- * DOC: Set of utilities to dynamically collect dependencies into a
- * structure which is fed into the GT migration code.
- *
- * Once we can do async unbinding, this is also needed to coalesce
- * the migration fence with the unbind fences if these are coalesced
- * post-migration.
- *
- * While collecting the individual dependencies, we store the refcounted
- * struct dma_fence pointers in a realloc-managed pointer array, since
- * that can be easily fed into a dma_fence_array. Other options are
- * available, like for example an xarray for similarity with drm/sched.
- * Can be changed easily if needed.
- *
- * A struct i915_deps need to be initialized using i915_deps_init().
- * If i915_deps_add_dependency() or i915_deps_add_resv() return an
- * error code they will internally call i915_deps_fini(), which frees
- * all internal references and allocations.
- *
- * We might want to break this out into a separate file as a utility.
- */
-
-#define I915_DEPS_MIN_ALLOC_CHUNK 8U
-
-static void i915_deps_reset_fences(struct i915_deps *deps)
-{
- if (deps->fences != &deps->single)
- kfree(deps->fences);
- deps->num_deps = 0;
- deps->fences_size = 1;
- deps->fences = &deps->single;
-}
-
-static void i915_deps_init(struct i915_deps *deps, gfp_t gfp)
-{
- deps->fences = NULL;
- deps->gfp = gfp;
- i915_deps_reset_fences(deps);
-}
-
-static void i915_deps_fini(struct i915_deps *deps)
-{
- unsigned int i;
-
- for (i = 0; i < deps->num_deps; ++i)
- dma_fence_put(deps->fences[i]);
-
- if (deps->fences != &deps->single)
- kfree(deps->fences);
-}
-
-static int i915_deps_grow(struct i915_deps *deps, struct dma_fence *fence,
- const struct ttm_operation_ctx *ctx)
-{
- int ret;
-
- if (deps->num_deps >= deps->fences_size) {
- unsigned int new_size = 2 * deps->fences_size;
- struct dma_fence **new_fences;
-
- new_size = max(new_size, I915_DEPS_MIN_ALLOC_CHUNK);
- new_fences = kmalloc_array(new_size, sizeof(*new_fences),
deps->gfp);
- if (!new_fences)
- goto sync;
-
- memcpy(new_fences, deps->fences,
- deps->fences_size * sizeof(*new_fences));
- swap(new_fences, deps->fences);
- if (new_fences != &deps->single)
- kfree(new_fences);
- deps->fences_size = new_size;
- }
- deps->fences[deps->num_deps++] = dma_fence_get(fence);
- return 0;
-
-sync:
- if (ctx->no_wait_gpu && !dma_fence_is_signaled(fence)) {
- ret = -EBUSY;
- goto unref;
- }
-
- ret = dma_fence_wait(fence, ctx->interruptible);
- if (ret)
- goto unref;
-
- ret = fence->error;
- if (ret)
- goto unref;
-
- return 0;
-
-unref:
- i915_deps_fini(deps);
- return ret;
-}
-
-static int i915_deps_sync(const struct i915_deps *deps,
- const struct ttm_operation_ctx *ctx)
-{
- struct dma_fence **fences = deps->fences;
- unsigned int i;
- int ret = 0;
-
- for (i = 0; i < deps->num_deps; ++i, ++fences) {
- if (ctx->no_wait_gpu && !dma_fence_is_signaled(*fences)) {
- ret = -EBUSY;
-
[Intel-gfx] [PATCH v2 5/7] drm/i915: Use the vma resource as argument for gtt binding / unbinding
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the insert_entries() op for struct i915_address_space.
Replace a couple of i915_vma_snapshot members with their newly introduced
i915_vma_resource counterparts, since they have the same lifetime.
Also make sure to avoid changing the struct i915_vma_flags (in particular
the bind flags) async. That should now only be done sync under the
vm mutex.
v2:
- Update the vma_res::bound_flags when binding to the aliased ggtt
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_dpt.c | 27 ++---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 ++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 70 ++---
drivers/gpu/drm/i915/gt/intel_gtt.h | 15 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 24 -
drivers/gpu/drm/i915/i915_vma.h | 11 +--
drivers/gpu/drm/i915/i915_vma_resource.c | 9 +-
drivers/gpu/drm/i915/i915_vma_resource.h | 99 ++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 4 -
drivers/gpu/drm/i915/i915_vma_snapshot.h | 8 --
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 64
drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +--
21 files changed, 307 insertions(+), 206 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 963ca7155b06..f9f2a4ef38cd 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -48,7 +48,7 @@ static void dpt_insert_page(struct i915_address_space *vm,
}
static void dpt_insert_entries(struct i915_address_space *vm,
- struct i915_vma *vma,
+ struct i915_vma_resource *vma_res,
enum i915_cache_level level,
u32 flags)
{
@@ -64,8 +64,8 @@ static void dpt_insert_entries(struct i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- i = vma->node.start / I915_GTT_PAGE_SIZE;
- for_each_sgt_daddr(addr, sgt_iter, vma->pages)
+ i = vma_res->start / I915_GTT_PAGE_SIZE;
+ for_each_sgt_daddr(addr, sgt_iter, vma_res->bi.pages)
gen8_set_pte(&base[i++], pte_encode | addr);
}
@@ -76,35 +76,38 @@ static void dpt_clear_range(struct i915_address_space *vm,
static void dpt_bind_vma(struct i915_address_space *vm,
struct i915_vm_pt_stash *stash,
-struct i915_vma *vma,
+struct i915_vma_resource *vma_res,
enum i915_cache_level cache_level,
u32 flags)
{
- struct drm_i915_gem_object *obj = vma->obj;
u32 pte_flags;
+ if (vma_res->bound_flags)
+ return;
+
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
- if (vma->vm->has_read_only && i915_gem_object_is_readonly(obj))
+ if (vm->has_read_only && vma_res->bi.readonly)
pte_flags |= PTE_READ_ONLY;
- if (i915_gem_object_is_lmem(obj))
+ if (vma_res->bi.lmem)
pte_flags |= PTE_LM;
- vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
+ vm->insert_entries(vm, vma_res, cache_level, pte_flags);
- vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
+ vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
/*
* Without aliasing PPGTT there's no difference between
* GLOBAL/LOCAL_BIND, it's all the same ptes. Hence unconditionally
* upgrade to both bound if we bind either to avoid double-binding.
*/
- atomic_or(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND, &vma->flags);
+ vma_res->bound_flags = I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
}
-static void dpt_unbind_vma(struct i915_address_space *vm, struct i915_vma *vma)
+static void dpt_unbind_vma(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res)
{
- vm->clear_range(vm, vma->node.start, vma->size);
+ vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
static void dpt_cleanup(struct i915_ad
[Intel-gfx] [PATCH v2 3/7] drm/i915: Require the vm mutex for i915_vma_bind()
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but since we block cpu
unplugging during sleeps inside kmap_local() sections this may have
unwanted side-effects. Particularly since we might wait for gpu while
holding the vm mutex.
This change may theoretically increase execbuf cpu-usage on snb, but
at least on non-highmem systems that increase should be very small.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 50 ++-
drivers/gpu/drm/i915/i915_vma.c | 1 +
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2213f7b613da..6013f7e18f60 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1109,6 +1109,47 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
reloc_cache *cache)
return &i915->ggtt;
}
+static void reloc_cache_unmap(struct reloc_cache *cache)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ vaddr = unmask_page(cache->vaddr);
+ if (cache->vaddr & KMAP)
+ kunmap_atomic(vaddr);
+ else
+ io_mapping_unmap_atomic((void __iomem *)vaddr);
+}
+
+static void reloc_cache_remap(struct reloc_cache *cache,
+ struct drm_i915_gem_object *obj)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ if (cache->vaddr & KMAP) {
+ struct page *page = i915_gem_object_get_page(obj, cache->page);
+
+ vaddr = kmap_atomic(page);
+ cache->vaddr = unmask_flags(cache->vaddr) |
+ (unsigned long)vaddr;
+ } else {
+ struct i915_ggtt *ggtt = cache_to_ggtt(cache);
+ unsigned long offset;
+
+ offset = cache->node.start;
+ if (!drm_mm_node_allocated(&cache->node))
+ offset += cache->page << PAGE_SHIFT;
+
+ cache->vaddr = (unsigned long)
+ io_mapping_map_atomic_wc(&ggtt->iomap, offset);
+ }
+}
+
static void reloc_cache_reset(struct reloc_cache *cache, struct
i915_execbuffer *eb)
{
void *vaddr;
@@ -1373,10 +1414,17 @@ eb_relocate_entry(struct i915_execbuffer *eb,
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
- GRAPHICS_VER(eb->i915) == 6) {
+ GRAPHICS_VER(eb->i915) == 6 &&
+ !i915_vma_is_bound(target->vma, I915_VMA_GLOBAL_BIND)) {
+ struct i915_vma *vma = target->vma;
+
+ reloc_cache_unmap(&eb->reloc_cache);
+ mutex_lock(&vma->vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
+ mutex_unlock(&vma->vm->mutex);
+ reloc_cache_remap(&eb->reloc_cache, ev->vma->obj);
if (err)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 927f0d4f8e11..d792a3d0da7a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -398,6 +398,7 @@ int i915_vma_bind(struct i915_vma *vma,
u32 bind_flags;
u32 vma_flags;
+ lockdep_assert_held(&vma->vm->mutex);
GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
GEM_BUG_ON(vma->size > vma->node.size);
--
2.31.1
[Intel-gfx] [PATCH v2 4/7] drm/i915: Initial introduction of vma resources
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 55 +++-
drivers/gpu/drm/i915/i915_vma.h | 19 ++-
drivers/gpu/drm/i915/i915_vma_resource.c | 124 ++
drivers/gpu/drm/i915/i915_vma_resource.h | 70 ++
drivers/gpu/drm/i915/i915_vma_snapshot.c | 15 +--
drivers/gpu/drm/i915/i915_vma_snapshot.h | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 5 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 99 --
10 files changed, 334 insertions(+), 63 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b62b9f65196..98433ad74194 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -174,6 +174,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
+ i915_vma_resource.o \
i915_vma_snapshot.o \
intel_wopcm.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6013f7e18f60..b6faae1f9081 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1422,7 +1422,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
mutex_lock(&vma->vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
- PIN_GLOBAL, NULL);
+ PIN_GLOBAL, NULL, NULL);
mutex_unlock(&vma->vm->mutex);
reloc_cache_remap(&eb->reloc_cache, ev->vma->obj);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d792a3d0da7a..4308659bf552 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -37,6 +37,7 @@
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
#include "i915_vma.h"
+#include "i915_vma_resource.h"
static struct kmem_cache *slab_vmas;
@@ -385,6 +386,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
* @cache_level: mapping cache level
* @flags: flags like global or local mapping
* @work: preallocated worker for allocating and binding the PTE
+ * @vma_res: pointer to a preallocated vma resource. The resource is either
+ * consumed or freed.
*
* DMA addresses are taken from the scatter-gather table of this object (or of
* this VMA in case of non-default GGTT views) and PTE entries set up.
@@ -393,7 +396,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
int i915_vma_bind(struct i915_vma *vma,
enum i915_cache_level cache_level,
u32 flags,
- struct i915_vma_work *work)
+ struct i915_vma_work *work,
+ struct i915_vma_resource *vma_res)
{
u32 bind_flags;
u32 vma_flags;
@@ -404,11 +408,15 @@ int i915_vma_bind(struct i915_vma *vma,
if (GEM_DEBUG_WARN_ON(range_overflows(vma->node.start,
vma->node.size,
- vma->vm->total)))
+ vma->vm->total))) {
+ kfree(vma_res);
return -ENODEV;
+ }
- if (GEM_DEBUG_WARN_ON(!flags))
+ if (GEM_DEBUG_WARN_ON(!flags)) {
+ kfree(vma_res);
return -EINVAL;
+ }
bind_flags = flags;
bind_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
@@ -417,11 +425,21 @@ int i915_vma_bind(struct i915_vma *vma,
vma_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
bind_flags &= ~vma_flags;
- if (bind_flags == 0)
+ if (bind_flags == 0) {
+ kfree(vma_res);
return 0;
+ }
GEM_BUG_ON(!vma->pages);
+ if (vma->resource || !vma_res) {
+ /* Rebinding with an additional I915_VMA_*_BIND */
+ GEM_WARN_ON(!vma_flags);
+ kfree(vma_res);
+ } else {
+ i915_vma_resource_init(vma_res);
+ vma->resource = vma_res;
+ }
trace_i915_vma_bind(vma, bind_flags);
if (work && bind_flags & vma->vm->bind_async_flags) {
struct dma_fence *prev;
@@ -897,6 +915,7 @
[Intel-gfx] [PATCH v2 6/7] drm/i915: Use vma resources for async unbinding
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to avoid stalling the migration blit waiting for unbind, as they
can certainly go on in parallel, but since we don't yet have a
reasonable data structure to use to coalesce fences and attach the
resulting fence to a timeline, we defer that for now.
Note that with async unbinding, even while the unbind waits for the
preceding bind to complete before unbinding, the vma itself might have been
destroyed in the process, clearing the vma pages. Therefore we can
only allow async unbinding if we have a refcounted sg-list and keep a
refcount on that for the vma resource pages to stay intact until
binding occurs. If this condition is not met, a request for an async
unbind is diverted to a sync unbind.
v2:
- Use a separate kmem_cache for vma resources for now to isolate their
memory allocation and aid debugging.
- Move the check for vm closed to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_module.c | 3 +
drivers/gpu/drm/i915/i915_vma.c | 181 --
drivers/gpu/drm/i915/i915_vma.h | 3 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 326 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 45 +++
11 files changed, 519 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index e8a99e8cd129..0b0477f0af8b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -142,7 +142,16 @@ int i915_ttm_move_notify(struct ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
int ret;
- ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE);
+ /*
+* Note: The async unbinding here will actually transform the
+* blocking wait for unbind into a wait before finally submitting
+* evict / migration blit and thus stall the migration timeline
+* which may not be good for overall throughput. We should make
+* sure we await the unbind fences *after* the migration blit
+* instead of *before* as we currently do.
+*/
+ ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE |
+I915_GEM_OBJECT_UNBIND_ASYNC);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index ad54941fcb98..3e9fbbfa13c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -145,7 +145,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
continue;
if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
- __i915_vma_evict(vma);
+ __i915_vma_evict(vma, false);
drm_mm_remove_node(&vma->node);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 30683c06b344..b582a4c6c3c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -161,6 +161,9 @@ static void __i915_vm_release(struct work_struct *work)
struct i915_address_space *vm =
container_of(work, struct i915_address_space, release_work);
+ /* Synchronize async unbinds. */
+ i915_vma_resource_bind_dep_sync_all(vm);
+
vm->cleanup(vm);
i915_address_space_fini(vm);
@@ -189,6 +192,7 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
if (!kref_read(&vm->resv_ref))
kref_init(&vm->resv_ref);
+ vm->pending_unbind = RB_ROOT_CACHED;
INIT_WORK(&vm->release_work, __i915_vm_release);
atomic_set(&vm->open, 1);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 19c2497630e8..b9bd60cb2687 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -267,6 +267,9 @@ struct i915_address_space {
/* Flags used when creating page-table objects for this vm */
unsigned long lmem_pt_obj_flags;
+ /*
[Intel-gfx] [PATCH v2 7/7] drm/i915: Use struct vma_resource instead of struct vma_snapshot
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a small price to pay for the simplification.
v2:
- Fix a missing include and declaration (kernel test robot )
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++--
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 14 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 3 +
drivers/gpu/drm/i915/i915_vma_resource.h | 28 +++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 125 --
drivers/gpu/drm/i915/i915_vma_snapshot.h | 101 --
11 files changed, 88 insertions(+), 313 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 98433ad74194..aa86ac33effc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -175,7 +175,6 @@ i915-y += \
i915_ttm_buddy_manager.o \
i915_vma.o \
i915_vma_resource.o \
- i915_vma_snapshot.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b6faae1f9081..51649bbb8cc3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -29,7 +29,6 @@
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-#include "i915_vma_snapshot.h"
struct eb_vma {
struct i915_vma *vma;
@@ -1952,7 +1951,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
{
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
- struct i915_vma_snapshot *vsnap;
while (i--) {
struct eb_vma *ev = &eb->vma[i];
@@ -1962,11 +1960,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
- vsnap = i915_vma_snapshot_alloc(GFP_KERNEL);
- if (!vsnap)
- continue;
-
- i915_vma_snapshot_init(vsnap, vma, "user");
for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
@@ -1975,10 +1968,9 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
continue;
capture->next = eb->capture_lists[j];
- capture->vma_snapshot = i915_vma_snapshot_get(vsnap);
+ capture->vma_res = i915_vma_resource_get(vma->resource);
eb->capture_lists[j] = capture;
}
- i915_vma_snapshot_put(vsnap);
}
}
@@ -3281,9 +3273,8 @@ eb_requests_create(struct i915_execbuffer *eb, struct
dma_fence *in_fence,
* _onstack interface.
*/
if (eb->batches[i]->vma)
-
i915_vma_snapshot_init_onstack(&eb->requests[i]->batch_snapshot,
- eb->batches[i]->vma,
- "batch");
+ eb->requests[i]->batch_res =
+
i915_vma_resource_get(eb->batches[i]->vma->resource);
if (eb->batch_pool) {
GEM_BUG_ON(intel_context_is_parallel(eb->context));
intel_gt_buffer_pool_mark_active(eb->batch_pool,
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 74aa90587061..d1daa4cc2895 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1708,18 +1708,15 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
static void print_request_ring(struct drm_printer *m, struct i915_request *rq)
{
- struct i915_vma_snapshot *vsnap = &rq->batch_snapshot;
+ struct i915_vma_resource *vma_res = rq->batch_res;
void *ring;
int size;
- if (!i915_vma_snapshot_present(vsnap))
- vsnap = NULL;
-
drm_printf(m,
"[head %04x, postfix %04x, tail %04x, batch 0x%08x_%08x]:\n",
rq->head, rq->postfix, rq->tail,
- vsnap ? upper_32_bits(vsnap->vma_resou
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Request RP0 before loading firmware (rev3)
== Series Details == Series: drm/i915/guc: Request RP0 before loading firmware (rev3) URL : https://patchwork.freedesktop.org/series/97682/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm()
== Series Details ==
Series: drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm()
URL : https://patchwork.freedesktop.org/series/98154/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21863
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_21863 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21863, 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_21863/index.html
Participating hosts (43 -> 34)
--
Additional (1): fi-skl-guc
Missing(10): fi-bxt-dsi bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-bsw-cyan
bat-adlp-6 bat-adlp-4 fi-bdw-samus bat-jsl-2 bat-jsl-1
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21863:
### IGT changes ###
Possible regressions
* igt@core_hotunplug@unbind-rebind:
- fi-blb-e6850: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.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-jsl-1}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-jsl-1/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-jsl-1/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_21863 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-skl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#3303])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][10] -> [INCOMPLETE][11] ([i915#3921])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][14] ([fdo#109271]) +28 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][15] ([fdo#109271]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-skl-guc: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21863/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@prim
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enabling WD Transcoder
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Adding support for writeback transcoder to start capturing frames using
> interrupt mechanism
I stopped reviewing this after a while, because there's just way too
much unrelated noise in the patch to even be able to focus on what's
actually being done functionally here. There are some comments inline
before I stopped.
Please don't do random superfluous whitespace or checkpatch changes in
the same patch. It's just a distraction.
Functionally the most questionable thing I spotted is adding the
intel_crtc and intel_wd pointer members in struct
drm_i915_private. That's not the kind of design we'll want. It should
all be in the atomic state.
Also, what is this in intel_wd.c:
> +static const struct drm_display_mode drm_dmt_modes[] = {
Please no.
BR,
Jani.
>
> Signed-off-by: suraj kandpal
> ---
> drivers/gpu/drm/i915/Makefile |2 +
> drivers/gpu/drm/i915/display/intel_acpi.c |1 +
> drivers/gpu/drm/i915/display/intel_display.c | 166 ++-
> drivers/gpu/drm/i915/display/intel_display.h |5 +
> .../drm/i915/display/intel_display_power.h|1 +
> .../drm/i915/display/intel_display_types.h|8 +
> drivers/gpu/drm/i915/display/intel_dpll.c |6 +
> drivers/gpu/drm/i915/display/intel_opregion.c |3 +
> .../gpu/drm/i915/display/intel_wb_connector.h | 20 +
> drivers/gpu/drm/i915/display/intel_wd.c | 1139 +
> drivers/gpu/drm/i915/display/intel_wd.h | 70 +
> .../drm/i915/display/skl_universal_plane.c|1 -
> drivers/gpu/drm/i915/i915_drv.h |5 +
> drivers/gpu/drm/i915/i915_irq.c |8 +-
> drivers/gpu/drm/i915/i915_pci.c |7 +-
> drivers/gpu/drm/i915/i915_reg.h | 139 +-
> 16 files changed, 1527 insertions(+), 54 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 5c8e022a7383..5472bb48196b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -206,6 +206,7 @@ i915-y += \
> display/intel_connector.o \
> display/intel_crtc.o \
> display/intel_cursor.o \
> + display/intel_wd.o \
Adding it twice?
> display/intel_display.o \
> display/intel_display_power.o \
> display/intel_dmc.o \
> @@ -276,6 +277,7 @@ i915-y += \
> display/intel_tv.o \
> display/intel_vdsc.o \
> display/intel_vrr.o \
> + display/intel_wd.o \
> display/vlv_dsi.o \
> display/vlv_dsi_pll.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 72cac55c0f0f..98537c7de20c 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -244,6 +244,7 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
> case DRM_MODE_CONNECTOR_LVDS:
> case DRM_MODE_CONNECTOR_eDP:
> case DRM_MODE_CONNECTOR_DSI:
> + case DRM_MODE_CONNECTOR_WRITEBACK:
> display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
> break;
> case DRM_MODE_CONNECTOR_Unknown:
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f27c294beb92..4a9e5972f381 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -105,6 +105,7 @@
> #include "intel_tc.h"
> #include "intel_vga.h"
> #include "i9xx_plane.h"
> +#include "intel_wd.h"
Please keep include lists sorted.
> #include "skl_scaler.h"
> #include "skl_universal_plane.h"
>
> @@ -195,10 +196,13 @@ skl_wa_827(struct drm_i915_private *dev_priv, enum pipe
> pipe, bool enable)
> {
> if (enable)
> intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> + intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> + DUPS1_GATING_DIS |
> + DUPS2_GATING_DIS);
> else
> intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> + intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> + ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> }
Superfluous changes that should not be part of this patch.
>
> /* Wa_2006604312:icl,ehl */
> @@ -208,10 +212,10 @@ icl_wa_scalerclkgating(struct drm_i915_private
> *dev_priv, enum pipe pipe,
> {
> if (enable)
> intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -
Re: [Intel-gfx] [PATCH 1/4] drm: add writeback pointers to drm_connector
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Adding drm_writeback_connector to drm_connector so that
> writeback_connector can be fetched from drm_connector
This needs some explaining, since drm_connector_to_writeback() does
exactly that.
> Adding drm_connector and drm_encoder pointers in drm_writeback_connector
Why?
We can all read the code, the commit message should mostly be about the
*why*.
Also, drm changes should Cc: dri-devel mailing list.
BR,
Jani.
>
> Signed-off-by: suraj kandpal
> ---
> drivers/gpu/drm/drm_writeback.c | 19 ++-
> include/drm/drm_connector.h | 3 +++
> include/drm/drm_writeback.h | 6 +++---
> 3 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index dccf4504f1bb..47238db42363 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -87,7 +87,7 @@ static const char
> *drm_writeback_fence_get_driver_name(struct dma_fence *fence)
> struct drm_writeback_connector *wb_connector =
> fence_to_wb_connector(fence);
>
> - return wb_connector->base.dev->driver->name;
> + return wb_connector->base->dev->driver->name;
> }
>
> static const char *
> @@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>const u32 *formats, int n_formats)
> {
> struct drm_property_blob *blob;
> - struct drm_connector *connector = &wb_connector->base;
> + struct drm_connector *connector = wb_connector->base;
> struct drm_mode_config *config = &dev->mode_config;
> int ret = create_writeback_properties(dev);
>
> @@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
> if (IS_ERR(blob))
> return PTR_ERR(blob);
>
> - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> - ret = drm_encoder_init(dev, &wb_connector->encoder,
> + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> + ret = drm_encoder_init(dev, wb_connector->encoder,
> &drm_writeback_encoder_funcs,
> DRM_MODE_ENCODER_VIRTUAL, NULL);
> if (ret)
> goto fail;
>
> connector->interlace_allowed = 0;
> + connector->wb_connector = wb_connector;
>
> ret = drm_connector_init(dev, connector, con_funcs,
>DRM_MODE_CONNECTOR_WRITEBACK);
> @@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> goto connector_fail;
>
> ret = drm_connector_attach_encoder(connector,
> - &wb_connector->encoder);
> + wb_connector->encoder);
> if (ret)
> goto attach_fail;
>
> @@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> attach_fail:
> drm_connector_cleanup(connector);
> connector_fail:
> - drm_encoder_cleanup(&wb_connector->encoder);
> + drm_encoder_cleanup(wb_connector->encoder);
> fail:
> drm_property_blob_put(blob);
> return ret;
> @@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job
> *job)
> {
> struct drm_writeback_connector *connector = job->connector;
> const struct drm_connector_helper_funcs *funcs =
> - connector->base.helper_private;
> + connector->base->helper_private;
> int ret;
>
> if (funcs->prepare_writeback_job) {
> @@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job
> *job)
> {
> struct drm_writeback_connector *connector = job->connector;
> const struct drm_connector_helper_funcs *funcs =
> - connector->base.helper_private;
> + connector->base->helper_private;
>
> if (job->prepared && funcs->cleanup_writeback_job)
> funcs->cleanup_writeback_job(connector, job);
> @@ -401,7 +402,7 @@ drm_writeback_get_out_fence(struct
> drm_writeback_connector *wb_connector)
> {
> struct dma_fence *fence;
>
> - if (WARN_ON(wb_connector->base.connector_type !=
> + if (WARN_ON(wb_connector->base->connector_type !=
> DRM_MODE_CONNECTOR_WRITEBACK))
> return NULL;
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 379746d3266f..ec049b1bc4bb 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -42,6 +42,7 @@ struct drm_property_blob;
> struct drm_printer;
> struct edid;
> struct i2c_adapter;
> +struct drm_writeback_connector;
>
> enum drm_connector_force {
> DRM_FORCE_UNSPECIFIED,
> @@ -1483,6 +1484,8 @@ struct drm_connector {
>*/
> struct drm_encoder *encoder;
>
> + struct drm_writeback_connector *wb_connector;
> +
> #define MAX_ELD_BYTES128
> /** @eld: E
[Intel-gfx] [PATCH v3] drm/i915/dsi: let HW maintain the HS-TRAIL timing
This change is to avoid over-specification of the TEOT timing
parameter, which is derived from software in current design.
Supposed that THS-TRAIL and THS-EXIT have the minimum values,
i.e., 60 and 100 in ns. If SW is overriding the HW default,
the TEOT value becomes 150 ns, approximately calculated by
the following formula.
DIV_ROUND_UP(60/50)*50 + DIV_ROUND_UP(100/50))*50/2, where 50
is LP Escape Clock time in ns.
The TEOT value 150 ns is larger than the maximum value,
around 136 ns if UI is 1.8ns, (105 ns + 12*UI, defined by MIPI
DPHY specification).
However, the TEOT value will meet the specification if THS-TRAIL
is set to the HW default, instead of software overriding.
The timing change is made for both data lane and clock lane.
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Vandita Kulkarni
Cc: Lee Shawn C
Cc: Cooper Chiou
Signed-off-by: William Tseng
---
drivers/gpu/drm/i915/display/icl_dsi.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 168c84a74d30..992e357e3f44 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1863,14 +1863,13 @@ static void icl_dphy_param_init(struct intel_dsi
*intel_dsi)
struct drm_i915_private *dev_priv = to_i915(dev);
struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
u32 tlpx_ns;
- u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
- u32 ths_prepare_ns, tclk_trail_ns;
+ u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt;
+ u32 ths_prepare_ns;
u32 hs_zero_cnt;
u32 tclk_pre_cnt, tclk_post_cnt;
tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
- tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
ths_prepare_ns = max(mipi_config->ths_prepare,
mipi_config->tclk_prepare);
@@ -1897,14 +1896,6 @@ static void icl_dphy_param_init(struct intel_dsi
*intel_dsi)
clk_zero_cnt = ICL_CLK_ZERO_CNT_MAX;
}
- /* trail cnt in escape clocks*/
- trail_cnt = DIV_ROUND_UP(tclk_trail_ns, tlpx_ns);
- if (trail_cnt > ICL_TRAIL_CNT_MAX) {
- drm_dbg_kms(&dev_priv->drm, "trail_cnt out of range (%d)\n",
- trail_cnt);
- trail_cnt = ICL_TRAIL_CNT_MAX;
- }
-
/* tclk pre count in escape clocks */
tclk_pre_cnt = DIV_ROUND_UP(mipi_config->tclk_pre, tlpx_ns);
if (tclk_pre_cnt > ICL_TCLK_PRE_CNT_MAX) {
@@ -1948,17 +1939,13 @@ static void icl_dphy_param_init(struct intel_dsi
*intel_dsi)
CLK_PRE_OVERRIDE |
CLK_PRE(tclk_pre_cnt) |
CLK_POST_OVERRIDE |
- CLK_POST(tclk_post_cnt) |
- CLK_TRAIL_OVERRIDE |
- CLK_TRAIL(trail_cnt));
+ CLK_POST(tclk_post_cnt));
/* data lanes dphy timings */
intel_dsi->dphy_data_lane_reg = (HS_PREPARE_OVERRIDE |
HS_PREPARE(prepare_cnt) |
HS_ZERO_OVERRIDE |
HS_ZERO(hs_zero_cnt) |
-HS_TRAIL_OVERRIDE |
-HS_TRAIL(trail_cnt) |
HS_EXIT_OVERRIDE |
HS_EXIT(exit_zero_cnt));
--
2.17.1
Re: [Intel-gfx] [PATCH 2/4] drm/komeda: change driver to use drm_writeback_connector.base pointer
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Changing driver to use drm_writeback_connector.base pointer
Every commit should build and work on its own, so this makes me believe
the previous patch breaks the build.
Also, why?
You see that (in our clunky object hierarchy implemented in C)
komeda_wb_connector extends drm_writeback_connector which extends
drm_connector. Why do you think we should change that hierarchy?
BR,
Jani.
>
> Signed-off-by: suraj kandpal
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
> drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 3 ++-
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 9 +
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 59172acb9738..eb37f41c1790 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
> if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
> komeda_pipeline_update(slave, old->state);
>
> - conn_st = wb_conn ? wb_conn->base.base.state : NULL;
> + conn_st = wb_conn ? wb_conn->base.base->state : NULL;
> if (conn_st && conn_st->writeback_job)
> drm_writeback_queue_job(&wb_conn->base, conn_st);
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 456f3c435719..8d83883a1d99 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -53,6 +53,7 @@ struct komeda_plane_state {
> * struct komeda_wb_connector
> */
> struct komeda_wb_connector {
> + struct drm_connector conn;
> /** @base: &drm_writeback_connector */
> struct drm_writeback_connector base;
>
> @@ -136,7 +137,7 @@ struct komeda_kms_dev {
> static inline bool is_writeback_only(struct drm_crtc_state *st)
> {
> struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
> - struct drm_connector *conn = wb_conn ? &wb_conn->base.base : NULL;
> + struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
>
> return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
> }
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> index e465cc4879c9..0caaf483276d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> @@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
> return -EINVAL;
> }
>
> - wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
> + wb_layer =
> to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
>
> /*
>* No need for a full modested when the only connector changed is the
> @@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector
> *connector,
> static void komeda_wb_connector_destroy(struct drm_connector *connector)
> {
> drm_connector_cleanup(connector);
> - kfree(to_kconn(to_wb_conn(connector)));
> + kfree(to_kconn(drm_connector_to_writeback(connector)));
> }
>
> static const struct drm_connector_funcs komeda_wb_connector_funcs = {
> @@ -155,6 +155,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
> *kms,
> kwb_conn->wb_layer = kcrtc->master->wb_layer;
>
> wb_conn = &kwb_conn->base;
> + wb_conn->base = &kwb_conn->conn;
> wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
>
> formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
> @@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
> *kms,
> return err;
> }
>
> - drm_connector_helper_add(&wb_conn->base, &komeda_wb_conn_helper_funcs);
> + drm_connector_helper_add(wb_conn->base, &komeda_wb_conn_helper_funcs);
>
> - info = &kwb_conn->base.base.display_info;
> + info = &kwb_conn->base.base->display_info;
> info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
> info->color_formats = kcrtc->master->improc->supported_color_formats;
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BUILD: failure for More preparation for multi gt patches (rev2)
== Series Details == Series: More preparation for multi gt patches (rev2) URL : https://patchwork.freedesktop.org/series/98032/ State : failure == Summary == Applying: drm/i915: Store backpointer to GT in uncore Applying: drm/i915: Introduce to_gt() helper Applying: drm/i915/display: Use to_gt() helper Applying: drm/i915/gt: Use to_gt() helper Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/uc/selftest_guc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/uc/selftest_guc.c warning: quoted CRLF detected Applying: drm/i915/gem: Use to_gt() helper Applying: drm/i915/gvt: Use to_gt() helper Applying: drm/i915/selftests: Use to_gt() helper Applying: drm/i915/pxp: Use to_gt() helper Applying: drm/i915: Use to_gt() helper Applying: drm/i915: Rename i915->gt to i915->gt0 Applying: drm/i915/gem: Use to_gt() helper for GGTT accesses error: corrupt patch at line 44 error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0011 drm/i915/gem: Use to_gt() helper for GGTT accesses When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Define WD trancoder for i915
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
This should be part of the patch that uses them.
BR,
Jani.
>
> Signed-off-by: suraj kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 6 ++
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h| 2 ++
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index d425ee77aad7..76f999525d43 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -117,6 +117,8 @@ enum transcoder {
> TRANSCODER_DSI_1,
> TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
> TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
> + TRANSCODER_WD_0,
> + TRANSCODER_WD_1,
>
> I915_MAX_TRANSCODERS
> };
> @@ -138,6 +140,10 @@ static inline const char *transcoder_name(enum
> transcoder transcoder)
> return "DSI A";
> case TRANSCODER_DSI_C:
> return "DSI C";
> + case TRANSCODER_WD_0:
> + return "WD 0";
> + case TRANSCODER_WD_1:
> + return "WD 1";
> default:
> return "";
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 9413ebae15f5..f20086280d7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -69,6 +69,7 @@ enum intel_output_type {
> INTEL_OUTPUT_DSI = 9,
> INTEL_OUTPUT_DDI = 10,
> INTEL_OUTPUT_DP_MST = 11,
> + INTEL_OUTPUT_WD = 12,
> };
>
> enum hdmi_force_audio {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ef594df039db..b8e42c55ff87 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4431,6 +4431,8 @@ enum {
> #define TRANSCODER_EDP_OFFSET 0x6f000
> #define TRANSCODER_DSI0_OFFSET 0x6b000
> #define TRANSCODER_DSI1_OFFSET 0x6b800
> +#define TRANSCODER_WD0_OFFSET0x6e000
> +#define TRANSCODER_WD1_OFFSET0x6e800
>
> #define HTOTAL(trans)_MMIO_TRANS2(trans, _HTOTAL_A)
> #define HBLANK(trans)_MMIO_TRANS2(trans, _HBLANK_A)
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Request RP0 before loading firmware (rev3)
== Series Details == Series: drm/i915/guc: Request RP0 before loading firmware (rev3) URL : https://patchwork.freedesktop.org/series/97682/ State : success == Summary == CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21864 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/index.html Participating hosts (43 -> 36) -- Additional (2): fi-skl-guc fi-pnv-d510 Missing(9): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-bdw-samus bat-jsl-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_21864 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-1115g4: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-skl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-guc/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live: - fi-skl-6600u: NOTRUN -> [FAIL][6] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@i915_selft...@live.html * igt@kms_chamelium@dp-crc-fast: - fi-skl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-skl-guc: NOTRUN -> [SKIP][9] ([fdo#109271]) +28 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][10] ([fdo#109271]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#4269]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-skl-guc: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-pnv-d510:NOTRUN -> [SKIP][15] ([fdo#109271]) +57 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-pnv-d510/igt@prime_v...@basic-userptr.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: [FAIL][16] ([i915#1888]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [FAIL][18] ([i915#4547]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html Warnings * igt@runner@aborted: - fi-skl-6600u: [FAIL][20] ([i915#4312]) -> [FAIL][21] ([i915#1436] / [i915#4312]) [20]:
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm()
On Thu, 16 Dec 2021, Harish Chegondi wrote:
> Check return pointer from intel_crtc_for_plane() before dereferencing
> it, as it can be NULL.
If you're doing this to satisfy some static analyzer, in these cases the
code would read *much* better if you added the NULL check inside
intel_crtc_active().
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Caz Yokoyama
> Cc: Radhakrishna Sripada
> Signed-off-by: Harish Chegondi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index bdf97a8c9ef3..c7a4d8d971d7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2373,7 +2373,7 @@ static void i9xx_update_wm(struct drm_i915_private
> *dev_priv)
> else
> fifo_size = i9xx_get_fifo_size(dev_priv, PLANE_A);
> crtc = intel_crtc_for_plane(dev_priv, PLANE_A);
> - if (intel_crtc_active(crtc)) {
> + if (crtc && intel_crtc_active(crtc)) {
> const struct drm_display_mode *pipe_mode =
> &crtc->config->hw.pipe_mode;
> const struct drm_framebuffer *fb =
> @@ -2403,7 +2403,7 @@ static void i9xx_update_wm(struct drm_i915_private
> *dev_priv)
> else
> fifo_size = i9xx_get_fifo_size(dev_priv, PLANE_B);
> crtc = intel_crtc_for_plane(dev_priv, PLANE_B);
> - if (intel_crtc_active(crtc)) {
> + if (crtc && intel_crtc_active(crtc)) {
> const struct drm_display_mode *pipe_mode =
> &crtc->config->hw.pipe_mode;
> const struct drm_framebuffer *fb =
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: remove circ_buf.h includes
On Thu, 16 Dec 2021, Patchwork wrote: > == Series Details == > > Series: drm/i915: remove circ_buf.h includes > URL : https://patchwork.freedesktop.org/series/98130/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > 24a5cb6b532c drm/i915: remove circ_buf.h includes > -:44: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address > mismatch: 'From: Jiri Slaby ' != 'Signed-off-by: Jiri > Slaby ' > > total: 0 errors, 1 warnings, 0 checks, 14 lines checked Now, this is interesting. The patch email has no mention of jirisl...@kernel.org. However, .mailmap in kernel source root has line: Jiri Slaby indicating that you prefer jirisl...@kernel.org. When I apply the patch, git am looks that up, and sets: Author: Jiri Slaby With that, we end up with an Author/Signed-off-by mismatch. If you prefer Jiri Slaby , I think you should have that in git config too. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH V3] drm/i915/adl-n: Enable ADL-N platform
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, December 16, 2021 5:28 PM
> To: Surendrakumar Upadhyay, TejaskumarX
> ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH V3] drm/i915/adl-n: Enable ADL-N platform
>
> On Fri, 10 Dec 2021, Tejas Upadhyay
> wrote:
> > Adding PCI device ids and enabling ADL-N platform.
> > ADL-N from i915 point of view is subplatform of ADL-P.
> >
> > BSpec: 68397
> >
> > Changes since V2:
> > - Added version log history
> > Changes since V1:
> > - replace IS_ALDERLAKE_N with IS_ADLP_N - Jani Nikula
> >
> > Signed-off-by: Tejas Upadhyay
> >
>
> Acked-by: Jani Nikula
Checked the changes with Bspec,
Reviewed-by: Anusha Srivatsa
>
>
> > ---
> > arch/x86/kernel/early-quirks.c | 1 +
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/i915_pci.c | 1 +
> > drivers/gpu/drm/i915/intel_device_info.c | 7 +++
> > drivers/gpu/drm/i915/intel_device_info.h | 3 +++
> > include/drm/i915_pciids.h| 6 ++
> > 6 files changed, 20 insertions(+)
> >
> > diff --git a/arch/x86/kernel/early-quirks.c
> > b/arch/x86/kernel/early-quirks.c index fd2d3ab38ebb..1ca3a56fdc2d
> > 100644
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> > @@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[]
> __initconst = {
> > INTEL_RKL_IDS(&gen11_early_ops),
> > INTEL_ADLS_IDS(&gen11_early_ops),
> > INTEL_ADLP_IDS(&gen11_early_ops),
> > + INTEL_ADLN_IDS(&gen11_early_ops),
> > INTEL_RPLS_IDS(&gen11_early_ops),
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index a0f54a69b11d..b2ec85a3e40a
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1283,6 +1283,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> > IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G11)
> #define
> > IS_ADLS_RPLS(dev_priv) \
> > IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_S,
> INTEL_SUBPLATFORM_RPL_S)
> > +#define IS_ADLP_N(dev_priv) \
> > + IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_N)
> > #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> > (INTEL_DEVID(dev_priv) & 0xFF00) ==
> 0x0C00) #define
> > IS_BDW_ULT(dev_priv) \ diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index 708a23415e9c..6a19e9da53cc
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -1132,6 +1132,7 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_RKL_IDS(&rkl_info),
> > INTEL_ADLS_IDS(&adl_s_info),
> > INTEL_ADLP_IDS(&adl_p_info),
> > + INTEL_ADLN_IDS(&adl_p_info),
> > INTEL_DG1_IDS(&dg1_info),
> > INTEL_RPLS_IDS(&adl_s_info),
> > {0, 0, 0}
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index a3446a2abcb2..54944d87cd3c 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -170,6 +170,10 @@ static const u16 subplatform_portf_ids[] = {
> > INTEL_ICL_PORT_F_IDS(0),
> > };
> >
> > +static const u16 subplatform_n_ids[] = {
> > + INTEL_ADLN_IDS(0),
> > +};
> > +
> > static const u16 subplatform_rpls_ids[] = {
> > INTEL_RPLS_IDS(0),
> > };
> > @@ -210,6 +214,9 @@ void intel_device_info_subplatform_init(struct
> drm_i915_private *i915)
> > } else if (find_devid(devid, subplatform_portf_ids,
> > ARRAY_SIZE(subplatform_portf_ids))) {
> > mask = BIT(INTEL_SUBPLATFORM_PORTF);
> > + } else if (find_devid(devid, subplatform_n_ids,
> > + ARRAY_SIZE(subplatform_n_ids))) {
> > + mask = BIT(INTEL_SUBPLATFORM_N);
> > } else if (find_devid(devid, subplatform_rpls_ids,
> > ARRAY_SIZE(subplatform_rpls_ids))) {
> > mask = BIT(INTEL_SUBPLATFORM_RPL_S); diff --git
> > a/drivers/gpu/drm/i915/intel_device_info.h
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index 213ae2c07126..e341d90f28a2 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -113,6 +113,9 @@ enum intel_platform {
> > /* ADL-S */
> > #define INTEL_SUBPLATFORM_RPL_S0
> >
> > +/* ADL-P */
> > +#define INTEL_SUBPLATFORM_N0
> > +
> > enum intel_ppgtt_type {
> > INTEL_PPGTT_NONE = I915_GEM_PPGTT_NONE,
> > INTEL_PPGTT_ALIASING = I915_GEM_PPGTT_ALIASING, diff --git
> > a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index
> > baf3d1d3d566..533890dc9da1 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -666,6 +666,12 @@
> > INTEL_VGA_DEVICE(0x46C2, info), \
> > INTEL_VGA_DEVICE(0x46C3, info)
> >
> > +/* ADL-N */
> > +#define IN
Re: [Intel-gfx] [PATCH v3 04/17] drm/i915: Take object lock in i915_ggtt_pin if ww is not set
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > i915_vma_wait_for_bind needs the vma lock held, fix the caller. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH v3 05/17] drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > We will need the lock to unbind the vma, and wait for bind to complete. > Remove the special casing for the !ww path, and force ww locking for all. > > Changes since v1: > - Pass err to for_i915_gem_ww handling for -EDEADLK handling. > > Signed-off-by: Maarten Lankhorst Deja-vu, Reviewed-by: Matthew Auld
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove short term pins from execbuf by requiring lock to unbind.
== Series Details == Series: drm/i915: Remove short term pins from execbuf by requiring lock to unbind. URL : https://patchwork.freedesktop.org/series/98137/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11009_full -> Patchwork_21861_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21861_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21861_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21861_full: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-skl9/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/shard-skl6/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-xy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-xy.html - shard-glk: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/igt@gem_mmap_...@cpuset-big-copy-xy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/shard-glk8/igt@gem_mmap_...@cpuset-big-copy-xy.html - shard-tglb: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-tglb7/igt@gem_mmap_...@cpuset-big-copy-xy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/shard-tglb3/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-tglb: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-tglb5/igt@gem_pp...@blt-vs-render-ctx0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/shard-tglb3/igt@gem_pp...@blt-vs-render-ctx0.html * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [CRASH][11] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21861/shard-skl3/igt@i915_pm...@dc6-psr.html Known issues Here are the changes found in Patchwork_21861_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36]) ([i915#4392]) -> ([PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58], [PASS][59], [PASS][60], [PASS][61]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk2/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk9/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk9/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk1/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk6/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk6/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk4/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dmc: Eliminate remnant GEN references
== Series Details == Series: drm/i915/dmc: Eliminate remnant GEN references URL : https://patchwork.freedesktop.org/series/98166/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21866 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21866 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21866, 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_21866/index.html Participating hosts (43 -> 34) -- Additional (1): fi-skl-guc Missing(10): bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-cfl-8700k bat-adlp-6 fi-bsw-cyan bat-adlp-4 fi-bdw-samus bat-jsl-2 bat-jsl-1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21866: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-kbl-8809g: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html Known issues Here are the changes found in Patchwork_21866 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-skl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-guc/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][6] -> [INCOMPLETE][7] ([i915#3921]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@too-high: - fi-kbl-8809g: [PASS][8] -> [FAIL][9] ([i915#4405]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-kbl-8809g/igt@kms_addfb_ba...@too-high.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-kbl-8809g/igt@kms_addfb_ba...@too-high.html * igt@kms_addfb_basic@unused-modifier: - fi-kbl-8809g: [PASS][10] -> [SKIP][11] ([fdo#109271]) +18 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-kbl-8809g/igt@kms_addfb_ba...@unused-modifier.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-kbl-8809g/igt@kms_addfb_ba...@unused-modifier.html * igt@kms_chamelium@dp-crc-fast: - fi-skl-guc: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-skl-guc: NOTRUN -> [SKIP][14] ([fdo#109271]) +28 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][15] ([fdo#109271]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-connector-state: - fi-kbl-8809g: [PASS][16] -> [DMESG-FAIL][17] ([i915#4406]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/fi-kbl-8809g/igt@kms_force_connector_ba...@force-connector-state.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21866/fi-kbl-8809g/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-8809g: [PASS][18] -> [CRASH][19] ([i915#4406]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1100
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Don't hog IRQs when destroying contexts
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking waiting on H2G space from inside an IRQ
spinlock. There no was deadlock as such, it's just that the H2G queue
was full of context destroy commands and GuC was taking a long time to
process them. However, the kernel was seeing the large amount of time
spent inside the IRQ lock as a dead CPU. Various Bad Things(tm) would
then happen (heartbeat failures, CT deadlock errors, outstanding H2G
WARNs, etc.).
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
v2:
(John Harrison)
- Fix typo in comment message
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 45 ---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 36c2965db49b..96fcf869e3ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2644,7 +2644,6 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
unsigned long flags;
bool disabled;
- lockdep_assert_held(&guc->submission_state.lock);
GEM_BUG_ON(!intel_gt_pm_is_awake(gt));
GEM_BUG_ON(!lrc_desc_registered(guc, ce->guc_id.id));
GEM_BUG_ON(ce != __get_context(guc, ce->guc_id.id));
@@ -2660,7 +2659,7 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
}
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
if (unlikely(disabled)) {
- __release_guc_id(guc, ce);
+ release_guc_id(guc, ce);
__guc_context_destroy(ce);
return;
}
@@ -2694,36 +2693,48 @@ static void __guc_context_destroy(struct intel_context
*ce)
static void guc_flush_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
GEM_BUG_ON(!submission_disabled(guc) &&
guc_submission_initialized(guc));
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
-&guc->submission_state.destroyed_contexts,
-destroyed_link) {
- list_del_init(&ce->destroyed_link);
- __release_guc_id(guc, ce);
+ while (!list_empty(&guc->submission_state.destroyed_contexts)) {
Are lockless false negatives a concern here - I mean this thread not seeing
something just got added to the list?
+ spin_lock_irqsave(&guc->submission_state.lock, flags);
+ ce =
list_first_entry_or_null(&guc->submission_state.destroyed_contexts,
+ struct intel_context,
+ destroyed_link);
+ if (ce)
+ list_del_init(&ce->destroyed_link);
+ spin_unlock_irqrestore(&guc->submission_state.lock, flags);
+
+ if (!ce)
+ break;
+
+ release_guc_id(guc, ce);
This looks suboptimal and in conflict with this part of the commit message:
"""
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
"""
Because you end up doing:
... loop ...
spin_lock_irqsave(&guc->submission_state.lock, flags);
list_del_init(&ce->destroyed_link);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
release_guc_id, which calls:
spin_lock_irqsave(&guc->submission_state.lock, flags);
__release_guc_id(guc, ce);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
So a) the lock seems to be protecting more than just list management, or
release_guc_if is wrong, and b) the loop ends up with highly questionable
hammering on the lock.
Is there any point to this part of the patch? Or the only business end of the
patch is below:
__guc_context_destroy(ce);
}
- spin_unlock_irqrestore(&guc->submission_state.lock, flags);
}
static void deregister_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
-&guc->submission_state.destroyed_contexts,
-
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Don't hog IRQs when destroying contexts
On 17/12/2021 11:06, Tvrtko Ursulin wrote:
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking waiting on H2G space from inside an IRQ
spinlock. There no was deadlock as such, it's just that the H2G queue
was full of context destroy commands and GuC was taking a long time to
process them. However, the kernel was seeing the large amount of time
spent inside the IRQ lock as a dead CPU. Various Bad Things(tm) would
then happen (heartbeat failures, CT deadlock errors, outstanding H2G
WARNs, etc.).
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
v2:
(John Harrison)
- Fix typo in comment message
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 45 ---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 36c2965db49b..96fcf869e3ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2644,7 +2644,6 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
unsigned long flags;
bool disabled;
- lockdep_assert_held(&guc->submission_state.lock);
GEM_BUG_ON(!intel_gt_pm_is_awake(gt));
GEM_BUG_ON(!lrc_desc_registered(guc, ce->guc_id.id));
GEM_BUG_ON(ce != __get_context(guc, ce->guc_id.id));
@@ -2660,7 +2659,7 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
}
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
if (unlikely(disabled)) {
- __release_guc_id(guc, ce);
+ release_guc_id(guc, ce);
__guc_context_destroy(ce);
return;
}
@@ -2694,36 +2693,48 @@ static void __guc_context_destroy(struct
intel_context *ce)
static void guc_flush_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
GEM_BUG_ON(!submission_disabled(guc) &&
guc_submission_initialized(guc));
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
- &guc->submission_state.destroyed_contexts,
- destroyed_link) {
- list_del_init(&ce->destroyed_link);
- __release_guc_id(guc, ce);
+ while (!list_empty(&guc->submission_state.destroyed_contexts)) {
Are lockless false negatives a concern here - I mean this thread not
seeing something just got added to the list?
+ spin_lock_irqsave(&guc->submission_state.lock, flags);
+ ce =
list_first_entry_or_null(&guc->submission_state.destroyed_contexts,
+ struct intel_context,
+ destroyed_link);
+ if (ce)
+ list_del_init(&ce->destroyed_link);
+ spin_unlock_irqrestore(&guc->submission_state.lock, flags);
+
+ if (!ce)
+ break;
+
+ release_guc_id(guc, ce);
This looks suboptimal and in conflict with this part of the commit message:
"""
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
"""
Because you end up doing:
... loop ...
spin_lock_irqsave(&guc->submission_state.lock, flags);
list_del_init(&ce->destroyed_link);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
release_guc_id, which calls:
spin_lock_irqsave(&guc->submission_state.lock, flags);
__release_guc_id(guc, ce);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
So a) the lock seems to be protecting more than just list management, or
release_guc_if is wrong, and b) the loop ends up with highly
questionable hammering on the lock.
Is there any point to this part of the patch? Or the only business end
of the patch is below:
__guc_context_destroy(ce);
}
- spin_unlock_irqrestore(&guc->submission_state.lock, flags);
}
static void deregister_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
- &guc->submission_state.destroyed_contexts,
- destroyed_link) {
- list_del_init(&ce->destroyed_link);
+ while (!list_empty(&guc->submission_state.destroyed_contexts)) {
+ spin_lock_irqsave(&guc->submission_s
Re: [Intel-gfx] [PATCH v3 07/17] drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > Now that we require locking to evict, multiple vmas from the same object > might not be evicted. This is expected and required, because execbuf will > move to short-term pinning by using the lock only. This will cause these > tests to fail, because they create a ton of vma's for the same object. > > Unbind manually to prevent spurious -ENOSPC in those mock tests. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Request RP0 before loading firmware (rev3)
== Series Details == Series: drm/i915/guc: Request RP0 before loading firmware (rev3) URL : https://patchwork.freedesktop.org/series/97682/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11009_full -> Patchwork_21864_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21864_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21864_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21864_full: ### IGT changes ### Possible regressions * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [CRASH][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-skl10/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][2] -> [INCOMPLETE][3] +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-skl8/igt@i915_selftest@m...@requests.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-skl3/igt@i915_selftest@m...@requests.html Known issues Here are the changes found in Patchwork_21864_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][4], [PASS][5], [PASS][6], [FAIL][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28]) ([i915#4392]) -> ([PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk2/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk8/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk1/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk7/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk1/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk3/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk3/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk3/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11009/shard-glk2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-glk9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-glk9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-glk8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864/shard-glk8/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21864
Re: [Intel-gfx] [PATCH v3 08/17] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Now that we cannot unbind kill the currently locked object directly
"unbind kill"
> because we're removing short term pinning, we may have to unbind the
> object from gtt manually, using a i915_gem_evict_vm() call.
>
> Signed-off-by: Maarten Lankhorst
Maybe mention that this only in preparation for some future patches,
once the actual eviction is trylock and evict_for_vm can also handle
shared dma-resv? At this point in the series we shouldn't expect to
hit -ENOSPC, right?
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index af81d6c3332a..00cd9642669a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -358,8 +358,22 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
> 0, flags);
> }
>
> - /* The entire mappable GGTT is pinned? Unexpected! */
> - GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
> + /*
> +* The entire mappable GGTT is pinned? Unexpected!
> +* Try to evict the object we locked too, as normally we skip
> it
> +* due to lack of short term pinning inside execbuf.
> +*/
> + if (vma == ERR_PTR(-ENOSPC)) {
> + ret = mutex_lock_interruptible(&ggtt->vm.mutex);
> + if (!ret) {
> + ret = i915_gem_evict_vm(&ggtt->vm);
> + mutex_unlock(&ggtt->vm.mutex);
> + }
> + if (ret)
> + goto err_reset;
> + vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
> 0, flags);
> + }
> + GEM_WARN_ON(vma == ERR_PTR(-ENOSPC));
Looks like this is being triggered in CI, I assume because the trylock
could easily fail, due to contention? Is this expected for now? Do we
keep the WARN and track it as a known issue?
> }
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: Use vma resources for async unbinding
Hi "Thomas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20211216]
[cannot apply to drm-exynos/exynos-drm-next drm/drm-next
drm-intel/for-linux-next tegra-drm/drm/tegra/for-next airlied/drm-next
v5.16-rc5]
[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/Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unbinding/20211217-172108
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-r021-20211216
(https://download.01.org/0day-ci/archive/20211217/202112172015.hcepn2cg-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
9043c3d65b11b442226015acfbf8167684586cfa)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/45f1249183a30dea38defee195b33c7f6753d9f9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unbinding/20211217-172108
git checkout 45f1249183a30dea38defee195b33c7f6753d9f9
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_vma_resource.c:379:39: warning: format specifies
>> type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
pr_err("vma resource size is %lu\n", sizeof(struct
i915_vma_resource));
~~~ ^~~~
%u
include/linux/printk.h:493:33: note: expanded from macro 'pr_err'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/printk.h:450:60: note: expanded from macro 'printk'
#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/printk.h:422:19: note: expanded from macro 'printk_index_wrap'
_p_func(_fmt, ##__VA_ARGS__); \
^~~
1 warning generated.
vim +379 drivers/gpu/drm/i915/i915_vma_resource.c
376
377 int __init i915_vma_resource_module_init(void)
378 {
> 379 pr_err("vma resource size is %lu\n", sizeof(struct
> i915_vma_resource));
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the GuC firmware in the similar way it is done
by the execlists backend.
This way we have notion of where the hangs are before the GuC gains
support for proper error capture.
Ping - any interest to log this info?
All there currently is a non-descriptive "[drm] GPU HANG: ecode
12:0:".
Also, will GuC be reporting the reason for the engine reset at any point?
Regards,
Tvrtko
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9739da6f..51512123dc1a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_engine_heartbeat.h"
+#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_clock_utils.h"
@@ -3934,9 +3935,18 @@ static void capture_error_state(struct intel_guc *guc,
{
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- struct intel_engine_cs *engine = __context_to_physical_engine(ce);
+ struct intel_engine_cs *engine = ce->engine;
intel_wakeref_t wakeref;
+ if (intel_engine_is_virtual(engine)) {
+ drm_notice(&i915->drm, "%s class, engines 0x%x; GuC engine
reset\n",
+ intel_engine_class_repr(engine->class),
+ engine->mask);
+ engine = guc_virtual_get_sibling(engine, 0);
+ } else {
+ drm_notice(&i915->drm, "%s GuC engine reset\n", engine->name);
+ }
+
intel_engine_set_hung_context(engine, ce);
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
i915_capture_error_state(gt, engine->mask);
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Adding writeback support for i915
== Series Details == Series: Adding writeback support for i915 URL : https://patchwork.freedesktop.org/series/98168/ State : failure == Summary == Applying: drm: add writeback pointers to drm_connector Using index info to reconstruct a base tree... M include/drm/drm_connector.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_connector.h Applying: drm/komeda: change driver to use drm_writeback_connector.base pointer Applying: drm/i915: Define WD trancoder for i915 Applying: drm/i915: Enabling WD Transcoder error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_display.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0004 drm/i915: Enabling WD Transcoder 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] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Asynchronous vma unbinding (rev2)
== Series Details == Series: drm/i915: Asynchronous vma unbinding (rev2) URL : https://patchwork.freedesktop.org/series/98055/ State : warning == Summary == $ dim checkpatch origin/drm-tip 04617ab4c517 drm/i915: Avoid using the i915_fence_array when collecting dependencies c9d9298d1a0b drm/i915: Break out the i915_deps utility -:252: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #252: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 522 lines checked 9b0cf54fb6e3 drm/i915: Require the vm mutex for i915_vma_bind() 15ecf8b1fb33 drm/i915: Initial introduction of vma resources -:245: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #245: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 626 lines checked ade3187fa6ce drm/i915: Use the vma resource as argument for gtt binding / unbinding 2bdd5f2b6f3c drm/i915: Use vma resources for async unbinding -:541: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_node' - possible side-effects? #541: FILE: drivers/gpu/drm/i915/i915_vma_resource.c:36: +#define VMA_RES_LAST(_node) ((_node)->start + (_node)->node_size - 1) total: 0 errors, 0 warnings, 1 checks, 870 lines checked 17439602d54e drm/i915: Use struct vma_resource instead of struct vma_snapshot -:602: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #602: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 497 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Asynchronous vma unbinding (rev2)
== Series Details == Series: drm/i915: Asynchronous vma unbinding (rev2) URL : https://patchwork.freedesktop.org/series/98055/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Asynchronous vma unbinding (rev2)
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev2)
URL : https://patchwork.freedesktop.org/series/98055/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/i915_vma_resource.o
In file included from ./include/linux/kernel.h:20,
from ./include/linux/rbtree.h:22,
from ./include/linux/rbtree_augmented.h:16,
from ./include/linux/interval_tree_generic.h:10,
from drivers/gpu/drm/i915/i915_vma_resource.c:6:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_module_init’:
./include/linux/kern_levels.h:5:18: error: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 2 has type ‘unsigned int’
[-Werror=format=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^~
./include/linux/printk.h:422:11: note: in definition of macro
‘printk_index_wrap’
_p_func(_fmt, ##__VA_ARGS__);\
^~~~
./include/linux/printk.h:493:2: note: in expansion of macro ‘printk’
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~
./include/linux/kern_levels.h:11:18: note: in expansion of macro ‘KERN_SOH’
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
./include/linux/printk.h:493:9: note: in expansion of macro ‘KERN_ERR’
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
drivers/gpu/drm/i915/i915_vma_resource.c:382:2: note: in expansion of macro
‘pr_err’
pr_err("vma resource size is %lu\n", sizeof(struct i915_vma_resource));
^~
drivers/gpu/drm/i915/i915_vma_resource.c:382:33: note: format string is defined
here
pr_err("vma resource size is %lu\n", sizeof(struct i915_vma_resource));
~~^
%u
cc1: all warnings being treated as errors
scripts/Makefile.build:287: recipe for target
'drivers/gpu/drm/i915/i915_vma_resource.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_vma_resource.o] Error 1
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1846: recipe for target 'drivers' failed
make: *** [drivers] Error 2
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/build_32bit.log
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Asynchronous vma unbinding (rev2)
== Series Details == Series: drm/i915: Asynchronous vma unbinding (rev2) URL : https://patchwork.freedesktop.org/series/98055/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11012 -> Patchwork_21868 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21868 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21868, 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_21868/index.html Participating hosts (42 -> 34) -- Missing(8): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-bsw-cyan bat-adlp-6 fi-pnv-d510 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21868: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3: - fi-kbl-8809g: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-kbl-8809g/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-kbl-8809g/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-cml-u2: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-cml-u2/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-cml-u2/igt@i915_module_l...@reload.html - fi-blb-e6850: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-blb-e6850/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-blb-e6850/igt@i915_module_l...@reload.html - fi-cfl-8700k: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-cfl-8700k/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-cfl-8700k/igt@i915_module_l...@reload.html - fi-snb-2520m: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-snb-2520m/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-snb-2520m/igt@i915_module_l...@reload.html - fi-bxt-dsi: [PASS][11] -> [DMESG-WARN][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-bxt-dsi/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-bxt-dsi/igt@i915_module_l...@reload.html - fi-hsw-4770:[PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-hsw-4770/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-hsw-4770/igt@i915_module_l...@reload.html - fi-tgl-1115g4: [PASS][15] -> [DMESG-WARN][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-tgl-1115g4/igt@i915_module_l...@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-tgl-1115g4/igt@i915_module_l...@reload.html - fi-cfl-guc: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-cfl-guc/igt@i915_module_l...@reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-cfl-guc/igt@i915_module_l...@reload.html - fi-bsw-n3050: [PASS][19] -> [DMESG-WARN][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-bsw-n3050/igt@i915_module_l...@reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-bsw-n3050/igt@i915_module_l...@reload.html - fi-ilk-650: [PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-ilk-650/igt@i915_module_l...@reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-ilk-650/igt@i915_module_l...@reload.html - fi-ivb-3770:[PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-ivb-3770/igt@i915_module_l...@reload.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-ivb-3770/igt@i915_module_l...@reload.html - fi-rkl-guc: [PASS][25] -> [DMESG-WARN][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-rkl-guc/igt@i915_module_l...@reload.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-rkl-guc/igt@i915_module_l...@reload.html - fi-elk-e7500: [PASS][27] -> [DMESG-WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-elk-e7500/igt@i915_module_l...@reload.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21868/fi-elk-e7500/igt@i915_mo
Re: [Intel-gfx] [PATCH v3 09/17] drm/i915: Trylock the object when shrinking
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > We're working on requiring the obj->resv lock during unbind, fix > the shrinker to take the objectl ock. lock > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH v3 11/17] drm/i915: Add ww ctx to i915_gem_object_trylock
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > This is required for i915_gem_evict_vm, to be able to evict the entire VM, > including objects that are already locked to the current ww ctx. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH v3 12/17] drm/i915: Add locking to i915_gem_evict_vm()
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> i915_gem_evict_vm will need to be able to evict objects that are
> locked by the current ctx. By testing if the current context already
> locked the object, we can do this correctly. This allows us to
> evict the entire vm even if we already hold some objects' locks.
>
> Previously, this was spread over several commits, but it makes
> more sense to commit the changes to i915_gem_evict_vm separately
> from the changes to i915_gem_evict_something() and
> i915_gem_evict_for_node().
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +-
> drivers/gpu/drm/i915/i915_gem_evict.c | 30 +--
> drivers/gpu/drm/i915/i915_vma.c | 7 -
> .../gpu/drm/i915/selftests/i915_gem_evict.c | 10 +--
> 6 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 2213f7b613da..eb3649e844ff 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -766,7 +766,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
> case 1:
> /* Too fragmented, unbind everything and retry */
> mutex_lock(&eb->context->vm->mutex);
> - err = i915_gem_evict_vm(eb->context->vm);
> + err = i915_gem_evict_vm(eb->context->vm, &eb->ww);
> mutex_unlock(&eb->context->vm->mutex);
> if (err)
> return err;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 00cd9642669a..2856098cb449 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -366,7 +366,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> if (vma == ERR_PTR(-ENOSPC)) {
> ret = mutex_lock_interruptible(&ggtt->vm.mutex);
> if (!ret) {
> - ret = i915_gem_evict_vm(&ggtt->vm);
> + ret = i915_gem_evict_vm(&ggtt->vm, &ww);
> mutex_unlock(&ggtt->vm.mutex);
> }
> if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d51628d10f9d..c180019c607f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1725,7 +1725,8 @@ int __must_check i915_gem_evict_something(struct
> i915_address_space *vm,
> int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
> struct drm_mm_node *node,
> unsigned int flags);
> -int i915_gem_evict_vm(struct i915_address_space *vm);
> +int i915_gem_evict_vm(struct i915_address_space *vm,
> + struct i915_gem_ww_ctx *ww);
>
> /* i915_gem_internal.c */
> struct drm_i915_gem_object *
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 2b73ddb11c66..bfd66f539fc1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -367,7 +367,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
> * To clarify: This is for freeing up virtual address space, not for freeing
> * memory in e.g. the shrinker.
> */
> -int i915_gem_evict_vm(struct i915_address_space *vm)
> +int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx
> *ww)
> {
> int ret = 0;
>
> @@ -388,24 +388,50 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
> do {
> struct i915_vma *vma, *vn;
> LIST_HEAD(eviction_list);
> + LIST_HEAD(locked_eviction_list);
>
> list_for_each_entry(vma, &vm->bound_list, vm_link) {
> if (i915_vma_is_pinned(vma))
> continue;
>
> + /*
> +* If we already own the lock, trylock fails. In case
> the resv
> +* is shared among multiple objects, we still need
> the object ref.
What is "object ref" here? I assume it's just leftovers...
Otherwise,
Reviewed-by: Matthew Auld
> +*/
> + if (ww && (dma_resv_locking_ctx(vma->obj->base.resv)
> == &ww->ctx)) {
> + __i915_vma_pin(vma);
> + list_add(&vma->evict_link,
> &locked_eviction_list);
> + continue;
> + }
> +
> + i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: let HW maintain the HS-TRAIL timing (rev3)
== Series Details ==
Series: drm/i915/dsi: let HW maintain the HS-TRAIL timing (rev3)
URL : https://patchwork.freedesktop.org/series/96750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11012 -> Patchwork_21869
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/index.html
Participating hosts (42 -> 37)
--
Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_21869 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][1] -> [FAIL][2] ([i915#4547])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-tgl-dsi/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/fi-tgl-dsi/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
Build changes
-
* Linux: CI_DRM_11012 -> Patchwork_21869
CI-20190529: 20190529
CI_DRM_11012: 64bab3fe255d1886ef16ef57451df545380fa6be @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6313: 1793ed798cc09966c27bf478781e0c1d6bb23bad @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21869: 7da7b72244aaed598f4964998436169b52735d45 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7da7b72244aa drm/i915/dsi: let HW maintain the HS-TRAIL timing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/index.html
Re: [Intel-gfx] [PATCH V3] drm/i915/adl-n: Enable ADL-N platform
On Fri, 10 Dec 2021, Tejas Upadhyay
wrote:
> Adding PCI device ids and enabling ADL-N platform.
> ADL-N from i915 point of view is subplatform of ADL-P.
>
> BSpec: 68397
>
> Changes since V2:
> - Added version log history
> Changes since V1:
> - replace IS_ALDERLAKE_N with IS_ADLP_N - Jani Nikula
>
> Signed-off-by: Tejas Upadhyay
Cc: x86 maintainers & lists
Ack for merging the arch/x86/kernel/early-quirks.c PCI ID update via
drm-intel?
I note not all such changes in git log have your acks recorded, though
most do. Do you want us to be more careful about Cc'ing you for acks on
PCI ID changes every time going forward?
BR,
Jani.
> ---
> arch/x86/kernel/early-quirks.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> drivers/gpu/drm/i915/intel_device_info.c | 7 +++
> drivers/gpu/drm/i915/intel_device_info.h | 3 +++
> include/drm/i915_pciids.h| 6 ++
> 6 files changed, 20 insertions(+)
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index fd2d3ab38ebb..1ca3a56fdc2d 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[]
> __initconst = {
> INTEL_RKL_IDS(&gen11_early_ops),
> INTEL_ADLS_IDS(&gen11_early_ops),
> INTEL_ADLP_IDS(&gen11_early_ops),
> + INTEL_ADLN_IDS(&gen11_early_ops),
> INTEL_RPLS_IDS(&gen11_early_ops),
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a0f54a69b11d..b2ec85a3e40a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1283,6 +1283,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G11)
> #define IS_ADLS_RPLS(dev_priv) \
> IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_S, INTEL_SUBPLATFORM_RPL_S)
> +#define IS_ADLP_N(dev_priv) \
> + IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_N)
> #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
> #define IS_BDW_ULT(dev_priv) \
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 708a23415e9c..6a19e9da53cc 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1132,6 +1132,7 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_RKL_IDS(&rkl_info),
> INTEL_ADLS_IDS(&adl_s_info),
> INTEL_ADLP_IDS(&adl_p_info),
> + INTEL_ADLN_IDS(&adl_p_info),
> INTEL_DG1_IDS(&dg1_info),
> INTEL_RPLS_IDS(&adl_s_info),
> {0, 0, 0}
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index a3446a2abcb2..54944d87cd3c 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -170,6 +170,10 @@ static const u16 subplatform_portf_ids[] = {
> INTEL_ICL_PORT_F_IDS(0),
> };
>
> +static const u16 subplatform_n_ids[] = {
> + INTEL_ADLN_IDS(0),
> +};
> +
> static const u16 subplatform_rpls_ids[] = {
> INTEL_RPLS_IDS(0),
> };
> @@ -210,6 +214,9 @@ void intel_device_info_subplatform_init(struct
> drm_i915_private *i915)
> } else if (find_devid(devid, subplatform_portf_ids,
> ARRAY_SIZE(subplatform_portf_ids))) {
> mask = BIT(INTEL_SUBPLATFORM_PORTF);
> + } else if (find_devid(devid, subplatform_n_ids,
> + ARRAY_SIZE(subplatform_n_ids))) {
> + mask = BIT(INTEL_SUBPLATFORM_N);
> } else if (find_devid(devid, subplatform_rpls_ids,
> ARRAY_SIZE(subplatform_rpls_ids))) {
> mask = BIT(INTEL_SUBPLATFORM_RPL_S);
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 213ae2c07126..e341d90f28a2 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -113,6 +113,9 @@ enum intel_platform {
> /* ADL-S */
> #define INTEL_SUBPLATFORM_RPL_S 0
>
> +/* ADL-P */
> +#define INTEL_SUBPLATFORM_N0
> +
> enum intel_ppgtt_type {
> INTEL_PPGTT_NONE = I915_GEM_PPGTT_NONE,
> INTEL_PPGTT_ALIASING = I915_GEM_PPGTT_ALIASING,
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index baf3d1d3d566..533890dc9da1 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -666,6 +666,12 @@
> INTEL_VGA_DEVICE(0x46C2, info), \
> INTEL_VGA_DEVICE(0x46C3, info)
>
> +/* ADL-N */
> +#define INTEL_ADLN_IDS(info) \
> + INTEL_VGA_DEVICE(0x46D0, info), \
> + INTEL_VGA_DEVICE(0x46D1, info), \
> + INTEL_VGA_DEVICE(0x46D2, info)
> +
> /* RPL-S */
> #define INTEL_RPLS_IDS(info) \
> INTEL_VGA_DEVICE(0xA780,
Re: [Intel-gfx] [PATCH v3 13/17] drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > Because we will start to require the obj->resv lock for unbinding, > ensure these shrinker functions also take the lock. > > This requires some function signature changes, to ensure that the > ww context is passed around, but is mostly straightforward. Do we even need this? We aren't handling the shared dma-resv for these ones, right? Or more just to have a consistent-ish interface? > > Previously this was split up into several patches, but reworking > should allow for easier bisection. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- > drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_gem_evict.c | 34 +++ > drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-- > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++ > drivers/gpu/drm/i915/i915_vgpu.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 9 ++--- > .../gpu/drm/i915/selftests/i915_gem_evict.c | 17 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 14 > 11 files changed, 63 insertions(+), 32 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c > b/drivers/gpu/drm/i915/gt/intel_ggtt.c > index a287c9186ec9..ed43e9c80aaa 100644 > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c > @@ -504,7 +504,7 @@ static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt) > GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP); > size = ggtt->vm.total - GUC_GGTT_TOP; > > - ret = i915_gem_gtt_reserve(&ggtt->vm, &ggtt->uc_fw, size, > + ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw, size, >GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE, >PIN_NOEVICT); > if (ret) > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > index e5ad4d5a91c0..a3597a6bb805 100644 > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > @@ -1382,7 +1382,7 @@ static int evict_vma(void *data) > complete(&arg->completion); > > mutex_lock(&vm->mutex); > - err = i915_gem_evict_for_node(vm, &evict, 0); > + err = i915_gem_evict_for_node(vm, NULL, &evict, 0); > mutex_unlock(&vm->mutex); > > return err; > diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c > b/drivers/gpu/drm/i915/gvt/aperture_gm.c > index 0d6d59871308..c08098a167e9 100644 > --- a/drivers/gpu/drm/i915/gvt/aperture_gm.c > +++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c > @@ -63,7 +63,7 @@ static int alloc_gm(struct intel_vgpu *vgpu, bool high_gm) > > mutex_lock(>->ggtt->vm.mutex); > mmio_hw_access_pre(gt); > - ret = i915_gem_gtt_insert(>->ggtt->vm, node, > + ret = i915_gem_gtt_insert(>->ggtt->vm, NULL, node, > size, I915_GTT_PAGE_SIZE, > I915_COLOR_UNEVICTABLE, > start, end, flags); > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index c180019c607f..2a98192a89c1 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1718,11 +1718,13 @@ i915_gem_vm_lookup(struct drm_i915_file_private > *file_priv, u32 id) > > /* i915_gem_evict.c */ > int __must_check i915_gem_evict_something(struct i915_address_space *vm, > + struct i915_gem_ww_ctx *ww, > u64 min_size, u64 alignment, > unsigned long color, > u64 start, u64 end, > unsigned flags); > int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, > +struct i915_gem_ww_ctx *ww, > struct drm_mm_node *node, > unsigned int flags); > int i915_gem_evict_vm(struct i915_address_space *vm, > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c > b/drivers/gpu/drm/i915/i915_gem_evict.c > index bfd66f539fc1..f502a617b35c 100644 > --- a/drivers/gpu/drm/i915/i915_gem_evict.c > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c > @@ -51,6 +51,7 @@ static int ggtt_flush(struct intel_gt *gt) > > static bool > mark_free(struct drm_mm_scan *scan, > + struct i915_gem_ww_ctx *ww, > struct i915_vma *vma, > unsigned int flags, > struct list_head *unwind) > @@ -58,6 +59,9 @@ mark_free(struct drm_mm_scan *scan, > if (i915_vma_is_pinned(vma)) > return false; > > + if (!i915_gem_object_trylock
[Intel-gfx] [PATCH v3 0/7] drm/i915: Asynchronous vma unbinding
This patch series introduces infrastructure for asynchronous vma unbinding. The single enabled use-case is initially at buffer object migration where we otherwise sync when unbinding vmas before migration. This in theory allows us to pipeline any number of migrations, but in practice the number is restricted by a sync wait when filling the migration context ring. We might want to look at that moving forward if needed. The other main use-case is to be able to pipeline vma evictions, for example with softpinning where a new vma wants to reuse the vm range of an already active vma. We can't support this just yet because we need dma_resv locking around vma eviction for that, which is under implementation. Patch 1 and 2 are mainly a fix and a subsequent rearrangement of code, Patch 3 is needed for consistent bind locking, Patch 4 introduces vma resource first for error capture purposes. Patch 5 changes the vm backend interface to take vma resources rather than vmas, Patch 6 introduces the async unbinding itself, and finally Patch 7 realizes we have duplicated functionality and removes the vma snapshots. v2: -- Some kernel test robot reports addressed. -- kmem cache for vma resources, See patch 6 -- Various fixes all over the place. See separate commit messages. v3: -- Re-add a missing i915_vma_resource_put() -- Remove a stray debug printout Thomas Hellström (7): drm/i915: Avoid using the i915_fence_array when collecting dependencies drm/i915: Break out the i915_deps utility drm/i915: Require the vm mutex for i915_vma_bind() drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Use vma resources for async unbinding drm/i915: Use struct vma_resource instead of struct vma_snapshot drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_dpt.c | 27 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 67 ++- .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 304 ++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 72 ++-- drivers/gpu/drm/i915/gt/intel_gtt.c | 4 + drivers/gpu/drm/i915/gt/intel_gtt.h | 18 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 24 +- drivers/gpu/drm/i915/gt/intel_migrate.h | 9 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_deps.c | 244 +++ drivers/gpu/drm/i915/i915_deps.h | 46 +++ drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++-- drivers/gpu/drm/i915/i915_module.c| 3 + drivers/gpu/drm/i915/i915_request.c | 34 +- drivers/gpu/drm/i915/i915_request.h | 8 +- drivers/gpu/drm/i915/i915_vma.c | 214 +- drivers/gpu/drm/i915/i915_vma.h | 33 +- drivers/gpu/drm/i915/i915_vma_resource.c | 387 ++ drivers/gpu/drm/i915/i915_vma_resource.h | 232 +++ drivers/gpu/drm/i915/i915_vma_snapshot.c | 134 -- drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 - drivers/gpu/drm/i915/i915_vma_types.h | 5 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 159 --- drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +- 35 files changed, 1571 insertions(+), 840 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_deps.c create mode 100644 drivers/gpu/drm/i915/i915_deps.h create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h -- 2.31.1
[Intel-gfx] [PATCH v3 1/7] drm/i915: Avoid using the i915_fence_array when collecting dependencies
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us moving forward.
Have the gt migration code instead take a const struct i915_deps for
dependencies. This means we can skip the dma_fence_array creation
and instead pass the struct i915_deps instead to circumvent the
problem.
v2:
- Make the prev_deps() function static. (kernel test robot )
- Update the struct i915_deps kerneldoc.
Fixes: 5652df829b3c ("drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be
asynchronous")
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 129 +--
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 17 +++
drivers/gpu/drm/i915/gt/intel_migrate.c | 24 ++--
drivers/gpu/drm/i915/gt/intel_migrate.h | 9 +-
drivers/gpu/drm/i915/i915_request.c | 22
drivers/gpu/drm/i915/i915_request.h | 2 +
6 files changed, 91 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 80df9f592407..960145c8200f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,8 +3,6 @@
* Copyright © 2021 Intel Corporation
*/
-#include
-
#include
#include "i915_drv.h"
@@ -44,17 +42,12 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
#endif
/**
- * DOC: Set of utilities to dynamically collect dependencies and
- * eventually coalesce them into a single fence which is fed into
- * the GT migration code, since it only accepts a single dependency
- * fence.
- * The single fence returned from these utilities, in the case of
- * dependencies from multiple fence contexts, a struct dma_fence_array,
- * since the i915 request code can break that up and await the individual
- * fences.
+ * DOC: Set of utilities to dynamically collect dependencies into a
+ * structure which is fed into the GT migration code.
*
* Once we can do async unbinding, this is also needed to coalesce
- * the migration fence with the unbind fences.
+ * the migration fence with the unbind fences if these are coalesced
+ * post-migration.
*
* While collecting the individual dependencies, we store the refcounted
* struct dma_fence pointers in a realloc-managed pointer array, since
@@ -65,32 +58,13 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
* A struct i915_deps need to be initialized using i915_deps_init().
* If i915_deps_add_dependency() or i915_deps_add_resv() return an
* error code they will internally call i915_deps_fini(), which frees
- * all internal references and allocations. After a call to
- * i915_deps_to_fence(), or i915_deps_sync(), the struct should similarly
- * be viewed as uninitialized.
+ * all internal references and allocations.
*
* We might want to break this out into a separate file as a utility.
*/
#define I915_DEPS_MIN_ALLOC_CHUNK 8U
-/**
- * struct i915_deps - Collect dependencies into a single dma-fence
- * @single: Storage for pointer if the collection is a single fence.
- * @fence: Allocated array of fence pointers if more than a single fence;
- * otherwise points to the address of @single.
- * @num_deps: Current number of dependency fences.
- * @fences_size: Size of the @fences array in number of pointers.
- * @gfp: Allocation mode.
- */
-struct i915_deps {
- struct dma_fence *single;
- struct dma_fence **fences;
- unsigned int num_deps;
- unsigned int fences_size;
- gfp_t gfp;
-};
-
static void i915_deps_reset_fences(struct i915_deps *deps)
{
if (deps->fences != &deps->single)
@@ -163,7 +137,7 @@ static int i915_deps_grow(struct i915_deps *deps, struct
dma_fence *fence,
return ret;
}
-static int i915_deps_sync(struct i915_deps *deps,
+static int i915_deps_sync(const struct i915_deps *deps,
const struct ttm_operation_ctx *ctx)
{
struct dma_fence **fences = deps->fences;
@@ -183,7 +157,6 @@ static int i915_deps_sync(struct i915_deps *deps,
break;
}
- i915_deps_fini(deps);
return ret;
}
@@ -221,34 +194,6 @@ static int i915_deps_add_dependency(struct i915_deps *deps,
return i915_deps_grow(deps, fence, ctx);
}
-static struct dma_fence *i915_deps_to_fence(struct i915_deps *deps,
- const struct ttm_operation_ctx *ctx)
-{
- struct dma_fence_array *array;
-
- if (deps->num_deps == 0)
- return NULL;
-
- if (deps->num_deps == 1) {
- deps->num_deps = 0;
- return deps->fences[0];
- }
-
- /*
-* TODO: Alter the allocation mode here to not try too hard to
-* make things asy
[Intel-gfx] [PATCH v3 2/7] drm/i915: Break out the i915_deps utility
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 17 --
drivers/gpu/drm/i915/i915_deps.c | 244 +++
drivers/gpu/drm/i915/i915_deps.h | 46
drivers/gpu/drm/i915/i915_request.c | 2 +-
6 files changed, 293 insertions(+), 193 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_deps.c
create mode 100644 drivers/gpu/drm/i915/i915_deps.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6ddd2d2bbaaf..1b62b9f65196 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -163,6 +163,7 @@ i915-y += \
i915_active.o \
i915_buddy.o \
i915_cmd_parser.o \
+ i915_deps.o \
i915_gem_evict.o \
i915_gem_gtt.o \
i915_gem_ww.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 960145c8200f..e8a99e8cd129 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -5,6 +5,7 @@
#include
+#include "i915_deps.h"
#include "i915_drv.h"
#include "intel_memory_region.h"
#include "intel_region_ttm.h"
@@ -41,181 +42,6 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
}
#endif
-/**
- * DOC: Set of utilities to dynamically collect dependencies into a
- * structure which is fed into the GT migration code.
- *
- * Once we can do async unbinding, this is also needed to coalesce
- * the migration fence with the unbind fences if these are coalesced
- * post-migration.
- *
- * While collecting the individual dependencies, we store the refcounted
- * struct dma_fence pointers in a realloc-managed pointer array, since
- * that can be easily fed into a dma_fence_array. Other options are
- * available, like for example an xarray for similarity with drm/sched.
- * Can be changed easily if needed.
- *
- * A struct i915_deps need to be initialized using i915_deps_init().
- * If i915_deps_add_dependency() or i915_deps_add_resv() return an
- * error code they will internally call i915_deps_fini(), which frees
- * all internal references and allocations.
- *
- * We might want to break this out into a separate file as a utility.
- */
-
-#define I915_DEPS_MIN_ALLOC_CHUNK 8U
-
-static void i915_deps_reset_fences(struct i915_deps *deps)
-{
- if (deps->fences != &deps->single)
- kfree(deps->fences);
- deps->num_deps = 0;
- deps->fences_size = 1;
- deps->fences = &deps->single;
-}
-
-static void i915_deps_init(struct i915_deps *deps, gfp_t gfp)
-{
- deps->fences = NULL;
- deps->gfp = gfp;
- i915_deps_reset_fences(deps);
-}
-
-static void i915_deps_fini(struct i915_deps *deps)
-{
- unsigned int i;
-
- for (i = 0; i < deps->num_deps; ++i)
- dma_fence_put(deps->fences[i]);
-
- if (deps->fences != &deps->single)
- kfree(deps->fences);
-}
-
-static int i915_deps_grow(struct i915_deps *deps, struct dma_fence *fence,
- const struct ttm_operation_ctx *ctx)
-{
- int ret;
-
- if (deps->num_deps >= deps->fences_size) {
- unsigned int new_size = 2 * deps->fences_size;
- struct dma_fence **new_fences;
-
- new_size = max(new_size, I915_DEPS_MIN_ALLOC_CHUNK);
- new_fences = kmalloc_array(new_size, sizeof(*new_fences),
deps->gfp);
- if (!new_fences)
- goto sync;
-
- memcpy(new_fences, deps->fences,
- deps->fences_size * sizeof(*new_fences));
- swap(new_fences, deps->fences);
- if (new_fences != &deps->single)
- kfree(new_fences);
- deps->fences_size = new_size;
- }
- deps->fences[deps->num_deps++] = dma_fence_get(fence);
- return 0;
-
-sync:
- if (ctx->no_wait_gpu && !dma_fence_is_signaled(fence)) {
- ret = -EBUSY;
- goto unref;
- }
-
- ret = dma_fence_wait(fence, ctx->interruptible);
- if (ret)
- goto unref;
-
- ret = fence->error;
- if (ret)
- goto unref;
-
- return 0;
-
-unref:
- i915_deps_fini(deps);
- return ret;
-}
-
-static int i915_deps_sync(const struct i915_deps *deps,
- const struct ttm_operation_ctx *ctx)
-{
- struct dma_fence **fences = deps->fences;
- unsigned int i;
- int ret = 0;
-
- for (i = 0; i < deps->num_deps; ++i, ++fences) {
- if (ctx->no_wait_gpu && !dma_fence_is_signaled(*fences)) {
- ret = -EBUSY;
-
[Intel-gfx] [PATCH v3 3/7] drm/i915: Require the vm mutex for i915_vma_bind()
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but since we block cpu
unplugging during sleeps inside kmap_local() sections this may have
unwanted side-effects. Particularly since we might wait for gpu while
holding the vm mutex.
This change may theoretically increase execbuf cpu-usage on snb, but
at least on non-highmem systems that increase should be very small.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 50 ++-
drivers/gpu/drm/i915/i915_vma.c | 1 +
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2213f7b613da..6013f7e18f60 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1109,6 +1109,47 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
reloc_cache *cache)
return &i915->ggtt;
}
+static void reloc_cache_unmap(struct reloc_cache *cache)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ vaddr = unmask_page(cache->vaddr);
+ if (cache->vaddr & KMAP)
+ kunmap_atomic(vaddr);
+ else
+ io_mapping_unmap_atomic((void __iomem *)vaddr);
+}
+
+static void reloc_cache_remap(struct reloc_cache *cache,
+ struct drm_i915_gem_object *obj)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ if (cache->vaddr & KMAP) {
+ struct page *page = i915_gem_object_get_page(obj, cache->page);
+
+ vaddr = kmap_atomic(page);
+ cache->vaddr = unmask_flags(cache->vaddr) |
+ (unsigned long)vaddr;
+ } else {
+ struct i915_ggtt *ggtt = cache_to_ggtt(cache);
+ unsigned long offset;
+
+ offset = cache->node.start;
+ if (!drm_mm_node_allocated(&cache->node))
+ offset += cache->page << PAGE_SHIFT;
+
+ cache->vaddr = (unsigned long)
+ io_mapping_map_atomic_wc(&ggtt->iomap, offset);
+ }
+}
+
static void reloc_cache_reset(struct reloc_cache *cache, struct
i915_execbuffer *eb)
{
void *vaddr;
@@ -1373,10 +1414,17 @@ eb_relocate_entry(struct i915_execbuffer *eb,
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
- GRAPHICS_VER(eb->i915) == 6) {
+ GRAPHICS_VER(eb->i915) == 6 &&
+ !i915_vma_is_bound(target->vma, I915_VMA_GLOBAL_BIND)) {
+ struct i915_vma *vma = target->vma;
+
+ reloc_cache_unmap(&eb->reloc_cache);
+ mutex_lock(&vma->vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
+ mutex_unlock(&vma->vm->mutex);
+ reloc_cache_remap(&eb->reloc_cache, ev->vma->obj);
if (err)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 927f0d4f8e11..d792a3d0da7a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -398,6 +398,7 @@ int i915_vma_bind(struct i915_vma *vma,
u32 bind_flags;
u32 vma_flags;
+ lockdep_assert_held(&vma->vm->mutex);
GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
GEM_BUG_ON(vma->size > vma->node.size);
--
2.31.1
[Intel-gfx] [PATCH v3 4/7] drm/i915: Initial introduction of vma resources
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 55 +++-
drivers/gpu/drm/i915/i915_vma.h | 19 ++-
drivers/gpu/drm/i915/i915_vma_resource.c | 124 ++
drivers/gpu/drm/i915/i915_vma_resource.h | 70 ++
drivers/gpu/drm/i915/i915_vma_snapshot.c | 15 +--
drivers/gpu/drm/i915/i915_vma_snapshot.h | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 5 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 99 --
10 files changed, 334 insertions(+), 63 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b62b9f65196..98433ad74194 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -174,6 +174,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
+ i915_vma_resource.o \
i915_vma_snapshot.o \
intel_wopcm.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6013f7e18f60..b6faae1f9081 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1422,7 +1422,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
mutex_lock(&vma->vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
- PIN_GLOBAL, NULL);
+ PIN_GLOBAL, NULL, NULL);
mutex_unlock(&vma->vm->mutex);
reloc_cache_remap(&eb->reloc_cache, ev->vma->obj);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d792a3d0da7a..4308659bf552 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -37,6 +37,7 @@
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
#include "i915_vma.h"
+#include "i915_vma_resource.h"
static struct kmem_cache *slab_vmas;
@@ -385,6 +386,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
* @cache_level: mapping cache level
* @flags: flags like global or local mapping
* @work: preallocated worker for allocating and binding the PTE
+ * @vma_res: pointer to a preallocated vma resource. The resource is either
+ * consumed or freed.
*
* DMA addresses are taken from the scatter-gather table of this object (or of
* this VMA in case of non-default GGTT views) and PTE entries set up.
@@ -393,7 +396,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
int i915_vma_bind(struct i915_vma *vma,
enum i915_cache_level cache_level,
u32 flags,
- struct i915_vma_work *work)
+ struct i915_vma_work *work,
+ struct i915_vma_resource *vma_res)
{
u32 bind_flags;
u32 vma_flags;
@@ -404,11 +408,15 @@ int i915_vma_bind(struct i915_vma *vma,
if (GEM_DEBUG_WARN_ON(range_overflows(vma->node.start,
vma->node.size,
- vma->vm->total)))
+ vma->vm->total))) {
+ kfree(vma_res);
return -ENODEV;
+ }
- if (GEM_DEBUG_WARN_ON(!flags))
+ if (GEM_DEBUG_WARN_ON(!flags)) {
+ kfree(vma_res);
return -EINVAL;
+ }
bind_flags = flags;
bind_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
@@ -417,11 +425,21 @@ int i915_vma_bind(struct i915_vma *vma,
vma_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
bind_flags &= ~vma_flags;
- if (bind_flags == 0)
+ if (bind_flags == 0) {
+ kfree(vma_res);
return 0;
+ }
GEM_BUG_ON(!vma->pages);
+ if (vma->resource || !vma_res) {
+ /* Rebinding with an additional I915_VMA_*_BIND */
+ GEM_WARN_ON(!vma_flags);
+ kfree(vma_res);
+ } else {
+ i915_vma_resource_init(vma_res);
+ vma->resource = vma_res;
+ }
trace_i915_vma_bind(vma, bind_flags);
if (work && bind_flags & vma->vm->bind_async_flags) {
struct dma_fence *prev;
@@ -897,6 +915,7 @
[Intel-gfx] [PATCH v3 7/7] drm/i915: Use struct vma_resource instead of struct vma_snapshot
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a small price to pay for the simplification.
v2:
- Fix a missing include and declaration (kernel test robot )
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++--
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 14 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 3 +
drivers/gpu/drm/i915/i915_vma_resource.h | 28 +++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 125 --
drivers/gpu/drm/i915/i915_vma_snapshot.h | 101 --
11 files changed, 88 insertions(+), 313 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 98433ad74194..aa86ac33effc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -175,7 +175,6 @@ i915-y += \
i915_ttm_buddy_manager.o \
i915_vma.o \
i915_vma_resource.o \
- i915_vma_snapshot.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b6faae1f9081..51649bbb8cc3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -29,7 +29,6 @@
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-#include "i915_vma_snapshot.h"
struct eb_vma {
struct i915_vma *vma;
@@ -1952,7 +1951,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
{
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
- struct i915_vma_snapshot *vsnap;
while (i--) {
struct eb_vma *ev = &eb->vma[i];
@@ -1962,11 +1960,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
- vsnap = i915_vma_snapshot_alloc(GFP_KERNEL);
- if (!vsnap)
- continue;
-
- i915_vma_snapshot_init(vsnap, vma, "user");
for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
@@ -1975,10 +1968,9 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
continue;
capture->next = eb->capture_lists[j];
- capture->vma_snapshot = i915_vma_snapshot_get(vsnap);
+ capture->vma_res = i915_vma_resource_get(vma->resource);
eb->capture_lists[j] = capture;
}
- i915_vma_snapshot_put(vsnap);
}
}
@@ -3281,9 +3273,8 @@ eb_requests_create(struct i915_execbuffer *eb, struct
dma_fence *in_fence,
* _onstack interface.
*/
if (eb->batches[i]->vma)
-
i915_vma_snapshot_init_onstack(&eb->requests[i]->batch_snapshot,
- eb->batches[i]->vma,
- "batch");
+ eb->requests[i]->batch_res =
+
i915_vma_resource_get(eb->batches[i]->vma->resource);
if (eb->batch_pool) {
GEM_BUG_ON(intel_context_is_parallel(eb->context));
intel_gt_buffer_pool_mark_active(eb->batch_pool,
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 74aa90587061..d1daa4cc2895 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1708,18 +1708,15 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
static void print_request_ring(struct drm_printer *m, struct i915_request *rq)
{
- struct i915_vma_snapshot *vsnap = &rq->batch_snapshot;
+ struct i915_vma_resource *vma_res = rq->batch_res;
void *ring;
int size;
- if (!i915_vma_snapshot_present(vsnap))
- vsnap = NULL;
-
drm_printf(m,
"[head %04x, postfix %04x, tail %04x, batch 0x%08x_%08x]:\n",
rq->head, rq->postfix, rq->tail,
- vsnap ? upper_32_bits(vsnap->vma_resou
[Intel-gfx] [PATCH v3 5/7] drm/i915: Use the vma resource as argument for gtt binding / unbinding
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the insert_entries() op for struct i915_address_space.
Replace a couple of i915_vma_snapshot members with their newly introduced
i915_vma_resource counterparts, since they have the same lifetime.
Also make sure to avoid changing the struct i915_vma_flags (in particular
the bind flags) async. That should now only be done sync under the
vm mutex.
v2:
- Update the vma_res::bound_flags when binding to the aliased ggtt
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_dpt.c | 27 ++---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 ++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 70 ++---
drivers/gpu/drm/i915/gt/intel_gtt.h | 15 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 24 -
drivers/gpu/drm/i915/i915_vma.h | 11 +--
drivers/gpu/drm/i915/i915_vma_resource.c | 9 +-
drivers/gpu/drm/i915/i915_vma_resource.h | 99 ++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 4 -
drivers/gpu/drm/i915/i915_vma_snapshot.h | 8 --
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 64
drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +--
21 files changed, 307 insertions(+), 206 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 963ca7155b06..f9f2a4ef38cd 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -48,7 +48,7 @@ static void dpt_insert_page(struct i915_address_space *vm,
}
static void dpt_insert_entries(struct i915_address_space *vm,
- struct i915_vma *vma,
+ struct i915_vma_resource *vma_res,
enum i915_cache_level level,
u32 flags)
{
@@ -64,8 +64,8 @@ static void dpt_insert_entries(struct i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- i = vma->node.start / I915_GTT_PAGE_SIZE;
- for_each_sgt_daddr(addr, sgt_iter, vma->pages)
+ i = vma_res->start / I915_GTT_PAGE_SIZE;
+ for_each_sgt_daddr(addr, sgt_iter, vma_res->bi.pages)
gen8_set_pte(&base[i++], pte_encode | addr);
}
@@ -76,35 +76,38 @@ static void dpt_clear_range(struct i915_address_space *vm,
static void dpt_bind_vma(struct i915_address_space *vm,
struct i915_vm_pt_stash *stash,
-struct i915_vma *vma,
+struct i915_vma_resource *vma_res,
enum i915_cache_level cache_level,
u32 flags)
{
- struct drm_i915_gem_object *obj = vma->obj;
u32 pte_flags;
+ if (vma_res->bound_flags)
+ return;
+
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
- if (vma->vm->has_read_only && i915_gem_object_is_readonly(obj))
+ if (vm->has_read_only && vma_res->bi.readonly)
pte_flags |= PTE_READ_ONLY;
- if (i915_gem_object_is_lmem(obj))
+ if (vma_res->bi.lmem)
pte_flags |= PTE_LM;
- vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
+ vm->insert_entries(vm, vma_res, cache_level, pte_flags);
- vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
+ vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
/*
* Without aliasing PPGTT there's no difference between
* GLOBAL/LOCAL_BIND, it's all the same ptes. Hence unconditionally
* upgrade to both bound if we bind either to avoid double-binding.
*/
- atomic_or(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND, &vma->flags);
+ vma_res->bound_flags = I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
}
-static void dpt_unbind_vma(struct i915_address_space *vm, struct i915_vma *vma)
+static void dpt_unbind_vma(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res)
{
- vm->clear_range(vm, vma->node.start, vma->size);
+ vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
static void dpt_cleanup(struct i915_ad
[Intel-gfx] [PATCH v3 6/7] drm/i915: Use vma resources for async unbinding
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to avoid stalling the migration blit waiting for unbind, as they
can certainly go on in parallel, but since we don't yet have a
reasonable data structure to use to coalesce fences and attach the
resulting fence to a timeline, we defer that for now.
Note that with async unbinding, even while the unbind waits for the
preceding bind to complete before unbinding, the vma itself might have been
destroyed in the process, clearing the vma pages. Therefore we can
only allow async unbinding if we have a refcounted sg-list and keep a
refcount on that for the vma resource pages to stay intact until
binding occurs. If this condition is not met, a request for an async
unbind is diverted to a sync unbind.
v2:
- Use a separate kmem_cache for vma resources for now to isolate their
memory allocation and aid debugging.
- Move the check for vm closed to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_module.c | 3 +
drivers/gpu/drm/i915/i915_vma.c | 180 --
drivers/gpu/drm/i915/i915_vma.h | 3 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 325 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 45 +++
11 files changed, 518 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index e8a99e8cd129..0b0477f0af8b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -142,7 +142,16 @@ int i915_ttm_move_notify(struct ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
int ret;
- ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE);
+ /*
+* Note: The async unbinding here will actually transform the
+* blocking wait for unbind into a wait before finally submitting
+* evict / migration blit and thus stall the migration timeline
+* which may not be good for overall throughput. We should make
+* sure we await the unbind fences *after* the migration blit
+* instead of *before* as we currently do.
+*/
+ ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE |
+I915_GEM_OBJECT_UNBIND_ASYNC);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index ad54941fcb98..3e9fbbfa13c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -145,7 +145,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
continue;
if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
- __i915_vma_evict(vma);
+ __i915_vma_evict(vma, false);
drm_mm_remove_node(&vma->node);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 30683c06b344..b582a4c6c3c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -161,6 +161,9 @@ static void __i915_vm_release(struct work_struct *work)
struct i915_address_space *vm =
container_of(work, struct i915_address_space, release_work);
+ /* Synchronize async unbinds. */
+ i915_vma_resource_bind_dep_sync_all(vm);
+
vm->cleanup(vm);
i915_address_space_fini(vm);
@@ -189,6 +192,7 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
if (!kref_read(&vm->resv_ref))
kref_init(&vm->resv_ref);
+ vm->pending_unbind = RB_ROOT_CACHED;
INIT_WORK(&vm->release_work, __i915_vm_release);
atomic_set(&vm->open, 1);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 19c2497630e8..b9bd60cb2687 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -267,6 +267,9 @@ struct i915_address_space {
/* Flags used when creating page-table objects for this vm */
unsigned long lmem_pt_obj_flags;
+ /*
Re: [Intel-gfx] [PATCH v3 13/17] drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something
On 17-12-2021 14:55, Matthew Auld wrote: > On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst > wrote: >> Because we will start to require the obj->resv lock for unbinding, >> ensure these shrinker functions also take the lock. >> >> This requires some function signature changes, to ensure that the >> ww context is passed around, but is mostly straightforward. > Do we even need this? We aren't handling the shared dma-resv for these > ones, right? Or more just to have a consistent-ish interface? Yeah, we don't currently use it, but it will allow for easier eviction in the future, with -EDEADLK handling when required. It will currently only annotate the objects as being held by the ww context, which can cause -EDEADLK when other threads try to lock. Ideally we'd take a ref to the object and perform a blocking lock, but our locking and eviction code can't handle that right now. >> Previously this was split up into several patches, but reworking >> should allow for easier bisection. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- >> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- >> drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 ++ >> drivers/gpu/drm/i915/i915_gem_evict.c | 34 +++ >> drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-- >> drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++ >> drivers/gpu/drm/i915/i915_vgpu.c | 2 +- >> drivers/gpu/drm/i915/i915_vma.c | 9 ++--- >> .../gpu/drm/i915/selftests/i915_gem_evict.c | 17 +- >> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 14 >> 11 files changed, 63 insertions(+), 32 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c >> b/drivers/gpu/drm/i915/gt/intel_ggtt.c >> index a287c9186ec9..ed43e9c80aaa 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c >> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c >> @@ -504,7 +504,7 @@ static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt) >> GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP); >> size = ggtt->vm.total - GUC_GGTT_TOP; >> >> - ret = i915_gem_gtt_reserve(&ggtt->vm, &ggtt->uc_fw, size, >> + ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw, size, >>GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE, >>PIN_NOEVICT); >> if (ret) >> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> index e5ad4d5a91c0..a3597a6bb805 100644 >> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> @@ -1382,7 +1382,7 @@ static int evict_vma(void *data) >> complete(&arg->completion); >> >> mutex_lock(&vm->mutex); >> - err = i915_gem_evict_for_node(vm, &evict, 0); >> + err = i915_gem_evict_for_node(vm, NULL, &evict, 0); >> mutex_unlock(&vm->mutex); >> >> return err; >> diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c >> b/drivers/gpu/drm/i915/gvt/aperture_gm.c >> index 0d6d59871308..c08098a167e9 100644 >> --- a/drivers/gpu/drm/i915/gvt/aperture_gm.c >> +++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c >> @@ -63,7 +63,7 @@ static int alloc_gm(struct intel_vgpu *vgpu, bool high_gm) >> >> mutex_lock(>->ggtt->vm.mutex); >> mmio_hw_access_pre(gt); >> - ret = i915_gem_gtt_insert(>->ggtt->vm, node, >> + ret = i915_gem_gtt_insert(>->ggtt->vm, NULL, node, >> size, I915_GTT_PAGE_SIZE, >> I915_COLOR_UNEVICTABLE, >> start, end, flags); >> diff --git a/drivers/gpu/drm/i915/i915_drv.h >> b/drivers/gpu/drm/i915/i915_drv.h >> index c180019c607f..2a98192a89c1 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.h >> +++ b/drivers/gpu/drm/i915/i915_drv.h >> @@ -1718,11 +1718,13 @@ i915_gem_vm_lookup(struct drm_i915_file_private >> *file_priv, u32 id) >> >> /* i915_gem_evict.c */ >> int __must_check i915_gem_evict_something(struct i915_address_space *vm, >> + struct i915_gem_ww_ctx *ww, >> u64 min_size, u64 alignment, >> unsigned long color, >> u64 start, u64 end, >> unsigned flags); >> int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, >> +struct i915_gem_ww_ctx *ww, >> struct drm_mm_node *node, >> unsigned int flags); >> int i915_gem_evict_vm(struct i915_address_space *vm, >> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c >> b/drivers/gpu/drm/i915/i915_gem_evict.c >> index bfd66f539fc1..f502a617b35c
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: let HW maintain the HS-TRAIL timing (rev3)
== Series Details == Series: drm/i915/dsi: let HW maintain the HS-TRAIL timing (rev3) URL : https://patchwork.freedesktop.org/series/96750/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11012_full -> Patchwork_21869_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21869_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21869_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21869_full: ### IGT changes ### Possible regressions * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-skl4/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-b-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-skl8/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-b-planes.html Known issues Here are the changes found in Patchwork_21869_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [FAIL][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk2/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk8/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21869/shard-glk7/boot.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Asynchronous vma unbinding (rev3)
== Series Details == Series: drm/i915: Asynchronous vma unbinding (rev3) URL : https://patchwork.freedesktop.org/series/98055/ State : warning == Summary == $ dim checkpatch origin/drm-tip af22ef498eaa drm/i915: Avoid using the i915_fence_array when collecting dependencies 664fd217a101 drm/i915: Break out the i915_deps utility -:252: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #252: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 522 lines checked 2cb9ea59d9f7 drm/i915: Require the vm mutex for i915_vma_bind() a7bf661b94a2 drm/i915: Initial introduction of vma resources -:245: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #245: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 626 lines checked 866990d2db6d drm/i915: Use the vma resource as argument for gtt binding / unbinding 0e2ee499a329 drm/i915: Use vma resources for async unbinding -:540: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_node' - possible side-effects? #540: FILE: drivers/gpu/drm/i915/i915_vma_resource.c:36: +#define VMA_RES_LAST(_node) ((_node)->start + (_node)->node_size - 1) total: 0 errors, 0 warnings, 1 checks, 869 lines checked 508fe6fa71d1 drm/i915: Use struct vma_resource instead of struct vma_snapshot -:602: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #602: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 497 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Asynchronous vma unbinding (rev3)
== Series Details == Series: drm/i915: Asynchronous vma unbinding (rev3) URL : https://patchwork.freedesktop.org/series/98055/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v3 03/17] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v3.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > Big delta, but boils down to moving set_pages to i915_vma.c, and removing > the special handling, all callers use the defaults anyway. We only remap > in ggtt, so default case will fall through. > > Because we still don't require locking in i915_vma_unpin(), handle this by > using xchg in get_pages(), as it's locked with obj->mutex, and cmpxchg in > unpin, which only fails if we race a against a new pin. > > Changes since v1: > - aliasing gtt sets ZERO_SIZE_PTR, not -ENODEV, remove special case > from __i915_vma_get_pages(). (Matt) > Changes since v2: > - Free correct old pages in __i915_vma_get_pages(). (Matt) > Remove race of clearing vma->pages accidentally from put, > free it but leave it set, as only get has the lock. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH v3 08/17] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors
On 17-12-2021 12:58, Matthew Auld wrote:
> On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
> wrote:
>> Now that we cannot unbind kill the currently locked object directly
> "unbind kill"
>
>> because we're removing short term pinning, we may have to unbind the
>> object from gtt manually, using a i915_gem_evict_vm() call.
>>
>> Signed-off-by: Maarten Lankhorst
> Maybe mention that this only in preparation for some future patches,
> once the actual eviction is trylock and evict_for_vm can also handle
> shared dma-resv? At this point in the series we shouldn't expect to
> hit -ENOSPC, right?
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 --
>> 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index af81d6c3332a..00cd9642669a 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -358,8 +358,22 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
>> vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view,
>> 0, 0, flags);
>> }
>>
>> - /* The entire mappable GGTT is pinned? Unexpected! */
>> - GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
>> + /*
>> +* The entire mappable GGTT is pinned? Unexpected!
>> +* Try to evict the object we locked too, as normally we
>> skip it
>> +* due to lack of short term pinning inside execbuf.
>> +*/
>> + if (vma == ERR_PTR(-ENOSPC)) {
>> + ret = mutex_lock_interruptible(&ggtt->vm.mutex);
>> + if (!ret) {
>> + ret = i915_gem_evict_vm(&ggtt->vm);
>> + mutex_unlock(&ggtt->vm.mutex);
>> + }
>> + if (ret)
>> + goto err_reset;
>> + vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view,
>> 0, 0, flags);
>> + }
>> + GEM_WARN_ON(vma == ERR_PTR(-ENOSPC));
> Looks like this is being triggered in CI, I assume because the trylock
> could easily fail, due to contention? Is this expected for now? Do we
> keep the WARN and track it as a known issue?
I think it makes sense. I can probably fix i915_gem_evict_vm to attempt to take
all objects in a blocking way.
I had some primitives that could lock for eviction, and keep a refcount on the
object. i915_gem_evict_vm could probably be changed to use it.
>> }
>> if (IS_ERR(vma)) {
>> ret = PTR_ERR(vma);
>> --
>> 2.34.1
>>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Asynchronous vma unbinding (rev3)
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev3)
URL : https://patchwork.freedesktop.org/series/98055/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11012 -> Patchwork_21870
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/index.html
Participating hosts (42 -> 36)
--
Missing(6): fi-bdw-5557u bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_21870 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1610])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live:
- fi-skl-6600u: NOTRUN -> [FAIL][3] ([i915#4547])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-skl-6600u/igt@i915_selft...@live.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@prime_vgem@basic-userptr:
- fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-skl-6600u/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-tgl-dsi/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][9] ([i915#4269]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [FAIL][11] ([i915#4547]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
Warnings
* igt@runner@aborted:
- fi-skl-6600u: [FAIL][13] ([i915#4312]) -> [FAIL][14] ([i915#1436] /
[i915#4312])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/fi-skl-6600u/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/fi-skl-6600u/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#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
Build changes
-
* Linux: CI_DRM_11012 -> Patchwork_21870
CI-20190529: 20190529
CI_DRM_11012: 64bab3fe255d1886ef16ef57451df545380fa6be @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6313: 1793ed798cc09966c27bf478781e0c1d6bb23bad @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21870: 508fe6fa71d119fa5ca79d876ac1c9f038b84430 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
508fe6fa71d1 drm/i915: Use struct vma_resource instead of struct vma_snapshot
0e2ee499a329 drm/i915: Use vma resources for async unbinding
866990d2db6d drm/i915: Use the vma resource as argument for gtt binding /
unbinding
a7bf661b94a2 drm/i915: Initial introduction of vma resources
2cb9ea59d9f7 drm/i915: Require the vm mutex for i915_vma_bind()
664fd217a101 drm/i915: Break out the i915_deps utility
af22ef498eaa drm/i915: Avoid using the i915_fence_array when collecting
dependencies
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/index.html
[Intel-gfx] [PATCH 1/6] drm/i915/bios: Introduce has_ddi_port_info()
From: Ville Syrjälä
Pull the "do we want to use i915->vbt.ports[]?" check into
a central place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 76a8f001f4c4..fce1ea7a6693 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2073,6 +2073,11 @@ static void parse_ddi_port(struct drm_i915_private *i915,
i915->vbt.ports[port] = devdata;
}
+static bool has_ddi_port_info(struct drm_i915_private *i915)
+{
+ return HAS_DDI(i915);
+}
+
static void parse_ddi_ports(struct drm_i915_private *i915)
{
struct intel_bios_encoder_data *devdata;
@@ -2673,7 +2678,7 @@ bool intel_bios_is_port_present(struct drm_i915_private
*i915, enum port port)
[PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
};
- if (HAS_DDI(i915))
+ if (has_ddi_port_info(i915))
return i915->vbt.ports[port];
/* FIXME maybe deal with port A as well? */
@@ -2713,7 +2718,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private
*i915, enum port port)
[PORT_F] = DVO_PORT_DPF,
};
- if (HAS_DDI(i915)) {
+ if (has_ddi_port_info(i915)) {
const struct intel_bios_encoder_data *devdata;
devdata = intel_bios_encoder_data_lookup(i915, port);
@@ -2768,7 +2773,7 @@ bool intel_bios_is_port_dp_dual_mode(struct
drm_i915_private *i915,
};
const struct intel_bios_encoder_data *devdata;
- if (HAS_DDI(i915)) {
+ if (has_ddi_port_info(i915)) {
const struct intel_bios_encoder_data *devdata;
devdata = intel_bios_encoder_data_lookup(i915, port);
--
2.32.0
[Intel-gfx] [PATCH 0/6] drm/i915: Extend parse_ddi_port() to all g4x+ platforms
From: Ville Syrjälä Quick attempt at unifying the VBT DDI parsing to all g4x+ platforms. Note that we'll still use the hardware straps as the primary source of port presence information on old platforms since the device type bits in VBT tend to be often a bit wrong (for DP++ ports at least). Hopefully the rest of the information (mainly aux_ch/ddc_pin) are correct. Only very slightly smoke tested on SNB so far. Ville Syrjälä (6): drm/i915/bios: Introduce has_ddi_port_info() drm/i915/bios: Use i915->vbt.ports[] on CHV drm/i915/bios: Use i915->vbt.ports[] for all g4x+ drm/i915/bios: Throw out the !has_ddi_port_info() codepaths drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITS drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports drivers/gpu/drm/i915/display/intel_bios.c | 117 +++--- drivers/gpu/drm/i915/display/intel_hdmi.c | 8 ++ drivers/gpu/drm/i915/display/intel_vbt_defs.h | 26 3 files changed, 28 insertions(+), 123 deletions(-) -- 2.32.0
[Intel-gfx] [PATCH 2/6] drm/i915/bios: Use i915->vbt.ports[] on CHV
From: Ville Syrjälä
CHV is currently straddling the divide by using parse_ddi_ports() stuff
for aux_ch/ddc_pin but going through all old codepaths for the rest
(intel_bios_is_port_present(), intel_bios_is_port_edp(),
intel_bios_is_port_dp_dual_mode()). Let's switch over full and use
i915->vbt.ports[] for the rest of the stuff.
dvo_port_to_port() doesn't know about DSI so we won't get into
any kind of "is port B HDMI or DSI or both?" conundrum, which
could otherwise happen on VLV/CHV due to DSI ports living in a
separate world from the other digital ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index fce1ea7a6693..b7adea9827c3 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2075,14 +2075,14 @@ static void parse_ddi_port(struct drm_i915_private
*i915,
static bool has_ddi_port_info(struct drm_i915_private *i915)
{
- return HAS_DDI(i915);
+ return HAS_DDI(i915) || IS_CHERRYVIEW(i915);
}
static void parse_ddi_ports(struct drm_i915_private *i915)
{
struct intel_bios_encoder_data *devdata;
- if (!HAS_DDI(i915) && !IS_CHERRYVIEW(i915))
+ if (!has_ddi_port_info(i915))
return;
if (i915->vbt.version < 155)
--
2.32.0
[Intel-gfx] [PATCH 3/6] drm/i915/bios: Use i915->vbt.ports[] for all g4x+
From: Ville Syrjälä
Extend the vbt.ports[] stuff for all g4x+ platforms. We do need
to drop the version check as some elk/ctg machines may have VBTs
older than that. The oldest I know is an elk with version 142.
But the child device stuff has had the correct size since at
least version 125 (observed on my sdg), we from that angle this
should be totally safe.
This does couple of things:
- Start using the aux_ch/ddc_pin from VBT instead of just the
hardcoded defaults. Hopefully there are no VBTs with entirely
bogus information here.
- Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode().
Should be fine as the logic doesn't actually change.
- Start using i915->vbt.ports[] for intel_bios_is_port_edp().
The old codepath only looks at the DP DVO ports, the new codepath
looks at both DP and HDMI DVO ports. In principle that should not
matter. We also stop looking at some of the other device type bits
(eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that
it sets up totally conflicting device type bits (eg. LVDS+eDP at the
same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't
be hard to re-introduce that into eg. sanitize_device_type() if needed).
TODO: actually smoke test on various platforms
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index b7adea9827c3..d7d64d3bf083 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2075,7 +2075,7 @@ static void parse_ddi_port(struct drm_i915_private *i915,
static bool has_ddi_port_info(struct drm_i915_private *i915)
{
- return HAS_DDI(i915) || IS_CHERRYVIEW(i915);
+ return DISPLAY_VER(i915) >= 5 || IS_G4X(i915);
}
static void parse_ddi_ports(struct drm_i915_private *i915)
@@ -2085,9 +2085,6 @@ static void parse_ddi_ports(struct drm_i915_private *i915)
if (!has_ddi_port_info(i915))
return;
- if (i915->vbt.version < 155)
- return;
-
list_for_each_entry(devdata, &i915->vbt.display_devices, node)
parse_ddi_port(i915, devdata);
}
--
2.32.0
[Intel-gfx] [PATCH 5/6] drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITS
From: Ville Syrjälä
Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just
a DP+HDMI check. The rest of the bits shouldn't really
matter anyway.
The slight change in behaviour here is that now we do look at
the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via
intel_bios_encoder_supports_hdmi()) when we previously ignored it.
The one platform we know that has problems with that bit is VLV.
But IIRC the problem was always that buggy VBTs basically never
set that bit. So that should be OK since all it would do is make
all DVI ports look like HDMI ports instead. Also can't imagine
there are many VLV machines with actual DVI ports in existence.
We still keep the rest of the dvo_port/aux_ch checks as we
can't trust that DP+HDMI device type equals DP++ due to
buggy VBTs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 10 ++
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 11 ---
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index f5aa2c72b2fe..d1909ad28306 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2684,10 +2684,12 @@ bool intel_bios_is_port_edp(struct drm_i915_private
*i915, enum port port)
return devdata && intel_bios_encoder_supports_edp(devdata);
}
-static bool child_dev_is_dp_dual_mode(const struct child_device_config *child)
+static bool intel_bios_encoder_supports_dp_dual_mode(const struct
intel_bios_encoder_data *devdata)
{
- if ((child->device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) !=
- (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
+ const struct child_device_config *child = &devdata->child;
+
+ if (!intel_bios_encoder_supports_dp(devdata) ||
+ !intel_bios_encoder_supports_hdmi(devdata))
return false;
if (dvo_port_type(child->dvo_port) == DVO_PORT_DPA)
@@ -2707,7 +2709,7 @@ bool intel_bios_is_port_dp_dual_mode(struct
drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata =
intel_bios_encoder_data_lookup(i915, port);
- return devdata && child_dev_is_dp_dual_mode(&devdata->child);
+ return devdata && intel_bios_encoder_supports_dp_dual_mode(devdata);
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index c23582769f34..a39d6cfea87a 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -226,17 +226,6 @@ struct bdb_general_features {
#define DEVICE_TYPE_DIGITAL_OUTPUT (1 << 1)
#define DEVICE_TYPE_ANALOG_OUTPUT (1 << 0)
-#define DEVICE_TYPE_DP_DUAL_MODE_BITS \
- (DEVICE_TYPE_INTERNAL_CONNECTOR | \
-DEVICE_TYPE_MIPI_OUTPUT | \
-DEVICE_TYPE_COMPOSITE_OUTPUT | \
-DEVICE_TYPE_LVDS_SIGNALING | \
-DEVICE_TYPE_TMDS_DVI_SIGNALING | \
-DEVICE_TYPE_VIDEO_SIGNALING | \
-DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
-DEVICE_TYPE_DIGITAL_OUTPUT | \
-DEVICE_TYPE_ANALOG_OUTPUT)
-
#define DEVICE_CFG_NONE0x00
#define DEVICE_CFG_12BIT_DVOB 0x01
#define DEVICE_CFG_12BIT_DVOC 0x02
--
2.32.0
[Intel-gfx] [PATCH 4/6] drm/i915/bios: Throw out the !has_ddi_port_info() codepaths
From: Ville Syrjälä
Now that we parse the DDI port info from the VBT on all g4x+ platforms
we can throw out all the old codepaths in intel_bios_is_port_present(),
intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None
of these should be called on pre-g4x platforms.
For good measure throw in a WARN into intel_bios_is_port_present()
should someone get the urge to call it on older platforms. The
other two functions are specific to HDMI and DP so should not need
any protection as those encoder types don't even exist on older
platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 99 ++-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 15 ---
2 files changed, 9 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index d7d64d3bf083..f5aa2c72b2fe 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2663,37 +2663,10 @@ bool intel_bios_is_lvds_present(struct drm_i915_private
*i915, u8 *i2c_pin)
*/
bool intel_bios_is_port_present(struct drm_i915_private *i915, enum port port)
{
- const struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
- static const struct {
- u16 dp, hdmi;
- } port_mapping[] = {
- [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
- [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
- [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
- [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
- [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
- };
+ if (WARN_ON(!has_ddi_port_info(i915)))
+ return true;
- if (has_ddi_port_info(i915))
- return i915->vbt.ports[port];
-
- /* FIXME maybe deal with port A as well? */
- if (drm_WARN_ON(&i915->drm,
- port == PORT_A) || port >= ARRAY_SIZE(port_mapping))
- return false;
-
- list_for_each_entry(devdata, &i915->vbt.display_devices, node) {
- child = &devdata->child;
-
- if ((child->dvo_port == port_mapping[port].dp ||
-child->dvo_port == port_mapping[port].hdmi) &&
- (child->device_type & (DEVICE_TYPE_TMDS_DVI_SIGNALING |
- DEVICE_TYPE_DISPLAYPORT_OUTPUT)))
- return true;
- }
-
- return false;
+ return i915->vbt.ports[port];
}
/**
@@ -2705,34 +2678,10 @@ bool intel_bios_is_port_present(struct drm_i915_private
*i915, enum port port)
*/
bool intel_bios_is_port_edp(struct drm_i915_private *i915, enum port port)
{
- const struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
- static const short port_mapping[] = {
- [PORT_B] = DVO_PORT_DPB,
- [PORT_C] = DVO_PORT_DPC,
- [PORT_D] = DVO_PORT_DPD,
- [PORT_E] = DVO_PORT_DPE,
- [PORT_F] = DVO_PORT_DPF,
- };
+ const struct intel_bios_encoder_data *devdata =
+ intel_bios_encoder_data_lookup(i915, port);
- if (has_ddi_port_info(i915)) {
- const struct intel_bios_encoder_data *devdata;
-
- devdata = intel_bios_encoder_data_lookup(i915, port);
-
- return devdata && intel_bios_encoder_supports_edp(devdata);
- }
-
- list_for_each_entry(devdata, &i915->vbt.display_devices, node) {
- child = &devdata->child;
-
- if (child->dvo_port == port_mapping[port] &&
- (child->device_type & DEVICE_TYPE_eDP_BITS) ==
- (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
- return true;
- }
-
- return false;
+ return devdata && intel_bios_encoder_supports_edp(devdata);
}
static bool child_dev_is_dp_dual_mode(const struct child_device_config *child)
@@ -2755,40 +2704,10 @@ static bool child_dev_is_dp_dual_mode(const struct
child_device_config *child)
bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *i915,
enum port port)
{
- static const struct {
- u16 dp, hdmi;
- } port_mapping[] = {
- /*
-* Buggy VBTs may declare DP ports as having
-* HDMI type dvo_port :( So let's check both.
-*/
- [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
- [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
- [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
- [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
- [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
- };
- const struct intel_bios_encoder_data *devdata;
+ const struct intel_bios_encoder_data *devdata =
+ intel_bios_enc
[Intel-gfx] [PATCH 6/6] drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports
From: Ville Syrjälä
Lots of machines these days seem to have a crappy type1 DP dual
mode adaptor chip slapped onto the motherboard. Based on the
DP dual mode spec we currently limit those to 165MHz max TMDS
clock.
Windows OTOH ignores DP dual mode adaptors when the VBT
indicates that the port is not actually DP++, so we can
perhaps assume that the vendors did intend that the 165MHz
clock limit doesn't apply here. Though it would be much
nicer if they actually declared an explicit limit through
VBT, but that doesn't seem to be happening either.
So in order to match Windows behaviour let's ignore the
DP dual mode adaptor's TMDS clock limit for ports that
don't look like DP++ in VBT.
Unfortunately many older VBTs misdelcare their DP++ ports
as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB
Lenovo ThinkPad X220). So we can't really do this universally
without risking black screens. I suppose a sensible cutoff
is HSW+ since that's when 4k became a thing and one might
assume that the machines have been tested to work with higher
TMDS clock rates.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 3b5b9e7b05b7..9f0557d9e9a5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2359,6 +2359,14 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
"DP dual mode adaptor (%s) detected (max TMDS clock: %d
kHz)\n",
drm_dp_get_dual_mode_type_name(type),
hdmi->dp_dual_mode.max_tmds_clock);
+
+ /* Older VBTs are often buggy and can't be trusted :( Play it safe. */
+ if ((DISPLAY_VER(dev_priv) >= 8 || IS_BROADWELL(dev_priv)) &&
+ !intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
+ drm_dbg_kms(&dev_priv->drm,
+ "Ignoring DP dual mode adaptor max TMDS clock for
native HDMI port\n");
+ hdmi->dp_dual_mode.max_tmds_clock = 0;
+ }
}
static bool
--
2.32.0
[Intel-gfx] [PATCH v2] drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm()
Check return pointer from intel_crtc_for_plane() before dereferencing it, as it can be NULL. v2: Moved the NULL check into intel_crtc_active(). Cc: Jani Nikula Cc: Caz Yokoyama Cc: Radhakrishna Sripada Signed-off-by: Harish Chegondi --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index bdf97a8c9ef3..8b357ec35a4a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -877,7 +877,7 @@ static bool intel_crtc_active(struct intel_crtc *crtc) * crtc->state->active once we have proper CRTC states wired up * for atomic. */ - return crtc->active && crtc->base.primary->state->fb && + return crtc && crtc->active && crtc->base.primary->state->fb && crtc->config->hw.adjusted_mode.crtc_clock; } -- 2.31.1
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm()
On Fri, Dec 17, 2021 at 08:02:55AM -0800, Harish Chegondi wrote: > Check return pointer from intel_crtc_for_plane() before dereferencing > it, as it can be NULL. Can't actually bu NULL. But I guess no real harm in having the check if it shuts up some static analysis thing. > > v2: Moved the NULL check into intel_crtc_active(). > > Cc: Jani Nikula > Cc: Caz Yokoyama > Cc: Radhakrishna Sripada > Signed-off-by: Harish Chegondi > --- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index bdf97a8c9ef3..8b357ec35a4a 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -877,7 +877,7 @@ static bool intel_crtc_active(struct intel_crtc *crtc) >* crtc->state->active once we have proper CRTC states wired up >* for atomic. >*/ > - return crtc->active && crtc->base.primary->state->fb && > + return crtc && crtc->active && crtc->base.primary->state->fb && > crtc->config->hw.adjusted_mode.crtc_clock; > } > > -- > 2.31.1 -- Ville Syrjälä Intel
[Intel-gfx] How to fix screen resolution detection?
The screen resolution on my laptop is not reported accurately. Here's an extract from the output of xdpyinfo: screen #0: dimensions:3200x1800 pixels (847x476 millimeters) resolution:96x96 dots per inch The number of pixels is correct, but the size and resolution values smack of a bogus default. The actual width of the screen (determined with a tape measure) is about 11.5 inches (291 mm), which yields a resolution of 280 dots per inch (11 dots per mm), approximately. Most definitely _not_ 96 dpi. Presumably X gets the size/resolution information from Wayland, which gets it from the kernel, which gets it from the firmware. So the kernel driver is the logical place to start in figuring where things are going wrong. The laptop uses i915; here are the relevant lines from the kernel log: [0.00] Linux version 5.14.9-200.fc34.x86_64 (mockbu...@bkernel02.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.35.2-5.fc34) #1 SMP Thu Sep 30 11:55:35 UTC 2021 [0.463895] efifb: probing for efifb [0.463913] efifb: framebuffer at 0xe000, using 22500k, total 22500k [0.463916] efifb: mode is 3200x1800x32, linelength=12800, pages=1 [0.463919] efifb: scrolling: redraw [0.463920] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [0.464028] Console: switching to colour frame buffer device 400x112 [0.474894] fb0: EFI VGA frame buffer device [2.58] fb0: switching to inteldrmfb from EFI VGA [2.891260] Console: switching to colour dummy device 80x25 [2.891318] i915 :00:02.0: vgaarb: deactivate vga console [2.902665] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.904833] i915 :00:02.0: [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27) [2.947359] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 [2.949468] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [2.949803] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input9 [2.964371] fbcon: i915 (fb0) is primary device [2.979854] Console: switching to colour frame buffer device 400x112 [3.012355] i915 :00:02.0: [drm] fb0: i915 frame buffer device Now, I know nothing about the kernel's graphics subsystems. How can I find out what size/resolution information i915 is getting and passing to Wayland? If it's wrong, how can I fix it? Thanks, Alan Stern
Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
>
> On 14/12/2021 15:07, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Log engine resets done by the GuC firmware in the similar way it is done
> > by the execlists backend.
> >
> > This way we have notion of where the hangs are before the GuC gains
> > support for proper error capture.
>
> Ping - any interest to log this info?
>
> All there currently is a non-descriptive "[drm] GPU HANG: ecode
> 12:0:".
>
Yea, this could be helpful. One suggestion below.
> Also, will GuC be reporting the reason for the engine reset at any point?
>
We are working on the error state capture, presumably the registers will
give a clue what caused the hang.
As for the GuC providing a reason, that isn't defined in the interface
but that is decent idea to provide a hint in G2H what the issue was. Let
me run that by the i915 GuC developers / GuC firmware team and see what
they think.
> Regards,
>
> Tvrtko
>
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Matthew Brost
> > Cc: John Harrison
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 9739da6f..51512123dc1a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -11,6 +11,7 @@
> > #include "gt/intel_context.h"
> > #include "gt/intel_engine_pm.h"
> > #include "gt/intel_engine_heartbeat.h"
> > +#include "gt/intel_engine_user.h"
> > #include "gt/intel_gpu_commands.h"
> > #include "gt/intel_gt.h"
> > #include "gt/intel_gt_clock_utils.h"
> > @@ -3934,9 +3935,18 @@ static void capture_error_state(struct intel_guc
> > *guc,
> > {
> > struct intel_gt *gt = guc_to_gt(guc);
> > struct drm_i915_private *i915 = gt->i915;
> > - struct intel_engine_cs *engine = __context_to_physical_engine(ce);
> > + struct intel_engine_cs *engine = ce->engine;
> > intel_wakeref_t wakeref;
> > + if (intel_engine_is_virtual(engine)) {
> > + drm_notice(&i915->drm, "%s class, engines 0x%x; GuC engine
> > reset\n",
> > + intel_engine_class_repr(engine->class),
> > + engine->mask);
> > + engine = guc_virtual_get_sibling(engine, 0);
> > + } else {
> > + drm_notice(&i915->drm, "%s GuC engine reset\n", engine->name);
Probably include the guc_id of the context too then?
Matt
> > + }
> > +
> > intel_engine_set_hung_context(engine, ce);
> > with_intel_runtime_pm(&i915->runtime_pm, wakeref)
> > i915_capture_error_state(gt, engine->mask);
> >
Re: [Intel-gfx] [PATCH] drm/i915/mst: update slot information for 128b/132b
On Thu, Dec 16, 2021 at 04:05:48PM +0200, Jani Nikula wrote:
> 128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
> slot 0 for metadata.
>
> Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
> on Encoding Format") added support for updating the topology state
> accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP 2.0 MST
> DM Support") started using it in the amd driver.
>
> This feels more than a little cumbersome, especially updating the
> information in atomic check. For i915, add the update to MST connector
> .atomic_check hook rather than iterating over all MST managers and
> connectors in global mode config .atomic_check. Fingers crossed.
>
> Cc: Bhawanpreet Lakha
> Cc: Lyude Paul
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index b8bc7d397c81..d13c7952a8d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -302,6 +302,8 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
> if (!old_conn_state->crtc)
> return 0;
>
> + mgr =
> &enc_to_mst(to_intel_encoder(old_conn_state->best_encoder))->primary->dp.mst_mgr;
> +
> /* We only want to free VCPI if this state disables the CRTC on this
>* connector
>*/
> @@ -309,6 +311,15 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> struct intel_crtc *crtc = to_intel_crtc(new_crtc);
> struct intel_crtc_state *crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> + struct drm_dp_mst_topology_state *topology_state;
> + u8 link_coding_cap = intel_dp_is_uhbr(crtc_state) ?
> + DP_CAP_ANSI_128B132B : DP_CAP_ANSI_8B10B;
This is too early. We haven't determined the link rate yet.
So intel_dp_mst_compute_config() is the earliest we can do this.
> +
> + topology_state =
> drm_atomic_get_mst_topology_state(&state->base, mgr);
> + if (IS_ERR(topology_state))
> + return PTR_ERR(topology_state);
> +
> + drm_dp_mst_update_slots(topology_state, link_coding_cap);
>
> if (!crtc_state ||
> !drm_atomic_crtc_needs_modeset(&crtc_state->uapi) ||
> @@ -316,7 +327,6 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
> return 0;
> }
>
> - mgr =
> &enc_to_mst(to_intel_encoder(old_conn_state->best_encoder))->primary->dp.mst_mgr;
> ret = drm_dp_atomic_release_vcpi_slots(&state->base, mgr,
> intel_connector->port);
>
> @@ -357,6 +367,7 @@ static void intel_mst_disable_dp(struct
> intel_atomic_state *state,
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
> struct drm_i915_private *i915 = to_i915(connector->base.qdev);
> + int start_slot = intel_dp_is_uhbr(old_crtc_state) ? 0 : 1;a
> int ret;
>
> drm_dbg_kms(&i915->drm, "active links %d\n",
> @@ -366,7 +377,7 @@ static void intel_mst_disable_dp(struct
> intel_atomic_state *state,
>
> drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, connector->port);
>
> - ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, 1);
> + ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, start_slot);
I supoose what we should do in these places is grab the new/old
mst state and dig the slot info out from it. Or I guess even better
to just pass in the whole mst_state and let the mst code dig out what
it needs.
> if (ret) {
> drm_dbg_kms(&i915->drm, "failed to update payload %d\n", ret);
> }
> @@ -475,6 +486,7 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> + int start_slot = intel_dp_is_uhbr(pipe_config) ? 0 : 1;
> int ret;
> bool first_mst_stream;
>
> @@ -509,7 +521,7 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
>
> intel_dp->active_mst_links++;
>
> - ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, 1);
> + ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, start_slot);
>
> /*
>* Before Gen 12 this is not done as part of
> --
> 2.30.2
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend parse_ddi_port() to all g4x+ platforms
== Series Details == Series: drm/i915: Extend parse_ddi_port() to all g4x+ platforms URL : https://patchwork.freedesktop.org/series/98183/ State : success == Summary == CI Bug Log - changes from CI_DRM_11013 -> Patchwork_21871 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/index.html Participating hosts (41 -> 35) -- Additional (2): fi-kbl-soraka fi-icl-u2 Missing(8): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-pnv-d510 bat-jsl-2 fi-bdw-samus Known issues Here are the changes found in Patchwork_21871 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +26 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: [PASS][4] -> [FAIL][5] ([i915#1888]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [PASS][6] -> [FAIL][7] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][11] ([i915#4613]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_rpm@module-reload: - fi-icl-u2: NOTRUN -> [FAIL][12] ([i915#3049]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gt_mocs: - fi-tgl-1115g4: [PASS][13] -> [DMESG-WARN][14] ([i915#2867]) +20 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][15] ([i915#1886] / [i915#2291]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@objects: - fi-icl-u2: NOTRUN -> [DMESG-WARN][16] ([i915#2867]) +4 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@i915_selftest@l...@objects.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][18] ([fdo#111827]) +8 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][19] ([fdo#109278]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][20] ([fdo#109285]) [
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm() (rev2)
== Series Details == Series: drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm() (rev2) URL : https://patchwork.freedesktop.org/series/98154/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11013 -> Patchwork_21872 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21872 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21872, 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_21872/index.html Participating hosts (41 -> 34) -- Missing(7): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-jsl-2 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21872: ### CI changes ### Possible regressions * boot: - fi-bxt-dsi: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-bxt-dsi/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21872/fi-bxt-dsi/boot.html Known issues Here are the changes found in Patchwork_21872 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21872/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [PASS][4] -> [FAIL][5] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21872/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][6] -> [DMESG-WARN][7] ([i915#4269]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21872/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][8] ([i915#3921]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21872/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_11013 -> Patchwork_21872 CI-20190529: 20190529 CI_DRM_11013: 8bb5fc67223d47c94f8689f3034e080d7f72af38 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6313: 1793ed798cc09966c27bf478781e0c1d6bb23bad @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21872: e80a1665579d1c85c218e021862aa89d0f246226 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e80a1665579d drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21872/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Asynchronous vma unbinding (rev3)
== Series Details == Series: drm/i915: Asynchronous vma unbinding (rev3) URL : https://patchwork.freedesktop.org/series/98055/ State : success == Summary == CI Bug Log - changes from CI_DRM_11012_full -> Patchwork_21870_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21870_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-iclb6/igt@feature_discov...@display-4x.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][2] -> [TIMEOUT][3] ([i915#3063] / [i915#3648]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-tglb8/igt@gem_...@unwedge-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-tglb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_capture@pi@vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][4] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-skl4/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-skl: NOTRUN -> [SKIP][5] ([fdo#109271]) +91 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-glk3/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-multi: - shard-skl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-skl8/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@smem-oom: - shard-kbl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-kbl2/igt@gem_lmem_swapp...@smem-oom.html * igt@gem_pwrite@basic-exhaustion: - shard-kbl: NOTRUN -> [WARN][11] ([i915#2658]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-kbl2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_pxp@regular-baseline-src-copy-readible: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271]) +70 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-kbl6/igt@gem_...@regular-baseline-src-copy-readible.html * igt@gem_render_copy@yf-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#768]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-iclb6/igt@gem_render_c...@yf-tiled-to-vebox-linear.html * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109293] / [fdo#109506]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-iclb6/igt@i915_pm_...@gem-execbuf-stress-pc8.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#2521]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-skl7/igt@kms_async_fl...@alternate-sync-async-flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11012/shard-glk5/igt@kms_big...@x-tiled-32bpp-rotate-180.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-glk2/igt@kms_big...@x-tiled-32bpp-rotate-180.html * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-kbl2/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180-hflip.html * igt@kms_big_fb@y-tiled-64bpp-rotate-90: - shard-iclb: NOTRUN -> [SKIP][20] ([fdo#110725] / [fdo#111614]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21870/shard-iclb6/igt@kms_big...@y-tiled-64bpp-rotate-90.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip: - shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3777]) +1 similar issue [21]: https://in
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Extend parse_ddi_port() to all g4x+ platforms
== Series Details == Series: drm/i915: Extend parse_ddi_port() to all g4x+ platforms URL : https://patchwork.freedesktop.org/series/98183/ State : success == Summary == CI Bug Log - changes from CI_DRM_11013_full -> Patchwork_21871_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21871_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-kbl3/igt@gem_cre...@create-massive.html - shard-skl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-skl10/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-skl: NOTRUN -> [TIMEOUT][5] ([i915#3063]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-skl10/igt@gem_...@unwedge-stress.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-skl7/igt@gem_exec_capture@p...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-skl3/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-apl8/igt@gem_exec_fair@basic-none-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-glk7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-skl10/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@heavy-verify-random: - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-kbl6/igt@gem_lmem_swapp...@heavy-verify-random.html * igt@gem_lmem_swapping@parallel-multi: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-apl7/igt@gem_lmem_swapp...@parallel-multi.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-apl7/igt@gem_soft...@noreloc-s3.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-apl3/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html * igt@i915_pm_dc@dc6-dpms: - shard-skl: NOTRUN -> [FAIL][19] ([i915#454]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-skl10/igt@i915_pm...@dc6-dpms.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][20] -> [INCOMPLETE][21] ([i915#3921]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-snb2/igt@i915_selftest@l...@hangcheck.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-snb4/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@perf@region: - shard-tglb: [PASS][22] -> [DMESG-WARN][23] ([i915#2867]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-tglb7/igt@i915_selftest@p...@region.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21871/shard-
[Intel-gfx] [PATCH] drm/i915/display: Move cdclk checks to atomic check
Checking cdclk conditions during atomic check and preparing
for commit phase so we can have atomic commit as simple
as possible. Add the specific steps to be taken during
cdclk changes, prepare for squashing, crawling and modeset
scenarios.
Rename functions intel_cdclk_can_squash() and
intel_cdclk_can_crawl() since they no longer simply check
if squashing and crawling can be performed.
Cc: Matt Roper
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 130 +++---
drivers/gpu/drm/i915/display/intel_cdclk.h| 3 +-
.../drm/i915/display/intel_display_power.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 13 ++
4 files changed, 96 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 249f81a80eb7..4a5ddc202c05 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1698,12 +1698,15 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
{
+ struct cdclk_steps *cdclk_steps = dev_priv->cdclk.steps;
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
+ u32 squash_ctl = 0;
u32 val;
u16 waveform;
int clock;
int ret;
+ int i;
/* Inform power controller of upcoming frequency change. */
if (DISPLAY_VER(dev_priv) >= 11)
@@ -1727,40 +1730,43 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->cdclk.hw.vco > 0 && vco > 0)
{
- if (dev_priv->cdclk.hw.vco != vco)
+ for (i = 0; i < CDCLK_ACTIONS; i++) {
+ switch (cdclk_steps[i].action) {
+ case CDCLK_MODESET:
+ if (DISPLAY_VER(dev_priv) >= 11) {
+ if (dev_priv->cdclk.hw.vco != 0 &&
+ dev_priv->cdclk.hw.vco != vco)
+ icl_cdclk_pll_disable(dev_priv);
+
+ if (dev_priv->cdclk.hw.vco != vco)
+ icl_cdclk_pll_enable(dev_priv, vco);
+ } else {
+ if (dev_priv->cdclk.hw.vco != 0 &&
+ dev_priv->cdclk.hw.vco != vco)
+ bxt_de_pll_disable(dev_priv);
+
+ if (dev_priv->cdclk.hw.vco != vco)
+ bxt_de_pll_enable(dev_priv, vco);
+ }
+ clock = cdclk;
+ break;
+ case CDCLK_CRAWL:
adlp_cdclk_pll_crawl(dev_priv, vco);
- } else if (DISPLAY_VER(dev_priv) >= 11) {
- if (dev_priv->cdclk.hw.vco != 0 &&
- dev_priv->cdclk.hw.vco != vco)
- icl_cdclk_pll_disable(dev_priv);
-
- if (dev_priv->cdclk.hw.vco != vco)
- icl_cdclk_pll_enable(dev_priv, vco);
- } else {
- if (dev_priv->cdclk.hw.vco != 0 &&
- dev_priv->cdclk.hw.vco != vco)
- bxt_de_pll_disable(dev_priv);
-
- if (dev_priv->cdclk.hw.vco != vco)
- bxt_de_pll_enable(dev_priv, vco);
- }
-
- waveform = cdclk_squash_waveform(dev_priv, cdclk);
-
- if (waveform)
- clock = vco / 2;
- else
- clock = cdclk;
-
- if (has_cdclk_squasher(dev_priv)) {
- u32 squash_ctl = 0;
-
- if (waveform)
+ clock = cdclk;
+ break;
+ case CDCLK_SQUASH:
+ waveform = cdclk_squash_waveform(dev_priv,
cdclk_steps[i].cdclk);
+ clock = vco / 2;
squash_ctl = CDCLK_SQUASH_ENABLE |
- CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
-
- intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
+ CDCLK_SQUASH_WINDOW_SIZE(0xf) |
waveform;
+ intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
+ break;
+ case CDCLK_NOOP:
+ break;
+ default:
+ MISSING_CASE(cdclk_steps[i].action);
+ break;
+ }
}
val = bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) |
@@ -1950,10 +1956,11 @@ void intel_cdclk_uninit_hw(struct drm_i915_private
*i915)
skl_cdclk_uninit_hw(i915);
}
-static bool intel_cdclk_can_crawl(struct drm_i915_private *dev_priv,
+static bool intel_cdclk_crawl(struct drm_i915_private *dev_priv,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Move cdclk checks to atomic check (rev2)
== Series Details == Series: drm/i915/display: Move cdclk checks to atomic check (rev2) URL : https://patchwork.freedesktop.org/series/97850/ State : warning == Summary == $ dim checkpatch origin/drm-tip a83c610f1486 drm/i915/display: Move cdclk checks to atomic check -:120: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #120: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1960: +static bool intel_cdclk_crawl(struct drm_i915_private *dev_priv, const struct intel_cdclk_config *a, -:144: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #144: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1988: +static bool intel_cdclk_squash(struct drm_i915_private *dev_priv, const struct intel_cdclk_config *a, total: 0 errors, 0 warnings, 2 checks, 288 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Move cdclk checks to atomic check (rev2)
== Series Details == Series: drm/i915/display: Move cdclk checks to atomic check (rev2) URL : https://patchwork.freedesktop.org/series/97850/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/display: Move cdclk checks to atomic check (rev2)
== Series Details == Series: drm/i915/display: Move cdclk checks to atomic check (rev2) URL : https://patchwork.freedesktop.org/series/97850/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_cdclk.c:2025: warning: Function parameter or member 'dev_priv' not described in 'intel_cdclk_needs_modeset' ./drivers/gpu/drm/i915/display/intel_cdclk.c:2085: warning: Function parameter or member 'dev_priv' not described in 'intel_cdclk_changed'
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Move cdclk checks to atomic check (rev2)
== Series Details == Series: drm/i915/display: Move cdclk checks to atomic check (rev2) URL : https://patchwork.freedesktop.org/series/97850/ State : success == Summary == CI Bug Log - changes from CI_DRM_11013 -> Patchwork_21873 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/index.html Participating hosts (41 -> 36) -- Additional (2): fi-kbl-soraka fi-icl-u2 Missing(7): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-jsl-2 fi-bdw-samus Known issues Here are the changes found in Patchwork_21873 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +25 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [PASS][4] -> [INCOMPLETE][5] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#1886] / [i915#2291]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][11] -> [INCOMPLETE][12] ([i915#3303]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#109278]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][17] -> [DMESG-WARN][18] ([i915#4269]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-icl-u2:
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Eliminate remnant GEN references
On Thu, 2021-12-16 at 19:41 -0800, Madhumitha Tolakanahalli Pradeep
wrote:
> Replace GEN with DISPLAY_VER, in line with the naming
> convention
> followed in the i915 driver code.
>
> Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> madhumitha.tolakanahalli.prad...@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index a69b28d65a9b..7616a3906b9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -43,9 +43,9 @@
> __stringify(major) "_" \
> __stringify(minor) ".bin"
>
> -#define GEN12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
> +#define DISPLAY_VER13_DMC_MAX_FW_SIZE0x2
>
> -#define GEN13_DMC_MAX_FW_SIZE0x2
> +#define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
Why the order of GEN12/13 and VER12/13 is reversed?
Other than that, LGTM.
-caz
>
> #define ADLP_DMC_PATHDMC_PATH(adlp, 2, 14)
> #define ADLP_DMC_VERSION_REQUIREDDMC_VERSION(2, 14)
> @@ -684,23 +684,23 @@ void intel_dmc_ucode_init(struct
> drm_i915_private *dev_priv)
> if (IS_ALDERLAKE_P(dev_priv)) {
> dmc->fw_path = ADLP_DMC_PATH;
> dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
> - dmc->max_fw_size = GEN13_DMC_MAX_FW_SIZE;
> + dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> } else if (IS_ALDERLAKE_S(dev_priv)) {
> dmc->fw_path = ADLS_DMC_PATH;
> dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
> - dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
> + dmc->max_fw_size = DISPLAY_VER12_DMC_MAX_FW_SIZE;
> } else if (IS_DG1(dev_priv)) {
> dmc->fw_path = DG1_DMC_PATH;
> dmc->required_version = DG1_DMC_VERSION_REQUIRED;
> - dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
> + dmc->max_fw_size = DISPLAY_VER12_DMC_MAX_FW_SIZE;
> } else if (IS_ROCKETLAKE(dev_priv)) {
> dmc->fw_path = RKL_DMC_PATH;
> dmc->required_version = RKL_DMC_VERSION_REQUIRED;
> - dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
> + dmc->max_fw_size = DISPLAY_VER12_DMC_MAX_FW_SIZE;
> } else if (DISPLAY_VER(dev_priv) >= 12) {
> dmc->fw_path = TGL_DMC_PATH;
> dmc->required_version = TGL_DMC_VERSION_REQUIRED;
> - dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
> + dmc->max_fw_size = DISPLAY_VER12_DMC_MAX_FW_SIZE;
> } else if (DISPLAY_VER(dev_priv) == 11) {
> dmc->fw_path = ICL_DMC_PATH;
> dmc->required_version = ICL_DMC_VERSION_REQUIRED;
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Move cdclk checks to atomic check (rev2)
== Series Details == Series: drm/i915/display: Move cdclk checks to atomic check (rev2) URL : https://patchwork.freedesktop.org/series/97850/ State : success == Summary == CI Bug Log - changes from CI_DRM_11013_full -> Patchwork_21873_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21873_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-iclb6/igt@feature_discov...@psr2.html * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-kbl7/igt@gem_cre...@create-massive.html - shard-skl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-skl7/igt@gem_cre...@create-massive.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-glk8/igt@gem_exec_fair@basic-n...@vecs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_huc_copy@huc-copy: - shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-glk9/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - shard-skl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-skl9/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@heavy-verify-random: - shard-kbl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-kbl2/igt@gem_lmem_swapp...@heavy-verify-random.html * igt@gem_lmem_swapping@parallel-multi: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-apl6/igt@gem_lmem_swapp...@parallel-multi.html * igt@gem_render_copy@y-tiled-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#768]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-iclb6/igt@gem_render_c...@y-tiled-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3323]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-kbl7/igt@gem_userptr_bl...@dmabuf-sync.html * igt@i915_pm_dc@dc6-dpms: - shard-skl: NOTRUN -> [FAIL][12] ([i915#454]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-skl9/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-iclb1/igt@i915_pm...@dc6-psr.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: NOTRUN -> [DMESG-WARN][15] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-kbl3/igt@i915_susp...@forcewake.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-kbl1/igt@i915_susp...@forcewake.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][18] ([i915#3743]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-skl4/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html * igt@kms_big_fb@y-tiled-32bpp-rotate-180: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / [i915#1888]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11013/shard-glk1/igt@kms_big...@y-tiled-32bpp-rotate-180.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-glk8/igt@kms_big...@y-tiled-32bpp-rotate-180.html * igt@kms_big_fb@y-tiled-8bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][21] ([fdo#110725] / [fdo#111614]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21873/shard-iclb6/igt@kms_big...@y-tiled-8bpp-rotate-270.html * igt@kms_big_fb@y-tiled-
Re: [Intel-gfx] [PATCH v8 11/16] drm/i915/gem: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:41PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 ++-
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 8 +---
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 15 ---
> .../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 19 ++-
> .../drm/i915/gem/selftests/i915_gem_object.c | 2 +-
> 11 files changed, 42 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index babfecb17ad1..e5b0f66ea1fe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -174,7 +174,7 @@ i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
>
> vm = ctx->vm;
> if (!vm)
> - vm = &ctx->i915->ggtt.vm;
> + vm = &to_gt(ctx->i915)->ggtt->vm;
> vm = i915_vm_get(vm);
>
> return vm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index ec7c4a29a720..3078611d5bfe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1106,7 +1106,7 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
> reloc_cache *cache)
> {
> struct drm_i915_private *i915 =
> container_of(cache, struct i915_execbuffer, reloc_cache)->i915;
> - return &i915->ggtt;
> + return to_gt(i915)->ggtt;
> }
>
> static void reloc_cache_reset(struct reloc_cache *cache, struct
> i915_execbuffer *eb)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 1ca5c062974e..a9effb34d7ed 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -295,7 +295,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> struct drm_device *dev = obj->base.dev;
> struct drm_i915_private *i915 = to_i915(dev);
> struct intel_runtime_pm *rpm = &i915->runtime_pm;
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> bool write = area->vm_flags & VM_WRITE;
> struct i915_gem_ww_ctx ww;
> intel_wakeref_t wakeref;
> @@ -388,16 +388,16 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> assert_rpm_wakelock_held(rpm);
>
> /* Mark as being mmapped into userspace for later revocation */
> - mutex_lock(&i915->ggtt.vm.mutex);
> + mutex_lock(&to_gt(i915)->ggtt->vm.mutex);
> if (!i915_vma_set_userfault(vma) && !obj->userfault_count++)
> - list_add(&obj->userfault_link, &i915->ggtt.userfault_list);
> - mutex_unlock(&i915->ggtt.vm.mutex);
> + list_add(&obj->userfault_link,
> &to_gt(i915)->ggtt->userfault_list);
> + mutex_unlock(&to_gt(i915)->ggtt->vm.mutex);
>
> /* Track the mmo associated with the fenced vma */
> vma->mmo = mmo;
>
> if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
> - intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
> + intel_wakeref_auto(&to_gt(i915)->ggtt->userfault_wakeref,
>
> msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
>
> if (write) {
> @@ -512,7 +512,7 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj)
>* wakeref.
>*/
> wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> - mutex_lock(&i915->ggtt.vm.mutex);
> + mutex_lock(&to_gt(i915)->ggtt->vm.mutex);
>
> if (!obj->userfault_count)
> goto out;
> @@ -530,7 +530,7 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj)
> wmb();
>
> out:
> - mutex_unlock(&i915->ggtt.vm.mutex);
> + mutex_unlock(&to_gt(i915)->ggtt->vm.mutex);
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> }
>
> @@ -733,13 +733,14 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> u32 handle,
> u64 *offset)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> enum i915_mmap_type mmap_type;
>
> if (HAS_LMEM(to_i915(dev)))
> mmap_type = I9
Re: [Intel-gfx] [PATCH v8 12/16] drm/i915/display: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:42PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 8be01b93015f..98319c0322d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -595,7 +595,7 @@ static void ivb_fbc_activate(struct intel_fbc *fbc)
> else if (DISPLAY_VER(i915) == 9)
> skl_fbc_program_cfb_stride(fbc);
>
> - if (i915->ggtt.num_fences)
> + if (to_gt(i915)->ggtt->num_fences)
> snb_fbc_program_fence(fbc);
>
> intel_de_write(i915, ILK_DPFC_CONTROL,
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index adc3a81be9f7..41d279db2be6 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -180,7 +180,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> struct drm_device *dev = helper->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> - struct i915_ggtt *ggtt = &dev_priv->ggtt;
> + struct i915_ggtt *ggtt = to_gt(dev_priv)->ggtt;
> const struct i915_ggtt_view view = {
> .type = I915_GGTT_VIEW_NORMAL,
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 01ce1d72297f..e4186a0b8edb 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -94,7 +94,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> goto err_obj;
> }
>
> - vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
> + vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
> if (IS_ERR(vma))
> goto err_obj;
>
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH v8 13/16] drm/i915/gt: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:43PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +++---
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> 4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 971e737b37b2..ec3b998392ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -89,7 +89,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
>* beyond the end of the batch buffer, across the page boundary,
>* and beyond the end of the GTT if we do not provide a guard.
>*/
> - ret = ggtt_init_hw(&i915->ggtt);
> + ret = ggtt_init_hw(to_gt(i915)->ggtt);
> if (ret)
> return ret;
>
> @@ -725,14 +725,14 @@ int i915_init_ggtt(struct drm_i915_private *i915)
> {
> int ret;
>
> - ret = init_ggtt(&i915->ggtt);
> + ret = init_ggtt(to_gt(i915)->ggtt);
> if (ret)
> return ret;
>
> if (INTEL_PPGTT(i915) == INTEL_PPGTT_ALIASING) {
> - ret = init_aliasing_ppgtt(&i915->ggtt);
> + ret = init_aliasing_ppgtt(to_gt(i915)->ggtt);
> if (ret)
> - cleanup_init_ggtt(&i915->ggtt);
> + cleanup_init_ggtt(to_gt(i915)->ggtt);
> }
>
> return 0;
> @@ -775,7 +775,7 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> */
> void i915_ggtt_driver_release(struct drm_i915_private *i915)
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>
> fini_aliasing_ppgtt(ggtt);
>
> @@ -790,7 +790,7 @@ void i915_ggtt_driver_release(struct drm_i915_private
> *i915)
> */
> void i915_ggtt_driver_late_release(struct drm_i915_private *i915)
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>
> GEM_WARN_ON(kref_read(&ggtt->vm.resv_ref) != 1);
> dma_resv_fini(&ggtt->vm._resv);
> @@ -1232,7 +1232,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
> {
> int ret;
>
> - ret = ggtt_probe_hw(&i915->ggtt, to_gt(i915));
> + ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index f8948de72036..beabf3bc9b75 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -728,8 +728,8 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
> swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> }
>
> - i915->ggtt.bit_6_swizzle_x = swizzle_x;
> - i915->ggtt.bit_6_swizzle_y = swizzle_y;
> + to_gt(i915)->ggtt->bit_6_swizzle_x = swizzle_x;
> + to_gt(i915)->ggtt->bit_6_swizzle_y = swizzle_y;
> }
>
> /*
> @@ -896,7 +896,7 @@ void intel_gt_init_swizzling(struct intel_gt *gt)
> struct intel_uncore *uncore = gt->uncore;
>
> if (GRAPHICS_VER(i915) < 5 ||
> - i915->ggtt.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> + to_gt(i915)->ggtt->bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> return;
>
> intel_uncore_rmw(uncore, DISP_ARB_CTL, 0, DISP_TILE_SURFACE_SWIZZLING);
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> index fde2dcb59809..21215a080088 100644
> --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -15,7 +15,7 @@
> static int init_fake_lmem_bar(struct intel_memory_region *mem)
> {
> struct drm_i915_private *i915 = mem->i915;
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> unsigned long n;
> int ret;
>
> @@ -131,7 +131,7 @@ intel_gt_setup_fake_lmem(struct intel_gt *gt)
> if (!i915->params.fake_lmem_start)
> return ERR_PTR(-ENODEV);
>
> - GEM_BUG_ON(i915_ggtt_has_aperture(&i915->ggtt));
> + GEM_BUG_ON(i915_ggtt_has_aperture(to_gt(i915)->ggtt));
>
> /* Your mappable aperture belongs to me now! */
> mappable_end = pci_resource_len(pdev, 2);
> diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c
> b/drivers/gpu/drm/i915/gt/selftest_reset.c
> index 8a873f6bda7f..37c38bdd5f47 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_reset.c
> +++ b/drivers/gpu/
Re: [Intel-gfx] [PATCH v8 14/16] drm/i915/selftests: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:44PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/selftests/i915_gem.c| 8
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 6 +++---
> drivers/gpu/drm/i915/selftests/i915_request.c| 2 +-
> drivers/gpu/drm/i915/selftests/i915_vma.c| 2 +-
> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index b5576888cd78..1628b81d0a35 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -41,7 +41,7 @@ static int switch_to_context(struct i915_gem_context *ctx)
>
> static void trash_stolen(struct drm_i915_private *i915)
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> const u64 slot = ggtt->error_capture.start;
> const resource_size_t size = resource_size(&i915->dsm);
> unsigned long page;
> @@ -99,7 +99,7 @@ static void igt_pm_suspend(struct drm_i915_private *i915)
> intel_wakeref_t wakeref;
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - i915_ggtt_suspend(&i915->ggtt);
> + i915_ggtt_suspend(to_gt(i915)->ggtt);
> i915_gem_suspend_late(i915);
> }
> }
> @@ -109,7 +109,7 @@ static void igt_pm_hibernate(struct drm_i915_private
> *i915)
> intel_wakeref_t wakeref;
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - i915_ggtt_suspend(&i915->ggtt);
> + i915_ggtt_suspend(to_gt(i915)->ggtt);
>
> i915_gem_freeze(i915);
> i915_gem_freeze_late(i915);
> @@ -125,7 +125,7 @@ static void igt_pm_resume(struct drm_i915_private *i915)
>* that runtime-pm just works.
>*/
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - i915_ggtt_resume(&i915->ggtt);
> + i915_ggtt_resume(to_gt(i915)->ggtt);
> i915_gem_resume(i915);
> }
> }
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 48123c3e1ff0..9afe7cf9d068 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -1122,7 +1122,7 @@ static int exercise_ggtt(struct drm_i915_private *i915,
>u64 hole_start, u64 hole_end,
>unsigned long end_time))
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> u64 hole_start, hole_end, last = 0;
> struct drm_mm_node *node;
> IGT_TIMEOUT(end_time);
> @@ -1182,7 +1182,7 @@ static int igt_ggtt_page(void *arg)
> const unsigned int count = PAGE_SIZE/sizeof(u32);
> I915_RND_STATE(prng);
> struct drm_i915_private *i915 = arg;
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> struct drm_i915_gem_object *obj;
> intel_wakeref_t wakeref;
> struct drm_mm_node tmp;
> @@ -2110,7 +2110,7 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private
> *i915)
> SUBTEST(igt_cs_tlb),
> };
>
> - GEM_BUG_ON(offset_in_page(i915->ggtt.vm.total));
> + GEM_BUG_ON(offset_in_page(to_gt(i915)->ggtt->vm.total));
>
> return i915_subtests(tests, i915);
> }
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index 92a859b34190..7f66f6d299b2 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@ -843,7 +843,7 @@ static struct i915_vma *empty_batch(struct
> drm_i915_private *i915)
>
> intel_gt_chipset_flush(to_gt(i915));
>
> - vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
> + vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
> if (IS_ERR(vma)) {
> err = PTR_ERR(vma);
> goto err;
> diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
> b/drivers/gpu/drm/i915/selftests/i915_vma.c
> index 1f10fe36619b..6ac15d3bc5bc 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> @@ -967,7 +967,7 @@ static int igt_vma_remapped_gtt(void *arg)
> intel_wakeref_t wakeref;
> int err = 0;
>
> - if (!i915_ggtt_has_aperture(&i915->ggtt))
> + if (!i915_ggtt_has_aperture(to_gt(i915)->ggtt))
> return 0;
>
>
Re: [Intel-gfx] [PATCH v8 15/16] drm/i915: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:45PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/i915_driver.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 23 ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
> drivers/gpu/drm/i915/i915_getparam.c | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 4 ++--
> 8 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 8e65cd8258b9..94c3eb1586b0 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -84,7 +84,7 @@ static int vgpu_gem_get_pages(
> kfree(st);
> return ret;
> }
> - gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
> + gtt_entries = (gen8_pte_t __iomem *)to_gt(dev_priv)->ggtt->gsm +
> (fb_info->start >> PAGE_SHIFT);
> for_each_sg(st->sgl, sg, page_num, i) {
> dma_addr_t dma_addr =
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 93c3d154885b..0913daff62d7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -390,9 +390,9 @@ static int i915_swizzle_info(struct seq_file *m, void
> *data)
> intel_wakeref_t wakeref;
>
> seq_printf(m, "bit6 swizzle for X-tiling = %s\n",
> -swizzle_string(dev_priv->ggtt.bit_6_swizzle_x));
> +swizzle_string(to_gt(dev_priv)->ggtt->bit_6_swizzle_x));
> seq_printf(m, "bit6 swizzle for Y-tiling = %s\n",
> -swizzle_string(dev_priv->ggtt.bit_6_swizzle_y));
> +swizzle_string(to_gt(dev_priv)->ggtt->bit_6_swizzle_y));
>
> if (dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
> seq_puts(m, "L-shaped memory detected\n");
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 95174938b160..3c984553d86f 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -571,6 +571,8 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
>
> i915_perf_init(dev_priv);
>
> + intel_gt_init_hw_early(to_gt(dev_priv), &dev_priv->ggtt);
> +
Does moving this call earlier in the function need to happen in patch
#13 rather than here? That patch converts the internals of
i915_ggtt_probe_hw() to use to_gt()->ggtt, but I believe until this
patch that pointer is uninitialized.
Matt
> ret = i915_ggtt_probe_hw(dev_priv);
> if (ret)
> goto err_perf;
> @@ -587,8 +589,6 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
> if (ret)
> goto err_ggtt;
>
> - intel_gt_init_hw_early(to_gt(dev_priv), &dev_priv->ggtt);
> -
> ret = intel_gt_probe_lmem(to_gt(dev_priv));
> if (ret)
> goto err_mem_regions;
> @@ -1146,7 +1146,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>
> /* Must be called before GGTT is suspended. */
> intel_dpt_suspend(dev_priv);
> - i915_ggtt_suspend(&dev_priv->ggtt);
> + i915_ggtt_suspend(to_gt(dev_priv)->ggtt);
>
> i915_save_display(dev_priv);
>
> @@ -1270,7 +1270,7 @@ static int i915_drm_resume(struct drm_device *dev)
> if (ret)
> drm_err(&dev_priv->drm, "failed to re-enable GGTT\n");
>
> - i915_ggtt_resume(&dev_priv->ggtt);
> + i915_ggtt_resume(to_gt(dev_priv)->ggtt);
> /* Must be called after GGTT is resumed. */
> intel_dpt_resume(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 28c1524e2e3b..65724e4df3bd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1762,7 +1762,7 @@ static inline bool
> i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_objec
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
>
> - return i915->ggtt.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17 &&
> + return to_gt(i915)->ggtt->bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17
> &&
> i915_gem_object_is_tiled(obj);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8ba2119092f2..45e3b4c540a1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -88,7 +88,8 @@ int
> i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
>
Re: [Intel-gfx] [PATCH v8 16/16] drm/i915: Remove unused i915->ggtt
On Tue, Dec 14, 2021 at 09:33:46PM +0200, Andi Shyti wrote:
> The reference to the GGTT from the private date is not used
> anymore. Remove it.
You may want to also mention here that tile0's ggtt will now be
dynamically allocated (and auto-deallocated on driver unload by the
drmm_* infrastructure).
Otherwise,
Reviewed-by: Matt Roper
Matt
>
> Suggested-by: Matt Roper
> Signed-off-by: Andi Shyti
> Cc: Michał Winiarski
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 7 +--
> drivers/gpu/drm/i915/gt/intel_gt.h| 2 +-
> drivers/gpu/drm/i915/i915_driver.c| 4 +++-
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 20 ++-
> drivers/gpu/drm/i915/selftests/i915_vma.c | 20 ++-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +++--
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 9 -
> drivers/gpu/drm/i915/selftests/mock_gtt.h | 3 ++-
> 9 files changed, 44 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f98f0fb21efb..298ff32c8d0c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -3,6 +3,7 @@
> * Copyright © 2019 Intel Corporation
> */
>
> +#include
> #include
>
> #include "intel_gt_debugfs.h"
> @@ -85,9 +86,11 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
> return 0;
> }
>
> -void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt)
> +int intel_gt_assign_ggtt(struct intel_gt *gt)
> {
> - gt->ggtt = ggtt;
> + gt->ggtt = drmm_kzalloc(>->i915->drm, sizeof(*gt->ggtt), GFP_KERNEL);
> +
> + return gt->ggtt ? 0 : -ENOMEM;
> }
>
> static const struct intel_mmio_range icl_l3bank_steering_table[] = {
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 3ace129eb2af..94e1bac8c0cc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -36,7 +36,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
> *huc)
>
> void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
> void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private
> *i915);
> -void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt);
> +int intel_gt_assign_ggtt(struct intel_gt *gt);
> int intel_gt_probe_lmem(struct intel_gt *gt);
> int intel_gt_init_mmio(struct intel_gt *gt);
> int __must_check intel_gt_init_hw(struct intel_gt *gt);
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 3c984553d86f..5f2343389b5e 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -571,7 +571,9 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
>
> i915_perf_init(dev_priv);
>
> - intel_gt_init_hw_early(to_gt(dev_priv), &dev_priv->ggtt);
> + ret = intel_gt_assign_ggtt(to_gt(dev_priv));
> + if (ret)
> + goto err_perf;
>
> ret = i915_ggtt_probe_hw(dev_priv);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 65724e4df3bd..8266df3e11ac 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -838,8 +838,6 @@ struct drm_i915_private {
> struct drm_atomic_state *modeset_restore_state;
> struct drm_modeset_acquire_ctx reset_ctx;
>
> - struct i915_ggtt ggtt; /* VM representing the global address space */
> -
> struct i915_gem_mm mm;
>
> /* Kernel Modesetting */
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 9afe7cf9d068..f62f7dac57f2 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -1737,26 +1737,28 @@ int i915_gem_gtt_mock_selftests(void)
> SUBTEST(igt_gtt_insert),
> };
> struct drm_i915_private *i915;
> - struct i915_ggtt *ggtt;
> + struct intel_gt *gt;
> int err;
>
> i915 = mock_gem_device();
> if (!i915)
> return -ENOMEM;
>
> - ggtt = kmalloc(sizeof(*ggtt), GFP_KERNEL);
> - if (!ggtt) {
> - err = -ENOMEM;
> + /* allocate the ggtt */
> + err = intel_gt_assign_ggtt(to_gt(i915));
> + if (err)
> goto out_put;
> - }
> - mock_init_ggtt(i915, ggtt);
>
> - err = i915_subtests(tests, ggtt);
> + gt = to_gt(i915);
> +
> + mock_init_ggtt(gt);
> +
> + err = i915_subtests(tests, gt->ggtt);
>
> mock_device_flush(i915);
> i915_gem_drain_freed_objects(i915);
> - mock_fini_ggtt(ggtt);
> - kfree(ggtt);
> + mock_fini_ggtt(gt->ggtt);
> +
> out_put:
> mock_destroy_device(i915);
> return err;
> diff --git a/drivers/gp
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for More preparation for multi gt patches
On Wed, Dec 15, 2021 at 07:25:17AM +, Patchwork wrote:
> == Series Details ==
>
> Series: More preparation for multi gt patches
> URL : https://patchwork.freedesktop.org/series/98032/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11002_full -> Patchwork_21849_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21849_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21849_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (10 -> 10)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_21849_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_exec_fair@basic-none@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21849/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html
https://gitlab.freedesktop.org/drm/intel/-/issues/2842
>
> * igt@i915_suspend@sysfs-reader:
> - shard-skl: [PASS][2] -> [INCOMPLETE][3]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-skl8/igt@i915_susp...@sysfs-reader.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21849/shard-skl10/igt@i915_susp...@sysfs-reader.html
Looks similar to this ADL-P issue that was seen only once:
https://gitlab.freedesktop.org/drm/intel/-/issues/4092
The first 10 patches have gone through several clean CI cycles now, so
I've pushed those to drm-intel-gt-next. There are just a couple minor
comments on the ggtt patches, so we can push the rest of those once the
comments are addressed.
BTW, there's one i915->gt reference in the display code that has moved
from display/intel_display.c to display/skl_universal_plane.c on
drm-intel-next, but that movement hasn't made its way to
drm-intel-gt-next yet. This led to a merge conflict while rebuilding
drm-tip. I had to use a 'dim cat-to-fixup' to apply the following diff
to the drm-intel-gt-next merge commit:
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 158d89b8d490..b3162f49f341 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1737,7 +1737,7 @@ static bool bo_has_valid_encryption(struct
drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
- return intel_pxp_key_check(&i915->gt.pxp, obj, false) == 0;
+ return intel_pxp_key_check(&to_gt(i915)->pxp, obj, false) == 0;
}
static bool pxp_is_borked(struct drm_i915_gem_object *obj)
Matt
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_21849_full that come from known
> issues:
>
> ### CI changes ###
>
> Issues hit
>
> * boot:
> - shard-snb: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
> [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
> [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
> [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
> [PASS][26], [PASS][27], [PASS][28]) -> ([PASS][29], [PASS][30], [PASS][31],
> [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37],
> [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [FAIL][43],
> [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49],
> [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4338])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb7/boot.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb7/boot.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb7/boot.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb7/boot.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb7/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb7/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb6/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb6/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb6/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb6/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11002/shard-snb5/boot.html
>[15]:
> https://intel-gfx-ci.01
[Intel-gfx] [PATCH] x86/quirks: Fix logic to apply quirk once
When using QFLAG_APPLY_ONCE we make sure the quirk is applied only once.
This is useful when it's enough one device to trigger a certain
condition or when the resource in each that applies is global to the
system rather than local to the device.
However we call the quirk handler based on vendor, class, and device,
allowing the specific handler to do additional filtering. In that case
check_dev_quirk() may incorrectly mark the quirk as applied when it's
not. This is particularly bad for intel_graphics_quirks() that uses
PCI_ANY_ID and then compares with a long list of devices. This hasn't
been problematic so far because those devices are integrated GPUs and
there can only be one in the system. However as Intel starts to
release discrete cards, this condition is no longer true and we fail to
reserve the stolen memory (for the integrated gpu) depending on the bus
topology: if the traversal finds the discrete card first, for which
there is no system stolen memory, we will fail to reserve it for the
integrated card.
This fixes the stolen memory reservation for an Alderlake-P system with
one additional DG2. In this system we have:
- 00:01.0 Bridge
`- 03:00.0 DG2
- Alderklake-P's integrated graphics
Since we do a depth-first traversal, when we call the handler because of
DG2 we were marking it as already being applied and never reserving the
stolen memory for Alderlake-P.
Here we change the quirk fucntions to return bool in case it applied a
quirk so we only flag it as applied when that really happened. This only
makes a difference for quirks using QFLAG_APPLY_ONCE, so all the others
simply returns true in order to avoid unnecessary complication.
Signed-off-by: Lucas De Marchi
---
arch/x86/kernel/early-quirks.c | 75 ++
1 file changed, 49 insertions(+), 26 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 391a4e2b8604..5d235fe2a07a 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -28,7 +28,7 @@
#include
#include
-static void __init fix_hypertransport_config(int num, int slot, int func)
+static bool __init fix_hypertransport_config(int num, int slot, int func)
{
u32 htcfg;
/*
@@ -51,10 +51,10 @@ static void __init fix_hypertransport_config(int num, int
slot, int func)
}
}
-
+ return true;
}
-static void __init via_bugs(int num, int slot, int func)
+static bool __init via_bugs(int num, int slot, int func)
{
#ifdef CONFIG_GART_IOMMU
if ((max_pfn > MAX_DMA32_PFN || force_iommu) &&
@@ -63,8 +63,12 @@ static void __init via_bugs(int num, int slot, int func)
"Looks like a VIA chipset. Disabling IOMMU."
" Override with iommu=allowed\n");
gart_iommu_aperture_disabled = 1;
+
+ return true;
}
#endif
+
+ return false;
}
#ifdef CONFIG_ACPI
@@ -77,7 +81,7 @@ static int __init nvidia_hpet_check(struct acpi_table_header
*header)
#endif /* CONFIG_X86_IO_APIC */
#endif /* CONFIG_ACPI */
-static void __init nvidia_bugs(int num, int slot, int func)
+static bool __init nvidia_bugs(int num, int slot, int func)
{
#ifdef CONFIG_ACPI
#ifdef CONFIG_X86_IO_APIC
@@ -86,7 +90,7 @@ static void __init nvidia_bugs(int num, int slot, int func)
* Nvidia graphics cards with PCI ports on secondary buses.
*/
if (num)
- return;
+ return false;
/*
* All timer overrides on Nvidia are
@@ -96,7 +100,7 @@ static void __init nvidia_bugs(int num, int slot, int func)
* at least allow a command line override.
*/
if (acpi_use_timer_override)
- return;
+ return false;
if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
acpi_skip_timer_override = 1;
@@ -105,11 +109,14 @@ static void __init nvidia_bugs(int num, int slot, int
func)
"timer override.\n");
printk(KERN_INFO "If you got timer trouble "
"try acpi_use_timer_override\n");
+
+ return true;
}
#endif
#endif
/* RED-PEN skip them on mptables too? */
+ return false;
}
#if defined(CONFIG_ACPI) && defined(CONFIG_X86_IO_APIC)
@@ -131,13 +138,13 @@ static u32 __init ati_ixp4x0_rev(int num, int slot, int
func)
return d;
}
-static void __init ati_bugs(int num, int slot, int func)
+static bool __init ati_bugs(int num, int slot, int func)
{
u32 d;
u8 b;
if (acpi_use_timer_override)
- return;
+ return true;
d = ati_ixp4x0_rev(num, slot, func);
if (d < 0x82)
@@ -155,6 +162,8 @@ static void __init ati_bugs(int num, int slot, int func)
printk(KERN_INFO "If you got timer trouble "
"try acpi_use_timer_override\n");
[Intel-gfx] ✓ Fi.CI.BAT: success for x86/quirks: Fix logic to apply quirk once
== Series Details ==
Series: x86/quirks: Fix logic to apply quirk once
URL : https://patchwork.freedesktop.org/series/98200/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11014 -> Patchwork_21874
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/index.html
Participating hosts (41 -> 33)
--
Additional (1): fi-bxt-dsi
Missing(9): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-bsw-n3050 fi-bsw-cyan
bat-adlp-6 fi-pnv-d510 bat-jsl-2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_21874 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live:
- fi-skl-6600u: NOTRUN -> [FAIL][3] ([i915#4547])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-skl-6600u/igt@i915_selft...@live.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bsw-nick:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bsw-nick/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +30 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-nick:NOTRUN -> [SKIP][8] ([fdo#109271]) +62 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bsw-nick/igt@prime_v...@basic-fence-flip.html
* igt@runner@aborted:
- fi-skl-6600u: NOTRUN -> [FAIL][9] ([i915#1436] / [i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-skl-6600u/igt@run...@aborted.html
Possible fixes
* igt@gem_ctx_exec@basic:
- fi-bsw-nick:[DMESG-WARN][10] ([i915#3428]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11014/fi-bsw-nick/igt@gem_ctx_e...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-bsw-nick/igt@gem_ctx_e...@basic.html
* igt@i915_selftest@live@gem_contexts:
- {fi-tgl-dsi}: [INCOMPLETE][12] ([i915#402]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11014/fi-tgl-dsi/igt@i915_selftest@live@gem_contexts.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-tgl-dsi/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@hugepages:
- {fi-tgl-dsi}: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11014/fi-tgl-dsi/igt@i915_selftest@l...@hugepages.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-tgl-dsi/igt@i915_selftest@l...@hugepages.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][16] ([i915#4269]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11014/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21874/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#4269]: https
