Re: [Intel-gfx] [PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path
On Tue, Jul 07, 2020 at 10:12:11PM +0200, Daniel Vetter wrote:
> Like the helpers, nothing special. Well except not, because we the
> critical section extends until after hw_done(), since that's the last
> thing which could hold up a subsequent atomic commit. That means the
> wait_for_flip_done is included, but that's not a problem, we're
> allowed to call dma_fence_wait() from signalling critical sections.
> Even on our own fence (which this does), it's just a bit confusing.
> But in a way those last 2 function calls are already part of the fence
> signalling critical section for the next atomic commit.
>
> Reading this I'm wondering why komeda waits for flip_done() before
> calling hw_done(), which is a bit backwards (but hey hw can be
> special). Might be good to throw a comment in there that explains why,
> because the original commit that added this just doesn't.
Hi Daniel:
It's a typo, thank you for pointing this out, and I'll give a fix after
this series have been merged.
for this patch
Reviewed-by: James Qian Wang
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 1f6682032ca4..cc5b5915bc5e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -73,6 +73,7 @@ static struct drm_driver komeda_kms_driver = {
> static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
> {
> struct drm_device *dev = old_state->dev;
> + bool fence_cookie = dma_fence_begin_signalling();
>
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>
> @@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state
> *old_state)
>
> drm_atomic_helper_commit_hw_done(old_state);
>
> + dma_fence_end_signalling(fence_cookie);
> +
> drm_atomic_helper_cleanup_planes(dev, old_state);
> }
>
> --
> 2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/uc: Extract uc usage details into separate debugfs
== Series Details == Series: series starting with [1/2] drm/i915/uc: Extract uc usage details into separate debugfs URL : https://patchwork.freedesktop.org/series/79220/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8711_full -> Patchwork_18102_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18102_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18102_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18102_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html Known issues Here are the changes found in Patchwork_18102_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk4/igt@gem_exec_whis...@basic-fds-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-glk6/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][5] -> [WARN][6] ([i915#1519]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@kms_atomic_transition@plane-toggle-modeset-transition: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-snb1/igt@kms_atomic_transit...@plane-toggle-modeset-transition.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-snb2/igt@kms_atomic_transit...@plane-toggle-modeset-transition.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-apl2/igt@kms_big...@x-tiled-8bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-apl6/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl7/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-skl3/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-render.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_sprite_mmap_gtt: -
[Intel-gfx] ✗ Fi.CI.BAT: failure for Move some device capabilities under intel_gt (rev3)
== Series Details ==
Series: Move some device capabilities under intel_gt (rev3)
URL : https://patchwork.freedesktop.org/series/78829/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18103
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18103 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18103, 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_18103/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18103:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-y: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_18103 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][7] -> [DMESG-WARN][8] ([i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@kms_psr@cursor_plane_move:
- fi-tgl-y: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@kms_psr@cursor_plane_move.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-tgl-y/igt@kms_psr@cursor_plane_move.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][17] -> [DMESG-WARN][18] ([i915#402])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Possible fixes
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_force_connector_basic@force-connector-state:
- {fi-tgl-dsi}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18103/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
*
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-fence annotations, round 3 (rev2)
== Series Details == Series: dma-fence annotations, round 3 (rev2) URL : https://patchwork.freedesktop.org/series/79212/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8711_full -> Patchwork_18101_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18101_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18101_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18101_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html Known issues Here are the changes found in Patchwork_18101_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_endless@dispatch@rcs0: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#1958] / [i915#2119]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-tglb5/igt@gem_exec_endless@dispa...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-tglb3/igt@gem_exec_endless@dispa...@rcs0.html * igt@gem_exec_gttfill@all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk4/igt@gem_exec_gttf...@all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-glk2/igt@gem_exec_gttf...@all.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#1930]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-kbl4/igt@gem_soft...@noreloc-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-kbl7/igt@gem_soft...@noreloc-s3.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +56 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl6/igt@i915_module_l...@reload-with-fault-injection.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-skl7/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_selftest@live@execlists: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#750]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-tglb8/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-tglb1/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-sliding: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#62]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-256x85-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x85-sliding.html * igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk9/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-glk6/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html * igt@kms_flip@2x-flip-vs-panning-vs-hang@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][19] -> [INCOMPLETE][20] ([i915#58] / [k.org#198133]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk5/igt@kms_flip@2x-flip-vs-panning-vs-h...@ab-hdmi-a1-hdmi-a2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/shard-glk8/igt@kms_flip@2x-flip-vs-panning-vs-h...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@dpms-vs-vblank-race@a-dp1: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-kbl6/igt@kms_flip@dpms-vs-vblank-r...@a-dp1.html [22]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move some device capabilities under intel_gt (rev3)
== Series Details == Series: Move some device capabilities under intel_gt (rev3) URL : https://patchwork.freedesktop.org/series/78829/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Move some device capabilities under intel_gt (rev3)
== Series Details == Series: Move some device capabilities under intel_gt (rev3) URL : https://patchwork.freedesktop.org/series/78829/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7ed094988586 drm/i915: Convert device_info to uncore/de_read fdcbfbd417ae drm/i915: Use the gt in HAS_ENGINE 4f35f1ee2075 drm/i915: Move engine-related mmio init to engines_init_mmio d8ce0e15423d drm/i915: Move the engine mask to intel_gt_info 175320cb4eb3 drm/i915: Introduce gt_init_mmio 4ab8c86b1410 drm/i915/sseu: Move sseu detection and dump to intel_sseu -:285: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #285: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:311: +* across subslices. + */ -:294: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #294: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:320: +* more than one EU pair per subslice. + */ -:320: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #320: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:346: +* to each of the enabled slices. + */ -:328: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #328: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:354: +* count the total enabled EU. + */ -:370: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #370: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:396: +* distribution. + */ -:382: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #382: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:408: +* pair per subslice. + */ -:506: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment #506: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:532: + /* fall through */ -:526: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment #526: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:552: + /* fall through */ total: 0 errors, 8 warnings, 0 checks, 1259 lines checked 03320da3ca4c drm/i915/sseu: Move sseu_info under gt_info bfa82674d569 drm/i915: gt-fy sseu debugfs -:121: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #121: FILE: drivers/gpu/drm/i915/i915_debugfs.c:1698: + eu_reg[2*s] = intel_uncore_read(uncore, GEN9_SS01_EU_PGCTL_ACK(s)); ^ -:122: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #122: FILE: drivers/gpu/drm/i915/i915_debugfs.c:1699: + eu_reg[2*s + 1] = intel_uncore_read(uncore, GEN9_SS23_EU_PGCTL_ACK(s)); ^ total: 0 errors, 0 warnings, 2 checks, 188 lines checked 39f5aed2982f drm/i915: Move sseu debugfs under gt/ -:50: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #50: new file mode 100644 -:178: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #178: FILE: drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c:124: + eu_reg[2*s] = intel_uncore_read(uncore, GEN9_SS01_EU_PGCTL_ACK(s)); ^ -:179: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #179: FILE: drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c:125: + eu_reg[2*s + 1] = intel_uncore_read(uncore, GEN9_SS23_EU_PGCTL_ACK(s)); ^ -:216: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #216: FILE: drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c:162: + eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & ^ -:216: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #216: FILE: drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c:162: + eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & ^ -:217: CHECK:SPACING: spaces preferred around that '%' (ctx:VxV) #217: FILE: drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c:163: + eu_mask[ss%2]); ^ total: 0 errors, 1 warnings, 5 checks, 637 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Add new PCI ids (rev2)
== Series Details == Series: drm/i915/ehl: Add new PCI ids (rev2) URL : https://patchwork.freedesktop.org/series/78910/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8711_full -> Patchwork_18100_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18100_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18100_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18100_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html Known issues Here are the changes found in Patchwork_18100_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1930]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk4/igt@gem_exec_whis...@basic-fds-forked-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-glk4/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-apl8/igt@kms_big...@linear-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-apl7/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_big_fb@y-tiled-32bpp-rotate-180: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl8/igt@kms_big...@y-tiled-32bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-skl10/igt@kms_big...@y-tiled-32bpp-rotate-180.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-random: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-64x64-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-64x64-random.html * igt@kms_cursor_edge_walk@pipe-b-128x128-right-edge: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-glk7/igt@kms_cursor_edge_w...@pipe-b-128x128-right-edge.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-glk9/igt@kms_cursor_edge_w...@pipe-b-128x128-right-edge.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [PASS][17] -> [FAIL][18] ([IGT#5]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-skl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#49]) [21]:
Re: [Intel-gfx] [PATCH v7 5/5] drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
On Tue, 2020-06-16 at 20:31 -0700, Matt Roper wrote:
> After doing normal PHY-B initialization on Rocket Lake, we need to
> manually copy some additional PHY-A register values into PHY-B
> registers.
>
> Note that the bspec's combo phy page doesn't specify that this
> workaround is restricted to specific platform steppings (and doesn't
> even do a very good job of specifying that RKL is the only platform this
> is needed on), but the RKL workaround page lists this as relevant only
> for A and B steppings, so I'm trusting that information for now.
>
> v2: Make rkl_combo_phy_b_init_wa() static
>
> Bspec: 49291
> Bspec: 53273
> Signed-off-by: Matt Roper
> ---
> .../gpu/drm/i915/display/intel_combo_phy.c| 26 +++
> drivers/gpu/drm/i915/i915_reg.h | 13 +-
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 77b04bb3ec62..d5d95e2746c2 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -338,6 +338,27 @@ void intel_combo_phy_power_up_lanes(struct
> drm_i915_private *dev_priv,
> intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
> }
>
> +static void rkl_combo_phy_b_init_wa(struct drm_i915_private *i915)
> +{
> + u32 grccode, grccode_ldo;
> + u32 iref_rcal_ord, rcompcode_ld_cap_ov;
Nitpick: you could do all the bellow with just 2 u32(val and grccode).
> +
> + intel_de_wait_for_register(i915, ICL_PORT_COMP_DW3(PHY_A),
> +FIRST_COMP_DONE, FIRST_COMP_DONE, 100);
The timeout parameter here is in ms not usec
> +
> + grccode = REG_FIELD_GET(GRCCODE,
> + intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
> + iref_rcal_ord = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
> + intel_de_rmw(i915, ICL_PORT_COMP_DW2(PHY_B), IREF_RCAL_ORD,
> + iref_rcal_ord | IREF_RCAL_ORD_EN);
> +
> + grccode_ldo = REG_FIELD_GET(GRCCODE_LDO,
> + intel_de_read(i915,
> ICL_PORT_COMP_DW0(PHY_A)));
> + rcompcode_ld_cap_ov = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode_ldo);
> + intel_de_rmw(i915, ICL_PORT_COMP_DW6(PHY_B), RCOMPCODE_LD_CAP_OV,
> + rcompcode_ld_cap_ov | RCOMPCODEOVEN_LDO_SYNC);
> +}
> +
> static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> {
> enum phy phy;
> @@ -390,6 +411,11 @@ static void icl_combo_phys_init(struct drm_i915_private
> *dev_priv)
> val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
> val |= CL_POWER_DOWN_ENABLE;
> intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
> +
> + if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
> + phy == PHY_B)
> + /* Wa_14011224835:rkl[a0..c0] */
> + rkl_combo_phy_b_init_wa(dev_priv);
Missing the icl_combo_phy_verify_state() counter part.
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 34b2ec04ccd8..10f6e46523b6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1908,11 +1908,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>
> #define CNL_PORT_COMP_DW0_MMIO(0x162100)
> #define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy))
> -#define COMP_INIT (1 << 31)
> +#define COMP_INIT REG_BIT(31)
> +#define GRCCODE_LDOREG_GENMASK(7, 0)
>
> #define CNL_PORT_COMP_DW1_MMIO(0x162104)
> #define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy))
>
> +#define ICL_PORT_COMP_DW2(phy) _MMIO(_ICL_PORT_COMP_DW(2, phy))
> +#define IREF_RCAL_ORD_EN REG_BIT(7)
> +#define IREF_RCAL_ORD REG_GENMASK(6, 0)
> +
> #define CNL_PORT_COMP_DW3_MMIO(0x16210c)
> #define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy))
> #define PROCESS_INFO_DOT_0 (0 << 26)
> @@ -1925,6 +1930,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define VOLTAGE_INFO_1_05V (2 << 24)
> #define VOLTAGE_INFO_MASK (3 << 24)
> #define VOLTAGE_INFO_SHIFT 24
> +#define FIRST_COMP_DONEREG_BIT(22)
> +
> +#define ICL_PORT_COMP_DW6(phy) _MMIO(_ICL_PORT_COMP_DW(6, phy))
> +#define GRCCODEREG_GENMASK(30, 24)
> +#define RCOMPCODEOVEN_LDO_SYNC REG_BIT(23)
> +#define RCOMPCODE_LD_CAP_OVREG_GENMASK(22, 16)
>
Register definition matches.
> #define ICL_PORT_COMP_DW8(phy) _MMIO(_ICL_PORT_COMP_DW(8, phy))
> #define IREFGEN(1 << 24)
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH v7 5/5] drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
On Tue, 2020-06-16 at 20:31 -0700, Matt Roper wrote:
> After doing normal PHY-B initialization on Rocket Lake, we need to
> manually copy some additional PHY-A register values into PHY-B
> registers.
>
> Note that the bspec's combo phy page doesn't specify that this
> workaround is restricted to specific platform steppings (and doesn't
> even do a very good job of specifying that RKL is the only platform this
> is needed on), but the RKL workaround page lists this as relevant only
> for A and B steppings, so I'm trusting that information for now.
>
> v2: Make rkl_combo_phy_b_init_wa() static
>
> Bspec: 49291
> Bspec: 53273
> Signed-off-by: Matt Roper
> ---
> .../gpu/drm/i915/display/intel_combo_phy.c| 26 +++
> drivers/gpu/drm/i915/i915_reg.h | 13 +-
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 77b04bb3ec62..d5d95e2746c2 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -338,6 +338,27 @@ void intel_combo_phy_power_up_lanes(struct
> drm_i915_private *dev_priv,
> intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
> }
>
> +static void rkl_combo_phy_b_init_wa(struct drm_i915_private *i915)
> +{
> + u32 grccode, grccode_ldo;
> + u32 iref_rcal_ord, rcompcode_ld_cap_ov;
> +
> + intel_de_wait_for_register(i915, ICL_PORT_COMP_DW3(PHY_A),
> +FIRST_COMP_DONE, FIRST_COMP_DONE, 100);
> +
> + grccode = REG_FIELD_GET(GRCCODE,
> + intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
> + iref_rcal_ord = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
> + intel_de_rmw(i915, ICL_PORT_COMP_DW2(PHY_B), IREF_RCAL_ORD,
> + iref_rcal_ord | IREF_RCAL_ORD_EN);
> +
> + grccode_ldo = REG_FIELD_GET(GRCCODE_LDO,
> + intel_de_read(i915,
> ICL_PORT_COMP_DW0(PHY_A)));
> + rcompcode_ld_cap_ov = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode_ldo);
> + intel_de_rmw(i915, ICL_PORT_COMP_DW6(PHY_B), RCOMPCODE_LD_CAP_OV,
> + rcompcode_ld_cap_ov | RCOMPCODEOVEN_LDO_SYNC);
> +}
> +
> static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> {
> enum phy phy;
> @@ -390,6 +411,11 @@ static void icl_combo_phys_init(struct drm_i915_private
> *dev_priv)
> val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
> val |= CL_POWER_DOWN_ENABLE;
> intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
> +
> + if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
> + phy == PHY_B)
> + /* Wa_14011224835:rkl[a0..c0] */
> + rkl_combo_phy_b_init_wa(dev_priv);
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 34b2ec04ccd8..10f6e46523b6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1908,11 +1908,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>
> #define CNL_PORT_COMP_DW0_MMIO(0x162100)
> #define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy))
> -#define COMP_INIT (1 << 31)
> +#define COMP_INIT REG_BIT(31)
> +#define GRCCODE_LDOREG_GENMASK(7, 0)
>
> #define CNL_PORT_COMP_DW1_MMIO(0x162104)
> #define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy))
>
> +#define ICL_PORT_COMP_DW2(phy) _MMIO(_ICL_PORT_COMP_DW(2, phy))
> +#define IREF_RCAL_ORD_EN REG_BIT(7)
> +#define IREF_RCAL_ORD REG_GENMASK(6, 0)
> +
> #define CNL_PORT_COMP_DW3_MMIO(0x16210c)
> #define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy))
> #define PROCESS_INFO_DOT_0 (0 << 26)
> @@ -1925,6 +1930,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define VOLTAGE_INFO_1_05V (2 << 24)
> #define VOLTAGE_INFO_MASK (3 << 24)
> #define VOLTAGE_INFO_SHIFT 24
> +#define FIRST_COMP_DONEREG_BIT(22)
> +
> +#define ICL_PORT_COMP_DW6(phy) _MMIO(_ICL_PORT_COMP_DW(6, phy))
> +#define GRCCODEREG_GENMASK(30, 24)
> +#define RCOMPCODEOVEN_LDO_SYNC REG_BIT(23)
> +#define RCOMPCODE_LD_CAP_OVREG_GENMASK(22, 16)
>
> #define ICL_PORT_COMP_DW8(phy) _MMIO(_ICL_PORT_COMP_DW(8, phy))
> #define IREFGEN(1 << 24)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 4/5] drm/i915/rkl: Add initial workarounds
On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> RKL and TGL share some general gen12 workarounds, but each platform also
> has its own platform-specific workarounds.
>
> v2:
> - Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to
>TGL's, so we'll have both functions call the tgl_ function for now;
>this workaround isn't listed for DG1 so we don't want to add it to
>the general gen12_ function.
>
> Cc: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 5 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
> 2 files changed, 59 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 3cd461bf9131..63ac79f88fa2 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -2842,8 +2842,9 @@ static bool skl_plane_format_mod_supported(struct
> drm_plane *_plane,
> static bool gen12_plane_supports_mc_ccs(struct drm_i915_private *dev_priv,
> enum plane_id plane_id)
> {
> - /* Wa_14010477008:tgl[a0..c0] */
> - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> + /* Wa_14010477008:tgl[a0..c0],rkl[all] */
> + if (IS_ROCKETLAKE(dev_priv) ||
> + IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> return false;
>
> return plane_id < PLANE_SPRITE4;
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 2da366821dda..741710ca2b9a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -596,8 +596,8 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
> }
>
> -static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
> - struct i915_wa_list *wal)
> +static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine,
> +struct i915_wa_list *wal)
> {
> /*
>* Wa_1409142259:tgl
> @@ -607,12 +607,28 @@ static void tgl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
>* Wa_1409207793:tgl
>* Wa_1409178076:tgl
>* Wa_1408979724:tgl
> + * Wa_14010443199:rkl
> + * Wa_14010698770:rkl
>*/
> WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
> GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
>
> + /* WaDisableGPGPUMidThreadPreemption:gen12 */
> + WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> + GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> + GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
> +}
> +
> +static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
> + struct i915_wa_list *wal)
> +{
> + gen12_ctx_workarounds_init(engine, wal);
> +
> /*
> - * Wa_1604555607:gen12 and Wa_1608008084:gen12
> + * Wa_1604555607:tgl,rkl
> + *
> + * Note that the implementation of this workaround is further modified
> + * according to the FF_MODE2 guidance given by Wa_1608008084:gen12.
>* FF_MODE2 register will return the wrong value when read. The default
>* value for this register is zero for all fields and there are no bit
>* masks. So instead of doing a RMW we should just write the GS Timer
> @@ -623,11 +639,6 @@ static void tgl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> FF_MODE2_GS_TIMER_MASK | FF_MODE2_TDS_TIMER_MASK,
> FF_MODE2_GS_TIMER_224 | FF_MODE2_TDS_TIMER_128,
> 0);
> -
> - /* WaDisableGPGPUMidThreadPreemption:tgl */
> - WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> - GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> - GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
> }
>
> static void
> @@ -642,8 +653,10 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs
> *engine,
>
> wa_init_start(wal, name, engine->name);
>
> - if (IS_GEN(i915, 12))
> + if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915))
> tgl_ctx_workarounds_init(engine, wal);
> + else if (IS_GEN(i915, 12))
> + gen12_ctx_workarounds_init(engine, wal);
> else if (IS_GEN(i915, 11))
> icl_ctx_workarounds_init(engine, wal);
> else if (IS_CANNONLAKE(i915))
> @@ -1176,9 +1189,16 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> }
>
> static void
> -tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +gen12_gt_workarounds_init(struct drm_i915_private *i915,
> + struct i915_wa_list *wal)
> {
> wa_init_mcr(i915, wal);
> +}
> +
> +static void
> +tgl_gt_workarounds_init(struct
[Intel-gfx] [PATCH v3 4/9] drm/i915: Move the engine mask to intel_gt_info
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.
In preparation for other info being moved to the gt in follow up patches
(sseu), introduce an intel_gt_info structure to group all gt-related
runtime info.
v2: s/max_engine_mask/platform_engine_mask (tvrtko), fix selftest
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
Reviewed-by: Tvrtko Ursulin #v1
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +++---
drivers/gpu/drm/i915/gt/intel_gt.c| 6 +++
drivers/gpu/drm/i915/gt/intel_gt.h| 4 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 8
drivers/gpu/drm/i915/gt/intel_reset.c | 6 +--
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ++
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++
drivers/gpu/drm/i915/i915_pci.c | 42 +--
drivers/gpu/drm/i915/intel_device_info.c | 1 -
drivers/gpu/drm/i915/intel_device_info.h | 7 +---
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 3 +-
21 files changed, 84 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index dd15a799f9d6..6b4ec66cb558 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1980,8 +1980,7 @@ static int eb_submit(struct i915_execbuffer *eb, struct
i915_vma *batch)
static int num_vcs_engines(const struct drm_i915_private *i915)
{
- return hweight64(INTEL_INFO(i915)->engine_mask &
-GENMASK_ULL(VCS0 + I915_MAX_VCS - 1, VCS0));
+ return hweight64(VDBOX_MASK(>gt));
}
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 04114de15fe3..fca3c2348e5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -370,7 +370,7 @@ static void __setup_engine_capabilities(struct
intel_engine_cs *engine)
* instances.
*/
if ((INTEL_GEN(i915) >= 11 &&
-RUNTIME_INFO(i915)->vdbox_sfc_access & engine->mask) ||
+engine->gt->info.vdbox_sfc_access & engine->mask) ||
(INTEL_GEN(i915) >= 9 && engine->instance == 0))
engine->uabi_capabilities |=
I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC;
@@ -463,7 +463,7 @@ void intel_engines_free(struct intel_gt *gt)
static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- struct intel_device_info *info = mkwrite_device_info(i915);
+ struct intel_gt_info *info = >info;
struct intel_uncore *uncore = gt->uncore;
unsigned int logical_vdbox = 0;
unsigned int i;
@@ -471,6 +471,8 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
u16 vdbox_mask;
u16 vebox_mask;
+ info->engine_mask = INTEL_INFO(i915)->platform_engine_mask;
+
if (INTEL_GEN(i915) < 11)
return info->engine_mask;
@@ -498,7 +500,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
* In TGL each VDBOX has access to an SFC.
*/
if (INTEL_GEN(i915) >= 12 || logical_vdbox++ % 2 == 0)
- RUNTIME_INFO(i915)->vdbox_sfc_access |= BIT(i);
+ gt->info.vdbox_sfc_access |= BIT(i);
}
drm_dbg(>drm, "vdbox enable: %04x, instances: %04lx\n",
vdbox_mask, VDBOX_MASK(gt));
@@ -531,7 +533,6 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
int intel_engines_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- struct intel_device_info *device_info = mkwrite_device_info(i915);
const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
unsigned int i;
@@ -561,9 +562,9 @@ int intel_engines_init_mmio(struct intel_gt *gt)
* engines.
*/
if (drm_WARN_ON(>drm, mask != engine_mask))
- device_info->engine_mask = mask;
+
[Intel-gfx] [PATCH v3 5/9] drm/i915: Introduce gt_init_mmio
We already call 2 gt-related init_mmio functions in driver_mmio_probe
and a 3rd one will be added by a follow-up patch, so pre-emptively
introduce a gt_init_mmio function to group them.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
drivers/gpu/drm/i915/i915_drv.c| 4 +---
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6a268c6d6a6f..d96c34802e2b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -44,6 +44,13 @@ void intel_gt_init_hw_early(struct intel_gt *gt, struct
i915_ggtt *ggtt)
gt->ggtt = ggtt;
}
+int intel_gt_init_mmio(struct intel_gt *gt)
+{
+ intel_uc_init_mmio(>uc);
+
+ return intel_engines_init_mmio(gt);
+}
+
static void init_unused_ring(struct intel_gt *gt, u32 base)
{
struct intel_uncore *uncore = gt->uncore;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 908fc5dea885..9157c7411f60 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -36,6 +36,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
*huc)
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt);
+int intel_gt_init_mmio(struct intel_gt *gt);
int __must_check intel_gt_init_hw(struct intel_gt *gt);
int intel_gt_init(struct intel_gt *gt);
void intel_gt_driver_register(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 67789df42be8..5fd5af4bc855 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -531,9 +531,7 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
- intel_uc_init_mmio(_priv->gt.uc);
-
- ret = intel_engines_init_mmio(_priv->gt);
+ ret = intel_gt_init_mmio(_priv->gt);
if (ret)
goto err_uncore;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/5] drm/i915/rkl: Handle HTI
On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> If HTI (also sometimes called HDPORT) is enabled at startup, it may be
> using some of the PHYs and DPLLs making them unavailable for general
> usage. Let's read out the HDPORT_STATE register and avoid making use of
> resources that HTI is already using.
>
> v2:
> - Fix minor checkpatch warnings
>
> Bspec: 49189
> Bspec: 53707
> Cc: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 30 ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 21 +
> drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 3 ++
> drivers/gpu/drm/i915/i915_reg.h | 6
> 5 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6c2bb3354b86..f16512eddc58 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -46,6 +46,7 @@
> #include "display/intel_ddi.h"
> #include "display/intel_dp.h"
> #include "display/intel_dp_mst.h"
> +#include "display/intel_dpll_mgr.h"
> #include "display/intel_dsi.h"
> #include "display/intel_dvo.h"
> #include "display/intel_gmbus.h"
> @@ -16814,6 +16815,13 @@ static void intel_pps_init(struct drm_i915_private
> *dev_priv)
> intel_pps_unlock_regs_wa(dev_priv);
> }
>
> +static bool hti_uses_phy(u32 hdport_state, enum phy phy)
> +{
> + return hdport_state & HDPORT_ENABLED &&
> + (hdport_state & HDPORT_PHY_USED_DP(phy) ||
> + hdport_state & HDPORT_PHY_USED_HDMI(phy));
> +}
> +
> static void intel_setup_outputs(struct drm_i915_private *dev_priv)
> {
> struct intel_encoder *encoder;
> @@ -16825,10 +16833,22 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> return;
>
> if (IS_ROCKETLAKE(dev_priv)) {
> - intel_ddi_init(dev_priv, PORT_A);
> - intel_ddi_init(dev_priv, PORT_B);
> - intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
> - intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
> + /*
> + * If HTI (aka HDPORT) is enabled at boot, it may have taken
> + * over some of the PHYs and made them unavailable to the
> + * driver. In that case we should skip initializing the
> + * corresponding outputs.
> + */
> + u32 hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
> +
> + if (!hti_uses_phy(hdport_state, PHY_A))
> + intel_ddi_init(dev_priv, PORT_A);
> + if (!hti_uses_phy(hdport_state, PHY_B))
> + intel_ddi_init(dev_priv, PORT_B);
> + if (!hti_uses_phy(hdport_state, PHY_C))
> + intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
> + if (!hti_uses_phy(hdport_state, PHY_D))
> + intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
> } else if (INTEL_GEN(dev_priv) >= 12) {
> intel_ddi_init(dev_priv, PORT_A);
> intel_ddi_init(dev_priv, PORT_B);
> @@ -18376,6 +18396,8 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
>
> intel_dpll_readout_hw_state(dev_priv);
>
> + dev_priv->hti_pll_mask = intel_get_hti_plls(dev_priv);
Why not do this in intel_shared_dpll_init()?
> +
> for_each_intel_encoder(dev, encoder) {
> pipe = 0;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index b5f4d4cef682..6f59f9ec453b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -265,6 +265,24 @@ void intel_disable_shared_dpll(const struct
> intel_crtc_state *crtc_state)
> mutex_unlock(_priv->dpll.lock);
> }
>
> +/*
> + * HTI (aka HDPORT) may be using some of the platform's PLL's, making them
> + * unavailable for use.
> + */
> +u32 intel_get_hti_plls(struct drm_i915_private *dev_priv)
No need to export this function, check above.
> +{
> + u32 hdport_state;
> +
> + if (!IS_ROCKETLAKE(dev_priv))
> + return 0;
> +
> + hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
> + if (!(hdport_state & HDPORT_ENABLED))
> + return 0;
> +
> + return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, hdport_state);
> +}
> +
> static struct intel_shared_dpll *
> intel_find_shared_dpll(struct intel_atomic_state *state,
> const struct intel_crtc *crtc,
> @@ -280,6 +298,9 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
>
> drm_WARN_ON(_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
>
> + /* Eliminate DPLLs from consideration if reserved by HTI */
> + dpll_mask &= ~dev_priv->hti_pll_mask;
[Intel-gfx] [PATCH v3 8/9] drm/i915: gt-fy sseu debugfs
Ahead of moving the sseu debugfs logic under gt/, update the functions
to use intel_gt where possible to make the move cleaner.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/i915_debugfs.c | 93 +++--
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 69acc6990a66..5ba9f1c03eb0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1578,31 +1578,31 @@ i915_cache_sharing_set(void *data, u64 val)
return 0;
}
-static void
-intel_sseu_copy_subslices(const struct sseu_dev_info *sseu, int slice,
- u8 *to_mask)
+DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
+ i915_cache_sharing_get, i915_cache_sharing_set,
+ "%llu\n");
+
+static void sseu_copy_subslices(const struct sseu_dev_info *sseu,
+ int slice, u8 *to_mask)
{
int offset = slice * sseu->ss_stride;
memcpy(_mask[offset], >subslice_mask[offset], sseu->ss_stride);
}
-DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
- i915_cache_sharing_get, i915_cache_sharing_set,
- "%llu\n");
-
-static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv,
+static void cherryview_sseu_device_status(struct intel_gt *gt,
struct sseu_dev_info *sseu)
{
#define SS_MAX 2
+ struct intel_uncore *uncore = gt->uncore;
const int ss_max = SS_MAX;
u32 sig1[SS_MAX], sig2[SS_MAX];
int ss;
- sig1[0] = I915_READ(CHV_POWER_SS0_SIG1);
- sig1[1] = I915_READ(CHV_POWER_SS1_SIG1);
- sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
- sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
+ sig1[0] = intel_uncore_read(uncore, CHV_POWER_SS0_SIG1);
+ sig1[1] = intel_uncore_read(uncore, CHV_POWER_SS1_SIG1);
+ sig2[0] = intel_uncore_read(uncore, CHV_POWER_SS0_SIG2);
+ sig2[1] = intel_uncore_read(uncore, CHV_POWER_SS1_SIG2);
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -1624,11 +1624,12 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
#undef SS_MAX
}
-static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
+static void gen10_sseu_device_status(struct intel_gt *gt,
struct sseu_dev_info *sseu)
{
#define SS_MAX 6
- const struct intel_gt_info *info = _priv->gt.info;
+ struct intel_uncore *uncore = gt->uncore;
+ const struct intel_gt_info *info = >info;
u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
int s, ss;
@@ -1639,10 +1640,12 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
* although this seems wrong because it would leave many
* subslices without ACK.
*/
- s_reg[s] = I915_READ(GEN10_SLICE_PGCTL_ACK(s)) &
+ s_reg[s] = intel_uncore_read(uncore, GEN10_SLICE_PGCTL_ACK(s)) &
GEN10_PGCTL_VALID_SS_MASK(s);
- eu_reg[2 * s] = I915_READ(GEN10_SS01_EU_PGCTL_ACK(s));
- eu_reg[2 * s + 1] = I915_READ(GEN10_SS23_EU_PGCTL_ACK(s));
+ eu_reg[2 * s] = intel_uncore_read(uncore,
+ GEN10_SS01_EU_PGCTL_ACK(s));
+ eu_reg[2 * s + 1] = intel_uncore_read(uncore,
+
GEN10_SS23_EU_PGCTL_ACK(s));
}
eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
@@ -1660,7 +1663,7 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
continue;
sseu->slice_mask |= BIT(s);
- intel_sseu_copy_subslices(>sseu, s, sseu->subslice_mask);
+ sseu_copy_subslices(>sseu, s, sseu->subslice_mask);
for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
@@ -1681,18 +1684,19 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
#undef SS_MAX
}
-static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
+static void gen9_sseu_device_status(struct intel_gt *gt,
struct sseu_dev_info *sseu)
{
#define SS_MAX 3
- const struct intel_gt_info *info = _priv->gt.info;
+ struct intel_uncore *uncore = gt->uncore;
+ const struct intel_gt_info *info = >info;
u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
int s, ss;
for (s = 0; s < info->sseu.max_slices; s++) {
- s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
- eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
- eu_reg[2*s + 1] =
[Intel-gfx] [PATCH v3 3/9] drm/i915: Move engine-related mmio init to engines_init_mmio
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
v2: clarify comment about forcewake requirements and pruning (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
Reviewed-by: Tvrtko Ursulin #v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 76 ++-
drivers/gpu/drm/i915/i915_drv.c | 4 --
drivers/gpu/drm/i915/intel_device_info.c | 66
drivers/gpu/drm/i915/intel_device_info.h | 2 -
4 files changed, 75 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index be92d1ef9aa9..04114de15fe3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -450,6 +450,78 @@ void intel_engines_free(struct intel_gt *gt)
}
}
+/*
+ * Determine which engines are fused off in our particular hardware.
+ * Note that we have a catch-22 situation where we need to be able to access
+ * the blitter forcewake domain to read the engine fuses, but at the same time
+ * we need to know which engines are available on the system to know which
+ * forcewake domains are present. We solve this by intializing the forcewake
+ * domains based on the full engine mask in the platform capabilities before
+ * calling this function and pruning the domains for fused-off engines
+ * afterwards.
+ */
+static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_device_info *info = mkwrite_device_info(i915);
+ struct intel_uncore *uncore = gt->uncore;
+ unsigned int logical_vdbox = 0;
+ unsigned int i;
+ u32 media_fuse;
+ u16 vdbox_mask;
+ u16 vebox_mask;
+
+ if (INTEL_GEN(i915) < 11)
+ return info->engine_mask;
+
+ media_fuse = ~intel_uncore_read(uncore, GEN11_GT_VEBOX_VDBOX_DISABLE);
+
+ vdbox_mask = media_fuse & GEN11_GT_VDBOX_DISABLE_MASK;
+ vebox_mask = (media_fuse & GEN11_GT_VEBOX_DISABLE_MASK) >>
+ GEN11_GT_VEBOX_DISABLE_SHIFT;
+
+ for (i = 0; i < I915_MAX_VCS; i++) {
+ if (!HAS_ENGINE(gt, _VCS(i))) {
+ vdbox_mask &= ~BIT(i);
+ continue;
+ }
+
+ if (!(BIT(i) & vdbox_mask)) {
+ info->engine_mask &= ~BIT(_VCS(i));
+ drm_dbg(>drm, "vcs%u fused off\n", i);
+ continue;
+ }
+
+ /*
+* In Gen11, only even numbered logical VDBOXes are
+* hooked up to an SFC (Scaler & Format Converter) unit.
+* In TGL each VDBOX has access to an SFC.
+*/
+ if (INTEL_GEN(i915) >= 12 || logical_vdbox++ % 2 == 0)
+ RUNTIME_INFO(i915)->vdbox_sfc_access |= BIT(i);
+ }
+ drm_dbg(>drm, "vdbox enable: %04x, instances: %04lx\n",
+ vdbox_mask, VDBOX_MASK(gt));
+ GEM_BUG_ON(vdbox_mask != VDBOX_MASK(gt));
+
+ for (i = 0; i < I915_MAX_VECS; i++) {
+ if (!HAS_ENGINE(gt, _VECS(i))) {
+ vebox_mask &= ~BIT(i);
+ continue;
+ }
+
+ if (!(BIT(i) & vebox_mask)) {
+ info->engine_mask &= ~BIT(_VECS(i));
+ drm_dbg(>drm, "vecs%u fused off\n", i);
+ }
+ }
+ drm_dbg(>drm, "vebox enable: %04x, instances: %04lx\n",
+ vebox_mask, VEBOX_MASK(gt));
+ GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
+
+ return info->engine_mask;
+}
+
/**
* intel_engines_init_mmio() - allocate and prepare the Engine Command
Streamers
* @gt: pointer to struct intel_gt
@@ -460,7 +532,7 @@ int intel_engines_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
struct intel_device_info *device_info = mkwrite_device_info(i915);
- const unsigned int engine_mask = INTEL_INFO(i915)->engine_mask;
+ const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
unsigned int i;
int err;
@@ -497,6 +569,8 @@ int intel_engines_init_mmio(struct intel_gt *gt)
intel_setup_engine_capabilities(gt);
+ intel_uncore_prune_engine_fw_domains(gt->uncore, gt);
+
return 0;
cleanup:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1f9c40cf10ae..611287353420 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -531,10 +531,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
-
[Intel-gfx] [PATCH v3 0/9] Move some device capabilities under intel_gt
Rebased to the latest tip. Cc: Tvrtko Ursulin Cc: Andi Shyti Cc: Venkata Sandeep Dhanalakota Daniele Ceraolo Spurio (8): drm/i915: Convert device_info to uncore/de_read drm/i915: Use the gt in HAS_ENGINE drm/i915: Move engine-related mmio init to engines_init_mmio drm/i915: Move the engine mask to intel_gt_info drm/i915: Introduce gt_init_mmio drm/i915/sseu: Move sseu detection and dump to intel_sseu drm/i915: gt-fy sseu debugfs drm/i915: Move sseu debugfs under gt/ Venkata Sandeep Dhanalakota (1): drm/i915/sseu: Move sseu_info under gt_info drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +- .../drm/i915/gem/selftests/i915_gem_context.c | 5 +- drivers/gpu/drm/i915/gt/debugfs_gt.c | 2 + drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 91 ++- drivers/gpu/drm/i915/gt/intel_gt.c| 16 + drivers/gpu/drm/i915/gt/intel_gt.h| 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt_types.h | 11 + drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c | 6 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_rps.c | 3 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 592 +++- drivers/gpu/drm/i915/gt/intel_sseu.h | 10 +- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 303 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.h | 17 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 10 +- drivers/gpu/drm/i915/gvt/handlers.c | 4 +- drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 268 +-- drivers/gpu/drm/i915/i915_drv.c | 9 +- drivers/gpu/drm/i915/i915_drv.h | 17 +- drivers/gpu/drm/i915/i915_getparam.c | 2 +- drivers/gpu/drm/i915/i915_gpu_error.c | 25 +- drivers/gpu/drm/i915/i915_gpu_error.h | 3 + drivers/gpu/drm/i915/i915_pci.c | 42 +- drivers/gpu/drm/i915/i915_perf.c | 9 +- drivers/gpu/drm/i915/i915_query.c | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 652 +- drivers/gpu/drm/i915/intel_device_info.h | 14 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 16 +- drivers/gpu/drm/i915/intel_uncore.h | 4 +- drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- .../gpu/drm/i915/selftests/mock_gem_device.c | 3 +- 42 files changed, 1161 insertions(+), 1025 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c create mode 100644 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.h -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 6/9] drm/i915/sseu: Move sseu detection and dump to intel_sseu
Keep all the SSEU code in the relevant file. The code has also been
updated to use intel_gt instead of dev_priv.
Based on an original patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 587 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 8 +
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c| 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 584 +-
drivers/gpu/drm/i915/intel_device_info.h | 2 -
7 files changed, 600 insertions(+), 586 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d96c34802e2b..2c20fe693714 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -47,6 +47,7 @@ void intel_gt_init_hw_early(struct intel_gt *gt, struct
i915_ggtt *ggtt)
int intel_gt_init_mmio(struct intel_gt *gt)
{
intel_uc_init_mmio(>uc);
+ intel_sseu_info_init(gt);
return intel_engines_init_mmio(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index d173271c7397..006f9118b319 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -60,6 +60,548 @@ intel_sseu_subslices_per_slice(const struct sseu_dev_info
*sseu, u8 slice)
return hweight32(intel_sseu_get_subslices(sseu, slice));
}
+static int sseu_eu_idx(const struct sseu_dev_info *sseu, int slice,
+ int subslice)
+{
+ int slice_stride = sseu->max_subslices * sseu->eu_stride;
+
+ return slice * slice_stride + subslice * sseu->eu_stride;
+}
+
+static u16 sseu_get_eus(const struct sseu_dev_info *sseu, int slice,
+ int subslice)
+{
+ int i, offset = sseu_eu_idx(sseu, slice, subslice);
+ u16 eu_mask = 0;
+
+ for (i = 0; i < sseu->eu_stride; i++) {
+ eu_mask |= ((u16)sseu->eu_mask[offset + i]) <<
+ (i * BITS_PER_BYTE);
+ }
+
+ return eu_mask;
+}
+
+static void sseu_set_eus(struct sseu_dev_info *sseu, int slice, int subslice,
+u16 eu_mask)
+{
+ int i, offset = sseu_eu_idx(sseu, slice, subslice);
+
+ for (i = 0; i < sseu->eu_stride; i++) {
+ sseu->eu_mask[offset + i] =
+ (eu_mask >> (BITS_PER_BYTE * i)) & 0xff;
+ }
+}
+
+static u16 compute_eu_total(const struct sseu_dev_info *sseu)
+{
+ u16 i, total = 0;
+
+ for (i = 0; i < ARRAY_SIZE(sseu->eu_mask); i++)
+ total += hweight8(sseu->eu_mask[i]);
+
+ return total;
+}
+
+static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
+ u8 s_en, u32 ss_en, u16 eu_en)
+{
+ int s, ss;
+
+ /* ss_en represents entire subslice mask across all slices */
+ GEM_BUG_ON(sseu->max_slices * sseu->max_subslices >
+ sizeof(ss_en) * BITS_PER_BYTE);
+
+ for (s = 0; s < sseu->max_slices; s++) {
+ if ((s_en & BIT(s)) == 0)
+ continue;
+
+ sseu->slice_mask |= BIT(s);
+
+ intel_sseu_set_subslices(sseu, s, ss_en);
+
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (intel_sseu_has_subslice(sseu, s, ss))
+ sseu_set_eus(sseu, s, ss, eu_en);
+ }
+ sseu->eu_per_subslice = hweight16(eu_en);
+ sseu->eu_total = compute_eu_total(sseu);
+}
+
+static void gen12_sseu_info_init(struct intel_gt *gt)
+{
+ struct sseu_dev_info *sseu = _INFO(gt->i915)->sseu;
+ struct intel_uncore *uncore = gt->uncore;
+ u8 s_en;
+ u32 dss_en;
+ u16 eu_en = 0;
+ u8 eu_en_fuse;
+ int eu;
+
+ /*
+* Gen12 has Dual-Subslices, which behave similarly to 2 gen11 SS.
+* Instead of splitting these, provide userspace with an array
+* of DSS to more closely represent the hardware resource.
+*/
+ intel_sseu_set_info(sseu, 1, 6, 16);
+
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
+
+ dss_en = intel_uncore_read(uncore, GEN12_GT_DSS_ENABLE);
+
+ /* one bit per pair of EUs */
+ eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
+ for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
+ if (eu_en_fuse & BIT(eu))
+ eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
+
+ gen11_compute_sseu_info(sseu, s_en, dss_en, eu_en);
+
+ /* TGL only supports slice-level power gating */
+ sseu->has_slice_pg = 1;
+}
+
+static void gen11_sseu_info_init(struct intel_gt *gt)
+{
+ struct sseu_dev_info *sseu =
[Intel-gfx] [PATCH v3 2/9] drm/i915: Use the gt in HAS_ENGINE
A follow up patch will move the engine mask under the gt structure,
so get ready for that.
v2: switch the remaining gvt case using dev_priv->gt to gvt->gt (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
Reviewed-by: Tvrtko Ursulin #v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 ---
drivers/gpu/drm/i915/gvt/handlers.c| 2 +-
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
drivers/gpu/drm/i915/gvt/mmio_context.c| 2 +-
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 15 ---
drivers/gpu/drm/i915/intel_device_info.c | 13 +++--
drivers/gpu/drm/i915/intel_pm.c| 2 +-
drivers/gpu/drm/i915/intel_uncore.c| 16 +---
drivers/gpu/drm/i915/intel_uncore.h| 4 +++-
12 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7bf2f76212f0..be92d1ef9aa9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -473,7 +473,7 @@ int intel_engines_init_mmio(struct intel_gt *gt)
return -ENODEV;
for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
- if (!HAS_ENGINE(i915, i))
+ if (!HAS_ENGINE(gt, i))
continue;
err = intel_engine_setup(gt, i);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0cc7dd54f4f9..e1964cf40fd6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -457,7 +457,7 @@ void gen5_gt_irq_postinstall(struct intel_gt *gt)
* RPS interrupts will get enabled/disabled on demand when RPS
* itself is enabled/disabled.
*/
- if (HAS_ENGINE(gt->i915, VECS0)) {
+ if (HAS_ENGINE(gt, VECS0)) {
pm_irqs |= PM_VEBOX_USER_INTERRUPT;
gt->pm_ier |= PM_VEBOX_USER_INTERRUPT;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 101728006ae9..fbdd6b0677db 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -67,7 +67,8 @@ struct __guc_ads_blob {
static void __guc_ads_init(struct intel_guc *guc)
{
- struct drm_i915_private *dev_priv = guc_to_gt(guc)->i915;
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct drm_i915_private *dev_priv = gt->i915;
struct __guc_ads_blob *blob = guc->ads_blob;
const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
@@ -103,8 +104,8 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->system_info.rcs_enabled = 1;
blob->system_info.bcs_enabled = 1;
- blob->system_info.vdbox_enable_mask = VDBOX_MASK(dev_priv);
- blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv);
+ blob->system_info.vdbox_enable_mask = VDBOX_MASK(gt);
+ blob->system_info.vebox_enable_mask = VEBOX_MASK(gt);
blob->system_info.vdbox_sfc_support_mask =
RUNTIME_INFO(dev_priv)->vdbox_sfc_access;
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 78ba2857144e..85e44c6c47a6 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1868,7 +1868,7 @@ static int csfe_chicken1_mmio_write(struct intel_vgpu
*vgpu,
MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \
MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \
MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \
- if (HAS_ENGINE(dev_priv, VCS1)) \
+ if (HAS_ENGINE(gvt->gt, VCS1)) \
MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, f, am, rm, d, r, w); \
} while (0)
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
b/drivers/gpu/drm/i915/gvt/interrupt.c
index 540017fed908..7498878e6289 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.c
+++ b/drivers/gpu/drm/i915/gvt/interrupt.c
@@ -540,7 +540,7 @@ static void gen8_init_irq(
SET_BIT_INFO(irq, 4, VCS_MI_FLUSH_DW, INTEL_GVT_IRQ_INFO_GT1);
SET_BIT_INFO(irq, 8, VCS_AS_CONTEXT_SWITCH, INTEL_GVT_IRQ_INFO_GT1);
- if (HAS_ENGINE(gvt->gt->i915, VCS1)) {
+ if (HAS_ENGINE(gvt->gt, VCS1)) {
SET_BIT_INFO(irq, 16, VCS2_MI_USER_INTERRUPT,
INTEL_GVT_IRQ_INFO_GT1);
SET_BIT_INFO(irq, 20, VCS2_MI_FLUSH_DW,
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index 2ccaf78f96e8..86a60bdf0818 100644
---
[Intel-gfx] [PATCH v3 7/9] drm/i915/sseu: Move sseu_info under gt_info
From: Venkata Sandeep Dhanalakota
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 ---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 5 -
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_gt.c| 2 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_sseu.c | 19 ++-
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 3 +--
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
drivers/gpu/drm/i915/i915_perf.c | 9 -
drivers/gpu/drm/i915/i915_query.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 3 ---
drivers/gpu/drm/i915/intel_device_info.h | 3 ---
20 files changed, 49 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 41784df51e58..d0bdb6d447ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1400,11 +1400,12 @@ static int get_ringsize(struct i915_gem_context *ctx,
}
int
-i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu
*user,
struct intel_sseu *context)
{
- const struct sseu_dev_info *device = _INFO(i915)->sseu;
+ const struct sseu_dev_info *device = >info.sseu;
+ struct drm_i915_private *i915 = gt->i915;
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1537,7 +1538,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = i915_gem_user_to_context_sseu(i915, _sseu, );
+ ret = i915_gem_user_to_context_sseu(ce->engine->gt, _sseu, );
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 3702b2fb27ab..a133f92bbedb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -225,7 +225,7 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
-int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+int i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu
*user,
struct intel_sseu *context);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b81978890641..7ffc3c751432 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1229,7 +1229,7 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
int inst = 0;
int ret = 0;
- if (INTEL_GEN(i915) < 9 || !RUNTIME_INFO(i915)->sseu.has_slice_pg)
+ if (INTEL_GEN(i915) < 9)
return 0;
if (flags & TEST_RESET)
@@ -1255,6 +1255,9 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
if (hweight32(engine->sseu.slice_mask) < 2)
continue;
+ if (!engine->gt->info.sseu.has_slice_pg)
+ continue;
+
/*
* Gen11 VME friendly power-gated configuration with
* half enabled sub-slices.
diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
index 27ae48049239..b9c8163978a3 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
@@ -30,7 +30,7 @@ static int gen8_emit_rpcs_config(struct i915_request *rq,
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
- *cs++ = intel_sseu_make_rpcs(rq->engine->i915, );
+ *cs++ = intel_sseu_make_rpcs(rq->engine->gt, );
intel_ring_advance(rq, cs);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index fca3c2348e5e..dd1a42c4d344 100644
---
[Intel-gfx] [PATCH v3 1/9] drm/i915: Convert device_info to uncore/de_read
Use intel__read instead of I915_READ to read the
informational registers.
Extended from an original sseu-only patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_device_info.c | 77 +++-
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 544ac61fbc36..c27a56aff5de 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -26,6 +26,7 @@
#include
#include "display/intel_cdclk.h"
+#include "display/intel_de.h"
#include "intel_device_info.h"
#include "i915_drv.h"
@@ -237,6 +238,7 @@ static void gen11_compute_sseu_info(struct sseu_dev_info
*sseu,
static void gen12_sseu_info_init(struct drm_i915_private *dev_priv)
{
struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+ struct intel_uncore *uncore = _priv->uncore;
u8 s_en;
u32 dss_en;
u16 eu_en = 0;
@@ -250,12 +252,14 @@ static void gen12_sseu_info_init(struct drm_i915_private
*dev_priv)
*/
intel_sseu_set_info(sseu, 1, 6, 16);
- s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
- dss_en = I915_READ(GEN12_GT_DSS_ENABLE);
+ dss_en = intel_uncore_read(uncore, GEN12_GT_DSS_ENABLE);
/* one bit per pair of EUs */
- eu_en_fuse = ~(I915_READ(GEN11_EU_DISABLE) & GEN11_EU_DIS_MASK);
+ eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
@@ -269,6 +273,7 @@ static void gen12_sseu_info_init(struct drm_i915_private
*dev_priv)
static void gen11_sseu_info_init(struct drm_i915_private *dev_priv)
{
struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+ struct intel_uncore *uncore = _priv->uncore;
u8 s_en;
u32 ss_en;
u8 eu_en;
@@ -278,9 +283,12 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
else
intel_sseu_set_info(sseu, 1, 8, 8);
- s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
- ss_en = ~I915_READ(GEN11_GT_SUBSLICE_DISABLE);
- eu_en = ~(I915_READ(GEN11_EU_DISABLE) & GEN11_EU_DIS_MASK);
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
+ ss_en = ~intel_uncore_read(uncore, GEN11_GT_SUBSLICE_DISABLE);
+
+ eu_en = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
gen11_compute_sseu_info(sseu, s_en, ss_en, eu_en);
@@ -292,8 +300,9 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
static void gen10_sseu_info_init(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = _priv->uncore;
struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
- const u32 fuse2 = I915_READ(GEN8_FUSE2);
+ const u32 fuse2 = intel_uncore_read(uncore, GEN8_FUSE2);
int s, ss;
const int eu_mask = 0xff;
u32 subslice_mask, eu_en;
@@ -304,26 +313,26 @@ static void gen10_sseu_info_init(struct drm_i915_private
*dev_priv)
GEN10_F2_S_ENA_SHIFT;
/* Slice0 */
- eu_en = ~I915_READ(GEN8_EU_DISABLE0);
+ eu_en = ~intel_uncore_read(uncore, GEN8_EU_DISABLE0);
for (ss = 0; ss < sseu->max_subslices; ss++)
sseu_set_eus(sseu, 0, ss, (eu_en >> (8 * ss)) & eu_mask);
/* Slice1 */
sseu_set_eus(sseu, 1, 0, (eu_en >> 24) & eu_mask);
- eu_en = ~I915_READ(GEN8_EU_DISABLE1);
+ eu_en = ~intel_uncore_read(uncore, GEN8_EU_DISABLE1);
sseu_set_eus(sseu, 1, 1, eu_en & eu_mask);
/* Slice2 */
sseu_set_eus(sseu, 2, 0, (eu_en >> 8) & eu_mask);
sseu_set_eus(sseu, 2, 1, (eu_en >> 16) & eu_mask);
/* Slice3 */
sseu_set_eus(sseu, 3, 0, (eu_en >> 24) & eu_mask);
- eu_en = ~I915_READ(GEN8_EU_DISABLE2);
+ eu_en = ~intel_uncore_read(uncore, GEN8_EU_DISABLE2);
sseu_set_eus(sseu, 3, 1, eu_en & eu_mask);
/* Slice4 */
sseu_set_eus(sseu, 4, 0, (eu_en >> 8) & eu_mask);
sseu_set_eus(sseu, 4, 1, (eu_en >> 16) & eu_mask);
/* Slice5 */
sseu_set_eus(sseu, 5, 0, (eu_en >> 24) & eu_mask);
- eu_en = ~I915_READ(GEN10_EU_DISABLE3);
+ eu_en = ~intel_uncore_read(uncore, GEN10_EU_DISABLE3);
sseu_set_eus(sseu, 5, 1, eu_en & eu_mask);
subslice_mask = (1 << 4) - 1;
@@ -372,7 +381,7 @@ static void cherryview_sseu_info_init(struct
drm_i915_private *dev_priv)
u32 fuse;
u8
[Intel-gfx] [PATCH v3 9/9] drm/i915: Move sseu debugfs under gt/
In line with what happened for other gt-related features, move the sseu
debugfs files under gt/.
The sseu_status debugfs has also been kept at the top level as we do
have tests that use it; it will be removed once we teach the tests to
look into the new path.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/debugfs_gt.c | 2 +
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 303 +++
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.h | 17 ++
drivers/gpu/drm/i915/i915_debugfs.c | 267 +---
5 files changed, 325 insertions(+), 265 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 41a27fd5dbc7..bda4c0e408f8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -112,6 +112,7 @@ gt-y += \
gt/intel_ring_submission.o \
gt/intel_rps.o \
gt/intel_sseu.o \
+ gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index 1de5fbaa1cf9..3a21cf63b3f0 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -9,6 +9,7 @@
#include "debugfs_engines.h"
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
+#include "intel_sseu_debugfs.h"
#include "uc/intel_uc_debugfs.h"
#include "i915_drv.h"
@@ -25,6 +26,7 @@ void debugfs_gt_register(struct intel_gt *gt)
debugfs_engines_register(gt, root);
debugfs_gt_pm_register(gt, root);
+ intel_sseu_debugfs_register(gt, root);
intel_uc_debugfs_register(>uc, root);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
new file mode 100644
index ..fc8d9737afe9
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include "debugfs_gt.h"
+#include "intel_sseu_debugfs.h"
+#include "i915_drv.h"
+
+static void sseu_copy_subslices(const struct sseu_dev_info *sseu,
+ int slice, u8 *to_mask)
+{
+ int offset = slice * sseu->ss_stride;
+
+ memcpy(_mask[offset], >subslice_mask[offset], sseu->ss_stride);
+}
+
+static void cherryview_sseu_device_status(struct intel_gt *gt,
+ struct sseu_dev_info *sseu)
+{
+#define SS_MAX 2
+ struct intel_uncore *uncore = gt->uncore;
+ const int ss_max = SS_MAX;
+ u32 sig1[SS_MAX], sig2[SS_MAX];
+ int ss;
+
+ sig1[0] = intel_uncore_read(uncore, CHV_POWER_SS0_SIG1);
+ sig1[1] = intel_uncore_read(uncore, CHV_POWER_SS1_SIG1);
+ sig2[0] = intel_uncore_read(uncore, CHV_POWER_SS0_SIG2);
+ sig2[1] = intel_uncore_read(uncore, CHV_POWER_SS1_SIG2);
+
+ for (ss = 0; ss < ss_max; ss++) {
+ unsigned int eu_cnt;
+
+ if (sig1[ss] & CHV_SS_PG_ENABLE)
+ /* skip disabled subslice */
+ continue;
+
+ sseu->slice_mask = BIT(0);
+ sseu->subslice_mask[0] |= BIT(ss);
+ eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
+((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
+ sseu->eu_total += eu_cnt;
+ sseu->eu_per_subslice = max_t(unsigned int,
+ sseu->eu_per_subslice, eu_cnt);
+ }
+#undef SS_MAX
+}
+
+static void gen10_sseu_device_status(struct intel_gt *gt,
+struct sseu_dev_info *sseu)
+{
+#define SS_MAX 6
+ struct intel_uncore *uncore = gt->uncore;
+ const struct intel_gt_info *info = >info;
+ u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
+ int s, ss;
+
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ /*
+* FIXME: Valid SS Mask respects the spec and read
+* only valid bits for those registers, excluding reserved
+* although this seems wrong because it would leave many
+* subslices without ACK.
+*/
+ s_reg[s] = intel_uncore_read(uncore, GEN10_SLICE_PGCTL_ACK(s)) &
+ GEN10_PGCTL_VALID_SS_MASK(s);
+ eu_reg[2 * s] = intel_uncore_read(uncore,
+ GEN10_SS01_EU_PGCTL_ACK(s));
+ eu_reg[2 * s + 1] = intel_uncore_read(uncore,
+
Re: [Intel-gfx] [PATCH v7 1/5] drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
>
> v2:
> - Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
> - Checkpatch style fixes
>
Reviewed-by: José Roberto de Souza
> Bspec: 50287
> Cc: Aditya Swarup
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++---
> drivers/gpu/drm/i915/display/intel_display.c | 15 ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> 3 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ca7bb2294d2b..8790f221dc77 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2770,7 +2770,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp)
> static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
>enum phy phy)
> {
> - if (intel_phy_is_combo(dev_priv, phy)) {
> + if (IS_ROCKETLAKE(dev_priv)) {
> + return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> + } else if (intel_phy_is_combo(dev_priv, phy)) {
> return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> } else if (intel_phy_is_tc(dev_priv, phy)) {
> enum tc_port tc_port = intel_port_to_tc(dev_priv,
> @@ -2797,6 +2799,16 @@ static void icl_map_plls_to_ports(struct intel_encoder
> *encoder,
> (val & icl_dpclka_cfgcr0_clk_off(dev_priv, phy)) == 0);
>
> if (intel_phy_is_combo(dev_priv, phy)) {
> + u32 mask, sel;
> +
> + if (IS_ROCKETLAKE(dev_priv)) {
> + mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> + sel = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> + } else {
> + mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> + sel = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> + }
> +
> /*
>* Even though this register references DDIs, note that we
>* want to pass the PHY rather than the port (DDI). For
> @@ -2807,8 +2819,8 @@ static void icl_map_plls_to_ports(struct intel_encoder
> *encoder,
>* Clock Select chooses the PLL for both DDIA and DDID and
>* drives port A in all cases."
>*/
> - val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - val |= ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> + val &= ~mask;
> + val |= sel;
> intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
> intel_de_posting_read(dev_priv, ICL_DPCLKA_CFGCR0);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7457813ef273..6c2bb3354b86 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10785,9 +10785,18 @@ static void icl_get_ddi_pll(struct drm_i915_private
> *dev_priv, enum port port,
> u32 temp;
>
> if (intel_phy_is_combo(dev_priv, phy)) {
> - temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) &
> - ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - id = temp >> ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
> + u32 mask, shift;
> +
> + if (IS_ROCKETLAKE(dev_priv)) {
> + mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> + shift = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
> + } else {
> + mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> + shift = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
> + }
> +
> + temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) & mask;
> + id = temp >> shift;
> port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> } else if (intel_phy_is_tc(dev_priv, phy)) {
> u32 clk_sel = intel_de_read(dev_priv, DDI_CLK_SEL(port)) &
> DDI_CLK_SEL_MASK;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f09120cac89a..45bda5819abd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10195,12 +10195,18 @@ enum skl_power_gate {
>
> #define ICL_DPCLKA_CFGCR0_MMIO(0x164280)
> #define ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy) (1 << _PICK(phy, 10, 11, 24))
> +#define RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy) REG_BIT((phy) + 10)
> #define ICL_DPCLKA_CFGCR0_TC_CLK_OFF(tc_port) (1 << ((tc_port) <
> PORT_TC4 ? \
> (tc_port) + 12 : \
> (tc_port) - PORT_TC4 +
> 21))
> #define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy)((phy) * 2)
>
Re: [Intel-gfx] [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path
Hi Daniel, Thank you for the patch. On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote: > Ends right after drm_atomic_helper_commit_hw_done(), absolutely > nothing fancy going on here. Just looking at this patch and the commit message, I have no idea what this does, and why. It would be nice to expand the commit message to give some more context, and especially explain why ending signalling right after drm_atomic_helper_commit_hw_done() is the right option. I suppose I'll have to check the whole series in the meantime :-) > Signed-off-by: Daniel Vetter > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: linux-renesas-...@vger.kernel.org > --- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > index 482329102f19..42c5dc588435 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > struct drm_crtc_state *crtc_state; > struct drm_crtc *crtc; > unsigned int i; > + bool fence_cookie = dma_fence_begin_signalling(); Can this be moved right before the drm_atomic_helper_commit_modeset_disables() call ? > > /* >* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured > @@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > drm_atomic_helper_commit_hw_done(old_state); > + dma_fence_end_signalling(fence_cookie); > drm_atomic_helper_wait_for_flip_done(dev, old_state); > > drm_atomic_helper_cleanup_planes(dev, old_state); -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: filter out the display mode exceed sink's capability
On Tue, May 26, 2020 at 02:23:10PM -0400, Lyude Paul wrote:
> From: Lee Shawn C
>
> So far, max dot clock rate for MST mode rely on physcial
> bandwidth limitation. It would caused compatibility issue
> if source display resolution exceed MST hub output ability.
>
> For example, source DUT had DP 1.2 output capability.
> And MST docking just support HDMI 1.4 spec. When a HDMI 2.0
> monitor connected. Source would retrieve EDID from external
> and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps
> because it did not surpass DP physical bandwidth limitation.
> Do modeset to 4k@60fps, source output display data but MST
> docking can't output HDMI properly due to this resolution
> already over HDMI 1.4 spec.
>
> Refer to commit ("drm/dp_mst: Use full_pbn
> instead of available_pbn for bandwidth checks").
> Source driver should refer to full_pbn to evaluate sink
> output capability. And filter out the resolution surpass
> sink output limitation.
>
> v2: Using mgr->base.lock to protect full_pbn.
> v3: Add ctx lock.
> v4:
> * s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/
> intel_dp_mst_mode_clock_exceeds_pbn_bw/
> * Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe
> down the drm_modeset_acquire_ctx that the probe helpers are using, so
> we can safely grab >base.lock without deadlocking
>
> Cc: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Cooper Chiou
> Co-developed-by: Lyude Paul
> Signed-off-by: Lee Shawn C
> Tested-by: Lee Shawn C
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 ++---
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d18b406f2a7d2..cf052095ad785 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -610,15 +610,42 @@ static int intel_dp_mst_get_modes(struct drm_connector
> *connector)
> return intel_dp_mst_get_ddc_modes(connector);
> }
>
> +static int
> +intel_dp_mst_mode_clock_exceeds_pbn_bw(struct drm_connector *connector,
> +struct drm_modeset_acquire_ctx *ctx,
> +int clock, int bpp)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct intel_dp *intel_dp = intel_connector->mst_port;
> + struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> + struct drm_dp_mst_port *port = (to_intel_connector(connector))->port;
intel_connector
> + int ret = MODE_OK;
> +
> + if (!mgr)
As a NULL check this would be bogus, but also connector->mst_port and so
mst_mgr too should be always non-NULL?
> + return ret;
> +
> + ret = drm_modeset_lock(>base.lock, ctx);
> + if (ret == -EDEADLK)
> + return ret;
> +
> + if (port->full_pbn &&
How could full_pbn be unset?
> + drm_dp_calc_pbn_mode(clock, bpp, false) > port->full_pbn)
> + ret = MODE_CLOCK_HIGH;
> +
> + return ret;
> +}
> +
> static enum drm_mode_status
> -intel_dp_mst_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> +intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
> + struct drm_display_mode *mode,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct intel_dp *intel_dp = intel_connector->mst_port;
> int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> int max_rate, mode_rate, max_lanes, max_link_clock;
> + int ret;
>
> if (drm_connector_is_unregistered(connector))
> return MODE_ERROR;
> @@ -632,7 +659,11 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> mode_rate = intel_dp_link_required(mode->clock, 18);
>
> - /* TODO - validate mode against available PBN for link */
> + ret = intel_dp_mst_mode_clock_exceeds_pbn_bw(connector, ctx,
> + mode->clock, 24);
Why 24 bpp and not 18?
Nit: could be checked after max_rate/max_dotclk for consistency.
> + if (ret != MODE_OK)
> + return ret;
> +
> if (mode->clock < 1)
> return MODE_CLOCK_LOW;
>
> @@ -671,7 +702,7 @@ intel_dp_mst_detect(struct drm_connector *connector,
>
> static const struct drm_connector_helper_funcs
> intel_dp_mst_connector_helper_funcs = {
> .get_modes = intel_dp_mst_get_modes,
> - .mode_valid = intel_dp_mst_mode_valid,
> + .mode_valid_ctx = intel_dp_mst_mode_valid_ctx,
> .atomic_best_encoder = intel_mst_atomic_best_encoder,
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915/huc: Adjust HuC state accordingly after GuC fetch error
On 7/7/2020 2:52 PM, Michał Winiarski wrote:
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in case
of GuC fetch error, leading those asserts to fire when calling
"intel_huc_is_used()".
Reported-by: Marcin Bernatowicz
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Marcin Bernatowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 1c2d6358826c..993e9755f317 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -267,8 +267,14 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
GEM_BUG_ON(!intel_uc_wants_guc(uc));
err = intel_uc_fw_fetch(>guc.fw);
- if (err)
+ if (err) {
+ /* Make sure we transition out of transient "SELECTED" state */
+ if (intel_uc_wants_huc(uc))
+ intel_uc_fw_change_status(>huc.fw,
+ INTEL_UC_FIRMWARE_ERROR);
I think that a debug message saying that we're disabling HuC because GuC
FW was not found would be useful to make it clear that the error is not
related to the HuC blob itself.
+
return;
+ }
if (intel_uc_wants_huc(uc))
intel_uc_fw_fetch(>huc.fw);
It looks like this function could use a bit of rework for better onion
unwinding because if we fail to fetch the HuC and we don't want GuC
submission we should disable the GuC.
That's not an issue with this patch, so with the added debug log:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/uc: Extract uc usage details into separate debugfs
== Series Details ==
Series: series starting with [1/2] drm/i915/uc: Extract uc usage details into
separate debugfs
URL : https://patchwork.freedesktop.org/series/79220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18102
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/index.html
Known issues
Here are the changes found in Patchwork_18102 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][3] -> [DMESG-WARN][4] ([i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_mmap_...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][13] ([i915#95]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][17] ([i915#1233]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18102/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_force_connector_basic@force-connector-state:
- {fi-tgl-dsi}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
[24]:
Re: [Intel-gfx] [PATCH 1/2] drm/i915/uc: Extract uc usage details into separate debugfs
On 7/7/2020 2:52 PM, Michał Winiarski wrote:
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Lukasz Fiedorowicz
Cc: Michal Wajdeczko
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 23 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 29 +++
2 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 446a41946f56..861657897c0f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -733,28 +733,19 @@ int intel_guc_allocate_and_map_vma(struct intel_guc *guc,
u32 size,
*/
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p)
{
- struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_guc(uc)),
- yesno(intel_uc_wants_guc(uc)),
- yesno(intel_uc_uses_guc(uc)));
- drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_huc(uc)),
- yesno(intel_uc_wants_huc(uc)),
- yesno(intel_uc_uses_huc(uc)));
- drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_guc_submission(uc)),
- yesno(intel_uc_wants_guc_submission(uc)),
- yesno(intel_uc_uses_guc_submission(uc)));
-
- if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
+ if (!intel_guc_is_supported(guc)) {
+ drm_printf(p, "GuC not supported\n");
return;
+ }
- drm_puts(p, "\n");
+ if (!intel_guc_is_wanted(guc)) {
+ drm_printf(p, "GuC disabled\n");
+ return;
+ }
intel_uc_fw_dump(>fw, p);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
index 9d16b784aa0d..089d98662f46 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
@@ -4,14 +4,41 @@
*/
#include
+#include
+#include "gt/debugfs_gt.h"
#include "intel_guc_debugfs.h"
#include "intel_huc_debugfs.h"
#include "intel_uc.h"
#include "intel_uc_debugfs.h"
+static int uc_usage_show(struct seq_file *m, void *data)
+{
+ struct intel_uc *uc = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(, "[guc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc(uc)),
+ yesno(intel_uc_wants_guc(uc)),
+ yesno(intel_uc_uses_guc(uc)));
+ drm_printf(, "[huc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_huc(uc)),
+ yesno(intel_uc_wants_huc(uc)),
+ yesno(intel_uc_uses_huc(uc)));
+ drm_printf(, "[submission] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc_submission(uc)),
+ yesno(intel_uc_wants_guc_submission(uc)),
+ yesno(intel_uc_uses_guc_submission(uc)));
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(uc_usage);
+
void intel_uc_debugfs_register(struct intel_uc *uc, struct dentry *gt_root)
{
+ static const struct debugfs_gt_file files[] = {
+ { "usage", _usage_fops, NULL },
+ };
struct dentry *root;
if (!gt_root)
@@ -25,6 +52,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
dentry *gt_root)
if (IS_ERR(root))
return;
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
+
intel_guc_debugfs_register(>guc, root);
intel_huc_debugfs_register(>huc, root);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-fence annotations, round 3 (rev2)
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18101
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/index.html
Known issues
Here are the changes found in Patchwork_18101 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-soraka/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][5] -> [DMESG-WARN][6] ([i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
- fi-byt-j1900: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_mmap_...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][17] ([i915#95]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26]
[25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix initial fb to use resource_size_t (rev2)
== Series Details == Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2) URL : https://patchwork.freedesktop.org/series/79205/ State : success == Summary == CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18098_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18098_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@processes: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl3/igt@gem_ctx_persiste...@processes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-skl10/igt@gem_ctx_persiste...@processes.html * igt@gem_exec_balancer@sliced: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1936] / [i915#1958] / [i915#2119]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb8/igt@gem_exec_balan...@sliced.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-tglb1/igt@gem_exec_balan...@sliced.html * igt@gem_exec_reloc@basic-gtt-cpu-noreloc: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2119]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb8/igt@gem_exec_re...@basic-gtt-cpu-noreloc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-tglb1/igt@gem_exec_re...@basic-gtt-cpu-noreloc.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#1436] / [i915#716]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-kbl3/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-snb4/igt@kms_big...@x-tiled-32bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-snb2/igt@kms_big...@x-tiled-32bpp-rotate-180.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl3/igt@kms_co...@pipe-a-gamma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-kbl1/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@pipe-b-torture-move: - shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([i915#128]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-iclb6/igt@kms_cursor_leg...@pipe-b-torture-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-iclb8/igt@kms_cursor_leg...@pipe-b-torture-move.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip_tiling@flip-x-tiled: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#95]) +12 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl3/igt@kms_flip_til...@flip-x-tiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-apl1/igt@kms_flip_til...@flip-x-tiled.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: - shard-snb: [PASS][23] -> [TIMEOUT][24] ([i915#1958] / [i915#2119]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-snb2/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html *
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-fence annotations, round 3 (rev2)
== Series Details == Series: dma-fence annotations, round 3 (rev2) URL : https://patchwork.freedesktop.org/series/79212/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast to restricted __le16
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-fence annotations, round 3 (rev2)
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ef2cbad3c3f dma-fence: basic lockdep annotations
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e91498589746
("locking/lockdep/selftests: Add mixed read-write ABBA tests")'
#23:
commit e91498589746065e3ae95d9a00b068e525eec34f
-:97: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e966eaeeb623 ("locking/lockdep:
Remove the cross-release locking checks")'
#97:
commit e966eaeeb623f09975ef362c2866fae6f86844f9
-:103: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#103:
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and
CONFIG_LOCKDEP_COMPLETIONS=y),
-:303: ERROR:IN_ATOMIC: do not use in_atomic in drivers
#303: FILE: drivers/dma-buf/dma-fence.c:228:
+ if (in_atomic())
-:341: CHECK:LINE_SPACING: Please don't use multiple blank lines
#341: FILE: drivers/dma-buf/dma-fence.c:266:
+
+
-:390: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#390: FILE: include/linux/dma-fence.h:368:
+}
+static inline void dma_fence_end_signalling(bool cookie) {}
-:396: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 3 errors, 2 warnings, 2 checks, 217 lines checked
161956239d13 dma-fence: prime lockdep annotations
-:31: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 23b68395c7c7 ("mm/mmu_notifiers:
add a lockdep map for invalidate_range_start/end")'
#31:
commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
-:193: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 91 lines checked
8b75e6b6b1b6 dma-buf.rst: Document why idenfinite fences are a bad idea
-:149: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 105 lines checked
5fad761a1004 drm/vkms: Annotate vblank timer
-:59: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
92b268014731 drm/vblank: Annotate with dma-fence signalling section
-:71: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 38 lines checked
cf8a240564b5 drm/amdgpu: add dma-fence annotations to atomic commit path
-:52: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 24 lines checked
7a522c30b416 drm/komdea: Annotate dma-fence critical section in commit path
-:46: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 15 lines checked
c378cbda4b96 drm/malidp: Annotate dma-fence critical section in commit path
-:38: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 15 lines checked
4507fb407ce9 drm/atmel: Use drm_atomic_helper_commit
-:213: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 170 lines checked
bbe90243440b drm/imx: Annotate dma-fence critical section in commit path
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 21a01abbe32a ("drm/atomic: Fix
freeing connector/plane state too early by tracking commits, v3.")'
#14:
commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
-:50: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
8d9019996f33 drm/omapdrm: Annotate dma-fence critical section in commit path
-:54: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 29 lines checked
e54ea8ce539b drm/rcar-du: Annotate dma-fence critical section in commit path
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
b6a053a9563c drm/tegra: Annotate dma-fence critical section in commit path
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
c4c8e32708f2 drm/tidss: Annotate dma-fence critical section in commit path
-:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Add new PCI ids
On Tue, Jul 07, 2020 at 01:45:30PM -0700, José Roberto de Souza wrote: > Two new PCI ids added to ehl. > > v2: added two additional PCI ids > > BSpec: 29153 > Cc: Matt Roper > Cc: Anusha Srivatsa > Signed-off-by: José Roberto de Souza Reviewed-by: Matt Roper > --- > include/drm/i915_pciids.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index bc989de2aac2..d6cb28992ba0 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -588,7 +588,11 @@ > INTEL_VGA_DEVICE(0x4551, info), \ > INTEL_VGA_DEVICE(0x4541, info), \ > INTEL_VGA_DEVICE(0x4E71, info), \ > + INTEL_VGA_DEVICE(0x4557, info), \ > + INTEL_VGA_DEVICE(0x4555, info), \ > INTEL_VGA_DEVICE(0x4E61, info), \ > + INTEL_VGA_DEVICE(0x4E57, info), \ > + INTEL_VGA_DEVICE(0x4E55, info), \ > INTEL_VGA_DEVICE(0x4E51, info) > > /* TGL */ > -- > 2.27.0 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix initial fb to use resource_size_t
== Series Details == Series: drm/i915/display: Fix initial fb to use resource_size_t URL : https://patchwork.freedesktop.org/series/79205/ State : success == Summary == CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18097_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18097_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@madvise: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk1/igt@gem_exec_cre...@madvise.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-glk3/igt@gem_exec_cre...@madvise.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#198] / [i915#2110]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl7/igt@i915_selftest@m...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl1/igt@i915_selftest@m...@requests.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl3/igt@kms_co...@pipe-a-gamma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-kbl7/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] / [i915#95]) +19 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-move.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-apl2/igt@kms_cursor_leg...@pipe-a-forked-move.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl5/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl2/igt@kms_flip@flip-vs-susp...@c-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: - shard-snb: [PASS][15] -> [TIMEOUT][16] ([i915#1958] / [i915#2119]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#49]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl10/igt@kms_...@bpc-switch-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl1/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-a-coverage-vs-premult-vs-constant: - shard-kbl: [PASS][21] -> [DMESG-FAIL][22] ([fdo#108145] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-kbl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html - shard-apl: [PASS][23] -> [DMESG-FAIL][24] ([fdo#108145] / [i915#1635] / [i915#95]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Add new PCI ids (rev2)
== Series Details ==
Series: drm/i915/ehl: Add new PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/78910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18100
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/index.html
Known issues
Here are the changes found in Patchwork_18100 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][7] -> [DMESG-WARN][8] ([i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][9] -> [DMESG-FAIL][10] ([i915#1748])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@vgem_ba...@setversion.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_mmap_...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][17] ([i915#95]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_force_connector_basic@force-connector-state:
- {fi-tgl-dsi}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][23] ([i915#62]) -> [SKIP][24]
([fdo#109271])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +8 similar issues
[25]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Unpin idle contexts from kswapd reclaim
== Series Details == Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim URL : https://patchwork.freedesktop.org/series/79204/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18096_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18096_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18096_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18096_full: ### IGT changes ### Possible regressions * igt@kms_properties@crtc-properties-atomic: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb7/igt@kms_propert...@crtc-properties-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-tglb2/igt@kms_propert...@crtc-properties-atomic.html Known issues Here are the changes found in Patchwork_18096_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@i915_selftest@live@execlists: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#794]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl6/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-kbl4/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198] / [i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl7/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-skl8/igt@i915_selftest@m...@requests.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl3/igt@kms_co...@pipe-a-gamma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-kbl6/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +15 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-move.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-apl3/igt@kms_cursor_leg...@pipe-a-forked-move.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl8/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-tglb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / [i915#95]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-glk9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: - shard-snb: [PASS][21] -> [TIMEOUT][22] ([i915#1958] / [i915#2119]) +3 similar issues [21]:
[Intel-gfx] [PATCH 2/2] drm/i915/huc: Adjust HuC state accordingly after GuC fetch error
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in case
of GuC fetch error, leading those asserts to fire when calling
"intel_huc_is_used()".
Reported-by: Marcin Bernatowicz
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Marcin Bernatowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 1c2d6358826c..993e9755f317 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -267,8 +267,14 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
GEM_BUG_ON(!intel_uc_wants_guc(uc));
err = intel_uc_fw_fetch(>guc.fw);
- if (err)
+ if (err) {
+ /* Make sure we transition out of transient "SELECTED" state */
+ if (intel_uc_wants_huc(uc))
+ intel_uc_fw_change_status(>huc.fw,
+ INTEL_UC_FIRMWARE_ERROR);
+
return;
+ }
if (intel_uc_wants_huc(uc))
intel_uc_fw_fetch(>huc.fw);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/uc: Extract uc usage details into separate debugfs
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Lukasz Fiedorowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 23 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 29 +++
2 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 446a41946f56..861657897c0f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -733,28 +733,19 @@ int intel_guc_allocate_and_map_vma(struct intel_guc *guc,
u32 size,
*/
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p)
{
- struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_guc(uc)),
- yesno(intel_uc_wants_guc(uc)),
- yesno(intel_uc_uses_guc(uc)));
- drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_huc(uc)),
- yesno(intel_uc_wants_huc(uc)),
- yesno(intel_uc_uses_huc(uc)));
- drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_guc_submission(uc)),
- yesno(intel_uc_wants_guc_submission(uc)),
- yesno(intel_uc_uses_guc_submission(uc)));
-
- if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
+ if (!intel_guc_is_supported(guc)) {
+ drm_printf(p, "GuC not supported\n");
return;
+ }
- drm_puts(p, "\n");
+ if (!intel_guc_is_wanted(guc)) {
+ drm_printf(p, "GuC disabled\n");
+ return;
+ }
intel_uc_fw_dump(>fw, p);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
index 9d16b784aa0d..089d98662f46 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
@@ -4,14 +4,41 @@
*/
#include
+#include
+#include "gt/debugfs_gt.h"
#include "intel_guc_debugfs.h"
#include "intel_huc_debugfs.h"
#include "intel_uc.h"
#include "intel_uc_debugfs.h"
+static int uc_usage_show(struct seq_file *m, void *data)
+{
+ struct intel_uc *uc = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(, "[guc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc(uc)),
+ yesno(intel_uc_wants_guc(uc)),
+ yesno(intel_uc_uses_guc(uc)));
+ drm_printf(, "[huc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_huc(uc)),
+ yesno(intel_uc_wants_huc(uc)),
+ yesno(intel_uc_uses_huc(uc)));
+ drm_printf(, "[submission] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc_submission(uc)),
+ yesno(intel_uc_wants_guc_submission(uc)),
+ yesno(intel_uc_uses_guc_submission(uc)));
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(uc_usage);
+
void intel_uc_debugfs_register(struct intel_uc *uc, struct dentry *gt_root)
{
+ static const struct debugfs_gt_file files[] = {
+ { "usage", _usage_fops, NULL },
+ };
struct dentry *root;
if (!gt_root)
@@ -25,6 +52,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
dentry *gt_root)
if (IS_ERR(root))
return;
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
+
intel_guc_debugfs_register(>guc, root);
intel_huc_debugfs_register(>huc, root);
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/atmel: Use drm_atomic_helper_commit
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.
v2:
- Also delete the workqueue (Sam)
- drop the @commit kerneldoc, I missed that one.
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 107 +--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 7 --
2 files changed, 2 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 871293d1aeeb..03984932d174 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
void *data)
return IRQ_HANDLED;
}
-struct atmel_hlcdc_dc_commit {
- struct work_struct work;
- struct drm_device *dev;
- struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
- struct drm_device *dev = commit->dev;
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct drm_atomic_state *old_state = commit->state;
-
- /* Apply the atomic update. */
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state, 0);
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-
- drm_atomic_state_put(old_state);
-
- /* Complete the commit, wake up any waiter. */
- spin_lock(>commit.wait.lock);
- dc->commit.pending = false;
- wake_up_all_locked(>commit.wait);
- spin_unlock(>commit.wait.lock);
-
- kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
- struct atmel_hlcdc_dc_commit *commit =
- container_of(work, struct atmel_hlcdc_dc_commit, work);
-
- atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct atmel_hlcdc_dc_commit *commit;
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* Allocate the commit object. */
- commit = kzalloc(sizeof(*commit), GFP_KERNEL);
- if (!commit) {
- ret = -ENOMEM;
- goto error;
- }
-
- INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
- commit->dev = dev;
- commit->state = state;
-
- spin_lock(>commit.wait.lock);
- ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
- if (ret == 0)
- dc->commit.pending = true;
- spin_unlock(>commit.wait.lock);
-
- if (ret)
- goto err_free;
-
- /* We have our own synchronization through the commit lock. */
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /* Swap state succeeded, this is the point of no return. */
- drm_atomic_state_get(state);
- if (async)
- queue_work(dc->wq, >work);
- else
- atmel_hlcdc_dc_atomic_complete(commit);
-
- return 0;
-
-err_free:
- kfree(commit);
-error:
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -712,11 +619,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc)
return -ENOMEM;
- dc->wq = alloc_ordered_workqueue("atmel-hlcdc-dc", 0);
- if (!dc->wq)
- return -ENOMEM;
-
- init_waitqueue_head(>commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
@@ -724,7 +626,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
ret =
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
== Series Details == Series: series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map() URL : https://patchwork.freedesktop.org/series/79211/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18099 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18099 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18099, 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_18099/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18099: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-cml-s: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-cml-s/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-cml-s/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_18099 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_module_load@reload: - fi-bxt-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bxt-dsi/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-bxt-dsi/igt@i915_module_l...@reload.html - fi-tgl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-whl-u: [PASS][9] -> [DMESG-WARN][10] ([i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-glk-dsi/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [PASS][13] -> [INCOMPLETE][14] ([i915#1932] / [i915#2045]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][15] -> [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-u2: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html * igt@vgem_basic@create: - fi-tgl-y: [PASS][21] -> [DMESG-WARN][22] ([i915#402]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@vgem_ba...@create.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-y/igt@vgem_ba...@create.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][23] ([i915#402]) -> [PASS][24] +1 similar issue [23]:
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hello Hans, On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote: > On 7/7/20 9:34 AM, Uwe Kleine-König wrote: > > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: > > > But if we do then I think closest to the truth would be: > > > > > > state->period = UINT_MAX; > > > state->duty_cycle = 0; > > > > I'd say state->period = 1 & state->duty_cycle = 0 is a better > > representation. > > But that would suggest the output is configured for an > infinitely high output frequency, but the frequency is > actually 0, the reason why get_state needs to treat a > base_unit val of 0 special at all is to avoid a division > by 0, and in math dividing by 0 gives infinite, isn't > UINT_MAX a better way to represent infinity ? Given that duty_cycle is 0, how can to tell anything about the period when only seeing the signal (= a constant low)? Given that (ideally) a period is completed when pwm_apply_state() is called, a short period is much more sensible. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
== Series Details == Series: series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map() URL : https://patchwork.freedesktop.org/series/79211/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3286cb8bd6d2 drm/i915/gt: Replace opencoded i915_gem_object_pin_map() 9caa553dca10 drm/i915: Release shortlived maps of longlived objects -:22: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #22: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:396: } +int i915_gem_object_release_map(struct drm_i915_gem_object *obj); total: 0 errors, 0 warnings, 1 checks, 68 lines checked b500f5a58d25 drm/i915: Remove i915_gem_object_get_dirty_page() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/ehl: Add new PCI ids
Two new PCI ids added to ehl. v2: added two additional PCI ids BSpec: 29153 Cc: Matt Roper Cc: Anusha Srivatsa Signed-off-by: José Roberto de Souza --- include/drm/i915_pciids.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index bc989de2aac2..d6cb28992ba0 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -588,7 +588,11 @@ INTEL_VGA_DEVICE(0x4551, info), \ INTEL_VGA_DEVICE(0x4541, info), \ INTEL_VGA_DEVICE(0x4E71, info), \ + INTEL_VGA_DEVICE(0x4557, info), \ + INTEL_VGA_DEVICE(0x4555, info), \ INTEL_VGA_DEVICE(0x4E61, info), \ + INTEL_VGA_DEVICE(0x4E57, info), \ + INTEL_VGA_DEVICE(0x4E55, info), \ INTEL_VGA_DEVICE(0x4E51, info) /* TGL */ -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit
Hi Daniel.
On Tue, Jul 07, 2020 at 10:12:13PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
>
> Could also perhaps use the drm_mode_config_helper_suspend/resume
> stuff, for another few lines deleted. But I'm not looking at that
> stuff, I'm just going through all the atomic commit functions and make
> sure they have properly annotated dma-fence critical sections
> everywhere.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: linux-arm-ker...@lists.infradead.org
Looks good, nice to see all this code deleted!
This more or less matches what I had concluded.
But..
atmel_hlcdc_dc.wq is no longer used - so can also be deleted.
This will delete even more code - good.
I will try to test the patch in the weekend.
Will get back if I suceed doing so.
Sam
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 -
> 2 files changed, 1 insertion(+), 99 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 871293d1aeeb..9ec156e98f06 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
> void *data)
> return IRQ_HANDLED;
> }
>
> -struct atmel_hlcdc_dc_commit {
> - struct work_struct work;
> - struct drm_device *dev;
> - struct drm_atomic_state *state;
> -};
> -
> -static void
> -atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
> -{
> - struct drm_device *dev = commit->dev;
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct drm_atomic_state *old_state = commit->state;
> -
> - /* Apply the atomic update. */
> - drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> -
> - drm_atomic_helper_cleanup_planes(dev, old_state);
> -
> - drm_atomic_state_put(old_state);
> -
> - /* Complete the commit, wake up any waiter. */
> - spin_lock(>commit.wait.lock);
> - dc->commit.pending = false;
> - wake_up_all_locked(>commit.wait);
> - spin_unlock(>commit.wait.lock);
> -
> - kfree(commit);
> -}
> -
> -static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
> -{
> - struct atmel_hlcdc_dc_commit *commit =
> - container_of(work, struct atmel_hlcdc_dc_commit, work);
> -
> - atmel_hlcdc_dc_atomic_complete(commit);
> -}
> -
> -static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
> - struct drm_atomic_state *state,
> - bool async)
> -{
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct atmel_hlcdc_dc_commit *commit;
> - int ret;
> -
> - ret = drm_atomic_helper_prepare_planes(dev, state);
> - if (ret)
> - return ret;
> -
> - /* Allocate the commit object. */
> - commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> - if (!commit) {
> - ret = -ENOMEM;
> - goto error;
> - }
> -
> - INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
> - commit->dev = dev;
> - commit->state = state;
> -
> - spin_lock(>commit.wait.lock);
> - ret = wait_event_interruptible_locked(dc->commit.wait,
> - !dc->commit.pending);
> - if (ret == 0)
> - dc->commit.pending = true;
> - spin_unlock(>commit.wait.lock);
> -
> - if (ret)
> - goto err_free;
> -
> - /* We have our own synchronization through the commit lock. */
> - BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
> -
> - /* Swap state succeeded, this is the point of no return. */
> - drm_atomic_state_get(state);
> - if (async)
> - queue_work(dc->wq, >work);
> - else
> - atmel_hlcdc_dc_atomic_complete(commit);
> -
> - return 0;
> -
> -err_free:
> - kfree(commit);
> -error:
> - drm_atomic_helper_cleanup_planes(dev, state);
> - return ret;
> -}
> -
> static const struct drm_mode_config_funcs mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> .atomic_check = drm_atomic_helper_check,
> - .atomic_commit = atmel_hlcdc_dc_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
> };
>
> static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
> @@ -716,7 +623,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
> if (!dc->wq)
>
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Implement new combo phy initialization step (rev3)
On Tue, 2020-06-30 at 15:19 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/display: Implement new combo phy initialization step (rev3) > URL : https://patchwork.freedesktop.org/series/78796/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8677_full -> Patchwork_18039_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Pushed, Matt Roper gave review in v2 version but he reviewed v3 too. > > > > Known issues > > > Here are the changes found in Patchwork_18039_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: > - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#1528]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-kbl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-kbl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html > > * igt@i915_module_load@reload: > - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 > similar issue >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-tglb3/igt@i915_module_l...@reload.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-tglb6/igt@i915_module_l...@reload.html > > * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: > - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / > [i915#95]) +2 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-kbl7/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html > > * igt@kms_cursor_legacy@pipe-b-torture-move: > - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#128]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-tglb5/igt@kms_cursor_leg...@pipe-b-torture-move.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-tglb1/igt@kms_cursor_leg...@pipe-b-torture-move.html > > * igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset@ab-vga1-hdmi-a1: > - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-hsw8/igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-mode...@ab-vga1-hdmi-a1.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-hsw6/igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-mode...@ab-vga1-hdmi-a1.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: > - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html > > * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: > - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 > similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html > > * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1: > - shard-skl: [PASS][15] -> [FAIL][16] ([i915#1928]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-skl10/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: > - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / > [i915#95]) +13 similar issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-apl7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-apl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html > > * igt@kms_hdr@bpc-switch-suspend: > - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar > issue >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-skl5/igt@kms_...@bpc-switch-suspend.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-skl5/igt@kms_...@bpc-switch-suspend.html > > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: > - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) >[21]: >
[Intel-gfx] [PATCH 24/25] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be held when we allocate memory, which
might never happen because the dma_fence_wait() is stuck waiting on
our gpu reset:
[ 136.763714] ==
[ 136.763714] WARNING: possible circular locking dependency detected
[ 136.763715] 5.7.0-rc3+ #346 Tainted: GW
[ 136.763716] --
[ 136.763716] kworker/2:3/682 is trying to acquire lock:
[ 136.763716] 8226f140 (console_lock){+.+.}-{0:0}, at:
drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763723]
but task is already holding lock:
[ 136.763724] 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 136.763726]
which lock already depends on the new lock.
[ 136.763726]
the existing dependency chain (in reverse order) is:
[ 136.763727]
-> #2 (dma_fence_map){}-{0:0}:
[ 136.763730]__dma_fence_might_wait+0x41/0xb0
[ 136.763732]dma_resv_lockdep+0x171/0x202
[ 136.763734]do_one_initcall+0x5d/0x2f0
[ 136.763736]kernel_init_freeable+0x20d/0x26d
[ 136.763738]kernel_init+0xa/0xfb
[ 136.763740]ret_from_fork+0x27/0x50
[ 136.763740]
-> #1 (fs_reclaim){+.+.}-{0:0}:
[ 136.763743]fs_reclaim_acquire.part.0+0x25/0x30
[ 136.763745]kmem_cache_alloc_trace+0x2e/0x6e0
[ 136.763747]device_create_groups_vargs+0x52/0xf0
[ 136.763747]device_create+0x49/0x60
[ 136.763749]fb_console_init+0x25/0x145
[ 136.763750]fbmem_init+0xcc/0xe2
[ 136.763750]do_one_initcall+0x5d/0x2f0
[ 136.763751]kernel_init_freeable+0x20d/0x26d
[ 136.763752]kernel_init+0xa/0xfb
[ 136.763753]ret_from_fork+0x27/0x50
[ 136.763753]
-> #0 (console_lock){+.+.}-{0:0}:
[ 136.763755]__lock_acquire+0x1241/0x23f0
[ 136.763756]lock_acquire+0xad/0x370
[ 136.763757]console_lock+0x47/0x70
[ 136.763761]drm_fb_helper_set_suspend_unlocked+0x7b/0xa0
[drm_kms_helper]
[ 136.763809]amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[ 136.763850]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 136.763851]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 136.763852]process_one_work+0x23c/0x580
[ 136.763853]worker_thread+0x50/0x3b0
[ 136.763854]kthread+0x12e/0x150
[ 136.763855]ret_from_fork+0x27/0x50
[ 136.763855]
other info that might help us debug this:
[ 136.763856] Chain exists of:
console_lock --> fs_reclaim --> dma_fence_map
[ 136.763857] Possible unsafe locking scenario:
[ 136.763857]CPU0CPU1
[ 136.763857]
[ 136.763857] lock(dma_fence_map);
[ 136.763858]lock(fs_reclaim);
[ 136.763858]lock(dma_fence_map);
[ 136.763858] lock(console_lock);
[ 136.763859]
*** DEADLOCK ***
[ 136.763860] 4 locks held by kworker/2:3/682:
[ 136.763860] #0: 8887fb81c938 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x1bc/0x580
[ 136.763862] #1: c9cafe58
((work_completion)(&(>work_tdr)->work)){+.+.}-{0:0}, at:
process_one_work+0x1bc/0x580
[ 136.763863] #2: 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 136.763865] #3: 8887ab621748 (>lock_reset){+.+.}-{3:3}, at:
amdgpu_device_gpu_recover.cold+0x5ab/0xe7b [amdgpu]
[ 136.763914]
stack backtrace:
[ 136.763915] CPU: 2 PID: 682 Comm: kworker/2:3 Tainted: GW
5.7.0-rc3+ #346
[ 136.763916] Hardware name: System manufacturer System Product Name/PRIME
X370-PRO, BIOS 4011 04/19/2018
[ 136.763918] Workqueue: events drm_sched_job_timedout [gpu_sched]
[ 136.763919] Call Trace:
[ 136.763922] dump_stack+0x8f/0xd0
[ 136.763924] check_noncircular+0x162/0x180
[ 136.763926] __lock_acquire+0x1241/0x23f0
[ 136.763927] lock_acquire+0xad/0x370
[ 136.763932] ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763933] ? mark_held_locks+0x2d/0x80
[ 136.763934] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 136.763936] console_lock+0x47/0x70
[ 136.763940] ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763944] drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763993] amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[ 136.764036] amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 136.764038] drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 136.764040]
[Intel-gfx] [PATCH 25/25] drm/amdgpu: gpu recovery does full modesets
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] --
[ 132.586184] kworker/2:3/865 is trying to acquire lock:
[ 132.586857] c9677c70 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[ 132.587569]
but task is already holding lock:
[ 132.589044] 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 132.589803]
which lock already depends on the new lock.
[ 132.592009]
the existing dependency chain (in reverse order) is:
[ 132.593507]
-> #2 (dma_fence_map){}-{0:0}:
[ 132.595019]dma_fence_begin_signalling+0x50/0x60
[ 132.595767]drm_atomic_helper_commit+0xa1/0x180 [drm_kms_helper]
[ 132.596567]drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
[ 132.597420]drm_client_modeset_commit_locked+0x55/0x190 [drm]
[ 132.598178]drm_client_modeset_commit+0x24/0x40 [drm]
[ 132.598948]drm_fb_helper_restore_fbdev_mode_unlocked+0x4b/0xa0
[drm_kms_helper]
[ 132.599738]drm_fb_helper_set_par+0x30/0x40 [drm_kms_helper]
[ 132.600539]fbcon_init+0x2e8/0x660
[ 132.601344]visual_init+0xce/0x130
[ 132.602156]do_bind_con_driver+0x1bc/0x2b0
[ 132.602970]do_take_over_console+0x115/0x180
[ 132.603763]do_fbcon_takeover+0x58/0xb0
[ 132.604564]register_framebuffer+0x1ee/0x300
[ 132.605369]__drm_fb_helper_initial_config_and_unlock+0x36e/0x520
[drm_kms_helper]
[ 132.606187]amdgpu_fbdev_init+0xb3/0xf0 [amdgpu]
[ 132.607032]amdgpu_device_init.cold+0xe90/0x1677 [amdgpu]
[ 132.607862]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[ 132.608697]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[ 132.609511]local_pci_probe+0x42/0x80
[ 132.610324]pci_device_probe+0x104/0x1a0
[ 132.611130]really_probe+0x147/0x3c0
[ 132.611939]driver_probe_device+0xb6/0x100
[ 132.612766]device_driver_attach+0x53/0x60
[ 132.613593]__driver_attach+0x8c/0x150
[ 132.614419]bus_for_each_dev+0x7b/0xc0
[ 132.615249]bus_add_driver+0x14c/0x1f0
[ 132.616071]driver_register+0x6c/0xc0
[ 132.616902]do_one_initcall+0x5d/0x2f0
[ 132.617731]do_init_module+0x5c/0x230
[ 132.618560]load_module+0x2981/0x2bc0
[ 132.619391]__do_sys_finit_module+0xaa/0x110
[ 132.620228]do_syscall_64+0x5a/0x250
[ 132.621064]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 132.621903]
-> #1 (crtc_ww_class_mutex){+.+.}-{3:3}:
[ 132.623587]__ww_mutex_lock.constprop.0+0xcc/0x10c0
[ 132.624448]ww_mutex_lock+0x43/0xb0
[ 132.625315]drm_modeset_lock+0x44/0x120 [drm]
[ 132.626184]drmm_mode_config_init+0x2db/0x8b0 [drm]
[ 132.627098]amdgpu_device_init.cold+0xbd1/0x1677 [amdgpu]
[ 132.628007]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[ 132.628920]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[ 132.629804]local_pci_probe+0x42/0x80
[ 132.630690]pci_device_probe+0x104/0x1a0
[ 132.631583]really_probe+0x147/0x3c0
[ 132.632479]driver_probe_device+0xb6/0x100
[ 132.633379]device_driver_attach+0x53/0x60
[ 132.634275]__driver_attach+0x8c/0x150
[ 132.635170]bus_for_each_dev+0x7b/0xc0
[ 132.636069]bus_add_driver+0x14c/0x1f0
[ 132.636974]driver_register+0x6c/0xc0
[ 132.637870]do_one_initcall+0x5d/0x2f0
[ 132.638765]do_init_module+0x5c/0x230
[ 132.639654]load_module+0x2981/0x2bc0
[ 132.640522]__do_sys_finit_module+0xaa/0x110
[ 132.641372]do_syscall_64+0x5a/0x250
[ 132.642203]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 132.643022]
-> #0 (crtc_ww_class_acquire){+.+.}-{0:0}:
[ 132.644643]__lock_acquire+0x1241/0x23f0
[ 132.645469]lock_acquire+0xad/0x370
[ 132.646274]drm_modeset_acquire_init+0xd2/0x100 [drm]
[ 132.647071]drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[ 132.647902]dm_suspend+0x1c/0x60 [amdgpu]
[ 132.648698]amdgpu_device_ip_suspend_phase1+0x83/0xe0 [amdgpu]
[ 132.649498]amdgpu_device_ip_suspend+0x1c/0x60 [amdgpu]
[ 132.650300]amdgpu_device_gpu_recover.cold+0x4e6/0xe64 [amdgpu]
[ 132.651084]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 132.651825]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 132.652594]process_one_work+0x23c/0x580
[ 132.653402]worker_thread+0x50/0x3b0
[ 132.654139]kthread+0x12e/0x150
[ 132.654868]ret_from_fork+0x27/0x50
[ 132.655598]
[Intel-gfx] [PATCH 13/25] drm/tegra: Annotate dma-fence critical section in commit path
Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..9aea8fe48db3 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -65,11 +65,14 @@ static void tegra_atomic_commit_tail(struct
drm_atomic_state *old_state)
struct tegra_drm *tegra = drm->dev_private;
if (tegra->hub) {
+ bool fence_cookie = dma_fence_begin_signalling();
+
drm_atomic_helper_commit_modeset_disables(drm, old_state);
tegra_display_hub_atomic_commit(drm, old_state);
drm_atomic_helper_commit_planes(drm, old_state, 0);
drm_atomic_helper_commit_modeset_enables(drm, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_vblanks(drm, old_state);
drm_atomic_helper_cleanup_planes(drm, old_state);
} else {
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/25] drm/tilcdc: Use standard drm_atomic_helper_commit
Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.
The riskiest thing with this conversion is maybe that there's an issue
with the vblank handling or vblank event handling, which will upset
the modern commit support in atomic helpers. But from a cursory review
drm_crtc_vblank_on/off is called in the right places, and the event
handling also seems to exist (albeit with much hand-rolling and
probably some races, could perhaps be converted over to
drm_crtc_arm_vblank_event without any real loss).
Motivated by me not having to hand-roll the dma-fence annotations for
this.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +
1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0d74a6443263..4f5fc3e87383 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -87,55 +87,10 @@ static int tilcdc_atomic_check(struct drm_device *dev,
return ret;
}
-static int tilcdc_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_swap_state(state, true);
- if (ret) {
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
- }
-
- /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* current layout.
-*/
-
- drm_atomic_helper_commit_modeset_disables(dev, state);
-
- drm_atomic_helper_commit_planes(dev, state, 0);
-
- drm_atomic_helper_commit_modeset_enables(dev, state);
-
- drm_atomic_helper_wait_for_vblanks(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
-
- return 0;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = tilcdc_atomic_check,
- .atomic_commit = tilcdc_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static void modeset_init(struct drm_device *dev)
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/25] drm/scheduler: use dma-fence annotations in tdr work
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this was part of the overall scheduler annotation patch.
But amdgpu has some glorious inversions here:
- grabs console_lock
- does a full modeset, which grabs all kinds of locks
(drm_modeset_lock, dma_resv_lock) which can deadlock with
dma_fence_wait held inside them.
- almost minor at that point, but the modeset code also allocates
memory
These all look like they'll be very hard to fix properly, the hardware
seems to require a full display reset with any gpu recovery.
Hence split out as a seperate patch.
Since amdgpu isn't the only hardware driver that needs to reset the
display (at least gen2/3 on intel have the same problem) we need a
generic solution for this. There's two tricks we could still from
drm/i915 and lift to dma-fence:
- The big whack, aka force-complete all fences. i915 does this for all
pending jobs if the reset is somehow stuck. Trouble is we'd need to
do this for all fences in the entire system, and just the
book-keeping for that will be fun. Plus lots of drivers use fences
for all kinds of internal stuff like memory management, so
unconditionally resetting all of them doesn't work.
I'm also hoping that with these fence annotations we could enlist
lockdep in finding the last offenders causing deadlocks, and we
could remove this get-out-of-jail trick.
- The more feasible approach (across drivers at least as part of the
dma_fence contract) is what drm/i915 does for gen2/3: When we need
to reset the display we wake up all dma_fence_wait_interruptible
calls, or well at least the equivalent of those in i915 internally.
Relying on ioctl restart we force all other threads to release their
locks, which means the tdr thread is guaranteed to be able to get
them. I think we could implement this at the dma_fence level,
including proper lockdep annotations.
dma_fence_begin_tdr():
- must be nested within a dma_fence_begin/end_signalling section
- will wake up all interruptible (but not the non-interruptible)
dma_fence_wait() calls and force them to complete with a
-ERESTARTSYS errno code. All new interrupitble calls to
dma_fence_wait() will immeidately fail with the same error code.
dma_fence_end_trdr():
- this will convert dma_fence_wait() calls back to normal.
Of course interrupting dma_fence_wait is only ok if the caller
specified that, which means we need to split the annotations into
interruptible and non-interruptible version. If we then make sure
that we only use interruptible dma_fence_wait() calls while holding
drm_modeset_lock we can grab them in tdr code, and allow display
resets. Doing the same for dma_resv_lock might be a lot harder, so
buffer updates must be avoided.
What's worse, we're not going to be able to make the dma_fence_wait
calls in mmu-notifiers interruptible, that doesn't work. So
allocating memory still wont' be allowed, even in tdr sections. Plus
obviously we can use this trick only in tdr, it is rather intrusive.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 52f1ab4bc922..a1c091e11ffd 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -281,9 +281,12 @@ static void drm_sched_job_timedout(struct work_struct
*work)
{
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+ bool fence_cookie;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
+ fence_cookie = dma_fence_begin_signalling();
+
/* Protects against concurrent deletion in drm_sched_get_cleanup_job */
spin_lock(>job_list_lock);
job = list_first_entry_or_null(>ring_mirror_list,
@@ -315,6 +318,8 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(>job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(>job_list_lock);
+
+ dma_fence_end_signalling(fence_cookie);
}
/**
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/25] drm/amdgpu: use dma-fence annotations in cs_submit()
This is a bit tricky, since ->notifier_lock is held while calling dma_fence_wait we must ensure that also the read side (i.e. dma_fence_begin_signalling) is on the same side. If we mix this up lockdep complaints, and that's again why we want to have these annotations. A nice side effect of this is that because of the fs_reclaim priming for dma_fence_enable lockdep now automatically checks for us that nothing in here allocates memory, without even running any userptr workloads. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index a512ccbc4dea..858528a06fe7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1212,6 +1212,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, struct amdgpu_job *job; uint64_t seq; int r; + bool fence_cookie; job = p->job; p->job = NULL; @@ -1226,6 +1227,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, */ mutex_lock(>adev->notifier_lock); + fence_cookie = dma_fence_begin_signalling(); + /* If userptr are invalidated after amdgpu_cs_parser_bos(), return * -EAGAIN, drmIoctl in libdrm will restart the amdgpu_cs_ioctl. */ @@ -1262,12 +1265,14 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, amdgpu_vm_move_to_lru_tail(p->adev, >vm); ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence); + dma_fence_end_signalling(fence_cookie); mutex_unlock(>adev->notifier_lock); return 0; error_abort: drm_sched_job_cleanup(>base); + dma_fence_end_signalling(fence_cookie); mutex_unlock(>adev->notifier_lock); error_unlock: -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/25] drm/imx: Annotate dma-fence critical section in commit path
drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.
Aside, I think since the atomic helpers do track plane disabling now
separately this might no longer be a real problem since:
commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
Author: Maarten Lankhorst
Date: Mon Sep 4 12:48:37 2017 +0200
drm/atomic: Fix freeing connector/plane state too early by tracking
commits, v3.
Plus the subsequent bugfixes of course, this was tricky to get right.
Signed-off-by: Daniel Vetter
Cc: Philipp Zabel
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 36037b2e6564..8c209bd36780 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -80,6 +80,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_plane_state *old_plane_state, *new_plane_state;
bool plane_disabling = false;
int i;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -110,6 +111,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
}
drm_atomic_helper_commit_hw_done(state);
+ dma_fence_end_signalling(fence_cookie);
}
static const struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers =
{
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/25] drm/amdgpu: use dma-fence annotations for gpu reset code
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a649e40fd96f..3a3bccd7f1c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4261,6 +4261,9 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
(amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) ?
true : false;
bool audio_suspended = false;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
/*
* Flush RAM to disk so that after reboot
@@ -4289,6 +4292,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another
already in progress",
job ? job->base.id : -1, hive->hive_id);
mutex_unlock(>hive_lock);
+ dma_fence_end_signalling(fence_cookie);
return 0;
}
@@ -4299,8 +4303,10 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
*/
INIT_LIST_HEAD(_list);
if (adev->gmc.xgmi.num_physical_nodes > 1) {
- if (!hive)
+ if (!hive) {
+ dma_fence_end_signalling(fence_cookie);
return -ENODEV;
+ }
if (!list_is_first(>gmc.xgmi.head, >device_list))
list_rotate_to_front(>gmc.xgmi.head,
>device_list);
device_list_handle = >device_list;
@@ -4315,6 +4321,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, as another
already in progress",
job ? job->base.id : -1);
mutex_unlock(>hive_lock);
+ dma_fence_end_signalling(fence_cookie);
return 0;
}
@@ -4455,6 +4462,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
if (r)
dev_info(adev->dev, "GPU reset end with ret = %d\n", r);
+ dma_fence_end_signalling(fence_cookie);
return r;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path
Ends right after drm_atomic_helper_commit_hw_done(), absolutely nothing fancy going on here. Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 482329102f19..42c5dc588435 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state) struct drm_crtc_state *crtc_state; struct drm_crtc *crtc; unsigned int i; + bool fence_cookie = dma_fence_begin_signalling(); /* * Store RGB routing to DPAD0 and DPAD1, the hardware will be configured @@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state) drm_atomic_helper_commit_modeset_enables(dev, old_state); drm_atomic_helper_commit_hw_done(old_state); + dma_fence_end_signalling(fence_cookie); drm_atomic_helper_wait_for_flip_done(dev, old_state); drm_atomic_helper_cleanup_planes(dev, old_state); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
My dma-fence lockdep annotations caught an inversion because we allocate memory where we really shouldn't: kmem_cache_alloc+0x2b/0x6d0 amdgpu_fence_emit+0x30/0x330 [amdgpu] amdgpu_ib_schedule+0x306/0x550 [amdgpu] amdgpu_job_run+0x10f/0x260 [amdgpu] drm_sched_main+0x1b9/0x490 [gpu_sched] kthread+0x12e/0x150 Trouble right now is that lockdep only validates against GFP_FS, which would be good enough for shrinkers. But for mmu_notifiers we actually need !GFP_ATOMIC, since they can be called from any page laundering, even if GFP_NOFS or GFP_NOIO are set. I guess we should improve the lockdep annotations for fs_reclaim_acquire/release. Ofc real fix is to properly preallocate this fence and stuff it into the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of the way. v2: Two more allocations in scheduler paths. Frist one: __kmalloc+0x58/0x720 amdgpu_vmid_grab+0x100/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Second one: kmem_cache_alloc+0x2b/0x6d0 amdgpu_sync_fence+0x7e/0x110 [amdgpu] amdgpu_vmid_grab+0x86b/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c index 8d84975885cd..a089a827fdfe 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c @@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f, uint32_t seq; int r; - fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL); + fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC); if (fence == NULL) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c index 267fa45ddb66..a333ca2d4ddd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) return amdgpu_sync_fence(sync, ring->vmid_wait); - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); + fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC); if (!fences) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c index 8ea6c49529e7..af22b526cec9 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c @@ -160,7 +160,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f) if (amdgpu_sync_add_later(sync, f)) return 0; - e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL); + e = kmem_cache_alloc(amdgpu_sync_slab, GFP_ATOMIC); if (!e) return -ENOMEM; -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/25] drm/amdgpu: DC also loves to allocate stuff where it shouldn't
Not going to bother with a complete commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm_kms_helper]
drm_atomic_helper_commit+0x152/0x180 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
drm_client_modeset_commit_locked+0x55/0x190 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]
v2: Found more in DC code, I'm just going to pile them all up.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 4cfc786699c7..1b0c674fab25 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -1226,7 +1226,7 @@ static int amdgpu_atom_execute_table_locked(struct
atom_context *ctx, int index,
ectx.abort = false;
ectx.last_jump = 0;
if (ws)
- ectx.ws = kcalloc(4, ws, GFP_KERNEL);
+ ectx.ws = kcalloc(4, ws, GFP_ATOMIC);
else
ectx.ws = NULL;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6afcc33ff846..3d41eddc7908 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6872,7 +6872,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dc_stream_update stream_update;
} *bundle;
- bundle = kzalloc(sizeof(*bundle), GFP_KERNEL);
+ bundle = kzalloc(sizeof(*bundle), GFP_ATOMIC);
if (!bundle) {
dm_error("Failed to allocate update bundle\n");
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 942ceb0f6383..f9a58509efb2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1475,8 +1475,10 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
struct dc_state *dc_create_state(struct dc *dc)
{
+ /* No you really cant allocate random crap here this late in
+* atomic_commit_tail. */
struct dc_state *context = kvzalloc(sizeof(struct dc_state),
- GFP_KERNEL);
+ GFP_ATOMIC);
if (!context)
return NULL;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/25] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3d41eddc7908..d6bb876a74e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6949,7 +6949,11 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* explicitly on fences instead
* and in general should be called for
* blocking commit to as per framework helpers
+*
+* Yes, this deadlocks, since you're calling dma_resv_lock in a
+* path that leads to a dma_fence_signal(). Don't do that.
*/
+#if 0
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0))
DRM_ERROR("failed to reserve buffer before flip\n");
@@ -6959,6 +6963,12 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
tmz_surface = amdgpu_bo_encrypted(abo);
amdgpu_bo_unreserve(abo);
+#endif
+ /*
+* this races anyway, so READ_ONCE isn't any better or worse
+* than the stuff above. Except the stuff above can deadlock.
+*/
+ tiling_flags = READ_ONCE(abo->tiling_flags);
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 -
2 files changed, 1 insertion(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 871293d1aeeb..9ec156e98f06 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
void *data)
return IRQ_HANDLED;
}
-struct atmel_hlcdc_dc_commit {
- struct work_struct work;
- struct drm_device *dev;
- struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
- struct drm_device *dev = commit->dev;
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct drm_atomic_state *old_state = commit->state;
-
- /* Apply the atomic update. */
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state, 0);
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-
- drm_atomic_state_put(old_state);
-
- /* Complete the commit, wake up any waiter. */
- spin_lock(>commit.wait.lock);
- dc->commit.pending = false;
- wake_up_all_locked(>commit.wait);
- spin_unlock(>commit.wait.lock);
-
- kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
- struct atmel_hlcdc_dc_commit *commit =
- container_of(work, struct atmel_hlcdc_dc_commit, work);
-
- atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct atmel_hlcdc_dc_commit *commit;
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* Allocate the commit object. */
- commit = kzalloc(sizeof(*commit), GFP_KERNEL);
- if (!commit) {
- ret = -ENOMEM;
- goto error;
- }
-
- INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
- commit->dev = dev;
- commit->state = state;
-
- spin_lock(>commit.wait.lock);
- ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
- if (ret == 0)
- dc->commit.pending = true;
- spin_unlock(>commit.wait.lock);
-
- if (ret)
- goto err_free;
-
- /* We have our own synchronization through the commit lock. */
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /* Swap state succeeded, this is the point of no return. */
- drm_atomic_state_get(state);
- if (async)
- queue_work(dc->wq, >work);
- else
- atmel_hlcdc_dc_atomic_complete(commit);
-
- return 0;
-
-err_free:
- kfree(commit);
-error:
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -716,7 +623,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc->wq)
return -ENOMEM;
- init_waitqueue_head(>commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 469d4507e576..9367a3747a3a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -346,10 +346,6 @@ struct atmel_hlcdc_dc {
u32 imr;
[Intel-gfx] [PATCH 08/25] drm/malidp: Annotate dma-fence critical section in commit path
Again needs to be put right after the call to drm_atomic_helper_commit_hw_done(), since that's the last thing which can hold up a subsequent atomic commit. No surprises here. Signed-off-by: Daniel Vetter Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov --- drivers/gpu/drm/arm/malidp_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 69fee05c256c..26e60401a8e1 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) struct drm_crtc *crtc; struct drm_crtc_state *old_crtc_state; int i; + bool fence_cookie = dma_fence_begin_signalling(); pm_runtime_get_sync(drm->dev); @@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) malidp_atomic_commit_hw_done(state); + dma_fence_end_signalling(fence_cookie); + pm_runtime_put(drm->dev); drm_atomic_helper_cleanup_planes(drm, state); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/25] drm/amdgpu: add dma-fence annotations to atomic commit path
I need a canary in a ttm-based atomic driver to make sure the dma_fence_begin/end_signalling annotations actually work. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 5b0f708dd8c5..6afcc33ff846 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -57,6 +57,7 @@ #include "ivsrcid/ivsrcid_vislands30.h" +#include #include #include #include @@ -7359,6 +7360,9 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) struct drm_connector_state *old_con_state, *new_con_state; struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; int crtc_disable_count = 0; + bool fence_cookie; + + fence_cookie = dma_fence_begin_signalling(); drm_atomic_helper_update_legacy_modeset_state(dev, state); @@ -7639,6 +7643,8 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) /* Signal HW programming completion */ drm_atomic_helper_commit_hw_done(state); + dma_fence_end_signalling(fence_cookie); + if (wait_for_vblank) drm_atomic_helper_wait_for_flip_done(dev, state); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/25] drm/omapdrm: Annotate dma-fence critical section in commit path
Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.
For a bit more clarity pull the hw_done() call out of the if/else,
that way it's a bit clearer flow. But happy to shuffle this around as
is seen fit.
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 4526967978b7..aa3a8034d0ea 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -68,6 +68,7 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
*old_state)
{
struct drm_device *dev = old_state->dev;
struct omap_drm_private *priv = dev->dev_private;
+ bool fence_cookie = dma_fence_begin_signalling();
priv->dispc_ops->runtime_get(priv->dispc);
@@ -90,8 +91,6 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
*old_state)
omap_atomic_wait_for_completion(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
-
- drm_atomic_helper_commit_hw_done(old_state);
} else {
/*
* OMAP3 DSS seems to have issues with the work-around above,
@@ -101,10 +100,12 @@ static void omap_atomic_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_commit_hw_done(old_state);
}
+ drm_atomic_helper_commit_hw_done(old_state);
+
+ dma_fence_end_signalling(fence_cookie);
+
/*
* Wait for completion of the page flips to ensure that old buffers
* can't be touched by the hardware anymore before cleaning up planes.
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path
Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call dma_fence_wait() from signalling critical sections.
Even on our own fence (which this does), it's just a bit confusing.
But in a way those last 2 function calls are already part of the fence
signalling critical section for the next atomic commit.
Reading this I'm wondering why komeda waits for flip_done() before
calling hw_done(), which is a bit backwards (but hey hw can be
special). Might be good to throw a comment in there that explains why,
because the original commit that added this just doesn't.
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 1f6682032ca4..cc5b5915bc5e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -73,6 +73,7 @@ static struct drm_driver komeda_kms_driver = {
static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_cleanup_planes(dev, old_state);
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/25] drm/atomic-helper: Add dma-fence annotations
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
implementations of this hook right now), so bad flag day. And also a
bit leaky abstraction.
Hence just do it function-by-function.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c6bf9722b51b..f67ee513a7cc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1550,6 +1550,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1561,6 +1562,8 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1580,6 +1583,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1592,6 +1596,8 @@ void drm_atomic_helper_commit_tail_rpm(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1607,6 +1613,9 @@ static void commit_tail(struct drm_atomic_state
*old_state)
ktime_t start;
s64 commit_time_ms;
unsigned int i, new_self_refresh_mask = 0;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
funcs = dev->mode_config.helper_private;
@@ -1635,6 +1644,8 @@ static void commit_tail(struct drm_atomic_state
*old_state)
if (new_crtc_state->self_refresh_active)
new_self_refresh_mask |= BIT(i);
+ dma_fence_end_signalling(fence_cookie);
+
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
@@ -1790,6 +1801,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
bool nonblock)
{
int ret;
+ bool fence_cookie;
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -1812,6 +1824,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
+ fence_cookie = dma_fence_begin_signalling();
+
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
@@ -1849,6 +1863,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
*/
drm_atomic_state_get(state);
+ dma_fence_end_signalling(fence_cookie);
if (nonblock)
queue_work(system_unbound_wq, >commit_work);
else
@@ -1857,6 +1872,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
return 0;
err:
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/25] drm/scheduler: use dma-fence annotations in main thread
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no expert on drm scheduler.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index d6eaa23ad746..52f1ab4bc922 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -765,9 +765,12 @@ static int drm_sched_main(void *param)
struct sched_param sparam = {.sched_priority = 1};
struct drm_gpu_scheduler *sched = (struct drm_gpu_scheduler *)param;
int r;
+ bool fence_cookie;
sched_setscheduler(current, SCHED_FIFO, );
+ fence_cookie = dma_fence_begin_signalling();
+
while (!kthread_should_stop()) {
struct drm_sched_entity *entity = NULL;
struct drm_sched_fence *s_fence;
@@ -825,6 +828,9 @@ static int drm_sched_main(void *param)
wake_up(>job_scheduled);
}
+
+ dma_fence_end_signalling(fence_cookie);
+
return 0;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/25] drm/tidss: Annotate dma-fence critical section in commit path
Ends right after hw_done(), totally standard case.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index b6e61d6cf60f..556bc801b77c 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -4,6 +4,8 @@
* Author: Tomi Valkeinen
*/
+#include
+
#include
#include
#include
@@ -26,6 +28,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state
*old_state)
{
struct drm_device *ddev = old_state->dev;
struct tidss_device *tidss = to_tidss(ddev);
+ bool fence_cookie = dma_fence_begin_signalling();
dev_dbg(ddev->dev, "%s\n", __func__);
@@ -36,6 +39,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_commit_modeset_enables(ddev, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_flip_done(ddev, old_state);
drm_atomic_helper_cleanup_planes(ddev, old_state);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/25] dma-fence: prime lockdep annotations
Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mmu notifier callbacks (which amdgpu does, and which i915 sometimes also does, and probably always should, but that's kinda a debate). Also for stuff like HMM we really need to be able to do this, or things get real dicey. Consequence is that any critical path necessary to get to a dma_fence_signal for a fence must never a) call dma_resv_lock nor b) allocate memory with GFP_KERNEL. Also by implication of dma_resv_lock(), no userspace faulting allowed. That's some supremely obnoxious limitations, which is why we need to sprinkle the right annotations to all relevant paths. The one big locking context we're leaving out here is mmu notifiers, added in commit 23b68395c7c78a764e8963fc15a7cfd318bf187f Author: Daniel Vetter Date: Mon Aug 26 22:14:21 2019 +0200 mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end that one covers a lot of other callsites, and it's also allowed to wait on dma-fences from mmu notifiers. But there's no ready-made functions exposed to prime this, so I've left it out for now. v2: Also track against mmu notifier context. v3: kerneldoc to spec the cross-driver contract. Note that currently i915 throws in a hard-coded 10s timeout on foreign fences (not sure why that was done, but it's there), which is why that rule is worded with SHOULD instead of MUST. Also some of the mmu_notifier/shrinker rules might surprise SoC drivers, I haven't fully audited them all. Which is infeasible anyway, we'll need to run them with lockdep and dma-fence annotations and see what goes boom. v4: A spelling fix from Mika v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately this means lockdep enforcement is slightly inconsistent, it won't spot GFP_NOIO and GFP_NOFS allocations in the wrong spot if CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well. v5: Note that only drivers/gpu has a reasonable (or at least historical) excuse to use dma_fence_wait() from shrinker and mmu notifier callbacks. Everyone else should either have a better memory manager model, or better hardware. This reflects discussions with Jason Gunthorpe. Cc: Jason Gunthorpe Cc: Felix Kuehling Cc: kernel test robot Reviewed-by: Thomas Hellström (v4) Cc: Mika Kuoppala Cc: Thomas Hellstrom Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst | 6 drivers/dma-buf/dma-fence.c | 46 drivers/dma-buf/dma-resv.c | 8 + include/linux/dma-fence.h| 1 + 4 files changed, 61 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 05d856131140..f8f6decde359 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -133,6 +133,12 @@ DMA Fences .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: DMA fences overview +DMA Fence Cross-Driver Contract +~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence cross-driver contract + DMA Fence Signalling Annotations diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 0005bc002529..af1d8ea926b3 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -64,6 +64,52 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); * _buf.resv pointer. */ +/** + * DOC: fence cross-driver contract + * + * Since _fence provide a cross driver contract, all drivers must follow the + * same rules: + * + * * Fences must complete in a reasonable time. Fences which represent kernels + * and shaders submitted by userspace, which could run forever, must be backed + * up by timeout and gpu hang recovery code. Minimally that code must prevent + * further command submission and force complete all in-flight fences, e.g. + * when the driver or hardware do not support gpu reset, or if the gpu reset + * failed for some reason. Ideally the driver supports gpu recovery which only + * affects the offending userspace context, and no other userspace + * submissions. + * + * * Drivers may have different ideas of what completion within a reasonable + * time means. Some hang recovery code uses a fixed timeout, others a mix + * between observing forward progress and increasingly strict timeouts. + * Drivers should not try to second guess timeout handling of fences from + * other drivers. + * + * * To ensure there's no
[Intel-gfx] [PATCH 00/25] dma-fence annotations, round 3
Hi all, Bunch of changes that might matter: - Clarification that dma_fences are for drivers/gpu, requested by Jason Gunthorpe. - New patch to list all the past discussions around indefinite/future/whatever fences, and why this (sadly) still just plain doesn't work. Came up again when discussing this stuff, I'd like to just be able to point at some doc going forward. - I rolled dma-fence critical section annotations to (almost, vc4, nouveau and i915 have a bit too much custom commit functions) atomic kms drivers. Really looking for some serious testing with these, aside from the amdgpu atomic commit issues we've also found some problems in vmwgfx commit code. All real issues, and noted in the patches. After the modeset stuff there's still the drm/scheduler annotations. Testing with other drivers than amdgpu using the drm scheduler would be very much welcome. Then the usual pile of amdgpu hacks that I used for developing this. That stuff isn't for merging, I'm hoping amd is working on proper patches for these things. Testing for this series means, especially for the atomic kms drivers: - build with CONFIG_PROVE_LOCKING - run the kms_atomic igt, that one actually uses atomic in fences - withotu these it's only half the fun - run anything else you feel like which might use fences, like your rendering driver. You do have testcases for that right :-) The mmu notifier annotation integration landed in -mm for a few days meanwhile, but I busted it pretty bad. That one needs more baking, I'm trying to figure out how to write unit tests for these annotations so I'm not blowing them up all the time. Also I think it'd be nice if we could start merging some of the earlier stuff maybe, that doest start to feel solid (at least to me). Review, commenst and testing on drivers as per above very much welcome. Thanks, Daniel Daniel Vetter (25): dma-fence: basic lockdep annotations dma-fence: prime lockdep annotations dma-buf.rst: Document why idenfinite fences are a bad idea drm/vkms: Annotate vblank timer drm/vblank: Annotate with dma-fence signalling section drm/amdgpu: add dma-fence annotations to atomic commit path drm/komdea: Annotate dma-fence critical section in commit path drm/malidp: Annotate dma-fence critical section in commit path drm/atmel: Use drm_atomic_helper_commit drm/imx: Annotate dma-fence critical section in commit path drm/omapdrm: Annotate dma-fence critical section in commit path drm/rcar-du: Annotate dma-fence critical section in commit path drm/tegra: Annotate dma-fence critical section in commit path drm/tidss: Annotate dma-fence critical section in commit path drm/tilcdc: Use standard drm_atomic_helper_commit drm/atomic-helper: Add dma-fence annotations drm/scheduler: use dma-fence annotations in main thread drm/amdgpu: use dma-fence annotations in cs_submit() drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code drm/amdgpu: DC also loves to allocate stuff where it shouldn't drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail drm/scheduler: use dma-fence annotations in tdr work drm/amdgpu: use dma-fence annotations for gpu reset code Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" drm/amdgpu: gpu recovery does full modesets Documentation/driver-api/dma-buf.rst | 82 +++ drivers/dma-buf/dma-fence.c | 207 ++ drivers/dma-buf/dma-resv.c| 8 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 22 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- drivers/gpu/drm/amd/amdgpu/atom.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +- .../gpu/drm/arm/display/komeda/komeda_kms.c | 3 + drivers/gpu/drm/arm/malidp_drv.c | 3 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +--- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 - drivers/gpu/drm/drm_atomic_helper.c | 16 ++ drivers/gpu/drm/drm_vblank.c | 8 +- drivers/gpu/drm/imx/imx-drm-core.c| 2 + drivers/gpu/drm/omapdrm/omap_drv.c| 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 + drivers/gpu/drm/scheduler/sched_main.c| 11 + drivers/gpu/drm/tegra/drm.c | 3 + drivers/gpu/drm/tidss/tidss_kms.c | 4 + drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +--- drivers/gpu/drm/virtio/virtgpu_display.c | 20 -- drivers/gpu/drm/vkms/vkms_crtc.c | 8 +- include/linux/dma-fence.h | 13 ++ 27 files changed, 421 insertions(+), 182 deletions(-) -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 04/25] drm/vkms: Annotate vblank timer
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..a53a40848a72 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
+#include
+
#include
#include
#include
@@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
struct drm_crtc *crtc = >crtc;
struct vkms_crtc_state *state;
u64 ret_overrun;
- bool ret;
+ bool ret, fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
output->period_ns);
@@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
DRM_DEBUG_DRIVER("Composer worker already queued\n");
}
+ dma_fence_end_signalling(fence_cookie);
+
return HRTIMER_RESTART;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/25] drm/vblank: Annotate with dma-fence signalling section
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 42a84eb4cc8c..d681ab09963c 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -24,6 +24,7 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
@@ -1909,7 +1910,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
{
struct drm_vblank_crtc *vblank = >vblank[pipe];
unsigned long irqflags;
- bool disable_irq;
+ bool disable_irq, fence_cookie;
if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
return false;
@@ -1917,6 +1918,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return false;
+ fence_cookie = dma_fence_begin_signalling();
+
spin_lock_irqsave(>event_lock, irqflags);
/* Need timestamp lock to prevent concurrent execution with
@@ -1929,6 +1932,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (!vblank->enabled) {
spin_unlock(>vblank_time_lock);
spin_unlock_irqrestore(>event_lock, irqflags);
+ dma_fence_end_signalling(fence_cookie);
return false;
}
@@ -1954,6 +1958,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (disable_irq)
vblank_disable_fn(>disable_timer);
+ dma_fence_end_signalling(fence_cookie);
+
return true;
}
EXPORT_SYMBOL(drm_handle_vblank);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.
v2: Now with dot graph!
Cc: Jesse Natalie
Cc: Steve Pronovost
Cc: Jason Ekstrand
Cc: Felix Kuehling
Cc: Mika Kuoppala
Cc: Thomas Hellstrom
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/dma-buf.rst | 70
drivers/gpu/drm/virtio/virtgpu_display.c | 20 ---
2 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..037ba0078bb4 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
+Idefinite DMA Fences
+
+
+At various times _fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+ any longer, and created with the screen update that makes the buffer visible.
+ The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle _syncobj for which the fence has not yet
+ been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+ that userspace uses for synchronization across engines or with the CPU, which
+ are then imported as a DMA fence for integration into existing winsys
+ protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+ batch DMA fences for memory management instead of context preemption DMA
+ fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not
aware
+ of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+ exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+ :alt: Indefinite Fencing Dependency Cycle
+ :caption: Indefinite Fencing Dependency Cycle
+
+ digraph "Fencing Cycle" {
+ node [shape=box bgcolor=grey style=filled]
+ kernel [label="Kernel DMA Fences"]
+ userspace [label="userspace controlled fences"]
+ kernel -> userspace [label="memory management"]
+ userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+ { rank=same; kernel userspace }
+ }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock. In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+ with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+ userspace is allowed to use userspace fencing or long running compute
+ workloads. This also means no implicit fencing for shared buffers in these
+ cases.
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return _gpu_fb->base;
}
-static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
-{
- struct drm_device *dev =
[Intel-gfx] [PATCH 01/25] dma-fence: basic lockdep annotations
Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't nested the same way under all circumstances, so ABBA deadlocks are ok. Which they are, since this is an annotation only. - We're using non-recursive lockdep read lock mode, since in recursive read lock mode lockdep does not catch read side hazards. And we _very_ much want read side hazards to be caught. For full details of this limitation see commit e91498589746065e3ae95d9a00b068e525eec34f Author: Peter Zijlstra Date: Wed Aug 23 13:13:11 2017 +0200 locking/lockdep/selftests: Add mixed read-write ABBA tests - To allow nesting of the read-side explicit annotations we explicitly keep track of the nesting. lock_is_held() allows us to do that. - The wait-side annotation is a write lock, and entirely done within dma_fence_wait() for everyone by default. - To be able to freely annotate helper functions I want to make it ok to call dma_fence_begin/end_signalling from soft/hardirq context. First attempt was using the hardirq locking context for the write side in lockdep, but this forces all normal spinlocks nested within dma_fence_begin/end_signalling to be spinlocks. That bollocks. The approach now is to simple check in_atomic(), and for these cases entirely rely on the might_sleep() check in dma_fence_wait(). That will catch any wrong nesting against spinlocks from soft/hardirq contexts. The idea here is that every code path that's critical for eventually signalling a dma_fence should be annotated with dma_fence_begin/end_signalling. The annotation ideally starts right after a dma_fence is published (added to a dma_resv, exposed as a sync_file fd, attached to a drm_syncobj fd, or anything else that makes the dma_fence visible to other kernel threads), up to and including the dma_fence_wait(). Examples are irq handlers, the scheduler rt threads, the tail of execbuf (after the corresponding fences are visible), any workers that end up signalling dma_fences and really anything else. Not annotated should be code paths that only complete fences opportunistically as the gpu progresses, like e.g. shrinker/eviction code. The main class of deadlocks this is supposed to catch are: Thread A: mutex_lock(A); mutex_unlock(A); dma_fence_signal(); Thread B: mutex_lock(A); dma_fence_wait(); mutex_unlock(A); Thread B is blocked on A signalling the fence, but A never gets around to that because it cannot acquire the lock A. Note that dma_fence_wait() is allowed to be nested within dma_fence_begin/end_signalling sections. To allow this to happen the read lock needs to be upgraded to a write lock, which means that any other lock is acquired between the dma_fence_begin_signalling() call and the call to dma_fence_wait(), and still held, this will result in an immediate lockdep complaint. The only other option would be to not annotate such calls, defeating the point. Therefore these annotations cannot be sprinkled over the code entirely mindless to avoid false positives. Originally I hope that the cross-release lockdep extensions would alleviate the need for explicit annotations: https://lwn.net/Articles/709849/ But there's a few reasons why that's not an option: - It's not happening in upstream, since it got reverted due to too many false positives: commit e966eaeeb623f09975ef362c2866fae6f86844f9 Author: Ingo Molnar Date: Tue Dec 12 12:31:16 2017 +0100 locking/lockdep: Remove the cross-release locking checks This code (CONFIG_LOCKDEP_CROSSRELEASE=y and CONFIG_LOCKDEP_COMPLETIONS=y), while it found a number of old bugs initially, was also causing too many false positives that caused people to disable lockdep - which is arguably a worse overall outcome. - cross-release uses the complete() call to annotate the end of critical sections, for dma_fence that would be dma_fence_signal(). But we do not want all dma_fence_signal() calls to be treated as critical, since many are opportunistic cleanup of gpu requests. If these get stuck there's still the main completion interrupt and workers who can unblock everyone. Automatically annotating all dma_fence_signal() calls would hence cause false positives. - cross-release had some educated guesses for when a critical section starts, like fresh syscall or fresh work callback. This would again cause false positives without explicit annotations, since for dma_fence the critical sections only starts when we publish a fence. - Furthermore there can be cases where a thread never does a dma_fence_signal, but is still critical for reaching completion of fences. One example would be a
[Intel-gfx] [PATCH 1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
As we have a pin_map interface, that knows how to flush the data to the
device, use it. The only downside is that we keep the kmap around, as
once acquired we keep the mapping cached until the object's backing
store is released.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e866b8d721ed..02a38810bcd3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3880,7 +3880,6 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
struct i915_wa_ctx_bb *wa_bb[2] = { _ctx->indirect_ctx,
_ctx->per_ctx };
wa_bb_func_t wa_bb_fn[2];
- struct page *page;
void *batch, *batch_ptr;
unsigned int i;
int ret;
@@ -3916,14 +3915,14 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return ret;
}
- page = i915_gem_object_get_dirty_page(wa_ctx->vma->obj, 0);
- batch = batch_ptr = kmap_atomic(page);
+ batch = i915_gem_object_pin_map(wa_ctx->vma->obj, I915_MAP_WB);
/*
* Emit the two workaround batch buffers, recording the offset from the
* start of the workaround batch buffer object for each and their
* respective sizes.
*/
+ batch_ptr = batch;
for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
wa_bb[i]->offset = batch_ptr - batch;
if (GEM_DEBUG_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
@@ -3935,10 +3934,10 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
batch_ptr = wa_bb_fn[i](engine, batch_ptr);
wa_bb[i]->size = batch_ptr - (batch + wa_bb[i]->offset);
}
+ GEM_BUG_ON(batch_ptr - batch > CTX_WA_BB_OBJ_SIZE);
- BUG_ON(batch_ptr - batch > CTX_WA_BB_OBJ_SIZE);
-
- kunmap_atomic(batch);
+ __i915_gem_object_flush_map(wa_ctx->vma->obj, 0, batch_ptr - batch);
+ i915_gem_object_unpin_map(wa_ctx->vma->obj);
if (ret)
lrc_destroy_wa_ctx(engine);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Release shortlived maps of longlived objects
Some objects we map once during their construction, and then never
access their mappings again, even if they are kept around for the
duration of the driver. Keeping those pages mapped, often vmapped, is
therefore wasteful and we should release the maps as soon as we no
longer need them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20 +++
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 2 ++
6 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 2faa481cc18f..f9f91ec09a2f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -393,6 +393,7 @@ static inline void i915_gem_object_unpin_map(struct
drm_i915_gem_object *obj)
{
i915_gem_object_unpin_pages(obj);
}
+int i915_gem_object_release_map(struct drm_i915_gem_object *obj);
void
i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index af9e48ee4a33..114256014a97 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -408,6 +408,26 @@ void __i915_gem_object_flush_map(struct
drm_i915_gem_object *obj,
}
}
+int i915_gem_object_release_map(struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ err = mutex_lock_interruptible(>mm.lock);
+ if (err)
+ return err;
+
+ if (atomic_read(>mm.pages_pin_count)) {
+ err = -EBUSY;
+ } else if (obj->mm.mapping) {
+ unmap_object(obj, page_mask_bits(obj->mm.mapping));
+ obj->mm.mapping = NULL;
+ }
+
+ mutex_unlock(>mm.lock);
+
+ return err;
+}
+
struct scatterlist *
i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
unsigned int n,
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index de595b66a746..d2a94002ae6e 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -397,6 +397,7 @@ int gen7_setup_clear_gpr_bb(struct intel_engine_cs * const
engine,
i915_gem_object_flush_map(vma->obj);
i915_gem_object_unpin_map(vma->obj);
+ i915_gem_object_release_map(vma->obj);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 02a38810bcd3..476dfc6be15e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3938,6 +3938,7 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
__i915_gem_object_flush_map(wa_ctx->vma->obj, 0, batch_ptr - batch);
i915_gem_object_unpin_map(wa_ctx->vma->obj);
+ i915_gem_object_release_map(wa_ctx->vma->obj);
if (ret)
lrc_destroy_wa_ctx(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 68a08486fc87..a1e1d24da2fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -544,6 +544,7 @@ alloc_context_vma(struct intel_engine_cs *engine)
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
+ i915_gem_object_release_map(obj);
}
vma = i915_vma_instance(obj, >gt->ggtt->vm, NULL);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 25329b7600c9..34f82e0e912a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1773,6 +1773,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
i915_gem_object_flush_map(bo);
i915_gem_object_unpin_map(bo);
+ i915_gem_object_release_map(bo);
stream->noa_wait = vma;
return 0;
@@ -1868,6 +1869,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
+ i915_gem_object_release_map(obj);
oa_bo->vma = i915_vma_instance(obj,
>engine->gt->ggtt->vm,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Remove i915_gem_object_get_dirty_page()
Last user removed, remove the convenience function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index f9f91ec09a2f..a2d6a83d4d55 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -258,10 +258,6 @@ struct page *
i915_gem_object_get_page(struct drm_i915_gem_object *obj,
unsigned int n);
-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
- unsigned int n);
-
dma_addr_t
i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
unsigned long n,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 114256014a97..5aa9f584b154 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -553,20 +553,6 @@ i915_gem_object_get_page(struct drm_i915_gem_object *obj,
unsigned int n)
return nth_page(sg_page(sg), offset);
}
-/* Like i915_gem_object_get_page(), but mark the returned page dirty */
-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
- unsigned int n)
-{
- struct page *page;
-
- page = i915_gem_object_get_page(obj, n);
- if (!obj->mm.dirty)
- set_page_dirty(page);
-
- return page;
-}
-
dma_addr_t
i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
unsigned long n,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 7/7/20 9:09 PM, Uwe Kleine-König wrote: Hello Hans, On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote: On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: But if we do then I think closest to the truth would be: state->period = UINT_MAX; state->duty_cycle = 0; I'd say state->period = 1 & state->duty_cycle = 0 is a better representation. But that would suggest the output is configured for an infinitely high output frequency, but the frequency is actually 0, the reason why get_state needs to treat a base_unit val of 0 special at all is to avoid a division by 0, and in math dividing by 0 gives infinite, isn't UINT_MAX a better way to represent infinity ? Given that duty_cycle is 0, how can to tell anything about the period when only seeing the signal (= a constant low)? Given that (ideally) a period is completed when pwm_apply_state() is called, a short period is much more sensible. Ok, I will add a patch to v4 of the patch-set to adjust the pwm-lpss driver's get_state method accordingly. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller
Hi Uwe,
On 7/7/20 9:50 AM, Uwe Kleine-König wrote:
Hello Hans,
On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
Note that there is no hard dependency, the atomic API should work just
fine even with a non-converted driver. (Of course a converted driver
behaves better, but the i915 using the atomic API with a non-converted
driver is just as good as the legacy API with the same driver.)
So regarding your plan to get this series in soon: There is no hard need
to halt the efforts for the drm part if the pwm patches take a bit
longer (or vice versa).
I understand, but the main reason to do the conversion to the atomic
API, is to be able to skip the step where we force the backlight
to 100% brightness (which can look quite ugly during boot).
After this patch the intel-panel code initializes its internal
backlight state and the brightness reported under /sys/class/backlight
with the "brightness" returned from the PWM-drivers' get_state callback.
Without getting the PWM patches in first I think that things will
mostly work, but we will always report an initial brightness value
of 0. Lets say it is actually 50% and the user then presses the
increase-brightness hotkey, causing userspace to change it from 0% to 5%
so instead of increasing it by 1/20th, it just decreased it a lot.
So I do believe it is better to get the whole series in as a whole,
since we are at rc4 already (time flies) I guess it might not make it
in this cycle, but that is fine.
Talking about merging this, is it ok for me to push the entire
series upstream through the intel-drm-next-queued branch,
once all the PWM patches have your Ack?
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.
Signed-off-by: Hans de Goede
---
.../drm/i915/display/intel_display_types.h| 3 +-
drivers/gpu/drm/i915/display/intel_panel.c| 73 +--
2 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index de32f9efb120..4bd9981e70a1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
- int pwm_period_ns;
+ struct pwm_state pwm_state;
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index cb28b9908ca4..a0f76343f381 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,11 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
static u32 pwm_get_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = >panel;
- int duty_ns;
+ int duty_ns, period_ns;
duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
- return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+ period_ns = pwm_get_period(panel->backlight.pwm);
The transformation is correct, but using
pwm_get_state(pwm, );
duty_ns = state.duty_cycle;
period_ns = state.period;
is a bit more effective as it calls pwm_get_state() only once.
There is a function pwm_get_relative_duty_cycle which is similar (with
scale = 100) just used different rounding.
Ah nice, that is better then doing our own stuff.
I will switch to that for v4 of this patch-set.
+ return DIV_ROUND_UP(duty_ns * 100, period_ns);
}
static void lpt_set_backlight(const struct drm_connector_state *conn_state, u32 level)
@@ -669,10 +670,10 @@ static void bxt_set_backlight(const struct
drm_connector_state *conn_state, u32
static void pwm_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
{
struct intel_panel *panel =
_intel_connector(conn_state->connector)->panel;
- int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
- pwm_config(panel->backlight.pwm, duty_ns,
- panel->backlight.pwm_period_ns);
+ panel->backlight.pwm_state.duty_cycle =
+ DIV_ROUND_UP(level * panel->backlight.pwm_state.period, 100);
+ pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
}
static void
@@ -841,10 +842,8 @@ static void pwm_disable_backlight(const struct
drm_connector_state *old_conn_sta
struct intel_connector *connector =
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix initial fb to use resource_size_t (rev2)
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18098
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/index.html
Known issues
Here are the changes found in Patchwork_18098 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_store@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@gem_exec_st...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-y/igt@gem_exec_st...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-y/igt@kms_busy@ba...@flip.html
Possible fixes
* igt@gem_render_linear_blits@basic:
- fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [DMESG-WARN][11] ([i915#95]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][13] ([i915#2089] / [i915#750]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#750]:
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
Quoting lepton (2020-07-07 19:17:51) > On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: > > > > Quoting lepton (2020-07-07 18:05:21) > > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > > wrote: > > > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > > allow direct operations like mmap() assuming it behaves as backed by a > > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > > not always meaningful and the shmemfs backing store misleading. > > > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > > > and that rejects attempts to mmap an imported dmabuf, > > > What do you mean by "regular mmap access" here? It looks like vgem is > > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > > > drm_gem_dumb_map_offset > > > > As I too found out, and so had to correct my story telling. > > > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > > igt to see how it was being used. > Now it seems your fix is to disable "regular mmap" on imported dma buf > for vgem. I am not really a graphic guy, but then the api looks like: > for a gem handle, user space has to guess to find out the way to mmap > it. If user space guess wrong, then it will fail to mmap. Is this the > expected way > for people to handle gpu buffer? You either have a dumb buffer handle, or a dma-buf fd. If you have the handle, you have to use the dumb buffer API, there's no other way to mmap it. If you have the dma-buf fd, you should mmap it directly. Those two are clear. It's when you import the dma-buf into vgem and create a handle out of it, that's when the handle is no longer first class and certain uAPI [the dumb buffer API in particular] fail. It's not brilliant, as you say, it requires the user to remember the difference between the handles, but at the same time it does prevent them falling into coherency traps by forcing them to use the right driver to handle the object, and have to consider the additional ioctls that go along with that access. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: > > Quoting lepton (2020-07-07 18:05:21) > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > wrote: > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > allow direct operations like mmap() assuming it behaves as backed by a > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > not always meaningful and the shmemfs backing store misleading. > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > > and that rejects attempts to mmap an imported dmabuf, > > What do you mean by "regular mmap access" here? It looks like vgem is > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > > drm_gem_dumb_map_offset > > As I too found out, and so had to correct my story telling. > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix initial fb to use resource_size_t (rev2)
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40ee693823d1 drm/i915/display: Fix initial fb to use resource_size_t
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#17:
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#23:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
total: 2 errors, 1 warnings, 0 checks, 52 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/display: Fix initial fb to use resource_size_t
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions that we were simply handling offsets into the
GGTT not generic addresses/offsets].
We made the switch to using resource_size_t for stolen in commit
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
v2: Expand the intel_initial_plane_config struct as well to accommodate
any possible location.
Reported-by: Tvrtko Ursulin
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 15 ---
.../gpu/drm/i915/display/intel_display_types.h| 4 ++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dff7c17f3d2b..9fd18b3dbb37 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- u32 base, size;
+ resource_size_t base;
+ resource_size_t size;
if (plane_config->size == 0)
return NULL;
@@ -9319,13 +9320,13 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
aligned_height = intel_fb_align_height(fb, 0, fb->height);
- plane_config->size = fb->pitches[0] * aligned_height;
+ plane_config->size = mul_u32_u32(fb->pitches[0], aligned_height);
drm_dbg_kms(_priv->drm,
- "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%x\n",
+ "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%pa\n",
crtc->base.name, plane->base.name, fb->width, fb->height,
fb->format->cpp[0] * 8, base, fb->pitches[0],
- plane_config->size);
+ _config->size);
plane_config->fb = intel_fb;
}
@@ -10595,13 +10596,13 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
aligned_height = intel_fb_align_height(fb, 0, fb->height);
- plane_config->size = fb->pitches[0] * aligned_height;
+ plane_config->size = mul_u32_u32(fb->pitches[0], aligned_height);
drm_dbg_kms(_priv->drm,
- "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%x\n",
+ "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%pa\n",
crtc->base.name, plane->base.name, fb->width, fb->height,
fb->format->cpp[0] * 8, base, fb->pitches[0],
- plane_config->size);
+ _config->size);
plane_config->fb = intel_fb;
return;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e8f809161c75..75cbf00f5c9b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -591,9 +591,9 @@ struct intel_plane_state {
struct intel_initial_plane_config {
struct intel_framebuffer *fb;
struct i915_vma *vma;
+ resource_size_t base;
+ resource_size_t size;
unsigned int tiling;
- int size;
- u32 base;
u8 rotation;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix initial fb to use resource_size_t
Quoting Tvrtko Ursulin (2020-07-07 18:48:23)
>
> On 07/07/2020 18:15, Chris Wilson wrote:
> > We lookup up the physical address of the inherited framebuffer, and
> > presume that is an offset into the stolen memory region. As we are
> > dealing with physical resources and their addresses, we need to use
> > resource_size_t and not assume everything fits within a plain u32 [based
> > on prior assumptions that we were simpling handling offsets into the
> > GGTT not physical memory].
> >
> > We made the switch to using resource_size_t for stolen in commit
> > b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
> >
> > Reported-by: Tvrtko Ursulin
> > References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
> > stolen")
> > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä
> > Cc: Tvrtko Ursulin
> > Cc: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index dff7c17f3d2b..6bfe3148f927 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
> > {
> > struct drm_i915_gem_object *obj;
> > struct i915_vma *vma;
> > - u32 base, size;
> > + resource_size_t base;
> > + resource_size_t size;
> >
> > if (plane_config->size == 0)
> > return NULL;
> >
>
> There is also:
>
> base = round_down(plane_config->base,
> I915_GTT_MIN_ALIGNMENT);
>
> struct intel_initial_plane_config {
> struct intel_framebuffer *fb;
> struct i915_vma *vma;
> unsigned int tiling;
> int size;
> u32 base;
> u8 rotation;
> };
>
> So not sure, just throwing it out there.
In for a penny, in for a pound.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix initial fb to use resource_size_t
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18097
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/index.html
Known issues
Here are the changes found in Patchwork_18097 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-byt-j1900/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][9] ([i915#95]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][11] ([i915#2089] / [i915#750]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@mmap:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@vgem_ba...@mmap.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-y/igt@vgem_ba...@mmap.html
Warnings
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix initial fb to use resource_size_t
On 07/07/2020 18:15, Chris Wilson wrote:
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions that we were simpling handling offsets into the
GGTT not physical memory].
We made the switch to using resource_size_t for stolen in commit
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
Reported-by: Tvrtko Ursulin
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dff7c17f3d2b..6bfe3148f927 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- u32 base, size;
+ resource_size_t base;
+ resource_size_t size;
if (plane_config->size == 0)
return NULL;
There is also:
base = round_down(plane_config->base,
I915_GTT_MIN_ALIGNMENT);
struct intel_initial_plane_config {
struct intel_framebuffer *fb;
struct i915_vma *vma;
unsigned int tiling;
int size;
u32 base;
u8 rotation;
};
So not sure, just throwing it out there.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix initial fb to use resource_size_t
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f694486df0d8 drm/i915/display: Fix initial fb to use resource_size_t
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#17:
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#20:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
total: 2 errors, 1 warnings, 0 checks, 9 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
>
> If we assign obj->filp, we believe that the create vgem bo is native and
> allow direct operations like mmap() assuming it behaves as backed by a
> shmemfs inode. When imported from a dmabuf, the obj->pages are
> not always meaningful and the shmemfs backing store misleading.
>
> Note, that regular mmap access to a vgem bo is via the dumb buffer API,
> and that rejects attempts to mmap an imported dmabuf,
What do you mean by "regular mmap access" here? It looks like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
drm_gem_dumb_map_offset
>
> drm_gem_dumb_map_offset():
> if (obj->import_attach) return -EINVAL;
>
> So the only route by which we might accidentally allow mmapping of an
> imported buffer is via vgem_prime_mmap(), which checked for
> obj->filp assuming that it would be NULL.
>
> Well it would had it been updated to use the common
> drm_gem_dum_map_offset() helper, instead it has
>
> vgem_gem_dumb_map():
> if (!obj->filp) return -EINVAL;
>
> falling foul of the same trap as above.
>
> Reported-by: Lepton Wu
> Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
> Signed-off-by: Chris Wilson
> Cc: Lepton Wu
> Cc: Daniel Vetter
> Cc: Christian König
> Cc: Thomas Hellström (Intel)
> Cc: # v4.13+
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 909eba43664a..eb3b7cdac941 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> ret = 0;
> }
> mutex_unlock(>pages_lock);
> - if (ret) {
> + if (ret && obj->base.filp) {
> struct page *page;
>
> page = shmem_read_mapping_page(
> @@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct
> drm_file *file)
> }
>
> static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
> - unsigned long size)
> +struct file *shmem,
> +unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> int ret;
> @@ -166,11 +167,8 @@ static struct drm_vgem_gem_object
> *__vgem_gem_create(struct drm_device *dev,
> if (!obj)
> return ERR_PTR(-ENOMEM);
>
> - ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
> - if (ret) {
> - kfree(obj);
> - return ERR_PTR(ret);
> - }
> + drm_gem_private_object_init(dev, >base, size);
> + obj->base.filp = shmem;
>
> mutex_init(>pages_lock);
>
> @@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct
> drm_device *dev,
> unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> + struct file *shmem;
> int ret;
>
> - obj = __vgem_gem_create(dev, size);
> - if (IS_ERR(obj))
> + size = roundup(size, PAGE_SIZE);
> +
> + shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
> + if (IS_ERR(shmem))
> + return ERR_CAST(shmem);
> +
> + obj = __vgem_gem_create(dev, shmem, size);
> + if (IS_ERR(obj)) {
> + fput(shmem);
> return ERR_CAST(obj);
> + }
>
> ret = drm_gem_handle_create(file, >base, handle);
> if (ret) {
> @@ -363,7 +370,7 @@ static struct drm_gem_object
> *vgem_prime_import_sg_table(struct drm_device *dev,
> struct drm_vgem_gem_object *obj;
> int npages;
>
> - obj = __vgem_gem_create(dev, attach->dmabuf->size);
> + obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
> if (IS_ERR(obj))
> return ERR_CAST(obj);
>
> --
> 2.27.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: Hi, Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 43b1fc634af1..80d0f9c64f9d 100644 --- a/drivers/pwm/pwm-lpss.c +++ b/drivers/pwm/pwm-lpss.c @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, freq *= base_unit_range; base_unit = DIV_ROUND_CLOSEST_ULL(freq, c); DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend the time to actually confirm that. Yes I saw your comment elsewhere that the PWM API defines rounding in a certain direction, but fixing that falls outside of this patch. Yeah, sure. [...] I hope this helps to explain what is going on a bit. I will try to make sense of that and reply to the patch directly when I succeeded. ### As for the behavior on base_unit==0 in the get_state method, as mentioned above I wrote that when I did not fully understood how the controller works. We really should never encounter this. But if we do then I think closest to the truth would be: state->period = UINT_MAX; state->duty_cycle = 0; I'd say state->period = 1 & state->duty_cycle = 0 is a better representation. But that would suggest the output is configured for an infinitely high output frequency, but the frequency is actually 0, the reason why get_state needs to treat a base_unit val of 0 special at all is to avoid a division by 0, and in math dividing by 0 gives infinite, isn't UINT_MAX a better way to represent infinity ? Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
Quoting lepton (2020-07-07 18:05:21) > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote: > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > allow direct operations like mmap() assuming it behaves as backed by a > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > not always meaningful and the shmemfs backing store misleading. > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > and that rejects attempts to mmap an imported dmabuf, > What do you mean by "regular mmap access" here? It looks like vgem is > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > drm_gem_dumb_map_offset As I too found out, and so had to correct my story telling. By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer API] as opposed to mmap() via an exported dma-buf fd. I had to look at igt to see how it was being used. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/display: Fix initial fb to use resource_size_t
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions that we were simpling handling offsets into the
GGTT not physical memory].
We made the switch to using resource_size_t for stolen in commit
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
Reported-by: Tvrtko Ursulin
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dff7c17f3d2b..6bfe3148f927 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- u32 base, size;
+ resource_size_t base;
+ resource_size_t size;
if (plane_config->size == 0)
return NULL;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Unpin idle contexts from kswapd reclaim
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18096
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/index.html
Known issues
Here are the changes found in Patchwork_18096 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_addfb_basic@bad-pitch-32:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-32.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-32.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][5] ([i915#95]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@mmap:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@vgem_ba...@mmap.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-tgl-y/igt@vgem_ba...@mmap.html
Warnings
* igt@kms_flip@basic-plain-flip@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 35)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-tgl-u2 fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8710 -> Patchwork_18096
CI-20190529: 20190529
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Unpin idle contexts from kswapd reclaim
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9357a85637f9 drm/i915/gem: Unpin idle contexts from kswapd reclaim
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker
paths")
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9e9539800dd4 ("drm/i915: Remove
waiting & retiring from shrinker paths")'
#25:
References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker
paths")
total: 1 errors, 1 warnings, 0 checks, 75 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
== Series Details == Series: series starting with [1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object URL : https://patchwork.freedesktop.org/series/79203/ State : failure == Summary == Applying: drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object Applying: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() error: sha1 information is lacking or useless (drivers/gpu/drm/vgem/vgem_drv.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Unpin idle contexts from kswapd reclaim
We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are flushed by a heartbeat pulse following the last retired
request along their timeline. In order to ensure that pulse occurs in
time for memory reclamation, we should kick it from kswapd.
The catch is that we have added some flush_work() into the retirement
phase (to ensure that we reach a global idle in a timely manner), but
these flush_work() are not eligible (i.e do not belong to WQ_MEM_RELCAIM)
for use from inside kswapd. To avoid flushing those workqueues, we teach
the retirer not to do so unless we are actually waiting, and only do the
plain retire from inside the shrinker.
Note that for execlists, we already retire completed contexts as they
are scheduled out, so it should not be keeping global state
unnecessarily pinned. The legacy ringbuffer however...
References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker
paths")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 25 +---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 ---
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 1ced1e5d2ec0..dc8f052a0ffe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -13,6 +13,8 @@
#include
#include
+#include "gt/intel_gt_requests.h"
+
#include "i915_trace.h"
static bool swap_available(void)
@@ -111,15 +113,6 @@ i915_gem_shrink(struct drm_i915_private *i915,
unsigned long count = 0;
unsigned long scanned = 0;
- /*
-* When shrinking the active list, we should also consider active
-* contexts. Active contexts are pinned until they are retired, and
-* so can not be simply unbound to retire and unpin their pages. To
-* shrink the contexts, we must wait until the gpu is idle and
-* completed its switch to the kernel context. In short, we do
-* not have a good mechanism for idling a specific context.
-*/
-
trace_i915_gem_shrink(i915, target, shrink);
/*
@@ -133,6 +126,20 @@ i915_gem_shrink(struct drm_i915_private *i915,
shrink &= ~I915_SHRINK_BOUND;
}
+ /*
+* When shrinking the active list, we should also consider active
+* contexts. Active contexts are pinned until they are retired, and
+* so can not be simply unbound to retire and unpin their pages. To
+* shrink the contexts, we must wait until the gpu is idle and
+* completed its switch to the kernel context. In short, we do
+* not have a good mechanism for idling a specific context, but
+* what we can do is give them a kick so that we do not keep idle
+* contexts around longer than is necessary.
+*/
+ if (shrink & I915_SHRINK_ACTIVE)
+ /* Retire requests to unpin all idle contexts */
+ intel_gt_retire_requests(>gt);
+
/*
* As we may completely rewrite the (un)bound list whilst unbinding
* (due to retiring requests) we have to strictly process only
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 16ff47c83bd5..66fcbf9d0fdd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -31,12 +31,15 @@ static bool engine_active(const struct intel_engine_cs
*engine)
return !list_empty(>kernel_context->timeline->requests);
}
-static bool flush_submission(struct intel_gt *gt)
+static bool flush_submission(struct intel_gt *gt, long timeout)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
bool active = false;
+ if (!timeout)
+ return false;
+
if (!intel_gt_pm_is_awake(gt))
return false;
@@ -139,7 +142,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
if (unlikely(timeout < 0))
timeout = -timeout, interruptible = false;
- flush_submission(gt); /* kick the ksoftirqd tasklets */
+ flush_submission(gt, timeout); /* kick the ksoftirqd tasklets */
spin_lock(>lock);
list_for_each_entry_safe(tl, tn, >active_list, link) {
if (!mutex_trylock(>mutex)) {
@@ -194,7 +197,7 @@ out_active: spin_lock(>lock);
list_for_each_entry_safe(tl, tn, , link)
__intel_timeline_free(>kref);
- if (flush_submission(gt)) /* Wait, there's more! */
+ if (flush_submission(gt, timeout)) /* Wait, there's more! */
active_count++;
return
[Intel-gfx] [PATCH 2/2] drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index eb3b7cdac941..866cff537f28 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -236,32 +236,6 @@ static int vgem_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
return 0;
}
-static int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
-uint32_t handle, uint64_t *offset)
-{
- struct drm_gem_object *obj;
- int ret;
-
- obj = drm_gem_object_lookup(file, handle);
- if (!obj)
- return -ENOENT;
-
- if (!obj->filp) {
- ret = -EINVAL;
- goto unref;
- }
-
- ret = drm_gem_create_mmap_offset(obj);
- if (ret)
- goto unref;
-
- *offset = drm_vma_node_offset_addr(>vma_node);
-unref:
- drm_gem_object_put_unlocked(obj);
-
- return ret;
-}
-
static struct drm_ioctl_desc vgem_ioctls[] = {
DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl,
DRM_RENDER_ALLOW),
@@ -455,7 +429,7 @@ static struct drm_driver vgem_driver = {
.fops = _driver_fops,
.dumb_create= vgem_gem_dumb_create,
- .dumb_map_offset= vgem_gem_dumb_map,
+ .dumb_map_offset= drm_gem_dumb_map_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.
Note, that regular mmap access to a vgem bo is via the dumb buffer API,
and that rejects attempts to mmap an imported dmabuf,
drm_gem_dumb_map_offset():
if (obj->import_attach) return -EINVAL;
So the only route by which we might accidentally allow mmapping of an
imported buffer is via vgem_prime_mmap(), which checked for
obj->filp assuming that it would be NULL.
Well it would had it been updated to use the common
drm_gem_dum_map_offset() helper, instead it has
vgem_gem_dumb_map():
if (!obj->filp) return -EINVAL;
falling foul of the same trap as above.
Reported-by: Lepton Wu
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Signed-off-by: Chris Wilson
Cc: Lepton Wu
Cc: Daniel Vetter
Cc: Christian König
Cc: Thomas Hellström (Intel)
Cc: # v4.13+
---
drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 909eba43664a..eb3b7cdac941 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
ret = 0;
}
mutex_unlock(>pages_lock);
- if (ret) {
+ if (ret && obj->base.filp) {
struct page *page;
page = shmem_read_mapping_page(
@@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
}
static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
- unsigned long size)
+struct file *shmem,
+unsigned long size)
{
struct drm_vgem_gem_object *obj;
int ret;
@@ -166,11 +167,8 @@ static struct drm_vgem_gem_object
*__vgem_gem_create(struct drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
- ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
- if (ret) {
- kfree(obj);
- return ERR_PTR(ret);
- }
+ drm_gem_private_object_init(dev, >base, size);
+ obj->base.filp = shmem;
mutex_init(>pages_lock);
@@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct
drm_device *dev,
unsigned long size)
{
struct drm_vgem_gem_object *obj;
+ struct file *shmem;
int ret;
- obj = __vgem_gem_create(dev, size);
- if (IS_ERR(obj))
+ size = roundup(size, PAGE_SIZE);
+
+ shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
+ if (IS_ERR(shmem))
+ return ERR_CAST(shmem);
+
+ obj = __vgem_gem_create(dev, shmem, size);
+ if (IS_ERR(obj)) {
+ fput(shmem);
return ERR_CAST(obj);
+ }
ret = drm_gem_handle_create(file, >base, handle);
if (ret) {
@@ -363,7 +370,7 @@ static struct drm_gem_object
*vgem_prime_import_sg_table(struct drm_device *dev,
struct drm_vgem_gem_object *obj;
int npages;
- obj = __vgem_gem_create(dev, attach->dmabuf->size);
+ obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
if (IS_ERR(obj))
return ERR_CAST(obj);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind
== Series Details == Series: series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind URL : https://patchwork.freedesktop.org/series/79183/ State : success == Summary == CI Bug Log - changes from CI_DRM_8709_full -> Patchwork_18093_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18093_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#1930]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-glk5/igt@gem_exec_whis...@basic-contexts-priority.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#95]) +13 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-apl8/igt@kms_big...@x-tiled-8bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-apl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-glk5/igt@kms_big...@y-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-kbl2/igt@kms_co...@pipe-a-gamma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-kbl4/igt@kms_co...@pipe-a-gamma.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-skl7/igt@kms_co...@pipe-c-ctm-0-25.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-skl2/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#49]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-skl5/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-vs-premult-vs-constant: - shard-kbl: [PASS][17] -> [DMESG-FAIL][18] ([fdo#108145] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-kbl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-kbl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html - shard-apl: [PASS][19] -> [DMESG-FAIL][20] ([fdo#108145] / [i915#1635] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-apl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]:
Re: [Intel-gfx] [PATCH v7 09/36] drm: i915: fix common struct sg_table related issues
Hi
On 19.06.2020 12:36, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> This driver creatively uses sg_table->orig_nents to store the size of the
> allocated scatterlist and ignores the number of the entries returned by
> dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
> free the (over)allocated scatterlist.
>
> This patch only introduces the common DMA-mapping wrappers operating
> directly on the struct sg_table objects to the dmabuf related functions,
> so the other drivers, which might share buffers with i915 could rely on
> the properly set nents and orig_nents values.
>
> Signed-off-by: Marek Szyprowski
May I ask for a review/ack/comment for this patch?
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
> 2 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 2679380159fc..8a988592715b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> dma_buf_attachment *attachme
> src = sg_next(src);
> }
>
> - if (!dma_map_sg_attrs(attachment->dev,
> - st->sgl, st->nents, dir,
> - DMA_ATTR_SKIP_CPU_SYNC)) {
> - ret = -ENOMEM;
> + ret = dma_map_sgtable(attachment->dev, st, dir, DMA_ATTR_SKIP_CPU_SYNC);
> + if (ret)
> goto err_free_sg;
> - }
>
> return st;
>
> @@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
> dma_buf_attachment *attachment,
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
>
> - dma_unmap_sg_attrs(attachment->dev,
> -sg->sgl, sg->nents, dir,
> -DMA_ATTR_SKIP_CPU_SYNC);
> + dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sg);
> kfree(sg);
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> index debaf7b18ab5..be30b27e2926 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> @@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
> dma_buf_attachment *attachment,
> sg = sg_next(sg);
> }
>
> - if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
> - err = -ENOMEM;
> + err = dma_map_sgtable(attachment->dev, st, dir, 0);
> + if (err)
> goto err_st;
> - }
>
> return st;
>
> @@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct dma_buf_attachment
> *attachment,
> struct sg_table *st,
> enum dma_data_direction dir)
> {
> - dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
> + dma_unmap_sgtable(attachment->dev, st, dir, 0);
> sg_free_table(st);
> kfree(st);
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix spelling mistake in i915_reg.h (rev2)
== Series Details == Series: drm/i915: Fix spelling mistake in i915_reg.h (rev2) URL : https://patchwork.freedesktop.org/series/79156/ State : failure == Summary == Applying: drm/i915: Fix spelling mistake in i915_reg.h Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_reg.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_reg.h No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/15] pwm: crc: Implement get_state() method
Hello Hans, On Mon, Jul 06, 2020 at 11:05:20PM +0200, Hans de Goede wrote: > Before I post a new version of this patch-set, you have only responded > to some of the PWM patches in this set. Do you have any remarks on the > other PWM patches ? I stopped looking at them as I hoped someone would appear with a datasheet. Given that this probably won't happen I can take a look at the remaining patches. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable
Hello,
On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this commit makes crc_pwm_disable() clear it on disable and makes
> crc_pwm_enable() set it again on re-enable.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Remove paragraph about tri-stating the output from the commit message,
> we don't have a datasheet so this was just an unfounded guess
> ---
> drivers/pwm/pwm-crc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> index 81232da0c767..b72008c9b072 100644
> --- a/drivers/pwm/pwm-crc.c
> +++ b/drivers/pwm/pwm-crc.c
> @@ -54,7 +54,9 @@ static int crc_pwm_calc_clk_div(int period_ns)
> static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
> {
> struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
> + int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
>
> + regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
> regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
>
> return 0;
> @@ -63,8 +65,10 @@ static int crc_pwm_enable(struct pwm_chip *c, struct
> pwm_device *pwm)
> static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
> {
> struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
> + int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
>
> regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
> + regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
> }
>
> static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
In the absence of documentation this looks reasonable.
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915: Fix spelling mistake in i915_reg.h
Fix typo: "TRIGER" --> "TRIGGER" The two misplelled macros: 1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK are not used in any other sources of the kernel, so this change can be consider only a local change for the i915_reg.h file. Signed-off-by: Flavio Suligoi Reviewed-by: Chris Wilson --- v1: add "Reviewed-by: Chris Wilson " drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9d6536afc94b..c2153364724a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -868,7 +868,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OAREPORTTRIG1 _MMIO(0x2740) #define OAREPORTTRIG1_THRESHOLD_MASK 0x -#define OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ +#define OAREPORTTRIG1_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ #define OAREPORTTRIG2 _MMIO(0x2744) #define OAREPORTTRIG2_INVERT_A_0 (1 << 0) @@ -921,7 +921,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OAREPORTTRIG5 _MMIO(0x2750) #define OAREPORTTRIG5_THRESHOLD_MASK 0x -#define OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ +#define OAREPORTTRIG5_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ #define OAREPORTTRIG6 _MMIO(0x2754) #define OAREPORTTRIG6_INVERT_A_0 (1 << 0) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
