Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/selftests: recreate WA lists inside the selftest
Quoting Daniele Ceraolo Spurio (2019-01-10 01:32:31) > By using the wa lists inside the live driver structures, we won't > catch issues where those are incorrectly setup or corrupted. > To cover this gap, update the workaround framework to allow saving the > wa lists to independent structures and use them in the selftests. > > Suggested-by: Chris Wilson > Cc: Chris Wilson > Signed-off-by: Daniele Ceraolo Spurio Neat, slightly more work than I hoped it might have been so sorry about that, but looks an improvement overall (with the explicit wa_list parameters). Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: init per-engine WAs for all engines
Quoting Daniele Ceraolo Spurio (2019-01-10 01:32:32)
> commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> refactored the workaround code to have functions per-engine, but didn't
> call any of them from logical_xcs_ring_init. Since we do have a non-RCS
> workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
> intel_engine_init_workarounds for non-RCS engines.
> Note that whitelist is still RCS-only.
>
> v2: move the call to logical_ring_init (Chris)
>
> Fixes: 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave/Daniel, drm-misc-fixes-2019-01-10: Pull request for drm-misc-fixes for v5.0-rc2: - Fixes for the tc358767 bridge to work correctly with tc358867 using a DP connector. - Make resume work on amdgpu when a DP-MST display is unplugged. The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-01-10 for you to fetch changes up to f8c15790e4d8bdf2d21a5e9d43b5f97983af1222: drm/bridge: tc358767: use DP connector if no panel set (2019-01-09 10:49:31 +0100) Pull request for drm-misc-fixes for v5.0-rc2: - Fixes for the tc358767 bridge to work correctly with tc358867 using a DP connector. - Make resume work on amdgpu when a DP-MST display is unplugged. Lyude Paul (3): drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume() drm/amdgpu: Don't fail resume process if resuming atomic state fails drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume() Tomi Valkeinen (7): drm/bridge: tc358767: add bus flags drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE drm/bridge: tc358767: fix single lane configuration drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value drm/bridge: tc358767: reject modes which require too much BW drm/bridge: tc358767: fix output H/V syncs drm/bridge: tc358767: use DP connector if no panel set drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 37 +++-- drivers/gpu/drm/bridge/tc358767.c | 48 ++- include/drm/drm_dp_mst_helper.h | 3 +- 3 files changed, 65 insertions(+), 23 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/selftests: recreate WA lists inside the selftest
== Series Details == Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists inside the selftest URL : https://patchwork.freedesktop.org/series/54967/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11271_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11271_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@basic-all-heavy: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] +1 * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-b-ctm-negative: - shard-skl: PASS -> FAIL [fdo#107361] * igt@kms_cursor_crc@cursor-64x64-random: - shard-glk: PASS -> FAIL [fdo#103232] - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] +2 * igt@kms_pipe_crc_basic@read-crc-pipe-a: - shard-skl: NOTRUN -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: - shard-skl: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-apl: PASS -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-glk: PASS -> FAIL [fdo#103166] +3 * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@pm_backlight@fade_with_suspend: - shard-skl: NOTRUN -> FAIL [fdo#107847] * igt@pm_rpm@basic-rte: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@pm_rpm@dpms-mode-unset-non-lpsp: - shard-skl: SKIP -> INCOMPLETE [fdo#107807] Possible fixes * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: FAIL [fdo#108682] -> PASS * igt@kms_color@pipe-a-ctm-max: - shard-skl: FAIL [fdo#108147] -> PASS * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-glk: FAIL [fdo#103232] -> PASS +1 * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: FAIL [fdo#103184] -> PASS * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: FAIL [fdo#108222] -> PASS * igt@kms_flip@busy-flip-interruptible: - shard-skl: FAIL [fdo#103257] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-apl: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: FAIL [fdo#103167] -> PASS +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-pgflip-blt: - shard-skl: FAIL [fdo#105682] -> PASS * igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt: - shard-skl: FAIL [fdo#103167] -> PASS * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: FAIL [fdo#103166] -> PASS * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: FAIL [fdo#107815] / [fdo#108145] -> PASS * igt@kms_setmode@basic: - shard-apl: FAIL [fdo#99912] -> PASS - shard-kbl: FAIL [fdo#99912] -> PASS * igt@pm_rpm@debugfs-read: - shard-skl: INCOMPLETE [fdo#107807] -> PASS Warnings * igt@gem_cpu_reloc@full: - shard-skl: INCOMPLETE [fdo#108248] -> TIMEOUT [fdo#108248] [fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103257]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reduce i915_request_alloc retirement to local context (rev3)
== Series Details == Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev3) URL : https://patchwork.freedesktop.org/series/54820/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11270_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11270_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-b-ctm-negative: - shard-skl: PASS -> FAIL [fdo#107361] * igt@kms_cursor_crc@cursor-64x64-random: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: - shard-skl: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-apl: PASS -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-glk: PASS -> FAIL [fdo#103166] +4 * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: PASS -> FAIL [fdo#103166] +6 * igt@kms_rotation_crc@sprite-rotation-90-pos-100-0: - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@pm_backlight@fade_with_suspend: - shard-skl: NOTRUN -> FAIL [fdo#107847] Possible fixes * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: FAIL [fdo#108682] -> PASS * igt@kms_color@pipe-a-ctm-max: - shard-skl: FAIL [fdo#108147] -> PASS * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-glk: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: FAIL [fdo#103184] -> PASS * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: FAIL [fdo#108222] -> PASS * igt@kms_flip@busy-flip-interruptible: - shard-skl: FAIL [fdo#103257] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-apl: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: FAIL [fdo#103167] -> PASS +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-pgflip-blt: - shard-skl: FAIL [fdo#105682] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-farfromfence: - shard-skl: FAIL [fdo#103167] -> PASS +4 * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: FAIL [fdo#103166] -> PASS * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-apl: FAIL [fdo#103166] -> PASS * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: FAIL [fdo#107815] / [fdo#108145] -> PASS * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: DMESG-FAIL [fdo#108950] -> PASS * igt@pm_rpm@debugfs-read: - shard-skl: INCOMPLETE [fdo#107807] -> PASS Warnings * igt@gem_cpu_reloc@full: - shard-skl: INCOMPLETE [fdo#108248] -> TIMEOUT [fdo#108248] [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103257]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: drop DPF code for gen8+
== Series Details == Series: drm/i915: drop DPF code for gen8+ URL : https://patchwork.freedesktop.org/series/54963/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11269_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11269_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] +1 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-rte: - shard-glk: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-blt: - shard-apl: SKIP -> INCOMPLETE [fdo#103927] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-glk: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@pm_backlight@fade_with_suspend: - shard-skl: NOTRUN -> FAIL [fdo#107847] Possible fixes * igt@kms_busy@extended-pageflip-hang-newfb-render-a: - shard-apl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS +1 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-glk: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +3 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS +1 * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: FAIL [fdo#103184] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack: - shard-glk: FAIL [fdo#103167] -> PASS * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-apl: FAIL [fdo#103166] -> PASS * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: DMESG-FAIL [fdo#108950] -> PASS - shard-glk: DMESG-FAIL [fdo#105763] / [fdo#106538] -> PASS Warnings * igt@gem_cpu_reloc@full: - shard-skl: INCOMPLETE [fdo#108248] -> TIMEOUT [fdo#108248] [fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782 [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 [fdo#105682]: https://bugs.freedesktop.org/show_bug.cgi?id=105682 [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763 [fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510 [fdo#106538]: https://bugs.freedesktop.org/show_bug.cgi?id=106538 [fdo#107847]: https://bugs.freedesktop.org/show_bug.cgi?id=107847 [fdo#107882]: https://bugs.freedesktop.org/show_bug.cgi?id=107882 [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956 [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#108248]: https://bugs.freedesktop.org/show_bug.cgi?id=108248 [fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950 Participating hosts (7 -> 6) -- Missing(1): shard-iclb Build changes - * Linux: CI_DRM_5386 -> Patchwork_11269 CI_DRM_5386: c7b430c73b52681e3b7206a53c0d5d6f8000ebe2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: init per-engine WAs for all engines
== Series Details == Series: drm/i915: init per-engine WAs for all engines URL : https://patchwork.freedesktop.org/series/54962/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11268_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11268_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11268_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_11268_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP -> PASS * igt@tools_test@tools_test: - shard-glk: PASS -> SKIP Known issues Here are the changes found in Patchwork_11268_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_crc@cursor-256x256-random: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-random: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@all-pipes-single-move: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-xtiled: - shard-skl: PASS -> FAIL [fdo#107791] * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-skl: PASS -> FAIL [fdo#108472] * igt@kms_flip@dpms-vs-vblank-race: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#105345] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] +2 * igt@kms_pipe_crc_basic@read-crc-pipe-a: - shard-skl: NOTRUN -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / [fdo#105079] / [fdo#105602] * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-glk: PASS -> FAIL [fdo#103166] +1 - shard-iclb: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-apl: PASS -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-none: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_scaling@pipe-a-scaler-with-rotation: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@pm_rpm@gem-mmap-gtt: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / [fdo#105602] +6 * igt@pm_rpm@i2c: - shard-iclb: NOTRUN -> FAIL [fdo#104097] Possible fixes * igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +16 * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-iclb: DMESG-WARN [fdo#107724] / [fdo#109225] -> PASS * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS * igt@kms_color@pipe-a-ctm-max: - shard-skl: FAIL [fdo#108147] -> PASS * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-glk: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: FAIL [fdo#103184] -> PASS * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: FAIL [fdo#108222] -> PASS * igt@kms_fbcon_fbt@fbc-suspend: - shard-iclb: DMESG-FAIL [fdo#105681] /
Re: [Intel-gfx] [PATCH] drm/i915/gvt: remove drmP.h include
On 2019.01.08 10:25:45 +0200, Jani Nikula wrote: > drmP.h is deprecated and no longer needed. > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/gvt/dmabuf.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c > b/drivers/gpu/drm/i915/gvt/dmabuf.c > index 51ed99a37803..2eb681175fae 100644 > --- a/drivers/gpu/drm/i915/gvt/dmabuf.c > +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c > @@ -29,7 +29,6 @@ > */ > > #include > -#include > #include > > #include "i915_drv.h" > -- Reviewed-by: Zhenyu Wang Thanks! Will apply later. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: give the cmd parser cmd_info a const treatment
Looks good to me.
Reviewed-by: Yan Zhao
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Jani Nikula
> Sent: Tuesday, January 8, 2019 10:12 PM
> To: intel-gvt-...@lists.freedesktop.org
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org;
> Wang,
> Zhi A ; zhen...@linux.intel.com
> Subject: [PATCH 2/2] drm/i915/gvt: give the cmd parser cmd_info a const
> treatment
>
> It doesn't need to be changed, make it const. The string literals should
> anyway
> be referred to as const data.
>
> The following gets moved to rodata section:
>
> 0080 l O .rodata 1c00 cmd_info
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 24
> drivers/gpu/drm/i915/gvt/trace.h | 2 +-
> 2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 98415d465a09..cae00e6debaf 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -375,7 +375,7 @@ typedef int (*parser_cmd_handler)(struct
> parser_exec_state *s); #define ADDR_FIX_5(x1, x2, x3, x4, x5)
> (ADDR_FIX_1(x1)
> | ADDR_FIX_4(x2, x3, x4, x5))
>
> struct cmd_info {
> - char *name;
> + const char *name;
> u32 opcode;
>
> #define F_LEN_MASK (1U<<0)
> @@ -425,7 +425,7 @@ struct cmd_info {
>
> struct cmd_entry {
> struct hlist_node hlist;
> - struct cmd_info *info;
> + const struct cmd_info *info;
> };
>
> enum {
> @@ -474,7 +474,7 @@ struct parser_exec_state {
> int saved_buf_addr_type;
> bool is_ctx_wa;
>
> - struct cmd_info *info;
> + const struct cmd_info *info;
>
> struct intel_vgpu_workload *workload;
> };
> @@ -625,7 +625,7 @@ static inline u32 get_opcode(u32 cmd, int ring_id)
> return cmd >> (32 - d_info->op_len);
> }
>
> -static inline struct cmd_info *find_cmd_entry(struct intel_gvt *gvt,
> +static inline const struct cmd_info *find_cmd_entry(struct intel_gvt
> +*gvt,
> unsigned int opcode, int ring_id)
> {
> struct cmd_entry *e;
> @@ -638,7 +638,7 @@ static inline struct cmd_info *find_cmd_entry(struct
> intel_gvt *gvt,
> return NULL;
> }
>
> -static inline struct cmd_info *get_cmd_info(struct intel_gvt *gvt,
> +static inline const struct cmd_info *get_cmd_info(struct intel_gvt
> +*gvt,
> u32 cmd, int ring_id)
> {
> u32 opcode;
> @@ -776,7 +776,7 @@ static inline int ip_gma_advance(struct
> parser_exec_state *s,
> return 0;
> }
>
> -static inline int get_cmd_length(struct cmd_info *info, u32 cmd)
> +static inline int get_cmd_length(const struct cmd_info *info, u32 cmd)
> {
> if ((info->flag & F_LEN_MASK) == F_LEN_CONST)
> return info->len;
> @@ -1643,7 +1643,7 @@ static int batch_buffer_needs_scan(struct
> parser_exec_state *s) static int find_bb_size(struct parser_exec_state *s,
> unsigned long *bb_size) {
> unsigned long gma = 0;
> - struct cmd_info *info;
> + const struct cmd_info *info;
> uint32_t cmd_len = 0;
> bool bb_end = false;
> struct intel_vgpu *vgpu = s->vgpu;
> @@ -1842,7 +1842,7 @@ static int cmd_handler_mi_batch_buffer_start(struct
> parser_exec_state *s)
>
> static int mi_noop_index;
>
> -static struct cmd_info cmd_info[] = {
> +static const struct cmd_info cmd_info[] = {
> {"MI_NOOP", OP_MI_NOOP, F_LEN_CONST, R_ALL, D_ALL, 0, 1, NULL},
>
> {"MI_SET_PREDICATE", OP_MI_SET_PREDICATE, F_LEN_CONST, R_ALL,
> D_ALL, @@ -2521,7 +2521,7 @@ static void add_cmd_entry(struct intel_gvt
> *gvt, struct cmd_entry *e) static int cmd_parser_exec(struct
> parser_exec_state
> *s) {
> struct intel_vgpu *vgpu = s->vgpu;
> - struct cmd_info *info;
> + const struct cmd_info *info;
> u32 cmd;
> int ret = 0;
>
> @@ -2895,10 +2895,10 @@ int intel_gvt_scan_and_shadow_wa_ctx(struct
> intel_shadow_wa_ctx *wa_ctx)
> return 0;
> }
>
> -static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt,
> +static const struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt
> +*gvt,
> unsigned int opcode, unsigned long rings) {
> - struct cmd_info *info = NULL;
> + const struct cmd_info *info = NULL;
> unsigned int ring;
>
> for_each_set_bit(ring, , I915_NUM_ENGINES) { @@ -2913,7
> +2913,7 @@ static int init_cmd_table(struct intel_gvt *gvt) {
> int i;
> struct cmd_entry *e;
> - struct cmd_info *info;
> + const struct cmd_info *info;
> unsigned int gen_type;
>
> gen_type = intel_gvt_get_device_type(gvt); diff --git
> a/drivers/gpu/drm/i915/gvt/trace.h b/drivers/gpu/drm/i915/gvt/trace.h
> index 1fd64202d74e..6d787750d279 100644
> --- a/drivers/gpu/drm/i915/gvt/trace.h
> +++ b/drivers/gpu/drm/i915/gvt/trace.h
> @@ -228,7 +228,7 @@ TRACE_EVENT(oos_sync,
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: give the cmd parser decode_info a const treatment
Looks good to me.
Reviewed-by: Yan Zhao
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Jani Nikula
> Sent: Tuesday, January 8, 2019 10:12 PM
> To: intel-gvt-...@lists.freedesktop.org
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org;
> Wang,
> Zhi A ; zhen...@linux.intel.com
> Subject: [PATCH 1/2] drm/i915/gvt: give the cmd parser decode_info a const
> treatment
>
> It doesn't need to be changed, make it const. The string literals should
> anyway
> be referred to as const data.
>
> The following gets moved to rodata section:
>
> 0410 l O .rodata 0018 decode_info_mi
> 0390 l O .rodata 0018
> decode_info_3d_media
> 03e0 l O .rodata 0018 decode_info_2d
> 0330 l O .rodata 0018
> decode_info_mfx_vc
> 02e0 l O .rodata 0018
> decode_info_vebox
> 0300 l O .rodata 0028 sub_op_vebox
> 0360 l O .rodata 0028 sub_op_mfx_vc
> 03c0 l O .rodata 0020 sub_op_3d_media
> 0400 l O .rodata 0010 sub_op_2d
> 0430 l O .rodata 0010 sub_op_mi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 30 +--
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 77ae634eb11c..98415d465a09 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -55,10 +55,10 @@ struct sub_op_bits {
> int low;
> };
> struct decode_info {
> - char *name;
> + const char *name;
> int op_len;
> int nr_sub_op;
> - struct sub_op_bits *sub_op;
> + const struct sub_op_bits *sub_op;
> };
>
> #define MAX_CMD_BUDGET 0x7fff
> @@ -485,12 +485,12 @@ struct parser_exec_state { static unsigned long
> bypass_scan_mask = 0;
>
> /* ring ALL, type = 0 */
> -static struct sub_op_bits sub_op_mi[] = {
> +static const struct sub_op_bits sub_op_mi[] = {
> {31, 29},
> {28, 23},
> };
>
> -static struct decode_info decode_info_mi = {
> +static const struct decode_info decode_info_mi = {
> "MI",
> OP_LEN_MI,
> ARRAY_SIZE(sub_op_mi),
> @@ -498,12 +498,12 @@ static struct decode_info decode_info_mi = { };
>
> /* ring RCS, command type 2 */
> -static struct sub_op_bits sub_op_2d[] = {
> +static const struct sub_op_bits sub_op_2d[] = {
> {31, 29},
> {28, 22},
> };
>
> -static struct decode_info decode_info_2d = {
> +static const struct decode_info decode_info_2d = {
> "2D",
> OP_LEN_2D,
> ARRAY_SIZE(sub_op_2d),
> @@ -511,14 +511,14 @@ static struct decode_info decode_info_2d = { };
>
> /* ring RCS, command type 3 */
> -static struct sub_op_bits sub_op_3d_media[] = {
> +static const struct sub_op_bits sub_op_3d_media[] = {
> {31, 29},
> {28, 27},
> {26, 24},
> {23, 16},
> };
>
> -static struct decode_info decode_info_3d_media = {
> +static const struct decode_info decode_info_3d_media = {
> "3D_Media",
> OP_LEN_3D_MEDIA,
> ARRAY_SIZE(sub_op_3d_media),
> @@ -526,7 +526,7 @@ static struct decode_info decode_info_3d_media = { };
>
> /* ring VCS, command type 3 */
> -static struct sub_op_bits sub_op_mfx_vc[] = {
> +static const struct sub_op_bits sub_op_mfx_vc[] = {
> {31, 29},
> {28, 27},
> {26, 24},
> @@ -534,7 +534,7 @@ static struct sub_op_bits sub_op_mfx_vc[] = {
> {20, 16},
> };
>
> -static struct decode_info decode_info_mfx_vc = {
> +static const struct decode_info decode_info_mfx_vc = {
> "MFX_VC",
> OP_LEN_MFX_VC,
> ARRAY_SIZE(sub_op_mfx_vc),
> @@ -542,7 +542,7 @@ static struct decode_info decode_info_mfx_vc = { };
>
> /* ring VECS, command type 3 */
> -static struct sub_op_bits sub_op_vebox[] = {
> +static const struct sub_op_bits sub_op_vebox[] = {
> {31, 29},
> {28, 27},
> {26, 24},
> @@ -550,14 +550,14 @@ static struct sub_op_bits sub_op_vebox[] = {
> {20, 16},
> };
>
> -static struct decode_info decode_info_vebox = {
> +static const struct decode_info decode_info_vebox = {
> "VEBOX",
> OP_LEN_VEBOX,
> ARRAY_SIZE(sub_op_vebox),
> sub_op_vebox,
> };
>
> -static struct decode_info *ring_decode_info[I915_NUM_ENGINES][8] = {
> +static const struct decode_info *ring_decode_info[I915_NUM_ENGINES][8]
> += {
> [RCS] = {
> _info_mi,
> NULL,
> @@ -616,7 +616,7 @@ static struct decode_info
> *ring_decode_info[I915_NUM_ENGINES][8] = {
>
> static inline u32 get_opcode(u32 cmd, int ring_id) {
> - struct decode_info *d_info;
> + const struct decode_info *d_info;
>
>
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Add PSR2 selective update status registers and bits definitions
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> This register contains how many blocks was sent in the past selective
> updates.
> Those registers are not kept set all the times but pulling it after
I suppose you mean 'polling'.
> flip
> can show that the expected values are set for the current frame and
> the
> previous ones too.
The values correspond to the last 8 frames actually.
>
> v2: Improved macros(Dhinakaran)
Reviewed-by: Dhinakaran Pandiyan
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 44958d994bfa..f9712d05314b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4272,6 +4272,15 @@ enum {
> #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> #define EDP_PSR2_STATUS_STATE_SHIFT28
>
> +#define _PSR2_SU_STATUS_00x6F914
> +#define _PSR2_SU_STATUS_10x6F918
> +#define _PSR2_SU_STATUS_20x6F91C
> +#define _PSR2_SU_STATUS(index) _MMIO(_PICK_EVEN((index
> ), _PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
> +#define PSR2_SU_STATUS(frame)(_PSR2_SU_STATUS((frame
> ) / 3))
> +#define PSR2_SU_STATUS_SHIFT(frame) (((frame) % 3) * 10)
> +#define PSR2_SU_STATUS_MASK(frame) (0x3ff <<
> PSR2_SU_STATUS_SHIFT(frame))
> +#define PSR2_SU_STATUS_FRAMES8
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/debugfs: Print PSR selective update status register values
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> The value of this registers will be used to test if PSR2 is doing
> selective update and if the number of blocks match with the expected.
>
> v2:
> - Using new macros
> - Changed the string output
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 32 +
>
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5ebf0e647ac7..4e92078bc65d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2621,10 +2621,34 @@ static int i915_edp_psr_status(struct
> seq_file *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> - seq_printf(m, "Last attempted entry at: %lld\n",
> -psr->last_entry_attempt);
> - seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> + if (!psr->psr2_enabled) {
> + if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + seq_printf(m, "Last attempted entry at:
> %lld\n",
> +psr->last_entry_attempt);
> + seq_printf(m, "Last exit at: %lld\n", psr-
> >last_exit);
> + }
> + } else {
> + u8 frame;
> +
> + seq_puts(m, "Frame:\tPSR2 SU blocks:\n");
> +
> + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame++)
> {
> + u32 su_blocks;
> +
> + /*
> + * Avoid register reads as each register
> contains more
> + * than one frame value
> + */
I don't think the comment is needed, but if you want to retain it I
suggest explicitly saying each register contains data for three frames?
Not sure if it matters, how about completing all the three register
reads before printing so that we reduce the chances of crossing a frame
boundary between register reads?
> + if ((frame % 3) == 0)
> + val = I915_READ(PSR2_SU_STATUS(frame));
> +
> + su_blocks = val & PSR2_SU_STATUS_MASK(frame);
> + su_blocks = su_blocks >>
> PSR2_SU_STATUS_SHIFT(frame);
> + /* Only printing frames with SU blocks */
> + if (!su_blocks)
> + continue;
Why not print zero if that's the number of blocks updated in a frame?
> + seq_printf(m, "%d\t%d\n", frame, su_blocks);
> + }
> }
>
> unlock:
___
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 [v2,1/2] drm/i915/selftests: recreate WA lists inside the selftest
== Series Details == Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists inside the selftest URL : https://patchwork.freedesktop.org/series/54967/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11271 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11271 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11271, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54967/revisions/1/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11271: ### IGT changes ### Warnings * igt@pm_rpm@basic-pci-d3-state: - fi-byt-n2820: PASS -> SKIP Known issues Here are the changes found in Patchwork_11271 that come from known issues: ### IGT changes ### Issues hit * igt@pm_rpm@basic-rte: - fi-byt-n2820: PASS -> FAIL [fdo#108800] [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 Participating hosts (48 -> 43) -- Additional (3): fi-byt-j1900 fi-hsw-peppy fi-apl-guc Missing(8): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-bsw-kefka fi-bdw-samus Build changes - * Linux: CI_DRM_5386 -> Patchwork_11271 CI_DRM_5386: c7b430c73b52681e3b7206a53c0d5d6f8000ebe2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11271: bfd4f560a38e4b9ac08c6b540b0f4a598d21d58c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bfd4f560a38e drm/i915: init per-engine WAs for all engines 389635e85573 drm/i915/selftests: recreate WA lists inside the selftest == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11271/ ___ 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: Fix the static code analysis warning in debugfs
== Series Details == Series: drm/i915: Fix the static code analysis warning in debugfs URL : https://patchwork.freedesktop.org/series/54961/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11267_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11267_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11267_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_11267_full: ### IGT changes ### Warnings * igt@kms_vblank@pipe-b-query-forked-busy-hang: - shard-snb: PASS -> SKIP * igt@pm_rpm@gem-mmap-gtt: - shard-kbl: PASS -> SKIP Known issues Here are the changes found in Patchwork_11267_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-b: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_cursor_crc@cursor-256x256-random: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-random: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-xtiled: - shard-skl: PASS -> FAIL [fdo#107791] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +6 * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-glk: PASS -> FAIL [fdo#103166] - shard-apl: PASS -> FAIL [fdo#103166] +4 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_scaling@pipe-a-scaler-with-rotation: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@pm_backlight@fade_with_suspend: - shard-skl: NOTRUN -> FAIL [fdo#107847] * igt@pm_rpm@i2c: - shard-iclb: NOTRUN -> FAIL [fdo#104097] * igt@pm_rpm@reg-read-ioctl: - shard-skl: PASS -> INCOMPLETE [fdo#107807] Possible fixes * igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +16 * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-iclb: DMESG-WARN [fdo#107724] / [fdo#109225] -> PASS * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-glk: DMESG-WARN [fdo#107956] -> PASS * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: FAIL [fdo#108682] -> PASS * igt@kms_color@pipe-a-ctm-max: - shard-skl: FAIL [fdo#108147] -> PASS * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS +1 * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +2 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS +1 * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: FAIL [fdo#103184] -> PASS * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS * igt@kms_fbcon_fbt@fbc-suspend: - shard-iclb: DMESG-FAIL [fdo#105681] / [fdo#107724] -> PASS * igt@kms_flip@busy-flip-interruptible: - shard-skl: FAIL [fdo#103257] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_flip@plain-flip-fb-recreate: - shard-iclb: FAIL -> PASS +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: FAIL [fdo#103167] -> PASS *
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/selftests: recreate WA lists inside the selftest
== Series Details == Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists inside the selftest URL : https://patchwork.freedesktop.org/series/54967/ State : warning == Summary == $ dim checkpatch origin/drm-tip 389635e85573 drm/i915/selftests: recreate WA lists inside the selftest -:289: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) #289: FILE: drivers/gpu/drm/i915/selftests/intel_workarounds.c:30: + memset(lists, 0 , sizeof(*lists)); ^ total: 1 errors, 0 warnings, 0 checks, 376 lines checked bfd4f560a38e drm/i915: init per-engine WAs for all engines ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: init per-engine WAs for all engines
commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
refactored the workaround code to have functions per-engine, but didn't
call any of them from logical_xcs_ring_init. Since we do have a non-RCS
workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
intel_engine_init_workarounds for non-RCS engines.
Note that whitelist is still RCS-only.
v2: move the call to logical_ring_init (Chris)
Fixes: 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e3b9bac24dd7..42e7f9216728 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2235,6 +2235,8 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
if (ret)
return ret;
+ intel_engine_init_workarounds(engine);
+
if (HAS_LOGICAL_RING_ELSQ(i915)) {
execlists->submit_reg = i915->regs +
i915_mmio_reg_offset(RING_EXECLIST_SQ_CONTENTS(engine));
@@ -2293,7 +2295,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
}
intel_engine_init_whitelist(engine);
- intel_engine_init_workarounds(engine);
return 0;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/selftests: recreate WA lists inside the selftest
By using the wa lists inside the live driver structures, we won't
catch issues where those are incorrectly setup or corrupted.
To cover this gap, update the workaround framework to allow saving the
wa lists to independent structures and use them in the selftests.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_workarounds.c | 117 +-
.../drm/i915/selftests/intel_workarounds.c| 69 +--
2 files changed, 119 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 480c53a2ecb5..3210ad4e08f7 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -639,10 +639,9 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32
val)
wa_write_masked_or(wal, reg, val, val);
}
-static void gen9_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+gen9_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct i915_wa_list *wal = >gt_wa_list;
-
/* WaDisableKillLogic:bxt,skl,kbl */
if (!IS_COFFEELAKE(i915))
wa_write_or(wal,
@@ -666,11 +665,10 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
BDW_DISABLE_HDC_INVALIDATION);
}
-static void skl_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+skl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct i915_wa_list *wal = >gt_wa_list;
-
- gen9_gt_workarounds_init(i915);
+ gen9_gt_workarounds_init(i915, wal);
/* WaDisableGafsUnitClkGating:skl */
wa_write_or(wal,
@@ -684,11 +682,10 @@ static void skl_gt_workarounds_init(struct
drm_i915_private *i915)
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
}
-static void bxt_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+bxt_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct i915_wa_list *wal = >gt_wa_list;
-
- gen9_gt_workarounds_init(i915);
+ gen9_gt_workarounds_init(i915, wal);
/* WaInPlaceDecompressionHang:bxt */
wa_write_or(wal,
@@ -696,11 +693,10 @@ static void bxt_gt_workarounds_init(struct
drm_i915_private *i915)
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
}
-static void kbl_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+kbl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct i915_wa_list *wal = >gt_wa_list;
-
- gen9_gt_workarounds_init(i915);
+ gen9_gt_workarounds_init(i915, wal);
/* WaDisableDynamicCreditSharing:kbl */
if (IS_KBL_REVID(i915, 0, KBL_REVID_B0))
@@ -719,16 +715,16 @@ static void kbl_gt_workarounds_init(struct
drm_i915_private *i915)
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
}
-static void glk_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+glk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- gen9_gt_workarounds_init(i915);
+ gen9_gt_workarounds_init(i915, wal);
}
-static void cfl_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+cfl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct i915_wa_list *wal = >gt_wa_list;
-
- gen9_gt_workarounds_init(i915);
+ gen9_gt_workarounds_init(i915, wal);
/* WaDisableGafsUnitClkGating:cfl */
wa_write_or(wal,
@@ -741,10 +737,10 @@ static void cfl_gt_workarounds_init(struct
drm_i915_private *i915)
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
}
-static void wa_init_mcr(struct drm_i915_private *dev_priv)
+static void
+wa_init_mcr(struct drm_i915_private *dev_priv, struct i915_wa_list *wal)
{
const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
- struct i915_wa_list *wal = _priv->gt_wa_list;
u32 mcr_slice_subslice_mask;
/*
@@ -804,11 +800,10 @@ static void wa_init_mcr(struct drm_i915_private *dev_priv)
intel_calculate_mcr_s_ss_select(dev_priv));
}
-static void cnl_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+cnl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct i915_wa_list *wal = >gt_wa_list;
-
- wa_init_mcr(i915);
+ wa_init_mcr(i915, wal);
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(i915, CNL_REVID_B0, CNL_REVID_B0))
@@ -822,11 +817,10 @@ static void cnl_gt_workarounds_init(struct
drm_i915_private *i915)
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
}
-static void icl_gt_workarounds_init(struct drm_i915_private *i915)
+static void
+icl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
- struct
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/psr: Do not print last attempted entry or exit in PSR debugfs while in PSR2
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> PSR2 only trigger interruptions for AUX error, so let's not print
> useless information in debugfs.
> Also adding a comment to intel_psr_irq_handler() about that.
>
Is it worth keeping this stuff for PSR1 if PSR2 is not supported, did
not work well enough for PSR1 IGTs either. In any case, are these
interrupts present on ICL?
> v2: Warning and not letting user set PSR_DEBUG_IRQ when PSR2 is
> enabled(Dhinakaran)
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
> drivers/gpu/drm/i915/intel_psr.c| 1 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 77b097b50fd5..5ebf0e647ac7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2621,7 +2621,7 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
Is there a case where PSR2 and IRQ debug are enabled now that you
disallow setting of this value?
> seq_printf(m, "Last attempted entry at: %lld\n",
> psr->last_entry_attempt);
> seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> @@ -2676,6 +2676,10 @@ i915_edp_psr_debug_set(void *data, u64 val)
> skip_mode:
> if (!ret) {
> mutex_lock(_priv->psr.lock);
> + if (dev_priv->psr.psr2_enabled && (val &
> I915_PSR_DEBUG_IRQ)) {
> + val &= ~I915_PSR_DEBUG_IRQ;
> + DRM_WARN("PSR debug IRQ cannot be enabled with
> PSR2");
WARN is inconsistent with DEBUG level logging that this function
already uses.
> + }
> dev_priv->psr.debug = val;
> intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
We are accessing hardware outside of rpm_get()/rpm_put() here.
> mutex_unlock(_priv->psr.lock);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index bba4f7da68b3..a875546880fa 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -201,6 +201,7 @@ void intel_psr_irq_handler(struct
> drm_i915_private *dev_priv, u32 psr_iir)
> mask |= EDP_PSR_ERROR(shift);
> }
>
> + /* PSR2 don't trigger PRE_ENTRY and POST_EXIT
> interruptions */
> if (psr_iir & EDP_PSR_PRE_ENTRY(shift)) {
> dev_priv->psr.last_entry_attempt = time_ns;
> DRM_DEBUG_KMS("[transcoder %s] PSR entry
> attempt in 2 vblanks\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/46] drm/i915: Syntatic sugar for using intel_runtime_pm
On 1/9/2019 16:24, John Harrison wrote: On 1/7/2019 03:54, Chris Wilson wrote: Frequently, we use intel_runtime_pm_get/_put around a small block. Formalise that usage by providing a macro to define such a block with an automatic closure to scope the intel_runtime_pm wakeref to that block, i.e. macro abuse smelling of python. Signed-off-by: Chris Wilson Cc: Jani Nikula --- +#define with_intel_runtime_pm(i915, wf) \ + for (wf = intel_runtime_pm_get(i915); wf; \ + intel_runtime_pm_put(i915, wf), wf = 0) + +#define with_intel_runtime_pm_if_in_use(i915, wf) \ + for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \ + intel_runtime_pm_put(i915, wf), wf = 0) + This is a potential change in behaviour. Previously the simple 'get' version would unconditionally execute the wrapped code. Whereas now, if the get function fails for some reason and returns zero, the wrapped code will be skipped. Currently, the get() function can't return zero - it returns -1 in the case of the tracking code failing to allocate or similar. But is that guaranteed to be the case forevermore? It would be a better match for the original behaviour if the 'for' loop of the 'get' version was unconditional and only the 'get_if_in_use' version could skip. E.g. something like: for (intel_wakeref_t loop = -1, wf = intel_runtime_pm_get(i915) ; loop; intel_runtime_pm_put(i915, wf), wf = loop = 0) Although that does mean the wf becomes local to the loop. On the other hand, I'm also not sure why it needs to be external anyway? If it is guaranteed to be zero on exit and any value on entry is overwritten, then why have it external at all? Would it not be neater/smaller source to get rid of all the local instantiations? John. Doh. Not sure why I was thinking C99 extensions were valid in the kernel. I can't think of an alternative way to fix the above issues without making the macro truly hideous. So maybe it's not enough of a worry to worry about. John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/46] drm/i915: Markup paired operations on display power domains
On 1/7/2019 03:54, Chris Wilson wrote:
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b0cbad2e83c5..faff6cf1aaa1 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1364,14 +1364,14 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
free_oa_buffer(dev_priv);
- put_oa_config(dev_priv, stream->oa_config);
-
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
intel_runtime_pm_put(dev_priv, stream->wakeref);
if (stream->ctx)
oa_put_render_ctx_id(stream);
+ put_oa_config(dev_priv, stream->oa_config);
+
if (dev_priv->perf.oa.spurious_report_rs.missed) {
DRM_NOTE("%d spurious OA report notices suppressed due to
ratelimiting\n",
dev_priv->perf.oa.spurious_report_rs.missed);
Is this not reversing a change from patch 9/46? Is there a reason why
the oa_config scope needs to change temporarily for some of the series?
Or can this diff be folded down and optimised out of both patches?
John.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/46] drm/i915: Syntatic sugar for using intel_runtime_pm
On 1/7/2019 03:54, Chris Wilson wrote: Frequently, we use intel_runtime_pm_get/_put around a small block. Formalise that usage by providing a macro to define such a block with an automatic closure to scope the intel_runtime_pm wakeref to that block, i.e. macro abuse smelling of python. Signed-off-by: Chris Wilson Cc: Jani Nikula --- +#define with_intel_runtime_pm(i915, wf) \ + for (wf = intel_runtime_pm_get(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) + +#define with_intel_runtime_pm_if_in_use(i915, wf) \ + for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) + This is a potential change in behaviour. Previously the simple 'get' version would unconditionally execute the wrapped code. Whereas now, if the get function fails for some reason and returns zero, the wrapped code will be skipped. Currently, the get() function can't return zero - it returns -1 in the case of the tracking code failing to allocate or similar. But is that guaranteed to be the case forevermore? It would be a better match for the original behaviour if the 'for' loop of the 'get' version was unconditional and only the 'get_if_in_use' version could skip. E.g. something like: for (intel_wakeref_t loop = -1, wf = intel_runtime_pm_get(i915) ; loop; intel_runtime_pm_put(i915, wf), wf = loop = 0) Although that does mean the wf becomes local to the loop. On the other hand, I'm also not sure why it needs to be external anyway? If it is guaranteed to be zero on exit and any value on entry is overwritten, then why have it external at all? Would it not be neater/smaller source to get rid of all the local instantiations? John. ___ 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: Reduce i915_request_alloc retirement to local context (rev3)
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev3)
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11270
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11270 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11270, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54820/revisions/3/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11270:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11270 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
Participating hosts (48 -> 43)
--
Additional (3): fi-byt-j1900 fi-hsw-peppy fi-apl-guc
Missing(8): fi-kbl-soraka fi-hsw-4770r fi-ilk-m540 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5386 -> Patchwork_11270
CI_DRM_5386: c7b430c73b52681e3b7206a53c0d5d6f8000ebe2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11270: 4f7a98cdc73cfd43d7bf1284098bdf096e9be7d4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4f7a98cdc73c drm/i915: Reduce i915_request_alloc retirement to local context
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11270/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drop DPF code for gen8+
== Series Details == Series: drm/i915: drop DPF code for gen8+ URL : https://patchwork.freedesktop.org/series/54963/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11269 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/54963/revisions/1/ Known issues Here are the changes found in Patchwork_11269 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: FAIL [fdo#108767] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 Participating hosts (48 -> 45) -- Additional (3): fi-byt-j1900 fi-hsw-peppy fi-apl-guc Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5386 -> Patchwork_11269 CI_DRM_5386: c7b430c73b52681e3b7206a53c0d5d6f8000ebe2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11269: 2c8a6b082174565367683bea9dba5744803e64a0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2c8a6b082174 drm/i915: drop DPF code for gen8+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11269/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/46] drm/i915/gem: Track the rpm wakerefs
On 1/9/2019 03:16, Mika Kuoppala wrote:
Chris Wilson writes:
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 16693dd4d019..bc230e43b98f 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -154,6 +154,7 @@ i915_gem_shrink(struct drm_i915_private *i915,
{ >mm.bound_list, I915_SHRINK_BOUND },
{ NULL, 0 },
}, *phase;
+ intel_wakeref_t wakeref = 0;
unsigned long count = 0;
unsigned long scanned = 0;
bool unlock;
@@ -183,9 +184,11 @@ i915_gem_shrink(struct drm_i915_private *i915,
* device just to recover a little memory. If absolutely necessary,
* we will force the wake during oom-notifier.
*/
- if ((flags & I915_SHRINK_BOUND) &&
- !intel_runtime_pm_get_if_in_use(i915))
- flags &= ~I915_SHRINK_BOUND;
+ if (flags & I915_SHRINK_BOUND) {
+ wakeref = intel_runtime_pm_get_if_in_use(i915);
+ if (!wakeref)
+ flags &= ~I915_SHRINK_BOUND;
+ }
/*
* As we may completely rewrite the (un)bound list whilst unbinding
@@ -266,7 +269,7 @@ i915_gem_shrink(struct drm_i915_private *i915,
}
if (flags & I915_SHRINK_BOUND)
- intel_runtime_pm_put_unchecked(i915);
+ intel_runtime_pm_put(i915, wakeref);
This is ok but raises a question that did we have
GEM_BUG_ON(wakeref == 0) on pm_put? Perhaps not needed
per se as we do find that we don't have ref for 0.
Reviewed-by: Mika Kuoppala
There is a WARN not a BUG if pm_put() is called with a zero wakeref (in
the cancel_ function after the search fails to find a match with zero).
However, the flag checks mean that it can't happen from here.
John.
___
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: Reduce i915_request_alloc retirement to local context (rev3)
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev3)
URL : https://patchwork.freedesktop.org/series/54820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4f7a98cdc73c drm/i915: Reduce i915_request_alloc retirement to local context
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 11abf0c5a021 ("drm/i915: Limit
the backpressure for i915_request allocation")'
#15:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
total: 1 errors, 1 warnings, 0 checks, 73 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/46] drm/i915: Markup paired operations on wakerefs
On 1/9/2019 03:51, Chris Wilson wrote:
Quoting Mika Kuoppala (2019-01-09 09:23:53)
I should have been more specific. My concern was on documenting
the changing return values.
The interface isn't documented, there's nothing in the header about the
functions? Where else would it be?
I think Mika's point is that you now have inaccurate comments at the
start of the _get functions:
@@ -4207,7 +4256,7 @@ void intel_runtime_pm_get(struct drm_i915_private *i915)
*
* Returns: True if the wakeref was acquired, or False otherwise.
^^
*/
-bool intel_runtime_pm_get_if_in_use(struct drm_i915_private *i915)
+intel_wakeref_t intel_runtime_pm_get_if_in_use(struct drm_i915_private *i915)
{
The comment says 'returns: true ... or false' but should actually say 'returns:
an intel_wakeref_t if the wakeref was acquired or zero otherwise'. With the
assumption that zero is guaranteed to be an invalid value for an
intel_wakeref_t.
The other _get functions were previously void but also now return a wakeref_t.
Hence, they should have their comments updated too.
John.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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: init per-engine WAs for all engines
== Series Details ==
Series: drm/i915: init per-engine WAs for all engines
URL : https://patchwork.freedesktop.org/series/54962/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11268
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11268 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11268, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54962/revisions/1/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11268:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11268 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> DMESG-WARN [fdo#108622]
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: NOTRUN -> FAIL [fdo#108800]
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
{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#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
Participating hosts (48 -> 45)
--
Additional (3): fi-byt-j1900 fi-hsw-peppy fi-apl-guc
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5386 -> Patchwork_11268
CI_DRM_5386: c7b430c73b52681e3b7206a53c0d5d6f8000ebe2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11268: 882ca3492ebaaa93b82df09cc515710d578c59e2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
882ca3492eba drm/i915: init per-engine WAs for all engines
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11268/
___
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: Fix the static code analysis warning in debugfs
== Series Details == Series: drm/i915: Fix the static code analysis warning in debugfs URL : https://patchwork.freedesktop.org/series/54961/ State : success == Summary == CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11267 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11267 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11267, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54961/revisions/1/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11267: ### IGT changes ### Warnings * igt@pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: SKIP -> PASS Known issues Here are the changes found in Patchwork_11267 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1 * igt@pm_rpm@basic-rte: - fi-byt-j1900: NOTRUN -> FAIL [fdo#108800] Possible fixes * igt@pm_rpm@basic-rte: - fi-bsw-kefka: FAIL [fdo#108800] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 Participating hosts (48 -> 45) -- Additional (3): fi-byt-j1900 fi-hsw-peppy fi-apl-guc Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5386 -> Patchwork_11267 CI_DRM_5386: c7b430c73b52681e3b7206a53c0d5d6f8000ebe2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11267: 9e929310d7a85e6f89ad10e88659e6ef00f0c87f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9e929310d7a8 drm/i915: Fix the static code analysis warning in debugfs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11267/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Refactor PSR status debugfs
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> The old debugfs fields was not following a naming partern and it was
> a bit confusing.
>
> So it went from:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> PSR mode: PSR1
> Enabled: yes
> Busy frontbuffer bits: 0x000
> Main link in standby mode: no
> HW Enabled & Active bit: yes
> Source PSR status: 0x24050006 [SRDONACK]
>
> To:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink support: yes [0x03]
> PSR mode: PSR1 enabled
> Source PSR ctl: enabled [0x81f00e26]
> Source PSR status: IDLE [0x04010006]
> Busy frontbuffer bits: 0x
>
> The 'Main link in standby mode' was removed as it is not useful but
> if needed by someone the information is still in the register value
> of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled was
> squashed into PSR mode, some renames and reorders and we have this
> cleaner version. This will also make easy to parse debugfs for IGT
> tests.
>
> v2: Printing sink PSR version with only 2 hex digits as it is a byte
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Suggested-by: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 95 ++-
> --
> 1 file changed, 47 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 193823048f96..1a31921598e7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2529,7 +2529,8 @@ DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
> static void
> psr_source_status(struct drm_i915_private *dev_priv, struct seq_file
> *m)
> {
> - u32 val, psr_status;
> + u32 val, status_val;
> + const char *status = "unknown";
>
> if (dev_priv->psr.psr2_enabled) {
> static const char * const live_status[] = {
> @@ -2545,14 +2546,11 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "BUF_ON",
> "TG_ON"
> };
> - psr_status = I915_READ(EDP_PSR2_STATUS);
> - val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
> - EDP_PSR2_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR2_STATUS);
> + status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> } else {
> static const char * const live_status[] = {
> "IDLE",
> @@ -2564,74 +2562,75 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "SRDOFFACK",
> "SRDENT_ON",
> };
> - psr_status = I915_READ(EDP_PSR_STATUS);
> - val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
> - EDP_PSR_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR_STATUS);
> + status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
> + EDP_PSR_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> }
>
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n", psr_status,
> "unknown");
> + seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
> }
>
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - u32 psrperf = 0;
> - bool enabled = false;
> - bool sink_support;
> + struct i915_psr *psr = _priv->psr;
> + const char *status;
> + bool enabled;
> + u32 val;
>
> if (!HAS_PSR(dev_priv))
> return -ENODEV;
>
> - sink_support = dev_priv->psr.sink_support;
> - seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> - if (!sink_support)
> + seq_printf(m, "Sink support: %s", yesno(psr->sink_support));
> + seq_printf(m, " [0x%02x]\n", psr->dp->psr_dpcd[0]);
> + if (!psr->sink_support)
> return 0;
>
> intel_runtime_pm_get(dev_priv);
> + mutex_lock(>lock);
>
> - mutex_lock(_priv->psr.lock);
> - seq_printf(m, "PSR mode: %s\n",
> -dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1");
> -
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/psr: Allow PSR2 to be enabled when debugfs asks
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> For now PSR2 is still disabled by default for all platforms but is
> our intention to let debugfs to enable it for debug and tests
> proporses, so intel_psr2_enabled() that is also used by debugfs to
> decide if PSR2 is going to be enabled needs to take in consideration
> the debug field.
>
> v2: Using the switch/case that intel_psr2_enabled() already had to
> handle this(DK)
Reviewed-by: Dhinakaran Pandiyan
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index dce39f06b682..0ef6c5f8c298 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -71,17 +71,17 @@ static bool psr_global_enabled(u32 debug)
> static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> const struct intel_crtc_state
> *crtc_state)
> {
> - /* Disable PSR2 by default for all platforms */
> - if (i915_modparams.enable_psr == -1)
> - return false;
> -
> /* Cannot enable DSC and PSR2 simultaneously */
> WARN_ON(crtc_state->dsc_params.compression_enable &&
> crtc_state->has_psr2);
>
> switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
> + case I915_PSR_DEBUG_DISABLE:
> case I915_PSR_DEBUG_FORCE_PSR1:
> return false;
> + case I915_PSR_DEBUG_DEFAULT:
> + if (i915_modparams.enable_psr <= 0)
> + return false;
> default:
> return crtc_state->has_psr2;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Reduce i915_request_alloc retirement to local context
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
v2: Don't forget the list iteration included an early break, so we would
never throttle on the last request in the ring/timeline.
v3: Use the common ring_retire_requests()
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 55 +
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..d1355154886a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,38 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static void ring_retire_requests(struct intel_ring *ring)
+{
+ struct i915_request *rq, *rn;
+
+ list_for_each_entry_safe(rq, rn, >request_list, ring_link) {
+ if (!i915_request_completed(rq))
+ break;
+
+ i915_request_retire(rq);
+ }
+}
+
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq;
+
+ if (list_empty(>request_list))
+ goto out;
+
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ rq = list_last_entry(>request_list, typeof(*rq), ring_link);
+ cond_synchronize_rcu(rq->rcustate);
+
+ /* Retire our old requests in the hope that we free some */
+ ring_retire_requests(ring);
+
+out:
+ return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -559,15 +591,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
- i915_retire_requests(i915);
-
- /* Ratelimit ourselves to prevent oom from malicious clients */
- rq = i915_gem_active_raw(>ring->timeline->last_request,
->drm.struct_mutex);
- if (rq)
- cond_synchronize_rcu(rq->rcustate);
-
- rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
+ rq = i915_request_alloc_slow(ce);
if (!rq) {
ret = -ENOMEM;
goto err_unreserve;
@@ -1218,19 +1242,6 @@ long i915_request_wait(struct i915_request *rq,
return timeout;
}
-static void ring_retire_requests(struct intel_ring *ring)
-{
- struct i915_request *request, *next;
-
- list_for_each_entry_safe(request, next,
->request_list, ring_link) {
- if (!i915_request_completed(request))
- break;
-
- i915_request_retire(request);
- }
-}
-
void i915_retire_requests(struct drm_i915_private *i915)
{
struct intel_ring *ring, *tmp;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: init per-engine WAs for all engines
Quoting Chris Wilson (2019-01-09 21:48:29)
> Quoting Daniele Ceraolo Spurio (2019-01-09 21:30:38)
> > commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> > refactored the workaround code to have functions per-engine, but didn't
> > call any of them from logical_xcs_ring_init. Since we do have a non-RCS
> > workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
> > intel_engine_init_workarounds for non-RCS engines.
> > Note that whitelist is still RCS-only.
>
> Yeah, the danger is that our selftests are only as good as the code to
> setup the workaround lists. Hmm, really that code shouldn't be using the
> wa_list built into the engine, but building them itself to double check
> against such failures or corruption.
Fwiw, I think we should first create a patch for the selftests to detect
the missing initialisation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: init per-engine WAs for all engines
Quoting Daniele Ceraolo Spurio (2019-01-09 21:30:38)
> commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> refactored the workaround code to have functions per-engine, but didn't
> call any of them from logical_xcs_ring_init. Since we do have a non-RCS
> workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
> intel_engine_init_workarounds for non-RCS engines.
> Note that whitelist is still RCS-only.
Yeah, the danger is that our selftests are only as good as the code to
setup the workaround lists. Hmm, really that code shouldn't be using the
wa_list built into the engine, but building them itself to double check
against such failures or corruption.
I would push intel_engine_init_workarounds() to logical_ring init (after
intel_engine_init_common()?) and then remove the redundant call from
rcs_init. Is it worth doing the same for init_whitelist... Not so sure,
since the RCS nature of that whitelist is an intrinsic property that we
should be aware of (so less desire for automagical init).
Similar argument is that my intention is for the same code to be used to
setup the legacy ringbuffer workarounds, and so should we look at doing
the init as part of intel_engine_init_common() itself?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop DPF code for gen8+
Quoting Daniele Ceraolo Spurio (2019-01-09 21:31:47) > The only gen8+ platform that has the feature is BDW, but we don't define > the feature flag on any BDW platform and we only have partial support in > the gen8 path (irq enabling code, but no handler). > The only thing we could do in the irq handler is report the error > to userspace, but no one asked/cared about that since BDW was > released so it is relatively safe to assume that even if we added the > message no one would look at it. Just drop the dead code from the > driver instead. > > Signed-off-by: Daniele Ceraolo Spurio I'm not volunteering myself to add support, and should anyone be the code removed here would be trivial to reimplement and a mere fraction of the code required. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: drop DPF code for gen8+
The only gen8+ platform that has the feature is BDW, but we don't define
the feature flag on any BDW platform and we only have partial support in
the gen8 path (irq enabling code, but no handler).
The only thing we could do in the irq handler is report the error
to userspace, but no one asked/cared about that since BDW was
released so it is relatively safe to assume that even if we added the
message no one would look at it. Just drop the dead code from the
driver instead.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_irq.c | 3 ---
drivers/gpu/drm/i915/intel_lrc.c | 4
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fbb094ecf6c9..1f5d756c76cf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4173,9 +4173,6 @@ static void gen8_gt_irq_postinstall(struct
drm_i915_private *dev_priv)
GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VECS_IRQ_SHIFT
};
- if (HAS_L3_DPF(dev_priv))
- gt_interrupts[0] |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
-
dev_priv->pm_ier = 0x0;
dev_priv->pm_imr = ~dev_priv->pm_ier;
GEN8_IRQ_INIT_NDX(GT, 0, ~gt_interrupts[0], gt_interrupts[0]);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 13c6c579ec7a..f5fa8242caaa 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2267,14 +2267,10 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
int logical_render_ring_init(struct intel_engine_cs *engine)
{
- struct drm_i915_private *dev_priv = engine->i915;
int ret;
logical_ring_setup(engine);
- if (HAS_L3_DPF(dev_priv))
- engine->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
-
/* Override some for render ring. */
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: init per-engine WAs for all engines
commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
refactored the workaround code to have functions per-engine, but didn't
call any of them from logical_xcs_ring_init. Since we do have a non-RCS
workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
intel_engine_init_workarounds for non-RCS engines.
Note that whitelist is still RCS-only.
Fixes: 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_lrc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6c98fb7cebf2..13c6c579ec7a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2304,9 +2304,17 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
int logical_xcs_ring_init(struct intel_engine_cs *engine)
{
+ int ret;
+
logical_ring_setup(engine);
- return logical_ring_init(engine);
+ ret = logical_ring_init(engine);
+ if (ret)
+ return ret;
+
+ intel_engine_init_workarounds(engine);
+
+ return 0;
}
static u32
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the static code analysis warning in debugfs
On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote: > intel_dp->dsc_dpcd is defined as an array making the if check redundant. > Yes I agree, I guess when I added that if check it was anot an array to begin with and then forgot to take it off. Looks good to me. Reviewed-by: Manasi Navare Manasi > Cc: Rodrigo Vivi > Signed-off-by: Radhakrishna Sripada > --- > drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 95813e21ae02..908e41f9cb7d 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -4958,9 +4958,8 @@ static int i915_dsc_fec_support_show(struct seq_file > *m, void *data) > crtc_state = to_intel_crtc_state(crtc->state); > seq_printf(m, "DSC_Enabled: %s\n", > yesno(crtc_state->dsc_params.compression_enable)); > - if (intel_dp->dsc_dpcd) > - seq_printf(m, "DSC_Sink_Support: %s\n", > - > yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); > + seq_printf(m, "DSC_Sink_Support: %s\n", > +yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); > if (!intel_dp_is_edp(intel_dp)) > seq_printf(m, "FEC_Sink_Support: %s\n", > > yesno(drm_dp_sink_supports_fec(intel_dp->fec_capable))); > -- > 2.20.0.rc2.7.g965798d1f299 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix the static code analysis warning in debugfs
intel_dp->dsc_dpcd is defined as an array making the if check redundant. Cc: Rodrigo Vivi Signed-off-by: Radhakrishna Sripada --- drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 95813e21ae02..908e41f9cb7d 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4958,9 +4958,8 @@ static int i915_dsc_fec_support_show(struct seq_file *m, void *data) crtc_state = to_intel_crtc_state(crtc->state); seq_printf(m, "DSC_Enabled: %s\n", yesno(crtc_state->dsc_params.compression_enable)); - if (intel_dp->dsc_dpcd) - seq_printf(m, "DSC_Sink_Support: %s\n", - yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); + seq_printf(m, "DSC_Sink_Support: %s\n", + yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); if (!intel_dp_is_edp(intel_dp)) seq_printf(m, "FEC_Sink_Support: %s\n", yesno(drm_dp_sink_supports_fec(intel_dp->fec_capable))); -- 2.20.0.rc2.7.g965798d1f299 ___ 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: Reduce recursive mutex locking from the shrinker
Quoting Tvrtko Ursulin (2019-01-09 14:12:46) > From: Tvrtko Ursulin > > In two codepaths internal to the shrinker we know we will end up taking > the resursive mutex path. > > It instead feels more elegant to avoid this altogether and not call > mutex_trylock_recursive in those cases. > > We achieve this by extracting the shrinking part to __i915_gem_shrink, > wrapped by struct mutex taking i915_gem_shrink. > > At the same time move the runtime pm reference taking to always be in the > usual, before struct mutex, order. > > v2: > * Don't use flags but split i915_gem_shrink into locked and unlocked. Yes, I do prefer this to passing flags down, but I feel very underwhelmed by it. The fact that the recursive lock exists is the problem and this isn't reducing the problem (imo). I'd rather push the only call to shrinker_lock down to i915_gem_shrink and remove it from shrinker_scan and shrinker_vmap which should be doable in a few patches -- that would get rid of the self-inflicted recursion but still recursing from our callers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
Looks good to me.
> -Original Message-
> From: Souza, Jose
> Sent: Friday, January 4, 2019 9:37 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Oscar Mateo ; Sripada, Radhakrishna
> ; Souza, Jose
> Subject: [PATCH] drm/i915/icl: Apply
> WaEnablePreemptionGranularityControlByUMD
>
> According to Workaround database ICL also needs
> WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> fine-granularity preemptions per-context.
>
> BSpec: 11348
> Cc: Oscar Mateo
> Cc: Radhakrishna Sripada
> Signed-off-by: José Roberto de Souza
Reviewed-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 480c53a2ecb5..bbc5a66faa07 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct i915_wa_list
> *w)
> /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
>
> - /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
> + /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl]
> +*/
> whitelist_reg(w, GEN8_CS_CHICKEN1);
>
> /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */ @@ -
> 1068,6 +1068,9 @@ static void icl_whitelist_build(struct i915_wa_list *w)
>
> /* WaAllowUMDToModifySamplerMode:icl */
> whitelist_reg(w, GEN10_SAMPLER_MODE);
> +
> + /* WaEnablePreemptionGranularityControlByUMD:icl */
> + whitelist_reg(w, GEN8_CS_CHICKEN1);
> }
>
> void intel_engine_init_whitelist(struct intel_engine_cs *engine) @@ -1186,8
> +1189,8 @@ static void rcs_engine_wa_init(struct intel_engine_cs *engine)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> - /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> + if (IS_GEN_RANGE(i915, 9, 11)) {
> + /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl
> +*/
> wa_masked_en(wal,
>GEN7_FF_SLICE_CS_CHICKEN1,
>GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: simplify enable_psr handling
== Series Details == Series: drm/i915/psr: simplify enable_psr handling URL : https://patchwork.freedesktop.org/series/54959/ State : failure == Summary == Applying: drm/i915/psr: simplify enable_psr handling Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_params.c M drivers/gpu/drm/i915/i915_params.h M drivers/gpu/drm/i915/intel_bios.c M drivers/gpu/drm/i915/intel_psr.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_psr.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_psr.c Auto-merging drivers/gpu/drm/i915/intel_bios.c Auto-merging drivers/gpu/drm/i915/i915_params.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_params.h Auto-merging drivers/gpu/drm/i915/i915_params.c Auto-merging drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/psr: simplify enable_psr handling 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] Linux-4.18.20 fail to boot on old intel gfx card
On Tue, Dec 25, 2018 at 02:24:36PM +, ? ? wrote: > Package: Linux-image-amd64 > Version: 4.18+100~bpo9+1 > > Linux-4.18.20 fail to boot on old intel gfx card. > I also tried a fresh installed Debian testing with same kernel version, > still can't boot, even to command line interface. > > after blacklisting i915, Debian testing can boot to command line > interface. but when I tried to modprobe i915, screen blanks, shows > nothing. > > while Linux-4.18.6 is good to boot to UI. Sounds like this: https://bugs.freedesktop.org/show_bug.cgi?id=108850 Unfortunately 4.18 is EOL so the fix will never get backported. You'll need to upgrade to a more recent kernel. > > here is my hardware information: > Machine: Thinkpad X200 > output of lspci for gfx card: > > 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series > Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: > Lenovo Mobile 4 Series Chipset Integrated Graphics Controller > [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- > FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- INTx- Latency: 0 Region 0: Memory at f240 (64-bit, > non-prefetchable) [size=1M] Capabilities: > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip
I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
chipset) and hit some kernel panics while trying to view
image/animation-intensive stuff in Firefox (X11) unless I use
"iommu_intel=igfx_off".
With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
(4.17.17-1~bpo9+1) has no problems. But "linux-image-4.18.0-0.bpo.3-amd64"
(4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
and run startx.
Building 4.19.12 myself got me into X11 and able to start
Firefox to panic the kernel. I also updated to the latest BIOS
(1.40), but it's an EOL laptop (but it's still the most powerful
laptop I use). I intend to replace the BIOS with Coreboot soon...
Initially, I thought I was hitting another GPU hang from 4.18+:
https://bugs.freedesktop.org/show_bug.cgi?id=107945
But building drm-tip @ commit 28bb1fc015cedadf3b099b8bd0bb27609849f362
("drm-tip: 2018y-12m-25d-08h-12m-37s UTC integration manifest")
I was still able to reproduce the panic unless I use iommu_intel=igfx_off
"i915.reset=1" did not help matters, either.
Below is what I got from netconsole while on drm-tip:
Kernel panic - not syncing: DMAR hardware is malfunctioning
Shutting down cpus with NMI
Kernel Offset: disabled
---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#3!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel
aes_x86_64 crypto_simd cryptd mac80211 glue_helper intel_cstate iwlwifi
intel_uncore i915 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper cfbfillrect
syscopyarea intel_ips cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea
thinkpad_acpi prime_numbers cfg80211 ledtrig_audio i2c_i801 sg snd_hda_intel
led_class snd_hda_codec drm ac drm_panel_orientation_quirks snd_hwdep battery
e1000e agpgart snd_hda_core snd_pcm snd_timer ptp snd soundcore pps_core
ehci_pci ehci_hcd lpc_ich video mfd_core button acpi_cpufreq ecryptfs ip_tables
x_tables ipv6 evdev thermal [last unloaded: netconsole]
CPU: 0 PID: 105 Comm: kworker/u8:3 Not tainted 4.20.0-rc7b1+ #1
Hardware name: LENOVO 3680FBU/3680FBU, BIOS 6QET70WW (1.40 ) 10/11/2012
Workqueue: i915 __i915_gem_free_work [i915]
RIP: 0010:native_smp_send_reschedule+0x34/0x40
Code: 05 69 c6 c9 00 73 15 48 8b 05 18 2d b3 00 be fd 00 00 00 48 8b 40 30 e9
9a 58 7d 00 89 fe 48 c7 c7 78 73 af 81 e8 dc c2 01 00 <0f> 0b c3 66 0f 1f 84 00
00 00 00 00 66 66 66 66 90 8b 05 0d 7d df
RSP: 0018:888075003d98 EFLAGS: 00010092
RAX: 002e RBX: 8880751a0740 RCX: 0006
RDX: 0007 RSI: 0082 RDI: 888075015440
RBP: 88806e823700 R08: R09: 888072fc07c0
R10: 888075003d60 R11: fff5c002 R12: 8880751a0740
R13: 8880751a0740 R14: R15: 0003
FS: () GS:88807500() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fdb1f53f000 CR3: 01c0a004 CR4: 000206f0
Call Trace:
? check_preempt_curr+0x4e/0x90
? ttwu_do_wakeup.isra.19+0x14/0xf0
? try_to_wake_up+0x323/0x410
? autoremove_wake_function+0xe/0x30
? __wake_up_common+0x8d/0x140
? __wake_up_common_lock+0x6c/0x90
? irq_work_run_list+0x49/0x80
? tick_sched_handle.isra.6+0x50/0x50
? update_process_times+0x3b/0x50
? tick_sched_handle.isra.6+0x30/0x50
? tick_sched_timer+0x3b/0x80
? __hrtimer_run_queues+0xea/0x270
? hrtimer_interrupt+0x101/0x240
? smp_apic_timer_interrupt+0x6a/0x150
? apic_timer_interrupt+0xf/0x20
? panic+0x1ca/0x212
? panic+0x1c7/0x212
? __iommu_flush_iotlb+0x19e/0x1c0
? iommu_flush_iotlb_psi+0x96/0xf0
? intel_unmap+0xbf/0xf0
? i915_gem_object_put_pages_gtt+0x36/0x220 [i915]
? drm_ht_remove+0x20/0x20 [drm]
? drm_mm_remove_node+0x1ad/0x310 [drm]
? __pm_runtime_resume+0x54/0x70
? __i915_gem_object_unset_pages+0x129/0x170 [i915]
? __i915_gem_object_put_pages+0x70/0xa0 [i915]
? __i915_gem_free_objects+0x245/0x4e0 [i915]
? __switch_to_asm+0x24/0x60
? __i915_gem_free_work+0x65/0xa0 [i915]
? process_one_work+0x1fd/0x410
? worker_thread+0x49/0x3f0
? kthread+0xf8/0x130
? process_one_work+0x410/0x410
? kthread_park+0x90/0x90
? ret_from_fork+0x35/0x40
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
---[ end trace 7dd2184d8c86cef5 ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#2!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel
aes_x86_64 crypto_simd cryptd mac80211
Re: [Intel-gfx] "flip_done timed out" messages causing huge increase in boot time
I should really get to bed ... of course, I meant 516a49cc19467e298d08a404f73a6e311f4548d1 ;-) On Sat, 5 Jan 2019 at 01:16, Daniel Kamil Kozar wrote: > > Small omission on my part : I meant 4.19.12, not 4.19.2 as the last > working version. > Also, I can confirm that reverting > 13947d150bae871bd880565ada318b0bcd0e690e from the current HEAD of > linux-stable fixes the issue. > > On Sat, 5 Jan 2019 at 00:47, Daniel Kamil Kozar wrote: > > > > Hello. > > After upgrading the kernel to 4.20, I noticed that the boot time > > increased from about 5 seconds to 25 seconds. My machine is an Asus > > K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external > > display connected to it via HDMI. If the display is unplugged when > > booting the machine, the boot time stays at its old value. > > The kernel log shows two messages like this : > > > > [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done > > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > > [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies > > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > > > > Which are the only ones that don't appear in 4.19.2, where the boot > > time was smaller. Bisecting the commits between these two versions > > leads to commit 516a49cc19467e298d08a404f73a6e311f4548d1. > > > > Let me know if you need more information. > > > > Kind regards, > > Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: simplify enable_psr handling
The following commit:
commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be enabled.")
added some code with no usable functionality. Regardless of how the psr
default is set up in the BDB_DRIVER_FEATURES section, if the enable_psr
module parameter isn't specified it defaults to 0.
Remove this dead code, simplify the way that enable_psr is handled and
update the module parameter string to match the actual functionality.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: Ross Zwisler
---
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/i915_params.c | 4 +---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 1 -
drivers/gpu/drm/i915/intel_psr.c | 7 ---
5 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 872a2e159a5f9..b4c50ba0b22a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1115,7 +1115,6 @@ struct intel_vbt_data {
} edp;
struct {
- bool enable;
bool full_link;
bool require_aux_wakeup;
int idle_frames;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 295e981e4a398..80ce8758c3c69 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -87,9 +87,7 @@ i915_param_named_unsafe(enable_ppgtt, int, 0400,
"(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with
extended address space)");
i915_param_named_unsafe(enable_psr, int, 0600,
- "Enable PSR "
- "(0=disabled, 1=enabled) "
- "Default: -1 (use per-chip default)");
+ "Enable PSR (default: false)");
i915_param_named_unsafe(alpha_support, bool, 0400,
"Enable alpha quality driver support for latest hardware. "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 6c4d4a21474b5..144572f17a83d 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -42,7 +42,7 @@ struct drm_printer;
param(int, enable_dc, -1) \
param(int, enable_fbc, -1) \
param(int, enable_ppgtt, -1) \
- param(int, enable_psr, -1) \
+ param(int, enable_psr, 0) \
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1faa494e2bc91..d676d483d5cf1 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -551,7 +551,6 @@ parse_driver_features(struct drm_i915_private *dev_priv,
*/
if (!driver->drrs_enabled)
dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
- dev_priv->vbt.psr.enable = driver->psr_enabled;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b6838b525502e..26e7eb318cf07 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1065,13 +1065,6 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
if (!dev_priv->psr.sink_support)
return;
- if (i915_modparams.enable_psr == -1) {
- i915_modparams.enable_psr = dev_priv->vbt.psr.enable;
-
- /* Per platform default: all disabled. */
- i915_modparams.enable_psr = 0;
- }
-
/* Set link_standby x link_off defaults */
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
/* HSW and BDW require workarounds that we don't implement. */
--
2.20.1.415.g653613c723-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine
Jani et al, Do I need to do more? For instance adding people to the cc-list or is the bug visible to everybody? Regards, Jan On 02-01-19 13:34, Jan Vlietland wrote: Thank you. I just did. https://bugs.freedesktop.org/show_bug.cgi?id=109209 Met vriendelijke groet, *dr. Jan Vlietland*, namens spin-off Nederlands Instituut voor de Software Industrie _j.vlietland@nisi.nl_| 06 – 20 411 834 | 030 – 268 53 98 Princetonplein 5 | 3584 CC Utrecht | www.nisi.nl On 02-01-19 08:34, Jani Nikula wrote: On Tue, 01 Jan 2019, Jan Vlietland wrote: First of all happy new year. Based on advice of Greg K-H herewith a mail about my continuous (frustrating) issue with my laptop. I installed various Kali linux versions up to Linux 4.20.0-rc7 (downloaded, compiled and installed) on a Samsung NP900X5N laptop and have an issue with the driver after loading. Please file a bug at [1], add drm.debug=14 module parameter, attach dmesg from boot to desktop to the bug. If you can ssh into the machine and get a dmesg after the screen goes black, great, but if not, let's start with that. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] kernel panic on intel gen4 gfx card
Hi, Greg I found on Debian testing with kernel 4.18.20 fail boot, kernel panic on i915. and reported it to Debian bug 917280 [0], with panic log[1]. after revert: commit 06e562e7f515292ea7721475950f23554214adde Author: Chris Wilson Date: Mon Nov 5 09:43:05 2018 + drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 System boots to desktop. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917280 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=917280;filename=dmesg.txt;msg=10 BR. Ning. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915 module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine
Hello all, First of all happy new year. Based on advice of Greg K-H herewith a mail about my continuous (frustrating) issue with my laptop. I installed various Kali linux versions up to Linux 4.20.0-rc7 (downloaded, compiled and installed) on a Samsung NP900X5N laptop and have an issue with the driver after loading. My configuration: - i7 7500 - 16 gb / 256 gb ssd - nvidia 940MX (for 3D graphics) Shortly after loading the module the screen goes black (af if screen saver) and stays black. I tried to fix it myself.and 'studied' the behaviour for about 20 hours, I think it is a bug in the i915 module itself. I consider it much more efficient to ask you guys for some help. A summary of the test I performed. - I tried several versions and distributions (about 7). They all result in the same behaviour. Screen goes black.I do not see any logging in the logs. I enabled ssh and the machine is unresponsive after the screen going black. The more tests I do (rebooting via holding power key) the sooner the screen goes black. I wonder if the gpu gets too hot locally. Btw, the processor is not hot as the fan stays off. - I tried changing various parameters in the i915 module. No luck. For example, no compression, no power reduction. - Guc/huc setting to 0x03 seems to delay the black screens but the black screens continue. - When I disable the driver in grub or in the modprobe.d dir I do not have any black screens. - After closing and opening the lid the machine does not wake up. - With Windows 10 the machine does not results in lockups (kept the machine on for more than 24 hours). I would really appreciate some help here because the machine is unusable with Linux. Furthermore my older NP900X4D is working with Linux for almost 5 years now. I love linux and rather throw the machine away than using Windows 10 :-) ps: my Nouveau gives MMIO Faults so is not usable as well. -- Met vriendelijke groet, *dr. Jan Vlietland*, namens spin-off Nederlands Instituut voor de Software Industrie _j.vlietland@nisi.nl_| 06 – 20 411 834 | 030 – 268 53 98 Princetonplein 5 | 3584 CC Utrecht | www.nisi.nl ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Linux-4.18.20 fail to boot on old intel gfx card
Package: Linux-image-amd64 Version: 4.18+100~bpo9+1 Linux-4.18.20 fail to boot on old intel gfx card. I also tried a fresh installed Debian testing with same kernel version, still can't boot, even to command line interface. after blacklisting i915, Debian testing can boot to command line interface. but when I tried to modprobe i915, screen blanks, shows nothing. while Linux-4.18.6 is good to boot to UI. here is my hardware information: Machine: Thinkpad X200 output of lspci for gfx card: 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] "flip_done timed out" messages causing huge increase in boot time
I submitted the bug report at
https://bugs.freedesktop.org/show_bug.cgi?id=109245 . The dmesg log is
attached to the bug report.
Daniel
On Mon, 7 Jan 2019 at 14:34, Ville Syrjälä
wrote:
>
> On Sat, Jan 05, 2019 at 12:47:12AM +0100, Daniel Kamil Kozar wrote:
> > Hello.
> > After upgrading the kernel to 4.20, I noticed that the boot time
> > increased from about 5 seconds to 25 seconds. My machine is an Asus
> > K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external
> > display connected to it via HDMI. If the display is unplugged when
> > booting the machine, the boot time stays at its old value.
> > The kernel log shows two messages like this :
> >
> > [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done
> > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
> > [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies
> > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
>
> Hrm. With SNB I would be tempted to blame the LP3 watermarks, but
> 4.20 already has commit 21556350ade3 ("drm/i915: Disable LP3 watermarks
> on all SNB machines").
>
> Can you file a bug at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
> and attach the full dmesg from the boot with drm.debug=0xe passed to the
> kernel cmdline?
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine
Thank you. I just did. https://bugs.freedesktop.org/show_bug.cgi?id=109209 Met vriendelijke groet, *dr. Jan Vlietland*, namens spin-off Nederlands Instituut voor de Software Industrie _j.vlietland@nisi.nl_| 06 – 20 411 834 | 030 – 268 53 98 Princetonplein 5 | 3584 CC Utrecht | www.nisi.nl On 02-01-19 08:34, Jani Nikula wrote: On Tue, 01 Jan 2019, Jan Vlietland wrote: First of all happy new year. Based on advice of Greg K-H herewith a mail about my continuous (frustrating) issue with my laptop. I installed various Kali linux versions up to Linux 4.20.0-rc7 (downloaded, compiled and installed) on a Samsung NP900X5N laptop and have an issue with the driver after loading. Please file a bug at [1], add drm.debug=14 module parameter, attach dmesg from boot to desktop to the bug. If you can ssh into the machine and get a dmesg after the screen goes black, great, but if not, let's start with that. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip
Joonas Lahtinen wrote:
> Quoting Eric Wong (2018-12-27 13:49:48)
> > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > chipset) and hit some kernel panics while trying to view
> > image/animation-intensive stuff in Firefox (X11) unless I use
> > "iommu_intel=igfx_off".
> >
> > With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
> > (4.17.17-1~bpo9+1) has no problems. But "linux-image-4.18.0-0.bpo.3-amd64"
> > (4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
> > and run startx.
> Most confusing about this is that 4.17 would have worked to begin with,
> without intel_iommu=igfx_off (unless it was the default for older
> kernel?)
Yeah, so the Debian bpo 4.17(.17) kernel did not set
CONFIG_INTEL_IOMMU_DEFAULT_ON, so I didn't encounter problems.
My self-built kernels all set CONFIG_INTEL_IOMMU_DEFAULT_ON.
Booting the Debian 4.17 kernel with "intel_iommu=on" gives the
same hanging problem I hit with self-built 4.19.{12,13} kernels.
I'm not sure how far back the problem goes (maybe forever),
since I only got this hardware. Not sure what's the problem
with Debian 4.18, either; but (self-built) 4.19.13 is fine w/o
CONFIG_INTEL_IOMMU_DEFAULT_ON.
Debian backports doesn't have kernels for 4.19 or 4.20, yet.
> Did you maybe update other parts of the system while updating the
> kernel?
Definitely not; just the kernel + headers ("make bindeb-pkg)".
> If you could attach full boot dmesg from working and non-working kernel +
> have config file of both kernel's in Bugzilla. That'd be a good start!
Sorry, I get anxiety attacks when it comes to logins and forms.
Anyways, I managed to get the Debian kernel dmesg output uploaded
with and without iommu_intel=on:
https://bugs.freedesktop.org/attachment.cgi?bugid=109219
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: simplify enable_psr handling
On Fri, Dec 21, 2018 at 11:23:07AM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-12-21 at 10:23 -0700, Ross Zwisler wrote:
> > The following commit:
> >
> > commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be
> > enabled.")
> >
> > added some code with no usable functionality. Regardless of how the
> > psr
> > default is set up in the BDB_DRIVER_FEATURES section, if the
> > enable_psr
> > module parameter isn't specified it defaults to 0.
> Right, that was intentional and the commit message even makes a note of
> it
> " Note: The feature currently remains disabled by default for all
> platforms irrespective of what VBT says."
>
>
> Anyway, we've enabled the feature by default now and the current code
> should take into account the VBT flag if the module parameter is left
> to a default value. Please check git://anongit.freedesktop.org/drm-tip
> drm-tip.
Fair enough. It's a bad pattern to introduce dead code as a placeholder for
some future work, though. This code has been in the tree for three major
kernel releases (v4.{18,19,20}) without providing any useful functionality.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] "flip_done timed out" messages causing huge increase in boot time
Small omission on my part : I meant 4.19.12, not 4.19.2 as the last working version. Also, I can confirm that reverting 13947d150bae871bd880565ada318b0bcd0e690e from the current HEAD of linux-stable fixes the issue. On Sat, 5 Jan 2019 at 00:47, Daniel Kamil Kozar wrote: > > Hello. > After upgrading the kernel to 4.20, I noticed that the boot time > increased from about 5 seconds to 25 seconds. My machine is an Asus > K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external > display connected to it via HDMI. If the display is unplugged when > booting the machine, the boot time stays at its old value. > The kernel log shows two messages like this : > > [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > > Which are the only ones that don't appear in 4.19.2, where the boot > time was smaller. Bisecting the commits between these two versions > leads to commit 516a49cc19467e298d08a404f73a6e311f4548d1. > > Let me know if you need more information. > > Kind regards, > Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] "flip_done timed out" messages causing huge increase in boot time
Hello. After upgrading the kernel to 4.20, I noticed that the boot time increased from about 5 seconds to 25 seconds. My machine is an Asus K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external display connected to it via HDMI. If the display is unplugged when booting the machine, the boot time stays at its old value. The kernel log shows two messages like this : [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out Which are the only ones that don't appear in 4.19.2, where the boot time was smaller. Bisecting the commits between these two versions leads to commit 516a49cc19467e298d08a404f73a6e311f4548d1. Let me know if you need more information. Kind regards, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker
== Series Details == Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker URL : https://patchwork.freedesktop.org/series/54952/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11265_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11265_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11265_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_11265_full: ### IGT changes ### Possible regressions * igt@perf_pmu@busy-accuracy-98-bcs0: - shard-iclb: PASS -> INCOMPLETE Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP -> PASS Known issues Here are the changes found in Patchwork_11265_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@gem_userptr_blits@readonly-unsync: - shard-kbl: PASS -> TIMEOUT [fdo#108887] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: PASS -> DMESG-WARN [fdo#107956] - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-hsw: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-a-gamma: - shard-skl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-rte: - shard-glk: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +4 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-iclb: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@kms_psr@no_drrs: - shard-iclb: PASS -> FAIL [fdo#108341] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538] * igt@kms_universal_plane@universal-plane-pipe-b-functional: - shard-glk: PASS -> FAIL [fdo#103166] +1 * igt@pm_rpm@fences: - shard-skl: PASS -> INCOMPLETE [fdo#107807] +1 * igt@pm_rpm@gem-execbuf-stress-extra-wait: - shard-iclb: NOTRUN -> INCOMPLETE [fdo#108840] * igt@pm_rpm@legacy-planes: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#108654] Possible fixes * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: FAIL [fdo#107815] / [fdo#108470] -> PASS * igt@kms_color@pipe-b-ctm-negative: - shard-skl: FAIL [fdo#107361] -> PASS * igt@kms_cursor_crc@cursor-256x256-random: -
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Reduce recursive mutex locking from the shrinker
== Series Details == Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking from the shrinker URL : https://patchwork.freedesktop.org/series/54948/ State : success == Summary == CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11264_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11264_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11264_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_11264_full: ### IGT changes ### Warnings * igt@perf_pmu@rc6: - shard-kbl: SKIP -> PASS * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP -> PASS Known issues Here are the changes found in Patchwork_11264_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_userptr_blits@readonly-unsync: - shard-skl: PASS -> TIMEOUT [fdo#108887] * igt@kms_atomic_transition@plane-all-transition-nonblocking: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: PASS -> FAIL [fdo#108682] * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-xtiled: - shard-skl: PASS -> FAIL [fdo#107791] * igt@kms_flip@2x-flip-vs-panning: - shard-hsw: NOTRUN -> INCOMPLETE [fdo#103540] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-suspend: - shard-iclb: PASS -> DMESG-FAIL [fdo#103167] / [fdo#107724] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] +1 - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_psr@no_drrs: - shard-iclb: PASS -> FAIL [fdo#108341] * igt@pm_rpm@legacy-planes-dpms: - shard-iclb: NOTRUN -> INCOMPLETE [fdo#108840] * igt@pm_rpm@pm-tiling: - shard-skl: PASS -> INCOMPLETE [fdo#107807] Possible fixes * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: FAIL [fdo#107815] / [fdo#108470] -> PASS * igt@kms_color@pipe-b-ctm-negative: - shard-skl: FAIL [fdo#107361] -> PASS * igt@kms_cursor_crc@cursor-64x64-sliding: - shard-glk: FAIL [fdo#103232] -> PASS * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: FAIL [fdo#105767] -> PASS * igt@kms_draw_crc@draw-method-xrgb-mmap-cpu-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS +2 * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-skl: FAIL [fdo#108472] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: FAIL [fdo#103167] -> PASS +2
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker
== Series Details == Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker URL : https://patchwork.freedesktop.org/series/54952/ State : success == Summary == CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11265 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11265 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11265, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54952/revisions/1/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11265: ### IGT changes ### Warnings * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: SKIP -> PASS +7 * igt@pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: SKIP -> PASS Known issues Here are the changes found in Patchwork_11265 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108473] * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: PASS -> DMESG-WARN [fdo#102614] Possible fixes * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS * igt@gem_exec_suspend@basic-s3: - fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602] -> PASS * igt@i915_module_load@reload-with-fault-injection: - fi-kbl-7567u: DMESG-WARN [fdo#105602] / [fdo#108529] -> PASS +1 * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-7567u: FAIL [fdo#108767] -> PASS +2 * igt@kms_flip@basic-flip-vs-modeset: - fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS +1 * igt@kms_flip@basic-flip-vs-wf_vblank: - fi-bsw-n3050: FAIL [fdo#100368] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> PASS * igt@pm_rpm@basic-rte: - fi-bsw-kefka: FAIL [fdo#108800] -> PASS * igt@pm_rpm@module-reload: - fi-kbl-7567u: DMESG-WARN [fdo#108529] -> PASS [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368 [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998 [fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473 [fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 Participating hosts (48 -> 43) -- Additional (1): fi-pnv-d510 Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 Build changes - * Linux: CI_DRM_5383 -> Patchwork_11265 CI_DRM_5383: f0835c765f5520b13d032a1904a2f90a44297b3b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11265: 255c22d39a753d04be387f1d09421d7887b8d296 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 255c22d39a75 drm/i915: Removing polling for struct_mutex from vmap shrinker 5591d0fa3da6 drm/i915: Use mutex_lock_killable() from inside the shrinker == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11265/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
On Mon, Jan 07, 2019 at 11:19:31AM -0800, Matt Roper wrote:
> On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > > Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > > > According to Workaround database ICL also needs
> > > > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > > > fine-granularity preemptions per-context.
> > >
> > > I must wonder where is the userspace component that needs this, and why
> > > it hasn't been noticed earlier?
> > >
> > > Or is this one more of the cases when no userspace actually uses the
> > > register?
> >
> > It's used:
> > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64
> >
> > -Michał
>
> Wasn't this just an artificial i915-only workaround that was added to
> prevent breakage of pre-preemption UMD's? Initial gen9 driver releases
> didn't support preemption, so when preemption support did get added to
> i915, the kernel had to force object-level off by default at context
> creation to avoid breaking old userspace that didn't build batch buffers
> with all the necessary preemption workarounds. This CS_CHICKEN1
> register was then exposed to userspace so that newer, preemption-aware
> userspace could opt back in if it properly supported preemption.
It wasn't just old userspace vs preeemption-aware userspace.
Even the preemption-aware userspace needs to downgrade its preemption
granularity as a WA, see:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_draw.c#L876
> For gen11, there shouldn't be any "old" userspace around that doesn't
> support preemption, so shouldn't the kernel just leave object-level
> preemption enabled by default (meaning there's no need to expose this
> register to userspace to allow it to explicitly opt-in)?
Agreed, as a bonus we don't allow anyone to explicity opt-out - which is
great, as long as everything works reliably.
-Michał
>
> Matt
>
> >
> > > Regards, Joonas
> > >
> > > >
> > > > BSpec: 11348
> > > > Cc: Oscar Mateo
> > > > Cc: Radhakrishna Sripada
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> > > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > > > b/drivers/gpu/drm/i915/intel_workarounds.c
> > > > index 480c53a2ecb5..bbc5a66faa07 100644
> > > > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > > > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > > > @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct
> > > > i915_wa_list *w)
> > > > /*
> > > > WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> > > > whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> > > >
> > > > - /*
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
> > > > + /*
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl] */
> > > > whitelist_reg(w, GEN8_CS_CHICKEN1);
> > > >
> > > > /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */
> > > > @@ -1068,6 +1068,9 @@ static void icl_whitelist_build(struct
> > > > i915_wa_list *w)
> > > >
> > > > /* WaAllowUMDToModifySamplerMode:icl */
> > > > whitelist_reg(w, GEN10_SAMPLER_MODE);
> > > > +
> > > > + /* WaEnablePreemptionGranularityControlByUMD:icl */
> > > > + whitelist_reg(w, GEN8_CS_CHICKEN1);
> > > > }
> > > >
> > > > void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> > > > @@ -1186,8 +1189,8 @@ static void rcs_engine_wa_init(struct
> > > > intel_engine_cs *engine)
> > > > GEN7_DISABLE_SAMPLER_PREFETCH);
> > > > }
> > > >
> > > > - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > > > - /*
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> > > > + if (IS_GEN_RANGE(i915, 9, 11)) {
> > > > + /*
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl */
> > > > wa_masked_en(wal,
> > > > GEN7_FF_SLICE_CS_CHICKEN1,
> > > > GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> > > > --
> > > > 2.20.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
== Series Details == Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev2) URL : https://patchwork.freedesktop.org/series/54820/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11263_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11263_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11263_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_11263_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-fences-interruptible: - shard-iclb: PASS -> INCOMPLETE Warnings * igt@perf_pmu@rc6: - shard-kbl: SKIP -> PASS * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP -> PASS Known issues Here are the changes found in Patchwork_11263_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_userptr_blits@readonly-unsync: - shard-skl: PASS -> TIMEOUT [fdo#108887] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-hsw: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-2p-rte: - shard-glk: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-glk: PASS -> FAIL [fdo#108145] +1 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@pm_backlight@fade: - shard-iclb: PASS -> INCOMPLETE [fdo#107820] Possible fixes * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-iclb: DMESG-WARN [fdo#107956] -> PASS * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-128x128-dpms: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-256x256-random: - shard-glk: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: FAIL [fdo#105767] -> PASS * igt@kms_draw_crc@draw-method-xrgb-mmap-cpu-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS +2 * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: FAIL [fdo#108222] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: - shard-apl: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt: - shard-skl: FAIL [fdo#105682] -> PASS * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS +1 *
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker
== Series Details == Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker URL : https://patchwork.freedesktop.org/series/54952/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Use mutex_lock_killable() from inside the shrinker Okay! Commit: drm/i915: Removing polling for struct_mutex from vmap shrinker -drivers/gpu/drm/i915/i915_drv.h:3546:16: warning: expression using sizeof(void) ___ 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: Use mutex_lock_killable() from inside the shrinker
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from
inside the shrinker
URL : https://patchwork.freedesktop.org/series/54952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5591d0fa3da6 drm/i915: Use mutex_lock_killable() from inside the shrinker
-:26: ERROR:LOCKING: recursive locking is bad, do not use this ever.
#26: FILE: drivers/gpu/drm/i915/i915_gem_shrinker.c:44:
+ switch (mutex_trylock_recursive(m)) {
total: 1 errors, 0 warnings, 0 checks, 23 lines checked
255c22d39a75 drm/i915: Removing polling for struct_mutex from vmap shrinker
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Removing polling for struct_mutex from vmap shrinker
The wait-for-idle used from within the shrinker_lock_uninterruptible
depends on the struct_mutex locking state being known and declared to
i915_request_wait(). As it is conceivable that we reach the vmap
notifier from underneath struct_mutex (and so keep on relying on the
mutex_trylock_recursive), we should not blindly call i915_request_wait.
In the process we can remove the dubious polling to acquire
struct_mutex, and simply act, or not, on a successful trylock.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 35 +++-
1 file changed, 4 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 8ad9519779cc..6cc2b964c955 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -385,31 +385,6 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
return sc->nr_scanned ? freed : SHRINK_STOP;
}
-static bool
-shrinker_lock_uninterruptible(struct drm_i915_private *i915, bool *unlock,
- int timeout_ms)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies_timeout(timeout_ms);
-
- do {
- if (i915_gem_wait_for_idle(i915,
- 0, MAX_SCHEDULE_TIMEOUT) == 0 &&
- shrinker_lock(i915, 0, unlock))
- break;
-
- schedule_timeout_killable(1);
- if (fatal_signal_pending(current))
- return false;
-
- if (time_after(jiffies, timeout)) {
- pr_err("Unable to lock GPU to purge memory.\n");
- return false;
- }
- } while (1);
-
- return true;
-}
-
static int
i915_gem_shrinker_oom(struct notifier_block *nb, unsigned long event, void
*ptr)
{
@@ -461,16 +436,14 @@ i915_gem_shrinker_vmap(struct notifier_block *nb,
unsigned long event, void *ptr
struct i915_vma *vma, *next;
unsigned long freed_pages = 0;
bool unlock;
- int ret;
- if (!shrinker_lock_uninterruptible(i915, , 5000))
+ if (!shrinker_lock(i915, 0, ))
return NOTIFY_DONE;
/* Force everything onto the inactive lists */
- ret = i915_gem_wait_for_idle(i915,
-I915_WAIT_LOCKED,
-MAX_SCHEDULE_TIMEOUT);
- if (ret)
+ if (i915_gem_wait_for_idle(i915,
+ I915_WAIT_LOCKED,
+ MAX_SCHEDULE_TIMEOUT))
goto out;
intel_runtime_pm_get(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Use mutex_lock_killable() from inside the shrinker
If the current process is being killed (it was interrupted with SIGKILL
or equivalent), it will not make any progress in page allocation and we
can abort performing the shrinking on its behalf. So we can use
mutex_lock_killable() instead (although this path should only be
reachable from kswapd currently).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 34b108f73f1d..8ad9519779cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -39,18 +39,18 @@ static bool shrinker_lock(struct drm_i915_private *i915,
unsigned int flags,
bool *unlock)
{
- switch (mutex_trylock_recursive(>drm.struct_mutex)) {
+ struct mutex *m = >drm.struct_mutex;
+
+ switch (mutex_trylock_recursive(m)) {
case MUTEX_TRYLOCK_RECURSIVE:
*unlock = false;
return true;
case MUTEX_TRYLOCK_FAILED:
*unlock = false;
- if (flags & I915_SHRINK_ACTIVE) {
- mutex_lock_nested(>drm.struct_mutex,
- I915_MM_SHRINKER);
+ if (flags & I915_SHRINK_ACTIVE &&
+ mutex_lock_killable_nested(m, I915_MM_SHRINKER) == 0)
*unlock = true;
- }
return *unlock;
case MUTEX_TRYLOCK_SUCCESS:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
== Series Details == Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen URL : https://patchwork.freedesktop.org/series/54942/ State : success == Summary == CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11262_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11262_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11262_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_11262_full: ### IGT changes ### Warnings * igt@perf_pmu@rc6: - shard-kbl: SKIP -> PASS * igt@pm_rpm@gem-mmap-gtt: - shard-apl: PASS -> SKIP Known issues Here are the changes found in Patchwork_11262_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_atomic_transition@plane-all-transition-fencing: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-hsw: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-snb: PASS -> FAIL [fdo#103375] * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-glk: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: - shard-iclb: PASS -> FAIL [fdo#103355] * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled: - shard-iclb: PASS -> WARN [fdo#108336] +1 * igt@kms_fbcon_fbt@fbc-suspend: - shard-iclb: PASS -> DMESG-FAIL [fdo#105681] / [fdo#107724] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-rte: - shard-glk: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-modesetfrombusy: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +1 * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-pwrite: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +11 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> FAIL [fdo#103167] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-glk: PASS -> FAIL [fdo#103166] +2 - shard-apl: PASS -> FAIL [fdo#103166] +1 - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +5 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538] * igt@kms_vblank@pipe-c-wait-forked: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +20 * igt@pm_rpm@dpms-mode-unset-non-lpsp: - shard-skl: SKIP -> INCOMPLETE [fdo#107807] * igt@pm_rpm@legacy-planes: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#108654] * igt@pm_rpm@universal-planes: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] Possible fixes * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: FAIL [fdo#107815] / [fdo#108470] -> PASS *
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix timeout handling in i915_gem_shrinker_vmap
Quoting Tvrtko Ursulin (2019-01-09 15:07:34) > > On 09/01/2019 14:23, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-09 14:12:47) > >> From: Tvrtko Ursulin > >> > >> The code tries to grab struct mutex for 5ms every time the unlocked GPU > >> idle wait succeeds. But the GPU idle wait itself is practically unbound > >> which means the 5ms timeout might not be honoured. > > > > The arbitrary timeout is merely advisory. If we hang, we get to recover > > everything we can! > > You mean if we hang, eg. take more than 5ms to idle, the function bails > out on the 5ms timeout check, failing to take the lock and free anything? ;) No, just that I picked 5 _seconds_ as arbitrary timeout. As it now hits the mutex_lock() path, the whole polling + timeout is kaput. What I think we should do is use mutex_lock_killable instead. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix timeout handling in i915_gem_shrinker_vmap
On 09/01/2019 14:23, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-09 14:12:47) From: Tvrtko Ursulin The code tries to grab struct mutex for 5ms every time the unlocked GPU idle wait succeeds. But the GPU idle wait itself is practically unbound which means the 5ms timeout might not be honoured. The arbitrary timeout is merely advisory. If we hang, we get to recover everything we can! You mean if we hang, eg. take more than 5ms to idle, the function bails out on the 5ms timeout check, failing to take the lock and free anything? ;) Regards, Tvrtko ___ 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: Reduce recursive mutex locking from the shrinker
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54948/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11264
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11264 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11264, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54948/revisions/1/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11264:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: SKIP -> PASS +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +27
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11264 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105079] /
[fdo#105602]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: PASS -> DMESG-WARN [fdo#102614]
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602]
-> PASS
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7567u: FAIL [fdo#108767] -> PASS +2
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: FAIL [fdo#100368] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> SKIP
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
Participating hosts (48 -> 46)
--
Additional (3): fi-icl-y fi-gdg-551 fi-pnv-d510
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5383 -> Patchwork_11264
CI_DRM_5383: f0835c765f5520b13d032a1904a2f90a44297b3b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11264: b450521b73d1f64729522df0e58fb1906127b3d9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b450521b73d1 drm/i915: Fix timeout handling in i915_gem_shrinker_vmap
d7e16a58370e drm/i915: Reduce recursive mutex locking from the shrinker
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11264/
___
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: Reduce i915_request_alloc retirement to local context (rev2)
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11263
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11263 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11263, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54820/revisions/2/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11263:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: SKIP -> PASS +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +27
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11263 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: PASS -> DMESG-FAIL [fdo#105079]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: PASS -> DMESG-WARN [fdo#102614]
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602]
-> PASS
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7567u: FAIL [fdo#108767] -> PASS +2
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: FAIL [fdo#100368] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> SKIP
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
Participating hosts (48 -> 43)
--
Additional (3): fi-icl-y fi-gdg-551 fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-ivb-3520m fi-skl-6700k2 fi-kbl-r
Build changes
-
* Linux: CI_DRM_5383 -> Patchwork_11263
CI_DRM_5383: f0835c765f5520b13d032a1904a2f90a44297b3b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11263: 92c5dfde3ee96623e431c4dfbae21333845245fd @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
92c5dfde3ee9 drm/i915: Reduce i915_request_alloc retirement to local context
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11263/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/46] drm/i915: Syntatic sugar for using intel_runtime_pm
Chris Wilson writes:
> Frequently, we use intel_runtime_pm_get/_put around a small block.
> Formalise that usage by providing a macro to define such a block with an
> automatic closure to scope the intel_runtime_pm wakeref to that block,
> i.e. macro abuse smelling of python.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 162 --
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ++-
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 51 +++---
> drivers/gpu/drm/i915/i915_pmu.c | 7 +-
> drivers/gpu/drm/i915/i915_sysfs.c | 7 +-
> drivers/gpu/drm/i915/intel_drv.h | 8 +
> drivers/gpu/drm/i915/intel_guc_log.c | 26 ++-
> drivers/gpu/drm/i915/intel_huc.c | 7 +-
> drivers/gpu/drm/i915/intel_panel.c| 18 +-
> drivers/gpu/drm/i915/intel_uncore.c | 30 ++--
> drivers/gpu/drm/i915/selftests/i915_gem.c | 34 ++--
> .../gpu/drm/i915/selftests/i915_gem_context.c | 12 +-
> .../gpu/drm/i915/selftests/i915_gem_object.c | 11 +-
> .../drm/i915/selftests/intel_workarounds.c| 28 +--
> 15 files changed, 203 insertions(+), 231 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d667b05e7ca4..1521e08861d1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -953,9 +953,9 @@ static int i915_gpu_info_open(struct inode *inode, struct
> file *file)
> struct i915_gpu_state *gpu;
> intel_wakeref_t wakeref;
>
> - wakeref = intel_runtime_pm_get(i915);
> - gpu = i915_capture_gpu_state(i915);
> - intel_runtime_pm_put(i915, wakeref);
> + gpu = NULL;
> + with_intel_runtime_pm(i915, wakeref)
> + gpu = i915_capture_gpu_state(i915);
> if (IS_ERR(gpu))
> return PTR_ERR(gpu);
>
> @@ -1287,17 +1287,15 @@ static int i915_hangcheck_info(struct seq_file *m,
> void *unused)
> return 0;
> }
>
> - wakeref = intel_runtime_pm_get(dev_priv);
> + with_intel_runtime_pm(dev_priv, wakeref) {
> + for_each_engine(engine, dev_priv, id) {
> + acthd[id] = intel_engine_get_active_head(engine);
> + seqno[id] = intel_engine_get_seqno(engine);
> + }
>
> - for_each_engine(engine, dev_priv, id) {
> - acthd[id] = intel_engine_get_active_head(engine);
> - seqno[id] = intel_engine_get_seqno(engine);
> + intel_engine_get_instdone(dev_priv->engine[RCS], );
> }
>
> - intel_engine_get_instdone(dev_priv->engine[RCS], );
> -
> - intel_runtime_pm_put(dev_priv, wakeref);
> -
> if (timer_pending(_priv->gpu_error.hangcheck_work.timer))
> seq_printf(m, "Hangcheck active, timer fires in %dms\n",
>
> jiffies_to_msecs(dev_priv->gpu_error.hangcheck_work.timer.expires -
> @@ -1573,18 +1571,16 @@ static int i915_drpc_info(struct seq_file *m, void
> *unused)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> intel_wakeref_t wakeref;
> - int err;
> -
> - wakeref = intel_runtime_pm_get(dev_priv);
> -
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - err = vlv_drpc_info(m);
> - else if (INTEL_GEN(dev_priv) >= 6)
> - err = gen6_drpc_info(m);
> - else
> - err = ironlake_drpc_info(m);
> + int err = -ENODEV;
>
> - intel_runtime_pm_put(dev_priv, wakeref);
> + with_intel_runtime_pm(dev_priv, wakeref) {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + err = vlv_drpc_info(m);
> + else if (INTEL_GEN(dev_priv) >= 6)
> + err = gen6_drpc_info(m);
> + else
> + err = ironlake_drpc_info(m);
> + }
>
> return err;
> }
> @@ -2068,8 +2064,7 @@ static int i915_rps_boost_info(struct seq_file *m, void
> *data)
> intel_wakeref_t wakeref;
> struct drm_file *file;
>
> - wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
> - if (wakeref) {
> + with_intel_runtime_pm_if_in_use(dev_priv, wakeref) {
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> mutex_lock(_priv->pcu_lock);
> act_freq = vlv_punit_read(dev_priv,
> @@ -2080,7 +2075,6 @@ static int i915_rps_boost_info(struct seq_file *m, void
> *data)
> act_freq = intel_get_cagf(dev_priv,
> I915_READ(GEN6_RPSTAT1));
> }
> - intel_runtime_pm_put(dev_priv, wakeref);
> }
>
> seq_printf(m, "RPS enabled? %d\n", rps->enabled);
> @@ -2172,9 +2166,8 @@ static int i915_huc_load_status_info(struct seq_file
> *m, void
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix timeout handling in i915_gem_shrinker_vmap
Quoting Tvrtko Ursulin (2019-01-09 14:12:47)
> From: Tvrtko Ursulin
>
> The code tries to grab struct mutex for 5ms every time the unlocked GPU
> idle wait succeeds. But the GPU idle wait itself is practically unbound
> which means the 5ms timeout might not be honoured.
>
> Cap the GPU idle wait to 5ms as well to fix this.
>
> v2:
> * Rebase.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index ce539d38461c..4ee393028a93 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -402,13 +402,12 @@ i915_gem_shrinker_scan(struct shrinker *shrinker,
> struct shrink_control *sc)
>
> static bool
> shrinker_lock_uninterruptible(struct drm_i915_private *i915, bool *unlock,
> - int timeout_ms)
> + unsigned long timeout)
> {
> - unsigned long timeout = jiffies +
> msecs_to_jiffies_timeout(timeout_ms);
> + const unsigned long timeout_end = jiffies + timeout;
>
> do {
> - if (i915_gem_wait_for_idle(i915,
> - 0, MAX_SCHEDULE_TIMEOUT) == 0 &&
> + if (i915_gem_wait_for_idle(i915, 0, timeout) == 0 &&
Hmm, I wonder if this code could be hitting i915_request_wait():
#if IS_ENABLED(CONFIG_LOCKDEP)
GEM_BUG_ON(debug_locks &&
!!lockdep_is_held(>i915->drm.struct_mutex) !=
!!(flags & I915_WAIT_LOCKED));
#endif
as i915_gem_shrinker_vmap() could conceivably be called under
struct_mutex, e.g. i915_gem_object_pin_map(), and I'm sure I've seen the
vmap arena used for setting pte bits.
Onwards to removing that restriction!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix timeout handling in i915_gem_shrinker_vmap
Quoting Tvrtko Ursulin (2019-01-09 14:12:47) > From: Tvrtko Ursulin > > The code tries to grab struct mutex for 5ms every time the unlocked GPU > idle wait succeeds. But the GPU idle wait itself is practically unbound > which means the 5ms timeout might not be honoured. The arbitrary timeout is merely advisory. If we hang, we get to recover everything we can! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Fix timeout handling in i915_gem_shrinker_vmap
From: Tvrtko Ursulin
The code tries to grab struct mutex for 5ms every time the unlocked GPU
idle wait succeeds. But the GPU idle wait itself is practically unbound
which means the 5ms timeout might not be honoured.
Cap the GPU idle wait to 5ms as well to fix this.
v2:
* Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ce539d38461c..4ee393028a93 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -402,13 +402,12 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
static bool
shrinker_lock_uninterruptible(struct drm_i915_private *i915, bool *unlock,
- int timeout_ms)
+ unsigned long timeout)
{
- unsigned long timeout = jiffies + msecs_to_jiffies_timeout(timeout_ms);
+ const unsigned long timeout_end = jiffies + timeout;
do {
- if (i915_gem_wait_for_idle(i915,
- 0, MAX_SCHEDULE_TIMEOUT) == 0 &&
+ if (i915_gem_wait_for_idle(i915, 0, timeout) == 0 &&
shrinker_lock(i915, 0, unlock))
break;
@@ -416,7 +415,7 @@ shrinker_lock_uninterruptible(struct drm_i915_private
*i915, bool *unlock,
if (fatal_signal_pending(current))
return false;
- if (time_after(jiffies, timeout)) {
+ if (time_after(jiffies, timeout_end)) {
pr_err("Unable to lock GPU to purge memory.\n");
return false;
}
@@ -474,11 +473,12 @@ i915_gem_shrinker_vmap(struct notifier_block *nb,
unsigned long event, void *ptr
struct drm_i915_private *i915 =
container_of(nb, struct drm_i915_private, mm.vmap_notifier);
struct i915_vma *vma, *next;
+ const unsigned long timeout = msecs_to_jiffies_timeout(5000);
unsigned long freed_pages = 0;
bool unlock;
int ret;
- if (!shrinker_lock_uninterruptible(i915, , 5000))
+ if (!shrinker_lock_uninterruptible(i915, , timeout))
return NOTIFY_DONE;
/* Force everything onto the inactive lists */
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Reduce recursive mutex locking from the shrinker
From: Tvrtko Ursulin
In two codepaths internal to the shrinker we know we will end up taking
the resursive mutex path.
It instead feels more elegant to avoid this altogether and not call
mutex_trylock_recursive in those cases.
We achieve this by extracting the shrinking part to __i915_gem_shrink,
wrapped by struct mutex taking i915_gem_shrink.
At the same time move the runtime pm reference taking to always be in the
usual, before struct mutex, order.
v2:
* Don't use flags but split i915_gem_shrink into locked and unlocked.
v3:
* Whitespace and checkpatch reported errors.
v4:
* Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 152 +--
2 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d57438d87bc0..677a9af3771b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3178,7 +3178,7 @@ i915_gem_object_create_internal(struct drm_i915_private
*dev_priv,
unsigned long i915_gem_shrink(struct drm_i915_private *i915,
unsigned long target,
unsigned long *nr_scanned,
- unsigned flags);
+ unsigned int flags);
#define I915_SHRINK_PURGEABLE 0x1
#define I915_SHRINK_UNBOUND 0x2
#define I915_SHRINK_BOUND 0x4
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 72d6ea0cac7e..ce539d38461c 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -115,36 +115,11 @@ static bool unsafe_drop_pages(struct drm_i915_gem_object
*obj)
return !i915_gem_object_has_pages(obj);
}
-/**
- * i915_gem_shrink - Shrink buffer object caches
- * @i915: i915 device
- * @target: amount of memory to make available, in pages
- * @nr_scanned: optional output for number of pages scanned (incremental)
- * @flags: control flags for selecting cache types
- *
- * This function is the main interface to the shrinker. It will try to release
- * up to @target pages of main memory backing storage from buffer objects.
- * Selection of the specific caches can be done with @flags. This is e.g.
useful
- * when purgeable objects should be removed from caches preferentially.
- *
- * Note that it's not guaranteed that released amount is actually available as
- * free system memory - the pages might still be in-used to due to other
reasons
- * (like cpu mmaps) or the mm core has reused them before we could grab them.
- * Therefore code that needs to explicitly shrink buffer objects caches (e.g.
to
- * avoid deadlocks in memory reclaim) must fall back to i915_gem_shrink_all().
- *
- * Also note that any kind of pinning (both per-vma address space pins and
- * backing storage pins at the buffer object level) result in the shrinker code
- * having to skip the object.
- *
- * Returns:
- * The number of pages of backing storage actually released.
- */
-unsigned long
-i915_gem_shrink(struct drm_i915_private *i915,
- unsigned long target,
- unsigned long *nr_scanned,
- unsigned flags)
+static unsigned long
+__i915_gem_shrink(struct drm_i915_private *i915,
+ unsigned long target,
+ unsigned long *nr_scanned,
+ unsigned int flags)
{
const struct {
struct list_head *list;
@@ -156,10 +131,8 @@ i915_gem_shrink(struct drm_i915_private *i915,
}, *phase;
unsigned long count = 0;
unsigned long scanned = 0;
- bool unlock;
- if (!shrinker_lock(i915, flags, ))
- return 0;
+ lockdep_assert_held(>drm.struct_mutex);
/*
* When shrinking the active list, also consider active contexts.
@@ -175,18 +148,8 @@ i915_gem_shrink(struct drm_i915_private *i915,
I915_WAIT_LOCKED,
MAX_SCHEDULE_TIMEOUT);
- trace_i915_gem_shrink(i915, target, flags);
i915_retire_requests(i915);
- /*
-* Unbinding of objects will require HW access; Let us not wake the
-* device just to recover a little memory. If absolutely necessary,
-* we will force the wake during oom-notifier.
-*/
- if ((flags & I915_SHRINK_BOUND) &&
- !intel_runtime_pm_get_if_in_use(i915))
- flags &= ~I915_SHRINK_BOUND;
-
/*
* As we may completely rewrite the (un)bound list whilst unbinding
* (due to retiring requests) we have to strictly process only
@@ -265,15 +228,70 @@ i915_gem_shrink(struct drm_i915_private *i915,
spin_unlock(>mm.obj_lock);
}
- if (flags & I915_SHRINK_BOUND)
- intel_runtime_pm_put(i915);
-
i915_retire_requests(i915);
-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
URL : https://patchwork.freedesktop.org/series/54820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
92c5dfde3ee9 drm/i915: Reduce i915_request_alloc retirement to local context
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#14:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 11abf0c5a021 ("drm/i915: Limit
the backpressure for i915_request allocation")'
#14:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
total: 1 errors, 1 warnings, 0 checks, 47 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reduce i915_request_alloc retirement to local context
On 09/01/2019 13:14, Chris Wilson wrote:
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
v2: Don't forget the list iteration included an early break, so we would
never throttle on the last request in the ring/timeline.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 35 +
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..e183009f47f4 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,31 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq, *next;
+
+ if (list_empty(>request_list))
+ goto out;
+
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ rq = list_last_entry(>request_list, typeof(*rq), ring_link);
+ cond_synchronize_rcu(rq->rcustate);
+
+ /* Retire our old requests in the hope that we free some */
+ list_for_each_entry_safe(rq, next, >request_list, ring_link) {
+ if (!i915_request_completed(rq))
+ break;
+
+ i915_request_retire(rq);
+ }
Now this is more similar to ring_retire_requests. ;)
+
+out:
+ return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -559,15 +584,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
- i915_retire_requests(i915);
-
- /* Ratelimit ourselves to prevent oom from malicious clients */
- rq = i915_gem_active_raw(>ring->timeline->last_request,
->drm.struct_mutex);
- if (rq)
- cond_synchronize_rcu(rq->rcustate);
-
- rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
+ rq = i915_request_alloc_slow(ce);
if (!rq) {
ret = -ENOMEM;
goto err_unreserve;
With the retire consolidated:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
== Series Details == Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen URL : https://patchwork.freedesktop.org/series/54942/ State : success == Summary == CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11262 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11262 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11262, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54942/revisions/1/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11262: ### IGT changes ### Warnings * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: SKIP -> PASS +2 * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - fi-kbl-7567u: PASS -> SKIP +27 Known issues Here are the changes found in Patchwork_11262 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: PASS -> DMESG-FAIL [fdo#105079] * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +2 Possible fixes * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS * igt@gem_exec_suspend@basic-s3: - fi-kbl-7567u: DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602] -> PASS * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-7567u: FAIL [fdo#108767] -> PASS +2 * igt@kms_flip@basic-flip-vs-modeset: - fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS * igt@kms_flip@basic-flip-vs-wf_vblank: - fi-bsw-n3050: FAIL [fdo#100368] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> SKIP [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 Participating hosts (48 -> 42) -- Additional (1): fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 Build changes - * Linux: CI_DRM_5383 -> Patchwork_11262 CI_DRM_5383: f0835c765f5520b13d032a1904a2f90a44297b3b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11262: 977d8938ef909aec415512a6ac0ee5899ee45276 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 977d8938ef90 drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11262/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Reduce i915_request_alloc retirement to local context
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
v2: Don't forget the list iteration included an early break, so we would
never throttle on the last request in the ring/timeline.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 35 +
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..e183009f47f4 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,31 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq, *next;
+
+ if (list_empty(>request_list))
+ goto out;
+
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ rq = list_last_entry(>request_list, typeof(*rq), ring_link);
+ cond_synchronize_rcu(rq->rcustate);
+
+ /* Retire our old requests in the hope that we free some */
+ list_for_each_entry_safe(rq, next, >request_list, ring_link) {
+ if (!i915_request_completed(rq))
+ break;
+
+ i915_request_retire(rq);
+ }
+
+out:
+ return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -559,15 +584,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
- i915_retire_requests(i915);
-
- /* Ratelimit ourselves to prevent oom from malicious clients */
- rq = i915_gem_active_raw(>ring->timeline->last_request,
->drm.struct_mutex);
- if (rq)
- cond_synchronize_rcu(rq->rcustate);
-
- rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
+ rq = i915_request_alloc_slow(ce);
if (!rq) {
ret = -ENOMEM;
goto err_unreserve;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] tg3 vs commit 2b3e88ea6528 ("net: phy: improve phy state checking")
Hi, we've hit a snag with commit 2b3e88ea65287ba738a798622405b15344871085 Author: Heiner Kallweit Date: Sun Dec 16 18:30:14 2018 +0100 net: phy: improve phy state checking as it is detecting that the call from tg3 during suspend is from the HALTED state. <4> [74.170194] [ cut here ] <4> [74.170220] called from state HALTED <4> [74.170237] WARNING: CPU: 3 PID: 2473 at drivers/net/phy/phy.c:548 phy_start_aneg+0xf1/0x140 <4> [74.170239] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic asix usbnet mii i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core broadcom bcm_phy_lib snd_pcm tg3 mei_me i2c_i801 mei prime_numbers lpc_ich <4> [74.170258] CPU: 3 PID: 2473 Comm: kworker/u16:22 Tainted: G U 5.0.0-rc1-CI-CI_DRM_5366+ #1 <4> [74.170260] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 <4> [74.170264] Workqueue: events_unbound async_run_entry_fn <4> [74.170269] RIP: 0010:phy_start_aneg+0xf1/0x140 <4> [74.170271] Code: 10 89 93 d0 04 00 00 0f b6 40 04 89 83 d4 04 00 00 e9 74 ff ff ff 48 8b 34 c5 20 a7 ed 81 48 c7 c7 a6 7c 11 82 e8 9f 94 9d ff <0f> 0b 41 bc f0 ff ff ff eb 91 80 a3 c0 04 00 00 7f eb a3 48 b8 ff <4> [74.170273] RSP: 0018:c944bc80 EFLAGS: 00010282 <4> [74.170276] RAX: RBX: 888216e38958 RCX: <4> [74.170278] RDX: RSI: 8213044a RDI: <4> [74.170280] RBP: 888216e38f00 R08: c14614ba R09: <4> [74.170282] R10: c944bc80 R11: R12: 888216e38958 <4> [74.170284] R13: R14: 888223655f28 R15: 88821af6da58 <4> [74.170287] FS: () GS:888227ac() knlGS: <4> [74.170289] CS: 0010 DS: ES: CR0: 80050033 <4> [74.170291] CR2: 55f1dae80d80 CR3: 02214006 CR4: 000606e0 <4> [74.170293] Call Trace: <4> [74.170301] tg3_power_down_prepare+0x754/0xa30 [tg3] <4> [74.170308] tg3_suspend+0x1e5/0x350 [tg3] <4> [74.170316] pci_pm_suspend+0x6d/0x120 <4> [74.170319] ? pci_pm_freeze+0xc0/0xc0 <4> [74.170324] dpm_run_callback+0x64/0x280 <4> [74.170330] __device_suspend+0x12a/0x5b0 <4> [74.170335] ? dpm_watchdog_set+0x60/0x60 <4> [74.170344] async_suspend+0x15/0x90 <4> [74.170347] async_run_entry_fn+0x34/0x160 <4> [74.170352] process_one_work+0x245/0x610 <4> [74.170360] worker_thread+0x37/0x380 <4> [74.170365] ? process_one_work+0x610/0x610 <4> [74.170368] kthread+0x119/0x130 <4> [74.170371] ? kthread_park+0x80/0x80 <4> [74.170377] ret_from_fork+0x3a/0x50 <4> [74.170388] irq event stamp: 648 <4> [74.170392] hardirqs last enabled at (647): [] vprintk_emit+0x302/0x320 <4> [74.170396] hardirqs last disabled at (648): [] trace_hardirqs_off_thunk+0x1a/0x1c <4> [74.170399] softirqs last enabled at (626): [] __do_softirq+0x33a/0x4b9 <4> [74.170402] softirqs last disabled at (605): [] do_softirq_own_stack+0x2a/0x40 <4> [74.170405] WARNING: CPU: 3 PID: 2473 at drivers/net/phy/phy.c:548 phy_start_aneg+0xf1/0x140 <4> [74.170407] ---[ end trace e382359f2ec4f600 ]--- Previously phy_start_aneg() would handle the HALTED state but now it is a warning. To maintain coverage in our (intel-gfx) CI, we've locally reverted 2b3e88ea6528. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/backlight: Restore backlight on resume, v3. (rev2)
== Series Details == Series: series starting with [1/5] drm/i915/backlight: Restore backlight on resume, v3. (rev2) URL : https://patchwork.freedesktop.org/series/54896/ State : success == Summary == CI Bug Log - changes from CI_DRM_5382_full -> Patchwork_11261_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11261_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11261_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_11261_full: ### IGT changes ### Warnings * igt@gem_cpu_reloc@full: - shard-skl: TIMEOUT [fdo#108248] -> INCOMPLETE Known issues Here are the changes found in Patchwork_11261_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-kbl: NOTRUN -> FAIL [fdo#103158] * igt@gem_userptr_blits@readonly-unsync: - shard-iclb: PASS -> INCOMPLETE [fdo#108342] * igt@i915_suspend@shrink: - shard-apl: NOTRUN -> DMESG-WARN [fdo#107886] / [fdo#109244] - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107886] / [fdo#109244] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-glk: NOTRUN -> DMESG-WARN [fdo#107956] +2 - shard-hsw: NOTRUN -> DMESG-WARN [fdo#107956] - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 - shard-kbl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-a: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_color@pipe-a-gamma: - shard-skl: PASS -> FAIL [fdo#104782] * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-dpms: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-sliding: - shard-glk: NOTRUN -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: NOTRUN -> FAIL [fdo#105454] / [fdo#106509] * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled: - shard-iclb: PASS -> WARN [fdo#108336] * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: PASS -> FAIL [fdo#108222] * igt@kms_fbcon_fbt@fbc-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +5 - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt: - shard-glk: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-hsw: NOTRUN -> FAIL [fdo#105682] - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#103167] +4 * igt@kms_frontbuffer_tracking@fbcpsr-farfromfence: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-snb: SKIP -> INCOMPLETE [fdo#105411] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-glk: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: NOTRUN -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-apl: PASS -> FAIL [fdo#103166] +3 *
Re: [Intel-gfx] [PATCH 16/46] drm/i915/selftests: Mark up rpm wakerefs
Chris Wilson writes:
> Track the temporary wakerefs used within the selftests so that leaks are
> clear.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/selftests/huge_pages.c | 5 ++--
> drivers/gpu/drm/i915/selftests/i915_gem.c | 29 ---
> .../drm/i915/selftests/i915_gem_coherency.c | 5 ++--
> .../gpu/drm/i915/selftests/i915_gem_context.c | 27 ++---
> .../gpu/drm/i915/selftests/i915_gem_evict.c | 11 ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 10 ---
> .../gpu/drm/i915/selftests/i915_gem_object.c | 18
> drivers/gpu/drm/i915/selftests/i915_request.c | 22 --
> drivers/gpu/drm/i915/selftests/intel_guc.c| 10 ---
> .../gpu/drm/i915/selftests/intel_hangcheck.c | 15 ++
> drivers/gpu/drm/i915/selftests/intel_lrc.c| 25 +---
> .../drm/i915/selftests/intel_workarounds.c| 27 ++---
> 12 files changed, 126 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/huge_pages.c
> b/drivers/gpu/drm/i915/selftests/huge_pages.c
> index 731dfd3d3fc8..c7a4599173bb 100644
> --- a/drivers/gpu/drm/i915/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/selftests/huge_pages.c
> @@ -1760,6 +1760,7 @@ int i915_gem_huge_page_live_selftests(struct
> drm_i915_private *dev_priv)
> };
> struct drm_file *file;
> struct i915_gem_context *ctx;
> + intel_wakeref_t wakeref;
> int err;
>
> if (!HAS_PPGTT(dev_priv)) {
> @@ -1775,7 +1776,7 @@ int i915_gem_huge_page_live_selftests(struct
> drm_i915_private *dev_priv)
> return PTR_ERR(file);
>
> mutex_lock(_priv->drm.struct_mutex);
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
>
> ctx = live_context(dev_priv, file);
> if (IS_ERR(ctx)) {
> @@ -1789,7 +1790,7 @@ int i915_gem_huge_page_live_selftests(struct
> drm_i915_private *dev_priv)
> err = i915_subtests(tests, ctx);
>
> out_unlock:
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> mutex_unlock(_priv->drm.struct_mutex);
>
> mock_file_free(dev_priv, file);
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index 762e1a7125f5..01a46c46fe25 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -16,9 +16,10 @@ static int switch_to_context(struct drm_i915_private *i915,
> {
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
> + intel_wakeref_t wakeref;
> int err = 0;
>
> - intel_runtime_pm_get(i915);
> + wakeref = intel_runtime_pm_get(i915);
>
> for_each_engine(engine, i915, id) {
> struct i915_request *rq;
> @@ -32,7 +33,7 @@ static int switch_to_context(struct drm_i915_private *i915,
> i915_request_add(rq);
> }
>
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
>
> return err;
> }
> @@ -65,7 +66,9 @@ static void trash_stolen(struct drm_i915_private *i915)
>
> static void simulate_hibernate(struct drm_i915_private *i915)
> {
> - intel_runtime_pm_get(i915);
> + intel_wakeref_t wakeref;
> +
> + wakeref = intel_runtime_pm_get(i915);
>
> /*
>* As a final sting in the tail, invalidate stolen. Under a real S4,
> @@ -76,7 +79,7 @@ static void simulate_hibernate(struct drm_i915_private
> *i915)
>*/
> trash_stolen(i915);
>
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
> }
>
> static int pm_prepare(struct drm_i915_private *i915)
> @@ -93,39 +96,45 @@ static int pm_prepare(struct drm_i915_private *i915)
>
> static void pm_suspend(struct drm_i915_private *i915)
> {
> - intel_runtime_pm_get(i915);
> + intel_wakeref_t wakeref;
> +
> + wakeref = intel_runtime_pm_get(i915);
>
> i915_gem_suspend_gtt_mappings(i915);
> i915_gem_suspend_late(i915);
>
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
> }
>
> static void pm_hibernate(struct drm_i915_private *i915)
> {
> - intel_runtime_pm_get(i915);
> + intel_wakeref_t wakeref;
> +
> + wakeref = intel_runtime_pm_get(i915);
>
> i915_gem_suspend_gtt_mappings(i915);
>
> i915_gem_freeze(i915);
> i915_gem_freeze_late(i915);
>
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
> }
>
> static void pm_resume(struct drm_i915_private *i915)
> {
> + intel_wakeref_t wakeref;
> +
> /*
>* Both suspend and hibernate follow the same wakeup path and assume
>* that runtime-pm just works.
>*/
> - intel_runtime_pm_get(i915);
> + wakeref = intel_runtime_pm_get(i915);
>
> intel_engines_sanitize(i915,
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request_alloc retirement to local context
On 09/01/2019 12:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-09 11:56:15)
On 07/01/2019 15:29, Chris Wilson wrote:
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 33 +
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..9ba218c6029b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,29 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq, *next;
+
+ list_for_each_entry_safe(rq, next, >request_list, ring_link) {
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ if (>ring_link == >request_list) {
list_is_last(next, >request_list) ?
Tried it (needs list_is_last(>ring_link,...)), but I slightly
preferred not implying that next was a valid request here, and keeping
the matching form to list termination.
+ cond_synchronize_rcu(rq->rcustate);
+ break; /* keep the last objects for the next request */
+ }
+
+ if (!i915_request_completed(rq))
+ break;
+
+ /* Retire our old requests in the hope that we free some */
+ i915_request_retire(rq);
The RCU wait against the last submitted rq is also gone. Now it only
sync against the next to last rq, unless there is more than two live
requests. Is this what you intended?
Nah, I was trying to be too smart, forgetting that we didn't walk the
entire list. The RCU wait is against to the last rq (since next is the
list head at that point, so unchanged wrt to using list_last_entry), but
we break on seeing a busy request, so no ratelimiting if you keep the GPU
busy (not quite as intended!).
If the ring timeline has is a list of r-r-r-R-R-R (r=completed,
R=pending) then it looks like it will not sync on anything.
And if the list is r-r-r-r it will sync against a completed rq. Which I
hope is a no-op, but still, the loop logic looks potentially dodgy.
It also has a higher level vulnerability to one hog timeline starving
the rest I think.
Also? Other than forgetting the earlier break preventing the throtting,
what else do you see wrong with throttling along a timeline/ring?
I was on the wrong track when thinking about the removal of global
retire. I though the hog on one timeline would be able to starve the
other timeline, but the hog will eventually hit the allocation failure
and sync against itself. I think it's fine.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 1/2] drm: Add colorspace connector property
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:43 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; nd
>Subject: Re: [v6 1/2] drm: Add colorspace connector property
>
>Hi Uma,
>
>On Thu, Dec 27, 2018 at 11:22:37PM +0530, Uma Shankar wrote:
>> This patch adds a colorspace connector property, enabling userspace to
>> switch to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> colorspace enum to incorporate both HDMI and DP supported colorspaces.
>> Also, added a default option for colorspace.
>>
>> v3: Removed Adobe references from enum definitions as per Ville, Hans
>> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
>> state where driver will assign the colorspace is not chosen by user,
>> suggested by Ville and Maarten. Addressed other misc review comments
>> from Maarten. Split the changes to have separate colorspace property
>> for DP and HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Made the property creation helper accept enum list based on
>> platform capabilties as suggested by Shashank. Consolidated HDMI and
>> DP property creation in the common helper.
>>
>> v6: Addressed Shashank's review comments.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> drivers/gpu/drm/drm_connector.c | 79
>+++
>> include/drm/drm_connector.h | 17 +
>> include/uapi/drm/drm_mode.h | 33
>> 4 files changed, 133 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c408898..5e03292 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> return -EINVAL;
>> }
>> state->content_protection = val;
>> +} else if (property == connector->colorspace_property) {
>> +state->colorspace = val;
>> } else if (property == config->writeback_fb_id_property) {
>> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb); @@
>> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> *val = state->picture_aspect_ratio;
>> } else if (property == config->content_type_property) {
>> *val = state->content_type;
>> +} else if (property == connector->colorspace_property) {
>> +*val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> } else if (property == connector->content_protection_property) {
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 8475396..ad1b862 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
>> drm_display_info *info, };
>> DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>drm_cp_enum_list)
>>
>> +/* List of HDMI Colorspaces supported */ static const struct
>> +drm_prop_enum_list hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +/* List of DP Colorspaces supported */ static const struct
>> +drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default
Re: [Intel-gfx] [v6 0/2] Add Colorspace connector property interface
>-Original Message- >From: Brian Starkey [mailto:brian.star...@arm.com] >Sent: Tuesday, January 8, 2019 7:37 PM >To: Shankar, Uma >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >Lankhorst, >Maarten ; Syrjala, Ville >; >Sharma, Shashank ; nd >Subject: Re: [v6 0/2] Add Colorspace connector property interface > >Hi Uma, > >On Thu, Dec 27, 2018 at 11:22:36PM +0530, Uma Shankar wrote: >> This patch series creates a new connector property to program >> colorspace to sink devices. Modern sink devices support more than 1 >> type of colorspace like 601, 709, BT2020 etc. This helps to switch >> based on content type which is to be displayed. The decision lies with >> compositors as to in which scenarios, a particular colorspace will be >> picked. >> >> This will be helpful mostly to switch to higher gamut colorspaces like >> BT2020 when the media content is encoded as BT2020. Thereby giving a >> good visual experience to users. >> >> The expectation from userspace is that it should parse the EDID and >> get supported colorspaces. Use this property and switch to the one >> supported. Kernel will not give the supported colorspaces since this >> is panel dependent and our current property infrastructure is not >> supporting it. >> >> Basically the expectation from userspace is: >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink >>colorspace >> - Set this new property to let the sink know what it >>converted the CRTC output to. >> - This property is just to inform sink what colorspace >>source is trying to drive. > >All the above info is really important/useful stuff, but it's going to get lost >because it's only in the cover letter. This should either find its way into the >commit message of patch 1 or even better, into the kerneldoc for the property. Sure Brian, Will add it to kernel doc as well to commit message so that it's not lost. Regards, Uma Shankar >Cheers, >-Brian > >> >> Have tested this using xrandr by using below command: >> xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" >> >> v2: Addressed Ville and Maarten's review comments. Merged the 2nd and >> 3rd patch into one common logical patch. >> >> v3: Removed Adobe references from enum definitions as per Ville, Hans >> Verkuil and Jonas Karlman suggestions. Changed default to an unset >> state where driver will assign the colorspace when not chosen by user, >> suggested by Ville and Maarten. Addressed other misc review comments >> from Maarten. Split the changes to have separate colorspace property >> for DP and HDMI. >> >> v4: Addressed Chris and Ville's review comments, and created a common >> colorspace property for DP and HDMI, filtered the list based on the >> colorspaces supported by the respective protocol standard. Handled the >> default case more efficiently. >> >> v5: Modified the colorspace property creation helper to take platform >> specific enum list based on the capabilities of the platform as >> suggested by Shashank. With this there is no need for segregation >> between DP and HDMI. >> >> v6: Addressed Shashank's review comments. >> >> Uma Shankar (2): >> drm: Add colorspace connector property >> drm/i915: Attach colorspace property and enable modeset >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ >> drivers/gpu/drm/drm_connector.c| 82 >++ >> drivers/gpu/drm/i915/intel_atomic.c| 1 + >> drivers/gpu/drm/i915/intel_connector.c | 63 ++ >> drivers/gpu/drm/i915/intel_drv.h | 1 + >> drivers/gpu/drm/i915/intel_hdmi.c | 18 >> include/drm/drm_connector.h| 17 +++ >> include/uapi/drm/drm_mode.h| 33 ++ >> 8 files changed, 219 insertions(+) >> >> -- >> 1.9.1 >> >> Uma Shankar (2): >> drm: Add colorspace connector property >> drm/i915: Attach colorspace property and enable modeset >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ >> drivers/gpu/drm/drm_connector.c| 79 >++ >> drivers/gpu/drm/i915/intel_atomic.c| 1 + >> drivers/gpu/drm/i915/intel_connector.c | 63 +++ >> drivers/gpu/drm/i915/intel_drv.h | 1 + >> drivers/gpu/drm/i915/intel_hdmi.c | 19 >> include/drm/drm_connector.h| 17 >> include/uapi/drm/drm_mode.h| 33 ++ >> 8 files changed, 217 insertions(+) >> >> -- >> 1.9.1 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
From: Ville Syrjälä
Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
which misprograms the hardware badly when encountering a suitably
high resolution display. The programmed pipe timings are somewhat
bonkers and the DPLL is totally misprogrammed (P divider == 0).
That will result in atomic commit timeouts as apparently the pipe
is sufficiently stuck to not signal vblank interrupts.
IIRC something like this was also observed on some other SNB
machine years ago (might have been a Dell XPS 8300) but a BIOS
update cured it. Sadly looks like this was never fixed for the
ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still
broken.
The quickest way to deal with this seems to be to shut down
the pipe+ports+DPLL. Unfortunately doing this during the
normal sanitization phase isn't quite soon enough as we
already spew several WARNs about the bogus hardware state.
But it's better than hanging the boot for a few dozen seconds.
Since this is limited to a few old machines it doesn't seem
entirely worthwile to try and rework the readout+sanitization
code to handle it more gracefully.
Cc: sta...@vger.kernel.org # v4.20+
Cc: Daniel Kamil Kozar
Reported-by: Daniel Kamil Kozar
Tested-by: Daniel Kamil Kozar
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245
Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with
external display")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 51
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 696e6f5680df..ea2e09d36b4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15435,16 +15435,46 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
}
}
+static bool has_bogus_dpll_config(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+
+ /*
+* Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram
+* the hardware when a high res displays plugged in. DPLL P
+* divider is zero, and the pipe timings are bonkers. We'll
+* try to disable everything in that case.
+*
+* FIXME would be nice to be able to sanitize this state
+* without several WARNs, but for now let's take the easy
+* road.
+*/
+ return IS_GEN(dev_priv, 6) &&
+ crtc_state &&
+ crtc_state->base.active &&
+ crtc_state->shared_dpll &&
+ crtc_state->port_clock == 0;
+}
+
static void intel_sanitize_encoder(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_connector *connector;
+ struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_crtc_state *crtc_state = crtc ?
+ to_intel_crtc_state(crtc->base.state) : NULL;
/* We need to check both for a crtc link (meaning that the
* encoder is active and trying to read from a pipe) and the
* pipe itself being active. */
- bool has_active_crtc = encoder->base.crtc &&
- to_intel_crtc(encoder->base.crtc)->active;
+ bool has_active_crtc = crtc_state &&
+ crtc_state->base.active;
+
+ if (has_bogus_dpll_config(crtc_state)) {
+ DRM_DEBUG_KMS("BIOS has misprogrammed the hardware. Disabling
pipe %c\n",
+ pipe_name(crtc->pipe));
+ has_active_crtc = false;
+ }
connector = intel_encoder_find_connector(encoder);
if (connector && !has_active_crtc) {
@@ -15455,16 +15485,25 @@ static void intel_sanitize_encoder(struct
intel_encoder *encoder)
/* Connector is active, but has no active pipe. This is
* fallout from our resume register restoring. Disable
* the encoder manually again. */
- if (encoder->base.crtc) {
- struct drm_crtc_state *crtc_state =
encoder->base.crtc->state;
+ if (crtc_state) {
+ struct drm_encoder *best_encoder;
DRM_DEBUG_KMS("[ENCODER:%d:%s] manually disabled\n",
encoder->base.base.id,
encoder->base.name);
+
+ /* avoid oopsing in case the hooks consult best_encoder
*/
+ best_encoder = connector->base.state->best_encoder;
+ connector->base.state->best_encoder = >base;
+
if (encoder->disable)
- encoder->disable(encoder,
to_intel_crtc_state(crtc_state), connector->base.state);
+ encoder->disable(encoder, crtc_state,
+
Re: [Intel-gfx] [v4 10/12] drm/i915: Add HLG EOTF
>-Original Message-
>From: Roper, Matthew D
>Sent: Wednesday, January 9, 2019 1:15 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 10/12] drm/i915: Add HLG EOTF
>
>On Tue, Jan 08, 2019 at 02:41:25PM +0530, Uma Shankar wrote:
>> From: Ville Syrjälä
>>
>> ADD HLG EOTF to the list of EOTF transfer functions supported.
>> Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
>> HLG defines a nonlinear transfer function in which the lower half of
>> the signal values use a gamma curve and the upper half of the signal
>> values use a logarithmic curve.
>>
>> v2: Rebase
>>
>> v3: Fixed a warning message
>>
>> v4: Addressed Shashank's review comments
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 4 ++--
>> include/linux/hdmi.h | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>I haven't really looked at this series in depth, but just a quick drive-by
>comment:
>it doesn't look like this patch touches i915, so the "drm/i915:" headline
>prefix
>should probably just be "drm:" and you might want to move it earlier in the
>series
>so that all the core patches come before all the i915 patches.
Sure Matt, will update this as part of next version.
Regards,
Uma Shankar
>
>Matt
>
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index df27012..5592c9b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3850,8 +3850,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
>> return edid_ext[2] &
>> (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>> BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> - BIT(HDMI_EOTF_SMPTE_ST2084));
>> -
>> + BIT(HDMI_EOTF_SMPTE_ST2084) |
>> + BIT(HDMI_EOTF_BT_2100_HLG));
>> }
>>
>> static uint8_t hdr_metadata_type(const u8 *edid_ext) diff --git
>> a/include/linux/hdmi.h b/include/linux/hdmi.h index ce00e1e..b5346c3
>> 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -146,6 +146,7 @@ enum hdmi_eotf {
>> HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>> HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>> HDMI_EOTF_SMPTE_ST2084,
>> +HDMI_EOTF_BT_2100_HLG,
>> };
>>
>> struct hdmi_avi_infoframe {
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request_alloc retirement to local context
Quoting Tvrtko Ursulin (2019-01-09 11:56:15)
>
> On 07/01/2019 15:29, Chris Wilson wrote:
> > In the continual quest to reduce the amount of global work required when
> > submitting requests, replace i915_retire_requests() after allocation
> > failure to retiring just our ring.
> >
> > References: 11abf0c5a021 ("drm/i915: Limit the backpressure for
> > i915_request allocation")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 33 +
> > 1 file changed, 24 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 1e158eb8cb97..9ba218c6029b 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -477,6 +477,29 @@ submit_notify(struct i915_sw_fence *fence, enum
> > i915_sw_fence_notify state)
> > return NOTIFY_DONE;
> > }
> >
> > +static noinline struct i915_request *
> > +i915_request_alloc_slow(struct intel_context *ce)
> > +{
> > + struct intel_ring *ring = ce->ring;
> > + struct i915_request *rq, *next;
> > +
> > + list_for_each_entry_safe(rq, next, >request_list, ring_link) {
> > + /* Ratelimit ourselves to prevent oom from malicious clients
> > */
> > + if (>ring_link == >request_list) {
>
> list_is_last(next, >request_list) ?
Tried it (needs list_is_last(>ring_link,...)), but I slightly
preferred not implying that next was a valid request here, and keeping
the matching form to list termination.
> > + cond_synchronize_rcu(rq->rcustate);
> > + break; /* keep the last objects for the next request
> > */
> > + }
> > +
> > + if (!i915_request_completed(rq))
> > + break;
> > +
> > + /* Retire our old requests in the hope that we free some */
> > + i915_request_retire(rq);
> The RCU wait against the last submitted rq is also gone. Now it only
> sync against the next to last rq, unless there is more than two live
> requests. Is this what you intended?
Nah, I was trying to be too smart, forgetting that we didn't walk the
entire list. The RCU wait is against to the last rq (since next is the
list head at that point, so unchanged wrt to using list_last_entry), but
we break on seeing a busy request, so no ratelimiting if you keep the GPU
busy (not quite as intended!).
> If the ring timeline has is a list of r-r-r-R-R-R (r=completed,
> R=pending) then it looks like it will not sync on anything.
>
> And if the list is r-r-r-r it will sync against a completed rq. Which I
> hope is a no-op, but still, the loop logic looks potentially dodgy.
>
> It also has a higher level vulnerability to one hog timeline starving
> the rest I think.
Also? Other than forgetting the earlier break preventing the throtting,
what else do you see wrong with throttling along a timeline/ring?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request_alloc retirement to local context
On 07/01/2019 15:29, Chris Wilson wrote:
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 33 +
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..9ba218c6029b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,29 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq, *next;
+
+ list_for_each_entry_safe(rq, next, >request_list, ring_link) {
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ if (>ring_link == >request_list) {
list_is_last(next, >request_list) ?
+ cond_synchronize_rcu(rq->rcustate);
+ break; /* keep the last objects for the next request */
+ }
+
+ if (!i915_request_completed(rq))
+ break;
+
+ /* Retire our old requests in the hope that we free some */
+ i915_request_retire(rq);
The RCU wait against the last submitted rq is also gone. Now it only
sync against the next to last rq, unless there is more than two live
requests. Is this what you intended?
If the ring timeline has is a list of r-r-r-R-R-R (r=completed,
R=pending) then it looks like it will not sync on anything.
And if the list is r-r-r-r it will sync against a completed rq. Which I
hope is a no-op, but still, the loop logic looks potentially dodgy.
It also has a higher level vulnerability to one hog timeline starving
the rest I think.
Regards,
Tvrtko
+ }
+
+ return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -559,15 +582,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
- i915_retire_requests(i915);
-
- /* Ratelimit ourselves to prevent oom from malicious clients */
- rq = i915_gem_active_raw(>ring->timeline->last_request,
->drm.struct_mutex);
- if (rq)
- cond_synchronize_rcu(rq->rcustate);
-
- rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
+ rq = i915_request_alloc_slow(ce);
if (!rq) {
ret = -ENOMEM;
goto err_unreserve;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/46] drm/i915: Markup paired operations on wakerefs
Quoting Mika Kuoppala (2019-01-09 09:23:53) > I should have been more specific. My concern was on documenting > the changing return values. The interface isn't documented, there's nothing in the header about the functions? Where else would it be? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/46] drm/i915: Mark up debugfs with rpm wakeref tracking
Quoting Mika Kuoppala (2019-01-09 10:20:26) > Chris Wilson writes: > > @@ -1735,29 +1743,30 @@ static int i915_emon_status(struct seq_file *m, > > void *unused) > > struct drm_i915_private *dev_priv = node_to_i915(m->private); > > struct drm_device *dev = _priv->drm; > > unsigned long temp, chipset, gfx; > > + intel_wakeref_t wakeref; > > int ret; > > > > if (!IS_GEN(dev_priv, 5)) > > return -ENODEV; > > > > - intel_runtime_pm_get(dev_priv); > > - > > ret = mutex_lock_interruptible(>struct_mutex); > > if (ret) > > return ret; > > > > + wakeref = intel_runtime_pm_get(dev_priv); > > + > > temp = i915_mch_val(dev_priv); > > chipset = i915_chipset_val(dev_priv); > > gfx = i915_gfx_val(dev_priv); > > mutex_unlock(>struct_mutex); > > > > + intel_runtime_pm_put(dev_priv, wakeref); > > + > > I am a little surprised if this was the only callsite > for tighter scoping in this file. It's a recent regression. (Despite a patch to fix it correctly... Bitter, moi?) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/46] drm/i915/perf: Track the rpm wakeref
Quoting Mika Kuoppala (2019-01-09 10:30:56)
> Chris Wilson writes:
>
> > Keep track of our wakeref used to keep the device awake so we can catch
> > any leak.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/i915_perf.c | 10 +-
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a20bd2ec48de..bf25ae92f5de 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1320,6 +1320,8 @@ struct i915_perf_stream {
> >*/
> > struct list_head link;
> >
> > + intel_wakeref_t wakeref;
> > +
> > /**
> >* @sample_flags: Flags representing the `DRM_I915_PERF_PROP_SAMPLE_*`
> >* properties given when opening a stream, representing the contents
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index e4dfd1477c78..b0cbad2e83c5 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1364,14 +1364,14 @@ static void i915_oa_stream_destroy(struct
> > i915_perf_stream *stream)
> >
> > free_oa_buffer(dev_priv);
> >
> > + put_oa_config(dev_priv, stream->oa_config);
> > +
>
> Hmm you wanted to put this inside the wakeref. But
> I fail to see the reason.
I thought I undid it. Hazy memory says setup does it inside, but
teardown outside; consistency!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/46] drm/i915/panel: Track temporary rpm wakeref
Chris Wilson writes: > Keep track of the temporary rpm wakeref used for panel backlight access, > so that we can cancel it immediately upon release and so more clearly > identify leaks. > > Signed-off-by: Chris Wilson > Cc: Jani Nikula Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_panel.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index c2b7455a023e..93a2e4b5c54c 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -1203,17 +1203,18 @@ static int > intel_backlight_device_get_brightness(struct backlight_device *bd) > struct intel_connector *connector = bl_get_data(bd); > struct drm_device *dev = connector->base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > + intel_wakeref_t wakeref; > u32 hw_level; > int ret; > > - intel_runtime_pm_get(dev_priv); > + wakeref = intel_runtime_pm_get(dev_priv); > drm_modeset_lock(>mode_config.connection_mutex, NULL); > > hw_level = intel_panel_get_backlight(connector); > ret = scale_hw_to_user(connector, hw_level, bd->props.max_brightness); > > drm_modeset_unlock(>mode_config.connection_mutex); > - intel_runtime_pm_put_unchecked(dev_priv); > + intel_runtime_pm_put(dev_priv, wakeref); > > return ret; > } > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/46] drm/i915/hotplug: Track temporary rpm wakeref
Chris Wilson writes:
> Keep track of the temporary rpm wakeref inside hotplug detection, so
> that we can cancel it immediately upon release and so clearly identify
> leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_hotplug.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 067277ca7cff..6df8820b8b80 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -227,9 +227,10 @@ static void intel_hpd_irq_storm_reenable_work(struct
> work_struct *work)
> container_of(work, typeof(*dev_priv),
>hotplug.reenable_work.work);
> struct drm_device *dev = _priv->drm;
> + intel_wakeref_t wakeref;
> enum hpd_pin pin;
>
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
>
> spin_lock_irq(_priv->irq_lock);
> for_each_hpd_pin(pin) {
> @@ -262,7 +263,7 @@ static void intel_hpd_irq_storm_reenable_work(struct
> work_struct *work)
> dev_priv->display.hpd_irq_setup(dev_priv);
> spin_unlock_irq(_priv->irq_lock);
>
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> }
>
> bool intel_encoder_hotplug(struct intel_encoder *encoder,
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/46] drm/i915/fb: Track rpm wakerefs
Chris Wilson writes:
> Keep track of the rpm wakeref used for framebuffer access so that we can
> cancel upon release and so more clearly identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 +++--
> drivers/gpu/drm/i915/intel_fbdev.c | 9 +
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c6000aa47a8d..ea70cb8cf50a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2024,6 +2024,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> struct drm_device *dev = fb->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> + intel_wakeref_t wakeref;
> struct i915_vma *vma;
> unsigned int pinctl;
> u32 alignment;
> @@ -2047,7 +2048,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
>* intel_runtime_pm_put(), so it is correct to wrap only the
>* pin/unpin/fence and not more.
>*/
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
>
> atomic_inc(_priv->gpu_error.pending_fb_pin);
>
> @@ -2102,7 +2103,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> err:
> atomic_dec(_priv->gpu_error.pending_fb_pin);
>
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> return vma;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 11d877b908e2..de14cd78aa0f 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -178,8 +178,9 @@ static int intelfb_create(struct drm_fb_helper *helper,
> const struct i915_ggtt_view view = {
> .type = I915_GGTT_VIEW_NORMAL,
> };
> - struct fb_info *info;
> struct drm_framebuffer *fb;
> + intel_wakeref_t wakeref;
> + struct fb_info *info;
> struct i915_vma *vma;
> unsigned long flags = 0;
> bool prealloc = false;
> @@ -210,7 +211,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> }
>
> mutex_lock(>struct_mutex);
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
>
> /* Pin the GGTT vma for our access via info->screen_base.
>* This also validates that any existing fb inherited from the
> @@ -277,7 +278,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> ifbdev->vma = vma;
> ifbdev->vma_flags = flags;
>
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> mutex_unlock(>struct_mutex);
> vga_switcheroo_client_fb_set(pdev, info);
> return 0;
> @@ -285,7 +286,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> out_unpin:
> intel_unpin_fb_vma(vma, flags);
> out_unlock:
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> mutex_unlock(>struct_mutex);
> return ret;
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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/5] drm/i915/backlight: Restore backlight on resume, v3. (rev2)
== Series Details ==
Series: series starting with [1/5] drm/i915/backlight: Restore backlight on
resume, v3. (rev2)
URL : https://patchwork.freedesktop.org/series/54896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5382 -> Patchwork_11261
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54896/revisions/2/
Known issues
Here are the changes found in Patchwork_11261 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998] +1
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: PASS -> FAIL [fdo#103167]
- fi-hsw-peppy: PASS -> DMESG-FAIL [fdo#102614]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{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#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
Participating hosts (47 -> 45)
--
Additional (2): fi-icl-y fi-snb-2520m
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5382 -> Patchwork_11261
CI_DRM_5382: f4b4417009b26e8f389f9d4c5c35e2a8daa67c9f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4757: 738f43a54d626f08e250c926a5aeec53458fbd3c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11261: 53109c96d2f1641d71adc656f23f5ca304d592b7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
53109c96d2f1 drm/i915: Re-enable fastset by default
55a70fd879df drm/i915: Make HW readout mark CRTC scaler as in use.
eb50555aeccd drm/i915: Enable fastset for non-boot modesets.
fdf463f0ab72 drm/i915/backlight: Fix backlight takeover on LPT, v3.
0cd0b789cc0b drm/i915/backlight: Restore backlight on resume, v3.
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11261/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/46] drm/i915/gem: Track the rpm wakerefs
Chris Wilson writes:
> Keep track of the temporary rpm wakerefs used for user access to the
> device, so that we can cancel them upon release and clearly identify any
> leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_gem.c| 47 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 ++-
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 ++-
> drivers/gpu/drm/i915/i915_gem_gtt.c| 22 ++
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 32 +--
> drivers/gpu/drm/i915/intel_engine_cs.c | 12 --
> drivers/gpu/drm/i915/intel_uncore.c| 5 ++-
> 7 files changed, 81 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 27f207cbabd9..e04dadeca879 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -786,6 +786,8 @@ fb_write_origin(struct drm_i915_gem_object *obj, unsigned
> int domain)
>
> void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv)
> {
> + intel_wakeref_t wakeref;
> +
> /*
>* No actual flushing is required for the GTT write domain for reads
>* from the GTT domain. Writes to it "immediately" go to main memory
> @@ -812,13 +814,13 @@ void i915_gem_flush_ggtt_writes(struct drm_i915_private
> *dev_priv)
>
> i915_gem_chipset_flush(dev_priv);
>
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
> spin_lock_irq(_priv->uncore.lock);
>
> POSTING_READ_FW(RING_HEAD(RENDER_RING_BASE));
>
> spin_unlock_irq(_priv->uncore.lock);
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> }
>
> static void
> @@ -1070,6 +1072,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct i915_ggtt *ggtt = >ggtt;
> + intel_wakeref_t wakeref;
> struct drm_mm_node node;
> struct i915_vma *vma;
> void __user *user_data;
> @@ -1080,7 +1083,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
> if (ret)
> return ret;
>
> - intel_runtime_pm_get(i915);
> + wakeref = intel_runtime_pm_get(i915);
> vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
> PIN_MAPPABLE |
> PIN_NONFAULT |
> @@ -1153,7 +1156,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
> i915_vma_unpin(vma);
> }
> out_unlock:
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
> mutex_unlock(>drm.struct_mutex);
>
> return ret;
> @@ -1254,6 +1257,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object
> *obj,
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct i915_ggtt *ggtt = >ggtt;
> + intel_wakeref_t wakeref;
> struct drm_mm_node node;
> struct i915_vma *vma;
> u64 remain, offset;
> @@ -1272,13 +1276,14 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object
> *obj,
>* This easily dwarfs any performance advantage from
>* using the cache bypass of indirect GGTT access.
>*/
> - if (!intel_runtime_pm_get_if_in_use(i915)) {
> + wakeref = intel_runtime_pm_get_if_in_use(i915);
> + if (!wakeref) {
> ret = -EFAULT;
> goto out_unlock;
> }
> } else {
> /* No backing pages, no fallback, we must force GGTT access */
> - intel_runtime_pm_get(i915);
> + wakeref = intel_runtime_pm_get(i915);
> }
>
> vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
> @@ -1360,7 +1365,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object
> *obj,
> i915_vma_unpin(vma);
> }
> out_rpm:
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
> out_unlock:
> mutex_unlock(>drm.struct_mutex);
> return ret;
> @@ -1865,6 +1870,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct i915_ggtt *ggtt = _priv->ggtt;
> bool write = area->vm_flags & VM_WRITE;
> + intel_wakeref_t wakeref;
> struct i915_vma *vma;
> pgoff_t page_offset;
> int ret;
> @@ -1894,7 +1900,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> if (ret)
> goto err;
>
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
>
> ret = i915_mutex_lock_interruptible(dev);
> if (ret)
> @@ -1972,7 +1978,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> err_unlock:
> mutex_unlock(>struct_mutex);
> err_rpm:
> - intel_runtime_pm_put_unchecked(dev_priv);
> +
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
Quoting Kenneth Graunke (2019-01-09 09:02:35) > Does it work if you emit 3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP after > MI_SET_CONTEXT? That was the source of most CONSTANT_BUFFER hangs > I saw on Broadwater/Crestline. Notably, it's also a bug that was > fixed on Eaglelake/Cantiga... Thanks for the suggestion, but alas no. Which makes sense if my understanding is correct and it is the immediate execution of CONSTANT_BUFFER inside the context image that is triggering the hang -- we don't even reach the next primitive. I think have DevCL happy (at least as far as a few runs through piglit can determine), now to double check DevCTG, DevILK. Alas I have no gen4/gen5 desktop machines to hand. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/46] drm/i915/guc: Track the rpm wakeref
Chris Wilson writes:
> Keep track of our acquired wakeref for interacting with the guc, so that
> we can cancel it upon release and so clearly identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_guc_log.c | 15 +--
> drivers/gpu/drm/i915/intel_huc.c | 5 +++--
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
> b/drivers/gpu/drm/i915/intel_guc_log.c
> index 1b1581a42aa1..20c0b36d748e 100644
> --- a/drivers/gpu/drm/i915/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -436,6 +436,7 @@ static void guc_log_capture_logs(struct intel_guc_log
> *log)
> {
> struct intel_guc *guc = log_to_guc(log);
> struct drm_i915_private *dev_priv = guc_to_i915(guc);
> + intel_wakeref_t wakeref;
>
> guc_read_update_log_buffer(log);
>
> @@ -443,9 +444,9 @@ static void guc_log_capture_logs(struct intel_guc_log
> *log)
>* Generally device is expected to be active only at this
>* time, so get/put should be really quick.
>*/
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
> guc_action_flush_log_complete(guc);
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> }
>
> int intel_guc_log_create(struct intel_guc_log *log)
> @@ -505,6 +506,7 @@ int intel_guc_log_set_level(struct intel_guc_log *log,
> u32 level)
> {
> struct intel_guc *guc = log_to_guc(log);
> struct drm_i915_private *dev_priv = guc_to_i915(guc);
> + intel_wakeref_t wakeref;
> int ret;
>
> BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
> @@ -524,11 +526,11 @@ int intel_guc_log_set_level(struct intel_guc_log *log,
> u32 level)
> goto out_unlock;
> }
>
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
> ret = guc_action_control_log(guc, GUC_LOG_LEVEL_IS_VERBOSE(level),
>GUC_LOG_LEVEL_IS_ENABLED(level),
>GUC_LOG_LEVEL_TO_VERBOSITY(level));
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> if (ret) {
> DRM_DEBUG_DRIVER("guc_log_control action failed %d\n", ret);
> goto out_unlock;
> @@ -601,6 +603,7 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
> {
> struct intel_guc *guc = log_to_guc(log);
> struct drm_i915_private *i915 = guc_to_i915(guc);
> + intel_wakeref_t wakeref;
>
> /*
>* Before initiating the forceful flush, wait for any pending/ongoing
> @@ -608,9 +611,9 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
>*/
> flush_work(>relay.flush_work);
>
> - intel_runtime_pm_get(i915);
> + wakeref = intel_runtime_pm_get(i915);
> guc_action_flush_log(guc);
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
>
> /* GuC would have updated log buffer by now, so capture it */
> guc_log_capture_logs(log);
> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> b/drivers/gpu/drm/i915/intel_huc.c
> index c2b076e9bada..3e8c18b6a42d 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -115,14 +115,15 @@ int intel_huc_auth(struct intel_huc *huc)
> int intel_huc_check_status(struct intel_huc *huc)
> {
> struct drm_i915_private *dev_priv = huc_to_i915(huc);
> + intel_wakeref_t wakeref;
> bool status;
>
> if (!HAS_HUC(dev_priv))
> return -ENODEV;
>
> - intel_runtime_pm_get(dev_priv);
> + wakeref = intel_runtime_pm_get(dev_priv);
> status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
>
> return status;
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for MST refcounting/atomic helpers cleanup (rev5)
== Series Details == Series: MST refcounting/atomic helpers cleanup (rev5) URL : https://patchwork.freedesktop.org/series/54030/ State : success == Summary == CI Bug Log - changes from CI_DRM_5380_full -> Patchwork_11258_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11258_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-iclb: NOTRUN -> FAIL [fdo#103158] * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-skl: NOTRUN -> FAIL [fdo#103158] +1 * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: PASS -> TIMEOUT [fdo#108039] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-crc-primary-basic: - shard-iclb: NOTRUN -> FAIL [fdo#107725] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] * igt@kms_color@pipe-a-ctm-max: - shard-skl: NOTRUN -> FAIL [fdo#108147] * igt@kms_color@pipe-a-gamma: - shard-skl: NOTRUN -> FAIL [fdo#104782] * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x42-random: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-skl: PASS -> FAIL [fdo#108472] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-farfromfence: - shard-skl: NOTRUN -> FAIL [fdo#103167] +6 * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#106978] / [fdo#107773] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt: - shard-skl: PASS -> FAIL [fdo#103167] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-apl: PASS -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-iclb: PASS -> FAIL [fdo#103166] +3 * igt@kms_psr@no_drrs: - shard-iclb: PASS -> FAIL [fdo#108341] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-apl: PASS -> DMESG-FAIL [fdo#108950] * igt@pm_rpm@gem-mmap-gtt: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +8 * igt@syncobj_basic@bad-pad-fd-to-handle: - shard-apl: PASS -> INCOMPLETE [fdo#103927] Possible fixes * igt@gem_exec_whisper@normal: - shard-skl: TIMEOUT [fdo#108592] -> PASS * igt@gem_workarounds@suspend-resume-fd: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS +1 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-iclb: DMESG-WARN [fdo#107956] -> PASS * igt@kms_cursor_crc@cursor-128x128-random: - shard-kbl: DMESG-WARN [fdo#103313] -> PASS * igt@kms_cursor_crc@cursor-64x64-random: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: - shard-iclb: FAIL [fdo#103355] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: -
Re: [Intel-gfx] [PATCH 10/46] drm/i915/pmu: Track rpm wakeref
Chris Wilson writes:
> Track the wakeref used for temporary access to the device, and discard
> it upon release so that leaks can be identified.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index c99fcfce79d5..3d43fc9dd25d 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -167,6 +167,7 @@ engines_sample(struct drm_i915_private *dev_priv,
> unsigned int period_ns)
> {
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
> + intel_wakeref_t wakeref;
> bool fw = false;
>
> if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
> @@ -175,7 +176,8 @@ engines_sample(struct drm_i915_private *dev_priv,
> unsigned int period_ns)
> if (!dev_priv->gt.awake)
> return;
>
> - if (!intel_runtime_pm_get_if_in_use(dev_priv))
> + wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
> + if (!wakeref)
> return;
>
> for_each_engine(engine, dev_priv, id) {
> @@ -210,7 +212,7 @@ engines_sample(struct drm_i915_private *dev_priv,
> unsigned int period_ns)
> if (fw)
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>
> - intel_runtime_pm_put_unchecked(dev_priv);
> + intel_runtime_pm_put(dev_priv, wakeref);
> }
>
> static void
> @@ -227,11 +229,15 @@ frequency_sample(struct drm_i915_private *dev_priv,
> unsigned int period_ns)
> u32 val;
>
> val = dev_priv->gt_pm.rps.cur_freq;
> - if (dev_priv->gt.awake &&
> - intel_runtime_pm_get_if_in_use(dev_priv)) {
> - val = intel_get_cagf(dev_priv,
> - I915_READ_NOTRACE(GEN6_RPSTAT1));
> - intel_runtime_pm_put_unchecked(dev_priv);
> + if (dev_priv->gt.awake) {
> + intel_wakeref_t wakeref =
> + intel_runtime_pm_get_if_in_use(dev_priv);
> +
> + if (wakeref) {
> + val = intel_get_cagf(dev_priv,
> +
> I915_READ_NOTRACE(GEN6_RPSTAT1));
> + intel_runtime_pm_put(dev_priv, wakeref);
> + }
> }
>
> add_sample_mult(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
> @@ -443,12 +449,14 @@ static u64 __get_rc6(struct drm_i915_private *i915)
> static u64 get_rc6(struct drm_i915_private *i915)
> {
> #if IS_ENABLED(CONFIG_PM)
> + intel_wakeref_t wakeref;
> unsigned long flags;
> u64 val;
>
> - if (intel_runtime_pm_get_if_in_use(i915)) {
> + wakeref = intel_runtime_pm_get_if_in_use(i915);
> + if (wakeref) {
> val = __get_rc6(i915);
> - intel_runtime_pm_put_unchecked(i915);
> + intel_runtime_pm_put(i915, wakeref);
>
> /*
>* If we are coming back from being runtime suspended we must
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
