[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/4] drm/gem: Remove BUG_ON in drm_gem_private_object_init
== Series Details ==
Series: series starting with [v4,1/4] drm/gem: Remove BUG_ON in
drm_gem_private_object_init
URL : https://patchwork.freedesktop.org/series/113318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113318v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/index.html
Participating hosts (12 -> 11)
--
Additional (1): shard-rkl0
Missing(2): pig-skl-6260u pig-kbl-iris
Known issues
Here are the changes found in Patchwork_113318v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-glk: NOTRUN -> [SKIP][1] ([fdo#109271]) +42 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk3/igt@feature_discov...@display-4x.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][2] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk9/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk3/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk3/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk3/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2346])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#79]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#7742]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-rkl-3/igt@drm_fdinfo@i...@rcs0.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][14] ([i915#658]) -> [PASS][15] +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-3/igt@feature_discov...@psr1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][16] ([i915#6252]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-rkl-1/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][18] ([i915#6247]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][20] ([i915#3281]) -> [PASS][21] +11 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-6/igt@gem_exec_re...@basic-wc-read-noreloc.html
[21]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start and size from pages to bytes
== Series Details ==
Series: series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start
and size from pages to bytes
URL : https://patchwork.freedesktop.org/series/113313/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113313v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/index.html
Participating hosts (12 -> 10)
--
Missing(2): pig-skl-6260u pig-kbl-iris
Known issues
Here are the changes found in Patchwork_113313v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-glk: NOTRUN -> [SKIP][1] ([fdo#109271]) +42 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk4/igt@feature_discov...@display-4x.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2846])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk9/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][4] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk4/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#658])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk4/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk4/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2346])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk9/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#7742]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-rkl-5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +10 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-6/igt@gem_exec_re...@basic-wc-read-noreloc.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_mmap_wc@set-cache-level:
- {shard-rkl}:[SKIP][20] ([i915#1850]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-3/igt@gem_mmap...@set-cache-level.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/shard-rkl-6/igt@gem_mmap...@set-cache-level.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
-
[Intel-gfx] ✓ Fi.CI.BAT: success for Allow error capture without a request & fix locking issues (rev3)
== Series Details ==
Series: Allow error capture without a request & fix locking issues (rev3)
URL : https://patchwork.freedesktop.org/series/113078/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113078v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/index.html
Participating hosts (37 -> 39)
--
Additional (2): fi-kbl-soraka fi-bsw-kefka
Known issues
Here are the changes found in Patchwork_113078v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#7156])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#5334] / [i915#7872])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][7] ([fdo#109271]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][8] ([fdo#109271]) +26 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][11] ([i915#7911]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][13] ([i915#7699]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][15] ([i915#6367]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][17] ([i915#2346]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][19] ([fdo#103375]) -> [INCOMPLETE][20]
([i915#4817])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113078v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl/selftests: Flush all tiles on test exit
== Series Details ==
Series: drm/i915/mtl/selftests: Flush all tiles on test exit
URL : https://patchwork.freedesktop.org/series/113312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113312v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/index.html
Participating hosts (12 -> 10)
--
Missing(2): pig-skl-6260u pig-kbl-iris
Known issues
Here are the changes found in Patchwork_113312v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-glk: NOTRUN -> [SKIP][1] ([fdo#109271]) +42 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk5/igt@feature_discov...@display-4x.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][2] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk5/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk5/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk5/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2346])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][10] ([i915#7742]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html
* igt@drm_read@short-buffer-nonblock:
- {shard-rkl}:[SKIP][12] ([i915#4098]) -> [PASS][13] +2 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-5/igt@drm_r...@short-buffer-nonblock.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-rkl-6/igt@drm_r...@short-buffer-nonblock.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][14] ([i915#658]) -> [PASS][15] +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-3/igt@feature_discov...@psr1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][16] ([i915#6252]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-rkl-1/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][18] ([i915#6247]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][20] ([i915#2846]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-2/igt@gem_exec_f...@basic-deadline.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/shard-rkl-5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-tglu}: [FAIL][22] ([i915#2842]) -> [PASS][23]
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow error capture without a request & fix locking issues (rev3)
== Series Details == Series: Allow error capture without a request & fix locking issues (rev3) URL : https://patchwork.freedesktop.org/series/113078/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/xehp: GAM registers don't need to be re-applied on engine resets
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/xehp: GAM registers don't need
to be re-applied on engine resets
URL : https://patchwork.freedesktop.org/series/113370/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113370v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/index.html
Participating hosts (37 -> 38)
--
Additional (2): fi-kbl-soraka fi-bsw-kefka
Missing(1): fi-pnv-d510
Known issues
Here are the changes found in Patchwork_113370v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#7156])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#5334] / [i915#7872])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-kbl-8809g: [PASS][6] -> [INCOMPLETE][7] ([i915#4817])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-kbl-8809g/igt@i915_susp...@basic-s3-without-i915.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-8809g/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271]) +15 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][9] ([fdo#109271]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-lvds-1:
- fi-ctg-p8600: [PASS][10] -> [FAIL][11] ([fdo#103375])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-lvds-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-lvds-1.html
* igt@kms_psr@primary_page_flip:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][12] ([i915#1982])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-kbl-soraka/igt@kms_psr@primary_page_flip.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][13] ([fdo#109271]) +26 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][16] ([i915#7911]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][18] ([i915#7699]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113370v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][20] ([i915#2346]) -> [PASS][21]
[20]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Pass drm_i915_private as param to i915 funcs (rev3)
== Series Details ==
Series: drm/i915/display: Pass drm_i915_private as param to i915 funcs (rev3)
URL : https://patchwork.freedesktop.org/series/113083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113083v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/index.html
Participating hosts (12 -> 11)
--
Additional (1): shard-rkl0
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113083v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ccs@block-multicopy-compressed:
- {shard-rkl}:[SKIP][1] ([i915#5325]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-rkl-6/igt@gem_...@block-multicopy-compressed.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-rkl-5/igt@gem_...@block-multicopy-compressed.html
Known issues
Here are the changes found in Patchwork_113083v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271]) +42 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk4/igt@feature_discov...@display-4x.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_12638/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][6] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk4/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk4/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk4/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2346])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@2x-plain-flip-ts-check@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2122])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk1/igt@kms_flip@2x-plain-flip-ts-ch...@bc-hdmi-a1-hdmi-a2.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk5/igt@kms_flip@2x-plain-flip-ts-ch...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1:
- shard-glk: [PASS][16] -> [FAIL][17] ([i915#79])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html
* igt@perf@stress-open-close:
- shard-glk: [PASS][18] -> [INCOMPLETE][19] ([i915#5213])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/shard-glk6/igt@p...@stress-open-close.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/shard-glk5/igt@p...@stress-open-close.html
* igt@runner@aborted:
- shard-glk: NOTRUN -> [FAIL][20]
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915/xehp: GAM registers don't need to be re-applied on engine resets
== Series Details == Series: series starting with [v2,1/3] drm/i915/xehp: GAM registers don't need to be re-applied on engine resets URL : https://patchwork.freedesktop.org/series/113370/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Add selftests for TLB invalidation (rev3)
== Series Details ==
Series: drm/i915/gt: Add selftests for TLB invalidation (rev3)
URL : https://patchwork.freedesktop.org/series/112894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_112894v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/index.html
Participating hosts (37 -> 38)
--
Additional (2): fi-kbl-soraka fi-bsw-kefka
Missing(1): fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112894v3:
### IGT changes ###
Possible regressions
* {igt@i915_selftest@live@gt_tlb} (NEW):
- {bat-dg2-11}: NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/bat-dg2-11/igt@i915_selftest@live@gt_tlb.html
- fi-bsw-nick:NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-bsw-nick/igt@i915_selftest@live@gt_tlb.html
- fi-bsw-kefka: NOTRUN -> [DMESG-FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-bsw-kefka/igt@i915_selftest@live@gt_tlb.html
- {bat-atsm-1}: NOTRUN -> [DMESG-FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/bat-atsm-1/igt@i915_selftest@live@gt_tlb.html
- {bat-dg2-9}:NOTRUN -> [DMESG-FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/bat-dg2-9/igt@i915_selftest@live@gt_tlb.html
- {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/bat-dg2-8/igt@i915_selftest@live@gt_tlb.html
- fi-bsw-n3050: NOTRUN -> [DMESG-FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-bsw-n3050/igt@i915_selftest@live@gt_tlb.html
- fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_tlb.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-edp-1:
- {bat-adlp-6}: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-6/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-edp-1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/bat-adlp-6/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-edp-1.html
New tests
-
New tests have been introduced between CI_DRM_12640 and Patchwork_112894v3:
### New IGT tests (1) ###
* igt@i915_selftest@live@gt_tlb:
- Statuses : 6 dmesg-fail(s) 2 incomplete(s) 30 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_112894v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][13] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][14] ([i915#7156])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][15] -> [DMESG-FAIL][16] ([i915#5334])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][17] ([i915#1886])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][18] ([fdo#109271]) +15 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][19] ([i915#7828])
[19]:
[Intel-gfx] ✓ Fi.CI.BAT: success for fix DRM_USE_DYNAMIC_DEBUG regression
== Series Details ==
Series: fix DRM_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/113363/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113363v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/index.html
Participating hosts (37 -> 37)
--
Additional (1): fi-bsw-kefka
Missing(1): fi-rkl-11600
Known issues
Here are the changes found in Patchwork_113363v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][2] ([fdo#109271]) +26 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][5] ([i915#7911]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][7] ([i915#7699]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][9] ([i915#2346]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113363v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.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#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
Build changes
-
* Linux: CI_DRM_12640 -> Patchwork_113363v1
CI-20190529: 20190529
CI_DRM_12640: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113363v1: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
c22c4369f162 jump_label: RFC / temporary for CI - tolerate toggled state
0cc6565a85d2 test-dyndbg: tune sub-module behavior
b8c945421dab test-dyndbg: disable WIP dyndbg-trace params
36b4db92e876 test-dyndbg: rename DD_SYS_WRAP to DYNDBG_CLASSMAP_PARAM
c7e6b41aaa05 test-dyndbg: build test_dynamic_debug_submod
dd1cc200239f drm_print: fix stale macro-name in comment
5776c51534ed dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements
30bf62590141 dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args
9936163af8e9 dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
4084facfa255 dyndbg-API: split DECLARE_(DYNDBG_CLASSMAP) to $1(_DEFINE|_USE)
2ef4fff96f42 dyndbg: constify ddebug_apply_class_bitmap args
8a019aeb5649 dyndbg: tighten ddebug_class_name() 1st arg
9ce5d2edb055 dyndbg: reduce verbose/debug clutter
8756aa4479ed dyndbg: drop NUM_TYPE_ARRAY
63724ad24516 dyndbg: split param_set_dyndbg_classes to inner/outer fns
4f6279d5a6ca dyndbg: make ddebug_apply_class_bitmap more selective
a731fe9c137e dyndbg: replace classmap list with a vector
73fc8e6873fc test-dyndbg: show that DEBUG enables prdbgs at compiletime
c0ed6ccec06c test-dyndbg: fixup CLASSMAP usage
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fix DRM_USE_DYNAMIC_DEBUG regression
== Series Details == Series: fix DRM_USE_DYNAMIC_DEBUG regression URL : https://patchwork.freedesktop.org/series/113363/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Error/underrun interrupt fixes
== Series Details ==
Series: drm/i915: Error/underrun interrupt fixes
URL : https://patchwork.freedesktop.org/series/113353/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113353v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/index.html
Participating hosts (37 -> 36)
--
Missing(1): fi-rkl-11600
Known issues
Here are the changes found in Patchwork_113353v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/fi-hsw-4770/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][3] ([i915#7229]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][7] ([i915#7911]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][9] ([i915#7699]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][11] ([i915#2346]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.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#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
Build changes
-
* Linux: CI_DRM_12640 -> Patchwork_113353v1
CI-20190529: 20190529
CI_DRM_12640: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113353v1: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
2f1752ce21e5 drm/i915: Mask page table errors on gen2/3 with FBC
9cc4667e1b16 drm/i915: Extract {i9xx, i965)_error_mask()
7c1aade88d3e drm/i915: Dump PGTBL_ER on gen2/3/4 error interrupt
3667dec44110 drm/i915: Undo rmw damage to gen3 error interrupt handler
c74466c4b5e7 drm/i915: Mark FIFO underrun disabled earlier
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113353v1/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/fb-helper: Various cleanups (rev3)
== Series Details == Series: drm/fb-helper: Various cleanups (rev3) URL : https://patchwork.freedesktop.org/series/113220/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113220/revisions/3/mbox/ not applied Applying: drm/client: Test for connectors before sending hotplug event Applying: drm/client: Add hotplug_failed flag Applying: drm/fb-helper: Introduce drm_fb_helper_unprepare() Applying: drm/fbdev-generic: Initialize fb-helper structure in generic setup Applying: drm/fb-helper: Remove preferred_bpp parameter from fbdev internals Applying: drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function Applying: drm/fbdev-generic: Minimize hotplug error handling Applying: drm/fbdev-generic: Minimize client unregistering Applying: drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy() Applying: drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info' error: sha1 information is lacking or useless (drivers/gpu/drm/drm_fbdev_generic.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0010 drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info' When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✓ Fi.CI.BAT: success for Add _PICK_EVEN_2RANGES (rev3)
== Series Details ==
Series: Add _PICK_EVEN_2RANGES (rev3)
URL : https://patchwork.freedesktop.org/series/113177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113177v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/index.html
Participating hosts (37 -> 37)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113177v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@load:
- fi-ctg-p8600: [PASS][1] -> [DMESG-WARN][2] ([i915#6020])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-ctg-p8600/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-ctg-p8600/igt@i915_module_l...@load.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-kbl-8809g: [PASS][3] -> [INCOMPLETE][4] ([i915#4817])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-kbl-8809g/igt@i915_susp...@basic-s3-without-i915.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-kbl-8809g/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-ivb-3770:NOTRUN -> [SKIP][6] ([fdo#109271])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-ivb-3770/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][9] ([i915#7911]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][11] ([i915#7699]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][13] ([i915#2346]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][15] ([fdo#103375]) -> [INCOMPLETE][16]
([i915#4817])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#6020]: https://gitlab.freedesktop.org/drm/intel/issues/6020
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
Build changes
-
* Linux: CI_DRM_12640 -> Patchwork_113177v3
CI-20190529: 20190529
CI_DRM_12640: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113177v3: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
22dae415f850 drm/i915: Convert
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add _PICK_EVEN_2RANGES (rev3)
== Series Details == Series: Add _PICK_EVEN_2RANGES (rev3) URL : https://patchwork.freedesktop.org/series/113177/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/ttm: revert "stop allocating a dummy resource for pipelined gutting"
== Series Details ==
Series: series starting with [1/2] drm/ttm: revert "stop allocating a dummy
resource for pipelined gutting"
URL : https://patchwork.freedesktop.org/series/113345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113345v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/index.html
Participating hosts (37 -> 38)
--
Additional (1): fi-bsw-kefka
Known issues
Here are the changes found in Patchwork_113345v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2:
- bat-dg1-6: [PASS][2] -> [FAIL][3] ([fdo#103375]) +3 similar
issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg1-6/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/bat-dg1-6/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][4] ([fdo#109271]) +26 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][5] ([i915#7229]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][9] ([i915#7911]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][11] ([i915#7699]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][13] ([i915#6367]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][15] ([i915#2346]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][17] ([fdo#103375]) -> [INCOMPLETE][18]
([i915#4817])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113345v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7699]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/ttm: revert "stop allocating a dummy resource for pipelined gutting"
== Series Details == Series: series starting with [1/2] drm/ttm: revert "stop allocating a dummy resource for pipelined gutting" URL : https://patchwork.freedesktop.org/series/113345/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
[Intel-gfx] [PATCH v5 4/8] drm/i915: Allow error capture without a request
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.
In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.
So update the error capture code to always record engine information
if a context is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.
v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null
pointer.
v3: Tidy up request locking code flow (Tvrtko)
v4: Pull in improved info message from next patch and fix up potential
leak of GuC register state (Daniele)
Signed-off-by: John Harrison
Reviewed-by: Umesh Nerlige Ramappa (v2)
Reviewed-by: Daniele Ceraolo Spurio
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 74 ++-
1 file changed, 50 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b20bd6365615b..225f1b11a6b93 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct
intel_engine_coredump *ee)
}
static bool record_context(struct i915_gem_context_coredump *e,
- const struct i915_request *rq)
+ struct intel_context *ce)
{
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
rcu_read_lock();
- ctx = rcu_dereference(rq->context->gem_context);
+ ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
- e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
- e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+ e->total_runtime = intel_context_get_total_runtime_ns(ce);
+ e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
simulated = i915_gem_context_no_error_capture(ctx);
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs
*engine, gfp_t gfp, u32 dump_
return ee;
}
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+ struct intel_context *ce,
+ gfp_t gfp)
+{
+ struct intel_engine_capture_vma *vma = NULL;
+
+ ee->simulated |= record_context(>context, ce);
+ if (ee->simulated)
+ return NULL;
+
+ /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+ vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+ vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+ return vma;
+}
+
struct intel_engine_capture_vma *
intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
struct i915_request *rq,
gfp_t gfp)
{
- struct intel_engine_capture_vma *vma = NULL;
+ struct intel_engine_capture_vma *vma;
- ee->simulated |= record_context(>context, rq);
- if (ee->simulated)
+ vma = engine_coredump_add_context(ee, rq->context, gfp);
+ if (!vma)
return NULL;
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct
intel_engine_coredump *ee,
*/
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
- vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
- vma = capture_vma(vma, rq->context->state, "HW context", gfp);
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1604,25 +1624,31 @@ capture_engine(struct intel_engine_cs *engine,
return NULL;
intel_engine_get_hung_entity(engine, , );
- if (!rq || !i915_request_started(rq))
- goto no_request_capture;
+ if (rq && !i915_request_started(rq)) {
+ drm_info(>gt->i915->drm, "Got hung context on %s with
active request
[Intel-gfx] [PATCH v5 6/8] drm/i915/guc: Look for a guilty context when an engine reset fails
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC intentionally dies on such a situation,
it is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.
v2: Change comment to be less alarming (Tvrtko)
Signed-off-by: John Harrison
Acked-by: Tvrtko Ursulin
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a2b263e5fd667..7adc35bd4435a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4755,11 +4755,24 @@ static void reset_fail_worker_func(struct work_struct
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(>submission_state.lock, flags);
- if (likely(reset_fail_mask))
+ if (likely(reset_fail_mask)) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* GuC is toast at this point - it dead loops after sending the
failed
+* reset notification. So need to manually determine the guilty
context.
+* Note that it should be reliable to do this here because the
GuC is
+* toast and will not be scheduling behind the KMD's back.
+*/
+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
+ intel_guc_find_hung_context(engine);
+
intel_gt_handle_error(gt, reset_fail_mask,
I915_ERROR_CAPTURE,
- "GuC failed to reset engine mask=0x%x\n",
+ "GuC failed to reset engine mask=0x%x",
reset_fail_mask);
+ }
}
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
--
2.39.1
[Intel-gfx] [PATCH v5 2/8] drm/i915: Fix request locking during error capture & debugfs dump
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count but within the
spinlock not outside it.
The only other caller of the context based search is the code for
dumping engine state to debugfs. That code wasn't previously getting
an explicit reference at all as it does everything while holding the
execlist specific spinlock. So, that needs updaing as well as that
spinlock doesn't help when using GuC submission. Rather than trying to
conditionally get/put depending on submission model, just change it to
always do the get/put.
v2: Explicitly document adding an extra blank line in some dense code
(Andy Shevchenko). Fix multiple potential null pointer derefs in case
of no request found (some spotted by Tvrtko, but there was more!).
Also fix a leaked request in case of !started and another in
__guc_reset_context now that intel_context_find_active_request is
actually reference counting the returned request.
v3: Add a _get suffix to intel_context_find_active_request now that it
grabs a reference (Daniele).
v4: Split the intel_guc_find_hung_context change to a separate patch
and rename intel_context_find_active_request_get to
intel_context_get_active_request (Tvrtko).
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset
with GuC")
Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context reset")
Cc: Matthew Brost
Cc: John Harrison
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Andrzej Hajda
Cc: Matthew Auld
Cc: Matt Roper
Cc: Umesh Nerlige Ramappa
Cc: Michael Cheng
Cc: Lucas De Marchi
Cc: Tejas Upadhyay
Cc: Andy Shevchenko
Cc: Aravind Iddamsetty
Cc: Alan Previn
Cc: Bruce Chang
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +++-
drivers/gpu/drm/i915/gt/intel_context.h | 3 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 13 ++---
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e94365b08f1ef..2aa63ec521b89 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -528,7 +528,7 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
-struct i915_request *intel_context_find_active_request(struct intel_context
*ce)
+struct i915_request *intel_context_get_active_request(struct intel_context *ce)
{
struct intel_context *parent = intel_context_to_parent(ce);
struct i915_request *rq, *active = NULL;
@@ -552,6 +552,8 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
active = rq;
}
+ if (active)
+ active = i915_request_get_rcu(active);
spin_unlock_irqrestore(>guc_state.lock, flags);
return active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index fb62b7b8cbcda..0a8d553da3f43 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -268,8 +268,7 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce);
-struct i915_request *
-intel_context_find_active_request(struct intel_context *ce);
+struct i915_request *intel_context_get_active_request(struct intel_context
*ce);
static inline bool intel_context_is_barrier(const struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 922f1bb22dc68..a86bdbee7a6be 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2237,9 +2237,11 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct d
if (guc) {
ce = intel_engine_get_hung_context(engine);
if (ce)
- hung_rq = intel_context_find_active_request(ce);
+ hung_rq = intel_context_get_active_request(ce);
} else {
hung_rq = intel_engine_execlist_find_hung_request(engine);
+ if (hung_rq)
+ hung_rq = i915_request_get_rcu(hung_rq);
}
if (hung_rq)
@@ -2250,6 +2252,8 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct
[Intel-gfx] [PATCH v5 7/8] drm/i915/guc: Add a debug print on GuC triggered reset
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 7adc35bd4435a..2e6ab0bb5c2b6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4666,6 +4666,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
+ drm_dbg(_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting =
%d, banned = %d\n",
+ ce->guc_id.id, test_bit(CONTEXT_EXITING, >flags),
+ test_bit(CONTEXT_BANNED, >flags));
+
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
--
2.39.1
[Intel-gfx] [PATCH v5 5/8] drm/i915: Allow error capture of a pending request
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that this might be better than nothing.
v2: Reword 'not started' warning message (Tvrtko)
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 225f1b11a6b93..904f21e1380cd 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1624,12 +1624,9 @@ capture_engine(struct intel_engine_cs *engine,
return NULL;
intel_engine_get_hung_entity(engine, , );
- if (rq && !i915_request_started(rq)) {
+ if (rq && !i915_request_started(rq))
drm_info(>gt->i915->drm, "Got hung context on %s with
active request %lld:%lld [0x%04X] not yet started\n",
engine->name, rq->fence.context, rq->fence.seqno,
ce->guc_id.id);
- i915_request_put(rq);
- rq = NULL;
- }
if (rq) {
capture = intel_engine_coredump_add_request(ee, rq,
ATOMIC_MAYFAIL);
--
2.39.1
[Intel-gfx] [PATCH v5 3/8] drm/i915: Fix up locking around dumping requests lists
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span of the execlist state lock to only the execlist
specific code paths. In order to do that, also move the report of hold
count (which is an execlist only concept) from the top level dump
function to the lower level execlist specific function. Also, move the
execlist specific code into the execlist source file.
v2: Rename some functions and move to more appropriate files (Daniele).
v3: Rename new execlist dump function (Daniele)
Signed-off-by: John Harrison
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset
with GuC")
Cc: John Harrison
Cc: Matthew Brost
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Umesh Nerlige Ramappa
Cc: Michael Cheng
Cc: Lucas De Marchi
Cc: Bruce Chang
Cc: Alan Previn
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_engine.h| 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 74 +--
.../drm/i915/gt/intel_execlists_submission.c | 27 +++
.../drm/i915/gt/intel_execlists_submission.h | 4 +
drivers/gpu/drm/i915/i915_gpu_error.c | 26 +--
5 files changed, 73 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e24af5efee9c..b58c30ac8ef02 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -250,8 +250,8 @@ void intel_engine_dump_active_requests(struct list_head
*requests,
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now);
-struct i915_request *
-intel_engine_execlist_find_hung_request(struct intel_engine_cs *engine);
+void intel_engine_get_hung_entity(struct intel_engine_cs *engine,
+ struct intel_context **ce, struct
i915_request **rq);
u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
struct intel_context *
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index a86bdbee7a6be..9f703f255d721 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2114,17 +2114,6 @@ static void print_request_ring(struct drm_printer *m,
struct i915_request *rq)
}
}
-static unsigned long list_count(struct list_head *list)
-{
- struct list_head *pos;
- unsigned long count = 0;
-
- list_for_each(pos, list)
- count++;
-
- return count;
-}
-
static unsigned long read_ul(void *p, size_t x)
{
return *(unsigned long *)(p + x);
@@ -2216,11 +2205,11 @@ void intel_engine_dump_active_requests(struct list_head
*requests,
}
}
-static void engine_dump_active_requests(struct intel_engine_cs *engine, struct
drm_printer *m)
+static void engine_dump_active_requests(struct intel_engine_cs *engine,
+ struct drm_printer *m)
{
+ struct intel_context *hung_ce = NULL;
struct i915_request *hung_rq = NULL;
- struct intel_context *ce;
- bool guc;
/*
* No need for an engine->irq_seqno_barrier() before the seqno reads.
@@ -2229,29 +2218,20 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct d
* But the intention here is just to report an instantaneous snapshot
* so that's fine.
*/
- lockdep_assert_held(>sched_engine->lock);
+ intel_engine_get_hung_entity(engine, _ce, _rq);
drm_printf(m, "\tRequests:\n");
- guc = intel_uc_uses_guc_submission(>gt->uc);
- if (guc) {
- ce = intel_engine_get_hung_context(engine);
- if (ce)
- hung_rq = intel_context_get_active_request(ce);
- } else {
- hung_rq = intel_engine_execlist_find_hung_request(engine);
- if (hung_rq)
- hung_rq = i915_request_get_rcu(hung_rq);
- }
-
if (hung_rq)
engine_dump_request(hung_rq, m, "\t\thung");
+ else if (hung_ce)
+ drm_printf(m, "\t\tGot hung ce but no hung rq!\n");
- if (guc)
+ if (intel_uc_uses_guc_submission(>gt->uc))
intel_guc_dump_active_requests(engine, hung_rq, m);
else
-
intel_engine_dump_active_requests(>sched_engine->requests,
- hung_rq, m);
+ intel_execlists_dump_active_requests(engine, hung_rq, m);
+
if (hung_rq)
i915_request_put(hung_rq);
}
@@ -2263,7 +2243,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
[Intel-gfx] [PATCH v5 8/8] drm/i915/guc: Rename GuC register state capture node to be more obvious
From: John Harrison
The GuC specific register state entry in the error capture object was
just called 'capture'. Although the companion 'node' entry was called
'guc_capture_node'. Rename the base entry to be 'guc_capture' instead
so that it is a) more consistent and b) more obvious what it is.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 8
drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 1c1b85073b4bd..fc3b994626a4f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1506,7 +1506,7 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *ebuf,
if (!ebuf || !ee)
return -EINVAL;
- cap = ee->capture;
+ cap = ee->guc_capture;
if (!cap || !ee->engine)
return -ENODEV;
@@ -1576,8 +1576,8 @@ void intel_guc_capture_free_node(struct
intel_engine_coredump *ee)
if (!ee || !ee->guc_capture_node)
return;
- guc_capture_add_node_to_cachelist(ee->capture, ee->guc_capture_node);
- ee->capture = NULL;
+ guc_capture_add_node_to_cachelist(ee->guc_capture,
ee->guc_capture_node);
+ ee->guc_capture = NULL;
ee->guc_capture_node = NULL;
}
@@ -1611,7 +1611,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
(ce->lrc.lrca & CTX_GTT_ADDRESS_MASK)) {
list_del(>link);
ee->guc_capture_node = n;
- ee->capture = guc->capture;
+ ee->guc_capture = guc->capture;
return;
}
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index efc75cc2ffdb9..56027ffbce51f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -94,7 +94,7 @@ struct intel_engine_coredump {
struct intel_instdone instdone;
/* GuC matched capture-lists info */
- struct intel_guc_state_capture *capture;
+ struct intel_guc_state_capture *guc_capture;
struct __guc_capture_parsed_output *guc_capture_node;
struct i915_gem_context_coredump {
--
2.39.1
[Intel-gfx] [PATCH v5 1/8] drm/i915/guc: Fix locking when searching for a hung request
From: John Harrison
intel_guc_find_hung_context() was not acquiring the correct spinlock
before searching the request list. So fix that up. While at it, add
some extra whitespace padding for readability.
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset
with GuC")
Cc: John Harrison
Cc: Matthew Brost
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Umesh Nerlige Ramappa
Cc: Michael Cheng
Cc: Lucas De Marchi
Cc: Tejas Upadhyay
Cc: Chris Wilson
Cc: Bruce Chang
Cc: Alan Previn
Cc: Matthew Auld
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..3b34a82d692be 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4820,6 +4820,8 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
+ bool found;
+
if (!kref_get_unless_zero(>ref))
continue;
@@ -4836,10 +4838,18 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
goto next;
}
+ found = false;
+ spin_lock(>guc_state.lock);
list_for_each_entry(rq, >guc_state.requests, sched.link) {
if (i915_test_request_state(rq) != I915_REQUEST_ACTIVE)
continue;
+ found = true;
+ break;
+ }
+ spin_unlock(>guc_state.lock);
+
+ if (found) {
intel_engine_set_hung_context(engine, ce);
/* Can only cope with one hang at a time... */
@@ -4847,6 +4857,7 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
xa_lock(>context_lookup);
goto done;
}
+
next:
intel_context_put(ce);
xa_lock(>context_lookup);
--
2.39.1
[Intel-gfx] [PATCH v5 0/8] Allow error capture without a request & fix locking issues
From: John Harrison It is technically possible to get a hung context without a valid request. In such a situation, try to provide as much information in the error capture as possible rather than just aborting and capturing nothing. Similarly, in the case of an engine reset failure the GuC is not able to report the guilty context. So try a manual search instead of reporting nothing. While doing all this, it was noticed that the locking was broken in a number of places when searching for hung requests and dumping request info. So fix all that up as well. v2: Tidy up code flow in error capture. Reword some comments/messages. (review feedback from Tvrtko) Also fix up request locking issues from earlier changes noticed during code review of this change. v3: Fix some potential null pointer derefs and a reference leak. Add new patch to refactor the duplicated hung request search code into a common backend agnostic wrapper function and use the correct spinlocks for the correct lists. Also tweak some of the patch descriptions for better accuracy. v4: Shuffle some code around to more appropriate source files. Fix potential leak of GuC capture object after code flow re-org and pull improved info message earlier (Daniele). Also rename the GuC capture object to be more consistent. v5: Split one self contained locking fix out into a separate patch and rename a function to be shorter (Tvrtko). Signed-off-by: John Harrison John Harrison (8): drm/i915/guc: Fix locking when searching for a hung request drm/i915: Fix request locking during error capture & debugfs dump drm/i915: Fix up locking around dumping requests lists drm/i915: Allow error capture without a request drm/i915: Allow error capture of a pending request drm/i915/guc: Look for a guilty context when an engine reset fails drm/i915/guc: Add a debug print on GuC triggered reset drm/i915/guc: Rename GuC register state capture node to be more obvious drivers/gpu/drm/i915/gt/intel_context.c | 4 +- drivers/gpu/drm/i915/gt/intel_context.h | 3 +- drivers/gpu/drm/i915/gt/intel_engine.h| 4 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 74 --- .../drm/i915/gt/intel_execlists_submission.c | 27 ++ .../drm/i915/gt/intel_execlists_submission.h | 4 + .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 8 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 35 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 92 ++- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 10 files changed, 160 insertions(+), 93 deletions(-) -- 2.39.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/4] drm/amdgpu: Use cursor start instead of ttm resource start
== Series Details ==
Series: series starting with [v4,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113341/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113341v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113341v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113341v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/index.html
Participating hosts (37 -> 36)
--
Missing(1): fi-rkl-guc
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113341v1:
### IGT changes ###
Possible regressions
* igt@gem_exec_store@basic:
- fi-rkl-11600: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-rkl-11600/igt@gem_exec_st...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/fi-rkl-11600/igt@gem_exec_st...@basic.html
Known issues
Here are the changes found in Patchwork_113341v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-rkl-11600: NOTRUN -> [FAIL][4] ([i915#4312])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/fi-rkl-11600/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][5] ([i915#7229]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][9] ([i915#7911]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][11] ([i915#7699]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
*
igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [FAIL][13] ([i915#2346]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113341v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions-varying-size.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#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#4137]: https://gitlab.freedesktop.org/drm/intel/issues/4137
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
Build changes
-
* Linux: CI_DRM_12640 -> Patchwork_113341v1
CI-20190529: 20190529
CI_DRM_12640: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113341v1: cc7783f223ac644092bb8788f0750fc5c68aa00e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/4] drm/amdgpu: Use cursor start instead of ttm resource start
== Series Details ==
Series: series starting with [v3,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113336/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113336v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113336v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113336v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/index.html
Participating hosts (37 -> 38)
--
Additional (2): fi-kbl-soraka fi-bsw-kefka
Missing(1): bat-rpls-2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113336v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_heartbeat:
- fi-rkl-11600: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-rkl-11600/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-rkl-11600/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_113336v1 that come from known issues:
### IGT changes ###
Issues hit
* 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_113336v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][5] ([i915#7156])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +15 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][8] ([fdo#109271]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][9] ([fdo#109271]) +26 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@fbdev@write:
- fi-blb-e6850: [SKIP][10] ([fdo#109271]) -> [PASS][11] +4 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-blb-e6850/igt@fb...@write.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-blb-e6850/igt@fb...@write.html
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][12] ([i915#7229]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-9}: [DMESG-WARN][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/bat-adlp-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][16] ([i915#7911]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][18] ([i915#7699]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12640/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113336v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
*
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/4] drm/amdgpu: Use cursor start instead of ttm resource start
== Series Details == Series: series starting with [v3,1/4] drm/amdgpu: Use cursor start instead of ttm resource start URL : https://patchwork.freedesktop.org/series/113336/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/mtl: Correct implementation of Wa_18018781329
On Wed, Jan 25, 2023 at 03:41:58PM -0800, Matt Roper wrote:
> Workaround Wa_18018781329 has applied to several recent Xe_HP-based
> platforms. However there are some extra gotchas to implementing this
> properly for MTL that we need to take into account:
>
> * Due to the separation of media and render/compute into separate GTs,
>this workaround needs to be implemented on each GT, not just the
>primary GT. Since each class of register only exists on one of the
>two GTs, we should program the appropriate registers on each GT.
>
> * As with past Xe_HP platforms, the registers on the primary GT (Xe_LPG
>IP) are multicast/replicated registers and should be handled with the
>MCR-aware functions. However the registers on the media GT (Xe_LPM+
>IP) are regular singleton registers and should _not_ use MCR
>handling. We need to create separate register definitions for the
>Xe_HP multicast form and the Xe_LPM+ singleton form and use each in
>the appropriate place.
>
> * Starting with MTL, workarounds documented by the hardware teams are
>technically associated with IP versions/steppings rather than
>top-level platforms. That means we should take care to check the
>media IP version rather than the graphics IP version when deciding
>whether the workaround is needed on the Xe_LPM+ media GT (in this
>case the workaround applies to both IPs and the stepping bounds are
>identical, but we should still write the code appropriately to set a
>proper precedent for future workaround implementations).
>
> * It's worth noting that the GSC register and the CCS register are
>defined with the same MMIO offset (0xCF30). Since the CCS is only
>relevant to the primary GT and the GSC is only relevant to the media
>GT there isn't actually a clash here (the media GT automatically adds
>the additional 0x38 GSI offset). However there's currently a
>glitch in the bspec where the CCS register doesn't show up at all and
>the GSC register is listed as existing on both GTs. That's a known
>documentation problem for several registers with shared GSC/CCS
>offsets; rest assured that the CCS register really does still exist.
>
> Cc: Gustavo Sousa
> Signed-off-by: Matt Roper
Forgot to add:
Fixes: 41bb543f5598 ("drm/i915/mtl: Add initial gt workarounds")
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 7 +--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 22 ++---
> drivers/gpu/drm/i915/i915_drv.h | 4
> 3 files changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 2727645864db..310bdde049ab 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1100,8 +1100,11 @@
> #define XEHP_MERT_MOD_CTRL MCR_REG(0xcf28)
> #define RENDER_MOD_CTRL MCR_REG(0xcf2c)
> #define COMP_MOD_CTRLMCR_REG(0xcf30)
> -#define VDBX_MOD_CTRLMCR_REG(0xcf34)
> -#define VEBX_MOD_CTRLMCR_REG(0xcf38)
> +#define XELPMP_GSC_MOD_CTRL _MMIO(0xcf30) /* media GT
> only */
> +#define XEHP_VDBX_MOD_CTRL MCR_REG(0xcf34)
> +#define XELPMP_VDBX_MOD_CTRL _MMIO(0xcf34)
> +#define XEHP_VEBX_MOD_CTRL MCR_REG(0xcf38)
> +#define XELPMP_VEBX_MOD_CTRL _MMIO(0xcf38)
> #define FORCE_MISS_FTLBREG_BIT(3)
>
> #define GEN12_GAMSTLB_CTRL _MMIO(0xcf4c)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 9db60078460a..4c978abf3e2a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1681,8 +1681,8 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> /* Wa_18018781329 */
> wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_1509235366:dg2 */
> wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
> @@ -1700,8 +1700,8 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> /* Wa_18018781329 */
> wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL,
[Intel-gfx] [PATCH v2 3/3] drm/i915/xehp: Annotate a couple more workaround registers as MCR
GAMSTLB_CTRL and GAMCNTRL_CTRL became multicast/replicated registers on
Xe_HP. They should be defined accordingly and use MCR-aware operations.
These registers have only been used for some dg2/xehpsdv workarounds, so
this fix is mostly just for consistency/future-proofing; even lacking
the MCR annotation, workarounds will always be properly applied in a
multicast manner on these platforms.
Cc: Gustavo Sousa
Fixes: 58bc2453ab8a ("drm/i915: Define multicast registers as a new type")
Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 16
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 310bdde049ab..7fa18a3b3957 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1107,12 +1107,12 @@
#define XELPMP_VEBX_MOD_CTRL _MMIO(0xcf38)
#define FORCE_MISS_FTLB REG_BIT(3)
-#define GEN12_GAMSTLB_CTRL _MMIO(0xcf4c)
+#define XEHP_GAMSTLB_CTRL MCR_REG(0xcf4c)
#define CONTROL_BLOCK_CLKGATE_DISREG_BIT(12)
#define EGRESS_BLOCK_CLKGATE_DIS REG_BIT(11)
#define TAG_BLOCK_CLKGATE_DISREG_BIT(7)
-#define GEN12_GAMCNTRL_CTRL_MMIO(0xcf54)
+#define XEHP_GAMCNTRL_CTRL MCR_REG(0xcf54)
#define INVALIDATION_BROADCAST_MODE_DIS REG_BIT(12)
#define GLOBAL_INVALIDATION_MODE REG_BIT(2)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 4c978abf3e2a..3111df350f57 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1564,8 +1564,8 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
/* Wa_14014368820:xehpsdv */
- wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
- INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
+ wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
+ INVALIDATION_BROADCAST_MODE_DIS |
GLOBAL_INVALIDATION_MODE);
}
static void
@@ -1659,10 +1659,10 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, SSMCGCTL9530, RTFUNIT_CLKGATE_DIS);
/* Wa_14010680813:dg2_g10 */
- wa_write_or(wal, GEN12_GAMSTLB_CTRL,
- CONTROL_BLOCK_CLKGATE_DIS |
- EGRESS_BLOCK_CLKGATE_DIS |
- TAG_BLOCK_CLKGATE_DIS);
+ wa_mcr_write_or(wal, XEHP_GAMSTLB_CTRL,
+ CONTROL_BLOCK_CLKGATE_DIS |
+ EGRESS_BLOCK_CLKGATE_DIS |
+ TAG_BLOCK_CLKGATE_DIS);
}
/* Wa_14014830051:dg2 */
@@ -1685,8 +1685,8 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
/* Wa_1509235366:dg2 */
- wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
- INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
+ wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
+ INVALIDATION_BROADCAST_MODE_DIS |
GLOBAL_INVALIDATION_MODE);
}
static void
--
2.39.1
[Intel-gfx] [PATCH v2 1/3] drm/i915/xehp: GAM registers don't need to be re-applied on engine resets
Register reset characteristics (i.e., whether the register maintains or
loses its value on engine reset) is an important factor that determines
which wa_list we want to add workarounds to. We recently found out that
the bspec documentation for the Xe_HP's "GAM" registers in the 0xC800 -
0xCFFF range was misleading; these registers do not actually lose their
value on engine resets as the documentation implied. This means there's
no need to re-apply workarounds touching these registers after a reset,
and the corresponding workarounds should be moved from the 'engine'
lists back to the 'gt' list.
v2:
- Don't add Wa_18018781329 to xehpsdv; the original condition didn't
include that platform. (Gustavo)
- Move the MTL code to the GT function as-is for now; we'll take care
of the additional fixes needed in a follow-up patch.
Cc: Gustavo Sousa
Fixes: edf176f48d87 ("drm/i915/dg2: Move misplaced 'ctx' & 'gt' wa's to engine
wa list")
Fixes: b2006061ae28 ("drm/i915/xehpsdv: Move render/compute engine reset
domains related workarounds")
Fixes: 41bb543f5598 ("drm/i915/mtl: Add initial gt workarounds")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 77 -
1 file changed, 44 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 4efc1a532982..9db60078460a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1559,6 +1559,13 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_14011060649:xehpsdv */
wa_14011060649(gt, wal);
+
+ /* Wa_14012362059:xehpsdv */
+ wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
+
+ /* Wa_14014368820:xehpsdv */
+ wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
+ INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
}
static void
@@ -1599,6 +1606,12 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
DSS_ROUTER_CLKGATE_DIS);
}
+ if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_B0) ||
+ IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) {
+ /* Wa_14012362059:dg2 */
+ wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
+ }
+
if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_B0)) {
/* Wa_14010948348:dg2_g10 */
wa_write_or(wal, UNSLCGCTL9430, MSQDUNIT_CLKGATE_DIS);
@@ -1644,6 +1657,12 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_14011028019:dg2_g10 */
wa_mcr_write_or(wal, SSMCGCTL9530, RTFUNIT_CLKGATE_DIS);
+
+ /* Wa_14010680813:dg2_g10 */
+ wa_write_or(wal, GEN12_GAMSTLB_CTRL,
+ CONTROL_BLOCK_CLKGATE_DIS |
+ EGRESS_BLOCK_CLKGATE_DIS |
+ TAG_BLOCK_CLKGATE_DIS);
}
/* Wa_14014830051:dg2 */
@@ -1658,6 +1677,16 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_14015795083 */
wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+
+ /* Wa_18018781329 */
+ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
+
+ /* Wa_1509235366:dg2 */
+ wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
+ INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
}
static void
@@ -1667,16 +1696,29 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_14015795083 */
wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+
+ /* Wa_18018781329 */
+ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
}
static void
xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
{
- /* Wa_14014830051 */
if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
- IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0))
+ IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
+ /* Wa_14014830051 */
wa_mcr_write_clr(wal, SARB_CHICKEN1, COMP_CKN_IN);
+ /* Wa_18018781329 */
+ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal,
[Intel-gfx] [PATCH v2 2/3] drm/i915/mtl: Correct implementation of Wa_18018781329
Workaround Wa_18018781329 has applied to several recent Xe_HP-based platforms. However there are some extra gotchas to implementing this properly for MTL that we need to take into account: * Due to the separation of media and render/compute into separate GTs, this workaround needs to be implemented on each GT, not just the primary GT. Since each class of register only exists on one of the two GTs, we should program the appropriate registers on each GT. * As with past Xe_HP platforms, the registers on the primary GT (Xe_LPG IP) are multicast/replicated registers and should be handled with the MCR-aware functions. However the registers on the media GT (Xe_LPM+ IP) are regular singleton registers and should _not_ use MCR handling. We need to create separate register definitions for the Xe_HP multicast form and the Xe_LPM+ singleton form and use each in the appropriate place. * Starting with MTL, workarounds documented by the hardware teams are technically associated with IP versions/steppings rather than top-level platforms. That means we should take care to check the media IP version rather than the graphics IP version when deciding whether the workaround is needed on the Xe_LPM+ media GT (in this case the workaround applies to both IPs and the stepping bounds are identical, but we should still write the code appropriately to set a proper precedent for future workaround implementations). * It's worth noting that the GSC register and the CCS register are defined with the same MMIO offset (0xCF30). Since the CCS is only relevant to the primary GT and the GSC is only relevant to the media GT there isn't actually a clash here (the media GT automatically adds the additional 0x38 GSI offset). However there's currently a glitch in the bspec where the CCS register doesn't show up at all and the GSC register is listed as existing on both GTs. That's a known documentation problem for several registers with shared GSC/CCS offsets; rest assured that the CCS register really does still exist. Cc: Gustavo Sousa Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 7 +-- drivers/gpu/drm/i915/gt/intel_workarounds.c | 22 ++--- drivers/gpu/drm/i915/i915_drv.h | 4 3 files changed, 24 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 2727645864db..310bdde049ab 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1100,8 +1100,11 @@ #define XEHP_MERT_MOD_CTRL MCR_REG(0xcf28) #define RENDER_MOD_CTRLMCR_REG(0xcf2c) #define COMP_MOD_CTRL MCR_REG(0xcf30) -#define VDBX_MOD_CTRL MCR_REG(0xcf34) -#define VEBX_MOD_CTRL MCR_REG(0xcf38) +#define XELPMP_GSC_MOD_CTRL_MMIO(0xcf30) /* media GT only */ +#define XEHP_VDBX_MOD_CTRL MCR_REG(0xcf34) +#define XELPMP_VDBX_MOD_CTRL _MMIO(0xcf34) +#define XEHP_VEBX_MOD_CTRL MCR_REG(0xcf38) +#define XELPMP_VEBX_MOD_CTRL _MMIO(0xcf38) #define FORCE_MISS_FTLB REG_BIT(3) #define GEN12_GAMSTLB_CTRL _MMIO(0xcf4c) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 9db60078460a..4c978abf3e2a 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1681,8 +1681,8 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) /* Wa_18018781329 */ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB); wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB); - wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB); - wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB); + wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL, FORCE_MISS_FTLB); + wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB); /* Wa_1509235366:dg2 */ wa_write_or(wal, GEN12_GAMCNTRL_CTRL, @@ -1700,8 +1700,8 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) /* Wa_18018781329 */ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB); wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB); - wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB); - wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB); + wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL, FORCE_MISS_FTLB); + wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB); } static void @@ -1715,8 +1715,6 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) /* Wa_18018781329 */ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dp_mst: Fix MST payload removal during output disabling
== Series Details == Series: drm/i915/dp_mst: Fix MST payload removal during output disabling URL : https://patchwork.freedesktop.org/series/113329/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool LD [M] drivers/gpu/drm/i915/i915.o LD [M] drivers/gpu/drm/i915/kvmgt.o HDRTEST drivers/gpu/drm/i915/display/intel_dp_mst.h In file included from : ./drivers/gpu/drm/i915/display/intel_dp_mst.h:22:18: error: ‘struct intel_crtc’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 22 | struct intel_crtc *crtc); | ^~ ./drivers/gpu/drm/i915/display/intel_dp_mst.h:21:53: error: ‘struct intel_atomic_state’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 21 | int intel_dp_mst_add_topology_state_for_crtc(struct intel_atomic_state *state, | ^~ ./drivers/gpu/drm/i915/display/intel_dp_mst.h:23:39: error: ‘struct intel_atomic_state’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 23 | void intel_dp_mst_verify_state(struct intel_atomic_state *state); | ^~ cc1: all warnings being treated as errors make[5]: *** [drivers/gpu/drm/i915/Makefile:380: drivers/gpu/drm/i915/display/intel_dp_mst.hdrtest] Error 1 make[4]: *** [scripts/Makefile.build:504: drivers/gpu/drm/i915] Error 2 make[3]: *** [scripts/Makefile.build:504: drivers/gpu/drm] Error 2 make[2]: *** [scripts/Makefile.build:504: drivers/gpu] Error 2 make[1]: *** [scripts/Makefile.build:504: drivers] Error 2 make: *** [Makefile:2021: .] Error 2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: switch to drm_edid and enable HF-EEODB support
== Series Details ==
Series: drm/i915: switch to drm_edid and enable HF-EEODB support
URL : https://patchwork.freedesktop.org/series/113327/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12639 -> Patchwork_113327v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/index.html
Participating hosts (39 -> 38)
--
Additional (1): fi-bsw-kefka
Missing(2): fi-kbl-soraka fi-tgl-dsi
Known issues
Here are the changes found in Patchwork_113327v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2] ([i915#6972])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][3] ([fdo#109271]) +26 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#4312])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [DMESG-FAIL][5] ([i915#7699]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][7] ([i915#4983]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/bat-rpls-1/igt@i915_selftest@l...@reset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/bat-rpls-1/igt@i915_selftest@l...@reset.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#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6972]: https://gitlab.freedesktop.org/drm/intel/issues/6972
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7834]: https://gitlab.freedesktop.org/drm/intel/issues/7834
Build changes
-
* Linux: CI_DRM_12639 -> Patchwork_113327v1
CI-20190529: 20190529
CI_DRM_12639: 81c7c4a9c86dac434bc6d8c97fdc440866ca0d65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113327v1: 81c7c4a9c86dac434bc6d8c97fdc440866ca0d65 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
75695bb6a1eb drm/i915/panel: move panel fixed EDID to struct intel_panel
1d2d765aaee7 drm/i915/opregion: convert intel_opregion_get_edid() to struct
drm_edid
99c3dec8cf35 drm/i915/bios: convert intel_bios_init_panel() to drm_edid
bf3e19d682fb drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113327v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/amdgpu: Use cursor start instead of ttm resource start
== Series Details ==
Series: series starting with [v2,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12639 -> Patchwork_113322v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/index.html
Participating hosts (39 -> 39)
--
Additional (1): fi-bsw-kefka
Missing(1): fi-tgl-dsi
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113322v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_fence@basic-await@ccs1:
- {bat-dg2-9}:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/bat-dg2-9/igt@gem_exec_fence@basic-aw...@ccs1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/bat-dg2-9/igt@gem_exec_fence@basic-aw...@ccs1.html
Known issues
Here are the changes found in Patchwork_113322v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-kbl-soraka: [PASS][5] -> [INCOMPLETE][6] ([i915#7913])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][7] ([fdo#109271]) +26 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][8] ([i915#5334] / [i915#7872]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [DMESG-FAIL][10] ([i915#7699]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/bat-rpls-1/igt@i915_selftest@l...@reset.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113322v1/bat-rpls-1/igt@i915_selftest@l...@reset.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#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7834]: https://gitlab.freedesktop.org/drm/intel/issues/7834
[i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
Build changes
-
* Linux: CI_DRM_12639 -> Patchwork_113322v1
CI-20190529: 20190529
CI_DRM_12639: 81c7c4a9c86dac434bc6d8c97fdc440866ca0d65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113322v1: 81c7c4a9c86dac434bc6d8c97fdc440866ca0d65 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
0b8f3de27868 drm/amdgpu: Support allocate of amdgpu_gtt_mgr from pages to bytes
3b8face7f27b drm/amdgpu: Movie the amdgpu_gtt_mgr start and size from pages to
bytes
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: switch to drm_edid and enable HF-EEODB support
== Series Details == Series: drm/i915: switch to drm_edid and enable HF-EEODB support URL : https://patchwork.freedesktop.org/series/113327/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH v2] drm/i915/gt: Add selftests for TLB invalidation
From: Chris Wilson
Check that we invalidate the TLB cache, the updated physical addresses
are immediately visible to the HW, and there is no retention of the old
physical address for concurrent HW access.
Signed-off-by: Chris Wilson
[ahajda: adjust to upstream driver, v2]
Signed-off-by: Andrzej Hajda
---
v2:
- addressed comments (Tvrtko),
- changed pin/sample address calculation,
- removed checks for platforms older than 8,
- use low ints in MI_DO_COMPARE to be more clear,
- continue test if physical addresses have the same uppper 32 bits,
- consolidate two calls to pte_tlbinv into one
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c| 4 +
drivers/gpu/drm/i915/gt/selftest_tlb.c| 398 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
4 files changed, 404 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/selftest_tlb.c
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 2af1ae3831df98..e10507fa71ce63 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -394,6 +394,7 @@
#define MI_LOAD_URB_MEM MI_INSTR(0x2C, 0)
#define MI_STORE_URB_MEMMI_INSTR(0x2D, 0)
#define MI_CONDITIONAL_BATCH_BUFFER_END MI_INSTR(0x36, 0)
+#define MI_DO_COMPARE REG_BIT(21)
#define STATE_BASE_ADDRESS \
((0x3 << 29) | (0x0 << 27) | (0x1 << 24) | (0x1 << 16))
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f0dbfc434e0773..001a7ec5b86182 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1205,3 +1205,7 @@ void intel_gt_invalidate_tlb(struct intel_gt *gt, u32
seqno)
mutex_unlock(>tlb.invalidate_lock);
}
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_tlb.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/selftest_tlb.c
b/drivers/gpu/drm/i915/gt/selftest_tlb.c
new file mode 100644
index 00..e77b817738cbfc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_tlb.c
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "i915_selftest.h"
+
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
+
+#include "gen8_engine_cs.h"
+#include "i915_gem_ww.h"
+#include "intel_engine_regs.h"
+#include "intel_gpu_commands.h"
+#include "intel_context.h"
+#include "intel_gt.h"
+#include "intel_ring.h"
+
+#include "selftests/igt_flush_test.h"
+#include "selftests/i915_random.h"
+
+static void clear_dw(struct i915_vma *vma, u64 addr, u32 val)
+{
+ GEM_BUG_ON(addr < i915_vma_offset(vma));
+ GEM_BUG_ON(addr >= i915_vma_offset(vma) + i915_vma_size(vma));
+ memset32(page_mask_bits(vma->obj->mm.mapping) +
+(addr - i915_vma_offset(vma)), val, 1);
+}
+
+static int
+pte_tlbinv(struct intel_context *ce,
+ struct i915_vma *va,
+ struct i915_vma *vb,
+ u64 align,
+ void (*tlbinv)(struct i915_address_space *vm, u64 addr, u64 length),
+ u64 length,
+ struct rnd_state *prng)
+{
+ struct drm_i915_gem_object *batch;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ u64 addr;
+ int err;
+ u32 *cs;
+
+ batch = i915_gem_object_create_internal(ce->vm->i915, 4096);
+ if (IS_ERR(batch))
+ return PTR_ERR(batch);
+
+ vma = i915_vma_instance(batch, ce->vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ goto out;
+
+ /* Pin va at random but aligned offset after vma */
+ addr = round_up(vma->node.start + vma->node.size, align);
+ /* MI_CONDITIONAL_BATCH_BUFFER_END limits address to 48b */
+ addr = igt_random_offset(prng, addr, min(ce->vm->total, BIT_ULL(48)),
+va->size, align);
+ err = i915_vma_pin(va, 0, 0, addr | PIN_OFFSET_FIXED | PIN_USER);
+ if (err) {
+ pr_err("Cannot pin at %llx+%llx\n", addr, va->size);
+ goto out;
+ }
+ GEM_BUG_ON(i915_vma_offset(va) != addr);
+ vb->node = va->node; /* overwrites the _same_ PTE */
+
+ /*
+* Now choose random dword at the 1st pinned page.
+*
+* SZ_64K pages on dg1 require that the whole PT be marked
+* containing 64KiB entries. So we make sure that vma
+* covers the whole PT, despite being randomly aligned to 64KiB
+* and restrict our sampling to the 2MiB PT within where
+* we know that we will be using 64KiB pages.
+*/
+ if (align == SZ_64K)
+ addr = round_up(addr, SZ_2M) + igt_random_offset(prng, 0,
SZ_2M, 4, 4);
+ else
+ addr +=
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] drm/amdgpu: Use cursor start instead of ttm resource start
== Series Details == Series: series starting with [v2,1/4] drm/amdgpu: Use cursor start instead of ttm resource start URL : https://patchwork.freedesktop.org/series/113322/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v4 1/7] drm/i915: Fix request locking during error capture & debugfs dump
On 1/23/2023 09:51, Tvrtko Ursulin wrote: On 20/01/2023 23:28, john.c.harri...@intel.com wrote: From: John Harrison -struct i915_request *intel_context_find_active_request(struct intel_context *ce) +struct i915_request *intel_context_find_active_request_get(struct intel_context *ce) TBH I don't "dig" this name, it's a bit on the long side and feels out of character. I won't insist it be changed, but if get really has to be included in the name I would be happy with intel_context_get_active_request(). Daniele sided with you on this one. Will use your naming. John.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Split sel fetch plane configuration into arm and noarm
== Series Details ==
Series: drm/i915/psr: Split sel fetch plane configuration into arm and noarm
URL : https://patchwork.freedesktop.org/series/113321/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12639 -> Patchwork_113321v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v1/index.html
Participating hosts (39 -> 38)
--
Missing(1): fi-tgl-dsi
Known issues
Here are the changes found in Patchwork_113321v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: NOTRUN -> [FAIL][1] ([fdo#103375])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#7828])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v1/fi-rkl-11600/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [DMESG-FAIL][3] ([i915#7699]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][5] ([i915#4817]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12639/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
Build changes
-
* Linux: CI_DRM_12639 -> Patchwork_113321v1
CI-20190529: 20190529
CI_DRM_12639: 81c7c4a9c86dac434bc6d8c97fdc440866ca0d65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113321v1: 81c7c4a9c86dac434bc6d8c97fdc440866ca0d65 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
aa86bc3316f9 drm/i915/psr: Split sel fetch plane configuration into arm and
noarm
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v1/index.html
Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: GAM registers don't need to be re-applied on engine resets
On Wed, Jan 25, 2023 at 04:43:29PM -0300, Gustavo Sousa wrote:
> On Tue, Jan 24, 2023 at 05:14:06PM -0800, Matt Roper wrote:
> > Register reset characteristics (i.e., whether the register maintains or
> > loses its value on engine reset) is an important factor that determines
> > which wa_list we want to add workarounds to. We recently found out that
> > the bspec documentation for the Xe_HP's "GAM" registers in the 0xC800 -
> > 0xCFFF range was misleading; these registers do not actually lose their
> > value on engine resets as the documentation implied. This means there's
> > no need to re-apply workarounds touching these registers after a reset,
> > and the corresponding workarounds should be moved from the 'engine'
> > lists back to the 'gt' list.
> >
> > While moving these GAM-related workarounds to the various platforms' GT
> > workaround functions, we should also take care to handle Wa_18018781329
> > properly for MTL's two GTs --- the render/compute setting should be set
> > on the primary GT where those engines reside, and the vd/ve/gsc setting
> > should be set on the media GT. Previously the VD/VE/GSC setting was not
> > being properly applied.
> >
> > Cc: Gustavo Sousa
> > Fixes: edf176f48d87 ("drm/i915/dg2: Move misplaced 'ctx' & 'gt' wa's to
> > engine wa list")
> > Fixes: b2006061ae28 ("drm/i915/xehpsdv: Move render/compute engine reset
> > domains related workarounds")
> > Fixes: 41bb543f5598 ("drm/i915/mtl: Add initial gt workarounds")
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
> > drivers/gpu/drm/i915/i915_drv.h | 4 +
> > 3 files changed, 59 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 2727645864db..4a37d048b512 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1100,6 +1100,7 @@
> > #define XEHP_MERT_MOD_CTRL MCR_REG(0xcf28)
> > #define RENDER_MOD_CTRLMCR_REG(0xcf2c)
> > #define COMP_MOD_CTRL MCR_REG(0xcf30)
> > +#define GSC_MOD_CTRL MCR_REG(0xcf30) /*
> > media GT only */
> > #define VDBX_MOD_CTRL MCR_REG(0xcf34)
> > #define VEBX_MOD_CTRL MCR_REG(0xcf38)
> > #define FORCE_MISS_FTLB REG_BIT(3)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 4efc1a532982..0e7f64bb2860 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1559,6 +1559,19 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt,
> > struct i915_wa_list *wal)
> >
> > /* Wa_14011060649:xehpsdv */
> > wa_14011060649(gt, wal);
> > +
> > + /* Wa_18018781329 */
> > + wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> > + wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> > + wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> > + wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
>
> Maybe worth mentioning in the commit message that Wa_18018781329 is being
> extended to XEHPSDV in this patch? This could also be on its own patch.
Yeah, it's probably better to just drop it from this patch. We could
potentially add it to xehpsdv as a separate patch down the line if
necessary.
>
> > +
> > + /* Wa_14012362059:xehpsdv */
> > + wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> > +
> > + /* Wa_14014368820:xehpsdv */
> > + wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
> > + INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
> > }
> >
> > static void
> > @@ -1599,6 +1612,12 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> > i915_wa_list *wal)
> > DSS_ROUTER_CLKGATE_DIS);
> > }
> >
> > + if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_B0) ||
> > + IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) {
> > + /* Wa_14012362059:dg2 */
> > + wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> > + }
> > +
> > if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_B0)) {
> > /* Wa_14010948348:dg2_g10 */
> > wa_write_or(wal, UNSLCGCTL9430, MSQDUNIT_CLKGATE_DIS);
> > @@ -1644,6 +1663,12 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> > i915_wa_list *wal)
> >
> > /* Wa_14011028019:dg2_g10 */
> > wa_mcr_write_or(wal, SSMCGCTL9530, RTFUNIT_CLKGATE_DIS);
> > +
> > + /* Wa_14010680813:dg2_g10 */
> > + wa_write_or(wal, GEN12_GAMSTLB_CTRL,
> > + CONTROL_BLOCK_CLKGATE_DIS |
> > + EGRESS_BLOCK_CLKGATE_DIS |
> > +
Re: [Intel-gfx] [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> Test for connectors in the client code and remove a similar test
> from the generic fbdev emulation. Do nothing if the test fails.
> Not having connectors indicates a driver bug.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
> ---
> drivers/gpu/drm/drm_client.c| 5 +
> drivers/gpu/drm/drm_fbdev_generic.c | 5 -
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 262ec64d4397..09ac191c202d 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return;
>
> + if (!dev->mode_config.num_connector) {
> + drm_dbg_kms(dev, "No connectors found, will not send hotplug
> events!\n");
> + return;
This deserves a more visible logging - if a driver fails here it would
be good to spot it in the normal kernel log.
drm_info or drm_notice?
The original code had this on the debug level, but when moving the log
level could also be updated.
Sam
> + }
> +
> mutex_lock(>clientlist_mutex);
> list_for_each_entry(client, >clientlist, list) {
> if (!client->funcs || !client->funcs->hotplug)
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 0a4c160e0e58..3d455a2e3fb5 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -389,11 +389,6 @@ static int drm_fbdev_client_hotplug(struct
> drm_client_dev *client)
> if (dev->fb_helper)
> return drm_fb_helper_hotplug_event(dev->fb_helper);
>
> - if (!dev->mode_config.num_connector) {
> - drm_dbg_kms(dev, "No connectors found, will not create
> framebuffer!\n");
> - return 0;
> - }
> -
> drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
>
> ret = drm_fb_helper_init(dev, fb_helper);
> --
> 2.39.0
Re: [Intel-gfx] [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> Initialize the fb-helper structure immediately after its allocation
> in drm_fbdev_generic_setup(). That will make it easier to fill it with
> driver-specific values, such as the preferred BPP.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
> ---
> drivers/gpu/drm/drm_fbdev_generic.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 135d58b8007b..63f66325a8a5 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
> *client)
> if (dev->fb_helper)
> return drm_fb_helper_hotplug_event(dev->fb_helper);
>
> - drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
> -
> ret = drm_fb_helper_init(dev, fb_helper);
> if (ret)
> goto err;
>From the documentation:
The drm_fb_helper_prepare()
helper must be called first to initialize the minimum required to make
hotplug detection work.
...
To finish up the fbdev helper initialization, the
drm_fb_helper_init() function is called.
So this change do not follow the documentation as drm_fb_helper_init()
is now called before drm_fb_helper_prepare()
I did not follow all the code - but my gut feeling is that the
documentation is right.
Sam
> @@ -456,12 +454,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
> fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
> if (!fb_helper)
> return;
> + drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
>
> ret = drm_client_init(dev, _helper->client, "fbdev",
> _fbdev_client_funcs);
> if (ret) {
> - kfree(fb_helper);
> drm_err(dev, "Failed to register client: %d\n", ret);
> - return;
> + goto err_drm_client_init;
> }
>
> /*
> @@ -484,5 +482,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
> drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
>
> drm_client_register(_helper->client);
> +
> + return;
> +
> +err_drm_client_init:
> + drm_fb_helper_unprepare(fb_helper);
> + kfree(fb_helper);
> + return;
> }
> EXPORT_SYMBOL(drm_fbdev_generic_setup);
> --
> 2.39.0
Re: [Intel-gfx] [PATCH v3 02/10] drm/client: Add hotplug_failed flag
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:
> Signal failed hotplugging with a flag in struct drm_client_dev. If set,
> the client helpers will not further try to set up the fbdev display.
>
> This used to be signalled with a combination of cleared pointers in
> struct drm_fb_helper,
I failed to find where we clear the pointers. What do I miss?
(I had assumed we would stop clearing the pointers after this change).
Sam
which prevents us from initializing these pointers
> early after allocation.
>
> The change also harmonizes behavior among DRM clients. Additional DRM
> clients will now handle failed hotplugging like fbdev does.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
> ---
> drivers/gpu/drm/drm_client.c| 5 +
> drivers/gpu/drm/drm_fbdev_generic.c | 4
> include/drm/drm_client.h| 8
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 09ac191c202d..009e7b10455c 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -208,8 +208,13 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> if (!client->funcs || !client->funcs->hotplug)
> continue;
>
> + if (client->hotplug_failed)
> + continue;
> +
> ret = client->funcs->hotplug(client);
> drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
> + if (ret)
> + client->hotplug_failed = true;
> }
> mutex_unlock(>clientlist_mutex);
> }
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 3d455a2e3fb5..135d58b8007b 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -382,10 +382,6 @@ static int drm_fbdev_client_hotplug(struct
> drm_client_dev *client)
> struct drm_device *dev = client->dev;
> int ret;
>
> - /* Setup is not retried if it has failed */
> - if (!fb_helper->dev && fb_helper->funcs)
> - return 0;
> -
> if (dev->fb_helper)
> return drm_fb_helper_hotplug_event(dev->fb_helper);
>
> diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
> index 4fc8018eddda..39482527a775 100644
> --- a/include/drm/drm_client.h
> +++ b/include/drm/drm_client.h
> @@ -106,6 +106,14 @@ struct drm_client_dev {
>* @modesets: CRTC configurations
>*/
> struct drm_mode_set *modesets;
> +
> + /**
> + * @hotplug failed:
> + *
> + * Set by client hotplug helpers if the hotplugging failed
> + * before. It is usually not tried again.
> + */
> + bool hotplug_failed;
> };
>
> int drm_client_init(struct drm_device *dev, struct drm_client_dev *client,
> --
> 2.39.0
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/4] drm/gem: Remove BUG_ON in drm_gem_private_object_init
== Series Details ==
Series: series starting with [v4,1/4] drm/gem: Remove BUG_ON in
drm_gem_private_object_init
URL : https://patchwork.freedesktop.org/series/113318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113318v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/index.html
Participating hosts (38 -> 39)
--
Additional (2): fi-kbl-soraka fi-tgl-dsi
Missing(1): fi-bsw-kefka
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113318v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@module-reload:
- {bat-dg2-11}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-11/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/bat-dg2-11/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_113318v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][3] -> [SKIP][4] ([fdo#109271]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-blb-e6850/igt@fb...@write.html
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][5] -> [FAIL][6] ([i915#7229])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][9] ([i915#7156])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#5334] / [i915#7872])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271]) +15 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-guc: NOTRUN -> [SKIP][13] ([i915#7828])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-rkl-guc/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600: [PASS][14] -> [FAIL][15] ([fdo#103375])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-9}:[FAIL][16] ([fdo#103375]) -> [PASS][17] +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][18] ([i915#4983]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113318v1/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-dp-3:
- {bat-dg2-9}:[FAIL][20] -> [PASS][21]
[20]:
[Intel-gfx] [PATCH v3 19/19] jump_label: RFC / temporary for CI - tolerate toggled state
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected; it makes no allowances for the well-formed
but incorrect "toggled" state. This patch changes panic-on-toggled
into a warning, allowing to reduce the problem to a repeatable script.
note: this patch is arch/x86 only, so might not help CI at all.
submod () {
# set drm.debug analogues
echo MP test_dynamic_debug p_disjoint_bits=${1:-0} p_level_num=${2:-0}
modprobe test_dynamic_debug p_disjoint_bits=${1:-0} p_level_num=${2:-0}
dyndbg=+p
# _submod should pick up kparams
echo MP test_dynamic_debug_submod dyndbg=+pmf
modprobe test_dynamic_debug_submod dyndbg=+pmf
}
unmod () {
rmmod test_dynamic_debug_submod
rmmod test_dynamic_debug
}
note () {
echo NOTE: $* >&2
sleep 0.1
}
submod_probe () {
echo 4 > /sys/module/dynamic_debug/parameters/verbose
unmod
submod $*
note submod prdbgs are supposedly enabled
grep test_dynamic_debug /proc/dynamic_debug/control
cat /sys/module/test_dynamic_debug/parameters/do_prints
note but they dont print here
cat /sys/module/test_dynamic_debug_submod/parameters/do_prints
note if D2_CORE in $1, trigger toggled warning
note echo class D2_CORE -p
echo class D2_CORE -p > /proc/dynamic_debug/control
}
heres the repeatable results
[ 17.023758] virtme-init: triggering udev coldplug
[ 18.285949] virtme-init: waiting for udev to settle
[ 22.550866] i2c_piix4: module verification failed: signature and/or required
key missing - tainting kernel
[ 22.551945] dyndbg: add-module: i2c_piix4 12 sites 0.0
[ 22.552277] dyndbg: 12 debug prints in module i2c_piix4
[ 22.555099] piix4_smbus :00:01.3: SMBus Host Controller at 0x700,
revision 0
[ 22.597344] dyndbg: add-module: serio_raw 2 sites 0.0
[ 22.597633] dyndbg: 2 debug prints in module serio_raw
[ 22.603506] input: PC Speaker as /devices/platform/pcspkr/input/input4
[ 23.556657] dyndbg: add-module: intel_rapl_common 12 sites 0.0
[ 23.557000] dyndbg: 12 debug prints in module intel_rapl_common
[ 23.759499] dyndbg: add-module: intel_rapl_msr 2 sites 0.0
[ 23.759928] dyndbg: 2 debug prints in module intel_rapl_msr
[ 26.081050] virtme-init: udev is done
virtme-init: console is ttyS0
bash-5.2# . test-funcs.rc
:#> submod_probe 1 0
rmmod: ERROR: Module test_dynamic_debug_submod is not currently loaded
rmmod: ERROR: Module test_dynamic_debug is not currently loaded
MP test_dynamic_debug p_disjoint_bits=1 p_level_num=0 dyndbg=+pm
[ 61.712445] dyndbg: add-module: test_dynamic_debug 33 sites 4.0
[ 61.712789] dyndbg: classes[0..]: module:test_dynamic_debug base:22 len:8
ty:3
[ 61.713144] dyndbg: module:test_dynamic_debug attached 4 classes
[ 61.713894] dyndbg: 33 debug prints in module test_dynamic_debug
[ 61.715486] dyndbg: bits:0x1 > *.p_disjoint_bits
[ 61.715732] dyndbg: apply bitmap: 0x1 to: 0x0 for '*'
[ 61.715983] dyndbg: query 0: "class D2_CORE +p" mod:*
[ 61.716253] dyndbg: split into words: "class" "D2_CORE" "+p"
[ 61.716539] dyndbg: op='+' flags=0x1 maskp=0x
[ 61.716794] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=D2_CORE
[ 61.717232] dyndbg: good-class: test_dynamic_debug.D2_CORE
module:test_dynamic_debug nd:33 nc:4 nu:0
[ 61.717690] dyndbg: processed 1 queries, with 1 matches, 0 errs
[ 61.717982] dyndbg: bit_0: 1 matches on class: D2_CORE -> 0x1
[ 61.718283] dyndbg: applied bitmap: 0x1 to: 0x0 for '*'
[ 61.718542] dyndbg: p_disjoint_bits: total matches: 1
[ 61.718799] dyndbg: lvl:0 bits:0x0 > p_level_num
[ 61.719029] dyndbg: p_level_num: total matches: 0
[ 61.719279] dyndbg: module: test_dynamic_debug dyndbg="+pm"
[ 61.719554] dyndbg: query 0: "+pm" mod:test_dynamic_debug
[ 61.719824] dyndbg: split into words: "+pm"
[ 61.720034] dyndbg: op='+' flags=0x3 maskp=0x
[ 61.720299] dyndbg: parsed: func="" file="" module="test_dynamic_debug"
format="" lineno=0-0 class=(null)
[ 61.720786] dyndbg: changed lib/test_dynamic_debug.c:206
[test_dynamic_debug]test_dynamic_debug_exit p => pm
[ 61.721289] dyndbg: changed lib/test_dynamic_debug.c:200
[test_dynamic_debug]test_dynamic_debug_init p => pm
[ 61.721778] dyndbg: changed lib/test_dynamic_debug.c:198
[test_dynamic_debug]test_dynamic_debug_init p => pm
[ 61.722283] dyndbg: changed lib/test_dynamic_debug.c:191
[test_dynamic_debug]do_prints p => pm
[ 61.722711] dyndbg: changed lib/test_dynamic_debug.c:170
[test_dynamic_debug]do_levels p => pm
[ 61.723128] dyndbg: changed lib/test_dynamic_debug.c:150
[test_dynamic_debug]do_cats p => pm
[ 61.723554] dyndbg: processed 1 queries, with 6 matches, 0 errs
[ 61.725233] test_dynamic_debug: test_dd: init start
[ 61.725487] test_dynamic_debug: test_dd: do_prints:
[ 61.725745] test_dynamic_debug: test_dd: doing categories
[ 61.726011] test_dd: LOW msg
[ 61.726176] test_dd: MID msg
[ 61.726328] test_dd: HI msg
[ 61.726470] test_dd:
[Intel-gfx] [PATCH v3 15/19] test-dyndbg: build test_dynamic_debug_submod
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; drm subsystem
modules, which depend upon drm.ko and use the drm.debug API, do not
get enabled when __drm_debug is set by `modprobe drm debug=0x1f`.
With =N, __drm_debug is checked before logging the msg, so the
end-of-modprobe debug=$init affected all later checks. But with =y,
each run-time check is replaced by a static-key that is set at
end-of-modprobe.
This creates a chicken-egg dependency; i915 must be modprobed before
its drm.debugs are enabled, but drm.ko (and __drm_debug=$init) must be
done before modprobe i915, so its callsites arent there yet to be
enabled.
The fix is to split DECLARE_DYNDBG_CLASSMAP to:
DYNDBG_CLASSMAP_DEFINE - invoked in 'parent'
DYNDBG_CLASSMAP_USE - invoked in dependent, to USE the exported definition
To prove the fix w/o involving DRM, we need 2 modules, one dependent
on the other. Add test_dynamic_debug_submod.ko, which _USEs the
classmaps _exported by test_dynamic_debug.ko
To keep code to a minimum, test_dynamic_debug.c ifdefs on
TEST_DYNAMIC_DEBUG_SUBMOD to build either parent or dependent, with
either DYNDBG_CLASSMAP_DEFINE or DYNDBG_CLASSMAP_USE invocations.
So test_dynamic_debug_submod.c is just 2 lines: include the .c after
defining SUBMOD. This also gives the 2 modules identical prdbg
callsites, only differing by enablement/configuration.
Signed-off-by: Jim Cromie
---
lib/Makefile| 3 +-
lib/test_dynamic_debug.c| 52 -
lib/test_dynamic_debug_submod.c | 10 +++
3 files changed, 57 insertions(+), 8 deletions(-)
create mode 100644 lib/test_dynamic_debug_submod.c
diff --git a/lib/Makefile b/lib/Makefile
index 4d9461bfea42..7f7e75f44cd7 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -77,7 +77,7 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o
obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
-obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o
+obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o
test_dynamic_debug_submod.o
obj-$(CONFIG_TEST_PRINTF) += test_printf.o
obj-$(CONFIG_TEST_SCANF) += test_scanf.o
obj-$(CONFIG_TEST_BITMAP) += test_bitmap.o
@@ -98,6 +98,7 @@ obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
obj-$(CONFIG_TEST_REF_TRACKER) += test_ref_tracker.o
CFLAGS_test_fprobe.o += $(CC_FLAGS_FTRACE)
obj-$(CONFIG_FPROBE_SANITY_TEST) += test_fprobe.o
+
#
# CFLAGS for compiling floating point code inside the kernel. x86/Makefile
turns
# off the generation of FPU/SSE* instructions for kernel proper but FPU_FLAGS
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index e678884066bf..8c005c17f2db 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -6,7 +6,11 @@
* Jim Cromie
*/
-#define pr_fmt(fmt) "test_dd: " fmt
+#if defined(TEST_DYNAMIC_DEBUG_SUBMOD)
+ #define pr_fmt(fmt) "test_dd_submod: " fmt
+#else
+ #define pr_fmt(fmt) "test_dd: " fmt
+#endif
#define DEBUG /* enable all prdbgs (plain & class'd) at compiletime */
@@ -49,6 +53,14 @@ module_param_cb(do_prints, _ops_do_prints, NULL, 0600);
}; \
module_param_cb(_flags##_##_model, _ops_dyndbg_classes,
&_flags##_model, 0600)
+/*
+ * dynamic-debug imitates drm.debug's use of enums (DRM_UT_CORE etc)
+ * to define its classes/categories. dyndbg allows class-id's 0..62,
+ * reserving 63 for plain old (non-class'd) prdbgs. A module can
+ * define multiple classmaps, as long as they claim non-overlapping
+ * subranges.
+ */
+
/* numeric input, independent bits */
enum cat_disjoint_bits {
D2_CORE = 0,
@@ -61,7 +73,36 @@ enum cat_disjoint_bits {
D2_LEASE,
D2_DP,
D2_DRMRES };
+
+/* symbolic input, independent bits */
+enum cat_disjoint_names { LOW = 10, MID, HI };
+
+/* numeric verbosity, V2 > V1 related */
+enum cat_level_num { V0 = 14, V1, V2, V3, V4, V5, V6, V7 };
+
+/* symbolic verbosity */
+enum cat_level_names { L0 = 22, L1, L2, L3, L4, L5, L6, L7 };
+
+#if defined(TEST_DYNAMIC_DEBUG_SUBMOD)
+
+/* use the classmaps defined in 'parent' module below */
+DYNDBG_CLASSMAP_USE(map_disjoint_bits);
+DYNDBG_CLASSMAP_USE(map_disjoint_names);
+DYNDBG_CLASSMAP_USE(map_level_num);
+DYNDBG_CLASSMAP_USE(map_level_names);
+
+#else
+
+/*
+ * parent module, define a classmap of each of 4 types.
+ * enum values are class-ids
+ * enum symbols are stringified, used as classnames
+ * param bits are mapped in order: 0..N
+ * (a straight, obvious, linear map is encouraged)
+ */
+
DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits, DD_CLASS_TYPE_DISJOINT_BITS,
+ /* bits 0..N of param are mapped to these class-ids */
D2_CORE,
D2_DRIVER,
D2_KMS,
@@ -75,27 +116,23 @@ DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits,
DD_CLASS_TYPE_DISJOINT_BITS,
[Intel-gfx] [PATCH v3 18/19] test-dyndbg: tune sub-module behavior
lib/test_dynamic_debug.c is used to build 2 modules: test_dynamic_debug.ko and test_dynamic_debug_submod.ko Define DEBUG only in the main module, not in the submod. Its purpose is to insure that prdbgs are enabled by default, so that a modprobe without params actually logs something, showing that compile-time enablement works. This doesn't need to be repeated in the submodule. Rather, the submodule's purpose is to prove that classmaps defined and exported from a parent module are propagated to submodules, setting their class'd debugs accordingly. Signed-off-by: Jim Cromie --- lib/test_dynamic_debug.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c index 6b7bd35c3e15..70a1e8955ad0 100644 --- a/lib/test_dynamic_debug.c +++ b/lib/test_dynamic_debug.c @@ -10,10 +10,9 @@ #define pr_fmt(fmt) "test_dd_submod: " fmt #else #define pr_fmt(fmt) "test_dd: " fmt + #define DEBUG/* enable all prdbgs (plain & class'd), to log by default */ #endif -#define DEBUG /* enable all prdbgs (plain & class'd) at compiletime */ - #include /* run tests by reading or writing sysfs node: do_prints */ -- 2.39.1
[Intel-gfx] [PATCH v3 14/19] drm_print: fix stale macro-name in comment
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the macro args: DRM_UT_* list must be kept in sync
and in order.
Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3
drivers.")
Signed-off-by: Jim Cromie
---
. emphasize ABI non-change despite enum val change - Jani Nikula
. reorder to back of patchset to follow API name changes.
---
include/drm/drm_print.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 6a27e8f26770..7695ba31b3a4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const
char *prefix)
*
*/
enum drm_debug_category {
- /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+ /*
+* Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
+* the enum-values define BIT()s in drm.debug, so are ABI.
+*/
/**
* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
* drm_memory.c, ...
--
2.39.1
[Intel-gfx] [PATCH v3 17/19] test-dyndbg: disable WIP dyndbg-trace params
The dyndbg-to-trace feature is WIP, and not in mainline, so the presence of the interface to use/test it is unhelpful/confusing. So define DYNDBG_CLASSMAP_PARAM_T() as DYNDBG_CLASSMAP_PARAM() or blank, depending upon ifdef DYDBG_TRACE, and update 4 params controlling the T-flag to use it. Signed-off-by: Jim Cromie --- lib/test_dynamic_debug.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c index ff1e70ae060e..6b7bd35c3e15 100644 --- a/lib/test_dynamic_debug.c +++ b/lib/test_dynamic_debug.c @@ -54,6 +54,14 @@ module_param_cb(do_prints, _ops_do_prints, NULL, 0600); module_param_cb(_flags##_##_model, _ops_dyndbg_classes, \ &_flags##_##_model, 0600) +/* TBD */ +#ifdef DYNDBG_TRACE +#define DYNDBG_CLASSMAP_PARAM_T(_model, _flags)\ + DYNDBG_CLASSMAP_PARAM(_model, _flags) +#else +#define DYNDBG_CLASSMAP_PARAM_T(_model, _flags) +#endif + /* * dynamic-debug imitates drm.debug's use of enums (DRM_UT_CORE etc) * to define its classes/categories. dyndbg allows class-id's 0..62, @@ -115,22 +123,22 @@ DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits, DD_CLASS_TYPE_DISJOINT_BITS, D2_DP, D2_DRMRES); DYNDBG_CLASSMAP_PARAM(disjoint_bits, p); -DYNDBG_CLASSMAP_PARAM(disjoint_bits, T); +DYNDBG_CLASSMAP_PARAM_T(disjoint_bits, T); DYNDBG_CLASSMAP_DEFINE(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, LOW, MID, HI); DYNDBG_CLASSMAP_PARAM(disjoint_names, p); -DYNDBG_CLASSMAP_PARAM(disjoint_names, T); +DYNDBG_CLASSMAP_PARAM_T(disjoint_names, T); DYNDBG_CLASSMAP_DEFINE(map_level_num, DD_CLASS_TYPE_LEVEL_NUM, V0, V1, V2, V3, V4, V5, V6, V7); DYNDBG_CLASSMAP_PARAM(level_num, p); -DYNDBG_CLASSMAP_PARAM(level_num, T); +DYNDBG_CLASSMAP_PARAM_T(level_num, T); DYNDBG_CLASSMAP_DEFINE(map_level_names, DD_CLASS_TYPE_LEVEL_NAMES, L0, L1, L2, L3, L4, L5, L6, L7); DYNDBG_CLASSMAP_PARAM(level_names, p); -DYNDBG_CLASSMAP_PARAM(level_names, T); +DYNDBG_CLASSMAP_PARAM_T(level_names, T); #endif /* TEST_DYNAMIC_DEBUG_SUBMOD */ -- 2.39.1
[Intel-gfx] [PATCH v3 12/19] dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +-
drivers/gpu/drm/display/drm_dp_helper.c | 12 +-
drivers/gpu/drm/drm_crtc_helper.c | 12 +-
drivers/gpu/drm/i915/i915_params.c | 12 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +-
include/linux/dynamic_debug.h | 30 ++---
6 files changed, 22 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a7a3a382c4a6..6c57e598b7d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -190,17 +190,7 @@ int amdgpu_vcnfw_log;
static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
- "DRM_UT_CORE",
- "DRM_UT_DRIVER",
- "DRM_UT_KMS",
- "DRM_UT_PRIME",
- "DRM_UT_ATOMIC",
- "DRM_UT_VBL",
- "DRM_UT_STATE",
- "DRM_UT_LEASE",
- "DRM_UT_DP",
- "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
#endif
struct amdgpu_mgpu_info mgpu_info = {
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8fa7a88299e7..3bc188cb1116 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -42,17 +42,7 @@
#include "drm_dp_helper_internal.h"
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
- "DRM_UT_CORE",
- "DRM_UT_DRIVER",
- "DRM_UT_KMS",
- "DRM_UT_PRIME",
- "DRM_UT_ATOMIC",
- "DRM_UT_VBL",
- "DRM_UT_STATE",
- "DRM_UT_LEASE",
- "DRM_UT_DP",
- "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
#endif
struct dp_aux_backlight {
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 7e6b25446303..1780db9de069 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,17 +51,7 @@
#include "drm_crtc_helper_internal.h"
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
- "DRM_UT_CORE",
- "DRM_UT_DRIVER",
- "DRM_UT_KMS",
- "DRM_UT_PRIME",
- "DRM_UT_ATOMIC",
- "DRM_UT_VBL",
- "DRM_UT_STATE",
- "DRM_UT_LEASE",
- "DRM_UT_DP",
- "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
#endif
/**
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b5b2542ae364..e959d0384ead 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -30,17 +30,7 @@
#include "i915_drv.h"
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
- "DRM_UT_CORE",
- "DRM_UT_DRIVER",
- "DRM_UT_KMS",
- "DRM_UT_PRIME",
- "DRM_UT_ATOMIC",
- "DRM_UT_VBL",
- "DRM_UT_STATE",
- "DRM_UT_LEASE",
- "DRM_UT_DP",
- "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
#endif
#define i915_param_named(name, T, perm, desc) \
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index e4146b9af357..ad341411687f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -72,17 +72,7 @@
#include "nouveau_dmem.h"
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
- "DRM_UT_CORE",
- "DRM_UT_DRIVER",
- "DRM_UT_KMS",
- "DRM_UT_PRIME",
- "DRM_UT_ATOMIC",
- "DRM_UT_VBL",
- "DRM_UT_STATE",
- "DRM_UT_LEASE",
- "DRM_UT_DP",
- "DRM_UT_DRMRES");
[Intel-gfx] [PATCH v3 16/19] test-dyndbg: rename DD_SYS_WRAP to DYNDBG_CLASSMAP_PARAM
Original name was a punt; but the macro is maybe general enough to put
in the API later. Rename and improve the macro towards that end.
Also tweak internal name constructed in the macro, to add a '_'
between the name components. This changes the .i file only.
no functional change.
Signed-off-by: Jim Cromie
---
lib/test_dynamic_debug.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8c005c17f2db..ff1e70ae060e 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -44,14 +44,15 @@ module_param_cb(do_prints, _ops_do_prints, NULL,
0600);
* Additionally, here:
* - tie together sysname, mapname, bitsname, flagsname
*/
-#define DD_SYS_WRAP(_model, _flags)\
+#define DYNDBG_CLASSMAP_PARAM(_model, _flags) \
static unsigned long bits_##_model; \
- static struct ddebug_class_param _flags##_model = { \
+ static struct ddebug_class_param _flags##_##_model = { \
.bits = _##_model, \
.flags = #_flags, \
.map = _##_model, \
}; \
- module_param_cb(_flags##_##_model, _ops_dyndbg_classes,
&_flags##_model, 0600)
+ module_param_cb(_flags##_##_model, _ops_dyndbg_classes, \
+ &_flags##_##_model, 0600)
/*
* dynamic-debug imitates drm.debug's use of enums (DRM_UT_CORE etc)
@@ -113,23 +114,23 @@ DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits,
DD_CLASS_TYPE_DISJOINT_BITS,
D2_LEASE,
D2_DP,
D2_DRMRES);
-DD_SYS_WRAP(disjoint_bits, p);
-DD_SYS_WRAP(disjoint_bits, T);
+DYNDBG_CLASSMAP_PARAM(disjoint_bits, p);
+DYNDBG_CLASSMAP_PARAM(disjoint_bits, T);
DYNDBG_CLASSMAP_DEFINE(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES,
LOW, MID, HI);
-DD_SYS_WRAP(disjoint_names, p);
-DD_SYS_WRAP(disjoint_names, T);
+DYNDBG_CLASSMAP_PARAM(disjoint_names, p);
+DYNDBG_CLASSMAP_PARAM(disjoint_names, T);
DYNDBG_CLASSMAP_DEFINE(map_level_num, DD_CLASS_TYPE_LEVEL_NUM,
V0, V1, V2, V3, V4, V5, V6, V7);
-DD_SYS_WRAP(level_num, p);
-DD_SYS_WRAP(level_num, T);
+DYNDBG_CLASSMAP_PARAM(level_num, p);
+DYNDBG_CLASSMAP_PARAM(level_num, T);
DYNDBG_CLASSMAP_DEFINE(map_level_names, DD_CLASS_TYPE_LEVEL_NAMES,
L0, L1, L2, L3, L4, L5, L6, L7);
-DD_SYS_WRAP(level_names, p);
-DD_SYS_WRAP(level_names, T);
+DYNDBG_CLASSMAP_PARAM(level_names, p);
+DYNDBG_CLASSMAP_PARAM(level_names, T);
#endif /* TEST_DYNAMIC_DEBUG_SUBMOD */
--
2.39.1
[Intel-gfx] [PATCH v3 09/19] dyndbg: constify ddebug_apply_class_bitmap args
ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.
NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.
no functional change
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 10c29bc19901..b51f4bde6198 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -592,7 +592,7 @@ static int ddebug_exec_queries(char *query, const char
*modname)
/* apply a new bitmap to the sys-knob's current bit-state */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long
*old_bits,
+const unsigned long *new_bits, const
unsigned long *old_bits,
const char *query_modname)
{
#define QUERY_SIZE 128
--
2.39.1
[Intel-gfx] [PATCH v3 13/19] dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classname args to CLASSMAP macros were given as strings: "DRM_UT_CORE".
Now they are the actual enum const symbols: DRM_UT_CORE.
Direct use of symbols is tighter, more comprehensible by tools, grep
2- drop _base arg.
_base was the value of the 1st classname
that is now available due to 1, no need to require it 2x
So take _base out of the API/kdoc. Note that the macro impl keeps the
_base arg so that it can be used to set classmap.base, but reuses it
in the MAP-stringify _base, __VA_ARGS__ expression.
Also cleanup the API usage comment in test_dynamic_debug.c, and since
comments in test-code might not be noticed, restate that here.
Using the CLASSMAP api:
- class-specifications are enum consts/symbols,
like DRM_UT_CORE, DRM_UT_KMS, etc.
their values define bits in the sysfs-node (like drm.debug)
- they are stringified and accepted at >control
echo class DRM_UT_CORE +p >control
- multiple class-maps must share the per-module: 0-62 class_id space
(by setting initial enum values to non-overlapping subranges)
todo: fixup the 'i' prefix, a quick/dirty avoidance of MAP.
NOTE: test_dynamic_debug.c also has this helper macro to wire a
classmap to a drm.debug style parameter; its easier to just use it as
a model/template as needed, rather than try to make it general enough
to be an official API helper.
define DD_SYS_WRAP(_model, _flags) \
static unsigned long bits_##_model; \
static struct ddebug_class_param _flags##_model = { \
.bits = _##_model, \
.flags = #_flags, \
.map = _##_model, \
}; \
module_param_cb(_flags##_##_model, _ops_dyndbg_classes,
&_flags##_model, 0600)
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 22 +++---
include/drm/drm_print.h | 1 +
include/linux/dynamic_debug.h | 17 +--
include/linux/map.h | 55 +++
lib/test_dynamic_debug.c | 43 +--
5 files changed, 96 insertions(+), 42 deletions(-)
create mode 100644 include/linux/map.h
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4b697e18238d..07c25241e8cc 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,17 +56,17 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each
bit enables a debug cat
module_param_named(debug, __drm_debug, ulong, 0600);
#else
/* classnames must match vals of enum drm_debug_category */
-DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
- "DRM_UT_CORE",
- "DRM_UT_DRIVER",
- "DRM_UT_KMS",
- "DRM_UT_PRIME",
- "DRM_UT_ATOMIC",
- "DRM_UT_VBL",
- "DRM_UT_STATE",
- "DRM_UT_LEASE",
- "DRM_UT_DP",
- "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS,
+ DRM_UT_CORE,
+ DRM_UT_DRIVER,
+ DRM_UT_KMS,
+ DRM_UT_PRIME,
+ DRM_UT_ATOMIC,
+ DRM_UT_VBL,
+ DRM_UT_STATE,
+ DRM_UT_LEASE,
+ DRM_UT_DP,
+ DRM_UT_DRMRES);
static struct ddebug_class_param drm_debug_bitmap = {
.bits = &__drm_debug,
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..6a27e8f26770 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -333,6 +333,7 @@ static inline bool drm_debug_enabled_raw(enum
drm_debug_category category)
})
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+//extern struct ddebug_class_map drm_debug_classes[];
/*
* the drm.debug API uses dyndbg, so each drm_*dbg macro/callsite gets
* a descriptor, and only enabled callsites are reachable. They use
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 91015d1a04e0..7cdfc4b533ae 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -7,6 +7,7 @@
#endif
#include
+#include
/*
* An instance of this structure is created in a special
@@ -90,18 +91,16 @@ struct ddebug_class_map {
};
/**
- * DYNDBG_CLASSMAP_DEFINE - define debug-classes used by a module.
- * @_var: name of the classmap,
[Intel-gfx] [PATCH v3 10/19] dyndbg-API: split DECLARE_(DYNDBG_CLASSMAP) to $1(_DEFINE|_USE)
DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need to create the kparam, and call module_param_cb() to
wire the sysfs node to the classmap. DRM does this is in drm_print.c
In DRM, multiple modules declare identical DRM_UT_* classmaps, so that
the class'd prdbgs are modified across those modules in a coordinated
way across the subsystem, by either explicit class DRM_UT_* queries to
>control, or by writes to /sys/module/drm/parameters/debug (drm.debug)
This coordination-by-identical-declarations is weird, so this patch
splits the macro into _DEFINE and _USE flavors. This distinction
follows the definition vs declaration that K gave us, improving the
api; _DEFINE is used once to specify the classmap, and multiple users
_USE the single definition explicitly.
Currently the latter just reuses the former, and still needs all the
same args, but that can be tuned later; the _DEFINE can initialize an
(extern/global) struct classmap, and _USE can, well use/reference
that struct.
Also wrap DYNDBG_CLASSMAP_USEs with ifdef DRM_USE_DYNAMIC_DEBUG to
balance with the one around drm_print's use of DYNDBG_CLASSMAP_DEFINE.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
drivers/gpu/drm/display/drm_dp_helper.c | 4 +++-
drivers/gpu/drm/drm_crtc_helper.c | 4 +++-
drivers/gpu/drm/drm_print.c | 2 +-
drivers/gpu/drm/i915/i915_params.c | 4 +++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +++-
include/linux/dynamic_debug.h | 20
lib/test_dynamic_debug.c| 32 -
8 files changed, 48 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index cd4caaa29528..a7a3a382c4a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -189,7 +189,8 @@ int amdgpu_vcnfw_log;
static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -200,6 +201,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes,
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..8fa7a88299e7 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -41,7 +41,8 @@
#include "drm_dp_helper_internal.h"
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -52,6 +53,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes,
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
struct dp_aux_backlight {
struct backlight_device *base;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a209659a996c..7e6b25446303 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -50,7 +50,8 @@
#include "drm_crtc_helper_internal.h"
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -61,6 +62,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes,
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
/**
* DOC: overview
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 5b93c11895bb..4b697e18238d 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,7 +56,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables a debug cat
module_param_named(debug, __drm_debug, ulong, 0600);
#else
/* classnames must match vals of enum drm_debug_category */
[Intel-gfx] [PATCH v3 11/19] dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate them according to their separate jobs. Dyndbg's existing __dyndbg_classes[] section does: . catalogs the classmaps defined by the module (or builtin modules) . authorizes dyndbg to >control those class'd prdbgs for the module. This patch adds __dyndbg_class_refs[] section: . catalogs refs/uses of the classmap definitions. . authorizes dyndbg to >control those class'd prdbgs in ref'g module. . maps the client module to classmap definitions drm-drivers and helpers are clients. this allows dyndbg to apply drm.debug to the client module, when added. The distinction of the 2 roles yields these gains: It follows the define-once-declare-elsewhere pattern that K gave us, dumping the weird coordinated-changes-by-identical-classmaps API. It allows separate handling of class-refs, to find the classed kernel-params (if any) using this classmap, and propagate their settings to the class'd prdbgs in the client module. It fixes the chicken-egg problem that DRM_USE_DYNAMIC_DEBUG=y has; the new type allows dyndbg to handle class-refs found while adding the module. The new DYNDBG_CLASSMAP_* macros add records to the sections: DYNDBG_CLASSMAP_DEFINE: invoked just once per sub-system. for drm, its drm_print, where drm.debug is exposed. defines the classmap, names "DRM_UT_*", maps to class_id's authorizes dyndbg to exert >control populates __dyndbg_classes[] "section", __used. exports the classmap. DYNDBG_CLASSMAP_USE: invoked by modules using classmaps defined & exported elsewhere populates __dyndbg_class_refs[] "section", __used. maps client-module name to the extern'd classmap. has client-name, so dyndbg can recognize loading client modules. To support this, a few data changes: . struct ddebug_class_user contains: user-module-name, ref to classmap-defn encodes drm-driver's use of a classmap, allowing lookup struct ddebug_info gets 2 new fields to encapsulate the new section: class_refs, num_class_refs. set by dynamic_debug_init() for builtins. or by kernel/module/main:load_info() for loadable modules. vmlinux.lds.h: new BOUNDED_SECTION for class-refs, with linker symbols dynamic_debug.c: changes to: setup - in/under ddebug_add_module(), immediately following prdbg enables - in/under ddebug_change(), further below ddebug_attach_module_classes() - largely unchanged: called from ddebug_add_module finds classmaps whose .mod_name matches module being added. attaches them to the module's ddebug_table. minor tweaks for code regularity, debug output ddebug_attach_client_module_classes() - new fn: . like above, but works class-refs, not classes. . called from ddebug_add_module, after list-add to ddebug-tables. this lets ddebug_change find it to apply the settings . scans class-refs, for the block "owned" by the module being added. for builtins, its N consecutive of many. for loadables, N of N . calls ddebug_apply_parents_params() for each. ddebug_apply_parents_params(new fn) scans module's/builtin kernel-params, calls ddebug_match_attach_kparam for each to find the params/sysfs-nodes using a classmap. ddebug_match_apply_kparam(new fn): 1st, it tests the kernel-param.ops is dyndbg's; this guarantees that the attached arg is a struct ddebug_class_param, which has a ref to the param's state, and to the classmap. 2nd, it requires that the classmap attached to the kparam is the one were called for; modules can use many separate classmaps (as test_dynamic_debug does). Then apply the "parent" kparam's setting to the client. The ddebug_change() support: ddebug_find_valid_class(): This does the search over classmaps, looking for the class FOO echo'd to >control. So now it searches over __dyndbg_class_refs[] after __dyndbg_classes[]. ddebug_apply_class_bitmap(): now quieter when not changing things. ddebug_class_name(): return class-names for defined AND used classes. Signed-off-by: Jim Cromie -- v3 - s/BUG_ON/WARN_ON/ in __dyndbg_class_refs handling simpler args in callchain v2 - rebase past merge conflicts --- include/asm-generic/vmlinux.lds.h | 1 + include/linux/dynamic_debug.h | 39 --- kernel/module/main.c | 3 + lib/dynamic_debug.c | 170 ++ 4 files changed, 179 insertions(+), 34 deletions(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 659bf3b31c91..5beb0321613e 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -373,6 +373,7 @@ /* implement dynamic printk debug */\ . = ALIGN(8); \ BOUNDED_SECTION_BY(__dyndbg_classes, ___dyndbg_classes) \ + BOUNDED_SECTION_BY(__dyndbg_class_refs, ___dyndbg_class_refs) \ BOUNDED_SECTION_BY(__dyndbg, ___dyndbg)
[Intel-gfx] [PATCH v3 08/19] dyndbg: tighten ddebug_class_name() 1st arg
Change function's 1st arg-type, by derefing in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 2d4640479e5b..10c29bc19901 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1110,12 +1110,12 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
#define class_in_range(class_id, map) \
(class_id >= map->base && class_id < map->base + map->length)
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug
*dp)
{
- struct ddebug_class_map *map = iter->table->classes;
- int i, nc = iter->table->num_classes;
+ struct ddebug_class_map *map = dt->classes;
+ int i;
- for (i = 0; i < nc; i++, map++)
+ for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1149,7 +1149,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
- class = ddebug_class_name(iter, dp);
+ class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
--
2.39.1
[Intel-gfx] [PATCH v3 05/19] dyndbg: split param_set_dyndbg_classes to inner/outer fns
Inner fn adds mod_name param, allowing caller to guarantee that only
one module is affected by a prdbgs update. Outer fn preserves
kernel_param interface, passing NULL to inner fn.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 943e0597ecd4..0a5efc735b36 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -707,18 +707,9 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
return 0;
}
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+ const struct kernel_param *kp,
+ const char *modnm)
{
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -755,8 +746,8 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
KP_NAME(kp), inrep,
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
- v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
NULL);
+ v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
+ totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -769,7 +760,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -778,6 +769,21 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
}
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+ return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
EXPORT_SYMBOL(param_set_dyndbg_classes);
/**
--
2.39.1
[Intel-gfx] [PATCH v3 04/19] dyndbg: make ddebug_apply_class_bitmap more selective
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.
bash-5.2# lsmod
Module Size Used by
i915 3133440 0
drm_buddy 20480 1 i915
ttm90112 1 i915
i2c_algo_bit 16384 1 i915
video 61440 1 i915
wmi32768 1 video
drm_display_helper200704 1 i915
drm_kms_helper208896 2 drm_display_helper,i915
drm 606208 5
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344 2 drm_display_helper,i915
---
lib/dynamic_debug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 823190094350..943e0597ecd4 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -600,7 +600,8 @@ static int ddebug_exec_queries(char *query, const char
*modname)
/* apply a new bitmap to the sys-knob's current bit-state */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long
*old_bits)
+unsigned long *new_bits, unsigned long
*old_bits,
+const char *query_modname)
{
#define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -608,7 +609,8 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+ v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
+ query_modname ?: "");
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -617,12 +619,15 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s",
map->class_names[bi],
test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
- ct = ddebug_exec_queries(query, NULL);
+ ct = ddebug_exec_queries(query, query_modname);
matches += ct;
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
+ v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
+ query_modname ?: "");
+
return matches;
}
@@ -678,7 +683,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
map->class_names[cls_id]);
@@ -688,7 +693,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
- totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
map->class_names[cls_id], old_bits,
curr_bits);
@@ -751,7 +756,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+ totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -764,7 +769,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
NULL);
[Intel-gfx] [PATCH v3 07/19] dyndbg: reduce verbose/debug clutter
currently, for verbose=3, this is logged:
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_CORE
dyndbg: no matches for query
dyndbg: no-match: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_CORE
dyndbg: processed 1 queries, with 0 matches, 0 errs
This patch:
shrinks 3 lines of 2nd stanza to single line
drops 2 middle lines of 3rd stanza
3 differs from 1 only by status
2 is just status, retold in 4, with more info.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 0a5efc735b36..2d4640479e5b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -265,9 +265,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
- if (!nfound && verbose)
- pr_info("no matches for query\n");
-
return nfound;
}
@@ -496,7 +493,6 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
- v3pr_info("op='%c'\n", op);
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -510,7 +506,6 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
return -EINVAL;
}
}
- v3pr_info("flags=0x%x\n", modifiers->flags);
/* calculate final flags, mask based upon op */
switch (op) {
@@ -526,7 +521,7 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
- v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags,
modifiers->mask);
+ v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags,
modifiers->mask);
return 0;
}
@@ -536,7 +531,7 @@ static int ddebug_exec_query(char *query_string, const char
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
#define MAXWORDS 9
- int nwords, nfound;
+ int nwords;
char *words[MAXWORDS];
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -554,10 +549,7 @@ static int ddebug_exec_query(char *query_string, const
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
- nfound = ddebug_change(, );
- vpr_info_dq(, nfound ? "applied" : "no-match");
-
- return nfound;
+ return ddebug_change(, );
}
/* handle multiple queries in query string, continue on error, return
--
2.39.1
[Intel-gfx] [PATCH v3 03/19] dyndbg: replace classmap list with a vector
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.
So this changes:
struct ddebug_class_map drops list-head link.
struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.
The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.
The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.
Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.
This isn't technically a bugfix, but IMO simplifies later fixes for
the chicken-egg post-init enablement regression.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 1 -
lib/dynamic_debug.c | 61 ++-
2 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 41682278d2e8..bf47bcfad8e6 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -81,7 +81,6 @@ enum class_map_type {
};
struct ddebug_class_map {
- struct list_head link;
struct module *mod;
const char *mod_name; /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 009f2ead09c1..823190094350 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
extern struct ddebug_class_map __stop___dyndbg_classes[];
struct ddebug_table {
- struct list_head link, maps;
+ struct list_head link;
const char *mod_name;
- unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+ struct ddebug_class_map *classes;
+ unsigned int num_ddebugs, num_classes;
};
struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
query->first_lineno, query->last_lineno, query->class_string);
}
+#define __outvar /* filled by callee */
static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table
const *dt,
- const char
*class_string, int *class_id)
+ const char
*class_string,
+ __outvar int *class_id)
{
struct ddebug_class_map *map;
- int idx;
+ int i, idx;
- list_for_each_entry(map, >maps, link) {
+ for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
}
-#define __outvar /* filled by callee */
/*
* Search the tables for _ddebug's which match the given `query' and
* apply the `flags' and `mask' to them. Returns number of matching
@@ -1107,9 +1109,10 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
{
- struct ddebug_class_map *map;
+ struct ddebug_class_map *map = iter->table->classes;
+ int i, nc = iter->table->num_classes;
- list_for_each_entry(map, >table->maps, link)
+ for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1193,30 +1196,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
};
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct
_ddebug_info *di)
{
struct ddebug_class_map *cm;
- int i, j, ct = 0;
+ int i, nc = 0;
- for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+ /*
+* Find this module's classmaps in a subrange/wholerange of
+* the
[Intel-gfx] [PATCH v3 06/19] dyndbg: drop NUM_TYPE_ARRAY
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -104,11 +104,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base, \
.map_type = _maptype, \
- .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+ .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames, \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
/* encapsulate linker provided built-in (or module) dyndbg data */
struct _ddebug_info {
--
2.39.1
[Intel-gfx] [PATCH v3 02/19] test-dyndbg: show that DEBUG enables prdbgs at compiletime
Dyndbg is required to enable prdbgs at compile-time if DEBUG is defined. Show this works; add the defn to test_dynamic_debug.c, and manually inspect/verify its effect at module load: [ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes [ 15.293189] dyndbg: 32 debug prints in module test_dynamic_debug [ 15.293715] test_dd: init start [ 15.293716] test_dd: doing categories [ 15.293716] test_dd: LOW msg ... [ 15.293733] test_dd: L6 msg [ 15.293733] test_dd: L7 msg [ 15.293733] test_dd: init done NOTES: As is observable above, define DEBUG enables all prdbgs, including those in mod_init-fn, and more notably, the class'd ones (callsites with non-default class_ids). This differs from the >control interface, which in order to properly protect a client's class'd prdbgs, requires a "class FOO" in queries to change them. If this sounds wrong, note that the DEBUG is in the module source file, and is thus privileged. This yields an occaisional surprise; the following disables all the compile-time enabled plain prdbgs, but leaves the class'd ones enabled. :#> modprobe test_dynamic_debug dyndbg==_ Signed-off-by: Jim Cromie --- lib/test_dynamic_debug.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c index a01f0193a419..89dd7f285e31 100644 --- a/lib/test_dynamic_debug.c +++ b/lib/test_dynamic_debug.c @@ -8,6 +8,8 @@ #define pr_fmt(fmt) "test_dd: " fmt +#define DEBUG /* enable all prdbgs (plain & class'd) at compiletime */ + #include /* run tests by reading or writing sysfs node: do_prints */ -- 2.39.1
[Intel-gfx] [PATCH v3 01/19] test-dyndbg: fixup CLASSMAP usage error
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class
unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. Basically, I coded in an error, and
forgot to verify it and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP([1]), showing that
it is too error-prone. As noted in test-dynamic-debug.c comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist) used in DEFINE_DYNAMIC_DEBUG_CLASSMAP(), on
__VA_ARGS__ a 2nd time. Then, DRM would pass DRM_UT_* ; all the
categories, in order, and not their stringifications, which created
all the usage complications above.
[1] name changed later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.39.1
[Intel-gfx] [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression
Hi everyone, In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in drivers at modprobe. It is due to a chicken-egg problem loading modules; on `modprobe i915`, drm is loaded 1st, and drm/parameters/debug is set. When drm_debug_enabled() tested __drm_debug at runtime, this just worked. But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a static_key for each drm_dbg/dyndbg callsite, enabled by dyndbg's kparam callback on __drm_debug. So with drm.ko loaded and initialized before the dependent modules, their debug callsites aren't yet present to be enabled. STATUS - v3 not quite ready. rebased on -rc5, hopefully applies to patchwork head still has RFC patch -> CI_ONLY temporary, to avoid panics boots on my amdgpu box, drm.debug=0x3ff works at boot-time the "toggled" warning is repeatable with test_dynamic_debug*.ko it also occurs on amdgpu, so not just artificial. v2 is https://lore.kernel.org/lkml/20230113193016.749791-1-jim.cro...@gmail.com/ OVERVIEW As Jani Nikula noted rather more gently, DECLARE_DYNDBG_CLASSMAP is error-prone enough to call broken: sharing of a common classmap required identical classmap definitions in all modules using DRM_UT_*, which is inherently error-prone. IOW, it muddled the K distinction between a (single) definition, and multiple references. So patches 10-13 split it into: DYNDBG_CLASSMAP_DEFINE used once per subsystem to define each classmap. DYNDBG_CLASSMAP_USE declare dependence on a DEFINEd classmap. DYNDBG_CLASSMAP_DEFINE initializes the classmap, stores it into the (existing) __dyndbg_classes section, and exports the struct var (unlike DECLARE_DYNDBG_CLASSMAP). DYNDBG_CLASSMAP_USE initializes a class-ref struct, containing the user-module-name, and a ref to the exported classmap var. The distinction allows separate treatment of classmaps and classmap-refs, the latter getting additional behavior to propagate parent's kparam settings to USEr. (forex: drm.debug to drm-drivers) . lookup the classmap defn being referenced, and its module . find the module's kernel-params using the classmap . propagate kparam vals into the prdgs in module being added. It also makes the weird coordinated-changes-by-identical-classmaps "feature" unnecessary. Patch-10 splits the DECLARE macro into DEFINE & USE, and updates uses. Patch-11 is the core of it; the separate treatment begins in ddebug_add_module(). It calls ddebug_attach_module_classes(1) to handle class-defns; this adds ddebug_attach_client_module_classes(2) to handle class-refs, as they are found while modprobing drm drivers. (2) calls ddebug_apply_parents_params(3) on each USEr's referred classmap definition. (3) scans kernel-params owned by the module DEFINEing the classmap, either builtin or loadable, calls ddebug_match_apply_kparam(4) on each. (4) looks for kparams which are wired to dyndbg's param-ops. Those params have a struct ddebug_class_param attached, which has a classmap and a ref to a state-var (__drm_debug for DRM case). If the kparam's classmap is the same as from (2), then apply its state-var to the client module by calling ddebug_apply_class_bitmap(). Patch-12 cleans up DYNDBG_CLASSMAP_USE, dropping now unneeded args. Patch-13 improves DYNDBG_CLASSMAP_DEFINE, by accepting DRM_UT_* symbols directly, not "DRM_UT_*" (their strings). It adds new include/linux/map.h to support this. Patches 1-9 are prep, refactor, cleanup, tighten interfaces Patches 15-18 extend test_dynamic_debug to recreate DRM's multi-module regression; it builds both test_dynamic_debug.ko and _submod.ko, with an ifdef to _DEFINE in the main module, and _USE in the submod. This gives both modules identical set of prdbgs, which is helpful for comparing results. here it is, working properly: doing class DRM_UT_CORE -p [ 9904.961750] dyndbg: read 21 bytes from userspace [ 9904.962286] dyndbg: query 0: "class DRM_UT_CORE -p" mod:* [ 9904.962848] dyndbg: split into words: "class" "DRM_UT_CORE" "-p" [ 9904.963444] dyndbg: op='-' flags=0x0 maskp=0xfffe [ 9904.963945] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=DRM_UT_CORE [ 9904.964781] dyndbg: good-class: drm.DRM_UT_CORE module:drm nd:302 nc:1 nu:0 [ 9904.966411] dyndbg: class-ref: drm_kms_helper.DRM_UT_CORE module:drm_kms_helper nd:95 nc:0 nu:1 [ 9904.967265] dyndbg: class-ref: drm_display_helper.DRM_UT_CORE module:drm_display_helper nd:150 nc:0 nu:1 [ 9904.968349] dyndbg: class-ref: i915.DRM_UT_CORE module:i915 nd:1659 nc:0 nu:1 [ 9904.969801] dyndbg: class-ref: amdgpu.DRM_UT_CORE module:amdgpu nd:4425 nc:0 nu:1 [ 9904.977079] dyndbg: class-ref: nouveau.DRM_UT_CORE module:nouveau nd:103 nc:0 nu:1 [ 9904.977830] dyndbg: processed 1 queries, with 507 matches, 0 errs doing class DRM_UT_DRIVER +p [ 9906.151761] dyndbg: read 23 bytes from userspace [ 9906.152241] dyndbg: query 0: "class DRM_UT_DRIVER +p" mod:* [ 9906.152793] dyndbg: split into words: "class" "DRM_UT_DRIVER" "+p" [ 9906.153388] dyndbg:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v4,1/4] drm/gem: Remove BUG_ON in drm_gem_private_object_init
== Series Details == Series: series starting with [v4,1/4] drm/gem: Remove BUG_ON in drm_gem_private_object_init URL : https://patchwork.freedesktop.org/series/113318/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start and size from pages to bytes
== Series Details ==
Series: series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start
and size from pages to bytes
URL : https://patchwork.freedesktop.org/series/113313/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113313v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/index.html
Participating hosts (38 -> 37)
--
Missing(1): bat-atsm-1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113313v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@reset:
- {bat-rplp-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-rplp-1/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/bat-rplp-1/igt@i915_selftest@l...@reset.html
Known issues
Here are the changes found in Patchwork_113313v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][3] -> [SKIP][4] ([fdo#109271]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/fi-blb-e6850/igt@fb...@write.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][5] -> [INCOMPLETE][6] ([i915#4983])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][7] -> [INCOMPLETE][8] ([i915#4983])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
* igt@runner@aborted:
- bat-dg1-6: NOTRUN -> [FAIL][9] ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-9}:[FAIL][10] ([fdo#103375]) -> [PASS][11] +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-dp-3:
- {bat-dg2-9}:[FAIL][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3:
- {bat-dg2-9}:[FAIL][14] ([fdo#103375] / [i915#7932]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113313v1/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
Build changes
-
* Linux: CI_DRM_12638 -> Patchwork_113313v1
CI-20190529: 20190529
CI_DRM_12638: 6a52e439bb5bfa16c32681bec4442ae7d0f1df12 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7136: 31b6af91747ad8c705399c9006cdb81cb1864146 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113313v1: 6a52e439bb5bfa16c32681bec4442ae7d0f1df12 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
c420834fcc0e drm/amdkfd: Use cursor start instead of ttm resource start
0a504f9523fb drm/amdgpu: Use cursor start instead of ttm resource start
9340dc912bc2 drm/amdgpu: Support
[Intel-gfx] [PATCH v3 08/10] drm/fbdev-generic: Minimize client unregistering
For uninitialized framebuffers, only release the DRM client and
free the fbdev memory. Do not attempt to clean up the framebuffer.
DRM fbdev clients have a two-step initialization: first create
the DRM client; then create the framebuffer device on the first
successful hotplug event. In cases where the client never creates
the framebuffer, only the client state needs to be released. We
can detect which case it is, full or client-only cleanup, by
looking at the presence of fb_helper's info field.
v3:
* fix typo in commit message (Javier)
* release client before unpreparing fbdev
v2:
* remove test for (fbi != NULL) in drm_fbdev_cleanup() (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index dd8be5e0f271..a9c519001019 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -51,12 +51,10 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
*fb_helper)
if (!fb_helper->dev)
return;
- if (fbi) {
- if (fbi->fbdefio)
- fb_deferred_io_cleanup(fbi);
- if (drm_fbdev_use_shadow_fb(fb_helper))
- shadow = fbi->screen_buffer;
- }
+ if (fbi->fbdefio)
+ fb_deferred_io_cleanup(fbi);
+ if (drm_fbdev_use_shadow_fb(fb_helper))
+ shadow = fbi->screen_buffer;
drm_fb_helper_fini(fb_helper);
@@ -362,11 +360,13 @@ static void drm_fbdev_client_unregister(struct
drm_client_dev *client)
{
struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
- if (fb_helper->info)
- /* drm_fbdev_fb_destroy() takes care of cleanup */
+ if (fb_helper->info) {
drm_fb_helper_unregister_info(fb_helper);
- else
- drm_fbdev_release(fb_helper);
+ } else {
+ drm_client_release(_helper->client);
+ drm_fb_helper_unprepare(fb_helper);
+ kfree(fb_helper);
+ }
}
static int drm_fbdev_client_restore(struct drm_client_dev *client)
--
2.39.0
[Intel-gfx] [PATCH v3 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'
The generic fbdev emulation names variables of type struct fb_info
both 'fbi' and 'info'. The latter seems to be more common in fbdev
code, so name fbi accordingly.
Also replace the duplicate variable in drm_fbdev_fb_destroy().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 47 ++---
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 68ce652e3a14..43f94aa9e015 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -46,16 +46,15 @@ static int drm_fbdev_fb_release(struct fb_info *info, int
user)
static void drm_fbdev_fb_destroy(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
- struct fb_info *fbi = fb_helper->info;
void *shadow = NULL;
if (!fb_helper->dev)
return;
- if (fbi->fbdefio)
- fb_deferred_io_cleanup(fbi);
+ if (info->fbdefio)
+ fb_deferred_io_cleanup(info);
if (drm_fbdev_use_shadow_fb(fb_helper))
- shadow = fbi->screen_buffer;
+ shadow = info->screen_buffer;
drm_fb_helper_fini(fb_helper);
@@ -171,7 +170,7 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
*fb_helper,
struct drm_device *dev = fb_helper->dev;
struct drm_client_buffer *buffer;
struct drm_framebuffer *fb;
- struct fb_info *fbi;
+ struct fb_info *info;
u32 format;
struct iosys_map map;
int ret;
@@ -190,35 +189,35 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
*fb_helper,
fb_helper->fb = buffer->fb;
fb = buffer->fb;
- fbi = drm_fb_helper_alloc_info(fb_helper);
- if (IS_ERR(fbi))
- return PTR_ERR(fbi);
+ info = drm_fb_helper_alloc_info(fb_helper);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
- fbi->fbops = _fbdev_fb_ops;
- fbi->screen_size = sizes->surface_height * fb->pitches[0];
- fbi->fix.smem_len = fbi->screen_size;
- fbi->flags = FBINFO_DEFAULT;
+ info->fbops = _fbdev_fb_ops;
+ info->screen_size = sizes->surface_height * fb->pitches[0];
+ info->fix.smem_len = info->screen_size;
+ info->flags = FBINFO_DEFAULT;
- drm_fb_helper_fill_info(fbi, fb_helper, sizes);
+ drm_fb_helper_fill_info(info, fb_helper, sizes);
if (drm_fbdev_use_shadow_fb(fb_helper)) {
- fbi->screen_buffer = vzalloc(fbi->screen_size);
- if (!fbi->screen_buffer)
+ info->screen_buffer = vzalloc(info->screen_size);
+ if (!info->screen_buffer)
return -ENOMEM;
- fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
+ info->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
- fbi->fbdefio = _fbdev_defio;
- fb_deferred_io_init(fbi);
+ info->fbdefio = _fbdev_defio;
+ fb_deferred_io_init(info);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, );
if (ret)
return ret;
if (map.is_iomem) {
- fbi->screen_base = map.vaddr_iomem;
+ info->screen_base = map.vaddr_iomem;
} else {
- fbi->screen_buffer = map.vaddr;
- fbi->flags |= FBINFO_VIRTFB;
+ info->screen_buffer = map.vaddr;
+ info->flags |= FBINFO_VIRTFB;
}
/*
@@ -227,10 +226,10 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
*fb_helper,
* case.
*/
#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
- if (fb_helper->hint_leak_smem_start && fbi->fix.smem_start == 0
&&
+ if (fb_helper->hint_leak_smem_start && info->fix.smem_start ==
0 &&
!drm_WARN_ON_ONCE(dev, map.is_iomem))
- fbi->fix.smem_start =
- page_to_phys(virt_to_page(fbi->screen_buffer));
+ info->fix.smem_start =
+ page_to_phys(virt_to_page(info->screen_buffer));
#endif
}
--
2.39.0
[Intel-gfx] [PATCH v3 05/10] drm/fb-helper: Remove preferred_bpp parameter from fbdev internals
Store the console's preferred BPP value in struct drm_fb_helper
and remove the respective function parameters from the internal
fbdev code.
The BPP value is only required as a fallback and will now always
be available in the fb-helper instance.
No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4379bcd7718b..258103d317ac 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1786,7 +1786,7 @@ static uint32_t
drm_fb_helper_find_color_mode_format(struct drm_fb_helper *fb_he
return drm_fb_helper_find_format(fb_helper, formats, format_count, bpp,
depth);
}
-static int __drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper, int
preferred_bpp,
+static int __drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
struct drm_client_dev *client = _helper->client;
@@ -1831,7 +1831,7 @@ static int __drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int prefe
surface_format = drm_fb_helper_find_color_mode_format(fb_helper,
plane->format_types,
plane->format_count,
-
preferred_bpp);
+
fb_helper->preferred_bpp);
if (surface_format != DRM_FORMAT_INVALID)
break; /* found supported format */
}
@@ -1903,7 +1903,7 @@ static int __drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int prefe
return 0;
}
-static int drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper, int
preferred_bpp,
+static int drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
struct drm_client_dev *client = _helper->client;
@@ -1912,7 +1912,7 @@ static int drm_fb_helper_find_sizes(struct drm_fb_helper
*fb_helper, int preferr
int ret;
mutex_lock(>modeset_mutex);
- ret = __drm_fb_helper_find_sizes(fb_helper, preferred_bpp, sizes);
+ ret = __drm_fb_helper_find_sizes(fb_helper, sizes);
mutex_unlock(>modeset_mutex);
if (ret)
@@ -1934,15 +1934,14 @@ static int drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int preferr
* Allocates the backing storage and sets up the fbdev info structure through
* the ->fb_probe callback.
*/
-static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
-int preferred_bpp)
+static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper)
{
struct drm_client_dev *client = _helper->client;
struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_surface_size sizes;
int ret;
- ret = drm_fb_helper_find_sizes(fb_helper, preferred_bpp, );
+ ret = drm_fb_helper_find_sizes(fb_helper, );
if (ret) {
/* First time: disable all crtc's.. */
if (!fb_helper->deferred_setup)
@@ -2125,8 +2124,7 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper
*fb_helper)
/* Note: Drops fb_helper->lock before returning. */
static int
-__drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
- int bpp_sel)
+__drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
struct fb_info *info;
@@ -2137,10 +2135,9 @@ __drm_fb_helper_initial_config_and_unlock(struct
drm_fb_helper *fb_helper,
height = dev->mode_config.max_height;
drm_client_modeset_probe(_helper->client, width, height);
- ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
+ ret = drm_fb_helper_single_fb_probe(fb_helper);
if (ret < 0) {
if (ret == -EAGAIN) {
- fb_helper->preferred_bpp = bpp_sel;
fb_helper->deferred_setup = true;
ret = 0;
}
@@ -2231,8 +2228,10 @@ int drm_fb_helper_initial_config(struct drm_fb_helper
*fb_helper, int bpp_sel)
if (!drm_fbdev_emulation)
return 0;
+ fb_helper->preferred_bpp = bpp_sel;
+
mutex_lock(_helper->lock);
- ret = __drm_fb_helper_initial_config_and_unlock(fb_helper, bpp_sel);
+ ret = __drm_fb_helper_initial_config_and_unlock(fb_helper);
return ret;
}
@@ -2268,8 +2267,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
*fb_helper)
[Intel-gfx] [PATCH v3 09/10] drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy()
The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
caller. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index a9c519001019..68ce652e3a14 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -43,8 +43,9 @@ static int drm_fbdev_fb_release(struct fb_info *info, int
user)
return 0;
}
-static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
+static void drm_fbdev_fb_destroy(struct fb_info *info)
{
+ struct drm_fb_helper *fb_helper = info->par;
struct fb_info *fbi = fb_helper->info;
void *shadow = NULL;
@@ -64,24 +65,10 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
*fb_helper)
drm_client_buffer_vunmap(fb_helper->buffer);
drm_client_framebuffer_delete(fb_helper->buffer);
-}
-
-static void drm_fbdev_release(struct drm_fb_helper *fb_helper)
-{
- drm_fbdev_cleanup(fb_helper);
drm_client_release(_helper->client);
kfree(fb_helper);
}
-/*
- * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
- * unregister_framebuffer() or fb_release().
- */
-static void drm_fbdev_fb_destroy(struct fb_info *info)
-{
- drm_fbdev_release(info->par);
-}
-
static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct drm_fb_helper *fb_helper = info->par;
--
2.39.0
[Intel-gfx] [PATCH v3 07/10] drm/fbdev-generic: Minimize hotplug error handling
Call drm_fb_helper_fini() in the generic-fbdev hotplug helper to revert the effects of drm_fb_helper_init(). No full cleanup is required. v3: * fix error in commit message (Javier) Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/gpu/drm/drm_fbdev_generic.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_fbdev_generic.c b/drivers/gpu/drm/drm_fbdev_generic.c index 6ae014040df3..dd8be5e0f271 100644 --- a/drivers/gpu/drm/drm_fbdev_generic.c +++ b/drivers/gpu/drm/drm_fbdev_generic.c @@ -387,25 +387,21 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev *client) ret = drm_fb_helper_init(dev, fb_helper); if (ret) - goto err; + goto err_drm_err; if (!drm_drv_uses_atomic_modeset(dev)) drm_helper_disable_unused_functions(dev); ret = drm_fb_helper_initial_config(fb_helper); if (ret) - goto err_cleanup; + goto err_drm_fb_helper_fini; return 0; -err_cleanup: - drm_fbdev_cleanup(fb_helper); -err: - fb_helper->dev = NULL; - fb_helper->info = NULL; - +err_drm_fb_helper_fini: + drm_fb_helper_fini(fb_helper); +err_drm_err: drm_err(dev, "fbdev: Failed to setup generic emulation (ret=%d)\n", ret); - return ret; } -- 2.39.0
[Intel-gfx] [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup
Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 135d58b8007b..63f66325a8a5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
- drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
-
ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto err;
@@ -456,12 +454,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
if (!fb_helper)
return;
+ drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
ret = drm_client_init(dev, _helper->client, "fbdev",
_fbdev_client_funcs);
if (ret) {
- kfree(fb_helper);
drm_err(dev, "Failed to register client: %d\n", ret);
- return;
+ goto err_drm_client_init;
}
/*
@@ -484,5 +482,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
drm_client_register(_helper->client);
+
+ return;
+
+err_drm_client_init:
+ drm_fb_helper_unprepare(fb_helper);
+ kfree(fb_helper);
+ return;
}
EXPORT_SYMBOL(drm_fbdev_generic_setup);
--
2.39.0
[Intel-gfx] [PATCH v3 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()
Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
functional changes.
v2:
* declare as static inline (kernel test robot)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 14 +-
include/drm/drm_fb_helper.h | 5 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c5c13e192b64..4379bcd7718b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -435,6 +435,18 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
}
EXPORT_SYMBOL(drm_fb_helper_prepare);
+/**
+ * drm_fb_helper_unprepare - clean up a drm_fb_helper structure
+ * @fb_helper: driver-allocated fbdev helper structure to set up
+ *
+ * Cleans up the framebuffer helper. Inverse of drm_fb_helper_prepare().
+ */
+void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
+{
+ mutex_destroy(_helper->lock);
+}
+EXPORT_SYMBOL(drm_fb_helper_unprepare);
+
/**
* drm_fb_helper_init - initialize a drm_fb_helper
* @dev: drm device
@@ -561,7 +573,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
mutex_unlock(_fb_helper_lock);
- mutex_destroy(_helper->lock);
+ drm_fb_helper_unprepare(fb_helper);
if (!fb_helper->client.funcs)
drm_client_release(_helper->client);
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index f443e1f11654..39710c570a04 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -230,6 +230,7 @@ drm_fb_helper_from_client(struct drm_client_dev *client)
#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
const struct drm_fb_helper_funcs *funcs);
+void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper);
int drm_fb_helper_init(struct drm_device *dev, struct drm_fb_helper *helper);
void drm_fb_helper_fini(struct drm_fb_helper *helper);
int drm_fb_helper_blank(int blank, struct fb_info *info);
@@ -296,6 +297,10 @@ static inline void drm_fb_helper_prepare(struct drm_device
*dev,
{
}
+static inline void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
+{
+}
+
static inline int drm_fb_helper_init(struct drm_device *dev,
struct drm_fb_helper *helper)
{
--
2.39.0
[Intel-gfx] [PATCH v3 00/10] drm/fb-helper: Various cleanups
Add various cleanups and changes to DRM's fbdev helpers and the generic fbdev emulation. There's no clear theme here, just lots of small things that need to be updated. In the end, the code will better reflect which parts are in the DRM client, which is fbdev emulation, and which are shared fbdev helpers. v3: * various minor fixes (Javier)) * build with CONFIG_DRM_FBDEV_EMULATION unset (kernel test robot) v2: * cleanups in drm_fbdev_fb_destroy() (Sam) * fix declaration of drm_fb_helper_unprepare() Thomas Zimmermann (10): drm/client: Test for connectors before sending hotplug event drm/client: Add hotplug_failed flag drm/fb-helper: Introduce drm_fb_helper_unprepare() drm/fbdev-generic: Initialize fb-helper structure in generic setup drm/fb-helper: Remove preferred_bpp parameter from fbdev internals drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function drm/fbdev-generic: Minimize hotplug error handling drm/fbdev-generic: Minimize client unregistering drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy() drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info' drivers/gpu/drm/armada/armada_fbdev.c | 4 +- drivers/gpu/drm/drm_client.c | 10 ++ drivers/gpu/drm/drm_fb_helper.c| 58 ++--- drivers/gpu/drm/drm_fbdev_generic.c| 131 - drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- drivers/gpu/drm/gma500/framebuffer.c | 4 +- drivers/gpu/drm/i915/display/intel_fbdev.c | 11 +- drivers/gpu/drm/msm/msm_fbdev.c| 4 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 +- drivers/gpu/drm/radeon/radeon_fb.c | 4 +- drivers/gpu/drm/tegra/fb.c | 7 +- include/drm/drm_client.h | 8 ++ include/drm/drm_fb_helper.h| 16 ++- 13 files changed, 138 insertions(+), 127 deletions(-) base-commit: 7d3e7f64a42d66ba8da6e7b66a8d85457ef84570 -- 2.39.0
[Intel-gfx] [PATCH v3 06/10] drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function
Initialize the fb-helper's preferred_bpp field early from within
drm_fb_helper_prepare(); instead of the later client hot-plugging
callback. This simplifies the generic fbdev setup function.
No real changes, but all drivers' fbdev code has to be adapted.
v3:
* build with CONFIG_DRM_FBDEV_EMULATION unset (kernel test bot)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/armada/armada_fbdev.c | 4 ++--
drivers/gpu/drm/drm_fb_helper.c| 22 ++
drivers/gpu/drm/drm_fbdev_generic.c| 19 ++-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
drivers/gpu/drm/gma500/framebuffer.c | 4 ++--
drivers/gpu/drm/i915/display/intel_fbdev.c | 11 ++-
drivers/gpu/drm/msm/msm_fbdev.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 ++--
drivers/gpu/drm/radeon/radeon_fb.c | 4 ++--
drivers/gpu/drm/tegra/fb.c | 7 +++
include/drm/drm_fb_helper.h| 11 ++-
11 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 584cee123bd8..07e410c62b7a 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -129,7 +129,7 @@ int armada_fbdev_init(struct drm_device *dev)
priv->fbdev = fbh;
- drm_fb_helper_prepare(dev, fbh, _fb_helper_funcs);
+ drm_fb_helper_prepare(dev, fbh, 32, _fb_helper_funcs);
ret = drm_fb_helper_init(dev, fbh);
if (ret) {
@@ -137,7 +137,7 @@ int armada_fbdev_init(struct drm_device *dev)
goto err_fb_helper;
}
- ret = drm_fb_helper_initial_config(fbh, 32);
+ ret = drm_fb_helper_initial_config(fbh);
if (ret) {
DRM_ERROR("failed to set initial config\n");
goto err_fb_setup;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 258103d317ac..28c428e9c530 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -416,14 +416,30 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
* drm_fb_helper_prepare - setup a drm_fb_helper structure
* @dev: DRM device
* @helper: driver-allocated fbdev helper structure to set up
+ * @preferred_bpp: Preferred bits per pixel for the device.
* @funcs: pointer to structure of functions associate with this helper
*
* Sets up the bare minimum to make the framebuffer helper usable. This is
* useful to implement race-free initialization of the polling helpers.
*/
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
+ unsigned int preferred_bpp,
const struct drm_fb_helper_funcs *funcs)
{
+ /*
+* Pick a preferred bpp of 32 if no value has been given. This
+* will select XRGB for the framebuffer formats. All drivers
+* have to support XRGB for backwards compatibility with legacy
+* userspace, so it's the safe choice here.
+*
+* TODO: Replace struct drm_mode_config.preferred_depth and this
+* bpp value with a preferred format that is given as struct
+* drm_format_info. Then derive all other values from the
+* format.
+*/
+ if (!preferred_bpp)
+ preferred_bpp = 32;
+
INIT_LIST_HEAD(>kernel_fb_list);
spin_lock_init(>damage_lock);
INIT_WORK(>resume_work, drm_fb_helper_resume_worker);
@@ -432,6 +448,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
mutex_init(>lock);
helper->funcs = funcs;
helper->dev = dev;
+ helper->preferred_bpp = preferred_bpp;
}
EXPORT_SYMBOL(drm_fb_helper_prepare);
@@ -2183,7 +2200,6 @@ __drm_fb_helper_initial_config_and_unlock(struct
drm_fb_helper *fb_helper)
/**
* drm_fb_helper_initial_config - setup a sane initial connector configuration
* @fb_helper: fb_helper device struct
- * @bpp_sel: bpp value to use for the framebuffer configuration
*
* Scans the CRTCs and connectors and tries to put together an initial setup.
* At the moment, this is a cloned configuration across all heads with
@@ -2221,15 +2237,13 @@ __drm_fb_helper_initial_config_and_unlock(struct
drm_fb_helper *fb_helper)
* RETURNS:
* Zero if everything went ok, nonzero otherwise.
*/
-int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel)
+int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper)
{
int ret;
if (!drm_fbdev_emulation)
return 0;
- fb_helper->preferred_bpp = bpp_sel;
-
mutex_lock(_helper->lock);
ret = __drm_fb_helper_initial_config_and_unlock(fb_helper);
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index
[Intel-gfx] [PATCH v3 02/10] drm/client: Add hotplug_failed flag
Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.
This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper, which prevents us from initializing these pointers
early after allocation.
The change also harmonizes behavior among DRM clients. Additional DRM
clients will now handle failed hotplugging like fbdev does.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_client.c| 5 +
drivers/gpu/drm/drm_fbdev_generic.c | 4
include/drm/drm_client.h| 8
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 09ac191c202d..009e7b10455c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -208,8 +208,13 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!client->funcs || !client->funcs->hotplug)
continue;
+ if (client->hotplug_failed)
+ continue;
+
ret = client->funcs->hotplug(client);
drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
+ if (ret)
+ client->hotplug_failed = true;
}
mutex_unlock(>clientlist_mutex);
}
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 3d455a2e3fb5..135d58b8007b 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -382,10 +382,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
struct drm_device *dev = client->dev;
int ret;
- /* Setup is not retried if it has failed */
- if (!fb_helper->dev && fb_helper->funcs)
- return 0;
-
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 4fc8018eddda..39482527a775 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -106,6 +106,14 @@ struct drm_client_dev {
* @modesets: CRTC configurations
*/
struct drm_mode_set *modesets;
+
+ /**
+* @hotplug failed:
+*
+* Set by client hotplug helpers if the hotplugging failed
+* before. It is usually not tried again.
+*/
+ bool hotplug_failed;
};
int drm_client_init(struct drm_device *dev, struct drm_client_dev *client,
--
2.39.0
[Intel-gfx] [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_client.c| 5 +
drivers/gpu/drm/drm_fbdev_generic.c | 5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 262ec64d4397..09ac191c202d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
+ if (!dev->mode_config.num_connector) {
+ drm_dbg_kms(dev, "No connectors found, will not send hotplug
events!\n");
+ return;
+ }
+
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (!client->funcs || !client->funcs->hotplug)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 0a4c160e0e58..3d455a2e3fb5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -389,11 +389,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
- if (!dev->mode_config.num_connector) {
- drm_dbg_kms(dev, "No connectors found, will not create
framebuffer!\n");
- return 0;
- }
-
drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
ret = drm_fb_helper_init(dev, fb_helper);
--
2.39.0
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start and size from pages to bytes
== Series Details == Series: series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start and size from pages to bytes URL : https://patchwork.freedesktop.org/series/113313/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Annotate a couple more workaround registers as MCR
On Tue, Jan 24, 2023 at 05:14:07PM -0800, Matt Roper wrote:
> GAMSTLB_CTRL and GAMCNTRL_CTRL became multicast/replicated registers on
> Xe_HP. They should be defined accordingly and use MCR-aware operations.
>
> These registers have only been used for some dg2/xehpsdv workarounds, so
> this fix is mostly just for consistency/future-proofing; even lacking
> the MCR annotation, workarounds will always be properly applied in a
> multicast manner on these platforms.
>
> Cc: Gustavo Sousa
> Fixes: 58bc2453ab8a ("drm/i915: Define multicast registers as a new type")
> Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 16
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 4a37d048b512..a0ebf3fa63ca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1105,12 +1105,12 @@
> #define VEBX_MOD_CTRLMCR_REG(0xcf38)
> #define FORCE_MISS_FTLBREG_BIT(3)
>
> -#define GEN12_GAMSTLB_CTRL _MMIO(0xcf4c)
> +#define XEHP_GAMSTLB_CTRLMCR_REG(0xcf4c)
> #define CONTROL_BLOCK_CLKGATE_DIS REG_BIT(12)
> #define EGRESS_BLOCK_CLKGATE_DIS REG_BIT(11)
> #define TAG_BLOCK_CLKGATE_DIS REG_BIT(7)
>
> -#define GEN12_GAMCNTRL_CTRL _MMIO(0xcf54)
> +#define XEHP_GAMCNTRL_CTRL MCR_REG(0xcf54)
> #define INVALIDATION_BROADCAST_MODE_DISREG_BIT(12)
> #define GLOBAL_INVALIDATION_MODE REG_BIT(2)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 0e7f64bb2860..94eb498f3c2c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1570,8 +1570,8 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_14014368820:xehpsdv */
> - wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
> - INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
> + wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
> + INVALIDATION_BROADCAST_MODE_DIS |
> GLOBAL_INVALIDATION_MODE);
> }
>
> static void
> @@ -1665,10 +1665,10 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, SSMCGCTL9530, RTFUNIT_CLKGATE_DIS);
>
> /* Wa_14010680813:dg2_g10 */
> - wa_write_or(wal, GEN12_GAMSTLB_CTRL,
> - CONTROL_BLOCK_CLKGATE_DIS |
> - EGRESS_BLOCK_CLKGATE_DIS |
> - TAG_BLOCK_CLKGATE_DIS);
> + wa_mcr_write_or(wal, XEHP_GAMSTLB_CTRL,
> + CONTROL_BLOCK_CLKGATE_DIS |
> + EGRESS_BLOCK_CLKGATE_DIS |
> + TAG_BLOCK_CLKGATE_DIS);
> }
>
> /* Wa_14014830051:dg2 */
> @@ -1691,8 +1691,8 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_1509235366:dg2 */
> - wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
> - INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
> + wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
> + INVALIDATION_BROADCAST_MODE_DIS |
> GLOBAL_INVALIDATION_MODE);
> }
>
> static void
> --
> 2.39.0
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: GAM registers don't need to be re-applied on engine resets
On Tue, Jan 24, 2023 at 05:14:06PM -0800, Matt Roper wrote:
> Register reset characteristics (i.e., whether the register maintains or
> loses its value on engine reset) is an important factor that determines
> which wa_list we want to add workarounds to. We recently found out that
> the bspec documentation for the Xe_HP's "GAM" registers in the 0xC800 -
> 0xCFFF range was misleading; these registers do not actually lose their
> value on engine resets as the documentation implied. This means there's
> no need to re-apply workarounds touching these registers after a reset,
> and the corresponding workarounds should be moved from the 'engine'
> lists back to the 'gt' list.
>
> While moving these GAM-related workarounds to the various platforms' GT
> workaround functions, we should also take care to handle Wa_18018781329
> properly for MTL's two GTs --- the render/compute setting should be set
> on the primary GT where those engines reside, and the vd/ve/gsc setting
> should be set on the media GT. Previously the VD/VE/GSC setting was not
> being properly applied.
>
> Cc: Gustavo Sousa
> Fixes: edf176f48d87 ("drm/i915/dg2: Move misplaced 'ctx' & 'gt' wa's to
> engine wa list")
> Fixes: b2006061ae28 ("drm/i915/xehpsdv: Move render/compute engine reset
> domains related workarounds")
> Fixes: 41bb543f5598 ("drm/i915/mtl: Add initial gt workarounds")
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
> drivers/gpu/drm/i915/i915_drv.h | 4 +
> 3 files changed, 59 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 2727645864db..4a37d048b512 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1100,6 +1100,7 @@
> #define XEHP_MERT_MOD_CTRL MCR_REG(0xcf28)
> #define RENDER_MOD_CTRL MCR_REG(0xcf2c)
> #define COMP_MOD_CTRLMCR_REG(0xcf30)
> +#define GSC_MOD_CTRL MCR_REG(0xcf30) /* media GT
> only */
> #define VDBX_MOD_CTRLMCR_REG(0xcf34)
> #define VEBX_MOD_CTRLMCR_REG(0xcf38)
> #define FORCE_MISS_FTLBREG_BIT(3)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 4efc1a532982..0e7f64bb2860 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1559,6 +1559,19 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
>
> /* Wa_14011060649:xehpsdv */
> wa_14011060649(gt, wal);
> +
> + /* Wa_18018781329 */
> + wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
Maybe worth mentioning in the commit message that Wa_18018781329 is being
extended to XEHPSDV in this patch? This could also be on its own patch.
> +
> + /* Wa_14012362059:xehpsdv */
> + wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> +
> + /* Wa_14014368820:xehpsdv */
> + wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
> + INVALIDATION_BROADCAST_MODE_DIS | GLOBAL_INVALIDATION_MODE);
> }
>
> static void
> @@ -1599,6 +1612,12 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> DSS_ROUTER_CLKGATE_DIS);
> }
>
> + if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_B0) ||
> + IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) {
> + /* Wa_14012362059:dg2 */
> + wa_mcr_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> + }
> +
> if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_B0)) {
> /* Wa_14010948348:dg2_g10 */
> wa_write_or(wal, UNSLCGCTL9430, MSQDUNIT_CLKGATE_DIS);
> @@ -1644,6 +1663,12 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
>
> /* Wa_14011028019:dg2_g10 */
> wa_mcr_write_or(wal, SSMCGCTL9530, RTFUNIT_CLKGATE_DIS);
> +
> + /* Wa_14010680813:dg2_g10 */
> + wa_write_or(wal, GEN12_GAMSTLB_CTRL,
> + CONTROL_BLOCK_CLKGATE_DIS |
> + EGRESS_BLOCK_CLKGATE_DIS |
> + TAG_BLOCK_CLKGATE_DIS);
> }
>
> /* Wa_14014830051:dg2 */
> @@ -1658,6 +1683,16 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
>
> /* Wa_14015795083 */
> wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> +
> + /* Wa_18018781329 */
> +
Re: [Intel-gfx] [PATCH v4] drm/i915/uncore: Use GT message helpers in uncore
On Wed, Jan 25, 2023 at 10:51:53AM +, Tvrtko Ursulin wrote:
>
> On 24/01/2023 20:54, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > Uncore is really part of the GT. So use the GT specific debug/error
That's not really true; uncore should be outside the GT since it's used
for all kinds of non-GT stuff as well (sgunit, display, etc.). I
believe "uncore" is just an old-fashioned name for what modern docs
refer to as "system agent" these days.
Granted, our i915 design does stretch the truth quite a bit today by
rolling some of the GT-specific concepts into the uncore code (GT
forcewake/shadowing, GSI offset, etc.). Having two intel_uncore
structures on a platform like MTL doesn't really match the hardware
reality at the lowest levels, but allows us to update the software for
these new platforms without major, intrusive changes for all platforms.
I feel like including 'gt' information in log messages unrelated to GT
might be confusing. For display stuff it's probably obvious that the GT
information is bogus, but when stuff is related to the sgunit it won't
always be so obvious.
Matt
> > message helpers so as to get the GT index in the prints.
>
> Conversion looks good to me and on balance it's better to include the origin
> in logs even for messages which strictly are not GT related, than not to
> have the origin at all (intel_de_... helpers, I *think*).
>
> Reviewed-by: Tvrtko Ursulin
>
> I'll just add Jani and Matt in case they have a different opinion.
>
> Regards,
>
> Tvrtko
>
> > Signed-off-by: John Harrison
> > ---
> > drivers/gpu/drm/i915/intel_uncore.c | 133 +---
> > 1 file changed, 63 insertions(+), 70 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 8dee9e62a73ee..4e357477c6592 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include "gt/intel_engine_regs.h"
> > +#include "gt/intel_gt_print.h"
> > #include "gt/intel_gt_regs.h"
> > #include "i915_drv.h"
> > @@ -83,8 +84,7 @@ static void mmio_debug_resume(struct intel_uncore *uncore)
> > uncore->debug->unclaimed_mmio_check =
> > uncore->debug->saved_mmio_check;
> > if (check_for_unclaimed_mmio(uncore))
> > - drm_info(>i915->drm,
> > -"Invalid mmio detected during user access\n");
> > + gt_info(uncore->gt, "Invalid mmio detected during user
> > access\n");
> > spin_unlock(>debug->lock);
> > }
> > @@ -179,9 +179,9 @@ static inline void
> > fw_domain_wait_ack_clear(const struct intel_uncore_forcewake_domain *d)
> > {
> > if (wait_ack_clear(d, FORCEWAKE_KERNEL)) {
> > - drm_err(>uncore->i915->drm,
> > - "%s: timed out waiting for forcewake ack to clear.\n",
> > - intel_uncore_forcewake_domain_to_str(d->id));
> > + gt_err(d->uncore->gt,
> > + "%s: timed out waiting for forcewake ack to clear.\n",
> > + intel_uncore_forcewake_domain_to_str(d->id));
> > add_taint_for_CI(d->uncore->i915, TAINT_WARN); /* CI now
> > unreliable */
> > }
> > }
> > @@ -228,12 +228,11 @@ fw_domain_wait_ack_with_fallback(const struct
> > intel_uncore_forcewake_domain *d,
> > fw_clear(d, FORCEWAKE_KERNEL_FALLBACK);
> > } while (!ack_detected && pass++ < 10);
> > - drm_dbg(>uncore->i915->drm,
> > - "%s had to use fallback to %s ack, 0x%x (passes %u)\n",
> > - intel_uncore_forcewake_domain_to_str(d->id),
> > - type == ACK_SET ? "set" : "clear",
> > - fw_ack(d),
> > - pass);
> > + gt_dbg(d->uncore->gt, "%s had to use fallback to %s ack, 0x%x (passes
> > %u)\n",
> > + intel_uncore_forcewake_domain_to_str(d->id),
> > + type == ACK_SET ? "set" : "clear",
> > + fw_ack(d),
> > + pass);
> > return ack_detected ? 0 : -ETIMEDOUT;
> > }
> > @@ -258,9 +257,8 @@ static inline void
> > fw_domain_wait_ack_set(const struct intel_uncore_forcewake_domain *d)
> > {
> > if (wait_ack_set(d, FORCEWAKE_KERNEL)) {
> > - drm_err(>uncore->i915->drm,
> > - "%s: timed out waiting for forcewake ack request.\n",
> > - intel_uncore_forcewake_domain_to_str(d->id));
> > + gt_err(d->uncore->gt, "%s: timed out waiting for forcewake ack
> > request.\n",
> > + intel_uncore_forcewake_domain_to_str(d->id));
> > add_taint_for_CI(d->uncore->i915, TAINT_WARN); /* CI now
> > unreliable */
> > }
> > }
> > @@ -366,9 +364,9 @@ static void __gen6_gt_wait_for_thread_c0(struct
> > intel_uncore *uncore)
> > * w/a for a sporadic read returning 0 by waiting for the GT
> > * thread to wake up.
> > */
> > - drm_WARN_ONCE(>i915->drm,
> > -
[Intel-gfx] [PATCH 5/5] drm/i915: Mask page table errors on gen2/3 with FBC
From: Ville Syrjälä
FBC on gen2/3 seems to trigger page table errors. No visual
artifacts are visible, and essentially the same FBC
code works on gen4 so these seem entirely spurious. There
are also hints in gen3 bspec indicating that certain bits
in PGTBL_ER are just not wired up correctly in the
hardware.
Ideally we'd want to mask out only the bogus bits, but
sadly there is no mask for PGTBL_ER, and instead we are
forced to mask out all page table errors via EMR :(
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 081b79d00521..496f76bf42f3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3473,8 +3473,23 @@ static void i8xx_irq_reset(struct drm_i915_private
*dev_priv)
static u32 i9xx_error_mask(struct drm_i915_private *i915)
{
- return ~(I915_ERROR_PAGE_TABLE |
-I915_ERROR_MEMORY_REFRESH);
+ /*
+* On gen2/3 FBC generates (seemingly spurious)
+* display INVALID_GTT/INVALID_GTT_PTE table errors.
+*
+* Also gen3 bspec has this to say:
+* "DISPA_INVALID_GTT_PTE
+" [DevNapa] : Reserved. This bit does not reflect the page
+" table error for the display plane A."
+*
+* Unfortunately we can't mask off individual PGTBL_ER bits,
+* so we just have to mask off all page table errors via EMR.
+*/
+ if (HAS_FBC(i915))
+ return ~I915_ERROR_MEMORY_REFRESH;
+ else
+ return ~(I915_ERROR_PAGE_TABLE |
+I915_ERROR_MEMORY_REFRESH);
}
static void i8xx_irq_postinstall(struct drm_i915_private *dev_priv)
@@ -3762,6 +3777,9 @@ static u32 i965_error_mask(struct drm_i915_private *i915)
/*
* Enable some error detection, note the instruction error mask
* bit is reserved, so we leave it masked.
+*
+* i965 FBC no longer generates spurious GTT errors,
+* so we can always enable the page table errors.
*/
if (IS_G4X(i915))
return ~(GM45_ERROR_PAGE_TABLE |
--
2.39.1
[Intel-gfx] [PATCH 3/5] drm/i915: Dump PGTBL_ER on gen2/3/4 error interrupt
From: Ville Syrjälä PGTBL_ER contains the individual reasons for the page table error interrupt. Dump it out. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index b45d426a5bd5..0e90c348175e 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -3539,6 +3539,9 @@ static void i8xx_error_irq_handler(struct drm_i915_private *dev_priv, if (eir_stuck) drm_dbg(_priv->drm, "EIR stuck: 0x%04x, masked\n", eir_stuck); + + drm_dbg(_priv->drm, "PGTBL_ER: 0x%08x\n", + intel_uncore_read(_priv->uncore, PGTBL_ER)); } static void i9xx_error_irq_ack(struct drm_i915_private *dev_priv, @@ -3576,6 +3579,9 @@ static void i9xx_error_irq_handler(struct drm_i915_private *dev_priv, if (eir_stuck) drm_dbg(_priv->drm, "EIR stuck: 0x%08x, masked\n", eir_stuck); + + drm_dbg(_priv->drm, "PGTBL_ER: 0x%08x\n", + intel_uncore_read(_priv->uncore, PGTBL_ER)); } static irqreturn_t i8xx_irq_handler(int irq, void *arg) -- 2.39.1
[Intel-gfx] [PATCH 4/5] drm/i915: Extract {i9xx, i965)_error_mask()
From: Ville Syrjälä
Pull the EMR calculation into small helpers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++---
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0e90c348175e..081b79d00521 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3471,15 +3471,18 @@ static void i8xx_irq_reset(struct drm_i915_private
*dev_priv)
dev_priv->irq_mask = ~0u;
}
+static u32 i9xx_error_mask(struct drm_i915_private *i915)
+{
+ return ~(I915_ERROR_PAGE_TABLE |
+I915_ERROR_MEMORY_REFRESH);
+}
+
static void i8xx_irq_postinstall(struct drm_i915_private *dev_priv)
{
struct intel_uncore *uncore = _priv->uncore;
u16 enable_mask;
- intel_uncore_write16(uncore,
-EMR,
-~(I915_ERROR_PAGE_TABLE |
- I915_ERROR_MEMORY_REFRESH));
+ intel_uncore_write16(uncore, EMR, i9xx_error_mask(dev_priv));
/* Unmask the interrupts that we always want on. */
dev_priv->irq_mask =
@@ -3651,8 +3654,7 @@ static void i915_irq_postinstall(struct drm_i915_private
*dev_priv)
struct intel_uncore *uncore = _priv->uncore;
u32 enable_mask;
- intel_uncore_write(uncore, EMR, ~(I915_ERROR_PAGE_TABLE |
- I915_ERROR_MEMORY_REFRESH));
+ intel_uncore_write(uncore, EMR, i9xx_error_mask(dev_priv));
/* Unmask the interrupts that we always want on. */
dev_priv->irq_mask =
@@ -3755,26 +3757,28 @@ static void i965_irq_reset(struct drm_i915_private
*dev_priv)
dev_priv->irq_mask = ~0u;
}
-static void i965_irq_postinstall(struct drm_i915_private *dev_priv)
+static u32 i965_error_mask(struct drm_i915_private *i915)
{
- struct intel_uncore *uncore = _priv->uncore;
- u32 enable_mask;
- u32 error_mask;
-
/*
* Enable some error detection, note the instruction error mask
* bit is reserved, so we leave it masked.
*/
- if (IS_G4X(dev_priv)) {
- error_mask = ~(GM45_ERROR_PAGE_TABLE |
- GM45_ERROR_MEM_PRIV |
- GM45_ERROR_CP_PRIV |
- I915_ERROR_MEMORY_REFRESH);
- } else {
- error_mask = ~(I915_ERROR_PAGE_TABLE |
- I915_ERROR_MEMORY_REFRESH);
- }
- intel_uncore_write(uncore, EMR, error_mask);
+ if (IS_G4X(i915))
+ return ~(GM45_ERROR_PAGE_TABLE |
+GM45_ERROR_MEM_PRIV |
+GM45_ERROR_CP_PRIV |
+I915_ERROR_MEMORY_REFRESH);
+ else
+ return ~(I915_ERROR_PAGE_TABLE |
+I915_ERROR_MEMORY_REFRESH);
+}
+
+static void i965_irq_postinstall(struct drm_i915_private *dev_priv)
+{
+ struct intel_uncore *uncore = _priv->uncore;
+ u32 enable_mask;
+
+ intel_uncore_write(uncore, EMR, i965_error_mask(dev_priv));
/* Unmask the interrupts that we always want on. */
dev_priv->irq_mask =
--
2.39.1
[Intel-gfx] [PATCH 2/5] drm/i915: Undo rmw damage to gen3 error interrupt handler
From: Ville Syrjälä
The gen2/gen3 irq code is supposed to be identical apart
from the 32bit vs. 16bit access width. The recent change
to intel_de_rmw() ruined that symmetry. Restore it to avoid
needless mental gymnastics when comparing the two codepaths.
And while at it remove the extra eir!=0 check that somehow
ended up in the gen2 codepath only.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 240d5e198904..b45d426a5bd5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3510,9 +3510,7 @@ static void i8xx_error_irq_ack(struct drm_i915_private
*i915,
u16 emr;
*eir = intel_uncore_read16(uncore, EIR);
-
- if (*eir)
- intel_uncore_write16(uncore, EIR, *eir);
+ intel_uncore_write16(uncore, EIR, *eir);
*eir_stuck = intel_uncore_read16(uncore, EIR);
if (*eir_stuck == 0)
@@ -3548,7 +3546,8 @@ static void i9xx_error_irq_ack(struct drm_i915_private
*dev_priv,
{
u32 emr;
- *eir = intel_uncore_rmw(_priv->uncore, EIR, 0, 0);
+ *eir = intel_uncore_read(_priv->uncore, EIR);
+ intel_uncore_write(_priv->uncore, EIR, *eir);
*eir_stuck = intel_uncore_read(_priv->uncore, EIR);
if (*eir_stuck == 0)
@@ -3564,7 +3563,8 @@ static void i9xx_error_irq_ack(struct drm_i915_private
*dev_priv,
* (or by a GPU reset) so we mask any bit that
* remains set.
*/
- emr = intel_uncore_rmw(_priv->uncore, EMR, ~0, 0x);
+ emr = intel_uncore_read(_priv->uncore, EMR);
+ intel_uncore_write(_priv->uncore, EMR, 0x);
intel_uncore_write(_priv->uncore, EMR, emr | *eir_stuck);
}
--
2.39.1
[Intel-gfx] [PATCH 1/5] drm/i915: Mark FIFO underrun disabled earlier
From: Ville Syrjälä
At least on some platforms (tested on ctg) the way
vgacon does screen blanking seems to flag constant
FIFO underruns, which means we have to be prepared
for them while the driver is loading. Currently
there is a time window between drm_crtc_init() and
intel_sanitize_fifo_underrun_reporting() during
which FIFO underrun reporting is in fact marked as
enabled. Thus we may end up mistakenly detecting
these bogus underruns during driver init.
Close the race by marking FIFO underrun reporting
as disabled prior to even registering the crtc.
intel_sanitize_fifo_underrun_reporting()/etc. will
re-enable it later if needed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 3 +++
.../drm/i915/display/intel_fifo_underrun.c| 20
.../drm/i915/display/intel_fifo_underrun.h| 3 +++
.../drm/i915/display/intel_modeset_setup.c| 24 +--
4 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 82be0fbe9934..b79a8834559f 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -25,6 +25,7 @@
#include "intel_display_types.h"
#include "intel_drrs.h"
#include "intel_dsi.h"
+#include "intel_fifo_underrun.h"
#include "intel_pipe_crc.h"
#include "intel_psr.h"
#include "intel_sprite.h"
@@ -314,6 +315,8 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, enum
pipe pipe)
}
crtc->plane_ids_mask |= BIT(primary->id);
+ intel_init_fifo_underrun_reporting(dev_priv, crtc, false);
+
for_each_sprite(dev_priv, pipe, sprite) {
struct intel_plane *plane;
diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
index d636d21fa9ce..b708a62e509a 100644
--- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
@@ -31,6 +31,7 @@
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_fifo_underrun.h"
+#include "intel_pch_display.h"
/**
* DOC: fifo underrun handling
@@ -509,3 +510,22 @@ void intel_check_pch_fifo_underruns(struct
drm_i915_private *dev_priv)
spin_unlock_irq(_priv->irq_lock);
}
+
+void intel_init_fifo_underrun_reporting(struct drm_i915_private *i915,
+ struct intel_crtc *crtc,
+ bool enable)
+{
+ crtc->cpu_fifo_underrun_disabled = !enable;
+
+ /*
+* We track the PCH trancoder underrun reporting state
+* within the crtc. With crtc for pipe A housing the underrun
+* reporting state for PCH transcoder A, crtc for pipe B housing
+* it for PCH transcoder B, etc. LPT-H has only PCH transcoder A,
+* and marking underrun reporting as disabled for the non-existing
+* PCH transcoders B and C would prevent enabling the south
+* error interrupt (see cpt_can_enable_serr_int()).
+*/
+ if (intel_has_pch_trancoder(i915, crtc->pipe))
+ crtc->pch_fifo_underrun_disabled = !enable;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.h
b/drivers/gpu/drm/i915/display/intel_fifo_underrun.h
index 2e47d7d3c101..b00d8abebcf9 100644
--- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.h
+++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.h
@@ -9,8 +9,11 @@
#include
struct drm_i915_private;
+struct intel_crtc;
enum pipe;
+void intel_init_fifo_underrun_reporting(struct drm_i915_private *i915,
+ struct intel_crtc *crtc, bool enable);
bool intel_set_cpu_fifo_underrun_reporting(struct drm_i915_private *dev_priv,
enum pipe pipe, bool enable);
bool intel_set_pch_fifo_underrun_reporting(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index 52cdbd4fc2fa..be095327a9ba 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -21,6 +21,7 @@
#include "intel_display.h"
#include "intel_display_power.h"
#include "intel_display_types.h"
+#include "intel_fifo_underrun.h"
#include "intel_modeset_setup.h"
#include "intel_pch_display.h"
#include "intel_pm.h"
@@ -234,12 +235,9 @@ static void intel_sanitize_fifo_underrun_reporting(const
struct intel_crtc_state
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- if (!crtc_state->hw.active && !HAS_GMCH(i915))
- return;
-
/*
-* We start out with underrun reporting disabled to avoid races.
-* For correct bookkeeping mark this on active crtcs.
+* We start out with underrun reporting disabled
[Intel-gfx] [PATCH 0/5] drm/i915: Error/underrun interrupt fixes
From: Ville Syrjälä
Fix up some error interrupt/underrun reporting issues
on old platforms.
Ville Syrjälä (5):
drm/i915: Mark FIFO underrun disabled earlier
drm/i915: Undo rmw damage to gen3 error interrupt handler
drm/i915: Dump PGTBL_ER on gen2/3/4 error interrupt
drm/i915: Extract {i9xx,i965)_error_mask()
drm/i915: Mask page table errors on gen2/3 with FBC
drivers/gpu/drm/i915/display/intel_crtc.c | 3 +
.../drm/i915/display/intel_fifo_underrun.c| 20 +
.../drm/i915/display/intel_fifo_underrun.h| 3 +
.../drm/i915/display/intel_modeset_setup.c| 24 ++
drivers/gpu/drm/i915/i915_irq.c | 80 +--
5 files changed, 86 insertions(+), 44 deletions(-)
--
2.39.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl/selftests: Flush all tiles on test exit
== Series Details ==
Series: drm/i915/mtl/selftests: Flush all tiles on test exit
URL : https://patchwork.freedesktop.org/series/113312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113312v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/index.html
Participating hosts (38 -> 38)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113312v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adlm-1}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_113312v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][3] -> [SKIP][4] ([fdo#109271]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-blb-e6850/igt@fb...@write.html
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][5] -> [FAIL][6] ([i915#7229])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_module_load@load:
- fi-ctg-p8600: [PASS][7] -> [DMESG-WARN][8] ([i915#6020])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-ctg-p8600/igt@i915_module_l...@load.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-ctg-p8600/igt@i915_module_l...@load.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][9] -> [INCOMPLETE][10] ([i915#7911])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][11] -> [INCOMPLETE][12] ([i915#4983])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600: [PASS][13] -> [FAIL][14] ([fdo#103375])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][15] ([fdo#109271] / [i915#4312])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-9}:[FAIL][16] ([fdo#103375]) -> [PASS][17] +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-dp-3:
- {bat-dg2-9}:[FAIL][18] -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3:
- {bat-dg2-9}:[FAIL][20] ([fdo#103375] / [i915#7932]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113312v1/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Pass drm_i915_private as param to i915 funcs (rev3)
== Series Details ==
Series: drm/i915/display: Pass drm_i915_private as param to i915 funcs (rev3)
URL : https://patchwork.freedesktop.org/series/113083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113083v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/index.html
Participating hosts (38 -> 40)
--
Additional (2): fi-kbl-soraka fi-tgl-dsi
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113083v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@dmabuf@all-tests@dma_fence_chain:
- {fi-tgl-dsi}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-tgl-dsi/igt@dmabuf@all-tests@dma_fence_chain.html
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: NOTRUN -> [DMESG-FAIL][2] +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@runner@aborted:
- {fi-tgl-dsi}: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-tgl-dsi/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_113083v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][4] -> [SKIP][5] ([fdo#109271]) +4 similar
issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-blb-e6850/igt@fb...@write.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-blb-e6850/igt@fb...@write.html
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][9] ([i915#7156])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#5334] / [i915#7872])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-guc: NOTRUN -> [SKIP][12] ([i915#7828])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-rkl-guc/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600: [PASS][13] -> [FAIL][14] ([fdo#103375])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-9}:[FAIL][15] ([fdo#103375]) -> [PASS][16] +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][17] ([i915#4983]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113083v3/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-dp-3:
- {bat-dg2-9}:[FAIL][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12638/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-3.html
[20]:
[Intel-gfx] [PATCH v2.2] drm/i915: Add _PICK_EVEN_2RANGES()
It's a constant pattern in the driver to need to use 2 ranges of MMIOs based on port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged due to some reasons like: 1) It increases the code size since the array is declared in each call site 2) Developers need to be careful not to incur an out-of-bounds array access 3) Developers need to be careful that the indexes match the table. For that it may be that the table needs to contain holes, making (1) even worse. Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one to use depending on the index value. v2: Fix the address expansion in the example (Anusha) v3: Also rename macro to _PICK_EVEN_2RANGES() in the documentation and reword it to clarify what ranges are chosen based on the index (Jani) Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_reg_defs.h | 29 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h b/drivers/gpu/drm/i915/i915_reg_defs.h index be43580a6979..983c5aa3045b 100644 --- a/drivers/gpu/drm/i915/i915_reg_defs.h +++ b/drivers/gpu/drm/i915/i915_reg_defs.h @@ -119,6 +119,35 @@ */ #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) +/* + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets. + * @__c_index corresponds to the index in which the second range starts to be + * used. Using math interval notation, the first range is used for indexes [ 0, + * @__c_index), while the second range is used for [ @__c_index, ... ). Example: + * + * #define _FOO_A 0xf000 + * #define _FOO_B 0xf004 + * #define _FOO_C 0xf008 + * #define _SUPER_FOO_A0xa000 + * #define _SUPER_FOO_B0xa100 + * #define FOO(x) _MMIO(_PICK_EVEN_2RANGES(x, 3, \ + * _FOO_A, _FOO_B, \ + * _SUPER_FOO_A, _SUPER_FOO_B)) + * + * This expands to: + * 0: 0xf000, + * 1: 0xf004, + * 2: 0xf008, + * 3: 0xa000, + * 4: 0xa100, + * 5: 0xa200, + * ... + */ +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) \ + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + \ +((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : \ + _PICK_EVEN((__index) - (__c_index), __c, __d))) + /* * Given the arbitrary numbers in varargs, pick the 0-based __index'th number. * -- 2.39.0
Re: [Intel-gfx] [PATCH v4 2/7] drm/i915: Fix up locking around dumping requests lists
On 1/25/2023 10:12, Tvrtko Ursulin wrote:
On 25/01/2023 18:00, John Harrison wrote:
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span of the execlist state lock to only the execlist
specific code paths. In order to do that, also move the report of hold
count (which is an execlist only concept) from the top level dump
function to the lower level execlist specific function. Also, move the
execlist specific code into the execlist source file.
v2: Rename some functions and move to more appropriate files
(Daniele).
Continuing from yesterday where you pointed out 2/7 exists, after I
declared capitulation on 1/7.. I think this refactor makes sense and
definitely improves things a lot.
On the high level I am only unsure if the patch split could be
improved. There seem to be three separate things, correct me if I
missed something:
1) Locking fix in intel_guc_find_hung_context
This is the change already it's own patch - #1/7. Can't really split
that one up any further. Changing the internal GuC code requires
changing the external common code to match.
2) Ref counting change throughout
3) Locking refactor / helper consolidation
These two being the changes in this patch - #2/7, yes?
The problem is that the reference counting fixes can only be done
once the code has been refactored/reordered. And the refactor/reorder
can only be done if the reference counting is fixed. I guess there
would be some way to do the re-order first but it would require
making even more of a mess of the spinlock activity to keep it all
correct around that intermediate stage. So I don't think it would
noticeably simplify the patch.
(Or 2 and 3 swapped around, not sure.)
That IMO might be a bit easier to read because first patch wouldn't
have two logical changes in it. Maybe easier to backport too if it
comes to that?
I'm not seeing 'two logical changes' in the first patch. Patch #1
fixes the reference counting of finding the hung request. That
involves adding a reference count internally within the spinlock on
the GuC side and moving the external reference count to within the
spinlock on the execlist side and then doing a put in all cases. That
really is a single change. It can't be split without either a)
introducing a get/put mis-match bug or b) making the code really ugly
as an intermediate (while still leaving one or other side broken).
I was thinking this part is wholy standalone:
@@ -4820,6 +4821,8 @@ void intel_guc_find_hung_context(struct
intel_engine_cs *engine)
xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
+ bool found;
+
if (!kref_get_unless_zero(>ref))
continue;
@@ -4836,10 +4839,18 @@ void intel_guc_find_hung_context(struct
intel_engine_cs *engine)
goto next;
}
+ found = false;
+ spin_lock(>guc_state.lock);
list_for_each_entry(rq, >guc_state.requests, sched.link) {
if (i915_test_request_state(rq) != I915_REQUEST_ACTIVE)
continue;
+ found = true;
+ break;
+ }
+ spin_unlock(>guc_state.lock);
+
+ if (found) {
intel_engine_set_hung_context(engine, ce);
/* Can only cope with one hang at a time... */
@@ -4847,6 +4858,7 @@ void intel_guc_find_hung_context(struct
intel_engine_cs *engine)
xa_lock(>context_lookup);
goto done;
}
+
next:
intel_context_put(ce);
xa_lock(>context_lookup);
Am I missing something?
Doh.
Yes, I guess that part is stand alone. I was getting myself confused and
thinking that was part of moving a get inside the spinlock. But you are
right, that part is just about using the correct spinlock for that loop.
So yeah, I can split that chunk out to a separate patch. But that is
splitting patch #1 into #1a and #1b. It doesn't help with patch #2.
Which is the one I though you were complaining about being too complex.
Which it is :(. But I'm really not seeing anyway to simplify it given
how much of a mess the code is in.
John.
Regards,
Tvrtko
John.
On the low level it all looks fine to me - hopefully Daniele can do
a detailed pass.
Regards,
Tvrtko
P.S. Only that intel_context_find_active_request_get hurts my eyes,
and inflates the diff. I wouldn't rename it but if you guys insist
okay.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 74
+--
.../drm/i915/gt/intel_execlists_submission.c | 27 +++
Re: [Intel-gfx] [PATCH v4 2/7] drm/i915: Fix up locking around dumping requests lists
On 25/01/2023 18:00, John Harrison wrote:
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span of the execlist state lock to only the execlist
specific code paths. In order to do that, also move the report of hold
count (which is an execlist only concept) from the top level dump
function to the lower level execlist specific function. Also, move the
execlist specific code into the execlist source file.
v2: Rename some functions and move to more appropriate files (Daniele).
Continuing from yesterday where you pointed out 2/7 exists, after I
declared capitulation on 1/7.. I think this refactor makes sense and
definitely improves things a lot.
On the high level I am only unsure if the patch split could be
improved. There seem to be three separate things, correct me if I
missed something:
1) Locking fix in intel_guc_find_hung_context
This is the change already it's own patch - #1/7. Can't really split
that one up any further. Changing the internal GuC code requires
changing the external common code to match.
2) Ref counting change throughout
3) Locking refactor / helper consolidation
These two being the changes in this patch - #2/7, yes?
The problem is that the reference counting fixes can only be done once
the code has been refactored/reordered. And the refactor/reorder can
only be done if the reference counting is fixed. I guess there would be
some way to do the re-order first but it would require making even more
of a mess of the spinlock activity to keep it all correct around that
intermediate stage. So I don't think it would noticeably simplify the
patch.
(Or 2 and 3 swapped around, not sure.)
That IMO might be a bit easier to read because first patch wouldn't
have two logical changes in it. Maybe easier to backport too if it
comes to that?
I'm not seeing 'two logical changes' in the first patch. Patch #1 fixes
the reference counting of finding the hung request. That involves adding
a reference count internally within the spinlock on the GuC side and
moving the external reference count to within the spinlock on the
execlist side and then doing a put in all cases. That really is a single
change. It can't be split without either a) introducing a get/put
mis-match bug or b) making the code really ugly as an intermediate
(while still leaving one or other side broken).
I was thinking this part is wholy standalone:
@@ -4820,6 +4821,8 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
+ bool found;
+
if (!kref_get_unless_zero(>ref))
continue;
@@ -4836,10 +4839,18 @@ void intel_guc_find_hung_context(struct intel_engine_cs *engine)
goto next;
}
+ found = false;
+ spin_lock(>guc_state.lock);
list_for_each_entry(rq, >guc_state.requests, sched.link) {
if (i915_test_request_state(rq) != I915_REQUEST_ACTIVE)
continue;
+ found = true;
+ break;
+ }
+ spin_unlock(>guc_state.lock);
+
+ if (found) {
intel_engine_set_hung_context(engine, ce);
/* Can only cope with one hang at a time... */
@@ -4847,6 +4858,7 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
xa_lock(>context_lookup);
goto done;
}
+
next:
intel_context_put(ce);
xa_lock(>context_lookup);
Am I missing something?
Regards,
Tvrtko
John.
On the low level it all looks fine to me - hopefully Daniele can do a
detailed pass.
Regards,
Tvrtko
P.S. Only that intel_context_find_active_request_get hurts my eyes,
and inflates the diff. I wouldn't rename it but if you guys insist okay.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 74 +--
.../drm/i915/gt/intel_execlists_submission.c | 27 +++
.../drm/i915/gt/intel_execlists_submission.h | 4 +
drivers/gpu/drm/i915/i915_gpu_error.c | 26 +--
5 files changed, 73 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e24af5efee9c..b58c30ac8ef02 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -250,8 +250,8 @@ void intel_engine_dump_active_requests(struct
Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller
Hi, On 23/01/2023 15:42, Michal Koutný wrote: Hello Tvrtko. Interesting work. Thanks! On Thu, Jan 12, 2023 at 04:55:57PM +, Tvrtko Ursulin wrote: Because of the heterogenous hardware and driver DRM capabilities, soft limits are implemented as a loose co-operative (bi-directional) interface between the controller and DRM core. IIUC, this periodic scanning, calculating and applying could be partly implemented with userspace utilities. (As you write, these limits are best effort only, so it sounds to me such a total implementation is unnecessary.) I don't immediately see how you envisage the half-userspace implementation would look like in terms of what functionality/new APIs would be provided by the kernel? I think a better approach would be to avoid the async querying and instead require implementing explicit foo_charge_time(client, dur) API (similar to how other controllers achieve this). Your argument is the heterogenity of devices -- does it mean there are devices/drivers that can't implement such a synchronous charging? Problem there is to find a suitable point to charge at. If for a moment we limit the discussion to i915, out of the box we could having charging happening at several thousand times per second to effectively never. This is to illustrate the GPU context execution dynamics which range from many small packets of work to multi-minute, or longer. For the latter to be accounted for we'd still need some periodic scanning, which would then perhaps go per driver. For the former we'd have thousands of needless updates per second. Hence my thinking was to pay both the cost of accounting and collecting the usage data once per actionable event, where the latter is controlled by some reasonable scanning period/frequency. In addition to that, a few DRM drivers already support GPU usage querying via fdinfo, so that being externally triggered, it is next to trivial to wire all those DRM drivers into such common DRM cgroup controller framework. All that every driver needs to implement on top is the "over budget" callback. DRM core provides an API to query per process GPU utilization and 2nd API to receive notification from the cgroup controller when the group enters or exits the over budget condition. The return value of foo_charge_time() would substitute such a notification synchronously. (By extension all clients in an affected cgroup could be notified to achieve some broader actions.) Right, it is doable in theory, but as mention above some rate limit would have to be added. And the notification would still need to have unused budget propagation through the tree, so it wouldn't work to localize the action to the single cgroup (the one getting the charge). Individual DRM drivers which implement the interface are expected to act on this in the best-effort manner only. There are no guarantees that the soft limits will be respected. Back to original concern -- must all code reside in the kernel when it's essentially advisory resource control? * DRM core is required to track all DRM clients belonging to processes so it can answer when asked how much GPU time is a process using. [...] * Individual drivers need to implement two similar hooks, but which work for a single DRM client. Over budget callback and GPU utilisation query. This information is eventually aggregated for each process in a cgroup. (And the action is carried on a single client, not a process.) The per-process tracking seems like an additional indirection. Could be the clients associated directly with DRM cgroup? [1] I think you could be right here - with some deeper integration with the cgroup subsystem this could probably be done. It would require moving the list of drm clients into the cgroup css state itself. Let me try and sketch that out in the following weeks because it would be a nice simplification if it indeed worked out. Regards, Tvrtko Regards, Michal [1] I understand the sending a fd of a client is a regular operation, so I'm not sure how cross-cg migrations would have to be handled in any case.
Re: [Intel-gfx] [PATCH v7 3/6] mei: clean pending read with vtag on bus
Why are you top posting? On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote: > > Greg, ack on getting these 3 mei patches merged through intel-gfx? $ mdfrm -c ~/mail/todo/ 756 messages in /home/gregkh/mail/todo/ Give me a chance, what is the sudden rush? greg k-h
Re: [Intel-gfx] [PATCH v4 2/7] drm/i915: Fix up locking around dumping requests lists
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span of the execlist state lock to only the execlist
specific code paths. In order to do that, also move the report of hold
count (which is an execlist only concept) from the top level dump
function to the lower level execlist specific function. Also, move the
execlist specific code into the execlist source file.
v2: Rename some functions and move to more appropriate files (Daniele).
Continuing from yesterday where you pointed out 2/7 exists, after I
declared capitulation on 1/7.. I think this refactor makes sense and
definitely improves things a lot.
On the high level I am only unsure if the patch split could be
improved. There seem to be three separate things, correct me if I
missed something:
1) Locking fix in intel_guc_find_hung_context
This is the change already it's own patch - #1/7. Can't really split
that one up any further. Changing the internal GuC code requires
changing the external common code to match.
2) Ref counting change throughout
3) Locking refactor / helper consolidation
These two being the changes in this patch - #2/7, yes?
The problem is that the reference counting fixes can only be done once
the code has been refactored/reordered. And the refactor/reorder can
only be done if the reference counting is fixed. I guess there would be
some way to do the re-order first but it would require making even more
of a mess of the spinlock activity to keep it all correct around that
intermediate stage. So I don't think it would noticeably simplify the patch.
(Or 2 and 3 swapped around, not sure.)
That IMO might be a bit easier to read because first patch wouldn't
have two logical changes in it. Maybe easier to backport too if it
comes to that?
I'm not seeing 'two logical changes' in the first patch. Patch #1 fixes
the reference counting of finding the hung request. That involves adding
a reference count internally within the spinlock on the GuC side and
moving the external reference count to within the spinlock on the
execlist side and then doing a put in all cases. That really is a single
change. It can't be split without either a) introducing a get/put
mis-match bug or b) making the code really ugly as an intermediate
(while still leaving one or other side broken).
John.
On the low level it all looks fine to me - hopefully Daniele can do a
detailed pass.
Regards,
Tvrtko
P.S. Only that intel_context_find_active_request_get hurts my eyes,
and inflates the diff. I wouldn't rename it but if you guys insist okay.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 74 +--
.../drm/i915/gt/intel_execlists_submission.c | 27 +++
.../drm/i915/gt/intel_execlists_submission.h | 4 +
drivers/gpu/drm/i915/i915_gpu_error.c | 26 +--
5 files changed, 73 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e24af5efee9c..b58c30ac8ef02 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -250,8 +250,8 @@ void intel_engine_dump_active_requests(struct
list_head *requests,
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now);
-struct i915_request *
-intel_engine_execlist_find_hung_request(struct intel_engine_cs
*engine);
+void intel_engine_get_hung_entity(struct intel_engine_cs *engine,
+ struct intel_context **ce, struct i915_request **rq);
u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
struct intel_context *
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index fbc0a81617e89..1d77e27801bce 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2114,17 +2114,6 @@ static void print_request_ring(struct
drm_printer *m, struct i915_request *rq)
}
}
-static unsigned long list_count(struct list_head *list)
-{
- struct list_head *pos;
- unsigned long count = 0;
-
- list_for_each(pos, list)
- count++;
-
- return count;
-}
-
static unsigned long read_ul(void *p, size_t x)
{
return *(unsigned long *)(p + x);
@@ -2216,11 +2205,11 @@ void intel_engine_dump_active_requests(struct
list_head *requests,
}
}
-static void engine_dump_active_requests(struct intel_engine_cs
*engine, struct drm_printer *m)
+static void engine_dump_active_requests(struct intel_engine_cs *engine,
+
Re: [Intel-gfx] [PATCH v7 3/6] mei: clean pending read with vtag on bus
Greg, ack on getting these 3 mei patches merged through intel-gfx?
On Wed, Jan 25, 2023 at 12:26:34AM -0800, Alan Previn wrote:
> From: Alexander Usyskin
>
> Client on bus have only one vtag map slot and should disregard the vtag
> value when cleaning pending read flag.
> Fixes read flow control message unexpectedly generated when
> clent on bus send messages with different vtags.
>
> Signed-off-by: Alexander Usyskin
> Reviewed-by: Tomas Winkler
> Signed-off-by: Alan Previn
> ---
> drivers/misc/mei/client.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
> index 9ddb854b8155..5c19097266fe 100644
> --- a/drivers/misc/mei/client.c
> +++ b/drivers/misc/mei/client.c
> @@ -1343,7 +1343,9 @@ static void mei_cl_reset_read_by_vtag(const struct
> mei_cl *cl, u8 vtag)
> struct mei_cl_vtag *vtag_l;
>
> list_for_each_entry(vtag_l, >vtag_map, list) {
> - if (vtag_l->vtag == vtag) {
> + /* The client on bus has one fixed vtag map */
> + if ((cl->cldev && mei_cldev_enabled(cl->cldev)) ||
> + vtag_l->vtag == vtag) {
> vtag_l->pending_read = false;
> break;
> }
> --
> 2.39.0
>
Re: [Intel-gfx] [PATCH 2/2] drm/ttm: revert "stop allocating dummy resources during BO creation"
On Wed, 25 Jan 2023 at 16:15, Christian König wrote:
>
> Am 25.01.23 um 17:13 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 15:50, Christian König
> > wrote:
> >> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
> >>
> >> It seems to still breka i915.
> > We also need to revert the third patch:
> >
> > b49323aa35d5 drm/ttm: prevent moving of pinned BOs
> >
> > It introduces the side effect of no longer calling tt_create(true) in
> > ttm_bo_validate(), and I'm 99% sure that will break object clearing.
> > We rely on having a ttm_tt for the initial dummy placement, with
> > FLAG_ZERO_ALLOC set if clear is needed. Also I'm not sure who even
> > creates the ttm_tt now, if ttm_bo_validate() doesn't, and we don't
> > have the dummy move, like with this patch.
>
> Oh, yes of course. Can I add your Acked-by to reverting all three?
Yeah, feel free to add. I can then resend your series with the extra
stuff we need for i915.
>
> Thanks,
> Christian.
>
> >
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >> index 33471e363ff4..9baccb2f6e99 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >> @@ -957,6 +957,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
> >> struct ttm_buffer_object *bo,
> >> struct sg_table *sg, struct dma_resv *resv,
> >> void (*destroy) (struct ttm_buffer_object *))
> >> {
> >> + static const struct ttm_place sys_mem = { .mem_type =
> >> TTM_PL_SYSTEM };
> >> int ret;
> >>
> >> kref_init(>kref);
> >> @@ -973,6 +974,12 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
> >> struct ttm_buffer_object *bo,
> >> bo->base.resv = >base._resv;
> >> atomic_inc(_glob.bo_count);
> >>
> >> + ret = ttm_resource_alloc(bo, _mem, >resource);
> >> + if (unlikely(ret)) {
> >> + ttm_bo_put(bo);
> >> + return ret;
> >> + }
> >> +
> >> /*
> >> * For ttm_bo_type_device buffers, allocate
> >> * address space from the device.
> >> --
> >> 2.34.1
> >>
>
Re: [Intel-gfx] [PATCH 2/2] drm/ttm: revert "stop allocating dummy resources during BO creation"
Am 25.01.23 um 17:13 schrieb Matthew Auld:
On Wed, 25 Jan 2023 at 15:50, Christian König
wrote:
This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
It seems to still breka i915.
We also need to revert the third patch:
b49323aa35d5 drm/ttm: prevent moving of pinned BOs
It introduces the side effect of no longer calling tt_create(true) in
ttm_bo_validate(), and I'm 99% sure that will break object clearing.
We rely on having a ttm_tt for the initial dummy placement, with
FLAG_ZERO_ALLOC set if clear is needed. Also I'm not sure who even
creates the ttm_tt now, if ttm_bo_validate() doesn't, and we don't
have the dummy move, like with this patch.
Oh, yes of course. Can I add your Acked-by to reverting all three?
Thanks,
Christian.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 33471e363ff4..9baccb2f6e99 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -957,6 +957,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev, struct
ttm_buffer_object *bo,
struct sg_table *sg, struct dma_resv *resv,
void (*destroy) (struct ttm_buffer_object *))
{
+ static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
int ret;
kref_init(>kref);
@@ -973,6 +974,12 @@ int ttm_bo_init_reserved(struct ttm_device *bdev, struct
ttm_buffer_object *bo,
bo->base.resv = >base._resv;
atomic_inc(_glob.bo_count);
+ ret = ttm_resource_alloc(bo, _mem, >resource);
+ if (unlikely(ret)) {
+ ttm_bo_put(bo);
+ return ret;
+ }
+
/*
* For ttm_bo_type_device buffers, allocate
* address space from the device.
--
2.34.1
