[Intel-gfx] ✓ Fi.CI.BAT: success for i915 TTM sync accelerated migration and clear (rev4)
== Series Details ==
Series: i915 TTM sync accelerated migration and clear (rev4)
URL : https://patchwork.freedesktop.org/series/91463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10233 -> Patchwork_20397
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/index.html
New tests
-
New tests have been introduced between CI_DRM_10233 and Patchwork_20397:
### New IGT tests (1) ###
* igt@i915_selftest@live@migrate:
- Statuses : 2 dmesg-warn(s) 32 pass(s)
- Exec time: [0.53, 9.0] s
Known issues
Here are the changes found in Patchwork_20397 that come from known issues:
### IGT changes ###
Issues hit
* {igt@i915_selftest@live@migrate} (NEW):
- {fi-ehl-2}: NOTRUN -> [DMESG-WARN][1] ([i915#1222])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/fi-ehl-2/igt@i915_selftest@l...@migrate.html
- {fi-jsl-1}: NOTRUN -> [DMESG-WARN][2] ([i915#1222])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/fi-jsl-1/igt@i915_selftest@l...@migrate.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {fi-tgl-dsi}: [DMESG-WARN][3] ([i915#1982] / [i915#2411]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-tgl-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/fi-tgl-dsi/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
Participating hosts (43 -> 38)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10233 -> Patchwork_20397
CI-20190529: 20190529
CI_DRM_10233: e00d16681acd7e91fd02f800adcc20cca89f6127 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6109: 61ba2ed489540e6a8a649be38abb075b3ab4d28a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20397: 0c1b355b98b0c758f219b94ae5ffcbda0a6acf75 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0c1b355b98b0 drm/i915/gem: Zap the i915_gem_object_blt code
f96ba67920e0 drm/i915/gem: Zap the client blt code
44bc96f6062f drm/i915/ttm: accelerated move implementation
af79c48203b1 drm/i915/gt: Setup a default migration context on the GT
50c44cdbf0dc drm/i915/gt: Pipelined clear
1348ed66563c drm/i915/gt: Pipelined page migration
dafe4c39f77d drm/i915/gt: Export the pinned context constructor and destructor
63732fd3b3dd drm/i915/gt: Add a routine to iterate over the pagetables of a GTT
55d91f54ea63 drm/i915/gt: Add an insert_entry for gen8_ppgtt
3d2c4703e490 drm/i915: Introduce a ww transaction helper
b3d1124db2b3 drm/i915: Break out dma_resv ww locking utilities to separate files
05e61818c510 drm/i915: Reference objects on the ww object list
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add relocation exceptions for two other platforms (rev8)
== Series Details == Series: drm/i915: Add relocation exceptions for two other platforms (rev8) URL : https://patchwork.freedesktop.org/series/89594/ State : success == Summary == CI Bug Log - changes from CI_DRM_10233_full -> Patchwork_20395_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20395_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-noreloc-purge-cache-random: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271]) +180 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-snb5/igt@api_intel...@blit-noreloc-purge-cache-random.html * igt@drm_mm@all@insert_range: - shard-skl: NOTRUN -> [INCOMPLETE][2] ([i915#2485]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-skl8/igt@drm_mm@all@insert_range.html * igt@gem_create@create-clear: - shard-glk: NOTRUN -> [FAIL][3] ([i915#1888] / [i915#3160]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-glk8/igt@gem_cre...@create-clear.html * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-snb7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-cleanup: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-cleanup.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk3/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-iclb8/igt@gem_exec_fair@basic-p...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-iclb8/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][14] ([i915#2389]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][15] ([i915#2389]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-glk: [PASS][16] -> [DMESG-WARN][17] ([i915#118] / [i915#95]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-glk3/igt@gem_exec_whis...@basic-contexts-priority.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#307]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk4/igt@gem_mmap_...@cpuset-big-copy-xy.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-glk9/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-kbl7/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-apl6/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][22] ([i915#3002]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20395/shard-apl8/igt
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg1: Add HWMON power sensor support (rev6)
== Series Details == Series: drm/i915/dg1: Add HWMON power sensor support (rev6) URL : https://patchwork.freedesktop.org/series/88459/ State : warning == Summary == $ dim checkpatch origin/drm-tip 77d53ceadffe drm/i915/dg1: Add HWMON power sensor support -:22: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #22: new file mode 100644 -:250: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible side-effects? #250: FILE: drivers/gpu/drm/i915/i915_hwmon.c:31: +#define FIELD_SHIFT(__mask)\ + (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \ + BUILD_BUG_ON_ZERO((__mask) == 0) + \ + __bf_shf(__mask)) total: 0 errors, 1 warnings, 1 checks, 1042 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for i915 TTM sync accelerated migration and clear (rev4)
== Series Details == Series: i915 TTM sync accelerated migration and clear (rev4) URL : https://patchwork.freedesktop.org/series/91463/ State : success == Summary == CI Bug Log - changes from CI_DRM_10233_full -> Patchwork_20397_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_10233_full and Patchwork_20397_full: ### New IGT tests (2) ### * igt@i915_selftest@live@migrate: - Statuses : 6 pass(s) - Exec time: [1.18, 8.51] s * igt@i915_selftest@perf@migrate: - Statuses : 5 pass(s) - Exec time: [1.31, 6.13] s Known issues Here are the changes found in Patchwork_20397_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_mm@all@insert_range: - shard-skl: NOTRUN -> [INCOMPLETE][1] ([i915#2485]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-skl4/igt@drm_mm@all@insert_range.html * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-snb6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-cleanup: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-cleanup.html * igt@gem_ctx_shared@detached-shared-gtt: - shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk3/igt@gem_ctx_sha...@detached-shared-gtt.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-glk4/igt@gem_ctx_sha...@detached-shared-gtt.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] / [i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-iclb8/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-iclb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk3/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-glk4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][14] ([i915#2842]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][16] ([i915#2389]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_pwrite@basic-exhaustion: - shard-kbl: NOTRUN -> [WARN][17] ([i915#2658]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-kbl4/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][18] ([i915#3002]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-apl1/igt@gem_userptr_bl...@input-checking.html * igt@i915_hangman@engine-error@vecs0: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271]) +94 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-kbl1/igt@i915_hangman@engine-er...@vecs0.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1937]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20397/shard-apl3/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][21] -> [IN
[Intel-gfx] [PATCH] drm/i915/ttm: remove unused function
intel_region_ttm_node_free is no longer used. Also fixup the related
kerneldoc.
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/intel_region_ttm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index d53d78dec2be..4cd10f364e84 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -141,7 +141,7 @@ struct sg_table *intel_region_ttm_resource_to_st(struct
intel_memory_region *mem
#ifdef CONFIG_DRM_I915_SELFTEST
/**
- * intel_region_ttm_node_alloc - Allocate memory resources from a region
+ * intel_region_ttm_resource_alloc - Allocate memory resources from a region
* @mem: The memory region,
* @size: The requested size in bytes
* @flags: Allocation flags
@@ -150,8 +150,8 @@ struct sg_table *intel_region_ttm_resource_to_st(struct
intel_memory_region *mem
* memory from standalone TTM range managers, without the TTM eviction
* functionality. Don't use if you are not completely sure that's the
* case. The returned opaque node can be converted to an sg_table using
- * intel_region_ttm_node_to_st(), and can be freed using
- * intel_region_ttm_node_free().
+ * intel_region_ttm_resource_to_st(), and can be freed using
+ * intel_region_ttm_resource_free().
*
* Return: A valid pointer on success, an error pointer on failure.
*/
@@ -178,14 +178,6 @@ intel_region_ttm_resource_alloc(struct intel_memory_region
*mem,
#endif
-void intel_region_ttm_node_free(struct intel_memory_region *mem,
- struct ttm_resource *res)
-{
- struct ttm_resource_manager *man = mem->region_private;
-
- man->func->free(man, res);
-}
-
/**
* intel_region_ttm_resource_free - Free a resource allocated from a resource
manager
* @mem: The region the resource was allocated from.
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Remove duplicated call to ops->pread
On Wed, Jun 16, 2021 at 11:45:28AM +0100, Matthew Auld wrote: > On Wed, 16 Jun 2021 at 10:04, Daniel Vetter wrote: > > > > Between > > > > commit ae30af84edb5b7cc95485922e43afd909a892e1b > > Author: Maarten Lankhorst > > Date: Tue Mar 23 16:50:00 2021 +0100 > > > > drm/i915: Disable userptr pread/pwrite support. > > > > and > > > > commit 0049b688459b846f819b6e51c24cd0781fcfde41 > > Author: Matthew Auld > > Date: Thu Nov 5 15:49:33 2020 + > > > > drm/i915/gem: Allow backends to override pread implementation > > > > this accidentally landed twice. > > > > Cc: Matthew Auld > Cc: Thomas Hellström > > Cc: Jason Ekstrand > > Cc: Daniel Vetter > > Signed-off-by: Daniel Vetter > Reviewed-by: Matthew Auld > > --- > > drivers/gpu/drm/i915/i915_gem.c | 6 -- > > 1 file changed, 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 6a0a3f0e36e1..07aa80773a02 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -469,12 +469,6 @@ i915_gem_pread_ioctl(struct drm_device *dev, void > > *data, > > if (ret != -ENODEV) > > goto out; > > > > - ret = -ENODEV; > > - if (obj->ops->pread) > > - ret = obj->ops->pread(obj, args); > > - if (ret != -ENODEV) > > - goto out; > > - > > ret = i915_gem_object_wait(obj, > >I915_WAIT_INTERRUPTIBLE, > >MAX_SCHEDULE_TIMEOUT); > > -- > > 2.32.0.rc2 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg1: Add HWMON power sensor support (rev6)
== Series Details ==
Series: drm/i915/dg1: Add HWMON power sensor support (rev6)
URL : https://patchwork.freedesktop.org/series/88459/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10233 -> Patchwork_20398
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20398 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20398, 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_20398/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20398:
### IGT changes ###
Possible regressions
* igt@core_hotunplug@unbind-rebind:
- fi-elk-e7500: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-elk-e7500/igt@core_hotunp...@unbind-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-elk-e7500/igt@core_hotunp...@unbind-rebind.html
- fi-ilk-650: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-ilk-650/igt@core_hotunp...@unbind-rebind.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-ilk-650/igt@core_hotunp...@unbind-rebind.html
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-bsw-nick/igt@core_hotunp...@unbind-rebind.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-bsw-nick/igt@core_hotunp...@unbind-rebind.html
- fi-bwr-2160:[PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html
Known issues
Here are the changes found in Patchwork_20398 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-pnv-d510:[PASS][9] -> [INCOMPLETE][10] ([i915#299])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-pnv-d510/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-pnv-d510/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-kbl-soraka/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][13] ([i915#2283] / [i915#2426])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-ilk-650/igt@run...@aborted.html
- fi-pnv-d510:NOTRUN -> [FAIL][14] ([i915#2403] / [i915#2505])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-pnv-d510/igt@run...@aborted.html
- fi-bdw-5557u: NOTRUN -> [FAIL][15] ([i915#1602] / [i915#2029])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-bdw-5557u/igt@run...@aborted.html
- fi-bwr-2160:NOTRUN -> [FAIL][16] ([i915#2505])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-bwr-2160/igt@run...@aborted.html
- fi-elk-e7500: NOTRUN -> [FAIL][17] ([i915#2426])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-elk-e7500/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {fi-tgl-dsi}: [DMESG-WARN][18] ([i915#1982] / [i915#2411]) ->
[PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-tgl-dsi/igt@i915_pm_...@module-reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20398/fi-tgl-dsi/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
[i915#299]: https://gitlab.freedesktop.org/drm/intel/issues/299
Participating hosts (43 -> 37)
--
Missing
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/ttm: remove unused function
== Series Details == Series: drm/i915/ttm: remove unused function URL : https://patchwork.freedesktop.org/series/91621/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -O:drivers/gpu/drm/i915/intel_region_ttm.c:181:6: warning: symbol 'intel_region_ttm_node_free' was not declared. Should it be static? + ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ttm: remove unused function
On 6/17/21 10:37 AM, Matthew Auld wrote: intel_region_ttm_node_free is no longer used. Also fixup the related kerneldoc. Reported-by: kernel test robot Signed-off-by: Matthew Auld Cc: Thomas Hellström LGTM. Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: remove unused function
== Series Details ==
Series: drm/i915/ttm: remove unused function
URL : https://patchwork.freedesktop.org/series/91621/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10233 -> Patchwork_20399
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/index.html
Known issues
Here are the changes found in Patchwork_20399 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {fi-tgl-dsi}: [DMESG-WARN][1] ([i915#1982] / [i915#2411]) ->
[PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/fi-tgl-dsi/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/fi-tgl-dsi/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (43 -> 38)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10233 -> Patchwork_20399
CI-20190529: 20190529
CI_DRM_10233: e00d16681acd7e91fd02f800adcc20cca89f6127 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6109: 61ba2ed489540e6a8a649be38abb075b3ab4d28a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20399: 61c7ef8b74704e264cf0278033ae155b28cb95fc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
61c7ef8b7470 drm/i915/ttm: remove unused function
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()
[Public]
Really sorry for the mistake that I made and any inconvenience it brought.
Thanks José and Lyude.
Regards,
Wayne
> From: Lyude Paul
> Sent: Thursday, June 17, 2021 03:47
> To: José Roberto de Souza; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Lin, Wayne
> Subject: Re: [PATCH] drm/dp_mst: Add missing drm parameters to recently added
> call to drm_dbg_kms()
>
> Reviewed-by: Lyude Paul
>
> Will go ahead and push this to drm-misc-next-fixes, thanks
>
> On Wed, 2021-06-16 at 12:44 -0700, José Roberto de Souza wrote:
> > Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > ports in stale topology") added to calls to drm_dbg_kms() but it
> > missed the first parameter, the drm device breaking the build.
> >
> > Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in
> > stale topology")
> > Cc: Wayne Lin
> > Cc: Lyude Paul
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 9ac148efd9e43..ad0795afc21cf 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3389,7 +3389,9 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > mutex_unlock(&mgr->lock);
> >
> > if (skip) {
> > - drm_dbg_kms("Virtual channel %d is not in
> > current topology\n", i);
> > + drm_dbg_kms(mgr->dev,
> > + "Virtual channel %d is not in
> > current topology\n",
> > + i);
> > continue;
> > }
> > /* Validated ports don't matter if we're releasing
> > @@ -3404,7 +3406,8 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > payload->start_slot =
> > req_payload.start_slot;
> > continue;
> > } else {
> > - drm_dbg_kms("Fail:set
> > payload to invalid sink");
> > + drm_dbg_kms(mgr->dev,
> > + "Fail:set
> > payload to invalid sink");
> > mutex_unlock(&mgr-
> > >payload_lock);
> > return -EINVAL;
> > }
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Wed, 16 Jun 2021, Claire Chang wrote:
> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
> ---
> include/linux/swiotlb.h | 11 +++
> kernel/dma/direct.c | 2 +-
> kernel/dma/direct.h | 2 +-
> kernel/dma/swiotlb.c| 4
> 4 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index dd1c30a83058..8d8855c77d9a 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -84,6 +84,7 @@ extern enum swiotlb_force swiotlb_force;
> * unmap calls.
> * @debugfs: The dentry to debugfs.
> * @late_alloc: %true if allocated using the page allocator
> + * @force_bounce: %true if swiotlb bouncing is forced
> */
> struct io_tlb_mem {
> phys_addr_t start;
> @@ -94,6 +95,7 @@ struct io_tlb_mem {
> spinlock_t lock;
> struct dentry *debugfs;
> bool late_alloc;
> + bool force_bounce;
> struct io_tlb_slot {
> phys_addr_t orig_addr;
> size_t alloc_size;
> @@ -109,6 +111,11 @@ static inline bool is_swiotlb_buffer(struct device *dev,
> phys_addr_t paddr)
> return mem && paddr >= mem->start && paddr < mem->end;
> }
>
> +static inline bool is_swiotlb_force_bounce(struct device *dev)
> +{
> + return dev->dma_io_tlb_mem->force_bounce;
> +}
> void __init swiotlb_exit(void);
> unsigned int swiotlb_max_segment(void);
> size_t swiotlb_max_mapping_size(struct device *dev);
> @@ -120,6 +127,10 @@ static inline bool is_swiotlb_buffer(struct device *dev,
> phys_addr_t paddr)
> {
> return false;
> }
> +static inline bool is_swiotlb_force_bounce(struct device *dev)
> +{
> + return false;
> +}
> static inline void swiotlb_exit(void)
> {
> }
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 7a88c34d0867..a92465b4eb12 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -496,7 +496,7 @@ size_t dma_direct_max_mapping_size(struct device *dev)
> {
> /* If SWIOTLB is active, use its maximum mapping size */
> if (is_swiotlb_active(dev) &&
> - (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
> + (dma_addressing_limited(dev) || is_swiotlb_force_bounce(dev)))
> return swiotlb_max_mapping_size(dev);
> return SIZE_MAX;
> }
> diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
> index 13e9e7158d94..4632b0f4f72e 100644
> --- a/kernel/dma/direct.h
> +++ b/kernel/dma/direct.h
> @@ -87,7 +87,7 @@ static inline dma_addr_t dma_direct_map_page(struct device
> *dev,
> phys_addr_t phys = page_to_phys(page) + offset;
> dma_addr_t dma_addr = phys_to_dma(dev, phys);
>
> - if (unlikely(swiotlb_force == SWIOTLB_FORCE))
> + if (is_swiotlb_force_bounce(dev))
> return swiotlb_map(dev, phys, size, dir, attrs);
>
> if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
Should we also make the same change in
drivers/xen/swiotlb-xen.c:xen_swiotlb_map_page ?
If I make that change, I can see that everything is working as
expected for a restricted-dma device with Linux running as dom0 on Xen.
However, is_swiotlb_force_bounce returns non-zero even for normal
non-restricted-dma devices. That shouldn't happen, right?
It looks like struct io_tlb_slot is not zeroed on allocation.
Adding memset(mem, 0x0, struct_size) in swiotlb_late_init_with_tbl
solves the issue.
With those two changes, the series passes my tests and you can add my
tested-by.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 11/12] dt-bindings: of: Add restricted DMA pool
On Wed, 16 Jun 2021, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the reserved-memory node.
>
> Signed-off-by: Claire Chang
> ---
> .../reserved-memory/reserved-memory.txt | 36 +--
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index e8d3096d922c..46804f24df05 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -51,6 +51,23 @@ compatible (optional) - standard definition
>used as a shared pool of DMA buffers for a set of devices. It can
>be used by an operating system to instantiate the necessary pool
>management subsystem if necessary.
> +- restricted-dma-pool: This indicates a region of memory meant to be
> + used as a pool of restricted DMA buffers for a set of devices. The
> + memory region would be the only region accessible to those devices.
> + When using this, the no-map and reusable properties must not be
> set,
> + so the operating system can create a virtual mapping that will be
> used
> + for synchronization. The main purpose for restricted DMA is to
> + mitigate the lack of DMA access control on systems without an
> IOMMU,
> + which could result in the DMA accessing the system memory at
> + unexpected times and/or unexpected addresses, possibly leading to
> data
> + leakage or corruption. The feature on its own provides a basic
> level
> + of protection against the DMA overwriting buffer contents at
> + unexpected times. However, to protect against general data leakage
> and
> + system memory corruption, the system needs to provide way to lock
> down
> + the memory access, e.g., MPU. Note that since coherent allocation
> + needs remapping, one must set up another device coherent pool by
> + shared-dma-pool and use dma_alloc_from_dev_coherent instead for
> atomic
> + coherent allocation.
> - vendor specific string in the form ,[-]
> no-map (optional) - empty property
> - Indicates the operating system must not create a virtual mapping
> @@ -85,10 +102,11 @@ memory-region-names (optional) - a list of names, one
> for each corresponding
>
> Example
> ---
> -This example defines 3 contiguous regions are defined for Linux kernel:
> +This example defines 4 contiguous regions for Linux kernel:
> one default of all device drivers (named linux,cma@7200 and 64MiB in
> size),
> -one dedicated to the framebuffer device (named framebuffer@7800, 8MiB),
> and
> -one for multimedia processing (named multimedia-memory@7700, 64MiB).
> +one dedicated to the framebuffer device (named framebuffer@7800, 8MiB),
> +one for multimedia processing (named multimedia-memory@7700, 64MiB), and
> +one for restricted dma pool (named restricted_dma_reserved@0x5000,
> 64MiB).
>
> / {
> #address-cells = <1>;
> @@ -120,6 +138,11 @@ one for multimedia processing (named
> multimedia-memory@7700, 64MiB).
> compatible = "acme,multimedia-memory";
> reg = <0x7700 0x400>;
> };
> +
> + restricted_dma_reserved: restricted_dma_reserved {
> + compatible = "restricted-dma-pool";
> + reg = <0x5000 0x400>;
> + };
> };
>
> /* ... */
> @@ -138,4 +161,11 @@ one for multimedia processing (named
> multimedia-memory@7700, 64MiB).
> memory-region = <&multimedia_reserved>;
> /* ... */
> };
> +
> + pcie_device: pcie_device@0,0 {
> + reg = <0x8301 0x0 0x 0x0 0x0010
> +0x8301 0x0 0x0010 0x0 0x0010>;
> + memory-region = <&restricted_dma_mem_reserved>;
Shouldn't it be &restricted_dma_reserved ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform execbuffer object locking as a separate step
On 2021-06-15 at 13:36:00 +0200, Thomas Hellström wrote:
> To help avoid evicting already resident buffers from the batch we're
> processing, perform locking as a separate step.
>
Looks reasonable to me.
Reviewed-by: Ramalingam C
> Signed-off-by: Thomas Hellström
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 ---
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 201fed19d120..394eb40c95b5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -922,21 +922,38 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
> return err;
> }
>
> -static int eb_validate_vmas(struct i915_execbuffer *eb)
> +static int eb_lock_vmas(struct i915_execbuffer *eb)
> {
> unsigned int i;
> int err;
>
> - INIT_LIST_HEAD(&eb->unbound);
> -
> for (i = 0; i < eb->buffer_count; i++) {
> - struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> struct eb_vma *ev = &eb->vma[i];
> struct i915_vma *vma = ev->vma;
>
> err = i915_gem_object_lock(vma->obj, &eb->ww);
> if (err)
> return err;
> + }
> +
> + return 0;
> +}
> +
> +static int eb_validate_vmas(struct i915_execbuffer *eb)
> +{
> + unsigned int i;
> + int err;
> +
> + INIT_LIST_HEAD(&eb->unbound);
> +
> + err = eb_lock_vmas(eb);
> + if (err)
> + return err;
> +
> + for (i = 0; i < eb->buffer_count; i++) {
> + struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> + struct eb_vma *ev = &eb->vma[i];
> + struct i915_vma *vma = ev->vma;
>
> err = eb_pin_vma(eb, entry, ev);
> if (err == -EDEADLK)
> --
> 2.31.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform execbuffer object locking as a separate step
On 6/17/21 11:56 AM, Ramalingam C wrote: On 2021-06-15 at 13:36:00 +0200, Thomas Hellström wrote: To help avoid evicting already resident buffers from the batch we're processing, perform locking as a separate step. Looks reasonable to me. Reviewed-by: Ramalingam C Thanks for reviewing! /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add relocation exceptions for two other platforms
On Thu, Jun 17, 2021 at 07:44:18AM +0200, Zbigniew Kempczyński wrote:
> For topic/intel-for-CI branch only.
pushed to topic/core-for-CI.
Thanks for the patch.
>
> We have established previously we stop using relocations starting
> from gen12 platforms with Tigerlake as an exception. We keep this
> statement but we want to enable relocations conditionally for
> Alderlake S+P under require_force_probe flag set.
>
> Keeping relocations under require_force_probe flag is interim solution
> until IGTs will be rewritten to use softpin.
>
> v2: - remove inline from function definition (Jani)
> - fix indentation
>
> v3: change to GRAPHICS_VER() (Zbigniew)
>
> v4: remove RKL from flag as it is already shipped (Rodrigo)
>
> v5: prepare patch to be used within topic/intel-for-CI branch only
>
> v6: change comment (Rodrigo)
>
> Signed-off-by: Zbigniew Kempczyński
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Cc: Rodrigo Vivi
> Acked-by: Dave Airlie
> Acked-by: Rodrigo Vivi
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 ++-
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 760c8aefea3a..8f15fa88cac6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -491,16 +491,27 @@ eb_unreserve_vma(struct eb_vma *ev)
> ev->flags &= ~__EXEC_OBJECT_RESERVED;
> }
>
> +static bool platform_has_relocs_enabled(const struct i915_execbuffer *eb)
> +{
> + /*
> + * Relocations are disallowed starting from gen12 with Tigerlake
> + * as an exception. To unblock CI, we are temporarily allowing it
> + * for Rocketlake and Alderlake.
> + */
> + if (GRAPHICS_VER(eb->i915) < 12 || IS_TIGERLAKE(eb->i915) ||
> + IS_ROCKETLAKE(eb->i915) || IS_ALDERLAKE_S(eb->i915) ||
> + IS_ALDERLAKE_P(eb->i915))
> + return true;
> +
> + return false;
> +}
> +
> static int
> eb_validate_vma(struct i915_execbuffer *eb,
> struct drm_i915_gem_exec_object2 *entry,
> struct i915_vma *vma)
> {
> - /* Relocations are disallowed for all platforms after TGL-LP. This
> - * also covers all platforms with local memory.
> - */
> - if (entry->relocation_count &&
> - GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> + if (entry->relocation_count && !platform_has_relocs_enabled(eb))
> return -EINVAL;
>
> if (unlikely(entry->flags & eb->invalid_flags))
> --
> 2.26.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform execbuffer object locking as a separate step
Op 15-06-2021 om 13:36 schreef Thomas Hellström:
> To help avoid evicting already resident buffers from the batch we're
> processing, perform locking as a separate step.
>
> Signed-off-by: Thomas Hellström
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 ---
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 201fed19d120..394eb40c95b5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -922,21 +922,38 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
> return err;
> }
>
> -static int eb_validate_vmas(struct i915_execbuffer *eb)
> +static int eb_lock_vmas(struct i915_execbuffer *eb)
> {
> unsigned int i;
> int err;
>
> - INIT_LIST_HEAD(&eb->unbound);
> -
> for (i = 0; i < eb->buffer_count; i++) {
> - struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> struct eb_vma *ev = &eb->vma[i];
> struct i915_vma *vma = ev->vma;
>
> err = i915_gem_object_lock(vma->obj, &eb->ww);
> if (err)
> return err;
> + }
> +
> + return 0;
> +}
> +
> +static int eb_validate_vmas(struct i915_execbuffer *eb)
> +{
> + unsigned int i;
> + int err;
> +
> + INIT_LIST_HEAD(&eb->unbound);
> +
> + err = eb_lock_vmas(eb);
> + if (err)
> + return err;
> +
> + for (i = 0; i < eb->buffer_count; i++) {
> + struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> + struct eb_vma *ev = &eb->vma[i];
> + struct i915_vma *vma = ev->vma;
>
> err = eb_pin_vma(eb, entry, ev);
> if (err == -EDEADLK)
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: remove unused function
== Series Details == Series: drm/i915/ttm: remove unused function URL : https://patchwork.freedesktop.org/series/91621/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10233_full -> Patchwork_20399_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20399_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20399_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_20399_full: ### IGT changes ### Possible regressions * igt@gem_ctx_create@basic-files: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-iclb5/igt@gem_ctx_cre...@basic-files.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-iclb2/igt@gem_ctx_cre...@basic-files.html Known issues Here are the changes found in Patchwork_20399_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_mm@all@insert_range: - shard-skl: NOTRUN -> [INCOMPLETE][3] ([i915#2485]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-skl4/igt@drm_mm@all@insert_range.html * igt@gem_create@create-clear: - shard-glk: NOTRUN -> [FAIL][4] ([i915#1888] / [i915#3160]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-glk5/igt@gem_cre...@create-clear.html * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][5] ([i915#3002]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-snb5/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_shared@detached-shared-gtt: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk3/igt@gem_ctx_sha...@detached-shared-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-glk1/igt@gem_ctx_sha...@detached-shared-gtt.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][9] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-kbl6/igt@gem_exec_f...@basic-deadline.html - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk3/igt@gem_exec_f...@basic-deadline.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-glk1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-glk1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-iclb8/igt@gem_exec_fair@basic-p...@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][16] ([i915#2389]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-apl3/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][17] ([i915#2389]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_mmap_gtt@big-copy-xy: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#307]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10233/shard-glk3/igt@gem_mmap_...@big-copy-xy.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-glk3/igt@gem_mmap_...@big-copy-xy.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-kbl6/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20399/shard-apl
[Intel-gfx] Allow mdev drivers to directly create the vfio_device (v4)
This is my alternative take on this series from Jason: https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/ The mdev/vfio parts are exactly the same, but this solves the driver core changes for the direct probing without the in/out flag that Greg hated, which cause a little more work, but probably make the result better. Original decription from Jason below: The mdev bus's core part for managing the lifecycle of devices is mostly as one would expect for a driver core bus subsystem. However instead of having a normal 'struct device_driver' and binding the actual mdev drivers through the standard driver core mechanisms it open codes this with the struct mdev_parent_ops and provides a single driver that shims between the VFIO core's struct vfio_device and the actual device driver. Instead, allow mdev drivers implement an actual struct mdev_driver and directly call vfio_register_group_dev() in the probe() function for the mdev. Arrange to bind the created mdev_device to the mdev_driver that is provided by the end driver. The actual execution flow doesn't change much, eg what was parent_ops->create is now device_driver->probe and it is called at almost the exact same time - except under the normal control of the driver core. Ultimately converting all the drivers unlocks a fair number of additional VFIO simplifications and cleanups. Changes since v3: - minor cleanup to avoid the probe_ret variable in really_probe entirely - use a saner name for a variable in mdev-mtty - use a better driver name in mdev-mtty - update the documentation to match the new interface Changes since v2: - avoid warning spam for successful probes - improve the probe_count protection ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] driver core: Pull required checks into driver_probe_device()
From: Jason Gunthorpe
Checking if the dev is dead or if the dev is already bound is a required
precondition to invoking driver_probe_device(). All the call chains
leading here duplicate these checks.
Add it directly to driver_probe_device() so the precondition is clear and
remove the checks from device_driver_attach() and
__driver_attach_async_helper().
The other call chain going through __device_attach_driver() does have
these same checks but they are inlined into logic higher up the call stack
and can't be removed.
The sysfs uAPI call chain starting at bind_store() is a bit confused
because it reads dev->driver unlocked and returns -ENODEV if it is !NULL,
otherwise it reads it again under lock and returns 0 if it is !NULL. Fix
this to always return -EBUSY and always read dev->driver under its lock.
Done in preparation for the next patches which will add additional
callers to driver_probe_device() and will need these checks as well.
Signed-off-by: Jason Gunthorpe
[hch: drop the extra checks in device_driver_attach and bind_store]
Signed-off-by: Christoph Hellwig
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Cornelia Huck
---
drivers/base/bus.c | 2 +-
drivers/base/dd.c | 32 ++--
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 36d0c654ea61..7de13302e8c8 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -210,7 +210,7 @@ static ssize_t bind_store(struct device_driver *drv, const
char *buf,
int err = -ENODEV;
dev = bus_find_device_by_name(bus, NULL, buf);
- if (dev && dev->driver == NULL && driver_match_device(drv, dev)) {
+ if (dev && driver_match_device(drv, dev)) {
err = device_driver_attach(drv, dev);
if (err > 0) {
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index ecd7cf848daf..7477d3322b3a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -733,8 +733,9 @@ EXPORT_SYMBOL_GPL(wait_for_device_probe);
* @drv: driver to bind a device to
* @dev: device to try to bind to the driver
*
- * This function returns -ENODEV if the device is not registered,
- * 1 if the device is bound successfully and 0 otherwise.
+ * This function returns -ENODEV if the device is not registered, -EBUSY if it
+ * already has a driver, and 1 if the device is bound successfully and 0
+ * otherwise.
*
* This function must be called with @dev lock held. When called for a
* USB interface, @dev->parent lock must be held as well.
@@ -745,8 +746,10 @@ static int driver_probe_device(struct device_driver *drv,
struct device *dev)
{
int ret = 0;
- if (!device_is_registered(dev))
+ if (dev->p->dead || !device_is_registered(dev))
return -ENODEV;
+ if (dev->driver)
+ return -EBUSY;
dev->can_match = true;
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
@@ -1027,17 +1030,10 @@ static void __device_driver_unlock(struct device *dev,
struct device *parent)
*/
int device_driver_attach(struct device_driver *drv, struct device *dev)
{
- int ret = 0;
+ int ret;
__device_driver_lock(dev, dev->parent);
-
- /*
-* If device has been removed or someone has already successfully
-* bound a driver before us just skip the driver probe call.
-*/
- if (!dev->p->dead && !dev->driver)
- ret = driver_probe_device(drv, dev);
-
+ ret = driver_probe_device(drv, dev);
__device_driver_unlock(dev, dev->parent);
return ret;
@@ -1047,19 +1043,11 @@ static void __driver_attach_async_helper(void *_dev,
async_cookie_t cookie)
{
struct device *dev = _dev;
struct device_driver *drv;
- int ret = 0;
+ int ret;
__device_driver_lock(dev, dev->parent);
-
drv = dev->p->async_driver;
-
- /*
-* If device has been removed or someone has already successfully
-* bound a driver before us just skip the driver probe call.
-*/
- if (!dev->p->dead && !dev->driver)
- ret = driver_probe_device(drv, dev);
-
+ ret = driver_probe_device(drv, dev);
__device_driver_unlock(dev, dev->parent);
dev_dbg(dev, "driver %s async attach completed: %d\n", drv->name, ret);
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] driver core: Better distinguish probe errors in really_probe
really_probe tries to special case errors from ->probe, but due to all
other initialization added to the function over time now a lot of
internal errors hit that code path as well. Untangle that by adding
a new probe_err local variable and apply the special casing only to
that.
Signed-off-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kirti Wankhede
---
drivers/base/dd.c | 72 +++
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 7477d3322b3a..fd83817240e6 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -513,12 +513,44 @@ static ssize_t state_synced_show(struct device *dev,
}
static DEVICE_ATTR_RO(state_synced);
+
+static int call_driver_probe(struct device *dev, struct device_driver *drv)
+{
+ int ret = 0;
+
+ if (dev->bus->probe)
+ ret = dev->bus->probe(dev);
+ else if (drv->probe)
+ ret = drv->probe(dev);
+
+ switch (ret) {
+ case 0:
+ break;
+ case -EPROBE_DEFER:
+ /* Driver requested deferred probing */
+ dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+ break;
+ case -ENODEV:
+ case -ENXIO:
+ pr_debug("%s: probe of %s rejects match %d\n",
+drv->name, dev_name(dev), ret);
+ break;
+ default:
+ /* driver matched but the probe failed */
+ pr_warn("%s: probe of %s failed with error %d\n",
+ drv->name, dev_name(dev), ret);
+ break;
+ }
+
+ return ret;
+}
+
static int really_probe(struct device *dev, struct device_driver *drv)
{
- int ret = -EPROBE_DEFER;
int local_trigger_count = atomic_read(&deferred_trigger_count);
bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) &&
!drv->suppress_bind_attrs;
+ int ret = -EPROBE_DEFER, probe_ret = 0;
if (defer_all_probes) {
/*
@@ -572,14 +604,14 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto probe_failed;
}
- if (dev->bus->probe) {
- ret = dev->bus->probe(dev);
- if (ret)
- goto probe_failed;
- } else if (drv->probe) {
- ret = drv->probe(dev);
- if (ret)
- goto probe_failed;
+ probe_ret = call_driver_probe(dev, drv);
+ if (probe_ret) {
+ /*
+* Ignore errors returned by ->probe so that the next driver can
+* try its luck.
+*/
+ ret = 0;
+ goto probe_failed;
}
if (device_add_groups(dev, drv->dev_groups)) {
@@ -650,28 +682,8 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
dev->pm_domain->dismiss(dev);
pm_runtime_reinit(dev);
dev_pm_set_driver_flags(dev, 0);
-
- switch (ret) {
- case -EPROBE_DEFER:
- /* Driver requested deferred probing */
- dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+ if (probe_ret == -EPROBE_DEFER)
driver_deferred_probe_add_trigger(dev, local_trigger_count);
- break;
- case -ENODEV:
- case -ENXIO:
- pr_debug("%s: probe of %s rejects match %d\n",
-drv->name, dev_name(dev), ret);
- break;
- default:
- /* driver matched but the probe failed */
- pr_warn("%s: probe of %s failed with error %d\n",
- drv->name, dev_name(dev), ret);
- }
- /*
-* Ignore errors returned by ->probe so that the next driver can try
-* its luck.
-*/
- ret = 0;
done:
atomic_dec(&probe_count);
wake_up_all(&probe_waitqueue);
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind
Currently really_probe() returns 1 on success and 0 if the probe() call
fails. This return code arrangement is designed to be useful for
__device_attach_driver() which is walking the device list and trying every
driver. 0 means to keep trying.
However, it is not useful for the other places that call through to
really_probe() that do actually want to see the probe() return code.
For instance bind_store() would be better to return the actual error code
from the driver's probe method, not discarding it and returning -ENODEV.
Reorganize things so that really_probe() returns the error code from
->probe as a (inverted) positive number, and 0 for successful attach.
With this, __device_attach_driver can ignore the (positive) probe errors,
return 1 to exit the loop for a successful binding and pass on the
other negative errors, while device_driver_attach simplify inverts the
positive errors and returns all errors to the sysfs code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Cornelia Huck
---
drivers/base/bus.c | 6 +-
drivers/base/dd.c | 29 -
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 7de13302e8c8..1f6b4bd61056 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -212,13 +212,9 @@ static ssize_t bind_store(struct device_driver *drv, const
char *buf,
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && driver_match_device(drv, dev)) {
err = device_driver_attach(drv, dev);
-
- if (err > 0) {
+ if (!err) {
/* success */
err = count;
- } else if (err == 0) {
- /* driver didn't accept device */
- err = -ENODEV;
}
}
put_device(dev);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index fd83817240e6..25341f52198c 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -607,10 +607,10 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
probe_ret = call_driver_probe(dev, drv);
if (probe_ret) {
/*
-* Ignore errors returned by ->probe so that the next driver can
-* try its luck.
+* Return probe errors as positive values so that the callers
+* can distinguish them from other errors.
*/
- ret = 0;
+ ret = -probe_ret;
goto probe_failed;
}
@@ -653,7 +653,6 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
dev->pm_domain->sync(dev);
driver_bound(dev);
- ret = 1;
pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
drv->bus->name, __func__, dev_name(dev), drv->name);
goto done;
@@ -746,8 +745,8 @@ EXPORT_SYMBOL_GPL(wait_for_device_probe);
* @dev: device to try to bind to the driver
*
* This function returns -ENODEV if the device is not registered, -EBUSY if it
- * already has a driver, and 1 if the device is bound successfully and 0
- * otherwise.
+ * already has a driver, 0 if the device is bound successfully and a positive
+ * (inverted) error code for failures from the ->probe method.
*
* This function must be called with @dev lock held. When called for a
* USB interface, @dev->parent lock must be held as well.
@@ -882,7 +881,14 @@ static int __device_attach_driver(struct device_driver
*drv, void *_data)
if (data->check_async && async_allowed != data->want_async)
return 0;
- return driver_probe_device(drv, dev);
+ /*
+* Ignore errors returned by ->probe so that the next driver can try
+* its luck.
+*/
+ ret = driver_probe_device(drv, dev);
+ if (ret < 0)
+ return ret;
+ return ret == 0;
}
static void __device_attach_async_helper(void *_dev, async_cookie_t cookie)
@@ -1038,7 +1044,7 @@ static void __device_driver_unlock(struct device *dev,
struct device *parent)
* @dev: Device to attach it to
*
* Manually attach driver to a device. Will acquire both @dev lock and
- * @dev->parent lock if needed.
+ * @dev->parent lock if needed. Returns 0 on success, -ERR on failure.
*/
int device_driver_attach(struct device_driver *drv, struct device *dev)
{
@@ -1048,6 +1054,9 @@ int device_driver_attach(struct device_driver *drv,
struct device *dev)
ret = driver_probe_device(drv, dev);
__device_driver_unlock(dev, dev->parent);
+ /* also return probe errors as normal negative errnos */
+ if (ret > 0)
+ ret = -ret;
return ret;
}
@@ -1114,7 +1123,9 @@ static int __driver_attach(struct device *dev, void *data)
return 0;
}
- device_driver_attach(drv, dev);
+ __device_driver_lock(dev, dev->parent);
+
[Intel-gfx] [PATCH 04/10] driver core: Don't return EPROBE_DEFER to userspace during sysfs bind
EPROBE_DEFER is an internal kernel error code and it should not be leaked
to userspace via the bind_store() sysfs. Userspace doesn't have this
constant and cannot understand it.
Further, it doesn't really make sense to have userspace trigger a deferred
probe via bind_store(), which could eventually succeed, while
simultaneously returning an error back.
Resolve this by splitting driver_probe_device so that the version used
by the sysfs binding that turns EPROBE_DEFER into -EAGAIN, while the one
used for internally binding keeps the error code, and calls
driver_deferred_probe_add where needed. This also allows to nicely split
out the defer_all_probes / probe_count checks so that they actually allow
for full device_{block,unblock}_probing protection while not bothering
the sysfs bind case.
Signed-off-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Greg Kroah-Hartman
---
drivers/base/dd.c | 84 +--
1 file changed, 45 insertions(+), 39 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 25341f52198c..1d8012459587 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -491,15 +491,6 @@ EXPORT_SYMBOL_GPL(device_bind_driver);
static atomic_t probe_count = ATOMIC_INIT(0);
static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
-static void driver_deferred_probe_add_trigger(struct device *dev,
- int local_trigger_count)
-{
- driver_deferred_probe_add(dev);
- /* Did a trigger occur while probing? Need to re-trigger if yes */
- if (local_trigger_count != atomic_read(&deferred_trigger_count))
- driver_deferred_probe_trigger();
-}
-
static ssize_t state_synced_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -547,10 +538,9 @@ static int call_driver_probe(struct device *dev, struct
device_driver *drv)
static int really_probe(struct device *dev, struct device_driver *drv)
{
- int local_trigger_count = atomic_read(&deferred_trigger_count);
bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) &&
!drv->suppress_bind_attrs;
- int ret = -EPROBE_DEFER, probe_ret = 0;
+ int ret;
if (defer_all_probes) {
/*
@@ -559,17 +549,13 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
* wait_for_device_probe() right after that to avoid any races.
*/
dev_dbg(dev, "Driver %s force probe deferral\n", drv->name);
- driver_deferred_probe_add(dev);
- return ret;
+ return -EPROBE_DEFER;
}
ret = device_links_check_suppliers(dev);
- if (ret == -EPROBE_DEFER)
- driver_deferred_probe_add_trigger(dev, local_trigger_count);
if (ret)
return ret;
- atomic_inc(&probe_count);
pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
drv->bus->name, __func__, drv->name, dev_name(dev));
if (!list_empty(&dev->devres_head)) {
@@ -604,13 +590,13 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto probe_failed;
}
- probe_ret = call_driver_probe(dev, drv);
- if (probe_ret) {
+ ret = call_driver_probe(dev, drv);
+ if (ret) {
/*
* Return probe errors as positive values so that the callers
* can distinguish them from other errors.
*/
- ret = -probe_ret;
+ ret = -ret;
goto probe_failed;
}
@@ -681,11 +667,7 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
dev->pm_domain->dismiss(dev);
pm_runtime_reinit(dev);
dev_pm_set_driver_flags(dev, 0);
- if (probe_ret == -EPROBE_DEFER)
- driver_deferred_probe_add_trigger(dev, local_trigger_count);
done:
- atomic_dec(&probe_count);
- wake_up_all(&probe_waitqueue);
return ret;
}
@@ -739,21 +721,7 @@ void wait_for_device_probe(void)
}
EXPORT_SYMBOL_GPL(wait_for_device_probe);
-/**
- * driver_probe_device - attempt to bind device & driver together
- * @drv: driver to bind a device to
- * @dev: device to try to bind to the driver
- *
- * This function returns -ENODEV if the device is not registered, -EBUSY if it
- * already has a driver, 0 if the device is bound successfully and a positive
- * (inverted) error code for failures from the ->probe method.
- *
- * This function must be called with @dev lock held. When called for a
- * USB interface, @dev->parent lock must be held as well.
- *
- * If the device has a parent, runtime-resume the parent before driver probing.
- */
-static int driver_probe_device(struct device_driver *drv, struct device *dev)
+static int __driver_probe_device(struct device_dri
[Intel-gfx] [PATCH 05/10] driver core: Export device_driver_attach()
From: Jason Gunthorpe
This is intended as a replacement API for device_bind_driver(). It has at
least the following benefits:
- Internal locking. Few of the users of device_bind_driver() follow the
locking rules
- Calls device driver probe() internally. Notably this means that devm
support for probe works correctly as probe() error will call
devres_release_all()
- struct device_driver -> dev_groups is supported
- Simplified calling convention, no need to manually call probe().
The general usage is for situations that already know what driver to bind
and need to ensure the bind is synchronized with other logic. Call
device_driver_attach() after device_add().
If probe() returns a failure then this will be preserved up through to the
error return of device_driver_attach().
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Greg Kroah-Hartman
---
drivers/base/base.h| 1 -
drivers/base/dd.c | 3 +++
include/linux/device.h | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index e5f9b7e656c3..404db83ee5ec 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -152,7 +152,6 @@ extern int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups);
extern void driver_remove_groups(struct device_driver *drv,
const struct attribute_group **groups);
-int device_driver_attach(struct device_driver *drv, struct device *dev);
void device_driver_detach(struct device *dev);
extern char *make_class_name(const char *name, struct kobject *kobj);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 1d8012459587..daeb9b5763ae 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -471,6 +471,8 @@ static void driver_sysfs_remove(struct device *dev)
* (It is ok to call with no other effort from a driver's probe() method.)
*
* This function must be called with the device lock held.
+ *
+ * Callers should prefer to use device_driver_attach() instead.
*/
int device_bind_driver(struct device *dev)
{
@@ -1065,6 +1067,7 @@ int device_driver_attach(struct device_driver *drv,
struct device *dev)
return -EAGAIN;
return ret;
}
+EXPORT_SYMBOL_GPL(device_driver_attach);
static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
{
diff --git a/include/linux/device.h b/include/linux/device.h
index f1a00040fa53..d8b9c9e7d493 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -845,6 +845,8 @@ static inline void *dev_get_platdata(const struct device
*dev)
* Manual binding of a device to driver. See drivers/base/bus.c
* for information on use.
*/
+int __must_check device_driver_attach(struct device_driver *drv,
+ struct device *dev);
int __must_check device_bind_driver(struct device *dev);
void device_release_driver(struct device *dev);
int __must_check device_attach(struct device *dev);
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE
From: Jason Gunthorpe
For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.
A later patch deletes this driver entirely.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kirti Wankhede
---
Documentation/s390/vfio-ap.rst | 1 -
arch/s390/Kconfig| 2 +-
drivers/gpu/drm/i915/Kconfig | 2 +-
drivers/vfio/mdev/Kconfig| 7 ---
drivers/vfio/mdev/Makefile | 3 +--
drivers/vfio/mdev/mdev_core.c| 16 ++--
drivers/vfio/mdev/mdev_private.h | 2 ++
drivers/vfio/mdev/vfio_mdev.c| 24 +---
samples/Kconfig | 6 +++---
9 files changed, 23 insertions(+), 40 deletions(-)
diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst
index e15436599086..f57ae621f33e 100644
--- a/Documentation/s390/vfio-ap.rst
+++ b/Documentation/s390/vfio-ap.rst
@@ -514,7 +514,6 @@ These are the steps:
* S390_AP_IOMMU
* VFIO
* VFIO_MDEV
- * VFIO_MDEV_DEVICE
* KVM
If using make menuconfig select the following to build the vfio_ap module::
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index b4c7c34069f8..ea63fd22e119 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -768,7 +768,7 @@ config VFIO_CCW
config VFIO_AP
def_tristate n
prompt "VFIO support for AP devices"
- depends on S390_AP_IOMMU && VFIO_MDEV_DEVICE && KVM
+ depends on S390_AP_IOMMU && VFIO_MDEV && KVM
depends on ZCRYPT
help
This driver grants access to Adjunct Processor (AP) devices
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca7..53bc68631861 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -124,7 +124,7 @@ config DRM_I915_GVT_KVMGT
tristate "Enable KVM/VFIO support for Intel GVT-g"
depends on DRM_I915_GVT
depends on KVM
- depends on VFIO_MDEV && VFIO_MDEV_DEVICE
+ depends on VFIO_MDEV
default n
help
Choose this option if you want to enable KVMGT support for
diff --git a/drivers/vfio/mdev/Kconfig b/drivers/vfio/mdev/Kconfig
index 5da27f2100f9..763c877a1318 100644
--- a/drivers/vfio/mdev/Kconfig
+++ b/drivers/vfio/mdev/Kconfig
@@ -9,10 +9,3 @@ config VFIO_MDEV
See Documentation/driver-api/vfio-mediated-device.rst for more
details.
If you don't know what do here, say N.
-
-config VFIO_MDEV_DEVICE
- tristate "VFIO driver for Mediated devices"
- depends on VFIO && VFIO_MDEV
- default n
- help
- VFIO based driver for Mediated devices.
diff --git a/drivers/vfio/mdev/Makefile b/drivers/vfio/mdev/Makefile
index 101516fdf375..ff9ecd802125 100644
--- a/drivers/vfio/mdev/Makefile
+++ b/drivers/vfio/mdev/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
+mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o vfio_mdev.o
obj-$(CONFIG_VFIO_MDEV) += mdev.o
-obj-$(CONFIG_VFIO_MDEV_DEVICE) += vfio_mdev.o
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 2a85d6fcb7dd..ff8c1a845166 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -360,11 +360,24 @@ int mdev_device_remove(struct mdev_device *mdev)
static int __init mdev_init(void)
{
- return mdev_bus_register();
+ int rc;
+
+ rc = mdev_bus_register();
+ if (rc)
+ return rc;
+ rc = mdev_register_driver(&vfio_mdev_driver);
+ if (rc)
+ goto err_bus;
+ return 0;
+err_bus:
+ mdev_bus_unregister();
+ return rc;
}
static void __exit mdev_exit(void)
{
+ mdev_unregister_driver(&vfio_mdev_driver);
+
if (mdev_bus_compat_class)
class_compat_unregister(mdev_bus_compat_class);
@@ -378,4 +391,3 @@ MODULE_VERSION(DRIVER_VERSION);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
-MODULE_SOFTDEP("post: vfio_mdev");
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/vfio/mdev/mdev_private.h
index 6999c89db7b1..afbad7b0a14a 100644
--- a/drivers/vfio/mdev/mdev_private.h
+++ b/drivers/vfio/mdev/mdev_private.h
@@ -37,6 +37,8 @@ struct mdev_type {
#define to_mdev_type(_kobj)\
container_of(_kobj, struct mdev_type, kobj)
+extern struct mdev_driver vfio_mdev_driver;
+
int parent_create_sysfs_files(struct mdev_parent *parent);
void parent_remove_sysfs_files(struct mdev_parent *parent);
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 922729071c5a..d5b4eede47c1 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -17,10 +17,6 @@
#include "mdev_private.h"
-#define
[Intel-gfx] [PATCH 07/10] vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind
From: Jason Gunthorpe
This allows a mdev driver to opt out of using vfio_mdev.c, instead the
driver will provide a 'struct mdev_driver' and register directly with the
driver core.
Much of mdev_parent_ops becomes unused in this mode:
- create()/remove() are done via the mdev_driver probe()/remove()
- mdev_attr_groups becomes mdev_driver driver.dev_groups
- Wrapper function callbacks are replaced with the same ones from
struct vfio_device_ops
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kirti Wankhede
---
.../driver-api/vfio-mediated-device.rst | 35 +++
drivers/vfio/mdev/mdev_core.c | 30 +++-
drivers/vfio/mdev/mdev_driver.c | 10 ++
include/linux/mdev.h | 2 ++
4 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 1779b85f014e..9f26079cacae 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -93,7 +93,7 @@ interfaces:
Registration Interface for a Mediated Bus Driver
-The registration interface for a mediated bus driver provides the following
+The registration interface for a mediated device driver provides the following
structure to represent a mediated device's driver::
/*
@@ -136,37 +136,26 @@ The structures in the mdev_parent_ops structure are as
follows:
* dev_attr_groups: attributes of the parent device
* mdev_attr_groups: attributes of the mediated device
* supported_config: attributes to define supported configurations
+* device_driver: device driver to bind for mediated device instances
-The functions in the mdev_parent_ops structure are as follows:
+The mdev_parent_ops also still has various functions pointers. Theses exist
+for historical reasons only and shall not be used for new drivers.
-* create: allocate basic resources in a driver for a mediated device
-* remove: free resources in a driver when a mediated device is destroyed
-
-(Note that mdev-core provides no implicit serialization of create/remove
-callbacks per mdev parent device, per mdev type, or any other categorization.
-Vendor drivers are expected to be fully asynchronous in this respect or
-provide their own internal resource protection.)
-
-The callbacks in the mdev_parent_ops structure are as follows:
-
-* open: open callback of mediated device
-* close: close callback of mediated device
-* ioctl: ioctl callback of mediated device
-* read : read emulation callback
-* write: write emulation callback
-* mmap: mmap emulation callback
-
-A driver should use the mdev_parent_ops structure in the function call to
-register itself with the mdev core driver::
+When a driver wants to add the GUID creation sysfs to an existing device it has
+probe'd to then it should call::
extern int mdev_register_device(struct device *dev,
const struct mdev_parent_ops *ops);
-However, the mdev_parent_ops structure is not required in the function call
-that a driver should use to unregister itself with the mdev core driver::
+This will provide the 'mdev_supported_types/XX/create' files which can then be
+used to trigger the creation of a mdev_device. The created mdev_device will be
+attached to the specified driver.
+
+When the driver needs to remove itself it calls::
extern void mdev_unregister_device(struct device *dev);
+Which will unbind and destroy all the created mdevs and remove the sysfs files.
Mediated Device Management Interface Through sysfs
==
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index ff8c1a845166..e4581ec093a6 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -94,9 +94,11 @@ static void mdev_device_remove_common(struct mdev_device
*mdev)
mdev_remove_sysfs_files(mdev);
device_del(&mdev->dev);
lockdep_assert_held(&parent->unreg_sem);
- ret = parent->ops->remove(mdev);
- if (ret)
- dev_err(&mdev->dev, "Remove failed: err=%d\n", ret);
+ if (parent->ops->remove) {
+ ret = parent->ops->remove(mdev);
+ if (ret)
+ dev_err(&mdev->dev, "Remove failed: err=%d\n", ret);
+ }
/* Balances with device_initialize() */
put_device(&mdev->dev);
@@ -127,7 +129,9 @@ int mdev_register_device(struct device *dev, const struct
mdev_parent_ops *ops)
char *envp[] = { env_string, NULL };
/* check for mandatory ops */
- if (!ops || !ops->create || !ops->remove || !ops->supported_type_groups)
+ if (!ops || !ops->supported_type_groups)
+ return -EINVAL;
+ if (!o
[Intel-gfx] [PATCH 08/10] vfio/mtty: Convert to use vfio_register_group_dev()
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of()
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kirti Wankhede
---
samples/vfio-mdev/mtty.c | 185 ++-
1 file changed, 83 insertions(+), 102 deletions(-)
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index b9b24be4abda..faf9b8e8873a 100644
--- a/samples/vfio-mdev/mtty.c
+++ b/samples/vfio-mdev/mtty.c
@@ -127,6 +127,7 @@ struct serial_port {
/* State of each mdev device */
struct mdev_state {
+ struct vfio_device vdev;
int irq_fd;
struct eventfd_ctx *intx_evtfd;
struct eventfd_ctx *msi_evtfd;
@@ -150,6 +151,8 @@ static const struct file_operations vd_fops = {
.owner = THIS_MODULE,
};
+static const struct vfio_device_ops mtty_dev_ops;
+
/* function prototypes */
static int mtty_trigger_interrupt(struct mdev_state *mdev_state);
@@ -631,22 +634,15 @@ static void mdev_read_base(struct mdev_state *mdev_state)
}
}
-static ssize_t mdev_access(struct mdev_device *mdev, u8 *buf, size_t count,
+static ssize_t mdev_access(struct mdev_state *mdev_state, u8 *buf, size_t
count,
loff_t pos, bool is_write)
{
- struct mdev_state *mdev_state;
unsigned int index;
loff_t offset;
int ret = 0;
- if (!mdev || !buf)
- return -EINVAL;
-
- mdev_state = mdev_get_drvdata(mdev);
- if (!mdev_state) {
- pr_err("%s mdev_state not found\n", __func__);
+ if (!buf)
return -EINVAL;
- }
mutex_lock(&mdev_state->ops_lock);
@@ -708,15 +704,18 @@ static ssize_t mdev_access(struct mdev_device *mdev, u8
*buf, size_t count,
return ret;
}
-static int mtty_create(struct mdev_device *mdev)
+static int mtty_probe(struct mdev_device *mdev)
{
struct mdev_state *mdev_state;
int nr_ports = mdev_get_type_group_id(mdev) + 1;
+ int ret;
mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
if (mdev_state == NULL)
return -ENOMEM;
+ vfio_init_group_dev(&mdev_state->vdev, &mdev->dev, &mtty_dev_ops);
+
mdev_state->nr_ports = nr_ports;
mdev_state->irq_index = -1;
mdev_state->s[0].max_fifo_size = MAX_FIFO_SIZE;
@@ -731,7 +730,6 @@ static int mtty_create(struct mdev_device *mdev)
mutex_init(&mdev_state->ops_lock);
mdev_state->mdev = mdev;
- mdev_set_drvdata(mdev, mdev_state);
mtty_create_config_space(mdev_state);
@@ -739,50 +737,40 @@ static int mtty_create(struct mdev_device *mdev)
list_add(&mdev_state->next, &mdev_devices_list);
mutex_unlock(&mdev_list_lock);
+ ret = vfio_register_group_dev(&mdev_state->vdev);
+ if (ret) {
+ kfree(mdev_state);
+ return ret;
+ }
+ dev_set_drvdata(&mdev->dev, mdev_state);
return 0;
}
-static int mtty_remove(struct mdev_device *mdev)
+static void mtty_remove(struct mdev_device *mdev)
{
- struct mdev_state *mds, *tmp_mds;
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
- int ret = -EINVAL;
+ struct mdev_state *mdev_state = dev_get_drvdata(&mdev->dev);
+ vfio_unregister_group_dev(&mdev_state->vdev);
mutex_lock(&mdev_list_lock);
- list_for_each_entry_safe(mds, tmp_mds, &mdev_devices_list, next) {
- if (mdev_state == mds) {
- list_del(&mdev_state->next);
- mdev_set_drvdata(mdev, NULL);
- kfree(mdev_state->vconfig);
- kfree(mdev_state);
- ret = 0;
- break;
- }
- }
+ list_del(&mdev_state->next);
mutex_unlock(&mdev_list_lock);
- return ret;
+ kfree(mdev_state->vconfig);
+ kfree(mdev_state);
}
-static int mtty_reset(struct mdev_device *mdev)
+static int mtty_reset(struct mdev_state *mdev_state)
{
- struct mdev_state *mdev_state;
-
- if (!mdev)
- return -EINVAL;
-
- mdev_state = mdev_get_drvdata(mdev);
- if (!mdev_state)
- return -EINVAL;
-
pr_info("%s: called\n", __func__);
return 0;
}
-static ssize_t mtty_read(struct mdev_device *mdev, char __user *buf,
+static ssize_t mtty_read(struct vfio_device *vdev, char __user *buf,
size_t count, loff_t *ppos)
{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
unsigned int done = 0;
int ret;
@@ -792,7 +780,7 @@ static ssize_t mtty_read(struct mdev_device *mdev, char
__user *buf,
[Intel-gfx] [PATCH 09/10] vfio/mdpy: Convert to use vfio_register_group_dev()
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Greg Kroah-Hartman
---
samples/vfio-mdev/mdpy.c | 159 ++-
1 file changed, 88 insertions(+), 71 deletions(-)
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index e889c1cf8fd1..7e9c9df0f05b 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -85,9 +85,11 @@ static struct class *mdpy_class;
static struct cdev mdpy_cdev;
static struct device mdpy_dev;
static u32 mdpy_count;
+static const struct vfio_device_ops mdpy_dev_ops;
/* State of each mdev device */
struct mdev_state {
+ struct vfio_device vdev;
u8 *vconfig;
u32 bar_mask;
struct mutex ops_lock;
@@ -162,11 +164,9 @@ static void handle_pci_cfg_write(struct mdev_state
*mdev_state, u16 offset,
}
}
-static ssize_t mdev_access(struct mdev_device *mdev, char *buf, size_t count,
- loff_t pos, bool is_write)
+static ssize_t mdev_access(struct mdev_state *mdev_state, char *buf,
+ size_t count, loff_t pos, bool is_write)
{
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
- struct device *dev = mdev_dev(mdev);
int ret = 0;
mutex_lock(&mdev_state->ops_lock);
@@ -187,8 +187,9 @@ static ssize_t mdev_access(struct mdev_device *mdev, char
*buf, size_t count,
memcpy(buf, mdev_state->memblk, count);
} else {
- dev_info(dev, "%s: %s @0x%llx (unhandled)\n",
-__func__, is_write ? "WR" : "RD", pos);
+ dev_info(mdev_state->vdev.dev,
+"%s: %s @0x%llx (unhandled)\n", __func__,
+is_write ? "WR" : "RD", pos);
ret = -1;
goto accessfailed;
}
@@ -202,9 +203,8 @@ static ssize_t mdev_access(struct mdev_device *mdev, char
*buf, size_t count,
return ret;
}
-static int mdpy_reset(struct mdev_device *mdev)
+static int mdpy_reset(struct mdev_state *mdev_state)
{
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
u32 stride, i;
/* initialize with gray gradient */
@@ -216,13 +216,14 @@ static int mdpy_reset(struct mdev_device *mdev)
return 0;
}
-static int mdpy_create(struct mdev_device *mdev)
+static int mdpy_probe(struct mdev_device *mdev)
{
const struct mdpy_type *type =
&mdpy_types[mdev_get_type_group_id(mdev)];
struct device *dev = mdev_dev(mdev);
struct mdev_state *mdev_state;
u32 fbsize;
+ int ret;
if (mdpy_count >= max_devices)
return -ENOMEM;
@@ -230,6 +231,7 @@ static int mdpy_create(struct mdev_device *mdev)
mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
if (mdev_state == NULL)
return -ENOMEM;
+ vfio_init_group_dev(&mdev_state->vdev, &mdev->dev, &mdpy_dev_ops);
mdev_state->vconfig = kzalloc(MDPY_CONFIG_SPACE_SIZE, GFP_KERNEL);
if (mdev_state->vconfig == NULL) {
@@ -250,36 +252,41 @@ static int mdpy_create(struct mdev_device *mdev)
mutex_init(&mdev_state->ops_lock);
mdev_state->mdev = mdev;
- mdev_set_drvdata(mdev, mdev_state);
-
mdev_state->type= type;
mdev_state->memsize = fbsize;
mdpy_create_config_space(mdev_state);
- mdpy_reset(mdev);
+ mdpy_reset(mdev_state);
mdpy_count++;
+
+ ret = vfio_register_group_dev(&mdev_state->vdev);
+ if (ret) {
+ kfree(mdev_state);
+ return ret;
+ }
+ dev_set_drvdata(&mdev->dev, mdev_state);
return 0;
}
-static int mdpy_remove(struct mdev_device *mdev)
+static void mdpy_remove(struct mdev_device *mdev)
{
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
- struct device *dev = mdev_dev(mdev);
+ struct mdev_state *mdev_state = dev_get_drvdata(&mdev->dev);
- dev_info(dev, "%s\n", __func__);
+ dev_info(&mdev->dev, "%s\n", __func__);
- mdev_set_drvdata(mdev, NULL);
+ vfio_unregister_group_dev(&mdev_state->vdev);
vfree(mdev_state->memblk);
kfree(mdev_state->vconfig);
kfree(mdev_state);
mdpy_count--;
- return 0;
}
-static ssize_t mdpy_read(struct mdev_device *mdev, char __user *buf,
+static ssize_t mdpy_read(struct vfio_device *vdev, char __user *buf,
size_t count, loff_t *ppos)
{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
unsigned int done = 0;
int ret;
@@ -289,8 +296,8 @@ static ssize_t mdpy_read(s
[Intel-gfx] [PATCH 10/10] vfio/mbochs: Convert to use vfio_register_group_dev()
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Greg Kroah-Hartman
---
samples/vfio-mdev/mbochs.c | 163 +
1 file changed, 91 insertions(+), 72 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 881ef9a7296f..6c0f229db36a 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -130,6 +130,7 @@ static struct class *mbochs_class;
static struct cdev mbochs_cdev;
static struct device mbochs_dev;
static int mbochs_used_mbytes;
+static const struct vfio_device_ops mbochs_dev_ops;
struct vfio_region_info_ext {
struct vfio_region_info base;
@@ -160,6 +161,7 @@ struct mbochs_dmabuf {
/* State of each mdev device */
struct mdev_state {
+ struct vfio_device vdev;
u8 *vconfig;
u64 bar_mask[3];
u32 memory_bar_mask;
@@ -425,11 +427,9 @@ static void handle_edid_blob(struct mdev_state
*mdev_state, u16 offset,
memcpy(buf, mdev_state->edid_blob + offset, count);
}
-static ssize_t mdev_access(struct mdev_device *mdev, char *buf, size_t count,
- loff_t pos, bool is_write)
+static ssize_t mdev_access(struct mdev_state *mdev_state, char *buf,
+ size_t count, loff_t pos, bool is_write)
{
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
- struct device *dev = mdev_dev(mdev);
struct page *pg;
loff_t poff;
char *map;
@@ -478,7 +478,7 @@ static ssize_t mdev_access(struct mdev_device *mdev, char
*buf, size_t count,
put_page(pg);
} else {
- dev_dbg(dev, "%s: %s @0x%llx (unhandled)\n",
+ dev_dbg(mdev_state->vdev.dev, "%s: %s @0x%llx (unhandled)\n",
__func__, is_write ? "WR" : "RD", pos);
ret = -1;
goto accessfailed;
@@ -493,9 +493,8 @@ static ssize_t mdev_access(struct mdev_device *mdev, char
*buf, size_t count,
return ret;
}
-static int mbochs_reset(struct mdev_device *mdev)
+static int mbochs_reset(struct mdev_state *mdev_state)
{
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
u32 size64k = mdev_state->memsize / (64 * 1024);
int i;
@@ -506,12 +505,13 @@ static int mbochs_reset(struct mdev_device *mdev)
return 0;
}
-static int mbochs_create(struct mdev_device *mdev)
+static int mbochs_probe(struct mdev_device *mdev)
{
const struct mbochs_type *type =
&mbochs_types[mdev_get_type_group_id(mdev)];
struct device *dev = mdev_dev(mdev);
struct mdev_state *mdev_state;
+ int ret = -ENOMEM;
if (type->mbytes + mbochs_used_mbytes > max_mbytes)
return -ENOMEM;
@@ -519,6 +519,7 @@ static int mbochs_create(struct mdev_device *mdev)
mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
if (mdev_state == NULL)
return -ENOMEM;
+ vfio_init_group_dev(&mdev_state->vdev, &mdev->dev, &mbochs_dev_ops);
mdev_state->vconfig = kzalloc(MBOCHS_CONFIG_SPACE_SIZE, GFP_KERNEL);
if (mdev_state->vconfig == NULL)
@@ -537,7 +538,6 @@ static int mbochs_create(struct mdev_device *mdev)
mutex_init(&mdev_state->ops_lock);
mdev_state->mdev = mdev;
- mdev_set_drvdata(mdev, mdev_state);
INIT_LIST_HEAD(&mdev_state->dmabufs);
mdev_state->next_id = 1;
@@ -547,32 +547,38 @@ static int mbochs_create(struct mdev_device *mdev)
mdev_state->edid_regs.edid_offset = MBOCHS_EDID_BLOB_OFFSET;
mdev_state->edid_regs.edid_max_size = sizeof(mdev_state->edid_blob);
mbochs_create_config_space(mdev_state);
- mbochs_reset(mdev);
+ mbochs_reset(mdev_state);
mbochs_used_mbytes += type->mbytes;
+
+ ret = vfio_register_group_dev(&mdev_state->vdev);
+ if (ret)
+ goto err_mem;
+ dev_set_drvdata(&mdev->dev, mdev_state);
return 0;
err_mem:
kfree(mdev_state->vconfig);
kfree(mdev_state);
- return -ENOMEM;
+ return ret;
}
-static int mbochs_remove(struct mdev_device *mdev)
+static void mbochs_remove(struct mdev_device *mdev)
{
- struct mdev_state *mdev_state = mdev_get_drvdata(mdev);
+ struct mdev_state *mdev_state = dev_get_drvdata(&mdev->dev);
mbochs_used_mbytes -= mdev_state->type->mbytes;
- mdev_set_drvdata(mdev, NULL);
+ vfio_unregister_group_dev(&mdev_state->vdev);
kfree(mdev_state->pages);
kfree(mdev_state->vconfig);
kfree(mdev_state);
- return 0;
}
-static ssize_t mbochs_read(struct mdev_device *mdev, char __user *buf
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] driver core: Pull required checks into driver_probe_device()
== Series Details == Series: series starting with [01/10] driver core: Pull required checks into driver_probe_device() URL : https://patchwork.freedesktop.org/series/91634/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8569eedd3acf driver core: Pull required checks into driver_probe_device() -:114: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 1 warnings, 0 checks, 70 lines checked 7219dfc72b48 driver core: Better distinguish probe errors in really_probe -:25: CHECK:LINE_SPACING: Please don't use multiple blank lines #25: FILE: drivers/base/dd.c:516: + total: 0 errors, 0 warnings, 1 checks, 96 lines checked 71bb6630d110 driver core: Flow the return code from ->probe() through to sysfs bind 3ab6e590c963 driver core: Don't return EPROBE_DEFER to userspace during sysfs bind e326450a2b43 driver core: Export device_driver_attach() -:77: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 1 warnings, 0 checks, 30 lines checked ccbf4a404276 vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE -:206: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 1 warnings, 0 checks, 113 lines checked 8d3893f54334 vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind -:203: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 1 warnings, 0 checks, 155 lines checked 2bf9ef7c0deb vfio/mtty: Convert to use vfio_register_group_dev() -:190: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #190: FILE: samples/vfio-mdev/mtty.c:831: +static ssize_t mtty_write(struct vfio_device *vdev, const char __user *buf, size_t count, loff_t *ppos) -:251: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #251: FILE: samples/vfio-mdev/mtty.c:1010: +static int mtty_get_region_info(struct mdev_state *mdev_state, struct vfio_region_info *region_info, -:294: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #294: FILE: samples/vfio-mdev/mtty.c:1084: +static long mtty_ioctl(struct vfio_device *vdev, unsigned int cmd, unsigned long arg) -:470: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 1 warnings, 3 checks, 425 lines checked 3772f36a3130 vfio/mdpy: Convert to use vfio_register_group_dev() -:123: WARNING:TRACING_LOGGING: Unnecessary ftrace-like logging - prefer using ftrace #123: FILE: samples/vfio-mdev/mdpy.c:275: + dev_info(&mdev->dev, "%s\n", __func__); -:454: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 2 warnings, 0 checks, 406 lines checked 25103c4fe2e3 vfio/mbochs: Convert to use vfio_register_group_dev() -:492: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason Gunthorpe ' total: 0 errors, 1 warnings, 0 checks, 440 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] driver core: Pull required checks into driver_probe_device()
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91634/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10237 -> Patchwork_20400
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/index.html
Known issues
Here are the changes found in Patchwork_20400 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +4 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][3] -> [FAIL][4] ([i915#2203] / [i915#579])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/fi-bdw-5557u/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][7] ([i915#2782] / [i915#2940]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus fi-skl-6700k2
Build changes
-
* Linux: CI_DRM_10237 -> Patchwork_20400
CI-20190529: 20190529
CI_DRM_10237: 7a1a8ad7aecfd36adc8ec4e74ddea71920cf7f10 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6112: a17cc0c5d096fabfd516848c114bc411e11130f4 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20400: 25103c4fe2e318de888bfaaf4d1dac3d11fa027b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
25103c4fe2e3 vfio/mbochs: Convert to use vfio_register_group_dev()
3772f36a3130 vfio/mdpy: Convert to use vfio_register_group_dev()
2bf9ef7c0deb vfio/mtty: Convert to use vfio_register_group_dev()
8d3893f54334 vfio/mdev: Allow the mdev_parent_ops to specify the device driver
to bind
ccbf4a404276 vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE
e326450a2b43 driver core: Export device_driver_attach()
3ab6e590c963 driver core: Don't return EPROBE_DEFER to userspace during sysfs
bind
71bb6630d110 driver core: Flow the return code from ->probe() through to sysfs
bind
7219dfc72b48 driver core: Better distinguish probe errors in really_probe
8569eedd3acf driver core: Pull required checks into driver_probe_device()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform execbuffer object locking as a separate step
> -Original Message-
> From: Intel-gfx On Behalf Of
> Thomas Hellström
> Sent: Tuesday, June 15, 2021 4:36 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Thomas Hellström ; Auld, Matthew
>
> Subject: [Intel-gfx] [PATCH] drm/i915: Perform execbuffer object locking as a
> separate step
>
> To help avoid evicting already resident buffers from the batch we're
> processing, perform locking as a separate step.
>
> Signed-off-by: Thomas Hellström
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 --
> -
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 201fed19d120..394eb40c95b5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -922,21 +922,38 @@ static int eb_lookup_vmas(struct i915_execbuffer
> *eb)
> return err;
> }
>
> -static int eb_validate_vmas(struct i915_execbuffer *eb)
> +static int eb_lock_vmas(struct i915_execbuffer *eb)
> {
> unsigned int i;
> int err;
>
> - INIT_LIST_HEAD(&eb->unbound);
> -
> for (i = 0; i < eb->buffer_count; i++) {
> - struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> struct eb_vma *ev = &eb->vma[i];
> struct i915_vma *vma = ev->vma;
>
> err = i915_gem_object_lock(vma->obj, &eb->ww);
> if (err)
> return err;
> + }
> +
> + return 0;
> +}
> +
> +static int eb_validate_vmas(struct i915_execbuffer *eb) {
> + unsigned int i;
> + int err;
> +
> + INIT_LIST_HEAD(&eb->unbound);
> +
> + err = eb_lock_vmas(eb);
> + if (err)
> + return err;
> +
> + for (i = 0; i < eb->buffer_count; i++) {
> + struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> + struct eb_vma *ev = &eb->vma[i];
> + struct i915_vma *vma = ev->vma;
>
> err = eb_pin_vma(eb, entry, ev);
> if (err == -EDEADLK)
Thomas, just checked eb_pin_vma(), it calls i915_vma_pin_ww(), if the object is
already locked, under what condition these calls still return -EDEADLK?
--CQ
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
Sorry I'm behind on mails ...
On Fri, Jun 11, 2021 at 12:50:29PM -0700, Matthew Brost wrote:
> On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> > On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> > > Add entry for i915 new parallel submission uAPI plan.
> > >
> > > v2:
> > > (Daniel Vetter):
> > > - Expand logical order explaination
> > > - Add dummy header
> > > - Only allow N BBs in execbuf IOCTL
> > > - Configure parallel submission per slot not per gem context
> > > v3:
> > > (Marcin Ślusarz):
> > > - Lot's of typos / bad english fixed
> > > (Tvrtko Ursulin):
> > > - Consistent pseudo code, clean up wording in descriptions
> > >
> > > Cc: Tvrtko Ursulin
> > > Cc: Tony Ye
> > > CC: Carl Zhang
> > > Cc: Daniel Vetter
> > > Cc: Jason Ekstrand
> > > Signed-off-by: Matthew Brost
> > > ---
> > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 145 ++
> > > Documentation/gpu/rfc/i915_scheduler.rst | 55 ++-
> > > 2 files changed, 198 insertions(+), 2 deletions(-)
> > > create 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
> > > new file mode 100644
> > > index ..20de206e3ab4
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > @@ -0,0 +1,145 @@
> > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > > i915_context_engines_parallel_submit */
> > > +
> > > +/*
> > > + * i915_context_engines_parallel_submit:
> >
> > So the idea is to make these kerneldoc and pull them into the rfc section.
> > Then when we merge, move them to the real uapi section, like what Matt has
> > done for lmem.
> >
>
> Yep, will fix in next rev.
>
> > > + *
> > > + * 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
> > > know how
> > > + * many BBs there are based on the slots configuration. The N BBs are
> > > the last N
> > > + * buffer objects for first N if I915_EXEC_BATCH_FIRST is set.
> >
> > s/for/or/
> >
> > > + *
> > > + * There are two currently defined ways to control the placement of the
> > > + * hardware contexts on physical engines: default behavior (no flags) and
> > > + * I915_PARALLEL_IMPLICIT_BONDS (a flag). More flags may be added the in
> > > the
> > > + * future as new hardware / use cases arise. Details of how to use this
> > > + * interface above the flags field in this structure.
> > > + *
> > > + * 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
> > > + * inteface.
> > > + */
> > > +struct i915_context_engines_parallel_submit {
> > > + struct i915_user_extension base;
> > > +
> > > + __u16 engine_index; /* slot for parallel engine */
> >
> > Kernel doc here for the inline comments too.
> >
>
> Yep.
>
> > > + __u16 width;/* number of contexts per parallel engine */
> > > + __u16 num_siblings; /* number of siblings per context */
> > > + __u16 mbz16;
> > > +/*
> > > + * Default placement behavior (currently unsupported):
> > > + *
> > > + * Allow BBs to be placed on any available engine instance. In this case
> > > each
> > > + * context's engine mask indicates where that context can be placed. It
> > > is
> > > + * implied in this mode that all contexts have mutual exclusive
> > > placement.
> > > + * e.g. If one context is running CSX[0] no other contexts can run on
> > > CSX[0]).
> > > + *
> > > + * Example 1 pseudo code:
> > > + * CSX,Y[N] = generic engine class X or Y, logical instance N
> > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > + * set_engines(INVALID)
> > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > + * engines=CSX[0],CSX[1],CSY[0],CSY[1])
> > > + *
> > > + * Results in the following valid placements:
> > > + * CSX[0], CSY[0]
> > > + * CSX[0], CSY[1]
> > > + * CSX[1], CSY[0]
> > > + * CSX[1], CSY[1]
> > > + *
> > > + * This can also be thought of as 2 virtual engines described by 2-D
> > > array in
> > > + * the engines the field:
> > > + * VE[0] = CSX[0], CSX[1]
> > > + * VE[1] = CSY[0], CSY[1]
> > > + *
> > > + * Example 2 pseudo code:
> > > + * CSX[Y] = generic engine of same class X, logical instance N
> > > + * INVALID =
Re: [Intel-gfx] [PATCH 0/2] GuC submission / DRM scheduler integration plan + new uAPI
On Fri, Jun 11, 2021 at 04:40:42PM -0700, Matthew Brost wrote: > Subject and patches say it all. > > v2: Address comments, patches have details of changes > v3: Address comments, patches have details of changes > v4: Address comments, patches have details of changes > > Signed-off-by: Matthew Brost Imo ready (well overdue) for merging, please annoy Carl or someone from media for an ack and then ask John or Daniele to merge it into drm-intel-gt-next. -Daniel > > Matthew Brost (2): > drm/doc/rfc: i915 GuC submission / DRM scheduler > drm/doc/rfc: i915 new parallel submission uAPI plan > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 117 ++ > Documentation/gpu/rfc/i915_scheduler.rst | 148 ++ > Documentation/gpu/rfc/index.rst | 4 + > 3 files changed, 269 insertions(+) > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h > create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst > > -- > 2.28.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/10] driver core: Pull required checks into driver_probe_device()
== Series Details == Series: series starting with [01/10] driver core: Pull required checks into driver_probe_device() URL : https://patchwork.freedesktop.org/series/91634/ State : success == Summary == CI Bug Log - changes from CI_DRM_10237_full -> Patchwork_20400_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20400_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-noreloc-purge-cache-random: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271]) +155 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-snb5/igt@api_intel...@blit-noreloc-purge-cache-random.html * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-snb2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][6] ([i915#3354]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/shard-iclb3/igt@gem_exec_fair@basic-p...@vecs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-iclb3/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2849]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/shard-skl6/igt@gem_mmap_...@big-copy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-skl3/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_gtt@cpuset-medium-copy: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10237/shard-glk8/igt@gem_mmap_...@cpuset-medium-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-glk6/igt@gem_mmap_...@cpuset-medium-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-apl7/igt@gem_pwr...@basic-exhaustion.html * igt@gen9_exec_parse@allowed-single: - shard-skl: NOTRUN -> [DMESG-WARN][20] ([i915#1436] / [i915#716]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@bb-start-param: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#112306]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-tglb6/igt@gen9_exec_pa...@bb-start-param.html * igt@kms_big_fb@linear-64bpp-rotate-90: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111614]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20400/shard-tglb6/igt@kms_big...@linear-64bpp-rotate-90.html * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - shard-glk: [PASS][23] -> [DMES
Re: [Intel-gfx] [PATCH v2] drm/i915: Document the Virtual Engine uAPI
On Mon, Jun 14, 2021 at 10:09:59AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A little bit of documentation covering the topics of engine discovery,
> context engine maps and virtual engines. It is not very detailed but
> supposed to be a starting point of giving a brief high level overview of
> general principles and intended use cases.
>
> v2:
> * Have the text in uapi header and link from there.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
What I meant was the kerneldoc directly as kerneldoc for the uapi structs,
like Matt has done for e.g. drm_i915_gem_create_ext_memory_regions.
But then I also realized that Matt hasn't set up the include for this, so
it's not automatic at all yet :-/
-Daniel
> ---
> Documentation/gpu/i915.rst | 18
> include/uapi/drm/i915_drm.h | 188
> 2 files changed, 206 insertions(+)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..00aa55bbe0fd 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -335,6 +335,24 @@ for execution also include a list of all locations
> within buffers that
> refer to GPU-addresses so that the kernel can edit the buffer correctly.
> This process is dubbed relocation.
>
> +Engine Discovery uAPI
> +-
> +
> +.. kernel-doc:: include/uapi/drm/i915_drm.h
> + :doc: Engine Discovery uAPI
> +
> +Context Engine Map uAPI
> +---
> +
> +.. kernel-doc:: include/uapi/drm/i915_drm.h
> + :doc: Context Engine Map uAPI
> +
> +Virtual Engine uAPI
> +---
> +
> +.. kernel-doc:: include/uapi/drm/i915_drm.h
> + :doc: Virtual Engine uAPI
> +
> Locking Guidelines
> --
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index a1cb4aa035a9..2f70c48567c0 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1806,6 +1806,69 @@ struct drm_i915_gem_context_param_sseu {
> __u32 rsvd;
> };
>
> +/**
> + * DOC: Virtual Engine uAPI
> + *
> + * Virtual engine is a concept where userspace is able to configure a set of
> + * physical engines, submit a batch buffer, and let the driver execute it on
> any
> + * engine from the set as it sees fit.
> + *
> + * This is primarily useful on parts which have multiple instances of a same
> + * class engine, like for example GT3+ Skylake parts with their two VCS
> engines.
> + *
> + * For instance userspace can enumerate all engines of a certain class using
> the
> + * previously described `Engine Discovery uAPI`_. After that userspace can
> + * create a GEM context with a placeholder slot for the virtual engine (using
> + * `I915_ENGINE_CLASS_INVALID` and `I915_ENGINE_CLASS_INVALID_NONE` for class
> + * and instance respectively) and finally using the
> + * `I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine
> in
> + * the same reserved slot.
> + *
> + * Example of creating a virtual engine and submitting a batch buffer to it:
> + *
> + * .. code-block:: C
> + *
> + * I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(virtual, 2) = {
> + * .base.name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE,
> + * .engine_index = 0, // Place this virtual engine into engine map
> slot 0
> + * .num_siblings = 2,
> + * .engines = { { I915_ENGINE_CLASS_VIDEO, 0 },
> + *{ I915_ENGINE_CLASS_VIDEO, 1 }, },
> + * };
> + * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = {
> + * .engines = { { I915_ENGINE_CLASS_INVALID,
> + * I915_ENGINE_CLASS_INVALID_NONE } },
> + * .extensions = to_user_pointer(&virtual), // Chains after
> load_balance extension
> + * };
> + * struct drm_i915_gem_context_create_ext_setparam p_engines = {
> + * .base = {
> + * .name = I915_CONTEXT_CREATE_EXT_SETPARAM,
> + * },
> + * .param = {
> + * .param = I915_CONTEXT_PARAM_ENGINES,
> + * .value = to_user_pointer(&engines),
> + * .size = sizeof(engines),
> + * },
> + * };
> + * struct drm_i915_gem_context_create_ext create = {
> + * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> + * .extensions = to_user_pointer(&p_engines);
> + * };
> + *
> + * ctx_id = gem_context_create_ext(drm_fd, &create);
> + *
> + * // Now we have created a GEM context with its engine map containing a
> + * // single virtual engine. Submissions to this slot can go either to
> + * // vcs0 or vcs1, depending on the load balancing algorithm used inside
> + * // the driver. The load balancing is dynamic from one batch buffer to
> + * // another and transparent to userspace.
> + *
> + * ...
> + * execbuf.rsvd1 = ctx_id;
> + * execbuf.flags = 0; // Submits to index 0 which is the virtual engine
> + * gem_execbuf(drm_fd, &execbuf);
> + */
> +
> /
Re: [Intel-gfx] [PATCH] drm/i915: allow DG1 autoprobe for CONFIG_BROKEN
On Wed, Jun 16, 2021 at 03:29:26PM +0100, Matthew Auld wrote:
> On Mon, 14 Jun 2021 at 10:22, Matthew Auld wrote:
> >
> > Purely for CI so we can get some pre-merge results for DG1. This is
> > especially useful for cross driver TTM changes where CI can hopefully
> > catch regressions. This is similar to how we already handle the DG1
> > specific uAPI, which are also hidden behind CONFIG_BROKEN.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Daniel Vetter
> > Cc: Dave Airlie
>
> Daniel, any objections to landing this?
I think stuffing this into topic/core-for-CI is fine, lets wait a bit more
until mesa and everything is ready with adding the pciids to an official
tree.
(Catching up on mails, apologies and all that).
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 83b500bb170c..78742157aaa3 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -1040,6 +1040,9 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_RKL_IDS(&rkl_info),
> > INTEL_ADLS_IDS(&adl_s_info),
> > INTEL_ADLP_IDS(&adl_p_info),
> > +#if IS_ENABLED(CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM)
> > + INTEL_DG1_IDS(&dg1_info),
> > +#endif
> > {0, 0, 0}
> > };
> > MODULE_DEVICE_TABLE(pci, pciidlist);
> > --
> > 2.26.3
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
On Mon, Jun 14, 2021 at 09:45:37PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> We are observing some user-space crashes (sigabort, segfaults etc.)
> under moderate memory pressure (pretty far from severe pressure) which
> have one thing in common - restrictive GFP mask in setup_scratch_page().
>
> For instance, (stable 4.19) drivers/gpu/drm/i915/i915_gem_gtt.c
>
> (trimmed down version)
>
> static int gen8_init_scratch(struct i915_address_space *vm)
> {
> setup_scratch_page(vm, __GFP_HIGHMEM);
>
> vm->scratch_pt = alloc_pt(vm);
> vm->scratch_pd = alloc_pd(vm);
> if (use_4lvl(vm)) {
> vm->scratch_pdp = alloc_pdp(vm);
> }
> }
>
> gen8_init_scratch() function puts a rather inconsistent restrictions on mm.
>
> Looking at it line by line:
>
> setup_scratch_page() uses very restrictive gfp mask:
> __GFP_HIGHMEM | __GFP_ZERO | __GFP_RETRY_MAYFAIL
>
> it doesn't try to reclaim anything and fails almost immediately.
>
> alloc_pt() - uses more permissive gfp mask:
> GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN
>
> alloc_pd() - likewise:
> GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN
>
> alloc_pdp() - very permissive gfp mask:
> GFP_KERNEL
>
>
> So can all allocations in gen8_init_scratch() use
> GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN
Yeah that looks all fairly broken tbh. The only thing I didn't know was
that GFP_DMA32 wasn't a full gfp mask with reclaim bits set as needed. I
guess it would be clearer if we use GFP_KERNEL | __GFP_DMA32 for these.
The commit that introduced a lot of this, including I915_GFP_ALLOW_FAIL
seems to be
commit 1abb70f5955d1a9021f96359a2c6502ca569b68d
Author: Chris Wilson
Date: Tue May 22 09:36:43 2018 +0100
drm/i915/gtt: Allow pagedirectory allocations to fail
which used a selftest as justification, not real world workloads, so looks
rather dubious.
Adding Matt Auld to this thread, maybe he has ideas.
Thanks, Daniel
> ?
>
> E.g.
>
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index a12430187108..e862680b9c93 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -792,7 +792,7 @@ alloc_pdp(struct i915_address_space *vm)
>
> GEM_BUG_ON(!use_4lvl(vm));
>
> - pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
> + pdp = kzalloc(sizeof(*pdp), I915_GFP_ALLOW_FAIL);
> if (!pdp)
> return ERR_PTR(-ENOMEM);
>
> @@ -1262,7 +1262,7 @@ static int gen8_init_scratch(struct i915_address_space
> *vm)
> {
> int ret;
>
> - ret = setup_scratch_page(vm, __GFP_HIGHMEM);
> + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
> if (ret)
> return ret;
>
> @@ -1972,7 +1972,7 @@ static int gen6_ppgtt_init_scratch(struct gen6_hw_ppgtt
> *ppgtt)
> u32 pde;
> int ret;
>
> - ret = setup_scratch_page(vm, __GFP_HIGHMEM);
> + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
> if (ret)
> return ret;
>
> @@ -3078,7 +3078,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt,
> u64 size)
> return -ENOMEM;
> }
>
> - ret = setup_scratch_page(&ggtt->vm, GFP_DMA32);
> + ret = setup_scratch_page(&ggtt->vm, GFP_KERNEL | GFP_DMA32);
> if (ret) {
> DRM_ERROR("Scratch setup failed\n");
> /* iounmap will also get called at remove, but meh */
> ---
>
>
>
> It's quite similar on stable 5.4 - setup_scratch_page() uses restrictive
> gfp mask again.
>
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index f614646ed3f9..99d78b1052df 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1378,7 +1378,7 @@ static int gen8_init_scratch(struct i915_address_space
> *vm)
> return 0;
> }
>
> - ret = setup_scratch_page(vm, __GFP_HIGHMEM);
> + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
> if (ret)
> return ret;
>
> @@ -1753,7 +1753,7 @@ static int gen6_ppgtt_init_scratch(struct gen6_ppgtt
> *ppgtt)
> struct i915_page_directory * const pd = ppgtt->base.pd;
> int ret;
>
> - ret = setup_scratch_page(vm, __GFP_HIGHMEM);
> + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
> if (ret)
> return ret;
>
> @@ -2860,7 +2860,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt,
> u64 size)
> return -ENOMEM;
> }
>
> - ret = setup_scratch_page(&ggtt->vm, GFP_DMA32);
> + ret = setup_scratch_page(&ggtt->vm, GFP_KERNEL | GFP_DMA32);
> if (ret) {
> DRM_ERROR("Scratch setup failed\n");
> /* iounmap will also get called at remove, but meh */
> ---
--
Daniel Vetter
Software Engineer
Re: [Intel-gfx] [RFC PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Thu, Jun 17, 2021 at 06:46:48PM +0200, Daniel Vetter wrote:
> Sorry I'm behind on mails ...
>
Aren't we all.
> On Fri, Jun 11, 2021 at 12:50:29PM -0700, Matthew Brost wrote:
> > On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> > > On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> > > > Add entry for i915 new parallel submission uAPI plan.
> > > >
> > > > v2:
> > > > (Daniel Vetter):
> > > > - Expand logical order explaination
> > > > - Add dummy header
> > > > - Only allow N BBs in execbuf IOCTL
> > > > - Configure parallel submission per slot not per gem context
> > > > v3:
> > > > (Marcin Ślusarz):
> > > > - Lot's of typos / bad english fixed
> > > > (Tvrtko Ursulin):
> > > > - Consistent pseudo code, clean up wording in descriptions
> > > >
> > > > Cc: Tvrtko Ursulin
> > > > Cc: Tony Ye
> > > > CC: Carl Zhang
> > > > Cc: Daniel Vetter
> > > > Cc: Jason Ekstrand
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 145 ++
> > > > Documentation/gpu/rfc/i915_scheduler.rst | 55 ++-
> > > > 2 files changed, 198 insertions(+), 2 deletions(-)
> > > > create 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
> > > > new file mode 100644
> > > > index ..20de206e3ab4
> > > > --- /dev/null
> > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > @@ -0,0 +1,145 @@
> > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > > > i915_context_engines_parallel_submit */
> > > > +
> > > > +/*
> > > > + * i915_context_engines_parallel_submit:
> > >
> > > So the idea is to make these kerneldoc and pull them into the rfc section.
> > > Then when we merge, move them to the real uapi section, like what Matt has
> > > done for lmem.
> > >
> >
> > Yep, will fix in next rev.
> >
> > > > + *
> > > > + * 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
> > > > know how
> > > > + * many BBs there are based on the slots configuration. The N BBs are
> > > > the last N
> > > > + * buffer objects for first N if I915_EXEC_BATCH_FIRST is set.
> > >
> > > s/for/or/
> > >
> > > > + *
> > > > + * There are two currently defined ways to control the placement of the
> > > > + * hardware contexts on physical engines: default behavior (no flags)
> > > > and
> > > > + * I915_PARALLEL_IMPLICIT_BONDS (a flag). More flags may be added the
> > > > in the
> > > > + * future as new hardware / use cases arise. Details of how to use this
> > > > + * interface above the flags field in this structure.
> > > > + *
> > > > + * 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
> > > > + * inteface.
> > > > + */
> > > > +struct i915_context_engines_parallel_submit {
> > > > + struct i915_user_extension base;
> > > > +
> > > > + __u16 engine_index; /* slot for parallel engine */
> > >
> > > Kernel doc here for the inline comments too.
> > >
> >
> > Yep.
> >
> > > > + __u16 width;/* number of contexts per parallel
> > > > engine */
> > > > + __u16 num_siblings; /* number of siblings per context */
> > > > + __u16 mbz16;
> > > > +/*
> > > > + * Default placement behavior (currently unsupported):
> > > > + *
> > > > + * Allow BBs to be placed on any available engine instance. In this
> > > > case each
> > > > + * context's engine mask indicates where that context can be placed.
> > > > It is
> > > > + * implied in this mode that all contexts have mutual exclusive
> > > > placement.
> > > > + * e.g. If one context is running CSX[0] no other contexts can run on
> > > > CSX[0]).
> > > > + *
> > > > + * Example 1 pseudo code:
> > > > + * CSX,Y[N] = generic engine class X or Y, logical instance N
> > > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > > + * set_engines(INVALID)
> > > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > > + * engines=CSX[0],CSX[1],CSY[0],CSY[1])
> > > > + *
> > > > + * Results in the following valid placements:
> > > > + * CSX[0], CSY[0]
> > > > + * CSX[0], CSY[1]
> > > > + * CSX[
Re: [Intel-gfx] [PATCH] drm/i915: Remove duplicate include of intel_region_lmem.h
On Tue, Jun 15, 2021 at 07:35:20PM +0800, Wan Jiabing wrote:
> Fix the following checkinclude.pl warning:
> drivers/gpu/drm/i915/gt/intel_region_lmem.c
> 8 #include "intel_region_lmem.h"
> 12 #include "intel_region_lmem.h"
>
> Signed-off-by: Wan Jiabing
Applied to drm-intel-gt-next, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> index f7366b054f8e..119eeec98837 100644
> --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -9,7 +9,6 @@
> #include "intel_region_ttm.h"
> #include "gem/i915_gem_lmem.h"
> #include "gem/i915_gem_region.h"
> -#include "intel_region_lmem.h"
>
> static int init_fake_lmem_bar(struct intel_memory_region *mem)
> {
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix duplicate included intel_region_lmem.h
On Wed, Jun 16, 2021 at 02:01:58PM +0800, Jiapeng Chong wrote: > Clean up the following includecheck warning: > > ./drivers/gpu/drm/i915/gt/intel_region_lmem.c: intel_region_lmem.h is > included more than once. > > No functional change. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Already merged another one of these: commit 6796c772850574ec0a9adc977e9889606b23d0f4 (HEAD -> drm-intel-gt-next, drm-intel/drm-intel-gt-next) Author: Wan Jiabing Date: Tue Jun 15 19:35:20 2021 +0800 drm/i915: Remove duplicate include of intel_region_lmem.h Thanks anyway. Cheers, Daniel > --- > drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c > b/drivers/gpu/drm/i915/gt/intel_region_lmem.c > index f7366b0..aa3cfca 100644 > --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c > +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c > @@ -5,7 +5,6 @@ > > #include "i915_drv.h" > #include "intel_memory_region.h" > -#include "intel_region_lmem.h" > #include "intel_region_ttm.h" > #include "gem/i915_gem_lmem.h" > #include "gem/i915_gem_region.h" > -- > 1.8.3.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 01/12] drm/i915: Reference objects on the ww object list
On Thu, Jun 17, 2021 at 08:30:07AM +0200, Thomas Hellström wrote:
> Since the ww transaction endpoint easily end up far out-of-scope of
> the objects on the ww object list, particularly for contending lock
> objects, make sure we reference objects on the list so they don't
> disappear under us.
>
> This comes with a performance penalty so it's been debated whether this
> is really needed. But I think this is motivated by the fact that locking
> is typically difficult to get right, and whatever we can do to make it
> simpler for developers moving forward should be done, unless the
> performance impact is far too high.
>
> Signed-off-by: Thomas Hellström
> Reviewed-by: Matthew Auld
Acked-by: Daniel Vetter
I've looked the past 2-3 weeks in-depth at our execbuf code. That has
definitely gone way too far into "very clevery" territory, and safe is so
much better than clever.
If there's a fundamental performance issue, we need to fix this in a
fundamental way. E.g. for this one here a possible solution could be
VM_BIND, at least in the fastpath, where we don't need to look-up any
objects, nor refcount them, nor anything else (at least that's the goal).
Only some per vm/request book-keeping and done.
Also I think we can easily claw this back once we get to the cleanup part
of this work: i915_vma_pin has a bunch of atomics (and lots of locks in
slow-paths) of its own, which are largely redundant now that object state
is protected by dma_resv_lock. Once that's cleaned up we can pay our
atomic inc/dec here with the removed atomic ops from the vma side I think.
Anyway just figured I drop some thoughts and my ack on the direction
you're pushing here.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 ++--
> drivers/gpu/drm/i915/i915_gem.c| 4
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index d66aa00d023a..241666931945 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -169,13 +169,17 @@ static inline int __i915_gem_object_lock(struct
> drm_i915_gem_object *obj,
> else
> ret = dma_resv_lock(obj->base.resv, ww ? &ww->ctx : NULL);
>
> - if (!ret && ww)
> + if (!ret && ww) {
> + i915_gem_object_get(obj);
> list_add_tail(&obj->obj_link, &ww->obj_list);
> + }
> if (ret == -EALREADY)
> ret = 0;
>
> - if (ret == -EDEADLK)
> + if (ret == -EDEADLK) {
> + i915_gem_object_get(obj);
> ww->contended = obj;
> + }
>
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6a0a3f0e36e1..c62dcd0e341a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1222,6 +1222,7 @@ static void i915_gem_ww_ctx_unlock_all(struct
> i915_gem_ww_ctx *ww)
> while ((obj = list_first_entry_or_null(&ww->obj_list, struct
> drm_i915_gem_object, obj_link))) {
> list_del(&obj->obj_link);
> i915_gem_object_unlock(obj);
> + i915_gem_object_put(obj);
> }
> }
>
> @@ -1229,6 +1230,7 @@ void i915_gem_ww_unlock_single(struct
> drm_i915_gem_object *obj)
> {
> list_del(&obj->obj_link);
> i915_gem_object_unlock(obj);
> + i915_gem_object_put(obj);
> }
>
> void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ww)
> @@ -1253,6 +1255,8 @@ int __must_check i915_gem_ww_ctx_backoff(struct
> i915_gem_ww_ctx *ww)
>
> if (!ret)
> list_add_tail(&ww->contended->obj_link, &ww->obj_list);
> + else
> + i915_gem_object_put(ww->contended);
>
> ww->contended = NULL;
>
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Document the Virtual Engine uAPI
On 17/06/2021 18:17, Daniel Vetter wrote:
On Mon, Jun 14, 2021 at 10:09:59AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A little bit of documentation covering the topics of engine discovery,
context engine maps and virtual engines. It is not very detailed but
supposed to be a starting point of giving a brief high level overview of
general principles and intended use cases.
v2:
* Have the text in uapi header and link from there.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
What I meant was the kerneldoc directly as kerneldoc for the uapi structs,
like Matt has done for e.g. drm_i915_gem_create_ext_memory_regions.
Hm I wanted to add some commentary to give a high level picture of this
area and not necessarily focus on uapi structs details. Some of them (at
least one I think) already have their own documentation and the rest
could be added in detail. But I do think a short "story" in the order of
chapters I added to i915.rst makes sense as reading material.
But then I also realized that Matt hasn't set up the include for this, so
it's not automatic at all yet :-/
No idea what where how you mean. The fact i915_drm.h docs are not pulled
in anywhere?
Regards,
Tvrtko
-Daniel
---
Documentation/gpu/i915.rst | 18
include/uapi/drm/i915_drm.h | 188
2 files changed, 206 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..00aa55bbe0fd 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -335,6 +335,24 @@ for execution also include a list of all locations within
buffers that
refer to GPU-addresses so that the kernel can edit the buffer correctly.
This process is dubbed relocation.
+Engine Discovery uAPI
+-
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
+ :doc: Engine Discovery uAPI
+
+Context Engine Map uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
+ :doc: Context Engine Map uAPI
+
+Virtual Engine uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
+ :doc: Virtual Engine uAPI
+
Locking Guidelines
--
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a1cb4aa035a9..2f70c48567c0 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1806,6 +1806,69 @@ struct drm_i915_gem_context_param_sseu {
__u32 rsvd;
};
+/**
+ * DOC: Virtual Engine uAPI
+ *
+ * Virtual engine is a concept where userspace is able to configure a set of
+ * physical engines, submit a batch buffer, and let the driver execute it on
any
+ * engine from the set as it sees fit.
+ *
+ * This is primarily useful on parts which have multiple instances of a same
+ * class engine, like for example GT3+ Skylake parts with their two VCS
engines.
+ *
+ * For instance userspace can enumerate all engines of a certain class using
the
+ * previously described `Engine Discovery uAPI`_. After that userspace can
+ * create a GEM context with a placeholder slot for the virtual engine (using
+ * `I915_ENGINE_CLASS_INVALID` and `I915_ENGINE_CLASS_INVALID_NONE` for class
+ * and instance respectively) and finally using the
+ * `I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine in
+ * the same reserved slot.
+ *
+ * Example of creating a virtual engine and submitting a batch buffer to it:
+ *
+ * .. code-block:: C
+ *
+ * I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(virtual, 2) = {
+ * .base.name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE,
+ * .engine_index = 0, // Place this virtual engine into engine map
slot 0
+ * .num_siblings = 2,
+ * .engines = { { I915_ENGINE_CLASS_VIDEO, 0 },
+ * { I915_ENGINE_CLASS_VIDEO, 1 }, },
+ * };
+ * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = {
+ * .engines = { { I915_ENGINE_CLASS_INVALID,
+ *I915_ENGINE_CLASS_INVALID_NONE } },
+ * .extensions = to_user_pointer(&virtual), // Chains after
load_balance extension
+ * };
+ * struct drm_i915_gem_context_create_ext_setparam p_engines = {
+ * .base = {
+ * .name = I915_CONTEXT_CREATE_EXT_SETPARAM,
+ * },
+ * .param = {
+ * .param = I915_CONTEXT_PARAM_ENGINES,
+ * .value = to_user_pointer(&engines),
+ * .size = sizeof(engines),
+ * },
+ * };
+ * struct drm_i915_gem_context_create_ext create = {
+ * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ * .extensions = to_user_pointer(&p_engines);
+ * };
+ *
+ * ctx_id = gem_context_create_ext(drm_fd, &create);
+ *
+ * // Now we have created a GEM context with its engine map containing a
+ * // single virtual engine. Submissions to this slot can go either to
+ * // vcs0 or vcs1,
[Intel-gfx] [PATCH v4 3/3] drm/i915: Add support for explicit L3BANK steering
Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register. In cases where it does not, use
explicit runtime steering whenever an L3BANK multicast register is read.
While we're at it, let's simplify the function a little bit and drop its
support for gen10/CNL since no such platforms ever materialized for real
use. Multicast register steering is already an area that causes enough
confusion; no need to complicate it with what's effectively dead code.
v2:
- Use gt->uncore instead of gt->i915->uncore. (Tvrtko)
- Use {} as table terminator. (Rodrigo)
v3:
- L3bank fuse register is a disable mask rather than an enable mask.
We need to invert it before use. (CI)
v4:
- L3bank ID goes in the subslice field, not the slice field. (CI)
Cc: Tvrtko Ursulin
Cc: Rodrigo Vivi
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt.c | 18 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 4 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 84 ++---
3 files changed, 46 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 80badc54b19d..a668f6670ce0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -83,6 +83,11 @@ void intel_gt_init_hw_early(struct intel_gt *gt, struct
i915_ggtt *ggtt)
gt->ggtt = ggtt;
}
+static const struct intel_mmio_range icl_l3bank_steering_table[] = {
+ { 0x00B100, 0x00B3FF },
+ {},
+};
+
int intel_gt_init_mmio(struct intel_gt *gt)
{
intel_gt_init_clock_frequency(gt);
@@ -90,6 +95,13 @@ int intel_gt_init_mmio(struct intel_gt *gt)
intel_uc_init_mmio(>->uc);
intel_sseu_info_init(gt);
+ if (GRAPHICS_VER(gt->i915) >= 11) {
+ gt->steering_table[L3BANK] = icl_l3bank_steering_table;
+ gt->info.l3bank_mask =
+ ~intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) &
+ GEN10_L3BANK_MASK;
+ }
+
return intel_engines_init_mmio(gt);
}
@@ -744,6 +756,12 @@ static void intel_gt_get_valid_steering(struct intel_gt
*gt,
u8 *sliceid, u8 *subsliceid)
{
switch (type) {
+ case L3BANK:
+ GEM_DEBUG_WARN_ON(!gt->info.l3bank_mask); /* should be
impossible! */
+
+ *sliceid = 0; /* unused */
+ *subsliceid = __ffs(gt->info.l3bank_mask);
+ break;
default:
MISSING_CASE(type);
*sliceid = 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f2c274eee1e6..80dc131e862f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -48,6 +48,8 @@ struct intel_mmio_range {
* need to explicitly re-steer reads of registers of the other type.
*/
enum intel_steering_type {
+ L3BANK,
+
NUM_STEERING_TYPES
};
@@ -174,6 +176,8 @@ struct intel_gt {
/* Media engine access to SFC per instance */
u8 vdbox_sfc_access;
+ u32 l3bank_mask;
+
/* Slice/subslice/EU info */
struct sseu_dev_info sseu;
} info;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 93c74d4cae02..d9a5a445ceec 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -945,71 +945,37 @@ cfl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
}
static void
-wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
+icl_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
const struct sseu_dev_info *sseu = &i915->gt.info.sseu;
unsigned int slice, subslice;
- u32 l3_en, mcr, mcr_mask;
+ u32 mcr, mcr_mask;
- GEM_BUG_ON(GRAPHICS_VER(i915) < 10);
+ GEM_BUG_ON(GRAPHICS_VER(i915) < 11);
+ GEM_BUG_ON(hweight8(sseu->slice_mask) > 1);
+ slice = 0;
/*
-* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
-* L3Banks could be fused off in single slice scenario. If that is
-* the case, we might need to program MCR select to a valid L3Bank
-* by default, to make sure we correctly read certain registers
-* later on (in the range 0xB100 - 0xB3FF).
-*
-* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
-* Before any MMIO read into slice/subslice specific registers, MCR
-* packet control register needs to be programmed to point to any
-* enabled s/ss pair. Otherwise, incorrect values will be returned.
-* Th
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Explicity steer l3bank multicast reads when necessary (rev6)
== Series Details == Series: Explicity steer l3bank multicast reads when necessary (rev6) URL : https://patchwork.freedesktop.org/series/91485/ State : failure == Summary == Applying: drm/i915: extract steered reg access to common function Applying: drm/i915: Add GT support for multiple types of multicast steering Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_gt.c M drivers/gpu/drm/i915/gt/intel_gt_types.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_gt_types.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_gt_types.h Auto-merging drivers/gpu/drm/i915/gt/intel_gt.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/i915: Add GT support for multiple types of multicast steering 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Pipe DMC bits + PSR fix
Pipe DMC series exposed a corner case in PSR patches that were merged recently. Sending the fix along with the Pipe DMC bits to get ensure that CI has no regressions. Anusha Srivatsa (4): drm/i915/dmc: Introduce DMC_FW_MAIN drm/i915/xelpd: Pipe A DMC plugging drm/i915/adl_p: Pipe B DMC Support drm/i915/adl_p: Load DMC Gwan-gyeong Mun (1): drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P drivers/gpu/drm/i915/display/intel_cdclk.c| 22 ++- .../drm/i915/display/intel_display_debugfs.c | 6 +- .../drm/i915/display/intel_display_power.c| 5 +- drivers/gpu/drm/i915/display/intel_dmc.c | 165 ++ drivers/gpu/drm/i915/display/intel_dmc.h | 23 ++- drivers/gpu/drm/i915/i915_reg.h | 2 +- 6 files changed, 139 insertions(+), 84 deletions(-) -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/dmc: Introduce DMC_FW_MAIN
This is a prep patch for Pipe DMC plugging.
Add dmc_info struct in intel_dmc to have all common fields
shared between all DMC's in the package.
Add DMC_FW_MAIN(dmc_id 0) to refer to the blob.
v2: Remove dmc_offset and start_mmioaddr from dmc_info struct (Jose)
Cc: Souza, Jose
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 38 +---
drivers/gpu/drm/i915/display/intel_dmc.h | 18 +++
2 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 97308da28059..269a57d936ab 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -239,7 +239,7 @@ struct stepping_info {
bool intel_dmc_has_payload(struct drm_i915_private *i915)
{
- return i915->dmc.dmc_payload;
+ return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
}
static const struct stepping_info skl_stepping_info[] = {
@@ -316,7 +316,8 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
*/
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
- u32 *payload = dev_priv->dmc.dmc_payload;
+ struct intel_dmc *dmc = &dev_priv->dmc;
+ struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
u32 i, fw_size;
if (!HAS_DMC(dev_priv)) {
@@ -325,26 +326,26 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- if (!intel_dmc_has_payload(dev_priv)) {
+ if (!dev_priv->dmc.dmc_info[DMC_FW_MAIN].payload) {
drm_err(&dev_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
- fw_size = dev_priv->dmc.dmc_fw_size;
+ fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(&dev_priv->runtime_pm);
preempt_disable();
for (i = 0; i < fw_size; i++)
intel_uncore_write_fw(&dev_priv->uncore, DMC_PROGRAM(i),
- payload[i]);
+ dmc_info->payload[i]);
preempt_enable();
- for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
- intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
- dev_priv->dmc.mmiodata[i]);
+ for (i = 0; i < dmc_info->mmio_count; i++) {
+ intel_de_write(dev_priv, dmc_info->mmioaddr[i],
+ dmc_info->mmiodata[i]);
}
dev_priv->dmc.dc_state = 0;
@@ -401,13 +402,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
size_t rem_size)
{
struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+ struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
u8 *payload;
- BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+ BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
/*
* Check if we can access common fields, we will checkc again below
@@ -469,10 +471,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
mmioaddr[i]);
return 0;
}
- dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
- dmc->mmiodata[i] = mmiodata[i];
+ dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
+ dmc_info->mmiodata[i] = mmiodata[i];
}
- dmc->mmio_count = mmio_count;
+ dmc_info->mmio_count = mmio_count;
rem_size -= header_len_bytes;
@@ -485,14 +487,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
drm_err(&i915->drm, "DMC FW too big (%u bytes)\n",
payload_size);
return 0;
}
- dmc->dmc_fw_size = dmc_header->fw_size;
+ dmc_info->dmc_fw_size = dmc_header->fw_size;
- dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
- if (!dmc->dmc_payload)
+ dmc_info->payload = kmalloc(payload_size, GFP_KERNEL);
+ if (!dmc_info->payload)
return 0;
payload = (u8 *)(dmc_header) + header_len_bytes;
- memcpy(dmc->dmc_payload, payload, payload_size);
+ memcpy(dmc_info->payload, payload, payload_size);
return header_len_bytes + payload_size;
@@ -827,5 +829,5 @@ void intel_dmc_ucode_fini(struct drm_i915_private *dev_priv)
intel_dmc_ucode_suspend(dev_priv);
drm_WARN_ON(&dev_priv->drm, dev_priv->dmc.wakeref);
- kfree(dev_priv->dmc.dmc_payload);
+ kfree(dev_priv->dmc.dmc_info[D
[Intel-gfx] [PATCH 3/5] drm/i915/xelpd: Pipe A DMC plugging
This patch adds Pipe A plumbing to the already
existing parsing and loading functions which is
taken care of in the prep patches. Adding MAX_DMC_FW
to keep track for both Main and Pipe A DMC while loading
the respective blobs.
Also adding present field in dmc_info.
s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
fw_info_matches_stepping() helper. CSR_PROGRAM() should now
take the starting address of the particular blob (Main or Pipe)
and not hardcode it.
v2: Add dmc_offset and start_mmioaddr fields for dmc_info struct.
v3: Add a missing corner cases of stepping-substepping combination in
fw_info_matches_stepping() helper.
v4: Add macro for start_mmioaddr for V1 package. Simplify code
in dmc_set_fw_offset (Lucas)
Cc: Souza, Jose
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
.../drm/i915/display/intel_display_debugfs.c | 4 +-
.../drm/i915/display/intel_display_power.c| 5 +-
drivers/gpu/drm/i915/display/intel_dmc.c | 131 ++
drivers/gpu/drm/i915/display/intel_dmc.h | 4 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
5 files changed, 85 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 88bb05d5c483..2a1c39a0e56e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "fw loaded: %s\n",
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
+ seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
+ seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
out:
seq_printf(m, "program base: 0x%08x\n",
- intel_de_read(dev_priv, DMC_PROGRAM(0)));
+ intel_de_read(dev_priv,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
seq_printf(m, "ssp base: 0x%08x\n",
intel_de_read(dev_priv, DMC_SSP_BASE));
seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv, DMC_HTP_SKL));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4298ae684d7d..285380079aab 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private
*dev_priv)
static void assert_dmc_loaded(struct drm_i915_private *dev_priv)
{
drm_WARN_ONCE(&dev_priv->drm,
- !intel_de_read(dev_priv, DMC_PROGRAM(0)),
- "DMC program storage start is NULL\n");
+ !intel_de_read(dev_priv,
+
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+"DMC program storage start is NULL\n");
drm_WARN_ONCE(&dev_priv->drm, !intel_de_read(dev_priv, DMC_SSP_BASE),
"DMC SSP Base Not fine\n");
drm_WARN_ONCE(&dev_priv->drm, !intel_de_read(dev_priv, DMC_HTP_SKL),
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 269a57d936ab..18e0d225a478 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -96,6 +96,7 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
#define DMC_V1_MAX_MMIO_COUNT 8
#define DMC_V3_MAX_MMIO_COUNT 20
+#define DMC_V1_MMIO_START_RANGE0x8
struct intel_css_header {
/* 0x09 for DMC */
@@ -317,8 +318,7 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = &dev_priv->dmc;
- struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
- u32 i, fw_size;
+ u32 id, i;
if (!HAS_DMC(dev_priv)) {
drm_err(&dev_priv->drm,
@@ -332,20 +332,25 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(&dev_priv->runtime_pm);
preempt_disable();
- for (i = 0; i < fw_size; i++)
- intel_uncore_write_fw(&dev_priv->uncore, DMC_PROGRAM(i),
- dmc_info->payload[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
+ intel_uncore_write_fw(&dev_priv->uncore,
+
[Intel-gfx] [PATCH 4/5] drm/i915/adl_p: Pipe B DMC Support
ADLP requires us to load both Pipe A and Pipe B.
Plug Pipe B loading support.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 ++
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2a1c39a0e56e..db38891a9ef0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -546,6 +546,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "path: %s\n", dmc->fw_path);
seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
+ seq_printf(m, "Pipe B fw support: %s\n",
yesno(IS_ALDERLAKE_P(dev_priv)));
+ seq_printf(m, "Pipe B fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 007a284b0ef0..c3c00ff03869 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -19,6 +19,7 @@ struct drm_i915_private;
enum {
DMC_FW_MAIN = 0,
DMC_FW_PIPEA,
+ DMC_FW_PIPEB,
DMC_FW_MAX
};
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/adl_p: Load DMC
Load DMC v2.10 on ADLP. The release notes mention that
this version enables few power savings features.
v2: Add DMC_PATH() for ADLP (Lucas)
Cc: Lucas De Marchi
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 18e0d225a478..f8789d4543bf 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -45,6 +45,10 @@
#define GEN12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
+#define ADLP_DMC_PATH DMC_PATH(adlp, 2, 10)
+#define ADLP_DMC_VERSION_REQUIRED DMC_VERSION(2, 10)
+MODULE_FIRMWARE(ADLP_DMC_PATH);
+
#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01)
#define ADLS_DMC_VERSION_REQUIRED DMC_VERSION(2, 1)
MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -724,7 +728,11 @@ void intel_dmc_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_dmc_runtime_pm_get(dev_priv);
- if (IS_ALDERLAKE_S(dev_priv)) {
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ dmc->fw_path = ADLP_DMC_PATH;
+ dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
+ dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
+ } else if (IS_ALDERLAKE_S(dev_priv)) {
dmc->fw_path = ADLS_DMC_PATH;
dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P
From: Gwan-gyeong Mun
Only ADL-P platform requires a temporal disabling of PSR for changing the
CDCLK PLL frequency with crawling. Changing the CDCLK PLL frequency on
prior platforms of ADL-P or changing the CDCLK PLL frequency without
crawling on ADL-P don't need to disable of PSR.
Bspec: 49207
Cc: Ville Syrjälä
Cc: Mika Kahola
Cc: Stanislav Lisovskiy
Cc: Anusha Srivatsa
Fixes: 17c1a4b7ac6f ("drm/i915: Disable PSR around cdclk change")
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 613ffcc68eba..6da426d26aac 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1962,10 +1962,18 @@ static void intel_set_cdclk(struct drm_i915_private
*dev_priv,
intel_dump_cdclk_config(cdclk_config, "Changing CDCLK to");
- for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ /*
+* Only ADL-P platform requires a temporal disabling of PSR for changing
+* the CDCLK PLL frequency with crawling.
+* Changing the CDCLK PLL frequency on prior platforms of ADL-P or
changing
+* the CDCLK PLL frequency without crawling on ADL-P don't need to
disable of PSR.
+*/
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- intel_psr_pause(intel_dp);
+ intel_psr_pause(intel_dp);
+ }
}
/*
@@ -1990,10 +1998,12 @@ static void intel_set_cdclk(struct drm_i915_private
*dev_priv,
}
mutex_unlock(&dev_priv->gmbus_mutex);
- for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- intel_psr_resume(intel_dp);
+ intel_psr_resume(intel_dp);
+ }
}
if (drm_WARN(&dev_priv->drm,
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 0/3] Explicity steer l3bank multicast reads when necessary
We've recently learned that when steering reads of multicast registers
that use 'subslice' replication, it's not only important to steer to a
subslice that isn't fused off, but also to steer to the lowest-numbered
subslice. This is because when Render Power Gating is enabled, grabbing
forcewake will only cause the hardware to power up a single subslice
(referred to as the "minconfig") until/unless a real workload is being
run on the EUs. If we try to read back a value from a register instance
other than the minconfig subslice, the read operation will either return
0 or random garbage.
Unfortunately this extra requirement to steer to the minconfig means
that the steering target we use for subslice-replicated registers may
not select a valid instance for l3bank-replicated registers. In cases
where the two types of multicast registers do not have compatible
steering targets, we'll initialize the steering control register to the
proper subslice target at driver load, and then explicitly re-steer
individual reads of l3bank registers as they occur at runtime.
This series sets up an infrastructure to handle explicit resteering of
multiple multicast register types, and then applies it to l3bank
registers. Our next upcoming platform (which we'll probably start
upstreaming soon) will bring several more types of multicast registers,
each with their own steering criteria, so the infrastructure here is
partially in preparation for those extra multicast types that will be
arriving soon.
v2:
- Use {} as table terminator and check for end==0 instead of 0xFF
on loop iteration. (Rodrigo)
- Use gt->uncore instead of gt->i915->uncore. (Tvrtko)
- Now that wa_list_verify() uses _fw accessors we need to explicitly
grab forcewake.
v2.1:
- Rebase
v3:
- The L3BANK fuse value is a disable mask rather than an enable mask.
We need to invert it before applying ffs() to select a valid
instance.
v4:
- The selected L3BANK ID goes in the subslice field of the steering
register, not the slice field.
v4.1:
- Rebase
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Tejas Upadhyay
Cc: Rodrigo Vivi
Daniele Ceraolo Spurio (1):
drm/i915: extract steered reg access to common function
Matt Roper (2):
drm/i915: Add GT support for multiple types of multicast steering
drm/i915: Add support for explicit L3BANK steering
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 41 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 102 +++
drivers/gpu/drm/i915/gt/intel_gt.h| 8 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 26
drivers/gpu/drm/i915/gt/intel_workarounds.c | 123 --
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 55
drivers/gpu/drm/i915/intel_uncore.h | 6 +
8 files changed, 251 insertions(+), 112 deletions(-)
--
2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: Add GT support for multiple types of multicast steering
Although most of our multicast registers are replicated per-subslice, we
also have a small number of multicast registers that are replicated
per-l3 bank instead. For both types of multicast registers we need to
make sure we steer reads of these registers to a valid instance.
Ideally we'd like to find a specific instance ID that would steer reads
of either type of multicast register to a valid instance (i.e., not
fused off and not powered down), but sometimes the combination of
part-specific fusing and the additional restrictions imposed by Render
Power Gating make it impossible to find any overlap between the set of
valid subslices and valid l3 banks. This problem will become even more
noticeable on our upcoming platforms since they will be adding
additional types of multicast registers with new types of replication
and rules for finding valid instances for reads.
To handle this we'll continue to pick a suitable subslice instance at
driver startup and program this as the default (sliceid,subsliceid)
setting in the steering control register (0xFDC). In cases where we
need to read another type of multicast GT register, but the default
subslice steering would not correspond to a valid instance, we'll
explicitly re-steer the single read to a valid value, perform the read,
and then reset the steering to it's "subslice" default.
This patch adds the general functionality to prepare for this explicit
steering of other multicast register types. We'll plug L3 bank steering
into this in the next patch, and then add additional types of multicast
registers when the support for our next upcoming platform arrives.
v2:
- Use entry->end==0 as table terminator. (Rodrigo)
- Grab forcewake in wa_list_verify() now that we're using accessors
that assume forcewake is already held.
v3:
- Fix loop condition when iterating over steering range tables.
(Rodrigo)
Cc: Rodrigo Vivi
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt.c| 84 +++
drivers/gpu/drm/i915/gt/intel_gt.h| 8 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 22 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 39 ++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
5 files changed, 142 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 67ef057ae918..1c7ca7a090ab 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -701,6 +701,90 @@ void intel_gt_driver_late_release(struct intel_gt *gt)
intel_engines_free(gt);
}
+/**
+ * intel_gt_reg_needs_read_steering - determine whether a register read
+ * requires explicit steering
+ * @gt: GT structure
+ * @reg: the register to check steering requirements for
+ * @type: type of multicast steering to check
+ *
+ * Determines whether @reg needs explicit steering of a specific type for
+ * reads.
+ *
+ * Returns false if @reg does not belong to a register range of the given
+ * steering type, or if the default (subslice-based) steering IDs are suitable
+ * for @type steering too.
+ */
+static bool intel_gt_reg_needs_read_steering(struct intel_gt *gt,
+i915_reg_t reg,
+enum intel_steering_type type)
+{
+ const u32 offset = i915_mmio_reg_offset(reg);
+ const struct intel_mmio_range *entry;
+
+ if (likely(!intel_gt_needs_read_steering(gt, type)))
+ return false;
+
+ for (entry = gt->steering_table[type]; entry->end; entry++) {
+ if (offset >= entry->start && offset <= entry->end)
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * intel_gt_get_valid_steering - determines valid IDs for a class of MCR
steering
+ * @gt: GT structure
+ * @type: multicast register type
+ * @sliceid: Slice ID returned
+ * @subsliceid: Subslice ID returned
+ *
+ * Determines sliceid and subsliceid values that will steer reads
+ * of a specific multicast register class to a valid value.
+ */
+static void intel_gt_get_valid_steering(struct intel_gt *gt,
+ enum intel_steering_type type,
+ u8 *sliceid, u8 *subsliceid)
+{
+ switch (type) {
+ default:
+ MISSING_CASE(type);
+ *sliceid = 0;
+ *subsliceid = 0;
+ }
+}
+
+/**
+ * intel_gt_read_register_fw - reads a GT register with support for multicast
+ * @gt: GT structure
+ * @reg: register to read
+ *
+ * This function will read a GT register. If the register is a multicast
+ * register, the read will be steered to a valid instance (i.e., one that
+ * isn't fused off or powered down by power gating).
+ *
+ * Returns the value from a valid instance of @reg.
+ */
+u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg)
+{
+ int type;
+ u8 slicei
[Intel-gfx] [CI 3/3] drm/i915: Add support for explicit L3BANK steering
Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register. In cases where it does not, use
explicit runtime steering whenever an L3BANK multicast register is read.
While we're at it, let's simplify the function a little bit and drop its
support for gen10/CNL since no such platforms ever materialized for real
use. Multicast register steering is already an area that causes enough
confusion; no need to complicate it with what's effectively dead code.
v2:
- Use gt->uncore instead of gt->i915->uncore. (Tvrtko)
- Use {} as table terminator. (Rodrigo)
v3:
- L3bank fuse register is a disable mask rather than an enable mask.
We need to invert it before use. (CI)
v4:
- L3bank ID goes in the subslice field, not the slice field. (CI)
Cc: Tvrtko Ursulin
Cc: Rodrigo Vivi
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt.c | 18 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 4 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 84 ++---
3 files changed, 46 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 1c7ca7a090ab..e714e21c0a4d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -84,6 +84,11 @@ void intel_gt_init_hw_early(struct intel_gt *gt, struct
i915_ggtt *ggtt)
gt->ggtt = ggtt;
}
+static const struct intel_mmio_range icl_l3bank_steering_table[] = {
+ { 0x00B100, 0x00B3FF },
+ {},
+};
+
int intel_gt_init_mmio(struct intel_gt *gt)
{
intel_gt_init_clock_frequency(gt);
@@ -91,6 +96,13 @@ int intel_gt_init_mmio(struct intel_gt *gt)
intel_uc_init_mmio(>->uc);
intel_sseu_info_init(gt);
+ if (GRAPHICS_VER(gt->i915) >= 11) {
+ gt->steering_table[L3BANK] = icl_l3bank_steering_table;
+ gt->info.l3bank_mask =
+ ~intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) &
+ GEN10_L3BANK_MASK;
+ }
+
return intel_engines_init_mmio(gt);
}
@@ -748,6 +760,12 @@ static void intel_gt_get_valid_steering(struct intel_gt
*gt,
u8 *sliceid, u8 *subsliceid)
{
switch (type) {
+ case L3BANK:
+ GEM_DEBUG_WARN_ON(!gt->info.l3bank_mask); /* should be
impossible! */
+
+ *sliceid = 0; /* unused */
+ *subsliceid = __ffs(gt->info.l3bank_mask);
+ break;
default:
MISSING_CASE(type);
*sliceid = 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index cabea1966b4e..d93d578a4105 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -49,6 +49,8 @@ struct intel_mmio_range {
* need to explicitly re-steer reads of registers of the other type.
*/
enum intel_steering_type {
+ L3BANK,
+
NUM_STEERING_TYPES
};
@@ -177,6 +179,8 @@ struct intel_gt {
/* Media engine access to SFC per instance */
u8 vdbox_sfc_access;
+ u32 l3bank_mask;
+
/* Slice/subslice/EU info */
struct sseu_dev_info sseu;
} info;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 93c74d4cae02..d9a5a445ceec 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -945,71 +945,37 @@ cfl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
}
static void
-wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
+icl_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
const struct sseu_dev_info *sseu = &i915->gt.info.sseu;
unsigned int slice, subslice;
- u32 l3_en, mcr, mcr_mask;
+ u32 mcr, mcr_mask;
- GEM_BUG_ON(GRAPHICS_VER(i915) < 10);
+ GEM_BUG_ON(GRAPHICS_VER(i915) < 11);
+ GEM_BUG_ON(hweight8(sseu->slice_mask) > 1);
+ slice = 0;
/*
-* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
-* L3Banks could be fused off in single slice scenario. If that is
-* the case, we might need to program MCR select to a valid L3Bank
-* by default, to make sure we correctly read certain registers
-* later on (in the range 0xB100 - 0xB3FF).
-*
-* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl
-* Before any MMIO read into slice/subslice specific registers, MCR
-* packet control register needs to be programmed to point to any
-* enabled s/ss pair. Otherwise, incorrect values will be returned.
-* Th
[Intel-gfx] [CI 1/3] drm/i915: extract steered reg access to common function
From: Daniele Ceraolo Spurio
New steering cases will be added in the follow-up patches, so prepare a
common helper to avoid code duplication.
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 41 +
drivers/gpu/drm/i915/intel_uncore.c | 55 +++
drivers/gpu/drm/i915/intel_uncore.h | 6 +++
3 files changed, 63 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index fcbaad18ac91..04c1f5b9ce71 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1112,45 +1112,8 @@ static u32
read_subslice_reg(const struct intel_engine_cs *engine,
int slice, int subslice, i915_reg_t reg)
{
- struct drm_i915_private *i915 = engine->i915;
- struct intel_uncore *uncore = engine->uncore;
- u32 mcr_mask, mcr_ss, mcr, old_mcr, val;
- enum forcewake_domains fw_domains;
-
- if (GRAPHICS_VER(i915) >= 11) {
- mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
- mcr_ss = GEN11_MCR_SLICE(slice) | GEN11_MCR_SUBSLICE(subslice);
- } else {
- mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
- mcr_ss = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
- }
-
- fw_domains = intel_uncore_forcewake_for_reg(uncore, reg,
- FW_REG_READ);
- fw_domains |= intel_uncore_forcewake_for_reg(uncore,
-GEN8_MCR_SELECTOR,
-FW_REG_READ |
FW_REG_WRITE);
-
- spin_lock_irq(&uncore->lock);
- intel_uncore_forcewake_get__locked(uncore, fw_domains);
-
- old_mcr = mcr = intel_uncore_read_fw(uncore, GEN8_MCR_SELECTOR);
-
- mcr &= ~mcr_mask;
- mcr |= mcr_ss;
- intel_uncore_write_fw(uncore, GEN8_MCR_SELECTOR, mcr);
-
- val = intel_uncore_read_fw(uncore, reg);
-
- mcr &= ~mcr_mask;
- mcr |= old_mcr & mcr_mask;
-
- intel_uncore_write_fw(uncore, GEN8_MCR_SELECTOR, mcr);
-
- intel_uncore_forcewake_put__locked(uncore, fw_domains);
- spin_unlock_irq(&uncore->lock);
-
- return val;
+ return intel_uncore_read_with_mcr_steering(engine->uncore, reg,
+ slice, subslice);
}
/* NB: please notice the memset */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 1bed8f666048..d067524f9162 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2277,6 +2277,61 @@ intel_uncore_forcewake_for_reg(struct intel_uncore
*uncore,
return fw_domains;
}
+u32 intel_uncore_read_with_mcr_steering_fw(struct intel_uncore *uncore,
+ i915_reg_t reg,
+ int slice, int subslice)
+{
+ u32 mcr_mask, mcr_ss, mcr, old_mcr, val;
+
+ lockdep_assert_held(&uncore->lock);
+
+ if (GRAPHICS_VER(uncore->i915) >= 11) {
+ mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
+ mcr_ss = GEN11_MCR_SLICE(slice) | GEN11_MCR_SUBSLICE(subslice);
+ } else {
+ mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
+ mcr_ss = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+ }
+
+ old_mcr = mcr = intel_uncore_read_fw(uncore, GEN8_MCR_SELECTOR);
+
+ mcr &= ~mcr_mask;
+ mcr |= mcr_ss;
+ intel_uncore_write_fw(uncore, GEN8_MCR_SELECTOR, mcr);
+
+ val = intel_uncore_read_fw(uncore, reg);
+
+ mcr &= ~mcr_mask;
+ mcr |= old_mcr & mcr_mask;
+
+ intel_uncore_write_fw(uncore, GEN8_MCR_SELECTOR, mcr);
+
+ return val;
+}
+
+u32 intel_uncore_read_with_mcr_steering(struct intel_uncore *uncore,
+ i915_reg_t reg, int slice, int subslice)
+{
+ enum forcewake_domains fw_domains;
+ u32 val;
+
+ fw_domains = intel_uncore_forcewake_for_reg(uncore, reg,
+ FW_REG_READ);
+ fw_domains |= intel_uncore_forcewake_for_reg(uncore,
+GEN8_MCR_SELECTOR,
+FW_REG_READ |
FW_REG_WRITE);
+
+ spin_lock_irq(&uncore->lock);
+ intel_uncore_forcewake_get__locked(uncore, fw_domains);
+
+ val = intel_uncore_read_with_mcr_steering_fw(uncore, reg, slice,
subslice);
+
+ intel_uncore_forcewake_put__locked(uncore, fw_domains);
+ spin_unlock_irq(&uncore->lock);
+
+ return val;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_uncore.c"
#include "selftests/intel_unc
Re: [Intel-gfx] [PATCH 1/5] drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P
On Thu, 2021-06-17 at 14:12 -0700, Anusha Srivatsa wrote:
> From: Gwan-gyeong Mun
>
> Only ADL-P platform requires a temporal disabling of PSR for changing the
> CDCLK PLL frequency with crawling. Changing the CDCLK PLL frequency on
> prior platforms of ADL-P or changing the CDCLK PLL frequency without
> crawling on ADL-P don't need to disable of PSR.
This is only hiding a possible bug found in ICL under the IS_ALDERLAKE_P()
check.
There is no reason to not pause PSR in older platforms during cdclck changes.
>
> Bspec: 49207
>
> Cc: Ville Syrjälä
> Cc: Mika Kahola
> Cc: Stanislav Lisovskiy
> Cc: Anusha Srivatsa
> Fixes: 17c1a4b7ac6f ("drm/i915: Disable PSR around cdclk change")
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 22 --
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 613ffcc68eba..6da426d26aac 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1962,10 +1962,18 @@ static void intel_set_cdclk(struct drm_i915_private
> *dev_priv,
>
> intel_dump_cdclk_config(cdclk_config, "Changing CDCLK to");
>
> - for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + /*
> + * Only ADL-P platform requires a temporal disabling of PSR for changing
> + * the CDCLK PLL frequency with crawling.
> + * Changing the CDCLK PLL frequency on prior platforms of ADL-P or
> changing
> + * the CDCLK PLL frequency without crawling on ADL-P don't need to
> disable of PSR.
> + */
> + if (IS_ALDERLAKE_P(dev_priv)) {
> + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> - intel_psr_pause(intel_dp);
> + intel_psr_pause(intel_dp);
> + }
> }
>
> /*
> @@ -1990,10 +1998,12 @@ static void intel_set_cdclk(struct drm_i915_private
> *dev_priv,
> }
> mutex_unlock(&dev_priv->gmbus_mutex);
>
> - for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + if (IS_ALDERLAKE_P(dev_priv)) {
> + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> - intel_psr_resume(intel_dp);
> + intel_psr_resume(intel_dp);
> + }
> }
>
> if (drm_WARN(&dev_priv->drm,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P
> -Original Message-
> From: Souza, Jose
> Sent: Thursday, June 17, 2021 2:18 PM
> To: Mun, Gwan-gyeong ; Srivatsa, Anusha
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/display: Limit disabling PSR
> around cdclk changes to ADL-P
>
> On Thu, 2021-06-17 at 14:12 -0700, Anusha Srivatsa wrote:
> > From: Gwan-gyeong Mun
> >
> > Only ADL-P platform requires a temporal disabling of PSR for changing
> > the CDCLK PLL frequency with crawling. Changing the CDCLK PLL
> > frequency on prior platforms of ADL-P or changing the CDCLK PLL
> > frequency without crawling on ADL-P don't need to disable of PSR.
>
> This is only hiding a possible bug found in ICL under the IS_ALDERLAKE_P()
> check.
> There is no reason to not pause PSR in older platforms during cdclck changes.
According to 15729, pausing PSR during cdclk changes is not valid.
Anusha
> >
> > Bspec: 49207
> >
> > Cc: Ville Syrjälä
> > Cc: Mika Kahola
> > Cc: Stanislav Lisovskiy
> > Cc: Anusha Srivatsa
> > Fixes: 17c1a4b7ac6f ("drm/i915: Disable PSR around cdclk change")
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 22
> > --
> > 1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 613ffcc68eba..6da426d26aac 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1962,10 +1962,18 @@ static void intel_set_cdclk(struct
> > drm_i915_private *dev_priv,
> >
> > intel_dump_cdclk_config(cdclk_config, "Changing CDCLK to");
> >
> > - for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + /*
> > +* Only ADL-P platform requires a temporal disabling of PSR for
> changing
> > +* the CDCLK PLL frequency with crawling.
> > +* Changing the CDCLK PLL frequency on prior platforms of ADL-P or
> changing
> > +* the CDCLK PLL frequency without crawling on ADL-P don't need to
> disable of PSR.
> > +*/
> > + if (IS_ALDERLAKE_P(dev_priv)) {
> > + for_each_intel_encoder_with_psr(&dev_priv->drm,
> encoder) {
> > + struct intel_dp *intel_dp =
> enc_to_intel_dp(encoder);
> >
> > - intel_psr_pause(intel_dp);
> > + intel_psr_pause(intel_dp);
> > + }
> > }
> >
> > /*
> > @@ -1990,10 +1998,12 @@ static void intel_set_cdclk(struct
> drm_i915_private *dev_priv,
> > }
> > mutex_unlock(&dev_priv->gmbus_mutex);
> >
> > - for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + if (IS_ALDERLAKE_P(dev_priv)) {
> > + for_each_intel_encoder_with_psr(&dev_priv->drm,
> encoder) {
> > + struct intel_dp *intel_dp =
> enc_to_intel_dp(encoder);
> >
> > - intel_psr_resume(intel_dp);
> > + intel_psr_resume(intel_dp);
> > + }
> > }
> >
> > if (drm_WARN(&dev_priv->drm,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P
On Thu, 2021-06-17 at 14:26 -0700, Srivatsa, Anusha wrote:
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Thursday, June 17, 2021 2:18 PM
> > To: Mun, Gwan-gyeong ; Srivatsa, Anusha
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/display: Limit disabling PSR
> > around cdclk changes to ADL-P
> >
> > On Thu, 2021-06-17 at 14:12 -0700, Anusha Srivatsa wrote:
> > > From: Gwan-gyeong Mun
> > >
> > > Only ADL-P platform requires a temporal disabling of PSR for changing
> > > the CDCLK PLL frequency with crawling. Changing the CDCLK PLL
> > > frequency on prior platforms of ADL-P or changing the CDCLK PLL
> > > frequency without crawling on ADL-P don't need to disable of PSR.
> >
> > This is only hiding a possible bug found in ICL under the IS_ALDERLAKE_P()
> > check.
> > There is no reason to not pause PSR in older platforms during cdclck
> > changes.
>
> According to 15729, pausing PSR during cdclk changes is not valid.
The bspec tag is not valid, it do not means the sequence is not valid for GEN9
and GEN11 platforms.
>
> Anusha
> > >
> > > Bspec: 49207
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Mika Kahola
> > > Cc: Stanislav Lisovskiy
> > > Cc: Anusha Srivatsa
> > > Fixes: 17c1a4b7ac6f ("drm/i915: Disable PSR around cdclk change")
> > > Signed-off-by: Gwan-gyeong Mun
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 22
> > > --
> > > 1 file changed, 16 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 613ffcc68eba..6da426d26aac 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1962,10 +1962,18 @@ static void intel_set_cdclk(struct
> > > drm_i915_private *dev_priv,
> > >
> > > intel_dump_cdclk_config(cdclk_config, "Changing CDCLK to");
> > >
> > > - for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > + /*
> > > + * Only ADL-P platform requires a temporal disabling of PSR for
> > changing
> > > + * the CDCLK PLL frequency with crawling.
> > > + * Changing the CDCLK PLL frequency on prior platforms of ADL-P or
> > changing
> > > + * the CDCLK PLL frequency without crawling on ADL-P don't need to
> > disable of PSR.
> > > + */
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm,
> > encoder) {
> > > + struct intel_dp *intel_dp =
> > enc_to_intel_dp(encoder);
> > >
> > > - intel_psr_pause(intel_dp);
> > > + intel_psr_pause(intel_dp);
> > > + }
> > > }
> > >
> > > /*
> > > @@ -1990,10 +1998,12 @@ static void intel_set_cdclk(struct
> > drm_i915_private *dev_priv,
> > > }
> > > mutex_unlock(&dev_priv->gmbus_mutex);
> > >
> > > - for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm,
> > encoder) {
> > > + struct intel_dp *intel_dp =
> > enc_to_intel_dp(encoder);
> > >
> > > - intel_psr_resume(intel_dp);
> > > + intel_psr_resume(intel_dp);
> > > + }
> > > }
> > >
> > > if (drm_WARN(&dev_priv->drm,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/display: Do not zero past infoframes.vsc
intel_dp_vsc_sdp_unpack() was using a memset() size (36, struct dp_sdp)
larger than the destination (24, struct drm_dp_vsc_sdp), clobbering
fields in struct intel_crtc_state after infoframes.vsc. Use the actual
target size for the memset().
Fixes: 1b404b7dbb10 ("drm/i915/dp: Read out DP SDPs")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..6cc03b9e4321 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2868,7 +2868,7 @@ static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp
*vsc,
if (size < sizeof(struct dp_sdp))
return -EINVAL;
- memset(vsc, 0, size);
+ memset(vsc, 0, sizeof(*vsc));
if (sdp->sdp_header.HB0 != 0)
return -EINVAL;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Do not zero past infoframes.vsc
On Thu, 2021-06-17 at 14:33 -0700, Kees Cook wrote:
> intel_dp_vsc_sdp_unpack() was using a memset() size (36, struct dp_sdp)
> larger than the destination (24, struct drm_dp_vsc_sdp), clobbering
> fields in struct intel_crtc_state after infoframes.vsc. Use the actual
> target size for the memset().
Reviewed-by: José Roberto de Souza
>
> Fixes: 1b404b7dbb10 ("drm/i915/dp: Read out DP SDPs")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5c983044..6cc03b9e4321 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2868,7 +2868,7 @@ static int intel_dp_vsc_sdp_unpack(struct
> drm_dp_vsc_sdp *vsc,
> if (size < sizeof(struct dp_sdp))
> return -EINVAL;
>
> - memset(vsc, 0, size);
> + memset(vsc, 0, sizeof(*vsc));
>
> if (sdp->sdp_header.HB0 != 0)
> return -EINVAL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Pipe DMC bits + PSR fix
== Series Details == Series: Pipe DMC bits + PSR fix URL : https://patchwork.freedesktop.org/series/91647/ State : warning == Summary == $ dim checkpatch origin/drm-tip 30ae65475a6b drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P ef0c0ea027d1 drm/i915/dmc: Introduce DMC_FW_MAIN 16750b8e4d02 drm/i915/xelpd: Pipe A DMC plugging -:49: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #49: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:587: + intel_de_read(dev_priv, DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0))); -:64: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #64: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:965: + DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)), total: 0 errors, 2 warnings, 0 checks, 287 lines checked 48f0bb960725 drm/i915/adl_p: Pipe B DMC Support b9dae32d79f5 drm/i915/adl_p: Load DMC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Pipe DMC bits + PSR fix
== Series Details == Series: Pipe DMC bits + PSR fix URL : https://patchwork.freedesktop.org/series/91647/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/i915_gem_ttm.c:675:38: warning: symbol 'i915_gem_ttm_obj_ops' was not declared. Should it be static? +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/li
[Intel-gfx] ✓ Fi.CI.BAT: success for Pipe DMC bits + PSR fix
== Series Details == Series: Pipe DMC bits + PSR fix URL : https://patchwork.freedesktop.org/series/91647/ State : success == Summary == CI Bug Log - changes from CI_DRM_10239 -> Patchwork_20403 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/index.html Known issues Here are the changes found in Patchwork_20403 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][2] -> [INCOMPLETE][3] ([i915#2782]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][4] ([i915#2782] / [i915#2940]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 Participating hosts (42 -> 36) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10239 -> Patchwork_20403 CI-20190529: 20190529 CI_DRM_10239: 2e8f52ca20126a06cb95ae49a772792606ffc719 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6112: a17cc0c5d096fabfd516848c114bc411e11130f4 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20403: b9dae32d79f5eae6d4aeb930cde7d7f26e28b4ac @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b9dae32d79f5 drm/i915/adl_p: Load DMC 48f0bb960725 drm/i915/adl_p: Pipe B DMC Support 16750b8e4d02 drm/i915/xelpd: Pipe A DMC plugging ef0c0ea027d1 drm/i915/dmc: Introduce DMC_FW_MAIN 30ae65475a6b drm/i915/display: Limit disabling PSR around cdclk changes to ADL-P == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Explicity steer l3bank multicast reads when necessary (rev7)
== Series Details == Series: Explicity steer l3bank multicast reads when necessary (rev7) URL : https://patchwork.freedesktop.org/series/91485/ State : warning == Summary == $ dim checkpatch origin/drm-tip 796eee9fb582 drm/i915: extract steered reg access to common function -:90: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #90: FILE: drivers/gpu/drm/i915/intel_uncore.c:2296: + old_mcr = mcr = intel_uncore_read_fw(uncore, GEN8_MCR_SELECTOR); total: 0 errors, 0 warnings, 1 checks, 120 lines checked 9699e7d507a4 drm/i915: Add GT support for multiple types of multicast steering dd849d5d39e7 drm/i915: Add support for explicit L3BANK steering ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Explicity steer l3bank multicast reads when necessary (rev7)
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev7)
URL : https://patchwork.freedesktop.org/series/91485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10239 -> Patchwork_20404
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20404:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_engines:
- {fi-ehl-2}: [DMESG-FAIL][1] ([i915#1222]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
- {fi-jsl-1}: [DMESG-FAIL][3] ([i915#1222]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-jsl-1/igt@i915_selftest@live@gt_engines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-jsl-1/igt@i915_selftest@live@gt_engines.html
Known issues
Here are the changes found in Patchwork_20404 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka: NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][7] ([i915#1602] / [i915#2029])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [INCOMPLETE][8] ([i915#2782] / [i915#2940]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_lrc:
- {fi-jsl-1}: [DMESG-WARN][10] ([i915#1222]) -> [PASS][11] +37
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-jsl-1/igt@i915_selftest@live@gt_lrc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-jsl-1/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@migrate:
- {fi-ehl-2}: [DMESG-WARN][12] ([i915#1222]) -> [PASS][13] +37
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-ehl-2/igt@i915_selftest@l...@migrate.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/fi-ehl-2/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
Participating hosts (42 -> 37)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10239 -> Patchwork_20404
CI-20190529: 20190529
CI_DRM_10239: 2e8f52ca20126a06cb95ae49a772792606ffc719 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6112: a17cc0c5d096fabfd516848c114bc411e11130f4 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20404: dd849d5d39e7cd06405d3ac4cbab221cdde7d0bc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dd849d5d39e7 drm/i915: Add support for explicit L3BANK steering
9699e7d507a4 drm/i915: Add GT support for multiple types of multicast steering
796eee9fb582 drm/i915: extract steered reg access to common function
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Do not zero past infoframes.vsc
== Series Details == Series: drm/i915/display: Do not zero past infoframes.vsc URL : https://patchwork.freedesktop.org/series/91650/ State : success == Summary == CI Bug Log - changes from CI_DRM_10239 -> Patchwork_20405 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/index.html Known issues Here are the changes found in Patchwork_20405 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#2782]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][5] ([i915#2782] / [i915#2940]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 Participating hosts (42 -> 37) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10239 -> Patchwork_20405 CI-20190529: 20190529 CI_DRM_10239: 2e8f52ca20126a06cb95ae49a772792606ffc719 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6112: a17cc0c5d096fabfd516848c114bc411e11130f4 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20405: ee6afe14b6ac3e6b4fd7824e2d7f53b490a0193a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ee6afe14b6ac drm/i915/display: Do not zero past infoframes.vsc == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Pipe DMC bits + PSR fix
== Series Details == Series: Pipe DMC bits + PSR fix URL : https://patchwork.freedesktop.org/series/91647/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10239_full -> Patchwork_20403_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20403_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20403_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_20403_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][1] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-apl2/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-iclb3/igt@i915_pm...@dc6-psr.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-iclb2/igt@i915_pm...@dc6-psr.html Known issues Here are the changes found in Patchwork_20403_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-apl3/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-snb2/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842] / [i915#3468]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-glk9/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-iclb8/igt@gem_exec_par...@secure-non-root.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-kbl3/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk2/igt@gem_mmap_...@big-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-glk9/igt@gem_mmap_...@big-copy-odd.html * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#768]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-iclb8/igt@gem_render_c...@yf-tiled-to-vebox-yf-tiled.html * igt@gem_vm_create@destroy-race: - shard-tglb: NOTRUN -> [TIMEOUT][18] ([i915#2795]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-tglb7/igt@gem_vm_cre...@destroy-race.html * igt@gen7_exec_parse@oacontrol-tracking: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20403/shard-tglb7/igt@gen7_exec_pa...@oacontrol-tracking.html * igt@i915_module_load@reload: - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-skl7/igt@i915_module_l...@reload.html [21]: https://intel-gfx-ci.0
[Intel-gfx] ✗ Fi.CI.IGT: failure for Explicity steer l3bank multicast reads when necessary (rev7)
== Series Details == Series: Explicity steer l3bank multicast reads when necessary (rev7) URL : https://patchwork.freedesktop.org/series/91485/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10239_full -> Patchwork_20404_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20404_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20404_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_20404_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][1] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-apl2/igt@gem_exec_reloc@basic-wide-act...@bcs0.html Known issues Here are the changes found in Patchwork_20404_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-apl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-snb2/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842] / [i915#3468]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][11] -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-iclb1/igt@gem_exec_par...@secure-non-root.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-kbl2/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-skl3/igt@gem_mmap_...@big-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-skl1/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#307]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk1/igt@gem_mmap_...@cpuset-basic-small-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-glk5/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#307] / [i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-glk1/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#307]) [21]: https://intel-gfx-ci.01.org/
[Intel-gfx] [PATCH 2/8] drm/i915: Add i915_sched_engine_is_empty function
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
drivers/gpu/drm/i915/i915_scheduler.h| 6 ++
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4772ed1a1f3a..aeaf5c6f94b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1296,7 +1296,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
intel_engine_flush_submission(engine);
/* ELSP is empty, but there are ready requests? E.g. after reset */
- if (!RB_EMPTY_ROOT(&engine->sched_engine->queue.rb_root))
+ if (!i915_sched_engine_is_empty(engine->sched_engine))
return false;
/* Ring stopped? */
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4f759559a792..e36b0e81876a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -384,7 +384,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
prio = rq_prio(rq);
pl = i915_sched_lookup_priolist(engine, prio);
}
- GEM_BUG_ON(RB_EMPTY_ROOT(&engine->sched_engine->queue.rb_root));
+ GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
list_move(&rq->sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
@@ -1139,7 +1139,7 @@ static bool needs_timeslice(const struct intel_engine_cs
*engine,
}
/* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
- if (!RB_EMPTY_ROOT(&engine->sched_engine->queue.rb_root)) {
+ if (!i915_sched_engine_is_empty(engine->sched_engine)) {
ENGINE_TRACE(engine, "timeslice required for queue\n");
return true;
}
@@ -2487,7 +2487,7 @@ static void execlists_submit_request(struct i915_request
*request)
} else {
queue_request(engine, request);
- GEM_BUG_ON(RB_EMPTY_ROOT(&engine->sched_engine->queue.rb_root));
+ GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
GEM_BUG_ON(list_empty(&request->sched.link));
if (submit_queue(engine, request))
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 5c5f33f40055..d65a7665b38e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -515,7 +515,7 @@ static void guc_submit_request(struct i915_request *rq)
queue_request(engine, rq, rq_prio(rq));
- GEM_BUG_ON(RB_EMPTY_ROOT(&engine->sched_engine->queue.rb_root));
+ GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
GEM_BUG_ON(list_empty(&rq->sched.link));
tasklet_hi_schedule(&engine->execlists.tasklet);
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 91a04e34cac5..5bec7b3b8456 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -66,6 +66,12 @@ i915_sched_engine_put(struct i915_sched_engine *sched_engine)
kref_put(&sched_engine->ref, i915_sched_engine_free);
}
+static inline bool
+i915_sched_engine_is_empty(struct i915_sched_engine *sched_engine)
+{
+ return RB_EMPTY_ROOT(&sched_engine->queue.rb_root);
+}
+
void i915_request_show_with_schedule(struct drm_printer *m,
const struct i915_request *rq,
const char *prefix,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] Introduce i915_sched_engine object
As discussed in [1] we are breaking that large series into a several smaller ones. This series is stand alone patch part of step #4 which has no other dependencies or patches relevant to it. v2: (Daniel Vetter): - Split into several smaller patches - Add kernel doc for i915_sched_engine (Matthew Brost): - Drop wrapper functions for tasklet as eventually tasklet will be dropped v3: (Jason Ekstrand) - Address his comments, change logs in individual patches - Squash documentation patch into previous patches as needed (Checkpatch) - Fix warnings (Docs) - Fix warnings v4: (Daniele) - Update a comments / commit messages - Set queue_priority_hint v5: (CI) - Rebase and fix build error v6: - Rebase Signed-off-by: Matthew Brost [1] https://patchwork.freedesktop.org/series/89844/ Matthew Brost (8): drm/i915: Move priolist to new i915_sched_engine object drm/i915: Add i915_sched_engine_is_empty function drm/i915: Reset sched_engine.no_priolist immediately after dequeue drm/i915: Move active tracking to i915_sched_engine drm/i915: Move engine->schedule to i915_sched_engine drm/i915: Add kick_backend function to i915_sched_engine drm/i915: Update i915_scheduler to operate on i915_sched_engine drm/i915: Move submission tasklet to i915_sched_engine Documentation/gpu/i915.rst| 5 + drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine.h| 16 - drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 49 +-- drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- .../drm/i915/gt/intel_execlists_submission.c | 325 +++--- .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +- drivers/gpu/drm/i915/gt/mock_engine.c | 17 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 34 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 70 ++-- drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- drivers/gpu/drm/i915/i915_request.c | 42 +-- drivers/gpu/drm/i915/i915_request.h | 2 +- drivers/gpu/drm/i915/i915_scheduler.c | 168 + drivers/gpu/drm/i915/i915_scheduler.h | 47 ++- drivers/gpu/drm/i915/i915_scheduler_types.h | 89 + 22 files changed, 556 insertions(+), 424 deletions(-) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915: Update i915_scheduler to operate on i915_sched_engine
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 46 +--
drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
4 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9487d9e0be62..ffad4d98cec0 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -382,7 +382,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
if (rq_prio(rq) != prio) {
prio = rq_prio(rq);
- pl = i915_sched_lookup_priolist(engine, prio);
+ pl = i915_sched_lookup_priolist(engine->sched_engine,
+ prio);
}
GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
@@ -1096,7 +1097,8 @@ static void defer_active(struct intel_engine_cs *engine)
if (!rq)
return;
- defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
+ defer_request(rq, i915_sched_lookup_priolist(engine->sched_engine,
+rq_prio(rq)));
}
static bool
@@ -2083,7 +2085,7 @@ static void __execlists_unhold(struct i915_request *rq)
i915_request_clear_hold(rq);
list_move_tail(&rq->sched.link,
- i915_sched_lookup_priolist(rq->engine,
+
i915_sched_lookup_priolist(rq->engine->sched_engine,
rq_prio(rq)));
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
@@ -2452,7 +2454,8 @@ static void queue_request(struct intel_engine_cs *engine,
{
GEM_BUG_ON(!list_empty(&rq->sched.link));
list_add_tail(&rq->sched.link,
- i915_sched_lookup_priolist(engine, rq_prio(rq)));
+ i915_sched_lookup_priolist(engine->sched_engine,
+rq_prio(rq)));
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
}
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 60121809e6e2..cb13cc586c67 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -503,7 +503,7 @@ static inline void queue_request(struct intel_engine_cs
*engine,
{
GEM_BUG_ON(!list_empty(&rq->sched.link));
list_add_tail(&rq->sched.link,
- i915_sched_lookup_priolist(engine, prio));
+ i915_sched_lookup_priolist(engine->sched_engine, prio));
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 035b88f2e4aa..fa8863df9513 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -61,14 +61,13 @@ static void assert_priolists(struct i915_sched_engine *
const sched_engine)
}
struct list_head *
-i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
+i915_sched_lookup_priolist(struct i915_sched_engine *sched_engine, int prio)
{
- struct i915_sched_engine * const sched_engine = engine->sched_engine;
struct i915_priolist *p;
struct rb_node **parent, *rb;
bool first = true;
- lockdep_assert_held(&engine->sched_engine->lock);
+ lockdep_assert_held(&sched_engine->lock);
assert_priolists(sched_engine);
if (unlikely(sched_engine->no_priolist))
@@ -130,13 +129,13 @@ struct sched_cache {
struct list_head *priolist;
};
-static struct intel_engine_cs *
-sched_lock_engine(const struct i915_sched_node *node,
- struct intel_engine_cs *locked,
+static struct i915_sched_engine *
+lock_sched_engine(struct i915_sched_node *node,
+ struct i915_sched_engine *locked,
struct sched_cache *cache)
{
const struct i915_request *rq = node_to_request(node);
- struct intel_engine_cs *engine;
+ struct i915_sched_engine *sched_engine;
GEM_BUG_ON(!locked);
@@ -146,14 +145,14 @@ sched_lock_engine(const struct i915_sched_node *node,
* engine lock. The simple ploy we use is to take the lock then
* check that the rq still belongs to the newly locked engine.
*/
- while (locked !=
[Intel-gfx] [PATCH 4/8] drm/i915: Move active tracking to i915_sched_engine
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
v6:
Rebase
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 --
.../drm/i915/gt/intel_execlists_submission.c | 98 ++-
.../gpu/drm/i915/gt/intel_ring_submission.c | 12 +--
drivers/gpu/drm/i915/gt/mock_engine.c | 7 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_request.c | 32 +++---
drivers/gpu/drm/i915/i915_request.h | 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 30 --
drivers/gpu/drm/i915/i915_scheduler_types.h | 16 +++
13 files changed, 140 insertions(+), 136 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 62f7440bc111..45ee08fc40a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -269,8 +269,6 @@ intel_engine_create_pinned_context(struct intel_engine_cs
*engine,
void intel_engine_destroy_pinned_context(struct intel_context *ce);
-void intel_engine_init_active(struct intel_engine_cs *engine,
- unsigned int subclass);
#define ENGINE_PHYSICAL0
#define ENGINE_MOCK1
#define ENGINE_VIRTUAL 2
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index aeaf5c6f94b2..b7efc4e399c5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -721,7 +721,6 @@ static int engine_setup_common(struct intel_engine_cs
*engine)
if (err)
goto err_cmd_parser;
- intel_engine_init_active(engine, ENGINE_PHYSICAL);
intel_engine_init_execlists(engine);
intel_engine_init__pm(engine);
intel_engine_init_retire(engine);
@@ -780,11 +779,11 @@ static int measure_breadcrumb_dw(struct intel_context *ce)
frame->rq.ring = &frame->ring;
mutex_lock(&ce->timeline->mutex);
- spin_lock_irq(&engine->active.lock);
+ spin_lock_irq(&engine->sched_engine->lock);
dw = engine->emit_fini_breadcrumb(&frame->rq, frame->cs) - frame->cs;
- spin_unlock_irq(&engine->active.lock);
+ spin_unlock_irq(&engine->sched_engine->lock);
mutex_unlock(&ce->timeline->mutex);
GEM_BUG_ON(dw & 1); /* RING_TAIL must be qword aligned */
@@ -793,28 +792,6 @@ static int measure_breadcrumb_dw(struct intel_context *ce)
return dw;
}
-void
-intel_engine_init_active(struct intel_engine_cs *engine, unsigned int subclass)
-{
- INIT_LIST_HEAD(&engine->active.requests);
- INIT_LIST_HEAD(&engine->active.hold);
-
- spin_lock_init(&engine->active.lock);
- lockdep_set_subclass(&engine->active.lock, subclass);
-
- /*
-* Due to an interesting quirk in lockdep's internal debug tracking,
-* after setting a subclass we must ensure the lock is used. Otherwise,
-* nr_unused_locks is incremented once too often.
-*/
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- local_irq_disable();
- lock_map_acquire(&engine->active.lock.dep_map);
- lock_map_release(&engine->active.lock.dep_map);
- local_irq_enable();
-#endif
-}
-
struct intel_context *
intel_engine_create_pinned_context(struct intel_engine_cs *engine,
struct i915_address_space *vm,
@@ -969,7 +946,7 @@ int intel_engines_init(struct intel_gt *gt)
*/
void intel_engine_cleanup_common(struct intel_engine_cs *engine)
{
- GEM_BUG_ON(!list_empty(&engine->active.requests));
+ GEM_BUG_ON(!list_empty(&engine->sched_engine->requests));
tasklet_kill(&engine->execlists.tasklet); /* flush the callback */
i915_sched_engine_put(engine->sched_engine);
@@ -1362,7 +1339,7 @@ static struct intel_timeline *get_timeline(struct
i915_request *rq)
struct intel_timeline *tl;
/*
-* Even though we are holding the engine->active.lock here, there
+* Even though we are holding the engine->sched_engine->lock here, there
* is no control over the submission queue per-se and we are
* inspecting the active state at a random point in time, with an
* unknown queue. Play safe and make sure the timeline remains valid.
@@ -1709,7 +1686,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tRequests:\n");
- spin_lock_irqsave(&engine->active.lock, flags);
+ spin_lock_irqsave(&engine->sched_engine->lock, flags);
rq = intel_engine_find_active_requ
[Intel-gfx] [PATCH 1/8] drm/i915: Move priolist to new i915_sched_engine object
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering. Currently the execlists
backend uses 1 of these object per each engine (physical or virtual) but
future backends like the GuC will point to less instances utilizing the
reference counting.
This is a bit of detour to integrating the i915 with the DRM scheduler
but this object will still exist when the DRM scheduler lands in the
i915. It will however look a bit different. It will encapsulate the
drm_gpu_scheduler object plus and common variables (to the backends)
related to scheduling. Regardless this is a step in the right direction.
This patch starts the aforementioned transition by moving the priolist
into the i915_sched_engine object.
v3:
(Jason Ekstrand)
Update comment next to intel_engine_cs.virtual
Add kernel doc
(Checkpatch)
Fix double the in commit message
v4:
(Daniele)
Update comment message.
Add comment about subclass field
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
Documentation/gpu/i915.rst| 5 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 32 ++--
.../drm/i915/gt/intel_execlists_submission.c | 81 +++
drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
drivers/gpu/drm/i915/i915_scheduler.c | 53 +---
drivers/gpu/drm/i915/i915_scheduler.h | 18 +
drivers/gpu/drm/i915/i915_scheduler_types.h | 47 +++
10 files changed, 192 insertions(+), 90 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..1d5ce5676d35 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -425,6 +425,11 @@ User Batchbuffer Execution
.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
:doc: User command execution
+Scheduling
+--
+.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h
+ :functions: i915_sched_engine
+
Logical Rings, Logical Ring Contexts and Execlists
--
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index fcbaad18ac91..4772ed1a1f3a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -585,9 +585,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
*engine)
memset(execlists->pending, 0, sizeof(execlists->pending));
execlists->active =
memset(execlists->inflight, 0, sizeof(execlists->inflight));
-
- execlists->queue_priority_hint = INT_MIN;
- execlists->queue = RB_ROOT_CACHED;
}
static void cleanup_status_page(struct intel_engine_cs *engine)
@@ -714,6 +711,12 @@ static int engine_setup_common(struct intel_engine_cs
*engine)
goto err_status;
}
+ engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
+ if (!engine->sched_engine) {
+ err = -ENOMEM;
+ goto err_sched_engine;
+ }
+
err = intel_engine_init_cmd_parser(engine);
if (err)
goto err_cmd_parser;
@@ -737,6 +740,8 @@ static int engine_setup_common(struct intel_engine_cs
*engine)
return 0;
err_cmd_parser:
+ i915_sched_engine_put(engine->sched_engine);
+err_sched_engine:
intel_breadcrumbs_free(engine->breadcrumbs);
err_status:
cleanup_status_page(engine);
@@ -967,6 +972,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
GEM_BUG_ON(!list_empty(&engine->active.requests));
tasklet_kill(&engine->execlists.tasklet); /* flush the callback */
+ i915_sched_engine_put(engine->sched_engine);
intel_breadcrumbs_free(engine->breadcrumbs);
intel_engine_fini_retire(engine);
@@ -1290,7 +1296,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
intel_engine_flush_submission(engine);
/* ELSP is empty, but there are ready requests? E.g. after reset */
- if (!RB_EMPTY_ROOT(&engine->execlists.queue.rb_root))
+ if (!RB_EMPTY_ROOT(&engine->sched_engine->queue.rb_root))
return false;
/* Ring stopped? */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 47f4397095e5..b6a00dd72808 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
intel_breadcrumbs_park(engine->breadcrumbs);
/* Must be reset upon idling, or we may miss the busy wakeup. */
- GEM_BUG_ON(en
[Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
.../drm/i915/gt/intel_execlists_submission.c | 52
drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
drivers/gpu/drm/i915/i915_scheduler_types.h | 6 ++
3 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 8a3d4014fd2c..9487d9e0be62 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3116,10 +3116,61 @@ 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)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ struct i915_sched_engine *sched_engine = engine->sched_engine;
+ const struct i915_request *inflight;
+
+ /*
+* We only need to kick the tasklet once for the high priority
+* new context we add into the queue.
+*/
+ if (prio <= sched_engine->queue_priority_hint)
+ return;
+
+ rcu_read_lock();
+
+ /* Nothing currently active? We're overdue for a submission! */
+ inflight = execlists_active(&engine->execlists);
+ if (!inflight)
+ goto unlock;
+
+ /*
+* If we are already the currently executing context, don't
+* bother evaluating if we should preempt ourselves.
+*/
+ if (inflight->context == rq->context)
+ goto unlock;
+
+ ENGINE_TRACE(engine,
+"bumping queue-priority-hint:%d for rq:%llx:%lld,
inflight:%llx:%lld prio %d\n",
+prio,
+rq->fence.context, rq->fence.seqno,
+inflight->fence.context, inflight->fence.seqno,
+inflight->sched.attr.priority);
+
+ sched_engine->queue_priority_hint = prio;
+
+ /*
+* Allow preemption of low -> normal -> high, but we do
+* not allow low priority tasks to preempt other low priority
+* tasks under the impression that latency for low priority
+* tasks does not matter (as much as background throughput),
+* so kiss.
+*/
+ if (prio >= max(I915_PRIORITY_NORMAL, rq_prio(inflight)))
+ tasklet_hi_schedule(&engine->execlists.tasklet);
+
+unlock:
+ rcu_read_unlock();
+}
+
static void execlists_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = execlists_submit_request;
engine->sched_engine->schedule = i915_schedule;
+ engine->sched_engine->kick_backend = kick_execlists;
engine->execlists.tasklet.callback = execlists_submission_tasklet;
}
@@ -3702,6 +3753,7 @@ intel_execlists_create_virtual(struct intel_engine_cs
**siblings,
ve->base.request_alloc = execlists_request_alloc;
ve->base.sched_engine->schedule = i915_schedule;
+ ve->base.sched_engine->kick_backend = kick_execlists;
ve->base.submit_request = virtual_submit_request;
ve->base.bond_execute = virtual_bond_execute;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 4bc6969f6a97..035b88f2e4aa 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -157,65 +157,6 @@ sched_lock_engine(const struct i915_sched_node *node,
return locked;
}
-static inline int rq_prio(const struct i915_request *rq)
-{
- return rq->sched.attr.priority;
-}
-
-static inline bool need_preempt(int prio, int active)
-{
- /*
-* Allow preemption of low -> normal -> high, but we do
-* not allow low priority tasks to preempt other low priority
-* tasks under the impression that latency for low priority
-* tasks does not matter (as much as background throughput),
-* so kiss.
-*/
- return prio >= max(I915_PRIORITY_NORMAL, active);
-}
-
-static void kick_submission(struct intel_engine_cs *engine,
- const struct i915_request *rq,
- int prio)
-{
- const struct i915_request *inflight;
-
- /*
-* We only need to kick the tasklet once for the high priority
-* new context we add into the queue.
-*/
- if (prio <= engine->sched_engine->queue_priority_hint)
- return;
-
- rcu_read_lock();
-
- /* Nothing currently active? We're overdue for a submission! */
- inflight = execlists_active(&engine->execlists);
- if (!inflight)
- goto unlock;
-
-
[Intel-gfx] [PATCH 5/8] drm/i915: Move engine->schedule to i915_sched_engine
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
.../gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 16
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
drivers/gpu/drm/i915/i915_request.c | 10 +-
drivers/gpu/drm/i915/i915_scheduler_types.h | 10 ++
11 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 1e97520c62b2..1070d3afdce7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -104,8 +104,8 @@ static void fence_set_priority(struct dma_fence *fence,
engine = rq->engine;
rcu_read_lock(); /* RCU serialisation for set-wedged protection */
- if (engine->schedule)
- engine->schedule(rq, attr);
+ if (engine->sched_engine->schedule)
+ engine->sched_engine->schedule(rq, attr);
rcu_read_unlock();
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index b7efc4e399c5..354c1c260726 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -328,9 +328,6 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
if (engine->context_size)
DRIVER_CAPS(i915)->has_logical_contexts = true;
- /* Nothing to do here, execute in order of dependencies */
- engine->schedule = NULL;
-
ewma__engine_latency_init(&engine->latency);
seqcount_init(&engine->stats.lock);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index b99ac41695f3..b6a305e6a974 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -121,7 +121,7 @@ static void heartbeat(struct work_struct *wrk)
* but all other contexts, including the kernel
* context are stuck waiting for the signal.
*/
- } else if (engine->schedule &&
+ } else if (engine->sched_engine->schedule &&
rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
/*
* Gradually raise the priority of the heartbeat to
@@ -136,7 +136,7 @@ static void heartbeat(struct work_struct *wrk)
attr.priority = I915_PRIORITY_BARRIER;
local_bh_disable();
- engine->schedule(rq, &attr);
+ engine->sched_engine->schedule(rq, &attr);
local_bh_enable();
} else {
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5e0f39d202ef..0bb65c57d274 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -428,14 +428,6 @@ struct intel_engine_cs {
void(*bond_execute)(struct i915_request *rq,
struct dma_fence *signal);
- /*
-* Call when the priority on a request has changed and it and its
-* dependencies may need rescheduling. Note the request itself may
-* not be ready to run!
-*/
- void(*schedule)(struct i915_request *request,
- const struct i915_sched_attr *attr);
-
void(*release)(struct intel_engine_cs *engine);
struct intel_engine_execlists execlists;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 3cca7ea2d6ea..84142127ebd8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -108,7 +108,7 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
for_each_uabi_engine(engine, i915) { /* all engines must agree! */
int i;
- if (engine->schedule)
+ if (engine->sched_engine->schedule)
enabled |= (I915_SCHEDULER_CAP_ENABLED |
I915_SCHEDULER_CAP_PRIORITY);
else
diff --git a/drivers/gpu/drm/i915/gt/intel_execli
[Intel-gfx] [PATCH 3/8] drm/i915: Reset sched_engine.no_priolist immediately after dequeue
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 --
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 ++
drivers/gpu/drm/i915/i915_scheduler.h| 7 +++
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b6a00dd72808..1f07ac4e0672 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -280,8 +280,6 @@ static int __engine_park(struct intel_wakeref *wf)
if (engine->park)
engine->park(engine);
- engine->sched_engine->no_priolist = false;
-
/* While gt calls i915_vma_parked(), we have to break the lock cycle */
intel_gt_pm_put_async(engine->gt);
return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index e36b0e81876a..47a43aafa39f 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1553,6 +1553,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* interrupt for secondary ports).
*/
sched_engine->queue_priority_hint = queue_prio(sched_engine);
+ i915_sched_engine_reset_on_empty(sched_engine);
spin_unlock(&engine->active.lock);
/*
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 d65a7665b38e..9887a514a4d5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -263,6 +263,8 @@ static void guc_submission_tasklet(struct tasklet_struct *t)
__guc_dequeue(engine);
+ i915_sched_engine_reset_on_empty(engine->sched_engine);
+
spin_unlock_irqrestore(&engine->active.lock, flags);
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 5bec7b3b8456..713c38c99de9 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -72,6 +72,13 @@ i915_sched_engine_is_empty(struct i915_sched_engine
*sched_engine)
return RB_EMPTY_ROOT(&sched_engine->queue.rb_root);
}
+static inline void
+i915_sched_engine_reset_on_empty(struct i915_sched_engine *sched_engine)
+{
+ if (i915_sched_engine_is_empty(sched_engine))
+ sched_engine->no_priolist = false;
+}
+
void i915_request_show_with_schedule(struct drm_printer *m,
const struct i915_request *rq,
const char *prefix,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: Move submission tasklet to i915_sched_engine
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
v5:
(CI)
Rebase and fix build error
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_engine.h| 14
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 --
.../drm/i915/gt/intel_execlists_submission.c | 84 ++-
drivers/gpu/drm/i915/gt/mock_engine.c | 1 +
drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 ++--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25 +++---
drivers/gpu/drm/i915/i915_scheduler.c | 1 +
drivers/gpu/drm/i915/i915_scheduler.h | 14
drivers/gpu/drm/i915/i915_scheduler_types.h | 10 +++
13 files changed, 100 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 45ee08fc40a1..f911c1224ab2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -125,20 +125,6 @@ execlists_active(const struct intel_engine_execlists
*execlists)
return active;
}
-static inline void
-execlists_active_lock_bh(struct intel_engine_execlists *execlists)
-{
- local_bh_disable(); /* prevent local softirq and lock recursion */
- tasklet_lock(&execlists->tasklet);
-}
-
-static inline void
-execlists_active_unlock_bh(struct intel_engine_execlists *execlists)
-{
- tasklet_unlock(&execlists->tasklet);
- local_bh_enable(); /* restore softirq, and kick ksoftirqd! */
-}
-
struct i915_request *
execlists_unwind_incomplete_requests(struct intel_engine_execlists *execlists);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 354c1c260726..14b92bfd321b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -713,6 +713,7 @@ static int engine_setup_common(struct intel_engine_cs
*engine)
err = -ENOMEM;
goto err_sched_engine;
}
+ engine->sched_engine->private_data = engine;
err = intel_engine_init_cmd_parser(engine);
if (err)
@@ -944,7 +945,6 @@ int intel_engines_init(struct intel_gt *gt)
void intel_engine_cleanup_common(struct intel_engine_cs *engine)
{
GEM_BUG_ON(!list_empty(&engine->sched_engine->requests));
- tasklet_kill(&engine->execlists.tasklet); /* flush the callback */
i915_sched_engine_put(engine->sched_engine);
intel_breadcrumbs_free(engine->breadcrumbs);
@@ -1230,7 +1230,7 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
void __intel_engine_flush_submission(struct intel_engine_cs *engine, bool sync)
{
- struct tasklet_struct *t = &engine->execlists.tasklet;
+ struct tasklet_struct *t = &engine->sched_engine->tasklet;
if (!t->callback)
return;
@@ -1491,8 +1491,8 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
drm_printf(m, "\tExeclist tasklet queued? %s (%s), preempt? %s,
timeslice? %s\n",
yesno(test_bit(TASKLET_STATE_SCHED,
- &engine->execlists.tasklet.state)),
-
enableddisabled(!atomic_read(&engine->execlists.tasklet.count)),
+
&engine->sched_engine->tasklet.state)),
+
enableddisabled(!atomic_read(&engine->sched_engine->tasklet.count)),
repr_timer(&engine->execlists.preempt),
repr_timer(&engine->execlists.timer));
@@ -1516,7 +1516,7 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
idx, hws[idx * 2], hws[idx * 2 + 1]);
}
- execlists_active_lock_bh(execlists);
+ i915_sched_engine_active_lock_bh(engine->sched_engine);
rcu_read_lock();
for (port = execlists->active; (rq = *port); port++) {
char hdr[160];
@@ -1547,7 +1547,7 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
i915_request_show(m, rq, hdr, 0);
}
rcu_read_unlock();
- execlists_active_unlock_bh(execlists);
+ i915_sched_engine_active_unlock_bh(engine->sched_engine);
} else if (GRAPHICS_VER(dev_priv) > 6) {
drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
ENGINE_READ(
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Do not zero past infoframes.vsc
== Series Details == Series: drm/i915/display: Do not zero past infoframes.vsc URL : https://patchwork.freedesktop.org/series/91650/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10239_full -> Patchwork_20405_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20405_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20405_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_20405_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-iclb3/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb5/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html Known issues Here are the changes found in Patchwork_20405_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-apl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +5 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][7] ([i915#3354]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb8/igt@gem_exec_par...@secure-non-root.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-kbl4/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#307]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-snb2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#768]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb8/igt@gem_render_c...@yf-tiled-to-vebox-yf-tiled.html * igt@gen7_exec_parse@oacontrol-tracking: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-tglb1/igt@gen7_exec_pa...@oacontrol-tracking.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#658]) [20]: https://intel-gfx-ci.01.org/
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce i915_sched_engine object (rev6)
== Series Details == Series: Introduce i915_sched_engine object (rev6) URL : https://patchwork.freedesktop.org/series/90630/ State : success == Summary == CI Bug Log - changes from CI_DRM_10240 -> Patchwork_20406 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/index.html Known issues Here are the changes found in Patchwork_20406 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#2283]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +23 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886] / [i915#2291]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-ilk-650: [DMESG-WARN][9] ([i915#164]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/fi-ilk-650/igt@gem_exec_susp...@basic-s0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-ilk-650/igt@gem_exec_susp...@basic-s0.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-guc: [FAIL][11] ([i915#3049]) -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#164]: https://gitlab.freedesktop.org/drm/intel/issues/164 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#3049]: https://gitlab.freedesktop.org/drm/intel/issues/3049 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (41 -> 37) -- Additional (1): fi-kbl-soraka Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10240 -> Patchwork_20406 CI-20190529: 20190529 CI_DRM_10240: c160d8d6c40f2264c495f2bc6f24bf3547ba50ab @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6112: a17cc0c5d096fabfd516848c114bc411e11130f4 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20406: e8d59936c8b41c542f7ab6c245690cc91d4d93ad @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e8d59936c8b4 drm/i915: Move submission tasklet to i915_sched_engine 411259b2f85c drm/i915: Update i915_scheduler to operate on i915_sched_engine cbaa9faf3768 drm/i915: Add kick_backend function to i915_sched_engine 5ecdd32a7b83 drm/i915: Move engine->schedule to i915_sched_engine 0066781910bf drm/i915: Move active tracking to i915_sched_engine ed9a634226ba drm/i915: Reset sched_engine.no_priolist immediately after dequeue 0ea5ffb0e145 drm/i915: Add i915_sched_engine_is_empty function b42f08f67724 drm/i915: Move priolist to new i915_sched_e
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Explicity steer l3bank multicast reads when necessary (rev7)
On Fri, Jun 18, 2021 at 12:10:23AM +, Patchwork wrote: > == Series Details == > > Series: Explicity steer l3bank multicast reads when necessary (rev7) > URL : https://patchwork.freedesktop.org/series/91485/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10239_full -> Patchwork_20404_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20404_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20404_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_20404_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_exec_reloc@basic-wide-active@bcs0: > - shard-apl: NOTRUN -> [FAIL][1] +3 similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-apl2/igt@gem_exec_reloc@basic-wide-act...@bcs0.html This test has been failing on every platform since at least CI_DRM_10206, maybe earlier. Failure isn't caused by this series. Series pushed to gt-next. Thanks Rodrigo for the reviews. Matt > > > Known issues > > > Here are the changes found in Patchwork_20404_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-apl7/igt@gem_cre...@create-massive.html > > * igt@gem_ctx_persistence@engines-mixed: > - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +4 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-snb2/igt@gem_ctx_persiste...@engines-mixed.html > > * igt@gem_ctx_persistence@many-contexts: > - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2842]) +1 similar issue >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_exec_fair@basic-none@vecs0: > - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842] / [i915#3468]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_fair@basic-pace@rcs0: > - shard-kbl: [PASS][11] -> [SKIP][12] ([fdo#109271]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html > > * igt@gem_exec_params@secure-non-root: > - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-iclb1/igt@gem_exec_par...@secure-non-root.html > > * igt@gem_huc_copy@huc-copy: > - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-kbl2/igt@gem_huc_c...@huc-copy.html > > * igt@gem_mmap_gtt@big-copy-odd: > - shard-skl: [PASS][15] -> [FAIL][16] ([i915#307]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-skl3/igt@gem_mmap_...@big-copy-odd.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-skl1/igt@gem_mmap_...@big-copy-odd.html > > * igt@gem_mmap_gtt@cpuset-basic-small-copy: > - shard-glk: [PASS][17] -> [FAIL][18] ([i915#307]) +1 similar > issue >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk1/igt@gem_mmap_...@cpuset-basic-small-copy.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20404/shard-glk5/igt@gem_mmap_...@cpuset-basic-small-copy.html > > * igt@gem_mmap_gt
Re: [Intel-gfx] [PULL] drm-misc-next-fixes
when I pulled this in drm-next I got these.
were the mst fixes meant for next or fixes btw? I'm not really sure,
but either way I don't think this is a local reason it doesn't build
or did I miss something?
Dave.
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:
In function ‘drm_dp_update_payload_part1’:
/home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:450:27:
error: request for member ‘dev’ in something not a structure or union
450 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
| ^~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3392:5:
note: in expansion of macro ‘drm_dbg_kms’
3392 | drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
| ^~~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3392:68:
warning: passing argument 3 of ‘drm_dev_dbg’ makes pointer from
integer without a cast [-Wint-conversion]
3392 | drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
|^
||
|int
/home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:450:53:
note: in definition of macro ‘drm_dbg_kms’
450 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
| ^~~
/home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:338:16:
note: expected ‘const char *’ but argument is of type ‘int’
338 |const char *format, ...);
|^~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:53:
error: macro "drm_dbg_kms" requires 3 arguments, but only 1 given
3407 | drm_dbg_kms("Fail:set payload to invalid sink");
| ^
In file included from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:45:
/home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:449: note:
macro "drm_dbg_kms" defined here
449 | #define drm_dbg_kms(drm, fmt, ...) \
|
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:7:
error: ‘drm_dbg_kms’ undeclared (first use in this function)
3407 | drm_dbg_kms("Fail:set payload to invalid sink");
| ^~~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:7:
note: each undeclared identifier is reported only once for each
function it appears in
make[4]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:272:
drivers/gpu/drm/drm_dp_mst_topology.o] Error 1
make[4]: *** Waiting for unfinished jobs
On Thu, 17 Jun 2021 at 04:30, Thomas Zimmermann wrote:
>
> Hi Dave and Daniel,
>
> here's this week's PR for drm-misc-next-fixes.
>
> Best regards
> Thomas
>
> drm-misc-next-fixes-2021-06-16:
> Short summary of fixes pull:
>
> * hyperv: advertise the correct formatmodifiers for its primary plane
> * dp_mst: VCPI fixes to make it work with StarTech hub
>
> The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
>
> Merge tag 'exynos-drm-next-for-v5.14' of
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
> drm-next (2021-06-11 14:19:12 +1000)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-misc
> tags/drm-misc-next-fixes-2021-06-16
>
> for you to fetch changes up to 3769e4c0af5b82c8ea21d037013cb9564dfaa51f:
>
> drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> (2021-06-16 12:57:46 -0400)
>
>
> Short summary of fixes pull:
>
> * hyperv: advertise the correct formatmodifiers for its primary plane
> * dp_mst: VCPI fixes to make it work with StarTech hub
>
>
> Pu Lehui (1):
> drm/hyperv: Fix unused const variable 'hyperv_modifiers'
>
> Wayne Lin (2):
> drm/dp_mst: Do not set proposed vcpi directly
> drm/dp_mst: Avoid to mess up payload table by ports in stale topology
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 65
> +
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +-
> 2 files changed, 40 insertions(+), 27 deletions(-)
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
On (21/06/17 19:27), Daniel Vetter wrote: > > > > So can all allocations in gen8_init_scratch() use > > GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN > > Yeah that looks all fairly broken tbh. The only thing I didn't know was > that GFP_DMA32 wasn't a full gfp mask with reclaim bits set as needed. I > guess it would be clearer if we use GFP_KERNEL | __GFP_DMA32 for these. Looks good. > The commit that introduced a lot of this, including I915_GFP_ALLOW_FAIL > seems to be > > commit 1abb70f5955d1a9021f96359a2c6502ca569b68d > Author: Chris Wilson > Date: Tue May 22 09:36:43 2018 +0100 > > drm/i915/gtt: Allow pagedirectory allocations to fail > > which used a selftest as justification, not real world workloads, so looks > rather dubious. Exactly, the commit we landed internally partially reverts 1abb70f5955 in 4.19 and 5.4 kernels. I don't mind I915_GFP_ALLOW_FAIL and so on, I kept those bits, but we need reclaim. I can reproduce cases when order:0 allocation fails with __GFP_HIGHMEM|__GFP_RETRY_MAYFAIL but succeeds with GFP_KERNEL|__GFP_HIGHMEM|__GFP_RETRY_MAYFAIL ON a side note, I'm not very sure if __GFP_RETRY_MAYFAIL is actually needed. Especially seeing it in syscalls is a bit uncommon: drm_ioctl() i915_gem_context_create_ioctl() i915_gem_create_context() i915_ppgtt_create() setup_scratch_page() // __GFP_RETRY_MAYFAIL But with GFP_KERNEL at least it tries to make some reclaim progress between retries, so it seems to be good enough. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-next-fixes
22:27 airlied: re: the pull, I should have pushed a fix for the
compilation error today. that was something I pulled in from amd that they
didn't compile check and I missed :S
22:28 airlied: 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c in drm-
misc/drm-misc-next-fixes
sorry about this - I already talked to hwentlan the other day about trying to
make sure that AMD is more on top of actually making sure things compile
before submitting them, was my fault for missing this during the initial
review of that fix.
On Fri, 2021-06-18 at 12:26 +1000, Dave Airlie wrote:
> when I pulled this in drm-next I got these.
>
> were the mst fixes meant for next or fixes btw? I'm not really sure,
> but either way I don't think this is a local reason it doesn't build
> or did I miss something?
>
> Dave.
>
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:
> In function ‘drm_dp_update_payload_part1’:
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:450:27:
> error: request for member ‘dev’ in something not a structure or union
> 450 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt,
> ##__VA_ARGS__)
> | ^~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3392:
> 5:
> note: in expansion of macro ‘drm_dbg_kms’
> 3392 | drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
> | ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3392:
> 68:
> warning: passing argument 3 of ‘drm_dev_dbg’ makes pointer from
> integer without a cast [-Wint-conversion]
> 3392 | drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
> | ^
> | |
> | int
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:450:53:
> note: in definition of macro ‘drm_dbg_kms’
> 450 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt,
> ##__VA_ARGS__)
> | ^~~
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:338:16:
> note: expected ‘const char *’ but argument is of type ‘int’
> 338 | const char *format, ...);
> | ^~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:
> 53:
> error: macro "drm_dbg_kms" requires 3 arguments, but only 1 given
> 3407 | drm_dbg_kms("Fail:set payload to invalid sink");
> | ^
> In file included from
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:45:
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:449: note:
> macro "drm_dbg_kms" defined here
> 449 | #define drm_dbg_kms(drm, fmt, ...) \
> |
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:
> 7:
> error: ‘drm_dbg_kms’ undeclared (first use in this function)
> 3407 | drm_dbg_kms("Fail:set payload to invalid sink");
> | ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:
> 7:
> note: each undeclared identifier is reported only once for each
> function it appears in
> make[4]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:272:
> drivers/gpu/drm/drm_dp_mst_topology.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>
> On Thu, 17 Jun 2021 at 04:30, Thomas Zimmermann wrote:
> >
> > Hi Dave and Daniel,
> >
> > here's this week's PR for drm-misc-next-fixes.
> >
> > Best regards
> > Thomas
> >
> > drm-misc-next-fixes-2021-06-16:
> > Short summary of fixes pull:
> >
> > * hyperv: advertise the correct formatmodifiers for its primary plane
> > * dp_mst: VCPI fixes to make it work with StarTech hub
> >
> > The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> >
> > Merge tag 'exynos-drm-next-for-v5.14' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-
> > next (2021-06-11 14:19:12 +1000)
> >
> > are available in the Git repository at:
> >
> > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-
> > 06-16
> >
> > for you to fetch changes up to 3769e4c0af5b82c8ea21d037013cb9564dfaa51f:
> >
> > drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> > (2021-06-16 12:57:46 -0400)
> >
> >
> > Short summary of fixes pull:
> >
> > * hyperv: advertise the correct formatmodifiers for its primary plane
> > * dp_mst: VCPI fixes to make it work with StarTech hub
> >
> >
> > Pu Lehui (1):
> > drm/hyperv: Fix unused const variable 'hyperv_modifiers'
> >
> > Wayne Lin (2):
> > drm/dp_mst: Do not s
Re: [Intel-gfx] [PULL] drm-misc-next-fixes
On Fri, 18 Jun 2021 at 12:26, Dave Airlie wrote:
>
> when I pulled this in drm-next I got these.
>
> were the mst fixes meant for next or fixes btw? I'm not really sure,
> but either way I don't think this is a local reason it doesn't build
> or did I miss something?
Hi Thomas,
Please resend with the fix Lyude has pushed (just keep building, just
keep building).
Thanks,
Dave.
>
> Dave.
>
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:
> In function ‘drm_dp_update_payload_part1’:
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:450:27:
> error: request for member ‘dev’ in something not a structure or union
> 450 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt,
> ##__VA_ARGS__)
> | ^~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3392:5:
> note: in expansion of macro ‘drm_dbg_kms’
> 3392 | drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
> | ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3392:68:
> warning: passing argument 3 of ‘drm_dev_dbg’ makes pointer from
> integer without a cast [-Wint-conversion]
> 3392 | drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
> |^
> ||
> |int
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:450:53:
> note: in definition of macro ‘drm_dbg_kms’
> 450 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt,
> ##__VA_ARGS__)
> | ^~~
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:338:16:
> note: expected ‘const char *’ but argument is of type ‘int’
> 338 |const char *format, ...);
> |^~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:53:
> error: macro "drm_dbg_kms" requires 3 arguments, but only 1 given
> 3407 | drm_dbg_kms("Fail:set payload to invalid sink");
> | ^
> In file included from
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:45:
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:449: note:
> macro "drm_dbg_kms" defined here
> 449 | #define drm_dbg_kms(drm, fmt, ...) \
> |
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:7:
> error: ‘drm_dbg_kms’ undeclared (first use in this function)
> 3407 | drm_dbg_kms("Fail:set payload to invalid sink");
> | ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/drm_dp_mst_topology.c:3407:7:
> note: each undeclared identifier is reported only once for each
> function it appears in
> make[4]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:272:
> drivers/gpu/drm/drm_dp_mst_topology.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>
> On Thu, 17 Jun 2021 at 04:30, Thomas Zimmermann wrote:
> >
> > Hi Dave and Daniel,
> >
> > here's this week's PR for drm-misc-next-fixes.
> >
> > Best regards
> > Thomas
> >
> > drm-misc-next-fixes-2021-06-16:
> > Short summary of fixes pull:
> >
> > * hyperv: advertise the correct formatmodifiers for its primary plane
> > * dp_mst: VCPI fixes to make it work with StarTech hub
> >
> > The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> >
> > Merge tag 'exynos-drm-next-for-v5.14' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
> > drm-next (2021-06-11 14:19:12 +1000)
> >
> > are available in the Git repository at:
> >
> > git://anongit.freedesktop.org/drm/drm-misc
> > tags/drm-misc-next-fixes-2021-06-16
> >
> > for you to fetch changes up to 3769e4c0af5b82c8ea21d037013cb9564dfaa51f:
> >
> > drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> > (2021-06-16 12:57:46 -0400)
> >
> >
> > Short summary of fixes pull:
> >
> > * hyperv: advertise the correct formatmodifiers for its primary plane
> > * dp_mst: VCPI fixes to make it work with StarTech hub
> >
> >
> > Pu Lehui (1):
> > drm/hyperv: Fix unused const variable 'hyperv_modifiers'
> >
> > Wayne Lin (2):
> > drm/dp_mst: Do not set proposed vcpi directly
> > drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> >
> > drivers/gpu/drm/drm_dp_mst_topology.c | 65
> > +
> > drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +-
> > 2 files changed, 40 insertions(+), 27 deletions(-)
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr.
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Do not zero past infoframes.vsc
On Fri, Jun 18, 2021 at 12:58:22AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/display: Do not zero past infoframes.vsc > URL : https://patchwork.freedesktop.org/series/91650/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10239_full -> Patchwork_20405_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20405_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20405_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. Err, it's not clear to me if my patch caused this? There's a long "known issues" section here. If it _did_ cause it, then the code depended on the large clobber and some other solution is needed? -Kees > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20405_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: > - shard-iclb: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-iclb3/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb5/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html > > > Known issues > > > Here are the changes found in Patchwork_20405_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-apl8/igt@gem_cre...@create-massive.html > > * igt@gem_ctx_persistence@legacy-engines-queued: > - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +5 > similar issues >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html > > * igt@gem_ctx_persistence@many-contexts: > - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html > > * igt@gem_eio@unwedge-stress: > - shard-snb: NOTRUN -> [FAIL][7] ([i915#3354]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-snb5/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_fair@basic-flow@rcs0: > - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +3 similar > issues >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html > > * igt@gem_exec_fair@basic-none-rrul@rcs0: > - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs1: > - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html > > * igt@gem_exec_params@secure-non-root: > - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb8/igt@gem_exec_par...@secure-non-root.html > > * igt@gem_huc_copy@huc-copy: > - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-kbl4/igt@gem_huc_c...@huc-copy.html > > * igt@gem_mmap_gtt@cpuset-big-copy-odd: > - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#307]) +1 similar > issue >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy-odd.html > > * igt@gem_pwrite@basic-exhaustion: > - shard-snb: NOTRUN -> [WARN][17] ([i915#2658]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20405/shard-snb2/igt@gem_pwr...@basic-exhaustion.html > > * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled: > - shard-iclb: NOTRUN -> [SKIP][18] ([i915#768]) >[18]: > https
[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce i915_sched_engine object (rev6)
== Series Details == Series: Introduce i915_sched_engine object (rev6) URL : https://patchwork.freedesktop.org/series/90630/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10240_full -> Patchwork_20406_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20406_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20406_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_20406_full: ### IGT changes ### Possible regressions * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-mmap-wc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-mmap-wc.html Known issues Here are the changes found in Patchwork_20406_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-iclb2/igt@feature_discov...@psr2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-iclb3/igt@feature_discov...@psr2.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-snb2/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-glk7/igt@gem_exec_fair@basic-none-s...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-glk9/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842] / [i915#3468]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-glk7/igt@gem_exec_fair@basic-n...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-glk9/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10240/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-sync@rcs0: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-skl4/igt@gem_exec_fair@basic-s...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271]) +249 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_params@no-bsd: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109283]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-iclb4/igt@gem_exec_par...@no-bsd.html * igt@gem_pread@exhaustion: - shard-snb: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20406/shard-snb6/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant
Hello,
Humble request for review of this please
https://patchwork.freedesktop.org/series/90828/
Can anyone kindly help review this so we can request for merge?
Thank you so much.
Regards
Vidya
-Original Message-
From: Srinivas, Vidya
Sent: Tuesday, June 15, 2021 1:55 PM
To: Modem, Bhanuprakash ;
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Cc: Shankar, Uma
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't
set primary fb color in coverage-vs-premult-vs-constant
Hello Bhanu,
Sorry for the trouble. Kindly can you check if rev 3 is okay? Thanks a lot.
Regards
Vidya
-Original Message-
From: Srinivas, Vidya
Sent: Friday, June 11, 2021 6:28 PM
To: Modem, Bhanuprakash ;
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't
set primary fb color in coverage-vs-premult-vs-constant
Hello Bhanu,
I have uploaded version 3 where I have not removed primary plane.
Instead I have added a commit of the primary plane and I have changed alpha.
This passes on Gen11 systems.
Kindly check https://patchwork.freedesktop.org/patch/438831/?series=90828&rev=3
and suggest.
Thank you so much.
Regards
Vidya
-Original Message-
From: Srinivas, Vidya
Sent: Friday, June 11, 2021 1:00 PM
To: Modem, Bhanuprakash ;
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't
set primary fb color in coverage-vs-premult-vs-constant
Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is
also not helping.
Regards
Vidya
-Original Message-
From: Modem, Bhanuprakash
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ;
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't
set primary fb color in coverage-vs-premult-vs-constant
> From: Intel-gfx On Behalf Of
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend:
> Don't set primary fb color in coverage-vs-premult-vs-constant
>
> Patch removes setting primary fb color in
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11
> systems.
I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and
"pixel blend mode"), is this test failing on a particular plane?
- Bhanu
> Similar change has already been done in tests constant_alpha_min and
> basic_alpha where the test runs on all planes but dont set the primary
> fb color.
>
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_plane_alpha_blend.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/tests/kms_plane_alpha_blend.c
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t
> *data, enum pipe pipe, igt_plane_t
> igt_display_t *display = &data->display;
> igt_crc_t ref_crc = {}, crc = {};
>
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(&display->pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), &data->gray_fb);
> -
> igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
> igt_plane_set_fb(plane, &data->argb_fb_cov_7e);
> igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 01/12] swiotlb: Refactor swiotlb init functions
On Fri, Jun 18, 2021 at 7:30 AM Stefano Stabellini
wrote:
>
> On Thu, 17 Jun 2021, Claire Chang wrote:
> > Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> > initialization to make the code reusable.
> >
> > Signed-off-by: Claire Chang
> > Reviewed-by: Christoph Hellwig
> > Tested-by: Stefano Stabellini
> > Tested-by: Will Deacon
> > ---
> > kernel/dma/swiotlb.c | 50 ++--
> > 1 file changed, 25 insertions(+), 25 deletions(-)
> >
> > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> > index 52e2ac526757..47bb2a766798 100644
> > --- a/kernel/dma/swiotlb.c
> > +++ b/kernel/dma/swiotlb.c
> > @@ -168,9 +168,28 @@ void __init swiotlb_update_mem_attributes(void)
> > memset(vaddr, 0, bytes);
> > }
> >
> > -int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> > verbose)
> > +static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t
> > start,
> > + unsigned long nslabs, bool late_alloc)
> > {
> > + void *vaddr = phys_to_virt(start);
> > unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> > +
> > + mem->nslabs = nslabs;
> > + mem->start = start;
> > + mem->end = mem->start + bytes;
> > + mem->index = 0;
> > + mem->late_alloc = late_alloc;
> > + spin_lock_init(&mem->lock);
> > + for (i = 0; i < mem->nslabs; i++) {
> > + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > + mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > + mem->slots[i].alloc_size = 0;
> > + }
> > + memset(vaddr, 0, bytes);
> > +}
> > +
> > +int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> > verbose)
> > +{
> > struct io_tlb_mem *mem;
> > size_t alloc_size;
> >
> > @@ -186,16 +205,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned
> > long nslabs, int verbose)
> > if (!mem)
> > panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > __func__, alloc_size, PAGE_SIZE);
> > - mem->nslabs = nslabs;
> > - mem->start = __pa(tlb);
> > - mem->end = mem->start + bytes;
> > - mem->index = 0;
> > - spin_lock_init(&mem->lock);
> > - for (i = 0; i < mem->nslabs; i++) {
> > - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > - mem->slots[i].alloc_size = 0;
> > - }
> > +
> > + swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
> >
> > io_tlb_default_mem = mem;
> > if (verbose)
> > @@ -282,8 +293,8 @@ swiotlb_late_init_with_default_size(size_t default_size)
> > int
> > swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
> > {
> > - unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> > struct io_tlb_mem *mem;
> > + unsigned long bytes = nslabs << IO_TLB_SHIFT;
> >
> > if (swiotlb_force == SWIOTLB_NO_FORCE)
> > return 0;
> > @@ -297,20 +308,9 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
> > nslabs)
> > if (!mem)
> > return -ENOMEM;
> >
> > - mem->nslabs = nslabs;
> > - mem->start = virt_to_phys(tlb);
> > - mem->end = mem->start + bytes;
> > - mem->index = 0;
> > - mem->late_alloc = 1;
> > - spin_lock_init(&mem->lock);
> > - for (i = 0; i < mem->nslabs; i++) {
> > - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > - mem->slots[i].alloc_size = 0;
> > - }
> > -
> > + memset(mem, 0, sizeof(*mem));
> > + swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true);
> > set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
> > - memset(tlb, 0, bytes);
>
> This is good for swiotlb_late_init_with_tbl. However I have just noticed
> that mem could also be allocated from swiotlb_init_with_tbl, in which
> case the zeroing is missing. I think we need another memset in
> swiotlb_init_with_tbl as well. Or maybe it could be better to have a
> single memset at the beginning of swiotlb_init_io_tlb_mem instead. Up to
> you.
swiotlb_init_with_tbl uses memblock_alloc to allocate the io_tlb_mem
and memblock_alloc[1] will do memset in memblock_alloc_try_nid[2], so
swiotlb_init_with_tbl is also good.
I'm happy to add the memset in swiotlb_init_io_tlb_mem if you think
it's clearer and safer.
[1]
https://elixir.bootlin.com/linux/v5.13-rc6/source/include/linux/memblock.h#L407
[2] https://elixir.bootlin.com/linux/v5.13-rc6/source/mm/memblock.c#L1555
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
