[Intel-gfx] ✗ Fi.CI.BAT: failure for Parallel submission aka multi-bb execbuf (rev5)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev5) URL : https://patchwork.freedesktop.org/series/92789/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21241 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21241 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21241, 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_21241/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21241: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-threads: - fi-kbl-7500u: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-kbl-7500u/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-kbl-7500u/igt@gem_close_r...@basic-threads.html - fi-kbl-r: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-kbl-r/igt@gem_close_r...@basic-threads.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-kbl-r/igt@gem_close_r...@basic-threads.html - fi-ivb-3770:[PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-ivb-3770/igt@gem_close_r...@basic-threads.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-ivb-3770/igt@gem_close_r...@basic-threads.html - fi-cml-u2: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-cml-u2/igt@gem_close_r...@basic-threads.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-cml-u2/igt@gem_close_r...@basic-threads.html * igt@gem_render_linear_blits@basic: - fi-kbl-soraka: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-kbl-soraka/igt@gem_render_linear_bl...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-kbl-soraka/igt@gem_render_linear_bl...@basic.html * igt@gem_render_tiled_blits@basic: - fi-hsw-4770:[PASS][11] -> [FAIL][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-hsw-4770/igt@gem_render_tiled_bl...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-hsw-4770/igt@gem_render_tiled_bl...@basic.html * igt@runner@aborted: - fi-ivb-3770:NOTRUN -> [FAIL][13] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-ivb-3770/igt@run...@aborted.html New tests - New tests have been introduced between CI_DRM_10681 and Patchwork_21241: ### New IGT tests (1) ### * igt@i915_selftest@live@guc_multi_lrc: - Statuses : 24 pass(s) - Exec time: [0.42, 3.86] s Known issues Here are the changes found in Patchwork_21241 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([fdo#109315]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][15] ([fdo#109271]) +27 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][16] ([fdo#109315] / [i915#2575]) +16 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][17] ([i915#3718]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-apl-guc: NOTRUN -> [SKIP][18] ([fdo#109271]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][19] ([i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - fi-apl-guc: NOTRUN -> [DMESG-WARN][20] ([i915#1610]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21241/fi-apl-guc/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][21] ([i915#1155]) [21]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v5,01/13] drm/ttm: stop calling tt_swapin in vm_access (rev2)
== Series Details == Series: series starting with [v5,01/13] drm/ttm: stop calling tt_swapin in vm_access (rev2) URL : https://patchwork.freedesktop.org/series/95093/ State : failure == Summary == Applying: drm/ttm: stop calling tt_swapin in vm_access Using index info to reconstruct a base tree... M drivers/gpu/drm/ttm/ttm_bo_vm.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/ttm/ttm_bo_vm.c No changes -- Patch already applied. Applying: drm/ttm: stop setting page->index for the ttm_tt Using index info to reconstruct a base tree... M drivers/gpu/drm/ttm/ttm_bo_vm.c M drivers/gpu/drm/ttm/ttm_tt.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/ttm/ttm_tt.c CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_tt.c Auto-merging drivers/gpu/drm/ttm/ttm_bo_vm.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 drm/ttm: stop setting page->index for the ttm_tt 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 v5 09/13] drm/i915/ttm: add tt shmem backend
Hi Matthew/Thomas,
See one question inline
Regards,
Oak
-Original Message-
From: Intel-gfx On Behalf Of Matthew
Auld
Sent: September 27, 2021 7:41 AM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
; Christian König
Subject: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
For cached objects we can allocate our pages directly in shmem. This should
make it possible(in a later patch) to utilise the existing i915-gem shrinker
code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to check if the object is even still shrinkable; in between us
dropping the shrinker LRU lock and acquiring the object lock it could for
example have been moved. Also we need to differentiate between
"lazy" shrinking and the immediate writeback mode. Also later we need to
handle objects which don't even have mm.pages, so bundling this into
put_pages() would require somehow handling that edge case, hence
just letting the ttm backend handle everything in try_to_writeback
doesn't seem too bad.
v3(Thomas):
- Likely a bad idea to touch the object from the unpopulate hook,
since it's not possible to hold a reference, without also creating
circular dependency, so likely this is too fragile. For now just
ensure we at least mark the pages as dirty/accessed when called from the
shrinker on WILLNEED objects.
- s/try_to_writeback/shrinker_release_pages, since this can do more
than just writeback.
- Get rid of do_backup boolean and just set the SWAPPED flag prior to
calling unpopulate.
- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, since
these just get skipped anyway. We can try to come up with something
better later.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 240 --
5 files changed, 245 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3043fcbd31bd..1c9a1d8d3434 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -601,6 +601,14 @@ int i915_gem_object_wait_migration(struct
drm_i915_gem_object *obj, bool i915_gem_object_placement_possible(struct
drm_i915_gem_object *obj,
enum intel_memory_type type);
+struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region *mr,
+ struct address_space *mapping,
+ unsigned int max_segment);
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup);
+void __shmem_writeback(size_t size, struct address_space *mapping);
+
#ifdef CONFIG_MMU_NOTIFIER
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj) diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index fa2ba9e2a4d0..f0fb17be2f7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -56,6 +56,8 @@ struct drm_i915_gem_object_ops {
struct sg_table *pages);
void (*truncate)(struct drm_i915_gem_object *obj);
void (*writeback)(struct drm_i915_gem_object *obj);
+ int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
+ bool should_writeback);
int (*pread)(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_pread *arg); diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 36b711ae9e28..19e55cc29a15 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -25,8 +25,8 @@ static void check_release_pagevec(struct pagevec *pvec)
cond_resched();
}
-static void shmem_free_st(struct sg_table *st, struct address_space *mapping,
- bool dirty, bool backup)
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup)
{
struct sgt_iter sgt_iter;
struct pagevec pvec;
@@ -52,10 +52,10 @@ static void shmem_free_st(struct sg_table *st, struct
address_space *mapping,
kfree(st);
}
-static struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
- size_t size, struct intel_memory_region
*mr,
-
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Parallel submission aka multi-bb execbuf (rev5)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev5) URL : https://patchwork.freedesktop.org/series/92789/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_stall_reason' not described in 'intel_guc' ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_state' not described in 'intel_guc'
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Parallel submission aka multi-bb execbuf (rev5)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev5) URL : https://patchwork.freedesktop.org/series/92789/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Parallel submission aka multi-bb execbuf (rev5)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev5) URL : https://patchwork.freedesktop.org/series/92789/ State : warning == Summary == $ dim checkpatch origin/drm-tip fc9c9fb6630a drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct fa11631fe33a drm/i915/guc: Take GT PM ref when deregistering context -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects? #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: +#define with_intel_gt_pm(gt, tmp) \ + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ +intel_gt_pm_put(gt), tmp = 0) -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tmp' - possible side-effects? #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: +#define with_intel_gt_pm(gt, tmp) \ + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ +intel_gt_pm_put(gt), tmp = 0) total: 0 errors, 0 warnings, 2 checks, 290 lines checked f26913441370 drm/i915/guc: Take engine PM when a context is pinned with GuC submission 00cd343ff096 drm/i915/guc: Don't call switch_to_kernel_context with GuC submission b94a2d8dd4a6 drm/i915: Add logical engine mapping a352b3260782 drm/i915: Expose logical engine instance to user b00df96b3c7a drm/i915/guc: Introduce context parent-child relationship 4a15247fee14 drm/i915/guc: Add multi-lrc context registration d99a9b87a2b4 drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts 94fb468f6a15 drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids 4fefc07d9141 drm/i915/guc: Implement parallel context pin / unpin functions cce8ed09d2b3 drm/i915/guc: Implement multi-lrc submission -:364: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) #364: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:771: + *wqi++ = child->ring->tail / sizeof(u64); ^ total: 0 errors, 0 warnings, 1 checks, 570 lines checked 1327655fea5c drm/i915/guc: Insert submit fences between requests in parent-child relationship f22df6f9 drm/i915/guc: Implement multi-lrc reset 45f5266f4bc8 drm/i915/guc: Update debugfs for GuC multi-lrc -:23: CHECK:LINE_SPACING: Please don't use multiple blank lines #23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3707: + total: 0 errors, 0 warnings, 1 checks, 67 lines checked 4121bd97a8b5 drm/i915: Fix bug in user proto-context creation that leaked contexts 1a690133eb25 drm/i915/guc: Connect UAPI to GuC multi-lrc interface 2f9e9c7755e0 drm/i915/doc: Update parallel submit doc to point to i915_drm.h -:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #13: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 10 lines checked 77f007a50c5c drm/i915/guc: Add basic GuC multi-lrc selftest -:22: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #22: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 190 lines checked 12e50491ae0d drm/i915/guc: Implement no mid batch preemption for multi-lrc a2d809b95c10 drm/i915: Multi-BB execbuf -:369: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? #369: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1854: +#define for_each_batch_create_order(_eb, _i) \ + for (_i = 0; _i < (_eb)->num_batches; ++_i) -:371: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements should be enclosed in a do - while loop #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: +#define for_each_batch_add_order(_eb, _i) \ + BUILD_BUG_ON(!typecheck(int, _i)); \ + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) -:371: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: +#define for_each_batch_add_order(_eb, _i) \ + BUILD_BUG_ON(!typecheck(int, _i)); \ + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) total: 1 errors, 0 warnings, 2 checks, 1298 lines checked c45d7a15a6cc drm/i915/guc: Handle errors in multi-lrc requests 31ff5626db61 drm/i915: Make request conflict tracking understand parallel submits b73b105b6c29 drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences 54ef99f9936c drm/i915: Enable multi-bb execbuf aef348f7f8e8 drm/i915/execlists: Weak parallel submission support for execlists
Re: [Intel-gfx] [v4] drm/i915/dsi: do not register gmbus if it was reserved for MIPI display
Hi all, could you please share your comments for the latest patch? Thanks!
Best regards,
Shawn
>
>Gmbus driver would setup all Intel i2c GMBuses. But DDC bus may configured as
>gpio and reserved for MIPI driver to control panel power on/off sequence.
>
>Using i2c tool to communicate to peripherals via i2c interface reversed for
>gmbus(DDC). There will be some high/low pulse appear on DDC SCL and SDA (might
>be host sent out i2c slave address). MIPI panel would be impacted due to
>unexpected signal then caused abnormal display or shut down issue.
>
>v2: gmbus driver should not add i2c adapter for DDC interface
>if LFP display was configured to support MIPI panel.
>v3: fix sparse warning
>v4: before gmbus driver add/delete/access i2c adapter would
>call intel_gmbus_is_valid_pin() to know target adapter
>is available or not. Avoid to access unexisting adapter.
>Driver should check DSI status and pin's availability in
>intel_gmbus_is_valid_pin().
>
>Cc: Jani Nikula
>Cc: Vandita Kulkarni
>Cc: Cooper Chiou
>Cc: William Tseng
>Signed-off-by: Lee Shawn C
>---
> drivers/gpu/drm/i915/display/intel_gmbus.c | 18 ++
> 1 file changed, 18 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
>b/drivers/gpu/drm/i915/display/intel_gmbus.c
>index ceb1bf8a8c3c..852e499e2e8c 100644
>--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
>+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
>@@ -118,11 +118,29 @@ static const struct gmbus_pin *get_gmbus_pin(struct
>drm_i915_private *dev_priv,
> return _pins[pin];
> }
>
>+static bool intel_gmbus_ddc_reserve_for_mipi_dsi(struct drm_i915_private
>*dev_priv,
>+ unsigned int pin)
>+{
>+ if (intel_bios_is_dsi_present(dev_priv, NULL)) {
>+ if (DISPLAY_VER(dev_priv) >= 11) {
>+ if ((pin == GMBUS_PIN_2_BXT &&
>dev_priv->vbt.dsi.config->dual_link) ||
>+ pin == GMBUS_PIN_1_BXT) {
>+ return true;
>+ }
>+ }
>+ }
>+
>+ return false;
>+}
>+
> bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
> unsigned int pin)
> {
> unsigned int size;
>
>+ if (intel_gmbus_ddc_reserve_for_mipi_dsi(dev_priv, pin))
>+ return false;
>+
> if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> size = ARRAY_SIZE(gmbus_pins_dg1);
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>--
>2.17.1
>
Re: [Intel-gfx] [Freedreno] [PATCH v3 03/14] drm/hdcp: Update property value on content type and user changes
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to DESIRED while ENABLED. In this case, the
value should be reset immediately to ENABLED since the link is
actively being encrypted.
To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-4-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-4-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-Fixed indentation issue identified by 0-day
---
drivers/gpu/drm/drm_hdcp.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index dd8fa91c51d6..8c851d40cd45 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -487,21 +487,29 @@ bool drm_hdcp_atomic_check(struct drm_connector
*connector,
return true;
/*
-* Nothing to do if content type is unchanged and one of:
-* - state didn't change
+* Content type changes require an HDCP disable/enable cycle.
+*/
+ if (new_conn_state->hdcp_content_type !=
old_conn_state->hdcp_content_type) {
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return true;
+ }
+
+ /*
+* Ignore meaningless state changes:
* - HDCP was activated since the last commit
-* - attempting to set to desired while already enabled
+* - Attempting to set to desired while already enabled
*/
- if (old_hdcp == new_hdcp ||
- (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
- if (old_conn_state->hdcp_content_type ==
- new_conn_state->hdcp_content_type)
- return false;
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ return false;
}
- return true;
+ /* Finally, if state changes, we need action */
+ return old_hdcp != new_hdcp;
}
EXPORT_SYMBOL(drm_hdcp_atomic_check);
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Improve DP link training further (rev3)
== Series Details == Series: drm/i915: Improve DP link training further (rev3) URL : https://patchwork.freedesktop.org/series/95405/ State : failure == Summary == Applying: drm/i915: Tweak the DP "max vswing reached?" condition Applying: drm/i915: Show LTTPR in the TPS debug print Applying: drm/i915: Print the DP vswing adjustment request error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_dp_link_training.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/i915: Print the DP vswing adjustment request 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: failure for Parallel submission aka multi-bb execbuf (rev4)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev4) URL : https://patchwork.freedesktop.org/series/92789/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21239 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21239 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21239, 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_21239/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21239: ### IGT changes ### Possible regressions * igt@gem_render_tiled_blits@basic: - fi-ivb-3770:[PASS][1] -> [FAIL][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-ivb-3770/igt@gem_render_tiled_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-ivb-3770/igt@gem_render_tiled_bl...@basic.html - fi-hsw-4770:[PASS][3] -> [FAIL][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-hsw-4770/igt@gem_render_tiled_bl...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-hsw-4770/igt@gem_render_tiled_bl...@basic.html New tests - New tests have been introduced between CI_DRM_10681 and Patchwork_21239: ### New IGT tests (1) ### * igt@i915_selftest@live@guc_multi_lrc: - Statuses : 29 pass(s) - Exec time: [0.44, 3.89] s Known issues Here are the changes found in Patchwork_21239 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([fdo#109315]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271]) +27 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([fdo#109315] / [i915#2575]) +16 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][8] ([i915#3718]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-apl-guc: NOTRUN -> [SKIP][9] ([fdo#109271]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - fi-apl-guc: NOTRUN -> [DMESG-WARN][11] ([i915#1610]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-apl-guc/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#1155]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][13] -> [INCOMPLETE][14] ([i915#3921]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([i915#4103]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21239/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][18] ([fdo#109285]) [18]:
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Parallel submission aka multi-bb execbuf (rev4)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev4) URL : https://patchwork.freedesktop.org/series/92789/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_stall_reason' not described in 'intel_guc' ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_state' not described in 'intel_guc'
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Parallel submission aka multi-bb execbuf (rev4)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev4) URL : https://patchwork.freedesktop.org/series/92789/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Parallel submission aka multi-bb execbuf (rev4)
== Series Details == Series: Parallel submission aka multi-bb execbuf (rev4) URL : https://patchwork.freedesktop.org/series/92789/ State : warning == Summary == $ dim checkpatch origin/drm-tip e2a47a99bf9d drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct f83d8f1539fa drm/i915/guc: Take GT PM ref when deregistering context -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects? #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: +#define with_intel_gt_pm(gt, tmp) \ + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ +intel_gt_pm_put(gt), tmp = 0) -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tmp' - possible side-effects? #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: +#define with_intel_gt_pm(gt, tmp) \ + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ +intel_gt_pm_put(gt), tmp = 0) total: 0 errors, 0 warnings, 2 checks, 290 lines checked 93e5284929b3 drm/i915/guc: Take engine PM when a context is pinned with GuC submission 4dd6554d994d drm/i915/guc: Don't call switch_to_kernel_context with GuC submission 8629b55f536c drm/i915: Add logical engine mapping 8117ec0a1ca7 drm/i915: Expose logical engine instance to user aa8e1eb4dd4e drm/i915/guc: Introduce context parent-child relationship aaf50eacc2fd drm/i915/guc: Add multi-lrc context registration e5f6f50e66d1 drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts adf21ba138f3 drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids 40ef33318b81 drm/i915/guc: Implement parallel context pin / unpin functions 1ad560c70346 drm/i915/guc: Implement multi-lrc submission -:364: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) #364: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:771: + *wqi++ = child->ring->tail / sizeof(u64); ^ total: 0 errors, 0 warnings, 1 checks, 570 lines checked 466c01457dec drm/i915/guc: Insert submit fences between requests in parent-child relationship 2ece815c1f18 drm/i915/guc: Implement multi-lrc reset 7add5784199f drm/i915/guc: Update debugfs for GuC multi-lrc -:23: CHECK:LINE_SPACING: Please don't use multiple blank lines #23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3707: + total: 0 errors, 0 warnings, 1 checks, 67 lines checked 966991d7bbed drm/i915: Fix bug in user proto-context creation that leaked contexts 0eb3d3bf0c84 drm/i915/guc: Connect UAPI to GuC multi-lrc interface 68c6596b649a drm/i915/doc: Update parallel submit doc to point to i915_drm.h -:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #13: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 10 lines checked 8290f5d15ca2 drm/i915/guc: Add basic GuC multi-lrc selftest -:22: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #22: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 190 lines checked ade3768c42d5 drm/i915/guc: Implement no mid batch preemption for multi-lrc 57882939d788 drm/i915: Multi-BB execbuf -:369: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? #369: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1854: +#define for_each_batch_create_order(_eb, _i) \ + for (_i = 0; _i < (_eb)->num_batches; ++_i) -:371: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements should be enclosed in a do - while loop #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: +#define for_each_batch_add_order(_eb, _i) \ + BUILD_BUG_ON(!typecheck(int, _i)); \ + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) -:371: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: +#define for_each_batch_add_order(_eb, _i) \ + BUILD_BUG_ON(!typecheck(int, _i)); \ + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) total: 1 errors, 0 warnings, 2 checks, 1298 lines checked 28b699ece289 drm/i915/guc: Handle errors in multi-lrc requests 962e6b3dce59 drm/i915: Make request conflict tracking understand parallel submits 368ab12f5205 drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences b52570f01859 drm/i915: Enable multi-bb execbuf 8766155832d7 drm/i915/execlists: Weak parallel submission support for execlists
[Intel-gfx] [PATCH 22/26] drm/i915/guc: Handle errors in multi-lrc requests
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arises because with multi-lrc
breadcrumbs there is a handshake between the parent and children to make
forward progress. If all the requests are not present this handshake
doesn't work. To work around this, if multi-lrc request has an error we
skip the handshake but still emit the breadcrumbs seqno.
v2:
(John Harrison)
- Add comment explaining the skipping of the handshake logic
- Fix typos in the commit message
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 71 ++-
1 file changed, 68 insertions(+), 3 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 83b0d2a114af..05e8b199e4ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4072,8 +4072,8 @@ static int
emit_bb_start_child_no_preempt_mid_batch(struct i915_request *rq,
}
static u32 *
-emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
-u32 *cs)
+__emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
{
struct intel_context *ce = rq->context;
u8 i;
@@ -4101,6 +4101,46 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct
i915_request *rq,
get_children_go_addr(ce),
0);
+ return cs;
+}
+
+/*
+ * If this true, a submission of multi-lrc requests had an error and the
+ * requests need to be skipped. The front end (execuf IOCTL) should've called
+ * i915_request_skip which squashes the BB but we still need to emit the fini
+ * breadrcrumbs seqno write. At this point we don't know how many of the
+ * requests in the multi-lrc submission were generated so we can't do the
+ * handshake between the parent and children (e.g. if 4 requests should be
+ * generated but 2nd hit an error only 1 would be seen by the GuC backend).
+ * Simply skip the handshake, but still emit the breadcrumbd seqno, if an error
+ * has occurred on any of the requests in submission / relationship.
+ */
+static inline bool skip_handshake(struct i915_request *rq)
+{
+ return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, >fence.flags);
+}
+
+static u32 *
+emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
+u32 *cs)
+{
+ struct intel_context *ce = rq->context;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ if (unlikely(skip_handshake(rq))) {
+ /*
+* NOP everything in
+* __emit_fini_breadcrumb_parent_no_preempt_mid_batch, the -6
+* comes of the length emission below.
+*/
+ memset(cs, 0, sizeof(u32) *
+ (ce->engine->emit_fini_breadcrumb_dw - 6));
+ cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ } else {
+ cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
+ }
+
/* Emit fini breadcrumb */
cs = gen8_emit_ggtt_write(cs,
rq->fence.seqno,
@@ -4117,7 +4157,8 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct
i915_request *rq,
}
static u32 *
-emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq, u32
*cs)
+__emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
{
struct intel_context *ce = rq->context;
struct intel_context *parent = intel_context_to_parent(ce);
@@ -4144,6 +4185,30 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct
i915_request *rq, u32 *cs
*cs++ = get_children_go_addr(parent);
*cs++ = 0;
+ return cs;
+}
+
+static u32 *
+emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
+{
+ struct intel_context *ce = rq->context;
+
+ GEM_BUG_ON(!intel_context_is_child(ce));
+
+ if (unlikely(skip_handshake(rq))) {
+ /*
+* NOP everything in
+* __emit_fini_breadcrumb_child_no_preempt_mid_batch, the -6
+* comes from the length the emission below.
+*/
+ memset(cs, 0, sizeof(u32) *
+ (ce->engine->emit_fini_breadcrumb_dw - 6));
+ cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ } else {
+ cs = __emit_fini_breadcrumb_child_no_preempt_mid_batch(rq, cs);
+ }
+
/* Emit fini breadcrumb */
cs = gen8_emit_ggtt_write(cs,
[Intel-gfx] [PATCH 25/26] drm/i915: Enable multi-bb execbuf
Enable multi-bb execbuf by enabling the set_parallel extension. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 6290bc20ccb1..605440388988 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -536,9 +536,6 @@ set_proto_ctx_engines_parallel_submit(struct i915_user_extension __user *base, struct intel_engine_cs **siblings = NULL; intel_engine_mask_t prev_mask; - /* Disabling for now */ - return -ENODEV; - /* FIXME: This is NIY for execlists */ if (!(intel_uc_uses_guc_submission(>gt.uc))) return -ENODEV; -- 2.32.0
[Intel-gfx] [PATCH 26/26] drm/i915/execlists: Weak parallel submission support for execlists
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for the existing (hopefully soon deprecated) bonding interface.
We perma-pin these execlists contexts to align with GuC implementation.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 ++--
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
.../drm/i915/gt/intel_execlists_submission.c | 56 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 -
5 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 605440388988..732111457dd2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -536,10 +536,6 @@ set_proto_ctx_engines_parallel_submit(struct
i915_user_extension __user *base,
struct intel_engine_cs **siblings = NULL;
intel_engine_mask_t prev_mask;
- /* FIXME: This is NIY for execlists */
- if (!(intel_uc_uses_guc_submission(>gt.uc)))
- return -ENODEV;
-
if (get_user(slot, >engine_index))
return -EFAULT;
@@ -549,6 +545,12 @@ set_proto_ctx_engines_parallel_submit(struct
i915_user_extension __user *base,
if (get_user(num_siblings, >num_siblings))
return -EFAULT;
+ if (!intel_uc_uses_guc_submission(>gt.uc) && num_siblings != 1) {
+ drm_dbg(>drm, "Only 1 sibling (%d) supported in non-GuC
mode\n",
+ num_siblings);
+ return -EINVAL;
+ }
+
if (slot >= set->num_engines) {
drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
slot, set->num_engines);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index ee84259959d0..3fc1c5155fd4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -79,7 +79,8 @@ static int intel_context_active_acquire(struct intel_context
*ce)
__i915_active_acquire(>active);
- if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))
+ if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine) ||
+ intel_context_is_parallel(ce))
return 0;
/* Preallocate tracking nodes */
@@ -562,7 +563,6 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
* Callers responsibility to validate that this function is used
* correctly but we use GEM_BUG_ON here ensure that they do.
*/
- GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
GEM_BUG_ON(intel_context_is_pinned(parent));
GEM_BUG_ON(intel_context_is_child(parent));
GEM_BUG_ON(intel_context_is_pinned(child));
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 8d7f571029df..a747fbbf18b5 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -927,8 +927,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
static bool ctx_single_port_submission(const struct intel_context *ce)
{
- return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- intel_context_force_single_submission(ce));
+ return intel_context_force_single_submission(ce);
}
static bool can_merge_ctx(const struct intel_context *prev,
@@ -2598,6 +2597,58 @@ static void execlists_context_cancel_request(struct
intel_context *ce,
current->comm);
}
+static struct intel_context *
+execlists_create_parallel(struct intel_engine_cs **engines,
+ unsigned int num_siblings,
+ unsigned int width)
+{
+ struct intel_engine_cs **siblings = NULL;
+ struct intel_context *parent = NULL, *ce, *err;
+ int i, j;
+
+ GEM_BUG_ON(num_siblings != 1);
+
+ siblings = kmalloc_array(num_siblings,
+sizeof(*siblings),
+GFP_KERNEL);
+ if (!siblings)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < width; ++i) {
+ for (j = 0; j < num_siblings; ++j)
+ siblings[j] = engines[i * num_siblings + j];
+
+ ce = intel_context_create(siblings[0]);
+ if (!ce) {
+ err = ERR_PTR(-ENOMEM);
+ goto unwind;
+ }
+
+ if (i == 0)
+ parent = ce;
+ else
+
[Intel-gfx] [PATCH 20/26] drm/i915/guc: Implement no mid batch preemption for multi-lrc
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by
default if a context is configured by set parallel extension.
v2:
(John Harrison)
- Fix a few comments wording
- Add struture for parent page layout
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 330 +-
4 files changed, 324 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 3b340eb59ada..ee84259959d0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -569,7 +569,7 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
GEM_BUG_ON(intel_context_is_child(child));
GEM_BUG_ON(intel_context_is_parent(child));
- parent->parallel.number_children++;
+ parent->parallel.child_index = parent->parallel.number_children++;
list_add_tail(>parallel.child_link,
>parallel.child_list);
child->parallel.parent = parent;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 1d880303a7e4..95a5b94b4ece 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -250,6 +250,8 @@ struct intel_context {
struct i915_request *last_rq;
/** @number_children: number of children if parent */
u8 number_children;
+ /** @child_index: index into child_list if child */
+ u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
/** @wqi_head: head pointer in work queue */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index a00eeddc1449..663950d3badc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -181,7 +181,7 @@ struct guc_process_desc {
u32 wq_status;
u32 engine_presence;
u32 priority;
- u32 reserved[30];
+ u32 reserved[36];
} __packed;
#define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
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 12ee8ca76249..f28e36aa77c2 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_gpu_commands.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
#include "gt/intel_gt_pm.h"
@@ -368,10 +369,16 @@ static inline struct i915_priolist *to_priolist(struct
rb_node *rb)
/*
* When using multi-lrc submission an extra page in the context state is
- * reserved for the process descriptor and work queue.
+ * reserved for the process descriptor, work queue, and handshake between the
+ * parent + childlren contexts to insert safe preemption points between each
set
+ * of BBs.
*
* The layout of this page is below:
* 0 guc_process_desc
+ * + sizeof(struct guc_process_desc) child go
+ * + CACHELINE_BYTES child join[0]
+ * ...
+ * + CACHELINE_BYTES child join[n - 1]
* ... unused
* PAGE_SIZE / 2 work queue start
* ... work queue
@@ -379,7 +386,25 @@ static inline struct i915_priolist *to_priolist(struct
rb_node *rb)
*/
#define WQ_SIZE(PAGE_SIZE / 2)
#define WQ_OFFSET (PAGE_SIZE - WQ_SIZE)
-static u32 __get_process_desc_offset(struct intel_context *ce)
+
+struct parent_page {
+ struct guc_process_desc pdesc;
+
+ u32 child_go_memory;
+ u8 unused0[CACHELINE_BYTES - sizeof(u32)];
+
+ struct {
+ u32 child_join_memory;
+ u8 unused1[CACHELINE_BYTES - sizeof(u32)];
+ } join[MAX_ENGINE_INSTANCE + 1];
+
+ u8 unused2[(WQ_OFFSET - sizeof(struct guc_process_desc) -
+ CACHELINE_BYTES * (MAX_ENGINE_INSTANCE + 2))];
+
+ u32 wq[WQ_SIZE / sizeof(u32)];
+};
+
+static u32 __get_parent_page_offset(struct intel_context *ce)
{
GEM_BUG_ON(!ce->parallel.guc.parent_page);
@@ -388,23 +413,35 @@ static u32 __get_process_desc_offset(struct intel_context
*ce)
static u32
[Intel-gfx] [PATCH 19/26] drm/i915/guc: Add basic GuC multi-lrc selftest
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 179 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 181 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
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 9b19e0d830a2..12ee8ca76249 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3957,4 +3957,5 @@ bool intel_guc_virtual_engine_has_heartbeat(const struct
intel_engine_cs *ve)
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_guc.c"
+#include "selftest_guc_multi_lrc.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
new file mode 100644
index ..50953c8e8b53
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright �� 2019 Intel Corporation
+ */
+
+#include "selftests/igt_spinner.h"
+#include "selftests/igt_reset.h"
+#include "selftests/intel_scheduler_helpers.h"
+#include "gt/intel_engine_heartbeat.h"
+#include "gem/selftests/mock_context.h"
+
+static void logical_sort(struct intel_engine_cs **engines, int num_engines)
+{
+ struct intel_engine_cs *sorted[MAX_ENGINE_INSTANCE + 1];
+ int i, j;
+
+ for (i = 0; i < num_engines; ++i)
+ for (j = 0; j < MAX_ENGINE_INSTANCE + 1; ++j) {
+ if (engines[j]->logical_mask & BIT(i)) {
+ sorted[i] = engines[j];
+ break;
+ }
+ }
+
+ memcpy(*engines, *sorted,
+ sizeof(struct intel_engine_cs *) * num_engines);
+}
+
+static struct intel_context *
+multi_lrc_create_parent(struct intel_gt *gt, u8 class,
+ unsigned long flags)
+{
+ struct intel_engine_cs *siblings[MAX_ENGINE_INSTANCE + 1];
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int i = 0;
+
+ for_each_engine(engine, gt, id) {
+ if (engine->class != class)
+ continue;
+
+ siblings[i++] = engine;
+ }
+
+ if (i <= 1)
+ return ERR_PTR(0);
+
+ logical_sort(siblings, i);
+
+ return intel_engine_create_parallel(siblings, 1, i);
+}
+
+static void multi_lrc_context_unpin(struct intel_context *ce)
+{
+ struct intel_context *child;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ for_each_child(ce, child)
+ intel_context_unpin(child);
+ intel_context_unpin(ce);
+}
+
+static void multi_lrc_context_put(struct intel_context *ce)
+{
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ /*
+* Only the parent gets the creation ref put in the uAPI, the parent
+* itself is responsible for creation ref put on the children.
+*/
+ intel_context_put(ce);
+}
+
+static struct i915_request *
+multi_lrc_nop_request(struct intel_context *ce)
+{
+ struct intel_context *child;
+ struct i915_request *rq, *child_rq;
+ int i = 0;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return rq;
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ for_each_child(ce, child) {
+ child_rq = intel_context_create_request(child);
+ if (IS_ERR(child_rq))
+ goto child_error;
+
+ if (++i == ce->parallel.number_children)
+ set_bit(I915_FENCE_FLAG_SUBMIT_PARALLEL,
+ _rq->fence.flags);
+ i915_request_add(child_rq);
+ }
+
+ return rq;
+
+child_error:
+ i915_request_put(rq);
+
+ return ERR_PTR(-ENOMEM);
+}
+
+static int __intel_guc_multi_lrc_basic(struct intel_gt *gt, unsigned int class)
+{
+ struct intel_context *parent;
+ struct i915_request *rq;
+ int ret;
+
+ parent = multi_lrc_create_parent(gt, class, 0);
+ if (IS_ERR(parent)) {
+ pr_err("Failed creating contexts: %ld", PTR_ERR(parent));
+ return PTR_ERR(parent);
+ } else if (!parent) {
+ pr_debug("Not enough engines in class: %d", class);
+ return 0;
+ }
+
+ rq = multi_lrc_nop_request(parent);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ pr_err("Failed creating requests: %d", ret);
+ goto out;
+ }
+
+ ret = intel_selftest_wait_for_rq(rq);
+ if (ret)
+ pr_err("Failed waiting on request: %d",
[Intel-gfx] [PATCH 15/26] drm/i915/guc: Update debugfs for GuC multi-lrc
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
v2:
(John Harrison)
- Output number children in debugfs
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 53 ++-
1 file changed, 39 insertions(+), 14 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 d661a69ef4f7..f69e984683aa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3704,6 +3704,26 @@ static inline void guc_log_context_priority(struct
drm_printer *p,
drm_printf(p, "\n");
}
+
+static inline void guc_log_context(struct drm_printer *p,
+ struct intel_context *ce)
+{
+ drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
+ drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
+ drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
+ ce->ring->head,
+ ce->lrc_reg_state[CTX_RING_HEAD]);
+ drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
+ ce->ring->tail,
+ ce->lrc_reg_state[CTX_RING_TAIL]);
+ drm_printf(p, "\t\tContext Pin Count: %u\n",
+ atomic_read(>pin_count));
+ drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
+ atomic_read(>guc_id.ref));
+ drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
+ ce->guc_state.sched_state);
+}
+
void intel_guc_submission_print_context_info(struct intel_guc *guc,
struct drm_printer *p)
{
@@ -3713,22 +3733,27 @@ void intel_guc_submission_print_context_info(struct
intel_guc *guc,
xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
- drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
- drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
- drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
- ce->ring->head,
- ce->lrc_reg_state[CTX_RING_HEAD]);
- drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
- ce->ring->tail,
- ce->lrc_reg_state[CTX_RING_TAIL]);
- drm_printf(p, "\t\tContext Pin Count: %u\n",
- atomic_read(>pin_count));
- drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
- atomic_read(>guc_id.ref));
- drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
- ce->guc_state.sched_state);
+ GEM_BUG_ON(intel_context_is_child(ce));
+ guc_log_context(p, ce);
guc_log_context_priority(p, ce);
+
+ if (intel_context_is_parent(ce)) {
+ struct guc_process_desc *desc = __get_process_desc(ce);
+ struct intel_context *child;
+
+ drm_printf(p, "\t\tNumber children: %u\n",
+ ce->parallel.number_children);
+ drm_printf(p, "\t\tWQI Head: %u\n",
+ READ_ONCE(desc->head));
+ drm_printf(p, "\t\tWQI Tail: %u\n",
+ READ_ONCE(desc->tail));
+ drm_printf(p, "\t\tWQI Status: %u\n\n",
+ READ_ONCE(desc->wq_status));
+
+ for_each_child(ce, child)
+ guc_log_context(p, child);
+ }
}
xa_unlock_irqrestore(>context_lookup, flags);
}
--
2.32.0
[Intel-gfx] [PATCH 17/26] drm/i915/guc: Connect UAPI to GuC multi-lrc interface
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Daniel Vetter)
- Add IGT link and placeholder for media UMD link
v3:
(Kernel test robot)
- Fix warning in unpin engines call
(John Harrison)
- Reword a bunch of the kernel doc
Cc: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 221 +-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 6 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +-
drivers/gpu/drm/i915/gt/intel_engine.h| 12 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
.../drm/i915/gt/intel_execlists_submission.c | 6 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 -
include/uapi/drm/i915_drm.h | 131 +++
9 files changed, 489 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8c7ea6e56262..6290bc20ccb1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -522,9 +522,150 @@ set_proto_ctx_engines_bond(struct i915_user_extension
__user *base, void *data)
return 0;
}
+static int
+set_proto_ctx_engines_parallel_submit(struct i915_user_extension __user *base,
+ void *data)
+{
+ struct i915_context_engines_parallel_submit __user *ext =
+ container_of_user(base, typeof(*ext), base);
+ const struct set_proto_ctx_engines *set = data;
+ struct drm_i915_private *i915 = set->i915;
+ u64 flags;
+ int err = 0, n, i, j;
+ u16 slot, width, num_siblings;
+ struct intel_engine_cs **siblings = NULL;
+ intel_engine_mask_t prev_mask;
+
+ /* Disabling for now */
+ return -ENODEV;
+
+ /* FIXME: This is NIY for execlists */
+ if (!(intel_uc_uses_guc_submission(>gt.uc)))
+ return -ENODEV;
+
+ if (get_user(slot, >engine_index))
+ return -EFAULT;
+
+ if (get_user(width, >width))
+ return -EFAULT;
+
+ if (get_user(num_siblings, >num_siblings))
+ return -EFAULT;
+
+ if (slot >= set->num_engines) {
+ drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
+ slot, set->num_engines);
+ return -EINVAL;
+ }
+
+ if (set->engines[slot].type != I915_GEM_ENGINE_TYPE_INVALID) {
+ drm_dbg(>drm,
+ "Invalid placement[%d], already occupied\n", slot);
+ return -EINVAL;
+ }
+
+ if (get_user(flags, >flags))
+ return -EFAULT;
+
+ if (flags) {
+ drm_dbg(>drm, "Unknown flags 0x%02llx", flags);
+ return -EINVAL;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ext->mbz64); n++) {
+ err = check_user_mbz(>mbz64[n]);
+ if (err)
+ return err;
+ }
+
+ if (width < 2) {
+ drm_dbg(>drm, "Width (%d) < 2\n", width);
+ return -EINVAL;
+ }
+
+ if (num_siblings < 1) {
+ drm_dbg(>drm, "Number siblings (%d) < 1\n",
+ num_siblings);
+ return -EINVAL;
+ }
+
+ siblings = kmalloc_array(num_siblings * width,
+sizeof(*siblings),
+GFP_KERNEL);
+ if (!siblings)
+ return -ENOMEM;
+
+ /* Create contexts / engines */
+ for (i = 0; i < width; ++i) {
+ intel_engine_mask_t current_mask = 0;
+ struct i915_engine_class_instance prev_engine;
+
+ for (j = 0; j < num_siblings; ++j) {
+ struct i915_engine_class_instance ci;
+
+ n = i * num_siblings + j;
+ if (copy_from_user(, >engines[n], sizeof(ci))) {
+ err = -EFAULT;
+ goto out_err;
+ }
+
+ siblings[n] =
+ intel_engine_lookup_user(i915, ci.engine_class,
+ci.engine_instance);
+ if (!siblings[n]) {
+ drm_dbg(>drm,
+ "Invalid sibling[%d]: { class:%d,
inst:%d }\n",
+ n, ci.engine_class, ci.engine_instance);
+ err = -EINVAL;
+ goto out_err;
+ }
+
+ if (n) {
+ if (prev_engine.engine_class !=
+
[Intel-gfx] [PATCH 21/26] drm/i915: Multi-BB execbuf
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops. First a loop is used to find
all the batches, a loop to pin all the HW contexts, a loop to create all
the requests, a loop to submit (emit BB start, etc...) all the requests,
a loop to tie the requests to the VMAs they touch, and finally a loop to
commit the requests to the backend.
A composite fence is also created for the generated requests to return
to the user and to stick in dma resv slots.
No behavior from the existing IOCTL should be changed aside from when
throttling because the ring for a context is full, wait on the request
while holding the object locks.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Matthew Brost)
- Return proper error value if i915_request_create fails
v3:
(John Harrison)
- Add comment explaining create / add order loops + locking
- Update commit message explaining different in IOCTL behavior
- Line wrap some comments
- eb_add_request returns void
- Return -EINVAL rather triggering BUG_ON if cmd parser used
(Checkpatch)
- Check eb->batch_len[*current_batch]
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 793 --
drivers/gpu/drm/i915/gt/intel_context.h | 8 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 10 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +
drivers/gpu/drm/i915/i915_request.h | 9 +
drivers/gpu/drm/i915/i915_vma.c | 21 +-
drivers/gpu/drm/i915/i915_vma.h | 13 +-
7 files changed, 599 insertions(+), 257 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2f2434b52317..5c7fb6f68bbb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -244,17 +244,25 @@ struct i915_execbuffer {
struct drm_i915_gem_exec_object2 *exec; /** ioctl execobj[] */
struct eb_vma *vma;
- struct intel_engine_cs *engine; /** engine to queue the request to */
+ struct intel_gt *gt; /* gt for the execbuf */
struct intel_context *context; /* logical state for the request */
struct i915_gem_context *gem_context; /** caller's context */
- struct i915_request *request; /** our request to build */
- struct eb_vma *batch; /** identity of the batch obj/vma */
+ /** our requests to build */
+ struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
+ /** identity of the batch obj/vma */
+ struct eb_vma *batches[MAX_ENGINE_INSTANCE + 1];
struct i915_vma *trampoline; /** trampoline used for chaining */
+ /** used for excl fence in dma_resv objects when > 1 BB submitted */
+ struct dma_fence *composite_fence;
+
/** actual size of execobj[] as we may extend it for the cmdparser */
unsigned int buffer_count;
+ /* number of batches in execbuf IOCTL */
+ unsigned int num_batches;
+
/** list of vma not yet bound during reservation phase */
struct list_head unbound;
@@ -281,7 +289,8 @@ struct i915_execbuffer {
u64 invalid_flags; /** Set of execobj.flags that are invalid */
- u64 batch_len; /** Length of batch within object */
+ /** Length of batch within object */
+ u64 batch_len[MAX_ENGINE_INSTANCE + 1];
u32 batch_start_offset; /** Location within object of batch */
u32 batch_flags; /** Flags composed for emit_bb_start() */
struct intel_gt_buffer_pool_node *batch_pool; /** pool node for batch
buffer */
@@ -299,14 +308,13 @@ struct i915_execbuffer {
};
static int eb_parse(struct i915_execbuffer *eb);
-static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
- bool throttle);
+static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle);
static void eb_unpin_engine(struct i915_execbuffer *eb);
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
- return intel_engine_requires_cmd_parser(eb->engine) ||
- (intel_engine_using_cmd_parser(eb->engine) &&
+ return intel_engine_requires_cmd_parser(eb->context->engine) ||
+ (intel_engine_using_cmd_parser(eb->context->engine) &&
eb->args->batch_len);
}
@@ -544,11 +552,21 @@ eb_validate_vma(struct i915_execbuffer *eb,
return 0;
}
-static void
+static inline bool
+is_batch_buffer(struct i915_execbuffer *eb, unsigned int buffer_idx)
+{
+ return eb->args->flags & I915_EXEC_BATCH_FIRST ?
+ buffer_idx < eb->num_batches :
+ buffer_idx >= eb->args->buffer_count - eb->num_batches;
+}
[Intel-gfx] [PATCH 18/26] drm/i915/doc: Update parallel submit doc to point to i915_drm.h
Update parallel submit doc to point to i915_drm.h
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 --
Documentation/gpu/rfc/i915_scheduler.rst | 4 +-
2 files changed, 2 insertions(+), 124 deletions(-)
delete mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
deleted file mode 100644
index 8cbe2c4e0172..
--- a/Documentation/gpu/rfc/i915_parallel_execbuf.h
+++ /dev/null
@@ -1,122 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2021 Intel Corporation
- */
-
-#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
i915_context_engines_parallel_submit */
-
-/**
- * struct drm_i915_context_engines_parallel_submit - Configure engine for
- * parallel submission.
- *
- * Setup a slot in the context engine map to allow multiple BBs to be submitted
- * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the
GPU
- * in parallel. Multiple hardware contexts are created internally in the i915
- * run these BBs. Once a slot is configured for N BBs only N BBs can be
- * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user
- * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how
- * many BBs there are based on the slot's configuration. The N BBs are the last
- * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set.
- *
- * The default placement behavior is to create implicit bonds between each
- * context if each context maps to more than 1 physical engine (e.g. context is
- * a virtual engine). Also we only allow contexts of same engine class and
these
- * contexts must be in logically contiguous order. Examples of the placement
- * behavior described below. Lastly, the default is to not allow BBs to
- * preempted mid BB rather insert coordinated preemption on all hardware
- * contexts between each set of BBs. Flags may be added in the future to change
- * both of these default behaviors.
- *
- * Returns -EINVAL if hardware context placement configuration is invalid or if
- * the placement configuration isn't supported on the platform / submission
- * interface.
- * Returns -ENODEV if extension isn't supported on the platform / submission
- * interface.
- *
- * .. code-block:: none
- *
- * Example 1 pseudo code:
- * CS[X] = generic engine of same class, logical instance X
- * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
- * set_engines(INVALID)
- * set_parallel(engine_index=0, width=2, num_siblings=1,
- * engines=CS[0],CS[1])
- *
- * Results in the following valid placement:
- * CS[0], CS[1]
- *
- * Example 2 pseudo code:
- * CS[X] = generic engine of same class, logical instance X
- * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
- * set_engines(INVALID)
- * set_parallel(engine_index=0, width=2, num_siblings=2,
- * engines=CS[0],CS[2],CS[1],CS[3])
- *
- * Results in the following valid placements:
- * CS[0], CS[1]
- * CS[2], CS[3]
- *
- * This can also be thought of as 2 virtual engines described by 2-D array
- * in the engines the field with bonds placed between each index of the
- * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to
- * CS[3].
- * VE[0] = CS[0], CS[2]
- * VE[1] = CS[1], CS[3]
- *
- * Example 3 pseudo code:
- * CS[X] = generic engine of same class, logical instance X
- * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
- * set_engines(INVALID)
- * set_parallel(engine_index=0, width=2, num_siblings=2,
- * engines=CS[0],CS[1],CS[1],CS[3])
- *
- * Results in the following valid and invalid placements:
- * CS[0], CS[1]
- * CS[1], CS[3] - Not logical contiguous, return -EINVAL
- */
-struct drm_i915_context_engines_parallel_submit {
- /**
-* @base: base user extension.
-*/
- struct i915_user_extension base;
-
- /**
-* @engine_index: slot for parallel engine
-*/
- __u16 engine_index;
-
- /**
-* @width: number of contexts per parallel engine
-*/
- __u16 width;
-
- /**
-* @num_siblings: number of siblings per context
-*/
- __u16 num_siblings;
-
- /**
-* @mbz16: reserved for future use; must be zero
-*/
- __u16 mbz16;
-
- /**
-* @flags: all undefined flags must be zero, currently not defined flags
-*/
- __u64 flags;
-
- /**
-* @mbz64: reserved for future use; must be zero
-*/
- __u64 mbz64[3];
-
- /**
-* @engines: 2-d array of engine instances to configure parallel engine
-*
-* length = width (i) * num_siblings (j)
-* index = j + i *
[Intel-gfx] [PATCH 23/26] drm/i915: Make request conflict tracking understand parallel submits
If an object in the excl or shared slot is a composite fence from a
parallel submit and the current request in the conflict tracking is from
the same parallel context there is no need to enforce ordering as the
ordering already implicit. Make the request conflict tracking understand
this by comparing the parents parallel fence values and skipping the
conflict insertion if the values match.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_request.c | 43 +++--
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e9bfa32f9270..cf89624020ad 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1325,6 +1325,25 @@ i915_request_await_external(struct i915_request *rq,
struct dma_fence *fence)
return err;
}
+static inline bool is_parallel_rq(struct i915_request *rq)
+{
+ return intel_context_is_parallel(rq->context);
+}
+
+static inline struct intel_context *request_to_parent(struct i915_request *rq)
+{
+ return intel_context_to_parent(rq->context);
+}
+
+static bool is_same_parallel_context(struct i915_request *to,
+struct i915_request *from)
+{
+ if (is_parallel_rq(to))
+ return request_to_parent(to) == request_to_parent(from);
+
+ return false;
+}
+
int
i915_request_await_execution(struct i915_request *rq,
struct dma_fence *fence)
@@ -1356,11 +1375,14 @@ i915_request_await_execution(struct i915_request *rq,
* want to run our callback in all cases.
*/
- if (dma_fence_is_i915(fence))
+ if (dma_fence_is_i915(fence)) {
+ if (is_same_parallel_context(rq, to_request(fence)))
+ continue;
ret = __i915_request_await_execution(rq,
to_request(fence));
- else
+ } else {
ret = i915_request_await_external(rq, fence);
+ }
if (ret < 0)
return ret;
} while (--nchild);
@@ -1461,10 +1483,13 @@ i915_request_await_dma_fence(struct i915_request *rq,
struct dma_fence *fence)
fence))
continue;
- if (dma_fence_is_i915(fence))
+ if (dma_fence_is_i915(fence)) {
+ if (is_same_parallel_context(rq, to_request(fence)))
+ continue;
ret = i915_request_await_request(rq, to_request(fence));
- else
+ } else {
ret = i915_request_await_external(rq, fence);
+ }
if (ret < 0)
return ret;
@@ -1539,16 +1564,6 @@ i915_request_await_object(struct i915_request *to,
return ret;
}
-static inline bool is_parallel_rq(struct i915_request *rq)
-{
- return intel_context_is_parallel(rq->context);
-}
-
-static inline struct intel_context *request_to_parent(struct i915_request *rq)
-{
- return intel_context_to_parent(rq->context);
-}
-
static struct i915_request *
__i915_request_ensure_parallel_ordering(struct i915_request *rq,
struct intel_timeline *timeline)
--
2.32.0
[Intel-gfx] [PATCH 24/26] drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences
Parallel submission create composite fences (dma_fence_array) for excl /
shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
determine the busyness of the object. Prior to patch it only check if
the fence in the slot was a i915_request. Update the check to understand
composite fences and correctly report the busyness.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 60 +++
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 5 +-
drivers/gpu/drm/i915/i915_request.h | 6 ++
3 files changed, 58 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 6234e17259c1..b89d173c62eb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -4,6 +4,8 @@
* Copyright © 2014-2016 Intel Corporation
*/
+#include
+
#include "gt/intel_engine.h"
#include "i915_gem_ioctls.h"
@@ -36,7 +38,7 @@ static __always_inline u32 __busy_write_id(u16 id)
}
static __always_inline unsigned int
-__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u16 id))
+__busy_set_if_active(struct dma_fence *fence, u32 (*flag)(u16 id))
{
const struct i915_request *rq;
@@ -46,29 +48,63 @@ __busy_set_if_active(const struct dma_fence *fence, u32
(*flag)(u16 id))
* to eventually flush us, but to minimise latency just ask the
* hardware.
*
-* Note we only report on the status of native fences.
+* Note we only report on the status of native fences and we currently
+* have two native fences:
+*
+* 1. A composite fence (dma_fence_array) constructed of i915 requests
+* created during a parallel submission. In this case we deconstruct the
+* composite fence into individual i915 requests and check the status of
+* each request.
+*
+* 2. A single i915 request.
*/
- if (!dma_fence_is_i915(fence))
+ if (dma_fence_is_array(fence)) {
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+ struct dma_fence **child = array->fences;
+ unsigned int nchild = array->num_fences;
+
+ do {
+ struct dma_fence *current_fence = *child++;
+
+ /* Not an i915 fence, can't be busy per above */
+ if (!dma_fence_is_i915(current_fence) ||
+ !test_bit(I915_FENCE_FLAG_COMPOSITE,
+ _fence->flags)) {
+ return 0;
+ }
+
+ rq = to_request(current_fence);
+ if (!i915_request_completed(rq)) {
+ BUILD_BUG_ON(!typecheck(u16,
+
rq->engine->uabi_class));
+ return flag(rq->engine->uabi_class);
+ }
+ } while (--nchild);
+
+ /* All requests in array complete, not busy */
return 0;
+ } else {
+ if (!dma_fence_is_i915(fence))
+ return 0;
- /* opencode to_request() in order to avoid const warnings */
- rq = container_of(fence, const struct i915_request, fence);
- if (i915_request_completed(rq))
- return 0;
+ rq = to_request(fence);
+ if (i915_request_completed(rq))
+ return 0;
- /* Beware type-expansion follies! */
- BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
- return flag(rq->engine->uabi_class);
+ /* Beware type-expansion follies! */
+ BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
+ return flag(rq->engine->uabi_class);
+ }
}
static __always_inline unsigned int
-busy_check_reader(const struct dma_fence *fence)
+busy_check_reader(struct dma_fence *fence)
{
return __busy_set_if_active(fence, __busy_read_flag);
}
static __always_inline unsigned int
-busy_check_writer(const struct dma_fence *fence)
+busy_check_writer(struct dma_fence *fence)
{
if (!fence)
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 5c7fb6f68bbb..16276f406fd6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2988,8 +2988,11 @@ eb_composite_fence_create(struct i915_execbuffer *eb,
int out_fence_fd)
if (!fences)
return ERR_PTR(-ENOMEM);
- for_each_batch_create_order(eb, i)
+ for_each_batch_create_order(eb, i) {
fences[i] = >requests[i]->fence;
+ __set_bit(I915_FENCE_FLAG_COMPOSITE,
+ >requests[i]->fence.flags);
+ }
[Intel-gfx] [PATCH 04/26] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission
Calling switch_to_kernel_context isn't needed if the engine PM reference is taken while all user contexts are pinned as if don't have PM ref that guarantees that all user contexts scheduling is disabled. By not calling switch_to_kernel_context we save on issuing a request to the engine. v2: (Daniel Vetter) - Add FIXME comment about pushing switch_to_kernel_context to backend v3: (John Harrison) - Update commit message - Fix workding comment Signed-off-by: Matthew Brost Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c index dacd62773735..a1334b48dde7 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c @@ -162,6 +162,19 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine) unsigned long flags; bool result = true; + /* +* This is execlist specific behaviour intended to ensure the GPU is +* idle by switching to a known 'safe' context. With GuC submission, the +* same idle guarantee is achieved by other means (disabling +* scheduling). Further, switching to a 'safe' context has no effect +* with GuC submission as the scheduler can just switch back again. +* +* FIXME: Move this backend scheduler specific behaviour into the +* scheduler backend. +*/ + if (intel_engine_uses_guc(engine)) + return true; + /* GPU is pointing to the void, as good as in the kernel context. */ if (intel_gt_is_wedged(engine->gt)) return true; -- 2.32.0
[Intel-gfx] [PATCH 01/26] drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct
Move guc_id allocation under submission state sub-struct as a future
patch will reuse the spin lock as a global submission state lock. Moving
this into sub-struct makes ownership of fields / lock clear.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 26 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 ++-
3 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 12252c411159..e7e3984aab78 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -197,18 +197,18 @@ struct intel_context {
struct {
/**
* @id: handle which is used to uniquely identify this context
-* with the GuC, protected by guc->contexts_lock
+* with the GuC, protected by guc->submission_state.lock
*/
u16 id;
/**
* @ref: the number of references to the guc_id, when
* transitioning in and out of zero protected by
-* guc->contexts_lock
+* guc->submission_state.lock
*/
atomic_t ref;
/**
* @link: in guc->guc_id_list when the guc_id has no refs but is
-* still valid, protected by guc->contexts_lock
+* still valid, protected by guc->submission_state.lock
*/
struct list_head link;
} guc_id;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5dd174babf7a..65b5e8eeef96 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -70,17 +70,21 @@ struct intel_guc {
void (*disable)(struct intel_guc *guc);
} interrupts;
- /**
-* @contexts_lock: protects guc_ids, guc_id_list, ce->guc_id.id, and
-* ce->guc_id.ref when transitioning in and out of zero
-*/
- spinlock_t contexts_lock;
- /** @guc_ids: used to allocate unique ce->guc_id.id values */
- struct ida guc_ids;
- /**
-* @guc_id_list: list of intel_context with valid guc_ids but no refs
-*/
- struct list_head guc_id_list;
+ struct {
+ /**
+* @lock: protects everything in submission_state
+*/
+ spinlock_t lock;
+ /**
+* @guc_ids: used to allocate new guc_ids
+*/
+ struct ida guc_ids;
+ /**
+* @guc_id_list: list of intel_context with valid guc_ids but no
+* refs
+*/
+ struct list_head guc_id_list;
+ } submission_state;
/**
* @submission_supported: tracks whether we support GuC submission on
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 ba0de35f6323..ad5c18119d92 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -68,16 +68,16 @@
* fence is used to stall all requests associated with this guc_id until the
* corresponding G2H returns indicating the guc_id has been deregistered.
*
- * guc_ids:
+ * submission_state.guc_ids:
* Unique number associated with private GuC context data passed in during
* context registration / submission / deregistration. 64k available. Simple
ida
* is used for allocation.
*
- * Stealing guc_ids:
- * If no guc_ids are available they can be stolen from another context at
- * request creation time if that context is unpinned. If a guc_id can't be
found
- * we punt this problem to the user as we believe this is near impossible to
hit
- * during normal use cases.
+ * Stealing submission_state.guc_ids:
+ * If no submission_state.guc_ids are available they can be stolen from another
+ * context at request creation time if that context is unpinned. If a guc_id
+ * can't be found we punt this problem to the user as we believe this is near
+ * impossible to hit during normal use cases.
*
* Locking:
* In the GuC submission code we have 3 basic spin locks which protect
@@ -89,7 +89,7 @@
* sched_engine can be submitting at a time. Currently only one sched_engine is
* used for all of GuC submission but that could change in the future.
*
- * guc->contexts_lock
+ * guc->submission_state.lock
* Protects guc_id allocation for the given GuC, i.e. only one context can be
* doing guc_id allocation operations at a time for each GuC in the system.
*
@@ -103,7 +103,7 @@
*
* Lock ordering rules:
* sched_engine->lock -> ce->guc_state.lock
- * guc->contexts_lock -> ce->guc_state.lock
+ *
[Intel-gfx] [PATCH 14/26] drm/i915/guc: Implement multi-lrc reset
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its' children. The parent context owns the reset replaying / canceling
requests as needed.
v2:
(John Harrison)
- Simply loop in find active request
- Add comments to find ative request / reset loop
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 15 +++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
2 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c5bb7ccfb3f8..3b340eb59ada 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -528,20 +528,29 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
struct i915_request *intel_context_find_active_request(struct intel_context
*ce)
{
+ struct intel_context *parent = intel_context_to_parent(ce);
struct i915_request *rq, *active = NULL;
unsigned long flags;
GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
- spin_lock_irqsave(>guc_state.lock, flags);
- list_for_each_entry_reverse(rq, >guc_state.requests,
+ /*
+* We search the parent list to find an active request on the submitted
+* context. The parent list contains the requests for all the contexts
+* in the relationship so we have to do a compare of each request's
+* context must be done.
+*/
+ spin_lock_irqsave(>guc_state.lock, flags);
+ list_for_each_entry_reverse(rq, >guc_state.requests,
sched.link) {
+ if (rq->context != ce)
+ continue;
if (i915_request_completed(rq))
break;
active = rq;
}
- spin_unlock_irqrestore(>guc_state.lock, flags);
+ spin_unlock_irqrestore(>guc_state.lock, flags);
return active;
}
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 6be7adf89e4f..d661a69ef4f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -681,6 +681,11 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline bool is_multi_lrc(struct intel_context *ce)
+{
+ return intel_context_is_parallel(ce);
+}
+
static bool is_multi_lrc_rq(struct i915_request *rq)
{
return intel_context_is_parallel(rq->context);
@@ -1214,10 +1219,15 @@ __unwind_incomplete_requests(struct intel_context *ce)
static void __guc_reset_context(struct intel_context *ce, bool stalled)
{
+ bool local_stalled;
struct i915_request *rq;
unsigned long flags;
u32 head;
+ int i, number_children = ce->parallel.number_children;
bool skip = false;
+ struct intel_context *parent = ce;
+
+ GEM_BUG_ON(intel_context_is_child(ce));
intel_context_get(ce);
@@ -1243,25 +1253,38 @@ static void __guc_reset_context(struct intel_context
*ce, bool stalled)
if (unlikely(skip))
goto out_put;
- rq = intel_context_find_active_request(ce);
- if (!rq) {
- head = ce->ring->tail;
- stalled = false;
- goto out_replay;
- }
+ /*
+* For each context in the relationship find the hanging request
+* resetting each context / request as needed
+*/
+ for (i = 0; i < number_children + 1; ++i) {
+ if (!intel_context_is_pinned(ce))
+ goto next_context;
+
+ local_stalled = false;
+ rq = intel_context_find_active_request(ce);
+ if (!rq) {
+ head = ce->ring->tail;
+ goto out_replay;
+ }
- if (!i915_request_started(rq))
- stalled = false;
+ GEM_BUG_ON(i915_active_is_idle(>active));
+ head = intel_ring_wrap(ce->ring, rq->head);
- GEM_BUG_ON(i915_active_is_idle(>active));
- head = intel_ring_wrap(ce->ring, rq->head);
- __i915_request_reset(rq, stalled);
+ if (i915_request_started(rq))
+ local_stalled = true;
+ __i915_request_reset(rq, local_stalled && stalled);
out_replay:
- guc_reset_state(ce, head, stalled);
- __unwind_incomplete_requests(ce);
+ guc_reset_state(ce, head, local_stalled && stalled);
+next_context:
+ if (i != number_children)
+ ce = list_next_entry(ce, parallel.child_link);
+ }
+
+ __unwind_incomplete_requests(parent);
out_put:
- intel_context_put(ce);
+ intel_context_put(parent);
}
void
[Intel-gfx] [PATCH 02/26] drm/i915/guc: Take GT PM ref when deregistering context
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref blows up. Previously we took a
runtime PM from this atomic context which worked but will stop working
once runtime pm autosuspend in enabled.
So this patch is two fold, stop intel_gt_wait_for_idle from short
circuting and fix runtime pm autosuspend.
v2:
(John Harrison)
- Split structure changes out in different patch
(Tvrtko)
- Don't drop lock in deregister_destroyed_contexts
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 5 +
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 4 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 146 +++---
6 files changed, 121 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e9a0cad5c34d..1076066f41e0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -399,6 +399,8 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
ce->guc_id.id = GUC_INVALID_LRC_ID;
INIT_LIST_HEAD(>guc_id.link);
+ INIT_LIST_HEAD(>destroyed_link);
+
/*
* Initialize fence to be complete as this is expected to be complete
* unless there is a pending schedule disable outstanding.
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e7e3984aab78..4613d027cbc3 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -213,6 +213,13 @@ struct intel_context {
struct list_head link;
} guc_id;
+ /**
+* @destroyed_link: link in guc->submission_state.destroyed_contexts, in
+* list when context is pending to be destroyed (deregistered with the
+* GuC), protected by guc->submission_state.lock
+*/
+ struct list_head destroyed_link;
+
#ifdef CONFIG_DRM_I915_SELFTEST
/**
* @drop_schedule_enable: Force drop of schedule enable G2H for selftest
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 8520c595f5e1..6fdeae668e6e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -16,6 +16,11 @@ intel_engine_pm_is_awake(const struct intel_engine_cs
*engine)
return intel_wakeref_is_active(>wakeref);
}
+static inline void __intel_engine_pm_get(struct intel_engine_cs *engine)
+{
+ __intel_wakeref_get(>wakeref);
+}
+
static inline void intel_engine_pm_get(struct intel_engine_cs *engine)
{
intel_wakeref_get(>wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index d0588d8aaa44..05de6c1af25b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -41,6 +41,10 @@ static inline void intel_gt_pm_put_async(struct intel_gt *gt)
intel_wakeref_put_async(>wakeref);
}
+#define with_intel_gt_pm(gt, tmp) \
+ for (tmp = 1, intel_gt_pm_get(gt); tmp; \
+intel_gt_pm_put(gt), tmp = 0)
+
static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
{
return intel_wakeref_wait_for_idle(>wakeref);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 65b5e8eeef96..25a598e2b6e8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -84,6 +84,17 @@ struct intel_guc {
* refs
*/
struct list_head guc_id_list;
+ /**
+* @destroyed_contexts: list of contexts waiting to be destroyed
+* (deregistered with the GuC)
+*/
+ struct list_head destroyed_contexts;
+ /**
+* @destroyed_worker: worker to deregister contexts, need as we
+* need to take a GT PM reference and can't from destroy
+* function as it might be in an atomic context (no sleeping)
+*/
+ struct work_struct destroyed_worker;
} submission_state;
/**
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 ad5c18119d92..17da2fea1bff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -90,8 +90,8 @@
* used for all of GuC submission but that could change in the future.
*
* guc->submission_state.lock
- *
[Intel-gfx] [PATCH 06/26] drm/i915: Expose logical engine instance to user
Expose logical engine instance to user via query engine info IOCTL. This
is required for split-frame workloads as these needs to be placed on
engines in a logically contiguous order. The logical mapping can change
based on fusing. Rather than having user have knowledge of the fusing we
simply just expose the logical mapping with the existing query engine
info IOCTL.
IGT: https://patchwork.freedesktop.org/patch/445637/?series=92854=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Daniel Vetter)
- Add IGT link, placeholder for media UMD
Cc: Tvrtko Ursulin
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_query.c | 2 ++
include/uapi/drm/i915_drm.h | 8 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 5e2b909827f4..51b368be0fc4 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -124,7 +124,9 @@ query_engine_info(struct drm_i915_private *i915,
for_each_uabi_engine(engine, i915) {
info.engine.engine_class = engine->uabi_class;
info.engine.engine_instance = engine->uabi_instance;
+ info.flags = I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE;
info.capabilities = engine->uabi_capabilities;
+ info.logical_instance = ilog2(engine->logical_mask);
if (copy_to_user(info_ptr, , sizeof(info)))
return -EFAULT;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index bde5860b3686..b1248a67b4f8 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2726,14 +2726,20 @@ struct drm_i915_engine_info {
/** @flags: Engine flags. */
__u64 flags;
+#define I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE (1 << 0)
/** @capabilities: Capabilities of this engine. */
__u64 capabilities;
#define I915_VIDEO_CLASS_CAPABILITY_HEVC (1 << 0)
#define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC(1 << 1)
+ /** @logical_instance: Logical instance of engine */
+ __u16 logical_instance;
+
/** @rsvd1: Reserved fields. */
- __u64 rsvd1[4];
+ __u16 rsvd1[3];
+ /** @rsvd2: Reserved fields. */
+ __u64 rsvd2[3];
};
/**
--
2.32.0
[Intel-gfx] [PATCH 13/26] drm/i915/guc: Insert submit fences between requests in parent-child relationship
The GuC must receive requests in the order submitted for contexts in a
parent-child relationship to function correctly. To ensure this, insert
a submit fence between the current request and last request submitted
for requests / contexts in a parent child relationship. This is
conceptually similar to a single timeline.
Signed-off-by: Matthew Brost
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.h | 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +-
drivers/gpu/drm/i915/i915_request.c | 120 ++
4 files changed, 108 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index b63c10a144af..1bc705f98e2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -75,6 +75,11 @@ intel_context_to_parent(struct intel_context *ce)
}
}
+static inline bool intel_context_is_parallel(struct intel_context *ce)
+{
+ return intel_context_is_child(ce) || intel_context_is_parent(ce);
+}
+
void intel_context_bind_parent_child(struct intel_context *parent,
struct intel_context *child);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 48decb5ee954..8309d1141d0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -237,6 +237,12 @@ struct intel_context {
};
/** @parent: pointer to parent if child */
struct intel_context *parent;
+ /**
+* @last_rq: last request submitted on a parallel context, used
+* to insert submit fences between requests in the parallel
+* context
+*/
+ struct i915_request *last_rq;
/** @number_children: number of children if parent */
u8 number_children;
/** @guc: GuC specific members for parallel submission */
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 1610120e31a1..6be7adf89e4f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -683,8 +683,7 @@ static inline int rq_prio(const struct i915_request *rq)
static bool is_multi_lrc_rq(struct i915_request *rq)
{
- return intel_context_is_child(rq->context) ||
- intel_context_is_parent(rq->context);
+ return intel_context_is_parallel(rq->context);
}
static bool can_merge_rq(struct i915_request *rq,
@@ -2870,6 +2869,8 @@ static void guc_parent_context_unpin(struct intel_context
*ce)
GEM_BUG_ON(!intel_context_is_parent(ce));
GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+ if (ce->parallel.last_rq)
+ i915_request_put(ce->parallel.last_rq);
unpin_guc_id(guc, ce);
lrc_unpin(ce);
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 79da5eca60af..e9bfa32f9270 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1539,36 +1539,62 @@ i915_request_await_object(struct i915_request *to,
return ret;
}
+static inline bool is_parallel_rq(struct i915_request *rq)
+{
+ return intel_context_is_parallel(rq->context);
+}
+
+static inline struct intel_context *request_to_parent(struct i915_request *rq)
+{
+ return intel_context_to_parent(rq->context);
+}
+
static struct i915_request *
-__i915_request_add_to_timeline(struct i915_request *rq)
+__i915_request_ensure_parallel_ordering(struct i915_request *rq,
+ struct intel_timeline *timeline)
{
- struct intel_timeline *timeline = i915_request_timeline(rq);
struct i915_request *prev;
- /*
-* Dependency tracking and request ordering along the timeline
-* is special cased so that we can eliminate redundant ordering
-* operations while building the request (we know that the timeline
-* itself is ordered, and here we guarantee it).
-*
-* As we know we will need to emit tracking along the timeline,
-* we embed the hooks into our request struct -- at the cost of
-* having to have specialised no-allocation interfaces (which will
-* be beneficial elsewhere).
-*
-* A second benefit to open-coding i915_request_await_request is
-* that we can apply a slight variant of the rules specialised
-* for timelines that jump between engines (such as virtual engines).
-* If we consider the case of virtual engine, we must emit a dma-fence
-* to prevent scheduling of the second request until the first is
-*
[Intel-gfx] [PATCH 16/26] drm/i915: Fix bug in user proto-context creation that leaked contexts
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines returning NULL
v3:
(Checkpatch / Tvrtko)
- Remove braces around single line if statement
Cc: Jason Ekstrand
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
parameters (v5)")
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..8c7ea6e56262 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -898,6 +898,10 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
unsigned int n;
e = alloc_engines(num_engines);
+ if (!e)
+ return ERR_PTR(-ENOMEM);
+ e->num_engines = num_engines;
+
for (n = 0; n < num_engines; n++) {
struct intel_context *ce;
int ret;
@@ -931,7 +935,6 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
goto free_engines;
}
}
- e->num_engines = num_engines;
return e;
--
2.32.0
[Intel-gfx] [PATCH 12/26] drm/i915/guc: Implement multi-lrc submission
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to coalesce requests into a single submission.
v2:
(John Harrison)
- s/wqe/wqi
- Use FIELD_PREP macros
- Add GEM_BUG_ONs ensures length fits within field
- Add comment / white space to intel_guc_write_barrier
(Kernel test robot)
- Make need_tasklet a static function
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 26 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 23 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 319 --
drivers/gpu/drm/i915/i915_request.h | 8 +
6 files changed, 335 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 8f8182bf7c11..7191e8439290 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -756,3 +756,29 @@ void intel_guc_load_status(struct intel_guc *guc, struct
drm_printer *p)
}
}
}
+
+void intel_guc_write_barrier(struct intel_guc *guc)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
+ /*
+* Ensure intel_uncore_write_fw can be used rather than
+* intel_uncore_write.
+*/
+ GEM_BUG_ON(guc->send_regs.fw_domains);
+
+ /*
+* This register is used by the i915 and GuC for MMIO based
+* communication. Once we are in this code CTBs are the only
+* method the i915 uses to communicate with the GuC so it is
+* safe to write to this register (a value of 0 is NOP for MMIO
+* communication). If we ever start mixing CTBs and MMIOs a new
+* register will have to be chosen.
+*/
+ intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
+ } else {
+ /* wmb() sufficient for a barrier if in smem */
+ wmb();
+ }
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index a9f4ec972bfb..147f39cc0f2f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -46,6 +46,12 @@ struct intel_guc {
* submitted until the stalled request is processed.
*/
struct i915_request *stalled_request;
+ enum {
+ STALL_NONE,
+ STALL_REGISTER_CONTEXT,
+ STALL_MOVE_LRC_TAIL,
+ STALL_ADD_REQUEST,
+ } submission_stall_reason;
/* intel_guc_recv interrupt related state */
/** @irq_lock: protects GuC irq state */
@@ -361,4 +367,6 @@ void intel_guc_submission_cancel_requests(struct intel_guc
*guc);
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p);
+void intel_guc_write_barrier(struct intel_guc *guc);
+
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 20c710a74498..10d1878d2826 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -377,28 +377,6 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
return ++ct->requests.last_fence;
}
-static void write_barrier(struct intel_guc_ct *ct)
-{
- struct intel_guc *guc = ct_to_guc(ct);
- struct intel_gt *gt = guc_to_gt(guc);
-
- if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
- GEM_BUG_ON(guc->send_regs.fw_domains);
- /*
-* This register is used by the i915 and GuC for MMIO based
-* communication. Once we are in this code CTBs are the only
-* method the i915 uses to communicate with the GuC so it is
-* safe to write to this register (a value of 0 is NOP for MMIO
-* communication). If we ever start mixing CTBs and MMIOs a new
-* register will have to be chosen.
-*/
- intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
- } else {
- /* wmb() sufficient for a barrier if in smem */
- wmb();
- }
-}
-
static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
@@ -468,7 +446,7 @@ static int ct_write(struct intel_guc_ct *ct,
* make sure H2G buffer update and LRC tail update (if this triggering a
* submission) are visible before updating the descriptor tail
*/
- write_barrier(ct);
+
[Intel-gfx] [PATCH 10/26] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
available guc_ids). The consecutive search is implemented via the bitmap
API.
This is a precursor to the full GuC multi-lrc implementation but aligns
to how GuC mutli-lrc interface is defined - guc_ids must be consecutive
when using the GuC multi-lrc interface.
v2:
(Daniel Vetter)
- Explicitly state why we assign consecutive guc_ids
v3:
(John Harrison)
- Bring back in spin lock
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 6 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 104 ++
2 files changed, 86 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 25a598e2b6e8..a9f4ec972bfb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -76,9 +76,13 @@ struct intel_guc {
*/
spinlock_t lock;
/**
-* @guc_ids: used to allocate new guc_ids
+* @guc_ids: used to allocate new guc_ids, single-lrc
*/
struct ida guc_ids;
+ /**
+* @guc_ids_bitmap: used to allocate new guc_ids, multi-lrc
+*/
+ unsigned long *guc_ids_bitmap;
/**
* @guc_id_list: list of intel_context with valid guc_ids but no
* refs
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 1f2809187513..79e7732e83b2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -128,6 +128,16 @@ guc_create_virtual(struct intel_engine_cs **siblings,
unsigned int count);
#define GUC_REQUEST_SIZE 64 /* bytes */
+/*
+ * We reserve 1/16 of the guc_ids for multi-lrc as these need to be contiguous
+ * per the GuC submission interface. A different allocation algorithm is used
+ * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
+ * partition the guc_id space. We believe the number of multi-lrc contexts in
+ * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
+ * multi-lrc.
+ */
+#define NUMBER_MULTI_LRC_GUC_ID(GUC_MAX_LRC_DESCRIPTORS / 16)
+
/*
* Below is a set of functions which control the GuC scheduling state which
* require a lock.
@@ -1206,6 +1216,11 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_WORK(>submission_state.destroyed_worker,
destroyed_worker_func);
+ guc->submission_state.guc_ids_bitmap =
+ bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID, GFP_KERNEL);
+ if (!guc->submission_state.guc_ids_bitmap)
+ return -ENOMEM;
+
return 0;
}
@@ -1217,6 +1232,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
guc_lrc_desc_pool_destroy(guc);
guc_flush_destroyed_contexts(guc);
i915_sched_engine_put(guc->sched_engine);
+ bitmap_free(guc->submission_state.guc_ids_bitmap);
}
static inline void queue_request(struct i915_sched_engine *sched_engine,
@@ -1268,18 +1284,43 @@ static void guc_submit_request(struct i915_request *rq)
spin_unlock_irqrestore(_engine->lock, flags);
}
-static int new_guc_id(struct intel_guc *guc)
+static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
{
- return ida_simple_get(>submission_state.guc_ids, 0,
- GUC_MAX_LRC_DESCRIPTORS, GFP_KERNEL |
- __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
+ int ret;
+
+ GEM_BUG_ON(intel_context_is_child(ce));
+
+ if (intel_context_is_parent(ce))
+ ret =
bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
+ NUMBER_MULTI_LRC_GUC_ID,
+
order_base_2(ce->parallel.number_children
+ + 1));
+ else
+ ret = ida_simple_get(>submission_state.guc_ids,
+NUMBER_MULTI_LRC_GUC_ID,
+GUC_MAX_LRC_DESCRIPTORS,
+GFP_KERNEL | __GFP_RETRY_MAYFAIL |
+__GFP_NOWARN);
+ if (unlikely(ret < 0))
+ return ret;
+
+ ce->guc_id.id = ret;
+ return 0;
}
static void __release_guc_id(struct intel_guc *guc, struct intel_context *ce)
{
+ GEM_BUG_ON(intel_context_is_child(ce));
+
if (!context_guc_id_invalid(ce)) {
- ida_simple_remove(>submission_state.guc_ids,
- ce->guc_id.id);
+ if
[Intel-gfx] [PATCH 09/26] drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts
In GuC parent-child contexts the parent context controls the scheduling,
ensure only the parent does the scheduling operations.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 -
1 file changed, 12 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 ab6d7fc1b0b1..1f2809187513 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -324,6 +324,12 @@ static inline void decr_context_committed_requests(struct
intel_context *ce)
GEM_BUG_ON(ce->guc_state.number_committed_requests < 0);
}
+static struct intel_context *
+request_to_scheduling_context(struct i915_request *rq)
+{
+ return intel_context_to_parent(rq->context);
+}
+
static inline bool context_guc_id_invalid(struct intel_context *ce)
{
return ce->guc_id.id == GUC_INVALID_LRC_ID;
@@ -1710,6 +1716,7 @@ static void __guc_context_sched_disable(struct intel_guc
*guc,
GEM_BUG_ON(guc_id == GUC_INVALID_LRC_ID);
+ GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_sched_disable(ce);
guc_submission_send_busy_loop(guc, action, ARRAY_SIZE(action),
@@ -1935,6 +1942,8 @@ static void guc_context_sched_disable(struct
intel_context *ce)
intel_wakeref_t wakeref;
u16 guc_id;
+ GEM_BUG_ON(intel_context_is_child(ce));
+
spin_lock_irqsave(>guc_state.lock, flags);
/*
@@ -2303,6 +2312,8 @@ static void guc_signal_context_fence(struct intel_context
*ce)
{
unsigned long flags;
+ GEM_BUG_ON(intel_context_is_child(ce));
+
spin_lock_irqsave(>guc_state.lock, flags);
clr_context_wait_for_deregister_to_register(ce);
__guc_signal_context_fence(ce);
@@ -2333,7 +2344,7 @@ static void guc_context_init(struct intel_context *ce)
static int guc_request_alloc(struct i915_request *rq)
{
- struct intel_context *ce = rq->context;
+ struct intel_context *ce = request_to_scheduling_context(rq);
struct intel_guc *guc = ce_to_guc(ce);
unsigned long flags;
int ret;
--
2.32.0
[Intel-gfx] [PATCH 11/26] drm/i915/guc: Implement parallel context pin / unpin functions
Parallel contexts are perma-pinned by the upper layers which makes the
backend implementation rather simple. The parent pins the guc_id and
children increment the parent's pin count on pin to ensure all the
contexts are unpinned before we disable scheduling with the GuC / or
deregister the context.
v2:
(Daniel Vetter)
- Perma-pin parallel contexts
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 70 +++
1 file changed, 70 insertions(+)
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 79e7732e83b2..031b1bf5ba91 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2583,6 +2583,76 @@ static const struct intel_context_ops
virtual_guc_context_ops = {
.get_sibling = guc_virtual_get_sibling,
};
+/* Future patches will use this function */
+__maybe_unused
+static int guc_parent_context_pin(struct intel_context *ce, void *vaddr)
+{
+ struct intel_engine_cs *engine = guc_virtual_get_sibling(ce->engine, 0);
+ struct intel_guc *guc = ce_to_guc(ce);
+ int ret;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+ GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+
+ ret = pin_guc_id(guc, ce);
+ if (unlikely(ret < 0))
+ return ret;
+
+ return __guc_context_pin(ce, engine, vaddr);
+}
+
+/* Future patches will use this function */
+__maybe_unused
+static int guc_child_context_pin(struct intel_context *ce, void *vaddr)
+{
+ struct intel_engine_cs *engine = guc_virtual_get_sibling(ce->engine, 0);
+
+ GEM_BUG_ON(!intel_context_is_child(ce));
+ GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+
+ __intel_context_pin(ce->parallel.parent);
+ return __guc_context_pin(ce, engine, vaddr);
+}
+
+/* Future patches will use this function */
+__maybe_unused
+static void guc_parent_context_unpin(struct intel_context *ce)
+{
+ struct intel_guc *guc = ce_to_guc(ce);
+
+ GEM_BUG_ON(context_enabled(ce));
+ GEM_BUG_ON(intel_context_is_barrier(ce));
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+ GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+
+ unpin_guc_id(guc, ce);
+ lrc_unpin(ce);
+}
+
+/* Future patches will use this function */
+__maybe_unused
+static void guc_child_context_unpin(struct intel_context *ce)
+{
+ GEM_BUG_ON(context_enabled(ce));
+ GEM_BUG_ON(intel_context_is_barrier(ce));
+ GEM_BUG_ON(!intel_context_is_child(ce));
+ GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+
+ lrc_unpin(ce);
+}
+
+/* Future patches will use this function */
+__maybe_unused
+static void guc_child_context_post_unpin(struct intel_context *ce)
+{
+ GEM_BUG_ON(!intel_context_is_child(ce));
+ GEM_BUG_ON(!intel_context_is_pinned(ce->parallel.parent));
+ GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+
+ lrc_post_unpin(ce);
+ intel_context_unpin(ce->parallel.parent);
+}
+
static bool
guc_irq_enable_breadcrumbs(struct intel_breadcrumbs *b)
{
--
2.32.0
[Intel-gfx] [PATCH 03/26] drm/i915/guc: Take engine PM when a context is pinned with GuC submission
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
Returning GT idle when it is not can cause all sorts of issues
throughout the stack.
v2:
(Daniel Vetter)
- Add might_lock annotations to pin / unpin function
v3:
(CI)
- Drop intel_engine_pm_might_put from unpin path as an async put is
used
v4:
(John Harrison)
- Make intel_engine_pm_might_get/put work with GuC virtual engines
- Update commit message
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 32 +
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 10 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 36 +--
drivers/gpu/drm/i915/intel_wakeref.h | 12 +++
5 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 1076066f41e0..f601323b939f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -240,6 +240,8 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
if (err)
goto err_post_unpin;
+ intel_engine_pm_might_get(ce->engine);
+
if (unlikely(intel_context_is_closed(ce))) {
err = -ENOENT;
goto err_unlock;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 6fdeae668e6e..d68675925b79 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -6,9 +6,11 @@
#ifndef INTEL_ENGINE_PM_H
#define INTEL_ENGINE_PM_H
+#include "i915_drv.h"
#include "i915_request.h"
#include "intel_engine_types.h"
#include "intel_wakeref.h"
+#include "intel_gt_pm.h"
static inline bool
intel_engine_pm_is_awake(const struct intel_engine_cs *engine)
@@ -31,6 +33,21 @@ static inline bool intel_engine_pm_get_if_awake(struct
intel_engine_cs *engine)
return intel_wakeref_get_if_active(>wakeref);
}
+static inline void intel_engine_pm_might_get(struct intel_engine_cs *engine)
+{
+ if (!intel_engine_is_virtual(engine)) {
+ intel_wakeref_might_get(>wakeref);
+ } else {
+ struct intel_gt *gt = engine->gt;
+ struct intel_engine_cs *tengine;
+ intel_engine_mask_t tmp, mask = engine->mask;
+
+ for_each_engine_masked(tengine, gt, mask, tmp)
+ intel_wakeref_might_get(>wakeref);
+ }
+ intel_gt_pm_might_get(engine->gt);
+}
+
static inline void intel_engine_pm_put(struct intel_engine_cs *engine)
{
intel_wakeref_put(>wakeref);
@@ -52,6 +69,21 @@ static inline void intel_engine_pm_flush(struct
intel_engine_cs *engine)
intel_wakeref_unlock_wait(>wakeref);
}
+static inline void intel_engine_pm_might_put(struct intel_engine_cs *engine)
+{
+ if (!intel_engine_is_virtual(engine)) {
+ intel_wakeref_might_put(>wakeref);
+ } else {
+ struct intel_gt *gt = engine->gt;
+ struct intel_engine_cs *tengine;
+ intel_engine_mask_t tmp, mask = engine->mask;
+
+ for_each_engine_masked(tengine, gt, mask, tmp)
+ intel_wakeref_might_put(>wakeref);
+ }
+ intel_gt_pm_might_put(engine->gt);
+}
+
static inline struct i915_request *
intel_engine_create_kernel_request(struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 05de6c1af25b..bc898df7a48c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -31,6 +31,11 @@ static inline bool intel_gt_pm_get_if_awake(struct intel_gt
*gt)
return intel_wakeref_get_if_active(>wakeref);
}
+static inline void intel_gt_pm_might_get(struct intel_gt *gt)
+{
+ intel_wakeref_might_get(>wakeref);
+}
+
static inline void intel_gt_pm_put(struct intel_gt *gt)
{
intel_wakeref_put(>wakeref);
@@ -41,6 +46,11 @@ static inline void intel_gt_pm_put_async(struct intel_gt *gt)
intel_wakeref_put_async(>wakeref);
}
+static inline void intel_gt_pm_might_put(struct intel_gt *gt)
+{
+ intel_wakeref_might_put(>wakeref);
+}
+
#define with_intel_gt_pm(gt, tmp) \
for (tmp = 1, intel_gt_pm_get(gt); tmp; \
intel_gt_pm_put(gt), tmp = 0)
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 17da2fea1bff..8b82da50c2bc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1571,7 +1571,12 @@ static int guc_context_pre_pin(struct intel_context *ce,
static int guc_context_pin(struct intel_context *ce, void *vaddr)
{
- return __guc_context_pin(ce, ce->engine, vaddr);
+ int
[Intel-gfx] [PATCH 08/26] drm/i915/guc: Add multi-lrc context registration
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into sub-struct
- Clean up WQ defines
- Add comment explaining math to derive WQ / PD address
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 +-
5 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 76dfca57cb45..48decb5ee954 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -239,6 +239,18 @@ struct intel_context {
struct intel_context *parent;
/** @number_children: number of children if parent */
u8 number_children;
+ /** @guc: GuC specific members for parallel submission */
+ struct {
+ /** @wqi_head: head pointer in work queue */
+ u16 wqi_head;
+ /** @wqi_tail: tail pointer in work queue */
+ u16 wqi_tail;
+ /**
+* @parent_page: page in context state (ce->state) used
+* by parent for work queue, process descriptor
+*/
+ u8 parent_page;
+ } guc;
} parallel;
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3ef9eaf8c50e..57339d5c1fc8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -942,6 +942,11 @@ __lrc_alloc_state(struct intel_context *ce, struct
intel_engine_cs *engine)
context_size += PAGE_SIZE;
}
+ if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
+ ce->parallel.guc.parent_page = context_size / PAGE_SIZE;
+ context_size += PAGE_SIZE;
+ }
+
obj = i915_gem_object_create_lmem(engine->i915, context_size,
I915_BO_ALLOC_PM_VOLATILE);
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 8ff58aff..ba10bd374cee 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -142,6 +142,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
+ INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
INTEL_GUC_ACTION_RESET_CLIENT = 0x5507,
INTEL_GUC_ACTION_LIMIT
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index fa4be13c8854..0eeb2a9feeed 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -52,8 +52,6 @@
#define GUC_DOORBELL_INVALID 256
-#define GUC_WQ_SIZE(PAGE_SIZE * 2)
-
/* Work queue item header definitions */
#define WQ_STATUS_ACTIVE 1
#define WQ_STATUS_SUSPENDED2
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 451d9ae861a6..ab6d7fc1b0b1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -344,6 +344,45 @@ static inline struct i915_priolist *to_priolist(struct
rb_node *rb)
return rb_entry(rb, struct i915_priolist, node);
}
+/*
+ * When using multi-lrc submission an extra page in the context state is
+ * reserved for the process descriptor and work queue.
+ *
+ * The layout of this page is below:
+ * 0 guc_process_desc
+ * ... unused
+ * PAGE_SIZE / 2 work queue start
+ * ... work queue
+ * PAGE_SIZE - 1 work queue end
+ */
+#define WQ_SIZE(PAGE_SIZE / 2)
+#define WQ_OFFSET (PAGE_SIZE - WQ_SIZE)
+static u32 __get_process_desc_offset(struct intel_context *ce)
+{
+ GEM_BUG_ON(!ce->parallel.guc.parent_page);
+
+ return ce->parallel.guc.parent_page * PAGE_SIZE;
+}
+
+static u32 __get_wq_offset(struct intel_context *ce)
+{
+ return __get_process_desc_offset(ce) +
[Intel-gfx] [PATCH 05/26] drm/i915: Add logical engine mapping
Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
(Daniel Vetter)
- Add kernel doc for new fields
v3
(Tvrtko)
- Update comment for new logical_mask field
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 60 ---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 +++
.../drm/i915/gt/intel_execlists_submission.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +--
5 files changed, 62 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ae57e4656a3..2eb798ad068b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -290,7 +290,8 @@ static void nop_irq_handler(struct intel_engine_cs *engine,
u16 iir)
GEM_DEBUG_WARN_ON(iir);
}
-static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id)
+static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id,
+ u8 logical_instance)
{
const struct engine_info *info = _engines[id];
struct drm_i915_private *i915 = gt->i915;
@@ -335,6 +336,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->class = info->class;
engine->instance = info->instance;
+ engine->logical_mask = BIT(logical_instance);
__sprint_engine_name(engine);
engine->props.heartbeat_interval_ms =
@@ -588,6 +590,37 @@ static intel_engine_mask_t init_engine_mask(struct
intel_gt *gt)
return info->engine_mask;
}
+static void populate_logical_ids(struct intel_gt *gt, u8 *logical_ids,
+u8 class, const u8 *map, u8 num_instances)
+{
+ int i, j;
+ u8 current_logical_id = 0;
+
+ for (j = 0; j < num_instances; ++j) {
+ for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
+ if (!HAS_ENGINE(gt, i) ||
+ intel_engines[i].class != class)
+ continue;
+
+ if (intel_engines[i].instance == map[j]) {
+ logical_ids[intel_engines[i].instance] =
+ current_logical_id++;
+ break;
+ }
+ }
+ }
+}
+
+static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8 class)
+{
+ int i;
+ u8 map[MAX_ENGINE_INSTANCE + 1];
+
+ for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
+ map[i] = i;
+ populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
+}
+
/**
* intel_engines_init_mmio() - allocate and prepare the Engine Command
Streamers
* @gt: pointer to struct intel_gt
@@ -599,7 +632,8 @@ int intel_engines_init_mmio(struct intel_gt *gt)
struct drm_i915_private *i915 = gt->i915;
const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
- unsigned int i;
+ unsigned int i, class;
+ u8 logical_ids[MAX_ENGINE_INSTANCE + 1];
int err;
drm_WARN_ON(>drm, engine_mask == 0);
@@ -609,15 +643,23 @@ int intel_engines_init_mmio(struct intel_gt *gt)
if (i915_inject_probe_failure(i915))
return -ENODEV;
- for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
- if (!HAS_ENGINE(gt, i))
- continue;
+ for (class = 0; class < MAX_ENGINE_CLASS + 1; ++class) {
+ setup_logical_ids(gt, logical_ids, class);
- err = intel_engine_setup(gt, i);
- if (err)
- goto cleanup;
+ for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
+ u8 instance = intel_engines[i].instance;
+
+ if (intel_engines[i].class != class ||
+ !HAS_ENGINE(gt, i))
+ continue;
- mask |= BIT(i);
+ err = intel_engine_setup(gt, i,
+logical_ids[instance]);
+ if (err)
+ goto cleanup;
+
+ mask |= BIT(i);
+ }
}
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5ae1207c363b..68010da468a4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -269,6 +269,13 @@ struct intel_engine_cs {
unsigned int guc_id;
intel_engine_mask_t mask;
+ /**
+* @logical_mask: logical mask of engine, reported to user space via
+* query IOCTL and used to communicate with the GuC in logical space.
+
[Intel-gfx] [PATCH 07/26] drm/i915/guc: Introduce context parent-child relationship
Introduce context parent-child relationship. Once this relationship is
created all pinning / unpinning operations are directed to the parent
context. The parent context is responsible for pinning all of its'
children and itself.
This is a precursor to the full GuC multi-lrc implementation but aligns
to how GuC mutli-lrc interface is defined - a single H2G is used
register / deregister all of the contexts simultaneously.
Subsequent patches in the series will implement the pinning / unpinning
operations for parent / child contexts.
v2:
(Daniel Vetter)
- Add kernel doc, add wrapper to access parent to ensure safety
v3:
(John Harrison)
- Fix comment explaing GEM_BUG_ON in to_parent()
- Make variable names generic (non-GuC specific)
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 29 +
drivers/gpu/drm/i915/gt/intel_context.h | 41 +++
drivers/gpu/drm/i915/gt/intel_context_types.h | 21 ++
3 files changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index f601323b939f..c5bb7ccfb3f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -403,6 +403,8 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
INIT_LIST_HEAD(>destroyed_link);
+ INIT_LIST_HEAD(>parallel.child_list);
+
/*
* Initialize fence to be complete as this is expected to be complete
* unless there is a pending schedule disable outstanding.
@@ -417,10 +419,17 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
void intel_context_fini(struct intel_context *ce)
{
+ struct intel_context *child, *next;
+
if (ce->timeline)
intel_timeline_put(ce->timeline);
i915_vm_put(ce->vm);
+ /* Need to put the creation ref for the children */
+ if (intel_context_is_parent(ce))
+ for_each_child_safe(ce, child, next)
+ intel_context_put(child);
+
mutex_destroy(>pin_mutex);
i915_active_fini(>active);
i915_sw_fence_fini(>guc_state.blocked);
@@ -537,6 +546,26 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
return active;
}
+void intel_context_bind_parent_child(struct intel_context *parent,
+struct intel_context *child)
+{
+ /*
+* Callers responsibility to validate that this function is used
+* correctly but we use GEM_BUG_ON here ensure that they do.
+*/
+ GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
+ GEM_BUG_ON(intel_context_is_pinned(parent));
+ GEM_BUG_ON(intel_context_is_child(parent));
+ GEM_BUG_ON(intel_context_is_pinned(child));
+ GEM_BUG_ON(intel_context_is_child(child));
+ GEM_BUG_ON(intel_context_is_parent(child));
+
+ parent->parallel.number_children++;
+ list_add_tail(>parallel.child_link,
+ >parallel.child_list);
+ child->parallel.parent = parent;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index c41098950746..b63c10a144af 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -44,6 +44,47 @@ void intel_context_free(struct intel_context *ce);
int intel_context_reconfigure_sseu(struct intel_context *ce,
const struct intel_sseu sseu);
+static inline bool intel_context_is_child(struct intel_context *ce)
+{
+ return !!ce->parallel.parent;
+}
+
+static inline bool intel_context_is_parent(struct intel_context *ce)
+{
+ return !!ce->parallel.number_children;
+}
+
+static inline bool intel_context_is_pinned(struct intel_context *ce);
+
+static inline struct intel_context *
+intel_context_to_parent(struct intel_context *ce)
+{
+ if (intel_context_is_child(ce)) {
+ /*
+* The parent holds ref count to the child so it is always safe
+* for the parent to access the child, but the child has a
+* pointer to the parent without a ref. To ensure this is safe
+* the child should only access the parent pointer while the
+* parent is pinned.
+*/
+ GEM_BUG_ON(!intel_context_is_pinned(ce->parallel.parent));
+
+ return ce->parallel.parent;
+ } else {
+ return ce;
+ }
+}
+
+void intel_context_bind_parent_child(struct intel_context *parent,
+struct intel_context *child);
+
+#define for_each_child(parent, ce)\
+ list_for_each_entry(ce, &(parent)->parallel.child_list,\
+ parallel.child_link)
+#define
[Intel-gfx] [PATCH 00/26] Parallel submission aka multi-bb execbuf
As discussed in [1] we are introducing a new parallel submission uAPI for the i915 which allows more than 1 BB to be submitted in an execbuf IOCTL. This is the implemenation for both GuC and execlists. In addition to selftests in the series, an IGT is available implemented in the first 4 patches [2]. The execbuf IOCTL changes have been done in a single large patch (#21) as all the changes flow together and I believe a single patch will be better if some one has to lookup this change in the future. Can split in a series of smaller patches if desired. This code is available in a public [3] repo for UMD teams to test there code on. v2: Drop complicated state machine to block in kernel if no guc_ids available, perma-pin parallel contexts, reworker execbuf IOCTL to be a series of loops inside the IOCTL rather than 1 large one on the outside, address Daniel Vetter's comments v3: Address John Harrison's comments, add a couple of patches which fix bugs found internally Signed-off-by: Matthew Brost [1] https://patchwork.freedesktop.org/series/92028/ [2] https://patchwork.freedesktop.org/series/93071/ [3] https://gitlab.freedesktop.org/mbrost/mbrost-drm-intel/-/tree/drm-intel-parallel Matthew Brost (26): drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct drm/i915/guc: Take GT PM ref when deregistering context drm/i915/guc: Take engine PM when a context is pinned with GuC submission drm/i915/guc: Don't call switch_to_kernel_context with GuC submission drm/i915: Add logical engine mapping drm/i915: Expose logical engine instance to user drm/i915/guc: Introduce context parent-child relationship drm/i915/guc: Add multi-lrc context registration drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids drm/i915/guc: Implement parallel context pin / unpin functions drm/i915/guc: Implement multi-lrc submission drm/i915/guc: Insert submit fences between requests in parent-child relationship drm/i915/guc: Implement multi-lrc reset drm/i915/guc: Update debugfs for GuC multi-lrc drm/i915: Fix bug in user proto-context creation that leaked contexts drm/i915/guc: Connect UAPI to GuC multi-lrc interface drm/i915/doc: Update parallel submit doc to point to i915_drm.h drm/i915/guc: Add basic GuC multi-lrc selftest drm/i915/guc: Implement no mid batch preemption for multi-lrc drm/i915: Multi-BB execbuf drm/i915/guc: Handle errors in multi-lrc requests drm/i915: Make request conflict tracking understand parallel submits drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences drm/i915: Enable multi-bb execbuf drm/i915/execlists: Weak parallel submission support for execlists Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 -- Documentation/gpu/rfc/i915_scheduler.rst |4 +- drivers/gpu/drm/i915/gem/i915_gem_busy.c | 60 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 225 ++- .../gpu/drm/i915/gem/i915_gem_context_types.h |6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 796 ++--- drivers/gpu/drm/i915/gt/intel_context.c | 50 +- drivers/gpu/drm/i915/gt/intel_context.h | 54 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 73 +- drivers/gpu/drm/i915/gt/intel_engine.h| 12 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 66 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 13 + drivers/gpu/drm/i915/gt/intel_engine_pm.h | 37 + drivers/gpu/drm/i915/gt/intel_engine_types.h |7 + .../drm/i915/gt/intel_execlists_submission.c | 63 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 14 + drivers/gpu/drm/i915/gt/intel_lrc.c |7 + drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +- .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h |1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 26 + drivers/gpu/drm/i915/gt/uc/intel_guc.h| 49 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 27 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1456 ++--- .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 179 ++ drivers/gpu/drm/i915/i915_query.c |2 + drivers/gpu/drm/i915/i915_request.c | 143 +- drivers/gpu/drm/i915/i915_request.h | 23 + drivers/gpu/drm/i915/i915_vma.c | 21 +- drivers/gpu/drm/i915/i915_vma.h | 13 +- drivers/gpu/drm/i915/intel_wakeref.h | 12 + .../drm/i915/selftests/i915_live_selftests.h |1 + include/uapi/drm/i915_drm.h | 139 +- 34 files changed, 3038 insertions(+), 701 deletions(-) delete mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c -- 2.32.0
Re: [Intel-gfx] [PATCH] drm/i915: remove IS_ACTIVE
Cc'ing Dan Carpenter
On Fri, Oct 01, 2021 at 12:57:13PM +0300, Jani Nikula wrote:
On Fri, 01 Oct 2021, Chris Wilson wrote:
Quoting Lucas De Marchi (2021-10-01 08:40:41)
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a boolean context. So I also
added the support for handling undefined macros as the IS_ENABLED()
counterpart. However the feedback received from Masahiro Yamada was that
it is too ugly, not providing much value. And just wrapping in a boolean
context is too dumb - we could simply open code it.
As detailed in commit babaab2f4738 ("drm/i915: Encapsulate kconfig
constant values inside boolean predicates"), the IS_ACTIVE macro was
added to workaround a compilation warning. However after checking again
our current uses of IS_ACTIVE it turned out there is only
1 case in which it would potentially trigger a warning. All the others
can simply use the shorter version, without wrapping it in any macro.
And even that single one didn't trigger any warning in gcc 10.3.
So here I'm dialing all the way back to simply removing the macro. If it
triggers warnings in future we may change the few cases to check for > 0
or != 0. Another possibility would be to use the great "not not
operator" for all positive checks, which would allow us to maintain
consistency. However let's try first the simplest form though, hopefully
we don't hit broken compilers spitting a warning:
You didn't prevent the compilation warning this re-introduces.
drivers/gpu/drm/i915/i915_config.c:11 i915_fence_context_timeout() warn: should
this be a bitwise op?
drivers/gpu/drm/i915/i915_request.c:1679 i915_request_wait() warn: should this
be a bitwise op?
Looks like that's a Smatch warning. The immediate fix would be to just
add the != 0 in the relevant places. But this is stuff that's just going
to get broken again unless we add Smatch to CI. Most people aren't
running it on a regular basis.
clang gives a warning only in drivers/gpu/drm/i915/i915_config.c and the
warning is gone if the condition swapped:
- if (context && CONFIG_DRM_I915_FENCE_TIMEOUT)
+ if (CONFIG_DRM_I915_FENCE_TIMEOUT && context)
which would make sense if we think about shortcutting the if condition.
However smatch still reports the warning and an additional one
in drivers/gpu/drm/i915/i915_request.c. The ways I found to stop the
false positives with smatch are:
if (context && CONFIG_DRM_I915_FENCE_TIMEOUT != 0)
or
if (context && !!CONFIG_DRM_I915_FENCE_TIMEOUT)
or
if (context && CONFIG_DRM_I915_FENCE_TIMEOUT > 0)
Dan, anything else that we could do here? This is about this kind of
code:
f (context && CONFIG_DRM_I915_FENCE_TIMEOUT)
in which context is a u64 variable, that gives this warning:
drivers/gpu/drm/i915/i915_config.c:11 i915_fence_context_timeout() warn: should
this be a bitwise op?
thanks
Lucas De Marchi
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: Don't nuke manually around flips (rev2)
== Series Details == Series: drm/i915/fbc: Don't nuke manually around flips (rev2) URL : https://patchwork.freedesktop.org/series/89823/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10681_full -> Patchwork_21236_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21236_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21236_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21236_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-ytiled: - shard-iclb: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-iclb8/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-ytiled.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-iclb1/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-ytiled.html Known issues Here are the changes found in Patchwork_21236_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@chamelium: - shard-tglb: NOTRUN -> [SKIP][3] ([fdo#111827]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-tglb6/igt@feature_discov...@chamelium.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][11] -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-bsd: - shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-tglb1/igt@gem_exec_par...@no-bsd.html * igt@gem_exec_params@secure-non-master: - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#112283]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-tglb1/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-glk7/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][17] -> [SKIP][18] ([i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-tglb1/igt@gem_huc_c...@huc-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@yf-tiled-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#768]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-iclb1/igt@gem_render_c...@yf-tiled-to-vebox-y-tiled.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][20] ([i915#3318]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/shard-apl2/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_mixed_blits: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271]) +91 similar issues
Re: [Intel-gfx] [PATCH 01/28] dma-buf: add dma_resv_for_each_fence_unlocked v7
Am 04.10.21 um 12:50 schrieb Tvrtko Ursulin:
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they might be freed,
improve kerneldoc, rename _cursor to _iter, add
dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end
v3: restructor the code, move rcu_read_lock()/unlock() into the
iterator, add dma_resv_iter_is_restarted()
v4: fix NULL deref when no explicit fence exists, drop superflous
rcu_read_lock()/unlock() calls.
v5: fix typos in the documentation
v6: fix coding error when excl fence is NULL
v7: one more logic fix
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 100
+
include/linux/dma-resv.h | 95
+++
2 files changed, 195 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 84fbe60629e3..3cbcf66a137e 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -323,6 +323,106 @@ void dma_resv_add_excl_fence(struct
dma_resv *obj, struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_resv_add_excl_fence);
+/**
+ * dma_resv_iter_restart_unlocked - restart the unlocked iterator
+ * @cursor: The dma_resv_iter object to restart
+ *
+ * Restart the unlocked iteration by initializing the cursor
object.
+ */
+static void dma_resv_iter_restart_unlocked(struct dma_resv_iter
*cursor)
+{
+ cursor->seq = read_seqcount_begin(>obj->seq);
+ cursor->index = -1;
+ if (cursor->all_fences)
+ cursor->fences = dma_resv_shared_list(cursor->obj);
+ else
+ cursor->fences = NULL;
+ cursor->is_restarted = true;
+}
+
+/**
+ * dma_resv_iter_walk_unlocked - walk over fences in a dma_resv obj
+ * @cursor: cursor to record the current position
+ *
+ * Return all the fences in the dma_resv object which are not
yet signaled.
+ * The returned fence has an extra local reference so will stay
alive.
+ * If a concurrent modify is detected the whole iteration is
started over again.
+ */
+static void dma_resv_iter_walk_unlocked(struct dma_resv_iter
*cursor)
+{
+ struct dma_resv *obj = cursor->obj;
+
+ do {
+ /* Drop the reference from the previous round */
+ dma_fence_put(cursor->fence);
+
+ if (cursor->index == -1) {
+ cursor->fence = dma_resv_excl_fence(obj);
+ cursor->index++;
+ if (!cursor->fence)
+ continue;
+
+ } else if (!cursor->fences ||
+ cursor->index >= cursor->fences->shared_count) {
+ cursor->fence = NULL;
+ break;
+
+ } else {
+ struct dma_resv_list *fences = cursor->fences;
+ unsigned int idx = cursor->index++;
+
+ cursor->fence = rcu_dereference(fences->shared[idx]);
+ }
+ cursor->fence = dma_fence_get_rcu(cursor->fence);
Worth having an assert dma_fence_get_rcu does not fail here? Not
sure that I have seen debug build only asserts though on the DRM
core side.
That won't work. It's perfectly valid for dma_fence_get_rcu() to
return NULL when we are racing here. Keep in mind that we don't
hold any locks.
Ah yes.. No need to change anything then, sorry for the confusion. I
did not find any holes, the rest was just about how to maybe make
the flow more obvious. Let me know if you want r-b now or later.
Now would be good. I've tried to make that more cleaner, but this
only lead to repeating the code more often.
Reviewed-by: Tvrtko Ursulin
Thanks, but what about the rest?
The selftests in this version still have some bugs which I already
fixed, but I think we could push most of the set.
Christian.
Regards,
Tvrtko
Regards,
Christian.
Regards,
Tvrtko
What we could do is to return NULL and repeat with a new sequence
immediately though.
On the bike shedding front, would it be clearer if the continue
condition on signaled fences was standalone, using the continue
statement? I'd also possibly re-arrange the three if-else blocks
so that the end of iteration is not sandwiched between blocks
handling exclusive and shared, and flow tweaked a bit, like:
struct dma_fence *fence = cursor->fence;
int index = cursor->index;
dma_fence_put(fence);
fence = NULL;
next:
if (index == -1) {
/* Try picking the exclusive fence. */
index++;
fence = dma_resv_excl_fence(obj);
if (!fence)
goto next;
} else if (cursor->fences && index <
cursor->fences->shared_count) {
/* Try picking next shared fence. */
struct dma_resv_list *fences = cursor->fences;
fence =
Re: [Intel-gfx] [PATCH v3 12/14] dt-bindings: msm/dp: Add bindings for HDCP registers
On Fri 01 Oct 10:11 CDT 2021, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
>
> We'll use a new compatible string for this since the fields are optional.
>
> Cc: Rob Herring
> Cc: Stephen Boyd
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-13-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-13-s...@poorly.run
> #v2
>
> Changes in v2:
> -Drop register range names (Stephen)
> -Fix yaml errors (Rob)
> Changes in v3:
> -Add new compatible string for dp-hdcp
> -Add descriptions to reg
> -Add minItems/maxItems to reg
> -Make reg depend on the new hdcp compatible string
> ---
>
> Disclaimer: I really don't know if this is the right way to approach
> this. I tried using examples from other bindings, but feedback would be
> very much welcome on how I could add the optional register ranges.
>
>
> .../bindings/display/msm/dp-controller.yaml | 34 ---
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> index 64d8d9e5e47a..a176f97b2f4c 100644
> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> @@ -17,9 +17,10 @@ properties:
>compatible:
> enum:
>- qcom,sc7180-dp
> + - qcom,sc7180-dp-hdcp
>
> - reg:
> -maxItems: 1
> + # See compatible-specific constraints below.
> + reg: true
>
>interrupts:
> maxItems: 1
> @@ -89,6 +90,29 @@ required:
>- power-domains
>- ports
>
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: qcom,sc7180-dp-hdcp
> +then:
> + properties:
> +reg:
> + minItems: 3
> + maxItems: 3
> + items:
> +- description: Registers for base DP functionality
> +- description: (Optional) Registers for HDCP device key injection
> +- description: (Optional) Registers for HDCP TrustZone
> interaction
> +else:
> + properties:
> +reg:
> + minItems: 1
> + maxItems: 1
> + items:
> +- description: Registers for base DP functionality
> +
> additionalProperties: false
>
> examples:
> @@ -99,8 +123,10 @@ examples:
> #include
>
> displayport-controller@ae9 {
> -compatible = "qcom,sc7180-dp";
> -reg = <0xae9 0x1400>;
> +compatible = "qcom,sc7180-dp-hdcp";
> +reg = <0 0x0ae9 0 0x1400>,
> + <0 0x0aed1000 0 0x174>,
> + <0 0x0aee1000 0 0x2c>;
Forgot to mention, #address-cells = #size-cells = <1> in the example
"environment", so you have to omit the lone 0s in the example to make it
pass the tests.
Regards,
Bjorn
> interrupt-parent = <>;
> interrupts = <12>;
> clocks = < DISP_CC_MDSS_AHB_CLK>,
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
Re: [Intel-gfx] [PATCH v3 12/14] dt-bindings: msm/dp: Add bindings for HDCP registers
On Fri 01 Oct 10:11 CDT 2021, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
>
> We'll use a new compatible string for this since the fields are optional.
>
I don't think you need a new compatible, in particular since I presume
we should use the hdcp compatible in all platforms? Or is there a reason
for not picking that one?
Instead I suggest that you simply do minItems: 1, maxItems: 3 and detect
which of the two cases you have in the driver.
PS. I hope to get
https://lore.kernel.org/linux-arm-msm/20211001174400.981707-1-bjorn.anders...@linaro.org/
landed before we add these new optional regions...
Regards,
Bjorn
> Cc: Rob Herring
> Cc: Stephen Boyd
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-13-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-13-s...@poorly.run
> #v2
>
> Changes in v2:
> -Drop register range names (Stephen)
> -Fix yaml errors (Rob)
> Changes in v3:
> -Add new compatible string for dp-hdcp
> -Add descriptions to reg
> -Add minItems/maxItems to reg
> -Make reg depend on the new hdcp compatible string
> ---
>
> Disclaimer: I really don't know if this is the right way to approach
> this. I tried using examples from other bindings, but feedback would be
> very much welcome on how I could add the optional register ranges.
>
>
> .../bindings/display/msm/dp-controller.yaml | 34 ---
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> index 64d8d9e5e47a..a176f97b2f4c 100644
> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> @@ -17,9 +17,10 @@ properties:
>compatible:
> enum:
>- qcom,sc7180-dp
> + - qcom,sc7180-dp-hdcp
>
> - reg:
> -maxItems: 1
> + # See compatible-specific constraints below.
> + reg: true
>
>interrupts:
> maxItems: 1
> @@ -89,6 +90,29 @@ required:
>- power-domains
>- ports
>
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: qcom,sc7180-dp-hdcp
> +then:
> + properties:
> +reg:
> + minItems: 3
> + maxItems: 3
> + items:
> +- description: Registers for base DP functionality
> +- description: (Optional) Registers for HDCP device key injection
> +- description: (Optional) Registers for HDCP TrustZone
> interaction
> +else:
> + properties:
> +reg:
> + minItems: 1
> + maxItems: 1
> + items:
> +- description: Registers for base DP functionality
> +
> additionalProperties: false
>
> examples:
> @@ -99,8 +123,10 @@ examples:
> #include
>
> displayport-controller@ae9 {
> -compatible = "qcom,sc7180-dp";
> -reg = <0xae9 0x1400>;
> +compatible = "qcom,sc7180-dp-hdcp";
> +reg = <0 0x0ae9 0 0x1400>,
> + <0 0x0aed1000 0 0x174>,
> + <0 0x0aee1000 0 0x2c>;
> interrupt-parent = <>;
> interrupts = <12>;
> clocks = < DISP_CC_MDSS_AHB_CLK>,
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
[Intel-gfx] [PULL] drm-intel-next
Hi Dave and Daniel, Here goes an accumulated pull request. A special highlight to the ADL-P (XE_LPD) and DG2 display support preparation and on a big clean-up in the display portion of the driver. Here goes drm-intel-next-2021-10-04: Cross-subsystem Changes: - fbdev/efifb: Release PCI device's runtime PM ref during FB destr\ oy (Imre) i915 Core Driver Changes: - Only access SFC_DONE in media when not fused off for graphics 12 and newer. - Double Memory latency values from pcode for DG2 (Matt Roper) - ADL-S PCI ID update (Tejas) - New DG1 PCI ID (Jose) - Fix regression with uncore refactoring (Dave) i915 Display Changes: - ADL-P display (XE_LPD) fixes and updates (Ankit, Jani, Matt Roper, Anusham, Jose, Imre, Vandita) - DG2 display fixes (Ankit, Jani) - Expand PCH_CNP tweaked display workaround to all newer displays (Anshuman) - General display simplifications and clean-ups (Jani, Swati, Jose, Ville) - PSR Clean-ups, dropping support for BDW/HSD and enable PSR2 selective fetch by default (Jose, Gwan-gyeong) - Nuke ORIGIN_GTT (Jose) - Return proper DPRX link training result (Lee) - FBC related refactor and fixes (Ville) - Yet another attempt to solve the fast+narrow vs slow+wide eDP link training (Kai-Heng) - DP 2.0 preparation work (Jani) - Silence __iomem sparse warn (Ville) - Clean up DPLL stuff (Ville) - Fix various dp/edp max rates (Matt Atwood, Animesh, Jani) - Remove VBT ddi_port_info caching (Jani) - DSI driver improvements (Lee) - HDCP fixes (Juston) - Associate ACPI connector nodes with connector entries (Heikki) - Add support for out-of-bound hotplug events (Hans) - VESA vendor block and drm/i915 MSO use of it (Jani) - Fixes for bigjoiner (Ville) - Update memory bandwidth parameters (RK) - DMC related fixes (Chris, Jose) - HDR related fixes and improvements (Tejas) - g4x/vlv/chv CxSR/wm fixes/cleanups (Ville) - Use BIOS provided value for RKL Audio's HDA link (Kai-Heng) - Fix the dsc check while selecting min_cdclk (Vandita) - Split and constify vtable (Dave) - Add ww context to intel_dpt_pin (Maarten) - Fix bdb version check (Lukasz) - DP per-lane drive settings prep work and other DP fixes (Ville) Thanks, Rodrigo. The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f: Linux 5.15-rc1 (2021-09-12 16:28:37 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-10-04 for you to fetch changes up to 104c1b3d6fb6a794babd5e2ffd6a5183b5a3d6c7: drm/i915: Allow per-lane drive settings with LTTPRs (2021-10-04 13:04:36 +0300) Cross-subsystem Changes: - fbdev/efifb: Release PCI device's runtime PM ref during FB destr\ oy (Imre) i915 Core Driver Changes: - Only access SFC_DONE in media when not fused off for graphics 12 and newer. - Double Memory latency values from pcode for DG2 (Matt Roper) - ADL-S PCI ID update (Tejas) - New DG1 PCI ID (Jose) - Fix regression with uncore refactoring (Dave) i915 Display Changes: - ADL-P display (XE_LPD) fixes and updates (Ankit, Jani, Matt Roper, Anusham, Jose, Imre, Vandita) - DG2 display fixes (Ankit, Jani) - Expand PCH_CNP tweaked display workaround to all newer displays (Anshuman) - General display simplifications and clean-ups (Jani, Swati, Jose, Ville) - PSR Clean-ups, dropping support for BDW/HSD and enable PSR2 selective fetch by default (Jose, Gwan-gyeong) - Nuke ORIGIN_GTT (Jose) - Return proper DPRX link training result (Lee) - FBC related refactor and fixes (Ville) - Yet another attempt to solve the fast+narrow vs slow+wide eDP link training (Kai-Heng) - DP 2.0 preparation work (Jani) - Silence __iomem sparse warn (Ville) - Clean up DPLL stuff (Ville) - Fix various dp/edp max rates (Matt Atwood, Animesh, Jani) - Remove VBT ddi_port_info caching (Jani) - DSI driver improvements (Lee) - HDCP fixes (Juston) - Associate ACPI connector nodes with connector entries (Heikki) - Add support for out-of-bound hotplug events (Hans) - VESA vendor block and drm/i915 MSO use of it (Jani) - Fixes for bigjoiner (Ville) - Update memory bandwidth parameters (RK) - DMC related fixes (Chris, Jose) - HDR related fixes and improvements (Tejas) - g4x/vlv/chv CxSR/wm fixes/cleanups (Ville) - Use BIOS provided value for RKL Audio's HDA link (Kai-Heng) - Fix the dsc check while selecting min_cdclk (Vandita) - Split and constify vtable (Dave) - Add ww context to intel_dpt_pin (Maarten) - Fix bdb version check (Lukasz) - DP per-lane drive settings prep work and other DP fixes (Ville) Animesh Manna (3): drm/i915/dg2: UHBR tables added for pll programming drm/i915/dp: fix EHL/JSL max source rates calculation drm/i915/dp: fix for ADL_P/S dp/edp max source rates Ankit Nautiyal (2): drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg drm/i915/dg2: Configure PCON in DP pre-enable path Anshuman Gupta (1): drm/i915:
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend the async flip VT-d w/a to skl/bxt
On Mon, Oct 04, 2021 at 10:50:00AM -0700, Matt Roper wrote: > On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote: > > On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote: > > > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > Looks like skl/bxt/derivatives also need the plane stride > > > > stretch w/a when using async flips and VT-d is enabled, or > > > > else we get corruption on screen. To my surprise this was > > > > even documented in bspec, but only as a note on the > > > > CHICHKEN_PIPESL register description rather than on the > > > > w/a list. > > > > > > > > So very much the same thing as on HSW/BDW, except the bits > > > > moved yet again. > > > > > > Bspec 7522 doesn't say anything about this requirement being tied to > > > VT-d on these platforms. Should we drop the intel_vtd_active() > > > condition to be safe? > > > > I think it's just an oversight in bspec. I read through the hsd and > > IIRC it did specify that it's VT-d only. Also real life confirms > > it. No problems whatsoever when VT-d is disabled. > > I notice there are additional bits that we should set to apply this > workaround to planes 2, 3, and 4, but since i915 still artificially > limits async flips to just the primary plane, only programming bits 1:0 > should be fine for now; we'll just need to remember to extend this > workaround if we do start allowing async flips on other planes in the > future. Aye. gen8_de_pipe_flip_done_mask() is the other place where we still hardcode this for plane 1 only. I think the rest of the code I did end up making more or less plane agnostic already. I was considering at least parametrizing the register defines but then I got a nagging feeling that I once ran into some issues while trying to stick non-constant numbers into REG_BIT & co. So I decided to hardcode plane 1 for the moment. > > Reviewed-by: Matt Roper Thanks. Pushed. -- Ville Syrjälä Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/atomic: Add the crtc to affected crtc only if uapi.enable = true (rev3)
== Series Details ==
Series: drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
(rev3)
URL : https://patchwork.freedesktop.org/series/87555/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10681_full -> Patchwork_21235_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_21235_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@sysfs_heartbeat_interval@precise@vecs0:
- {shard-rkl}:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-rkl-1/igt@sysfs_heartbeat_interval@prec...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-rkl-1/igt@sysfs_heartbeat_interval@prec...@vecs0.html
Known issues
Here are the changes found in Patchwork_21235_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][3] ([fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb1/igt@feature_discov...@chamelium.html
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][4] ([i915#1839])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb1/igt@feature_discov...@display-4x.html
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][5] ([i915#3002])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-apl7/igt@gem_cre...@create-massive.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl: NOTRUN -> [DMESG-WARN][6] ([i915#180])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_ctx_persistence@idempotent:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-snb2/igt@gem_ctx_persiste...@idempotent.html
* igt@gem_ctx_sseu@engines:
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#280])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb1/igt@gem_ctx_s...@engines.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109283])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb6/igt@gem_exec_par...@no-bsd.html
* igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][14] ([fdo#112283])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb6/igt@gem_exec_par...@secure-non-master.html
* igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118] /
[i915#95]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-glk4/igt@gem_exec_whis...@basic-queues-forked-all.html
* igt@gem_render_copy@yf-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-iclb6/igt@gem_render_c...@yf-tiled-to-vebox-y-tiled.html
* igt@gem_userptr_blits@coherency-sync:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#110542])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb1/igt@gem_userptr_bl...@coherency-sync.html
* igt@gem_userptr_blits@vma-merge:
- shard-apl: NOTRUN -> [FAIL][19] ([i915#3318])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-apl2/igt@gem_userptr_bl...@vma-merge.html
* igt@gen3_mixed_blits:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/shard-tglb1/igt@gen3_mixed_blits.html
* igt@gen7_exec_parse@basic-offset:
- shard-apl: NOTRUN ->
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Add privacy-screen support (v2)
On Mon, Oct 04, 2021 at 06:02:21PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> > On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> >> Add support for eDP panels with a built-in privacy screen using the
> >> new drm_privacy_screen class.
> >>
> >> Changes in v2:
> >> - Call drm_connector_update_privacy_screen() from
> >> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
> >> for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
> >> - Move the probe-deferral check to the intel_modeset_probe_defer() helper
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> >> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
> >> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> >> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
> >> 4 files changed, 24 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> >> b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> index b4e7ac51aa31..a62550711e98 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> @@ -139,6 +139,7 @@ int intel_digital_connector_atomic_check(struct
> >> drm_connector *conn,
> >>new_conn_state->base.picture_aspect_ratio !=
> >> old_conn_state->base.picture_aspect_ratio ||
> >>new_conn_state->base.content_type !=
> >> old_conn_state->base.content_type ||
> >>new_conn_state->base.scaling_mode !=
> >> old_conn_state->base.scaling_mode ||
> >> + new_conn_state->base.privacy_screen_sw_state !=
> >> old_conn_state->base.privacy_screen_sw_state ||
> >>!drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
> >>crtc_state->mode_changed = true;
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> >> b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> index 51cd0420e00e..e4496c830a35 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> @@ -25,6 +25,7 @@
> >> *
> >> */
> >>
> >> +#include
> >> #include
> >>
> >> #include "i915_drv.h"
> >> @@ -3022,6 +3023,7 @@ static void intel_enable_ddi_dp(struct
> >> intel_atomic_state *state,
> >>if (port == PORT_A && DISPLAY_VER(dev_priv) < 9)
> >>intel_dp_stop_link_train(intel_dp, crtc_state);
> >>
> >> + drm_connector_update_privacy_screen(conn_state);
> >>intel_edp_backlight_on(crtc_state, conn_state);
> >>
> >>if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
> >> @@ -3247,6 +3249,7 @@ static void intel_ddi_update_pipe_dp(struct
> >> intel_atomic_state *state,
> >>intel_drrs_update(intel_dp, crtc_state);
> >>
> >>intel_backlight_update(state, encoder, crtc_state, conn_state);
> >> + drm_connector_update_privacy_screen(conn_state);
> >> }
> >>
> >> void intel_ddi_update_pipe(struct intel_atomic_state *state,
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index e67f3207ba54..9a5dbe51458d 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -42,6 +42,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -12693,6 +12694,8 @@ void intel_modeset_driver_remove_nogem(struct
> >> drm_i915_private *i915)
> >>
> >> bool intel_modeset_probe_defer(struct pci_dev *pdev)
> >> {
> >> + struct drm_privacy_screen *privacy_screen;
> >> +
> >>/*
> >> * apple-gmux is needed on dual GPU MacBook Pro
> >> * to probe the panel if we're the inactive GPU.
> >> @@ -12700,6 +12703,13 @@ bool intel_modeset_probe_defer(struct pci_dev
> >> *pdev)
> >>if (vga_switcheroo_client_probe_defer(pdev))
> >>return true;
> >>
> >> + /* If the LCD panel has a privacy-screen, wait for it */
> >> + privacy_screen = drm_privacy_screen_get(>dev, NULL);
> >> + if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
> >> + return true;
> >> +
> >> + drm_privacy_screen_put(privacy_screen);
> >> +
> >>return false;
> >> }
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 74a657ae131a..91207310dc0d 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -37,6 +37,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> #include "g4x_dp.h"
> >> @@ -4808,6 +4809,7 @@ static bool intel_edp_init_connector(struct intel_dp
> >> *intel_dp,
> >>struct drm_connector *connector = _connector->base;
> >>struct drm_display_mode *fixed_mode = NULL;
> >>struct drm_display_mode *downclock_mode = NULL;
> >> + struct drm_privacy_screen
Re: [Intel-gfx] [PATCH v2] drm/i915: Clean up disabled warnings
On Tue, 14 Sep 2021, Nathan Chancellor wrote:
> i915 enables a wider set of warnings with '-Wall -Wextra' then disables
> several with cc-disable-warning. If an unknown flag gets added to
> KBUILD_CFLAGS when building with clang, all subsequent calls to
> cc-{disable-warning,option} will fail, meaning that all of these
> warnings do not get disabled [1].
>
> A separate series will address the root cause of the issue by not adding
> these flags when building with clang [2]; however, the symptom of these
> extra warnings appearing can be addressed separately by just removing
> the calls to cc-disable-warning, which makes the build ever so slightly
> faster because the compiler does not need to be called as much before
> building.
>
> The following warnings are supported by GCC 4.9 and clang 10.0.1, which
> are the minimum supported versions of these compilers so the call to
> cc-disable-warning is not necessary. Masahiro cleaned this up for the
> reset of the kernel in commit 4c8dd95a723d ("kbuild: add some extra
> warning flags unconditionally").
>
> * -Wmissing-field-initializers
> * -Wsign-compare
> * -Wtype-limits
> * -Wunused-parameter
>
> -Wunused-but-set-variable was implemented in clang 13.0.0 and
> -Wframe-address was implemented in clang 12.0.0 so the
> cc-disable-warning calls are kept for these two warnings.
>
> Lastly, -Winitializer-overrides is clang's version of -Woverride-init,
> which is disabled for the specific files that are problematic. clang
> added a compatibility alias in clang 8.0.0 so -Winitializer-overrides
> can be removed.
>
> [1]: https://lore.kernel.org/r/202108210311.cbtcgoul-...@intel.com/
> [2]: https://lore.kernel.org/r/20210824022640.2170859-1-nat...@kernel.org/
>
> Reviewed-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
Thanks for the patch, and sorry for the delay.
Exceptionally pushed to drm-intel-gt-next instead of drm-intel-next
because some of the dependencies such as 43192617f781 ("drm/i915: Enable
-Wsometimes-uninitialized") were queued there too.
BR,
Jani.
> ---
>
> v1 -> v2:
> https://lore.kernel.org/r/20210824232237.2085342-1-nat...@kernel.org/
>
> * Rebase on drm-intel-gt-next now that the prerequisite patch series has
> been merged: https://lore.kernel.org/r/87wnnj13t5@intel.com/
>
> * Add Nick's reviewed-by tag.
>
> drivers/gpu/drm/i915/Makefile | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c584188aa15a..fd99374583d5 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -13,13 +13,11 @@
> # will most likely get a sudden build breakage... Hopefully we will fix
> # new warnings before CI updates!
> subdir-ccflags-y := -Wall -Wextra
> -subdir-ccflags-y += $(call cc-disable-warning, unused-parameter)
> -subdir-ccflags-y += $(call cc-disable-warning, type-limits)
> -subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
> +subdir-ccflags-y += -Wno-unused-parameter
> +subdir-ccflags-y += -Wno-type-limits
> +subdir-ccflags-y += -Wno-missing-field-initializers
> +subdir-ccflags-y += -Wno-sign-compare
> subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
> -# clang warnings
> -subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
> -subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
> subdir-ccflags-y += $(call cc-disable-warning, frame-address)
> subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
>
>
> base-commit: 43192617f7816bb74584c1df06f57363afd15337
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] i915 MST HDCP code looks broken
On Mon, Oct 04, 2021 at 03:04:01PM +, Gupta, Anshuman wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Monday, October 4, 2021 4:22 PM > > To: intel-gfx@lists.freedesktop.org > > Cc: Sean Paul ; Gupta, Anshuman > > ; C, Ramalingam ; B S, > > Karthik > > Subject: i915 MST HDCP code looks broken > > > > Hi, > > > > I took a quick peek at intel_dp_add_mst_connector() the other day and > > noticed > > that it calls intel_dp_hdcp_init() and passes in the SST dig_port. And > > digging in a > > bit further that seems to clobber all kinds of things in > > dig_port->hdcp_port_data. > > This looks rather broken to me. > > > > So has anyone actually thought what happens if you first use MST on the > > port, > > and then later switch to SST on the same port? > AFAIU there shouldn't be , when the last connector of MST topology get > destroyed and it switches to SST mode on same port. > The base static connector of same dig_port should get connected and will call > intel_dp_init_connector()->intel_dp_hdcp_init(). SST conectors are static. They are created exactly once when the driver loads. -- Ville Syrjälä Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy()
== Series Details == Series: drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy() URL : https://patchwork.freedesktop.org/series/95402/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10681_full -> Patchwork_21232_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21232_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21232_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21232_full: ### IGT changes ### Possible regressions * igt@kms_psr@sprite_blt: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-skl6/igt@kms_psr@sprite_blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-skl8/igt@kms_psr@sprite_blt.html Known issues Here are the changes found in Patchwork_21232_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@chamelium: - shard-tglb: NOTRUN -> [SKIP][3] ([fdo#111827]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb5/igt@feature_discov...@chamelium.html * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#1839]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb8/igt@feature_discov...@display-4x.html * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][5] ([i915#3002]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-apl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-apl: NOTRUN -> [DMESG-WARN][6] ([i915#180]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-apl7/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][8] ([i915#280]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb8/igt@gem_ctx_s...@engines.html * igt@gem_eio@in-flight-contexts-10ms: - shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#3063]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb8/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_eio@in-flight-suspend: - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#456]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-tglb6/igt@gem_...@in-flight-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb7/igt@gem_...@in-flight-suspend.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-glk5/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-bsd: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109283]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb1/igt@gem_exec_par...@no-bsd.html * igt@gem_exec_params@secure-non-master: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#112283]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/shard-tglb1/igt@gem_exec_par...@secure-non-master.html * igt@gem_render_copy@yf-tiled-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#768]) [21]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Improve DP link training further (rev2)
== Series Details == Series: drm/i915: Improve DP link training further (rev2) URL : https://patchwork.freedesktop.org/series/95405/ State : failure == Summary == Applying: drm/i915: Tweak the DP "max vswing reached?" condition Applying: drm/i915: Show LTTPR in the TPS debug print Applying: drm/i915: Print the DP vswing adjustment request error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_dp_link_training.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/i915: Print the DP vswing adjustment request When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] [PATCH v2 5/5] drm/i915: Call intel_dp_dump_link_status() for CR failures
From: Ville Syrjälä
I suppose intel_dp_dump_link_status() might be useful for diagnosing
link training failures. Hoever we only call from the channel EQ phase
currently. Let's call it from the CR phase as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 18f4b469766e..c92044710012 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -649,6 +649,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
u8 old_link_status[DP_LINK_STATUS_SIZE] = {};
int voltage_tries, cr_tries, max_cr_tries;
+ u8 link_status[DP_LINK_STATUS_SIZE];
bool max_vswing_reached = false;
char phy_name[10];
@@ -678,8 +679,6 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
voltage_tries = 1;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
- u8 link_status[DP_LINK_STATUS_SIZE];
-
intel_dp_link_training_clock_recovery_delay(intel_dp, dp_phy);
if (drm_dp_dpcd_read_phy_link_status(_dp->aux, dp_phy,
@@ -697,6 +696,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
}
if (voltage_tries == 5) {
+ intel_dp_dump_link_status(intel_dp, dp_phy,
link_status);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s][%s] Same voltage tried 5
times\n",
encoder->base.base.id, encoder->base.name,
phy_name);
@@ -704,6 +704,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
}
if (max_vswing_reached) {
+ intel_dp_dump_link_status(intel_dp, dp_phy,
link_status);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s][%s] Max Voltage Swing
reached\n",
encoder->base.base.id, encoder->base.name,
phy_name);
@@ -732,6 +733,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
max_vswing_reached = true;
}
+ intel_dp_dump_link_status(intel_dp, dp_phy, link_status);
drm_err(>drm,
"[ENCODER:%d:%s][%s] Failed clock recovery %d times, giving
up!\n",
encoder->base.base.id, encoder->base.name, phy_name,
max_cr_tries);
--
2.32.0
[Intel-gfx] [PATCH v2 0/5] drm/i915: Improve DP link training further
From: Ville Syrjälä A little bit more generic DP link training improvements before we finally get to the actual per-lane drive settings PHY programming stuff. v2: CI is confused about sha1s for some reason Ville Syrjälä (5): drm/i915: Tweak the DP "max vswing reached?" condition drm/i915: Show LTTPR in the TPS debug print drm/i915: Print the DP vswing adjustment request drm/i915: Pimp link training debug prints drm/i915: Call intel_dp_dump_link_status() for CR failures drivers/gpu/drm/i915/display/g4x_dp.c | 2 +- .../drm/i915/display/intel_dp_link_training.c | 217 +- .../drm/i915/display/intel_dp_link_training.h | 1 + 3 files changed, 157 insertions(+), 63 deletions(-) -- 2.32.0
[Intel-gfx] [PATCH v2 2/5] drm/i915: Show LTTPR in the TPS debug print
From: Ville Syrjälä
Indicate which LTTPR we're currently attempting to train when
we print which training pattern we're using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 11 +++
drivers/gpu/drm/i915/display/intel_dp_link_training.h | 1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index 60ae2ba52006..85a09c3e09e8 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -637,7 +637,7 @@ static void intel_dp_enable_port(struct intel_dp *intel_dp,
/* enable with pattern 1 (as per spec) */
intel_dp_program_link_training_pattern(intel_dp, crtc_state,
- DP_TRAINING_PATTERN_1);
+ DP_PHY_DPRX,
DP_TRAINING_PATTERN_1);
/*
* Magic for VLV/CHV. We _must_ first set up the register
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index a45569b8c959..6bab097cafd2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -376,7 +376,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
int len;
intel_dp_program_link_training_pattern(intel_dp, crtc_state,
- dp_train_pat);
+ dp_phy, dp_train_pat);
buf[0] = dp_train_pat;
/* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
@@ -404,17 +404,20 @@ static char dp_training_pattern_name(u8 train_pat)
void
intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state,
+ enum drm_dp_phy dp_phy,
u8 dp_train_pat)
{
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u8 train_pat = intel_dp_training_pattern_symbol(dp_train_pat);
+ char phy_name[10];
if (train_pat != DP_TRAINING_PATTERN_DISABLE)
drm_dbg_kms(_priv->drm,
- "[ENCODER:%d:%s] Using DP training pattern TPS%c\n",
+ "[ENCODER:%d:%s] Using DP training pattern TPS%c,
at %s\n",
encoder->base.base.id, encoder->base.name,
- dp_training_pattern_name(train_pat));
+ dp_training_pattern_name(train_pat),
+ intel_dp_phy_name(dp_phy, phy_name,
sizeof(phy_name)));
intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
}
@@ -855,7 +858,7 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp,
intel_dp->link_trained = true;
intel_dp_disable_dpcd_training_pattern(intel_dp, DP_PHY_DPRX);
- intel_dp_program_link_training_pattern(intel_dp, crtc_state,
+ intel_dp_program_link_training_pattern(intel_dp, crtc_state,
DP_PHY_DPRX,
DP_TRAINING_PATTERN_DISABLE);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 9d24d594368c..6a3a7b37349a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -19,6 +19,7 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8 link_status[DP_LINK_STATUS_SIZE]);
void intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state,
+ enum drm_dp_phy dp_phy,
u8 dp_train_pat);
void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
--
2.32.0
Re: [Intel-gfx] [PATCH 2/2] drm/i195: Make the async flip VT-d workaround dynamic
On Thu, Sep 30, 2021 at 10:09:43PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since the VT-d vs. async flip issues are plaguing a wider range
> of supported hw let's try to minimize the impact on normal
> operation by flipping the relevant chicken bits on and off
> as needed. I presume there is some power/perf impact on since
> this is reducing some prefetching I think.
>
> Cc: Karthik B S
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 35
> drivers/gpu/drm/i915/intel_pm.c | 26 ---
> 2 files changed, 35 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a4453dd1bb51..5407f53e770b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2473,6 +2473,33 @@ static bool needs_cursorclk_wa(const struct
> intel_crtc_state *crtc_state)
> return false;
> }
>
> +static void intel_async_flip_vtd_wa(struct drm_i915_private *i915,
> + enum pipe pipe, bool enable)
> +{
> + if (DISPLAY_VER(i915) == 9) {
> + /*
> + * "Plane N strech max must be programmed to 11b (x1)
> + * when Async flips are enabled on that plane."
> + */
> + intel_de_rmw(i915, CHICKEN_PIPESL_1(pipe),
> + SKL_PLANE1_STRETCH_MAX_MASK,
> + enable ? SKL_PLANE1_STRETCH_MAX_X1 :
> SKL_PLANE1_STRETCH_MAX_X8);
> + } else {
> + /* Also needed on HSW/BDW albeit undocumented */
> + intel_de_rmw(i915, CHICKEN_PIPESL_1(pipe),
> + HSW_PRI_STRETCH_MAX_MASK,
> + enable ? HSW_PRI_STRETCH_MAX_X1 :
> HSW_PRI_STRETCH_MAX_X8);
> + }
> +}
> +
> +static bool needs_async_flip_vtd_wa(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + return crtc_state->uapi.async_flip && intel_vtd_active() &&
> + (DISPLAY_VER(i915) == 9 || IS_BROADWELL(i915) ||
> IS_HASWELL(i915));
> +}
> +
> static bool planes_enabling(const struct intel_crtc_state *old_crtc_state,
> const struct intel_crtc_state *new_crtc_state)
> {
> @@ -2508,6 +2535,10 @@ static void intel_post_plane_update(struct
> intel_atomic_state *state,
> intel_fbc_post_update(state, crtc);
> intel_drrs_page_flip(state, crtc);
>
> + if (needs_async_flip_vtd_wa(old_crtc_state) &&
> + !needs_async_flip_vtd_wa(new_crtc_state))
> + intel_async_flip_vtd_wa(dev_priv, pipe, false);
> +
> if (needs_nv12_wa(old_crtc_state) &&
> !needs_nv12_wa(new_crtc_state))
> skl_wa_827(dev_priv, pipe, false);
> @@ -2606,6 +2637,10 @@ static void intel_pre_plane_update(struct
> intel_atomic_state *state,
> if (intel_fbc_pre_update(state, crtc))
> intel_wait_for_vblank(dev_priv, pipe);
>
> + if (!needs_async_flip_vtd_wa(old_crtc_state) &&
> + needs_async_flip_vtd_wa(new_crtc_state))
> + intel_async_flip_vtd_wa(dev_priv, pipe, true);
> +
> /* Display WA 827 */
> if (!needs_nv12_wa(old_crtc_state) &&
> needs_nv12_wa(new_crtc_state))
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 74d4620a4999..73178d0cf0c9 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -76,8 +76,6 @@ struct intel_wm_config {
>
> static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - enum pipe pipe;
> -
> if (HAS_LLC(dev_priv)) {
> /*
>* WaCompressedResourceDisplayNewHashMode:skl,kbl
> @@ -91,16 +89,6 @@ static void gen9_init_clock_gating(struct drm_i915_private
> *dev_priv)
> SKL_DE_COMPRESSED_HASH_MODE);
> }
>
> - for_each_pipe(dev_priv, pipe) {
> - /*
> - * "Plane N strech max must be programmed to 11b (x1)
> - * when Async flips are enabled on that plane."
> - */
> - if (!IS_GEMINILAKE(dev_priv) && intel_vtd_active())
> - intel_uncore_rmw(_priv->uncore,
> CHICKEN_PIPESL_1(pipe),
> - SKL_PLANE1_STRETCH_MAX_MASK,
> SKL_PLANE1_STRETCH_MAX_X1);
> - }
> -
> /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl,cfl */
> intel_uncore_write(_priv->uncore, CHICKEN_PAR1_1,
> intel_uncore_read(_priv->uncore, CHICKEN_PAR1_1) |
> SKL_EDP_PSR_FIX_RDWRAP);
> @@ -7599,11 +7587,6 @@ static void bdw_init_clock_gating(struct
> drm_i915_private *dev_priv)
> intel_uncore_write(_priv->uncore, CHICKEN_PIPESL_1(pipe),
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend the async flip VT-d w/a to skl/bxt
On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Looks like skl/bxt/derivatives also need the plane stride
> > > stretch w/a when using async flips and VT-d is enabled, or
> > > else we get corruption on screen. To my surprise this was
> > > even documented in bspec, but only as a note on the
> > > CHICHKEN_PIPESL register description rather than on the
> > > w/a list.
> > >
> > > So very much the same thing as on HSW/BDW, except the bits
> > > moved yet again.
> >
> > Bspec 7522 doesn't say anything about this requirement being tied to
> > VT-d on these platforms. Should we drop the intel_vtd_active()
> > condition to be safe?
>
> I think it's just an oversight in bspec. I read through the hsd and
> IIRC it did specify that it's VT-d only. Also real life confirms
> it. No problems whatsoever when VT-d is disabled.
I notice there are additional bits that we should set to apply this
workaround to planes 2, 3, and 4, but since i915 still artificially
limits async flips to just the primary plane, only programming bits 1:0
should be fine for now; we'll just need to remember to extend this
workaround if we do start allowing async flips on other planes in the
future.
Reviewed-by: Matt Roper
>
> >
> >
> > Matt
> >
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: Karthik B S
> > > Fixes: 55ea1cb178ef ("drm/i915: Enable async flips in i915")
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 5 +
> > > drivers/gpu/drm/i915/intel_pm.c | 12
> > > 2 files changed, 17 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 3a20a55d2512..29f6bfc2002d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -8222,6 +8222,11 @@ enum {
> > > #define HSW_SPR_STRETCH_MAX_X1
> > > REG_FIELD_PREP(HSW_SPR_STRETCH_MAX_MASK, 3)
> > > #define HSW_FBCQ_DIS(1 << 22)
> > > #define BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
> > > +#define SKL_PLANE1_STRETCH_MAX_MASK REG_GENMASK(1, 0)
> > > +#define SKL_PLANE1_STRETCH_MAX_X8
> > > REG_FIELD_PREP(SKL_PLANE1_STRETCH_MAX_MASK, 0)
> > > +#define SKL_PLANE1_STRETCH_MAX_X4
> > > REG_FIELD_PREP(SKL_PLANE1_STRETCH_MAX_MASK, 1)
> > > +#define SKL_PLANE1_STRETCH_MAX_X2
> > > REG_FIELD_PREP(SKL_PLANE1_STRETCH_MAX_MASK, 2)
> > > +#define SKL_PLANE1_STRETCH_MAX_X1
> > > REG_FIELD_PREP(SKL_PLANE1_STRETCH_MAX_MASK, 3)
> > > #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
> > > _CHICKEN_PIPESL_1_B)
> > >
> > > #define _CHICKEN_TRANS_A 0x420c0
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index ef5f73934dab..74d4620a4999 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -76,6 +76,8 @@ struct intel_wm_config {
> > >
> > > static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> > > {
> > > + enum pipe pipe;
> > > +
> > > if (HAS_LLC(dev_priv)) {
> > > /*
> > >* WaCompressedResourceDisplayNewHashMode:skl,kbl
> > > @@ -89,6 +91,16 @@ static void gen9_init_clock_gating(struct
> > > drm_i915_private *dev_priv)
> > > SKL_DE_COMPRESSED_HASH_MODE);
> > > }
> > >
> > > + for_each_pipe(dev_priv, pipe) {
> > > + /*
> > > + * "Plane N strech max must be programmed to 11b (x1)
> > > + * when Async flips are enabled on that plane."
> > > + */
> > > + if (!IS_GEMINILAKE(dev_priv) && intel_vtd_active())
> > > + intel_uncore_rmw(_priv->uncore,
> > > CHICKEN_PIPESL_1(pipe),
> > > + SKL_PLANE1_STRETCH_MAX_MASK,
> > > SKL_PLANE1_STRETCH_MAX_X1);
> > > + }
> > > +
> > > /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl,cfl */
> > > intel_uncore_write(_priv->uncore, CHICKEN_PAR1_1,
> > > intel_uncore_read(_priv->uncore, CHICKEN_PAR1_1) |
> > > SKL_EDP_PSR_FIX_RDWRAP);
> > > --
> > > 2.32.0
> > >
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
>
> --
> Ville Syrjälä
> Intel
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
[Intel-gfx] [PATCH v2 3/5] drm/i915: Print the DP vswing adjustment request
From: Ville Syrjälä
Print out each DP vswing adjustment request we got from the RX.
Could help in diagnosing what's going on during link training.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 6bab097cafd2..5657be1461ec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -343,14 +343,41 @@ static u8 intel_dp_get_lane_adjust_train(struct intel_dp
*intel_dp,
return v | p;
}
+#define TRAIN_REQ_FMT "%d/%d/%d/%d"
+#define _TRAIN_REQ_VSWING_ARGS(link_status, lane) \
+ (drm_dp_get_adjust_request_voltage((link_status), (lane)) >>
DP_TRAIN_VOLTAGE_SWING_SHIFT)
+#define TRAIN_REQ_VSWING_ARGS(link_status) \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 0), \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 1), \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 2), \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 3)
+#define _TRAIN_REQ_PREEMPH_ARGS(link_status, lane) \
+ (drm_dp_get_adjust_request_pre_emphasis((link_status), (lane)) >>
DP_TRAIN_PRE_EMPHASIS_SHIFT)
+#define TRAIN_REQ_PREEMPH_ARGS(link_status) \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 0), \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 1), \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 2), \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 3)
+
void
intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
enum drm_dp_phy dp_phy,
const u8 link_status[DP_LINK_STATUS_SIZE])
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ char phy_name[10];
int lane;
+ drm_dbg_kms(encoder->base.dev, "[ENCODER:%d:%s] lanes: %d, "
+ "vswing request: " TRAIN_REQ_FMT ", "
+ "pre-emphasis request: " TRAIN_REQ_FMT ", at %s\n",
+ encoder->base.base.id, encoder->base.name,
+ crtc_state->lane_count,
+ TRAIN_REQ_VSWING_ARGS(link_status),
+ TRAIN_REQ_PREEMPH_ARGS(link_status),
+ intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)));
+
for (lane = 0; lane < 4; lane++)
intel_dp->train_set[lane] =
intel_dp_get_lane_adjust_train(intel_dp, crtc_state,
--
2.32.0
[Intel-gfx] [PATCH v2 4/5] drm/i915: Pimp link training debug prints
From: Ville Syrjälä
Unify all debug prints during link training to include information
on both the encoder and the LTTPR. We unify the format to something
like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not
sure if those brackets around the dp_phy just make it look like
line noise? I'll accept suggestions on better formatting.
I'm slightly on the fence about also including the connector,
but technically only the DPRX is the SST connector (ie.
intel_dp->attached_connector). I suppose you could think of it
as the branch device/whatever in the topology, and we're training
the link leading to it. So that could argue for its inclusion.
But it's all getting a bit long alrady, so not going to do it
I think.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 167 +++---
1 file changed, 106 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 5657be1461ec..18f4b469766e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -25,15 +25,6 @@
#include "intel_dp.h"
#include "intel_dp_link_training.h"
-static void
-intel_dp_dump_link_status(struct drm_device *drm,
- const u8 link_status[DP_LINK_STATUS_SIZE])
-{
- drm_dbg_kms(drm,
- "ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x adj_req0_1:0x%x
adj_req2_3:0x%x\n",
- link_status[0], link_status[1], link_status[2],
- link_status[3], link_status[4], link_status[5]);
-}
static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
{
@@ -66,6 +57,7 @@ static u8 *intel_dp_lttpr_phy_caps(struct intel_dp *intel_dp,
static void intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp,
enum drm_dp_phy dp_phy)
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
char phy_name[10];
@@ -73,21 +65,22 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp
*intel_dp,
if (drm_dp_read_lttpr_phy_caps(_dp->aux, dp_phy, phy_caps) < 0) {
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "failed to read the PHY caps for %s\n",
- phy_name);
+ "[ENCODER:%d:%s][%s] failed to read the PHY caps\n",
+ encoder->base.base.id, encoder->base.name,
phy_name);
return;
}
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "%s PHY capabilities: %*ph\n",
- phy_name,
+ "[ENCODER:%d:%s][%s] PHY capabilities: %*ph\n",
+ encoder->base.base.id, encoder->base.name, phy_name,
(int)sizeof(intel_dp->lttpr_phy_caps[0]),
phy_caps);
}
static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
{
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
if (intel_dp_is_edp(intel_dp))
return false;
@@ -104,7 +97,8 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp
*intel_dp)
goto reset_caps;
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "LTTPR common capabilities: %*ph\n",
+ "[ENCODER:%d:%s] LTTPR common capabilities: %*ph\n",
+ encoder->base.base.id, encoder->base.name,
(int)sizeof(intel_dp->lttpr_common_caps),
intel_dp->lttpr_common_caps);
@@ -130,6 +124,8 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp
*intel_dp, bool enable)
static int intel_dp_init_lttpr(struct intel_dp *intel_dp)
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
int lttpr_count;
int i;
@@ -161,8 +157,9 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp)
return 0;
if (!intel_dp_set_lttpr_transparent_mode(intel_dp, false)) {
- drm_dbg_kms(_to_i915(intel_dp)->drm,
- "Switching to LTTPR non-transparent LT mode failed,
fall-back to transparent mode\n");
+ drm_dbg_kms(>drm,
+ "[ENCODER:%d:%s] Switching to LTTPR non-transparent
LT mode failed, fall-back to transparent mode\n",
+ encoder->base.base.id, encoder->base.name);
intel_dp_set_lttpr_transparent_mode(intel_dp, true);
intel_dp_reset_lttpr_count(intel_dp);
@@ -366,17 +363,18 @@ intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8
[Intel-gfx] [PATCH v2 1/5] drm/i915: Tweak the DP "max vswing reached?" condition
From: Ville Syrjälä
Currently we consider the max vswing reached when we transmit a
the max voltage level, but we don't consider pre-emphasis at all.
This kinda matches older DP specs that only had some vague text
about transmitting the maximum voltage swing. Latest versions
now say something vague about consider the sum of the vswing
and pre-emphasis fields in the ADJUST_REQUEST_LANE registers.
Very vague, and super confusing especially the fact that it
talks about transmitted voltgage swing in the same sentence
as it say to look at the requested values.
Also glanced at the link CTS spec, and that one seems to have
tests that assume contradicting behaviour. Some say to consider
just the vswing level we transmit, others say to check for
sum of transmitted vswing+preemph being 3.
So let's try to take some kind of sane middle ground here.
I think what could make sense is only consider max vswing
reached if MAX_SWING_REACHED==1 _and_ vswing+preemph==3.
That will allow things to go all the way up to vswing 3 +
pre-emph 0 or vswing 2 + pre-emph 1, depending on what
the maximum supported vswing is. Only considering the sum
of vswing+pre-emph doesn't make much sense to me since
we could terminate too early if the sink requests eg.
vswing 0 + pre-emph 3. And if we'd stick to the current
code we could terminate too early of the sink asks for
vswing 2 + pre-emph 0 when vswing level 3 is not supported.
Side note: I don't really understand why any of this stuff is
"specified" at all. There is already a limit of 5 attempts at
the same vswing+pre-emph level, and a total limit of 10
attempts. So might as well stick to the same max 5 attempts
across the board IMO.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 22 ---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index c052ce14894d..a45569b8c959 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -492,11 +492,27 @@ static bool intel_dp_link_max_vswing_reached(struct
intel_dp *intel_dp,
{
int lane;
- for (lane = 0; lane < crtc_state->lane_count; lane++)
- if ((intel_dp->train_set[lane] &
-DP_TRAIN_MAX_SWING_REACHED) == 0)
+ /*
+* FIXME: The DP spec is very confusing here, also the Link CTS
+* spec seems to have self contradicting tests around this area.
+*
+* In lieu of better ideas let's just stop when we've reached the
+* max supported vswing with its max pre-emphasis, which is either
+* 2+1 or 3+0 depending on whether vswing level 3 is supported or not.
+*/
+ for (lane = 0; lane < crtc_state->lane_count; lane++) {
+ u8 v = (intel_dp->train_set[lane] &
DP_TRAIN_VOLTAGE_SWING_MASK) >>
+ DP_TRAIN_VOLTAGE_SWING_SHIFT;
+ u8 p = (intel_dp->train_set[lane] & DP_TRAIN_PRE_EMPHASIS_MASK)
>>
+ DP_TRAIN_PRE_EMPHASIS_SHIFT;
+
+ if ((intel_dp->train_set[lane] & DP_TRAIN_MAX_SWING_REACHED) ==
0)
return false;
+ if (v + p != 3)
+ return false;
+ }
+
return true;
}
--
2.32.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Don't nuke manually around flips (rev2)
== Series Details == Series: drm/i915/fbc: Don't nuke manually around flips (rev2) URL : https://patchwork.freedesktop.org/series/89823/ State : success == Summary == CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21236 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/index.html Known issues Here are the changes found in Patchwork_21236 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#3718]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - fi-apl-guc: NOTRUN -> [DMESG-WARN][7] ([i915#1610]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-apl-guc/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#1155]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_pm: - fi-tgl-1115g4: NOTRUN -> [DMESG-FAIL][9] ([i915#3987]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#3301]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-apl-guc: NOTRUN -> [FAIL][16] ([i915#2426] / [i915#3363]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-apl-guc/igt@run...@aborted.html Possible fixes * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][17] ([i915#95]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21236/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][19] ([i915#295]) -> [PASS][20] +12 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [20]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for CPU + GPU synchronised priority scheduling (rev2)
== Series Details == Series: CPU + GPU synchronised priority scheduling (rev2) URL : https://patchwork.freedesktop.org/series/95294/ State : failure == Summary == fatal: empty ident name (for <>) not allowed Applying: effective and consolidated user experience. In other words why user would not be
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Add privacy-screen support (v2)
On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> Add support for eDP panels with a built-in privacy screen using the
> new drm_privacy_screen class.
>
> Changes in v2:
> - Call drm_connector_update_privacy_screen() from
> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
> for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
> - Move the probe-deferral check to the intel_modeset_probe_defer() helper
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
> 4 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index b4e7ac51aa31..a62550711e98 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -139,6 +139,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> new_conn_state->base.picture_aspect_ratio !=
> old_conn_state->base.picture_aspect_ratio ||
> new_conn_state->base.content_type !=
> old_conn_state->base.content_type ||
> new_conn_state->base.scaling_mode !=
> old_conn_state->base.scaling_mode ||
> + new_conn_state->base.privacy_screen_sw_state !=
> old_conn_state->base.privacy_screen_sw_state ||
> !drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
> crtc_state->mode_changed = true;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 51cd0420e00e..e4496c830a35 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -25,6 +25,7 @@
> *
> */
>
> +#include
> #include
>
> #include "i915_drv.h"
> @@ -3022,6 +3023,7 @@ static void intel_enable_ddi_dp(struct
> intel_atomic_state *state,
> if (port == PORT_A && DISPLAY_VER(dev_priv) < 9)
> intel_dp_stop_link_train(intel_dp, crtc_state);
>
> + drm_connector_update_privacy_screen(conn_state);
> intel_edp_backlight_on(crtc_state, conn_state);
>
> if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
> @@ -3247,6 +3249,7 @@ static void intel_ddi_update_pipe_dp(struct
> intel_atomic_state *state,
> intel_drrs_update(intel_dp, crtc_state);
>
> intel_backlight_update(state, encoder, crtc_state, conn_state);
> + drm_connector_update_privacy_screen(conn_state);
> }
>
> void intel_ddi_update_pipe(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e67f3207ba54..9a5dbe51458d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -12693,6 +12694,8 @@ void intel_modeset_driver_remove_nogem(struct
> drm_i915_private *i915)
>
> bool intel_modeset_probe_defer(struct pci_dev *pdev)
> {
> + struct drm_privacy_screen *privacy_screen;
> +
> /*
>* apple-gmux is needed on dual GPU MacBook Pro
>* to probe the panel if we're the inactive GPU.
> @@ -12700,6 +12703,13 @@ bool intel_modeset_probe_defer(struct pci_dev *pdev)
> if (vga_switcheroo_client_probe_defer(pdev))
> return true;
>
> + /* If the LCD panel has a privacy-screen, wait for it */
> + privacy_screen = drm_privacy_screen_get(>dev, NULL);
> + if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
> + return true;
> +
> + drm_privacy_screen_put(privacy_screen);
> +
> return false;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 74a657ae131a..91207310dc0d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "g4x_dp.h"
> @@ -4808,6 +4809,7 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> struct drm_connector *connector = _connector->base;
> struct drm_display_mode *fixed_mode = NULL;
> struct drm_display_mode *downclock_mode = NULL;
> + struct drm_privacy_screen *privacy_screen;
> bool has_dpcd;
> enum pipe pipe = INVALID_PIPE;
> struct edid *edid;
> @@ -4902,6 +4904,14 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> fixed_mode->hdisplay, fixed_mode->vdisplay);
> }
>
> + privacy_screen = drm_privacy_screen_get(dev->dev, NULL);
> + if (!IS_ERR(privacy_screen)) {
> +
Re: [Intel-gfx] [PATCH 05/10] drm/connector: Add a drm_connector privacy-screen helper functions (v2)
On Sat, Oct 02, 2021 at 06:36:13PM +0200, Hans de Goede wrote:
> Add 2 drm_connector privacy-screen helper functions:
>
> 1. drm_connector_attach_privacy_screen_provider(), this function creates
> and attaches the standard privacy-screen properties and registers a
> generic notifier for generating sysfs-connector-status-events on external
> changes to the privacy-screen status.
>
> 2. drm_connector_update_privacy_screen(), update the privacy-screen's
> sw_state if the connector has a privacy-screen.
>
> Changes in v2:
> - Do not update connector->state->privacy_screen_sw_state on
> atomic-commits.
> - Change drm_connector_update_privacy_screen() to take drm_connector_state
> as argument instead of a full drm_atomic_state. This allows the helper
> to be called by drivers when they are enabling crtcs/encoders/connectors.
>
> Reviewed-by: Emil Velikov
> Reviewed-by: Lyude Paul
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/drm_connector.c | 102
> include/drm/drm_connector.h | 11
> 2 files changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b2f1f1b1bfb4..00cf3b6135f6 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -462,6 +463,11 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> DRM_CONNECTOR_REGISTERED))
> drm_connector_unregister(connector);
>
> + if (connector->privacy_screen) {
> + drm_privacy_screen_put(connector->privacy_screen);
> + connector->privacy_screen = NULL;
> + }
> +
> if (connector->tile_group) {
> drm_mode_put_tile_group(dev, connector->tile_group);
> connector->tile_group = NULL;
> @@ -543,6 +549,10 @@ int drm_connector_register(struct drm_connector
> *connector)
> /* Let userspace know we have a new connector */
> drm_sysfs_hotplug_event(connector->dev);
>
> + if (connector->privacy_screen)
> + drm_privacy_screen_register_notifier(connector->privacy_screen,
> +>privacy_screen_notifier);
> +
> mutex_lock(_list_lock);
> list_add_tail(>global_connector_list_entry, _list);
> mutex_unlock(_list_lock);
> @@ -578,6 +588,11 @@ void drm_connector_unregister(struct drm_connector
> *connector)
> list_del_init(>global_connector_list_entry);
> mutex_unlock(_list_lock);
>
> + if (connector->privacy_screen)
> + drm_privacy_screen_unregister_notifier(
> + connector->privacy_screen,
> + >privacy_screen_notifier);
> +
> if (connector->funcs->early_unregister)
> connector->funcs->early_unregister(connector);
>
> @@ -2442,6 +2457,93 @@ drm_connector_attach_privacy_screen_properties(struct
> drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
>
> +static void drm_connector_update_privacy_screen_properties(
> + struct drm_connector *connector, bool set_sw_state)
> +{
> + enum drm_privacy_screen_status sw_state, hw_state;
> +
> + drm_privacy_screen_get_state(connector->privacy_screen,
> + _state, _state);
> +
> + if (set_sw_state)
> + connector->state->privacy_screen_sw_state = sw_state;
> + drm_object_property_set_value(>base,
> + connector->privacy_screen_hw_state_property, hw_state);
> +}
> +
> +static int drm_connector_privacy_screen_notifier(
> + struct notifier_block *nb, unsigned long action, void *data)
> +{
> + struct drm_connector *connector =
> + container_of(nb, struct drm_connector, privacy_screen_notifier);
> + struct drm_device *dev = connector->dev;
> +
> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
> + drm_connector_update_privacy_screen_properties(connector, true);
This thing still seems pretty unatomic in essence. The standard rule
is that non-immutable properties do not change under external
influence. So if userspace is unaware of the change then it could
just flip the state back to where it was previously. Ie. seems racy
at least which could in theory lead to some funny ping pong in the
state.
To go proper atomic route here the state of the prop should be
fully cotrolled by userspace. Is that not possible for some reason?
> + drm_modeset_unlock(>mode_config.connection_mutex);
> +
> + drm_sysfs_connector_status_event(connector,
> + connector->privacy_screen_sw_state_property);
> + drm_sysfs_connector_status_event(connector,
> + connector->privacy_screen_hw_state_property);
> +
> + return NOTIFY_DONE;
> +}
> +
> +/**
> + *
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Add privacy-screen support (v2)
Hi,
On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> Changes in v2:
>> - Call drm_connector_update_privacy_screen() from
>> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
>> for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
>> - Move the probe-deferral check to the intel_modeset_probe_defer() helper
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
>> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
>> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
>> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
>> 4 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
>> b/drivers/gpu/drm/i915/display/intel_atomic.c
>> index b4e7ac51aa31..a62550711e98 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
>> @@ -139,6 +139,7 @@ int intel_digital_connector_atomic_check(struct
>> drm_connector *conn,
>> new_conn_state->base.picture_aspect_ratio !=
>> old_conn_state->base.picture_aspect_ratio ||
>> new_conn_state->base.content_type !=
>> old_conn_state->base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode ||
>> +new_conn_state->base.privacy_screen_sw_state !=
>> old_conn_state->base.privacy_screen_sw_state ||
>> !drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
>> crtc_state->mode_changed = true;
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index 51cd0420e00e..e4496c830a35 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -25,6 +25,7 @@
>> *
>> */
>>
>> +#include
>> #include
>>
>> #include "i915_drv.h"
>> @@ -3022,6 +3023,7 @@ static void intel_enable_ddi_dp(struct
>> intel_atomic_state *state,
>> if (port == PORT_A && DISPLAY_VER(dev_priv) < 9)
>> intel_dp_stop_link_train(intel_dp, crtc_state);
>>
>> +drm_connector_update_privacy_screen(conn_state);
>> intel_edp_backlight_on(crtc_state, conn_state);
>>
>> if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
>> @@ -3247,6 +3249,7 @@ static void intel_ddi_update_pipe_dp(struct
>> intel_atomic_state *state,
>> intel_drrs_update(intel_dp, crtc_state);
>>
>> intel_backlight_update(state, encoder, crtc_state, conn_state);
>> +drm_connector_update_privacy_screen(conn_state);
>> }
>>
>> void intel_ddi_update_pipe(struct intel_atomic_state *state,
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index e67f3207ba54..9a5dbe51458d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -42,6 +42,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -12693,6 +12694,8 @@ void intel_modeset_driver_remove_nogem(struct
>> drm_i915_private *i915)
>>
>> bool intel_modeset_probe_defer(struct pci_dev *pdev)
>> {
>> +struct drm_privacy_screen *privacy_screen;
>> +
>> /*
>> * apple-gmux is needed on dual GPU MacBook Pro
>> * to probe the panel if we're the inactive GPU.
>> @@ -12700,6 +12703,13 @@ bool intel_modeset_probe_defer(struct pci_dev *pdev)
>> if (vga_switcheroo_client_probe_defer(pdev))
>> return true;
>>
>> +/* If the LCD panel has a privacy-screen, wait for it */
>> +privacy_screen = drm_privacy_screen_get(>dev, NULL);
>> +if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
>> +return true;
>> +
>> +drm_privacy_screen_put(privacy_screen);
>> +
>> return false;
>> }
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 74a657ae131a..91207310dc0d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include "g4x_dp.h"
>> @@ -4808,6 +4809,7 @@ static bool intel_edp_init_connector(struct intel_dp
>> *intel_dp,
>> struct drm_connector *connector = _connector->base;
>> struct drm_display_mode *fixed_mode = NULL;
>> struct drm_display_mode *downclock_mode = NULL;
>> +struct drm_privacy_screen *privacy_screen;
>> bool has_dpcd;
>> enum pipe pipe = INVALID_PIPE;
>> struct edid *edid;
>> @@ -4902,6 +4904,14 @@ static bool intel_edp_init_connector(struct intel_dp
>> *intel_dp,
>> fixed_mode->hdisplay,
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Add the crtc to affected crtc only if uapi.enable = true (rev3)
== Series Details == Series: drm/atomic: Add the crtc to affected crtc only if uapi.enable = true (rev3) URL : https://patchwork.freedesktop.org/series/87555/ State : success == Summary == CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21235 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/index.html Known issues Here are the changes found in Patchwork_21235 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#3718]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - fi-apl-guc: NOTRUN -> [DMESG-WARN][7] ([i915#1610]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-apl-guc/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#1155]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][10] -> [FAIL][11] ([i915#1372]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html - fi-bdw-5557u: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][16] ([i915#3301]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-apl-guc: NOTRUN -> [FAIL][17] ([i915#2426] / [i915#3363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-apl-guc/igt@run...@aborted.html Possible fixes * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][18] ([i915#295]) -> [PASS][19] +12 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21235/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]:
Re: [Intel-gfx] [PATCH 09/10] drm/i915: Add intel_modeset_probe_defer() helper
On Sat, Oct 02, 2021 at 06:36:17PM +0200, Hans de Goede wrote:
> The upcoming privacy-screen support adds another check for
> deferring probe till some other drivers have bound first.
>
> Factor out the current vga_switcheroo_client_probe_defer() check
> into an intel_modeset_probe_defer() helper, so that further
> probe-deferral checks can be added there.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +
> drivers/gpu/drm/i915/display/intel_display.h | 1 +
> drivers/gpu/drm/i915/i915_pci.c | 9 ++---
> 3 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 60b2bc3ad011..e67f3207ba54 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -12690,6 +12691,18 @@ void intel_modeset_driver_remove_nogem(struct
> drm_i915_private *i915)
> intel_bios_driver_remove(i915);
> }
>
> +bool intel_modeset_probe_defer(struct pci_dev *pdev)
> +{
> + /*
> + * apple-gmux is needed on dual GPU MacBook Pro
> + * to probe the panel if we're the inactive GPU.
> + */
> + if (vga_switcheroo_client_probe_defer(pdev))
> + return true;
> +
> + return false;
> +}
Seems fine. Presumably Jani isn't too grumpy about it :P
Reviewed-by: Ville Syrjälä
> +
> void intel_display_driver_register(struct drm_i915_private *i915)
> {
> if (!HAS_DISPLAY(i915))
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 3028072c2cf3..d3d34acb6c08 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -633,6 +633,7 @@ void intel_display_driver_register(struct
> drm_i915_private *i915);
> void intel_display_driver_unregister(struct drm_i915_private *i915);
>
> /* modesetting */
> +bool intel_modeset_probe_defer(struct pci_dev *pdev);
> void intel_modeset_init_hw(struct drm_i915_private *i915);
> int intel_modeset_init_noirq(struct drm_i915_private *i915);
> int intel_modeset_init_nogem(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d4a6a9dcf182..cf4ad648b742 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -22,8 +22,6 @@
> *
> */
>
> -#include
> -
> #include
> #include
>
> @@ -1187,11 +1185,8 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> if (PCI_FUNC(pdev->devfn))
> return -ENODEV;
>
> - /*
> - * apple-gmux is needed on dual GPU MacBook Pro
> - * to probe the panel if we're the inactive GPU.
> - */
> - if (vga_switcheroo_client_probe_defer(pdev))
> + /* Detect if we need to wait for other drivers early on */
> + if (intel_modeset_probe_defer(pdev))
> return -EPROBE_DEFER;
>
> err = i915_driver_probe(pdev, ent);
> --
> 2.31.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 05/10] drm/connector: Add a drm_connector privacy-screen helper functions (v2)
Hi,
On 10/4/21 5:22 PM, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 06:36:13PM +0200, Hans de Goede wrote:
>> Add 2 drm_connector privacy-screen helper functions:
>>
>> 1. drm_connector_attach_privacy_screen_provider(), this function creates
>> and attaches the standard privacy-screen properties and registers a
>> generic notifier for generating sysfs-connector-status-events on external
>> changes to the privacy-screen status.
>>
>> 2. drm_connector_update_privacy_screen(), update the privacy-screen's
>> sw_state if the connector has a privacy-screen.
>>
>> Changes in v2:
>> - Do not update connector->state->privacy_screen_sw_state on
>> atomic-commits.
>> - Change drm_connector_update_privacy_screen() to take drm_connector_state
>> as argument instead of a full drm_atomic_state. This allows the helper
>> to be called by drivers when they are enabling crtcs/encoders/connectors.
>>
>> Reviewed-by: Emil Velikov
>> Reviewed-by: Lyude Paul
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/drm_connector.c | 102
>> include/drm/drm_connector.h | 11
>> 2 files changed, 113 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index b2f1f1b1bfb4..00cf3b6135f6 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -462,6 +463,11 @@ void drm_connector_cleanup(struct drm_connector
>> *connector)
>> DRM_CONNECTOR_REGISTERED))
>> drm_connector_unregister(connector);
>>
>> +if (connector->privacy_screen) {
>> +drm_privacy_screen_put(connector->privacy_screen);
>> +connector->privacy_screen = NULL;
>> +}
>> +
>> if (connector->tile_group) {
>> drm_mode_put_tile_group(dev, connector->tile_group);
>> connector->tile_group = NULL;
>> @@ -543,6 +549,10 @@ int drm_connector_register(struct drm_connector
>> *connector)
>> /* Let userspace know we have a new connector */
>> drm_sysfs_hotplug_event(connector->dev);
>>
>> +if (connector->privacy_screen)
>> +drm_privacy_screen_register_notifier(connector->privacy_screen,
>> + >privacy_screen_notifier);
>> +
>> mutex_lock(_list_lock);
>> list_add_tail(>global_connector_list_entry, _list);
>> mutex_unlock(_list_lock);
>> @@ -578,6 +588,11 @@ void drm_connector_unregister(struct drm_connector
>> *connector)
>> list_del_init(>global_connector_list_entry);
>> mutex_unlock(_list_lock);
>>
>> +if (connector->privacy_screen)
>> +drm_privacy_screen_unregister_notifier(
>> +connector->privacy_screen,
>> +>privacy_screen_notifier);
>> +
>> if (connector->funcs->early_unregister)
>> connector->funcs->early_unregister(connector);
>>
>> @@ -2442,6 +2457,93 @@ drm_connector_attach_privacy_screen_properties(struct
>> drm_connector *connector)
>> }
>> EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
>>
>> +static void drm_connector_update_privacy_screen_properties(
>> +struct drm_connector *connector, bool set_sw_state)
>> +{
>> +enum drm_privacy_screen_status sw_state, hw_state;
>> +
>> +drm_privacy_screen_get_state(connector->privacy_screen,
>> + _state, _state);
>> +
>> +if (set_sw_state)
>> +connector->state->privacy_screen_sw_state = sw_state;
>> +drm_object_property_set_value(>base,
>> +connector->privacy_screen_hw_state_property, hw_state);
>> +}
>> +
>> +static int drm_connector_privacy_screen_notifier(
>> +struct notifier_block *nb, unsigned long action, void *data)
>> +{
>> +struct drm_connector *connector =
>> +container_of(nb, struct drm_connector, privacy_screen_notifier);
>> +struct drm_device *dev = connector->dev;
>> +
>> +drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> +drm_connector_update_privacy_screen_properties(connector, true);
>
> This thing still seems pretty unatomic in essence. The standard rule
> is that non-immutable properties do not change under external
> influence. So if userspace is unaware of the change then it could
> just flip the state back to where it was previously. Ie. seems racy
> at least which could in theory lead to some funny ping pong in the
> state.
>
> To go proper atomic route here the state of the prop should be
> fully cotrolled by userspace. Is that not possible for some reason?
No, the privacy-screen can be toggled on/off with a Fn + somekey
hotkey combo on the laptop's keyboard, this is fully handled
by the laptop's embedded-controller.
Note that when this happens we do send a udev change event
with info on which connector the event is on
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
On 24/09/2021 23:34, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:
- total busyness: total time that the context was running (total)
- id: id of the running context (id)
- start timestamp: timestamp when the context started running (start)
At the time (now) of sampling the engine busyness, if the id is valid
(!= ~0), and start is non-zero, then the context is considered to be
active and the engine busyness is calculated using the below equation
engine busyness = total + (now - start)
All times are obtained from the gt clock base. For inactive contexts,
engine busyness is just equal to the total.
The start and total values provided by GuC are 32 bits and wrap around
in a few minutes. Since perf pmu provides busyness as 64 bit
monotonically increasing values, there is a need for this implementation
to account for overflows and extend the time to 64 bits before returning
busyness to the user. In order to do that, a worker runs periodically at
frequqncy = 1/8th the time it takes for the timestamp to wrap. As an
frequency
example, that would be once in 27 seconds for a gt clock frequency of
19.2 MHz.
Opens and wip that are targeted for later patches:
1) On global gt reset the total busyness of engines resets and i915
needs to fix that so that user sees monotonically increasing
busyness.
2) In runtime suspend mode, the worker may not need to be run. We could
stop the worker on suspend and rerun it on resume provided that the
guc pm timestamp does not tick during suspend.
2) sounds easy since there are park/unpark hooks for pmu already. Will
see if I can figure out why you did not just immediately do it.
I would also document in the commit message the known problem of
possible over-accounting, just for historical reference.
v2: (Tvrtko)
- Include details in commit message
- Move intel engine busyness function into execlist code
- Use union inside engine->stats
- Use natural type for ping delay jiffies
- Drop active_work condition checks
- Use for_each_engine if iterating all engines
- Drop seq locking, use spinlock at guc level to update engine stats
- Document worker specific details
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 26 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 82 ---
.../drm/i915/gt/intel_execlists_submission.c | 32 +++
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 26 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 13 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 204 ++
drivers/gpu/drm/i915/i915_reg.h | 2 +
10 files changed, 363 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ae57e4656a3..6fcc70a313d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1873,22 +1873,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
intel_engine_print_breadcrumbs(engine, m);
}
-static ktime_t __intel_engine_get_busy_time(struct intel_engine_cs *engine,
- ktime_t *now)
-{
- ktime_t total = engine->stats.total;
-
- /*
-* If the engine is executing something at the moment
-* add it to the total.
-*/
- *now = ktime_get();
- if (READ_ONCE(engine->stats.active))
- total = ktime_add(total, ktime_sub(*now, engine->stats.start));
-
- return total;
-}
-
/**
* intel_engine_get_busy_time() - Return current accumulated engine busyness
* @engine: engine to report on
@@ -1898,15 +1882,7 @@ static ktime_t __intel_engine_get_busy_time(struct
intel_engine_cs *engine,
*/
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine, ktime_t
*now)
{
- unsigned int seq;
- ktime_t total;
-
- do {
- seq = read_seqcount_begin(>stats.lock);
- total = __intel_engine_get_busy_time(engine, now);
- } while (read_seqcount_retry(>stats.lock, seq));
-
- return total;
+ return engine->busyness(engine, now);
}
struct intel_context *
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5ae1207c363b..490166b54ed6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -432,6 +432,12 @@ struct intel_engine_cs {
void
Re: [Intel-gfx] i915 MST HDCP code looks broken
> -Original Message- > From: Ville Syrjälä > Sent: Monday, October 4, 2021 4:22 PM > To: intel-gfx@lists.freedesktop.org > Cc: Sean Paul ; Gupta, Anshuman > ; C, Ramalingam ; B S, > Karthik > Subject: i915 MST HDCP code looks broken > > Hi, > > I took a quick peek at intel_dp_add_mst_connector() the other day and noticed > that it calls intel_dp_hdcp_init() and passes in the SST dig_port. And > digging in a > bit further that seems to clobber all kinds of things in > dig_port->hdcp_port_data. > This looks rather broken to me. > > So has anyone actually thought what happens if you first use MST on the port, > and then later switch to SST on the same port? AFAIU there shouldn't be , when the last connector of MST topology get destroyed and it switches to SST mode on same port. The base static connector of same dig_port should get connected and will call intel_dp_init_connector()->intel_dp_hdcp_init(). What is the specific sequence is broken here , is it the connector destroy path ? > -- > Ville Syrjälä > Intel
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/atomic: Add the crtc to affected crtc only if uapi.enable = true (rev3)
== Series Details == Series: drm/atomic: Add the crtc to affected crtc only if uapi.enable = true (rev3) URL : https://patchwork.freedesktop.org/series/87555/ State : warning == Summary == $ dim checkpatch origin/drm-tip 658485c7066a drm/atomic: Add the crtc to affected crtc only if uapi.enable = true -:10: WARNING:TYPO_SPELLING: 'mutiple' may be misspelled - perhaps 'multiple'? #10: In case of a modeset where a mode gets split across mutiple CRTCs ^^^ -:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #12: the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as total: 0 errors, 2 warnings, 0 checks, 24 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy()
== Series Details == Series: drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy() URL : https://patchwork.freedesktop.org/series/95402/ State : success == Summary == CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21232 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/index.html Known issues Here are the changes found in Patchwork_21232 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#3718]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@debugfs_test@read_all_entries: - fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982] / [i915#262]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - fi-apl-guc: NOTRUN -> [DMESG-WARN][9] ([i915#1610]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-apl-guc/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#1155]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][11] -> [INCOMPLETE][12] ([i915#3921]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][14] -> [FAIL][15] ([i915#1372]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10681/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html - fi-bdw-5557u: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([i915#4103]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][18] ([fdo#109285]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][19] ([i915#1072]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][20] ([i915#3301]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21232/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-apl-guc: NOTRUN -> [FAIL][21] ([i915#2426] / [i915#3363]) [21]:
[Intel-gfx] [RFC 7/8] drm/i915: Inherit process nice for context scheduling priority
From: Tvrtko Ursulin
Introduce the concept of context nice value which matches the process
nice.
We do this by extending the struct i915_sched_attr and add a helper
(i915_sched_attr_priority) to be used to convert to effective priority
when used by backend code and for priority sorting.
Context nice is then inherited from the process which creates the GEM
context and utilised secondary to context priority, only when the latter
has been left at the default setting, in order to avoid disturbing any
application made choices of low and high (batch processing and maybe
latency sensitive compositing). In those cases nice value adjusts the
effective priority in the narrow band of -19 to +20 around
I915_CONTEXT_DEFAULT_PRIORITY.
This means that in theory userspace using the context priority uapi
directly has a wider range of possible adjustments (thought to be
beneficial), but in practice that only applies to execlists platforms.
With GuC there are only three priority buckets (less than zero is low
priority, zero is normal and greater than zero is high) which therefore
interact as expected with the nice adjustment. It makes the question of
should the nice be a sub-range of GEM priorities, or stretched across the
whole, a moot one.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 1 +
.../gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/i915_request.h| 5 +
drivers/gpu/drm/i915/i915_scheduler.c | 12
drivers/gpu/drm/i915/i915_scheduler.h | 14 ++
drivers/gpu/drm/i915/i915_scheduler_types.h| 8
8 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8d4d687ab1d0..fed0733cb652 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,6 +257,7 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
if (i915->params.enable_hangcheck)
pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
pc->sched.priority = I915_PRIORITY_NORMAL;
+ pc->sched.nice = task_nice(current);
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
if (!HAS_EXECLISTS(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index e91d803a6453..1a02c65823a7 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -250,7 +250,7 @@ static struct i915_priolist *to_priolist(struct rb_node *rb)
static int rq_prio(const struct i915_request *rq)
{
- return READ_ONCE(rq->sched.attr.priority);
+ return i915_request_priority(rq);
}
static int effective_prio(const struct i915_request *rq)
@@ -3221,8 +3221,8 @@ static void kick_execlists(const struct i915_request *rq,
{
struct intel_engine_cs *engine = rq->engine;
struct i915_sched_engine *sched_engine = engine->sched_engine;
+ const int prio = i915_sched_attr_priority(attr);
const struct i915_request *inflight;
- const int prio = attr->priority;
/*
* We only need to kick the tasklet once for the high priority
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 b5883a4365ca..f258607685a2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2417,7 +2417,7 @@ static void guc_bump_inflight_request_prio(struct
i915_request *rq,
const struct i915_sched_attr *attr)
{
struct intel_context *ce = rq->context;
- const int prio = attr->priority;
+ const int prio = i915_sched_attr_priority(attr);
u8 new_guc_prio = map_i915_prio_to_guc_prio(prio);
/* Short circuit function */
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 79da5eca60af..a8c6f3a64895 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1930,7 +1930,7 @@ static int print_sched_attr(const struct i915_sched_attr
*attr,
return x;
x += snprintf(buf + x, len - x,
- " prio=%d", attr->priority);
+ " prio=%d nice=%d", attr->priority, attr->nice);
return x;
}
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 7bd9ed20623e..c2c4c344837e 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -399,6 +399,11 @@ long i915_request_wait(struct i915_request *rq,
#define
[Intel-gfx] [RFC v2 0/8] CPU + GPU synchronised priority scheduling
From: Tvrtko Ursulin
This is a somewhat early sketch of one of my ideas intended for early feedback
from the core scheduler experts. First and last two patches in the series are
the most interesting ones for people outside of i915. (Note I did not copy
everyone on all patches but just the cover letter for context and the rest
should be available from the mailing list.)
General idea is that current processing landscape seems to be more and more
composed of pipelines where computations are done on multiple hardware devices.
Furthermore some of the non-CPU devices, like in this case many GPUs supported
by the i915 driver, actually support priority based scheduling which is
currently rather inaccesible to the user (in terms of being able to control it
from the outside).
>From these two statements a question arises on how to allow for a simple,
effective and consolidated user experience. In other words why user would not be
able to do something like:
$ nice ffmmpeg ...transcode my videos...
$ my-favourite-game
And have the nice hint apply to GPU parts of the transcode pipeline as well?
Another reason why I started thinking about this is that I noticed Chrome
browser for instance uses nice to de-prioritise background tabs. So again,
having that decision propagate to the GPU rendering pipeline sounds like a big
plus to the overall user experience.
This RFC implements this idea with the hairy part being the notifier chain I
added to enable dynamic adjustments. It is a global notifier which raises a few
questions so I am very curious what experts will think here. Please see the
opens in the first patch for more on this.
Last patch ("drm/i915: Connect with the process nice change notifier")
demonstrates how i915 can use the notifier. With a bit of notable tracking being
required and addedd in "drm/i915: Keep track of registered clients indexed by
task struct".
On a more positive note the thing seems to even work as is. For instance I
roughly simulated the above scenario by running a GPU hog at three nice levels
and a GfxBench TRex in parallel (as a game proxy). This is what I got:
GPU hog nice | TRex fps
--+---
not running | 48.9
0 | 42.7
10 | 47.9
-10 | 29.0
When re-niced the background GPU hog has a much smaller effect on the
performance of the game user is running in the foreground. So it appears the
feature can indeed improve the user experience. Question is just if people are
happy with this method of implementing it.
v2:
* Moved notifier outside task_rq_lock.
* Some improvements and restructuring on the i915 side of the series.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
Tvrtko Ursulin (8):
sched: Add nice value change notifier
drm/i915: Explicitly track DRM clients
drm/i915: Make GEM contexts track DRM clients
drm/i915: Track all user contexts per client
drm/i915: Keep track of registered clients indexed by task struct
drm/i915: Make some recently added vfuncs use full scheduling
attribute
drm/i915: Inherit process nice for context scheduling priority
drm/i915: Connect with the process nice change notifier
drivers/gpu/drm/i915/Makefile | 5 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 20 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 6 +
.../drm/i915/gt/intel_execlists_submission.c | 6 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +-
drivers/gpu/drm/i915/i915_drm_client.c| 130 ++
drivers/gpu/drm/i915/i915_drm_client.h| 71 ++
drivers/gpu/drm/i915/i915_drv.c | 6 +
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 21 ++-
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_request.h | 5 +
drivers/gpu/drm/i915/i915_scheduler.c | 16 ++-
drivers/gpu/drm/i915/i915_scheduler.h | 14 ++
drivers/gpu/drm/i915/i915_scheduler_types.h | 12 +-
include/linux/sched.h | 5 +
kernel/sched/core.c | 37 -
17 files changed, 346 insertions(+), 18 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
--
2.30.2
[Intel-gfx] [RFC 1/8] sched: Add nice value change notifier
From: Tvrtko Ursulin
Implement a simple notifier chain via which interested parties can track
when process nice value changes. Simple because it is global so each user
would have to track which tasks it is interested in.
First intended use case are GPU drivers using task nice as priority hint
when scheduling GPU contexts belonging to respective clients.
To use register_user_nice_notifier and unregister_user_nice_notifier
functions are provided and new nice value and pointer to task_struct
being modified passed to the callbacks.
v2:
* Move the notifier chain outside task_rq_lock. (Peter)
Opens:
* Security. Would some sort of a per process mechanism be better and
feasible?
x Peter Zijlstra thinks it may be passable now that it is outside
core scheduler locks.
* Put it all behind kconfig to be selected by interested drivers?
Signed-off-by: Tvrtko Ursulin
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
---
include/linux/sched.h | 5 +
kernel/sched/core.c | 37 -
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c1a927ddec64..1fcec88e5dbc 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2309,4 +2309,9 @@ static inline void sched_core_free(struct task_struct
*tsk) { }
static inline void sched_core_fork(struct task_struct *p) { }
#endif
+struct notifier_block;
+
+extern int register_user_nice_notifier(struct notifier_block *);
+extern int unregister_user_nice_notifier(struct notifier_block *);
+
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1bba4128a3e6..fc90b603bb6f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6864,10 +6864,42 @@ static inline int rt_effective_prio(struct task_struct
*p, int prio)
}
#endif
+ATOMIC_NOTIFIER_HEAD(user_nice_notifier_list);
+
+/**
+ * register_user_nice_notifier - Register function to be called when task nice
changes
+ * @nb: Info about notifier function to be called
+ *
+ * Registers a function with the list of functions to be called when task nice
+ * value changes.
+ *
+ * Currently always returns zero, as atomic_notifier_chain_register()
+ * always returns zero.
+ */
+int register_user_nice_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(_nice_notifier_list, nb);
+}
+EXPORT_SYMBOL(register_user_nice_notifier);
+
+/**
+ * unregister_user_nice_notifier - Unregister previously registered user nice
notifier
+ * @nb: Hook to be unregistered
+ *
+ * Unregisters a previously registered user nice notifier function.
+ *
+ * Returns zero on success, or %-ENOENT on failure.
+ */
+int unregister_user_nice_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(_nice_notifier_list, nb);
+}
+EXPORT_SYMBOL(unregister_user_nice_notifier);
+
void set_user_nice(struct task_struct *p, long nice)
{
bool queued, running;
- int old_prio;
+ int old_prio, ret;
struct rq_flags rf;
struct rq *rq;
@@ -6915,6 +6947,9 @@ void set_user_nice(struct task_struct *p, long nice)
out_unlock:
task_rq_unlock(rq, p, );
+
+ ret = atomic_notifier_call_chain(_nice_notifier_list, nice, p);
+ WARN_ON_ONCE(ret != NOTIFY_DONE);
}
EXPORT_SYMBOL(set_user_nice);
--
2.30.2
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Prefer struct_size over open coded arithmetic
== Series Details ==
Series: drm/i915: Prefer struct_size over open coded arithmetic
URL : https://patchwork.freedesktop.org/series/95408/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/i915_syncmap.o
drivers/gpu/drm/i915/i915_syncmap.c:86:3: error: expected
specifier-qualifier-list before ‘DECLARE_FLEX_ARRAY’
DECLARE_FLEX_ARRAY(u32, seqno);
^~
drivers/gpu/drm/i915/i915_syncmap.c: In function ‘__sync_seqno’:
drivers/gpu/drm/i915/i915_syncmap.c:106:10: error: ‘struct i915_syncmap’ has no
member named ‘seqno’
return p->seqno;
^~
drivers/gpu/drm/i915/i915_syncmap.c: In function ‘__sync_child’:
drivers/gpu/drm/i915/i915_syncmap.c:112:10: error: ‘struct i915_syncmap’ has no
member named ‘child’
return p->child;
^~
In file included from ./include/linux/slab.h:16,
from drivers/gpu/drm/i915/i915_syncmap.c:25:
drivers/gpu/drm/i915/i915_syncmap.c: In function ‘__sync_alloc_leaf’:
./include/linux/overflow.h:194:18: error: ‘struct i915_syncmap’ has no member
named ‘seqno’
sizeof(*(p)->member) + __must_be_array((p)->member),\
^~
drivers/gpu/drm/i915/i915_syncmap.c:207:14: note: in expansion of macro
‘struct_size’
p = kmalloc(struct_size(p, seqno, KSYNCMAP), GFP_KERNEL);
^~~
In file included from ./include/linux/bits.h:22,
from ./include/linux/ratelimit_types.h:5,
from ./include/linux/printk.h:10,
from ./include/asm-generic/bug.h:22,
from ./arch/x86/include/asm/bug.h:84,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/gfp.h:5,
from ./include/linux/slab.h:15,
from drivers/gpu/drm/i915/i915_syncmap.c:25:
./include/linux/overflow.h:194:49: error: ‘struct i915_syncmap’ has no member
named ‘seqno’
sizeof(*(p)->member) + __must_be_array((p)->member),\
^~
./include/linux/build_bug.h:16:62: note: in definition of macro
‘BUILD_BUG_ON_ZERO’
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
./include/linux/compiler.h:258:46: note: in expansion of macro ‘__same_type’
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^~~
./include/linux/overflow.h:194:30: note: in expansion of macro ‘__must_be_array’
sizeof(*(p)->member) + __must_be_array((p)->member),\
^~~
drivers/gpu/drm/i915/i915_syncmap.c:207:14: note: in expansion of macro
‘struct_size’
p = kmalloc(struct_size(p, seqno, KSYNCMAP), GFP_KERNEL);
^~~
./include/linux/overflow.h:194:49: error: ‘struct i915_syncmap’ has no member
named ‘seqno’
sizeof(*(p)->member) + __must_be_array((p)->member),\
^~
./include/linux/build_bug.h:16:62: note: in definition of macro
‘BUILD_BUG_ON_ZERO’
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
./include/linux/compiler.h:258:46: note: in expansion of macro ‘__same_type’
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^~~
./include/linux/overflow.h:194:30: note: in expansion of macro ‘__must_be_array’
sizeof(*(p)->member) + __must_be_array((p)->member),\
^~~
drivers/gpu/drm/i915/i915_syncmap.c:207:14: note: in expansion of macro
‘struct_size’
p = kmalloc(struct_size(p, seqno, KSYNCMAP), GFP_KERNEL);
^~~
./include/linux/build_bug.h:16:51: error: bit-field ‘’ width not an
integer constant
#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
^
./include/linux/compiler.h:258:28: note: in expansion of macro
‘BUILD_BUG_ON_ZERO’
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
./include/linux/overflow.h:194:30: note: in expansion of macro ‘__must_be_array’
sizeof(*(p)->member) + __must_be_array((p)->member),\
^~~
drivers/gpu/drm/i915/i915_syncmap.c:207:14: note: in expansion of macro
‘struct_size’
p = kmalloc(struct_size(p, seqno, KSYNCMAP), GFP_KERNEL);
^~~
In file included from ./include/linux/slab.h:16,
from drivers/gpu/drm/i915/i915_syncmap.c:25:
drivers/gpu/drm/i915/i915_syncmap.c: In function ‘__sync_set’:
./include/linux/overflow.h:194:18: error: ‘struct i915_syncmap’ has no member
named
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Improve DP link training further
== Series Details == Series: drm/i915: Improve DP link training further URL : https://patchwork.freedesktop.org/series/95405/ State : failure == Summary == Applying: drm/i915: Tweak the DP "max vswing reached?" condition Applying: drm/i915: Show LTTPR in the TPS debug print Applying: drm/i915: Print the DP vswing adjustment request error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_dp_link_training.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/i915: Print the DP vswing adjustment request 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] [RFC 5/8] drm/i915: Keep track of registered clients indexed by task struct
From: Tvrtko Ursulin
A simple hash table of registered clients indexed by the task struct
pointer is kept to be used in a following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_drm_client.c | 31 -
drivers/gpu/drm/i915/i915_drm_client.h | 13 +
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d1992ba59ed8..8d4d687ab1d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1932,6 +1932,8 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
return -EIO;
}
+ i915_drm_client_update_owner(ext_data.fpriv->client, current);
+
ext_data.pc = proto_context_create(i915, args->flags);
if (IS_ERR(ext_data.pc))
return PTR_ERR(ext_data.pc);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 91a8559bebf7..82b9636482ef 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -18,6 +18,9 @@ void i915_drm_clients_init(struct i915_drm_clients *clients,
clients->next_id = 0;
xa_init_flags(>xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
+
+ rwlock_init(>lock);
+ hash_init(clients->tasks);
}
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
@@ -42,6 +45,8 @@ struct i915_drm_client *i915_drm_client_add(struct
i915_drm_clients *clients)
INIT_LIST_HEAD(>ctx_list);
client->clients = clients;
+ i915_drm_client_update_owner(client, current);
+
return client;
err:
@@ -54,9 +59,14 @@ void __i915_drm_client_free(struct kref *kref)
{
struct i915_drm_client *client =
container_of(kref, typeof(*client), kref);
- struct xarray *xa = >clients->xarray;
+ struct i915_drm_clients *clients = client->clients;
+ struct xarray *xa = >xarray;
unsigned long flags;
+ write_lock(>lock);
+ hash_del(>node);
+ write_unlock(>lock);
+
xa_lock_irqsave(xa, flags);
__xa_erase(xa, client->id);
xa_unlock_irqrestore(xa, flags);
@@ -68,3 +78,22 @@ void i915_drm_clients_fini(struct i915_drm_clients *clients)
GEM_BUG_ON(!xa_empty(>xarray));
xa_destroy(>xarray);
}
+
+void i915_drm_client_update_owner(struct i915_drm_client *client,
+ struct task_struct *owner)
+{
+ struct i915_drm_clients *clients;
+
+ if (READ_ONCE(client->owner) == owner)
+ return;
+
+ clients = client->clients;
+ write_lock(>lock);
+ if (READ_ONCE(client->owner) != owner) {
+ if (client->owner)
+ hash_del(>node);
+ client->owner = owner;
+ hash_add(clients->tasks, >node, (uintptr_t)owner);
+ }
+ write_unlock(>lock);
+}
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 0207dfad4568..42fd79f0558a 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -6,8 +6,11 @@
#ifndef __I915_DRM_CLIENT_H__
#define __I915_DRM_CLIENT_H__
+#include
#include
#include
+#include
+#include
#include
#include
@@ -18,6 +21,9 @@ struct i915_drm_clients {
struct xarray xarray;
u32 next_id;
+
+ rwlock_t lock;
+ DECLARE_HASHTABLE(tasks, 6);
};
struct i915_drm_client {
@@ -28,6 +34,9 @@ struct i915_drm_client {
spinlock_t ctx_lock; /* For add/remove from ctx_list. */
struct list_head ctx_list; /* List of contexts belonging to client. */
+ struct task_struct *owner; /* No reference kept, never dereferenced. */
+ struct hlist_node node;
+
struct i915_drm_clients *clients;
};
@@ -52,4 +61,8 @@ struct i915_drm_client *i915_drm_client_add(struct
i915_drm_clients *clients);
void i915_drm_clients_fini(struct i915_drm_clients *clients);
+void i915_drm_client_update_owner(struct i915_drm_client *client,
+ struct task_struct *owner);
+
+
#endif /* !__I915_DRM_CLIENT_H__ */
--
2.30.2
[Intel-gfx] [RFC 6/8] drm/i915: Make some recently added vfuncs use full scheduling attribute
From: Tvrtko Ursulin
Code added in 71ed60112d5d ("drm/i915: Add kick_backend function to
i915_sched_engine") and ee242ca704d3 ("drm/i915/guc: Implement GuC
priority management") introduced some scheduling related vfuncs which
take integer request priority as argument.
Make them instead take struct i915_sched_attr, which is the type
encapsulating this information, so it probably aligns with the design
better. It definitely enables extending the set of scheduling attributes.
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 3 ++-
drivers/gpu/drm/i915/i915_scheduler.c| 4 ++--
drivers/gpu/drm/i915/i915_scheduler_types.h | 4 ++--
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7147fe80919e..e91d803a6453 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3216,11 +3216,13 @@ static bool can_preempt(struct intel_engine_cs *engine)
return engine->class != RENDER_CLASS;
}
-static void kick_execlists(const struct i915_request *rq, int prio)
+static void kick_execlists(const struct i915_request *rq,
+ const struct i915_sched_attr *attr)
{
struct intel_engine_cs *engine = rq->engine;
struct i915_sched_engine *sched_engine = engine->sched_engine;
const struct i915_request *inflight;
+ const int prio = attr->priority;
/*
* We only need to kick the tasklet once for the high priority
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 ba0de35f6323..b5883a4365ca 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2414,9 +2414,10 @@ static void guc_init_breadcrumbs(struct intel_engine_cs
*engine)
}
static void guc_bump_inflight_request_prio(struct i915_request *rq,
- int prio)
+ const struct i915_sched_attr *attr)
{
struct intel_context *ce = rq->context;
+ const int prio = attr->priority;
u8 new_guc_prio = map_i915_prio_to_guc_prio(prio);
/* Short circuit function */
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 762127dd56c5..534bab99fcdc 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -255,7 +255,7 @@ static void __i915_schedule(struct i915_sched_node *node,
/* Must be called before changing the nodes priority */
if (sched_engine->bump_inflight_request_prio)
- sched_engine->bump_inflight_request_prio(from, prio);
+ sched_engine->bump_inflight_request_prio(from, attr);
WRITE_ONCE(node->attr.priority, prio);
@@ -280,7 +280,7 @@ static void __i915_schedule(struct i915_sched_node *node,
/* Defer (tasklet) submission until after all of our updates. */
if (sched_engine->kick_backend)
- sched_engine->kick_backend(node_to_request(node), prio);
+ sched_engine->kick_backend(node_to_request(node), attr);
}
spin_unlock(_engine->lock);
diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
b/drivers/gpu/drm/i915/i915_scheduler_types.h
index b0a1b58c7893..24b9ac1c2ce2 100644
--- a/drivers/gpu/drm/i915/i915_scheduler_types.h
+++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
@@ -177,13 +177,13 @@ struct i915_sched_engine {
* @kick_backend: kick backend after a request's priority has changed
*/
void(*kick_backend)(const struct i915_request *rq,
- int prio);
+ const struct i915_sched_attr *attr);
/**
* @bump_inflight_request_prio: update priority of an inflight request
*/
void(*bump_inflight_request_prio)(struct i915_request *rq,
- int prio);
+ const struct i915_sched_attr
*attr);
/**
* @retire_inflight_request_prio: indicate request is retired to
--
2.30.2
[Intel-gfx] [RFC 3/8] drm/i915: Make GEM contexts track DRM clients
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram): Rebase.
v5: Trivial rebase for proto ctx changes.
v6: Rebase after clients no longer track name and pid.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v5
Reviewed-by: Aravind Iddamsetty # v5
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..9296d69681d7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -956,6 +956,9 @@ static void i915_gem_context_release_work(struct
work_struct *work)
if (vm)
i915_vm_put(vm);
+ if (ctx->client)
+ i915_drm_client_put(ctx->client);
+
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
@@ -1373,6 +1376,8 @@ static void gem_context_register(struct i915_gem_context
*ctx,
ctx->file_priv = fpriv;
ctx->pid = get_task_pid(current, PIDTYPE_PID);
+ ctx->client = i915_drm_client_get(fpriv->client);
+
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
current->comm, pid_nr(ctx->pid));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index c4617e4d9fa9..598c57ac5cdf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -277,6 +277,9 @@ struct i915_gem_context {
/** @link: place with _i915_private.context_list */
struct list_head link;
+ /** @client: struct i915_drm_client */
+ struct i915_drm_client *client;
+
/**
* @ref: reference count
*
--
2.30.2
[Intel-gfx] [RFC 4/8] drm/i915: Track all user contexts per client
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
drivers/gpu/drm/i915/i915_drm_client.c| 2 ++
drivers/gpu/drm/i915/i915_drm_client.h| 5 +
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9296d69681d7..d1992ba59ed8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1169,6 +1169,7 @@ static void set_closed_name(struct i915_gem_context *ctx)
static void context_close(struct i915_gem_context *ctx)
{
+ struct i915_drm_client *client;
struct i915_address_space *vm;
/* Flush any concurrent set_engines() */
@@ -1205,6 +1206,13 @@ static void context_close(struct i915_gem_context *ctx)
list_del(>link);
spin_unlock(>i915->gem.contexts.lock);
+ client = ctx->client;
+ if (client) {
+ spin_lock(>ctx_lock);
+ list_del_rcu(>client_link);
+ spin_unlock(>ctx_lock);
+ }
+
mutex_unlock(>mutex);
/*
@@ -1385,6 +1393,10 @@ static void gem_context_register(struct i915_gem_context
*ctx,
old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
WARN_ON(old);
+ spin_lock(>client->ctx_lock);
+ list_add_tail_rcu(>client_link, >client->ctx_list);
+ spin_unlock(>client->ctx_lock);
+
spin_lock(>gem.contexts.lock);
list_add_tail(>link, >gem.contexts.list);
spin_unlock(>gem.contexts.lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 598c57ac5cdf..b878e1b13b38 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -280,6 +280,9 @@ struct i915_gem_context {
/** @client: struct i915_drm_client */
struct i915_drm_client *client;
+ /** link: _client.context_list */
+ struct list_head client_link;
+
/**
* @ref: reference count
*
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index e61e9ba15256..91a8559bebf7 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -38,6 +38,8 @@ struct i915_drm_client *i915_drm_client_add(struct
i915_drm_clients *clients)
goto err;
kref_init(>kref);
+ spin_lock_init(>ctx_lock);
+ INIT_LIST_HEAD(>ctx_list);
client->clients = clients;
return client;
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index e8986ad51176..0207dfad4568 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -7,6 +7,8 @@
#define __I915_DRM_CLIENT_H__
#include
+#include
+#include
#include
struct drm_i915_private;
@@ -23,6 +25,9 @@ struct i915_drm_client {
unsigned int id;
+ spinlock_t ctx_lock; /* For add/remove from ctx_list. */
+ struct list_head ctx_list; /* List of contexts belonging to client. */
+
struct i915_drm_clients *clients;
};
--
2.30.2
[Intel-gfx] [RFC 2/8] drm/i915: Explicitly track DRM clients
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multiple file descriptors owned by the same process.
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
v3:
* sysfs_attr_init.
v4:
* Fix for internal clients.
v5:
* Use cyclic ida for client id. (Chris)
* Do not leak pid reference. (Chris)
* Tidy code with some locals.
v6:
* Use xa_alloc_cyclic to simplify locking. (Chris)
* No need to unregister individial sysfs files. (Chris)
* Rebase on top of fpriv kref.
* Track client closed status and reflect in sysfs.
v7:
* Make drm_client more standalone concept.
v8:
* Simplify sysfs show. (Chris)
* Always track name and pid.
v9:
* Fix cyclic id assignment.
v10:
* No need for a mutex around xa_alloc_cyclic.
* Refactor sysfs into own function.
* Unregister sysfs before freeing pid and name.
* Move clients setup into own function.
v11:
* Call clients init directly from driver init. (Chris)
v12:
* Do not fail client add on id wrap. (Maciej)
v13 (Lucas): Rebase.
v14:
* Dropped sysfs bits.
v15:
* Dropped tracking of pid/ and name.
* Dropped RCU freeing of the client object.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v11
Reviewed-by: Aravind Iddamsetty # v11
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 5 +-
drivers/gpu/drm/i915/i915_drm_client.c | 68 ++
drivers/gpu/drm/i915/i915_drm_client.h | 50 +++
drivers/gpu/drm/i915/i915_drv.c| 6 +++
drivers/gpu/drm/i915/i915_drv.h| 5 ++
drivers/gpu/drm/i915/i915_gem.c| 21 ++--
6 files changed, 150 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5c8e022a7383..005b5df425a1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -32,8 +32,9 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
# core driver code
-i915-y += i915_drv.o \
- i915_config.o \
+i915-y += i915_config.o \
+ i915_drm_client.o \
+ i915_drv.o \
i915_irq.o \
i915_getparam.o \
i915_mitigations.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..e61e9ba15256
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+void i915_drm_clients_init(struct i915_drm_clients *clients,
+ struct drm_i915_private *i915)
+{
+ clients->i915 = i915;
+ clients->next_id = 0;
+
+ xa_init_flags(>xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
+}
+
+struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
+{
+ struct i915_drm_client *client;
+ struct xarray *xa = >xarray;
+ int ret;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return ERR_PTR(-ENOMEM);
+
+ xa_lock_irq(xa);
+ ret = __xa_alloc_cyclic(xa, >id, client, xa_limit_32b,
+ >next_id, GFP_KERNEL);
+ xa_unlock_irq(xa);
+ if (ret < 0)
+ goto err;
+
+ kref_init(>kref);
+ client->clients = clients;
+
+ return client;
+
+err:
+ kfree(client);
+
+ return ERR_PTR(ret);
+}
+
+void __i915_drm_client_free(struct kref *kref)
+{
+ struct i915_drm_client *client =
+ container_of(kref, typeof(*client), kref);
+ struct xarray *xa = >clients->xarray;
+ unsigned long flags;
+
+ xa_lock_irqsave(xa, flags);
+ __xa_erase(xa, client->id);
+ xa_unlock_irqrestore(xa, flags);
+ kfree(client);
+}
+
+void i915_drm_clients_fini(struct i915_drm_clients *clients)
+{
+ GEM_BUG_ON(!xa_empty(>xarray));
+ xa_destroy(>xarray);
+}
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
new file mode 100644
index ..e8986ad51176
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __I915_DRM_CLIENT_H__
+#define __I915_DRM_CLIENT_H__
+
+#include
+#include
+
+struct drm_i915_private;
+
+struct i915_drm_clients {
+ struct drm_i915_private *i915;
+
+ struct xarray xarray;
+ u32 next_id;
+};
+
+struct
[Intel-gfx] [RFC 8/8] drm/i915: Connect with the process nice change notifier
From: Tvrtko Ursulin
Connect i915 with the process nice change notifier so that our scheduling
can react to runtime adjustments, on top of previously added nice value
inheritance at context create time.
To achieve this we use the previously added map of clients per owning
tasks in combination with the list of GEM contexts per client.
To avoid possibly unnecessary complications the updated context nice value
will only apply to future submissions against the context.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drm_client.c | 31 ++
drivers/gpu/drm/i915/i915_drm_client.h | 3 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 82b9636482ef..e34c1228f65b 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -7,10 +7,35 @@
#include
#include
+#include "gem/i915_gem_context.h"
#include "i915_drm_client.h"
#include "i915_gem.h"
#include "i915_utils.h"
+static int
+clients_notify(struct notifier_block *nb, unsigned long val, void *ptr)
+{
+ struct i915_drm_clients *clients =
+ container_of(nb, typeof(*clients), prio_notifier);
+ struct i915_drm_client *client;
+
+ rcu_read_lock();
+ read_lock(>lock);
+ hash_for_each_possible(clients->tasks, client, node, (uintptr_t)ptr) {
+ struct i915_gem_context *ctx;
+
+ if (client->owner != ptr)
+ continue;
+
+ list_for_each_entry_rcu(ctx, >ctx_list, client_link)
+ ctx->sched.nice = (int)val;
+ }
+ read_unlock(>lock);
+ rcu_read_unlock();
+
+ return NOTIFY_DONE;
+}
+
void i915_drm_clients_init(struct i915_drm_clients *clients,
struct drm_i915_private *i915)
{
@@ -21,6 +46,10 @@ void i915_drm_clients_init(struct i915_drm_clients *clients,
rwlock_init(>lock);
hash_init(clients->tasks);
+
+ memset(>prio_notifier, 0, sizeof(clients->prio_notifier));
+ clients->prio_notifier.notifier_call = clients_notify;
+ register_user_nice_notifier(>prio_notifier);
}
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
@@ -75,6 +104,8 @@ void __i915_drm_client_free(struct kref *kref)
void i915_drm_clients_fini(struct i915_drm_clients *clients)
{
+ unregister_user_nice_notifier(>prio_notifier);
+
GEM_BUG_ON(!xa_empty(>xarray));
xa_destroy(>xarray);
}
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 42fd79f0558a..dda26aa42ac9 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,8 @@ struct i915_drm_clients {
rwlock_t lock;
DECLARE_HASHTABLE(tasks, 6);
+
+ struct notifier_block prio_notifier;
};
struct i915_drm_client {
--
2.30.2
[Intel-gfx] [PATCH 2/2] drm/i915/fbc: Don't nuke manually around flips
From: Ville Syrjälä Apparently we have discovered another way to hit the dreaded top of screen FBC corruption on GLK. Previously we thought it was limited to some combination of FBC nuke+disable+plane update during the same frame, for which we have the extra vblank wait as a workaround. But looks like it can somehow be hit even without the FBC disable. Skipping the extra manual nuke immediately after page flips seems to cure this. The manual nuke shouldn't be needed anyway since the flip itself will already cause a nuke. I suppose this means it might still be possible to hit this if you mix page flips and frontbuffer rendering in clever ways, but at least it's a bit less likely now. v2: Rebase Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_fbc.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c index ef2f1ece4a89..d909402bd151 100644 --- a/drivers/gpu/drm/i915/display/intel_fbc.c +++ b/drivers/gpu/drm/i915/display/intel_fbc.c @@ -458,11 +458,13 @@ static void intel_fbc_activate(struct drm_i915_private *dev_priv) trace_intel_fbc_activate(fbc->crtc); + intel_fbc_hw_activate(dev_priv); + + if (!fbc->active) + intel_fbc_recompress(dev_priv); + fbc->active = true; fbc->activated = true; - - intel_fbc_hw_activate(dev_priv); - intel_fbc_recompress(dev_priv); } static void intel_fbc_deactivate(struct drm_i915_private *dev_priv, -- 2.32.0
[Intel-gfx] [PATCH 1/2] drm/i915/fbc: Hoist more stuff out from intel_fbc_hw_(de)activate()
From: Ville Syrjälä
Move more of the common stuff one level up from
intel_fbc_hw_(de)activate().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 1f66de77a6b1..ef2f1ece4a89 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -418,13 +418,6 @@ static bool intel_fbc_hw_is_active(struct drm_i915_private
*dev_priv)
static void intel_fbc_hw_activate(struct drm_i915_private *dev_priv)
{
- struct intel_fbc *fbc = _priv->fbc;
-
- trace_intel_fbc_activate(fbc->crtc);
-
- fbc->active = true;
- fbc->activated = true;
-
if (DISPLAY_VER(dev_priv) >= 7)
gen7_fbc_activate(dev_priv);
else if (DISPLAY_VER(dev_priv) >= 5)
@@ -437,12 +430,6 @@ static void intel_fbc_hw_activate(struct drm_i915_private
*dev_priv)
static void intel_fbc_hw_deactivate(struct drm_i915_private *dev_priv)
{
- struct intel_fbc *fbc = _priv->fbc;
-
- trace_intel_fbc_deactivate(fbc->crtc);
-
- fbc->active = false;
-
if (DISPLAY_VER(dev_priv) >= 5)
ilk_fbc_deactivate(dev_priv);
else if (IS_GM45(dev_priv))
@@ -467,6 +454,13 @@ bool intel_fbc_is_active(struct drm_i915_private *dev_priv)
static void intel_fbc_activate(struct drm_i915_private *dev_priv)
{
+ struct intel_fbc *fbc = _priv->fbc;
+
+ trace_intel_fbc_activate(fbc->crtc);
+
+ fbc->active = true;
+ fbc->activated = true;
+
intel_fbc_hw_activate(dev_priv);
intel_fbc_recompress(dev_priv);
}
@@ -478,10 +472,16 @@ static void intel_fbc_deactivate(struct drm_i915_private
*dev_priv,
drm_WARN_ON(_priv->drm, !mutex_is_locked(>lock));
- if (fbc->active)
- intel_fbc_hw_deactivate(dev_priv);
-
fbc->no_fbc_reason = reason;
+
+ if (!fbc->active)
+ return;
+
+ trace_intel_fbc_deactivate(fbc->crtc);
+
+ intel_fbc_hw_deactivate(dev_priv);
+
+ fbc->active = false;
}
static u64 intel_fbc_cfb_base_max(struct drm_i915_private *i915)
--
2.32.0
[Intel-gfx] [PATCH 0/2] drm/i915/fbc: Don't nuke manually around flips
From: Ville Syrjälä Let's see how the glk is behaving these days... Ville Syrjälä (2): drm/i915/fbc: Hoist more stuff out from intel_fbc_hw_(de)activate() drm/i915/fbc: Don't nuke manually around flips drivers/gpu/drm/i915/display/intel_fbc.c | 36 +--- 1 file changed, 19 insertions(+), 17 deletions(-) -- 2.32.0
Re: [Intel-gfx] [PATCH 01/28] dma-buf: add dma_resv_for_each_fence_unlocked v7
On 04/10/2021 13:59, Christian König wrote:
Am 04.10.21 um 12:50 schrieb Tvrtko Ursulin:
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they might be freed,
improve kerneldoc, rename _cursor to _iter, add
dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end
v3: restructor the code, move rcu_read_lock()/unlock() into the
iterator, add dma_resv_iter_is_restarted()
v4: fix NULL deref when no explicit fence exists, drop superflous
rcu_read_lock()/unlock() calls.
v5: fix typos in the documentation
v6: fix coding error when excl fence is NULL
v7: one more logic fix
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 100
+
include/linux/dma-resv.h | 95
+++
2 files changed, 195 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 84fbe60629e3..3cbcf66a137e 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -323,6 +323,106 @@ void dma_resv_add_excl_fence(struct
dma_resv *obj, struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_resv_add_excl_fence);
+/**
+ * dma_resv_iter_restart_unlocked - restart the unlocked iterator
+ * @cursor: The dma_resv_iter object to restart
+ *
+ * Restart the unlocked iteration by initializing the cursor
object.
+ */
+static void dma_resv_iter_restart_unlocked(struct dma_resv_iter
*cursor)
+{
+ cursor->seq = read_seqcount_begin(>obj->seq);
+ cursor->index = -1;
+ if (cursor->all_fences)
+ cursor->fences = dma_resv_shared_list(cursor->obj);
+ else
+ cursor->fences = NULL;
+ cursor->is_restarted = true;
+}
+
+/**
+ * dma_resv_iter_walk_unlocked - walk over fences in a dma_resv obj
+ * @cursor: cursor to record the current position
+ *
+ * Return all the fences in the dma_resv object which are not
yet signaled.
+ * The returned fence has an extra local reference so will stay
alive.
+ * If a concurrent modify is detected the whole iteration is
started over again.
+ */
+static void dma_resv_iter_walk_unlocked(struct dma_resv_iter
*cursor)
+{
+ struct dma_resv *obj = cursor->obj;
+
+ do {
+ /* Drop the reference from the previous round */
+ dma_fence_put(cursor->fence);
+
+ if (cursor->index == -1) {
+ cursor->fence = dma_resv_excl_fence(obj);
+ cursor->index++;
+ if (!cursor->fence)
+ continue;
+
+ } else if (!cursor->fences ||
+ cursor->index >= cursor->fences->shared_count) {
+ cursor->fence = NULL;
+ break;
+
+ } else {
+ struct dma_resv_list *fences = cursor->fences;
+ unsigned int idx = cursor->index++;
+
+ cursor->fence = rcu_dereference(fences->shared[idx]);
+ }
+ cursor->fence = dma_fence_get_rcu(cursor->fence);
Worth having an assert dma_fence_get_rcu does not fail here? Not
sure that I have seen debug build only asserts though on the DRM
core side.
That won't work. It's perfectly valid for dma_fence_get_rcu() to
return NULL when we are racing here. Keep in mind that we don't
hold any locks.
Ah yes.. No need to change anything then, sorry for the confusion. I
did not find any holes, the rest was just about how to maybe make
the flow more obvious. Let me know if you want r-b now or later.
Now would be good. I've tried to make that more cleaner, but this
only lead to repeating the code more often.
Reviewed-by: Tvrtko Ursulin
Thanks, but what about the rest?
I'll go through the core patches, it just taking time.
i915 patches, again, I'd prefer you drop the busy ioctl but at least you
have i915_request_await_object as a pilot. The rest of i915 I'd prefer
someone who knows the display paths can answer whether locked or
unlocked iterator is the right one.
The selftests in this version still have some bugs which I already
fixed, but I think we could push most of the set.
Ah.. I just replied on that one.
Regards,
Tvrtko
Christian.
Regards,
Tvrtko
Regards,
Christian.
Regards,
Tvrtko
What we could do is to return NULL and repeat with a new sequence
immediately though.
On the bike shedding front, would it be clearer if the continue
condition on signaled fences was standalone, using the continue
statement? I'd also possibly re-arrange the three if-else blocks
so that the end of iteration is not sandwiched between blocks
handling exclusive and shared, and flow tweaked a bit, like:
struct dma_fence *fence = cursor->fence;
Re: [Intel-gfx] [PATCH 03/28] dma-buf: add dma_resv selftest
On 01/10/2021 11:05, Christian König wrote:
Just exercising a very minor subset of the functionality, but already
proven useful.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-resv.c | 164 ++
3 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/st-dma-resv.c
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 1ef021273a06..511805dbeb75 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o
dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
- st-dma-fence-chain.o
+ st-dma-fence-chain.o \
+ st-dma-resv.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h
index bc8cea67bf1e..97d73aaa31da 100644
--- a/drivers/dma-buf/selftests.h
+++ b/drivers/dma-buf/selftests.h
@@ -12,3 +12,4 @@
selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */
selftest(dma_fence, dma_fence)
selftest(dma_fence_chain, dma_fence_chain)
+selftest(dma_resv, dma_resv)
diff --git a/drivers/dma-buf/st-dma-resv.c b/drivers/dma-buf/st-dma-resv.c
new file mode 100644
index ..ea44769d058d
--- /dev/null
+++ b/drivers/dma-buf/st-dma-resv.c
@@ -0,0 +1,164 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+* Copyright © 2019 Intel Corporation
+*/
May want to update the year.
+
+//#include
+//#include
+//#include
+//#include
+//#include
And remove these?
+
+#include
+#include
+#include
+
+#include "selftest.h"
+
+static struct spinlock fence_lock;
+
+static const char *fence_name(struct dma_fence *f)
+{
+ return "selftest";
+}
+
+static const struct dma_fence_ops fence_ops = {
+ .get_driver_name = fence_name,
+ .get_timeline_name = fence_name,
+};
+
+static struct dma_fence *alloc_fence(void)
+{
+ struct dma_fence *f;
+
+ f = kmalloc(sizeof(*f), GFP_KERNEL);
+ if (!f)
+ return NULL;
+
+ dma_fence_init(f, _ops, _lock, 0, 0);
+ return f;
+}
+
+static int sanitycheck(void *arg)
+{
+ struct dma_fence *f;
+
+ f = alloc_fence();
+ if (!f)
+ return -ENOMEM;
+
+ dma_fence_signal(f);
+ dma_fence_put(f);
+ return 0;
+}
+
+static int test_excl_signaling(void *arg)
+{
+ struct dma_resv resv;
+ struct dma_fence *f;
+ int err = -EINVAL;
+
+ f = alloc_fence();
+ if (!f)
+ return -ENOMEM;
+
+ dma_resv_init();
+ dma_resv_add_excl_fence(, f);
+ if (dma_resv_test_signaled(, false)) {
+ pr_err("Resv unexpectedly signaled\n");
+ goto err_free;
+ }
+ dma_fence_signal(f);
+ if (!dma_resv_test_signaled(, false)) {
+ pr_err("Resv not reporting signaled\n");
+ goto err_free;
+ }
+ err = 0;
+err_free:
+ dma_resv_fini();
+ dma_fence_put(f);
+ return err;
+}
+
+static int test_shared_signaling(void *arg)
+{
+ struct dma_resv resv;
+ struct dma_fence *f;
+ int err;
+
+ f = alloc_fence();
+ if (!f)
+ return -ENOMEM;
+
+ dma_resv_init();
+ err = dma_resv_reserve_shared(, 1);
+ if (err) {
+ pr_err("Resv shared slot allocation failed\n");
+ goto err_free;
+ }
+
+ err = -EINVAL;
+ dma_resv_add_shared_fence(, f);
+ if (dma_resv_test_signaled(, true)) {
+ pr_err("Resv unexpectedly signaled\n");
+ goto err_free;
+ }
+ dma_fence_signal(f);
+ if (!dma_resv_test_signaled(, true)) {
+ pr_err("Resv not reporting signaled\n");
+ goto err_free;
+ }
+ err = 0;
+err_free:
+ dma_resv_fini();
+ dma_fence_put(f);
+ return err;
+}
Task for a rainy day - consolidate the above two into parameter driven
dma_resv setup (more fences, mixed signaling status, mixed exclusive and
shared, different signaling mode) and common verification stages.
+
+static int test_excl_for_each(void *arg)
+{
+ struct dma_resv_iter cursor;
+ struct dma_fence *f, *fence;
+ struct dma_resv resv;
+ int err;
+
+ f = alloc_fence();
+ if (!f)
+ return -ENOMEM;
+
+ dma_resv_init();
+ dma_resv_add_excl_fence(, f);
+
+ err = -EINVAL;
+ dma_resv_for_each_fence(, , false, fence) {
What about the dma_resv_assert_held(cursor->obj) assert? I must be
missing something..
+ if (f != fence) {
+ pr_err("Unexpected fence\n");
Best set err to something, unit tests should be super robust, like if
unexpected fence follows the expected one.
+ goto err_free;
+ }
+
[Intel-gfx] [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
In case of a modeset where a mode gets split across mutiple CRTCs
in the driver specific implementation (bigjoiner in i915) we wrongly count
the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
an affected CRTC in atomic_check_only().
This triggers a warning since affected CRTCs doent match requested CRTC.
To fix this in such bigjoiner configurations, we should only
increment affected crtcs if that CRTC is enabled in UAPI not
if it is just used internally in the driver to split the mode.
v3: Add the same uapi crtc_state->enable check in requested
crtc calc (Ville)
Cc: Ville Syrjälä
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Daniel Stone
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_atomic.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..a1e4c7905ebb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
DRM_DEBUG_ATOMIC("checking %p\n", state);
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- requested_crtc |= drm_crtc_mask(crtc);
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->enable)
+ requested_crtc |= drm_crtc_mask(crtc);
+ }
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
@@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- affected_crtc |= drm_crtc_mask(crtc);
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->enable)
+ affected_crtc |= drm_crtc_mask(crtc);
+ }
/*
* For commits that allow modesets drivers can add other CRTCs to the
--
2.19.1
Re: [Intel-gfx] [PATCH 01/28] dma-buf: add dma_resv_for_each_fence_unlocked v7
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they might be freed,
improve kerneldoc, rename _cursor to _iter, add
dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end
v3: restructor the code, move rcu_read_lock()/unlock() into the
iterator, add dma_resv_iter_is_restarted()
v4: fix NULL deref when no explicit fence exists, drop superflous
rcu_read_lock()/unlock() calls.
v5: fix typos in the documentation
v6: fix coding error when excl fence is NULL
v7: one more logic fix
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 100 +
include/linux/dma-resv.h | 95 +++
2 files changed, 195 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 84fbe60629e3..3cbcf66a137e 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -323,6 +323,106 @@ void dma_resv_add_excl_fence(struct dma_resv
*obj, struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_resv_add_excl_fence);
+/**
+ * dma_resv_iter_restart_unlocked - restart the unlocked iterator
+ * @cursor: The dma_resv_iter object to restart
+ *
+ * Restart the unlocked iteration by initializing the cursor object.
+ */
+static void dma_resv_iter_restart_unlocked(struct dma_resv_iter
*cursor)
+{
+ cursor->seq = read_seqcount_begin(>obj->seq);
+ cursor->index = -1;
+ if (cursor->all_fences)
+ cursor->fences = dma_resv_shared_list(cursor->obj);
+ else
+ cursor->fences = NULL;
+ cursor->is_restarted = true;
+}
+
+/**
+ * dma_resv_iter_walk_unlocked - walk over fences in a dma_resv obj
+ * @cursor: cursor to record the current position
+ *
+ * Return all the fences in the dma_resv object which are not yet
signaled.
+ * The returned fence has an extra local reference so will stay alive.
+ * If a concurrent modify is detected the whole iteration is started
over again.
+ */
+static void dma_resv_iter_walk_unlocked(struct dma_resv_iter *cursor)
+{
+ struct dma_resv *obj = cursor->obj;
+
+ do {
+ /* Drop the reference from the previous round */
+ dma_fence_put(cursor->fence);
+
+ if (cursor->index == -1) {
+ cursor->fence = dma_resv_excl_fence(obj);
+ cursor->index++;
+ if (!cursor->fence)
+ continue;
+
+ } else if (!cursor->fences ||
+ cursor->index >= cursor->fences->shared_count) {
+ cursor->fence = NULL;
+ break;
+
+ } else {
+ struct dma_resv_list *fences = cursor->fences;
+ unsigned int idx = cursor->index++;
+
+ cursor->fence = rcu_dereference(fences->shared[idx]);
+ }
+ cursor->fence = dma_fence_get_rcu(cursor->fence);
Worth having an assert dma_fence_get_rcu does not fail here? Not sure
that I have seen debug build only asserts though on the DRM core side.
That won't work. It's perfectly valid for dma_fence_get_rcu() to return
NULL when we are racing here. Keep in mind that we don't hold any locks.
What we could do is to return NULL and repeat with a new sequence
immediately though.
On the bike shedding front, would it be clearer if the continue
condition on signaled fences was standalone, using the continue
statement? I'd also possibly re-arrange the three if-else blocks so
that the end of iteration is not sandwiched between blocks handling
exclusive and shared, and flow tweaked a bit, like:
struct dma_fence *fence = cursor->fence;
int index = cursor->index;
dma_fence_put(fence);
fence = NULL;
next:
if (index == -1) {
/* Try picking the exclusive fence. */
index++;
fence = dma_resv_excl_fence(obj);
if (!fence)
goto next;
} else if (cursor->fences && index < cursor->fences->shared_count) {
/* Try picking next shared fence. */
struct dma_resv_list *fences = cursor->fences;
fence = rcu_dereference(fences->shared[index++]);
}
if (fence) {
if (dma_fence_is_signaled(fence))
goto next; /* Skip signaled. */
fence = dma_fence_get_rcu(fence);
WARN_ON(!fence);
}
cursor->fence = fence;
cursor->index = index;
(I started with a loop here but ended with goto based flow since it
ended up more succinct.)
At least if I don't have a handling flaw in there it looks like easier
to follow flow to me. Plus picking a not signaled fence works without
a reference FWIW.
I strongly don't think that this will work correctly. You need to grab a
reference first when you want to call dma_fence_is_signaled(), that's
why I used the testbit approach initially.
How does it look to you?
Mhm, let me try to reorder the loop once
Re: [Intel-gfx] [PATCH 01/28] dma-buf: add dma_resv_for_each_fence_unlocked v7
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they might be freed,
improve kerneldoc, rename _cursor to _iter, add
dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end
v3: restructor the code, move rcu_read_lock()/unlock() into the
iterator, add dma_resv_iter_is_restarted()
v4: fix NULL deref when no explicit fence exists, drop superflous
rcu_read_lock()/unlock() calls.
v5: fix typos in the documentation
v6: fix coding error when excl fence is NULL
v7: one more logic fix
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 100
+
include/linux/dma-resv.h | 95 +++
2 files changed, 195 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 84fbe60629e3..3cbcf66a137e 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -323,6 +323,106 @@ void dma_resv_add_excl_fence(struct dma_resv
*obj, struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_resv_add_excl_fence);
+/**
+ * dma_resv_iter_restart_unlocked - restart the unlocked iterator
+ * @cursor: The dma_resv_iter object to restart
+ *
+ * Restart the unlocked iteration by initializing the cursor object.
+ */
+static void dma_resv_iter_restart_unlocked(struct dma_resv_iter
*cursor)
+{
+ cursor->seq = read_seqcount_begin(>obj->seq);
+ cursor->index = -1;
+ if (cursor->all_fences)
+ cursor->fences = dma_resv_shared_list(cursor->obj);
+ else
+ cursor->fences = NULL;
+ cursor->is_restarted = true;
+}
+
+/**
+ * dma_resv_iter_walk_unlocked - walk over fences in a dma_resv obj
+ * @cursor: cursor to record the current position
+ *
+ * Return all the fences in the dma_resv object which are not yet
signaled.
+ * The returned fence has an extra local reference so will stay
alive.
+ * If a concurrent modify is detected the whole iteration is
started over again.
+ */
+static void dma_resv_iter_walk_unlocked(struct dma_resv_iter *cursor)
+{
+ struct dma_resv *obj = cursor->obj;
+
+ do {
+ /* Drop the reference from the previous round */
+ dma_fence_put(cursor->fence);
+
+ if (cursor->index == -1) {
+ cursor->fence = dma_resv_excl_fence(obj);
+ cursor->index++;
+ if (!cursor->fence)
+ continue;
+
+ } else if (!cursor->fences ||
+ cursor->index >= cursor->fences->shared_count) {
+ cursor->fence = NULL;
+ break;
+
+ } else {
+ struct dma_resv_list *fences = cursor->fences;
+ unsigned int idx = cursor->index++;
+
+ cursor->fence = rcu_dereference(fences->shared[idx]);
+ }
+ cursor->fence = dma_fence_get_rcu(cursor->fence);
Worth having an assert dma_fence_get_rcu does not fail here? Not
sure that I have seen debug build only asserts though on the DRM
core side.
That won't work. It's perfectly valid for dma_fence_get_rcu() to
return NULL when we are racing here. Keep in mind that we don't hold
any locks.
Ah yes.. No need to change anything then, sorry for the confusion. I
did not find any holes, the rest was just about how to maybe make the
flow more obvious. Let me know if you want r-b now or later.
Now would be good. I've tried to make that more cleaner, but this only
lead to repeating the code more often.
Regards,
Christian.
Regards,
Tvrtko
What we could do is to return NULL and repeat with a new sequence
immediately though.
On the bike shedding front, would it be clearer if the continue
condition on signaled fences was standalone, using the continue
statement? I'd also possibly re-arrange the three if-else blocks so
that the end of iteration is not sandwiched between blocks handling
exclusive and shared, and flow tweaked a bit, like:
struct dma_fence *fence = cursor->fence;
int index = cursor->index;
dma_fence_put(fence);
fence = NULL;
next:
if (index == -1) {
/* Try picking the exclusive fence. */
index++;
fence = dma_resv_excl_fence(obj);
if (!fence)
goto next;
} else if (cursor->fences && index < cursor->fences->shared_count) {
/* Try picking next shared fence. */
struct dma_resv_list *fences = cursor->fences;
fence = rcu_dereference(fences->shared[index++]);
}
if (fence) {
if (dma_fence_is_signaled(fence))
goto next; /* Skip signaled. */
fence = dma_fence_get_rcu(fence);
WARN_ON(!fence);
}
cursor->fence = fence;
cursor->index = index;
(I started with a loop here but ended with goto based flow since
[Intel-gfx] [PATCH] drm/i915: Prefer struct_size over open coded arithmetic
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrapping around and a smaller allocation being made than the
caller was expecting. Using those allocations could lead to linear
overflows of heap memory and other misbehaviors.
In this case these are not actually dynamic sizes: all the operands
involved in the calculation are constant values. However it is better to
refactor them anyway, just to keep the open-coded math idiom out of
code.
So, add at the end of the struct i915_syncmap a union with two flexible
array members (these arrays share the same memory layout). This is
possible using the new DECLARE_FLEX_ARRAY macro. And then, use the
struct_size() helper to do the arithmetic instead of the argument
"size + count * size" in the kmalloc and kzalloc() functions.
Also, take the opportunity to refactor the __sync_seqno and __sync_child
making them more readable.
This code was detected with the help of Coccinelle and audited and fixed
manually.
[1]
https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
Signed-off-by: Len Baker
---
drivers/gpu/drm/i915/i915_syncmap.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_syncmap.c
b/drivers/gpu/drm/i915/i915_syncmap.c
index 60404dbb2e9f..a8d35491d05a 100644
--- a/drivers/gpu/drm/i915/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/i915_syncmap.c
@@ -82,6 +82,10 @@ struct i915_syncmap {
* struct i915_syncmap *child[KSYNCMAP];
* };
*/
+ union {
+ DECLARE_FLEX_ARRAY(u32, seqno);
+ DECLARE_FLEX_ARRAY(struct i915_syncmap *, child);
+ };
};
/**
@@ -99,13 +103,13 @@ void i915_syncmap_init(struct i915_syncmap **root)
static inline u32 *__sync_seqno(struct i915_syncmap *p)
{
GEM_BUG_ON(p->height);
- return (u32 *)(p + 1);
+ return p->seqno;
}
static inline struct i915_syncmap **__sync_child(struct i915_syncmap *p)
{
GEM_BUG_ON(!p->height);
- return (struct i915_syncmap **)(p + 1);
+ return p->child;
}
static inline unsigned int
@@ -200,7 +204,7 @@ __sync_alloc_leaf(struct i915_syncmap *parent, u64 id)
{
struct i915_syncmap *p;
- p = kmalloc(sizeof(*p) + KSYNCMAP * sizeof(u32), GFP_KERNEL);
+ p = kmalloc(struct_size(p, seqno, KSYNCMAP), GFP_KERNEL);
if (unlikely(!p))
return NULL;
@@ -282,7 +286,7 @@ static noinline int __sync_set(struct i915_syncmap **root,
u64 id, u32 seqno)
unsigned int above;
/* Insert a join above the current layer */
- next = kzalloc(sizeof(*next) + KSYNCMAP * sizeof(next),
+ next = kzalloc(struct_size(next, child, KSYNCMAP),
GFP_KERNEL);
if (unlikely(!next))
return -ENOMEM;
--
2.25.1
Re: [Intel-gfx] [PATCH v2] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Mon, Oct 04, 2021 at 04:36:29AM -0700, Manasi Navare wrote:
> In case of a modeset where a mode gets split across mutiple CRTCs
> in the driver specific implementation (bigjoiner in i915) we wrongly count
> the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
> an affected CRTC in atomic_check_only().
> This triggers a warning since affected CRTCs doent match requested CRTC.
>
> To fix this in such bigjoiner configurations, we should only
> increment affected crtcs if that CRTC is enabled in UAPI not
> if it is just used internally in the driver to split the mode.
>
> There is no way we can adjust requested_crtc calculation as suggested
> in review comments because the crtc gets stolen only after the atomic_check
> call.
The uapi crtc_state->enable value does not change due to bigjoiner
stealing the crtc. So I don't understand what you're trying to say
here.
The only internal thing that could alter the set of enabled crtcs
on the uapi level is update_connector_routing(true), but that is
always called before drm_atomic_check_only().
>
> Cc: Ville Syrjälä
> Cc: Simon Ser
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_atomic.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ff1416cd609a..44e7ebf43a2a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1360,8 +1360,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - affected_crtc |= drm_crtc_mask(crtc);
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->enable)
> + affected_crtc |= drm_crtc_mask(crtc);
> + }
>
> /*
>* For commits that allow modesets drivers can add other CRTCs to the
> --
> 2.19.1
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH v2] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
In case of a modeset where a mode gets split across mutiple CRTCs
in the driver specific implementation (bigjoiner in i915) we wrongly count
the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
an affected CRTC in atomic_check_only().
This triggers a warning since affected CRTCs doent match requested CRTC.
To fix this in such bigjoiner configurations, we should only
increment affected crtcs if that CRTC is enabled in UAPI not
if it is just used internally in the driver to split the mode.
There is no way we can adjust requested_crtc calculation as suggested
in review comments because the crtc gets stolen only after the atomic_check
call.
Cc: Ville Syrjälä
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Daniel Stone
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_atomic.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..44e7ebf43a2a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1360,8 +1360,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- affected_crtc |= drm_crtc_mask(crtc);
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->enable)
+ affected_crtc |= drm_crtc_mask(crtc);
+ }
/*
* For commits that allow modesets drivers can add other CRTCs to the
--
2.19.1
[Intel-gfx] [PATCH 5/5] drm/i915: Call intel_dp_dump_link_status() for CR failures
From: Ville Syrjälä
I suppose intel_dp_dump_link_status() might be useful for diagnosing
link training failures. Hoever we only call from the channel EQ phase
currently. Let's call it from the CR phase as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 18f4b469766e..c92044710012 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -649,6 +649,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
u8 old_link_status[DP_LINK_STATUS_SIZE] = {};
int voltage_tries, cr_tries, max_cr_tries;
+ u8 link_status[DP_LINK_STATUS_SIZE];
bool max_vswing_reached = false;
char phy_name[10];
@@ -678,8 +679,6 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
voltage_tries = 1;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
- u8 link_status[DP_LINK_STATUS_SIZE];
-
intel_dp_link_training_clock_recovery_delay(intel_dp, dp_phy);
if (drm_dp_dpcd_read_phy_link_status(_dp->aux, dp_phy,
@@ -697,6 +696,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
}
if (voltage_tries == 5) {
+ intel_dp_dump_link_status(intel_dp, dp_phy,
link_status);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s][%s] Same voltage tried 5
times\n",
encoder->base.base.id, encoder->base.name,
phy_name);
@@ -704,6 +704,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
}
if (max_vswing_reached) {
+ intel_dp_dump_link_status(intel_dp, dp_phy,
link_status);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s][%s] Max Voltage Swing
reached\n",
encoder->base.base.id, encoder->base.name,
phy_name);
@@ -732,6 +733,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
max_vswing_reached = true;
}
+ intel_dp_dump_link_status(intel_dp, dp_phy, link_status);
drm_err(>drm,
"[ENCODER:%d:%s][%s] Failed clock recovery %d times, giving
up!\n",
encoder->base.base.id, encoder->base.name, phy_name,
max_cr_tries);
--
2.32.0
[Intel-gfx] [PATCH 3/5] drm/i915: Print the DP vswing adjustment request
From: Ville Syrjälä
Print out each DP vswing adjustment request we got from the RX.
Could help in diagnosing what's going on during link training.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 6bab097cafd2..5657be1461ec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -343,14 +343,41 @@ static u8 intel_dp_get_lane_adjust_train(struct intel_dp
*intel_dp,
return v | p;
}
+#define TRAIN_REQ_FMT "%d/%d/%d/%d"
+#define _TRAIN_REQ_VSWING_ARGS(link_status, lane) \
+ (drm_dp_get_adjust_request_voltage((link_status), (lane)) >>
DP_TRAIN_VOLTAGE_SWING_SHIFT)
+#define TRAIN_REQ_VSWING_ARGS(link_status) \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 0), \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 1), \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 2), \
+ _TRAIN_REQ_VSWING_ARGS(link_status, 3)
+#define _TRAIN_REQ_PREEMPH_ARGS(link_status, lane) \
+ (drm_dp_get_adjust_request_pre_emphasis((link_status), (lane)) >>
DP_TRAIN_PRE_EMPHASIS_SHIFT)
+#define TRAIN_REQ_PREEMPH_ARGS(link_status) \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 0), \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 1), \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 2), \
+ _TRAIN_REQ_PREEMPH_ARGS(link_status, 3)
+
void
intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
enum drm_dp_phy dp_phy,
const u8 link_status[DP_LINK_STATUS_SIZE])
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ char phy_name[10];
int lane;
+ drm_dbg_kms(encoder->base.dev, "[ENCODER:%d:%s] lanes: %d, "
+ "vswing request: " TRAIN_REQ_FMT ", "
+ "pre-emphasis request: " TRAIN_REQ_FMT ", at %s\n",
+ encoder->base.base.id, encoder->base.name,
+ crtc_state->lane_count,
+ TRAIN_REQ_VSWING_ARGS(link_status),
+ TRAIN_REQ_PREEMPH_ARGS(link_status),
+ intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)));
+
for (lane = 0; lane < 4; lane++)
intel_dp->train_set[lane] =
intel_dp_get_lane_adjust_train(intel_dp, crtc_state,
--
2.32.0
[Intel-gfx] [PATCH 4/5] drm/i915: Pimp link training debug prints
From: Ville Syrjälä
Unify all debug prints during link training to include information
on both the encoder and the LTTPR. We unify the format to something
like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not
sure if those brackets around the dp_phy just make it look like
line noise? I'll accept suggestions on better formatting.
I'm slightly on the fence about also including the connector,
but technically only the DPRX is the SST connector (ie.
intel_dp->attached_connector). I suppose you could think of it
as the branch device/whatever in the topology, and we're training
the link leading to it. So that could argue for its inclusion.
But it's all getting a bit long alrady, so not going to do it
I think.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 167 +++---
1 file changed, 106 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 5657be1461ec..18f4b469766e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -25,15 +25,6 @@
#include "intel_dp.h"
#include "intel_dp_link_training.h"
-static void
-intel_dp_dump_link_status(struct drm_device *drm,
- const u8 link_status[DP_LINK_STATUS_SIZE])
-{
- drm_dbg_kms(drm,
- "ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x adj_req0_1:0x%x
adj_req2_3:0x%x\n",
- link_status[0], link_status[1], link_status[2],
- link_status[3], link_status[4], link_status[5]);
-}
static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
{
@@ -66,6 +57,7 @@ static u8 *intel_dp_lttpr_phy_caps(struct intel_dp *intel_dp,
static void intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp,
enum drm_dp_phy dp_phy)
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
char phy_name[10];
@@ -73,21 +65,22 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp
*intel_dp,
if (drm_dp_read_lttpr_phy_caps(_dp->aux, dp_phy, phy_caps) < 0) {
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "failed to read the PHY caps for %s\n",
- phy_name);
+ "[ENCODER:%d:%s][%s] failed to read the PHY caps\n",
+ encoder->base.base.id, encoder->base.name,
phy_name);
return;
}
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "%s PHY capabilities: %*ph\n",
- phy_name,
+ "[ENCODER:%d:%s][%s] PHY capabilities: %*ph\n",
+ encoder->base.base.id, encoder->base.name, phy_name,
(int)sizeof(intel_dp->lttpr_phy_caps[0]),
phy_caps);
}
static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
{
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
if (intel_dp_is_edp(intel_dp))
return false;
@@ -104,7 +97,8 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp
*intel_dp)
goto reset_caps;
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "LTTPR common capabilities: %*ph\n",
+ "[ENCODER:%d:%s] LTTPR common capabilities: %*ph\n",
+ encoder->base.base.id, encoder->base.name,
(int)sizeof(intel_dp->lttpr_common_caps),
intel_dp->lttpr_common_caps);
@@ -130,6 +124,8 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp
*intel_dp, bool enable)
static int intel_dp_init_lttpr(struct intel_dp *intel_dp)
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
int lttpr_count;
int i;
@@ -161,8 +157,9 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp)
return 0;
if (!intel_dp_set_lttpr_transparent_mode(intel_dp, false)) {
- drm_dbg_kms(_to_i915(intel_dp)->drm,
- "Switching to LTTPR non-transparent LT mode failed,
fall-back to transparent mode\n");
+ drm_dbg_kms(>drm,
+ "[ENCODER:%d:%s] Switching to LTTPR non-transparent
LT mode failed, fall-back to transparent mode\n",
+ encoder->base.base.id, encoder->base.name);
intel_dp_set_lttpr_transparent_mode(intel_dp, true);
intel_dp_reset_lttpr_count(intel_dp);
@@ -366,17 +363,18 @@ intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8
[Intel-gfx] [PATCH 2/5] drm/i915: Show LTTPR in the TPS debug print
From: Ville Syrjälä
Indicate which LTTPR we're currently attempting to train when
we print which training pattern we're using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 11 +++
drivers/gpu/drm/i915/display/intel_dp_link_training.h | 1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index 60ae2ba52006..85a09c3e09e8 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -637,7 +637,7 @@ static void intel_dp_enable_port(struct intel_dp *intel_dp,
/* enable with pattern 1 (as per spec) */
intel_dp_program_link_training_pattern(intel_dp, crtc_state,
- DP_TRAINING_PATTERN_1);
+ DP_PHY_DPRX,
DP_TRAINING_PATTERN_1);
/*
* Magic for VLV/CHV. We _must_ first set up the register
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index a45569b8c959..6bab097cafd2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -376,7 +376,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
int len;
intel_dp_program_link_training_pattern(intel_dp, crtc_state,
- dp_train_pat);
+ dp_phy, dp_train_pat);
buf[0] = dp_train_pat;
/* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
@@ -404,17 +404,20 @@ static char dp_training_pattern_name(u8 train_pat)
void
intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state,
+ enum drm_dp_phy dp_phy,
u8 dp_train_pat)
{
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u8 train_pat = intel_dp_training_pattern_symbol(dp_train_pat);
+ char phy_name[10];
if (train_pat != DP_TRAINING_PATTERN_DISABLE)
drm_dbg_kms(_priv->drm,
- "[ENCODER:%d:%s] Using DP training pattern TPS%c\n",
+ "[ENCODER:%d:%s] Using DP training pattern TPS%c,
at %s\n",
encoder->base.base.id, encoder->base.name,
- dp_training_pattern_name(train_pat));
+ dp_training_pattern_name(train_pat),
+ intel_dp_phy_name(dp_phy, phy_name,
sizeof(phy_name)));
intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
}
@@ -855,7 +858,7 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp,
intel_dp->link_trained = true;
intel_dp_disable_dpcd_training_pattern(intel_dp, DP_PHY_DPRX);
- intel_dp_program_link_training_pattern(intel_dp, crtc_state,
+ intel_dp_program_link_training_pattern(intel_dp, crtc_state,
DP_PHY_DPRX,
DP_TRAINING_PATTERN_DISABLE);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 9d24d594368c..6a3a7b37349a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -19,6 +19,7 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8 link_status[DP_LINK_STATUS_SIZE]);
void intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state,
+ enum drm_dp_phy dp_phy,
u8 dp_train_pat);
void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
--
2.32.0
[Intel-gfx] [PATCH 1/5] drm/i915: Tweak the DP "max vswing reached?" condition
From: Ville Syrjälä
Currently we consider the max vswing reached when we transmit a
the max voltage level, but we don't consider pre-emphasis at all.
This kinda matches older DP specs that only had some vague text
about transmitting the maximum voltage swing. Latest versions
now say something vague about consider the sum of the vswing
and pre-emphasis fields in the ADJUST_REQUEST_LANE registers.
Very vague, and super confusing especially the fact that it
talks about transmitted voltgage swing in the same sentence
as it say to look at the requested values.
Also glanced at the link CTS spec, and that one seems to have
tests that assume contradicting behaviour. Some say to consider
just the vswing level we transmit, others say to check for
sum of transmitted vswing+preemph being 3.
So let's try to take some kind of sane middle ground here.
I think what could make sense is only consider max vswing
reached if MAX_SWING_REACHED==1 _and_ vswing+preemph==3.
That will allow things to go all the way up to vswing 3 +
pre-emph 0 or vswing 2 + pre-emph 1, depending on what
the maximum supported vswing is. Only considering the sum
of vswing+pre-emph doesn't make much sense to me since
we could terminate too early if the sink requests eg.
vswing 0 + pre-emph 3. And if we'd stick to the current
code we could terminate too early of the sink asks for
vswing 2 + pre-emph 0 when vswing level 3 is not supported.
Side note: I don't really understand why any of this stuff is
"specified" at all. There is already a limit of 5 attempts at
the same vswing+pre-emph level, and a total limit of 10
attempts. So might as well stick to the same max 5 attempts
across the board IMO.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 22 ---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index c052ce14894d..a45569b8c959 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -492,11 +492,27 @@ static bool intel_dp_link_max_vswing_reached(struct
intel_dp *intel_dp,
{
int lane;
- for (lane = 0; lane < crtc_state->lane_count; lane++)
- if ((intel_dp->train_set[lane] &
-DP_TRAIN_MAX_SWING_REACHED) == 0)
+ /*
+* FIXME: The DP spec is very confusing here, also the Link CTS
+* spec seems to have self contradicting tests around this area.
+*
+* In lieu of better ideas let's just stop when we've reached the
+* max supported vswing with its max pre-emphasis, which is either
+* 2+1 or 3+0 depending on whether vswing level 3 is supported or not.
+*/
+ for (lane = 0; lane < crtc_state->lane_count; lane++) {
+ u8 v = (intel_dp->train_set[lane] &
DP_TRAIN_VOLTAGE_SWING_MASK) >>
+ DP_TRAIN_VOLTAGE_SWING_SHIFT;
+ u8 p = (intel_dp->train_set[lane] & DP_TRAIN_PRE_EMPHASIS_MASK)
>>
+ DP_TRAIN_PRE_EMPHASIS_SHIFT;
+
+ if ((intel_dp->train_set[lane] & DP_TRAIN_MAX_SWING_REACHED) ==
0)
return false;
+ if (v + p != 3)
+ return false;
+ }
+
return true;
}
--
2.32.0
