[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move tasklet kicking to __i915_request_queue caller
== Series Details == Series: drm/i915: Move tasklet kicking to __i915_request_queue caller URL : https://patchwork.freedesktop.org/series/65221/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14022 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/ Known issues Here are the changes found in Patchwork_14022 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@legacy-render: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html * igt@gem_exec_basic@basic-all: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u3/igt@gem_exec_ba...@basic-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-icl-u3/igt@gem_exec_ba...@basic-all.html * igt@i915_module_load@reload-with-fault-injection: - fi-hsw-4770r: [PASS][5] -> [DMESG-WARN][6] ([fdo#107732]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-hsw-4770r/igt@i915_module_l...@reload-with-fault-injection.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-hsw-4770r/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_selftest@live_reset: - fi-icl-u3: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u3/igt@i915_selftest@live_reset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-icl-u3/igt@i915_selftest@live_reset.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][9] -> [DMESG-WARN][10] ([fdo#102614]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: [PASS][11] -> [INCOMPLETE][12] ([fdo#107718]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Warnings * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [FAIL][13] ([fdo#110387]) -> [FAIL][14] ([fdo#110627]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387 [fdo#110627]: https://bugs.freedesktop.org/show_bug.cgi?id=110627 Participating hosts (53 -> 45) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6711 -> Patchwork_14022 CI-20190529: 20190529 CI_DRM_6711: 66992026e64fe4405ca25b1e978a98c7e132673b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14022: 36b4eba49a499e56473d846cccbad74dbfb31a24 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 36b4eba49a49 drm/i915: Move tasklet kicking to __i915_request_queue caller == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14022/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move tasklet kicking to __i915_request_queue caller
Since __i915_request_queue() may be called from hardirq (timer) context, we cannot use local_bh_disable/enable at the lower level. As we do want to kick the tasklet to speed up initial submission or preemption for normal client submission, lift it to the normal process context callpath. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 4021334dd2c5..8a2bc1d317e4 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1203,12 +1203,10 @@ void __i915_request_queue(struct i915_request *rq, * decide whether to preempt the entire chain so that it is ready to * run at the earliest possible convenience. */ - local_bh_disable(); i915_sw_fence_commit(>semaphore); if (attr && rq->engine->schedule) rq->engine->schedule(rq, attr); i915_sw_fence_commit(>submit); - local_bh_enable(); /* Kick the execlists tasklet if just scheduled */ } void i915_request_add(struct i915_request *rq) @@ -1247,7 +1245,9 @@ void i915_request_add(struct i915_request *rq) if (list_empty(>sched.signalers_list)) attr.priority |= I915_PRIORITY_WAIT; + local_bh_disable(); __i915_request_queue(rq, ); + local_bh_enable(); /* Kick the execlists tasklet if just scheduled */ /* * In typical scenarios, we do not expect the previous request on -- 2.23.0.rc1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/wopcm: Try to use already locked WOPCM layout
== Series Details == Series: series starting with [1/2] drm/i915/wopcm: Try to use already locked WOPCM layout URL : https://patchwork.freedesktop.org/series/65175/ State : success == Summary == CI Bug Log - changes from CI_DRM_6706_full -> Patchwork_14012_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14012_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-glk: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-glk8/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-glk3/igt@gem_...@reset-stress.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb5/igt@gem_exec_as...@concurrent-writes-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl8/igt@gem_soft...@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-skl5/igt@gem_soft...@noreloc-s3.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +9 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-apl7/igt@i915_susp...@sysfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-apl6/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-random: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-apl5/igt@kms_cursor_...@pipe-c-cursor-64x64-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-64x64-random.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_pipe_crc_basic@read-crc-pipe-a: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103191]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl5/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-skl6/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-y.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: [PASS][23] -> [INCOMPLETE][24] ([fdo#103665]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-kbl7/igt@kms_rotation_...@multiplane-rotation-cropping-top.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
== Series Details == Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock URL : https://patchwork.freedesktop.org/series/65169/ State : success == Summary == CI Bug Log - changes from CI_DRM_6706_full -> Patchwork_14011_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14011_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl9/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-skl8/igt@gem_...@reset-stress.html - shard-iclb: [PASS][3] -> [FAIL][4] ([fdo#109661]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb2/igt@gem_...@reset-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-iclb6/igt@gem_...@reset-stress.html * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb5/igt@gem_exec_sched...@pi-ringfull-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-iclb4/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-kbl4/igt@i915_pm_rc6_reside...@rc6-accuracy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-kbl1/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108] / [fdo#107807]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl4/igt@i915_pm_...@system-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-skl4/igt@i915_pm_...@system-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-apl: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-apl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-apl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-glk2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([fdo#103540]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-hsw2/igt@kms_f...@flip-vs-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-hsw5/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_pipe_crc_basic@read-crc-pipe-a: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#103191]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl5/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-skl4/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [fdo#110403]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][25] -> [FAIL][26] ([fdo#108145]) [25]:
Re: [Intel-gfx] [PATCH] dma-buf/sw_sync: Synchronize signal vs syncpt free
On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote:
Hi Sasha,
On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking around sync_timeline
lists.
The bot has tested the following trees: v5.2.8, v4.19.66, v4.14.138, v4.9.189.
v5.2.8: Build OK!
v4.19.66: Build OK!
v4.14.138: Build OK!
v4.9.189: Failed to apply! Possible dependencies:
Unable to calculate
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
The backporting instruction has an explicit # v4.14+ in there, so failure
to apply to older kernels is expected.
Can you perhaps teach this trick to your script perhaps? Iirc we're using
the official format even.
Hey Daniel,
The script knows how to read stable tags :)
It tested out 4.9 because the commit also has a fixes tag pointing to
d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline
lists."), which was backported to 4.9.
Should this not be backported to 4.9, even though the commit it fixes is
there?
--
Thanks,
Sasha
___
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 i915 ggtt WA since GT E0 (rev3)
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev3)
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14021
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/
Known issues
Here are the changes found in Patchwork_14021 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#110566])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_tiled_pread_basic:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-icl-u3/igt@gem_tiled_pread_basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/fi-icl-u3/igt@gem_tiled_pread_basic.html
Possible fixes
* igt@i915_selftest@live_mman:
- fi-bsw-n3050: [DMESG-WARN][7] ([fdo#111373]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-bsw-n3050/igt@i915_selftest@live_mman.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/fi-bsw-n3050/igt@i915_selftest@live_mman.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][9] ([fdo#109271] / [fdo#109278]) -> [PASS][10]
+2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
Participating hosts (53 -> 43)
--
Additional (1): fi-kbl-8809g
Missing(11): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-skl-guc
fi-byt-squawks fi-bsw-cyan fi-bxt-j4205 fi-icl-y fi-icl-guc fi-byt-clapper
fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6710 -> Patchwork_14021
CI-20190529: 20190529
CI_DRM_6710: 131c6ccdf21739498689f22c973b1b77660ae7b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14021: 11198b10be6d7f769e87efb1dc73cd63683bc9b5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
11198b10be6d drm/i915: Remove i915 ggtt WA since GT E0
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14021/
___
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/tgl: disable DDIC
== Series Details ==
Series: drm/i915/tgl: disable DDIC
URL : https://patchwork.freedesktop.org/series/65217/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14020
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/
Known issues
Here are the changes found in Patchwork_14020 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-icl-u3/igt@gem_ctx_cre...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/fi-icl-u3/igt@gem_ctx_cre...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][3] -> [DMESG-WARN][4] ([fdo#102614])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_selftest@live_mman:
- fi-bsw-n3050: [DMESG-WARN][5] ([fdo#111373]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-bsw-n3050/igt@i915_selftest@live_mman.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/fi-bsw-n3050/igt@i915_selftest@live_mman.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
Participating hosts (53 -> 44)
--
Additional (1): fi-kbl-8809g
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-icl-u2 fi-bsw-cyan fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6710 -> Patchwork_14020
CI-20190529: 20190529
CI_DRM_6710: 131c6ccdf21739498689f22c973b1b77660ae7b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14020: 335a81e24ca83f0c0270bb22889a2805b6e20f91 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
335a81e24ca8 drm/i915/tgl: disable DDIC
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/
___
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/tgl: Enabling DSC on Pipe A for TGL
== Series Details ==
Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL
URL : https://patchwork.freedesktop.org/series/65216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14019
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/
Known issues
Here are the changes found in Patchwork_14019 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@i915_selftest@live_mman:
- fi-bsw-n3050: [DMESG-WARN][3] ([fdo#111373]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-bsw-n3050/igt@i915_selftest@live_mman.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/fi-bsw-n3050/igt@i915_selftest@live_mman.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][5] ([fdo#109271] / [fdo#109278]) -> [PASS][6]
+2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
Participating hosts (53 -> 46)
--
Additional (1): fi-kbl-8809g
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6710 -> Patchwork_14019
CI-20190529: 20190529
CI_DRM_6710: 131c6ccdf21739498689f22c973b1b77660ae7b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14019: 92b16928782e1044339b264ad631dfea34712ec3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
92b16928782e drm/i915/tgl: Enabling DSC on Pipe A for TGL
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Remove i915 ggtt WA since GT E0
From: "Yang, Dong"
Broxton steppings starting from GT E0 have fixed the bug, remove
WA since stepping GT E0.
v2: use BXT_REVID_D_LAST replace BXT_REVID_D0, by:
Joonas Lahtinen
Signed-off-by: Yang, Dong
---
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5f3e5c13fbaa..b1cda9dcbea4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2141,6 +2141,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define BXT_REVID_B0 0x3
#define BXT_REVID_B_LAST 0x8
#define BXT_REVID_C0 0x9
+#define BXT_REVID_D_LAST 0xC
+#define BXT_REVID_E0 0xD
#define IS_BXT_REVID(dev_priv, since, until) \
(IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
@@ -2357,7 +2359,7 @@ static inline bool intel_scanout_needs_vtd_wa(struct
drm_i915_private *dev_priv)
static inline bool
intel_ggtt_update_needs_vtd_wa(struct drm_i915_private *dev_priv)
{
- return IS_BROXTON(dev_priv) && intel_vtd_active();
+ return IS_BXT_REVID(dev_priv, 0, BXT_REVID_D_LAST) &&
intel_vtd_active();
}
/* i915_drv.c */
--
2.22.0
___
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/tgl: disable DDIC
== Series Details == Series: drm/i915/tgl: disable DDIC URL : https://patchwork.freedesktop.org/series/65217/ State : warning == Summary == $ dim checkpatch origin/drm-tip 335a81e24ca8 drm/i915/tgl: disable DDIC -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: The current SKUs added for Tiger Lake don't have DDIC hooked up, even though it total: 0 errors, 1 warnings, 0 checks, 15 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 00/11] Add mmu_notifier_get/put for managing mmu notifier registrations
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This series introduces a new registration flow for mmu_notifiers based on the idea that the user would like to get a single refcounted piece of memory for a mm, keyed to its use. For instance many users of mmu_notifiers use an interval tree or similar to dispatch notifications to some object. There are many objects but only one notifier subscription per mm holding the tree. Of the 12 places that call mmu_notifier_register: - 7 are maintaining some kind of obvious mapping of mm_struct to mmu_notifier registration, ie in some linked list or hash table. Of the 7 this series converts 4 (gru, hmm, RDMA, radeon) - 3 (hfi1, gntdev, vhost) are registering multiple notifiers, but each one immediately does some VA range filtering, ie with an interval tree. These would be better with a global subsystem-wide range filter and could convert to this API. - 2 (kvm, amd_iommu) are deliberately using a single mm at a time, and really can't use this API. One of the intel-svm's modes is also in this list The 3/7 unconverted drivers are: - intel-svm This driver tracks mm's in a global linked list 'global_svm_list' and would benefit from this API. Its flow is a bit complex, since it also wants a set of non-shared notifiers. - i915_gem_usrptr This driver tracks mm's in a per-device hash table (dev_priv->mm_structs), but only has an optional use of mmu_notifiers. Since it still seems to need the hash table it is difficult to convert. - amdkfd/kfd_process This driver is using a global SRCU hash table to track mm's The control flow here is very complicated and the driver is relying on this hash table to be fast on the ioctl syscall path. It would definitely benefit, but only if the ioctl path didn't need to do the search so often. This series is already entangled with patches in the hmm & RDMA tree and will require some git topic branches for the RDMA ODP stuff. I intend for it to go through the hmm tree. There is a git version here: https://github.com/jgunthorpe/linux/commits/mmu_notifier Which has the required pre-patches for the RDMA ODP conversion that are still being reviewed. Jason Gunthorpe (11): mm/mmu_notifiers: hoist do_mmu_notifier_register down_write to the caller mm/mmu_notifiers: do not speculatively allocate a mmu_notifier_mm mm/mmu_notifiers: add a get/put scheme for the registration misc/sgi-gru: use mmu_notifier_get/put for struct gru_mm_struct hmm: use mmu_notifier_get/put for 'struct hmm' RDMA/odp: use mmu_notifier_get/put for 'struct ib_ucontext_per_mm' RDMA/odp: remove ib_ucontext from ib_umem drm/radeon: use mmu_notifier_get/put for struct radeon_mn drm/amdkfd: fix a use after free race with mmu_notifer unregister drm/amdkfd: use mmu_notifier_put mm/mmu_notifiers: remove unregister_no_release drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 3 - drivers/gpu/drm/amd/amdkfd/kfd_process.c | 88 - drivers/gpu/drm/nouveau/nouveau_drm.c| 3 + drivers/gpu/drm/radeon/radeon.h | 3 - drivers/gpu/drm/radeon/radeon_device.c | 2 - drivers/gpu/drm/radeon/radeon_drv.c | 2 + drivers/gpu/drm/radeon/radeon_mn.c | 157 drivers/infiniband/core/umem.c | 4 +- drivers/infiniband/core/umem_odp.c | 183 ++ drivers/infiniband/core/uverbs_cmd.c | 3 - drivers/infiniband/core/uverbs_main.c| 1 + drivers/infiniband/hw/mlx5/main.c| 5 - drivers/misc/sgi-gru/grufile.c | 1 + drivers/misc/sgi-gru/grutables.h | 2 - drivers/misc/sgi-gru/grutlbpurge.c | 84 +++-- include/linux/hmm.h | 12 +- include/linux/mm_types.h | 6 - include/linux/mmu_notifier.h | 40 +++- include/rdma/ib_umem.h | 2 +- include/rdma/ib_umem_odp.h | 10 +- include/rdma/ib_verbs.h | 3 - kernel/fork.c| 1 - mm/hmm.c | 121 +++- mm/mmu_notifier.c| 230 +-- 25 files changed, 408 insertions(+), 559 deletions(-) For the core MM, HMM, and nouveau changes you can add: Tested-by: Ralph Campbell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 05/11] hmm: use mmu_notifier_get/put for 'struct hmm'
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This is a significant simplification, it eliminates all the remaining 'hmm' stuff in mm_struct, eliminates krefing along the critical notifier paths, and takes away all the ugly locking and abuse of page_table_lock. mmu_notifier_get() provides the single struct hmm per struct mm which eliminates mm->hmm. It also directly guarantees that no mmu_notifier op callback is callable while concurrent free is possible, this eliminates all the krefs inside the mmu_notifier callbacks. The remaining krefs in the range code were overly cautious, drivers are already not permitted to free the mirror while a range exists. Signed-off-by: Jason Gunthorpe Looks good. Reviewed-by: Ralph Campbell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 11/11] mm/mmu_notifiers: remove unregister_no_release
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe mmu_notifier_unregister_no_release() and mmu_notifier_call_srcu() no longer have any users, they have all been converted to use mmu_notifier_put(). So delete this difficult to use interface. Signed-off-by: Jason Gunthorpe Reviewed-by: Ralph Campbell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
On 8/14/19 3:14 PM, Andrew Morton wrote:
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return value to handle some
corner cases. Until we realized that these are only for when a task
has been killed by the oom reaper.
An alternative approach would be to split the callback into two
versions, one with the int return value, and the other with void
return value like in older kernels. But that's a lot more churn for
fairly little gain I think.
Summary from the m-l discussion on why we want something at warning
level: This allows automated tooling in CI to catch bugs without
humans having to look at everything. If we just upgrade the existing
pr_info to a pr_warn, then we'll have false positives. And as-is, no
one will ever spot the problem since it's lost in the massive amounts
of overall dmesg noise.
...
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct
mmu_notifier_range *range)
pr_info("%pS callback failed with %d in %sblockable
context.\n",
mn->ops->invalidate_range_start, _ret,
!mmu_notifier_range_blockable(range) ? "non-" :
"");
+ WARN_ON(mmu_notifier_range_blockable(range) ||
+ ret != -EAGAIN);
ret = _ret;
}
}
A problem with WARN_ON(a || b) is that if it triggers, we don't know
whether it was because of a or because of b. Or both. So I'd suggest
WARN_ON(a);
WARN_ON(b);
This won't quite work. It is OK to have
mmu_notifier_range_blockable(range) be true or false.
sync_cpu_device_pagetables() shouldn't return
-EAGAIN unless blockable is true.
___
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/tgl: Enabling DSC on Pipe A for TGL
== Series Details == Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL URL : https://patchwork.freedesktop.org/series/65216/ State : warning == Summary == $ dim checkpatch origin/drm-tip 92b16928782e drm/i915/tgl: Enabling DSC on Pipe A for TGL -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: Removing restriction on Pipe A as TigerLake onwards, all the pipes support DSC. total: 0 errors, 1 warnings, 0 checks, 28 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: disable DDIC
The current SKUs added for Tiger Lake don't have DDIC hooked up, even though it
is supported by the SoC. The current state for these SKUs is problematic
since while enabling the combo phy, PORT_COMP_DW* return 0x,
which is invalid per register definition.
During initialization we check what phys are not yet enabled by reading
PHY_MISC_C and try to enable it by toggling the "DE to IO Comp Pwr Down"
bit. But after that any read to the PORT_COMP_DW* returns invalid
results. This removes the following warning
[56997.634353] Missing case (val == 4294967295)
[56997.639241] WARNING: CPU: 5 PID: 768 at
drivers/gpu/drm/i915/display/intel_combo_phy.c:54
cnl_get_procmon_ref_values+0xc9/0xf0 [i915]
[56997.639808] Modules linked in: i915(+) prime_numbers x86_pkg_temp_thermal
coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel e1000e [last unloaded: prime_numbers]
[56997.639808] CPU: 5 PID: 768 Comm: insmod Tainted: G U W
5.2.0-demarchi+ #65
[56997.639808] Hardware name: Intel Corporation Tiger Lake Client
Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2252.A03.1906270154
06/27/2019
[56997.639808] RIP: 0010:cnl_get_procmon_ref_values+0xc9/0xf0 [i915]
[56997.639808] Code: 2c a0 85 c9 74 e0 81 f9 00 00 00 01 75 09 48 c7 c0 0c a4
2c a0 eb cf 48 c7 c6 3c 3a 31 a0 48 c7 c7 40 3a 31 a0 e8 6b 4d ea e0 <0f> 0b 48
c7 c0 00 a4 2c a0 eb b1 48 c7 c0 24 a4 2
c a0 eb a8 e8 be
[56997.639808] RSP: 0018:c968f8a8 EFLAGS: 00010286
[56997.639808] RAX: RBX: 88848fa9 RCX:
[56997.639808] RDX: 8884a08b5ef8 RSI: 8884a08a6658 RDI:
[56997.639808] RBP: 0002 R08: R09:
[56997.639808] R10: R11: R12: 88848fa9
[56997.639808] R13: R14: 0002 R15: 0006c0162000
[56997.639808] FS: 7f61ca3d12c0() GS:8884a088()
knlGS:
[56997.639808] CS: 0010 DS: ES: CR0: 80050033
[56997.639808] CR2: 7f71be6a92c0 CR3: 000494750006 CR4: 00760ee0
[56997.639808] PKRU: 5554
[56997.639808] Call Trace:
[56997.639808] cnl_verify_procmon_ref_values+0x36/0xf0 [i915]
[56997.639808] ? rcu_read_lock_sched_held+0x6f/0x80
[56997.639808] ? gen11_fwtable_read32+0x257/0x290 [i915]
[56997.639808] icl_combo_phy_verify_state.part.0+0x22/0xa0 [i915]
[56997.639808] intel_combo_phy_init+0x17e/0x3e0 [i915]
[56997.639808] ? icl_display_core_init+0x2c/0x1a0 [i915]
[56997.639808] ? _raw_spin_unlock_irqrestore+0x4c/0x60
[56997.639808] icl_display_core_init+0x34/0x1a0 [i915]
[56997.639808] intel_power_domains_init_hw+0x200/0x570 [i915]
[56997.639808] i915_driver_probe+0x103b/0x17e0 [i915]
[56997.639808] ? printk+0x53/0x6a
[56997.639808] i915_pci_probe+0x3b/0x190 [i915]
We may or may not need to change the implementation to account for DDIC
being available on other SKUs. For now I think the best thing to do is
to just disable the port.
Cc: José Roberto de Souza
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5b733e38eae3..6c6a5a5f41bb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6683,7 +6683,7 @@ bool intel_phy_is_combo(struct drm_i915_private
*dev_priv, enum phy phy)
if (phy == PHY_NONE)
return false;
- if (IS_ELKHARTLAKE(dev_priv) || INTEL_GEN(dev_priv) >= 12)
+ if (IS_ELKHARTLAKE(dev_priv))
return phy <= PHY_C;
if (INTEL_GEN(dev_priv) >= 11)
@@ -15317,7 +15317,6 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
/* TODO: initialize TC ports as well */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_C);
icl_dsi_init(dev_priv);
} else if (IS_ELKHARTLAKE(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL
Removing restriction on Pipe A as TigerLake onwards, all the pipes support DSC.
Cc: Manasi Navare
Signed-off-by: Madhumitha Tolakanahalli Pradeep
---
drivers/gpu/drm/i915/display/intel_dp.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4884c87c8ed7..a5b50f93fac5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1739,8 +1739,12 @@ static bool intel_dp_source_supports_fec(struct intel_dp
*intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- return INTEL_GEN(dev_priv) >= 11 &&
- pipe_config->cpu_transcoder != TRANSCODER_A;
+ /* On TGL, DSC is supported on all Pipes */
+ if (INTEL_GEN(dev_priv) >= 12)
+ return true;
+ else
+ return INTEL_GEN(dev_priv) == 11 &&
+ pipe_config->cpu_transcoder != TRANSCODER_A;
}
static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
@@ -1755,8 +1759,12 @@ static bool intel_dp_source_supports_dsc(struct intel_dp
*intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- return INTEL_GEN(dev_priv) >= 10 &&
- pipe_config->cpu_transcoder != TRANSCODER_A;
+ /* On TGL, DSC is supported on all Pipes */
+ if (INTEL_GEN(dev_priv) >= 12)
+ return true;
+ else
+ return (INTEL_GEN(dev_priv) == 10 || INTEL_GEN(dev_priv) == 11)
&&
+ pipe_config->cpu_transcoder != TRANSCODER_A;
}
static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
--
2.17.1
___
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_userptr_blit: Shoot down a shared mmap_gtt(userptr)
Establish a userptr and inherit it to many children with fresh mm. Into
each child mm, mmap_gtt the userptr handle so that they are many
different vma in the i_mapping tree pointing back to the userptr. Then
proceed to munmap that and force us to revoke all the mmaps.
Daniel discovered that from the unmap in the parent, we will call
i915_vma_revoke_mmaps() on all the child mappings, which in turn should
call mmu_notifier_invalidate_range -- ostensibly recursing from the
outer mmu_notifier_invalidate_range of the munamp.
v2: Invoke userptr in each child for more mmu-notifiers
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
tests/i915/gem_userptr_blits.c | 86 ++
1 file changed, 86 insertions(+)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 5f7770c93..f08616146 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -1613,6 +1613,89 @@ static void test_unmap(int fd, int expected)
gem_close(fd, bo[i]);
}
+static int count_sigbus(void *ptr, size_t len)
+{
+ struct sigaction sigact, orig_sigact;
+
+ memset(, 0, sizeof(sigact));
+ sigact.sa_sigaction = sigbus;
+ sigact.sa_flags = SA_SIGINFO;
+ igt_assert(sigaction(SIGBUS, , _sigact) == 0);
+
+ sigbus_start = (unsigned long)ptr;
+ sigbus_cnt = 0;
+ memset(ptr, 0, len);
+
+ sigaction(SIGBUS, _sigact, NULL);
+ return sigbus_cnt;
+}
+
+static void test_unmap_shared(int i915)
+{
+ const int num_child = 64;
+ struct {
+ void *base;
+ uint32_t *gtt;
+ uint32_t bo;
+ } t[2];
+
+ igt_require(gem_has_llc(i915));
+
+ for (int i = 0; i < ARRAY_SIZE(t); i++) {
+ t[i].base = mmap(NULL, sizeof(linear), PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+ igt_assert(t[i].base != MAP_FAILED);
+ igt_require(__gem_userptr(i915, t[i].base, sizeof(linear),
+ 0, userptr_flags, [i].bo) == 0);
+
+ t[i].gtt = gem_mmap__gtt(i915, t[i].bo,
+sizeof(linear), PROT_WRITE);
+ *t[i].gtt = i;
+ }
+
+ igt_fork(child, num_child) {
+ uint32_t *ptr;
+
+ /* First attach our own user pointer to prep the mmu notifier */
+ ptr = mmap(NULL, sizeof(linear), PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+ igt_assert(ptr != MAP_FAILED);
+ igt_require(__gem_userptr(i915, ptr, sizeof(linear),
+ 0, userptr_flags, ptr) == 0);
+
+ ptr = gem_mmap__gtt(i915, t[0].bo, sizeof(linear), PROT_WRITE);
+ ptr[child] = 1;
+
+ ptr = gem_mmap__gtt(i915, t[1].bo, sizeof(linear), PROT_WRITE);
+ while (READ_ONCE(*ptr) == 1)
+ usleep(10 * 1000);
+
+ ptr = gem_mmap__gtt(i915, t[0].bo, sizeof(linear), PROT_WRITE);
+ igt_assert(count_sigbus(ptr, 1) > 0);
+ }
+
+ /* busy wait for all children to instantiate their mmap */
+ for (int child = 0; child < num_child; child++) {
+ while (READ_ONCE(t[0].gtt[child]) == 0)
+ ;
+ }
+
+ /* shoot it down! */
+ munmap(t[0].base, sizeof(linear));
+
+ /* check our aim was true */
+ igt_assert(count_sigbus(t[0].gtt, 1) > 0);
+
+ *t[1].gtt = 0;
+ igt_waitchildren();
+
+ for (int i = 0; i < ARRAY_SIZE(t); i++) {
+ gem_close(i915, t[i].bo);
+ munmap(t[i].gtt, sizeof(linear));
+ munmap(t[i].base, sizeof(linear));
+ }
+}
+
static void test_unmap_after_close(int fd)
{
char *ptr, *bo_ptr;
@@ -2006,6 +2089,9 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("sync-unmap-after-close")
test_unmap_after_close(fd);
+ igt_subtest("sync-unmap-shared")
+ test_unmap_shared(fd);
+
igt_subtest("stress-mm")
test_stress_mm(fd);
igt_subtest("stress-purge")
--
2.23.0.rc1
___
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_userptr_blit: Shoot down a shared mmap_gtt(userptr)
Establish a userptr and inherit it to many children with fresh mm. Into
each child mm, mmap_gtt the userptr handle so that they are many
different vma in the i_mapping tree pointing back to the userptr. Then
proceed to munmap that and force us to revoke all the mmaps.
Daniel discovered that from the unmap in the parent, we will call
i915_vma_revoke_mmaps() on all the child mappings, which in turn should
call mmu_notifier_invalidate_range -- ostensibly recursing from the
outer mmu_notifier_invalidate_range of the munamp.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
tests/i915/gem_userptr_blits.c | 79 ++
1 file changed, 79 insertions(+)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 5f7770c93..ee2bdc890 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -1613,6 +1613,82 @@ static void test_unmap(int fd, int expected)
gem_close(fd, bo[i]);
}
+static int count_sigbus(void *ptr, size_t len)
+{
+ struct sigaction sigact, orig_sigact;
+
+ memset(, 0, sizeof(sigact));
+ sigact.sa_sigaction = sigbus;
+ sigact.sa_flags = SA_SIGINFO;
+ igt_assert(sigaction(SIGBUS, , _sigact) == 0);
+
+ sigbus_start = (unsigned long)ptr;
+ sigbus_cnt = 0;
+ memset(ptr, 0, len);
+
+ sigaction(SIGBUS, _sigact, NULL);
+ return sigbus_cnt;
+}
+
+static void test_unmap_shared(int i915)
+{
+ const int num_child = 64;
+ struct {
+ void *base;
+ uint32_t *gtt;
+ uint32_t bo;
+ } t[2];
+
+ igt_require(gem_has_llc(i915));
+
+ for (int i = 0; i < ARRAY_SIZE(t); i++) {
+ t[i].base = mmap(NULL, sizeof(linear), PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+ igt_assert(t[i].base != MAP_FAILED);
+ igt_require(__gem_userptr(i915, t[i].base, sizeof(linear),
+ 0, userptr_flags, [i].bo) == 0);
+
+ t[i].gtt = gem_mmap__gtt(i915, t[i].bo,
+sizeof(linear), PROT_WRITE);
+ *t[i].gtt = i;
+ }
+
+ igt_fork(child, num_child) {
+ uint32_t *ptr;
+
+ ptr = gem_mmap__gtt(i915, t[0].bo, sizeof(linear), PROT_WRITE);
+ ptr[child] = 1;
+
+ ptr = gem_mmap__gtt(i915, t[1].bo, sizeof(linear), PROT_WRITE);
+ while (READ_ONCE(*ptr) == 1)
+ usleep(10 * 1000);
+
+ ptr = gem_mmap__gtt(i915, t[0].bo, sizeof(linear), PROT_WRITE);
+ igt_assert(count_sigbus(ptr, 1) > 0);
+ }
+
+ /* busy wait for all children to instantiate their mmap */
+ for (int child = 0; child < num_child; child++) {
+ while (READ_ONCE(t[0].gtt[child]) == 0)
+ ;
+ }
+
+ /* shoot it down! */
+ munmap(t[0].base, sizeof(linear));
+
+ /* check our aim was true */
+ igt_assert(count_sigbus(t[0].gtt, 1) > 0);
+
+ *t[1].gtt = 0;
+ igt_waitchildren();
+
+ for (int i = 0; i < ARRAY_SIZE(t); i++) {
+ gem_close(i915, t[i].bo);
+ munmap(t[i].gtt, sizeof(linear));
+ munmap(t[i].base, sizeof(linear));
+ }
+}
+
static void test_unmap_after_close(int fd)
{
char *ptr, *bo_ptr;
@@ -2006,6 +2082,9 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("sync-unmap-after-close")
test_unmap_after_close(fd);
+ igt_subtest("sync-unmap-shared")
+ test_unmap_shared(fd);
+
igt_subtest("stress-mm")
test_stress_mm(fd);
igt_subtest("stress-purge")
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu notifiers and
> whether we could use the newly-introduced return value to handle some
> corner cases. Until we realized that these are only for when a task
> has been killed by the oom reaper.
>
> An alternative approach would be to split the callback into two
> versions, one with the int return value, and the other with void
> return value like in older kernels. But that's a lot more churn for
> fairly little gain I think.
>
> Summary from the m-l discussion on why we want something at warning
> level: This allows automated tooling in CI to catch bugs without
> humans having to look at everything. If we just upgrade the existing
> pr_info to a pr_warn, then we'll have false positives. And as-is, no
> one will ever spot the problem since it's lost in the massive amounts
> of overall dmesg noise.
>
> ...
>
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct
> mmu_notifier_range *range)
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
> mn->ops->invalidate_range_start, _ret,
> !mmu_notifier_range_blockable(range) ?
> "non-" : "");
> + WARN_ON(mmu_notifier_range_blockable(range) ||
> + ret != -EAGAIN);
> ret = _ret;
> }
> }
A problem with WARN_ON(a || b) is that if it triggers, we don't know
whether it was because of a or because of b. Or both. So I'd suggest
WARN_ON(a);
WARN_ON(b);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Print CCID for all renderCS
On Wed, 2019-08-14 at 10:02 +0100, Chris Wilson wrote: > Quoting Chris Wilson (2019-08-13 18:55:46) > > Quoting Stuart Summers (2019-08-13 18:41:20) > > > Use render class instead of RCS0 when printing CCID. > > > > > > Signed-off-by: Stuart Summers > > > > One day, one day, this will be using some lists of registers. > > > > Reviewed-by: Chris Wilson > > Pushed this patch. The first patch speaks of the panic if legacy HW > does > change and we end up with the rcs context somewhere else. And the > third > patch, I wish to develop into something of wider user. Thanks Chris! -Stuart > -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 hmm & mmu_notifier debug/lockdep annotations
== Series Details ==
Series: hmm & mmu_notifier debug/lockdep annotations
URL : https://patchwork.freedesktop.org/series/65204/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14018
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/
Known issues
Here are the changes found in Patchwork_14018 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@create-fd-close:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-icl-u3/igt@gem_ba...@create-fd-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/fi-icl-u3/igt@gem_ba...@create-fd-close.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_requests:
- fi-byt-j1900: [PASS][5] -> [INCOMPLETE][6] ([fdo#102657])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-byt-j1900/igt@i915_selftest@live_requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/fi-byt-j1900/igt@i915_selftest@live_requests.html
* igt@kms_chamelium@dp-edid-read:
- fi-cml-u2: [PASS][7] -> [FAIL][8] ([fdo#109483])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
Possible fixes
* igt@i915_selftest@live_mman:
- fi-bsw-n3050: [DMESG-WARN][9] ([fdo#111373]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/fi-bsw-n3050/igt@i915_selftest@live_mman.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/fi-bsw-n3050/igt@i915_selftest@live_mman.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
Participating hosts (53 -> 46)
--
Additional (1): fi-kbl-8809g
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6710 -> Patchwork_14018
CI-20190529: 20190529
CI_DRM_6710: 131c6ccdf21739498689f22c973b1b77660ae7b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14018: f19fc63b377a4030737033645c64832074f49e2e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f19fc63b377a mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors
e45141adafb7 mm, notifier: Add a lockdep map for invalidate_range_start
dc71123d4109 mm, notifier: Catch sleeping/blocking for !blockable
39d0c9af3003 kernel.h: Add non_block_start/end()
5a4f96d9f7a6 mm: Check if mmu notifier callbacks are allowed to fail
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14018/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 03/11] mm/mmu_notifiers: add a get/put scheme for the registration
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Many places in the kernel have a flow where userspace will create some
object and that object will need to connect to the subsystem's
mmu_notifier subscription for the duration of its lifetime.
In this case the subsystem is usually tracking multiple mm_structs and it
is difficult to keep track of what struct mmu_notifier's have been
allocated for what mm's.
Since this has been open coded in a variety of exciting ways, provide core
functionality to do this safely.
This approach uses the strct mmu_notifier_ops * as a key to determine if
s/strct/struct
the subsystem has a notifier registered on the mm or not. If there is a
registration then the existing notifier struct is returned, otherwise the
ops->alloc_notifiers() is used to create a new per-subsystem notifier for
the mm.
The destroy side incorporates an async call_srcu based destruction which
will avoid bugs in the callers such as commit 6d7c3cde93c1 ("mm/hmm: fix
use after free with struct hmm in the mmu notifiers").
Since we are inside the mmu notifier core locking is fairly simple, the
allocation uses the same approach as for mmu_notifier_mm, the write side
of the mmap_sem makes everything deterministic and we only need to do
hlist_add_head_rcu() under the mm_take_all_locks(). The new users count
and the discoverability in the hlist is fully serialized by the
mmu_notifier_mm->lock.
Co-developed-by: Christoph Hellwig
Signed-off-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/mmu_notifier.h | 35
mm/mmu_notifier.c| 156 +--
2 files changed, 185 insertions(+), 6 deletions(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6ad9..31aa971315a142 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -211,6 +211,19 @@ struct mmu_notifier_ops {
*/
void (*invalidate_range)(struct mmu_notifier *mn, struct mm_struct *mm,
unsigned long start, unsigned long end);
+
+ /*
+* These callbacks are used with the get/put interface to manage the
+* lifetime of the mmu_notifier memory. alloc_notifier() returns a new
+* notifier for use with the mm.
+*
+* free_notifier() is only called after the mmu_notifier has been
+* fully put, calls to any ops callback are prevented and no ops
+* callbacks are currently running. It is called from a SRCU callback
+* and cannot sleep.
+*/
+ struct mmu_notifier *(*alloc_notifier)(struct mm_struct *mm);
+ void (*free_notifier)(struct mmu_notifier *mn);
};
/*
@@ -227,6 +240,9 @@ struct mmu_notifier_ops {
struct mmu_notifier {
struct hlist_node hlist;
const struct mmu_notifier_ops *ops;
+ struct mm_struct *mm;
+ struct rcu_head rcu;
+ unsigned int users;
};
static inline int mm_has_notifiers(struct mm_struct *mm)
@@ -234,6 +250,21 @@ static inline int mm_has_notifiers(struct mm_struct *mm)
return unlikely(mm->mmu_notifier_mm);
}
+struct mmu_notifier *mmu_notifier_get_locked(const struct mmu_notifier_ops *ops,
+struct mm_struct *mm);
+static inline struct mmu_notifier *
+mmu_notifier_get(const struct mmu_notifier_ops *ops, struct mm_struct *mm)
+{
+ struct mmu_notifier *ret;
+
+ down_write(>mmap_sem);
+ ret = mmu_notifier_get_locked(ops, mm);
+ up_write(>mmap_sem);
+ return ret;
+}
+void mmu_notifier_put(struct mmu_notifier *mn);
+void mmu_notifier_synchronize(void);
+
extern int mmu_notifier_register(struct mmu_notifier *mn,
struct mm_struct *mm);
extern int __mmu_notifier_register(struct mmu_notifier *mn,
@@ -581,6 +612,10 @@ static inline void mmu_notifier_mm_destroy(struct
mm_struct *mm)
#define pudp_huge_clear_flush_notify pudp_huge_clear_flush
#define set_pte_at_notify set_pte_at
+static inline void mmu_notifier_synchronize(void)
+{
+}
+
#endif /* CONFIG_MMU_NOTIFIER */
#endif /* _LINUX_MMU_NOTIFIER_H */
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 696810f632ade1..4a770b5211b71d 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -248,6 +248,9 @@ int __mmu_notifier_register(struct mmu_notifier *mn, struct
mm_struct *mm)
lockdep_assert_held_write(>mmap_sem);
BUG_ON(atomic_read(>mm_users) <= 0);
+ mn->mm = mm;
+ mn->users = 1;
+
if (!mm->mmu_notifier_mm) {
/*
* kmalloc cannot be called under mm_take_all_locks(), but we
@@ -295,18 +298,24 @@ int __mmu_notifier_register(struct mmu_notifier *mn,
struct mm_struct *mm)
}
EXPORT_SYMBOL_GPL(__mmu_notifier_register);
-/*
+/**
+ * mmu_notifier_register - Register a notifier on a mm
+ * @mn: The notifier to attach
+ *
Re: [Intel-gfx] [PATCH 1/2] drm/i915/wopcm: Try to use already locked WOPCM layout
On 8/14/19 1:49 PM, Michal Wajdeczko wrote:
On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio
wrote:
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bda24200498..e5bc7b8a433e 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -154,6 +154,21 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
return err;
}
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,
+ u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+ u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+ u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+ if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+ !(reg_base & GUC_WOPCM_OFFSET_VALID))
+ return false;
Should we at least WARN in the unlikely case where only one of the 2
regs is locked?
I wanted just to cover valid case where both regs are locked so
we can grab base/size as final.
If only single reg is locked, then we continue with our own partitioning
as before, and fail during reg verification in uc_init_wopcm() where
we already have WARNs
That works
+
+ *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+ *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+ return true;
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -167,8 +182,9 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
void intel_wopcm_init(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
- u32 guc_fw_size =
intel_uc_fw_get_upload_size(>gt.uc.guc.fw);
- u32 huc_fw_size =
intel_uc_fw_get_upload_size(>gt.uc.huc.fw);
+ struct intel_gt *gt = >gt;
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(>uc.guc.fw);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(>uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -185,6 +201,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
+ if (__wopcm_regs_locked(gt->uncore, _wopcm_base,
_wopcm_size)) {
+ DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+ "GuC WOPCM is already locked [%uK, %uK)\n",
+ guc_wopcm_base / SZ_1K,
+ guc_wopcm_size / SZ_1K);
+ goto check;
+ }
+
if (guc_fw_size >= wopcm->size) {
DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
guc_fw_size / 1024);
@@ -211,6 +235,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+check:
The checks here don't really verify that the sizes we're locked with
are enough to fit the binaries. We need to at least print an error in
that case so we can debug why GuC/HuC fails to load later if the
sizes are not ok.
I've added DRM_DEV_DEBUG_DRIVER("GuC WOPCM is already locked [%uK, %uK)\n"
but maybe we should promote it to dev_notice ? will that work for you ?
I'd prefer an error-level message if huc doesn't fit so it jumps out
that this is wrong and not just an informational message. The same as
what we do with guc size below.
Daniele
Here I meant to refer to HuC only, since guc size is verified below
(I'm too used to refer to them as a pair :P )
Daniele
Daniele
guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for hmm & mmu_notifier debug/lockdep annotations
== Series Details ==
Series: hmm & mmu_notifier debug/lockdep annotations
URL : https://patchwork.freedesktop.org/series/65204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a4f96d9f7a6 mm: Check if mmu notifier callbacks are allowed to fail
-:64: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 8 lines checked
39d0c9af3003 kernel.h: Add non_block_start/end()
-:78: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#78: FILE: include/linux/kernel.h:238:
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
-:80: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#80: FILE: include/linux/kernel.h:240:
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
-:127: WARNING:PREFER_PR_LEVEL: Prefer [subsystem eg:
netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(... to
printk(KERN_ERR ...
#127: FILE: kernel/sched/core.c:3712:
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
-:128: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#128: FILE: kernel/sched/core.c:3713:
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
+ prev->comm, prev->pid, prev->non_block_count);
-:165: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 4 warnings, 1 checks, 87 lines checked
dc71123d4109 mm, notifier: Catch sleeping/blocking for !blockable
-:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
e45141adafb7 mm, notifier: Add a lockdep map for invalidate_range_start
-:94: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 35 lines checked
f19fc63b377a mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors
-:41: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 9 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/9] drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index b1ca8e5bdb56d..9fcf2c58c29c5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2752,8 +2752,9 @@ intel_hdmi_connector_register(struct drm_connector
*connector)
static void intel_hdmi_destroy(struct drm_connector *connector)
{
- if (intel_attached_hdmi(connector)->cec_notifier)
- cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
+ struct cec_notifier *n = intel_attached_hdmi(connector)->cec_notifier;
+
+ cec_notifier_conn_unregister(n);
intel_connector_destroy(connector);
}
@@ -3068,6 +3069,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
enum port port = intel_encoder->port;
+ struct cec_connector_info conn_info;
DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
port_name(port));
@@ -3120,8 +3122,11 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
- intel_hdmi->cec_notifier = cec_notifier_get_conn(dev->dev,
-port_identifier(port));
+ cec_fill_conn_info_from_drm(_info, connector);
+
+ intel_hdmi->cec_notifier =
+ cec_notifier_conn_register(dev->dev, port_identifier(port),
+ _info);
if (!intel_hdmi->cec_notifier)
DRM_DEBUG_KMS("CEC notifier get failed\n");
}
--
2.23.0.rc1.153.gdeed80330f-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.
Pass the connector info to the CEC adapter. This makes it possible
to associate the CEC adapter with the corresponding drm connector.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_cec.c | 25 ---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
include/drm/drm_dp_helper.h | 17 ++---
5 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 16218a202b591..5ec14efd4d8cb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_aux_register(>dm_dp_aux.aux);
drm_dp_cec_register_connector(>dm_dp_aux.aux,
- aconnector->base.name, dm->adev->dev);
+ >base);
aconnector->mst_mgr.cbs = _mst_cbs;
drm_dp_mst_topology_mgr_init(
>mst_mgr,
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index b15cee85b702b..b457c16c3a8bb 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -8,7 +8,9 @@
#include
#include
#include
+#include
#include
+#include
#include
/*
@@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct work_struct
*work)
*/
void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
{
- u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
+ struct drm_connector *connector = aux->cec.connector;
+ u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
+ CEC_CAP_CONNECTOR_INFO;
+ struct cec_connector_info conn_info;
unsigned int num_las = 1;
u8 cap;
@@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
/* Create a new adapter */
aux->cec.adap = cec_allocate_adapter(_dp_cec_adap_ops,
-aux, aux->cec.name, cec_caps,
+aux, connector->name, cec_caps,
num_las);
if (IS_ERR(aux->cec.adap)) {
aux->cec.adap = NULL;
goto unlock;
}
- if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
+
+ cec_fill_conn_info_from_drm(_info, connector);
+ cec_s_conn_info(aux->cec.adap, _info);
+
+ if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
cec_delete_adapter(aux->cec.adap);
aux->cec.adap = NULL;
} else {
@@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
/**
* drm_dp_cec_register_connector() - register a new connector
* @aux: DisplayPort AUX channel
- * @name: name of the CEC device
- * @parent: parent device
+ * @connector: drm connector
*
* A new connector was registered with associated CEC adapter name and
* CEC adapter parent device. After registering the name and parent
* drm_dp_cec_set_edid() is called to check if the connector supports
* CEC and to register a CEC adapter if that is the case.
*/
-void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
- struct device *parent)
+void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
{
WARN_ON(aux->cec.adap);
if (WARN_ON(!aux->transfer))
return;
- aux->cec.name = name;
- aux->cec.parent = parent;
+ aux->cec.connector = connector;
INIT_DELAYED_WORK(>cec.unregister_work,
drm_dp_cec_unregister_work);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1092499115760..de2486fe7bf2d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5497,7 +5497,6 @@ static int
intel_dp_connector_register(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_device *dev = connector->dev;
int ret;
ret = intel_connector_register(connector);
@@ -5512,8 +5511,7 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.dev = connector->kdev;
ret = drm_dp_aux_register(_dp->aux);
if (!ret)
- drm_dp_cec_register_connector(_dp->aux,
- connector->name, dev->dev);
+ drm_dp_cec_register_connector(_dp->aux, connector);
Re: [Intel-gfx] [PATCH v3 hmm 04/11] misc/sgi-gru: use mmu_notifier_get/put for struct gru_mm_struct
On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote: > Looks good, > > Reviewed-by: Christoph Hellwig Dimitri, are you OK with this patch? Thanks, Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 04/11] misc/sgi-gru: use mmu_notifier_get/put for struct gru_mm_struct
On Wed, Aug 14, 2019 at 03:58:34PM +, Jason Gunthorpe wrote: > On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote: > > Looks good, > > > > Reviewed-by: Christoph Hellwig > > Dimitri, are you OK with this patch? > I think this looks OK. Reviewed-by: Dimitri Sivanich ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API
This series updates DRM drivers to use new CEC notifier API. Changes since v6: Made CEC notifiers' registration and de-registration symmetric in tda998x and dw-hdmi drivers. Also, accidentally dropped one patch in v6 (change to drm_dp_cec), brought it back now. Changes since v5: Fixed a warning about a missing comment for a new member of drm_dp_aux_cec struct. Sending to a wider audience, including maintainers of respective drivers. Changes since v4: Addressing review comments. Changes since v3: Updated adapter flags in dw-hdmi-cec. Changes since v2: Include all DRM patches from "cec: improve notifier support, add connector info connector info" series. Changes since v1: Those patches delay creation of notifiers until respective connectors are constructed. It seems that those patches, for a couple of drivers, by adding the delay, introduce a race between notifiers' creation and the IRQs handling threads - at least I don't see anything obvious in there that would explicitly forbid such races to occur. v2 adds a write barrier to make sure IRQ threads see the notifier once it is created (replacing the WRITE_ONCE I put in v1). The best thing to do here, I believe, would be not to have any synchronization and make sure that an IRQ only gets enabled after the notifier is created. Dariusz Marcinkiewicz (9): drm_dp_cec: add connector info support. drm/i915/intel_hdmi: use cec_notifier_conn_(un)register dw-hdmi-cec: use cec_notifier_cec_adap_(un)register tda9950: use cec_notifier_cec_adap_(un)register drm: tda998x: use cec_notifier_conn_(un)register drm: sti: use cec_notifier_conn_(un)register drm: tegra: use cec_notifier_conn_(un)register drm: dw-hdmi: use cec_notifier_conn_(un)register drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +-- drivers/gpu/drm/drm_dp_cec.c | 25 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++-- drivers/gpu/drm/i2c/tda9950.c | 12 ++--- drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++- drivers/gpu/drm/i915/display/intel_dp.c | 4 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 13 -- drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- drivers/gpu/drm/sti/sti_hdmi.c| 19 +--- drivers/gpu/drm/tegra/output.c| 28 --- include/drm/drm_dp_helper.h | 17 --- 13 files changed, 155 insertions(+), 94 deletions(-) -- 2.23.0.rc1.153.gdeed80330f-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 01/11] mm/mmu_notifiers: hoist do_mmu_notifier_register down_write to the caller
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This simplifies the code to not have so many one line functions and extra logic. __mmu_notifier_register() simply becomes the entry point to register the notifier, and the other one calls it under lock. Also add a lockdep_assert to check that the callers are holding the lock as expected. Suggested-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe Nice clean up. Reviewed-by: Ralph Campbell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 02/11] mm/mmu_notifiers: do not speculatively allocate a mmu_notifier_mm
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary")
made an attempt at doing this, but had to be reverted as calling
the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see
commit 35cfa2b0b491 ("mm/mmu_notifier: allocate mmu_notifier in advance").
However, we can avoid that problem by doing the allocation only under
the mmap_sem, which is already happening.
Since all writers to mm->mmu_notifier_mm hold the write side of the
mmap_sem reading it under that sem is deterministic and we can use that to
decide if the allocation path is required, without speculation.
The actual update to mmu_notifier_mm must still be done under the
mm_take_all_locks() to ensure read-side coherency.
Signed-off-by: Jason Gunthorpe
Looks good to me.
Reviewed-by: Ralph Campbell
___
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/wopcm: Try to use already locked WOPCM layout
On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio
wrote:
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bda24200498..e5bc7b8a433e 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -154,6 +154,21 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
return err;
}
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,
+u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+!(reg_base & GUC_WOPCM_OFFSET_VALID))
+return false;
Should we at least WARN in the unlikely case where only one of the 2
regs is locked?
I wanted just to cover valid case where both regs are locked so
we can grab base/size as final.
If only single reg is locked, then we continue with our own partitioning
as before, and fail during reg verification in uc_init_wopcm() where
we already have WARNs
+
+*guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+*guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+return true;
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -167,8 +182,9 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
void intel_wopcm_init(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
-u32 guc_fw_size =
intel_uc_fw_get_upload_size(>gt.uc.guc.fw);
-u32 huc_fw_size =
intel_uc_fw_get_upload_size(>gt.uc.huc.fw);
+struct intel_gt *gt = >gt;
+u32 guc_fw_size = intel_uc_fw_get_upload_size(>uc.guc.fw);
+u32 huc_fw_size = intel_uc_fw_get_upload_size(>uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -185,6 +201,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
+if (__wopcm_regs_locked(gt->uncore, _wopcm_base,
_wopcm_size)) {
+DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+ "GuC WOPCM is already locked [%uK, %uK)\n",
+ guc_wopcm_base / SZ_1K,
+ guc_wopcm_size / SZ_1K);
+goto check;
+}
+
if (guc_fw_size >= wopcm->size) {
DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
guc_fw_size / 1024);
@@ -211,6 +235,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+check:
The checks here don't really verify that the sizes we're locked with
are enough to fit the binaries. We need to at least print an error in
that case so we can debug why GuC/HuC fails to load later if the sizes
are not ok.
I've added DRM_DEV_DEBUG_DRIVER("GuC WOPCM is already locked [%uK, %uK)\n"
but maybe we should promote it to dev_notice ? will that work for you ?
Here I meant to refer to HuC only, since guc size is verified below (I'm
too used to refer to them as a pair :P )
Daniele
Daniele
guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. > > This will be used in the oom paths of mmu-notifiers, where blocking is > not allowed to make sure there's forward progress. Quoting Michal: > > "The notifier is called from quite a restricted context - oom_reaper - > which shouldn't depend on any locks or sleepable conditionals. The code > should be swift as well but we mostly do care about it to make a forward > progress. Checking for sleepable context is the best thing we could come > up with that would describe these demands at least partially." > > Peter also asked whether we want to catch spinlocks on top, but Michal > said those are less of a problem because spinlocks can't have an > indirect dependency upon the page allocator and hence close the loop > with the oom reaper. I continue to struggle with this. It introduces a new kernel state "running preemptibly but must not call schedule()". How does this make any sense? Perhaps a much, much more detailed description of the oom_reaper situation would help out. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress. Quoting Michal:
"The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially."
Peter also asked whether we want to catch spinlocks on top, but Michal
said those are less of a problem because spinlocks can't have an
indirect dependency upon the page allocator and hence close the loop
with the oom reaper.
Suggested by Michal Hocko.
v2:
- Improve commit message (Michal)
- Also check in schedule, not just might_sleep (Peter)
v3: It works better when I actually squash in the fixup I had lying
around :-/
Cc: Jason Gunthorpe
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Masahiro Yamada
Cc: Wei Wang
Cc: Andy Shevchenko
Cc: Thomas Gleixner
Cc: Jann Horn
Cc: Feng Tang
Cc: Kees Cook
Cc: Randy Dunlap
Cc: linux-ker...@vger.kernel.org
Acked-by: Christian König (v1)
Signed-off-by: Daniel Vetter
---
include/linux/kernel.h | 10 +-
include/linux/sched.h | 4
kernel/sched/core.c| 19 ++-
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4fa360a13c1e..915fd9888afb 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -217,7 +217,9 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
* might_sleep - annotation for functions that can sleep
*
* this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
*
* This is a useful debugging help to be able to catch problems early and not
* be bitten later when the calling function happens to sleep when it is not
@@ -233,6 +235,10 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define cant_sleep() \
do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
# define sched_annotate_sleep()(current->task_state_change = 0)
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
#else
static inline void ___might_sleep(const char *file, int line,
int preempt_offset) { }
@@ -241,6 +247,8 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define might_sleep() do { might_resched(); } while (0)
# define cant_sleep() do { } while (0)
# define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
#endif
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9f51932bd543..c5630f3dca1f 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -974,6 +974,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ int non_block_count;
+#endif
+
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2b037f195473..57245770d6cc 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3700,13 +3700,22 @@ static noinline void __schedule_bug(struct task_struct
*prev)
/*
* Various schedule()-time debugging checks and statistics:
*/
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ if (!preempt && prev->state && prev->non_block_count) {
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
+ prev->comm, prev->pid, prev->non_block_count);
+ dump_stack();
+ add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
+ }
+#endif
+
if
[Intel-gfx] [PATCH 0/5] hmm & mmu_notifier debug/lockdep annotations
Hi all (but I guess mostly Jason), Finally gotten around to rebasing the previous version, fixing the rebase fail in there, update the commit message a bit and give this a spin with some tests. Nicely caught a lockdep splat that we're now discussing in i915, and seems to not have misfired anywhere else (including a few oom). Review, comments and everything very much appreciated. Plus I'd really like to land this, there's more hmm_mirror users in-flight, and I've seen some that get things wrong which this patchset should catch. Thanks, Daniel Daniel Vetter (5): mm: Check if mmu notifier callbacks are allowed to fail kernel.h: Add non_block_start/end() mm, notifier: Catch sleeping/blocking for !blockable mm, notifier: Add a lockdep map for invalidate_range_start mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors include/linux/kernel.h | 10 +- include/linux/mmu_notifier.h | 6 ++ include/linux/sched.h| 4 kernel/sched/core.c | 19 ++- mm/hmm.c | 3 +++ mm/mmu_notifier.c| 17 - 6 files changed, 52 insertions(+), 7 deletions(-) -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job done.
Inspired by an i915 patch series which did exactly that, because the
rules haven't been entirely clear to us.
v2: Use the shiny new non_block_start/end annotations instead of
abusing preempt_disable/enable.
v3: Rebase on top of Glisse's arg rework.
v4: Rebase on top of more Glisse rework.
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Reviewed-by: Christian König
Reviewed-by: Jérôme Glisse
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 16f1cbc775d0..43a76d030164 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -174,7 +174,13 @@ int __mmu_notifier_invalidate_range_start(struct
mmu_notifier_range *range)
id = srcu_read_lock();
hlist_for_each_entry_rcu(mn, >mm->mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
- int _ret = mn->ops->invalidate_range_start(mn, range);
+ int _ret;
+
+ if (!mmu_notifier_range_blockable(range))
+ non_block_start();
+ _ret = mn->ops->invalidate_range_start(mn, range);
+ if (!mmu_notifier_range_blockable(range))
+ non_block_end();
if (_ret) {
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors
Similar to the warning in the mmu notifer, warning if an hmm mirror callback gets it's blocking vs. nonblocking handling wrong, or if it fails with anything else than -EAGAIN. Cc: Jason Gunthorpe Cc: Ralph Campbell Cc: John Hubbard Cc: Dan Williams Cc: Dan Carpenter Cc: Matthew Wilcox Cc: Arnd Bergmann Cc: Balbir Singh Cc: Ira Weiny Cc: Souptick Joarder Cc: Andrew Morton Cc: "Jérôme Glisse" Cc: linux...@kvack.org Signed-off-by: Daniel Vetter --- mm/hmm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/hmm.c b/mm/hmm.c index 16b6731a34db..52ac59384268 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -205,6 +205,9 @@ static int hmm_invalidate_range_start(struct mmu_notifier *mn, ret = -EAGAIN; break; } + WARN(ret, "%pS callback failed with %d in %sblockable context\n", +mirror->ops->sync_cpu_device_pagetables, ret, +update.blockable ? "" : "non-"); } up_read(>mirrors_sem); -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.
v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion
with this being a real mutex (Chris Wilson).
v3: Rebase on top of Glisse's arg rework.
Cc: Jason Gunthorpe
Cc: Chris Wilson
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Reviewed-by: Jérôme Glisse
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 6 ++
mm/mmu_notifier.c| 7 +++
2 files changed, 13 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6a..9dd38c32fc53 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -42,6 +42,10 @@ enum mmu_notifier_event {
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -310,10 +314,12 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void
mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
{
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
}
static inline int
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 43a76d030164..331e43ce6f3c 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -21,6 +21,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return value to handle some
corner cases. Until we realized that these are only for when a task
has been killed by the oom reaper.
An alternative approach would be to split the callback into two
versions, one with the int return value, and the other with void
return value like in older kernels. But that's a lot more churn for
fairly little gain I think.
Summary from the m-l discussion on why we want something at warning
level: This allows automated tooling in CI to catch bugs without
humans having to look at everything. If we just upgrade the existing
pr_info to a pr_warn, then we'll have false positives. And as-is, no
one will ever spot the problem since it's lost in the massive amounts
of overall dmesg noise.
v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
the problematic case (Michal Hocko).
v3: Rebase on top of Glisse's arg rework.
v4: More rebase on top of Glisse reworking everything.
v5: Fixup rebase damage and also catch failures != EAGAIN for
!blockable (Jason). Also go back to WARN_ON as requested by Jason, so
automatic checkers can easily catch bugs by setting panic_on_warn.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Paolo Bonzini
Cc: Jason Gunthorpe
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index b5670620aea0..16f1cbc775d0 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct
mmu_notifier_range *range)
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!mmu_notifier_range_blockable(range) ?
"non-" : "");
+ WARN_ON(mmu_notifier_range_blockable(range) ||
+ ret != -EAGAIN);
ret = _ret;
}
}
--
2.22.0
___
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/wopcm: Try to use already locked WOPCM layout
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bda24200498..e5bc7b8a433e 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -154,6 +154,21 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
return err;
}
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,
+ u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+ u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+ u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+ if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+ !(reg_base & GUC_WOPCM_OFFSET_VALID))
+ return false;
Should we at least WARN in the unlikely case where only one of the 2
regs is locked?
+
+ *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+ *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+ return true;
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -167,8 +182,9 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
void intel_wopcm_init(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
- u32 guc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.guc.fw);
- u32 huc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.huc.fw);
+ struct intel_gt *gt = >gt;
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(>uc.guc.fw);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(>uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -185,6 +201,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
+ if (__wopcm_regs_locked(gt->uncore, _wopcm_base,
_wopcm_size)) {
+ DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+ "GuC WOPCM is already locked [%uK, %uK)\n",
+ guc_wopcm_base / SZ_1K,
+ guc_wopcm_size / SZ_1K);
+ goto check;
+ }
+
if (guc_fw_size >= wopcm->size) {
DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
guc_fw_size / 1024);
@@ -211,6 +235,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+check:
The checks here don't really verify that the sizes we're locked with are
enough to fit the binaries. We need to at least print an error in that
case so we can debug why GuC/HuC fails to load later if the sizes are
not ok.
Here I meant to refer to HuC only, since guc size is verified below (I'm
too used to refer to them as a pair :P )
Daniele
Daniele
guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Restore seqlock around dma_resv updates
On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-08-14 19:24:01)
> > This reverts
> > 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> > dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> > 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
> > 5d344f58da76 ("dma-buf: nuke reservation_object seq number")
Oh I didn't realize they landed already.
> > The scenario that defeats simply grabbing a set of shared/exclusive
> > fences and using them blissfully under RCU is that any of those fences
> > may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
> > scenario, while keeping the rcu_read_lock we need to establish that no
> > fence was changed in the dma_resv after a read (or full) memory barrier.
So if I'm reading correctly what Chris is saying here I guess my half
comment in that other thread pointed at a real oversight. Since I still
haven't checked and it's too late for real review not more for now.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Chris Wilson
>
> I said I needed to go lie down, that proves it.
Yeah I guess we need to wait for Christian to wake up an have a working
brain.
-Daniel
>
> Cc: Christian König
>
> > Cc: Daniel Vetter
> > ---
> > drivers/dma-buf/dma-buf.c | 31 -
> > drivers/dma-buf/dma-resv.c| 109 -
> > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +-
> > drivers/gpu/drm/i915/gem/i915_gem_busy.c | 24 ++--
> > include/linux/dma-resv.h | 113 --
> > 5 files changed, 175 insertions(+), 109 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index b3400d6524ab..433d91d710e4 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -199,7 +199,7 @@ static __poll_t dma_buf_poll(struct file *file,
> > poll_table *poll)
> > struct dma_resv_list *fobj;
> > struct dma_fence *fence_excl;
> > __poll_t events;
> > - unsigned shared_count;
> > + unsigned shared_count, seq;
> >
> > dmabuf = file->private_data;
> > if (!dmabuf || !dmabuf->resv)
> > @@ -213,8 +213,21 @@ static __poll_t dma_buf_poll(struct file *file,
> > poll_table *poll)
> > if (!events)
> > return 0;
> >
> > +retry:
> > + seq = read_seqcount_begin(>seq);
> > rcu_read_lock();
> > - dma_resv_fences(resv, _excl, , _count);
> > +
> > + fobj = rcu_dereference(resv->fence);
> > + if (fobj)
> > + shared_count = fobj->shared_count;
> > + else
> > + shared_count = 0;
> > + fence_excl = rcu_dereference(resv->fence_excl);
> > + if (read_seqcount_retry(>seq, seq)) {
> > + rcu_read_unlock();
> > + goto retry;
> > + }
> > +
> > if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) {
> > struct dma_buf_poll_cb_t *dcb = >cb_excl;
> > __poll_t pevents = EPOLLIN;
> > @@ -1144,6 +1157,7 @@ static int dma_buf_debug_show(struct seq_file *s,
> > void *unused)
> > struct dma_resv *robj;
> > struct dma_resv_list *fobj;
> > struct dma_fence *fence;
> > + unsigned seq;
> > int count = 0, attach_count, shared_count, i;
> > size_t size = 0;
> >
> > @@ -1174,9 +1188,16 @@ static int dma_buf_debug_show(struct seq_file *s,
> > void *unused)
> > buf_obj->name ?: "");
> >
> > robj = buf_obj->resv;
> > - rcu_read_lock();
> > - dma_resv_fences(robj, , , _count);
> > - rcu_read_unlock();
> > + while (true) {
> > + seq = read_seqcount_begin(>seq);
> > + rcu_read_lock();
> > + fobj = rcu_dereference(robj->fence);
> > + shared_count = fobj ? fobj->shared_count : 0;
> > + fence = rcu_dereference(robj->fence_excl);
> > + if (!read_seqcount_retry(>seq, seq))
> > + break;
> > + rcu_read_unlock();
> > + }
> >
> > if (fence)
> > seq_printf(s, "\tExclusive fence: %s %s
> > %ssignalled\n",
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index f5142683c851..42a8f3f11681 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -49,6 +49,12 @@
> > DEFINE_WD_CLASS(reservation_ww_class);
> > EXPORT_SYMBOL(reservation_ww_class);
> >
> > +struct lock_class_key reservation_seqcount_class;
> > +EXPORT_SYMBOL(reservation_seqcount_class);
> > +
> > +const char reservation_seqcount_string[] = "reservation_seqcount";
> > +EXPORT_SYMBOL(reservation_seqcount_string);
> > +
> > /**
> > *
Re: [Intel-gfx] [PATCH 2/2] drm/i915/uc: Move FW size sanity check back to fetch
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
Signed-off-by: Michał Winiarski
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 +++
drivers/gpu/drm/i915/intel_wopcm.c | 14 ++
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d056e1f4bd6d..98cb0eff143f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -265,6 +265,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
size_t size;
int err;
+ GEM_BUG_ON(!i915->wopcm.size);
GEM_BUG_ON(!intel_uc_fw_supported(uc_fw));
err = i915_inject_load_error(i915, -ENXIO);
@@ -324,6 +325,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
goto fail;
}
+ /* Sanity check whether this fw is not larger than whole WOPCM memory */
+ size = sizeof(struct uc_css_header) + uc_fw->ucode_size;
We could add a __intel_uc_fw_get_upload_size() that skips the
is_available() check and use that here. With our without this:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
+ if (unlikely(size >= i915->wopcm.size)) {
+ dev_warn(dev, "%s firmware %s: invalid size: %zu > %zu\n",
+intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
+size, (size_t)i915->wopcm.size);
+ err = -E2BIG;
+ goto fail;
+ }
+
/* Get version numbers from the CSS header */
switch (uc_fw->type) {
case INTEL_UC_FW_TYPE_GUC:
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index e5bc7b8a433e..295978356eef 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -197,6 +197,8 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(!wopcm->size);
GEM_BUG_ON(wopcm->guc.base);
GEM_BUG_ON(wopcm->guc.size);
+ GEM_BUG_ON(guc_fw_size >= wopcm->size);
+ GEM_BUG_ON(huc_fw_size >= wopcm->size);
if (i915_inject_probe_failure(i915))
return;
@@ -209,18 +211,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
goto check;
}
- if (guc_fw_size >= wopcm->size) {
- DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
- guc_fw_size / 1024);
- return;
- }
-
- if (huc_fw_size >= wopcm->size) {
- DRM_ERROR("HuC FW (%uKiB) is too big to fit in WOPCM.",
- huc_fw_size / 1024);
- return;
- }
-
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
GUC_WOPCM_OFFSET_ALIGNMENT);
if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex (rev3)
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex (rev3)
URL : https://patchwork.freedesktop.org/series/65177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14017
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/
Known issues
Here are the changes found in Patchwork_14017 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][1] -> [FAIL][2] ([fdo#108511])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278])
+2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7567u: [FAIL][9] ([fdo#109485]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-guc}: [FAIL][11] ([fdo#103167]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (53 -> 45)
--
Additional (1): fi-kbl-guc
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6709 -> Patchwork_14017
CI-20190529: 20190529
CI_DRM_6709: 4c9976607118e10dfc9f9feb3b9be2b3579631c9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14017: 85d9fbe5cdd84f806610507651c7f27e133afc65 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
85d9fbe5cdd8 RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
68f7d12ba111 drm/i915: Comment userptr recursion on struct_mutex
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/
___
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/wopcm: Try to use already locked WOPCM layout
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bda24200498..e5bc7b8a433e 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -154,6 +154,21 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
return err;
}
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,
+ u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+ u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+ u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+ if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+ !(reg_base & GUC_WOPCM_OFFSET_VALID))
+ return false;
Should we at least WARN in the unlikely case where only one of the 2
regs is locked?
+
+ *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+ *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+ return true;
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -167,8 +182,9 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
void intel_wopcm_init(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
- u32 guc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.guc.fw);
- u32 huc_fw_size = intel_uc_fw_get_upload_size(>gt.uc.huc.fw);
+ struct intel_gt *gt = >gt;
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(>uc.guc.fw);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(>uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -185,6 +201,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
+ if (__wopcm_regs_locked(gt->uncore, _wopcm_base, _wopcm_size)) {
+ DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+"GuC WOPCM is already locked [%uK, %uK)\n",
+guc_wopcm_base / SZ_1K,
+guc_wopcm_size / SZ_1K);
+ goto check;
+ }
+
if (guc_fw_size >= wopcm->size) {
DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
guc_fw_size / 1024);
@@ -211,6 +235,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+check:
The checks here don't really verify that the sizes we're locked with are
enough to fit the binaries. We need to at least print an error in that
case so we can debug why GuC/HuC fails to load later if the sizes are
not ok.
Daniele
guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex (rev3)
== Series Details == Series: series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex (rev3) URL : https://patchwork.freedesktop.org/series/65177/ State : warning == Summary == $ dim checkpatch origin/drm-tip 68f7d12ba111 drm/i915: Comment userptr recursion on struct_mutex -:30: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 12 lines checked 85d9fbe5cdd8 RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head -:88: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #88: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:287: +* struct_mutex in the entire system. */ -:282: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 170 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlighting a bit more
the actual nature of the nesting that's going on. Essentially we have
two kinds of objects:
- objects without pages allocated, which cannot be on any lru and are
hence inaccessible to the shrinker.
- objects which have pages allocated, which are on an lru, and which
the shrinker can decide to throw out.
For the former type of object, memory allcoations while holding
obj->mm.lock are permissible. For the latter they are not. And
get/put_pages transitions between the two types of objects.
This is still not entirely fool-proof since the rules might chance.
But as long as we run such a code ever at runtime lockdep should be
able to observe the inconsistency and complain (like with any other
lockdep class that we've split up in multiple classes). But there are
a few clear benefits:
- We can drop the nesting flag parameter from
__i915_gem_object_put_pages, because that function by definition is
never going allocate memory, and calling it on an object which
doesn't have its pages allocated would be a bug.
- We strictly catch more bugs, since there's not only one place in the
entire tree which is annotated with the special class. All the
other places that had explicit lockdep nesting annotations we're now
going to leave up to lockdep again.
- Specifically this catches stuff like calling get_pages from
put_pages (which isn't really a good idea, if we can call put_pages
so could the shrinker). I've seen patches do exactly that.
Of course I fully expect CI will show me for the fool I am with this
one here :-)
v2: There can only be one (lockdep only has a cache for the first
subclass, not for deeper ones, and we don't want to make these locks
even slower). Still separate enums for better documentation.
Real fix: don forget about phys objs and pin_map(), and fix the
shrinker to have the right annotations ... silly me.
v3: Forgot usertptr too ...
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
8 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 3929c3a6b281..a1a835539e09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -191,7 +191,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
GEM_BUG_ON(!list_empty(>lut_list));
atomic_set(>mm.pages_pin_count, 0);
- __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ __i915_gem_object_put_pages(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
bitmap_free(obj->bit_17);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3714cf234d64..5ce511ca7fa8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -281,11 +281,21 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
+ /*
+* Only used by struct_mutex, when called "recursively" from
+* direct-reclaim-esque. Safe because there is only every one
+* struct_mutex in the entire system. */
+ I915_MM_SHRINKER = 1,
+ /*
+* Used for obj->mm.lock when allocating pages. Safe because the object
+* isn't yet on any LRU, and therefore the shrinker can't deadlock on
+* it. As soon as the object has pages, obj->mm.lock nests within
+* fs_reclaim.
+*/
+ I915_MM_GET_PAGES = 1,
};
-int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
- enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Restore seqlock around dma_resv updates
== Series Details == Series: dma-buf: Restore seqlock around dma_resv updates URL : https://patchwork.freedesktop.org/series/65196/ State : success == Summary == CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14016 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/ Known issues Here are the changes found in Patchwork_14016 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [PASS][3] -> [FAIL][4] ([fdo#108511]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#08]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_requests: - fi-byt-j1900: [PASS][7] -> [INCOMPLETE][8] ([fdo#102657]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-byt-j1900/igt@i915_selftest@live_requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-byt-j1900/igt@i915_selftest@live_requests.html * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html * igt@kms_chamelium@dp-edid-read: - fi-icl-u2: [PASS][11] -> [FAIL][12] ([fdo#106766]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html * igt@prime_vgem@basic-fence-wait-default: - fi-icl-u3: [PASS][13] -> [DMESG-WARN][14] ([fdo#107724]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-u3/igt@prime_v...@basic-fence-wait-default.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-icl-u3/igt@prime_v...@basic-fence-wait-default.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [INCOMPLETE][15] ([fdo#107718]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_sanitycheck: - fi-icl-u3: [DMESG-WARN][17] ([fdo#107724]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7567u: [FAIL][19] ([fdo#109485]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#106766]: https://bugs.freedesktop.org/show_bug.cgi?id=106766 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08 Participating hosts (53 -> 43) -- Additional (1): fi-kbl-guc Missing(11): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-skl-6260u fi-cfl-8109u fi-icl-y fi-bdw-samus fi-byt-clapper fi-skl-6700k2 Build changes - * CI: CI-20190529 -> None * Linux:
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Comment userptr recursion on struct_mutex
On Wed, Aug 14, 2019 at 02:49:32PM +0200, Daniel Vetter wrote:
> Discussed this a bit with Chris, I think a comment here is warranted
> that this will be bad once we have more than one i915 instance. And
> lockdep won't catch it.
>
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 74da35611d7c..70dc506a5426 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -135,6 +135,12 @@ userptr_mn_invalidate_range_start(struct mmu_notifier
> *_mn,
> switch (mutex_trylock_recursive(unlock)) {
> default:
> case MUTEX_TRYLOCK_FAILED:
> + /*
> + * NOTE: This only works because there's only
> + * ever one i915-style struct_mutex in the
> + * entire system. If we could have two i915
> + * instances, this would deadlock.
> + */
While fixing up annotations for the 2nd patch I though more about this,
and I'm not sold that "there's only one" makes sense. Scenario:
thread A:
get_pages
-> mutex_lock(obj->mm.lock)
-> fs_reclaim
-> mmu_notifier picks range of memory we're interested in
-> mutex_lock_killable(struct_mutex)
Why can this not deadlock against any other thread which does:
mutex_lock(struct_mutex)
-> get_pages
-> mutex_lock(obj->mm.lock)
They would both need to pick the same object, that's right now at a 0->1
transition for pages_pin_count. Plus a long list of other unhappy
circumstances ...
Note that this is different from the same annotation in shrinker_lock:
That one is only used if current_is_kswapd is, which guarantees we're not
holding a few unfortunate locks.
-Daniel
> if (mutex_lock_killable_nested(unlock,
> I915_MM_SHRINKER)) {
> i915_gem_object_put(obj);
> return -EINTR;
> --
> 2.22.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Restore seqlock around dma_resv updates
== Series Details ==
Series: dma-buf: Restore seqlock around dma_resv updates
URL : https://patchwork.freedesktop.org/series/65196/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cffdefd474fc dma-buf: Restore seqlock around dma_resv updates
-:7: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 67c97fb79a7f ("dma-buf: add
reservation_object_fences helper")'
#7:
67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit dd7a7d1ff2f1 ("drm/i915: use new
reservation_object_fences helper")'
#8:
dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0e1d8083bddb ("dma-buf: further
relax reservation_object_add_shared_fence")'
#9:
0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 5d344f58da76 ("dma-buf: nuke
reservation_object seq number")'
#10:
5d344f58da76 ("dma-buf: nuke reservation_object seq number")
-:31: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#31: FILE: drivers/dma-buf/dma-buf.c:202:
+ unsigned shared_count, seq;
-:62: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#62: FILE: drivers/dma-buf/dma-buf.c:1160:
+ unsigned seq;
-:97: WARNING:STATIC_CONST_CHAR_ARRAY: const array should probably be static
const
#97: FILE: drivers/dma-buf/dma-resv.c:55:
+const char reservation_seqcount_string[] = "reservation_seqcount";
-:154: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#154: FILE: drivers/dma-buf/dma-resv.c:315:
+ unsigned i;
-:165: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#165: FILE: drivers/dma-buf/dma-resv.c:324:
+ unsigned shared_count = src_list->shared_count;
-:230: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#230: FILE: drivers/dma-buf/dma-resv.c:414:
+ shared_count = i = 0;
-:269: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#269: FILE: drivers/dma-buf/dma-resv.c:504:
+ unsigned seq, shared_count;
-:315: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#315: FILE: drivers/dma-buf/dma-resv.c:603:
+ unsigned seq, shared_count;
total: 4 errors, 7 warnings, 1 checks, 513 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 ttm
== Series Details ==
Series: ttm
URL : https://patchwork.freedesktop.org/series/65194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14015
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/
Known issues
Here are the changes found in Patchwork_14015 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@basic-default:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-u3/igt@gem_ctx_pa...@basic-default.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/fi-icl-u3/igt@gem_ctx_pa...@basic-default.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [INCOMPLETE][3] ([fdo#107718]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7567u: [FAIL][7] ([fdo#109485]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-guc}: [FAIL][9] ([fdo#103167]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (53 -> 45)
--
Additional (1): fi-kbl-guc
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6709 -> Patchwork_14015
CI-20190529: 20190529
CI_DRM_6709: 4c9976607118e10dfc9f9feb3b9be2b3579631c9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14015: f98f53ff57bd557a3b78744a6728c983109c1125 @
git://anongit.freedesktop.org/gfx-ci/linux
== Kernel 32bit build ==
Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/build_32bit.log
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
AR drivers/gpu/drm/i915/built-in.a
CC [M] drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.o
In file included from ./include/linux/bitops.h:5:0,
from ./include/linux/kernel.h:12,
from ./include/linux/list.h:9,
from ./include/linux/wait.h:7,
from ./include/linux/wait_bit.h:8,
from ./include/linux/fs.h:6,
from drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.h:9,
from drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c:6:
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c: In function ‘i915_ttm_ppgtt_create’:
./include/linux/bits.h:9:22: error: large integer implicitly truncated to
unsigned type [-Werror=overflow]
#define BIT_ULL(nr) (ULL(1) << (nr))
^
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c:164:48: note: in expansion of macro
‘BIT_ULL’
err = ttm_bo_init_mm(>bdev, TTM_PL_TT, BIT_ULL(48));
^~~
cc1: all warnings being treated as errors
scripts/Makefile.build:280: recipe for target
'drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.o' failed
make[4]: *** [drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.o] Error 1
scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error
Re: [Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
Quoting Daniel Vetter (2019-08-14 19:49:41)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index d474c6ac4100..1ea3c3c96a5a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -157,7 +157,15 @@ struct drm_i915_gem_object {
> unsigned int pin_global;
>
> struct {
> - struct mutex lock; /* protects the pages and their use */
> + /*
> +* Protects the pages and their use.
"Their use" is still a misleading suggest of mine. This should be
"protects the pinning of pages". The couple of other things it is used
for are tied to the concept of the pages being pinned; further use should
be discouraged; direct use prohibited.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> >> What if someone is real fast (like really real fast) and recycles the
> >> exclusive fence so you read the same pointer twice, but everything else
> >> changed? reused fence pointer is a lot more likely than seqlock
> >> wrapping
> >> around.
> > It's an exclusive fence. If it is replaced, it must be later than all
> > the shared fences (and dependent on them directly or indirectly), and
> > so still a consistent snapshot.
> An extension of that argument says we don't even need to loop,
>
> *list = rcu_dereference(obj->fence);
> *shared_count = *list ? (*list)->shared_count : 0;
> smp_rmb();
> *excl = rcu_dereference(obj->fence_excl);
>
> Gives a consistent snapshot. It doesn't matter if the fence_excl is
> before or after the shared_list -- if it's after, it's a superset of all
> fences, if it's before, we have a correct list of shared fences the
> earlier fence_excl.
> >>> The problem is that the point of the loop is that we do need a check on
> >>> the fences after the full memory barrier.
> >>>
> >>> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
> >>>
> >>> We don't have a full memory barrier here, so this cannot be used safely
> >>> in light of fence reallocation.
> >> i.e. we need to restore the loops in the callers,
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> index a2aff1d8290e..f019062c8cd7 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> >> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
> >> * to report the overall busyness. This is what the wait-ioctl
> >> does.
> >> *
> >> */
> >> +retry:
> >> dma_resv_fences(obj->base.resv, , , _count);
> >>
> >> /* Translate the exclusive fence to the READ *and* WRITE engine */
> >> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
> >> *data,
> >> args->busy |= busy_check_reader(fence);
> >> }
> >>
> >> + smp_rmb();
> >> + if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
> >> + goto retry;
> >> +
> >>
> >> wrap that up as
> >>
> >> static inline bool
> >> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
> >> {
> >> smp_rmb();
> >> return excl != rcu_access_pointer(resv->fence_excl);
> >> }
> > I give up. It's not just the fence_excl that's an issue here.
> >
> > Any of the shared fences may be replaced after dma_resv_fences()
> > and so the original shared fence pointer may be reassigned (even under
> > RCU).
>
> Yeah, but this should be harmless. See fences are always replaced either
> when they are signaled anyway or by later fences from the same context.
>
> And existing fences shouldn't be re-used while under RCU, or is anybody
> still using SLAB_TYPESAFE_BY_RCU?
Yes. We go through enough fences that the freelist is a noticeable
improvement.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlighting a bit more
the actual nature of the nesting that's going on. Essentially we have
two kinds of objects:
- objects without pages allocated, which cannot be on any lru and are
hence inaccessible to the shrinker.
- objects which have pages allocated, which are on an lru, and which
the shrinker can decide to throw out.
For the former type of object, memory allcoations while holding
obj->mm.lock are permissible. For the latter they are not. And
get/put_pages transitions between the two types of objects.
This is still not entirely fool-proof since the rules might chance.
But as long as we run such a code ever at runtime lockdep should be
able to observe the inconsistency and complain (like with any other
lockdep class that we've split up in multiple classes). But there are
a few clear benefits:
- We can drop the nesting flag parameter from
__i915_gem_object_put_pages, because that function by definition is
never going allocate memory, and calling it on an object which
doesn't have its pages allocated would be a bug.
- We strictly catch more bugs, since there's not only one place in the
entire tree which is annotated with the special class. All the
other places that had explicit lockdep nesting annotations we're now
going to leave up to lockdep again.
- Specifically this catches stuff like calling get_pages from
put_pages (which isn't really a good idea, if we can call put_pages
so could the shrinker). I've seen patches do exactly that.
Of course I fully expect CI will show me for the fool I am with this
one here :-)
v2: There can only be one (lockdep only has a cache for the first
subclass, not for deeper ones, and we don't want to make these locks
even slower). Still separate enums for better documentation.
Real fix: don forget about phys objs and pin_map(), and fix the
shrinker to have the right annotations ... silly me.
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
8 files changed, 37 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 3929c3a6b281..a1a835539e09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -191,7 +191,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
GEM_BUG_ON(!list_empty(>lut_list));
atomic_set(>mm.pages_pin_count, 0);
- __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ __i915_gem_object_put_pages(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
bitmap_free(obj->bit_17);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3714cf234d64..5ce511ca7fa8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -281,11 +281,21 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
+ /*
+* Only used by struct_mutex, when called "recursively" from
+* direct-reclaim-esque. Safe because there is only every one
+* struct_mutex in the entire system. */
+ I915_MM_SHRINKER = 1,
+ /*
+* Used for obj->mm.lock when allocating pages. Safe because the object
+* isn't yet on any LRU, and therefore the shrinker can't deadlock on
+* it. As soon as the object has pages, obj->mm.lock nests within
+* fs_reclaim.
+*/
+ I915_MM_GET_PAGES = 1,
};
-int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
- enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove i915 ggtt WA since GT E0 (rev2)
== Series Details == Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev2) URL : https://patchwork.freedesktop.org/series/65160/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6701_full -> Patchwork_14009_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14009_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14009_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_14009_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@wide-blt: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-skl8/igt@gem_exec_sched...@wide-blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-skl3/igt@gem_exec_sched...@wide-blt.html Known issues Here are the changes found in Patchwork_14009_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +14 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-iclb6/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@kms_cursor_edge_walk@pipe-a-256x256-top-edge: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-apl4/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-apl7/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#103355]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([fdo#103540]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-hsw6/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-hsw7/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6701/shard-skl8/igt@kms_frontbuffer_track...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14009/shard-skl6/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]:
Re: [Intel-gfx] [PATCH] drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+
I was going to ask the status of this and then I looked and realized that I
never provided a commit message blrub. Oops. Here you go:
On Broadwell, the sampler was changed to not require extra padding for
simple (no arrays, mipmapping, or MSAA) 1D, 2D, and buffer surfaces.
Setting the GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC bit in HALF_SLICE_CHICKEN3
disables this and reverts the hardware to the HSW-era behaviour where the
sampler over-fetches near the edges of the surface. While the over-fetch
does not cause faults due to the scratch page, it still means that more
data than needed is getting pulled into the sampler cache. If the
over-fetch from the sampler on a BUFFER surface leaks over into an atomic
on the L3$, hangs can occur.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110228
On Thu, Aug 8, 2019 at 11:35 PM Jason Ekstrand wrote:
> Also, I think we can provide a better commit message. I'll type something
> in the morning when I can actually look stuff up and provide correct
> references.
>
> On August 8, 2019 12:33:15 Jason Ekstrand wrote:
>
>> Note: This doesn't actually fix 110998. I can still get a hard-hang with
>> a slightly different version of the reproducer example. However, it does
>> fix the original and I suspect it will fix the UE4 editor hang in 110228
>>
>> On Thu, Aug 8, 2019 at 12:30 PM Jason Ekstrand
>> wrote:
>>
>>> This is consistent with what the Windows driver does and what I've heard
>>> from HW people.
>>>
>>> Reviewed-by: Jason Ekstrand
>>>
>>> On Thu, Aug 8, 2019 at 11:36 AM Chris Wilson
>>> wrote:
>>>
This bit was fliped on for "syncing dependencies between camera and
graphics". BSpec has no recollection why, and it is causing
unrecoverable GPU hangs with Vulkan compute workloads.
From BSpec, setting bit5 to 0 enables relaxed padding requiremets for
buffers, 1D and 2D non-array, non-MSAA, non-mip-mapped linear surfaces;
and *must* be set to 0h on skl+ to ensure "Out of Bounds" case is
suppressed.
Reported-by: Jason Ekstrand
Suggested-by: Jason Ekstrand
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998
Fixes: 8424171e135c ("drm/i915/gen9: h/w w/a: syncing dependencies
between camera and graphics")
Signed-off-by: Chris Wilson
Cc: Jason Ekstrand
Cc: Mika Kuoppala
Cc: # v4.1+
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 704ace01e7f5..b95c1d59a347 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -297,11 +297,6 @@ static void gen9_ctx_workarounds_init(struct
intel_engine_cs *engine,
FLOW_CONTROL_ENABLE |
PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
- /* Syncing dependencies between camera and graphics:skl,bxt,kbl
*/
- if (!IS_COFFEELAKE(i915))
- WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
- GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
-
/* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl,glk,cfl */
/* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl,cfl */
WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
--
2.23.0.rc1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for ttm
== Series Details == Series: ttm URL : https://patchwork.freedesktop.org/series/65194/ State : warning == Summary == $ dim checkpatch origin/drm-tip f98f53ff57bd ttm -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #33: new file mode 100644 -:49: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 'drivers/gpu/drm/i915/ttm/i915_ttm_drv.c', please use '//' instead #49: FILE: drivers/gpu/drm/i915/ttm/i915_ttm_drv.c:1: +/* SPDX-License-Identifier: MIT */ -:49: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #49: FILE: drivers/gpu/drm/i915/ttm/i915_ttm_drv.c:1: +/* SPDX-License-Identifier: MIT */ -:77: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 'drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c', please use '//' instead #77: FILE: drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c:1: +/* SPDX-License-Identifier: MIT */ -:77: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #77: FILE: drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c:1: +/* SPDX-License-Identifier: MIT */ -:169: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #169: FILE: drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c:93: +static void ppgtt_io_mem_free(struct ttm_bo_device *bdev, + struct ttm_mem_reg *mem) -:278: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 6 warnings, 1 checks, 236 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Restore seqlock around dma_resv updates
Quoting Chris Wilson (2019-08-14 19:24:01)
> This reverts
> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
> 5d344f58da76 ("dma-buf: nuke reservation_object seq number")
>
> The scenario that defeats simply grabbing a set of shared/exclusive
> fences and using them blissfully under RCU is that any of those fences
> may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
> scenario, while keeping the rcu_read_lock we need to establish that no
> fence was changed in the dma_resv after a read (or full) memory barrier.
>
> Signed-off-by: Chris Wilson
> Cc: Chris Wilson
I said I needed to go lie down, that proves it.
Cc: Christian König
> Cc: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c | 31 -
> drivers/dma-buf/dma-resv.c| 109 -
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +-
> drivers/gpu/drm/i915/gem/i915_gem_busy.c | 24 ++--
> include/linux/dma-resv.h | 113 --
> 5 files changed, 175 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index b3400d6524ab..433d91d710e4 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -199,7 +199,7 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> struct dma_resv_list *fobj;
> struct dma_fence *fence_excl;
> __poll_t events;
> - unsigned shared_count;
> + unsigned shared_count, seq;
>
> dmabuf = file->private_data;
> if (!dmabuf || !dmabuf->resv)
> @@ -213,8 +213,21 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> if (!events)
> return 0;
>
> +retry:
> + seq = read_seqcount_begin(>seq);
> rcu_read_lock();
> - dma_resv_fences(resv, _excl, , _count);
> +
> + fobj = rcu_dereference(resv->fence);
> + if (fobj)
> + shared_count = fobj->shared_count;
> + else
> + shared_count = 0;
> + fence_excl = rcu_dereference(resv->fence_excl);
> + if (read_seqcount_retry(>seq, seq)) {
> + rcu_read_unlock();
> + goto retry;
> + }
> +
> if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) {
> struct dma_buf_poll_cb_t *dcb = >cb_excl;
> __poll_t pevents = EPOLLIN;
> @@ -1144,6 +1157,7 @@ static int dma_buf_debug_show(struct seq_file *s, void
> *unused)
> struct dma_resv *robj;
> struct dma_resv_list *fobj;
> struct dma_fence *fence;
> + unsigned seq;
> int count = 0, attach_count, shared_count, i;
> size_t size = 0;
>
> @@ -1174,9 +1188,16 @@ static int dma_buf_debug_show(struct seq_file *s, void
> *unused)
> buf_obj->name ?: "");
>
> robj = buf_obj->resv;
> - rcu_read_lock();
> - dma_resv_fences(robj, , , _count);
> - rcu_read_unlock();
> + while (true) {
> + seq = read_seqcount_begin(>seq);
> + rcu_read_lock();
> + fobj = rcu_dereference(robj->fence);
> + shared_count = fobj ? fobj->shared_count : 0;
> + fence = rcu_dereference(robj->fence_excl);
> + if (!read_seqcount_retry(>seq, seq))
> + break;
> + rcu_read_unlock();
> + }
>
> if (fence)
> seq_printf(s, "\tExclusive fence: %s %s
> %ssignalled\n",
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index f5142683c851..42a8f3f11681 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -49,6 +49,12 @@
> DEFINE_WD_CLASS(reservation_ww_class);
> EXPORT_SYMBOL(reservation_ww_class);
>
> +struct lock_class_key reservation_seqcount_class;
> +EXPORT_SYMBOL(reservation_seqcount_class);
> +
> +const char reservation_seqcount_string[] = "reservation_seqcount";
> +EXPORT_SYMBOL(reservation_seqcount_string);
> +
> /**
> * dma_resv_list_alloc - allocate fence list
> * @shared_max: number of fences we need space for
> @@ -96,6 +102,9 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> void dma_resv_init(struct dma_resv *obj)
> {
> ww_mutex_init(>lock, _ww_class);
> +
> + __seqcount_init(>seq, reservation_seqcount_string,
> + _seqcount_class);
> RCU_INIT_POINTER(obj->fence, NULL);
> RCU_INIT_POINTER(obj->fence_excl, NULL);
> }
> @@ -225,6 +234,9 @@ void dma_resv_add_shared_fence(struct dma_resv *obj,
> struct dma_fence *fence)
> fobj = dma_resv_get_list(obj);
>
[Intel-gfx] [PATCH] dma-buf: Restore seqlock around dma_resv updates
This reverts
67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
5d344f58da76 ("dma-buf: nuke reservation_object seq number")
The scenario that defeats simply grabbing a set of shared/exclusive
fences and using them blissfully under RCU is that any of those fences
may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
scenario, while keeping the rcu_read_lock we need to establish that no
fence was changed in the dma_resv after a read (or full) memory barrier.
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 31 -
drivers/dma-buf/dma-resv.c| 109 -
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +-
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 24 ++--
include/linux/dma-resv.h | 113 --
5 files changed, 175 insertions(+), 109 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index b3400d6524ab..433d91d710e4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -199,7 +199,7 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
struct dma_resv_list *fobj;
struct dma_fence *fence_excl;
__poll_t events;
- unsigned shared_count;
+ unsigned shared_count, seq;
dmabuf = file->private_data;
if (!dmabuf || !dmabuf->resv)
@@ -213,8 +213,21 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
if (!events)
return 0;
+retry:
+ seq = read_seqcount_begin(>seq);
rcu_read_lock();
- dma_resv_fences(resv, _excl, , _count);
+
+ fobj = rcu_dereference(resv->fence);
+ if (fobj)
+ shared_count = fobj->shared_count;
+ else
+ shared_count = 0;
+ fence_excl = rcu_dereference(resv->fence_excl);
+ if (read_seqcount_retry(>seq, seq)) {
+ rcu_read_unlock();
+ goto retry;
+ }
+
if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) {
struct dma_buf_poll_cb_t *dcb = >cb_excl;
__poll_t pevents = EPOLLIN;
@@ -1144,6 +1157,7 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
struct dma_resv *robj;
struct dma_resv_list *fobj;
struct dma_fence *fence;
+ unsigned seq;
int count = 0, attach_count, shared_count, i;
size_t size = 0;
@@ -1174,9 +1188,16 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
buf_obj->name ?: "");
robj = buf_obj->resv;
- rcu_read_lock();
- dma_resv_fences(robj, , , _count);
- rcu_read_unlock();
+ while (true) {
+ seq = read_seqcount_begin(>seq);
+ rcu_read_lock();
+ fobj = rcu_dereference(robj->fence);
+ shared_count = fobj ? fobj->shared_count : 0;
+ fence = rcu_dereference(robj->fence_excl);
+ if (!read_seqcount_retry(>seq, seq))
+ break;
+ rcu_read_unlock();
+ }
if (fence)
seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index f5142683c851..42a8f3f11681 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -49,6 +49,12 @@
DEFINE_WD_CLASS(reservation_ww_class);
EXPORT_SYMBOL(reservation_ww_class);
+struct lock_class_key reservation_seqcount_class;
+EXPORT_SYMBOL(reservation_seqcount_class);
+
+const char reservation_seqcount_string[] = "reservation_seqcount";
+EXPORT_SYMBOL(reservation_seqcount_string);
+
/**
* dma_resv_list_alloc - allocate fence list
* @shared_max: number of fences we need space for
@@ -96,6 +102,9 @@ static void dma_resv_list_free(struct dma_resv_list *list)
void dma_resv_init(struct dma_resv *obj)
{
ww_mutex_init(>lock, _ww_class);
+
+ __seqcount_init(>seq, reservation_seqcount_string,
+ _seqcount_class);
RCU_INIT_POINTER(obj->fence, NULL);
RCU_INIT_POINTER(obj->fence_excl, NULL);
}
@@ -225,6 +234,9 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct
dma_fence *fence)
fobj = dma_resv_get_list(obj);
count = fobj->shared_count;
+ preempt_disable();
+ write_seqcount_begin(>seq);
+
for (i = 0; i < count; ++i) {
old = rcu_dereference_protected(fobj->shared[i],
@@ -242,6 +254,9 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct
dma_fence *fence)
RCU_INIT_POINTER(fobj->shared[i], fence);
/*
Re: [Intel-gfx] [PATCH] ttm
Quoting Chris Wilson (2019-08-14 19:22:54) You saw nothing; wrong experimental branch. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] ttm
---
drivers/gpu/drm/i915/Makefile | 7 +
drivers/gpu/drm/i915/ttm/Makefile | 5 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.c | 4 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.h | 12 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c | 174 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.h | 22 +++
6 files changed, 224 insertions(+)
create mode 100644 drivers/gpu/drm/i915/ttm/Makefile
create mode 100644 drivers/gpu/drm/i915/ttm/i915_ttm_drv.c
create mode 100644 drivers/gpu/drm/i915/ttm/i915_ttm_drv.h
create mode 100644 drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c
create mode 100644 drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 64db6fe5672b..14936e70ee2b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -98,6 +98,12 @@ gt-y += \
gt/gen8_renderstate.o \
gt/gen9_renderstate.o
i915-y += $(gt-y)
+#
+# TTM (translation table managmeent) code
+obj-y += ttm/
+ttm-y += \
+ ttm/i915_ttm_drv.o \
+ ttm/i915_ttm_ppgtt.o
# GEM (Graphics Execution Management) code
obj-y += gem/
@@ -126,6 +132,7 @@ gem-y += \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
i915-y += \
+ $(ttm-y) \
$(gem-y) \
i915_active.o \
i915_buddy.o \
diff --git a/drivers/gpu/drm/i915/ttm/Makefile
b/drivers/gpu/drm/i915/ttm/Makefile
new file mode 100644
index ..7e73aa587967
--- /dev/null
+++ b/drivers/gpu/drm/i915/ttm/Makefile
@@ -0,0 +1,5 @@
+# For building individual subdir files on the command line
+subdir-ccflags-y += -I$(srctree)/$(src)/..
+
+# Extra header tests
+header-test-pattern-$(CONFIG_DRM_I915_WERROR) := *.h
diff --git a/drivers/gpu/drm/i915/ttm/i915_ttm_drv.c
b/drivers/gpu/drm/i915/ttm/i915_ttm_drv.c
new file mode 100644
index ..863fbdad12eb
--- /dev/null
+++ b/drivers/gpu/drm/i915/ttm/i915_ttm_drv.c
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
diff --git a/drivers/gpu/drm/i915/ttm/i915_ttm_drv.h
b/drivers/gpu/drm/i915/ttm/i915_ttm_drv.h
new file mode 100644
index ..a2ad743ccc12
--- /dev/null
+++ b/drivers/gpu/drm/i915/ttm/i915_ttm_drv.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef I915_TTM_DRV_H
+#define I915_TTM_DRV_H
+
+struct i915_ttm_drv {
+};
+
+#endif /* I915_TTM_DRV_H */
diff --git a/drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c
b/drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c
new file mode 100644
index ..21a5e5e1027e
--- /dev/null
+++ b/drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c
@@ -0,0 +1,174 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_ttm_ppgtt.h"
+
+static struct ttm_tt *ppgtt_tt_create(struct ttm_buffer_object *bo,
+ u32 page_flags)
+{
+ pr_err("%s\n", __func__);
+ return NULL;
+}
+
+static int ppgtt_tt_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static void ppgtt_tt_unpopulate(struct ttm_tt *ttm)
+{
+ pr_err("%s\n", __func__);
+}
+
+static int ppgtt_invalidate_caches(struct ttm_bo_device *bdev, u32 flags)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static int ppgtt_init_mem_type(struct ttm_bo_device *bdev, u32 type,
+ struct ttm_mem_type_manager *man)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static bool ppgtt_eviction_valuable(struct ttm_buffer_object *bo,
+ const struct ttm_place *place)
+{
+ pr_err("%s\n", __func__);
+ return false;
+}
+
+static void ppgtt_evict_flags(struct ttm_buffer_object *bo,
+ struct ttm_placement *placement)
+{
+ pr_err("%s\n", __func__);
+}
+
+static int ppgtt_move(struct ttm_buffer_object *bo, bool evict,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_mem_reg *new_mem)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static int ppgtt_verify_access(struct ttm_buffer_object *bo,
+ struct file *filp)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static void ppgtt_move_notify(struct ttm_buffer_object *bo,
+ bool evict,
+ struct ttm_mem_reg *new_mem)
+{
+ pr_err("%s\n", __func__);
+}
+
+static int ppgtt_fault_reserve_notify(struct ttm_buffer_object *bo)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static void ppgtt_swap_notify(struct ttm_buffer_object *bo)
+{
+ pr_err("%s\n", __func__);
+}
+
+static int ppgtt_io_mem_reserve(struct ttm_bo_device *bdev,
+ struct ttm_mem_reg *mem)
+{
+ pr_err("%s\n", __func__);
+ return 0;
+}
+
+static void ppgtt_io_mem_free(struct
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Am 14.08.19 um 19:48 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 18:38:20)
>> Quoting Chris Wilson (2019-08-14 18:22:53)
>>> Quoting Chris Wilson (2019-08-14 18:06:18)
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> + } while (rcu_access_pointer(obj->fence_excl) != *excl);
>> What if someone is real fast (like really real fast) and recycles the
>> exclusive fence so you read the same pointer twice, but everything else
>> changed? reused fence pointer is a lot more likely than seqlock wrapping
>> around.
> It's an exclusive fence. If it is replaced, it must be later than all
> the shared fences (and dependent on them directly or indirectly), and
> so still a consistent snapshot.
An extension of that argument says we don't even need to loop,
*list = rcu_dereference(obj->fence);
*shared_count = *list ? (*list)->shared_count : 0;
smp_rmb();
*excl = rcu_dereference(obj->fence_excl);
Gives a consistent snapshot. It doesn't matter if the fence_excl is
before or after the shared_list -- if it's after, it's a superset of all
fences, if it's before, we have a correct list of shared fences the
earlier fence_excl.
>>> The problem is that the point of the loop is that we do need a check on
>>> the fences after the full memory barrier.
>>>
>>> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
>>>
>>> We don't have a full memory barrier here, so this cannot be used safely
>>> in light of fence reallocation.
>> i.e. we need to restore the loops in the callers,
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> index a2aff1d8290e..f019062c8cd7 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
>> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>> * to report the overall busyness. This is what the wait-ioctl does.
>> *
>> */
>> +retry:
>> dma_resv_fences(obj->base.resv, , , _count);
>>
>> /* Translate the exclusive fence to the READ *and* WRITE engine */
>> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>> args->busy |= busy_check_reader(fence);
>> }
>>
>> + smp_rmb();
>> + if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
>> + goto retry;
>> +
>>
>> wrap that up as
>>
>> static inline bool
>> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
>> {
>> smp_rmb();
>> return excl != rcu_access_pointer(resv->fence_excl);
>> }
> I give up. It's not just the fence_excl that's an issue here.
>
> Any of the shared fences may be replaced after dma_resv_fences()
> and so the original shared fence pointer may be reassigned (even under
> RCU).
Yeah, but this should be harmless. See fences are always replaced either
when they are signaled anyway or by later fences from the same context.
And existing fences shouldn't be re-used while under RCU, or is anybody
still using SLAB_TYPESAFE_BY_RCU?
Christian.
> The only defense against that is the seqcount.
>
> I totally screwed that up.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
On Wed, Aug 14, 2019 at 06:20:28PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2019-08-14 18:06:26) > > On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote: > > > Quoting Daniel Vetter (2019-08-14 16:39:08) > [snip] > > > > > > > if (old) > > > > > > > - old->shared_count = 0; > > > > > > > - write_seqcount_end(>seq); > > > > > > > + smp_store_mb(old->shared_count, 0); > > > > > > > > So your comment and the kerneldoc don't match up. Quoting > > > > Documentation/memory-barriers.txt: > > > > > > > > This assigns the value to the variable and then inserts a full > > > > memory > > > > barrier after it. It isn't guaranteed to insert anything more > > > > than a > > > > compiler barrier in a UP compilation. > > > > > > > > So order is 1. store 2. fence, but your comment suggests you want it the > > > > other way round. > > > > > > What's more weird is that it is a fully serialising instruction that is > > > used to fence first as part of the update. If that's way PeterZ uses > > > it... > > > > I haven't looked at the implementations tbh, just going with the text. Or > > do you mean in the write_seqlock that we're replacing? > > Nah, I misremembered set_current_state(), all that implies is the fence > is before the following instructions. I have some recollection that it > can be used as a RELEASE operation (if only because it is a locked xchg). > If all else fails, make it an xchg_release(). Or normal assignment + > smp_wmb(). Yeah that one is called smp_store_release, not smp_store_mb. I think smp_store_release is the right one here. > > > It's an exclusive fence. If it is replaced, it must be later than all > > > the shared fences (and dependent on them directly or indirectly), and > > > so still a consistent snapshot. > > > > I'm not worried about the fence, that part is fine. But we're defacto > > using the fence as a fancy seqlock-of-sorts. And if the fence gets reused > > and the pointers match, then our seqlock-of-sorts breaks. But I haven't > > looked around whether there's more in the code that makes this an > > irrelevant issue. > > No, it should not break if we replace the fence with the same pointer. > If the fence pointer expires, reused and assigned back as the excl_fence > -- it is still the excl_fence and by the properties of that > excl_fence construction, it is later than the shared_fences. So I thought the rules are that if we have an exclusive fence and shared fences both present, then the shared fences are after the exclusive one. But if we race here, then I think we could accidentally sample shared fences from _before_ the exclusive fences. Rough timeline: exlusive fence 1 -> shared fence 2 -> exclusive fence, but reuses memory of fence 1 Then we sample fence 1, capture the shared fence 2, and notice that the exclusive fence pointer is the same (but not the fence on the timeline) and conclude that we got a consistent sample. But the only consistent sample with the new fence state would be only the exclusive fence. Reminds me I forgot to look for the usual kref_get_unless_zero trickery we also need to do here to make sure we have the right fence. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Chris Wilson (2019-08-14 18:38:20)
> Quoting Chris Wilson (2019-08-14 18:22:53)
> > Quoting Chris Wilson (2019-08-14 18:06:18)
> > > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > > >
> > > > > What if someone is real fast (like really real fast) and recycles the
> > > > > exclusive fence so you read the same pointer twice, but everything
> > > > > else
> > > > > changed? reused fence pointer is a lot more likely than seqlock
> > > > > wrapping
> > > > > around.
> > > >
> > > > It's an exclusive fence. If it is replaced, it must be later than all
> > > > the shared fences (and dependent on them directly or indirectly), and
> > > > so still a consistent snapshot.
> > >
> > > An extension of that argument says we don't even need to loop,
> > >
> > > *list = rcu_dereference(obj->fence);
> > > *shared_count = *list ? (*list)->shared_count : 0;
> > > smp_rmb();
> > > *excl = rcu_dereference(obj->fence_excl);
> > >
> > > Gives a consistent snapshot. It doesn't matter if the fence_excl is
> > > before or after the shared_list -- if it's after, it's a superset of all
> > > fences, if it's before, we have a correct list of shared fences the
> > > earlier fence_excl.
> >
> > The problem is that the point of the loop is that we do need a check on
> > the fences after the full memory barrier.
> >
> > Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
> >
> > We don't have a full memory barrier here, so this cannot be used safely
> > in light of fence reallocation.
>
> i.e. we need to restore the loops in the callers,
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> index a2aff1d8290e..f019062c8cd7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
> * to report the overall busyness. This is what the wait-ioctl does.
> *
> */
> +retry:
> dma_resv_fences(obj->base.resv, , , _count);
>
> /* Translate the exclusive fence to the READ *and* WRITE engine */
> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
> args->busy |= busy_check_reader(fence);
> }
>
> + smp_rmb();
> + if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
> + goto retry;
> +
>
> wrap that up as
>
> static inline bool
> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
> {
> smp_rmb();
> return excl != rcu_access_pointer(resv->fence_excl);
> }
I give up. It's not just the fence_excl that's an issue here.
Any of the shared fences may be replaced after dma_resv_fences()
and so the original shared fence pointer may be reassigned (even under
RCU). The only defense against that is the seqcount.
I totally screwed that up.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Chris Wilson (2019-08-14 18:22:53)
> Quoting Chris Wilson (2019-08-14 18:06:18)
> > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > >
> > > > What if someone is real fast (like really real fast) and recycles the
> > > > exclusive fence so you read the same pointer twice, but everything else
> > > > changed? reused fence pointer is a lot more likely than seqlock wrapping
> > > > around.
> > >
> > > It's an exclusive fence. If it is replaced, it must be later than all
> > > the shared fences (and dependent on them directly or indirectly), and
> > > so still a consistent snapshot.
> >
> > An extension of that argument says we don't even need to loop,
> >
> > *list = rcu_dereference(obj->fence);
> > *shared_count = *list ? (*list)->shared_count : 0;
> > smp_rmb();
> > *excl = rcu_dereference(obj->fence_excl);
> >
> > Gives a consistent snapshot. It doesn't matter if the fence_excl is
> > before or after the shared_list -- if it's after, it's a superset of all
> > fences, if it's before, we have a correct list of shared fences the
> > earlier fence_excl.
>
> The problem is that the point of the loop is that we do need a check on
> the fences after the full memory barrier.
>
> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe()
>
> We don't have a full memory barrier here, so this cannot be used safely
> in light of fence reallocation.
i.e. we need to restore the loops in the callers,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index a2aff1d8290e..f019062c8cd7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
* to report the overall busyness. This is what the wait-ioctl does.
*
*/
+retry:
dma_resv_fences(obj->base.resv, , , _count);
/* Translate the exclusive fence to the READ *and* WRITE engine */
@@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
args->busy |= busy_check_reader(fence);
}
+ smp_rmb();
+ if (excl != rcu_access_pointer(obj->base.resv->fence_excl))
+ goto retry;
+
wrap that up as
static inline bool
dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl)
{
smp_rmb();
return excl != rcu_access_pointer(resv->fence_excl);
}
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf/sw_sync: Synchronize signal vs syncpt free
Hi Sasha, On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking around sync_timeline > lists. > > The bot has tested the following trees: v5.2.8, v4.19.66, v4.14.138, v4.9.189. > > v5.2.8: Build OK! > v4.19.66: Build OK! > v4.14.138: Build OK! > v4.9.189: Failed to apply! Possible dependencies: > Unable to calculate > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? The backporting instruction has an explicit # v4.14+ in there, so failure to apply to older kernels is expected. Can you perhaps teach this trick to your script perhaps? Iirc we're using the official format even. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Chris Wilson (2019-08-14 18:06:18) > Quoting Chris Wilson (2019-08-14 17:42:48) > > Quoting Daniel Vetter (2019-08-14 16:39:08) > > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl); > > > > > > What if someone is real fast (like really real fast) and recycles the > > > exclusive fence so you read the same pointer twice, but everything else > > > changed? reused fence pointer is a lot more likely than seqlock wrapping > > > around. > > > > It's an exclusive fence. If it is replaced, it must be later than all > > the shared fences (and dependent on them directly or indirectly), and > > so still a consistent snapshot. > > An extension of that argument says we don't even need to loop, > > *list = rcu_dereference(obj->fence); > *shared_count = *list ? (*list)->shared_count : 0; > smp_rmb(); > *excl = rcu_dereference(obj->fence_excl); > > Gives a consistent snapshot. It doesn't matter if the fence_excl is > before or after the shared_list -- if it's after, it's a superset of all > fences, if it's before, we have a correct list of shared fences the > earlier fence_excl. The problem is that the point of the loop is that we do need a check on the fences after the full memory barrier. Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe() We don't have a full memory barrier here, so this cannot be used safely in light of fence reallocation. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Daniel Vetter (2019-08-14 18:06:26) > On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2019-08-14 16:39:08) [snip] > > > > > > if (old) > > > > > > - old->shared_count = 0; > > > > > > - write_seqcount_end(>seq); > > > > > > + smp_store_mb(old->shared_count, 0); > > > > > > So your comment and the kerneldoc don't match up. Quoting > > > Documentation/memory-barriers.txt: > > > > > > This assigns the value to the variable and then inserts a full memory > > > barrier after it. It isn't guaranteed to insert anything more than a > > > compiler barrier in a UP compilation. > > > > > > So order is 1. store 2. fence, but your comment suggests you want it the > > > other way round. > > > > What's more weird is that it is a fully serialising instruction that is > > used to fence first as part of the update. If that's way PeterZ uses > > it... > > I haven't looked at the implementations tbh, just going with the text. Or > do you mean in the write_seqlock that we're replacing? Nah, I misremembered set_current_state(), all that implies is the fence is before the following instructions. I have some recollection that it can be used as a RELEASE operation (if only because it is a locked xchg). If all else fails, make it an xchg_release(). Or normal assignment + smp_wmb(). > > It's an exclusive fence. If it is replaced, it must be later than all > > the shared fences (and dependent on them directly or indirectly), and > > so still a consistent snapshot. > > I'm not worried about the fence, that part is fine. But we're defacto > using the fence as a fancy seqlock-of-sorts. And if the fence gets reused > and the pointers match, then our seqlock-of-sorts breaks. But I haven't > looked around whether there's more in the code that makes this an > irrelevant issue. No, it should not break if we replace the fence with the same pointer. If the fence pointer expires, reused and assigned back as the excl_fence -- it is still the excl_fence and by the properties of that excl_fence construction, it is later than the shared_fences. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked
On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> Now that dma_fence_signal always takes the spinlock to flush the
> cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> avoid code repetition.
>
> Suggested-by: Christian König
> Signed-off-by: Chris Wilson
> Cc: Christian König
Hm, I think this largely defeats the point of having the lockless signal
enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
but feels like a thing that needs a notch more thought. And if we need it,
maybe a bit more cleanup.
I guess with the addition of more fancy atomic BITs we could avoid this
too ... but no idea whether that's worth the effort.
-Daniel
> ---
> drivers/dma-buf/dma-fence.c | 32
> 1 file changed, 12 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index ab4a456bba04..367b71084d34 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -122,26 +122,18 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
> */
> int dma_fence_signal_locked(struct dma_fence *fence)
> {
> - int ret = 0;
> -
> - lockdep_assert_held(fence->lock);
> -
> if (WARN_ON(!fence))
> return -EINVAL;
>
> - if (!__dma_fence_signal(fence)) {
> - ret = -EINVAL;
> + lockdep_assert_held(fence->lock);
>
> - /*
> - * we might have raced with the unlocked dma_fence_signal,
> - * still run through all callbacks
> - */
> - } else {
> - __dma_fence_signal__timestamp(fence, ktime_get());
> - }
> + if (!__dma_fence_signal(fence))
> + return -EINVAL;
>
> + __dma_fence_signal__timestamp(fence, ktime_get());
> __dma_fence_signal__notify(fence);
> - return ret;
> +
> + return 0;
> }
> EXPORT_SYMBOL(dma_fence_signal_locked);
>
> @@ -161,19 +153,19 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
> int dma_fence_signal(struct dma_fence *fence)
> {
> unsigned long flags;
> + int ret;
>
> if (!fence)
> return -EINVAL;
>
> - if (!__dma_fence_signal(fence))
> - return -EINVAL;
> -
> - __dma_fence_signal__timestamp(fence, ktime_get());
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> + return 0;
>
> spin_lock_irqsave(fence->lock, flags);
> - __dma_fence_signal__notify(fence);
> + ret = dma_fence_signal_locked(fence);
> spin_unlock_irqrestore(fence->lock, flags);
> - return 0;
> +
> + return ret;
> }
> EXPORT_SYMBOL(dma_fence_signal);
>
> --
> 2.23.0.rc1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patch "drm/i915: Fix wrong escape clock divisor init for GLK" has been added to the 5.2-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 5.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-wrong-escape-clock-divisor-init-for-glk.patch
and it can be found in the queue-5.2 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee Mon Sep 17 00:00:00 2001
From: Stanislav Lisovskiy
Date: Fri, 12 Jul 2019 11:19:38 +0300
Subject: drm/i915: Fix wrong escape clock divisor init for GLK
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Vandita Kulkarni
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M
Cc: Madhav Chauhan
Cc: Jani Nikula
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovs...@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/vlv_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/vlv_dsi_pll.c
@@ -394,8 +394,8 @@ static void glk_dsi_program_esc_clock(st
else
txesc2_div = 10;
- I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
- I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, (1 << (txesc1_div - 1)) &
GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, (1 << (txesc2_div - 1)) &
GLK_TX_ESC_CLK_DIV2_MASK);
}
/* Program BXT Mipi clocks and dividers */
Patches currently in stable-queue which might be from
stanislav.lisovs...@intel.com are
queue-5.2/drm-i915-fix-wrong-escape-clock-divisor-init-for-glk.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Add high-precision time to vblank trace event
On Fri, Aug 09, 2019 at 05:36:39PM +0200, Heinrich wrote:
> Store the timestamp of the current vblank in the new field 'time' of the
> vblank trace event. If the timestamp is calculated by a driver that
> supports high-precision vblank timing, set the field 'high-prec' to
> 'true'.
>
> User space can now access actual hardware vblank times via the tracing
> infrastructure. Tracing applications (such as GPUVis, see [0] for
> related discussion), can use the newly added information to conduct a
> more accurate analysis of display timing.
>
> [0] https://github.com/mikesart/gpuvis/issues/30
>
> Signed-off-by: Heinrich
lgtm, and I think rather useful.
Reviewed-by: Daniel Vetter
I think we should let this hang out on the m-l for 2 weeks or so in case
of comments and what not. Please ping me again (since most likely I'll
forget).
Also adding Keith, he's been playing around a lot lately with vblank
timestamps and stuff, might be interested in this too.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_trace.h | 14 ++
> drivers/gpu/drm/drm_vblank.c | 3 ++-
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
> index baccc63db106..45f21d7fcfa1 100644
> --- a/drivers/gpu/drm/drm_trace.h
> +++ b/drivers/gpu/drm/drm_trace.h
> @@ -11,17 +11,23 @@
> #define TRACE_INCLUDE_FILE drm_trace
>
> TRACE_EVENT(drm_vblank_event,
> - TP_PROTO(int crtc, unsigned int seq),
> - TP_ARGS(crtc, seq),
> + TP_PROTO(int crtc, unsigned int seq, ktime_t time, bool high_prec),
> + TP_ARGS(crtc, seq, time, high_prec),
> TP_STRUCT__entry(
> __field(int, crtc)
> __field(unsigned int, seq)
> + __field(ktime_t, time)
> + __field(bool, high_prec)
> ),
> TP_fast_assign(
> __entry->crtc = crtc;
> __entry->seq = seq;
> - ),
> - TP_printk("crtc=%d, seq=%u", __entry->crtc, __entry->seq)
> + __entry->time = time;
> + __entry->high_prec = high_prec;
> + ),
> + TP_printk("crtc=%d, seq=%u, time=%lld, high-prec=%s",
> + __entry->crtc, __entry->seq, __entry->time,
> + __entry->high_prec ? "true" : "false")
> );
>
> TRACE_EVENT(drm_vblank_event_queued,
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index a1b65d26d761..fb089a88b516 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1706,7 +1706,8 @@ static void drm_handle_vblank_events(struct drm_device
> *dev, unsigned int pipe)
> send_vblank_event(dev, e, seq, now);
> }
>
> - trace_drm_vblank_event(pipe, seq);
> + trace_drm_vblank_event(pipe, seq, now,
> + dev->driver->get_vblank_timestamp != NULL);
> }
>
> /**
> --
> 2.23.0.rc1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4.14 55/69] drm/i915: Fix wrong escape clock divisor init for GLK
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Vandita Kulkarni
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M
Cc: Madhav Chauhan
Cc: Jani Nikula
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovs...@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/intel_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -422,8 +422,8 @@ static void glk_dsi_program_esc_clock(st
else
txesc2_div = 10;
- I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
- I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, (1 << (txesc1_div - 1)) &
GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, (1 << (txesc2_div - 1)) &
GLK_TX_ESC_CLK_DIV2_MASK);
}
/* Program BXT Mipi clocks and dividers */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4.19 76/91] drm/i915: Fix wrong escape clock divisor init for GLK
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Vandita Kulkarni
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M
Cc: Madhav Chauhan
Cc: Jani Nikula
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovs...@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/vlv_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/vlv_dsi_pll.c
@@ -413,8 +413,8 @@ static void glk_dsi_program_esc_clock(st
else
txesc2_div = 10;
- I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
- I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, (1 << (txesc1_div - 1)) &
GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, (1 << (txesc2_div - 1)) &
GLK_TX_ESC_CLK_DIV2_MASK);
}
/* Program BXT Mipi clocks and dividers */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Chris Wilson (2019-08-14 17:42:48) > Quoting Daniel Vetter (2019-08-14 16:39:08) > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl); > > > > What if someone is real fast (like really real fast) and recycles the > > exclusive fence so you read the same pointer twice, but everything else > > changed? reused fence pointer is a lot more likely than seqlock wrapping > > around. > > It's an exclusive fence. If it is replaced, it must be later than all > the shared fences (and dependent on them directly or indirectly), and > so still a consistent snapshot. An extension of that argument says we don't even need to loop, *list = rcu_dereference(obj->fence); *shared_count = *list ? (*list)->shared_count : 0; smp_rmb(); *excl = rcu_dereference(obj->fence_excl); Gives a consistent snapshot. It doesn't matter if the fence_excl is before or after the shared_list -- if it's after, it's a superset of all fences, if it's before, we have a correct list of shared fences the earlier fence_excl. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5.2 125/144] drm/i915: Fix wrong escape clock divisor init for GLK
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Vandita Kulkarni
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M
Cc: Madhav Chauhan
Cc: Jani Nikula
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovs...@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/vlv_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/vlv_dsi_pll.c
@@ -394,8 +394,8 @@ static void glk_dsi_program_esc_clock(st
else
txesc2_div = 10;
- I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
- I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, (1 << (txesc1_div - 1)) &
GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, (1 << (txesc2_div - 1)) &
GLK_TX_ESC_CLK_DIV2_MASK);
}
/* Program BXT Mipi clocks and dividers */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > Sorry I burried myself in some other stuff ...
> >
> > On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > > Quoting Christian König (2019-08-07 14:53:12)
> > > > > The only remaining use for this is to protect against setting a new
> > > > > exclusive
> > > > > fence while we grab both exclusive and shared. That can also be
> > > > > archived by
> > > > > looking if the exclusive fence has changed or not after completing the
> > > > > operation.
> > > > >
> > > > > v2: switch setting excl fence to rcu_assign_pointer
> > > > >
> > > > > Signed-off-by: Christian König
> > > > > ---
> > > > > drivers/dma-buf/reservation.c | 24 +---
> > > > > include/linux/reservation.h | 9 ++---
> > > > > 2 files changed, 7 insertions(+), 26 deletions(-)
> > > > >
> > > > > diff --git a/drivers/dma-buf/reservation.c
> > > > > b/drivers/dma-buf/reservation.c
> > > > > index 90bc6ef03598..f7f4a0858c2a 100644
> > > > > --- a/drivers/dma-buf/reservation.c
> > > > > +++ b/drivers/dma-buf/reservation.c
> > > > > @@ -49,12 +49,6 @@
> > > > > DEFINE_WD_CLASS(reservation_ww_class);
> > > > > EXPORT_SYMBOL(reservation_ww_class);
> > > > > -struct lock_class_key reservation_seqcount_class;
> > > > > -EXPORT_SYMBOL(reservation_seqcount_class);
> > > > > -
> > > > > -const char reservation_seqcount_string[] = "reservation_seqcount";
> > > > > -EXPORT_SYMBOL(reservation_seqcount_string);
> > > > > -
> > > > > /**
> > > > >* reservation_object_list_alloc - allocate fence list
> > > > >* @shared_max: number of fences we need space for
> > > > > @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct
> > > > > reservation_object_list *list)
> > > > > void reservation_object_init(struct reservation_object *obj)
> > > > > {
> > > > > ww_mutex_init(>lock, _ww_class);
> > > > > -
> > > > > - __seqcount_init(>seq, reservation_seqcount_string,
> > > > > - _seqcount_class);
> > > > > RCU_INIT_POINTER(obj->fence, NULL);
> > > > > RCU_INIT_POINTER(obj->fence_excl, NULL);
> > > > > }
> > > > > @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct
> > > > > reservation_object *obj,
> > > > > dma_fence_get(fence);
> > > > > preempt_disable();
> > > > > - write_seqcount_begin(>seq);
> > > > > - /* write_seqcount_begin provides the necessary memory barrier
> > > > > */
> > > > > - RCU_INIT_POINTER(obj->fence_excl, fence);
> > > > > + rcu_assign_pointer(obj->fence_excl, fence);
> > > > > + /* pointer update must be visible before we modify the
> > > > > shared_count */
> >
> > Pls add a "see reservation_object_fence()" here or similar.
> >
> > > > > if (old)
> > > > > - old->shared_count = 0;
> > > > > - write_seqcount_end(>seq);
> > > > > + smp_store_mb(old->shared_count, 0);
> >
> > So your comment and the kerneldoc don't match up. Quoting
> > Documentation/memory-barriers.txt:
> >
> > This assigns the value to the variable and then inserts a full memory
> > barrier after it. It isn't guaranteed to insert anything more than a
> > compiler barrier in a UP compilation.
> >
> > So order is 1. store 2. fence, but your comment suggests you want it the
> > other way round.
>
> What's more weird is that it is a fully serialising instruction that is
> used to fence first as part of the update. If that's way PeterZ uses
> it...
I haven't looked at the implementations tbh, just going with the text. Or
do you mean in the write_seqlock that we're replacing?
>
> > > > > preempt_enable();
> > > > > /* inplace update, no shared fences */
> > > > > @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct
> > > > > reservation_object *dst,
> > > > > old = reservation_object_get_excl(dst);
> > > > > preempt_disable();
> > > > > - write_seqcount_begin(>seq);
> > > > > - /* write_seqcount_begin provides the necessary memory barrier
> > > > > */
> > > > > - RCU_INIT_POINTER(dst->fence_excl, new);
> > > > > - RCU_INIT_POINTER(dst->fence, dst_list);
> > > > > - write_seqcount_end(>seq);
> > > > > + rcu_assign_pointer(dst->fence_excl, new);
> > > > > + rcu_assign_pointer(dst->fence, dst_list);
> > > > > preempt_enable();
> > > > > reservation_object_list_free(src_list);
> > > > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > > > index 044a5cd4af50..fd29baad0be3 100644
> > > > > --- a/include/linux/reservation.h
> > > > > +++ b/include/linux/reservation.h
> > > > > @@ -46,8 +46,6 @@
> > > > > #include
> > > > > extern struct ww_class reservation_ww_class;
> > > > > -extern struct lock_class_key
[Intel-gfx] Patch "drm/i915: Fix wrong escape clock divisor init for GLK" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-wrong-escape-clock-divisor-init-for-glk.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee Mon Sep 17 00:00:00 2001
From: Stanislav Lisovskiy
Date: Fri, 12 Jul 2019 11:19:38 +0300
Subject: drm/i915: Fix wrong escape clock divisor init for GLK
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Vandita Kulkarni
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M
Cc: Madhav Chauhan
Cc: Jani Nikula
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovs...@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/vlv_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/vlv_dsi_pll.c
@@ -413,8 +413,8 @@ static void glk_dsi_program_esc_clock(st
else
txesc2_div = 10;
- I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
- I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, (1 << (txesc1_div - 1)) &
GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, (1 << (txesc2_div - 1)) &
GLK_TX_ESC_CLK_DIV2_MASK);
}
/* Program BXT Mipi clocks and dividers */
Patches currently in stable-queue which might be from
stanislav.lisovs...@intel.com are
queue-4.19/drm-i915-fix-wrong-escape-clock-divisor-init-for-glk.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Daniel Vetter (2019-08-14 16:39:08)
> Sorry I burried myself in some other stuff ...
>
> On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > Quoting Christian König (2019-08-07 14:53:12)
> > > > The only remaining use for this is to protect against setting a new
> > > > exclusive
> > > > fence while we grab both exclusive and shared. That can also be
> > > > archived by
> > > > looking if the exclusive fence has changed or not after completing the
> > > > operation.
> > > >
> > > > v2: switch setting excl fence to rcu_assign_pointer
> > > >
> > > > Signed-off-by: Christian König
> > > > ---
> > > > drivers/dma-buf/reservation.c | 24 +---
> > > > include/linux/reservation.h | 9 ++---
> > > > 2 files changed, 7 insertions(+), 26 deletions(-)
> > > >
> > > > diff --git a/drivers/dma-buf/reservation.c
> > > > b/drivers/dma-buf/reservation.c
> > > > index 90bc6ef03598..f7f4a0858c2a 100644
> > > > --- a/drivers/dma-buf/reservation.c
> > > > +++ b/drivers/dma-buf/reservation.c
> > > > @@ -49,12 +49,6 @@
> > > > DEFINE_WD_CLASS(reservation_ww_class);
> > > > EXPORT_SYMBOL(reservation_ww_class);
> > > > -struct lock_class_key reservation_seqcount_class;
> > > > -EXPORT_SYMBOL(reservation_seqcount_class);
> > > > -
> > > > -const char reservation_seqcount_string[] = "reservation_seqcount";
> > > > -EXPORT_SYMBOL(reservation_seqcount_string);
> > > > -
> > > > /**
> > > >* reservation_object_list_alloc - allocate fence list
> > > >* @shared_max: number of fences we need space for
> > > > @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct
> > > > reservation_object_list *list)
> > > > void reservation_object_init(struct reservation_object *obj)
> > > > {
> > > > ww_mutex_init(>lock, _ww_class);
> > > > -
> > > > - __seqcount_init(>seq, reservation_seqcount_string,
> > > > - _seqcount_class);
> > > > RCU_INIT_POINTER(obj->fence, NULL);
> > > > RCU_INIT_POINTER(obj->fence_excl, NULL);
> > > > }
> > > > @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct
> > > > reservation_object *obj,
> > > > dma_fence_get(fence);
> > > > preempt_disable();
> > > > - write_seqcount_begin(>seq);
> > > > - /* write_seqcount_begin provides the necessary memory barrier */
> > > > - RCU_INIT_POINTER(obj->fence_excl, fence);
> > > > + rcu_assign_pointer(obj->fence_excl, fence);
> > > > + /* pointer update must be visible before we modify the
> > > > shared_count */
>
> Pls add a "see reservation_object_fence()" here or similar.
>
> > > > if (old)
> > > > - old->shared_count = 0;
> > > > - write_seqcount_end(>seq);
> > > > + smp_store_mb(old->shared_count, 0);
>
> So your comment and the kerneldoc don't match up. Quoting
> Documentation/memory-barriers.txt:
>
> This assigns the value to the variable and then inserts a full memory
> barrier after it. It isn't guaranteed to insert anything more than a
> compiler barrier in a UP compilation.
>
> So order is 1. store 2. fence, but your comment suggests you want it the
> other way round.
What's more weird is that it is a fully serialising instruction that is
used to fence first as part of the update. If that's way PeterZ uses
it...
> > > > preempt_enable();
> > > > /* inplace update, no shared fences */
> > > > @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct
> > > > reservation_object *dst,
> > > > old = reservation_object_get_excl(dst);
> > > > preempt_disable();
> > > > - write_seqcount_begin(>seq);
> > > > - /* write_seqcount_begin provides the necessary memory barrier */
> > > > - RCU_INIT_POINTER(dst->fence_excl, new);
> > > > - RCU_INIT_POINTER(dst->fence, dst_list);
> > > > - write_seqcount_end(>seq);
> > > > + rcu_assign_pointer(dst->fence_excl, new);
> > > > + rcu_assign_pointer(dst->fence, dst_list);
> > > > preempt_enable();
> > > > reservation_object_list_free(src_list);
> > > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > > index 044a5cd4af50..fd29baad0be3 100644
> > > > --- a/include/linux/reservation.h
> > > > +++ b/include/linux/reservation.h
> > > > @@ -46,8 +46,6 @@
> > > > #include
> > > > extern struct ww_class reservation_ww_class;
> > > > -extern struct lock_class_key reservation_seqcount_class;
> > > > -extern const char reservation_seqcount_string[];
> > > > /**
> > > >* struct reservation_object_list - a list of shared fences
> > > > @@ -71,7 +69,6 @@ struct reservation_object_list {
> > > >*/
> > > > struct reservation_object {
> > > > struct ww_mutex lock;
> > > > - seqcount_t seq;
> > > > struct dma_fence __rcu *fence_excl;
> > > > struct
[Intel-gfx] Patch "drm/i915: Fix wrong escape clock divisor init for GLK" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-wrong-escape-clock-divisor-init-for-glk.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee Mon Sep 17 00:00:00 2001
From: Stanislav Lisovskiy
Date: Fri, 12 Jul 2019 11:19:38 +0300
Subject: drm/i915: Fix wrong escape clock divisor init for GLK
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Vandita Kulkarni
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M
Cc: Madhav Chauhan
Cc: Jani Nikula
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovs...@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/intel_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -422,8 +422,8 @@ static void glk_dsi_program_esc_clock(st
else
txesc2_div = 10;
- I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
- I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, (1 << (txesc1_div - 1)) &
GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, (1 << (txesc2_div - 1)) &
GLK_TX_ESC_CLK_DIV2_MASK);
}
/* Program BXT Mipi clocks and dividers */
Patches currently in stable-queue which might be from
stanislav.lisovs...@intel.com are
queue-4.14/drm-i915-fix-wrong-escape-clock-divisor-init-for-glk.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] dma-buf: nuke reservation_object seq number
Sorry I burried myself in some other stuff ...
On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > Quoting Christian König (2019-08-07 14:53:12)
> > > The only remaining use for this is to protect against setting a new
> > > exclusive
> > > fence while we grab both exclusive and shared. That can also be archived
> > > by
> > > looking if the exclusive fence has changed or not after completing the
> > > operation.
> > >
> > > v2: switch setting excl fence to rcu_assign_pointer
> > >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/dma-buf/reservation.c | 24 +---
> > > include/linux/reservation.h | 9 ++---
> > > 2 files changed, 7 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > > index 90bc6ef03598..f7f4a0858c2a 100644
> > > --- a/drivers/dma-buf/reservation.c
> > > +++ b/drivers/dma-buf/reservation.c
> > > @@ -49,12 +49,6 @@
> > > DEFINE_WD_CLASS(reservation_ww_class);
> > > EXPORT_SYMBOL(reservation_ww_class);
> > > -struct lock_class_key reservation_seqcount_class;
> > > -EXPORT_SYMBOL(reservation_seqcount_class);
> > > -
> > > -const char reservation_seqcount_string[] = "reservation_seqcount";
> > > -EXPORT_SYMBOL(reservation_seqcount_string);
> > > -
> > > /**
> > >* reservation_object_list_alloc - allocate fence list
> > >* @shared_max: number of fences we need space for
> > > @@ -103,9 +97,6 @@ static void reservation_object_list_free(struct
> > > reservation_object_list *list)
> > > void reservation_object_init(struct reservation_object *obj)
> > > {
> > > ww_mutex_init(>lock, _ww_class);
> > > -
> > > - __seqcount_init(>seq, reservation_seqcount_string,
> > > - _seqcount_class);
> > > RCU_INIT_POINTER(obj->fence, NULL);
> > > RCU_INIT_POINTER(obj->fence_excl, NULL);
> > > }
> > > @@ -282,12 +273,10 @@ void reservation_object_add_excl_fence(struct
> > > reservation_object *obj,
> > > dma_fence_get(fence);
> > > preempt_disable();
> > > - write_seqcount_begin(>seq);
> > > - /* write_seqcount_begin provides the necessary memory barrier */
> > > - RCU_INIT_POINTER(obj->fence_excl, fence);
> > > + rcu_assign_pointer(obj->fence_excl, fence);
> > > + /* pointer update must be visible before we modify the
> > > shared_count */
Pls add a "see reservation_object_fence()" here or similar.
> > > if (old)
> > > - old->shared_count = 0;
> > > - write_seqcount_end(>seq);
> > > + smp_store_mb(old->shared_count, 0);
So your comment and the kerneldoc don't match up. Quoting
Documentation/memory-barriers.txt:
This assigns the value to the variable and then inserts a full memory
barrier after it. It isn't guaranteed to insert anything more than a
compiler barrier in a UP compilation.
So order is 1. store 2. fence, but your comment suggests you want it the
other way round.
> > > preempt_enable();
> > > /* inplace update, no shared fences */
> > > @@ -368,11 +357,8 @@ int reservation_object_copy_fences(struct
> > > reservation_object *dst,
> > > old = reservation_object_get_excl(dst);
> > > preempt_disable();
> > > - write_seqcount_begin(>seq);
> > > - /* write_seqcount_begin provides the necessary memory barrier */
> > > - RCU_INIT_POINTER(dst->fence_excl, new);
> > > - RCU_INIT_POINTER(dst->fence, dst_list);
> > > - write_seqcount_end(>seq);
> > > + rcu_assign_pointer(dst->fence_excl, new);
> > > + rcu_assign_pointer(dst->fence, dst_list);
> > > preempt_enable();
> > > reservation_object_list_free(src_list);
> > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > index 044a5cd4af50..fd29baad0be3 100644
> > > --- a/include/linux/reservation.h
> > > +++ b/include/linux/reservation.h
> > > @@ -46,8 +46,6 @@
> > > #include
> > > extern struct ww_class reservation_ww_class;
> > > -extern struct lock_class_key reservation_seqcount_class;
> > > -extern const char reservation_seqcount_string[];
> > > /**
> > >* struct reservation_object_list - a list of shared fences
> > > @@ -71,7 +69,6 @@ struct reservation_object_list {
> > >*/
> > > struct reservation_object {
> > > struct ww_mutex lock;
> > > - seqcount_t seq;
> > > struct dma_fence __rcu *fence_excl;
> > > struct reservation_object_list __rcu *fence;
> > > @@ -156,14 +153,12 @@ reservation_object_fences(struct reservation_object
> > > *obj,
> > >struct reservation_object_list **list,
> > >u32 *shared_count)
> > > {
> > > - unsigned int seq;
> > > -
> > > do {
> > > - seq = read_seqcount_begin(>seq);
> > > *excl =
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex
== Series Details == Series: series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex URL : https://patchwork.freedesktop.org/series/65177/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6707 -> Patchwork_14014 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14014 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14014, 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_14014/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14014: ### IGT changes ### Possible regressions * igt@gem_exec_gttfill@basic: - fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-kbl-x1275/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-kbl-x1275/igt@gem_exec_gttf...@basic.html - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-icl-u3/igt@gem_exec_gttf...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-icl-u3/igt@gem_exec_gttf...@basic.html - fi-cml-u: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-cml-u/igt@gem_exec_gttf...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-cml-u/igt@gem_exec_gttf...@basic.html - fi-kbl-8809g: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html - fi-kbl-guc: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-kbl-guc/igt@gem_exec_gttf...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-kbl-guc/igt@gem_exec_gttf...@basic.html - fi-cml-u2: [PASS][11] -> [DMESG-WARN][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-cml-u2/igt@gem_exec_gttf...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-cml-u2/igt@gem_exec_gttf...@basic.html - fi-skl-6600u: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-skl-6600u/igt@gem_exec_gttf...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-skl-6600u/igt@gem_exec_gttf...@basic.html - fi-ivb-3770:[PASS][15] -> [DMESG-WARN][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-ivb-3770/igt@gem_exec_gttf...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-ivb-3770/igt@gem_exec_gttf...@basic.html - fi-byt-j1900: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-byt-j1900/igt@gem_exec_gttf...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-byt-j1900/igt@gem_exec_gttf...@basic.html - fi-skl-lmem:[PASS][19] -> [DMESG-WARN][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-skl-lmem/igt@gem_exec_gttf...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-skl-lmem/igt@gem_exec_gttf...@basic.html - fi-apl-guc: [PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-apl-guc/igt@gem_exec_gttf...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-apl-guc/igt@gem_exec_gttf...@basic.html - fi-byt-n2820: [PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-byt-n2820/igt@gem_exec_gttf...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-byt-n2820/igt@gem_exec_gttf...@basic.html - fi-skl-6770hq: [PASS][25] -> [DMESG-WARN][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-skl-6770hq/igt@gem_exec_gttf...@basic.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-skl-6770hq/igt@gem_exec_gttf...@basic.html - fi-skl-6260u: [PASS][27] -> [DMESG-WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-skl-6260u/igt@gem_exec_gttf...@basic.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14014/fi-skl-6260u/igt@gem_exec_gttf...@basic.html - fi-cfl-8109u: [PASS][29] -> [DMESG-WARN][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6707/fi-cfl-8109u/igt@gem_exec_gttf...@basic.html [30]:
Re: [Intel-gfx] [PATCH 2/2] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
On Wed, Aug 14, 2019 at 3:06 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-08-14 13:49:33)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index d474c6ac4100..1ea3c3c96a5a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -157,7 +157,15 @@ struct drm_i915_gem_object {
> > unsigned int pin_global;
> >
> > struct {
> > - struct mutex lock; /* protects the pages and their use */
> > + /*
> > +* Protects the pages and their use.
> > +*
> > +* IMPORTANT: It is not allowed to allocate memory while
> > holding
> > +* this lock, because the shrinker might recurse on it,
> > except
> > +* when there are no pages allocated yet and the object
> > isn't
> > +* visible on any LRU.
>
> It's not meant to be public free-for-lock, just to guard the transition
> between 0<->1. Inside that transition we do page allocations.
>
> Everyone else takes a pin.
Well yeah the comment is missing a lot of things.
>
> > +*/
> > + struct mutex lock;
> > atomic_t pages_pin_count;
> >
> > struct sg_table *pages;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > index 18f0ce0135c1..3b7ec6e6ea8b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > @@ -101,7 +101,7 @@ int __i915_gem_object_get_pages(struct
> > drm_i915_gem_object *obj)
>
> Fwiw, we have use cases (and people asking where are those patches) for
> nested allocations.
Yeah and it's those patches I'm freaking out about. Imo the current
annotations for obj->mm.lock just annotate the call chain nesting.
Which trivially shuts up lockdep, but also guarantees you're not going
to find real deadlocks before they happen. There needs to be a very
clear proof attached to why the nesting annotation is correct. Random
selection of examples:
- block partitions nesting in their overall device, where you never
take them the other way round
- the struct_mutex nesting, which works because there's only ever one
struct_mutex in the entire system. As soon as there are two we need a
new reason (and that's the reason for patch 1 here).
- obj->mm.lock, which nest both ways with fs_reclaim, but there's a
clear difference for the pages_pin_count goes 0->1 (allocation
allowed) and 1->0 (can be called from shrinker context or anything
else that needs freeing Which this series tries to make a bit clearer
Just noticing that the shrinker generally can nest within normal code
and annotating that nesting like that doesn't really proof anything.
And allows some fun stuff, like someon allocating memory from a
put_pages call, which I expect will lead to some fun later on. Just
kinda usual paranoia.
And I'm not sure at all whether at least the internal patches floating
around with a lot more nesting actually work. There's not really solid
explanation attached to them, and I haven't figured one out (unlike
for the two cases in upstream we have already, with struct_mutex and
obj->mm.lock).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/uc: Fini hw even if GuC is not running
On 8/13/19 1:18 PM, Michal Wajdeczko wrote:
> On Tue, 13 Aug 2019 18:26:28 +0200, Fernando Pacheco
> wrote:
>
>> We should not be skipping uc_fini_hw on finding GuC
>> is no longer running. There is plenty of hw and internal
>> state that can be cleaned up without having to communicate
>> with GuC.
>>
>> Signed-off-by: Fernando Pacheco
>> Cc: Daniele Ceraolo Spurio
>> Cc: Michal Wajdeczko
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> index 0dc2b0cf4604..c698cddc14dc 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> @@ -521,7 +521,7 @@ void intel_uc_fini_hw(struct intel_uc *uc)
>> {
>> struct intel_guc *guc = >guc;
>> - if (!intel_guc_is_running(guc))
>> + if (!intel_uc_supports_guc(uc))
>
> there is a huge difference between is_running vs supports_guc
> and choosing supports_guc is optimist approach as we can fail
> to fetch guc fw and abort early, so maybe
>
> if (!intel_uc_fw_is_available(>fw))
This is the better check. Thanks!
>
> would be closer to reality (assuming we don't fail on wopcm
> (hmm, maybe we should force fw state to FAIL in such case?)
That would make sense to me. The fail on wopcm directly
affects the state of the fw because we abort the upload
as a result.
Thanks,
Fernando
>
>
>> return;
>> if (intel_uc_supports_guc_submission(uc))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex
== Series Details == Series: series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex URL : https://patchwork.freedesktop.org/series/65177/ State : warning == Summary == $ dim checkpatch origin/drm-tip ea422f4a5a9e drm/i915: Comment userptr recursion on struct_mutex -:30: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 12 lines checked 2c4c1d48651d RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head -:78: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #78: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:287: +* struct_mutex in the entire system. */ -:231: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 137 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for HDCP2.2 Phase II (rev15)
== Series Details == Series: HDCP2.2 Phase II (rev15) URL : https://patchwork.freedesktop.org/series/57232/ State : failure == Summary == Applying: drm: Add Content protection type property Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_atomic_uapi.c M drivers/gpu/drm/drm_connector.c M drivers/gpu/drm/drm_hdcp.c M drivers/gpu/drm/i915/display/intel_hdcp.c M include/drm/drm_connector.h M include/drm/drm_hdcp.h M include/drm/drm_mode_config.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_hdcp.h CONFLICT (content): Merge conflict in include/drm/drm_hdcp.h Auto-merging include/drm/drm_connector.h Auto-merging drivers/gpu/drm/i915/display/intel_hdcp.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_hdcp.c Auto-merging drivers/gpu/drm/drm_hdcp.c Auto-merging drivers/gpu/drm/drm_connector.c Auto-merging drivers/gpu/drm/drm_atomic_uapi.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm: Add Content protection type property When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v7, 01/16] drm: Add Enhanced Gamma LUT precision structure
>-Original Message-
>From: james qian wang (Arm Technology China) [mailto:james.qian.w...@arm.com]
>Sent: Tuesday, August 13, 2019 3:12 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>; nd
>Subject: Re: [v7,01/16] drm: Add Enhanced Gamma LUT precision structure
>
>On Fri, Mar 29, 2019 at 01:45:59AM +0530, Uma Shankar wrote:
>> Existing LUT precision structure is having only 16 bit precision. This
>> is not enough for upcoming enhanced hardwares and advance usecases
>> like HDR processing. Hence added a new structure with 32 bit precision
>> values. Also added the code, for extracting the same from values
>> passed from userspace.
>>
>> v4: Rebase
>>
>> v5: Relocated the helper function to drm_color_mgmt.c. Declared the
>> same in a header file (Alexandru Gheorghe)
>>
>> v6: Enhanced gamma lut structure to take U32.32 format as input.
>> This is needed for HDR usecase which require higher precision.
>>
>> v7: Addressed Maarten's review comments and fixed the calculation.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Alexandru Gheorghe
>
>Hi Uma
>
>When can we merge these plane color-mgmt support into upstream ?
>or can we merge the DRM-CORE part patches firstly?
Hi James,
I will refresh this series by early next week. We will try to prioritize this
development and speed
up with merge.
Regards,
Uma Shankar
>thanks
>james
>
>> ---
>> drivers/gpu/drm/drm_color_mgmt.c | 20
>> include/drm/drm_color_mgmt.h | 1 +
>> include/uapi/drm/drm_mode.h | 15 +++
>> 3 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>> b/drivers/gpu/drm/drm_color_mgmt.c
>> index d5d34d0..79ff874 100644
>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>> @@ -128,6 +128,26 @@ uint32_t drm_color_lut_extract(uint32_t
>> user_input, uint32_t bit_precision) }
>> EXPORT_SYMBOL(drm_color_lut_extract);
>>
>> +/*
>> + * Added to accommodate enhanced LUT precision.
>> + * Max LUT precision is 32 bits.
>> + */
>> +u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision) {
>> +u64 val = user_input & 0x;
>> +u32 max = 0x >> (32 - bit_precision);
>> +
>> +/* Round only if we're not using full precision. */
>> +if (bit_precision < 32) {
>> +val += 1UL << (32 - bit_precision - 1);
>> +val >>= 32 - bit_precision;
>> +}
>> +
>> +return ((user_input & 0x) |
>> +clamp_val(val, 0, max));
>> +}
>> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
>> +
>> /**
>> * drm_crtc_enable_color_mgmt - enable color management properties
>> * @crtc: DRM CRTC
>> diff --git a/include/drm/drm_color_mgmt.h
>> b/include/drm/drm_color_mgmt.h index d1c662d..c9d2746 100644
>> --- a/include/drm/drm_color_mgmt.h
>> +++ b/include/drm/drm_color_mgmt.h
>> @@ -30,6 +30,7 @@
>> struct drm_plane;
>>
>> uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t
>> bit_precision);
>> +u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision);
>>
>> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> uint degamma_lut_size,
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 09d7296..ca81410 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -629,6 +629,21 @@ struct drm_color_lut {
>> __u16 reserved;
>> };
>>
>> +/*
>> + * Creating 64 bit palette entries for better data
>> + * precision. This will be required for HDR and
>> + * similar color processing usecases.
>> + */
>> +struct drm_color_lut_ext {
>> +/*
>> + * Data is U32.32 fixed point format.
>> + */
>> +__u64 red;
>> +__u64 green;
>> +__u64 blue;
>> +__u64 reserved;
>> +};
>> +
>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
>> DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
>> DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
___
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: Remove i915 ggtt WA since GT E0
== Series Details == Series: drm/i915: Remove i915 ggtt WA since GT E0 URL : https://patchwork.freedesktop.org/series/65160/ State : success == Summary == CI Bug Log - changes from CI_DRM_6700_full -> Patchwork_14006_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14006_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb1/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@kms_flip@2x-flip-vs-modeset: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-hsw7/igt@kms_f...@2x-flip-vs-modeset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-hsw4/igt@kms_f...@2x-flip-vs-modeset.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-skl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb8/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +19 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb1/igt@prime_b...@hang-bsd2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb8/igt@prime_b...@hang-bsd2.html Possible fixes * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [SKIP][17] ([fdo#111325]) -> [PASS][18] +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb3/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [SKIP][19] ([fdo#109276]) -> [PASS][20] +23 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_suspend@fence-restore-untiled: - shard-skl: [INCOMPLETE][21] ([fdo#104108]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-skl7/igt@i915_susp...@fence-restore-untiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-skl2/igt@i915_susp...@fence-restore-untiled.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [FAIL][23] ([fdo#105767]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14006/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html *
Re: [Intel-gfx] [PATCH] drm/i915/uc: Fini hw even if GuC is not running
On 8/13/19 1:16 PM, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/19 9:26 AM, Fernando Pacheco wrote:
>> We should not be skipping uc_fini_hw on finding GuC
>> is no longer running. There is plenty of hw and internal
>> state that can be cleaned up without having to communicate
>> with GuC.
>>
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943
>
>> Signed-off-by: Fernando Pacheco
>> Cc: Daniele Ceraolo Spurio
>> Cc: Michal Wajdeczko
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> index 0dc2b0cf4604..c698cddc14dc 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> @@ -521,7 +521,7 @@ void intel_uc_fini_hw(struct intel_uc *uc)
>> {
>> struct intel_guc *guc = >guc;
>> - if (!intel_guc_is_running(guc))
>> + if (!intel_uc_supports_guc(uc))
>
> Both calls below handle the case where GuC is already not running so we're
> safe, but now that we wedge when we hit a guc error we can also do something
> like:
>
> -EIO load error -> uc_fini_hw() -> wedge
> and then
> unload -> uc_fini_hw()
>
> it should be all be handled safely (the fault injection test is passing where
> we've run it), but we end up with "GuC communication disabled" multiple times
> in the logs:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13999/fi-skl-guc/igt@i915_module_l...@reload-with-fault-injection.html
>
> <6> [237.818905] [drm] GuC communication enabled
>
> <6> [237.822739] i915 :00:02.0: [drm:__i915_inject_load_error [i915]]
> Injecting failure -5 at checkpoint 44 [i915_gem_init:1503]
> <6> [237.840808] [drm] GuC communication disabled
> ...
> <6> [238.160935] [drm] GuC communication disabled
>
> Maybe return early from guc_disable_communication if the communication was
> already disabled?
As discussed offline, an early return might also require changes to the stop
communication phase.
I'll work on this separately as for now the extra disable only results in the
extra logging.
Thanks,
Fernando
>
>
> Daniele
>
>> return;
>> if (intel_uc_supports_guc_submission(uc))
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [RFC PATCH 2/4] lib/i915/intel_memory_region: Add lib to manage memory regions
+ Abdiel/intel-gfx
Quoting Joonas Lahtinen (2019-08-14 15:46:01)
> Quoting Chris Wilson (2019-08-14 13:31:10)
> > Quoting Lukasz Kalamarz (2019-08-14 11:21:38)
> > > +/**
> > > + * gem_get_page_size:
> > > + * @fd: open i915 drm file descriptor
> > > + * @mem_region_type: used memory_region type
> > > + *
> > > + * With introduction of LMEM we observe different page sizes for those
> > > two
> > > + * memory regions. Without this helper function we may be prone to
> > > forget
> > > + * about setting proper page size.
> > > + */
> > > +uint32_t gem_get_batch_size(int fd, uint8_t mem_region_type)
> > > +{
> > > + return (mem_region_type == LOCAL_I915_DEVICE_MEMORY) ? 65536 :
> > > 4096;
> >
> > You have to be kidding me. This, this constitutes a forward thinking uAPI?
>
> We should be just fine requesting the minimum BO size we need, letting the KMD
> round the sizes up and reading back the created BO size.
>
> (Now that the regression has been fixed, too :) )
>
> So the code logic needs to be updated to follow that.
On a second thought we may be better off rounding the backing storage
size up transparently.
I guess the prime question is why would the userspace/IGT care for
actual backing storage size?
Abdiel/Matt, how painful would it be to round the backing storage size
up, irrespective of the BO size?
Regards, Joonas
___
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/guc: Remove client->submissions
== Series Details == Series: drm/i915/guc: Remove client->submissions URL : https://patchwork.freedesktop.org/series/65159/ State : success == Summary == CI Bug Log - changes from CI_DRM_6700_full -> Patchwork_14005_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14005_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([fdo#108686]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-glk2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@stress-mm-invalidate-close: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-apl6/igt@gem_userptr_bl...@stress-mm-invalidate-close.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-apl4/igt@gem_userptr_bl...@stress-mm-invalidate-close.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-ytiled: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103184] / [fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-skl9/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-skl10/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-skl5/igt@kms_frontbuffer_track...@fbc-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-skl1/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-badstride: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103167]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-skl9/igt@kms_frontbuffer_track...@fbcpsr-badstride.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-skl10/igt@kms_frontbuffer_track...@fbcpsr-badstride.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-iclb1/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@prime_vgem@fence-wait-bsd2: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +12 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb1/igt@prime_v...@fence-wait-bsd2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14005/shard-iclb8/igt@prime_v...@fence-wait-bsd2.html Possible fixes * igt@gem_ctx_shared@q-smoketest-bsd2: - shard-iclb: [SKIP][23] ([fdo#109276]) -> [PASS][24] +14 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6700/shard-iclb3/igt@gem_ctx_sha...@q-smoketest-bsd2.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/wopcm: Try to use already locked WOPCM layout
== Series Details == Series: series starting with [1/2] drm/i915/wopcm: Try to use already locked WOPCM layout URL : https://patchwork.freedesktop.org/series/65175/ State : success == Summary == CI Bug Log - changes from CI_DRM_6706 -> Patchwork_14012 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/ Known issues Here are the changes found in Patchwork_14012 that come from known issues: ### IGT changes ### Issues hit * igt@gem_basic@bad-close: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u3/igt@gem_ba...@bad-close.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/fi-icl-u3/igt@gem_ba...@bad-close.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#08]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html Possible fixes * igt@gem_exec_reloc@basic-cpu-read-noreloc: - fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u3/igt@gem_exec_re...@basic-cpu-read-noreloc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/fi-icl-u3/igt@gem_exec_re...@basic-cpu-read-noreloc.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][7] ([fdo#109483]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][9] ([fdo#103167]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Warnings * igt@kms_chamelium@common-hpd-after-suspend: - fi-icl-u2: [FAIL][11] ([fdo#109483]) -> [DMESG-WARN][12] ([fdo#102505] / [fdo#110390]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390 [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08 Participating hosts (52 -> 45) -- Additional (1): fi-icl-u4 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6706 -> Patchwork_14012 CI-20190529: 20190529 CI_DRM_6706: 57b60ae5ac6b9d384440562785c2581f6ee8330f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5133: f50ce93c889c4fdc1fd63fd77626a96afd8388a3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14012: 8f00fae7f845d9f4f1eb49d34b494c36e0742474 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8f00fae7f845 drm/i915/uc: Move FW size sanity check back to fetch e6a35c96b2ad drm/i915/wopcm: Try to use already locked WOPCM layout == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14012/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
== Series Details == Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock URL : https://patchwork.freedesktop.org/series/65169/ State : success == Summary == CI Bug Log - changes from CI_DRM_6706 -> Patchwork_14011 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/ Known issues Here are the changes found in Patchwork_14011 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_reloc@basic-cpu-read-noreloc: - fi-icl-u3: [DMESG-WARN][1] ([fdo#107724]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u3/igt@gem_exec_re...@basic-cpu-read-noreloc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/fi-icl-u3/igt@gem_exec_re...@basic-cpu-read-noreloc.html * igt@i915_selftest@live_requests: - fi-byt-j1900: [INCOMPLETE][3] ([fdo#102657]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-byt-j1900/igt@i915_selftest@live_requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/fi-byt-j1900/igt@i915_selftest@live_requests.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][5] ([fdo#109483]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@kms_chamelium@common-hpd-after-suspend: - fi-icl-u2: [FAIL][7] ([fdo#109483]) -> [DMESG-WARN][8] ([fdo#102505] / [fdo#110390]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6706/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505 [fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390 Participating hosts (52 -> 45) -- Additional (1): fi-icl-u4 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6706 -> Patchwork_14011 CI-20190529: 20190529 CI_DRM_6706: 57b60ae5ac6b9d384440562785c2581f6ee8330f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5133: f50ce93c889c4fdc1fd63fd77626a96afd8388a3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14011: 3be7cb49b9aa4675e6cca455ff87ceef78429b4a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3be7cb49b9aa drm/i915: Markup expected timeline locks for i915_active c041eb4cddd2 drm/i915: Extract intel_frontbuffer active tracking dd9b1624281c drm/i915/gt: Mark context->active_count as protected by timeline->mutex 85d1fdcb4c5a drm/i915: Protect request retirement with timeline->mutex 3ae4f657c23a drm/i915/gt: Guard timeline pinning with its own mutex 43ad1d6b5710 drm/i915/gt: Convert timeline tracking to spinlock 8a289c1555ae drm/i915/gt: Track timeline activeness in enter/exit c067af237d77 drm/i915/execlists: Lift process_csb() out of the irq-off spinlock == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14011/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
Quoting Daniel Vetter (2019-08-14 13:49:33)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index d474c6ac4100..1ea3c3c96a5a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -157,7 +157,15 @@ struct drm_i915_gem_object {
> unsigned int pin_global;
>
> struct {
> - struct mutex lock; /* protects the pages and their use */
> + /*
> +* Protects the pages and their use.
> +*
> +* IMPORTANT: It is not allowed to allocate memory while
> holding
> +* this lock, because the shrinker might recurse on it, except
> +* when there are no pages allocated yet and the object isn't
> +* visible on any LRU.
It's not meant to be public free-for-lock, just to guard the transition
between 0<->1. Inside that transition we do page allocations.
Everyone else takes a pin.
> +*/
> + struct mutex lock;
> atomic_t pages_pin_count;
>
> struct sg_table *pages;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 18f0ce0135c1..3b7ec6e6ea8b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -101,7 +101,7 @@ int __i915_gem_object_get_pages(struct
> drm_i915_gem_object *obj)
Fwiw, we have use cases (and people asking where are those patches) for
nested allocations.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Comment userptr recursion on struct_mutex
Discussed this a bit with Chris, I think a comment here is warranted
that this will be bad once we have more than one i915 instance. And
lockdep won't catch it.
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 74da35611d7c..70dc506a5426 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -135,6 +135,12 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
switch (mutex_trylock_recursive(unlock)) {
default:
case MUTEX_TRYLOCK_FAILED:
+ /*
+* NOTE: This only works because there's only
+* ever one i915-style struct_mutex in the
+* entire system. If we could have two i915
+* instances, this would deadlock.
+*/
if (mutex_lock_killable_nested(unlock,
I915_MM_SHRINKER)) {
i915_gem_object_put(obj);
return -EINTR;
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlighting a bit more
the actual nature of the nesting that's going on. Essentially we have
two kinds of objects:
- objects without pages allocated, which cannot be on any lru and are
hence inaccessible to the shrinker.
- objects which have pages allocated, which are on an lru, and which
the shrinker can decide to throw out.
For the former type of object, memory allcoations while holding
obj->mm.lock are permissible. For the latter they are not. And
get/put_pages transitions between the two types of objects.
This is still not entirely fool-proof since the rules might chance.
But as long as we run such a code ever at runtime lockdep should be
able to observe the inconsistency and complain (like with any other
lockdep class that we've split up in multiple classes). But there are
a few clear benefits:
- We can drop the nesting flag parameter from
__i915_gem_object_put_pages, because that function by definition is
never going allocate memory, and calling it on an object which
doesn't have its pages allocated would be a bug.
- We strictly catch more bugs, since there's not only one place in the
entire tree which is annotated with the special class. All the
other places that had explicit lockdep nesting annotations we're now
going to leave up to lockdep again.
- Specifically this catches stuff like calling get_pages from
put_pages (which isn't really a good idea, if we can call put_pages
so could the shrinker). I've seen patches do exactly that.
Of course I fully expect CI will show me for the fool I am with this
one here :-)
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 7 +++
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
7 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 3929c3a6b281..a1a835539e09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -191,7 +191,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
GEM_BUG_ON(!list_empty(>lut_list));
atomic_set(>mm.pages_pin_count, 0);
- __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ __i915_gem_object_put_pages(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
bitmap_free(obj->bit_17);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3714cf234d64..3bde9a601eca 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -281,11 +281,21 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
+ /*
+* Only used by struct_mutex, when called "recursively" from
+* direct-reclaim-esque. Safe because there is only every one
+* struct_mutex in the entire system. */
+ I915_MM_SHRINKER,
+ /*
+* Used for obj->mm.lock when allocating pages. Safe because the object
+* isn't yet on any LRU, and therefore the shrinker can't deadlock on
+* it. As soon as the object has pages, obj->mm.lock nests within
+* fs_reclaim.
+*/
+ I915_MM_GET_PAGES
};
-int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
- enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index d474c6ac4100..1ea3c3c96a5a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -157,7 +157,15 @@ struct drm_i915_gem_object {
unsigned int pin_global;
struct {
- struct mutex lock; /* protects the pages and their use */
+ /*
+* Protects the pages and their use.
+*
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
== Series Details == Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock URL : https://patchwork.freedesktop.org/series/65169/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Lift process_csb() out of the irq-off spinlock +drivers/gpu/drm/i915/gt/intel_lrc.c:983:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gt/intel_lrc.c:983:24: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) -./drivers/gpu/drm/i915/i915_utils.h:262:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) +./drivers/gpu/drm/i915/i915_utils.h:260:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_utils.h:262:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_utils.h:260:16: warning: expression using sizeof(void) Commit: drm/i915/gt: Track timeline activeness in enter/exit Okay! Commit: drm/i915/gt: Convert timeline tracking to spinlock Okay! Commit: drm/i915/gt: Guard timeline pinning with its own mutex Okay! Commit: drm/i915: Protect request retirement with timeline->mutex Okay! Commit: drm/i915/gt: Mark context->active_count as protected by timeline->mutex Okay! Commit: drm/i915: Extract intel_frontbuffer active tracking Okay! Commit: drm/i915: Markup expected timeline locks for i915_active Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
== Series Details == Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock URL : https://patchwork.freedesktop.org/series/65169/ State : warning == Summary == $ dim checkpatch origin/drm-tip c067af237d77 drm/i915/execlists: Lift process_csb() out of the irq-off spinlock 8a289c1555ae drm/i915/gt: Track timeline activeness in enter/exit 43ad1d6b5710 drm/i915/gt: Convert timeline tracking to spinlock 3ae4f657c23a drm/i915/gt: Guard timeline pinning with its own mutex 85d1fdcb4c5a drm/i915: Protect request retirement with timeline->mutex dd9b1624281c drm/i915/gt: Mark context->active_count as protected by timeline->mutex c041eb4cddd2 drm/i915: Extract intel_frontbuffer active tracking 3be7cb49b9aa drm/i915: Markup expected timeline locks for i915_active -:290: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #290: FILE: drivers/gpu/drm/i915/i915_active_types.h:28: + struct mutex *lock; total: 0 errors, 0 warnings, 1 checks, 242 lines checked ___ 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/ttm: make ttm bo a gem bo subclass (rev4)
== Series Details == Series: drm/ttm: make ttm bo a gem bo subclass (rev4) URL : https://patchwork.freedesktop.org/series/64701/ State : failure == Summary == Applying: drm/ttm: add gem base object Using index info to reconstruct a base tree... M include/drm/ttm/ttm_bo_api.h Falling back to patching base and 3-way merge... Auto-merging include/drm/ttm/ttm_bo_api.h No changes -- Patch already applied. Applying: drm/vram: use embedded gem object Using index info to reconstruct a base tree... M drivers/gpu/drm/ast/ast_main.c M drivers/gpu/drm/drm_gem_vram_helper.c M drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c M drivers/gpu/drm/vboxvideo/vbox_main.c M include/drm/drm_gem_vram_helper.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/drm_gem_vram_helper.c No changes -- Patch already applied. Applying: drm/qxl: use embedded gem object Using index info to reconstruct a base tree... M drivers/gpu/drm/qxl/qxl_cmd.c M drivers/gpu/drm/qxl/qxl_debugfs.c M drivers/gpu/drm/qxl/qxl_display.c M drivers/gpu/drm/qxl/qxl_drv.h M drivers/gpu/drm/qxl/qxl_gem.c M drivers/gpu/drm/qxl/qxl_object.c M drivers/gpu/drm/qxl/qxl_object.h M drivers/gpu/drm/qxl/qxl_release.c M drivers/gpu/drm/qxl/qxl_ttm.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/qxl/qxl_release.c Auto-merging drivers/gpu/drm/qxl/qxl_object.h Auto-merging drivers/gpu/drm/qxl/qxl_debugfs.c No changes -- Patch already applied. Applying: drm/radeon: use embedded gem object Using index info to reconstruct a base tree... M drivers/gpu/drm/radeon/radeon.h M drivers/gpu/drm/radeon/radeon_cs.c M drivers/gpu/drm/radeon/radeon_display.c M drivers/gpu/drm/radeon/radeon_gem.c M drivers/gpu/drm/radeon/radeon_object.c M drivers/gpu/drm/radeon/radeon_prime.c M drivers/gpu/drm/radeon/radeon_ttm.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/radeon/radeon_ttm.c Auto-merging drivers/gpu/drm/radeon/radeon_prime.c Auto-merging drivers/gpu/drm/radeon/radeon_object.c CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_object.c Auto-merging drivers/gpu/drm/radeon/radeon_gem.c Auto-merging drivers/gpu/drm/radeon/radeon_display.c Auto-merging drivers/gpu/drm/radeon/radeon_cs.c Auto-merging drivers/gpu/drm/radeon/radeon.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0004 drm/radeon: use embedded gem object When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for HDCP2.2 Phase II (rev14)
Hi,
Sorry for the delay, I was on vacation. The machine fi-skl-6770hq was
not marked as having an LSPCON. This is now done, and this means that
this issue should be covered by ab existing bug.
I queued another run, and we'll see if it gives us a green (new tests
don't need to pass on all machines).
Martin
On 02/08/2019 10:04, Ramalingam C wrote:
> On 2019-08-01 at 18:43:16 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: HDCP2.2 Phase II (rev14)
>> URL : https://patchwork.freedesktop.org/series/57232/
>> State : failure
>>
>> == Summary ==
>>
>> CI Bug Log - changes from CI_DRM_6605 -> Patchwork_13834
>>
>>
>> Summary
>> ---
>>
>> **FAILURE**
>>
>> Serious unknown changes coming with Patchwork_13834 absolutely need to be
>> verified manually.
>>
>> If you think the reported changes have nothing to do with the changes
>> introduced in Patchwork_13834, 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_13834/
>>
>> Possible new issues
>> ---
>
>>
>> Here are the unknown changes that may have been introduced in
>> Patchwork_13834:
>>
>> ### IGT changes ###
>>
>> Possible regressions
> Martin,
>
> There is no regression in this test result. Known skips and expected
> failures due to hdcp sinks are observed on the new HDCP test called
> "SRM".
>
> I have provided the reasoning for each observations below. With these
> filters in CI results supposed to be GREEN.
>
> How should we proceed here further? Thanks.
>>
>> * igt@i915_module_load@reload-with-fault-injection:
>> - fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] +2 similar issues
>>[1]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6605/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
>>[2]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
> These dmesg warnings are caused due to the DP aux transfer failures.
> [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff
>>
>> * {igt@kms_content_protection@srm} (NEW):
> SRM test is newly added at
> https://patchwork.freedesktop.org/series/57756/ and used here to test.
>> - fi-cfl-8109u: NOTRUN -> [FAIL][3]
>>[3]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-cfl-8109u/igt@kms_content_protect...@srm.html
> Failed due to the known HDCP error on LspCON
> <7> [388.944041] [drm:intel_hdcp_auth [i915]] KSV list failed to become ready
> (-110)
>> - {fi-icl-u4}:NOTRUN -> [SKIP][4]
>>[4]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-icl-u4/igt@kms_content_protect...@srm.html
>> - fi-icl-dsi: NOTRUN -> [SKIP][5]
>>[5]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-icl-dsi/igt@kms_content_protect...@srm.html
> Above two tests are expected to skip as No connector found with HDCP
> capability.
>> - fi-skl-lmem:NOTRUN -> [FAIL][6]
>>[6]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-skl-lmem/igt@kms_content_protect...@srm.html
>> - fi-apl-guc: NOTRUN -> [FAIL][7]
>>[7]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-apl-guc/igt@kms_content_protect...@srm.html
> Above two tests expected failed due to the known HDCP error on LspCON
> <7> [459.700324] [drm:intel_hdcp_auth [i915]] KSV list failed to become ready
> (-110)
>> - fi-icl-u3: NOTRUN -> [FAIL][8]
>>[8]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-icl-u3/igt@kms_content_protect...@srm.html
> Failed due to invalid BKSV. Hence expected behaviour on this sink.
> <7> [296.873715] [drm:intel_hdcp_read_valid_bksv.isra.1 [i915]] Bksv is
> invalid
>> - fi-cml-u2: NOTRUN -> [SKIP][9]
>>[9]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-cml-u2/igt@kms_content_protect...@srm.html
> Test expected to skip as No connector found with HDCP capability.
>
> -Ram
>>
>>
>> New tests
>> -
>>
>> New tests have been introduced between CI_DRM_6605 and Patchwork_13834:
>>
>> ### New IGT tests (1) ###
>>
>> * igt@kms_content_protection@srm:
>> - Statuses : 4 fail(s) 5 pass(s) 34 skip(s)
>> - Exec time: [0.0, 130.44] s
>>
>>
>>
>> Known issues
>>
>>
>> Here are the changes found in Patchwork_13834 that come from known issues:
>>
>> ### IGT changes ###
>>
>> Issues hit
>>
>> * igt@kms_addfb_basic@size-max:
>> - fi-icl-u3: [PASS][10] -> [DMESG-WARN][11] ([fdo#107724])
>>[10]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6605/fi-icl-u3/igt@kms_addfb_ba...@size-max.html
>>[11]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13834/fi-icl-u3/igt@kms_addfb_ba...@size-max.html
>>
>>
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove i915 ggtt WA since GT E0
Quoting dong.y...@intel.com (2019-08-14 10:54:05)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
>
> v2: add comment in code, by:
> Joonas Lahtinen
I didn't suggest any comments, I suggested to change the code.
>
> Signed-off-by: Yang, Dong
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5f3e5c13fbaa..a0dfd1926b1b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2141,6 +2141,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define BXT_REVID_B0 0x3
> #define BXT_REVID_B_LAST 0x8
> #define BXT_REVID_C0 0x9
> +#define BXT_REVID_D0 0xC
> +#define BXT_REVID_E0 0xD
>
> #define IS_BXT_REVID(dev_priv, since, until) \
> (IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
> @@ -2357,7 +2359,8 @@ static inline bool intel_scanout_needs_vtd_wa(struct
> drm_i915_private *dev_priv)
> static inline bool
> intel_ggtt_update_needs_vtd_wa(struct drm_i915_private *dev_priv)
> {
> - return IS_BROXTON(dev_priv) && intel_vtd_active();
> + /* Broxton steppings starting from E0 have fixed the bug. */
This comment is not needed.
I suggested using BXT_REVID_D_LAST define instead of D0.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
