[Intel-gfx] ✓ Fi.CI.IGT: success for softirq: Kick ksoftirqd if __do_softirq() is incomplete
== Series Details == Series: softirq: Kick ksoftirqd if __do_softirq() is incomplete URL : https://patchwork.freedesktop.org/series/77508/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517_full -> Patchwork_17748_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17748_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl4/igt@gem_workarou...@suspend-resume-context.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#54]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109349]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#177] / [i915#52] / [i915#54] / [i915#93] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-kbl6/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#64]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-glk5/igt@kms_fbcon_...@fbc-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-glk6/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#165]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl4/igt@kms_...@bpc-switch-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-kbl2/igt@kms_...@bpc-switch-suspend.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#53] / [i915#93] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl2/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-kbl4/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html - shard-apl: [PASS][17] -> [FAIL][18] ([i915#53] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-apl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_psr2...@frontbuffer.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-iclb8/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/shard-iclb8/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_setmode@basic: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#31]) [25]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range
== Series Details == Series: drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range URL : https://patchwork.freedesktop.org/series/77529/ State : success == Summary == CI Bug Log - changes from CI_DRM_8523 -> Patchwork_17755 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17755/index.html Known issues Here are the changes found in Patchwork_17755 that come from known issues: ### IGT changes ### Possible fixes * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[INCOMPLETE][1] ([i915#1250] / [i915#1436]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8523/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17755/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 Participating hosts (47 -> 42) -- Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8523 -> Patchwork_17755 CI-20190529: 20190529 CI_DRM_8523: f96c380f22d4a7808efbab0fccee2e95a0dc10ad @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5672: 4653b6464daf3403c22b8ce7d8e376d9ee6cb493 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17755: e1781eb0d5c008c72d2024e723c8cfe4f1f940eb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e1781eb0d5c0 drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17755/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Trace the CS interrupt (rev10)
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev10) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517_full -> Patchwork_17747_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17747_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@bcs0: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-skl7/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#69]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl6/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-skl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl6/igt@gem_soft...@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-kbl2/igt@gem_soft...@noreloc-s3.html * igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#72]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-glk1/igt@kms_cursor_leg...@2x-flip-vs-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-glk6/igt@kms_cursor_leg...@2x-flip-vs-cursor-legacy.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109349]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-iclb1/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#177] / [i915#52] / [i915#54] / [i915#93] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html * igt@kms_flip_tiling@flip-to-y-tiled: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#167]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl4/igt@kms_flip_til...@flip-to-y-tiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-skl3/igt@kms_flip_til...@flip-to-y-tiled.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#53] / [i915#93] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl2/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-kbl7/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html - shard-apl: [PASS][17] -> [FAIL][18] ([i915#53] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-apl4/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - 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_8517/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_psr2...@frontbuffer.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/shard-iclb1/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_primary_render: - shard-iclb: [PASS][25] ->
[Intel-gfx] [PATCH] drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range
Since the userptr may be invalidated from inside a reclaim path, we cannot wait on unbinding the object as we may hold any number of locks, including the active reference of the object we are trying to invalidate. E.g. [<0>] __i915_active_wait+0x70/0xc0 [i915] [<0>] i915_vma_unbind+0x2f/0x110 [i915] [<0>] i915_gem_object_unbind+0x17c/0x350 [i915] [<0>] userptr_mn_invalidate_range_start+0xb6/0x140 [i915] [<0>] __mmu_notifier_invalidate_range_start+0x105/0x150 [<0>] try_to_unmap_one+0x7fb/0x900 [<0>] rmap_walk_file+0xe4/0x240 [<0>] try_to_unmap+0x85/0xc0 [<0>] shrink_page_list+0x885/0xe80 [<0>] shrink_inactive_list+0x155/0x260 [<0>] shrink_lruvec+0x4ec/0x5f0 [<0>] shrink_node+0x15b/0x410 [<0>] try_to_free_pages+0x169/0x3a0 [<0>] __alloc_pages_slowpath.constprop.0+0x251/0xa00 [<0>] __alloc_pages_nodemask+0x144/0x170 [<0>] new_slab+0x259/0x280 [<0>] ___slab_alloc.isra.0.constprop.0+0x3dd/0x460 [<0>] __slab_alloc.isra.0.constprop.0+0x9/0x10 [<0>] kmem_cache_alloc+0x11a/0x130 [<0>] alloc_pd+0x17/0x60 [i915] [<0>] __gen8_ppgtt_alloc+0x2d7/0x350 [i915] [<0>] gen8_ppgtt_alloc+0x35/0x70 [i915] [<0>] ppgtt_bind_vma+0x29/0x70 [i915] This situation only occurs when the lru page shrinker tries to sacrifice one the objects it is trying to allocate for. However, we do have to wait for an active object so that we can revoke access to the page range. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1702 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index 8b0708708671..a398d817543e 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -126,9 +126,11 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn, } spin_unlock(>lock); - ret = i915_gem_object_unbind(obj, -I915_GEM_OBJECT_UNBIND_ACTIVE | -I915_GEM_OBJECT_UNBIND_BARRIER); + ret = i915_gem_object_wait(obj, + I915_WAIT_ALL, + MAX_SCHEDULE_TIMEOUT); + if (ret == 0) + ret = i915_gem_object_unbind(obj, 0); if (ret == 0) ret = __i915_gem_object_put_pages(obj); i915_gem_object_put(obj); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"
Quoting John Hubbard (2020-05-22 00:38:41)
> Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
> on, in internal_get_user_pages_fast().
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: "Joonas Lahtinen"
> Cc: Matthew Auld
> Cc: Matthew Wilcox
> Cc: Rodrigo Vivi
> Cc: Souptick Joarder
> Cc: Tvrtko Ursulin
> Signed-off-by: John Hubbard
> ---
>
> Hi Andrew, Chris,
>
> Andrew: This is a fixup that applies to today's (20200521) linux-next.
> In that tree, this fixes up:
>
> commit dfb8dfe80808 ("mm/gup: refactor and de-duplicate gup_fast() code")
>
> Chris: I'd like to request another CI run for the drm/i915 changes, so
> for that, would you prefer that I post a v2 of the series [1], or
> is it easier for you to just apply this patch here, on top of [2]?
If you post your series again with this patch included to intel-gfx, CI
will pick it up. Or I'll do that in the morning.
-Chris
___
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 drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2)
== Series Details == Series: series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77503/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517_full -> Patchwork_17746_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17746_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl6/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-skl5/igt@gem_...@in-flight-suspend.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl8/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-apl4/igt@gen9_exec_pa...@allowed-all.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109349]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-iclb6/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#177] / [i915#52] / [i915#54] / [i915#93] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-kbl7/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#53] / [i915#93] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-kbl2/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-kbl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html - shard-apl: [PASS][13] -> [FAIL][14] ([i915#53] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-apl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_psr2...@frontbuffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-iclb6/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_setmode@basic: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-skl8/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-skl7/igt@kms_setm...@basic.html Possible fixes * igt@gem_softpin@noreloc-s3: - shard-apl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/shard-apl1/igt@gem_soft...@noreloc-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/shard-apl7/igt@gem_soft...@noreloc-s3.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-random: - shard-skl: [FAIL][25] ([i915#54]) -> [PASS][26] [25]:
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)
On Thu, 2020-05-21 at 21:43 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)
> URL : https://patchwork.freedesktop.org/series/77382/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8516_full -> Patchwork_17742_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Pushed to dinq, thanks for the patch.
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_17742_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_ctx_persistence@engines-mixed-process@vcs0:
> - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528])
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl2/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
>
> * igt@gen9_exec_parse@allowed-all:
> - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] /
> [i915#716])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-glk2/igt@gen9_exec_pa...@allowed-all.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-glk9/igt@gen9_exec_pa...@allowed-all.html
>
> * igt@kms_cursor_crc@pipe-b-cursor-suspend:
> - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1
> similar issue
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html
>
> * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
> - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#108145] / [i915#265])
> +3 similar issues
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
>
> * igt@kms_plane_cursor@pipe-a-overlay-size-256:
> - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#1559] / [i915#93] /
> [i915#95])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl7/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-kbl3/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
> - shard-apl: [PASS][11] -> [FAIL][12] ([i915#1559] / [i915#95])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-apl8/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-apl7/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
>
> * igt@kms_psr@psr2_cursor_render:
> - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar
> issues
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-iclb3/igt@kms_psr@psr2_cursor_render.html
>
>
> Possible fixes
>
> * igt@i915_pm_rpm@system-suspend:
> - shard-skl: [INCOMPLETE][15] ([i915#151] / [i915#69]) ->
> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl10/igt@i915_pm_...@system-suspend.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-skl6/igt@i915_pm_...@system-suspend.html
>
> * {igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2}:
> - shard-glk: [FAIL][17] ([i915#79]) -> [PASS][18]
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-glk2/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
>
> * {igt@kms_flip@flip-vs-suspend-interruptible@a-dp1}:
> - shard-apl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +11
> similar issues
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-apl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-apl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
>
> * igt@kms_flip_tiling@flip-changes-tiling-yf:
> - shard-kbl: [FAIL][21] ([i915#699] / [i915#93] / [i915#95]) ->
> [PASS][22]
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl6/igt@kms_flip_til...@flip-changes-tiling-yf.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling-yf.html
>
> * igt@kms_hdr@bpc-switch-suspend:
> -
Re: [Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC
On Wed, 2020-05-20 at 23:44 -0700, Swathi Dhanavanthri wrote:
> This is a permanent w/a for JSL/EHL.This is to be applied to the
> PCH types on JSL/EHL ie JSP/MCC
> Bspec: 52888
>
> v2: Fixed the wrong usage of logical OR(ville)
> v3: Removed extra braces, changed the check(jose)
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Swathi Dhanavanthri
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 4dc601dffc08..bc82d0d8ad5b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2902,8 +2902,10 @@ static void gen11_display_irq_reset(struct
> drm_i915_private *dev_priv)
> if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> GEN3_IRQ_RESET(uncore, SDE);
>
> - /* Wa_14010685332:icl */
> - if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP) {
> + /* Wa_14010685332:icl,jsl,ehl */
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP ||
> + INTEL_PCH_TYPE(dev_priv) == PCH_JSP ||
> + INTEL_PCH_TYPE(dev_priv) == PCH_MCC) {
> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
>SBCLK_RUN_REFCLK_DIS, SBCLK_RUN_REFCLK_DIS);
> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
___
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/selftests: Measure CS_TIMESTAMP (rev5)
== Series Details ==
Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev5)
URL : https://patchwork.freedesktop.org/series/77320/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8516_full -> Patchwork_17744_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17744_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@pipe-b-torture-bo:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#128])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl1/igt@kms_cursor_leg...@pipe-b-torture-bo.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-kbl1/igt@kms_cursor_leg...@pipe-b-torture-bo.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl3/igt@kms_fbcon_...@psr-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-skl7/igt@kms_fbcon_...@psr-suspend.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#1188]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl7/igt@kms_...@bpc-switch-dpms.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-skl9/igt@kms_...@bpc-switch-dpms.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265])
+2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_plane_cursor@pipe-a-overlay-size-256:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#1559] / [i915#93] /
[i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl7/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-kbl7/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#1559] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-apl8/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-apl4/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-iclb7/igt@kms_psr@psr2_cursor_render.html
Possible fixes
* igt@i915_pm_rpm@system-suspend:
- shard-skl: [INCOMPLETE][19] ([i915#151] / [i915#69]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl10/igt@i915_pm_...@system-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-skl9/igt@i915_pm_...@system-suspend.html
* igt@kms_color@pipe-a-ctm-max:
- shard-skl: [FAIL][21] ([i915#168]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl2/igt@kms_co...@pipe-a-ctm-max.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-skl5/igt@kms_co...@pipe-a-ctm-max.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2
similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* {igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2}:
- shard-glk: [FAIL][25] ([i915#79]) -> [PASS][26]
Re: [Intel-gfx] [PATCH v9 0/7] Consider DBuf bandwidth when calculating CDCLK
Quoting Manasi Navare (2020-05-21 22:28:42) > Pushed the series to dinq, thank you for patches and reviews Could you tidy up the mess of the merge? Things like cd19154608610ab4cdd6c039e9214b8dd281845c: --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -6,11 +6,12 @@ #include #include "intel_bw.h" +#include "intel_pm.h" #include "intel_display_types.h" #include "intel_sideband.h" #include "intel_atomic.h" #include "intel_pm.h" - +#include "intel_cdclk.h" The out of place intel_atomic.h and intel_pm.h were added in 20f505f2253106f695ba6fa0a415159145a8fb2a The code is a mess, checkpatch would be mad. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part of it. CI hit <4> [185.667750] WARNING: CPU: 0 PID: 1387 at mm/gup.c:2699 internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667752] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel snd_intel_dspcfg crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel cdc_ether usbnet mii snd_pcm e1000e mei_me ptp pps_core mei intel_lpss_pci prime_numbers <4> [185.667774] CPU: 0 PID: 1387 Comm: gem_userptr_bli Tainted: G U 5.7.0-rc5-CI-Patchwork_17704+ #1 <4> [185.66] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 <4> [185.667782] RIP: 0010:internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667785] Code: 24 40 08 48 39 5c 24 38 49 89 df 0f 85 74 fc ff ff 48 83 44 24 50 08 48 39 5c 24 58 49 89 dc 0f 85 e0 fb ff ff e9 14 fe ff ff <0f> 0b b8 ea ff ff ff e9 36 fb ff ff 4c 89 e8 48 21 e8 48 39 e8 0f <4> [185.667789] RSP: 0018:c90001133c38 EFLAGS: 00010206 <4> [185.667792] RAX: RBX: RCX: 8884999ee800 <4> [185.667795] RDX: 000c0001 RSI: 0100 RDI: 7f419e774000 <4> [185.667798] RBP: 888453dbf040 R08: R09: 0001 <4> [185.667800] R10: R11: R12: 888453dbf380 <4> [185.667803] R13: 8884999ee800 R14: 888453dbf3e8 R15: 0040 <4> [185.667806] FS: 7f419e875e40() GS:88849fe0() knlGS: <4> [185.667808] CS: 0010 DS: ES: CR0: 80050033 <4> [185.667811] CR2: 7f419e873000 CR3: 000458bd2004 CR4: 00760ef0 <4> [185.667814] PKRU: 5554 <4> [185.667816] Call Trace: <4> [185.667912] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.667918] ? mark_held_locks+0x49/0x70 <4> [185.667998] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.668073] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] and then panicked, across a range of systems. -Chris Thanks for this report! I'm looking into it now. thanks, -- John Hubbard NVIDIA ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Solved: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
On 2020-05-21 12:11, John Hubbard wrote: On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part of it. CI hit <4> [185.667750] WARNING: CPU: 0 PID: 1387 at mm/gup.c:2699 internal_get_user_pages_fast+0x63a/0xac0 OK, what happened here is that it's WARN()'ing due to passing in the new FOLL_FAST_ONLY flag, which was not added to the whitelist. So the fix is easy, and should be applied to the refactoring patch. I'll send out a v2 of the series, which will effectively have this applied: diff --git a/mm/gup.c b/mm/gup.c index 6cbe98c93466..4f0ca3f849d1 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -2696,7 +2696,8 @@ static int internal_get_user_pages_fast(unsigned long start, int nr_pages, int nr_pinned = 0, ret = 0; if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM | - FOLL_FORCE | FOLL_PIN | FOLL_GET))) + FOLL_FORCE | FOLL_PIN | FOLL_GET | + FOLL_FAST_ONLY))) return -EINVAL; start = untagged_addr(start) & PAGE_MASK; <4> [185.667752] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel snd_intel_dspcfg crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel cdc_ether usbnet mii snd_pcm e1000e mei_me ptp pps_core mei intel_lpss_pci prime_numbers <4> [185.667774] CPU: 0 PID: 1387 Comm: gem_userptr_bli Tainted: G U 5.7.0-rc5-CI-Patchwork_17704+ #1 <4> [185.66] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 <4> [185.667782] RIP: 0010:internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667785] Code: 24 40 08 48 39 5c 24 38 49 89 df 0f 85 74 fc ff ff 48 83 44 24 50 08 48 39 5c 24 58 49 89 dc 0f 85 e0 fb ff ff e9 14 fe ff ff <0f> 0b b8 ea ff ff ff e9 36 fb ff ff 4c 89 e8 48 21 e8 48 39 e8 0f <4> [185.667789] RSP: 0018:c90001133c38 EFLAGS: 00010206 <4> [185.667792] RAX: RBX: RCX: 8884999ee800 <4> [185.667795] RDX: 000c0001 RSI: 0100 RDI: 7f419e774000 <4> [185.667798] RBP: 888453dbf040 R08: R09: 0001 <4> [185.667800] R10: R11: R12: 888453dbf380 <4> [185.667803] R13: 8884999ee800 R14: 888453dbf3e8 R15: 0040 <4> [185.667806] FS: 7f419e875e40() GS:88849fe0() knlGS: <4> [185.667808] CS: 0010 DS: ES: CR0: 80050033 <4> [185.667811] CR2: 7f419e873000 CR3: 000458bd2004 CR4: 00760ef0 <4> [185.667814] PKRU: 5554 <4> [185.667816] Call Trace: <4> [185.667912] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.667918] ? mark_held_locks+0x49/0x70 <4> [185.667998] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.668073] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] and then panicked, across a range of systems. -Chris btw, the panic seems to indicate an additional, pre-existing problem: i915_gem_userptr_get_pages(), in this case at least, is not able to recover from a get_user_pages/pin_user_pages failure. thanks, -- John Hubbard NVIDIA ___ 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/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)
== Series Details ==
Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)
URL : https://patchwork.freedesktop.org/series/77382/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8516_full -> Patchwork_17742_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17742_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process@vcs0:
- shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl2/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] /
[i915#716])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-glk2/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-glk9/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][7] -> [FAIL][8] ([fdo#108145] / [i915#265]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_plane_cursor@pipe-a-overlay-size-256:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#1559] / [i915#93] /
[i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl7/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-kbl3/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#1559] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-apl8/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-apl7/igt@kms_plane_cur...@pipe-a-overlay-size-256.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-iclb3/igt@kms_psr@psr2_cursor_render.html
Possible fixes
* igt@i915_pm_rpm@system-suspend:
- shard-skl: [INCOMPLETE][15] ([i915#151] / [i915#69]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-skl10/igt@i915_pm_...@system-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-skl6/igt@i915_pm_...@system-suspend.html
* {igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2}:
- shard-glk: [FAIL][17] ([i915#79]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-glk2/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
* {igt@kms_flip@flip-vs-suspend-interruptible@a-dp1}:
- shard-apl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +11
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-apl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-apl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
* igt@kms_flip_tiling@flip-changes-tiling-yf:
- shard-kbl: [FAIL][21] ([i915#699] / [i915#93] / [i915#95]) ->
[PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-kbl6/igt@kms_flip_til...@flip-changes-tiling-yf.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling-yf.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-iclb: [INCOMPLETE][23] ([i915#1185]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/shard-iclb3/igt@kms_...@bpc-switch-suspend.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/shard-iclb3/igt@kms_...@bpc-switch-suspend.html
* igt@kms_psr@psr2_primary_page_flip:
Re: [Intel-gfx] [PATCH v9 0/7] Consider DBuf bandwidth when calculating CDCLK
Pushed the series to dinq, thank you for patches and reviews Regards Manasi On Tue, May 19, 2020 at 04:11:10PM +0300, Stanislav Lisovskiy wrote: > We need to calculate cdclk after watermarks/ddb has been calculated > as with recent hw CDCLK needs to be adjusted accordingly to DBuf > requirements, which is not possible with current code organization. > > Setting CDCLK according to DBuf BW requirements and not just rejecting > if it doesn't satisfy BW requirements, will allow us to save power when > it is possible and gain additional bandwidth when it's needed - i.e > boosting both our power management and perfomance capabilities. > > This patch is preparation for that, first we now extract modeset > calculation from modeset checks, in order to call it after wm/ddb > has been calculated. > > Stanislav Lisovskiy (7): > drm/i915: Decouple cdclk calculation from modeset checks > drm/i915: Extract cdclk requirements checking to separate function > drm/i915: Check plane configuration properly > drm/i915: Plane configuration affects CDCLK in Gen11+ > drm/i915: Introduce for_each_dbuf_slice_in_mask macro > drm/i915: Adjust CDCLK accordingly to our DBuf bw needs > drm/i915: Remove unneeded hack now for CDCLK > > drivers/gpu/drm/i915/display/intel_bw.c | 118 +- > drivers/gpu/drm/i915/display/intel_bw.h | 10 ++ > drivers/gpu/drm/i915/display/intel_cdclk.c| 40 +++--- > drivers/gpu/drm/i915/display/intel_cdclk.h| 1 - > drivers/gpu/drm/i915/display/intel_display.c | 89 ++--- > drivers/gpu/drm/i915/display/intel_display.h | 7 ++ > .../drm/i915/display/intel_display_power.h| 1 + > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 31 - > drivers/gpu/drm/i915/intel_pm.h | 3 + > 10 files changed, 261 insertions(+), 40 deletions(-) > > -- > 2.24.1.485.gad05a3d8e5 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK (rev18)
Stan, I have addressed the issue and re-reported.
-Original Message-
From: Lisovskiy, Stanislav
Sent: Thursday, May 21, 2020 12:36 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating
CDCLK (rev18)
Seems to be unrelated issue. There seems to be some list corruption happening
in drm fb manipulation code.
if those patches would be causing that (like some severe mem corruption)- it
would happen much more broadly than single test and single platform. Moreover
there is no direct connection to the changes.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Patchwork
Sent: Thursday, May 21, 2020 9:55:27 AM
To: Lisovskiy, Stanislav
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating
CDCLK (rev18)
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev18)
URL : https://patchwork.freedesktop.org/series/74739/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17733_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17733_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17733_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_17733_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a2}:
- shard-glk: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
Known issues
Here are the changes found in Patchwork_17733_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-hostile@bcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#1622])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb3/igt@gem_ctx_persistence@engines-host...@bcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-iclb2/igt@gem_ctx_persistence@engines-host...@bcs0.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-apl7/igt@gem_soft...@noreloc-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-apl4/igt@gem_soft...@noreloc-s3.html
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_soft...@noreloc-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_soft...@noreloc-s3.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([i915#155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_selftest@live@execlists:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#1874])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl2/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl5/igt@i915_selftest@l...@execlists.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#1119] / [i915#118] /
[i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk6/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
*
[Intel-gfx] ✓ Fi.CI.IGT: success for Consider DBuf bandwidth when calculating CDCLK (rev18)
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev18)
URL : https://patchwork.freedesktop.org/series/74739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17733_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17733_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a2}:
- shard-glk: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
Known issues
Here are the changes found in Patchwork_17733_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-hostile@bcs0:
- shard-iclb: [PASS][3] -> [FAIL][4] ([i915#1622])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb3/igt@gem_ctx_persistence@engines-host...@bcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-iclb2/igt@gem_ctx_persistence@engines-host...@bcs0.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-apl7/igt@gem_soft...@noreloc-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-apl4/igt@gem_soft...@noreloc-s3.html
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_soft...@noreloc-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_soft...@noreloc-s3.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([i915#155])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_selftest@live@execlists:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#1874])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl2/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl5/igt@i915_selftest@l...@execlists.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#1119] / [i915#118] /
[i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk6/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement:
- shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-snb1/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk: [PASS][17] -> [DMESG-FAIL][18] ([i915#1186])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-render:
- shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-render.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-render.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#69])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
-
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels URL : https://patchwork.freedesktop.org/series/77518/ State : success == Summary == CI Bug Log - changes from CI_DRM_8520 -> Patchwork_17754 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17754/index.html Changes --- No changes found Participating hosts (47 -> 42) -- Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8520 -> Patchwork_17754 CI-20190529: 20190529 CI_DRM_8520: 1dd5736705657844b104b48d36677cd1096cdfc0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5669: 918d56bd0181d516e41e3505134f7a81b8fef8fb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17754: 7b21690733bd41f8d3ea0518c5ed5e035a9621f7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7b21690733bd drm/i915: Improve execute_cb struct packing 2c7b890b8dfb drm/i915/execlists: Shortcircuit queue_prio() for no internal levels == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17754/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
Quoting John Hubbard (2020-05-19 01:21:20) > This needs to go through Andrew's -mm tree, due to adding a new gup.c > routine. However, I would really love to have some testing from the > drm/i915 folks, because I haven't been able to run-time test that part > of it. CI hit <4> [185.667750] WARNING: CPU: 0 PID: 1387 at mm/gup.c:2699 internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667752] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel snd_intel_dspcfg crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel cdc_ether usbnet mii snd_pcm e1000e mei_me ptp pps_core mei intel_lpss_pci prime_numbers <4> [185.667774] CPU: 0 PID: 1387 Comm: gem_userptr_bli Tainted: G U 5.7.0-rc5-CI-Patchwork_17704+ #1 <4> [185.66] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 <4> [185.667782] RIP: 0010:internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667785] Code: 24 40 08 48 39 5c 24 38 49 89 df 0f 85 74 fc ff ff 48 83 44 24 50 08 48 39 5c 24 58 49 89 dc 0f 85 e0 fb ff ff e9 14 fe ff ff <0f> 0b b8 ea ff ff ff e9 36 fb ff ff 4c 89 e8 48 21 e8 48 39 e8 0f <4> [185.667789] RSP: 0018:c90001133c38 EFLAGS: 00010206 <4> [185.667792] RAX: RBX: RCX: 8884999ee800 <4> [185.667795] RDX: 000c0001 RSI: 0100 RDI: 7f419e774000 <4> [185.667798] RBP: 888453dbf040 R08: R09: 0001 <4> [185.667800] R10: R11: R12: 888453dbf380 <4> [185.667803] R13: 8884999ee800 R14: 888453dbf3e8 R15: 0040 <4> [185.667806] FS: 7f419e875e40() GS:88849fe0() knlGS: <4> [185.667808] CS: 0010 DS: ES: CR0: 80050033 <4> [185.667811] CR2: 7f419e873000 CR3: 000458bd2004 CR4: 00760ef0 <4> [185.667814] PKRU: 5554 <4> [185.667816] Call Trace: <4> [185.667912] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.667918] ? mark_held_locks+0x49/0x70 <4> [185.667998] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.668073] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] and then panicked, across a range of systems. -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/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt
== Series Details == Series: drm/i915/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt URL : https://patchwork.freedesktop.org/series/77517/ State : success == Summary == CI Bug Log - changes from CI_DRM_8520 -> Patchwork_17753 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17753/index.html Changes --- No changes found Participating hosts (47 -> 41) -- Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8520 -> Patchwork_17753 CI-20190529: 20190529 CI_DRM_8520: 1dd5736705657844b104b48d36677cd1096cdfc0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5669: 918d56bd0181d516e41e3505134f7a81b8fef8fb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17753: d248fc3b877b275b48e9060278ec5c2d2428fad2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d248fc3b877b drm/i915/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17753/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce DG1
== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/77496/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17740_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_17740_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17740_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_17740_full: ### IGT changes ### Warnings * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-iclb: [SKIP][1] ([i915#588]) -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8515/shard-iclb2/igt@i915_pm...@dc3co-vpb-simulation.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17740/shard-iclb1/igt@i915_pm...@dc3co-vpb-simulation.html New tests - New tests have been introduced between CI_DRM_8515_full and Patchwork_17740_full: ### New IGT tests (74) ### * igt@kms_big_fb@linear-16bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.51, 7.16] s * igt@kms_big_fb@linear-16bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.60, 7.22] s * igt@kms_big_fb@linear-16bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.20] s * igt@kms_big_fb@linear-16bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.01, 0.18] s * igt@kms_big_fb@linear-32bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.64, 11.15] s * igt@kms_big_fb@linear-32bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.63, 11.11] s * igt@kms_big_fb@linear-32bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.02, 0.21] s * igt@kms_big_fb@linear-32bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.01, 0.20] s * igt@kms_big_fb@linear-64bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.91, 11.01] s * igt@kms_big_fb@linear-64bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.92, 11.14] s * igt@kms_big_fb@linear-64bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.04, 0.73] s * igt@kms_big_fb@linear-64bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.06, 0.83] s * igt@kms_big_fb@linear-8bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.49, 6.06] s * igt@kms_big_fb@linear-8bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.48, 5.43] s * igt@kms_big_fb@linear-8bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.29] s * igt@kms_big_fb@linear-8bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.29] s * igt@kms_big_fb@linear-addfb: - Statuses : 7 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@x-tiled-16bpp-rotate-0: - Statuses : 6 pass(s) - Exec time: [1.47, 3.02] s * igt@kms_big_fb@x-tiled-16bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.58, 7.12] s * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.17] s * igt@kms_big_fb@x-tiled-16bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.01, 0.18] s * igt@kms_big_fb@x-tiled-32bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.56, 10.38] s * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - Statuses : 6 pass(s) - Exec time: [1.58, 10.83] s * igt@kms_big_fb@x-tiled-32bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.22] s * igt@kms_big_fb@x-tiled-32bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.20] s * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.87, 11.22] s * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.96, 10.61] s * igt@kms_big_fb@x-tiled-64bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.06, 0.86] s * igt@kms_big_fb@x-tiled-64bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.04, 0.74] s * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.27, 5.05] s * igt@kms_big_fb@x-tiled-8bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.40, 5.27] s * igt@kms_big_fb@x-tiled-8bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.30] s * igt@kms_big_fb@x-tiled-8bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.38] s * igt@kms_big_fb@x-tiled-addfb: - Statuses : 7 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@x-tiled-addfb-size-offset-overflow: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0] s * igt@kms_big_fb@x-tiled-addfb-size-overflow: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 0.00] s
[Intel-gfx] [PATCH 2/2] drm/i915: Improve execute_cb struct packing
Reduce the irq_work llist for attaching the callbacks to the signal for
both smaller structs (two fewer pointers!) and simpler [debug] code:
Function old new delta
irq_execute_cb35 34 -1
__igt_breadcrumbs_smoketest 16841682 -2
i915_request_retire 20031996 -7
__i915_request_create 10471040 -7
__notify_execute_cb 135 126 -9
__i915_request_ctor 188 178 -10
__await_execution.part.constprop 451 440 -11
igt_wait_request 924 714-210
One minor artifact is that the order of cb exection is reversed. No
current use cases are affected by that change.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 18 +-
drivers/gpu/drm/i915/i915_request.h | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index c282719ad3ac..22df5b229aed 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -42,7 +42,6 @@
#include "intel_pm.h"
struct execute_cb {
- struct list_head link;
struct irq_work work;
struct i915_sw_fence *fence;
void (*hook)(struct i915_request *rq, struct dma_fence *signal);
@@ -189,14 +188,14 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
static void __notify_execute_cb(struct i915_request *rq)
{
- struct execute_cb *cb;
+ struct execute_cb *cb, *cn;
lockdep_assert_held(>lock);
- if (list_empty(>execute_cb))
+ if (llist_empty(>execute_cb))
return;
- list_for_each_entry(cb, >execute_cb, link)
+ llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
irq_work_queue(>work);
/*
@@ -209,7 +208,7 @@ static void __notify_execute_cb(struct i915_request *rq)
* preempt-to-idle cycle on the target engine, all the while the
* master execute_cb may refire.
*/
- INIT_LIST_HEAD(>execute_cb);
+ rq->execute_cb.first = NULL;
}
static inline void
@@ -327,7 +326,7 @@ bool i915_request_retire(struct i915_request *rq)
set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
__notify_execute_cb(rq);
}
- GEM_BUG_ON(!list_empty(>execute_cb));
+ GEM_BUG_ON(!llist_empty(>execute_cb));
spin_unlock_irq(>lock);
remove_from_client(rq);
@@ -395,7 +394,8 @@ __await_execution(struct i915_request *rq,
i915_sw_fence_complete(cb->fence);
kmem_cache_free(global.slab_execute_cbs, cb);
} else {
- list_add_tail(>link, >execute_cb);
+ cb->work.llnode.next = signal->execute_cb.first;
+ signal->execute_cb.first = >work.llnode;
}
spin_unlock_irq(>lock);
@@ -704,7 +704,7 @@ static void __i915_request_ctor(void *arg)
rq->file_priv = NULL;
rq->capture_list = NULL;
- INIT_LIST_HEAD(>execute_cb);
+ init_llist_head(>execute_cb);
}
struct i915_request *
@@ -794,7 +794,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->batch = NULL;
GEM_BUG_ON(rq->file_priv);
GEM_BUG_ON(rq->capture_list);
- GEM_BUG_ON(!list_empty(>execute_cb));
+ GEM_BUG_ON(!llist_empty(>execute_cb));
/*
* Reserve space in the ring buffer for all the commands required to
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 8ec7ee4dbadc..5d4709a3dace 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -214,7 +214,7 @@ struct i915_request {
ktime_t emitted;
} duration;
};
- struct list_head execute_cb;
+ struct llist_head execute_cb;
struct i915_sw_fence semaphore;
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels
If there are no internal levels and the user priority-shift is zero, we can help the compiler eliminate some dead code: Function old new delta start_timeslice 169 154 -15 __execlists_submission_tasklet 46964659 -37 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index de5be57ed6d2..3214a4ecc31a 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -446,6 +446,9 @@ static int queue_prio(const struct intel_engine_execlists *execlists) * we have to flip the index value to become priority. */ p = to_priolist(rb); + if (!I915_USER_PRIORITY_SHIFT) + return p->priority; + return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used); } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/37] drm/i915: make intel_{uncore, de}_rmw() more useful
On Thu, May 21, 2020 at 10:24:49AM -0700, Jose Souza wrote:
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
Return the old value read so some places of the code can still do the
rmw but add warnings/errors about the value it read.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_de.h | 4 ++--
drivers/gpu/drm/i915/intel_uncore.h | 10 +++---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_de.h
b/drivers/gpu/drm/i915/display/intel_de.h
index 00da10bf35f5..d5441b1ba2fe 100644
--- a/drivers/gpu/drm/i915/display/intel_de.h
+++ b/drivers/gpu/drm/i915/display/intel_de.h
@@ -42,10 +42,10 @@ intel_de_write_fw(struct drm_i915_private *i915, i915_reg_t
reg, u32 val)
intel_uncore_write_fw(>uncore, reg, val);
}
Maybe add function documentation with this new information about the return?
yeah... just not sure about the usefulness since the only place I
intended to use it I ended up doing something different. So I'm still
not sure. Maybe wait a user to appear.
thanks
Lucas De Marchi
With that:
Reviewed-by: José Roberto de Souza
-static inline void
+static inline u32
intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear, u32 set)
{
- intel_uncore_rmw(>uncore, reg, clear, set);
+ return intel_uncore_rmw(>uncore, reg, clear, set);
}
static inline int
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 8d3aa8b9acf9..5da43b56fa11 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -379,8 +379,8 @@ intel_uncore_read64_2x32(struct intel_uncore *uncore,
#define intel_uncore_write64_fw(...) __raw_uncore_write64(__VA_ARGS__)
#define intel_uncore_posting_read_fw(...)
((void)intel_uncore_read_fw(__VA_ARGS__))
-static inline void intel_uncore_rmw(struct intel_uncore *uncore,
- i915_reg_t reg, u32 clear, u32 set)
+static inline u32 intel_uncore_rmw(struct intel_uncore *uncore,
+ i915_reg_t reg, u32 clear, u32 set)
{
u32 old, val;
@@ -388,9 +388,11 @@ static inline void intel_uncore_rmw(struct intel_uncore
*uncore,
val = (old & ~clear) | set;
if (val != old)
intel_uncore_write(uncore, reg, val);
+
+ return old;
}
-static inline void intel_uncore_rmw_fw(struct intel_uncore *uncore,
+static inline u32 intel_uncore_rmw_fw(struct intel_uncore *uncore,
i915_reg_t reg, u32 clear, u32 set)
{
u32 old, val;
@@ -399,6 +401,8 @@ static inline void intel_uncore_rmw_fw(struct intel_uncore
*uncore,
val = (old & ~clear) | set;
if (val != old)
intel_uncore_write_fw(uncore, reg, val);
+
+ return old;
}
static inline int intel_uncore_write_and_verify(struct intel_uncore *uncore,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/37] drm/i915: make intel_{uncore, de}_rmw() more useful
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> Return the old value read so some places of the code can still do the
> rmw but add warnings/errors about the value it read.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_de.h | 4 ++--
> drivers/gpu/drm/i915/intel_uncore.h | 10 +++---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index 00da10bf35f5..d5441b1ba2fe 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -42,10 +42,10 @@ intel_de_write_fw(struct drm_i915_private *i915,
> i915_reg_t reg, u32 val)
> intel_uncore_write_fw(>uncore, reg, val);
> }
>
Maybe add function documentation with this new information about the return?
With that:
Reviewed-by: José Roberto de Souza
>
> -static inline void
> +static inline u32
> intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear, u32
> set)
> {
> - intel_uncore_rmw(>uncore, reg, clear, set);
> + return intel_uncore_rmw(>uncore, reg, clear, set);
> }
>
> static inline int
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h
> b/drivers/gpu/drm/i915/intel_uncore.h
> index 8d3aa8b9acf9..5da43b56fa11 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -379,8 +379,8 @@ intel_uncore_read64_2x32(struct intel_uncore *uncore,
> #define intel_uncore_write64_fw(...) __raw_uncore_write64(__VA_ARGS__)
> #define intel_uncore_posting_read_fw(...)
> ((void)intel_uncore_read_fw(__VA_ARGS__))
>
> -static inline void intel_uncore_rmw(struct intel_uncore *uncore,
> - i915_reg_t reg, u32 clear, u32 set)
> +static inline u32 intel_uncore_rmw(struct intel_uncore *uncore,
> +i915_reg_t reg, u32 clear, u32 set)
> {
> u32 old, val;
>
> @@ -388,9 +388,11 @@ static inline void intel_uncore_rmw(struct intel_uncore
> *uncore,
> val = (old & ~clear) | set;
> if (val != old)
> intel_uncore_write(uncore, reg, val);
> +
> + return old;
> }
>
> -static inline void intel_uncore_rmw_fw(struct intel_uncore *uncore,
> +static inline u32 intel_uncore_rmw_fw(struct intel_uncore *uncore,
> i915_reg_t reg, u32 clear, u32 set)
> {
> u32 old, val;
> @@ -399,6 +401,8 @@ static inline void intel_uncore_rmw_fw(struct
> intel_uncore *uncore,
> val = (old & ~clear) | set;
> if (val != old)
> intel_uncore_write_fw(uncore, reg, val);
> +
> + return old;
> }
>
> static inline int intel_uncore_write_and_verify(struct intel_uncore *uncore,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt
In order to keep userptr distinct from ggtt mmaps in the eyes of lockdep, we need to avoid marking those userptr vma as PIN_GLOBAL. (So long as we comply with only using them as local PIN_USER!) References: https://gitlab.freedesktop.org/drm/intel/-/issues/1880 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 66165b10256e..1220abb2af6b 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -424,22 +424,17 @@ static int ggtt_bind_vma(struct i915_vma *vma, struct drm_i915_gem_object *obj = vma->obj; u32 pte_flags; + if (i915_vma_is_bound(vma, ~flags & (I915_VMA_LOCAL_BIND | I915_VMA_GLOBAL_BIND))) + return 0; + /* Applicable to VLV (gen8+ do not support RO in the GGTT) */ pte_flags = 0; if (i915_gem_object_is_readonly(obj)) pte_flags |= PTE_READ_ONLY; vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags); - vma->page_sizes.gtt = I915_GTT_PAGE_SIZE; - /* -* Without aliasing PPGTT there's no difference between -* GLOBAL/LOCAL_BIND, it's all the same ptes. Hence unconditionally -* upgrade to both bound if we bind either to avoid double-binding. -*/ - atomic_or(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND, >flags); - return 0; } -- 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: Remove PIN_UPDATE for i915_vma_pin
== Series Details == Series: drm/i915: Remove PIN_UPDATE for i915_vma_pin URL : https://patchwork.freedesktop.org/series/77515/ State : success == Summary == CI Bug Log - changes from CI_DRM_8518 -> Patchwork_17752 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17752/index.html Known issues Here are the changes found in Patchwork_17752 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][1] ([fdo#109271]) -> [FAIL][2] ([i915#62]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8518/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17752/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (47 -> 41) -- Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8518 -> Patchwork_17752 CI-20190529: 20190529 CI_DRM_8518: 869a68b66e355733cbebd96443ed56bbf57d7040 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5668: 00d214488f7361c7eceaa8a4a960031f4b467bd5 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17752: 0442695d05a4d2823b4d4a761f52ab8c21f58980 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0442695d05a4 drm/i915: Remove PIN_UPDATE for i915_vma_pin == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17752/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
== Series Details == Series: series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing URL : https://patchwork.freedesktop.org/series/77512/ State : success == Summary == CI Bug Log - changes from CI_DRM_8518 -> Patchwork_17751 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17751/index.html Known issues Here are the changes found in Patchwork_17751 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@client: - fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] ([i915#489]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8518/fi-bwr-2160/igt@i915_selftest@l...@client.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17751/fi-bwr-2160/igt@i915_selftest@l...@client.html [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (47 -> 42) -- Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8518 -> Patchwork_17751 CI-20190529: 20190529 CI_DRM_8518: 869a68b66e355733cbebd96443ed56bbf57d7040 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5668: 00d214488f7361c7eceaa8a4a960031f4b467bd5 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17751: c5572b7c8726df714c8de7e782c57d76c930b6a8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c5572b7c8726 drm/i915: Avoid using rq->engine after free during i915_fence_release 97a3a7ab6a8b drm/i915: Disable semaphore inter-engine sync without timeslicing == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17751/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add psr_safest_params
== Series Details == Series: drm/i915: Add psr_safest_params URL : https://patchwork.freedesktop.org/series/77491/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17738_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_17738_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17738_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_17738_full: ### IGT changes ### Warnings * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-iclb: [SKIP][1] ([i915#588]) -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8515/shard-iclb2/igt@i915_pm...@dc3co-vpb-simulation.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17738/shard-iclb3/igt@i915_pm...@dc3co-vpb-simulation.html New tests - New tests have been introduced between CI_DRM_8515_full and Patchwork_17738_full: ### New IGT tests (74) ### * igt@kms_big_fb@linear-16bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.51, 7.43] s * igt@kms_big_fb@linear-16bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.61, 7.23] s * igt@kms_big_fb@linear-16bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.19] s * igt@kms_big_fb@linear-16bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.19] s * igt@kms_big_fb@linear-32bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.65, 11.03] s * igt@kms_big_fb@linear-32bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.63, 10.83] s * igt@kms_big_fb@linear-32bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.20] s * igt@kms_big_fb@linear-32bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.01, 0.19] s * igt@kms_big_fb@linear-64bpp-rotate-0: - Statuses : 6 pass(s) - Exec time: [1.91, 10.99] s * igt@kms_big_fb@linear-64bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.92, 10.95] s * igt@kms_big_fb@linear-64bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.04, 0.78] s * igt@kms_big_fb@linear-64bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.06, 0.85] s * igt@kms_big_fb@linear-8bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.46, 6.00] s * igt@kms_big_fb@linear-8bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.48, 5.51] s * igt@kms_big_fb@linear-8bpp-rotate-270: - Statuses : 6 skip(s) - Exec time: [0.02, 0.21] s * igt@kms_big_fb@linear-8bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.30] s * igt@kms_big_fb@linear-addfb: - Statuses : 7 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@x-tiled-16bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.46, 7.09] s * igt@kms_big_fb@x-tiled-16bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.58, 7.07] s * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.19] s * igt@kms_big_fb@x-tiled-16bpp-rotate-90: - Statuses : 6 skip(s) - Exec time: [0.01, 0.20] s * igt@kms_big_fb@x-tiled-32bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.56, 10.64] s * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.59, 10.58] s * igt@kms_big_fb@x-tiled-32bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.21] s * igt@kms_big_fb@x-tiled-32bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.21] s * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.87, 11.61] s * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.97, 10.64] s * igt@kms_big_fb@x-tiled-64bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.04, 0.87] s * igt@kms_big_fb@x-tiled-64bpp-rotate-90: - Statuses : 6 skip(s) - Exec time: [0.05, 0.76] s * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.28, 5.08] s * igt@kms_big_fb@x-tiled-8bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.40, 5.49] s * igt@kms_big_fb@x-tiled-8bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.02, 0.29] s * igt@kms_big_fb@x-tiled-8bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.03, 0.42] s * igt@kms_big_fb@x-tiled-addfb: - Statuses : 7 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@x-tiled-addfb-size-offset-overflow: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0] s * igt@kms_big_fb@x-tiled-addfb-size-overflow: - Statuses : 6 pass(s) 1 skip(s) - Exec
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
== Series Details == Series: series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing URL : https://patchwork.freedesktop.org/series/77512/ 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/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/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_nop: Specify timeout in milliseconds
On Tue, 2020-05-12 at 18:19 +0100, Chris Wilson wrote:
> Our 'headless' subtest requires fairly precise measurements to determine
> the impact of the dmc upon request latency. The test cannot be effective
> if we cannot execute requests quickly, so add a very short pre-pass to
> check the test requirements. For this we want to specify the baseline
> measurement timeout in milliseconds, allowing us to speed up our other
> baseline measurements elsewhere as well.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Janusz Krzysztofik
Thanks,
Janusz
> ---
> tests/i915/gem_exec_nop.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
> index 4051e0fd7..21a937c83 100644
> --- a/tests/i915/gem_exec_nop.c
> +++ b/tests/i915/gem_exec_nop.c
> @@ -64,7 +64,7 @@ static double elapsed(const struct timespec *start, const
> struct timespec *end)
>
> static double nop_on_ring(int fd, uint32_t handle,
> const struct intel_execution_engine2 *e,
> - int timeout,
> + int timeout_ms,
> unsigned long *out)
> {
> struct drm_i915_gem_execbuffer2 execbuf;
> @@ -94,7 +94,7 @@ static double nop_on_ring(int fd, uint32_t handle,
> count++;
>
> clock_gettime(CLOCK_MONOTONIC, );
> - } while (elapsed(, ) < timeout);
> + } while (elapsed(, ) < timeout_ms * 1e-3);
> igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
>
> *out = count;
> @@ -348,14 +348,15 @@ static void single(int fd, uint32_t handle,
> double time;
> unsigned long count;
>
> - time = nop_on_ring(fd, handle, e, 20, );
> + time = nop_on_ring(fd, handle, e, 2, );
> igt_info("%s: %'lu cycles: %.3fus\n",
> e->name, count, time*1e6 / count);
> }
>
> static double
> stable_nop_on_ring(int fd, uint32_t handle,
> -const struct intel_execution_engine2 *e, int timeout,
> +const struct intel_execution_engine2 *e,
> +int timeout_ms,
> int reps)
> {
> igt_stats_t s;
> @@ -370,7 +371,7 @@ stable_nop_on_ring(int fd, uint32_t handle,
> unsigned long count;
> double time;
>
> - time = nop_on_ring(fd, handle, e, timeout, );
> + time = nop_on_ring(fd, handle, e, timeout_ms, );
> igt_stats_push_float(, time / count);
> }
>
> @@ -390,9 +391,10 @@ static void headless(int fd, uint32_t handle,
>const struct intel_execution_engine2 *e)
> {
> unsigned int nr_connected = 0;
> + double n_display, n_headless;
> drmModeConnector *connector;
> + unsigned long count;
> drmModeRes *res;
> - double n_display, n_headless;
>
> res = drmModeGetResources(fd);
> igt_require(res);
> @@ -409,8 +411,11 @@ static void headless(int fd, uint32_t handle,
> /* set graphics mode to prevent blanking */
> kmstest_set_vt_graphics_mode();
>
> + nop_on_ring(fd, handle, e, 10, );
> + igt_require_f(count > 100, "submillisecond precision required\n");
> +
> /* benchmark nops */
> - n_display = stable_nop_on_ring(fd, handle, e, 1, 5);
> + n_display = stable_nop_on_ring(fd, handle, e, 500, 5);
> igt_info("With one display connected: %.2fus\n",
>n_display * 1e6);
>
> @@ -418,7 +423,7 @@ static void headless(int fd, uint32_t handle,
> kmstest_unset_all_crtcs(fd, res);
>
> /* benchmark nops again */
> - n_headless = stable_nop_on_ring(fd, handle, e, 1, 5);
> + n_headless = stable_nop_on_ring(fd, handle, e, 500, 5);
> igt_info("Without a display connected (headless): %.2fus\n",
>n_headless * 1e6);
>
> @@ -444,7 +449,7 @@ static void parallel(int fd, uint32_t handle, int timeout)
> engines[nengine] = e->flags;
> names[nengine++] = strdup(e->name);
>
> - time = nop_on_ring(fd, handle, e, 1, ) / count;
> + time = nop_on_ring(fd, handle, e, 250, ) / count;
> sum += time;
> igt_debug("%s: %.3fus\n", e->name, 1e6*time);
> }
> @@ -506,7 +511,7 @@ static void independent(int fd, uint32_t handle, int
> timeout)
> engines[nengine] = e->flags;
> names[nengine++] = strdup(e->name);
>
> - time = nop_on_ring(fd, handle, e, 1, ) / count;
> + time = nop_on_ring(fd, handle, e, 250, ) / count;
> sum += time;
> igt_debug("%s: %.3fus\n", e->name, 1e6*time);
> }
> @@ -626,7 +631,7 @@ static void series(int fd, uint32_t handle, int timeout)
>
> nengine = 0;
> __for_each_physical_engine(fd, e) {
> - time = nop_on_ring(fd, handle, e, 1, ) / count;
> + time = nop_on_ring(fd, handle, e, 250, ) / count;
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Cancel the flush worker more thoroughly
== Series Details == Series: drm/i915/gt: Cancel the flush worker more thoroughly URL : https://patchwork.freedesktop.org/series/77490/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17736_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8515_full and Patchwork_17736_full: ### New IGT tests (74) ### * igt@kms_big_fb@linear-16bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.51, 7.10] s * igt@kms_big_fb@linear-16bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.61, 7.18] s * igt@kms_big_fb@linear-16bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.20] s * igt@kms_big_fb@linear-16bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.01, 0.18] s * igt@kms_big_fb@linear-32bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.65, 11.33] s * igt@kms_big_fb@linear-32bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.65, 10.94] s * igt@kms_big_fb@linear-32bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.20] s * igt@kms_big_fb@linear-32bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.20] s * igt@kms_big_fb@linear-64bpp-rotate-0: - Statuses : 6 pass(s) - Exec time: [1.92, 11.16] s * igt@kms_big_fb@linear-64bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.92, 11.01] s * igt@kms_big_fb@linear-64bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.04, 0.73] s * igt@kms_big_fb@linear-64bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.05, 0.85] s * igt@kms_big_fb@linear-8bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.49, 6.05] s * igt@kms_big_fb@linear-8bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.44, 5.52] s * igt@kms_big_fb@linear-8bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.02, 0.29] s * igt@kms_big_fb@linear-8bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.30] s * igt@kms_big_fb@linear-addfb: - Statuses : 7 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@x-tiled-16bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.45, 6.94] s * igt@kms_big_fb@x-tiled-16bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.58, 7.42] s * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.18] s * igt@kms_big_fb@x-tiled-16bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.01, 0.19] s * igt@kms_big_fb@x-tiled-32bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.56, 10.65] s * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.57, 11.22] s * igt@kms_big_fb@x-tiled-32bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.01, 0.22] s * igt@kms_big_fb@x-tiled-32bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.21] s * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.87, 10.89] s * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.97, 10.68] s * igt@kms_big_fb@x-tiled-64bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.06, 0.84] s * igt@kms_big_fb@x-tiled-64bpp-rotate-90: - Statuses : 6 skip(s) - Exec time: [0.04, 0.72] s * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - Statuses : 7 pass(s) - Exec time: [1.32, 5.03] s * igt@kms_big_fb@x-tiled-8bpp-rotate-180: - Statuses : 7 pass(s) - Exec time: [1.41, 5.25] s * igt@kms_big_fb@x-tiled-8bpp-rotate-270: - Statuses : 7 skip(s) - Exec time: [0.03, 0.32] s * igt@kms_big_fb@x-tiled-8bpp-rotate-90: - Statuses : 7 skip(s) - Exec time: [0.02, 0.62] s * igt@kms_big_fb@x-tiled-addfb: - Statuses : 6 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@x-tiled-addfb-size-offset-overflow: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0] s * igt@kms_big_fb@x-tiled-addfb-size-overflow: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 0.00] s * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - Statuses : 5 pass(s) 1 skip(s) - Exec time: [0.0, 7.05] s * igt@kms_big_fb@y-tiled-16bpp-rotate-180: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 6.84] s * igt@kms_big_fb@y-tiled-16bpp-rotate-270: - Statuses : 2 pass(s) 5 skip(s) - Exec time: [0.0, 1.83] s * igt@kms_big_fb@y-tiled-16bpp-rotate-90: - Statuses : 2 pass(s) 4 skip(s) - Exec time: [0.0, 1.85] s * igt@kms_big_fb@y-tiled-32bpp-rotate-0: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 10.89] s * igt@kms_big_fb@y-tiled-32bpp-rotate-180: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 11.82] s * igt@kms_big_fb@y-tiled-32bpp-rotate-270: - Statuses : 6 pass(s) 1 skip(s) -
[Intel-gfx] [CI] drm/i915: Remove PIN_UPDATE for i915_vma_pin
As we no longer use PIN_UPDATE (since commit 7d0aa0db4375 ("drm/i915/gem:
Unbind all current vma on changing cache-level")) we can remove
PIN_UPDATE itself. The benefit is just in simplifing the vma bind.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 142 --
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 -
drivers/gpu/drm/i915/i915_vma.c | 9 +-
3 files changed, 3 insertions(+), 149 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c9988b6d5c88..a0ed2fab0ff3 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1409,147 +1409,6 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
-static int igt_ppgtt_pin_update(void *arg)
-{
- struct i915_gem_context *ctx = arg;
- struct drm_i915_private *dev_priv = ctx->i915;
- unsigned long supported = INTEL_INFO(dev_priv)->page_sizes;
- struct drm_i915_gem_object *obj;
- struct i915_gem_engines_iter it;
- struct i915_address_space *vm;
- struct intel_context *ce;
- struct i915_vma *vma;
- unsigned int flags = PIN_USER | PIN_OFFSET_FIXED;
- unsigned int n;
- int first, last;
- int err = 0;
-
- /*
-* Make sure there's no funny business when doing a PIN_UPDATE -- in the
-* past we had a subtle issue with being able to incorrectly do multiple
-* alloc va ranges on the same object when doing a PIN_UPDATE, which
-* resulted in some pretty nasty bugs, though only when using
-* huge-gtt-pages.
-*/
-
- vm = i915_gem_context_get_vm_rcu(ctx);
- if (!i915_vm_is_4lvl(vm)) {
- pr_info("48b PPGTT not supported, skipping\n");
- goto out_vm;
- }
-
- first = ilog2(I915_GTT_PAGE_SIZE_64K);
- last = ilog2(I915_GTT_PAGE_SIZE_2M);
-
- for_each_set_bit_from(first, , last + 1) {
- unsigned int page_size = BIT(first);
-
- obj = i915_gem_object_create_internal(dev_priv, page_size);
- if (IS_ERR(obj)) {
- err = PTR_ERR(obj);
- goto out_vm;
- }
-
- vma = i915_vma_instance(obj, vm, NULL);
- if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
- goto out_put;
- }
-
- err = i915_vma_pin(vma, SZ_2M, 0, flags);
- if (err)
- goto out_put;
-
- if (vma->page_sizes.sg < page_size) {
- pr_info("Unable to allocate page-size %x, finishing
test early\n",
- page_size);
- goto out_unpin;
- }
-
- err = igt_check_page_sizes(vma);
- if (err)
- goto out_unpin;
-
- if (vma->page_sizes.gtt != page_size) {
- dma_addr_t addr = i915_gem_object_get_dma_address(obj,
0);
-
- /*
-* The only valid reason for this to ever fail would be
-* if the dma-mapper screwed us over when we did the
-* dma_map_sg(), since it has the final say over the dma
-* address.
-*/
- if (IS_ALIGNED(addr, page_size)) {
- pr_err("page_sizes.gtt=%u, expected=%u\n",
- vma->page_sizes.gtt, page_size);
- err = -EINVAL;
- } else {
- pr_info("dma address misaligned, finishing test
early\n");
- }
-
- goto out_unpin;
- }
-
- err = i915_vma_bind(vma, I915_CACHE_NONE, PIN_UPDATE, NULL);
- if (err)
- goto out_unpin;
-
- i915_vma_unpin(vma);
- i915_gem_object_put(obj);
- }
-
- obj = i915_gem_object_create_internal(dev_priv, PAGE_SIZE);
- if (IS_ERR(obj)) {
- err = PTR_ERR(obj);
- goto out_vm;
- }
-
- vma = i915_vma_instance(obj, vm, NULL);
- if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
- goto out_put;
- }
-
- err = i915_vma_pin(vma, 0, 0, flags);
- if (err)
- goto out_put;
-
- /*
-* Make sure we don't end up with something like where the pde is still
-* pointing to the 2M page, and the pt we just filled-in is dangling --
-* we can check this by writing to the first page where it would then
-* land in the now stale 2M page.
-*/
-
- n = 0;
- for_each_gem_engine(ce,
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove PIN_UPDATE for i915_vma_pin
On Sat, 16 May 2020 at 18:07, Chris Wilson wrote:
>
> As we no longer use PIN_UPDATE (since commit 7d0aa0db4375 ("drm/i915/gem:
> Unbind all current vma on changing cache-level")) we can remove
> PIN_UPDATE itself. The benefit is just in simplifing the vma bind.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release
In order to be valid to dereference during the i915_fence_release, after
retiring the fence and releasing its refererences, we assume that
rq->engine can only be a real engine (that stay intact until the device
is shutdown after all fences have been flushed). However, due to a quirk
of preempt-to-busy, we may retire a request that still belongs to a
virtual engine and so eventually free it with rq->engine being invalid.
To avoid dereferencing that invalid engine, we look at the
execution_mask which if it indicates it may be executed on more than one
engine, we know it originated on a virtual engine and may still be on
one.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 35 +++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 526c1e9acbd5..c282719ad3ac 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -121,8 +121,39 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(>submit);
i915_sw_fence_fini(>semaphore);
- /* Keep one request on each engine for reserved use under mempressure */
- if (!cmpxchg(>engine->request_pool, NULL, rq))
+ /*
+* Keep one request on each engine for reserved use under mempressure
+*
+* We do not hold a reference to the engine here and so have to be
+* very careful in what rq->engine we poke. The virtual engine is
+* referenced via the rq->context and we released that ref during
+* i915_request_retire(), ergo we must not dereference a virtual
+* engine here. Not that we would want to, as the only consumer of
+* the reserved engine->request_pool is the power management parking,
+* which must-not-fail, and that is only run on the physical engines.
+*
+* Since the request must have been executed to be have completed,
+* we know that it will have been processed by the HW and will
+* not be unsubmitted again, so rq->engine and rq->execution_mask
+* at this point is stable. rq->execution_mask will be a single
+* bit if the last and _only_ engine it could execution on was a
+* physical engine, if it's multiple bits then it started on and
+* could still be on a virtual engine. Thus if the mask is not a
+* power-of-two we assume that rq->engine may still be a virtual
+* engine and so a dangling invalid pointer that we cannot dereference
+*
+* For example, consider the flow of a bonded request through a virtual
+* engine. The request is created with a wide engine mask (all engines
+* that we might execute on). On processing the bond, the request mask
+* is reduced to one or more engines. If the request is subsequently
+* bound to a single engine, it will then be constrained to only
+* execute on that engine and never returned to the virtual engine
+* after timeslicing away, see __unwind_incomplete_requests(). Thus we
+* know that if the rq->execution_mask is a single bit, rq->engine
+* can be a physical engine with the exact corresponding mask.
+*/
+ if (is_power_of_2(rq->execution_mask) &&
+ !cmpxchg(>engine->request_pool, NULL, rq))
return;
kmem_cache_free(global.slab_requests, rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
Since the removal of the no-semaphore boosting, we rely on timeslicing to
reorder passed inter-dependency hogs across the engines. However, we
require preemption to support timeslicing into user payloads, and not all
machine support preemption so we do not universally enable timeslicing,
even when it would correctly preempt our own inter-engine semaphores.
Since timeslicing and semaphore priority deboosting is now disabled on
Broadwell/Braswell, we have to follow suite and not use semaphores.
Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..f5d59d18cd5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->timeline = intel_timeline_get(ctx->timeline);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
+ intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
}
@@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce,
void *arg)
{
struct i915_gem_context *ctx = arg;
- if (!intel_engine_has_semaphores(ce->engine))
+ if (!intel_engine_has_timeslices(ce->engine))
return 0;
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
On 21/05/2020 11:17, Chris Wilson wrote:
Quoting Chris Wilson (2020-05-21 10:42:26)
Quoting Tvrtko Ursulin (2020-05-21 10:10:10)
On 21/05/2020 09:53, Chris Wilson wrote:
Since the remove of the no-semaphore boosting, we rely on timeslicing to
reorder past inter-dependency hogs across the engines. However, we
require preemption to support timeslicing into user payloads, and not all
machine support preemption so we do not universally enable timeslicing
even when it would preempt our own inter-engine semaphores.
Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..f5d59d18cd5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->timeline = intel_timeline_get(ctx->timeline);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
+ intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
}
@@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce, void *arg)
{
struct i915_gem_context *ctx = arg;
- if (!intel_engine_has_semaphores(ce->engine))
+ if (!intel_engine_has_timeslices(ce->engine))
return 0;
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
__i915_request_await_execution is okay to keep using semaphores?
I think so. Using semaphores there still benefits from synchronising
with a master in ELSP[1]. The danger is that it does increase the
hangcheck possibility for the bond request, such that a slow request
before the master would result in us declaring the bond hung. The
question is whether that is worse than executing the bond before the
master.
I should be able to write a test to demonstrate the hang in the bond.
For example, if we do something like:
on master engine:
submit spin
submit master -> submit fence -> submit bond
for(;;)
submit high priority spin
terminate previous spin
Hmm. But without preemption... master will execute before we get a
chance to submit the high priority spinners. So this will not actually
hang.
Ok, so this is safer than it seems :)
Even more so, since we do preempt the semaphore for the hangcheck.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Avoid using rq->engine after free during i915_fence_release
On 21/05/2020 10:44, Chris Wilson wrote:
Quoting Chris Wilson (2020-05-21 10:32:49)
Quoting Chris Wilson (2020-05-21 10:27:16)
Quoting Tvrtko Ursulin (2020-05-21 10:13:14)
On 21/05/2020 09:53, Chris Wilson wrote:
In order to be valid to dereference during the i915_fence_release, after
retiring the fence and releasing its refererences, we assume that
rq->engine can only be a real engine (that stay intact until the device
is shutdown after all fences have been flushed). However, due to a quirk
of preempt-to-busy, we may retire a request that still belongs to a
virtual engine and so eventually free it with rq->engine being invalid.
To avoid dereferencing that invalid engine, we look at the
execution_mask which if it indicates it may be executed on more than one
engine, we know it originated on a virtual engine and may still be on
one.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 526c1e9acbd5..6e357183bece 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -121,8 +121,29 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(>submit);
i915_sw_fence_fini(>semaphore);
- /* Keep one request on each engine for reserved use under mempressure */
- if (!cmpxchg(>engine->request_pool, NULL, rq))
+ /*
+ * Keep one request on each engine for reserved use under mempressure
+ *
+ * We do not hold a reference to the engine here and so have to be
+ * very careful in what rq->engine we poke. The virtual engine is
+ * referenced via the rq->context and we released that ref during
+ * i915_request_retire(), ergo we must not dereference a virtual
+ * engine here. Not that we would want to, as the only consumer of
+ * the reserved engine->request_pool is the powermanagent parking,
power management
+ * which must-not-fail, and that is only run on the physical engines.
+ *
+ * Since the request must have been executed to be have completed,
+ * we know that it will have been processed by the HW and will
+ * not be unsubmitted again, so rq->engine and rq->execution_mask
+ * at this point is stable. rq->execution_mask will be a single
+ * bit if the last and only engine it could execution on was a
+ * physical engine, if it's multiple bits then it started on and
+ * could still be on a virtual engine. Thus if the mask is not a
+ * power-of-two we assume that rq->engine may still be a virtual
+ * engien and so a dangling invalid pointer that we cannot
engine
But.. submit fence can mask out execution_mask bits and make it appear
the request was on a physical engine. What then?
Then we execute along a single engine and it is never returned to the
virtual engine (in __unwind_incomplete_requests).
* For example, consider the flow of a bonded request through a virtual
* engine. The request is created with a wide engine mask (all engines
* that we might execute on). On processing the bond, the request mask
* is reduced to one or more engines. If the request is subsequently
* bound to a single engine, it will then be constrained to only
* execute on that engine and never returned to the virtual engine
* after timeslicing away, see __unwind_incomplete_requests(). Thus we
* know that if the rq->execution_mask is a single bit, only rq->engine
rq->engine can only be a physical engine, with the exact corresponding mask.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
* can be the exact corresponding engine->mask.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Flush the submission, not cancel it!
On 21/05/2020 13:43, Chris Wilson wrote:
Use intel_engine_flush_submission() when we want to ensure that the
tasklet is run. tasklet_kill(), while it may ensure that an ongoing
tasklet is completed, also prevents the tasklet from running if it's
already scheduled and hasn't yet been run.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1874
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index ef38dd52945c..66f710b1b61e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -332,7 +332,7 @@ static int live_unlite_restore(struct intel_gt *gt, int
prio)
i915_request_put(rq[0]);
err_ce:
- tasklet_kill(>execlists.tasklet); /* flush submission */
+ intel_engine_flush_submission(engine);
igt_spinner_end();
for (n = 0; n < ARRAY_SIZE(ce); n++) {
if (IS_ERR_OR_NULL(ce[n]))
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables
On Thu, May 21, 2020 at 5:36 AM Anshuman Gupta wrote:
>
> On 2020-05-21 at 10:27:21 +0530, Ramalingam C wrote:
> > On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > If userspace sets the CP property to DESIRED while it's already ENABLED,
> > > the driver will try to re-enable HDCP. On some displays, this will
> > > result in R0' mismatches. I'm guessing this is because the display is
> > > still sending back Ri instead of re-authenticating.
> > >
> > > At any rate, we can fix this inefficiency easily enough by just nooping
> > > the DESIRED property set if HDCP is already ENABLED.
> AFAIU may below patch also solves above issue implicitly.
> https://patchwork.freedesktop.org/patch/365758/?series=72251=4
> Besides that +1 for below Ram comment, it would be better if such type of
> duplicate
> enable request should filter by drm_atomic_connector_set_property().
Thanks Anshuman, I didn't see that patch. Indeed that seems like it
accomplishes the same thing.
Let's drop this.
Sean
> Thanks,
> Anshuman Gupta.
>
> > Sean,
> >
> > This will skip the hdcp enable.
> >
> > But at present too we will be getting below WARN_ON from intel_hdcp_enable,
> > to indicate userspace is going wrong with request.
> > drm_WARN_ON(_priv->drm,
> > hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
> >
> > And if we need to filter this out, could we validate the incoming hdcp
> > request at
> > drm_atomic_connector_set_property() itself? No point in going into the
> > atomic commit without a valid request. something like
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a1e5e262bae2..d98b2eeae78d 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -746,6 +746,12 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> > return -EINVAL;
> > }
> > + if (config->content_protection_property ==
> > + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > + val == DRM_MODE_CONTENT_PROTECTION_DESIRED) {
> > + DRM_DEBUG_KMS("Redundant req for content
> > protection\n");
> > + return -EINVAL;
> > + }
> > state->content_protection = val;
> > } else if (property == config->hdcp_content_type_property) {
> > state->hdcp_content_type = val;
> >
> > -Ram
> >
> > >
> > > Signed-off-by: Sean Paul
> > > ---
> > >
> > > I suspect this is the actual root cause I was chasing with
> > > "drm/i915/hdcp: Add additional R0' wait". I was able to reproduce the
> > > R0` messages by marking HDCP desired while it was already enabled. This
> > > _should_ work, but it seems like some displays handle it more graciously
> > > than others.
> > >
> > >
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 2cbc4619b4ce..f770fe0c5595 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -2156,12 +2156,16 @@ void intel_hdcp_atomic_check(struct drm_connector
> > > *connector,
> > > }
> > >
> > > /*
> > > -* Nothing to do if the state didn't change, or HDCP was activated
> > > since
> > > -* the last commit. And also no change in hdcp content type.
> > > +* Nothing to do if content type is unchanged and one of:
> > > +* - state didn't change
> > > +* - HDCP was activated since the last commit
> > > +* - attempting to set to desired while already enabled
> > > */
> > > if (old_cp == new_cp ||
> > > (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> > > -new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> > > +new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> > > + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > > +new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> > > if (old_state->hdcp_content_type ==
> > > new_state->hdcp_content_type)
> > > return;
> > > --
> > > Sean Paul, Software Engineer, Google / Chromium OS
> > >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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/selftests: Flush the submission, not cancel it!
== Series Details == Series: drm/i915/selftests: Flush the submission, not cancel it! URL : https://patchwork.freedesktop.org/series/77510/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17750 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17750/index.html Known issues Here are the changes found in Patchwork_17750 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17750/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8517 -> Patchwork_17750 CI-20190529: 20190529 CI_DRM_8517: 7c5c05e694bf83e9d4ef64172ef6c9d55aa334a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5666: dfa3b1fdc9813a48314a43faaacb7dacc06112d6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17750: c499c490cbf2532dd4f28ee93d54d1c5b7344ffd @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c499c490cbf2 drm/i915/selftests: Flush the submission, not cancel it! == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17750/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Immediately check for ACK after submission
== Series Details == Series: drm/i915/gt: Immediately check for ACK after submission URL : https://patchwork.freedesktop.org/series/77509/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17749 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17749/index.html Known issues Here are the changes found in Patchwork_17749 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17749/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8517 -> Patchwork_17749 CI-20190529: 20190529 CI_DRM_8517: 7c5c05e694bf83e9d4ef64172ef6c9d55aa334a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5666: dfa3b1fdc9813a48314a43faaacb7dacc06112d6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17749: a1e1029490c0d0c2f3770cfd4725a4192c27135f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a1e1029490c0 drm/i915/gt: Immediately check for ACK after submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17749/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Flush the submission, not cancel it!
Use intel_engine_flush_submission() when we want to ensure that the
tasklet is run. tasklet_kill(), while it may ensure that an ongoing
tasklet is completed, also prevents the tasklet from running if it's
already scheduled and hasn't yet been run.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1874
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index ef38dd52945c..66f710b1b61e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -332,7 +332,7 @@ static int live_unlite_restore(struct intel_gt *gt, int
prio)
i915_request_put(rq[0]);
err_ce:
- tasklet_kill(>execlists.tasklet); /* flush submission */
+ intel_engine_flush_submission(engine);
igt_spinner_end();
for (n = 0; n < ARRAY_SIZE(ce); n++) {
if (IS_ERR_OR_NULL(ce[n]))
--
2.27.0.rc0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Immediately check for ACK after submission
In an extreme case this may reduce the ACK latency by handling the
immediate HW response from a ready engine. That reduction in latency
should not actually impact any submission latency since on the direct
submit path we try and clear any pending interrupts first. On the
indirect reprioritisation or timeslicing paths, latency is not the
primary concern as the HW is still executing and will remain so until we
are able to preempt it (i.e. no reduction in effective pipeline stalls).
Still this may help mitigate the loss of softirq, which is a huge
concern.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1874
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index de5be57ed6d2..df77ed2a0a53 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2528,7 +2528,7 @@ gen8_csb_parse(const struct intel_engine_execlists
*execlists, const u32 *csb)
return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
}
-static void process_csb(struct intel_engine_cs *engine)
+static bool process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
const u32 * const buf = execlists->csb_status;
@@ -2557,7 +2557,7 @@ static void process_csb(struct intel_engine_cs *engine)
head = execlists->csb_head;
tail = READ_ONCE(*execlists->csb_write);
if (unlikely(head == tail))
- return;
+ return false;
/*
* Hopefully paired with a wmb() in HW!
@@ -2692,6 +2692,7 @@ static void process_csb(struct intel_engine_cs *engine)
* invalidation before.
*/
invalidate_csb_entries([0], [num_entries - 1]);
+ return true;
}
static void __execlists_submission_tasklet(struct intel_engine_cs *const
engine)
@@ -3116,9 +3117,11 @@ static void execlists_submission_tasklet(unsigned long
data)
if (!READ_ONCE(engine->execlists.pending[0]) || timeout) {
unsigned long flags;
- spin_lock_irqsave(>active.lock, flags);
- __execlists_submission_tasklet(engine);
- spin_unlock_irqrestore(>active.lock, flags);
+ do {
+ spin_lock_irqsave(>active.lock, flags);
+ __execlists_submission_tasklet(engine);
+ spin_unlock_irqrestore(>active.lock, flags);
+ } while (process_csb(engine));
/* Recheck after serialising with direct-submission */
if (unlikely(timeout && preempt_timeout(engine)))
--
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 softirq: Kick ksoftirqd if __do_softirq() is incomplete
== Series Details == Series: softirq: Kick ksoftirqd if __do_softirq() is incomplete URL : https://patchwork.freedesktop.org/series/77508/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17748 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/index.html Known issues Here are the changes found in Patchwork_17748 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] ([i915#1874]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/fi-skl-lmem/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@sanitycheck: - fi-bwr-2160:[PASS][3] -> [INCOMPLETE][4] ([i915#489]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][5] ([i915#62]) -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1874]: https://gitlab.freedesktop.org/drm/intel/issues/1874 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8517 -> Patchwork_17748 CI-20190529: 20190529 CI_DRM_8517: 7c5c05e694bf83e9d4ef64172ef6c9d55aa334a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5666: dfa3b1fdc9813a48314a43faaacb7dacc06112d6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17748: 0b4b1b4015c7e54a2598ff26dbc75fcfe6cbe488 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0b4b1b4015c7 softirq: Kick ksoftirqd if __do_softirq() is incomplete == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17748/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] softirq: Kick ksoftirqd if __do_softirq() is incomplete
When invoking the softirq, a tasklet may be skipped due to contention or
being disabled. The tasklet is then left on the scheduled list, but we
do not wakeup ksoftirqd to retry the execution.
Signed-off-by: Chris Wilson
---
kernel/softirq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index a47c6dd57452..88cec274037d 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -379,9 +379,10 @@ static inline void invoke_softirq(void)
*/
do_softirq_own_stack();
#endif
- } else {
- wakeup_softirqd();
}
+
+ if (local_softirq_pending())
+ wakeup_softirqd();
}
static inline void tick_irq_exit(void)
--
2.27.0.rc0
___
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/gt: Trace the CS interrupt (rev10)
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev10) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17747 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/index.html Known issues Here are the changes found in Patchwork_17747 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-tgl-y: [PASS][1] -> [INCOMPLETE][2] ([i915#1803]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-tgl-y/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/fi-tgl-y/igt@i915_selftest@l...@execlists.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][3] ([i915#62]) -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1803]: https://gitlab.freedesktop.org/drm/intel/issues/1803 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8517 -> Patchwork_17747 CI-20190529: 20190529 CI_DRM_8517: 7c5c05e694bf83e9d4ef64172ef6c9d55aa334a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5666: dfa3b1fdc9813a48314a43faaacb7dacc06112d6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17747: 9bcedd75ca6b5565a365e478c0cd5c9592260f8e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9bcedd75ca6b drm/i915/gt: Trace the CS interrupt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17747/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Exercise stalls of bonded pairs
Broadwell doesn't allow preemption and so a request must complete within
a hangcheck period or be declared hung. A bonded request may be
submitted before it's master is ready to run, and if preemption is
disabled there is a danger that wait may be charged against the bond,
rather than the culprit that is causing the master to hang.
This test tries to stall the master by blocking it with a high priority
spinner (or a queue of them) and verifies that we do not accidentally
reset the bonds.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 108 +++--
1 file changed, 104 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 573d09545..19543088f 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,95 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_nohang(int i915, uint32_t ctx,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count,
+ unsigned int flags)
+#define NOHANG 0x1
+{
+ struct drm_i915_gem_exec_object2 batch = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ };
+ igt_spin_t *time, *spin;
+ uint32_t load;
+
+ load = gem_context_create(i915);
+ gem_context_set_priority(i915, load, 1023);
+ set_load_balancer(i915, load, siblings, count, NULL);
+
+ spin = igt_spin_new(i915, load, .engine = 1);
+
+ /* Master on engine 1, stuck behind a spinner */
+ execbuf.flags = 1 | I915_EXEC_FENCE_OUT;
+ gem_execbuf_wr(i915, );
+
+ /* Bond on engine 2, engine clear bond can be submitted immediately */
+ execbuf.rsvd2 >>= 32;
+ execbuf.flags = 2 | I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
+ gem_execbuf_wr(i915, );
+
+ igt_debugfs_dump(i915, "i915_engine_info");
+
+ /* The master will remain blocked until the spinner is reset */
+ time = igt_spin_new(i915); /* rcs0 */
+ while (gem_bo_busy(i915, time->handle)) {
+ igt_spin_t *next;
+
+ if (flags & NOHANG) {
+ /* Keep replacing spin, so that it doesn't hang */
+ next = igt_spin_new(i915, load, .engine = 1);
+ igt_spin_free(i915, spin);
+ spin = next;
+ }
+
+ if (!gem_bo_busy(i915, batch.handle))
+ break;
+ }
+ igt_spin_free(i915, time);
+ igt_spin_free(i915, spin);
+
+ /* Check the bonded pair completed were not declared hung */
+ igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0x), 1);
+ igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
+
+ close(execbuf.rsvd2);
+ close(execbuf.rsvd2 >> 32);
+
+ gem_context_destroy(i915, load);
+ gem_close(i915, batch.handle);
+}
+
+static void bonded_nohang(int i915, unsigned int flags)
+{
+ uint32_t ctx;
+
+ /*
+* We try and trick ourselves into declaring a bonded request as
+* hung by preventing the master from running [after submission].
+*/
+
+ igt_require(gem_scheduler_has_semaphores(i915));
+
+ ctx = gem_context_create(i915);
+
+ for (int class = 1; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, );
+ if (count > 1)
+ __bonded_nohang(i915, ctx, siblings, count, flags);
+ free(siblings);
+ }
+
+ gem_context_destroy(i915, ctx);
+}
+
static void indices(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, I915_EXEC_RING_MASK + 1);
@@ -2199,11 +2288,22 @@ igt_main
igt_stop_hang_detector();
}
- igt_subtest("hang") {
- igt_hang_t hang = igt_allow_hang(i915, 0, 0);
+ igt_subtest_group {
+ igt_hang_t hang;
+
+ igt_fixture
+ hang = igt_allow_hang(i915, 0, 0);
+
+ igt_subtest("bonded-false-hang")
+ bonded_nohang(i915, NOHANG);
+
+ igt_subtest("bonded-true-hang")
+ bonded_nohang(i915, 0);
- hangme(i915);
+ igt_fixture
+ igt_disallow_hang(i915, hang);
- igt_disallow_hang(i915, hang);
+ igt_subtest("hang")
+ hangme(i915);
}
}
--
2.27.0.rc0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2)
== Series Details == Series: series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77503/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17746 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/index.html Known issues Here are the changes found in Patchwork_17746 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][1] ([i915#62]) -> [FAIL][2] ([i915#62] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8517 -> Patchwork_17746 CI-20190529: 20190529 CI_DRM_8517: 7c5c05e694bf83e9d4ef64172ef6c9d55aa334a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5666: dfa3b1fdc9813a48314a43faaacb7dacc06112d6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17746: 4e08f95c12826459d82860a64ead6e39d4f04418 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4e08f95c1282 drm/i915: Avoid using rq->engine after free during i915_fence_release 17642944c3fe drm/i915: Disable semaphore inter-engine sync without timeslicing == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17746/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
Quoting Chris Wilson (2020-05-21 10:42:26)
> Quoting Tvrtko Ursulin (2020-05-21 10:10:10)
> >
> > On 21/05/2020 09:53, Chris Wilson wrote:
> > > Since the remove of the no-semaphore boosting, we rely on timeslicing to
> > > reorder past inter-dependency hogs across the engines. However, we
> > > require preemption to support timeslicing into user payloads, and not all
> > > machine support preemption so we do not universally enable timeslicing
> > > even when it would preempt our own inter-engine semaphores.
> > >
> > > Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
> > > Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
> > > Signed-off-by: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > Cc: Mika Kuoppala
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > index 900ea8b7fc8f..f5d59d18cd5b 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > @@ -230,7 +230,7 @@ static void intel_context_set_gem(struct
> > > intel_context *ce,
> > > ce->timeline = intel_timeline_get(ctx->timeline);
> > >
> > > if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > > - intel_engine_has_semaphores(ce->engine))
> > > + intel_engine_has_timeslices(ce->engine))
> > > __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> > > }
> > >
> > > @@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context
> > > *ce, void *arg)
> > > {
> > > struct i915_gem_context *ctx = arg;
> > >
> > > - if (!intel_engine_has_semaphores(ce->engine))
> > > + if (!intel_engine_has_timeslices(ce->engine))
> > > return 0;
> > >
> > > if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
> > >
> >
> > __i915_request_await_execution is okay to keep using semaphores?
>
> I think so. Using semaphores there still benefits from synchronising
> with a master in ELSP[1]. The danger is that it does increase the
> hangcheck possibility for the bond request, such that a slow request
> before the master would result in us declaring the bond hung. The
> question is whether that is worse than executing the bond before the
> master.
>
> I should be able to write a test to demonstrate the hang in the bond.
> For example, if we do something like:
>
> on master engine:
> submit spin
> submit master -> submit fence -> submit bond
> for(;;)
> submit high priority spin
> terminate previous spin
>
> Hmm. But without preemption... master will execute before we get a
> chance to submit the high priority spinners. So this will not actually
> hang.
>
> Ok, so this is safer than it seems :)
Even more so, since we do preempt the semaphore for the hangcheck.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2)
== Series Details == Series: series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77503/ 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/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/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression ___ 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/gt: Trace the CS interrupt (rev9)
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev9) URL : https://patchwork.freedesktop.org/series/77441/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17745 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17745 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17745, 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_17745/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17745: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-apl-guc: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17745/fi-apl-guc/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17745 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][2] -> [DMESG-FAIL][3] ([i915#165]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17745/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][4] ([i915#62]) -> [SKIP][5] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8517/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17745/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8517 -> Patchwork_17745 CI-20190529: 20190529 CI_DRM_8517: 7c5c05e694bf83e9d4ef64172ef6c9d55aa334a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5666: dfa3b1fdc9813a48314a43faaacb7dacc06112d6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17745: daf509d8a40bef29edb99364bc2d970a4cb5cbee @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == daf509d8a40b drm/i915/gt: Trace the CS interrupt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17745/index.html ___ 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: Avoid using rq->engine after free during i915_fence_release
Quoting Chris Wilson (2020-05-21 10:32:49)
> Quoting Chris Wilson (2020-05-21 10:27:16)
> > Quoting Tvrtko Ursulin (2020-05-21 10:13:14)
> > >
> > > On 21/05/2020 09:53, Chris Wilson wrote:
> > > > In order to be valid to dereference during the i915_fence_release, after
> > > > retiring the fence and releasing its refererences, we assume that
> > > > rq->engine can only be a real engine (that stay intact until the device
> > > > is shutdown after all fences have been flushed). However, due to a quirk
> > > > of preempt-to-busy, we may retire a request that still belongs to a
> > > > virtual engine and so eventually free it with rq->engine being invalid.
> > > > To avoid dereferencing that invalid engine, we look at the
> > > > execution_mask which if it indicates it may be executed on more than one
> > > > engine, we know it originated on a virtual engine and may still be on
> > > > one.
> > > >
> > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
> > > > Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Tvrtko Ursulin
> > > > ---
> > > > drivers/gpu/drm/i915/i915_request.c | 25 +++--
> > > > 1 file changed, 23 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > > > b/drivers/gpu/drm/i915/i915_request.c
> > > > index 526c1e9acbd5..6e357183bece 100644
> > > > --- a/drivers/gpu/drm/i915/i915_request.c
> > > > +++ b/drivers/gpu/drm/i915/i915_request.c
> > > > @@ -121,8 +121,29 @@ static void i915_fence_release(struct dma_fence
> > > > *fence)
> > > > i915_sw_fence_fini(>submit);
> > > > i915_sw_fence_fini(>semaphore);
> > > >
> > > > - /* Keep one request on each engine for reserved use under
> > > > mempressure */
> > > > - if (!cmpxchg(>engine->request_pool, NULL, rq))
> > > > + /*
> > > > + * Keep one request on each engine for reserved use under
> > > > mempressure
> > > > + *
> > > > + * We do not hold a reference to the engine here and so have to be
> > > > + * very careful in what rq->engine we poke. The virtual engine is
> > > > + * referenced via the rq->context and we released that ref during
> > > > + * i915_request_retire(), ergo we must not dereference a virtual
> > > > + * engine here. Not that we would want to, as the only consumer of
> > > > + * the reserved engine->request_pool is the powermanagent parking,
> > >
> > > power management
> > >
> > > > + * which must-not-fail, and that is only run on the physical
> > > > engines.
> > > > + *
> > > > + * Since the request must have been executed to be have completed,
> > > > + * we know that it will have been processed by the HW and will
> > > > + * not be unsubmitted again, so rq->engine and rq->execution_mask
> > > > + * at this point is stable. rq->execution_mask will be a single
> > > > + * bit if the last and only engine it could execution on was a
> > > > + * physical engine, if it's multiple bits then it started on and
> > > > + * could still be on a virtual engine. Thus if the mask is not a
> > > > + * power-of-two we assume that rq->engine may still be a virtual
> > > > + * engien and so a dangling invalid pointer that we cannot
> > >
> > > engine
> > >
> > > But.. submit fence can mask out execution_mask bits and make it appear
> > > the request was on a physical engine. What then?
> >
> > Then we execute along a single engine and it is never returned to the
> > virtual engine (in __unwind_incomplete_requests).
>
> * For example, consider the flow of a bonded request through a
> virtual
> * engine. The request is created with a wide engine mask (all engines
> * that we might execute on). On processing the bond, the request mask
> * is reduced to one or more engines. If the request is subsequently
> * bound to a single engine, it will then be constrained to only
> * execute on that engine and never returned to the virtual engine
> * after timeslicing away, see __unwind_incomplete_requests(). Thus we
> * know that if the rq->execution_mask is a single bit, only
> rq->engine
rq->engine can only be a physical engine, with the exact corresponding mask.
> * can be the exact corresponding engine->mask.
>
> -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/i915: Disable semaphore inter-engine sync without timeslicing
Quoting Tvrtko Ursulin (2020-05-21 10:10:10)
>
> On 21/05/2020 09:53, Chris Wilson wrote:
> > Since the remove of the no-semaphore boosting, we rely on timeslicing to
> > reorder past inter-dependency hogs across the engines. However, we
> > require preemption to support timeslicing into user payloads, and not all
> > machine support preemption so we do not universally enable timeslicing
> > even when it would preempt our own inter-engine semaphores.
> >
> > Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
> > Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 900ea8b7fc8f..f5d59d18cd5b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context
> > *ce,
> > ce->timeline = intel_timeline_get(ctx->timeline);
> >
> > if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > - intel_engine_has_semaphores(ce->engine))
> > + intel_engine_has_timeslices(ce->engine))
> > __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> > }
> >
> > @@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce,
> > void *arg)
> > {
> > struct i915_gem_context *ctx = arg;
> >
> > - if (!intel_engine_has_semaphores(ce->engine))
> > + if (!intel_engine_has_timeslices(ce->engine))
> > return 0;
> >
> > if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
> >
>
> __i915_request_await_execution is okay to keep using semaphores?
I think so. Using semaphores there still benefits from synchronising
with a master in ELSP[1]. The danger is that it does increase the
hangcheck possibility for the bond request, such that a slow request
before the master would result in us declaring the bond hung. The
question is whether that is worse than executing the bond before the
master.
I should be able to write a test to demonstrate the hang in the bond.
For example, if we do something like:
on master engine:
submit spin
submit master -> submit fence -> submit bond
for(;;)
submit high priority spin
terminate previous spin
Hmm. But without preemption... master will execute before we get a
chance to submit the high priority spinners. So this will not actually
hang.
Ok, so this is safer than it seems :)
Just need to write that test and execute it on broadwell to verify my
claim.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables
On 2020-05-21 at 10:27:21 +0530, Ramalingam C wrote:
> On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > If userspace sets the CP property to DESIRED while it's already ENABLED,
> > the driver will try to re-enable HDCP. On some displays, this will
> > result in R0' mismatches. I'm guessing this is because the display is
> > still sending back Ri instead of re-authenticating.
> >
> > At any rate, we can fix this inefficiency easily enough by just nooping
> > the DESIRED property set if HDCP is already ENABLED.
AFAIU may below patch also solves above issue implicitly.
https://patchwork.freedesktop.org/patch/365758/?series=72251=4
Besides that +1 for below Ram comment, it would be better if such type of
duplicate
enable request should filter by drm_atomic_connector_set_property().
Thanks,
Anshuman Gupta.
> Sean,
>
> This will skip the hdcp enable.
>
> But at present too we will be getting below WARN_ON from intel_hdcp_enable,
> to indicate userspace is going wrong with request.
> drm_WARN_ON(_priv->drm,
> hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
>
> And if we need to filter this out, could we validate the incoming hdcp
> request at
> drm_atomic_connector_set_property() itself? No point in going into the
> atomic commit without a valid request. something like
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a1e5e262bae2..d98b2eeae78d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -746,6 +746,12 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> return -EINVAL;
> }
> + if (config->content_protection_property ==
> + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + val == DRM_MODE_CONTENT_PROTECTION_DESIRED) {
> + DRM_DEBUG_KMS("Redundant req for content
> protection\n");
> + return -EINVAL;
> + }
> state->content_protection = val;
> } else if (property == config->hdcp_content_type_property) {
> state->hdcp_content_type = val;
>
> -Ram
>
> >
> > Signed-off-by: Sean Paul
> > ---
> >
> > I suspect this is the actual root cause I was chasing with
> > "drm/i915/hdcp: Add additional R0' wait". I was able to reproduce the
> > R0` messages by marking HDCP desired while it was already enabled. This
> > _should_ work, but it seems like some displays handle it more graciously
> > than others.
> >
> >
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 2cbc4619b4ce..f770fe0c5595 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2156,12 +2156,16 @@ void intel_hdcp_atomic_check(struct drm_connector
> > *connector,
> > }
> >
> > /*
> > -* Nothing to do if the state didn't change, or HDCP was activated since
> > -* the last commit. And also no change in hdcp content type.
> > +* Nothing to do if content type is unchanged and one of:
> > +* - state didn't change
> > +* - HDCP was activated since the last commit
> > +* - attempting to set to desired while already enabled
> > */
> > if (old_cp == new_cp ||
> > (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> > -new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> > +new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> > + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > +new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> > if (old_state->hdcp_content_type ==
> > new_state->hdcp_content_type)
> > return;
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK (rev18)
Seems to be unrelated issue. There seems to be some list corruption happening
in drm fb manipulation code.
if those patches would be causing that (like some severe mem corruption)- it
would happen much more broadly than single test and single platform. Moreover
there is no direct connection to the changes.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Patchwork
Sent: Thursday, May 21, 2020 9:55:27 AM
To: Lisovskiy, Stanislav
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating
CDCLK (rev18)
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev18)
URL : https://patchwork.freedesktop.org/series/74739/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17733_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17733_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17733_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_17733_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a2}:
- shard-glk: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
Known issues
Here are the changes found in Patchwork_17733_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-hostile@bcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#1622])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb3/igt@gem_ctx_persistence@engines-host...@bcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-iclb2/igt@gem_ctx_persistence@engines-host...@bcs0.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-apl7/igt@gem_soft...@noreloc-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-apl4/igt@gem_soft...@noreloc-s3.html
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_soft...@noreloc-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_soft...@noreloc-s3.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([i915#155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_selftest@live@execlists:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#1874])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl2/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl5/igt@i915_selftest@l...@execlists.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#1119] / [i915#118] /
[i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk6/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement:
- shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html
[18]:
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release
Quoting Chris Wilson (2020-05-21 10:27:16)
> Quoting Tvrtko Ursulin (2020-05-21 10:13:14)
> >
> > On 21/05/2020 09:53, Chris Wilson wrote:
> > > In order to be valid to dereference during the i915_fence_release, after
> > > retiring the fence and releasing its refererences, we assume that
> > > rq->engine can only be a real engine (that stay intact until the device
> > > is shutdown after all fences have been flushed). However, due to a quirk
> > > of preempt-to-busy, we may retire a request that still belongs to a
> > > virtual engine and so eventually free it with rq->engine being invalid.
> > > To avoid dereferencing that invalid engine, we look at the
> > > execution_mask which if it indicates it may be executed on more than one
> > > engine, we know it originated on a virtual engine and may still be on
> > > one.
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
> > > Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
> > > Signed-off-by: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > ---
> > > drivers/gpu/drm/i915/i915_request.c | 25 +++--
> > > 1 file changed, 23 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > > b/drivers/gpu/drm/i915/i915_request.c
> > > index 526c1e9acbd5..6e357183bece 100644
> > > --- a/drivers/gpu/drm/i915/i915_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_request.c
> > > @@ -121,8 +121,29 @@ static void i915_fence_release(struct dma_fence
> > > *fence)
> > > i915_sw_fence_fini(>submit);
> > > i915_sw_fence_fini(>semaphore);
> > >
> > > - /* Keep one request on each engine for reserved use under
> > > mempressure */
> > > - if (!cmpxchg(>engine->request_pool, NULL, rq))
> > > + /*
> > > + * Keep one request on each engine for reserved use under
> > > mempressure
> > > + *
> > > + * We do not hold a reference to the engine here and so have to be
> > > + * very careful in what rq->engine we poke. The virtual engine is
> > > + * referenced via the rq->context and we released that ref during
> > > + * i915_request_retire(), ergo we must not dereference a virtual
> > > + * engine here. Not that we would want to, as the only consumer of
> > > + * the reserved engine->request_pool is the powermanagent parking,
> >
> > power management
> >
> > > + * which must-not-fail, and that is only run on the physical
> > > engines.
> > > + *
> > > + * Since the request must have been executed to be have completed,
> > > + * we know that it will have been processed by the HW and will
> > > + * not be unsubmitted again, so rq->engine and rq->execution_mask
> > > + * at this point is stable. rq->execution_mask will be a single
> > > + * bit if the last and only engine it could execution on was a
> > > + * physical engine, if it's multiple bits then it started on and
> > > + * could still be on a virtual engine. Thus if the mask is not a
> > > + * power-of-two we assume that rq->engine may still be a virtual
> > > + * engien and so a dangling invalid pointer that we cannot
> >
> > engine
> >
> > But.. submit fence can mask out execution_mask bits and make it appear
> > the request was on a physical engine. What then?
>
> Then we execute along a single engine and it is never returned to the
> virtual engine (in __unwind_incomplete_requests).
* For example, consider the flow of a bonded request through a virtual
* engine. The request is created with a wide engine mask (all engines
* that we might execute on). On processing the bond, the request mask
* is reduced to one or more engines. If the request is subsequently
* bound to a single engine, it will then be constrained to only
* execute on that engine and never returned to the virtual engine
* after timeslicing away, see __unwind_incomplete_requests(). Thus we
* know that if the rq->execution_mask is a single bit, only rq->engine
* can be the exact corresponding engine->mask.
-Chris
___
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: Avoid using rq->engine after free during i915_fence_release
Quoting Tvrtko Ursulin (2020-05-21 10:13:14)
>
> On 21/05/2020 09:53, Chris Wilson wrote:
> > In order to be valid to dereference during the i915_fence_release, after
> > retiring the fence and releasing its refererences, we assume that
> > rq->engine can only be a real engine (that stay intact until the device
> > is shutdown after all fences have been flushed). However, due to a quirk
> > of preempt-to-busy, we may retire a request that still belongs to a
> > virtual engine and so eventually free it with rq->engine being invalid.
> > To avoid dereferencing that invalid engine, we look at the
> > execution_mask which if it indicates it may be executed on more than one
> > engine, we know it originated on a virtual engine and may still be on
> > one.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
> > Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 25 +++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 526c1e9acbd5..6e357183bece 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -121,8 +121,29 @@ static void i915_fence_release(struct dma_fence *fence)
> > i915_sw_fence_fini(>submit);
> > i915_sw_fence_fini(>semaphore);
> >
> > - /* Keep one request on each engine for reserved use under mempressure
> > */
> > - if (!cmpxchg(>engine->request_pool, NULL, rq))
> > + /*
> > + * Keep one request on each engine for reserved use under mempressure
> > + *
> > + * We do not hold a reference to the engine here and so have to be
> > + * very careful in what rq->engine we poke. The virtual engine is
> > + * referenced via the rq->context and we released that ref during
> > + * i915_request_retire(), ergo we must not dereference a virtual
> > + * engine here. Not that we would want to, as the only consumer of
> > + * the reserved engine->request_pool is the powermanagent parking,
>
> power management
>
> > + * which must-not-fail, and that is only run on the physical engines.
> > + *
> > + * Since the request must have been executed to be have completed,
> > + * we know that it will have been processed by the HW and will
> > + * not be unsubmitted again, so rq->engine and rq->execution_mask
> > + * at this point is stable. rq->execution_mask will be a single
> > + * bit if the last and only engine it could execution on was a
> > + * physical engine, if it's multiple bits then it started on and
> > + * could still be on a virtual engine. Thus if the mask is not a
> > + * power-of-two we assume that rq->engine may still be a virtual
> > + * engien and so a dangling invalid pointer that we cannot
>
> engine
>
> But.. submit fence can mask out execution_mask bits and make it appear
> the request was on a physical engine. What then?
Then we execute along a single engine and it is never returned to the
virtual engine (in __unwind_incomplete_requests).
+ * at this point is stable. rq->execution_mask will be a single
+ * bit if the last and only engine it could execution on was a
+ * physical engine, if it's multiple bits then it started on and
-Chris
___
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: Avoid using rq->engine after free during i915_fence_release
On 21/05/2020 09:53, Chris Wilson wrote:
In order to be valid to dereference during the i915_fence_release, after
retiring the fence and releasing its refererences, we assume that
rq->engine can only be a real engine (that stay intact until the device
is shutdown after all fences have been flushed). However, due to a quirk
of preempt-to-busy, we may retire a request that still belongs to a
virtual engine and so eventually free it with rq->engine being invalid.
To avoid dereferencing that invalid engine, we look at the
execution_mask which if it indicates it may be executed on more than one
engine, we know it originated on a virtual engine and may still be on
one.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 526c1e9acbd5..6e357183bece 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -121,8 +121,29 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(>submit);
i915_sw_fence_fini(>semaphore);
- /* Keep one request on each engine for reserved use under mempressure */
- if (!cmpxchg(>engine->request_pool, NULL, rq))
+ /*
+* Keep one request on each engine for reserved use under mempressure
+*
+* We do not hold a reference to the engine here and so have to be
+* very careful in what rq->engine we poke. The virtual engine is
+* referenced via the rq->context and we released that ref during
+* i915_request_retire(), ergo we must not dereference a virtual
+* engine here. Not that we would want to, as the only consumer of
+* the reserved engine->request_pool is the powermanagent parking,
power management
+* which must-not-fail, and that is only run on the physical engines.
+*
+* Since the request must have been executed to be have completed,
+* we know that it will have been processed by the HW and will
+* not be unsubmitted again, so rq->engine and rq->execution_mask
+* at this point is stable. rq->execution_mask will be a single
+* bit if the last and only engine it could execution on was a
+* physical engine, if it's multiple bits then it started on and
+* could still be on a virtual engine. Thus if the mask is not a
+* power-of-two we assume that rq->engine may still be a virtual
+ * engien and so a dangling invalid pointer that we cannot
engine
But.. submit fence can mask out execution_mask bits and make it appear
the request was on a physical engine. What then?
Regards,
Tvrtko
dereference
+*/
+ if (is_power_of_2(rq->execution_mask) &&
+ !cmpxchg(>engine->request_pool, NULL, rq))
return;
kmem_cache_free(global.slab_requests, rq);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
On 21/05/2020 09:53, Chris Wilson wrote:
Since the remove of the no-semaphore boosting, we rely on timeslicing to
reorder past inter-dependency hogs across the engines. However, we
require preemption to support timeslicing into user payloads, and not all
machine support preemption so we do not universally enable timeslicing
even when it would preempt our own inter-engine semaphores.
Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..f5d59d18cd5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->timeline = intel_timeline_get(ctx->timeline);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
+ intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
}
@@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce, void *arg)
{
struct i915_gem_context *ctx = arg;
- if (!intel_engine_has_semaphores(ce->engine))
+ if (!intel_engine_has_timeslices(ce->engine))
return 0;
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
__i915_request_await_execution is okay to keep using semaphores?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable semaphore inter-engine sync without timeslicing
Since the removal of the no-semaphore boosting, we rely on timeslicing to
reorder passed inter-dependency hogs across the engines. However, we
require preemption to support timeslicing into user payloads, and not all
machine support preemption so we do not universally enable timeslicing,
even when it would correctly preempt our own inter-engine semaphores.
Since timeslicing and semaphore priority deboosting is now disabled on
Broadwell/Braswell, we have to follow suite and not use semaphores.
Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..f5d59d18cd5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->timeline = intel_timeline_get(ctx->timeline);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
+ intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
}
@@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce,
void *arg)
{
struct i915_gem_context *ctx = arg;
- if (!intel_engine_has_semaphores(ce->engine))
+ if (!intel_engine_has_timeslices(ce->engine))
return 0;
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release
In order to be valid to dereference during the i915_fence_release, after
retiring the fence and releasing its refererences, we assume that
rq->engine can only be a real engine (that stay intact until the device
is shutdown after all fences have been flushed). However, due to a quirk
of preempt-to-busy, we may retire a request that still belongs to a
virtual engine and so eventually free it with rq->engine being invalid.
To avoid dereferencing that invalid engine, we look at the
execution_mask which if it indicates it may be executed on more than one
engine, we know it originated on a virtual engine and may still be on
one.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 526c1e9acbd5..6e357183bece 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -121,8 +121,29 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(>submit);
i915_sw_fence_fini(>semaphore);
- /* Keep one request on each engine for reserved use under mempressure */
- if (!cmpxchg(>engine->request_pool, NULL, rq))
+ /*
+* Keep one request on each engine for reserved use under mempressure
+*
+* We do not hold a reference to the engine here and so have to be
+* very careful in what rq->engine we poke. The virtual engine is
+* referenced via the rq->context and we released that ref during
+* i915_request_retire(), ergo we must not dereference a virtual
+* engine here. Not that we would want to, as the only consumer of
+* the reserved engine->request_pool is the powermanagent parking,
+* which must-not-fail, and that is only run on the physical engines.
+*
+* Since the request must have been executed to be have completed,
+* we know that it will have been processed by the HW and will
+* not be unsubmitted again, so rq->engine and rq->execution_mask
+* at this point is stable. rq->execution_mask will be a single
+* bit if the last and only engine it could execution on was a
+* physical engine, if it's multiple bits then it started on and
+* could still be on a virtual engine. Thus if the mask is not a
+* power-of-two we assume that rq->engine may still be a virtual
+* engien and so a dangling invalid pointer that we cannot dereference
+*/
+ if (is_power_of_2(rq->execution_mask) &&
+ !cmpxchg(>engine->request_pool, NULL, rq))
return;
kmem_cache_free(global.slab_requests, rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing
Since the remove of the no-semaphore boosting, we rely on timeslicing to
reorder past inter-dependency hogs across the engines. However, we
require preemption to support timeslicing into user payloads, and not all
machine support preemption so we do not universally enable timeslicing
even when it would preempt our own inter-engine semaphores.
Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..f5d59d18cd5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->timeline = intel_timeline_get(ctx->timeline);
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
+ intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
}
@@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce,
void *arg)
{
struct i915_gem_context *ctx = arg;
- if (!intel_engine_has_semaphores(ce->engine))
+ if (!intel_engine_has_timeslices(ce->engine))
return 0;
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
--
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/selftests: Measure CS_TIMESTAMP (rev5)
== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev5) URL : https://patchwork.freedesktop.org/series/77320/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516 -> Patchwork_17744 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/index.html Known issues Here are the changes found in Patchwork_17744 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_engines: - fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] ([i915#489]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/fi-bwr-2160/igt@i915_selftest@live@gt_engines.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/fi-bwr-2160/igt@i915_selftest@live@gt_engines.html [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8516 -> Patchwork_17744 CI-20190529: 20190529 CI_DRM_8516: 5db9df14788c0a6038aa05e180cde8065d724e43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5665: c5e5b0ce26fc321591a6d0235c639a1e8ec3cdfa @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17744: f49741c693787f2bf8cadf68d744a0dcb55813ac @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f49741c69378 drm/i915/selftests: Measure CS_TIMESTAMP == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17744/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/37] drm/i915/dg1: Handle GRF/IC ECC error irq
Quoting Lucas De Marchi (2020-05-21 01:37:52)
> From: Fernando Pacheco
>
> The error detection and correction capability
> for GRF and instruction cache (IC) will utilize
> the new interrupt and error handling infrastructure
> for dgfx products. The GFX device can generate
> a number of classes of error under the new
> infrastructure: correctable, non-fatal, and
> fatal errors.
>
> The non-fatal and fatal error classes distinguish
> between levels of severity for uncorrectable errors.
> All ECC uncorrectable errors will be reported as
> fatal to produce the desired system response. Fatal
> errors are expected to route as PCIe error messages
> which should result in OS issuing a GFX device FLR.
> But the option exists to route fatal errors as
> interrupts.
>
> Driver will only handle logging of errors. Anything
> more will be handled at system level.
>
> For errors that will route as interrupts, three
> bits in the Master Interrupt Register will be used
> to convey the class of error.
>
> For each class of error:
> 1. Determine source of error (IP block) by reading
>the Device Error Source Register (RW1C) that
>corresponds to the class of error being serviced.
> 2. If the generating IP block is GT, read and log the
>GT Error Register (RW1C) that corresponds to the
>class of error being serviced. Non-GT errors will
>be logged in aggregate for now.
>
> Bspec: 50875
>
> Cc: Paulo Zanoni
> Cc: Daniele Ceraolo Spurio
> Cc: Fernando Pacheco
> Cc: Radhakrishna Sripada
> Signed-off-by: Fernando Pacheco
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_irq.c | 121
> drivers/gpu/drm/i915/i915_reg.h | 28
> 2 files changed, 149 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ebc80e8b1599..17e679b910da 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2515,6 +2515,124 @@ static irqreturn_t gen8_irq_handler(int irq, void
> *arg)
> return IRQ_HANDLED;
> }
>
> +static const char *
> +hardware_error_type_to_str(const enum hardware_error hw_err)
> +{
> + switch (hw_err) {
> + case HARDWARE_ERROR_CORRECTABLE:
> + return "CORRECTABLE";
> + case HARDWARE_ERROR_NONFATAL:
> + return "NONFATAL";
> + case HARDWARE_ERROR_FATAL:
> + return "FATAL";
> + default:
> + return "UNKNOWN";
> + }
> +}
> +
> +static void
> +gen12_gt_hw_error_handler(struct drm_i915_private * const i915,
> + const enum hardware_error hw_err)
> +{
> + void __iomem * const regs = i915->uncore.regs;
> + const char *hw_err_str = hardware_error_type_to_str(hw_err);
> + u32 other_errors = ~(EU_GRF_ERROR | EU_IC_ERROR);
> + u32 errstat;
> +
> + lockdep_assert_held(>irq_lock);
Wrong place and wrong locks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/37] drm/i915: add pcie snoop flag
Quoting Lucas De Marchi (2020-05-21 01:37:36) > From: Matthew Auld > > Gen 12 dgfx devices are coherent with system memory even over PCIe. > Therefore supporting coherent userptr should be possible. Then set has-snoop with a comment that it is over PCIe. This patch only covers one cache-coherent usecase, not all of them. Why not? -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/selftests: Measure CS_TIMESTAMP (rev5)
== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev5) URL : https://patchwork.freedesktop.org/series/77320/ State : warning == Summary == $ dim checkpatch origin/drm-tip f49741c69378 drm/i915/selftests: Measure CS_TIMESTAMP -:68: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst #68: FILE: drivers/gpu/drm/i915/gt/selftest_gt_pm.c:52: + udelay(1000); total: 0 errors, 0 warnings, 1 checks, 148 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Trace the CS interrupt (rev8)
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev8) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516 -> Patchwork_17743 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17743/index.html Changes --- No changes found Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8516 -> Patchwork_17743 CI-20190529: 20190529 CI_DRM_8516: 5db9df14788c0a6038aa05e180cde8065d724e43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5665: c5e5b0ce26fc321591a6d0235c639a1e8ec3cdfa @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17743: 69a4b2642f607d164470a3cf5f601e232f583022 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 69a4b2642f60 drm/i915/gt: Trace the CS interrupt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17743/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)
== Series Details == Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3) URL : https://patchwork.freedesktop.org/series/77382/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516 -> Patchwork_17742 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/index.html Known issues Here are the changes found in Patchwork_17742 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#1250] / [i915#1436]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/fi-bsw-nick/igt@debugfs_test@read_all_entries.html * igt@i915_selftest@live@sanitycheck: - fi-bwr-2160:[PASS][3] -> [INCOMPLETE][4] ([i915#489]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][5] ([fdo#109271]) -> [FAIL][6] ([i915#62]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8516/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (46 -> 42) -- Additional (1): fi-kbl-7560u Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8516 -> Patchwork_17742 CI-20190529: 20190529 CI_DRM_8516: 5db9df14788c0a6038aa05e180cde8065d724e43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5665: c5e5b0ce26fc321591a6d0235c639a1e8ec3cdfa @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17742: 6b14c700b9d472d7cc7602f9105b533e2400d197 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6b14c700b9d4 drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17742/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/selftests: Measure CS_TIMESTAMP
Count the number of CS_TIMESTAMP ticks and check that it matches our
expectations.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 132 +++
1 file changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index 242181a5214c..6180a47c1b51 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -5,10 +5,141 @@
* Copyright © 2019 Intel Corporation
*/
+#include
+
+#include "intel_gt_clock_utils.h"
+
#include "selftest_llc.h"
#include "selftest_rc6.h"
#include "selftest_rps.h"
+static int cmp_u64(const void *A, const void *B)
+{
+ const u64 *a = A, *b = B;
+
+ if (a < b)
+ return -1;
+ else if (a > b)
+ return 1;
+ else
+ return 0;
+}
+
+static int cmp_u32(const void *A, const void *B)
+{
+ const u32 *a = A, *b = B;
+
+ if (a < b)
+ return -1;
+ else if (a > b)
+ return 1;
+ else
+ return 0;
+}
+
+static void measure_clocks(struct intel_engine_cs *engine,
+ u32 *out_cycles, ktime_t *out_dt)
+{
+ ktime_t dt[5];
+ u32 cycles[5];
+ int i;
+
+ for (i = 0; i < 5; i++) {
+ preempt_disable();
+ cycles[i] = -ENGINE_READ_FW(engine, RING_TIMESTAMP);
+ dt[i] = ktime_get();
+
+ udelay(1000);
+
+ dt[i] = ktime_sub(ktime_get(), dt[i]);
+ cycles[i] += ENGINE_READ_FW(engine, RING_TIMESTAMP);
+ preempt_enable();
+ }
+
+ /* Use the median of both cycle/dt; close enough */
+ sort(cycles, 5, sizeof(*cycles), cmp_u32, NULL);
+ *out_cycles = (cycles[1] + 2 * cycles[2] + cycles[3]) / 4;
+
+ sort(dt, 5, sizeof(*dt), cmp_u64, NULL);
+ *out_dt = div_u64(dt[1] + 2 * dt[2] + dt[3], 4);
+}
+
+static int live_gt_clocks(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int err = 0;
+
+ if (!RUNTIME_INFO(gt->i915)->cs_timestamp_frequency_hz) { /* unknown */
+ pr_info("CS_TIMESTAMP frequency unknown\n");
+ return 0;
+ }
+
+ if (INTEL_GEN(gt->i915) < 4) /* Any CS_TIMESTAMP? */
+ return 0;
+
+ if (IS_GEN(gt->i915, 5))
+ /*
+* XXX CS_TIMESTAMP low dword is dysfunctional?
+*
+* Ville's experiments indicate the high dword still works,
+* but at a correspondingly reduced frequency.
+*/
+ return 0;
+
+ if (IS_GEN(gt->i915, 4))
+ /*
+* XXX CS_TIMESTAMP appears gibberish
+*
+* Ville's experiments indicate that it mostly appears 'stuck'
+* in that we see the register report the same cycle count
+* for a couple of reads.
+*/
+ return 0;
+
+ intel_gt_pm_get(gt);
+ intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_ALL);
+
+ for_each_engine(engine, gt, id) {
+ u32 cycles;
+ u32 expected;
+ u64 time;
+ u64 dt;
+
+ if (INTEL_GEN(engine->i915) < 7 && engine->id != RCS0)
+ continue;
+
+ measure_clocks(engine, , );
+
+ time = i915_cs_timestamp_ticks_to_ns(engine->i915, cycles);
+ expected = i915_cs_timestamp_ns_to_ticks(engine->i915, dt);
+
+ pr_info("%s: TIMESTAMP %d cycles [%lldns] in %lldns [%d
cycles], using CS clock frequency of %uKHz\n",
+ engine->name, cycles, time, dt, expected,
+ RUNTIME_INFO(engine->i915)->cs_timestamp_frequency_hz /
1000);
+
+ if (9 * time < 8 * dt || 8 * time > 9 * dt) {
+ pr_err("%s: CS ticks did not match walltime!\n",
+ engine->name);
+ err = -EINVAL;
+ break;
+ }
+
+ if (9 * expected < 8 * cycles || 8 * expected > 9 * cycles) {
+ pr_err("%s: walltime did not match CS ticks!\n",
+ engine->name);
+ err = -EINVAL;
+ break;
+ }
+ }
+
+ intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_ALL);
+ intel_gt_pm_put(gt);
+
+ return err;
+}
+
static int live_gt_resume(void *arg)
{
struct intel_gt *gt = arg;
@@ -52,6 +183,7 @@ static int live_gt_resume(void *arg)
int intel_gt_pm_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
+ SUBTEST(live_gt_clocks),
[Intel-gfx] ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK (rev18)
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev18)
URL : https://patchwork.freedesktop.org/series/74739/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17733_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17733_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17733_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_17733_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a2}:
- shard-glk: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a2.html
Known issues
Here are the changes found in Patchwork_17733_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-hostile@bcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#1622])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb3/igt@gem_ctx_persistence@engines-host...@bcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-iclb2/igt@gem_ctx_persistence@engines-host...@bcs0.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-apl7/igt@gem_soft...@noreloc-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-apl4/igt@gem_soft...@noreloc-s3.html
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_soft...@noreloc-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_soft...@noreloc-s3.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([i915#155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_selftest@live@execlists:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#1874])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl2/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl5/igt@i915_selftest@l...@execlists.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#1119] / [i915#118] /
[i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk6/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement:
- shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-snb1/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-render:
- shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-render.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17733/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-render.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#69])
[21]:
[Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC
This is a permanent w/a for JSL/EHL.This is to be applied to the
PCH types on JSL/EHL ie JSP/MCC
Bspec: 52888
v2: Fixed the wrong usage of logical OR(ville)
v3: Removed extra braces, changed the check(jose)
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4dc601dffc08..bc82d0d8ad5b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2902,8 +2902,10 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
GEN3_IRQ_RESET(uncore, SDE);
- /* Wa_14010685332:icl */
- if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP) {
+ /* Wa_14010685332:icl,jsl,ehl */
+ if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP ||
+ INTEL_PCH_TYPE(dev_priv) == PCH_JSP ||
+ INTEL_PCH_TYPE(dev_priv) == PCH_MCC) {
intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
SBCLK_RUN_REFCLK_DIS, SBCLK_RUN_REFCLK_DIS);
intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev10)
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev10)
URL : https://patchwork.freedesktop.org/series/73036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17732_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17732_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-hostile@vcs0:
- shard-iclb: [PASS][1] -> [FAIL][2] ([i915#1622])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb3/igt@gem_ctx_persistence@engines-host...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-iclb4/igt@gem_ctx_persistence@engines-host...@vcs0.html
* igt@gem_workarounds@suspend-resume:
- shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#69]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl8/igt@gem_workarou...@suspend-resume.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-skl4/igt@gem_workarou...@suspend-resume.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#155])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_suspend@sysfs-reader:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl6/igt@i915_susp...@sysfs-reader.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-kbl2/igt@i915_susp...@sysfs-reader.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#300])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-128x128-offscreen:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#54])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-128x128-offscreen.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-128x128-offscreen.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180] /
[i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-apl2/igt@kms_frontbuffer_track...@fbc-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-apl6/igt@kms_frontbuffer_track...@fbc-suspend.html
* igt@kms_psr@psr2_no_drrs:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-iclb6/igt@kms_psr@psr2_no_drrs.html
* igt@kms_setmode@basic:
- shard-kbl: [PASS][17] -> [FAIL][18] ([i915#31])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-kbl1/igt@kms_setm...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-kbl1/igt@kms_setm...@basic.html
Possible fixes
* igt@gem_ctx_persistence@engines-hostile@rcs0:
- shard-iclb: [FAIL][19] ([i915#1622]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-iclb3/igt@gem_ctx_persistence@engines-host...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-iclb4/igt@gem_ctx_persistence@engines-host...@rcs0.html
* igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
- shard-skl: [FAIL][21] ([i915#1528]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
* {igt@gem_exec_schedule@pi-distinct-iova@bcs0}:
- shard-glk: [FAIL][23] ([i915#859]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8511/shard-glk6/igt@gem_exec_schedule@pi-distinct-i...@bcs0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17732/shard-glk2/igt@gem_exec_schedule@pi-distinct-i...@bcs0.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][25] ([i915#454]) -> [PASS][26]
[25]:
