[Intel-gfx] ✗ Fi.CI.IGT: failure for Update to new HuC for TGL+ and enable GuC/HuC on ADL-P
== Series Details == Series: Update to new HuC for TGL+ and enable GuC/HuC on ADL-P URL : https://patchwork.freedesktop.org/series/91932/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10282_full -> Patchwork_20473_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20473_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20473_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_20473_full: ### IGT changes ### Possible regressions * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb2/igt@gem_huc_c...@huc-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-tglb3/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_heartbeat: - shard-tglb: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb1/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-tglb5/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1: - shard-iclb: [SKIP][5] ([i915#658]) -> [SKIP][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-iclb6/igt@kms_psr2...@overlay-plane-update-sf-dmg-area-1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-iclb2/igt@kms_psr2...@overlay-plane-update-sf-dmg-area-1.html Known issues Here are the changes found in Patchwork_20473_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][7] ([i915#3002]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-snb5/igt@gem_cre...@create-massive.html - shard-kbl: NOTRUN -> [DMESG-WARN][8] ([i915#3002]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-kbl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1099]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2410]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-kbl3/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][13] ([i915#2846]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-glk6/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: NOTRUN -> [FAIL][18] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html - shard-apl: [PASS][19] -> [FAIL][20] ([i915#2842] / [i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [22]:
Re: [Intel-gfx] [PATCH v4 25/27] drm/vmwgfx: Don't set struct drm_device.irq_enabled
> On Jun 25, 2021, at 04:22, Thomas Zimmermann wrote: > > The field drm_device.irq_enabled is only used by legacy drivers > with userspace modesetting. Don't set it in vmxgfx. All usage of > the field within vmwgfx can safely be removed. > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Laurent Pinchart > Acked-by: Daniel Vetter Looks good. Reviewed-by: Zack Rusin ___ 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 [1/2] drm/i915/display/adl_p: Implement PSR changes
== Series Details == Series: series starting with [1/2] drm/i915/display/adl_p: Implement PSR changes URL : https://patchwork.freedesktop.org/series/91931/ State : success == Summary == CI Bug Log - changes from CI_DRM_10282_full -> Patchwork_20472_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_20472_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20472_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_20472_full: ### IGT changes ### Warnings * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-2: - shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-iclb8/igt@kms_psr2...@primary-plane-update-sf-dmg-area-2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-2.html Known issues Here are the changes found in Patchwork_20472_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-kbl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-kbl: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-kbl1/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-kbl6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-kbl1/igt@gem_exec_fair@basic-none-r...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-kbl2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-glk1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_params@no-vebox: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271]) +21 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-skl3/igt@gem_exec_par...@no-vebox.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_20472/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-iclb8/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-iclb2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271]) +81 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-kbl6/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-kbl6/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][19] ([i915#3002]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/shard-apl3/igt@gem_userptr_bl...@input-checking.html - shard-snb: NOTRUN -> [DMESG-WARN][20] ([i915#3002]) [20]:
[Intel-gfx] ✓ Fi.CI.BAT: success for Update to new HuC for TGL+ and enable GuC/HuC on ADL-P
== Series Details ==
Series: Update to new HuC for TGL+ and enable GuC/HuC on ADL-P
URL : https://patchwork.freedesktop.org/series/91932/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10282 -> Patchwork_20473
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/index.html
Known issues
Here are the changes found in Patchwork_20473 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +14 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {fi-tgl-1115g4}:[DMESG-WARN][2] ([i915#2867]) -> [PASS][3] +14
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.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#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3436]: https://gitlab.freedesktop.org/drm/intel/issues/3436
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10282 -> Patchwork_20473
CI-20190529: 20190529
CI_DRM_10282: 67f5a18128770817e4218a9e496d2bf5047c51e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20473: 6fb908519db13d41a02b3c66bb60661d396ffed1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6fb908519db1 drm/i915/adlp: Add ADL-P GuC/HuC firmware files
fd497f366a5c drm/i915/huc: Update TGL and friends to HuC 7.9.3
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20473/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/adlp: Add ADL-P GuC/HuC firmware files
From: John Harrison Add ADL-P to the list of supported GuC and HuC firmware versions. For HuC, it reuses the existing TGL firmware file. For GuC, there is a dedicated firmware release. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index f05b1572e3c3..3a16d08608a5 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -48,6 +48,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * firmware as TGL. */ #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \ + fw_def(ALDERLAKE_P, 0, guc_def(adlp, 62, 0, 3), huc_def(tgl, 7, 9, 3)) \ fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/huc: Update TGL and friends to HuC 7.9.3
From: John Harrison A new HuC is available for TGL and compatible platforms, so switch to using it. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 9f23e9de3237..f05b1572e3c3 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -48,9 +48,9 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * firmware as TGL. */ #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \ - fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \ - fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \ - fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \ + fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ + fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ + fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \ fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \ fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \ fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl, 9, 0, 0)) \ -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] Update to new HuC for TGL+ and enable GuC/HuC on ADL-P
From: John Harrison There is a new HuC version available for TGL and compatible platforms, so switch to using it. Also, there is now a GuC and HuC for ADL-P, so use those too. Signed-off-by: John Harrison John Harrison (2): drm/i915/huc: Update TGL and friends to HuC 7.9.3 drm/i915/adlp: Add ADL-P GuC/HuC firmware files drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.25.1 ___ 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 [1/2] drm/i915/display/adl_p: Implement PSR changes
== Series Details ==
Series: series starting with [1/2] drm/i915/display/adl_p: Implement PSR changes
URL : https://patchwork.freedesktop.org/series/91931/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10282 -> Patchwork_20472
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/index.html
Known issues
Here are the changes found in Patchwork_20472 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +16 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {fi-tgl-1115g4}:[DMESG-WARN][2] ([i915#2867]) -> [PASS][3] +14
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.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#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10282 -> Patchwork_20472
CI-20190529: 20190529
CI_DRM_10282: 67f5a18128770817e4218a9e496d2bf5047c51e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20472: 399cecf3f729c6dd519d878af2bc0dc40cab3bec @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
399cecf3f729 drm/i915/display: Disable FBC when PSR2 is enabled display 12 and
newer
40703d3f9d23 drm/i915/display/adl_p: Implement PSR changes
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20472/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/display/adl_p: Implement PSR changes
== Series Details == Series: series starting with [1/2] drm/i915/display/adl_p: Implement PSR changes URL : https://patchwork.freedesktop.org/series/91931/ 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/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/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/display/adl_p: Implement PSR changes
== Series Details == Series: series starting with [1/2] drm/i915/display/adl_p: Implement PSR changes URL : https://patchwork.freedesktop.org/series/91931/ State : warning == Summary == $ dim checkpatch origin/drm-tip 40703d3f9d23 drm/i915/display/adl_p: Implement PSR changes -:149: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #149: FILE: drivers/gpu/drm/i915/i915_reg.h:4660: +#define PSR2_MAN_TRK_CTL(tran) _MMIO_TRANS2(tran, _PSR2_MAN_TRK_CTL_A) -:152: WARNING:LONG_LINE: line length of 127 exceeds 100 columns #152: FILE: drivers/gpu/drm/i915/i915_reg.h:4663: +#define PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val) REG_FIELD_PREP(PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val) -:162: WARNING:LONG_LINE: line length of 132 exceeds 100 columns #162: FILE: drivers/gpu/drm/i915/i915_reg.h:4670: +#define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val) REG_FIELD_PREP(ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val) -:164: WARNING:LONG_LINE: line length of 130 exceeds 100 columns #164: FILE: drivers/gpu/drm/i915/i915_reg.h:4672: +#define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(val) REG_FIELD_PREP(ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK, val) total: 0 errors, 4 warnings, 0 checks, 131 lines checked 399cecf3f729 drm/i915/display: Disable FBC when PSR2 is enabled display 12 and newer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/display/adl_p: Implement PSR changes
Implements changes around PSR for alderlake-P:
- EDP_SU_TRACK_ENABLE was removed and bit 30 now has other function
- Some bits of PSR2_MAN_TRK_CTL moved and SF_PARTIAL_FRAME_UPDATE was
removed setting SU_REGION_START/END_ADDR will do this job
- SU_REGION_START/END_ADDR have now line granularity but will need to
be aligned with DSC when the PSRS + DSC support lands
BSpec: 50422
BSpec: 50424
Cc: Gwan-gyeong Mun
Cc: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_psr.c | 43 ++--
drivers/gpu/drm/i915/i915_reg.h | 26 --
2 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9643624fe160d..46bb19c4b63a4 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -534,11 +534,13 @@ static u32 intel_psr2_get_tp_time(struct intel_dp
*intel_dp)
static void hsw_activate_psr2(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u32 val;
+ u32 val = EDP_PSR2_ENABLE;
+
+ val |= psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
- val = psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
+ if (!IS_ALDERLAKE_P(dev_priv))
+ val |= EDP_SU_TRACK_ENABLE;
- val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
val |= EDP_Y_COORDINATE_ENABLE;
@@ -793,6 +795,7 @@ static bool intel_psr2_sel_fetch_config_valid(struct
intel_dp *intel_dp,
static bool psr2_granularity_check(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state)
{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
const int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
const int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
u16 y_granularity = 0;
@@ -809,10 +812,13 @@ static bool psr2_granularity_check(struct intel_dp
*intel_dp,
return intel_dp->psr.su_y_granularity == 4;
/*
-* For SW tracking we can adjust the y to match sink requirement if
-* multiple of 4
+* adl_p has 1 line granularity for other platforms with SW tracking we
+* can adjust the y coordinate to match sink requirement if multiple of
+* 4
*/
- if (intel_dp->psr.su_y_granularity <= 2)
+ if (IS_ALDERLAKE_P(dev_priv))
+ y_granularity = intel_dp->psr.su_y_granularity;
+ else if (intel_dp->psr.su_y_granularity <= 2)
y_granularity = 4;
else if ((intel_dp->psr.su_y_granularity % 4) == 0)
y_granularity = intel_dp->psr.su_y_granularity;
@@ -1525,21 +1531,32 @@ void intel_psr2_program_trans_man_trk_ctl(const struct
intel_crtc_state *crtc_st
static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
struct drm_rect *clip, bool full_update)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 val = PSR2_MAN_TRK_CTL_ENABLE;
if (full_update) {
- val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+ if (IS_ALDERLAKE_P(dev_priv))
+ val |= ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+ else
+ val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+
goto exit;
}
if (clip->y1 == -1)
goto exit;
- drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 || clip->y2 % 4);
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1);
+ val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2);
+ } else {
+ drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 ||
clip->y2 % 4);
- val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
- val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 + 1);
- val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 / 4 + 1);
+ val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
+ val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 + 1);
+ val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 / 4 + 1);
+ }
exit:
crtc_state->psr2_man_track_ctl = val;
}
@@ -1563,11 +1580,15 @@ static void clip_area_update(struct drm_rect
*overlap_damage_area,
static void intel_psr2_sel_fetch_pipe_alignment(const struct intel_crtc_state
*crtc_state,
struct drm_rect *pipe_clip)
{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
const u16 y_alignment =
[Intel-gfx] [PATCH 2/2] drm/i915/display: Disable FBC when PSR2 is enabled display 12 and newer
This is now a requirement for all display 12 and newer, not only for
tigerlake.
BSpec: 50422
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 7dc72e4a4656b..270b1f26566df 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -911,11 +911,11 @@ static bool intel_fbc_can_activate(struct intel_crtc
*crtc)
}
/*
-* Tigerlake is not supporting FBC with PSR2.
+* Display 12+ is not supporting FBC with PSR2.
* Recommendation is to keep this combination disabled
* Bspec: 50422 HSD: 14010260002
*/
- if (fbc->state_cache.psr2_active && IS_TIGERLAKE(dev_priv)) {
+ if (fbc->state_cache.psr2_active && DISPLAY_VER(dev_priv) >= 12) {
fbc->no_fbc_reason = "not supported with PSR2";
return false;
}
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] PR for new GuC v62.0.3 and HuC v7.9.3 binaries
The following changes since commit 0f66b74b6267fce66395316308d88b0535aa3df2: cypress: update firmware for cyw54591 pcie (2021-06-09 07:12:02 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware adlp_updates for you to fetch changes up to 38983b6f28e0b217aedd7c5430081a60d6591732: drm/i915/firmware: Add GuC v62.03 for ADLP (2021-06-25 11:51:11 -0700) Anusha Srivatsa (2): drm/i915/firmware: Add HuC v7.9.3 for TGL drm/i915/firmware: Add GuC v62.03 for ADLP WHENCE | 7 +++ adlp_guc_62.0.3.bin | Bin 0 -> 336704 bytes tgl_huc_7.9.3.bin | Bin 0 -> 589888 bytes 3 files changed, 7 insertions(+) create mode 100644 adlp_guc_62.0.3.bin create mode 100644 tgl_huc_7.9.3.bin ___ 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, drm/ttm: Update the ttm_move_memcpy() interface (rev2)
== Series Details == Series: drm/i915, drm/ttm: Update the ttm_move_memcpy() interface (rev2) URL : https://patchwork.freedesktop.org/series/91893/ State : success == Summary == CI Bug Log - changes from CI_DRM_10282_full -> Patchwork_20471_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_20471_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20471_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_20471_full: ### IGT changes ### Warnings * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1: - shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-iclb7/igt@kms_psr2...@primary-plane-update-sf-dmg-area-1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-1.html Known issues Here are the changes found in Patchwork_20471_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-snb6/igt@gem_cre...@create-massive.html - shard-kbl: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-kbl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-snb2/igt@gem_ctx_persiste...@clone.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb7/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-tglb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +292 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-kbl: NOTRUN -> [FAIL][14] ([i915#3633]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-kbl4/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-apl1/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271]) +123 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-kbl2/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-kbl2/igt@gem_userptr_bl...@dmabuf-sync.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_20471/shard-apl3/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@bb-large: - shard-apl: NOTRUN -> [FAIL][19] ([i915#3296]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/shard-apl1/igt@gen9_exec_pa...@bb-large.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915, drm/ttm: Update the ttm_move_memcpy() interface (rev2)
== Series Details ==
Series: drm/i915, drm/ttm: Update the ttm_move_memcpy() interface (rev2)
URL : https://patchwork.freedesktop.org/series/91893/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10282 -> Patchwork_20471
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/index.html
Known issues
Here are the changes found in Patchwork_20471 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] ([i915#155])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#1372])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {fi-tgl-1115g4}:[DMESG-WARN][5] ([i915#2867]) -> [PASS][6] +14
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10282/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (43 -> 38)
--
Missing(5): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-bsw-cyan
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10282 -> Patchwork_20471
CI-20190529: 20190529
CI_DRM_10282: 67f5a18128770817e4218a9e496d2bf5047c51e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20471: 1d6ea1ed22074aa98ada142f26a6fe4f9f954bc1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1d6ea1ed2207 drm/ttm, drm/i915: Update ttm_move_memcpy for async use
946430347b95 drm/i915/ttm: Reorganize the ttm move code somewhat
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20471/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/47] drm/i915/guc: Optimize CTB writes and reads
On Fri, Jun 25, 2021 at 03:09:29PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail) which could result in accesses across the PCIe bus,
> > store shadow local copies and only read/write the descriptor values when
> > absolutely necessary. Also store the current space in the each channel
> > locally.
> >
Missed two comments, addressed below.
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 ++
> > 2 files changed, 51 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 27ec30b5ef47..1fd5c69358ef 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct
> > guc_ct_buffer_desc *desc)
> > static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> > {
> > ctb->broken = false;
> > + ctb->tail = 0;
> > + ctb->head = 0;
> > + ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> > +
> > guc_ct_buffer_desc_init(ctb->desc);
> > }
> >
> > @@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
> > {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > - u32 head = desc->head;
> > - u32 tail = desc->tail;
> > + u32 tail = ctb->tail;
> > u32 size = ctb->size;
> > - u32 used;
> > u32 header;
> > u32 hxg;
> > u32 *cmds = ctb->cmds;
> > @@ -398,25 +400,14 @@ static int ct_write(struct intel_guc_ct *ct,
> > if (unlikely(desc->status))
> > goto corrupted;
> >
> > - if (unlikely((tail | head) >= size)) {
> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
>
> since we are caching tail, we may want to check if it's sill correct:
>
> tail = READ_ONCE(desc->tail);
> if (unlikely(tail != ctb->tail)) {
> CT_ERROR(ct, "Tail was modified %u != %u\n",
>tail, ctb->tail);
> desc->status |= GUC_CTB_STATUS_MISMATCH;
> goto corrupted;
> }
>
> and since we own the tail then we can be more strict:
>
> GEM_BUG_ON(tail > size);
>
> and then finally just check GuC head:
>
> head = READ_ONCE(desc->head);
> if (unlikely(head >= size)) {
> ...
>
> > + if (unlikely((desc->tail | desc->head) >= size)) {
> > CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> > -head, tail, size);
> > +desc->head, desc->tail, size);
> > desc->status |= GUC_CTB_STATUS_OVERFLOW;
> > goto corrupted;
> > }
> > -
> > - /*
> > -* tail == head condition indicates empty. GuC FW does not support
> > -* using up the entire buffer to get tail == head meaning full.
> > -*/
> > - if (tail < head)
> > - used = (size - head) + tail;
> > - else
> > - used = tail - head;
> > -
> > - /* make sure there is a space including extra dw for the fence */
> > - if (unlikely(used + len + 1 >= size))
> > - return -ENOSPC;
> > +#endif
> >
> > /*
> > * dw0: CT header (including fence)
> > @@ -457,7 +448,9 @@ static int ct_write(struct intel_guc_ct *ct,
> > write_barrier(ct);
> >
> > /* now update descriptor */
> > + ctb->tail = tail;
> > WRITE_ONCE(desc->tail, tail);
> > + ctb->space -= len + 1;
>
> this magic "1" is likely GUC_CTB_MSG_MIN_LEN, right ?
>
> >
> > return 0;
> >
> > @@ -473,7 +466,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > * @req: pointer to pending request
> > * @status:placeholder for status
> > *
> > - * For each sent request, Guc shall send bac CT response message.
> > + * For each sent request, GuC shall send back CT response message.
> > * Our message handler will update status of tracked request once
> > * response message with given fence is received. Wait here and
> > * check for valid response status value.
> > @@ -520,24 +513,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct
> > *ct)
> > return ret;
> > }
> >
> > -static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32
> > len_dw)
> > +static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
> > {
> > - struct guc_ct_buffer_desc *desc = ctb->desc;
> > - u32 head = READ_ONCE(desc->head);
> > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > + u32 head;
> > u32 space;
> >
> > - space = CIRC_SPACE(desc->tail, head, ctb->size);
> > + if (ctb->space >= len_dw)
> > + return true;
> > +
> > + head =
Re: [Intel-gfx] [PATCH 09/47] drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor
On 6/24/2021 00:04, Matthew Brost wrote: Remove old GuC stage descriptor, add lrc descriptor which will be used by the new GuC interface implemented in this patch series. Cc: John Harrison Signed-off-by: Matthew Brost Reviewed-by: John Harrison ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 3:10 PM>To: Ruhl, Michael J >; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > > >On 6/25/21 9:07 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 2:50 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> Hi, Mike, >>> >>> On 6/25/21 7:57 PM, Ruhl, Michael J wrote: > -Original Message- > From: Thomas Hellström > Sent: Friday, June 25, 2021 1:52 PM > To: Ruhl, Michael J ; intel- > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Auld, Matthew > Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map > time > > > On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 12:18 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma- >buf > map >>> time >>> >>> Hi, Michael, >>> >>> thanks for looking at this. >>> >>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: > -Original Message- > From: dri-devel On >>> Behalf > Of > Thomas Hellström > Sent: Thursday, June 24, 2021 2:31 PM > To: intel-gfx@lists.freedesktop.org; dri- >de...@lists.freedesktop.org > Cc: Thomas Hellström ; Auld, >>> Matthew > > Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>> time > Until we support p2p dma or as a complement to that, migrate data > to system memory at dma-buf map time if possible. > > Signed-off-by: Thomas Hellström >>> > --- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > index 616c3a2f1baf..a52f885bc09a 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > @@ -25,7 +25,14 @@ static struct sg_table >>> *i915_gem_map_dma_buf(struct > dma_buf_attachment *attachme > struct scatterlist *src, *dst; > int ret, i; > > - ret = i915_gem_object_pin_pages_unlocked(obj); > + ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. >>> Yes, I agree, In particular for other instances of our own driver, at >>> least since the dma_resv introduction. >>> >>> But I also think that's a pre-existing bug, since >>> i915_gem_object_pin_pages_unlocked() will also take the lock. >> Ouch yes. Missed that. >> >>> I Think we need to initially make the exporter dynamic-capable to >>> resolve this, and drop the locking here completely, as dma-buf docs >says >>> that we're then guaranteed to get called with the object lock held. >>> >>> I figure if we make the exporter dynamic, we need to migrate already >at >>> dma_buf_pin time so we don't pin the object in the wrong location. >> The exporter as dynamic (ops->pin is available) is optional, but >importer >> dynamic (ops->move_notify) is required. >> >> With that in mind, it would seem that there are three possible >>> combinations >> for the migrate to be attempted: >> >> 1) in the ops->pin function (export_dynamic != import_dynamic, >during > attach) >> 2) in the ops->pin function (export_dynamic and > !CONFIG_DMABUF_MOVE_NOTIFY) during mapping >> 3) and possibly in ops->map_dma_buf (exort_dynamic iand > CONFIG_DMABUF_MOVE_NOTIFY) >> Since one possibility has to be in the mapping function, it seems that if >we >> can figure out the locking, that the migrate should probably be >available > here. >> Mike > So perhaps just to initially fix the bug, we could just implement NOP > pin() and unpin() callbacks and drop the locking in map_attach() and > replace it with an assert_object_held(); That is the sticky part of the move notify API. If you do the attach_dynamic you have to have an ops with move_notify. (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma- >>> buf.c#L730) If you don't have that, i.e. just
Re: [Intel-gfx] [PATCH 43/47] drm/i915/guc: Hook GuC scheduling policies up
On 6/24/2021 17:59, Matthew Brost wrote:
On Thu, Jun 24, 2021 at 12:05:12AM -0700, Matthew Brost wrote:
From: John Harrison
Use the official driver default scheduling policies for configuring
the GuC scheduler rather than a bunch of hardcoded values.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Cc: Jose Souza
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 44 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++--
4 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 0ceffa2be7a7..37db857bb56c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -455,6 +455,7 @@ struct intel_engine_cs {
#define I915_ENGINE_IS_VIRTUAL BIT(5)
#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(6)
#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7)
+#define I915_ENGINE_WANT_FORCED_PREEMPTION BIT(8)
unsigned int flags;
/*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index c38365cd5fab..905ecbc7dbe3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -270,6 +270,8 @@ int intel_guc_engine_failure_process_msg(struct intel_guc
*guc,
void intel_guc_find_hung_context(struct intel_engine_cs *engine);
+int intel_guc_global_policies_update(struct intel_guc *guc);
+
void intel_guc_submission_reset_prepare(struct intel_guc *guc);
void intel_guc_submission_reset(struct intel_guc *guc, bool stalled);
void intel_guc_submission_reset_finish(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d3e86ab7508f..2ad5fcd4e1b7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -77,14 +77,54 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
guc_ads_private_data_size(guc);
}
-static void guc_policies_init(struct guc_policies *policies)
+static void guc_policies_init(struct intel_guc *guc, struct guc_policies
*policies)
{
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct drm_i915_private *i915 = gt->i915;
+
policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
+
policies->global_flags = 0;
+ if (i915->params.reset < 2)
+ policies->global_flags |= GLOBAL_POLICY_DISABLE_ENGINE_RESET;
+
policies->is_valid = 1;
}
+static int guc_action_policies_update(struct intel_guc *guc, u32 policy_offset)
+{
+ u32 action[] = {
+ INTEL_GUC_ACTION_GLOBAL_SCHED_POLICY_CHANGE,
+ policy_offset
+ };
+
+ return intel_guc_send(guc, action, ARRAY_SIZE(action));
+}
+
+int intel_guc_global_policies_update(struct intel_guc *guc)
+{
+ struct __guc_ads_blob *blob = guc->ads_blob;
+ struct intel_gt *gt = guc_to_gt(guc);
+ intel_wakeref_t wakeref;
+ int ret;
+
+ if (!blob)
+ return -ENOTSUPP;
+
+ GEM_BUG_ON(!blob->ads.scheduler_policies);
+
+ guc_policies_init(guc, >policies);
+
+ if (!intel_guc_is_ready(guc))
+ return 0;
+
+ with_intel_runtime_pm(>i915->runtime_pm, wakeref)
+ ret = guc_action_policies_update(guc,
blob->ads.scheduler_policies);
+
+ return ret;
+}
+
static void guc_mapping_table_init(struct intel_gt *gt,
struct guc_gt_system_info *system_info)
{
@@ -281,7 +321,7 @@ static void __guc_ads_init(struct intel_guc *guc)
u8 engine_class, guc_class;
/* GuC scheduling policies */
- guc_policies_init(>policies);
+ guc_policies_init(guc, >policies);
/*
* GuC expects a per-engine-class context image and size
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 6188189314d5..a427336ce916 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -873,6 +873,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
*guc)
GEM_WARN_ON(atomic_read(>outstanding_submission_g2h));
atomic_set(>outstanding_submission_g2h, 0);
+ intel_guc_global_policies_update(guc);
enable_submission(guc);
intel_gt_unpark_heartbeats(guc_to_gt(guc));
}
@@ -1161,8 +1162,12 @@ static void guc_context_policy_init(struct
intel_engine_cs *engine,
{
desc->policy_flags = 0;
- desc->execution_quantum = CONTEXT_POLICY_DEFAULT_EXECUTION_QUANTUM_US;
- desc->preemption_timeout = CONTEXT_POLICY_DEFAULT_PREEMPTION_TIME_US;
+ if (engine->flags &
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
On 6/25/21 9:07 PM, Ruhl, Michael J wrote: -Original Message- From: Thomas Hellström Sent: Friday, June 25, 2021 2:50 PM To: Ruhl, Michael J ; intel- g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Auld, Matthew Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Hi, Mike, On 6/25/21 7:57 PM, Ruhl, Michael J wrote: -Original Message- From: Thomas Hellström Sent: Friday, June 25, 2021 1:52 PM To: Ruhl, Michael J ; intel- g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Auld, Matthew Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time On 6/25/21 7:38 PM, Ruhl, Michael J wrote: -Original Message- From: Thomas Hellström Sent: Friday, June 25, 2021 12:18 PM To: Ruhl, Michael J ; intel- g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Auld, Matthew Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Hi, Michael, thanks for looking at this. On 6/25/21 6:02 PM, Ruhl, Michael J wrote: -Original Message- From: dri-devel On Behalf Of Thomas Hellström Sent: Thursday, June 24, 2021 2:31 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Thomas Hellström ; Auld, Matthew Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf map time if possible. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index 616c3a2f1baf..a52f885bc09a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme struct scatterlist *src, *dst; int ret, i; - ret = i915_gem_object_pin_pages_unlocked(obj); + ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. Yes, I agree, In particular for other instances of our own driver, at least since the dma_resv introduction. But I also think that's a pre-existing bug, since i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. I Think we need to initially make the exporter dynamic-capable to resolve this, and drop the locking here completely, as dma-buf docs says that we're then guaranteed to get called with the object lock held. I figure if we make the exporter dynamic, we need to migrate already at dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during attach) 2) in the ops->pin function (export_dynamic and !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available here. Mike So perhaps just to initially fix the bug, we could just implement NOP pin() and unpin() callbacks and drop the locking in map_attach() and replace it with an assert_object_held(); That is the sticky part of the move notify API. If you do the attach_dynamic you have to have an ops with move_notify. (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma- buf.c#L730) If you don't have that, i.e. just the pin interface, the attach will be rejected, and you will not get the callbacks. I understood that as the requirement for move_notify is only if the *importer* declares dynamic. A dynamic exporter could choose whether to call move_notify() on eviction or to pin and never evict. If the importer is non-dynamic, the core calls pin() and the only choice is to pin and never evict. So if we temporarily choose to pin and never evict for *everything*, (as the current code does now), I think we should be good for now, and then we can implement all fancy p2p and move_notify stuff on top of that. /sigh. You are correct. I was mistakenly placing the pin API (dma_buf_ops) in the attach_ops. Must be Friday. Upon further reflection, I think that your path will work. However, is doing a pin (with no locking) from the dma_buf_mapping any different from using the pin API + export_dynamic? M Yes, it's different for dynamic importers only that would otherwise never pin, and we could mistakenly evict the object without having implemented calling move_notify. If we
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 2:50 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > >Hi, Mike, > >On 6/25/21 7:57 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 1:52 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> >>> On 6/25/21 7:38 PM, Ruhl, Michael J wrote: > -Original Message- > From: Thomas Hellström > Sent: Friday, June 25, 2021 12:18 PM > To: Ruhl, Michael J ; intel- > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Auld, Matthew > Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map > time > > Hi, Michael, > > thanks for looking at this. > > On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: dri-devel On >Behalf >>> Of >>> Thomas Hellström >>> Sent: Thursday, June 24, 2021 2:31 PM >>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Thomas Hellström ; Auld, > Matthew >>> >>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map > time >>> Until we support p2p dma or as a complement to that, migrate data >>> to system memory at dma-buf map time if possible. >>> >>> Signed-off-by: Thomas Hellström > >>> --- >>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> index 616c3a2f1baf..a52f885bc09a 100644 >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> @@ -25,7 +25,14 @@ static struct sg_table > *i915_gem_map_dma_buf(struct >>> dma_buf_attachment *attachme >>> struct scatterlist *src, *dst; >>> int ret, i; >>> >>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >> Hmm, I believe in most cases that the caller should be holding the >> lock (object dma-resv) on this object already. > Yes, I agree, In particular for other instances of our own driver, at > least since the dma_resv introduction. > > But I also think that's a pre-existing bug, since > i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. > I Think we need to initially make the exporter dynamic-capable to > resolve this, and drop the locking here completely, as dma-buf docs says > that we're then guaranteed to get called with the object lock held. > > I figure if we make the exporter dynamic, we need to migrate already at > dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible >combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during >>> attach) 2) in the ops->pin function (export_dynamic and >>> !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand >>> CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available >>> here. Mike >>> So perhaps just to initially fix the bug, we could just implement NOP >>> pin() and unpin() callbacks and drop the locking in map_attach() and >>> replace it with an assert_object_held(); >> That is the sticky part of the move notify API. >> >> If you do the attach_dynamic you have to have an ops with move_notify. >> >> (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma- >buf.c#L730) >> >> If you don't have that, i.e. just the pin interface, the attach will be >> rejected, and you will not get the callbacks. > >I understood that as the requirement for move_notify is only if the >*importer* declares dynamic. A dynamic exporter could choose whether to >call move_notify() on eviction or to pin and never evict. If the >importer is non-dynamic, the core calls pin() and the only choice is to >pin and never evict. > >So if we temporarily choose to pin and never evict for *everything*, (as >the current code does now), I think we should be good for now, and then >we can implement all fancy p2p
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
Hi, Mike, On 6/25/21 7:57 PM, Ruhl, Michael J wrote: -Original Message- From: Thomas Hellström Sent: Friday, June 25, 2021 1:52 PM To: Ruhl, Michael J ; intel- g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Auld, Matthew Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time On 6/25/21 7:38 PM, Ruhl, Michael J wrote: -Original Message- From: Thomas Hellström Sent: Friday, June 25, 2021 12:18 PM To: Ruhl, Michael J ; intel- g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Auld, Matthew Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Hi, Michael, thanks for looking at this. On 6/25/21 6:02 PM, Ruhl, Michael J wrote: -Original Message- From: dri-devel On Behalf Of Thomas Hellström Sent: Thursday, June 24, 2021 2:31 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Thomas Hellström ; Auld, Matthew Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf map time if possible. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index 616c3a2f1baf..a52f885bc09a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme struct scatterlist *src, *dst; int ret, i; - ret = i915_gem_object_pin_pages_unlocked(obj); + ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. Yes, I agree, In particular for other instances of our own driver, at least since the dma_resv introduction. But I also think that's a pre-existing bug, since i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. I Think we need to initially make the exporter dynamic-capable to resolve this, and drop the locking here completely, as dma-buf docs says that we're then guaranteed to get called with the object lock held. I figure if we make the exporter dynamic, we need to migrate already at dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during attach) 2) in the ops->pin function (export_dynamic and !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available here. Mike So perhaps just to initially fix the bug, we could just implement NOP pin() and unpin() callbacks and drop the locking in map_attach() and replace it with an assert_object_held(); That is the sticky part of the move notify API. If you do the attach_dynamic you have to have an ops with move_notify. (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma-buf.c#L730) If you don't have that, i.e. just the pin interface, the attach will be rejected, and you will not get the callbacks. I understood that as the requirement for move_notify is only if the *importer* declares dynamic. A dynamic exporter could choose whether to call move_notify() on eviction or to pin and never evict. If the importer is non-dynamic, the core calls pin() and the only choice is to pin and never evict. So if we temporarily choose to pin and never evict for *everything*, (as the current code does now), I think we should be good for now, and then we can implement all fancy p2p and move_notify stuff on top of that. /Thomas So I think that the only thing we can do for now is to dop the locking and add the assert_object_held(); M /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/47] drm/i915/guc: Optimize CTB writes and reads
On Fri, Jun 25, 2021 at 03:09:29PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail) which could result in accesses across the PCIe bus,
> > store shadow local copies and only read/write the descriptor values when
> > absolutely necessary. Also store the current space in the each channel
> > locally.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 ++
> > 2 files changed, 51 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 27ec30b5ef47..1fd5c69358ef 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct
> > guc_ct_buffer_desc *desc)
> > static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> > {
> > ctb->broken = false;
> > + ctb->tail = 0;
> > + ctb->head = 0;
> > + ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> > +
> > guc_ct_buffer_desc_init(ctb->desc);
> > }
> >
> > @@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
> > {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > - u32 head = desc->head;
> > - u32 tail = desc->tail;
> > + u32 tail = ctb->tail;
> > u32 size = ctb->size;
> > - u32 used;
> > u32 header;
> > u32 hxg;
> > u32 *cmds = ctb->cmds;
> > @@ -398,25 +400,14 @@ static int ct_write(struct intel_guc_ct *ct,
> > if (unlikely(desc->status))
> > goto corrupted;
> >
> > - if (unlikely((tail | head) >= size)) {
> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
>
> since we are caching tail, we may want to check if it's sill correct:
>
> tail = READ_ONCE(desc->tail);
> if (unlikely(tail != ctb->tail)) {
> CT_ERROR(ct, "Tail was modified %u != %u\n",
>tail, ctb->tail);
> desc->status |= GUC_CTB_STATUS_MISMATCH;
> goto corrupted;
> }
>
> and since we own the tail then we can be more strict:
>
> GEM_BUG_ON(tail > size);
>
> and then finally just check GuC head:
>
> head = READ_ONCE(desc->head);
> if (unlikely(head >= size)) {
> ...
>
Sure, but still hidden behind CONFIG_DRM_I915_DEBUG_GUC, right?
> > + if (unlikely((desc->tail | desc->head) >= size)) {
> > CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> > -head, tail, size);
> > +desc->head, desc->tail, size);
> > desc->status |= GUC_CTB_STATUS_OVERFLOW;
> > goto corrupted;
> > }
> > -
> > - /*
> > -* tail == head condition indicates empty. GuC FW does not support
> > -* using up the entire buffer to get tail == head meaning full.
> > -*/
> > - if (tail < head)
> > - used = (size - head) + tail;
> > - else
> > - used = tail - head;
> > -
> > - /* make sure there is a space including extra dw for the fence */
> > - if (unlikely(used + len + 1 >= size))
> > - return -ENOSPC;
> > +#endif
> >
> > /*
> > * dw0: CT header (including fence)
> > @@ -457,7 +448,9 @@ static int ct_write(struct intel_guc_ct *ct,
> > write_barrier(ct);
> >
> > /* now update descriptor */
> > + ctb->tail = tail;
> > WRITE_ONCE(desc->tail, tail);
> > + ctb->space -= len + 1;
>
> this magic "1" is likely GUC_CTB_MSG_MIN_LEN, right ?
>
Yes.
> >
> > return 0;
> >
> > @@ -473,7 +466,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > * @req: pointer to pending request
> > * @status:placeholder for status
> > *
> > - * For each sent request, Guc shall send bac CT response message.
> > + * For each sent request, GuC shall send back CT response message.
> > * Our message handler will update status of tracked request once
> > * response message with given fence is received. Wait here and
> > * check for valid response status value.
> > @@ -520,24 +513,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct
> > *ct)
> > return ret;
> > }
> >
> > -static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32
> > len_dw)
> > +static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
> > {
> > - struct guc_ct_buffer_desc *desc = ctb->desc;
> > - u32 head = READ_ONCE(desc->head);
> > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > + u32 head;
> > u32 space;
> >
> > - space = CIRC_SPACE(desc->tail, head, ctb->size);
> > + if (ctb->space >= len_dw)
> > + return true;
> > +
> >
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On Fri, Jun 25, 2021 at 01:50:21PM +0200, Michal Wajdeczko wrote:
>
>
> On 25.06.2021 00:41, Matthew Brost wrote:
> > On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 24.06.2021 17:49, Matthew Brost wrote:
> >>> On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> > will send CTBs in the critical path and does not need to wait for these
> > CTBs to complete before moving on, hence the need for this new function.
> >
> > The non-blocking CTB now must have a flow control mechanism to ensure
> > the buffer isn't overrun. A lazy spin wait is used as we believe the
> > flow control condition should be rare with a properly sized buffer.
> >
> > The function, intel_guc_send_nb, is exported in this patch but unused.
> > Several patches later in the series make use of this function.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
> > 3 files changed, 82 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 4abc59f6f3cd..24b1df6ad4ae 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
> > intel_guc_log *log)
> > static
> > inline int intel_guc_send(struct intel_guc *guc, const u32 *action,
> > u32 len)
> > {
> > - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> > + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> > +}
> > +
> > +#define INTEL_GUC_SEND_NB BIT(31)
>
> hmm, this flag really belongs to intel_guc_ct_send() so it should be
> defined as CTB flag near that function declaration
>
> >>>
> >>> I can move this up a few lines.
> >>>
> > +static
> > +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action,
> > u32 len)
> > +{
> > + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> > +INTEL_GUC_SEND_NB);
> > }
> >
> > static inline int
> > @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc,
> > const u32 *action, u32 len,
> >u32 *response_buf, u32 response_buf_size)
> > {
> > return intel_guc_ct_send(>ct, action, len,
> > -response_buf, response_buf_size);
> > +response_buf, response_buf_size, 0);
> > }
> >
> > static inline void intel_guc_to_host_event_handler(struct intel_guc
> > *guc)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index a17215920e58..c9a65d05911f 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -3,6 +3,11 @@
> > * Copyright © 2016-2019 Intel Corporation
> > */
> >
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > #include "i915_drv.h"
> > #include "intel_guc_ct.h"
> > #include "gt/intel_gt.h"
> > @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
> > static int ct_write(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len /* in dwords */,
> > - u32 fence)
> > + u32 fence, u32 flags)
> > {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
> > FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> > FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> >
> > - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> > - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > -GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> > + hxg = (flags & INTEL_GUC_SEND_NB) ?
> > + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> > +FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> > + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
> > + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> > +FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > +
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 1:52 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > > >On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 12:18 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> Hi, Michael, >>> >>> thanks for looking at this. >>> >>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: > -Original Message- > From: dri-devel On Behalf >Of > Thomas Hellström > Sent: Thursday, June 24, 2021 2:31 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Thomas Hellström ; Auld, >>> Matthew > > Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >>> time > Until we support p2p dma or as a complement to that, migrate data > to system memory at dma-buf map time if possible. > > Signed-off-by: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > index 616c3a2f1baf..a52f885bc09a 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > @@ -25,7 +25,14 @@ static struct sg_table >>> *i915_gem_map_dma_buf(struct > dma_buf_attachment *attachme > struct scatterlist *src, *dst; > int ret, i; > > - ret = i915_gem_object_pin_pages_unlocked(obj); > + ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. >>> Yes, I agree, In particular for other instances of our own driver, at >>> least since the dma_resv introduction. >>> >>> But I also think that's a pre-existing bug, since >>> i915_gem_object_pin_pages_unlocked() will also take the lock. >> Ouch yes. Missed that. >> >>> I Think we need to initially make the exporter dynamic-capable to >>> resolve this, and drop the locking here completely, as dma-buf docs says >>> that we're then guaranteed to get called with the object lock held. >>> >>> I figure if we make the exporter dynamic, we need to migrate already at >>> dma_buf_pin time so we don't pin the object in the wrong location. >> The exporter as dynamic (ops->pin is available) is optional, but importer >> dynamic (ops->move_notify) is required. >> >> With that in mind, it would seem that there are three possible combinations >> for the migrate to be attempted: >> >> 1) in the ops->pin function (export_dynamic != import_dynamic, during >attach) >> 2) in the ops->pin function (export_dynamic and >!CONFIG_DMABUF_MOVE_NOTIFY) during mapping >> 3) and possibly in ops->map_dma_buf (exort_dynamic iand >CONFIG_DMABUF_MOVE_NOTIFY) >> >> Since one possibility has to be in the mapping function, it seems that if we >> can figure out the locking, that the migrate should probably be available >here. >> >> Mike > >So perhaps just to initially fix the bug, we could just implement NOP >pin() and unpin() callbacks and drop the locking in map_attach() and >replace it with an assert_object_held(); That is the sticky part of the move notify API. If you do the attach_dynamic you have to have an ops with move_notify. (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma-buf.c#L730) If you don't have that, i.e. just the pin interface, the attach will be rejected, and you will not get the callbacks. So I think that the only thing we can do for now is to dop the locking and add the assert_object_held(); M >/Thomas > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/47] drm/i915/guc: Implement GuC context operations for new inteface
On Fri, Jun 25, 2021 at 03:25:13PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Implement GuC context operations which includes GuC specific operations
> > alloc, pin, unpin, and destroy.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 5 +
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 22 +-
> > drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 1 -
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 34 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 664 --
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/i915_request.c | 1 +
> > 8 files changed, 677 insertions(+), 55 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 4033184f13b9..2b68af16222c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -383,6 +383,11 @@ intel_context_init(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> >
> > mutex_init(>pin_mutex);
> >
> > + spin_lock_init(>guc_state.lock);
> > +
> > + ce->guc_id = GUC_INVALID_LRC_ID;
> > + INIT_LIST_HEAD(>guc_id_link);
> > +
> > i915_active_init(>active,
> > __intel_context_active, __intel_context_retire, 0);
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index bb6fef7eae52..ce7c69b34cd1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -95,6 +95,7 @@ struct intel_context {
> > #define CONTEXT_BANNED 6
> > #define CONTEXT_FORCE_SINGLE_SUBMISSION7
> > #define CONTEXT_NOPREEMPT 8
> > +#define CONTEXT_LRCA_DIRTY 9
> >
> > struct {
> > u64 timeout_us;
> > @@ -137,14 +138,29 @@ struct intel_context {
> >
> > u8 wa_bb_page; /* if set, page num reserved for context workarounds */
> >
> > + struct {
> > + /** lock: protects everything in guc_state */
> > + spinlock_t lock;
> > + /**
> > +* sched_state: scheduling state of this context using GuC
> > +* submission
> > +*/
> > + u8 sched_state;
> > + } guc_state;
> > +
> > /* GuC scheduling state that does not require a lock. */
> > atomic_t guc_sched_state_no_lock;
> >
> > + /* GuC lrc descriptor ID */
> > + u16 guc_id;
> > +
> > + /* GuC lrc descriptor reference count */
> > + atomic_t guc_id_ref;
> > +
> > /*
> > -* GuC lrc descriptor ID - Not assigned in this patch but future patches
> > -* in the series will.
> > +* GuC ID link - in list when unpinned but guc_id still valid in GuC
> > */
> > - u16 guc_id;
> > + struct list_head guc_id_link;
>
> some fields are being added with kerneldoc, some without
> what's the rule ?
>
Yea, idk. I think we need to scrub all the structures in the driver and
add kernel doc everywhere. IMO not a blocker too as I think all the
structures are going to be reworked with OO concepts after the GuC code
lands before moving to DRM scheduler. That would be logical time to
update all the kernel doc too.
> > };
> >
> > #endif /* __INTEL_CONTEXT_TYPES__ */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> > b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> > index 41e5350a7a05..49d4857ad9b7 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> > @@ -87,7 +87,6 @@
> > #define GEN11_CSB_WRITE_PTR_MASK (GEN11_CSB_PTR_MASK << 0)
> >
> > #define MAX_CONTEXT_HW_ID (1 << 21) /* exclusive */
> > -#define MAX_GUC_CONTEXT_HW_ID (1 << 20) /* exclusive */
> > #define GEN11_MAX_CONTEXT_HW_ID(1 << 11) /* exclusive */
> > /* in Gen12 ID 0x7FF is reserved to indicate idle */
> > #define GEN12_MAX_CONTEXT_HW_ID(GEN11_MAX_CONTEXT_HW_ID - 1)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 9ba8219475b2..d44316dc914b 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -44,6 +44,14 @@ struct intel_guc {
> > void (*disable)(struct intel_guc *guc);
> > } interrupts;
> >
> > + /*
> > +* contexts_lock protects the pool of free guc ids and a linked list of
> > +* guc ids available to be stolen
> > +*/
> > + spinlock_t contexts_lock;
> > + struct ida guc_ids;
> > + struct list_head guc_id_list;
> > +
> > bool submission_selected;
> >
> > struct i915_vma *ads_vma;
> > @@ -102,6 +110,29 @@ intel_guc_send_and_receive(struct intel_guc *guc,
> > const u32 *action, u32 len,
> >
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
On 6/25/21 7:38 PM, Ruhl, Michael J wrote: -Original Message- From: Thomas Hellström Sent: Friday, June 25, 2021 12:18 PM To: Ruhl, Michael J ; intel- g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Auld, Matthew Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Hi, Michael, thanks for looking at this. On 6/25/21 6:02 PM, Ruhl, Michael J wrote: -Original Message- From: dri-devel On Behalf Of Thomas Hellström Sent: Thursday, June 24, 2021 2:31 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Thomas Hellström ; Auld, Matthew Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf map time if possible. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index 616c3a2f1baf..a52f885bc09a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme struct scatterlist *src, *dst; int ret, i; - ret = i915_gem_object_pin_pages_unlocked(obj); + ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. Yes, I agree, In particular for other instances of our own driver, at least since the dma_resv introduction. But I also think that's a pre-existing bug, since i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. I Think we need to initially make the exporter dynamic-capable to resolve this, and drop the locking here completely, as dma-buf docs says that we're then guaranteed to get called with the object lock held. I figure if we make the exporter dynamic, we need to migrate already at dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during attach) 2) in the ops->pin function (export_dynamic and !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available here. Mike So perhaps just to initially fix the bug, we could just implement NOP pin() and unpin() callbacks and drop the locking in map_attach() and replace it with an assert_object_held(); /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 12:18 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > >Hi, Michael, > >thanks for looking at this. > >On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: dri-devel On Behalf Of >>> Thomas Hellström >>> Sent: Thursday, June 24, 2021 2:31 PM >>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Thomas Hellström ; Auld, >Matthew >>> >>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time >>> >>> Until we support p2p dma or as a complement to that, migrate data >>> to system memory at dma-buf map time if possible. >>> >>> Signed-off-by: Thomas Hellström >>> --- >>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> index 616c3a2f1baf..a52f885bc09a 100644 >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> @@ -25,7 +25,14 @@ static struct sg_table >*i915_gem_map_dma_buf(struct >>> dma_buf_attachment *attachme >>> struct scatterlist *src, *dst; >>> int ret, i; >>> >>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >> Hmm, I believe in most cases that the caller should be holding the >> lock (object dma-resv) on this object already. > >Yes, I agree, In particular for other instances of our own driver, at >least since the dma_resv introduction. > >But I also think that's a pre-existing bug, since >i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. >I Think we need to initially make the exporter dynamic-capable to >resolve this, and drop the locking here completely, as dma-buf docs says >that we're then guaranteed to get called with the object lock held. > >I figure if we make the exporter dynamic, we need to migrate already at >dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during attach) 2) in the ops->pin function (export_dynamic and !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available here. Mike >/Thomas > > >> >> I know for the dynamic version of dma-buf, there is a check to make >> sure that the lock is held when called. >> >> I think you will run into some issues if you try to get it here as well. >> >> Mike >> >>> + if (ret) >>> + return ERR_PTR(ret); >>> + >>> + ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >>> + if (!ret) >>> + ret = i915_gem_object_pin_pages(obj); >>> + i915_gem_object_unlock(obj); >>> if (ret) >>> goto err; >>> >>> -- >>> 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/47] drm/i915/guc: Add lrc descriptor context lookup array
On Fri, Jun 25, 2021 at 03:17:51PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Add lrc descriptor context lookup array which can resolve the
> > intel_context from the lrc descriptor index. In addition to lookup, it
> > can determine in the lrc descriptor context is currently registered with
> > the GuC by checking if an entry for a descriptor index is present.
> > Future patches in the series will make use of this array.
>
> s/lrc/LRC
>
I guess? lrc and LRC are used interchangeably throughout the current
code base.
> >
> > Cc: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +++
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 +--
> > 2 files changed, 35 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index b28fa54214f2..2313d9fc087b 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -6,6 +6,8 @@
> > #ifndef _INTEL_GUC_H_
> > #define _INTEL_GUC_H_
> >
> > +#include "linux/xarray.h"
>
> #include
>
Yep.
> > +
> > #include "intel_uncore.h"
> > #include "intel_guc_fw.h"
> > #include "intel_guc_fwif.h"
> > @@ -46,6 +48,9 @@ struct intel_guc {
> > struct i915_vma *lrc_desc_pool;
> > void *lrc_desc_pool_vaddr;
> >
> > + /* guc_id to intel_context lookup */
> > + struct xarray context_lookup;
> > +
> > /* Control params for fw initialization */
> > u32 params[GUC_CTL_MAX_DWORDS];
>
> btw, IIRC there was idea to move most struct definitions to
> intel_guc_types.h, is this still a plan ?
>
I don't ever recall discussing this but we can certainly do this. For
what it is worth we do introduce intel_guc_submission_types.h a bit
later. I'll make a note about intel_guc_types.h though.
Matt
> >
> > 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 a366890fb840..23a94a896a0b 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -65,8 +65,6 @@ static inline struct i915_priolist *to_priolist(struct
> > rb_node *rb)
> > return rb_entry(rb, struct i915_priolist, node);
> > }
> >
> > -/* Future patches will use this function */
> > -__attribute__ ((unused))
> > static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc *guc, u32
> > index)
> > {
> > struct guc_lrc_desc *base = guc->lrc_desc_pool_vaddr;
> > @@ -76,6 +74,15 @@ static struct guc_lrc_desc *__get_lrc_desc(struct
> > intel_guc *guc, u32 index)
> > return [index];
> > }
> >
> > +static inline struct intel_context *__get_context(struct intel_guc *guc,
> > u32 id)
> > +{
> > + struct intel_context *ce = xa_load(>context_lookup, id);
> > +
> > + GEM_BUG_ON(id >= GUC_MAX_LRC_DESCRIPTORS);
> > +
> > + return ce;
> > +}
> > +
> > static int guc_lrc_desc_pool_create(struct intel_guc *guc)
> > {
> > u32 size;
> > @@ -96,6 +103,25 @@ static void guc_lrc_desc_pool_destroy(struct intel_guc
> > *guc)
> > i915_vma_unpin_and_release(>lrc_desc_pool, I915_VMA_RELEASE_MAP);
> > }
> >
> > +static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)
> > +{
> > + struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
> > +
> > + memset(desc, 0, sizeof(*desc));
> > + xa_erase_irq(>context_lookup, id);
> > +}
> > +
> > +static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)
> > +{
> > + return __get_context(guc, id);
> > +}
> > +
> > +static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
> > + struct intel_context *ce)
> > +{
> > + xa_store_irq(>context_lookup, id, ce, GFP_ATOMIC);
> > +}
> > +
> > static void guc_add_request(struct intel_guc *guc, struct i915_request *rq)
> > {
> > /* Leaving stub as this function will be used in future patches */
> > @@ -400,6 +426,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
> > */
> > GEM_BUG_ON(!guc->lrc_desc_pool);
> >
> > + xa_init_flags(>context_lookup, XA_FLAGS_LOCK_IRQ);
> > +
> > return 0;
> > }
> >
> >
___
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 [v2,1/2] drm/i915/gem: only allow WC for lmem
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
URL : https://patchwork.freedesktop.org/series/91921/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10281_full -> Patchwork_20470_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_20470_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20470_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_20470_full:
### IGT changes ###
Warnings
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1:
- shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb5/igt@kms_psr2...@overlay-primary-update-sf-dmg-area-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb2/igt@kms_psr2...@overlay-primary-update-sf-dmg-area-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@suspend:
- {shard-rkl-1}: NOTRUN -> [FAIL][3] +47 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@gem_...@suspend.html
* igt@gem_eio@unwedge-stress:
- {shard-rkl-1}: NOTRUN -> [TIMEOUT][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@gem_...@unwedge-stress.html
* igt@gem_exec_parallel@fds@rcs0:
- {shard-rkl-6}: NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@gem_exec_parallel@f...@rcs0.html
* igt@gem_exec_suspend@basic-s3-devices:
- {shard-rkl-6}: NOTRUN -> [FAIL][6] +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@gem_exec_susp...@basic-s3-devices.html
* igt@gem_mmap_wc@set-cache-level:
- {shard-rkl-2}: NOTRUN -> [SKIP][7] +78 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-2/igt@gem_mmap...@set-cache-level.html
* {igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs}:
- {shard-rkl-2}: NOTRUN -> [FAIL][8] +39 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-2/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* {igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs}:
- {shard-rkl-6}: NOTRUN -> [SKIP][9] +9 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs.html
* {igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc}:
- {shard-rkl-5}: NOTRUN -> [FAIL][10] +42 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-5/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
- {shard-rkl-1}: NOTRUN -> [INCOMPLETE][11] +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-16bpp-ytile.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
- {shard-rkl-5}: NOTRUN -> [INCOMPLETE][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-5/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-32bpp-ytilercccs.html
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
- {shard-rkl-1}: NOTRUN -> [SKIP][13] +236 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html
* igt@kms_hdr@static-toggle-dpms:
- {shard-rkl-6}: NOTRUN -> [DMESG-WARN][14]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@kms_...@static-toggle-dpms.html
* igt@kms_plane@plane-position-hole-dpms@pipe-b-planes:
- {shard-rkl-5}: NOTRUN -> [SKIP][15] +94 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-5/igt@kms_plane@plane-position-hole-d...@pipe-b-planes.html
Known issues
Here are the changes found in Patchwork_20470_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_create@create-massive:
- shard-snb: NOTRUN -> [DMESG-WARN][16] ([i915#3002])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb2/igt@gem_cre...@create-massive.html
* igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#1099]) +5
similar issues
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
Hi, Michael, thanks for looking at this. On 6/25/21 6:02 PM, Ruhl, Michael J wrote: -Original Message- From: dri-devel On Behalf Of Thomas Hellström Sent: Thursday, June 24, 2021 2:31 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Cc: Thomas Hellström ; Auld, Matthew Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf map time if possible. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index 616c3a2f1baf..a52f885bc09a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme struct scatterlist *src, *dst; int ret, i; - ret = i915_gem_object_pin_pages_unlocked(obj); + ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. Yes, I agree, In particular for other instances of our own driver, at least since the dma_resv introduction. But I also think that's a pre-existing bug, since i915_gem_object_pin_pages_unlocked() will also take the lock. I Think we need to initially make the exporter dynamic-capable to resolve this, and drop the locking here completely, as dma-buf docs says that we're then guaranteed to get called with the object lock held. I figure if we make the exporter dynamic, we need to migrate already at dma_buf_pin time so we don't pin the object in the wrong location. /Thomas I know for the dynamic version of dma-buf, there is a check to make sure that the lock is held when called. I think you will run into some issues if you try to get it here as well. Mike + if (ret) + return ERR_PTR(ret); + + ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); + if (!ret) + ret = i915_gem_object_pin_pages(obj); + i915_gem_object_unlock(obj); if (ret) goto err; -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: dri-devel On Behalf Of >Thomas Hellström >Sent: Thursday, June 24, 2021 2:31 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Thomas Hellström ; Auld, Matthew > >Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time > >Until we support p2p dma or as a complement to that, migrate data >to system memory at dma-buf map time if possible. > >Signed-off-by: Thomas Hellström >--- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >index 616c3a2f1baf..a52f885bc09a 100644 >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >@@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct >dma_buf_attachment *attachme > struct scatterlist *src, *dst; > int ret, i; > >- ret = i915_gem_object_pin_pages_unlocked(obj); >+ ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. I know for the dynamic version of dma-buf, there is a check to make sure that the lock is held when called. I think you will run into some issues if you try to get it here as well. Mike >+ if (ret) >+ return ERR_PTR(ret); >+ >+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >+ if (!ret) >+ ret = i915_gem_object_pin_pages(obj); >+ i915_gem_object_unlock(obj); > if (ret) > goto err; > >-- >2.31.1 ___ 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 [v3,1/2] drm/i915: support forcing the page size with lmem
== Series Details == Series: series starting with [v3,1/2] drm/i915: support forcing the page size with lmem URL : https://patchwork.freedesktop.org/series/91918/ State : success == Summary == CI Bug Log - changes from CI_DRM_10280_full -> Patchwork_20469_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_20469_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20469_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_20469_full: ### IGT changes ### Warnings * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4: - shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-iclb8/igt@kms_psr2...@primary-plane-update-sf-dmg-area-4.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-4.html Known issues Here are the changes found in Patchwork_20469_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-glk8/igt@gem_exec_f...@basic-deadline.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-glk1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-glk6/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][10] ([i915#3633]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-apl2/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_mmap_gtt@big-copy: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#307]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-skl4/igt@gem_mmap_...@big-copy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-skl2/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_offset@clear: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#3160]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-iclb4/igt@gem_mmap_off...@clear.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-iclb3/igt@gem_mmap_off...@clear.html * igt@gem_pread@exhaustion: - shard-glk: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-glk2/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][16] ([i915#2658]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-apl2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271]) +72 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-kbl3/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@gem_softpin@evict-snoop-interruptible: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109312]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-iclb5/igt@gem_soft...@evict-snoop-interruptible.html * igt@gem_userptr_blits@access-control: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-iclb5/igt@gem_userptr_bl...@access-control.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/shard-apl2/igt@gem_userptr_bl...@dmabuf-sync.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
URL : https://patchwork.freedesktop.org/series/91921/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10281 -> Patchwork_20470
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/index.html
Known issues
Here are the changes found in Patchwork_20470 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-ivb-3770:NOTRUN -> [SKIP][1] ([fdo#109271]) +31 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-ivb-3770/igt@amdgpu/amd_cs_...@fork-compute0.html
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +14 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886] / [i915#2291])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-ivb-3770:NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-ivb-3770/igt@kms_chamel...@dp-hpd-fast.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- {fi-tgl-1115g4}:[FAIL][8] ([i915#1888]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (40 -> 38)
--
Additional (2): fi-kbl-soraka fi-ivb-3770
Missing(4): fi-ilk-m540 fi-hsw-4200u fi-bdw-samus fi-bsw-n3050
Build changes
-
* Linux: CI_DRM_10281 -> Patchwork_20470
CI-20190529: 20190529
CI_DRM_10281: de45b368328acbdfd194032621c175a65930a8a0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20470: ebe44a5c829ba27f84838227d0ed9cdfaaa53971 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ebe44a5c829b drm/i915/gem: only allow WB for smem only placements
02ac31b35505 drm/i915/gem: only allow WC for lmem
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/47] drm/i915/guc: Implement GuC context operations for new inteface
On 24.06.2021 09:04, Matthew Brost wrote:
> Implement GuC context operations which includes GuC specific operations
> alloc, pin, unpin, and destroy.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_context.c | 5 +
> drivers/gpu/drm/i915/gt/intel_context_types.h | 22 +-
> drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 1 -
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 34 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 +
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 664 --
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/i915_request.c | 1 +
> 8 files changed, 677 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 4033184f13b9..2b68af16222c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -383,6 +383,11 @@ intel_context_init(struct intel_context *ce, struct
> intel_engine_cs *engine)
>
> mutex_init(>pin_mutex);
>
> + spin_lock_init(>guc_state.lock);
> +
> + ce->guc_id = GUC_INVALID_LRC_ID;
> + INIT_LIST_HEAD(>guc_id_link);
> +
> i915_active_init(>active,
>__intel_context_active, __intel_context_retire, 0);
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index bb6fef7eae52..ce7c69b34cd1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -95,6 +95,7 @@ struct intel_context {
> #define CONTEXT_BANNED 6
> #define CONTEXT_FORCE_SINGLE_SUBMISSION 7
> #define CONTEXT_NOPREEMPT8
> +#define CONTEXT_LRCA_DIRTY 9
>
> struct {
> u64 timeout_us;
> @@ -137,14 +138,29 @@ struct intel_context {
>
> u8 wa_bb_page; /* if set, page num reserved for context workarounds */
>
> + struct {
> + /** lock: protects everything in guc_state */
> + spinlock_t lock;
> + /**
> + * sched_state: scheduling state of this context using GuC
> + * submission
> + */
> + u8 sched_state;
> + } guc_state;
> +
> /* GuC scheduling state that does not require a lock. */
> atomic_t guc_sched_state_no_lock;
>
> + /* GuC lrc descriptor ID */
> + u16 guc_id;
> +
> + /* GuC lrc descriptor reference count */
> + atomic_t guc_id_ref;
> +
> /*
> - * GuC lrc descriptor ID - Not assigned in this patch but future patches
> - * in the series will.
> + * GuC ID link - in list when unpinned but guc_id still valid in GuC
>*/
> - u16 guc_id;
> + struct list_head guc_id_link;
some fields are being added with kerneldoc, some without
what's the rule ?
> };
>
> #endif /* __INTEL_CONTEXT_TYPES__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> index 41e5350a7a05..49d4857ad9b7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> @@ -87,7 +87,6 @@
> #define GEN11_CSB_WRITE_PTR_MASK (GEN11_CSB_PTR_MASK << 0)
>
> #define MAX_CONTEXT_HW_ID(1 << 21) /* exclusive */
> -#define MAX_GUC_CONTEXT_HW_ID(1 << 20) /* exclusive */
> #define GEN11_MAX_CONTEXT_HW_ID (1 << 11) /* exclusive */
> /* in Gen12 ID 0x7FF is reserved to indicate idle */
> #define GEN12_MAX_CONTEXT_HW_ID (GEN11_MAX_CONTEXT_HW_ID - 1)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 9ba8219475b2..d44316dc914b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -44,6 +44,14 @@ struct intel_guc {
> void (*disable)(struct intel_guc *guc);
> } interrupts;
>
> + /*
> + * contexts_lock protects the pool of free guc ids and a linked list of
> + * guc ids available to be stolen
> + */
> + spinlock_t contexts_lock;
> + struct ida guc_ids;
> + struct list_head guc_id_list;
> +
> bool submission_selected;
>
> struct i915_vma *ads_vma;
> @@ -102,6 +110,29 @@ intel_guc_send_and_receive(struct intel_guc *guc, const
> u32 *action, u32 len,
>response_buf, response_buf_size, 0);
> }
>
> +static inline int intel_guc_send_busy_loop(struct intel_guc* guc,
> +const u32 *action,
> +u32 len,
> +bool loop)
> +{
> + int err;
> +
> + /* No sleeping with spin locks, just busy loop */
> + might_sleep_if(loop && (!in_atomic() && !irqs_disabled()));
> +
> +retry:
> + err = intel_guc_send_nb(guc, action, len);
> + if
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Drop all references to DRM IRQ midlayer
== Series Details == Series: drm/i915: Drop all references to DRM IRQ midlayer URL : https://patchwork.freedesktop.org/series/91915/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10280_full -> Patchwork_20467_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20467_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20467_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_20467_full: ### IGT changes ### Possible regressions * igt@kms_plane@pixel-format-source-clamping@pipe-a-planes: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-tglb1/igt@kms_plane@pixel-format-source-clamp...@pipe-a-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-tglb3/igt@kms_plane@pixel-format-source-clamp...@pipe-a-planes.html Warnings * igt@kms_cursor_crc@pipe-d-cursor-max-size-onscreen: - shard-skl: [SKIP][3] ([fdo#109271]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-skl2/igt@kms_cursor_...@pipe-d-cursor-max-size-onscreen.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-skl8/igt@kms_cursor_...@pipe-d-cursor-max-size-onscreen.html Known issues Here are the changes found in Patchwork_20467_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] / [i915#3070]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-iclb2/igt@gem_...@unwedge-stress.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-iclb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-glk8/igt@gem_exec_f...@basic-deadline.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-glk4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-glk1/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@rcs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-kbl6/igt@gem_exec_fair@basic-n...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-kbl7/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][20] ([i915#3633]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/shard-apl8/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_suspend@basic-s3: - shard-apl: NOTRUN -> [DMESG-WARN][21] ([i915#180]) [21]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
== Series Details == Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem URL : https://patchwork.freedesktop.org/series/91921/ 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/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/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
== Series Details == Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem URL : https://patchwork.freedesktop.org/series/91921/ State : warning == Summary == $ dim checkpatch origin/drm-tip 02ac31b35505 drm/i915/gem: only allow WC for lmem ebe44a5c829b drm/i915/gem: only allow WB for smem only placements -:59: WARNING:TABSTOP: Statements should start on a tabstop #59: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:705: +if (IS_DGFX(i915) && total: 0 errors, 1 warnings, 0 checks, 35 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/47] drm/i915/guc: Add lrc descriptor context lookup array
On 24.06.2021 09:04, Matthew Brost wrote:
> Add lrc descriptor context lookup array which can resolve the
> intel_context from the lrc descriptor index. In addition to lookup, it
> can determine in the lrc descriptor context is currently registered with
> the GuC by checking if an entry for a descriptor index is present.
> Future patches in the series will make use of this array.
s/lrc/LRC
>
> Cc: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 +--
> 2 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index b28fa54214f2..2313d9fc087b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -6,6 +6,8 @@
> #ifndef _INTEL_GUC_H_
> #define _INTEL_GUC_H_
>
> +#include "linux/xarray.h"
#include
> +
> #include "intel_uncore.h"
> #include "intel_guc_fw.h"
> #include "intel_guc_fwif.h"
> @@ -46,6 +48,9 @@ struct intel_guc {
> struct i915_vma *lrc_desc_pool;
> void *lrc_desc_pool_vaddr;
>
> + /* guc_id to intel_context lookup */
> + struct xarray context_lookup;
> +
> /* Control params for fw initialization */
> u32 params[GUC_CTL_MAX_DWORDS];
btw, IIRC there was idea to move most struct definitions to
intel_guc_types.h, is this still a plan ?
>
> 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 a366890fb840..23a94a896a0b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -65,8 +65,6 @@ static inline struct i915_priolist *to_priolist(struct
> rb_node *rb)
> return rb_entry(rb, struct i915_priolist, node);
> }
>
> -/* Future patches will use this function */
> -__attribute__ ((unused))
> static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc *guc, u32 index)
> {
> struct guc_lrc_desc *base = guc->lrc_desc_pool_vaddr;
> @@ -76,6 +74,15 @@ static struct guc_lrc_desc *__get_lrc_desc(struct
> intel_guc *guc, u32 index)
> return [index];
> }
>
> +static inline struct intel_context *__get_context(struct intel_guc *guc, u32
> id)
> +{
> + struct intel_context *ce = xa_load(>context_lookup, id);
> +
> + GEM_BUG_ON(id >= GUC_MAX_LRC_DESCRIPTORS);
> +
> + return ce;
> +}
> +
> static int guc_lrc_desc_pool_create(struct intel_guc *guc)
> {
> u32 size;
> @@ -96,6 +103,25 @@ static void guc_lrc_desc_pool_destroy(struct intel_guc
> *guc)
> i915_vma_unpin_and_release(>lrc_desc_pool, I915_VMA_RELEASE_MAP);
> }
>
> +static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)
> +{
> + struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
> +
> + memset(desc, 0, sizeof(*desc));
> + xa_erase_irq(>context_lookup, id);
> +}
> +
> +static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)
> +{
> + return __get_context(guc, id);
> +}
> +
> +static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
> +struct intel_context *ce)
> +{
> + xa_store_irq(>context_lookup, id, ce, GFP_ATOMIC);
> +}
> +
> static void guc_add_request(struct intel_guc *guc, struct i915_request *rq)
> {
> /* Leaving stub as this function will be used in future patches */
> @@ -400,6 +426,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
>*/
> GEM_BUG_ON(!guc->lrc_desc_pool);
>
> + xa_init_flags(>context_lookup, XA_FLAGS_LOCK_IRQ);
> +
> return 0;
> }
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/47] drm/i915/guc: Optimize CTB writes and reads
On 24.06.2021 09:04, Matthew Brost wrote:
> CTB writes are now in the path of command submission and should be
> optimized for performance. Rather than reading CTB descriptor values
> (e.g. head, tail) which could result in accesses across the PCIe bus,
> store shadow local copies and only read/write the descriptor values when
> absolutely necessary. Also store the current space in the each channel
> locally.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 ++
> 2 files changed, 51 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 27ec30b5ef47..1fd5c69358ef 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct
> guc_ct_buffer_desc *desc)
> static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> {
> ctb->broken = false;
> + ctb->tail = 0;
> + ctb->head = 0;
> + ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> +
> guc_ct_buffer_desc_init(ctb->desc);
> }
>
> @@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
> {
> struct intel_guc_ct_buffer *ctb = >ctbs.send;
> struct guc_ct_buffer_desc *desc = ctb->desc;
> - u32 head = desc->head;
> - u32 tail = desc->tail;
> + u32 tail = ctb->tail;
> u32 size = ctb->size;
> - u32 used;
> u32 header;
> u32 hxg;
> u32 *cmds = ctb->cmds;
> @@ -398,25 +400,14 @@ static int ct_write(struct intel_guc_ct *ct,
> if (unlikely(desc->status))
> goto corrupted;
>
> - if (unlikely((tail | head) >= size)) {
> +#ifdef CONFIG_DRM_I915_DEBUG_GUC
since we are caching tail, we may want to check if it's sill correct:
tail = READ_ONCE(desc->tail);
if (unlikely(tail != ctb->tail)) {
CT_ERROR(ct, "Tail was modified %u != %u\n",
tail, ctb->tail);
desc->status |= GUC_CTB_STATUS_MISMATCH;
goto corrupted;
}
and since we own the tail then we can be more strict:
GEM_BUG_ON(tail > size);
and then finally just check GuC head:
head = READ_ONCE(desc->head);
if (unlikely(head >= size)) {
...
> + if (unlikely((desc->tail | desc->head) >= size)) {
> CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> - head, tail, size);
> + desc->head, desc->tail, size);
> desc->status |= GUC_CTB_STATUS_OVERFLOW;
> goto corrupted;
> }
> -
> - /*
> - * tail == head condition indicates empty. GuC FW does not support
> - * using up the entire buffer to get tail == head meaning full.
> - */
> - if (tail < head)
> - used = (size - head) + tail;
> - else
> - used = tail - head;
> -
> - /* make sure there is a space including extra dw for the fence */
> - if (unlikely(used + len + 1 >= size))
> - return -ENOSPC;
> +#endif
>
> /*
>* dw0: CT header (including fence)
> @@ -457,7 +448,9 @@ static int ct_write(struct intel_guc_ct *ct,
> write_barrier(ct);
>
> /* now update descriptor */
> + ctb->tail = tail;
> WRITE_ONCE(desc->tail, tail);
> + ctb->space -= len + 1;
this magic "1" is likely GUC_CTB_MSG_MIN_LEN, right ?
>
> return 0;
>
> @@ -473,7 +466,7 @@ static int ct_write(struct intel_guc_ct *ct,
> * @req: pointer to pending request
> * @status: placeholder for status
> *
> - * For each sent request, Guc shall send bac CT response message.
> + * For each sent request, GuC shall send back CT response message.
> * Our message handler will update status of tracked request once
> * response message with given fence is received. Wait here and
> * check for valid response status value.
> @@ -520,24 +513,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct
> *ct)
> return ret;
> }
>
> -static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
> +static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
> {
> - struct guc_ct_buffer_desc *desc = ctb->desc;
> - u32 head = READ_ONCE(desc->head);
> + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> + u32 head;
> u32 space;
>
> - space = CIRC_SPACE(desc->tail, head, ctb->size);
> + if (ctb->space >= len_dw)
> + return true;
> +
> + head = READ_ONCE(ctb->desc->head);
> + if (unlikely(head > ctb->size)) {
> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u size=%u\n",
> + ctb->desc->head, ctb->desc->tail, ctb->size);
> + ctb->desc->status |=
[Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.
I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
for DGFX, so hopefully can also be safely rejected.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 7 +++
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 10 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d0c91697bb22..e3459a524e64 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
goto out_unpin;
}
+ if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
+ i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM) &&
+ read_domains != I915_GEM_DOMAIN_CPU) {
+ err = -EINVAL;
+ goto out_unpin;
+ }
+
if (read_domains & I915_GEM_DOMAIN_WC)
err = i915_gem_object_set_to_wc_domain(obj, write_domain);
else if (read_domains & I915_GEM_DOMAIN_GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index f3586b36dd53..afc9f3dc38b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
enum i915_mmap_type mmap_type,
u64 *offset, struct drm_file *file)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_mmap_offset *mmo;
if (i915_gem_object_never_mmap(obj))
@@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
return -ENODEV;
+ /*
+* For smem only placements on DGFX we need to default to WB. On DG1
+* everything is snooped always, so should always be coherent.
+*/
+if (IS_DGFX(i915) &&
+mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
+i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM))
+ return -ENODEV;
+
mmo = mmap_offset_attach(obj, mmap_type, file);
if (IS_ERR(mmo))
return PTR_ERR(mmo);
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem
This is already the case for our kernel internal mappings, and since we
now only support a single mode this should always be WC if the object
can be placed in lmem.
v2: rebase and also update set_domain
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 9 +
drivers/gpu/drm/i915/gem/i915_gem_object.c | 21 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
4 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 073822100da7..d0c91697bb22 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -571,6 +571,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
if (READ_ONCE(obj->write_domain) == read_domains)
goto out_unpin;
+ if (i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL) &&
+ read_domains != I915_GEM_DOMAIN_WC) {
+ err = -EINVAL;
+ goto out_unpin;
+ }
+
if (read_domains & I915_GEM_DOMAIN_WC)
err = i915_gem_object_set_to_wc_domain(obj, write_domain);
else if (read_domains & I915_GEM_DOMAIN_GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index a90f796e85c0..f3586b36dd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -688,6 +688,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
!i915_gem_object_has_iomem(obj))
return -ENODEV;
+ /*
+* Note that even if the object can also be placed in smem then we still
+* map as WC here, since we can only support a single mode. On DG1 this
+* sucks since we can't turn off snooping for this case.
+*/
+ if (mmap_type != I915_MMAP_TYPE_WC &&
+ i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
+ return -ENODEV;
+
mmo = mmap_offset_attach(obj, mmap_type, file);
if (IS_ERR(mmo))
return PTR_ERR(mmo);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..326956c18f76 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,27 @@ bool i915_gem_object_has_iomem(const struct
drm_i915_gem_object *obj)
return obj->mem_flags & I915_BO_FLAG_IOMEM;
}
+/**
+ * i915_gem_object_placements_contain_type - Check whether the object can be
+ * placed at certain memory type
+ * @obj: Pointer to the object
+ * @type: The memory type to check
+ *
+ * Return: True if the object can be placed in @type. False otherwise.
+ */
+bool i915_gem_object_placements_contain_type(struct drm_i915_gem_object *obj,
+enum intel_memory_type type)
+{
+ unsigned int i;
+
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ if (obj->mm.placements[i]->type == type)
+ return true;
+ }
+
+ return false;
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ea3224a480c4..e1daa58bc225 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -12,6 +12,7 @@
#include
#include "display/intel_frontbuffer.h"
+#include "intel_memory_region.h"
#include "i915_gem_object_types.h"
#include "i915_gem_gtt.h"
#include "i915_gem_ww.h"
@@ -597,6 +598,9 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
+bool i915_gem_object_placements_contain_type(struct drm_i915_gem_object *obj,
+enum intel_memory_type type);
+
#ifdef CONFIG_MMU_NOTIFIER
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/47] drm/i915/guc: Increase size of CTB buffers
On 24.06.2021 17:41, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 03:49:55PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 09:04, Matthew Brost wrote:
>>> With the introduction of non-blocking CTBs more than one CTB can be in
>>> flight at a time. Increasing the size of the CTBs should reduce how
>>> often software hits the case where no space is available in the CTB
>>> buffer.
>>>
>>> Cc: John Harrison
>>> Signed-off-by: Matthew Brost
>>> ---
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ---
>>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index 07f080ddb9ae..a17215920e58 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -58,11 +58,16 @@ static inline struct drm_device *ct_to_drm(struct
>>> intel_guc_ct *ct)
>>> * ++---+--+
>>> *
>>> * Size of each `CT Buffer`_ must be multiple of 4K.
>>> - * As we don't expect too many messages, for now use minimum sizes.
>>> + * We don't expect too many messages in flight at any time, unless we are
>>> + * using the GuC submission. In that case each request requires a minimum
>>> + * 2 dwords which gives us a maximum 256 queue'd requests. Hopefully this
>>> + * enough space to avoid backpressure on the driver. We increase the size
>>> + * of the receive buffer (relative to the send) to ensure a G2H response
>>> + * CTB has a landing spot.
>>> */
>>> #define CTB_DESC_SIZE ALIGN(sizeof(struct
>>> guc_ct_buffer_desc), SZ_2K)
>>> #define CTB_H2G_BUFFER_SIZE(SZ_4K)
>>> -#define CTB_G2H_BUFFER_SIZE(SZ_4K)
>>> +#define CTB_G2H_BUFFER_SIZE(4 * CTB_H2G_BUFFER_SIZE)
>>>
>>> struct ct_request {
>>> struct list_head link;
>>> @@ -641,7 +646,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
>>> ct_incoming_msg **msg)
>>> /* beware of buffer wrap case */
>>> if (unlikely(available < 0))
>>> available += size;
>>> - CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
>>> + CT_DEBUG(ct, "available %d (%u:%u:%u)\n", available, head, tail, size);
>>
>> CTB size is already printed in intel_guc_ct_init() and is fixed so not
>> sure if repeating it on every ct_read has any benefit
>>
>
> I'd say more debug the better and if CT_DEBUG is enabled the logs are
> very verbose so an extra value doesn't really hurt.
fair, but this doesn't mean we should add little/no value item, anyway
since DEBUG_GUC is if off by default, this is:
Reviewed-by: Michal Wajdeczko
>
> Matt
>
>>> GEM_BUG_ON(available < 0);
>>>
>>> header = cmds[head];
>>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/47] drm/i915/guc: Improve error message for unsolicited CT response
On 24.06.2021 09:04, Matthew Brost wrote:
> Improve the error message when a unsolicited CT response is received by
> printing fence that couldn't be found, the last fence, and all requests
> with a response outstanding.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index a59e239497ee..07f080ddb9ae 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -730,12 +730,16 @@ static int ct_handle_response(struct intel_guc_ct *ct,
> struct ct_incoming_msg *r
> found = true;
> break;
> }
> - spin_unlock_irqrestore(>requests.lock, flags);
> -
> if (!found) {
> CT_ERROR(ct, "Unsolicited response (fence %u)\n", fence);
> - return -ENOKEY;
> + CT_ERROR(ct, "Could not find fence=%u, last_fence=%u\n", fence,
> + ct->requests.last_fence);
> + list_for_each_entry(req, >requests.pending, link)
> + CT_ERROR(ct, "request %u awaits response\n",
> + req->fence);
not quite sure how listing of awaiting requests could help here (if we
suspect that this is a duplicated reply, then we should rather track
short list of already processed messages to look there) but since it
does not hurt too much, this is:
Reviewed-by: Michal Wajdeczko
> + err = -ENOKEY;
> }
> + spin_unlock_irqrestore(>requests.lock, flags);
>
> if (unlikely(err))
> return err;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On 25.06.2021 00:41, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 17:49, Matthew Brost wrote:
>>> On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
On 24.06.2021 09:04, Matthew Brost wrote:
> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> will send CTBs in the critical path and does not need to wait for these
> CTBs to complete before moving on, hence the need for this new function.
>
> The non-blocking CTB now must have a flow control mechanism to ensure
> the buffer isn't overrun. A lazy spin wait is used as we believe the
> flow control condition should be rare with a properly sized buffer.
>
> The function, intel_guc_send_nb, is exported in this patch but unused.
> Several patches later in the series make use of this function.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
> 3 files changed, 82 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 4abc59f6f3cd..24b1df6ad4ae 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
> intel_guc_log *log)
> static
> inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
> len)
> {
> - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> +}
> +
> +#define INTEL_GUC_SEND_NBBIT(31)
hmm, this flag really belongs to intel_guc_ct_send() so it should be
defined as CTB flag near that function declaration
>>>
>>> I can move this up a few lines.
>>>
> +static
> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action,
> u32 len)
> +{
> + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> + INTEL_GUC_SEND_NB);
> }
>
> static inline int
> @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const
> u32 *action, u32 len,
> u32 *response_buf, u32 response_buf_size)
> {
> return intel_guc_ct_send(>ct, action, len,
> - response_buf, response_buf_size);
> + response_buf, response_buf_size, 0);
> }
>
> static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index a17215920e58..c9a65d05911f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -3,6 +3,11 @@
> * Copyright © 2016-2019 Intel Corporation
> */
>
> +#include
> +#include
> +#include
> +#include
> +
> #include "i915_drv.h"
> #include "intel_guc_ct.h"
> #include "gt/intel_gt.h"
> @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
> static int ct_write(struct intel_guc_ct *ct,
> const u32 *action,
> u32 len /* in dwords */,
> - u32 fence)
> + u32 fence, u32 flags)
> {
> struct intel_guc_ct_buffer *ctb = >ctbs.send;
> struct guc_ct_buffer_desc *desc = ctb->desc;
> @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
>FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
>FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
>
> - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> - GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> + hxg = (flags & INTEL_GUC_SEND_NB) ?
> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> + FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
or as we already switched to accept and return whole HXG messages in
guc_send_mmio() maybe we should do the same for CTB variant too and
instead of using extra flag just let caller to prepare proper HXG header
with HXG_EVENT type and then in CTB code just look at this type to make
decision which code path to use
>>>
>>> Not sure I follow. Anyways could
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915: support forcing the page size with lmem
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: support forcing the page size
with lmem
URL : https://patchwork.freedesktop.org/series/91918/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10280 -> Patchwork_20469
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/index.html
Known issues
Here are the changes found in Patchwork_20469 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +6 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][3] ([i915#2283])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][5] ([i915#3303]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10280 -> Patchwork_20469
CI-20190529: 20190529
CI_DRM_10280: f931f9f9f1188586bca423930ea09d880dd6a269 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20469: 38e9e257da235b559c6ba5fe928e6a24def5ff8f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
38e9e257da23 drm/i915/gtt: ignore min_page_size for paging structures
98175644c174 drm/i915: support forcing the page size with lmem
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20469/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/2] drm/i915: support forcing the page size with lmem
== Series Details == Series: series starting with [v3,1/2] drm/i915: support forcing the page size with lmem URL : https://patchwork.freedesktop.org/series/91918/ 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/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/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' -
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm/i915: support forcing the page size with lmem
== Series Details == Series: series starting with [v3,1/2] drm/i915: support forcing the page size with lmem URL : https://patchwork.freedesktop.org/series/91918/ State : warning == Summary == $ dim checkpatch origin/drm-tip 98175644c174 drm/i915: support forcing the page size with lmem -:326: WARNING:TYPO_SPELLING: 'overriden' may be misspelled - perhaps 'overridden'? #326: FILE: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c:142: + * this must be at least as large as @chunk_size, and can be overriden by ^ total: 0 errors, 1 warnings, 0 checks, 379 lines checked 38e9e257da23 drm/i915/gtt: ignore min_page_size for paging structures ___ 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/display/dsc: Set BPP in the kernel
== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel URL : https://patchwork.freedesktop.org/series/91917/ State : failure == Summary == Couldn't find any build artifact matching "Test-with: Test-with: 20210622102454.8922-1-venkata.sai.patn...@intel.com" Check that the msg-id is correct and make sure that it had been built. ___ 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: Drop all references to DRM IRQ midlayer
== Series Details ==
Series: drm/i915: Drop all references to DRM IRQ midlayer
URL : https://patchwork.freedesktop.org/series/91915/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10280 -> Patchwork_20467
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20467:
### 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_pm:
- {fi-jsl-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_20467 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +5 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271]) +27 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][5] ([i915#2283])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.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_20467/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][7] ([i915#3303]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10280/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10280 -> Patchwork_20467
CI-20190529: 20190529
CI_DRM_10280: f931f9f9f1188586bca423930ea09d880dd6a269 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20467: c4b640356a9b733586da2bc0bc3ee43bfc1400b6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c4b640356a9b drm/i915: Drop all references to DRM IRQ midlayer
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20467/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gem: Implement object migration
On 24/06/2021 19:31, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 91 +++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 ++
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
5 files changed, 183 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..6421c3a8b2f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,97 @@ bool i915_gem_object_has_iomem(const struct
drm_i915_gem_object *obj)
return obj->mem_flags & I915_BO_FLAG_IOMEM;
}
+/**
+ * i915_gem_object_can_migrate - Whether an object likely can be migrated
+ *
+ * @obj: The object to migrate
+ * @id: The region intended to migrate to
+ *
+ * Check whether the object backend supports migration to the
+ * given region. Note that pinning may affect the ability to migrate.
+ *
+ * Return: true if migration is possible, false otherwise.
+ */
+bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
+enum intel_region_id id)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ unsigned int num_allowed = obj->mm.n_placements;
+ struct intel_memory_region *mr;
+ unsigned int i;
+
+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
+
+ if (!obj->ops->migrate)
+ return -EOPNOTSUPP;
+
+ mr = i915->mm.regions[id];
if (!mr)
return false;
?
+ if (obj->mm.region == mr)
+ return true;
+
+ if (!i915_gem_object_evictable(obj))
+ return false;
+
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return true;
+
+ if (num_allowed == 0)
+ return false;
+
+ for (i = 0; i < num_allowed; ++i) {
+ if (mr == obj->mm.placements[i])
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * i915_gem_object_migrate - Migrate an object to the desired region id
+ * @obj: The object to migrate.
+ * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
+ * not be successful in evicting other objects to make room for this object.
+ * @id: The region id to migrate to.
+ *
+ * Attempt to migrate the object to the desired memory region. The
+ * object backend must support migration and the object may not be
+ * pinned, (explicitly pinned pages or pinned vmas). The object must
+ * be locked.
+ * On successful completion, the object will have pages pointing to
+ * memory in the new region, but an async migration task may not have
+ * completed yet, and to accomplish that, i915_gem_object_wait_migration()
+ * must be called.
+ *
+ * Return: 0 on success. Negative error code on failure. In particular may
+ * return -ENXIO on lack of region space, -EDEADLK for deadlock avoidance
+ * if @ww is set, -EINTR or -ERESTARTSYS if signal pending, and
+ * -EBUSY if the object is pinned.
+ */
+int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
+ enum intel_region_id id)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct intel_memory_region *mr;
+
+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
+ assert_object_held(obj);
+
+ mr = i915->mm.regions[id];
GEM_BUG_ON(!mr) ?
+ if (obj->mm.region == mr)
+ return 0;
+
+ if (!i915_gem_object_evictable(obj))
+ return -EBUSY;
+
+ if (!obj->ops->migrate)
+ return -EOPNOTSUPP;
+
+ return obj->ops->migrate(obj, mr);
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ea3224a480c4..8cbd7a5334e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -17,6 +17,8 @@
#include "i915_gem_ww.h"
#include "i915_vma_types.h"
+enum intel_region_id;
+
/*
* XXX: There is a prevalence of the assumption that we fit the
* object's page count inside a 32bit _signed_ variable. Let's document
@@ -597,6 +599,16 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
+int
[Intel-gfx] ✓ Fi.CI.IGT: success for Deprecate struct drm_device.irq_enabled (rev2)
== Series Details == Series: Deprecate struct drm_device.irq_enabled (rev2) URL : https://patchwork.freedesktop.org/series/91845/ State : success == Summary == CI Bug Log - changes from CI_DRM_10279_full -> Patchwork_20466_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_20466_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20466_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_20466_full: ### IGT changes ### Warnings * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1: - shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/shard-iclb8/igt@kms_psr2...@overlay-plane-update-sf-dmg-area-1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-iclb2/igt@kms_psr2...@overlay-plane-update-sf-dmg-area-1.html Known issues Here are the changes found in Patchwork_20466_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-snb6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271]) +420 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-snb7/igt@gem_ctx_sha...@q-in-order.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_10279/shard-glk9/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-glk1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-glk8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#3633]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_mmap_gtt@big-copy: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#307]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/shard-skl9/igt@gem_mmap_...@big-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-skl9/igt@gem_mmap_...@big-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][16] ([i915#2658]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-snb7/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][17] ([i915#3002]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-apl8/igt@gem_userptr_bl...@input-checking.html * igt@i915_module_load@reload: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/shard-skl4/igt@i915_module_l...@reload.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/shard-skl7/igt@i915_module_l...@reload.html * igt@kms_big_fb@linear-32bpp-rotate-0: - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#118] / [i915#95]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/shard-glk2/igt@kms_big...@linear-32bpp-rotate-0.html [21]:
[Intel-gfx] [PATCH v3 2/2] drm/i915/gtt: ignore min_page_size for paging structures
The min_page_size is only needed for pages inserted into the GTT, and
for our paging structures we only need at most 4K bytes, so simply
ignore the min_page_size restrictions here, otherwise we might see some
severe overallocation on some devices.
v2(Thomas): add some commentary
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 084ea65d59c0..f7e0352edb62 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -16,7 +16,19 @@ struct drm_i915_gem_object *alloc_pt_lmem(struct
i915_address_space *vm, int sz)
{
struct drm_i915_gem_object *obj;
- obj = i915_gem_object_create_lmem(vm->i915, sz, 0);
+ /*
+* To avoid severe over-allocation when dealing with min_page_size
+* restrictions, we override that behaviour here by allowing an object
+* size and page layout which can be smaller. In practice this should be
+* totally fine, since GTT paging structures are not typically inserted
+* into the GTT.
+*
+* Note that we also hit this path for the scratch page, and for this
+* case it might need to be 64K, but that should work fine here since we
+* used the passed in size for the page size, which should ensure it
+* also has the same alignment.
+*/
+ obj = __i915_gem_object_create_lmem_with_ps(vm->i915, sz, sz, 0);
/*
* Ensure all paging structures for this vm share the same dma-resv
* object underneath, with the idea that one object_lock() will lock
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915: support forcing the page size with lmem
For some specialised objects we might need something larger than the
regions min_page_size due to some hw restriction, and slightly more
hairy is needing something smaller with the guarantee that such objects
will never be inserted into any GTT, which is the case for the paging
structures.
This also fixes how we setup the BO page_alignment, if we later migrate
the object somewhere else. For example if the placements are {SMEM,
LMEM}, then we might get this wrong. Pushing the min_page_size behaviour
into the manager should fix this.
v2(Thomas): push the default page size behaviour into buddy_man, and let
the user override it with the page-alignment, which looks cleaner
v3: rebase on ttm sys changes
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 33 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 ++
drivers/gpu/drm/i915/gem/i915_gem_region.c| 13 +++-
drivers/gpu/drm/i915/gem/i915_gem_region.h| 1 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 1 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 3 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 8 +--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 14 -
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +-
drivers/gpu/drm/i915/intel_memory_region.h| 1 +
drivers/gpu/drm/i915/intel_region_ttm.c | 4 +-
.../drm/i915/selftests/intel_memory_region.c | 63 ++-
drivers/gpu/drm/i915/selftests/mock_region.c | 1 +
17 files changed, 143 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 93bf63bbaff1..51f92e4b1a69 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -90,7 +90,7 @@ i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
*/
flags = I915_BO_ALLOC_USER;
- ret = mr->ops->init_object(mr, obj, size, flags);
+ ret = mr->ops->init_object(mr, obj, size, 0, flags);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 41d5182cd367..a795dd38aca7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -93,11 +93,42 @@ bool __i915_gem_object_is_lmem(struct drm_i915_gem_object
*obj)
mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
+/**
+ * __i915_gem_object_create_lmem_with_ps - Create lmem object and force the
+ * minimum page size for the backing pages.
+ * @i915: The i915 instance.
+ * @size: The size in bytes for the object. Note that we need to round the size
+ * up depending on the @page_size. The final object size can be fished out from
+ * the drm GEM object.
+ * @page_size: The requested minimum page size in bytes for this object. This
is
+ * useful if we need something bigger than the regions min_page_size due to
some
+ * hw restriction, or in some very specialised cases where it needs to be
+ * smaller, where the internal fragmentation cost is too great when rounding up
+ * the object size.
+ * @flags: The optional BO allocation flags.
+ *
+ * Note that this interface assumes you know what you are doing when forcing
the
+ * @page_size. If this is smaller than the regions min_page_size then it can
+ * never be inserted into any GTT, otherwise it might lead to undefined
+ * behaviour.
+ *
+ * Return: The object pointer, which might be an ERR_PTR in the case of
failure.
+ */
+struct drm_i915_gem_object *
+__i915_gem_object_create_lmem_with_ps(struct drm_i915_private *i915,
+ resource_size_t size,
+ resource_size_t page_size,
+ unsigned int flags)
+{
+ return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+size, page_size, flags);
+}
+
struct drm_i915_gem_object *
i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
unsigned int flags)
{
return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
-size, flags);
+size, 0, flags);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index 27a611deba47..4ee81fc66302 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -23,6 +23,11 @@ bool i915_gem_object_is_lmem(struct drm_i915_gem_object
*obj);
bool
[Intel-gfx] [PATCH 2/2] drm/i915/display/dsc: Set BPP in the kernel
From: Anusha Srivatsa
Set compress BPP in kernel while connector DP or eDP
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f74f70691247b..a454ee4210866 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1241,9 +1241,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
pipe_config->lane_count = limits->max_lane_count;
if (intel_dp_is_edp(intel_dp)) {
- pipe_config->dsc.compressed_bpp =
- min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
- pipe_config->pipe_bpp);
+ if (intel_dp->force_dsc_bpp) {
+ drm_dbg_kms(_priv->drm,
+ "DSC BPC forced to %d",
intel_dp->force_dsc_bpp);
+ pipe_config->dsc.compressed_bpp =
intel_dp->force_dsc_bpp;
+ } else {
+ pipe_config->dsc.compressed_bpp =
+ min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+ pipe_config->pipe_bpp);
+ }
pipe_config->dsc.slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
@@ -1269,9 +1275,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
"Compressed BPP/Slice Count not
supported\n");
return -EINVAL;
}
- pipe_config->dsc.compressed_bpp = min_t(u16,
+ if (intel_dp->force_dsc_bpp) {
+ drm_dbg_kms(_priv->drm,
+ "DSC BPC forced to %d\n",
intel_dp->force_dsc_bpp);
+ pipe_config->dsc.compressed_bpp =
intel_dp->force_dsc_bpp;
+ } else {
+ pipe_config->dsc.compressed_bpp = min_t(u16,
dsc_max_output_bpp >> 4,
pipe_config->pipe_bpp);
+ }
pipe_config->dsc.slice_count = dsc_dp_slice_count;
}
/*
@@ -1374,7 +1386,8 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
* Pipe joiner needs compression upto display12 due to BW limitation.
DG2
* onwards pipe joiner can be enabled without compression.
*/
- drm_dbg_kms(>drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
+ drm_dbg_kms(>drm, "Force DSC en = %d\n Force DSC BPP = %d\n",
+ intel_dp->force_dsc_en, intel_dp->force_dsc_bpp);
if (ret || intel_dp->force_dsc_en || (DISPLAY_VER(i915) < 13 &&
pipe_config->bigjoiner)) {
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
From: Anusha Srivatsa
DSC can be supported per DP connector. This patch creates
a per connector debugfs node to expose the Input and
Compressed BPP.
The same node can be used from userspace to force
DSC to a certain BPP.
force_dsc_bpp is written through this debugfs
node to force DSC BPP to all accepted values
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
---
.../drm/i915/display/intel_display_debugfs.c | 103 +-
.../drm/i915/display/intel_display_types.h| 1 +
2 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667d..6dc223227eeaa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2389,6 +2389,100 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_dp *intel_dp;
+ struct drm_modeset_acquire_ctx ctx;
+ struct intel_crtc_state *crtc_state = NULL;
+ int ret = 0;
+ bool try_again = false;
+
+ drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
+
+ do {
+ try_again = false;
+ ret = drm_modeset_lock(>mode_config.connection_mutex,
+ );
+ if (ret) {
+ ret = -EINTR;
+ break;
+ }
+ crtc = connector->state->crtc;
+ if (connector->status != connector_status_connected || !crtc) {
+ ret = -ENODEV;
+ break;
+ }
+ ret = drm_modeset_lock(>mutex, );
+ if (ret == -EDEADLK) {
+ ret = drm_modeset_backoff();
+ if (!ret) {
+ try_again = true;
+ continue;
+ }
+ break;
+ } else if (ret) {
+ break;
+ }
+ intel_dp = intel_attached_dp(to_intel_connector(connector));
+ crtc_state = to_intel_crtc_state(crtc->state);
+ seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
+ seq_printf(m, "Compressed_BPP: %d\n",
+ crtc_state->dsc.compressed_bpp);
+ } while (try_again);
+
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
+
+ return ret;
+}
+
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ int dsc_bpp = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ if (len == 0)
+ return 0;
+
+ drm_dbg(>drm,
+ "Copied %zu bytes from user to force BPP\n", len);
+
+ ret = kstrtoint_from_user(ubuf, len, 0, _bpp);
+
+ intel_dp->force_dsc_bpp = dsc_bpp;
+ if (ret < 0)
+ return ret;
+
+ *offp += len;
+ return len;
+}
+
+static int i915_dsc_bpp_support_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_dsc_bpp_support_show,
+ inode->i_private);
+}
+
+static const struct file_operations i915_dsc_bpp_support_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_dsc_bpp_support_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_dsc_bpp_support_write
+};
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2427,9 +2521,16 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector, _hdcp_sink_capability_fops);
}
- if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
!to_intel_connector(connector)->mst_port) || connector->connector_type ==
DRM_MODE_CONNECTOR_eDP))
+ if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
+ ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
[Intel-gfx] [PATCH 0/2] drm/i915/display/dsc: Set BPP in the kernel
From: Patnana Venkata Sai Test-with: 20210622102454.8922-1-venkata.sai.patn...@intel.com Anusha Srivatsa (2): drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable drm/i915/display/dsc: Set BPP in the kernel .../drm/i915/display/intel_display_debugfs.c | 103 +- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 23 +++- 3 files changed, 121 insertions(+), 6 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Deprecate struct drm_device.irq_enabled (rev2)
== Series Details ==
Series: Deprecate struct drm_device.irq_enabled (rev2)
URL : https://patchwork.freedesktop.org/series/91845/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10279 -> Patchwork_20466
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/index.html
Known issues
Here are the changes found in Patchwork_20466 that come from known issues:
### IGT changes ###
Issues hit
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][1] ([i915#1602] / [i915#2029])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][2] ([i915#1982] / [k.org#205379]) ->
[PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10279/fi-tgl-dsi/igt@i915_module_l...@reload.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/fi-tgl-dsi/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#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
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bdw-gvtdvm fi-glk-dsi fi-bsw-cyan
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10279 -> Patchwork_20466
CI-20190529: 20190529
CI_DRM_10279: a996e82cbdc77fc789d0a385602e02f7e2478a1e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20466: e1c155287a51ea8b770c774b9f98b77656dc2acc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e1c155287a51 drm/zte: Don't set struct drm_device.irq_enabled
0d788773b4a2 drm/xlnx: Don't set struct drm_device.irq_enabled
6e0450487727 drm/vmwgfx: Don't set struct drm_device.irq_enabled
1a40222c9b06 drm/vkms: Don't set struct drm_device.irq_enabled
5a68258241ce drm/vc4: Don't set struct drm_device.irq_enabled
a1667c37b77a drm/tidss: Don't use struct drm_device.irq_enabled
cdf717450b9f drm/tegra: Don't set struct drm_device.irq_enabled
ff36999c025e drm/sun4i: Don't set struct drm_device.irq_enabled
aeb6c0b29a7e drm/stm: Don't set struct drm_device.irq_enabled
07c0db48dd80 drm/sti: Don't set struct drm_device.irq_enabled
0bc658b72ff7 drm/rockchip: Don't set struct drm_device.irq_enabled
6c146315f78b drm/rcar-du: Don't set struct drm_device.irq_enabled
5192f22d62d4 drm/omapdrm: Track IRQ state in local device state
75ab41cf85ba drm/nouveau: Don't set struct drm_device.irq_enabled
3397b281d304 drm/mediatek: Don't set struct drm_device.irq_enabled
e6112f1649c3 drm/imx/dcss: Don't set struct drm_device.irq_enabled
2653cbdb30bb drm/imx: Don't set struct drm_device.irq_enabled
0e30c8dbb5d4 drm/kirin: Don't set struct drm_device.irq_enabled
55f896d83228 drm/exynos: Don't set struct drm_device.irq_enabled
5aec6c6f8fc4 drm/malidp: Don't set struct drm_device.irq_enabled
99ea1463f8fb drm/komeda: Don't set struct drm_device.irq_enabled
fb1312913e45 drm/i915: Track IRQ state in local device state
feeaf91e136a drm/armada: Don't set struct drm_device.irq_enabled
87185ebf5f0c drm: Don't test for IRQ support in VBLANK ioctls
f1fa91fa0489 drm/radeon: Track IRQ state in local device state
67cea301f9df drm/hibmc: Call drm_irq_uninstall() unconditionally
3045cc2d3cf2 drm/amdgpu: Track IRQ state in local device state
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20466/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Deprecate struct drm_device.irq_enabled (rev2)
== Series Details == Series: Deprecate struct drm_device.irq_enabled (rev2) URL : https://patchwork.freedesktop.org/series/91845/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB" +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/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/seqlock.h:840:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:840:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:866:16: warning: trying to copy expression type 31 +./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
Re: [Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
Am 23.06.21 um 13:26 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:10:14 +0200
> Werner Sembach wrote:
>
>> Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:57:53 +0200
>>> Werner Sembach wrote:
>>>
Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:14 +0200
> Werner Sembach wrote:
>
>> Add "Broadcast RGB" to general drm context so that more drivers besides
>> i915 and gma500 can implement it without duplicating code.
>>
>> Userspace can use this property to tell the graphic driver to use full or
>> limited color range for a given connector, overwriting the default
>> behaviour/automatic detection.
>>
>> Possible options are:
>> - Automatic (default/current behaviour)
>> - Full
>> - Limited 16:235
>>
>> In theory the driver should be able to automatically detect the monitors
>> capabilities, but because of flawed standard implementations in Monitors,
>> this might fail. In this case a manual overwrite is required to not have
>> washed out colors or lose details in very dark or bright scenes.
>>
>> Signed-off-by: Werner Sembach
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 4 +++
>> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
>> drivers/gpu/drm/drm_connector.c | 43 +
>> include/drm/drm_connector.h | 16 +++
>> 4 files changed, 67 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 90d62f305257..0c89d32efbd0 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device
>> *dev,
>> if (old_connector_state->preferred_color_format
>> !=
>> new_connector_state->preferred_color_format)
>> new_crtc_state->connectors_changed =
>> true;
>> +
>> +if (old_connector_state->preferred_color_range
>> !=
>> +new_connector_state->preferred_color_range)
>> +new_crtc_state->connectors_changed =
>> true;
>> }
>>
>> if (funcs->atomic_check)
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c536f5e22016..c589bb1a8163 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct
>> drm_connector *connector,
>> state->max_requested_bpc = val;
>> } else if (property ==
>> connector->preferred_color_format_property) {
>> state->preferred_color_format = val;
>> +} else if (property ==
>> connector->preferred_color_range_property) {
>> +state->preferred_color_range = val;
>> } else if (connector->funcs->atomic_set_property) {
>> return connector->funcs->atomic_set_property(connector,
>> state, property, val);
>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct
>> drm_connector *connector,
>> *val = state->max_requested_bpc;
>> } else if (property ==
>> connector->preferred_color_format_property) {
>> *val = state->preferred_color_format;
>> +} else if (property ==
>> connector->preferred_color_range_property) {
>> +*val = state->preferred_color_range;
>> } else if (connector->funcs->atomic_get_property) {
>> return connector->funcs->atomic_get_property(connector,
>> state, property, val);
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index aea03dd02e33..9bc596638613 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list
>> drm_active_color_format_enum_list[] = {
>> { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>> };
>>
>> +static const struct drm_prop_enum_list
>> drm_preferred_color_range_enum_list[] = {
>> +{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
>> +{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Hi,
>
> the same question here about these numbers as I asked on the "active
> color range" property.
>
>> +};
>> +
>> static const struct drm_prop_enum_list
>>
[Intel-gfx] [PATCH] drm/i915: Drop all references to DRM IRQ midlayer
Remove all references to DRM's IRQ midlayer.
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
Signed-off-by: Thomas Zimmermann
Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 3 ++-
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_irq.c | 1 -
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..d893aaaed74f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -180,12 +180,13 @@ static bool stop_ring(struct intel_engine_cs *engine)
static int xcs_resume(struct intel_engine_cs *engine)
{
struct intel_ring *ring = engine->legacy.ring;
+ struct pci_dev *pdev = to_pci_dev(engine->i915->drm.dev);
ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
ring->head, ring->tail);
/* Double check the ring is empty & disabled before we resume */
- synchronize_hardirq(engine->i915->drm.irq);
+ synchronize_hardirq(pdev->irq);
if (!stop_ring(engine))
goto err;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 850b499c71c8..73de45472f60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a11bdb667241..eef616d96f12 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -33,7 +33,6 @@
#include
#include
-#include
#include "display/intel_de.h"
#include "display/intel_display_types.h"
base-commit: 8c1323b422f8473421682ba783b5949ddd89a3f4
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 25/27] drm/vmwgfx: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vmxgfx. All usage of
the field within vmwgfx can safely be removed.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
index b9a9b7ddadbd..4b82f5995452 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
@@ -292,15 +292,11 @@ void vmw_irq_uninstall(struct drm_device *dev)
if (!(dev_priv->capabilities & SVGA_CAP_IRQMASK))
return;
- if (!dev->irq_enabled)
- return;
-
vmw_write(dev_priv, SVGA_REG_IRQMASK, 0);
status = vmw_irq_status_read(dev_priv);
vmw_irq_status_write(dev_priv, status);
- dev->irq_enabled = false;
free_irq(dev->irq, dev);
}
@@ -315,9 +311,6 @@ int vmw_irq_install(struct drm_device *dev, int irq)
{
int ret;
- if (dev->irq_enabled)
- return -EBUSY;
-
vmw_irq_preinstall(dev);
ret = request_threaded_irq(irq, vmw_irq_handler, vmw_thread_fn,
@@ -325,7 +318,6 @@ int vmw_irq_install(struct drm_device *dev, int irq)
if (ret < 0)
return ret;
- dev->irq_enabled = true;
dev->irq = irq;
return ret;
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 26/27] drm/xlnx: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in xlnx. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c index 0c1c50271a88..ac37053412a1 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c @@ -111,8 +111,6 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub) if (ret) return ret; - drm->irq_enabled = 1; - drm_kms_helper_poll_init(drm); /* -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 27/27] drm/zte: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in zte. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/zte/zx_drm_drv.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c index 5506336594e2..064056503ebb 100644 --- a/drivers/gpu/drm/zte/zx_drm_drv.c +++ b/drivers/gpu/drm/zte/zx_drm_drv.c @@ -75,12 +75,6 @@ static int zx_drm_bind(struct device *dev) goto out_unbind; } - /* -* We will manage irq handler on our own. In this case, irq_enabled -* need to be true for using vblank core support. -*/ - drm->irq_enabled = true; - drm_mode_config_reset(drm); drm_kms_helper_poll_init(drm); -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 24/27] drm/vkms: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vkms.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/vkms/vkms_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 027ffe759440..496de38ad983 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -163,8 +163,6 @@ static int vkms_create(struct vkms_config *config)
goto out_devres;
}
- vkms_device->drm.irq_enabled = true;
-
ret = drm_vblank_init(_device->drm, 1);
if (ret) {
DRM_ERROR("Failed to vblank\n");
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 23/27] drm/vc4: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vc4.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 6a1a9e1d72ce..f0b3e4cf5bce 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -880,7 +880,6 @@ int vc4_kms_load(struct drm_device *dev)
/* Set support for vblank irq fast disable, before drm_vblank_init() */
dev->vblank_disable_immediate = true;
- dev->irq_enabled = true;
ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
if (ret < 0) {
dev_err(dev->dev, "failed to initialize vblank\n");
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 22/27] drm/tidss: Don't use struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't use it in tidss.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tidss/tidss_irq.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_irq.c
b/drivers/gpu/drm/tidss/tidss_irq.c
index a5ec7931ef6b..2ed3e3296776 100644
--- a/drivers/gpu/drm/tidss/tidss_irq.c
+++ b/drivers/gpu/drm/tidss/tidss_irq.c
@@ -57,9 +57,6 @@ irqreturn_t tidss_irq_handler(int irq, void *arg)
unsigned int id;
dispc_irq_t irqstatus;
- if (WARN_ON(!ddev->irq_enabled))
- return IRQ_NONE;
-
irqstatus = dispc_read_and_clear_irqstatus(tidss->dispc);
for (id = 0; id < tidss->num_crtcs; id++) {
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 21/27] drm/tegra: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in tegra. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Thierry Reding Acked-by: Daniel Vetter --- drivers/gpu/drm/tegra/drm.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index f96c237b2242..8d27c21ddf48 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -1188,13 +1188,6 @@ static int host1x_drm_probe(struct host1x_device *dev) goto device; } - /* -* We don't use the drm_irq_install() helpers provided by the DRM -* core, so we need to set this manually in order to allow the -* DRM_IOCTL_WAIT_VBLANK to operate correctly. -*/ - drm->irq_enabled = true; - /* syncpoints are used for full 32-bit hardware VBLANK counters */ drm->max_vblank_count = 0x; -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 15/27] drm/omapdrm: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct omap_drm_device.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++
drivers/gpu/drm/omapdrm/omap_irq.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index d6f136984da9..591d4c273f02 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -48,6 +48,8 @@ struct omap_drm_private {
struct dss_device *dss;
struct dispc_device *dispc;
+ bool irq_enabled;
+
unsigned int num_pipes;
struct omap_drm_pipeline pipes[8];
struct omap_drm_pipeline *channels[8];
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 15148d4b35b5..bb6e3fc18204 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -291,7 +291,7 @@ int omap_drm_irq_install(struct drm_device *dev)
if (ret < 0)
return ret;
- dev->irq_enabled = true;
+ priv->irq_enabled = true;
return 0;
}
@@ -300,10 +300,10 @@ void omap_drm_irq_uninstall(struct drm_device *dev)
{
struct omap_drm_private *priv = dev->dev_private;
- if (!dev->irq_enabled)
+ if (!priv->irq_enabled)
return;
- dev->irq_enabled = false;
+ priv->irq_enabled = false;
dispc_free_irq(priv->dispc, dev);
}
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 20/27] drm/sun4i: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in sun4i. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c index af335f58bdfc..570f3af25e86 100644 --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c @@ -97,8 +97,6 @@ static int sun4i_drv_bind(struct device *dev) if (ret) goto cleanup_mode_config; - drm->irq_enabled = true; - /* Remove early framebuffers (ie. simplefb) */ ret = drm_aperture_remove_framebuffers(false, "sun4i-drm-fb"); if (ret) -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 19/27] drm/stm: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in stm. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/stm/ltdc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 08b71248044d..e9c5a52f041a 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -1339,9 +1339,6 @@ int ltdc_load(struct drm_device *ddev) goto err; } - /* Allow usage of vblank without having to call drm_irq_install */ - ddev->irq_enabled = 1; - clk_disable_unprepare(ldev->pixel_clk); pinctrl_pm_select_sleep_state(ddev->dev); -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 17/27] drm/rockchip: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in rockchip. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index b730b8d5d949..c8e60fd9ff24 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -162,12 +162,6 @@ static int rockchip_drm_bind(struct device *dev) drm_mode_config_reset(drm_dev); - /* -* enable drm irq mode. -* - with irq_enabled = true, we can use the vblank feature. -*/ - drm_dev->irq_enabled = true; - ret = rockchip_drm_fbdev_init(drm_dev); if (ret) goto err_unbind_all; -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 18/27] drm/sti: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in sti. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/sti/sti_compositor.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_compositor.c b/drivers/gpu/drm/sti/sti_compositor.c index 319962a2c17b..9caaf3ccfabe 100644 --- a/drivers/gpu/drm/sti/sti_compositor.c +++ b/drivers/gpu/drm/sti/sti_compositor.c @@ -145,8 +145,6 @@ static int sti_compositor_bind(struct device *dev, } drm_vblank_init(drm_dev, crtc_id); - /* Allow usage of vblank without having to call drm_irq_install */ - drm_dev->irq_enabled = 1; return 0; } -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 16/27] drm/rcar-du: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in rcar-du. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index bfbff90588cb..e289a66594a7 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -593,8 +593,6 @@ static int rcar_du_probe(struct platform_device *pdev) goto error; } - rcdu->ddev.irq_enabled = 1; - /* * Register the DRM device with the core and the connectors with * sysfs. -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 14/27] drm/nouveau: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in nouveau. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index a616cf4573b8..1cb14e99a60c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -553,8 +553,6 @@ nouveau_drm_device_init(struct drm_device *dev) if (ret) goto fail_master; - dev->irq_enabled = true; - nvxx_client(>client.base)->debug = nvkm_dbgopt(nouveau_debug, "DRM"); @@ -795,7 +793,6 @@ nouveau_drm_device_remove(struct drm_device *dev) drm_dev_unregister(dev); - dev->irq_enabled = false; client = nvxx_client(>client.base); device = nvkm_device_find(client->device); -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 13/27] drm/mediatek: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in mediatek. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index b46bdb8985da..9b60bec33d3b 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -270,12 +270,6 @@ static int mtk_drm_kms_init(struct drm_device *drm) goto err_component_unbind; } - /* -* We don't use the drm_irq_install() helpers provided by the DRM -* core, so we need to set this manually in order to allow the -* DRM_IOCTL_WAIT_VBLANK to operate correctly. -*/ - drm->irq_enabled = true; ret = drm_vblank_init(drm, MAX_CRTC); if (ret < 0) goto err_component_unbind; -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 11/27] drm/imx: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in imx. v3: * move dcss changes into separate patch (Laurentiu) Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Philipp Zabel Acked-by: Daniel Vetter --- drivers/gpu/drm/imx/imx-drm-core.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index 76819a8ac37f..9558e9e1b431 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -207,17 +207,6 @@ static int imx_drm_bind(struct device *dev) if (IS_ERR(drm)) return PTR_ERR(drm); - /* -* enable drm irq mode. -* - with irq_enabled = true, we can use the vblank feature. -* -* P.S. note that we wouldn't use drm irq handler but -* just specific driver own one instead because -* drm framework supports only one irq handler and -* drivers can well take care of their interrupts -*/ - drm->irq_enabled = true; - /* * set max width and height as default value(4096x4096). * this value would be used to check framebuffer size limitation -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 12/27] drm/imx/dcss: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in dcss. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Laurentiu Palcu Acked-by: Daniel Vetter --- drivers/gpu/drm/imx/dcss/dcss-kms.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c index 37ae68a7fba5..917834b1c80e 100644 --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c @@ -133,8 +133,6 @@ struct dcss_kms_dev *dcss_kms_attach(struct dcss_dev *dcss) if (ret) goto cleanup_mode_config; - drm->irq_enabled = true; - ret = dcss_kms_bridge_connector_init(kms); if (ret) goto cleanup_mode_config; @@ -178,7 +176,6 @@ void dcss_kms_detach(struct dcss_kms_dev *kms) drm_kms_helper_poll_fini(drm); drm_atomic_helper_shutdown(drm); drm_crtc_vblank_off(>crtc.base); - drm->irq_enabled = false; drm_mode_config_cleanup(drm); dcss_crtc_deinit(>crtc, drm); drm->dev_private = NULL; -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 10/27] drm/kirin: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in kirin.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index e590e19db657..98ae9a48f3fe 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -185,8 +185,6 @@ static int kirin_drm_kms_init(struct drm_device *dev,
DRM_ERROR("failed to initialize vblank.\n");
goto err_unbind_all;
}
- /* with irq_enabled = true, we can use the vblank feature. */
- dev->irq_enabled = true;
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 09/27] drm/exynos: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in exynos. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index e60257f1f24b..d8f1cf4d6b69 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -300,16 +300,6 @@ static int exynos_drm_bind(struct device *dev) drm_mode_config_reset(drm); - /* -* enable drm irq mode. -* - with irq_enabled = true, we can use the vblank feature. -* -* P.S. note that we wouldn't use drm irq handler but -* just specific driver own one instead because -* drm framework supports only one irq handler. -*/ - drm->irq_enabled = true; - /* init kms poll for handling hpd */ drm_kms_helper_poll_init(drm); -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 08/27] drm/malidp: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in malidp.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Liviu Dudau
Acked-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_drv.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index de59f3302516..78d15b04b105 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -847,8 +847,6 @@ static int malidp_bind(struct device *dev)
if (ret < 0)
goto irq_init_fail;
- drm->irq_enabled = true;
-
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
@@ -874,7 +872,6 @@ static int malidp_bind(struct device *dev)
vblank_fail:
malidp_se_irq_fini(hwdev);
malidp_de_irq_fini(hwdev);
- drm->irq_enabled = false;
irq_init_fail:
drm_atomic_helper_shutdown(drm);
component_unbind_all(dev, drm);
@@ -909,7 +906,6 @@ static void malidp_unbind(struct device *dev)
drm_atomic_helper_shutdown(drm);
malidp_se_irq_fini(hwdev);
malidp_de_irq_fini(hwdev);
- drm->irq_enabled = false;
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 07/27] drm/komeda: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in komeda. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Liviu Dudau Acked-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index ff45f23f3d56..52a6db5707a3 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -301,8 +301,6 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) if (err) goto free_component_binding; - drm->irq_enabled = true; - drm_kms_helper_poll_init(drm); err = drm_dev_register(drm, 0); @@ -313,7 +311,6 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) free_interrupts: drm_kms_helper_poll_fini(drm); - drm->irq_enabled = false; free_component_binding: component_unbind_all(mdev->dev, drm); cleanup_mode_config: @@ -331,7 +328,6 @@ void komeda_kms_detach(struct komeda_kms_dev *kms) drm_dev_unregister(drm); drm_kms_helper_poll_fini(drm); drm_atomic_helper_shutdown(drm); - drm->irq_enabled = false; component_unbind_all(mdev->dev, drm); drm_mode_config_cleanup(drm); komeda_kms_cleanup_private_objs(kms); -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 05/27] drm/armada: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in armada. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/armada/armada_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c index dab0a1f0983b..4a64f1b9ec4d 100644 --- a/drivers/gpu/drm/armada/armada_drv.c +++ b/drivers/gpu/drm/armada/armada_drv.c @@ -130,8 +130,6 @@ static int armada_drm_bind(struct device *dev) if (ret) goto err_comp; - priv->drm.irq_enabled = true; - drm_mode_config_reset(>drm); ret = armada_fbdev_init(>drm); -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 06/27] drm/i915: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct drm_i915_private.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 8
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01e11fe38642..48c1835bd54b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1134,6 +1134,8 @@ struct drm_i915_private {
/* For i915gm/i945gm vblank irq workaround */
u8 vblank_enabled;
+ bool irq_enabled;
+
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a11bdb667241..987211f21761 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4488,14 +4488,14 @@ int intel_irq_install(struct drm_i915_private *dev_priv)
*/
dev_priv->runtime_pm.irqs_enabled = true;
- dev_priv->drm.irq_enabled = true;
+ dev_priv->irq_enabled = true;
intel_irq_reset(dev_priv);
ret = request_irq(irq, intel_irq_handler(dev_priv),
IRQF_SHARED, DRIVER_NAME, dev_priv);
if (ret < 0) {
- dev_priv->drm.irq_enabled = false;
+ dev_priv->irq_enabled = false;
return ret;
}
@@ -4521,10 +4521,10 @@ void intel_irq_uninstall(struct drm_i915_private
*dev_priv)
* intel_modeset_driver_remove() calling us out of sequence.
* Would be nice if it didn't do that...
*/
- if (!dev_priv->drm.irq_enabled)
+ if (!dev_priv->irq_enabled)
return;
- dev_priv->drm.irq_enabled = false;
+ dev_priv->irq_enabled = false;
intel_irq_reset(dev_priv);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 04/27] drm: Don't test for IRQ support in VBLANK ioctls
For KMS drivers, replace the IRQ check in VBLANK ioctls with a check for
vblank support. IRQs might be enabled wthout vblanking being supported.
This change also removes the DRM framework's only dependency on IRQ state
for non-legacy drivers. For legacy drivers with userspace modesetting,
the original test remains in drm_wait_vblank_ioctl().
v4:
* avoid preprocessor ifdef in drm_wait_vblank_ioctl()
(Jani, Thierry)
v3:
* optimize test in drm_wait_vblank_ioctl() for KMS case (Liviu)
* update docs for drm_irq_uninstall()
v2:
* keep the old test for legacy drivers in
drm_wait_vblank_ioctl() (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Reviewed-by: Liviu Dudau
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c| 13 -
drivers/gpu/drm/drm_vblank.c | 15 ---
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c3bd664ea733..945dd82e2ea3 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -74,10 +74,8 @@
* only supports devices with a single interrupt on the main device stored in
* _device.dev and set as the device paramter in drm_dev_alloc().
*
- * These IRQ helpers are strictly optional. Drivers which roll their own only
- * need to set _device.irq_enabled to signal the DRM core that vblank
- * interrupts are working. Since these helpers don't automatically clean up the
- * requested interrupt like e.g. devm_request_irq() they're not really
+ * These IRQ helpers are strictly optional. Since these helpers don't
automatically
+ * clean up the requested interrupt like e.g. devm_request_irq() they're not
really
* recommended.
*/
@@ -91,9 +89,7 @@
* and after the installation.
*
* This is the simplified helper interface provided for drivers with no special
- * needs. Drivers which need to install interrupt handlers for multiple
- * interrupts must instead set _device.irq_enabled to signal the DRM core
- * that vblank interrupts are available.
+ * needs.
*
* @irq must match the interrupt number that would be passed to request_irq(),
* if called directly instead of using this helper function.
@@ -156,8 +152,7 @@ EXPORT_SYMBOL(drm_irq_install);
*
* Calls the driver's _driver.irq_uninstall function and unregisters the
IRQ
* handler. This should only be called by drivers which used drm_irq_install()
- * to set up their interrupt handler. Other drivers must only reset
- * _device.irq_enabled to false.
+ * to set up their interrupt handler.
*
* Note that for kernel modesetting drivers it is a bug if this function fails.
* The sanity checks are only to catch buggy user modesetting drivers which
call
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 3417e1ac7918..bba6781cc48f 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1737,6 +1737,15 @@ static void drm_wait_vblank_reply(struct drm_device
*dev, unsigned int pipe,
reply->tval_usec = ts.tv_nsec / 1000;
}
+static bool drm_wait_vblank_supported(struct drm_device *dev)
+{
+ if (IS_ENABLED(CONFIG_DRM_LEGACY)) {
+ if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
+ return dev->irq_enabled;
+ }
+ return drm_dev_has_vblank(dev);
+}
+
int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
@@ -1748,7 +1757,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
*data,
unsigned int pipe_index;
unsigned int flags, pipe, high_pipe;
- if (!dev->irq_enabled)
+ if (!drm_wait_vblank_supported(dev))
return -EOPNOTSUPP;
if (vblwait->request.type & _DRM_VBLANK_SIGNAL)
@@ -2023,7 +2032,7 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev,
void *data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
- if (!dev->irq_enabled)
+ if (!drm_dev_has_vblank(dev))
return -EOPNOTSUPP;
crtc = drm_crtc_find(dev, file_priv, get_seq->crtc_id);
@@ -2082,7 +2091,7 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device *dev,
void *data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
- if (!dev->irq_enabled)
+ if (!drm_dev_has_vblank(dev))
return -EOPNOTSUPP;
crtc = drm_crtc_find(dev, file_priv, queue_seq->crtc_id);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 02/27] drm/hibmc: Call drm_irq_uninstall() unconditionally
Remove the check around drm_irq_uninstall(). The same test is
done by the function internally. The tested state in irq_enabled
is considered obsolete and should not be used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Tian Tao
Acked-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index f4bc5386574a..f8ef711bbe5d 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -253,8 +253,7 @@ static int hibmc_unload(struct drm_device *dev)
{
drm_atomic_helper_shutdown(dev);
- if (dev->irq_enabled)
- drm_irq_uninstall(dev);
+ drm_irq_uninstall(dev);
pci_disable_msi(to_pci_dev(dev->dev));
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 03/27] drm/radeon: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct radeon_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c | 16
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 0d8ef2368adf..7ec581363e23 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -288,7 +288,7 @@ static void radeon_fence_check_lockup(struct work_struct
*work)
return;
}
- if (fence_drv->delayed_irq && rdev->ddev->irq_enabled) {
+ if (fence_drv->delayed_irq && rdev->irq.installed) {
unsigned long irqflags;
fence_drv->delayed_irq = false;
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 84d0b1a3355f..a36ce826d0c0 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -357,7 +357,7 @@ void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev,
int ring)
{
unsigned long irqflags;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
if (atomic_inc_return(>irq.ring_int[ring]) == 1) {
@@ -396,7 +396,7 @@ void radeon_irq_kms_sw_irq_put(struct radeon_device *rdev,
int ring)
{
unsigned long irqflags;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
if (atomic_dec_and_test(>irq.ring_int[ring])) {
@@ -422,7 +422,7 @@ void radeon_irq_kms_pflip_irq_get(struct radeon_device
*rdev, int crtc)
if (crtc < 0 || crtc >= rdev->num_crtc)
return;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
if (atomic_inc_return(>irq.pflip[crtc]) == 1) {
@@ -448,7 +448,7 @@ void radeon_irq_kms_pflip_irq_put(struct radeon_device
*rdev, int crtc)
if (crtc < 0 || crtc >= rdev->num_crtc)
return;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
if (atomic_dec_and_test(>irq.pflip[crtc])) {
@@ -470,7 +470,7 @@ void radeon_irq_kms_enable_afmt(struct radeon_device *rdev,
int block)
{
unsigned long irqflags;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
spin_lock_irqsave(>irq.lock, irqflags);
@@ -492,7 +492,7 @@ void radeon_irq_kms_disable_afmt(struct radeon_device
*rdev, int block)
{
unsigned long irqflags;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
spin_lock_irqsave(>irq.lock, irqflags);
@@ -514,7 +514,7 @@ void radeon_irq_kms_enable_hpd(struct radeon_device *rdev,
unsigned hpd_mask)
unsigned long irqflags;
int i;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
spin_lock_irqsave(>irq.lock, irqflags);
@@ -537,7 +537,7 @@ void radeon_irq_kms_disable_hpd(struct radeon_device *rdev,
unsigned hpd_mask)
unsigned long irqflags;
int i;
- if (!rdev->ddev->irq_enabled)
+ if (!rdev->irq.installed)
return;
spin_lock_irqsave(>irq.lock, irqflags);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 01/27] drm/amdgpu: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct amdgpu_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 32ce0e679dc7..7dad44e73cf6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -599,7 +599,7 @@ void amdgpu_irq_gpu_reset_resume_helper(struct
amdgpu_device *adev)
int amdgpu_irq_get(struct amdgpu_device *adev, struct amdgpu_irq_src *src,
unsigned type)
{
- if (!adev_to_drm(adev)->irq_enabled)
+ if (!adev->irq.installed)
return -ENOENT;
if (type >= src->num_types)
@@ -629,7 +629,7 @@ int amdgpu_irq_get(struct amdgpu_device *adev, struct
amdgpu_irq_src *src,
int amdgpu_irq_put(struct amdgpu_device *adev, struct amdgpu_irq_src *src,
unsigned type)
{
- if (!adev_to_drm(adev)->irq_enabled)
+ if (!adev->irq.installed)
return -ENOENT;
if (type >= src->num_types)
@@ -660,7 +660,7 @@ int amdgpu_irq_put(struct amdgpu_device *adev, struct
amdgpu_irq_src *src,
bool amdgpu_irq_enabled(struct amdgpu_device *adev, struct amdgpu_irq_src *src,
unsigned type)
{
- if (!adev_to_drm(adev)->irq_enabled)
+ if (!adev->irq.installed)
return false;
if (type >= src->num_types)
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 00/27] Deprecate struct drm_device.irq_enabled
Remove references to struct drm_device.irq_enabled from modern DRM drivers and core. KMS drivers enable IRQs for their devices internally. They don't have to keep track of the IRQ state via irq_enabled. For vblanking, it's cleaner to test for vblanking support directly than to test for enabled IRQs. The first 3 patches replace uses of irq_enabled that are not required. Patch 4 fixes vblank ioctls to actually test for vblank support instead of IRQs (for KMS drivers). The rest of the patchset removes irq_enabled from all non-legacy drivers. The only exceptions are i915 and omapdrm, which have an internal dpendency on the field's value. For these drivers, the state gets duplicated internally. With the patchset applied, drivers can later switch over to plain Linux IRQ interfaces and DRM's IRQ midlayer can be declared legacy. v4: * avoid preprocessor ifdef in drm_wait_vblank_ioctl() (Jani, Thierry) v3: * update armada, i915, rcar-du and vkms as well (Laurent) * optimize drm_wait_vblank_ioctl() for KMS (Liviu) * move imx/dcss changes into their own patch (Laurentiu) * doc cleanups v2: * keep the original test for legacy drivers in drm_wait_vblank_ioctl() (Daniel) Thomas Zimmermann (27): drm/amdgpu: Track IRQ state in local device state drm/hibmc: Call drm_irq_uninstall() unconditionally drm/radeon: Track IRQ state in local device state drm: Don't test for IRQ support in VBLANK ioctls drm/armada: Don't set struct drm_device.irq_enabled drm/i915: Track IRQ state in local device state drm/komeda: Don't set struct drm_device.irq_enabled drm/malidp: Don't set struct drm_device.irq_enabled drm/exynos: Don't set struct drm_device.irq_enabled drm/kirin: Don't set struct drm_device.irq_enabled drm/imx: Don't set struct drm_device.irq_enabled drm/imx/dcss: Don't set struct drm_device.irq_enabled drm/mediatek: Don't set struct drm_device.irq_enabled drm/nouveau: Don't set struct drm_device.irq_enabled drm/omapdrm: Track IRQ state in local device state drm/rcar-du: Don't set struct drm_device.irq_enabled drm/rockchip: Don't set struct drm_device.irq_enabled drm/sti: Don't set struct drm_device.irq_enabled drm/stm: Don't set struct drm_device.irq_enabled drm/sun4i: Don't set struct drm_device.irq_enabled drm/tegra: Don't set struct drm_device.irq_enabled drm/tidss: Don't use struct drm_device.irq_enabled drm/vc4: Don't set struct drm_device.irq_enabled drm/vkms: Don't set struct drm_device.irq_enabled drm/vmwgfx: Don't set struct drm_device.irq_enabled drm/xlnx: Don't set struct drm_device.irq_enabled drm/zte: Don't set struct drm_device.irq_enabled drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 6 +++--- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 drivers/gpu/drm/arm/malidp_drv.c| 4 drivers/gpu/drm/armada/armada_drv.c | 2 -- drivers/gpu/drm/drm_irq.c | 13 - drivers/gpu/drm/drm_vblank.c| 15 --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 -- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +-- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 -- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_irq.c | 8 drivers/gpu/drm/imx/dcss/dcss-kms.c | 3 --- drivers/gpu/drm/imx/imx-drm-core.c | 11 --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 -- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 --- drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++ drivers/gpu/drm/omapdrm/omap_irq.c | 6 +++--- drivers/gpu/drm/radeon/radeon_fence.c | 2 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 16 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 -- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 -- drivers/gpu/drm/sti/sti_compositor.c| 2 -- drivers/gpu/drm/stm/ltdc.c | 3 --- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 -- drivers/gpu/drm/tegra/drm.c | 7 --- drivers/gpu/drm/tidss/tidss_irq.c | 3 --- drivers/gpu/drm/vc4/vc4_kms.c | 1 - drivers/gpu/drm/vkms/vkms_drv.c | 2 -- drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 8 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 -- drivers/gpu/drm/zte/zx_drm_drv.c| 6 -- 31 files changed, 40 insertions(+), 122 deletions(-) base-commit: 8c1323b422f8473421682ba783b5949ddd89a3f4 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] KVM: do not allow mapping valid but non-refcounted pages
On 25/06/21 09:58, Christian Borntraeger wrote:
On 25.06.21 09:36, David Stevens wrote:
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it from 0 to 1.
When the reference is dropped, this will free the page incorrectly.
Fix this by only taking a reference on the page if it was non-zero,
which indicates it is participating in normal refcounting (and can be
released with put_page).
Signed-off-by: Nicholas Piggin
I guess this would be the small fix for stable? Do we want to add that cc?
Reviewed-by: Christian Borntraeger
Yes, this one is going to Linus today. The rest is for 5.15.
Paolo
---
virt/kvm/kvm_main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3dcc2abbfc60..f7445c3bcd90 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2175,6 +2175,13 @@ static bool vma_is_valid(struct vm_area_struct
*vma, bool write_fault)
return true;
}
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
+ return get_page_unless_zero(pfn_to_page(pfn));
+}
+
static int hva_to_pfn_remapped(struct vm_area_struct *vma,
unsigned long addr, bool *async,
bool write_fault, bool *writable,
@@ -2224,13 +2231,21 @@ static int hva_to_pfn_remapped(struct
vm_area_struct *vma,
* Whoever called remap_pfn_range is also going to call e.g.
* unmap_mapping_range before the underlying pages are freed,
* causing a call to our MMU notifier.
+ *
+ * Certain IO or PFNMAP mappings can be backed with valid
+ * struct pages, but be allocated without refcounting e.g.,
+ * tail pages of non-compound higher order allocations, which
+ * would then underflow the refcount when the caller does the
+ * required put_page. Don't allow those pages here.
*/
- kvm_get_pfn(pfn);
+ if (!kvm_try_get_pfn(pfn))
+ r = -EFAULT;
out:
pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
- return 0;
+
+ return r;
}
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reinstate the mmap ioctl for some platforms
On Fri, Jun 25, 2021 at 9:48 AM Maarten Lankhorst
wrote:
>
> Op 24-06-2021 om 14:04 schreef Daniel Vetter:
> > On Thu, Jun 24, 2021 at 1:29 PM Thomas Hellström
> > wrote:
> >> Reinstate the mmap ioctl for all current integrated platforms.
> >> The intention was really to have it disabled for discrete graphics
> >> where we enforce a single mmap mode.
> >>
> >> Fixes: 35cbd91eb541 ("drm/i915: Disable mmap ioctl for gen12+")
> >> Signed-off-by: Thomas Hellström
> >> Reviewed-by: Matthew Auld
> > Acked-by: Daniel Vetter
> >
> >> ---
> >> v2:
> >> - Added a R-B.
> >> - Fixed up the code comment a bit.
> >> ---
> >> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 ---
> >> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> index 2fd155742bd2..4f50a508c7a0 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> >> @@ -62,10 +62,11 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> >> struct drm_i915_gem_object *obj;
> >> unsigned long addr;
> >>
> >> - /* mmap ioctl is disallowed for all platforms after TGL-LP. This
> >> also
> >> -* covers all platforms with local memory.
> >> + /*
> >> +* mmap ioctl is disallowed for all discrete platforms,
> >> +* and for all platforms with GRAPHICS_VER > 12.
> >> */
> >> - if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915))
> >> + if (IS_DGFX(i915) || GRAPHICS_VER(i915) > 12)
> >> return -EOPNOTSUPP;
> >>
> >> if (args->flags & ~(I915_MMAP_WC))
> >> --
> >> 2.31.1
> >>
> >
> Would keeping this change unapplied break any currently shipping platforms?
> If not, could we leave it as-is?
It breaks media on rkl/adl afaik. Which should be part of the commit message.
-Daniel
--
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.BUILD: failure for Remove uses of struct page from x86 and arm64 MMU
== Series Details == Series: Remove uses of struct page from x86 and arm64 MMU URL : https://patchwork.freedesktop.org/series/91908/ State : failure == Summary == Applying: KVM: do not allow mapping valid but non-refcounted pages Applying: KVM: mmu: introduce new gfn_to_pfn_page functions Applying: KVM: x86/mmu: use gfn_to_pfn_page error: sha1 information is lacking or useless (arch/x86/kvm/mmu/mmu.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 KVM: x86/mmu: use gfn_to_pfn_page 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
Re: [Intel-gfx] [PATCH v2] drm/i915: Reinstate the mmap ioctl for some platforms
Op 24-06-2021 om 14:04 schreef Daniel Vetter:
> On Thu, Jun 24, 2021 at 1:29 PM Thomas Hellström
> wrote:
>> Reinstate the mmap ioctl for all current integrated platforms.
>> The intention was really to have it disabled for discrete graphics
>> where we enforce a single mmap mode.
>>
>> Fixes: 35cbd91eb541 ("drm/i915: Disable mmap ioctl for gen12+")
>> Signed-off-by: Thomas Hellström
>> Reviewed-by: Matthew Auld
> Acked-by: Daniel Vetter
>
>> ---
>> v2:
>> - Added a R-B.
>> - Fixed up the code comment a bit.
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index 2fd155742bd2..4f50a508c7a0 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -62,10 +62,11 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
>> struct drm_i915_gem_object *obj;
>> unsigned long addr;
>>
>> - /* mmap ioctl is disallowed for all platforms after TGL-LP. This
>> also
>> -* covers all platforms with local memory.
>> + /*
>> +* mmap ioctl is disallowed for all discrete platforms,
>> +* and for all platforms with GRAPHICS_VER > 12.
>> */
>> - if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915))
>> + if (IS_DGFX(i915) || GRAPHICS_VER(i915) > 12)
>> return -EOPNOTSUPP;
>>
>> if (args->flags & ~(I915_MMAP_WC))
>> --
>> 2.31.1
>>
>
Would keeping this change unapplied break any currently shipping platforms? If
not, could we leave it as-is?
___
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, drm/ttm: Update the ttm_move_memcpy() interface
== Series Details == Series: drm/i915, drm/ttm: Update the ttm_move_memcpy() interface URL : https://patchwork.freedesktop.org/series/91893/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10278_full -> Patchwork_20463_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20463_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20463_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_20463_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-priority-all: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/shard-tglb5/igt@gem_exec_whis...@basic-queues-priority-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-tglb8/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-kbl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-kbl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html Warnings * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4: - shard-iclb: [SKIP][4] ([i915#658]) -> [SKIP][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/shard-iclb4/igt@kms_psr2...@overlay-plane-update-sf-dmg-area-4.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-iclb2/igt@kms_psr2...@overlay-plane-update-sf-dmg-area-4.html Known issues Here are the changes found in Patchwork_20463_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][6] ([i915#3002]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-apl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-snb7/igt@gem_ctx_persiste...@idempotent.html * igt@gem_exec_capture@pi@vcs0: - shard-kbl: NOTRUN -> [INCOMPLETE][8] ([i915#2369] / [i915#794]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-kbl2/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.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_20463/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-glk8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_fence@parallel@vcs0: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/shard-glk6/igt@gem_exec_fence@paral...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-glk4/igt@gem_exec_fence@paral...@vcs0.html * igt@gem_exec_params@no-vebox: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109283]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-iclb3/igt@gem_exec_par...@no-vebox.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][18] ([i915#3633]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/shard-apl3/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-kbl: NOTRUN -> [FAIL][19] ([i915#3633]) +4 similar issues [19]:
[Intel-gfx] [PATCH v2 5/5] KVM: mmu: remove over-aggressive warnings
From: David Stevens Remove two warnings that require ref counts for pages to be non-zero, as mapped pfns from follow_pfn may not have an initialized ref count. Signed-off-by: David Stevens --- arch/x86/kvm/mmu/mmu.c | 7 --- virt/kvm/kvm_main.c| 2 +- 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index dd5cb6e33591..0c47245594c6 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -607,13 +607,6 @@ static int mmu_spte_clear_track_bits(u64 *sptep) pfn = spte_to_pfn(old_spte); - /* -* KVM does not hold the refcount of the page used by -* kvm mmu, before reclaiming the page, we should -* unmap it from mmu first. -*/ - WARN_ON(!kvm_is_reserved_pfn(pfn) && !page_count(pfn_to_page(pfn))); - if (is_accessed_spte(old_spte)) kvm_set_pfn_accessed(pfn); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 1de8702845ac..ce7126bab4b0 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -168,7 +168,7 @@ bool kvm_is_zone_device_pfn(kvm_pfn_t pfn) * the device has been pinned, e.g. by get_user_pages(). WARN if the * page_count() is zero to help detect bad usage of this helper. */ - if (!pfn_valid(pfn) || WARN_ON_ONCE(!page_count(pfn_to_page(pfn + if (!pfn_valid(pfn) || !page_count(pfn_to_page(pfn))) return false; return is_zone_device_page(pfn_to_page(pfn)); -- 2.32.0.93.g670b81a890-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] KVM: arm64/mmu: use gfn_to_pfn_page
From: David Stevens
Covert usages of the deprecated gfn_to_pfn functions to the new
gfn_to_pfn_page functions.
Signed-off-by: David Stevens
---
arch/arm64/kvm/mmu.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index c10207fed2f3..c29da690ed74 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -780,7 +780,7 @@ static bool fault_supports_stage2_huge_mapping(struct
kvm_memory_slot *memslot,
static unsigned long
transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
unsigned long hva, kvm_pfn_t *pfnp,
- phys_addr_t *ipap)
+ struct page **page, phys_addr_t *ipap)
{
kvm_pfn_t pfn = *pfnp;
@@ -789,7 +789,7 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
* sure that the HVA and IPA are sufficiently aligned and that the
* block map is contained within the memslot.
*/
- if (kvm_is_transparent_hugepage(pfn) &&
+ if (*page && kvm_is_transparent_hugepage(pfn) &&
fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE)) {
/*
* The address we faulted on is backed by a transparent huge
@@ -810,10 +810,11 @@ transparent_hugepage_adjust(struct kvm_memory_slot
*memslot,
* page accordingly.
*/
*ipap &= PMD_MASK;
- kvm_release_pfn_clean(pfn);
+ put_page(*page);
pfn &= ~(PTRS_PER_PMD - 1);
- kvm_get_pfn(pfn);
*pfnp = pfn;
+ *page = pfn_to_page(pfn);
+ get_page(*page);
return PMD_SIZE;
}
@@ -837,6 +838,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
short vma_shift;
gfn_t gfn;
kvm_pfn_t pfn;
+ struct page *page;
bool logging_active = memslot_is_logging(memslot);
unsigned long fault_level = kvm_vcpu_trap_get_fault_level(vcpu);
unsigned long vma_pagesize, fault_granule;
@@ -933,8 +935,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
*/
smp_rmb();
- pfn = __gfn_to_pfn_memslot(memslot, gfn, false, NULL,
- write_fault, , NULL);
+ pfn = __gfn_to_pfn_page_memslot(memslot, gfn, false, NULL,
+ write_fault, , NULL, );
if (pfn == KVM_PFN_ERR_HWPOISON) {
kvm_send_hwpoison_signal(hva, vma_shift);
return 0;
@@ -967,7 +969,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
*/
if (vma_pagesize == PAGE_SIZE && !force_pte)
vma_pagesize = transparent_hugepage_adjust(memslot, hva,
- , _ipa);
+ , ,
+ _ipa);
if (writable)
prot |= KVM_PGTABLE_PROT_W;
@@ -999,14 +1002,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
/* Mark the page dirty only if the fault is handled successfully */
if (writable && !ret) {
- kvm_set_pfn_dirty(pfn);
+ if (page)
+ kvm_set_pfn_dirty(pfn);
mark_page_dirty_in_slot(kvm, memslot, gfn);
}
out_unlock:
spin_unlock(>mmu_lock);
- kvm_set_pfn_accessed(pfn);
- kvm_release_pfn_clean(pfn);
+ if (page) {
+ kvm_set_pfn_accessed(pfn);
+ put_page(page);
+ }
return ret != -EAGAIN ? ret : 0;
}
--
2.32.0.93.g670b81a890-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] KVM: x86/mmu: use gfn_to_pfn_page
From: David Stevens
Covert usages of the deprecated gfn_to_pfn functions to the new
gfn_to_pfn_page functions.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 43 -
arch/x86/kvm/mmu/mmu_internal.h | 3 ++-
arch/x86/kvm/mmu/paging_tmpl.h | 23 +++---
arch/x86/kvm/mmu/tdp_mmu.c | 6 ++---
arch/x86/kvm/mmu/tdp_mmu.h | 4 +--
arch/x86/kvm/x86.c | 6 +++--
6 files changed, 51 insertions(+), 34 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 00732757cc60..dd5cb6e33591 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2702,8 +2702,9 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
return ret;
}
-static kvm_pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
-bool no_dirty_log)
+static kvm_pfn_t pte_prefetch_gfn_to_pfn_page(struct kvm_vcpu *vcpu,
+ gfn_t gfn, bool no_dirty_log,
+ struct page **page)
{
struct kvm_memory_slot *slot;
@@ -2711,7 +2712,7 @@ static kvm_pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu
*vcpu, gfn_t gfn,
if (!slot)
return KVM_PFN_ERR_FAULT;
- return gfn_to_pfn_memslot_atomic(slot, gfn);
+ return gfn_to_pfn_page_memslot_atomic(slot, gfn, page);
}
static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
@@ -2840,7 +2841,8 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm,
int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, gfn_t gfn,
int max_level, kvm_pfn_t *pfnp,
- bool huge_page_disallowed, int *req_level)
+ struct page *page, bool huge_page_disallowed,
+ int *req_level)
{
struct kvm_memory_slot *slot;
kvm_pfn_t pfn = *pfnp;
@@ -2852,6 +2854,9 @@ int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, gfn_t
gfn,
if (unlikely(max_level == PG_LEVEL_4K))
return PG_LEVEL_4K;
+ if (!page)
+ return PG_LEVEL_4K;
+
if (is_error_noslot_pfn(pfn) || kvm_is_reserved_pfn(pfn))
return PG_LEVEL_4K;
@@ -2906,7 +2911,8 @@ void disallowed_hugepage_adjust(u64 spte, gfn_t gfn, int
cur_level,
}
static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
- int map_writable, int max_level, kvm_pfn_t pfn,
+ int map_writable, int max_level,
+ kvm_pfn_t pfn, struct page *page,
bool prefault, bool is_tdp)
{
bool nx_huge_page_workaround_enabled = is_nx_huge_page_enabled();
@@ -2919,7 +2925,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa,
u32 error_code,
gfn_t gfn = gpa >> PAGE_SHIFT;
gfn_t base_gfn = gfn;
- level = kvm_mmu_hugepage_adjust(vcpu, gfn, max_level, ,
+ level = kvm_mmu_hugepage_adjust(vcpu, gfn, max_level, , page,
huge_page_disallowed, _level);
trace_kvm_mmu_spte_requested(gpa, level, pfn);
@@ -3768,8 +3774,9 @@ static bool kvm_arch_setup_async_pf(struct kvm_vcpu
*vcpu, gpa_t cr2_or_gpa,
}
static bool try_async_pf(struct kvm_vcpu *vcpu, bool prefault, gfn_t gfn,
-gpa_t cr2_or_gpa, kvm_pfn_t *pfn, hva_t *hva,
-bool write, bool *writable)
+gpa_t cr2_or_gpa, kvm_pfn_t *pfn,
+hva_t *hva, bool write, bool *writable,
+struct page **page)
{
struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
bool async;
@@ -3790,8 +3797,8 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool
prefault, gfn_t gfn,
}
async = false;
- *pfn = __gfn_to_pfn_memslot(slot, gfn, false, ,
- write, writable, hva);
+ *pfn = __gfn_to_pfn_page_memslot(slot, gfn, false, ,
+write, writable, hva, page);
if (!async)
return false; /* *pfn has correct page already */
@@ -3805,8 +3812,8 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool
prefault, gfn_t gfn,
return true;
}
- *pfn = __gfn_to_pfn_memslot(slot, gfn, false, NULL,
- write, writable, hva);
+ *pfn = __gfn_to_pfn_page_memslot(slot, gfn, false, NULL,
+write, writable, hva, page);
return false;
}
@@ -3820,6 +3827,7 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t
gpa, u32 error_code,
gfn_t gfn = gpa >> PAGE_SHIFT;
unsigned long mmu_seq;
kvm_pfn_t pfn;
+ struct page *page;
hva_t hva;
int r;
@@ -3840,7 +3848,7 @@ static int direct_page_fault(struct kvm_vcpu *vcpu,
[Intel-gfx] [PATCH v2 2/5] KVM: mmu: introduce new gfn_to_pfn_page functions
From: David Stevens
Introduce new gfn_to_pfn_page functions that parallel existing
gfn_to_pfn functions. The new functions are identical except they take
an additional out parameter that is used to return the struct page if
the hva was resolved by gup. This allows callers to differentiate the
gup and follow_pte cases, which in turn allows callers to only touch the
page refcount when necessitated by gup.
The old gfn_to_pfn functions are depreciated, and all callers should be
migrated to the new gfn_to_pfn_page functions. In the interim, the
gfn_to_pfn functions are reimplemented as wrappers of the corresponding
gfn_to_pfn_page functions. The wrappers take a reference to the pfn's
page that had previously been taken in hva_to_pfn_remapped.
Signed-off-by: David Stevens
---
include/linux/kvm_host.h | 17
virt/kvm/kvm_main.c | 186 ---
2 files changed, 152 insertions(+), 51 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ae7735b490b4..2f828edd7278 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -820,6 +820,19 @@ kvm_pfn_t __gfn_to_pfn_memslot(struct kvm_memory_slot
*slot, gfn_t gfn,
bool atomic, bool *async, bool write_fault,
bool *writable, hva_t *hva);
+kvm_pfn_t gfn_to_pfn_page(struct kvm *kvm, gfn_t gfn, struct page **page);
+kvm_pfn_t gfn_to_pfn_page_prot(struct kvm *kvm, gfn_t gfn,
+ bool write_fault, bool *writable,
+ struct page **page);
+kvm_pfn_t gfn_to_pfn_page_memslot(struct kvm_memory_slot *slot,
+ gfn_t gfn, struct page **page);
+kvm_pfn_t gfn_to_pfn_page_memslot_atomic(struct kvm_memory_slot *slot,
+gfn_t gfn, struct page **page);
+kvm_pfn_t __gfn_to_pfn_page_memslot(struct kvm_memory_slot *slot,
+ gfn_t gfn, bool atomic, bool *async,
+ bool write_fault, bool *writable,
+ hva_t *hva, struct page **page);
+
void kvm_release_pfn_clean(kvm_pfn_t pfn);
void kvm_release_pfn_dirty(kvm_pfn_t pfn);
void kvm_set_pfn_dirty(kvm_pfn_t pfn);
@@ -901,6 +914,10 @@ struct kvm_memslots *kvm_vcpu_memslots(struct kvm_vcpu
*vcpu);
struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t
gfn);
kvm_pfn_t kvm_vcpu_gfn_to_pfn_atomic(struct kvm_vcpu *vcpu, gfn_t gfn);
kvm_pfn_t kvm_vcpu_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn);
+kvm_pfn_t kvm_vcpu_gfn_to_pfn_page_atomic(struct kvm_vcpu *vcpu, gfn_t gfn,
+ struct page **page);
+kvm_pfn_t kvm_vcpu_gfn_to_pfn_page(struct kvm_vcpu *vcpu, gfn_t gfn,
+ struct page **page);
int kvm_vcpu_map(struct kvm_vcpu *vcpu, gpa_t gpa, struct kvm_host_map *map);
int kvm_map_gfn(struct kvm_vcpu *vcpu, gfn_t gfn, struct kvm_host_map *map,
struct gfn_to_pfn_cache *cache, bool atomic);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f7445c3bcd90..1de8702845ac 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2102,9 +2102,9 @@ static inline int check_user_page_hwpoison(unsigned long
addr)
* only part that runs if we can in atomic context.
*/
static bool hva_to_pfn_fast(unsigned long addr, bool write_fault,
- bool *writable, kvm_pfn_t *pfn)
+ bool *writable, kvm_pfn_t *pfn,
+ struct page **page)
{
- struct page *page[1];
/*
* Fast pin a writable pfn only if it is a write fault request
@@ -2115,7 +2115,7 @@ static bool hva_to_pfn_fast(unsigned long addr, bool
write_fault,
return false;
if (get_user_page_fast_only(addr, FOLL_WRITE, page)) {
- *pfn = page_to_pfn(page[0]);
+ *pfn = page_to_pfn(*page);
if (writable)
*writable = true;
@@ -2130,10 +2130,9 @@ static bool hva_to_pfn_fast(unsigned long addr, bool
write_fault,
* 1 indicates success, -errno is returned if error is detected.
*/
static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault,
- bool *writable, kvm_pfn_t *pfn)
+ bool *writable, kvm_pfn_t *pfn, struct page **page)
{
unsigned int flags = FOLL_HWPOISON;
- struct page *page;
int npages = 0;
might_sleep();
@@ -2146,7 +2145,7 @@ static int hva_to_pfn_slow(unsigned long addr, bool
*async, bool write_fault,
if (async)
flags |= FOLL_NOWAIT;
- npages = get_user_pages_unlocked(addr, 1, , flags);
+ npages = get_user_pages_unlocked(addr, 1, page, flags);
if (npages != 1)
return npages;
@@ -2156,11 +2155,11 @@ static int hva_to_pfn_slow(unsigned long addr, bool
*async,
[Intel-gfx] [PATCH v2 1/5] KVM: do not allow mapping valid but non-refcounted pages
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it from 0 to 1.
When the reference is dropped, this will free the page incorrectly.
Fix this by only taking a reference on the page if it was non-zero,
which indicates it is participating in normal refcounting (and can be
released with put_page).
Signed-off-by: Nicholas Piggin
---
virt/kvm/kvm_main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3dcc2abbfc60..f7445c3bcd90 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2175,6 +2175,13 @@ static bool vma_is_valid(struct vm_area_struct *vma,
bool write_fault)
return true;
}
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
+ return get_page_unless_zero(pfn_to_page(pfn));
+}
+
static int hva_to_pfn_remapped(struct vm_area_struct *vma,
unsigned long addr, bool *async,
bool write_fault, bool *writable,
@@ -2224,13 +2231,21 @@ static int hva_to_pfn_remapped(struct vm_area_struct
*vma,
* Whoever called remap_pfn_range is also going to call e.g.
* unmap_mapping_range before the underlying pages are freed,
* causing a call to our MMU notifier.
+*
+* Certain IO or PFNMAP mappings can be backed with valid
+* struct pages, but be allocated without refcounting e.g.,
+* tail pages of non-compound higher order allocations, which
+* would then underflow the refcount when the caller does the
+* required put_page. Don't allow those pages here.
*/
- kvm_get_pfn(pfn);
+ if (!kvm_try_get_pfn(pfn))
+ r = -EFAULT;
out:
pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
- return 0;
+
+ return r;
}
/*
--
2.32.0.93.g670b81a890-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] Remove uses of struct page from x86 and arm64 MMU
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using follow_pte in gfn_to_pfn. However, the resolved pfns may not have assoicated struct pages, so they should not be passed to pfn_to_page. This series removes such calls from the x86 and arm64 secondary MMU. To do this, this series introduces gfn_to_pfn_page functions that parallel the gfn_to_pfn functions. These functions take an extra out parameter which contains the page if the hva was resovled by gup. This allows the caller to call put_page only when necessated by gup. The gfn_to_pfn functions are depreciated. For now the functions remain with identical behavior to before, but callers should be migrated to the new gfn_to_pfn_page functions. I added new functions instead of simply adding another parameter to the existing functions to make it easier to track down users of the deprecated functions. I have migrated the x86 and arm64 secondary MMUs to the new gfn_to_pfn_page functions. This addresses CVE-2021-22543 on x86 and arm64. v1 -> v2: - Introduce new gfn_to_pfn_page functions instead of modifying the behavior of existing gfn_to_pfn functions, to make the change less invasive. - Drop changes to mmu_audit.c - Include Nicholas Piggin's patch to avoid corrupting refcount in the follow_pte case, and use it in depreciated gfn_to_pfn functions. - Rebase on kvm/next David Stevens (4): KVM: mmu: introduce new gfn_to_pfn_page functions KVM: x86/mmu: use gfn_to_pfn_page KVM: arm64/mmu: use gfn_to_pfn_page KVM: mmu: remove over-aggressive warnings Nicholas Piggin (1): KVM: do not allow mapping valid but non-refcounted pages arch/arm64/kvm/mmu.c| 26 +++-- arch/x86/kvm/mmu/mmu.c | 50 - arch/x86/kvm/mmu/mmu_internal.h | 3 +- arch/x86/kvm/mmu/paging_tmpl.h | 23 +++-- arch/x86/kvm/mmu/tdp_mmu.c | 6 +- arch/x86/kvm/mmu/tdp_mmu.h | 4 +- arch/x86/kvm/x86.c | 6 +- include/linux/kvm_host.h| 17 +++ virt/kvm/kvm_main.c | 177 +--- 9 files changed, 222 insertions(+), 90 deletions(-) -- 2.32.0.93.g670b81a890-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
