Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8)
Hi, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Aditya Swarup > Sent: lauantai 4. toukokuuta 2019 2.04 > To: intel-gfx@lists.freedesktop.org > Cc: Peres, Martin > Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set > GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8) > > On Tue, Apr 30, 2019 at 01:46:15PM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color > (rev8) > > URL : https://patchwork.freedesktop.org/series/58912/ > > State : failure > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_6012_full -> Patchwork_12900_full > > > > > > Summary > > --- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_12900_full absolutely need > > to > be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_12900_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_12900_full: > > > > ### IGT changes ### > > > > Possible regressions > > > > * igt@gem_caching@read-writes: > > - shard-skl: [PASS][1] -> [INCOMPLETE][2] +6 similar issues > >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > skl9/igt@gem_cach...@read-writes.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/ig > > t@gem_cach...@read-writes.html > > > > * igt@gem_mmap_gtt@forked-big-copy-odd: > > - shard-skl: NOTRUN -> [INCOMPLETE][3] +1 similar issue > >[3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/ig > > t@gem_mmap_...@forked-big-copy-odd.html > Hi Martin, > > These failures shouldn't be due to my patch. Is there a separate bug filed for > gem_caching and gem_mmap_gtt failures? Yes, this still I guess due to : https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/run25.log => Tomi, still happening: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Br, Jani > > Regards, > Aditya Swarup > > > > > > Warnings > > > > * igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size: > > - shard-skl: [SKIP][4] ([fdo#109271]) -> [INCOMPLETE][5] +1 > > similar issue > >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > skl6/igt@kms_cursor_leg...@cursorb-vs-flipa-varying-size.html > >[5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl8/ig > > t@kms_cursor_leg...@cursorb-vs-flipa-varying-size.html > > > > > > Known issues > > > > > > Here are the changes found in Patchwork_12900_full that come from known > issues: > > > > ### IGT changes ### > > > > Issues hit > > > > * igt@gem_cpu_reloc@forked: > > - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([fdo#107713] / > > [fdo#109100]) > >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > iclb4/igt@gem_cpu_re...@forked.html > >[7]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-iclb3/i > > gt@gem_cpu_re...@forked.html > > > > * igt@i915_pm_rpm@pm-tiling: > > - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([fdo#107807]) > >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > skl10/igt@i915_pm_...@pm-tiling.html > >[9]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/ig > > t@i915_pm_...@pm-tiling.html > > > > * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: > > - shard-snb: [PASS][10] -> [SKIP][11] ([fdo#109271] / > > [fdo#109278]) +1 > similar issue > >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > snb1/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html > >[11]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-snb6/ig > > t@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html > > > > * igt@kms_cursor_crc@cursor-64x21-offscreen: > > - shard-skl: [PASS][12] -> [FAIL][13] ([fdo#103232]) > >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > skl2/igt@kms_cursor_...@cursor-64x21-offscreen.html > >[13]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl3/ig > > t@kms_cursor_...@cursor-64x21-offscreen.html > > > > * igt@kms_flip@flip-vs-suspend-interruptible: > > - shard-glk: [PASS][14] -> [INCOMPLETE][15] ([fdo#103359] / > [k.org#198133]) +2 similar issues > >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- > glk5/igt@kms_f...@flip-vs-suspend-interruptible.html > >[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwor
[Intel-gfx] ✓ Fi.CI.IGT: success for Refactor to expand subslice mask (rev8)
== Series Details == Series: Refactor to expand subslice mask (rev8) URL : https://patchwork.freedesktop.org/series/59742/ State : success == Summary == CI Bug Log - changes from CI_DRM_6043_full -> Patchwork_12965_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12965_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-kbl6/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-kbl1/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108] / [fdo#107773] / [fdo#110581]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl9/igt@gem_soft...@noreloc-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-skl5/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rpm@pm-caching: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl9/igt@i915_pm_...@pm-caching.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-skl6/igt@i915_pm_...@pm-caching.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#104873]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103184] / [fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl5/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-skl9/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@2x-flip-vs-suspend-interruptible: - shard-glk: [PASS][11] -> [INCOMPLETE][12] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-glk3/igt@kms_f...@2x-flip-vs-suspend-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-glk7/igt@kms_f...@2x-flip-vs-suspend-interruptible.html * igt@kms_flip@2x-plain-flip-fb-recreate: - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#100368]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-glk9/igt@kms_f...@2x-plain-flip-fb-recreate.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-glk9/igt@kms_f...@2x-plain-flip-fb-recreate.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl8/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-skl2/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103167] / [fdo#110379]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-skl9/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108] / [fdo#110581]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl6/igt@kms_frontbuffer_track...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-skl2/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#103167]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/shard-skl5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt.html [24]: https://intel-gfx-c
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev10)
== Series Details == Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev10) URL : https://patchwork.freedesktop.org/series/58912/ State : success == Summary == CI Bug Log - changes from CI_DRM_6041_full -> Patchwork_12964_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12964_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-apl2/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-apl5/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-hsw: [PASS][3] -> [DMESG-WARN][4] ([fdo#108686]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-hsw1/igt@gem_tiled_swapp...@non-threaded.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-hsw2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rpm@dpms-lpsp: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#107807] / [fdo#110581]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl1/igt@i915_pm_...@dpms-lpsp.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-skl9/igt@i915_pm_...@dpms-lpsp.html * igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-snb4/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-snb4/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103184] / [fdo#103232]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl8/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-skl6/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@2x-flip-vs-suspend-interruptible: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk6/igt@kms_f...@2x-flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-glk3/igt@kms_f...@2x-flip-vs-suspend-interruptible.html - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([fdo#103540] / [fdo#110581]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-hsw6/igt@kms_f...@2x-flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-hsw7/igt@kms_f...@2x-flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +10 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_plane_cursor@pipe-a-viewport-size-128: - shard-snb: [PASS][19] -> [SKIP][20] ([fdo#109271]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-snb4/igt@kms_plane_cur...@pipe-a-viewport-size-128.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-snb4/igt@kms_plane_cur...@pipe-a-viewport-size-128.html * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-glk: [PASS][21] -> [SKIP][22] ([fdo#109271] / [fdo#109278]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-pixel-format.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/shard-glk8/igt@kms_plane_scal...@pipe-a-scaler-with-pixel-format.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr@psr2_primary_page_flip
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Replace intel_ddi_pll_init()
== Series Details == Series: series starting with [1/2] drm/i915: Replace intel_ddi_pll_init() URL : https://patchwork.freedesktop.org/series/60272/ State : success == Summary == CI Bug Log - changes from CI_DRM_6041_full -> Patchwork_12963_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12963_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#107807] / [fdo#110581]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl7/igt@i915_pm_...@dpms-mode-unset-lpsp.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-skl6/igt@i915_pm_...@dpms-mode-unset-lpsp.html * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-apl3/igt@kms_cursor_...@cursor-128x128-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-apl1/igt@kms_cursor_...@cursor-128x128-suspend.html * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl10/igt@kms_cursor_...@cursor-64x64-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-skl1/igt@kms_cursor_...@cursor-64x64-suspend.html * igt@kms_flip@2x-flip-vs-suspend-interruptible: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk6/igt@kms_f...@2x-flip-vs-suspend-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-glk5/igt@kms_f...@2x-flip-vs-suspend-interruptible.html * igt@kms_flip@2x-modeset-vs-vblank-race: - shard-glk: [PASS][9] -> [FAIL][10] ([fdo#103060]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk6/igt@kms_f...@2x-modeset-vs-vblank-race.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-glk5/igt@kms_f...@2x-modeset-vs-vblank-race.html * igt@kms_flip@busy-flip: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#110581]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb1/igt@kms_f...@busy-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-iclb1/igt@kms_f...@busy-flip.html * igt@kms_flip@flip-vs-suspend: - shard-snb: [PASS][13] -> [DMESG-WARN][14] ([fdo#102365]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-snb4/igt@kms_f...@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-snb6/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [fdo#110403]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_plane_low...@pipe-a-tiling-y.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/shard-iclb5/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_setmode@basic: - shard-apl:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
== Series Details == Series: series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register URL : https://patchwork.freedesktop.org/series/60271/ State : success == Summary == CI Bug Log - changes from CI_DRM_6041_full -> Patchwork_12962_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12962_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [FAIL][2] ([fdo#105957]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl1/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-skl1/igt@gem_...@reset-stress.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-apl2/igt@gem_workarou...@suspend-resume.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-apl1/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_rpm@drm-resources-equal: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl10/igt@i915_pm_...@drm-resources-equal.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-skl8/igt@i915_pm_...@drm-resources-equal.html * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([fdo#103313]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-kbl2/igt@kms_cursor_...@cursor-256x256-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-kbl5/igt@kms_cursor_...@cursor-256x256-suspend.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103184] / [fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl8/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-skl10/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-snb: [PASS][13] -> [DMESG-WARN][14] ([fdo#102365]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-snb5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-snb1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602]) +19 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-apl2/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-apl1/igt@kms_plane_multi...@atomic-pipe-c-tiling-yf.html * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-glk: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-pixel-format.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-glk1/igt@kms_plane_scal...@pipe-a-scaler-with-pixel-format.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr2_su@page_flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-iclb5/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/shard-iclb6/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_rotation_crc@multiplane-rotation: - shard-glk: [PASS][23] -> [DMESG-FAIL][24] ([fdo#105763] / [fdo#106538]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk8/igt@kms_rotation_...@multiplane-rotation.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/dp: Trigger modeset if master_crtc or slaves bitmask changes
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Manasi Navare
>Sent: Tuesday, April 23, 2019 8:49 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH v2 3/4] drm/i915/dp: Trigger modeset if master_crtc
>or slaves bitmask changes
>
>Add the comparison between the current state and new_crtc_state for newly
>added master_crtc pointer and slave bitmask so that if any of those change then
>the curernt master-slave links have changed and we need to reconfigure the
>transcoder port sync register and hence trigger a full modeset.
>
>Suggested-by: Ville Syrjälä
>Cc: Ville Syrjälä
>Cc: Maarten Lankhorst
>Cc: Matt Roper
>Signed-off-by: Manasi Navare
Looks good.
Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/intel_display.c | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index 81e8cb9fe221..4bd23e61c6fd 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -12524,6 +12524,11 @@ intel_pipe_config_compare(struct
>drm_i915_private *dev_priv,
> PIPE_CONF_CHECK_INFOFRAME(spd);
> PIPE_CONF_CHECK_INFOFRAME(hdmi);
>
>+ if (INTEL_GEN(dev_priv) >= 11) {
>+ PIPE_CONF_CHECK_I(trans_port_sync_slaves);
>+ PIPE_CONF_CHECK_P(master_crtc);
>+ }
>+
> #undef PIPE_CONF_CHECK_X
> #undef PIPE_CONF_CHECK_I
> #undef PIPE_CONF_CHECK_BOOL
>--
>2.19.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 v2 2/4] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Manasi Navare
>Sent: Tuesday, April 23, 2019 8:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Vetter, Daniel
>
>Subject: [Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Enable TRANSCODER PORT SYNC
>for tiled displays across separate ports
>
>In case of tiled displays where different tiles are displayed across different
>ports,
>we need to synchronize the transcoders involved.
>This patch implements the transcoder port sync feature for synchronizing one
>master transcoder with one or more slave transcoders. This is only enbaled in
^^^typo
Anusha
>slave transcoder and the master transcoder is unaware that it is operating in
>this
>mode.
>This has been tested with tiled display connected to ICL.
>
>v2:
>* Do not use RMW, just write to the register in commit (Jani N)
>
>Cc: Daniel Vetter
>Cc: Ville Syrjälä
>Cc: Maarten Lankhorst
>Cc: Matt Roper
>Cc: Jani Nikula
>Signed-off-by: Manasi Navare
>---
> drivers/gpu/drm/i915/intel_display.c | 58
> 1 file changed, 58 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index 92dea2231499..81e8cb9fe221 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -4020,6 +4020,61 @@ static void icl_set_pipe_chicken(struct intel_crtc
>*crtc)
> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> }
>
>+static void icl_set_transcoder_port_sync(struct intel_atomic_state
>*old_intel_state,
>+ const struct intel_crtc_state
>*crtc_state) {
>+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>+ struct intel_crtc_state *master_crtc_state = NULL;
>+ enum transcoder master_transcoder;
>+ u32 trans_ddi_func_ctl2_val;
>+ u8 master_select;
>+
>+ /*
>+ * Port Sync Mode cannot be enabled for DP MST
>+ */
>+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
>+ return;
>+
>+ /*
>+ * Configure the master select and enable Transcoder Port Sync for
>+ * Slave CRTCs transcoder.
>+ */
>+ if (!crtc_state->master_crtc)
>+ return;
>+
>+ master_crtc_state = intel_atomic_get_new_crtc_state(old_intel_state,
>+ crtc_state-
>>master_crtc);
>+ if (WARN_ON(!master_crtc_state))
>+ return;
>+
>+ master_transcoder = master_crtc_state->cpu_transcoder;
>+ switch (master_transcoder) {
>+ case TRANSCODER_A:
>+ master_select = 1;
>+ break;
>+ case TRANSCODER_B:
>+ master_select = 2;
>+ break;
>+ case TRANSCODER_C:
>+ master_select = 3;
>+ break;
>+ case TRANSCODER_EDP:
>+ default:
>+ master_select = 0;
>+ break;
>+ }
>+ /* Set the master select bits for Tranascoder Port Sync */
>+ trans_ddi_func_ctl2_val =
>(PORT_SYNC_MODE_MASTER_SELECT(master_select) &
>+ PORT_SYNC_MODE_MASTER_SELECT_MASK)
><<
>+ PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
>+ /* Enable Transcoder Port Sync */
>+ trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
>+
>+ I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
>+ trans_ddi_func_ctl2_val);
>+}
>+
> static void intel_update_pipe_config(const struct intel_crtc_state
>*old_crtc_state,
>const struct intel_crtc_state
>*new_crtc_state) { @@ -5971,6 +6026,9 @@ static void
>haswell_crtc_enable(struct intel_crtc_state *pipe_config,
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_set_pipe_timings(pipe_config);
>
>+ if (INTEL_GEN(dev_priv) >= 11)
>+ icl_set_transcoder_port_sync(old_intel_state, pipe_config);
>+
> intel_set_pipe_src_size(pipe_config);
>
> if (cpu_transcoder != TRANSCODER_EDP &&
>--
>2.19.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 v2 1/4] drm/i915/icl: Assign Master slave crtc links for Transcoder Port Sync
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Manasi Navare
>Sent: Tuesday, April 23, 2019 8:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Daniel Vetter
>Subject: [Intel-gfx] [PATCH v2 1/4] drm/i915/icl: Assign Master slave crtc
>links for
>Transcoder Port Sync
>
>In case of tiled displays when the two tiles are sent across two CRTCs over two
>separate DP SST connectors, we need a mechanism to synchronize the two CRTCs
>and their corresponding transcoders.
>So use the master-slave mode where there is one master corresponding to last
>horizontal and vertical tile that needs to be genlocked with all other slave
>tiles.
>This patch identifies saves the master CRTC pointer in all the slave CRTC
>states.
>This pointer is needed to select the master CRTC/transcoder while configuring
>transcoder port sync for the corresponding slaves.
>
>v2:
>* Move this to intel_mode_set_pipe_config(Jani N, Ville)
>* Use slave_bitmask to save associated slaves in master crtc state (Ville)
>
>Cc: Daniel Vetter
>Cc: Ville Syrjälä
>Cc: Maarten Lankhorst
>Cc: Matt Roper
>Signed-off-by: Manasi Navare
>---
> drivers/gpu/drm/i915/intel_display.c | 89
> drivers/gpu/drm/i915/intel_drv.h | 6 ++
> 2 files changed, 95 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index b276345779e6..92dea2231499 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -11316,6 +11316,86 @@ static int icl_check_nv12_planes(struct
>intel_crtc_state *crtc_state)
> return 0;
> }
>
>+static int icl_add_genlock_crtcs(struct drm_crtc *crtc,
>+ struct intel_crtc_state *crtc_state,
>+ struct drm_atomic_state *state)
>+{
>+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>+ struct drm_connector *master_connector, *connector;
>+ struct drm_connector_state *connector_state;
>+ struct drm_connector_list_iter conn_iter;
>+ struct drm_crtc *master_crtc = NULL;
>+ struct drm_crtc_state *master_crtc_state;
>+ int i, tile_group_id;
>+
>+ if (INTEL_GEN(dev_priv) < 11)
>+ return 0;
>+
>+ /*
>+ * In case of tiled displays there could be one or more slaves but
>there is
>+ * only one master. Lets make the CRTC used by the connector
>corresponding
>+ * to the last horizonal and last vertical tile a master/genlock CRTC.
>+ * All the other CRTCs corresponding to other tiles of the same Tile
>group
>+ * are the slave CRTCs and hold a pointer to their genlock CRTC.
>+ */
>+ for_each_new_connector_in_state(state, connector, connector_state, i)
>{
>+ if (connector_state->crtc != crtc)
>+ continue;
>+ if (!connector->has_tile)
>+ continue;
>+ if (connector->tile_h_loc == connector->num_h_tile - 1 &&
>+ connector->tile_v_loc == connector->num_v_tile - 1)
>+ continue;
>+ crtc_state->master_crtc = NULL;
>+ tile_group_id = connector->tile_group->id;
>+ drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
>+ drm_for_each_connector_iter(master_connector, &conn_iter) {
>+ struct drm_connector_state *master_conn_state =
>NULL;
>+
>+ if (!master_connector->has_tile)
>+ continue;
>+ if (master_connector->tile_h_loc != master_connector-
>>num_h_tile - 1 ||
>+ master_connector->tile_v_loc != master_connector-
>>num_v_tile - 1)
Will this ever be true? With the checks above (for slaves) we have iterated
over all slaves and potentially left with only master/last tile right?
Anusha
>+ continue;
>+ if (master_connector->tile_group->id != tile_group_id)
>+ continue;
>+
>+ master_conn_state =
>drm_atomic_get_connector_state(state,
>+
>master_connector);
>+ if (IS_ERR(master_conn_state)) {
>+ drm_connector_list_iter_end(&conn_iter);
>+ return PTR_ERR(master_conn_state);
>+ }
>+ if (master_conn_state->crtc) {
>+ master_crtc = master_conn_state->crtc;
>+ break;
>+ }
>+ }
>+ drm_connector_list_iter_end(&conn_iter);
>+
>+ if (!master_crtc) {
>+ DRM_DEBUG_KMS("Could not add Master CRTC for
>Slave CRTC %d\n",
>+connector_state->crtc->base.id);
>+ return -EINVAL;
>+ }
>+
>+ master_crtc_st
Re: [Intel-gfx] [PATCH v6 1/3] drm: Add CRTC background color property (v5)
On Thu, Apr 25, 2019 at 12:45:33PM +0200, Maarten Lankhorst wrote: > Op 26-02-2019 om 17:17 schreef Matt Roper: > > On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote: > >> Hey, > >> > >> Op 21-02-2019 om 01:28 schreef Matt Roper: > >>> Some display controllers can be programmed to present non-black colors > >>> for pixels not covered by any plane (or pixels covered by the > >>> transparent regions of higher planes). Compositors that want a UI with > >>> a solid color background can potentially save memory bandwidth by > >>> setting the CRTC background property and using smaller planes to display > >>> the rest of the content. > >>> > >>> To avoid confusion between different ways of encoding RGB data, we > >>> define a standard 64-bit format that should be used for this property's > >>> value. Helper functions and macros are provided to generate and dissect > >>> values in this standard format with varying component precision values. > >>> > >>> v2: > >>> - Swap internal representation's blue and red bits to make it easier > >>>to read if printed out. (Ville) > >>> - Document bgcolor property in drm_blend.c. (Sean Paul) > >>> - s/background_color/bgcolor/ for consistency between property name and > >>>value storage field. (Sean Paul) > >>> - Add a convenience function to attach property to a given crtc. > >>> > >>> v3: > >>> - Restructure ARGB component extraction macros to be easier to > >>>understand and enclose the parameters in () to avoid calculations > >>>if expressions are passed. (Sean Paul) > >>> - s/rgba/argb/ in helper function/macro names. Even though the idea is > >>>to not worry about the internal representation of the u64, it can > >>>still be confusing to look at code that uses 'rgba' terminology, but > >>>stores values with argb ordering. (Ville) > >>> > >>> v4: > >>> - Drop the bgcolor_changed flag. (Ville, Brian Starkey) > >>> - Clarify in kerneldoc that background color is expected to undergo the > >>>same pipe-level degamma/csc/gamma transformations that planes do. > >>>(Brian Starkey) > >>> - Update kerneldoc to indicate non-opaque colors are allowed, but are > >>>generally only useful in special cases such as when writeback > >>>connectors are used (Brian Starkey / Eric Anholt) > >>> > >>> v5: > >>> - Set crtc->state->bgcolor to solid black inside > >>>drm_crtc_add_bgcolor_property() in case drivers don't do this > >>>themselves. (Ville) > >>> - Add kerneldoc to drm_crtc_add_bgcolor_property() function. > >>> > >>> Cc: dri-de...@lists.freedesktop.org > >>> Cc: wei.c...@intel.com > >>> Cc: harish.krupo@intel.com > >>> Cc: Ville Syrjälä > >>> Cc: Sean Paul > >>> Cc: Brian Starkey > >>> Cc: Eric Anholt > >>> Cc: Stéphane Marchesin > >>> Cc: Daniel Vetter > >>> Signed-off-by: Matt Roper > >>> Reviewed-by(v2): Sean Paul > >>> Reviewed-by: Brian Starkey > >> I like how bgcolor is a u64 now, but there is an issue with setting > >> crtc->state->bgcolor in attaching the property. > >> > >> We should do it in atomic core init instead, like we already do for > >> connector/plane properties.. > >> > >> See for example https://patchwork.freedesktop.org/series/52363/ > >> > >> This was specificallly for the background color proposal, but we > >> probalby have to split out the non-trivial conversions of > >> __drm_atomic_helper_crtc_reset. > > Makes sense. What's the status of that patch? It looks like it has a > > lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking > > it? If you're still driving it forward, I can wait for that to land and > > then build on top of it. > > > > > > Matt > > > I've split out the patch and landed some of the preparation patches, it > should be good enough to unblock this patch series at least now. :) > Great, thanks! I've been traveling a bunch the last month and haven't had time to revisit this yet, but I'll come back and rebase / repost the series in the next week or so once I'm caught up again. Matt -- 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] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8)
On Tue, Apr 30, 2019 at 01:46:15PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color > (rev8) > URL : https://patchwork.freedesktop.org/series/58912/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_6012_full -> Patchwork_12900_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12900_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12900_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_12900_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_caching@read-writes: > - shard-skl: [PASS][1] -> [INCOMPLETE][2] +6 similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-skl9/igt@gem_cach...@read-writes.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/igt@gem_cach...@read-writes.html > > * igt@gem_mmap_gtt@forked-big-copy-odd: > - shard-skl: NOTRUN -> [INCOMPLETE][3] +1 similar issue >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/igt@gem_mmap_...@forked-big-copy-odd.html Hi Martin, These failures shouldn't be due to my patch. Is there a separate bug filed for gem_caching and gem_mmap_gtt failures? Regards, Aditya Swarup > > > Warnings > > * igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size: > - shard-skl: [SKIP][4] ([fdo#109271]) -> [INCOMPLETE][5] +1 > similar issue >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-skl6/igt@kms_cursor_leg...@cursorb-vs-flipa-varying-size.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl8/igt@kms_cursor_leg...@cursorb-vs-flipa-varying-size.html > > > Known issues > > > Here are the changes found in Patchwork_12900_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_cpu_reloc@forked: > - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([fdo#107713] / > [fdo#109100]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-iclb4/igt@gem_cpu_re...@forked.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-iclb3/igt@gem_cpu_re...@forked.html > > * igt@i915_pm_rpm@pm-tiling: > - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([fdo#107807]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-skl10/igt@i915_pm_...@pm-tiling.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/igt@i915_pm_...@pm-tiling.html > > * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: > - shard-snb: [PASS][10] -> [SKIP][11] ([fdo#109271] / > [fdo#109278]) +1 similar issue >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-snb1/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-snb6/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html > > * igt@kms_cursor_crc@cursor-64x21-offscreen: > - shard-skl: [PASS][12] -> [FAIL][13] ([fdo#103232]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-skl2/igt@kms_cursor_...@cursor-64x21-offscreen.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl3/igt@kms_cursor_...@cursor-64x21-offscreen.html > > * igt@kms_flip@flip-vs-suspend-interruptible: > - shard-glk: [PASS][14] -> [INCOMPLETE][15] ([fdo#103359] / > [k.org#198133]) +2 similar issues >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-glk5/igt@kms_f...@flip-vs-suspend-interruptible.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-glk7/igt@kms_f...@flip-vs-suspend-interruptible.html > - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([fdo#108566]) +1 > similar issue >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html > - shard-snb: [PASS][18] -> [INCOMPLETE][19] ([fdo#105411]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-snb5/igt@kms_f...@flip-vs-suspend-interruptible.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-snb1/igt@kms_f...@flip-vs-suspend-interruptible.html > > * igt@kms_fli
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Document that we implement WaIncreaseLatencyIPCEnabled
== Series Details == Series: series starting with [1/3] drm/i915: Document that we implement WaIncreaseLatencyIPCEnabled URL : https://patchwork.freedesktop.org/series/60266/ State : success == Summary == CI Bug Log - changes from CI_DRM_6041_full -> Patchwork_12961_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12961_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@medium-copy: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb7/igt@gem_mmap_...@medium-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-iclb1/igt@gem_mmap_...@medium-copy.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-apl4/igt@i915_susp...@fence-restore-untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-apl4/igt@i915_susp...@fence-restore-untiled.html * igt@kms_cursor_edge_walk@pipe-b-128x128-right-edge: - shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-snb6/igt@kms_cursor_edge_w...@pipe-b-128x128-right-edge.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-snb6/igt@kms_cursor_edge_w...@pipe-b-128x128-right-edge.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl8/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-skl8/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([fdo#102614]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-hsw2/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-hsw5/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl3/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-glk: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-pixel-format.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-glk8/igt@kms_plane_scal...@pipe-a-scaler-with-pixel-format.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr2_su@page_flip.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-iclb5/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_setmode@basic: - shard-kbl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-kbl2/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/shard-kbl2/igt@kms_setm...@basic.html Possible fixes * igt@debugfs_test@read_all_entries_display_off: - shard-skl: [INCOMPLETE][23] ([fdo#104108] / [fdo#110581]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/shard-skl5/igt@debugfs_test@read_all_entries_display_off.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork
[Intel-gfx] ✓ Fi.CI.BAT: success for Refactor to expand subslice mask (rev8)
== Series Details ==
Series: Refactor to expand subslice mask (rev8)
URL : https://patchwork.freedesktop.org/series/59742/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6043 -> Patchwork_12965
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12965 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12965, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12965:
### IGT changes ###
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [INCOMPLETE][1] ([fdo#103927] / [fdo#110581]) ->
[DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@dp-crc-fast:
- {fi-cml-u2}:[PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Known issues
Here are the changes found in Patchwork_12965 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] ([fdo#108602] /
[fdo#108744] / [fdo#110581])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([fdo#110512])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: [DMESG-WARN][9] ([fdo#110512]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [DMESG-FAIL][11] ([fdo#110235]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6043/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110512]: https://bugs.freedesktop.org/show_bug.cgi?id=110512
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
Participating hosts (53 -> 43)
--
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-j1900
fi-byt-squawks fi-bsw-cyan fi-gdg-551 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6043 -> Patchwork_12965
CI_DRM_6043: b33a03a0d9c2f7376b78c356d4e0e9e55f495f69 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12965: 8236a337793574e5ba805f69c4ac50598d6c7034 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8236a3377935 drm/i915: Expand subslice mask
9562a29d51ba drm/i915: Refactor sseu helper functions
2d091162979d drm/i915: Move calculation of subslices per slice to new function
5b5850b4867c drm/i915: Add macro for SSEU stride calculation
bde01fefeccf drm/i915: Use local variable for SSEU info in GETPARAM ioctl
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12965/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/int
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor to expand subslice mask (rev8)
== Series Details == Series: Refactor to expand subslice mask (rev8) URL : https://patchwork.freedesktop.org/series/59742/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Use local variable for SSEU info in GETPARAM ioctl Okay! Commit: drm/i915: Add macro for SSEU stride calculation Okay! Commit: drm/i915: Move calculation of subslices per slice to new function Okay! Commit: drm/i915: Refactor sseu helper functions Okay! Commit: drm/i915: Expand subslice mask +drivers/gpu/drm/i915/i915_drv.c:464:24: 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 Refactor to expand subslice mask (rev8)
== Series Details == Series: Refactor to expand subslice mask (rev8) URL : https://patchwork.freedesktop.org/series/59742/ State : warning == Summary == $ dim checkpatch origin/drm-tip bde01fefeccf drm/i915: Use local variable for SSEU info in GETPARAM ioctl 5b5850b4867c drm/i915: Add macro for SSEU stride calculation 2d091162979d drm/i915: Move calculation of subslices per slice to new function 9562a29d51ba drm/i915: Refactor sseu helper functions 8236a3377935 drm/i915: Expand subslice mask -:113: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv_' - possible side-effects? #113: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:546: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) -:113: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'sseu_' - possible side-effects? #113: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:546: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) -:113: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice_' - possible side-effects? #113: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:546: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) -:113: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'subslice_' - possible side-effects? #113: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:546: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) total: 0 errors, 0 warnings, 4 checks, 729 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Move calculation of subslices per slice to new function
Add a new function to return the number of subslices per slice to
consolidate code usage.
v2: rebase on changes to move sseu struct to intel_sseu.h
v3: add intel_* prefix to sseu_subslices_per_slice
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.h | 6 ++
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 4 ++--
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index d20b7f96907d..9618dff46d83 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -63,6 +63,12 @@ intel_sseu_from_device_info(const struct sseu_dev_info *sseu)
return value;
}
+static inline unsigned int
+intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
+{
+ return hweight8(sseu->subslice_mask[slice]);
+}
+
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..dceb32a16c5c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4187,7 +4187,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool
is_available_info,
sseu_subslice_total(sseu));
for (s = 0; s < fls(sseu->slice_mask); s++) {
seq_printf(m, " %s Slice%i subslices: %u\n", type,
- s, hweight8(sseu->subslice_mask[s]));
+ s, intel_sseu_subslices_per_slice(sseu, s));
}
seq_printf(m, " %s EU Total: %u\n", type,
sseu->eu_total);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 6af480b95bc6..9d6b9c45bc5e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -93,7 +93,7 @@ static void sseu_dump(const struct sseu_dev_info *sseu,
struct drm_printer *p)
drm_printf(p, "subslice total: %u\n", sseu_subslice_total(sseu));
for (s = 0; s < sseu->max_slices; s++) {
drm_printf(p, "slice%d: %u subslices, mask=%04x\n",
- s, hweight8(sseu->subslice_mask[s]),
+ s, intel_sseu_subslices_per_slice(sseu, s),
sseu->subslice_mask[s]);
}
drm_printf(p, "EU total: %u\n", sseu->eu_total);
@@ -126,7 +126,7 @@ void intel_device_info_dump_topology(const struct
sseu_dev_info *sseu,
for (s = 0; s < sseu->max_slices; s++) {
drm_printf(p, "slice%d: %u subslice(s) (0x%hhx):\n",
- s, hweight8(sseu->subslice_mask[s]),
+ s, intel_sseu_subslices_per_slice(sseu, s),
sseu->subslice_mask[s]);
for (ss = 0; ss < sseu->max_subslices; ss++) {
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice index / 8
v2: fix spacing in set_sseu_info args
use set_sseu_info to initialize sseu data when building
device status in debugfs
rename variables in intel_engine_types.h to avoid checkpatch
warnings
v3: update headers in intel_sseu.h
v4: add const to some sseu_dev_info variables
use sseu->eu_stride for EU stride calculations
v5: address review comments from Tvrtko and Daniele
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Acked-by: Lionel Landwerlin
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 24 ++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 ++--
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 43 -
drivers/gpu/drm/i915/gt/intel_sseu.h | 28 +++-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 40 ++---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_gpu_error.c| 5 +-
drivers/gpu/drm/i915/i915_query.c| 10 +-
drivers/gpu/drm/i915/intel_device_info.c | 155 ++-
11 files changed, 227 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 5907a9613641..290bda5cc82b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -909,12 +909,30 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static inline u32
+intel_sseu_fls_subslice(const struct sseu_dev_info *sseu, u32 slice)
+{
+ u32 subslice;
+ int i;
+
+ for (i = sseu->ss_stride - 1; i >= 0; i--) {
+ subslice = fls(sseu->subslice_mask[slice * sseu->ss_stride +
+ i]);
+ if (subslice) {
+ subslice += i * BITS_PER_BYTE;
+ break;
+ }
+ }
+
+ return subslice;
+}
+
u32 intel_calculate_mcr_s_ss_select(struct drm_i915_private *dev_priv)
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
u32 mcr_s_ss_select;
u32 slice = fls(sseu->slice_mask);
- u32 subslice = fls(sseu->subslice_mask[slice]);
+ u32 subslice = intel_sseu_fls_subslice(sseu, slice);
if (IS_GEN(dev_priv, 10))
mcr_s_ss_select = GEN8_MCR_SLICE(slice) |
@@ -990,6 +1008,7 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
struct intel_instdone *instdone)
{
struct drm_i915_private *dev_priv = engine->i915;
+ const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
struct intel_uncore *uncore = engine->uncore;
u32 mmio_base = engine->mmio_base;
int slice;
@@ -1007,7 +1026,8 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
instdone->slice_common =
intel_uncore_read(uncore, GEN7_SC_INSTDONE);
- for_each_instdone_slice_subslice(dev_priv, slice, subslice) {
+ for_each_instdone_slice_subslice(dev_priv, sseu, slice,
+subslice) {
instdone->sampler[slice][subslice] =
read_subslice_reg(dev_priv, slice, subslice,
GEN7_SAMPLER_INSTDONE);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c0ab11b12e14..582340b55144 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -535,20 +535,20 @@ intel_engine_needs_breadcrumb_tasklet(const struct
intel_engine_cs *engine)
return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
}
-#define instdone_slice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
-
-#define instdone_subslice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.subslice_mask[0])
-
-#define for_each_instdone_slice_subslice(dev_priv__, slice__, subslice__) \
- for ((slice__) = 0, (subslice__) = 0; \
-(slice__) < I915_MAX_SLICES; \
-(subslice__) = ((subslice__) + 1) < I915_MAX_SUBSLICES ?
(subslice__) + 1 : 0, \
- (slice__) += ((subslice__) == 0)) \
- for_each_if((BIT(slice__) & instdone_slice_mask(dev_priv__)) &&
\
- (BIT(subslice__) &
instdone_subslice_mask(dev_priv__)))
+#define instdo
[Intel-gfx] [PATCH 4/5] drm/i915: Refactor sseu helper functions
Move functions to intel_sseu.h and remove inline qualifier.
Additionally, ensure these are all prefixed with intel_sseu_*
to match the convention of other functions in i915.
v2: fix spacing from checkpatch warning
v3: squash helper function changes into a single patch
break 80 character line to fix checkpatch warning
move get/set_eus helpers to intel_device_info.c
Acked-by: Jani Nikula
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 17
drivers/gpu/drm/i915/gt/intel_sseu.h | 10 +--
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 103 ---
drivers/gpu/drm/i915/intel_device_info.h | 44 --
6 files changed, 97 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 7f448f3bea0b..a0756f006f5f 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -8,6 +8,23 @@
#include "intel_lrc_reg.h"
#include "intel_sseu.h"
+unsigned int
+intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
+{
+ unsigned int i, total = 0;
+
+ for (i = 0; i < ARRAY_SIZE(sseu->subslice_mask); i++)
+ total += hweight8(sseu->subslice_mask[i]);
+
+ return total;
+}
+
+unsigned int
+intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
+{
+ return hweight8(sseu->subslice_mask[slice]);
+}
+
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 9618dff46d83..b50d0401a4e2 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -63,11 +63,11 @@ intel_sseu_from_device_info(const struct sseu_dev_info
*sseu)
return value;
}
-static inline unsigned int
-intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
-{
- return hweight8(sseu->subslice_mask[slice]);
-}
+unsigned int
+intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
+
+unsigned int
+intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice);
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index dceb32a16c5c..fce3ccd87f76 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4160,7 +4160,7 @@ static void broadwell_sseu_device_status(struct
drm_i915_private *dev_priv,
RUNTIME_INFO(dev_priv)->sseu.subslice_mask[s];
}
sseu->eu_total = sseu->eu_per_subslice *
-sseu_subslice_total(sseu);
+intel_sseu_subslice_total(sseu);
/* subtract fused off EU(s) from enabled slice(s) */
for (s = 0; s < fls(sseu->slice_mask); s++) {
@@ -4184,7 +4184,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool
is_available_info,
seq_printf(m, " %s Slice Total: %u\n", type,
hweight8(sseu->slice_mask));
seq_printf(m, " %s Subslice Total: %u\n", type,
- sseu_subslice_total(sseu));
+ intel_sseu_subslice_total(sseu));
for (s = 0; s < fls(sseu->slice_mask); s++) {
seq_printf(m, " %s Slice%i subslices: %u\n", type,
s, intel_sseu_subslices_per_slice(sseu, s));
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dcc872f9c676..c2ea3f0992b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -382,7 +382,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = i915_cmd_parser_get_version(dev_priv);
break;
case I915_PARAM_SUBSLICE_TOTAL:
- value = sseu_subslice_total(sseu);
+ value = intel_sseu_subslice_total(sseu);
if (!value)
return -ENODEV;
break;
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 9d6b9c45bc5e..689702b28e80 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -90,7 +90,7 @@ static void sseu_dump(const struct sseu_dev_info *sseu,
struct drm_printer *p)
drm_printf(p, "slice total: %u, mask=%04x\n",
hweight8(sseu->slice_mask), sseu->slice_mask);
- drm_printf(p, "subslice total: %u\n", sseu_subslice_total(sseu));
+ drm_printf(p, "subslice total: %u\n", intel_sseu_subslice_total(sseu));
for (s = 0; s < sseu->max_slices; s++) {
[Intel-gfx] [PATCH 1/5] drm/i915: Use local variable for SSEU info in GETPARAM ioctl
In the GETPARAM ioctl handler, use a local variable to consolidate
usage of SSEU runtime info.
v2: add const to sseu_dev_info variable
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ed864752c7b..dcc872f9c676 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -328,6 +328,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
+ const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
drm_i915_getparam_t *param = data;
int value;
@@ -381,12 +382,12 @@ static int i915_getparam_ioctl(struct drm_device *dev,
void *data,
value = i915_cmd_parser_get_version(dev_priv);
break;
case I915_PARAM_SUBSLICE_TOTAL:
- value = sseu_subslice_total(&RUNTIME_INFO(dev_priv)->sseu);
+ value = sseu_subslice_total(sseu);
if (!value)
return -ENODEV;
break;
case I915_PARAM_EU_TOTAL:
- value = RUNTIME_INFO(dev_priv)->sseu.eu_total;
+ value = sseu->eu_total;
if (!value)
return -ENODEV;
break;
@@ -403,7 +404,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = HAS_POOLED_EU(dev_priv);
break;
case I915_PARAM_MIN_EU_IN_POOL:
- value = RUNTIME_INFO(dev_priv)->sseu.min_eu_in_pool;
+ value = sseu->min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
value = intel_huc_check_status(&dev_priv->huc);
@@ -453,12 +454,12 @@ static int i915_getparam_ioctl(struct drm_device *dev,
void *data,
value = intel_engines_has_context_isolation(dev_priv);
break;
case I915_PARAM_SLICE_MASK:
- value = RUNTIME_INFO(dev_priv)->sseu.slice_mask;
+ value = sseu->slice_mask;
if (!value)
return -ENODEV;
break;
case I915_PARAM_SUBSLICE_MASK:
- value = RUNTIME_INFO(dev_priv)->sseu.subslice_mask[0];
+ value = sseu->subslice_mask[0];
if (!value)
return -ENODEV;
break;
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Refactor to expand subslice mask
This patch series contains a few code clean-up patches, followed by a patch which changes the storage of the subslice mask to better match the userspace access through the I915_QUERY_TOPOLOGY_INFO ioctl. The index into the subslice_mask array is then calculated: slice * subslice stride + subslice index / 8 v2: fix i915_pm_sseu test failure v3: no changes to patches in the series, just resending to pick up in CI correctly v4: rebase v5: fix header test v6: address review comments from Jari address minor checkpatch warning in existing code use eu_stride for EU div-by-8 v7: another rebase v8: address review comments from Tvrtko and Daniele Stuart Summers (5): drm/i915: Use local variable for SSEU info in GETPARAM ioctl drm/i915: Add macro for SSEU stride calculation drm/i915: Move calculation of subslices per slice to new function drm/i915: Refactor sseu helper functions drm/i915: Expand subslice mask drivers/gpu/drm/i915/gt/intel_engine_cs.c| 24 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +-- drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 58 + drivers/gpu/drm/i915/gt/intel_sseu.h | 36 ++- drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 46 ++-- drivers/gpu/drm/i915/i915_drv.c | 15 +- drivers/gpu/drm/i915/i915_gpu_error.c| 5 +- drivers/gpu/drm/i915/i915_query.c| 15 +- drivers/gpu/drm/i915/intel_device_info.c | 246 --- drivers/gpu/drm/i915/intel_device_info.h | 47 12 files changed, 327 insertions(+), 200 deletions(-) -- 2.21.0.5.gaeb582a983 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Add macro for SSEU stride calculation
Subslice stride and EU stride are calculated multiple times in
i915_query. Move this calculation to a macro to reduce code duplication.
v2: update headers in intel_sseu.h
v3: use GEN_SSEU_STRIDE for stride calculations in intel_sseu.h
apply s/bits/max_entries/ to GEN_SSEU_STRIDE parameter
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 ++
drivers/gpu/drm/i915/i915_query.c| 17 -
drivers/gpu/drm/i915/intel_device_info.h | 9 +++--
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 73bc824094e8..d20b7f96907d 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -8,11 +8,13 @@
#define __INTEL_SSEU_H__
#include
+#include
struct drm_i915_private;
#define GEN_MAX_SLICES (6) /* CNL upper bound */
#define GEN_MAX_SUBSLICES (8) /* ICL upper bound */
+#define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries, BITS_PER_BYTE)
struct sseu_dev_info {
u8 slice_mask;
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 782183b78f49..7c1708c22811 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -37,6 +37,8 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
+ u8 subslice_stride = GEN_SSEU_STRIDE(sseu->max_subslices);
+ u8 eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
int ret;
if (query_item->flags != 0)
@@ -48,12 +50,10 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
slice_length = sizeof(sseu->slice_mask);
- subslice_length = sseu->max_slices *
- DIV_ROUND_UP(sseu->max_subslices, BITS_PER_BYTE);
- eu_length = sseu->max_slices * sseu->max_subslices *
- DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE);
-
- total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
+ subslice_length = sseu->max_slices * subslice_stride;
+ eu_length = sseu->max_slices * sseu->max_subslices * eu_stride;
+ total_length = sizeof(topo) + slice_length + subslice_length +
+ eu_length;
ret = copy_query_item(&topo, sizeof(topo), total_length,
query_item);
@@ -69,10 +69,9 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.max_eus_per_subslice = sseu->max_eus_per_subslice;
topo.subslice_offset = slice_length;
- topo.subslice_stride = DIV_ROUND_UP(sseu->max_subslices, BITS_PER_BYTE);
+ topo.subslice_stride = subslice_stride;
topo.eu_offset = slice_length + subslice_length;
- topo.eu_stride =
- DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE);
+ topo.eu_stride = eu_stride;
if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
&topo, sizeof(topo)))
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 5a2e17d6146b..9d43f7edfd63 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -231,8 +231,7 @@ static inline unsigned int sseu_subslice_total(const struct
sseu_dev_info *sseu)
static inline int sseu_eu_idx(const struct sseu_dev_info *sseu,
int slice, int subslice)
{
- int subslice_stride = DIV_ROUND_UP(sseu->max_eus_per_subslice,
- BITS_PER_BYTE);
+ int subslice_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
int slice_stride = sseu->max_subslices * subslice_stride;
return slice * slice_stride + subslice * subslice_stride;
@@ -244,8 +243,7 @@ static inline u16 sseu_get_eus(const struct sseu_dev_info
*sseu,
int i, offset = sseu_eu_idx(sseu, slice, subslice);
u16 eu_mask = 0;
- for (i = 0;
-i < DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE); i++) {
+ for (i = 0; i < GEN_SSEU_STRIDE(sseu->max_eus_per_subslice); i++) {
eu_mask |= ((u16) sseu->eu_mask[offset + i]) <<
(i * BITS_PER_BYTE);
}
@@ -258,8 +256,7 @@ static inline void sseu_set_eus(struct sseu_dev_info *sseu,
{
int i, offset = sseu_eu_idx(sseu, slice, subslice);
- for (i = 0;
-i < DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE); i++) {
+ for (i = 0; i < GEN_SSEU_STRIDE(sseu->max_eus_per_subslice); i++) {
sseu->eu_mask[offset + i] =
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
On 5/2/2019 3:48 PM, Kenny Ho wrote: > On 5/2/2019 1:34 AM, Leon Romanovsky wrote: >> Count us (Mellanox) too, our RDMA devices are exposing special and >> limited in size device memory to the users and we would like to provide >> an option to use cgroup to control its exposure. Hi Leon, great to hear and happy to work with you and RDMA community to shape this framework for use by RDMA devices as well. The intent was to support more than GPU devices. Incidentally, I also wanted to ask about the rdma cgroup controller and if there is interest in updating the device registration implemented in that controller. It could use the cgroup_device_register() that is proposed here. But this is perhaps future work, so can discuss separately. > Doesn't RDMA already has a separate cgroup? Why not implement it there? > Hi Kenny, I can't answer for Leon, but I'm hopeful he agrees with rationale I gave in the cover letter. Namely, to implement in rdma controller, would mean duplicating existing memcg controls there. Is AMD interested in collaborating to help shape this framework? It is intended to be device-neutral, so could be leveraged by various types of devices. If you have an alternative solution well underway, then maybe we can work together to merge our efforts into one. In the end, the DRM community is best served with common solution. > >>> and with future work, we could extend to: >>> * track and control share of GPU time (reuse of cpu/cpuacct) >>> * apply mask of allowed execution engines (reuse of cpusets) >>> >>> Instead of introducing a new cgroup subsystem for GPU devices, a new >>> framework is proposed to allow devices to register with existing cgroup >>> controllers, which creates per-device cgroup_subsys_state within the >>> cgroup. This gives device drivers their own private cgroup controls >>> (such as memory limits or other parameters) to be applied to device >>> resources instead of host system resources. >>> Device drivers (GPU or other) are then able to reuse the existing cgroup >>> controls, instead of inventing similar ones. >>> >>> Per-device controls would be exposed in cgroup filesystem as: >>> mount//.devices// >>> such as (for example): >>> mount//memory.devices//memory.max >>> mount//memory.devices//memory.current >>> mount//cpu.devices//cpu.stat >>> mount//cpu.devices//cpu.weight >>> >>> The drm/i915 patch in this series is based on top of other RFC work [1] >>> for i915 device memory support. >>> >>> AMD [2] and Intel [3] have proposed related work in this area within the >>> last few years, listed below as reference. This new RFC reuses existing >>> cgroup controllers and takes a different approach than prior work. >>> >>> Finally, some potential discussion points for this series: >>> * merge proposed .devices into a single devices directory? >>> * allow devices to have multiple registrations for subsets of resources? >>> * document a 'common charging policy' for device drivers to follow? >>> >>> [1] https://patchwork.freedesktop.org/series/56683/ >>> [2] >>> https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html >>> [3] >>> https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html >>> >>> >>> Brian Welty (5): >>> cgroup: Add cgroup_subsys per-device registration framework >>> cgroup: Change kernfs_node for directories to store >>> cgroup_subsys_state >>> memcg: Add per-device support to memory cgroup subsystem >>> drm: Add memory cgroup registration and DRIVER_CGROUPS feature bit >>> drm/i915: Use memory cgroup for enforcing device memory limit >>> >>> drivers/gpu/drm/drm_drv.c | 12 + >>> drivers/gpu/drm/drm_gem.c | 7 + >>> drivers/gpu/drm/i915/i915_drv.c| 2 +- >>> drivers/gpu/drm/i915/intel_memory_region.c | 24 +- >>> include/drm/drm_device.h | 3 + >>> include/drm/drm_drv.h | 8 + >>> include/drm/drm_gem.h | 11 + >>> include/linux/cgroup-defs.h| 28 ++ >>> include/linux/cgroup.h | 3 + >>> include/linux/memcontrol.h | 10 + >>> kernel/cgroup/cgroup-v1.c | 10 +- >>> kernel/cgroup/cgroup.c | 310 ++--- >>> mm/memcontrol.c| 183 +++- >>> 13 files changed, 552 insertions(+), 59 deletions(-) >>> >>> -- >>> 2.21.0 >>> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev10)
== Series Details ==
Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color
(rev10)
URL : https://patchwork.freedesktop.org/series/58912/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6041 -> Patchwork_12964
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/
Known issues
Here are the changes found in Patchwork_12964 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][1] ([fdo#108602] / [fdo#108744] /
[fdo#110581]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][3] ([fdo#109485]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- {fi-icl-u2}:[DMESG-WARN][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
[fdo#110595]: https://bugs.freedesktop.org/show_bug.cgi?id=110595
Participating hosts (51 -> 44)
--
Additional (1): fi-bsw-n3050
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-j1900
fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6041 -> Patchwork_12964
CI_DRM_6041: 014903e8b7de5d69a17de628345ed31db1600b73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12964: 53926fe20d0a3628bbcb96193aa6b8ebc3da13ab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
53926fe20d0a drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep
color
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12964/
___
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: Replace intel_ddi_pll_init()
== Series Details ==
Series: series starting with [1/2] drm/i915: Replace intel_ddi_pll_init()
URL : https://patchwork.freedesktop.org/series/60272/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6041 -> Patchwork_12963
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/
Known issues
Here are the changes found in Patchwork_12963 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718] /
[fdo#110581])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-blb-e6850/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/fi-blb-e6850/igt@i915_module_l...@reload.html
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][3] ([fdo#108602] / [fdo#108744] /
[fdo#110581]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][5] ([fdo#109485]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- {fi-icl-u2}:[DMESG-WARN][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[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#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
[fdo#110595]: https://bugs.freedesktop.org/show_bug.cgi?id=110595
Participating hosts (51 -> 46)
--
Additional (2): fi-bsw-n3050 fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6041 -> Patchwork_12963
CI_DRM_6041: 014903e8b7de5d69a17de628345ed31db1600b73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12963: 91cf56f6d70db058eda922fce0a7265b7561f045 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
91cf56f6d70d drm/i915: Move the hsw/bdw pc8 code to intel_runtime_pm.c
65a6f208116e drm/i915: Replace intel_ddi_pll_init()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12963/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Move pm_imr and pm_ier to intel_irc.
On Thu, Apr 25, 2019 at 03:55:28PM -0700, Rodrigo Vivi wrote: > On Thu, Apr 25, 2019 at 11:16:33PM +0100, Chris Wilson wrote: > > Quoting Rodrigo Vivi (2019-04-25 22:50:37) > > > No functional change. But by making those bits together > > > we will be able to convert many functions to pass > > > intel_irq instead of i915_private or uncore. > > > > > > For gen8+ "gt_" prefix would be better than pm_ on them > > > since these regs include more stuff then PM, but let's > > > keep for legacy reasons. > > > > I still disagree with this direction and would like to get the > > conflicting bug fixes reviewed first. > > Sorry, I missunderstood you then... > > I thought you were okay with intel_irq as long as we didn't > move rps related irq to it. > > I still want to split de from gt irqs though, just started > from the easy less risk place to start. > > About the bugs you mentioned you mean like this: > https://bugs.freedesktop.org/show_bug.cgi?id=109831 > ? > > or what else do you have in mind that I'm missing? > > Thanks, > Rodrigo Hi Chris, could you please clarify what is missing to get a no functional change in? > > > -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 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 [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60271/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6041 -> Patchwork_12962
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/
Known issues
Here are the changes found in Patchwork_12962 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718] /
[fdo#110581])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [FAIL][4] ([fdo#108511])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u3: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] /
[fdo#108569] / [fdo#110581])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][7] ([fdo#108602] / [fdo#108744] /
[fdo#110581]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#109485]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- {fi-icl-u2}:[DMESG-WARN][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
[fdo#110595]: https://bugs.freedesktop.org/show_bug.cgi?id=110595
Participating hosts (51 -> 45)
--
Additional (2): fi-bsw-n3050 fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6041 -> Patchwork_12962
CI_DRM_6041: 014903e8b7de5d69a17de628345ed31db1600b73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12962: 404a2b3b06037095b181fcf288f6c56328d3a174 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
404a2b3b0603 drm/i915: Make sure we have enough memory bandwidth on ICL
f4b65571ca4a drm/i915: Make sandybridge_pcode_read() deal with the second data
register
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12962/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
== Series Details == Series: series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register URL : https://patchwork.freedesktop.org/series/60271/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Make sandybridge_pcode_read() deal with the second data register Okay! Commit: drm/i915: Make sure we have enough memory bandwidth on ICL +drivers/gpu/drm/i915/i915_drv.c:1555:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1555:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1593:19: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1593:19: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1595:20: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1595:20: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1615:30: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1615:30: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1619:44: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1619:44: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1658:24: warning: expression using sizeof(void) +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
== Series Details == Series: series starting with [v3,1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register URL : https://patchwork.freedesktop.org/series/60271/ State : warning == Summary == $ dim checkpatch origin/drm-tip f4b65571ca4a drm/i915: Make sandybridge_pcode_read() deal with the second data register 404a2b3b0603 drm/i915: Make sure we have enough memory bandwidth on ICL -:415: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #415: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 668 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Replace intel_ddi_pll_init()
From: Ville Syrjälä
intel_ddi_pll_init() is an anachronism. Rename it to
hsw_assert_cdclk() and move it to the power domain init code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 25 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +-
2 files changed, 21 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index bb81f3506222..bf5e2541c35e 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1881,27 +1881,6 @@ static const struct intel_shared_dpll_funcs
bxt_ddi_pll_funcs = {
.get_hw_state = bxt_ddi_pll_get_hw_state,
};
-static void intel_ddi_pll_init(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
- if (INTEL_GEN(dev_priv) < 9) {
- u32 val = I915_READ(LCPLL_CTL);
-
- /*
-* The LCPLL register should be turned on by the BIOS. For now
-* let's just check its state and print errors in case
-* something is wrong. Don't even try to turn it on.
-*/
-
- if (val & LCPLL_CD_SOURCE_FCLK)
- DRM_ERROR("CDCLK source is not LCPLL\n");
-
- if (val & LCPLL_PLL_DISABLE)
- DRM_ERROR("LCPLL is disabled\n");
- }
-}
-
struct intel_dpll_mgr {
const struct dpll_info *dpll_info;
@@ -3305,10 +3284,6 @@ void intel_shared_dpll_init(struct drm_device *dev)
mutex_init(&dev_priv->dpll_lock);
BUG_ON(dev_priv->num_shared_dpll > I915_NUM_PLLS);
-
- /* FIXME: Move this to a more suitable place */
- if (HAS_DDI(dev_priv))
- intel_ddi_pll_init(dev);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 1b7ea6bab613..b1fd2ae99199 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3625,6 +3625,23 @@ static void icl_mbus_init(struct drm_i915_private
*dev_priv)
I915_WRITE(MBUS_ABOX_CTL, val);
}
+static void hsw_assert_cdclk(struct drm_i915_private *dev_priv)
+{
+ u32 val = I915_READ(LCPLL_CTL);
+
+ /*
+* The LCPLL register should be turned on by the BIOS. For now
+* let's just check its state and print errors in case
+* something is wrong. Don't even try to turn it on.
+*/
+
+ if (val & LCPLL_CD_SOURCE_FCLK)
+ DRM_ERROR("CDCLK source is not LCPLL\n");
+
+ if (val & LCPLL_PLL_DISABLE)
+ DRM_ERROR("LCPLL is disabled\n");
+}
+
static void intel_pch_reset_handshake(struct drm_i915_private *dev_priv,
bool enable)
{
@@ -4085,7 +4102,10 @@ void intel_power_domains_init_hw(struct drm_i915_private
*i915, bool resume)
mutex_unlock(&power_domains->lock);
assert_ved_power_gated(i915);
assert_isp_power_gated(i915);
- } else if (IS_IVYBRIDGE(i915) || INTEL_GEN(i915) >= 7) {
+ } else if (IS_BROADWELL(i915) || IS_HASWELL(i915)) {
+ hsw_assert_cdclk(i915);
+ intel_pch_reset_handshake(i915, !HAS_PCH_NOP(i915));
+ } else if (IS_IVYBRIDGE(i915)) {
intel_pch_reset_handshake(i915, !HAS_PCH_NOP(i915));
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Move the hsw/bdw pc8 code to intel_runtime_pm.c
From: Ville Syrjälä
hsw_enable_pc8()/hsw_disable_pc8() are more less equivalent to
the display core init/unit functions of later platforms. Relocate
the hsw/bdw code into intel_runtime_pm.c so that it sits next to
its cousins.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c| 222 +--
drivers/gpu/drm/i915/intel_display.h| 4 +
drivers/gpu/drm/i915/intel_drv.h| 2 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 223
drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +
5 files changed, 230 insertions(+), 223 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d81ec80e34f6..a351c8e219ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8725,7 +8725,7 @@ static void lpt_enable_clkout_dp(struct drm_i915_private
*dev_priv,
}
/* Sequence to disable CLKOUT_DP */
-static void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv)
+void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv)
{
u32 reg, tmp;
@@ -9482,226 +9482,6 @@ static bool ironlake_get_pipe_config(struct intel_crtc
*crtc,
return ret;
}
-
-static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
-{
- struct drm_device *dev = &dev_priv->drm;
- struct intel_crtc *crtc;
-
- for_each_intel_crtc(dev, crtc)
- I915_STATE_WARN(crtc->active, "CRTC for pipe %c enabled\n",
-pipe_name(crtc->pipe));
-
- I915_STATE_WARN(I915_READ(HSW_PWR_WELL_CTL2),
- "Display power well on\n");
- I915_STATE_WARN(I915_READ(SPLL_CTL) & SPLL_PLL_ENABLE, "SPLL
enabled\n");
- I915_STATE_WARN(I915_READ(WRPLL_CTL(0)) & WRPLL_PLL_ENABLE, "WRPLL1
enabled\n");
- I915_STATE_WARN(I915_READ(WRPLL_CTL(1)) & WRPLL_PLL_ENABLE, "WRPLL2
enabled\n");
- I915_STATE_WARN(I915_READ(PP_STATUS(0)) & PP_ON, "Panel power on\n");
- I915_STATE_WARN(I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE,
-"CPU PWM1 enabled\n");
- if (IS_HASWELL(dev_priv))
- I915_STATE_WARN(I915_READ(HSW_BLC_PWM2_CTL) & BLM_PWM_ENABLE,
-"CPU PWM2 enabled\n");
- I915_STATE_WARN(I915_READ(BLC_PWM_PCH_CTL1) & BLM_PCH_PWM_ENABLE,
-"PCH PWM1 enabled\n");
- I915_STATE_WARN(I915_READ(UTIL_PIN_CTL) & UTIL_PIN_ENABLE,
-"Utility pin enabled\n");
- I915_STATE_WARN(I915_READ(PCH_GTC_CTL) & PCH_GTC_ENABLE, "PCH GTC
enabled\n");
-
- /*
-* In theory we can still leave IRQs enabled, as long as only the HPD
-* interrupts remain enabled. We used to check for that, but since it's
-* gen-specific and since we only disable LCPLL after we fully disable
-* the interrupts, the check below should be enough.
-*/
- I915_STATE_WARN(intel_irqs_enabled(dev_priv), "IRQs enabled\n");
-}
-
-static u32 hsw_read_dcomp(struct drm_i915_private *dev_priv)
-{
- if (IS_HASWELL(dev_priv))
- return I915_READ(D_COMP_HSW);
- else
- return I915_READ(D_COMP_BDW);
-}
-
-static void hsw_write_dcomp(struct drm_i915_private *dev_priv, u32 val)
-{
- if (IS_HASWELL(dev_priv)) {
- if (sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_D_COMP,
- val))
- DRM_DEBUG_KMS("Failed to write to D_COMP\n");
- } else {
- I915_WRITE(D_COMP_BDW, val);
- POSTING_READ(D_COMP_BDW);
- }
-}
-
-/*
- * This function implements pieces of two sequences from BSpec:
- * - Sequence for display software to disable LCPLL
- * - Sequence for display software to allow package C8+
- * The steps implemented here are just the steps that actually touch the LCPLL
- * register. Callers should take care of disabling all the display engine
- * functions, doing the mode unset, fixing interrupts, etc.
- */
-static void hsw_disable_lcpll(struct drm_i915_private *dev_priv,
- bool switch_to_fclk, bool allow_power_down)
-{
- u32 val;
-
- assert_can_disable_lcpll(dev_priv);
-
- val = I915_READ(LCPLL_CTL);
-
- if (switch_to_fclk) {
- val |= LCPLL_CD_SOURCE_FCLK;
- I915_WRITE(LCPLL_CTL, val);
-
- if (wait_for_us(I915_READ(LCPLL_CTL) &
- LCPLL_CD_SOURCE_FCLK_DONE, 1))
- DRM_ERROR("Switching to FCLK failed\n");
-
- val = I915_READ(LCPLL_CTL);
- }
-
- val |= LCPLL_PLL_DISABLE;
- I915_WRITE(LCPLL_CTL, val);
- POSTING_READ(LCPLL_CTL);
-
- if (intel_wait_for_register(&dev_priv->uncore,
- LCPLL_CTL, LCPLL_PLL_LOCK, 0, 1))
- DRM_ERROR("LCPLL still locked\n");
-
- val = hsw_read_dcomp(dev_priv);
- val |= D_COMP_COMP_DISABLE;
- hsw_write_dcomp(d
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler (rev2) URL : https://patchwork.freedesktop.org/series/60257/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6039_full -> Patchwork_12960_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12960_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12960_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_12960_full: ### IGT changes ### Possible regressions * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-hsw: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-hsw5/igt@gem_pp...@flink-and-close-vma-leak.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-hsw5/igt@gem_pp...@flink-and-close-vma-leak.html - shard-iclb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb6/igt@gem_pp...@flink-and-close-vma-leak.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-iclb6/igt@gem_pp...@flink-and-close-vma-leak.html Known issues Here are the changes found in Patchwork_12960_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-apl5/igt@i915_susp...@debugfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-apl5/igt@i915_susp...@debugfs-reader.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-snb4/igt@kms_draw_...@draw-method-rgb565-pwrite-xtiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-snb7/igt@kms_draw_...@draw-method-rgb565-pwrite-xtiled.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103167] / [fdo#110379]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-skl8/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-skl5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-iclb5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][13] -> [SKIP][14] ([fdo#109271] / [fdo#109278]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-glk5/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-iclb4/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_setmode@basic: - shard-kbl: [PASS][17] -> [FAIL][18] ([fdo#99912]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-kbl1/igt@kms_setm...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-kbl6/igt@kms_setm...@basic.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-apl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-apl1/igt@gem_...@in-flight-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/shard-apl4/igt@gem_...@in-flight-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [FAIL][21] ([fdo#104873]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [22]: https://intel-gfx-ci.01.org/tre
[Intel-gfx] [PATCH v3 1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
From: Ville Syrjälä
The pcode mailbox has two data registers. So far we've only ever used
the one, but that's about to change. Expose the second data register to
the callers of sandybridge_pcode_read().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
drivers/gpu/drm/i915/intel_sideband.c | 15 +--
drivers/gpu/drm/i915/intel_sideband.h | 3 ++-
4 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..203088f6f269 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1494,7 +1494,7 @@ static int gen6_drpc_info(struct seq_file *m)
if (INTEL_GEN(dev_priv) <= 7)
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
- &rc6vids);
+ &rc6vids, NULL);
seq_printf(m, "RC1e Enabled: %s\n",
yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -1777,7 +1777,7 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
ia_freq = gpu_freq;
sandybridge_pcode_read(dev_priv,
GEN6_PCODE_READ_MIN_FREQ_TABLE,
- &ia_freq);
+ &ia_freq, NULL);
seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
intel_gpu_freq(dev_priv, (gpu_freq *
(IS_GEN9_BC(dev_priv) ||
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ef9fc77f8162..b043a96e123c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2822,7 +2822,7 @@ static void intel_read_wm_latency(struct drm_i915_private
*dev_priv,
val = 0; /* data0 to be programmed to 0 for first set */
ret = sandybridge_pcode_read(dev_priv,
GEN9_PCODE_READ_MEM_LATENCY,
-&val);
+&val, NULL);
if (ret) {
DRM_ERROR("SKL Mailbox read error = %d\n", ret);
@@ -2841,7 +2841,7 @@ static void intel_read_wm_latency(struct drm_i915_private
*dev_priv,
val = 1; /* data0 to be programmed to 1 for second set */
ret = sandybridge_pcode_read(dev_priv,
GEN9_PCODE_READ_MEM_LATENCY,
-&val);
+&val, NULL);
if (ret) {
DRM_ERROR("SKL Mailbox read error = %d\n", ret);
return;
@@ -7061,7 +7061,7 @@ static void gen6_init_rps_frequencies(struct
drm_i915_private *dev_priv)
if (sandybridge_pcode_read(dev_priv,
HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL,
- &ddcc_status) == 0)
+ &ddcc_status, NULL) == 0)
rps->efficient_freq =
clamp_t(u8,
((ddcc_status >> 8) & 0xff),
@@ -7408,7 +7408,8 @@ static void gen6_enable_rc6(struct drm_i915_private
*dev_priv)
GEN6_RC_CTL_HW_ENABLE);
rc6vids = 0;
- ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
&rc6vids);
+ ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
+&rc6vids, NULL);
if (IS_GEN(dev_priv, 6) && ret) {
DRM_DEBUG_DRIVER("Couldn't check for BIOS workaround\n");
} else if (IS_GEN(dev_priv, 6) && (GEN6_DECODE_RC6_VID(rc6vids & 0xff)
< 450)) {
@@ -8555,7 +8556,8 @@ void intel_init_gt_powersave(struct drm_i915_private
*dev_priv)
IS_IVYBRIDGE(dev_priv) || IS_HASWELL(dev_priv)) {
u32 params = 0;
- sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, ¶ms);
+ sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS,
+ ¶ms, NULL);
if (params & BIT(31)) { /* OC supported */
DRM_DEBUG_DRIVER("Overclocking supported, max: %dMHz,
overclock: %dMHz\n",
(rps->max_freq & 0xff) * 50,
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 87b5a14c7ca8..a115625e980c 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -374,7 +374,7 @@ static inline int gen7_check_mailbox_status(u32 mbox)
}
static int __sandybridge_pcode_rw(struct drm_i915_private *i915,
- u
[Intel-gfx] [PATCH v3 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query the
memory clock and timings, so we must rely on a combination of
raw readout from the memory controller and hardcoded assumptions.
The memory controller values obviously change as the system
jumps between the different SAGV points, so we try to stabilize
it first by disabling SAGV for the duration of the readout.
The utilized bandwidth is tracked via a device wide atomic
private object. That is actually not robust because we can't
afford to enforce strict global ordering between the pipes.
Thus I think I'll need to change this to simply chop up the
available bandwidth between all the active pipes. Each pipe
can then do whatever it wants as long as it doesn't exceed
its budget. That scheme will also require that we assume that
any number of planes could be active at any time.
TODO: make it robust and deal with all the open questions
v2: Sleep longer after disabling SAGV
v3: Poll for the dclk to get raised (seen it take 250ms!)
If the system has 2133MT/s memory then we pointlessly
wait one full second :(
v4: Use the new pcode interface to get the qgv points rather
that using hardcoded numbers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 229 ++
drivers/gpu/drm/i915/i915_drv.h | 10 +
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 20 ++
drivers/gpu/drm/i915/intel_atomic_plane.h | 2 +
drivers/gpu/drm/i915/intel_bw.c | 181 +
drivers/gpu/drm/i915/intel_bw.h | 46 +
drivers/gpu/drm/i915/intel_display.c | 40 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 +
10 files changed, 533 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_bw.c
create mode 100644 drivers/gpu/drm/i915/intel_bw.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68106fe35a04..139a0fc19390 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -138,6 +138,7 @@ i915-y += intel_audio.o \
intel_atomic.o \
intel_atomic_plane.o \
intel_bios.o \
+ intel_bw.o \
intel_cdclk.o \
intel_color.o \
intel_combo_phy.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ed864752c7b..b7fa7b51c2e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -70,6 +70,7 @@
#include "intel_overlay.h"
#include "intel_pipe_crc.h"
#include "intel_pm.h"
+#include "intel_sideband.h"
#include "intel_sprite.h"
#include "intel_uc.h"
@@ -1435,6 +1436,232 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
return 0;
}
+struct intel_qgv_point {
+ u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
+};
+
+struct intel_sagv_info {
+ struct intel_qgv_point points[3];
+ u8 num_points;
+ u8 num_channels;
+ u8 t_bl;
+ enum intel_dram_type dram_type;
+};
+
+static int icl_pcode_read_mem_global_info(struct drm_i915_private *dev_priv,
+ struct intel_sagv_info *si)
+{
+ u32 val = 0;
+ int ret;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ICL_PCODE_MEM_SS_READ_GLOBAL_INFO,
+&val, NULL);
+ if (ret)
+ return ret;
+
+ switch (val & 0xf) {
+ case 0:
+ si->dram_type = INTEL_DRAM_DDR4;
+ break;
+ case 1:
+ si->dram_type = INTEL_DRAM_DDR3;
+ break;
+ case 2:
+ si->dram_type = INTEL_DRAM_LPDDR3;
+ break;
+ case 3:
+ si->dram_type = INTEL_DRAM_LPDDR3;
+ break;
+ default:
+ MISSING_CASE(val & 0xf);
+ break;
+ }
+
+ si->num_channels = (val & 0xf0) >> 4;
+ si->num_points = (val & 0xf00) >> 8;
+
+ si->t_bl = si->dram_type == INTEL_DRAM_DDR4 ? 4 : 8;
+
+ return 0;
+}
+
+static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
+struct intel_qgv_point *sp,
+int point)
+{
+ u32 val = 0, val2;
+ int ret;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+
ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point),
+&val, &val2);
+ if (ret)
+ re
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Acquire the signaler's timeline HWSP last
== Series Details == Series: drm/i915: Acquire the signaler's timeline HWSP last URL : https://patchwork.freedesktop.org/series/60262/ State : success == Summary == CI Bug Log - changes from CI_DRM_6039_full -> Patchwork_12959_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12959_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-snb: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-snb5/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-snb1/igt@gem_...@reset-stress.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-kbl5/igt@gem_soft...@noreloc-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-kbl1/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_backlight@fade_with_suspend: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#107820] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb6/igt@i915_pm_backlight@fade_with_suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-iclb1/igt@i915_pm_backlight@fade_with_suspend.html * igt@i915_pm_rpm@i2c: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#104097]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb1/igt@i915_pm_...@i2c.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-iclb4/igt@i915_pm_...@i2c.html * igt@i915_pm_rpm@system-suspend-devices: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#107807] / [fdo#110581]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-skl10/igt@i915_pm_...@system-suspend-devices.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-skl2/igt@i915_pm_...@system-suspend-devices.html * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-c: - shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540] / [fdo#110581]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-hsw2/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-c.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-hsw2/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-c.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-glk3/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103167] / [fdo#110379]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-skl8/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-skl3/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][19] -> [SKIP][20] ([fdo#109271] / [fdo#109278]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-glk2/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-iclb7/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_setmode@basic: - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-kbl1/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/shard-kbl2/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-c-ts-continuation-susp
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Document that we implement WaIncreaseLatencyIPCEnabled
== Series Details ==
Series: series starting with [1/3] drm/i915: Document that we implement
WaIncreaseLatencyIPCEnabled
URL : https://patchwork.freedesktop.org/series/60266/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6041 -> Patchwork_12961
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12961 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12961, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12961:
### IGT changes ###
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [DMESG-FAIL][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@dp-hpd-fast:
- {fi-icl-u2}:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html
Known issues
Here are the changes found in Patchwork_12961 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718] /
[fdo#110581])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#109485]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- {fi-icl-u2}:[DMESG-WARN][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6041/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
[fdo#110595]: https://bugs.freedesktop.org/show_bug.cgi?id=110595
Participating hosts (51 -> 46)
--
Additional (2): fi-bsw-n3050 fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6041 -> Patchwork_12961
CI_DRM_6041: 014903e8b7de5d69a17de628345ed31db1600b73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12961: 771a9f396d25ce7e7d3ccd27914fa37bd2b8d480 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
771a9f396d25 drm/i915: Move w/a 0477/WaDisableIPC:skl into intel_init_ipc()
2f231097b2e8 drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for cnl
c1284b0162b9 drm/i915: Document that we implement WaIncreaseLatencyIPCEnabled
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12961/
___
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: Check the target has not already completed before waiting on it
== Series Details == Series: drm/i915: Check the target has not already completed before waiting on it URL : https://patchwork.freedesktop.org/series/60261/ State : success == Summary == CI Bug Log - changes from CI_DRM_6039_full -> Patchwork_12958_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12958_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-apl8/igt@gem_workarou...@suspend-resume.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-apl3/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_rpm@i2c: - shard-iclb: [PASS][3] -> [FAIL][4] ([fdo#104097]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb1/igt@i915_pm_...@i2c.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-iclb3/igt@i915_pm_...@i2c.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][5] -> [FAIL][6] ([fdo#105363]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-glk5/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk1/igt@kms_f...@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-glk8/igt@kms_f...@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103167] / [fdo#110379]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-skl8/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-skl6/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][13] -> [SKIP][14] ([fdo#109271] / [fdo#109278]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-glk7/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html * igt@kms_setmode@basic: - shard-kbl: [PASS][15] -> [FAIL][16] ([fdo#99912]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-kbl1/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-kbl4/igt@kms_setm...@basic.html * igt@tools_test@tools_test: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109352]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-iclb1/igt@tools_test@tools_test.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-iclb7/igt@tools_test@tools_test.html Possible fixes * igt@gem_eio@reset-stress: - shard-skl: [FAIL][19] ([fdo#105957]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-skl8/igt@gem_...@reset-stress.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-skl5/igt@gem_...@reset-stress.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [FAIL][23] ([fdo#104873]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/shard-glk7/igt@km
[Intel-gfx] [PATCH 3/3] drm/i915: Move w/a 0477/WaDisableIPC:skl into intel_init_ipc()
From: Ville Syrjälä
Move the w/a to disable IPC on SKL closer to the actual code
that implements IPS. Otherwise I just end up confused as to
what is excluding SKL from considerations.
IMO this makes more sense anyway since the hw does have the
feature, we're just not supposed to use it.
And this also makes us actually disable IPC in case eg. the
BIOS enabled it when it shouldn't have.
Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 2 --
drivers/gpu/drm/i915/intel_pm.c | 19 ++-
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..d7c07a947497 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -600,8 +600,6 @@ static const struct intel_device_info intel_cherryview_info
= {
#define SKL_PLATFORM \
GEN9_FEATURES, \
- /* Display WA #0477 WaDisableIPC: skl */ \
- .display.has_ipc = 0, \
PLATFORM(INTEL_SKYLAKE)
static const struct intel_device_info intel_skylake_gt1_info = {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ce348dd6da2d..decdd79c3805 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6375,16 +6375,25 @@ void intel_enable_ipc(struct drm_i915_private *dev_priv)
I915_WRITE(DISP_ARB_CTL2, val);
}
+static bool intel_can_enable_ipc(struct drm_i915_private *dev_priv)
+{
+ /* Display WA #0477 WaDisableIPC: skl */
+ if (IS_SKYLAKE(dev_priv))
+ return false;
+
+ /* Display WA #1141: SKL:all KBL:all CFL */
+ if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
+ return dev_priv->dram_info.symmetric_memory;
+
+ return true;
+}
+
void intel_init_ipc(struct drm_i915_private *dev_priv)
{
if (!HAS_IPC(dev_priv))
return;
- /* Display WA #1141: SKL:all KBL:all CFL */
- if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
- dev_priv->ipc_enabled = dev_priv->dram_info.symmetric_memory;
- else
- dev_priv->ipc_enabled = true;
+ dev_priv->ipc_enabled = intel_can_enable_ipc(dev_priv);
intel_enable_ipc(dev_priv);
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Document that we implement WaIncreaseLatencyIPCEnabled
From: Ville Syrjälä Display w/a #1141 is also known as WaIncreaseLatencyIPCEnabled. Add that to the comment. Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_pm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ef9fc77f8162..34fbf70df836 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4782,7 +4782,10 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *cstate, return; } - /* Display WA #1141: kbl,cfl */ + /* +* WaIncreaseLatencyIPCEnabled: kbl,cfl +* Display WA #1141: kbl,cfl +*/ if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && dev_priv->ipc_enabled) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for cnl
From: Ville Syrjälä Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for early cnl steppings. v2: Drop the IS_GEN9_BC() change since other related parts of the code also use the KBL||CFL pattern Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_pm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 34fbf70df836..ce348dd6da2d 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4786,8 +4786,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *cstate, * WaIncreaseLatencyIPCEnabled: kbl,cfl * Display WA #1141: kbl,cfl */ - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || - IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && + if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) || dev_priv->ipc_enabled) latency += 4; -- 2.21.0 ___ 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: Allow ICL pipe "HDR mode" when the cursor is visible
On Fri, May 03, 2019 at 03:31:49PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> >Sent: Friday, May 3, 2019 1:36 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Shankar, Uma ; Sharma, Shashank
> >
> >Subject: [PATCH 2/2] drm/i915: Allow ICL pipe "HDR mode" when the cursor is
> >visible
> >
> >From: Ville Syrjälä
> >
> >Turns out the cursor is compatible with the pipe "HDR mode". It's only the
> >actual SDR
> >planes that get entirely bypassed during blending. So let's ignore the
> >cursor when
> >checking if we have any planes active that aren't HDR compatible. This fixes
> >the
> >regressions in the kms_cursor_crc and kms_plane_cursor tests.
>
> Checked for details around this in spec, couldn't get anything specific
> around how cursor
> behaves wrt HDR_MODE.
Yeah, the spec is rather vague on this topic.
> But with the test results it appears that they do follow the HDR
> precision. With this observation and data, change looks ok.
>
> Reviewed-by: Uma Shankar
Thanks. Series pushed to dinq.
>
> >Cc: Uma Shankar
> >Cc: Shashank Sharma
> >Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110579
> >Fixes: 09b25812db10 ("drm/i915: Enable pipe HDR mode on ICL if only HDR
> >planes are
> >used")
> >Signed-off-by: Ville Syrjälä
> >---
> > drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_display.c
> >b/drivers/gpu/drm/i915/intel_display.c
> >index 28042a16084d..cc1203901ef4 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -8927,7 +8927,8 @@ static void bdw_set_pipemisc(const struct
> >intel_crtc_state
> >*crtc_state)
> > PIPEMISC_YUV420_MODE_FULL_BLEND;
> >
> > if (INTEL_GEN(dev_priv) >= 11 &&
> >-(crtc_state->active_planes & ~icl_hdr_plane_mask()) == 0)
> >+(crtc_state->active_planes & ~(icl_hdr_plane_mask() |
> >+ BIT(PLANE_CURSOR))) == 0)
> > val |= PIPEMISC_HDR_MODE_PRECISION;
> >
> > I915_WRITE(PIPEMISC(crtc->pipe), val);
> >--
> >2.21.0
>
--
Ville Syrjälä
Intel
___
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] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler (rev2)
== Series Details ==
Series: series starting with [v2] drm/i915: Assert breadcrumbs are correctly
ordered in the signal handler (rev2)
URL : https://patchwork.freedesktop.org/series/60257/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6039 -> Patchwork_12960
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/
Known issues
Here are the changes found in Patchwork_12960 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718] /
[fdo#110581])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@i915_selftest@live_gtt:
- fi-icl-y: [INCOMPLETE][3] ([fdo#107713] / [fdo#110581]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-icl-y/igt@i915_selftest@live_gtt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/fi-icl-y/igt@i915_selftest@live_gtt.html
* igt@kms_chamelium@common-hpd-after-suspend:
- {fi-icl-u2}:[DMESG-WARN][5] ([fdo#102505]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
Participating hosts (52 -> 46)
--
Additional (2): fi-byt-j1900 fi-bsw-kefka
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6039 -> Patchwork_12960
CI_DRM_6039: 941848427de77537b5709bd68ca4a4048be5b5d9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12960: 824b9e2304e344e55b1fea49f624c7b2ab0725bf @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
824b9e2304e3 drm/i915: Disable semaphore busywaits on saturated systems
ed45ebbc606a drm/i915: Bump signaler priority on adding a waiter
85b3c81ac684 drm/i915: Pass i915_sched_node around internally
cbce16bb8ac0 drm/i915: Rearrange i915_scheduler.c
058614b44ff5 drm/i915/execlists: Don't apply priority boost for resets
39d542060c6b drm/i915: Only reschedule the submission tasklet if preemption is
possible
b72f62bbbc63 drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
1f6964af2303 drm/i915: Cancel retire_worker on parking
b9b006f3e868 drm/i915: Remove delay for idle_work
6ea24581934a drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD
d6ebdabd10da drm/i915: Assert the local engine->wakeref is active
bdbff11af05c drm/i915: Prefer checking the wakeref itself rather than the
counter
0bd5b1be074d drm/i915: Assert breadcrumbs are correctly ordered in the signal
handler
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12960/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
> ICL introduces a new gamma correction mode in display engine, called
> multi-segmented-gamma mode. This mode allows users to program the
> darker region of the gamma curve with sueprfine precision. An
> example use case for this is HDR curves (like PQ ST-2084).
>
> If we plot a gamma correction curve from value range between 0.0 to 1.0,
> ICL's multi-segment has 3 different sections:
> - superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
> - fine segment: 257 values, ranges between 0 - 1/(128)
> - corase segment: 257 values, ranges between 0 - 1
>
> This patch:
> - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
> so that userspace can program with highest precision supported.
> - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
> - Adds functions to program/detect multi-segment gamma.
>
> V2: Addressed review comments from Ville
> - separate function for superfine and fine segments.
> - remove enum for segments.
> - reuse last entry of the LUT as gc_max value.
> - replace if() cond with switch...case in icl_load_luts.
> - add an entry variable, instead of 'word'
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Shashank Sharma
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c| 3 +-
> drivers/gpu/drm/i915/intel_color.c | 125 -
> 2 files changed, 123 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ffa2ee70a03d..83698951760b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -749,7 +749,8 @@ static const struct intel_device_info
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_logical_ring_elsq = 1, \
> - .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
> +
Bogus newline.
>
> static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 6c341bea514c..49831e8d02fb 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -41,6 +41,9 @@
> #define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
>
> #define LEGACY_LUT_LENGTH256
> +#define ICL_GAMMA_MULTISEG_LUT_LENGTH(256 * 128 * 8)
> +#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
> * format). This macro takes the coefficient we want transformed and the
> @@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
> *crtc_state)
> }
> }
>
> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> +static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
> +{
> + return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> + (color->blue >> 6);
> +}
> +
> +/* ilk+ "12.4" interpolated format (low 6 bits) */
> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> +{
> + return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> + (color->blue & 0x3f);
> +}
> +
> +static void
> +icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> + const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
> +}
> +
> +static void
> +icl_program_gamma_superfine_segment(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
> + const struct drm_color_lut *lut = blob->data;
> + enum pipe pipe = crtc->pipe;
> + u32 i;
> +
> + if (!lut || drm_color_lut_size(blob) < ICL_GAMMA_SUPERFINE_SEG_LENGTH)
> + return;
These checks aren't needed. Just dead code.
> +
> + /*
> + * Every entry in the multi-segment LUT is corresponding to a superfine
> + * segment step which is 1/(8 * 128 * 256).
> + *
> + * Superfine segment has 9 entries, corresponding to values
> + *
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler (rev2) URL : https://patchwork.freedesktop.org/series/60257/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Assert breadcrumbs are correctly ordered in the signal handler Okay! Commit: drm/i915: Prefer checking the wakeref itself rather than the counter Okay! Commit: drm/i915: Assert the local engine->wakeref is active Okay! Commit: drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD Okay! Commit: drm/i915: Remove delay for idle_work Okay! Commit: drm/i915: Cancel retire_worker on parking Okay! Commit: drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches) Okay! Commit: drm/i915: Only reschedule the submission tasklet if preemption is possible -O:drivers/gpu/drm/i915/gt/intel_engine.h:124:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/gt/intel_engine.h:124:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Don't apply priority boost for resets Okay! Commit: drm/i915: Rearrange i915_scheduler.c Okay! Commit: drm/i915: Pass i915_sched_node around internally Okay! Commit: drm/i915: Bump signaler priority on adding a waiter Okay! Commit: drm/i915: Disable semaphore busywaits on saturated systems +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) ___ 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: Allow ICL pipe "HDR mode" when the cursor is visible
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, May 3, 2019 1:36 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Sharma, Shashank
>
>Subject: [PATCH 2/2] drm/i915: Allow ICL pipe "HDR mode" when the cursor is
>visible
>
>From: Ville Syrjälä
>
>Turns out the cursor is compatible with the pipe "HDR mode". It's only the
>actual SDR
>planes that get entirely bypassed during blending. So let's ignore the cursor
>when
>checking if we have any planes active that aren't HDR compatible. This fixes
>the
>regressions in the kms_cursor_crc and kms_plane_cursor tests.
Checked for details around this in spec, couldn't get anything specific around
how cursor
behaves wrt HDR_MODE. But with the test results it appears that they do follow
the HDR
precision. With this observation and data, change looks ok.
Reviewed-by: Uma Shankar
>Cc: Uma Shankar
>Cc: Shashank Sharma
>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110579
>Fixes: 09b25812db10 ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes
>are
>used")
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index 28042a16084d..cc1203901ef4 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -8927,7 +8927,8 @@ static void bdw_set_pipemisc(const struct
>intel_crtc_state
>*crtc_state)
> PIPEMISC_YUV420_MODE_FULL_BLEND;
>
> if (INTEL_GEN(dev_priv) >= 11 &&
>- (crtc_state->active_planes & ~icl_hdr_plane_mask()) == 0)
>+ (crtc_state->active_planes & ~(icl_hdr_plane_mask() |
>+ BIT(PLANE_CURSOR))) == 0)
> val |= PIPEMISC_HDR_MODE_PRECISION;
>
> I915_WRITE(PIPEMISC(crtc->pipe), val);
>--
>2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move the PIPEMISC write the correct place
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, May 3, 2019 1:36 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Sharma, Shashank
>
>Subject: [PATCH 1/2] drm/i915: Move the PIPEMISC write the correct place
>
>From: Ville Syrjälä
>
>I fumbled the PIPEMISC write into the wrong place. It only gets called for
>fastsets, but
>since value needs to be updated based on the set of active planes it needs to
>be done
>for all plane updates.
>Move it to the correct spot.
>
>The symptoms include SDR planes never showing up if a previous modeset/fastset
>left
>the pipe in HDR mode. This was immediately obvious when running the kms_plane
>pixel format tests. Unfortunately the test didn't realize it was scanning out
>pure black
>all the time and declared success anyway.
Yeah. SDR Planes will not even be considered for blending and result will be
Black output.
Looks ok now.
Reviewed-by: Uma Shankar
>Cc: Uma Shankar
>Cc: Shashank Sharma
>Fixes: 09b25812db10 ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes
>are
>used")
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index dd65d7c521c1..28042a16084d 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -4099,9 +4099,6 @@ static void intel_update_pipe_config(const struct
>intel_crtc_state *old_crtc_sta
> ironlake_pfit_disable(old_crtc_state);
> }
>
>- if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
>- bdw_set_pipemisc(new_crtc_state);
>-
> if (INTEL_GEN(dev_priv) >= 11)
> icl_set_pipe_chicken(crtc);
> }
>@@ -14156,6 +14153,9 @@ static void intel_begin_crtc_commit(struct
>intel_atomic_state *state,
> else if (INTEL_GEN(dev_priv) >= 9)
> skl_detach_scalers(new_crtc_state);
>
>+ if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
>+ bdw_set_pipemisc(new_crtc_state);
>+
> out:
> if (dev_priv->display.atomic_update_watermarks)
> dev_priv->display.atomic_update_watermarks(state,
>--
>2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
Inside the signal handler, we expect the requests to be ordered by their
breadcrumb such that no later request may be complete if we find an
earlier incomplete. Add an assert to check that the next breadcrumb
should not be logically before the current.
v2: Move the overhanging line into its own function and reuse it after
doing the insertion.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 3cbffd400b1b..fe455f01aa65 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -80,6 +80,22 @@ static inline bool __request_completed(const struct
i915_request *rq)
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
}
+__maybe_unused static bool
+check_signal_order(struct intel_context *ce, struct i915_request *rq)
+{
+ if (!list_is_last(&rq->signal_link, &ce->signals) &&
+ i915_seqno_passed(rq->fence.seqno,
+ list_next_entry(rq, signal_link)->fence.seqno))
+ return false;
+
+ if (!list_is_first(&rq->signal_link, &ce->signals) &&
+ i915_seqno_passed(list_prev_entry(rq, signal_link)->fence.seqno,
+ rq->fence.seqno))
+ return false;
+
+ return true;
+}
+
void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
@@ -99,6 +115,8 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
struct i915_request *rq =
list_entry(pos, typeof(*rq), signal_link);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
+
if (!__request_completed(rq))
break;
@@ -282,6 +300,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
list_add(&rq->signal_link, pos);
if (pos == &ce->signals) /* catch transitions from empty list */
list_move_tail(&ce->signal_link, &b->signalers);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
set_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_trylock more
On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > console_trylock, called from within printk, can be called from pretty > much anywhere. Including try_to_wake_up. Note that this isn't common, > usually the box is in pretty bad shape at that point already. But it > really doesn't help when then lockdep jumps in and spams the logs, > potentially obscuring the real backtrace we're really interested in. > One case I've seen (slightly simplified backtrace): > > Call Trace: > > console_trylock+0xe/0x60 > vprintk_emit+0xf1/0x320 > printk+0x4d/0x69 > __warn_printk+0x46/0x90 > native_smp_send_reschedule+0x2f/0x40 > check_preempt_curr+0x81/0xa0 > ttwu_do_wakeup+0x14/0x220 > try_to_wake_up+0x218/0x5f0 > pollwake+0x6f/0x90 > credit_entropy_bits+0x204/0x310 > add_interrupt_randomness+0x18f/0x210 > handle_irq+0x67/0x160 > do_IRQ+0x5e/0x130 > common_interrupt+0xf/0xf > > > This alone isn't a problem, but the spinlock in the semaphore is also > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > callchain), which then closes the runqueue vs. semaphore.lock loop, > and upsets lockdep, which issues a circular locking splat to dmesg. > Worse it upsets developers, since we don't want to spam dmesg with > clutter when the machine is dying already. > > Fix this by creating a __down_trylock which only trylocks the > semaphore.lock. This isn't correct in full generality, but good enough > for console_lock: > > - there's only ever one console_lock holder, we won't fail spuriously > because someone is doing a down() or up() while there's still room > (unlike other semaphores with count > 1). > > - console_unlock() has one massive retry loop, which will catch anyone > who races the trylock against the up(). This makes sure that no > printk lines will get lost. Making the trylock more racy therefore > has no further impact. To be honest, I do not see how this could solve the problem. The circular dependency is still there. If the new __down_trylock() succeeds then console_unlock() will get called in the same context and it will still need to call up() -> try_to_wake_up(). Note that there are many other console_lock() callers that might happen in parallel and might appear in the wait queue. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Rename ivb_load_lut_10_max
On Tue, Apr 30, 2019 at 08:51:07PM +0530, Shashank Sharma wrote:
> This patch renames function ivb_load_lut_10_max to
> ivb_load_lut_ext_max.
>
> Cc: Uma Shankar
> Suggested-by: Ville Syrjala
> Signed-off-by: Shashank Sharma
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_color.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 962db1236970..6c341bea514c 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -607,7 +607,7 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
> I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> }
>
> -static void ivb_load_lut_10_max(struct intel_crtc *crtc)
> +static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
> @@ -640,7 +640,7 @@ static void ivb_load_luts(const struct intel_crtc_state
> *crtc_state)
> } else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
> ivb_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
> PAL_PREC_INDEX_VALUE(0));
> - ivb_load_lut_10_max(crtc);
> + ivb_load_lut_ext_max(crtc);
> ivb_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
> PAL_PREC_INDEX_VALUE(512));
> } else {
> @@ -648,7 +648,7 @@ static void ivb_load_luts(const struct intel_crtc_state
> *crtc_state)
>
> ivb_load_lut_10(crtc, blob,
> PAL_PREC_INDEX_VALUE(0));
> - ivb_load_lut_10_max(crtc);
> + ivb_load_lut_ext_max(crtc);
> }
> }
>
> @@ -663,7 +663,7 @@ static void bdw_load_luts(const struct intel_crtc_state
> *crtc_state)
> } else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
> bdw_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
> PAL_PREC_INDEX_VALUE(0));
> - ivb_load_lut_10_max(crtc);
> + ivb_load_lut_ext_max(crtc);
> bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
> PAL_PREC_INDEX_VALUE(512));
> } else {
> @@ -671,7 +671,7 @@ static void bdw_load_luts(const struct intel_crtc_state
> *crtc_state)
>
> bdw_load_lut_10(crtc, blob,
> PAL_PREC_INDEX_VALUE(0));
> - ivb_load_lut_10_max(crtc);
> + ivb_load_lut_ext_max(crtc);
> }
> }
>
> @@ -763,7 +763,7 @@ static void glk_load_luts(const struct intel_crtc_state
> *crtc_state)
> i9xx_load_luts(crtc_state);
> } else {
> bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
> - ivb_load_lut_10_max(crtc);
> + ivb_load_lut_ext_max(crtc);
> }
> }
>
> @@ -780,7 +780,7 @@ static void icl_load_luts(const struct intel_crtc_state
> *crtc_state)
> i9xx_load_luts(crtc_state);
> } else {
> bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
> - ivb_load_lut_10_max(crtc);
> + ivb_load_lut_ext_max(crtc);
> }
> }
>
> --
> 2.17.1
>
> ___
> 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] ✓ Fi.CI.BAT: success for drm/i915: Acquire the signaler's timeline HWSP last
== Series Details == Series: drm/i915: Acquire the signaler's timeline HWSP last URL : https://patchwork.freedesktop.org/series/60262/ State : success == Summary == CI Bug Log - changes from CI_DRM_6039 -> Patchwork_12959 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/ Known issues Here are the changes found in Patchwork_12959 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] / [fdo#108744] / [fdo#110581]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@i915_selftest@live_gtt: - fi-icl-y: [INCOMPLETE][5] ([fdo#107713] / [fdo#110581]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-icl-y/igt@i915_selftest@live_gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/fi-icl-y/igt@i915_selftest@live_gtt.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (52 -> 45) -- Additional (1): fi-bsw-kefka Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6039 -> Patchwork_12959 CI_DRM_6039: 941848427de77537b5709bd68ca4a4048be5b5d9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12959: 30add0da8a704d333159c12aa8e2154383296493 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 30add0da8a70 drm/i915: Acquire the signaler's timeline HWSP last == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12959/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Add register definitions for Multi Segmented gamma
On Tue, Apr 30, 2019 at 08:51:06PM +0530, Shashank Sharma wrote:
> From: Uma Shankar
>
> Add macros to define multi segmented gamma registers
>
> V2: Addressed Ville's comments:
> Add gen-lable before bit definition
> Addressed Jani's comment
> - Use REG_GENMASK() and REG_BIT()
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Maarten Lankhorst
> Signed-off-by: Uma Shankar
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6f0a0866c802..7d10b8d00d64 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7198,7 +7198,10 @@ enum {
> #define GAMMA_MODE_MODE_8BIT(0 << 0)
> #define GAMMA_MODE_MODE_10BIT (1 << 0)
> #define GAMMA_MODE_MODE_12BIT (2 << 0)
> +/* ivb-bdw */
> #define GAMMA_MODE_MODE_SPLIT (3 << 0)
> +/* icl + */
> +#define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0)
I would put the comments at the end of the line
#define ... /* ivb-bdw */
>
> /* DMC/CSR */
> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
> @@ -10145,6 +10148,22 @@ enum skl_power_gate {
> #define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
> _PRE_CSC_GAMC_INDEX_B)
> #define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
> _PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
>
> +/* Add registers for Gen11 Multi Segmented Gamma Mode */
Weird comment. 's/Add registers for //' might make it somewhat useful.
And no point in capitalizing every word. This isn't a movie title/etc.
With those sorted this is
Reviewed-by: Ville Syrjälä
> +#define _PAL_PREC_MULTI_SEG_INDEX_A 0x4A408
> +#define _PAL_PREC_MULTI_SEG_INDEX_B 0x4AC08
> +#define PAL_PREC_MULTI_SEGMENT_AUTO_INCREMENT REG_BIT(15)
> +#define PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK REG_GENMASK(4, 0)
> +
> +#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
> +#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
> +
> +#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
> + _PAL_PREC_MULTI_SEG_INDEX_A, \
> + _PAL_PREC_MULTI_SEG_INDEX_B)
> +#define PREC_PAL_MULTI_SEG_DATA(pipe)_MMIO_PIPE(pipe, \
> + _PAL_PREC_MULTI_SEG_DATA_A, \
> + _PAL_PREC_MULTI_SEG_DATA_B)
> +
> /* pipe CSC & degamma/gamma LUTs on CHV */
> #define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
> #define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
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: Check the target has not already completed before waiting on it
== Series Details == Series: drm/i915: Check the target has not already completed before waiting on it URL : https://patchwork.freedesktop.org/series/60261/ State : success == Summary == CI Bug Log - changes from CI_DRM_6039 -> Patchwork_12958 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/ Known issues Here are the changes found in Patchwork_12958 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] / [fdo#108744] / [fdo#110581]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@i915_selftest@live_gtt: - fi-icl-y: [INCOMPLETE][5] ([fdo#107713] / [fdo#110581]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-icl-y/igt@i915_selftest@live_gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/fi-icl-y/igt@i915_selftest@live_gtt.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [DMESG-FAIL][7] -> [INCOMPLETE][8] ([fdo#103927] / [fdo#110581]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][9] -> [FAIL][10] ([fdo#108866]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6039/fi-apl-guc/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108866]: https://bugs.freedesktop.org/show_bug.cgi?id=108866 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (52 -> 46) -- Additional (2): fi-byt-j1900 fi-bsw-kefka Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6039 -> Patchwork_12958 CI_DRM_6039: 941848427de77537b5709bd68ca4a4048be5b5d9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12958: d692ff91c1acad76a2b15bd41ab165a2de63f985 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d692ff91c1ac drm/i915: Check the target has not already completed before waiting on it == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12958/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Expand subslice mask
On Fri, 2019-05-03 at 10:05 +0100, Lionel Landwerlin wrote: > Acked-by: Lionel Landwerlin Thanks for the Ack! -Stuart smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Disable semaphore busywaits on saturated systems
On Fri, May 03, 2019 at 03:12:01PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2019-05-03 15:04:57) > > On Mon, Apr 29, 2019 at 07:00:19PM +0100, Chris Wilson wrote: > > > Asking the GPU to busywait on a memory address, perhaps not unexpectedly > > > in hindsight for a shared system, leads to bus contention that affects > > > CPU programs trying to concurrently access memory. This can manifest as > > > a drop in transcode throughput on highly over-saturated workloads. > > > > We can't use the singalling semaphore variant? > > That requires us to broadcast a signal to each engine (for which I can > hear the cries of cross-powerwell wakes), and currently does not work > with execlists + context-id==0. Or at least it failed in my testing. Ah. If only we had MI_MWAIT. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check the target has not already completed before waiting on it
Quoting Chris Wilson (2019-05-03 14:52:29)
> When we want to wait for a request to be executed, we first ask if it is
> not on the GPU as if it's on the gpu, there's no need to wait. However,
> we have to take into account that a request may not be on the GPU
> because it has already completed!
>
> The window is small due to the numerous preceding checks that our target
> has not yet completed, yet there is still a very small window across the
> kmalloc.
Ok, there's a second part to this problem as this only happens under
preempt-to-busy as it requires the request running in the background and
completing after unsubmission.
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine
> synchronisation on gen8+")
So not required.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for asynchronous display power disabling
On Fri, May 03, 2019 at 04:52:58PM +0300, Imre Deak wrote: > > > > [...] > > > > * igt@gem_persistent_relocs@forked-interruptible-thrashing: > > > > - shard-glk: [PASS][1] -> [TIMEOUT][2] > > > >[1]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-glk6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > > >[2]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > > > > > Looks like an unrelated issue: on this GLK there are two HDMI displays > > > connected, so the change shouldn't make any diffence on it. The change > > > only affects the DP detect and hotplug paths, where we'll do now an > > > async power domain put. > > > > There's no history of glk locking up there, > > > > > The machine is still up when the problem happens, the test seems to get > > > stuck and aborted by the test runner (after ~6mins according to [1]). > > > > > > [43/82] (762s left) gem_persistent_relocs (forked-interruptible-thrashing) > > > Starting subtest: forked-interruptible-thrashing > > > Timeout. Killing the current test with SIGQUIT. > > > Timeout. Killing the current test with SIGKILL. > > > > and yet it locked up sufficiently to not respond to a signal, suggesting > > an oops (the test takes 3s normally on glk). > > No pstore logs either. I also noticed that the run [1] above resulted in > an incomplete, if that's indicative of anything. The same goes for the > previous Patchwork_12954 run. Ah, there is actually a pstore log it's just not linked the html page for some reason, Tomi? Here it is: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/pstore25-1556858613_Panic_1.log --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Disable semaphore busywaits on saturated systems
Quoting Ville Syrjälä (2019-05-03 15:04:57) > On Mon, Apr 29, 2019 at 07:00:19PM +0100, Chris Wilson wrote: > > Asking the GPU to busywait on a memory address, perhaps not unexpectedly > > in hindsight for a shared system, leads to bus contention that affects > > CPU programs trying to concurrently access memory. This can manifest as > > a drop in transcode throughput on highly over-saturated workloads. > > We can't use the singalling semaphore variant? That requires us to broadcast a signal to each engine (for which I can hear the cries of cross-powerwell wakes), and currently does not work with execlists + context-id==0. Or at least it failed in my testing. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Disable semaphore busywaits on saturated systems
On Mon, Apr 29, 2019 at 07:00:19PM +0100, Chris Wilson wrote: > Asking the GPU to busywait on a memory address, perhaps not unexpectedly > in hindsight for a shared system, leads to bus contention that affects > CPU programs trying to concurrently access memory. This can manifest as > a drop in transcode throughput on highly over-saturated workloads. We can't use the singalling semaphore variant? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Acquire the signaler's timeline HWSP last
Acquiring the signaler's timeline takes an active reference to their HWSP that we would like to avoid if possible, so take it after performing all of our allocations required to set up the fencing. The acquisition also provides the final check that the target has not already signaled allowing us to avoid the semaphore at the last moment. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 6dbf8dc5cd6a..933a11677f4a 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -813,13 +813,13 @@ emit_semaphore_wait(struct i915_request *to, if (err < 0) return err; - /* We need to pin the signaler's HWSP until we are finished reading. */ - err = i915_timeline_read_hwsp(from, to, &hwsp_offset); + /* Only submit our spinner after the signaler is running! */ + err = i915_request_await_execution(to, from, gfp); if (err) return err; - /* Only submit our spinner after the signaler is running! */ - err = i915_request_await_execution(to, from, gfp); + /* We need to pin the signaler's HWSP until we are finished reading. */ + err = i915_timeline_read_hwsp(from, to, &hwsp_offset); if (err) return err; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for asynchronous display power disabling
On Fri, May 03, 2019 at 01:37:53PM +0100, Chris Wilson wrote: > Quoting Imre Deak (2019-05-03 11:07:55) > > On Fri, May 03, 2019 at 07:50:26AM +, Patchwork wrote: > > > == Series Details == > > > > > > Series: drm/i915: Add support for asynchronous display power disabling > > > URL : https://patchwork.freedesktop.org/series/60242/ > > > State : failure > > > > > > == Summary == > > > > > > CI Bug Log - changes from CI_DRM_6032_full -> Patchwork_12955_full > > > > > > > > > Summary > > > --- > > > > > > **FAILURE** > > > > > > Serious unknown changes coming with Patchwork_12955_full absolutely > > > need to be > > > verified manually. > > > > > > If you think the reported changes have nothing to do with the changes > > > introduced in Patchwork_12955_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_12955_full: > > > > > > ### IGT changes ### > > > > > > Possible regressions > > > > > > * igt@gem_persistent_relocs@forked-interruptible-thrashing: > > > - shard-glk: [PASS][1] -> [TIMEOUT][2] > > >[1]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-glk6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > >[2]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > > > Looks like an unrelated issue: on this GLK there are two HDMI displays > > connected, so the change shouldn't make any diffence on it. The change > > only affects the DP detect and hotplug paths, where we'll do now an > > async power domain put. > > There's no history of glk locking up there, > > > The machine is still up when the problem happens, the test seems to get > > stuck and aborted by the test runner (after ~6mins according to [1]). > > > > [43/82] (762s left) gem_persistent_relocs (forked-interruptible-thrashing) > > Starting subtest: forked-interruptible-thrashing > > Timeout. Killing the current test with SIGQUIT. > > Timeout. Killing the current test with SIGKILL. > > and yet it locked up sufficiently to not respond to a signal, suggesting > an oops (the test takes 3s normally on glk). No pstore logs either. I also noticed that the run [1] above resulted in an incomplete, if that's indicative of anything. The same goes for the previous Patchwork_12954 run. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check the target has not already completed before waiting on it
When we want to wait for a request to be executed, we first ask if it is
not on the GPU as if it's on the gpu, there's no need to wait. However,
we have to take into account that a request may not be on the GPU
because it has already completed!
The window is small due to the numerous preceding checks that our target
has not yet completed, yet there is still a very small window across the
kmalloc.
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine
synchronisation on gen8+")
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d06c45305b03..6dbf8dc5cd6a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -373,7 +373,7 @@ i915_request_await_execution(struct i915_request *rq,
init_irq_work(&cb->work, irq_execute_cb);
spin_lock_irq(&signal->lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || i915_request_completed(signal)) {
i915_sw_fence_complete(cb->fence);
kmem_cache_free(global.slab_execute_cbs, cb);
} else {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
On 03/05/2019 14:37, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-05-03 14:32:59) On 03/05/2019 12:52, Chris Wilson wrote: Inside the signal handler, we expect the requests to be ordered by their breadcrumb such that no later request may be complete if we find an earlier incomplete. Add an assert to check that the next breadcrumb should not be logically before the current. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c index 3cbffd400b1b..a6ffb25f72a2 100644 --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c @@ -99,6 +99,12 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine) struct i915_request *rq = list_entry(pos, typeof(*rq), signal_link); + GEM_BUG_ON(next != &ce->signals && +i915_seqno_passed(rq->fence.seqno, + list_entry(next, + typeof(*rq), + signal_link)->fence.seqno)); I know its only GEM_BUG_ON, but why check for this in the irq handler? You don't trust the insertion, or group deletion? Or just becuase it is the smallest amount of code to piggy-back on existing iteration? At this point, it's documenting the required sorting of ce->signals. The vulnerable part is list insertion. Would you like something like check_signal_order(ce, rq) and use it after insertion as well? We can do prev/next checking, just to be sure. I don't feel strongly either way. Was just curious why you decided to put it where it was. Helper I suppose is better since it is more self-documenting and it's easy to call it from all strategic places. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Add support for asynchronous display power disabling
On Fri, May 03, 2019 at 01:16:04PM +0100, Chris Wilson wrote: > Quoting Imre Deak (2019-05-03 00:26:41) > > By disabling a power domain asynchronously we can restrict holding a > > reference on that power domain to the actual code sequence that > > requires the power to be on for the HW access it's doing, by also > > avoiding unneeded on-off-on togglings of the power domain (since the > > disabling happens with a delay). > > That applies to no-delay. Are we not starting from a state where the > code acquires the powerwell for its immediate use, or it takes and holds > it for protracted durations even when the powerwell is not being used? The latter: we hold it for the entire duration of the detect and hotplug cycles, whereas we would only need it for the actual AUX transfers. By the end of the patchset we only hold it for the required duration, that is the AUX transfer, but to do that we would also want - imo - to avoid the power well on/off ping-pong due to back-to-back AUX transfers. > > One benefit is potential power saving if the delay is chosen properly. > > Which is suggesting that some delay is better power saving than > no-delay? It's believable that powering on cost mores more energy than > normal. But do please fill in a few details on how the delay should be > chosen. It's just my assumption that an on-off-on sequence costs more then just leaving the power well(s) on if the duration is short between the two on events, I haven't measured this. In the extreme case we could reduce the delay to 0, but still keep the disabling asynchronous, which would mean not blocking on the disabling. I measured the disabling time (with wait_for_us) to be ~1ms in average on VLV with the worst case being 4ms. > > In the case of the AUX power domain holding the reference on the domain > > for the minimal amount of time at defined spots is also a requirement: > > Do you mean that there is a minimum duration for which the power well > must be asserted once acquired before being released? I meant that we would need to keep the sequence where we hold the reference short and a well defined place, like what we would have by just holding the reference for the actual AUX transfer (achieved by the end of the patchset). Anything else would make the locking we need for ICL TypeC ports around this sequence rather problematic, adding for instance unnecessary lockdep dependencies, which I would really like to avoid. > > on ICL we need a stricter control of when either kind of AUX power > > domain (TBT-alt or DP-alt) can be enabled and the locking we need for > > that becomes problematic (due to dependencies on other locks) if we > > allow the reference to be held for arbitrarily long periods/places in > > the code. > > > > I chose the disabling delay to be 100msec for now to avoid the unneeded > > toggling (and so not to introduce dmesg spamming) in the DP MST sideband > > signaling code. We could optimize this delay later. > > Or removing the spam. Are we at a point where the error detection is > good enough to pin-point the lack of a particular powerwell wakeref? We don't have a per-powerwell list of registers that we could check against if that's what you mean. So we only detect if no wakeref is held (by this or another thread) or an actual unclaimed access if the power well is really off. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
On 03/05/2019 12:52, Chris Wilson wrote: Inside the signal handler, we expect the requests to be ordered by their breadcrumb such that no later request may be complete if we find an earlier incomplete. Add an assert to check that the next breadcrumb should not be logically before the current. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c index 3cbffd400b1b..a6ffb25f72a2 100644 --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c @@ -99,6 +99,12 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine) struct i915_request *rq = list_entry(pos, typeof(*rq), signal_link); + GEM_BUG_ON(next != &ce->signals && + i915_seqno_passed(rq->fence.seqno, +list_entry(next, + typeof(*rq), + signal_link)->fence.seqno)); I know its only GEM_BUG_ON, but why check for this in the irq handler? You don't trust the insertion, or group deletion? Or just becuase it is the smallest amount of code to piggy-back on existing iteration? Regards, Tvrtko + if (!__request_completed(rq)) break; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
Quoting Tvrtko Ursulin (2019-05-03 14:32:59) > > On 03/05/2019 12:52, Chris Wilson wrote: > > Inside the signal handler, we expect the requests to be ordered by their > > breadcrumb such that no later request may be complete if we find an > > earlier incomplete. Add an assert to check that the next breadcrumb > > should not be logically before the current. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > > b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > > index 3cbffd400b1b..a6ffb25f72a2 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > > +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c > > @@ -99,6 +99,12 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs > > *engine) > > struct i915_request *rq = > > list_entry(pos, typeof(*rq), signal_link); > > > > + GEM_BUG_ON(next != &ce->signals && > > +i915_seqno_passed(rq->fence.seqno, > > + list_entry(next, > > + typeof(*rq), > > + > > signal_link)->fence.seqno)); > > I know its only GEM_BUG_ON, but why check for this in the irq handler? > You don't trust the insertion, or group deletion? Or just becuase it is > the smallest amount of code to piggy-back on existing iteration? At this point, it's documenting the required sorting of ce->signals. The vulnerable part is list insertion. Would you like something like check_signal_order(ce, rq) and use it after insertion as well? We can do prev/next checking, just to be sure. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mm/pgtable: Drop pgtable_t variable from pte_fn_t functions
On Thu, May 02, 2019 at 04:14:57PM +0200, Martin Schwidefsky wrote: > On Thu, 2 May 2019 06:46:23 -0700 > Matthew Wilcox wrote: > > > On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote: > > > Drop the pgtable_t variable from all implementation for pte_fn_t as none > > > of > > > them use it. apply_to_pte_range() should stop computing it as well. Should > > > help us save some cycles. > > > > You didn't add Martin Schwidefsky for some reason. He introduced > > it originally for s390 for sub-page page tables back in 2008 (commit > > 2f569afd9c). I think he should confirm that he no longer needs it. > > With its 2K pte tables s390 can not deal with a (struct page *) as a reference > to a page table. But if there are no user of the apply_to_page_range() API > left which actually make use of the token argument we can safely drop it. Interestingly, I don't think there ever was a user which used that argument. Looking at your 2f56 patch, you only converted one function (presumably there was only one caller of apply_to_page_range() at the time), and it didn't u se any of the arguments. Xen was the initial user, and the two other functions they added also didn't use that argument. Looking at a quick sample of users added since, none of them appear to have ever used that argument. So removing it seems best. Acked-by: Matthew Wilcox ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Disable semaphore busywaits on saturated systems
On 29/04/2019 19:00, Chris Wilson wrote: Asking the GPU to busywait on a memory address, perhaps not unexpectedly in hindsight for a shared system, leads to bus contention that affects CPU programs trying to concurrently access memory. This can manifest as a drop in transcode throughput on highly over-saturated workloads. The only clue offered by perf, is that the bus-cycles (perf stat -e bus-cycles) jumped by 50% when enabling semaphores. This corresponds with extra CPU active cycles being attributed to intel_idle's mwait. This patch introduces a heuristic to try and detect when more than one client is submitting to the GPU pushing it into an oversaturated state. As we already keep track of when the semaphores are signaled, we can inspect their state on submitting the busywait batch and if we planned to use a semaphore but were too late, conclude that the GPU is overloaded and not try to use semaphores in future requests. In practice, this means we optimistically try to use semaphores for the first frame of a transcode job split over multiple engines, and fail is there are multiple clients active and continue not to use semaphores for the subsequent frames in the sequence. Periodically, trying to optimistically switch semaphores back on whenever the client waits to catch up with the transcode results. With 1 client, on Broxton J3455, with the relative fps normalized by %cpu: x no semaphores + drm-tip * throttle ++ |* | |*+ | |**+ | |**+ x | |x * +**+ x | |x x ** +***x xx | |x x ** *+***x *x | |x x* + ** *x *x x | | +x xx+x* + *** * * x * | | +x xx+x* * *** +** * xx * | |* + * +x*x+*+* ***+*+x* * | |*+ +** *+ + +* + *++** *xxx**x***+*+*++*| | |__A_M_| | | |___AM_| | | |A___M|| ++ N Min MaxMedian AvgStddev x 120 2.60475 3.50941 3.31123 3.21439530.21117399 + 1202.3826 3.57077 3.25101 3.14141610.28146407 Difference at 95.0% confidence -0.0729792 +/- 0.0629585 -2.27039% +/- 1.95864% (Student's t, pooled s = 0.248814) * 120 2.35536 3.667133.2849 3.20599170.24618565 No difference proven at 95.0% confidence With 10 clients over-saturating the pipeline: x no semaphores + drm-tip * patch ++ | ++** | | ++** | | ++** | | ++** | | ++xx *** | | ++xx *** | | ++xxx*** | | ++xxx*** | |+++xxx*** | |+++xx | |+++xx | |+++xx | |+++xx | | xx | | + xx | | + x x** | | ++ xxx*** | | ++ xxx*** | | ++ xxx*** | | ++ xx | | ++ | | ++ *
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
== Series Details ==
Series: series starting with [01/13] drm/i915: Assert breadcrumbs are correctly
ordered in the signal handler
URL : https://patchwork.freedesktop.org/series/60257/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6038 -> Patchwork_12957
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12957 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12957, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12957/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12957:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: NOTRUN -> [FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12957/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Known issues
Here are the changes found in Patchwork_12957 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-icl-y: [PASS][2] -> [INCOMPLETE][3] ([fdo#107713] /
[fdo#108569] / [fdo#110581])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6038/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12957/fi-icl-y/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][4] ([fdo#110235]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6038/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12957/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][6] ([fdo#107718] / [fdo#110581]) ->
[PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6038/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12957/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
Participating hosts (52 -> 46)
--
Additional (2): fi-cfl-guc fi-apl-guc
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6038 -> Patchwork_12957
CI_DRM_6038: e53f0aced0dd2d3f2eb32c98a419af87ce23206a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12957: cabb75f2920af68475b0cc6abe83fa53bc6a4ed5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cabb75f2920a drm/i915: Disable semaphore busywaits on saturated systems
9444a1d263e6 drm/i915: Bump signaler priority on adding a waiter
25385cf05c10 drm/i915: Pass i915_sched_node around internally
fa5c579cebdf drm/i915: Rearrange i915_scheduler.c
9fb5d3a33c11 drm/i915/execlists: Don't apply priority boost for resets
e5672eabe995 drm/i915: Only reschedule the submission tasklet if preemption is
possible
45d1066b44cc drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
92a89fd9909c drm/i915: Cancel retire_worker on parking
73b219cd5dc0 drm/i915: Remove delay for idle_work
5d9d9317cac7 drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD
4aa7e9d6d91f drm/i915: Assert the local engine->wakeref is active
6f682e41691d drm/i915: Prefer checking the wakeref itself rather than the
counter
f28a2bf53dc9 drm/i915: Assert breadcrumbs are correctly ordered in the signal
handler
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12957/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Tune down WARN about incorrect VBT TC legacy flag
On Fri, May 03, 2019 at 02:35:59PM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 03:09:00PM +0300, Jani Nikula wrote:
> > On Thu, 02 May 2019, Imre Deak wrote:
> > > Looks like VBT contains again the wrong information about a port's TypeC
> > > legacy vs. DP-alt/TBT-alt type. There is no further issues after we
> > > notice this and fix it up, so tune down the WARN to be a a DRM_ERROR.
> > >
> > > This also avoids CI tainting the kernel and stopping the test run.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110578
> > > Cc: Jani Nikula
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 4e7b8d29d733..07fa2670a677 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5230,9 +5230,12 @@ static bool icl_tc_port_connected(struct
> > > drm_i915_private *dev_priv,
> > >* WARN if we got a legacy port HPD, but VBT didn't mark the port as
> >
> >
> > With the comment fixed,
> >
> > Reviewed-by: Jani Nikula
> >
> > >* legacy. Treat the port as legacy from now on.
> > >*/
> > > - if (WARN_ON(!intel_dig_port->tc_legacy_port &&
> > > - I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)))
> > > + if (!intel_dig_port->tc_legacy_port &&
> > > + I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)) {
> > > + DRM_ERROR("VBT incorrectly claims port %c is not TypeC
> > > legacy\n",
> > > + port_name(port));
> > > intel_dig_port->tc_legacy_port = true;
>
> DRM_ERRROR still causes CI failures (e.g. module reload, where I guess
> this ends up in the logs).
>
> If we really can fully fix it up I think a DRM_INFO is the right level.
We have to wait until the first legacy HPD interrupt, whereas with a
correct VBT info we would configure the correct mode right from the
start. So I think it's still a problem and we should be complaining
about it louder even later.
I filed an HSD for it and would hope it would be treated as a real issue
by that team, not just yet another HSD. For that reason too I'd go
keeping it as an error, not to lose it from the radar.
Meanwhile, the error message is very specific (about this particular port
and scenario) so I think CI filtering could cope with marking it as a
known issue, until we get it fixed in VBT.
> -Daniel
>
> > > + }
> > > is_legacy = intel_dig_port->tc_legacy_port;
> > >
> > > /*
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
== Series Details == Series: series starting with [01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler URL : https://patchwork.freedesktop.org/series/60257/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Assert breadcrumbs are correctly ordered in the signal handler Okay! Commit: drm/i915: Prefer checking the wakeref itself rather than the counter Okay! Commit: drm/i915: Assert the local engine->wakeref is active Okay! Commit: drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD Okay! Commit: drm/i915: Remove delay for idle_work Okay! Commit: drm/i915: Cancel retire_worker on parking Okay! Commit: drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches) Okay! Commit: drm/i915: Only reschedule the submission tasklet if preemption is possible -O:drivers/gpu/drm/i915/gt/intel_engine.h:124:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/gt/intel_engine.h:124:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Don't apply priority boost for resets Okay! Commit: drm/i915: Rearrange i915_scheduler.c Okay! Commit: drm/i915: Pass i915_sched_node around internally Okay! Commit: drm/i915: Bump signaler priority on adding a waiter Okay! Commit: drm/i915: Disable semaphore busywaits on saturated systems +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with drm/i915/execlists: Flush the tasklet on parking (rev2)
== Series Details == Series: series starting with drm/i915/execlists: Flush the tasklet on parking (rev2) URL : https://patchwork.freedesktop.org/series/60216/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6036_full -> Patchwork_12956_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12956_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12956_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_12956_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled: - shard-iclb: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-iclb2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html Known issues Here are the changes found in Patchwork_12956_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][2] -> [FAIL][3] ([fdo#105957]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-skl8/igt@gem_...@reset-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-skl8/igt@gem_...@reset-stress.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([fdo#104108] / [fdo#107773] / [fdo#110581]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-skl1/igt@gem_workarou...@suspend-resume-fd.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-skl10/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([fdo#107807] / [fdo#110581]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-skl5/igt@i915_pm_...@basic-rte.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-skl10/igt@i915_pm_...@basic-rte.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][8] -> [DMESG-WARN][9] ([fdo#108566]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-apl5/igt@i915_susp...@sysfs-reader.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: [PASS][10] -> [FAIL][11] ([fdo#102887] / [fdo#105363]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-kbl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-kbl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-gtt: - shard-snb: [PASS][12] -> [SKIP][13] ([fdo#109271]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-snb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-mmap-gtt.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-snb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-tilingchange: - shard-iclb: [PASS][14] -> [FAIL][15] ([fdo#103167]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-iclb2/igt@kms_frontbuffer_track...@fbc-tilingchange.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-iclb5/igt@kms_frontbuffer_track...@fbc-tilingchange.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-iclb: [PASS][16] -> [FAIL][17] ([fdo#109247]) +19 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-iclb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-iclb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: [PASS][18] -> [INCOMPLETE][19] ([fdo#104108] / [fdo#110581]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-skl9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/shard-skl10/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: [PASS][20] -> [FAIL][21] ([fdo#110038]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/shard-iclb1/igt@kms_pl...@plane-position-covered-pipe-b-planes.html [21
Re: [Intel-gfx] [PATCH] drm/i915: Tune down WARN about incorrect VBT TC legacy flag
On Thu, May 02, 2019 at 03:09:00PM +0300, Jani Nikula wrote:
> On Thu, 02 May 2019, Imre Deak wrote:
> > Looks like VBT contains again the wrong information about a port's TypeC
> > legacy vs. DP-alt/TBT-alt type. There is no further issues after we
> > notice this and fix it up, so tune down the WARN to be a a DRM_ERROR.
> >
> > This also avoids CI tainting the kernel and stopping the test run.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110578
> > Cc: Jani Nikula
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 4e7b8d29d733..07fa2670a677 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5230,9 +5230,12 @@ static bool icl_tc_port_connected(struct
> > drm_i915_private *dev_priv,
> > * WARN if we got a legacy port HPD, but VBT didn't mark the port as
>
>
> With the comment fixed,
>
> Reviewed-by: Jani Nikula
>
> > * legacy. Treat the port as legacy from now on.
> > */
> > - if (WARN_ON(!intel_dig_port->tc_legacy_port &&
> > - I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)))
> > + if (!intel_dig_port->tc_legacy_port &&
> > + I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)) {
> > + DRM_ERROR("VBT incorrectly claims port %c is not TypeC
> > legacy\n",
> > + port_name(port));
> > intel_dig_port->tc_legacy_port = true;
DRM_ERRROR still causes CI failures (e.g. module reload, where I guess
this ends up in the logs).
If we really can fully fix it up I think a DRM_INFO is the right level.
-Daniel
> > + }
> > is_legacy = intel_dig_port->tc_legacy_port;
> >
> > /*
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for asynchronous display power disabling
Quoting Imre Deak (2019-05-03 11:07:55) > On Fri, May 03, 2019 at 07:50:26AM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Add support for asynchronous display power disabling > > URL : https://patchwork.freedesktop.org/series/60242/ > > State : failure > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_6032_full -> Patchwork_12955_full > > > > > > Summary > > --- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_12955_full absolutely need > > to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_12955_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_12955_full: > > > > ### IGT changes ### > > > > Possible regressions > > > > * igt@gem_persistent_relocs@forked-interruptible-thrashing: > > - shard-glk: [PASS][1] -> [TIMEOUT][2] > >[1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-glk6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > Looks like an unrelated issue: on this GLK there are two HDMI displays > connected, so the change shouldn't make any diffence on it. The change > only affects the DP detect and hotplug paths, where we'll do now an > async power domain put. There's no history of glk locking up there, > The machine is still up when the problem happens, the test seems to get > stuck and aborted by the test runner (after ~6mins according to [1]). > > [43/82] (762s left) gem_persistent_relocs (forked-interruptible-thrashing) > Starting subtest: forked-interruptible-thrashing > Timeout. Killing the current test with SIGQUIT. > Timeout. Killing the current test with SIGKILL. and yet it locked up sufficiently to not respond to a signal, suggesting an oops (the test takes 3s normally on glk). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Add support for asynchronous display power disabling
Quoting Imre Deak (2019-05-03 00:26:41) > By disabling a power domain asynchronously we can restrict holding a > reference on that power domain to the actual code sequence that > requires the power to be on for the HW access it's doing, by also > avoiding unneeded on-off-on togglings of the power domain (since the > disabling happens with a delay). That applies to no-delay. Are we not starting from a state where the code acquires the powerwell for its immediate use, or it takes and holds it for protracted durations even when the powerwell is not being used? > One benefit is potential power saving if the delay is chosen properly. Which is suggesting that some delay is better power saving than no-delay? It's believable that powering on cost mores more energy than normal. But do please fill in a few details on how the delay should be chosen. > In the case of the AUX power domain holding the reference on the domain > for the minimal amount of time at defined spots is also a requirement: Do you mean that there is a minimum duration for which the power well must be asserted once acquired before being released? > on ICL we need a stricter control of when either kind of AUX power > domain (TBT-alt or DP-alt) can be enabled and the locking we need for > that becomes problematic (due to dependencies on other locks) if we > allow the reference to be held for arbitrarily long periods/places in > the code. > > I chose the disabling delay to be 100msec for now to avoid the unneeded > toggling (and so not to introduce dmesg spamming) in the DP MST sideband > signaling code. We could optimize this delay later. Or removing the spam. Are we at a point where the error detection is good enough to pin-point the lack of a particular powerwell wakeref? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2
Am 03.05.19 um 14:09 schrieb Daniel Vetter: > [CAUTION: External Email] > > On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote: >> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: >>> On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: Add a structure for the parameters of dma_buf_attach, this makes it much easier to add new parameters later on. >>> I don't understand this reasoning. What are the "new parameters" that >>> are being proposed, and why do we need to put them into memory to pass >>> them across this interface? >>> >>> If the intention is to make it easier to change the interface, passing >>> parameters in this manner mean that it's easy for the interface to >>> change and drivers not to notice the changes, since the compiler will >>> not warn (unless some member of the structure that the driver is using >>> gets removed, in which case it will error.) >>> >>> Additions to the structure will go unnoticed by drivers - what if the >>> caller is expecting some different kind of behaviour, and the driver >>> ignores that new addition? >> Well, exactly that's the intention here: That the drivers using this >> interface should be able to ignore the new additions for now as long as they >> are not going to use them. >> >> The background is that we have multiple interface changes in the pipeline, >> and each step requires new optional parameters. >> >>> This doesn't seem to me like a good idea. >> Well, the obvious alternatives are: >> >> a) Change all drivers to explicitly provide NULL/0 for the new parameters. >> >> b) Use a wrapper, so that the function signature of dma_buf_attach stays the >> same. >> >> Key point here is that I have an invalidation callback change, a P2P patch >> set and some locking changes which all require adding new parameters or >> flags. And at each step I would then start to change all drivers, adding >> some more NULL pointers or flags with 0 default value. >> >> I'm actually perfectly fine going down any route, but this just seemed to me >> simplest and with the least risk of breaking anything. Opinions? > I think given all our discussions and plans the argument object makes tons > of sense. Much easier to document well than a long list of parameters. > Maybe we should make it const, so it could work like an ops/func table and > we could store it as a pointer in the dma_buf_attachment? Yeah, the invalidation callback and P2P flags are constant. But the importer_priv field isn't. We could do something like adding the importer_priv field as parameter and the other two as const structure. Third alternative would be to throw out all the DRM abstraction and just embed the attachment structure in the buffer object and get completely rid of the importer_priv field (probably the cleanest alternative, but also the most work todo). Christian. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/13] drm/i915: Pass i915_sched_node around internally
To simplify the next patch, update bump_priority and schedule to accept
the internal i915_sched_ndoe directly and not expect a request pointer.
add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)
Function old new delta
i915_schedule_bump_priority 109 113 +4
i915_schedule 50 54 +4
__i915_schedule 922 907 -15
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 33 +++
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 4a95cf2201a7..380cb7343a10 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -189,7 +189,7 @@ static void kick_submission(struct intel_engine_cs *engine,
int prio)
tasklet_hi_schedule(&engine->execlists.tasklet);
}
-static void __i915_schedule(struct i915_request *rq,
+static void __i915_schedule(struct i915_sched_node *rq,
const struct i915_sched_attr *attr)
{
struct intel_engine_cs *engine;
@@ -203,13 +203,13 @@ static void __i915_schedule(struct i915_request *rq,
lockdep_assert_held(&schedule_lock);
GEM_BUG_ON(prio == I915_PRIORITY_INVALID);
- if (i915_request_completed(rq))
+ if (prio <= READ_ONCE(rq->attr.priority))
return;
- if (prio <= READ_ONCE(rq->sched.attr.priority))
+ if (node_signaled(rq))
return;
- stack.signaler = &rq->sched;
+ stack.signaler = rq;
list_add(&stack.dfs_link, &dfs);
/*
@@ -260,9 +260,9 @@ static void __i915_schedule(struct i915_request *rq,
* execlists_submit_request()), we can set our own priority and skip
* acquiring the engine locks.
*/
- if (rq->sched.attr.priority == I915_PRIORITY_INVALID) {
- GEM_BUG_ON(!list_empty(&rq->sched.link));
- rq->sched.attr = *attr;
+ if (rq->attr.priority == I915_PRIORITY_INVALID) {
+ GEM_BUG_ON(!list_empty(&rq->link));
+ rq->attr = *attr;
if (stack.dfs_link.next == stack.dfs_link.prev)
return;
@@ -271,7 +271,7 @@ static void __i915_schedule(struct i915_request *rq,
}
memset(&cache, 0, sizeof(cache));
- engine = rq->engine;
+ engine = node_to_request(rq)->engine;
spin_lock(&engine->timeline.lock);
/* Fifo and depth-first replacement ensure our deps execute before us */
@@ -322,13 +322,20 @@ static void __i915_schedule(struct i915_request *rq,
void i915_schedule(struct i915_request *rq, const struct i915_sched_attr *attr)
{
spin_lock_irq(&schedule_lock);
- __i915_schedule(rq, attr);
+ __i915_schedule(&rq->sched, attr);
spin_unlock_irq(&schedule_lock);
}
+static void __bump_priority(struct i915_sched_node *node, unsigned int bump)
+{
+ struct i915_sched_attr attr = node->attr;
+
+ attr.priority |= bump;
+ __i915_schedule(node, &attr);
+}
+
void i915_schedule_bump_priority(struct i915_request *rq, unsigned int bump)
{
- struct i915_sched_attr attr;
unsigned long flags;
GEM_BUG_ON(bump & ~I915_PRIORITY_MASK);
@@ -337,11 +344,7 @@ void i915_schedule_bump_priority(struct i915_request *rq,
unsigned int bump)
return;
spin_lock_irqsave(&schedule_lock, flags);
-
- attr = rq->sched.attr;
- attr.priority |= bump;
- __i915_schedule(rq, &attr);
-
+ __bump_priority(&rq->sched, bump);
spin_unlock_irqrestore(&schedule_lock, flags);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/13] drm/i915: Only reschedule the submission tasklet if preemption is possible
If we couple the scheduler more tightly with the execlists policy, we
can apply the preemption policy to the question of whether we need to
kick the tasklet at all for this priority bump.
v2: Rephrase it as a core i915 policy and not an execlists foible.
v3: Pull the kick together.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 18 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 7 +++-
drivers/gpu/drm/i915/i915_request.c | 2 --
drivers/gpu/drm/i915/i915_scheduler.c | 37 -
drivers/gpu/drm/i915/i915_scheduler.h | 18 ++
drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
7 files changed, 50 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 9e2a183a351c..9359b3a7ad9c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -106,24 +106,6 @@ hangcheck_action_to_str(const enum
intel_engine_hangcheck_action a)
void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
-static inline bool __execlists_need_preempt(int prio, int last)
-{
- /*
-* Allow preemption of low -> normal -> high, but we do
-* not allow low priority tasks to preempt other low priority
-* tasks under the impression that latency for low priority
-* tasks does not matter (as much as background throughput),
-* so kiss.
-*
-* More naturally we would write
-* prio >= max(0, last);
-* except that we wish to prevent triggering preemption at the same
-* priority level: the task that is running should remain running
-* to preserve FIFO ordering of dependencies.
-*/
- return prio > max(I915_PRIORITY_NORMAL - 1, last);
-}
-
static inline void
execlists_set_active(struct intel_engine_execlists *execlists,
unsigned int bit)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 90900c7d7058..afcdfc440bbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -252,8 +252,8 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* ourselves, ignore the request.
*/
last_prio = effective_prio(rq);
- if (!__execlists_need_preempt(engine->execlists.queue_priority_hint,
- last_prio))
+ if (!i915_scheduler_need_preempt(engine->execlists.queue_priority_hint,
+last_prio))
return false;
/*
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 84538f69185b..4b042893dc0e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -638,14 +638,19 @@ static struct i915_request *dummy_request(struct
intel_engine_cs *engine)
GEM_BUG_ON(i915_request_completed(rq));
i915_sw_fence_init(&rq->submit, dummy_notify);
- i915_sw_fence_commit(&rq->submit);
+ set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
return rq;
}
static void dummy_request_free(struct i915_request *dummy)
{
+ /* We have to fake the CS interrupt to kick the next request */
+ i915_sw_fence_commit(&dummy->submit);
+
i915_request_mark_complete(dummy);
+ dma_fence_signal(&dummy->fence);
+
i915_sched_node_fini(&dummy->sched);
i915_sw_fence_fini(&dummy->submit);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d06c45305b03..8cb3ed5531e3 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1377,9 +1377,7 @@ long i915_request_wait(struct i915_request *rq,
if (flags & I915_WAIT_PRIORITY) {
if (!i915_request_started(rq) && INTEL_GEN(rq->i915) >= 6)
gen6_rps_boost(rq);
- local_bh_disable(); /* suspend tasklets for reprioritisation */
i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
- local_bh_enable(); /* kick tasklets en masse */
}
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 39bc4f54e272..fadf0cd9c75a 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -261,16 +261,30 @@ sched_lock_engine(const struct i915_sched_node *node,
return engine;
}
-static bool inflight(const struct i915_request *rq,
-const struct intel_engine_cs *engine)
+static inline int rq_prio(const struct i915_request *rq)
{
- const struct i915_request *active;
+ return rq->sched.attr.priority | __NO_PREEMPTION;
+}
+
+static void kick_submission(struc
Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2
On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote: > Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: > > On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: > > > Add a structure for the parameters of dma_buf_attach, this makes it much > > > easier > > > to add new parameters later on. > > I don't understand this reasoning. What are the "new parameters" that > > are being proposed, and why do we need to put them into memory to pass > > them across this interface? > > > > If the intention is to make it easier to change the interface, passing > > parameters in this manner mean that it's easy for the interface to > > change and drivers not to notice the changes, since the compiler will > > not warn (unless some member of the structure that the driver is using > > gets removed, in which case it will error.) > > > > Additions to the structure will go unnoticed by drivers - what if the > > caller is expecting some different kind of behaviour, and the driver > > ignores that new addition? > > Well, exactly that's the intention here: That the drivers using this > interface should be able to ignore the new additions for now as long as they > are not going to use them. > > The background is that we have multiple interface changes in the pipeline, > and each step requires new optional parameters. > > > This doesn't seem to me like a good idea. > > Well, the obvious alternatives are: > > a) Change all drivers to explicitly provide NULL/0 for the new parameters. > > b) Use a wrapper, so that the function signature of dma_buf_attach stays the > same. > > Key point here is that I have an invalidation callback change, a P2P patch > set and some locking changes which all require adding new parameters or > flags. And at each step I would then start to change all drivers, adding > some more NULL pointers or flags with 0 default value. > > I'm actually perfectly fine going down any route, but this just seemed to me > simplest and with the least risk of breaking anything. Opinions? I think given all our discussions and plans the argument object makes tons of sense. Much easier to document well than a long list of parameters. Maybe we should make it const, so it could work like an ops/func table and we could store it as a pointer in the dma_buf_attachment? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2
Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin: On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: Add a structure for the parameters of dma_buf_attach, this makes it much easier to add new parameters later on. I don't understand this reasoning. What are the "new parameters" that are being proposed, and why do we need to put them into memory to pass them across this interface? If the intention is to make it easier to change the interface, passing parameters in this manner mean that it's easy for the interface to change and drivers not to notice the changes, since the compiler will not warn (unless some member of the structure that the driver is using gets removed, in which case it will error.) Additions to the structure will go unnoticed by drivers - what if the caller is expecting some different kind of behaviour, and the driver ignores that new addition? Well, exactly that's the intention here: That the drivers using this interface should be able to ignore the new additions for now as long as they are not going to use them. The background is that we have multiple interface changes in the pipeline, and each step requires new optional parameters. This doesn't seem to me like a good idea. Well, the obvious alternatives are: a) Change all drivers to explicitly provide NULL/0 for the new parameters. b) Use a wrapper, so that the function signature of dma_buf_attach stays the same. Key point here is that I have an invalidation callback change, a P2P patch set and some locking changes which all require adding new parameters or flags. And at each step I would then start to change all drivers, adding some more NULL pointers or flags with 0 default value. I'm actually perfectly fine going down any route, but this just seemed to me simplest and with the least risk of breaking anything. Opinions? Thanks, Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/13] drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD
After realising we need to sample RING_START to detect context switches
from preemption events that do not allow for the seqno to advance, we
can also realise that the seqno itself is just a distance along the ring
and so can be replaced by sampling RING_HEAD.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine.h | 15 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 5 ++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 8 ++---
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 ---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 32 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
7 files changed, 12 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index f5b0f27cecb6..9e2a183a351c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -233,8 +233,6 @@ intel_write_status_page(struct intel_engine_cs *engine, int
reg, u32 value)
*/
#define I915_GEM_HWS_PREEMPT 0x32
#define I915_GEM_HWS_PREEMPT_ADDR (I915_GEM_HWS_PREEMPT * sizeof(u32))
-#define I915_GEM_HWS_HANGCHECK 0x34
-#define I915_GEM_HWS_HANGCHECK_ADDR(I915_GEM_HWS_HANGCHECK * sizeof(u32))
#define I915_GEM_HWS_SEQNO 0x40
#define I915_GEM_HWS_SEQNO_ADDR(I915_GEM_HWS_SEQNO *
sizeof(u32))
#define I915_GEM_HWS_SCRATCH 0x80
@@ -566,17 +564,4 @@ static inline bool inject_preempt_hang(struct
intel_engine_execlists *execlists)
#endif
-static inline u32
-intel_engine_next_hangcheck_seqno(struct intel_engine_cs *engine)
-{
- return engine->hangcheck.next_seqno =
- next_pseudo_random32(engine->hangcheck.next_seqno);
-}
-
-static inline u32
-intel_engine_get_hangcheck_seqno(struct intel_engine_cs *engine)
-{
- return intel_read_status_page(engine, I915_GEM_HWS_HANGCHECK);
-}
-
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 416d7e2e6f8c..4c3753c1b573 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -721,6 +721,7 @@ static int measure_breadcrumb_dw(struct intel_engine_cs
*engine)
goto out_timeline;
dw = engine->emit_fini_breadcrumb(&frame->rq, frame->cs) - frame->cs;
+ GEM_BUG_ON(dw & 1); /* RING_TAIL must be qword aligned */
i915_timeline_unpin(&frame->timeline);
@@ -1444,9 +1445,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "*** WEDGED ***\n");
drm_printf(m, "\tAwake? %d\n", atomic_read(&engine->wakeref.count));
- drm_printf(m, "\tHangcheck %x:%x [%d ms]\n",
- engine->hangcheck.last_seqno,
- engine->hangcheck.next_seqno,
+ drm_printf(m, "\tHangcheck: %d ms ago\n",
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c0ab11b12e14..e381c1c73902 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -54,8 +54,7 @@ struct intel_instdone {
struct intel_engine_hangcheck {
u64 acthd;
u32 last_ring;
- u32 last_seqno;
- u32 next_seqno;
+ u32 last_head;
unsigned long action_timestamp;
struct intel_instdone instdone;
};
diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
index 721ab74a382f..3a4d09b80fa0 100644
--- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
@@ -28,7 +28,7 @@
struct hangcheck {
u64 acthd;
u32 ring;
- u32 seqno;
+ u32 head;
enum intel_engine_hangcheck_action action;
unsigned long action_timestamp;
int deadlock;
@@ -134,16 +134,16 @@ static void hangcheck_load_sample(struct intel_engine_cs
*engine,
struct hangcheck *hc)
{
hc->acthd = intel_engine_get_active_head(engine);
- hc->seqno = intel_engine_get_hangcheck_seqno(engine);
hc->ring = ENGINE_READ(engine, RING_START);
+ hc->head = ENGINE_READ(engine, RING_HEAD);
}
static void hangcheck_store_sample(struct intel_engine_cs *engine,
const struct hangcheck *hc)
{
engine->hangcheck.acthd = hc->acthd;
- engine->hangcheck.last_seqno = hc->seqno;
engine->hangcheck.last_ring = hc->ring;
+ engine->hangcheck.last_head = hc->head;
}
static enum intel_engine_hangcheck_action
@@ -156,7 +156,7 @@ hangcheck_get_action(struct intel
[Intel-gfx] [PATCH 02/13] drm/i915: Prefer checking the wakeref itself rather than the counter
The counter goes to zero at the start of the parking cycle, but the
wakeref itself is held until the end. Likewise, the counter becomes one
at the end of the unparking, but the wakeref is taken first. If we check
the wakeref instead of the counter, we include the unpark/unparking time
as intel_wakeref_is_active(), and do not spuriously declare inactive if
we fail to park (i.e. the parking and wakeref drop is postponed).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_wakeref.c | 20 +---
drivers/gpu/drm/i915/intel_wakeref.h | 2 +-
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
b/drivers/gpu/drm/i915/intel_wakeref.c
index 1f94bc4ff9e4..91196d9612bb 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -7,6 +7,19 @@
#include "intel_drv.h"
#include "intel_wakeref.h"
+static void rpm_get(struct drm_i915_private *i915, struct intel_wakeref *wf)
+{
+ wf->wakeref = intel_runtime_pm_get(i915);
+}
+
+static void rpm_put(struct drm_i915_private *i915, struct intel_wakeref *wf)
+{
+ intel_wakeref_t wakeref = fetch_and_zero(&wf->wakeref);
+
+ intel_runtime_pm_put(i915, wakeref);
+ GEM_BUG_ON(!wakeref);
+}
+
int __intel_wakeref_get_first(struct drm_i915_private *i915,
struct intel_wakeref *wf,
int (*fn)(struct intel_wakeref *wf))
@@ -21,11 +34,11 @@ int __intel_wakeref_get_first(struct drm_i915_private *i915,
if (!atomic_read(&wf->count)) {
int err;
- wf->wakeref = intel_runtime_pm_get(i915);
+ rpm_get(i915, wf);
err = fn(wf);
if (unlikely(err)) {
- intel_runtime_pm_put(i915, wf->wakeref);
+ rpm_put(i915, wf);
mutex_unlock(&wf->mutex);
return err;
}
@@ -46,7 +59,7 @@ int __intel_wakeref_put_last(struct drm_i915_private *i915,
err = fn(wf);
if (likely(!err))
- intel_runtime_pm_put(i915, wf->wakeref);
+ rpm_put(i915, wf);
else
atomic_inc(&wf->count);
mutex_unlock(&wf->mutex);
@@ -58,4 +71,5 @@ void __intel_wakeref_init(struct intel_wakeref *wf, struct
lock_class_key *key)
{
__mutex_init(&wf->mutex, "wakeref", key);
atomic_set(&wf->count, 0);
+ wf->wakeref = 0;
}
diff --git a/drivers/gpu/drm/i915/intel_wakeref.h
b/drivers/gpu/drm/i915/intel_wakeref.h
index a979d638344b..db742291211c 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -127,7 +127,7 @@ intel_wakeref_unlock(struct intel_wakeref *wf)
static inline bool
intel_wakeref_active(struct intel_wakeref *wf)
{
- return atomic_read(&wf->count);
+ return READ_ONCE(wf->wakeref);
}
#endif /* INTEL_WAKEREF_H */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/13] drm/i915: Cancel retire_worker on parking
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although that the igt is trying to idle from one child while submitting
from another may be a contributing factor as to why it runs so slowly...
v2: Use the non-sync version of cancel_delayed_work(), we only need to
stop it from being scheduled as we independently check whether now is
the right time to be parking.
Testcase: igt/gem_concurrent_blit
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index ae91ad7cb31e..fa9c2ebd966a 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
container_of(work, typeof(*i915), gem.idle_work);
+ bool restart = true;
+ cancel_delayed_work(&i915->gem.retire_work);
mutex_lock(&i915->drm.struct_mutex);
intel_wakeref_lock(&i915->gt.wakeref);
- if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
+ if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work)) {
i915_gem_park(i915);
+ restart = false;
+ }
intel_wakeref_unlock(&i915->gt.wakeref);
mutex_unlock(&i915->drm.struct_mutex);
+ if (restart)
+ queue_delayed_work(i915->wq,
+ &i915->gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static void retire_work_handler(struct work_struct *work)
@@ -52,10 +60,9 @@ static void retire_work_handler(struct work_struct *work)
mutex_unlock(&i915->drm.struct_mutex);
}
- if (intel_wakeref_active(&i915->gt.wakeref))
- queue_delayed_work(i915->wq,
- &i915->gem.retire_work,
- round_jiffies_up_relative(HZ));
+ queue_delayed_work(i915->wq,
+ &i915->gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static int pm_notifier(struct notifier_block *nb,
@@ -140,7 +147,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- drain_delayed_work(&i915->gem.retire_work);
GEM_BUG_ON(i915->gt.awake);
flush_work(&i915->gem.idle_work);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d919f512042c..9fd02025d382 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -58,7 +58,6 @@ static void mock_device_release(struct drm_device *dev)
i915_gem_contexts_lost(i915);
mutex_unlock(&i915->drm.struct_mutex);
- drain_delayed_work(&i915->gem.retire_work);
flush_work(&i915->gem.idle_work);
i915_gem_drain_workqueue(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/13] drm/i915: Assert the local engine->wakeref is active
Due to the asynchronous tasklet and recursive GT wakeref, it may happen
that we submit to the engine (underneath it's own wakeref) prior to the
central wakeref being marked as taken. Switch to checking the local wakeref
for greater consistency.
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 5907a9613641..416d7e2e6f8c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1090,6 +1090,9 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (i915_reset_failed(engine->i915))
return true;
+ if (!intel_wakeref_active(&engine->wakeref))
+ return true;
+
/* Waiting to drain ELSP? */
if (READ_ONCE(engine->execlists.active)) {
struct tasklet_struct *t = &engine->execlists.tasklet;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7d69d07490e8..5580b6f1aa0c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -535,7 +535,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
* that all ELSP are drained i.e. we have processed the CSB,
* before allowing ourselves to idle and calling intel_runtime_pm_put().
*/
- GEM_BUG_ON(!engine->i915->gt.awake);
+ GEM_BUG_ON(!intel_wakeref_active(&engine->wakeref));
/*
* ELSQ note: the submit queue is not cleared after being submitted
@@ -1085,7 +1085,7 @@ static void execlists_submission_tasklet(unsigned long
data)
GEM_TRACE("%s awake?=%d, active=%x\n",
engine->name,
- !!engine->i915->gt.awake,
+ !!intel_wakeref_active(&engine->wakeref),
engine->execlists.active);
spin_lock_irqsave(&engine->timeline.lock, flags);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13] drm/i915: Bump signaler priority on adding a waiter
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event reordering the no-preemption
WAITs. To resolve this issue we currently promote all requests to WAIT
on unsubmission, however this interferes with the timeslicing
requirement that we do not apply any implicit promotion that will defeat
the round-robin timeslice list. (If we automatically promote the active
request it will go back to the head of the queue and not the tail!)
So we need implicit promotion to prevent reordering around semaphores
where we are not allowed to preempt, and we must avoid implicit
promotion on unsubmission. So instead of at unsubmit, if we apply that
implicit promotion on adding the dependency, we avoid the semaphore
deadlock and we also reduce the gains made by the promotion for user
space waiting. Furthermore, by keeping the earlier dependencies at a
higher level, we reduce the search space for timeslicing without
altering runtime scheduling too badly (no dependencies at all will be
assigned a higher priority for rrul).
v2: Limit the bump to external edges (as originally intended) i.e.
between contexts and out to the user.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 12
drivers/gpu/drm/i915/i915_request.c | 9 -
drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
drivers/gpu/drm/i915/i915_scheduler_types.h | 3 ++-
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 4b042893dc0e..5b3d8e33f1cf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -98,12 +98,14 @@ static int live_busywait_preempt(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_unlock;
- ctx_hi->sched.priority = INT_MAX;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = INT_MIN;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
@@ -958,12 +960,14 @@ static int live_preempt_hang(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_spin_lo;
- ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
for_each_engine(engine, i915, id) {
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 8cb3ed5531e3..065da1bcbb4c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -468,15 +468,6 @@ void __i915_request_unsubmit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
- /*
-* As we do not allow WAIT to preempt inflight requests,
-* once we have executed a request, along with triggering
-* any execution callbacks, we must preserve its ordering
-* within the non-preemptible FIFO.
-*/
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- request->sched.attr.priority |= __NO_PREEMPTION;
-
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags))
i915_request_cancel_breadcrumb(request);
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 380cb7343a10..ff0ca5718f97 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -391,6 +391,16 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
!node_started(signal))
node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
+ /*
+* As we do not allow WAIT to preempt inflight requests,
+* once we have executed a request, along with triggering
+* any execution callbacks, we must preserve its ordering
+* within the non-preemptible FIFO.
+*/
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK);
+
[Intel-gfx] [PATCH 01/13] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
Inside the signal handler, we expect the requests to be ordered by their breadcrumb such that no later request may be complete if we find an earlier incomplete. Add an assert to check that the next breadcrumb should not be logically before the current. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c index 3cbffd400b1b..a6ffb25f72a2 100644 --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c @@ -99,6 +99,12 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine) struct i915_request *rq = list_entry(pos, typeof(*rq), signal_link); + GEM_BUG_ON(next != &ce->signals && + i915_seqno_passed(rq->fence.seqno, +list_entry(next, + typeof(*rq), + signal_link)->fence.seqno)); + if (!__request_completed(rq)) break; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/13] drm/i915: Remove delay for idle_work
The original intent for the delay before running the idle_work was to
provide a hysteresis to avoid ping-ponging the device runtime-pm. Since
then we have also pulled in some memory management and general device
management for parking. But with the inversion of the wakeref handling,
GEM is no longer responsible for the wakeref and by the time we call the
idle_work, the device is asleep. It seems appropriate now to drop the
delay and just run the worker immediately to flush the cached GEM state
before sleeping.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_pm.c| 21 +++
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
5 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index da4fb9f34d27..674c8c936057 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3931,8 +3931,8 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_IDLE) {
do {
flush_delayed_work(&i915->gem.retire_work);
- drain_delayed_work(&i915->gem.idle_work);
} while (READ_ONCE(i915->gt.awake));
+ flush_work(&i915->gem.idle_work);
}
if (val & DROP_FREED)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64fa353a62bb..2bf518fea36e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2031,7 +2031,7 @@ struct drm_i915_private {
* arrive within a small period of time, we fire
* off the idle_work.
*/
- struct delayed_work idle_work;
+ struct work_struct idle_work;
} gem;
/* For i945gm vblank irq vs. C3 workaround */
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 49b0ce594f20..ae91ad7cb31e 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private *i915)
static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
- container_of(work, typeof(*i915), gem.idle_work.work);
+ container_of(work, typeof(*i915), gem.idle_work);
mutex_lock(&i915->drm.struct_mutex);
intel_wakeref_lock(&i915->gt.wakeref);
- if (!intel_wakeref_active(&i915->gt.wakeref))
+ if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
i915_gem_park(i915);
intel_wakeref_unlock(&i915->gt.wakeref);
@@ -74,9 +74,7 @@ static int pm_notifier(struct notifier_block *nb,
break;
case INTEL_GT_PARK:
- mod_delayed_work(i915->wq,
-&i915->gem.idle_work,
-msecs_to_jiffies(100));
+ queue_work(i915->wq, &i915->gem.idle_work);
break;
}
@@ -142,16 +140,11 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- GEM_BUG_ON(i915->gt.awake);
- cancel_delayed_work_sync(&i915->gpu_error.hangcheck_work);
-
drain_delayed_work(&i915->gem.retire_work);
+ GEM_BUG_ON(i915->gt.awake);
+ flush_work(&i915->gem.idle_work);
- /*
-* As the idle_work is rearming if it detects a race, play safe and
-* repeat the flush until it is definitely idle.
-*/
- drain_delayed_work(&i915->gem.idle_work);
+ cancel_delayed_work_sync(&i915->gpu_error.hangcheck_work);
i915_gem_drain_freed_objects(i915);
@@ -242,7 +235,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
void i915_gem_init__pm(struct drm_i915_private *i915)
{
- INIT_DELAYED_WORK(&i915->gem.idle_work, idle_work_handler);
+ INIT_WORK(&i915->gem.idle_work, idle_work_handler);
INIT_DELAYED_WORK(&i915->gem.retire_work, retire_work_handler);
i915->gem.pm_notifier.notifier_call = pm_notifier;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
index 088b2aa05dcd..b926d1cd165d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -509,7 +509,7 @@ static void disable_retire_worker(struct drm_i915_private
*i915)
intel_gt_pm_get(i915);
cancel_delayed_work_sync(&i915->gem.retire_work);
- cancel_delayed_work_sync(&i915->gem.idle_work);
+ flush_work(&i915->gem.idle_work);
}
static void restore_retire_worker(struct drm_i915_
[Intel-gfx] [PATCH 07/13] drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
If the user is racing a call to debugfs/i915_drop_caches with ongoing
submission from another thread/process, we may never end up idling the
GPU and be uninterruptibly spinning in debugfs/i915_drop_caches trying
to catch an idle moment.
Just flush the work once, that should be enough to park the system under
correct conditions. Outside of those we either have a driver bug or the
user is racing themselves. Sadly, because the user may be provoking the
unwanted situation we can't put a warn here to attract attention to a
probable bug.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 674c8c936057..ca6e12193470 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3929,9 +3929,7 @@ i915_drop_caches_set(void *data, u64 val)
fs_reclaim_release(GFP_KERNEL);
if (val & DROP_IDLE) {
- do {
- flush_delayed_work(&i915->gem.retire_work);
- } while (READ_ONCE(i915->gt.awake));
+ flush_delayed_work(&i915->gem.retire_work);
flush_work(&i915->gem.idle_work);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/13] drm/i915/execlists: Don't apply priority boost for resets
Do not treat reset as a normal preemption event and avoid giving the
guilty request a priority boost for simply being active at the time of
reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index afcdfc440bbd..6419bcaf1ecc 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -371,11 +371,11 @@ static void unwind_wa_tail(struct i915_request *rq)
}
static struct i915_request *
-__unwind_incomplete_requests(struct intel_engine_cs *engine)
+__unwind_incomplete_requests(struct intel_engine_cs *engine, int boost)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
+ int prio = I915_PRIORITY_INVALID | boost;
lockdep_assert_held(&engine->timeline.lock);
@@ -419,8 +419,9 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
* in the priority queue, but they will not gain immediate access to
* the GPU.
*/
- if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(active)) {
- prio |= ACTIVE_PRIORITY;
+ if (~prio & boost && __i915_request_has_started(active)) {
+ prio |= boost;
+ GEM_BUG_ON(active->sched.attr.priority >= prio);
active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
@@ -435,7 +436,7 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- return __unwind_incomplete_requests(engine);
+ return __unwind_incomplete_requests(engine, 0);
}
static inline void
@@ -656,7 +657,8 @@ static void complete_preempt_context(struct
intel_engine_execlists *execlists)
execlists_cancel_port_requests(execlists);
__unwind_incomplete_requests(container_of(execlists,
struct intel_engine_cs,
- execlists));
+ execlists),
+ACTIVE_PRIORITY);
}
static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -1909,7 +1911,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
execlists_cancel_port_requests(execlists);
/* Push back any incomplete requests for replay after the reset. */
- rq = __unwind_incomplete_requests(engine);
+ rq = __unwind_incomplete_requests(engine, 0);
if (!rq)
goto out_replay;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/13] drm/i915: Disable semaphore busywaits on saturated systems
Asking the GPU to busywait on a memory address, perhaps not unexpectedly in hindsight for a shared system, leads to bus contention that affects CPU programs trying to concurrently access memory. This can manifest as a drop in transcode throughput on highly over-saturated workloads. The only clue offered by perf, is that the bus-cycles (perf stat -e bus-cycles) jumped by 50% when enabling semaphores. This corresponds with extra CPU active cycles being attributed to intel_idle's mwait. This patch introduces a heuristic to try and detect when more than one client is submitting to the GPU pushing it into an oversaturated state. As we already keep track of when the semaphores are signaled, we can inspect their state on submitting the busywait batch and if we planned to use a semaphore but were too late, conclude that the GPU is overloaded and not try to use semaphores in future requests. In practice, this means we optimistically try to use semaphores for the first frame of a transcode job split over multiple engines, and fail is there are multiple clients active and continue not to use semaphores for the subsequent frames in the sequence. Periodically, trying to optimistically switch semaphores back on whenever the client waits to catch up with the transcode results. With 1 client, on Broxton J3455, with the relative fps normalized by %cpu: x no semaphores + drm-tip * throttle ++ |* | |*+ | |**+ | |**+ x | |x * +**+ x | |x x ** +***x xx | |x x ** *+***x *x | |x x* + ** *x *x x | | +x xx+x* + *** * * x * | | +x xx+x* * *** +** * xx * | |* + * +x*x+*+* ***+*+x* * | |*+ +** *+ + +* + *++** *xxx**x***+*+*++*| | |__A_M_| | | |___AM_| | | |A___M|| ++ N Min MaxMedian AvgStddev x 120 2.60475 3.50941 3.31123 3.21439530.21117399 + 1202.3826 3.57077 3.25101 3.14141610.28146407 Difference at 95.0% confidence -0.0729792 +/- 0.0629585 -2.27039% +/- 1.95864% (Student's t, pooled s = 0.248814) * 120 2.35536 3.667133.2849 3.20599170.24618565 No difference proven at 95.0% confidence With 10 clients over-saturating the pipeline: x no semaphores + drm-tip * patch ++ | ++** | | ++** | | ++** | | ++** | | ++xx *** | | ++xx *** | | ++xxx*** | | ++xxx*** | |+++xxx*** | |+++xx | |+++xx | |+++xx | |+++xx | | xx | | + xx | | + x x** | | ++ xxx*** | | ++ xxx*** | | ++ xxx*** | | ++ xx | | ++ | | ++ | |
[Intel-gfx] [PATCH 10/13] drm/i915: Rearrange i915_scheduler.c
To avoid pulling in a forward declaration in the next patch, move the
i915_sched_node handling to after the main dfs of the scheduler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 210 +-
1 file changed, 105 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index fadf0cd9c75a..4a95cf2201a7 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -35,109 +35,6 @@ static inline bool node_signaled(const struct
i915_sched_node *node)
return i915_request_completed(node_to_request(node));
}
-void i915_sched_node_init(struct i915_sched_node *node)
-{
- INIT_LIST_HEAD(&node->signalers_list);
- INIT_LIST_HEAD(&node->waiters_list);
- INIT_LIST_HEAD(&node->link);
- node->attr.priority = I915_PRIORITY_INVALID;
- node->semaphores = 0;
- node->flags = 0;
-}
-
-static struct i915_dependency *
-i915_dependency_alloc(void)
-{
- return kmem_cache_alloc(global.slab_dependencies, GFP_KERNEL);
-}
-
-static void
-i915_dependency_free(struct i915_dependency *dep)
-{
- kmem_cache_free(global.slab_dependencies, dep);
-}
-
-bool __i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal,
- struct i915_dependency *dep,
- unsigned long flags)
-{
- bool ret = false;
-
- spin_lock_irq(&schedule_lock);
-
- if (!node_signaled(signal)) {
- INIT_LIST_HEAD(&dep->dfs_link);
- list_add(&dep->wait_link, &signal->waiters_list);
- list_add(&dep->signal_link, &node->signalers_list);
- dep->signaler = signal;
- dep->flags = flags;
-
- /* Keep track of whether anyone on this chain has a semaphore */
- if (signal->flags & I915_SCHED_HAS_SEMAPHORE_CHAIN &&
- !node_started(signal))
- node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
-
- ret = true;
- }
-
- spin_unlock_irq(&schedule_lock);
-
- return ret;
-}
-
-int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
-{
- struct i915_dependency *dep;
-
- dep = i915_dependency_alloc();
- if (!dep)
- return -ENOMEM;
-
- if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_ALLOC))
- i915_dependency_free(dep);
-
- return 0;
-}
-
-void i915_sched_node_fini(struct i915_sched_node *node)
-{
- struct i915_dependency *dep, *tmp;
-
- GEM_BUG_ON(!list_empty(&node->link));
-
- spin_lock_irq(&schedule_lock);
-
- /*
-* Everyone we depended upon (the fences we wait to be signaled)
-* should retire before us and remove themselves from our list.
-* However, retirement is run independently on each timeline and
-* so we may be called out-of-order.
-*/
- list_for_each_entry_safe(dep, tmp, &node->signalers_list, signal_link) {
- GEM_BUG_ON(!node_signaled(dep->signaler));
- GEM_BUG_ON(!list_empty(&dep->dfs_link));
-
- list_del(&dep->wait_link);
- if (dep->flags & I915_DEPENDENCY_ALLOC)
- i915_dependency_free(dep);
- }
-
- /* Remove ourselves from everyone who depends upon us */
- list_for_each_entry_safe(dep, tmp, &node->waiters_list, wait_link) {
- GEM_BUG_ON(dep->signaler != node);
- GEM_BUG_ON(!list_empty(&dep->dfs_link));
-
- list_del(&dep->signal_link);
- if (dep->flags & I915_DEPENDENCY_ALLOC)
- i915_dependency_free(dep);
- }
-
- spin_unlock_irq(&schedule_lock);
-}
-
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
{
return rb_entry(rb, struct i915_priolist, node);
@@ -239,6 +136,11 @@ i915_sched_lookup_priolist(struct intel_engine_cs *engine,
int prio)
return &p->requests[idx];
}
+void __i915_priolist_free(struct i915_priolist *p)
+{
+ kmem_cache_free(global.slab_priorities, p);
+}
+
struct sched_cache {
struct list_head *priolist;
};
@@ -443,9 +345,107 @@ void i915_schedule_bump_priority(struct i915_request *rq,
unsigned int bump)
spin_unlock_irqrestore(&schedule_lock, flags);
}
-void __i915_priolist_free(struct i915_priolist *p)
+void i915_sched_node_init(struct i915_sched_node *node)
{
- kmem_cache_free(global.slab_priorities, p);
+ INIT_LIST_HEAD(&node->signalers_list);
+ INIT_LIST_HEAD(&node->waiters_list);
+ INIT_LIST_HEAD(&node->link);
+ node->attr.priority = I915_PRIORITY_INVALID;
+ node->semaphores = 0;
+
Re: [Intel-gfx] [PATCH 09/14] drm/i915: Delay semaphore submission until the start of the signaler
On 01/05/2019 12:45, Chris Wilson wrote:
Currently we submit the semaphore busywait as soon as the signaler is
submitted to HW. However, we may submit the signaler as the tail of a
batch of requests, and even not as the first context in the HW list,
i.e. the busywait may start spinning far in advance of the signaler even
starting.
If we wait until the request before the signaler is completed before
submitting the busywait, we prevent the busywait from starting too
early, if the signaler is not first in submission port.
To handle the case where the signaler is at the start of the second (or
later) submission port, we will need to delay the execution callback
until we know the context is promoted to port0. A challenge for later.
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
sation on gen8+")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 2e22da66a56c..8cb3ed5531e3 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -770,6 +770,21 @@ i915_request_create(struct intel_context *ce)
return rq;
}
+static int
+i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
+{
+ if (list_is_first(&signal->ring_link, &signal->ring->request_list))
+ return 0;
+
+ signal = list_prev_entry(signal, ring_link);
+ if (i915_timeline_sync_is_later(rq->timeline, &signal->fence))
+ return 0;
+
+ return i915_sw_fence_await_dma_fence(&rq->submit,
+&signal->fence, 0,
+I915_FENCE_GFP);
+}
+
static int
emit_semaphore_wait(struct i915_request *to,
struct i915_request *from,
@@ -788,6 +803,10 @@ emit_semaphore_wait(struct i915_request *to,
&from->fence, 0,
I915_FENCE_GFP);
+ err = i915_request_await_start(to, from);
+ if (err < 0)
+ return err;
+
err = i915_sw_fence_await_dma_fence(&to->semaphore,
&from->fence, 0,
I915_FENCE_GFP);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/14] drm/i915: Only reschedule the submission tasklet if preemption is possible
Quoting Tvrtko Ursulin (2019-05-03 11:53:31)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > If we couple the scheduler more tightly with the execlists policy, we
> > can apply the preemption policy to the question of whether we need to
> > kick the tasklet at all for this priority bump.
> >
> > v2: Rephrase it as a core i915 policy and not an execlists foible.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine.h | 18 --
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 7 ++-
> > drivers/gpu/drm/i915/i915_request.c | 2 --
> > drivers/gpu/drm/i915/i915_scheduler.c | 18 +++---
> > drivers/gpu/drm/i915/i915_scheduler.h | 18 ++
> > drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
> > 7 files changed, 39 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > index f5b0f27cecb6..06d785533502 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > @@ -106,24 +106,6 @@ hangcheck_action_to_str(const enum
> > intel_engine_hangcheck_action a)
> >
> > void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
> >
> > -static inline bool __execlists_need_preempt(int prio, int last)
> > -{
> > - /*
> > - * Allow preemption of low -> normal -> high, but we do
> > - * not allow low priority tasks to preempt other low priority
> > - * tasks under the impression that latency for low priority
> > - * tasks does not matter (as much as background throughput),
> > - * so kiss.
> > - *
> > - * More naturally we would write
> > - * prio >= max(0, last);
> > - * except that we wish to prevent triggering preemption at the same
> > - * priority level: the task that is running should remain running
> > - * to preserve FIFO ordering of dependencies.
> > - */
> > - return prio > max(I915_PRIORITY_NORMAL - 1, last);
> > -}
> > -
> > static inline void
> > execlists_set_active(struct intel_engine_execlists *execlists,
> >unsigned int bit)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 7be54b868d8e..35aae7b5c6b9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -251,8 +251,8 @@ static inline bool need_preempt(const struct
> > intel_engine_cs *engine,
> >* ourselves, ignore the request.
> >*/
> > last_prio = effective_prio(rq);
> > - if (!__execlists_need_preempt(engine->execlists.queue_priority_hint,
> > - last_prio))
> > + if
> > (!i915_scheduler_need_preempt(engine->execlists.queue_priority_hint,
> > + last_prio))
> > return false;
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > index 84538f69185b..4b042893dc0e 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > @@ -638,14 +638,19 @@ static struct i915_request *dummy_request(struct
> > intel_engine_cs *engine)
> > GEM_BUG_ON(i915_request_completed(rq));
> >
> > i915_sw_fence_init(&rq->submit, dummy_notify);
> > - i915_sw_fence_commit(&rq->submit);
> > + set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
> >
> > return rq;
> > }
> >
> > static void dummy_request_free(struct i915_request *dummy)
> > {
> > + /* We have to fake the CS interrupt to kick the next request */
> > + i915_sw_fence_commit(&dummy->submit);
> > +
> > i915_request_mark_complete(dummy);
> > + dma_fence_signal(&dummy->fence);
> > +
> > i915_sched_node_fini(&dummy->sched);
> > i915_sw_fence_fini(&dummy->submit);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index af8c9fa5e066..2e22da66a56c 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1358,9 +1358,7 @@ long i915_request_wait(struct i915_request *rq,
> > if (flags & I915_WAIT_PRIORITY) {
> > if (!i915_request_started(rq) && INTEL_GEN(rq->i915) >= 6)
> > gen6_rps_boost(rq);
> > - local_bh_disable(); /* suspend tasklets for reprioritisation
> > */
> > i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
> > - local_bh_enable(); /* kick tasklets en masse */
> > }
> >
> > wait.tsk = current;
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 39bc4f54e272..88d18600f5db 100644
> > --- a/drivers/gpu/drm/i915/i91
Re: [Intel-gfx] [PATCH 08/14] drm/i915: Only reschedule the submission tasklet if preemption is possible
On 01/05/2019 12:45, Chris Wilson wrote:
If we couple the scheduler more tightly with the execlists policy, we
can apply the preemption policy to the question of whether we need to
kick the tasklet at all for this priority bump.
v2: Rephrase it as a core i915 policy and not an execlists foible.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 18 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 7 ++-
drivers/gpu/drm/i915/i915_request.c | 2 --
drivers/gpu/drm/i915/i915_scheduler.c | 18 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 18 ++
drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
7 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index f5b0f27cecb6..06d785533502 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -106,24 +106,6 @@ hangcheck_action_to_str(const enum
intel_engine_hangcheck_action a)
void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
-static inline bool __execlists_need_preempt(int prio, int last)
-{
- /*
-* Allow preemption of low -> normal -> high, but we do
-* not allow low priority tasks to preempt other low priority
-* tasks under the impression that latency for low priority
-* tasks does not matter (as much as background throughput),
-* so kiss.
-*
-* More naturally we would write
-* prio >= max(0, last);
-* except that we wish to prevent triggering preemption at the same
-* priority level: the task that is running should remain running
-* to preserve FIFO ordering of dependencies.
-*/
- return prio > max(I915_PRIORITY_NORMAL - 1, last);
-}
-
static inline void
execlists_set_active(struct intel_engine_execlists *execlists,
unsigned int bit)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7be54b868d8e..35aae7b5c6b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -251,8 +251,8 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* ourselves, ignore the request.
*/
last_prio = effective_prio(rq);
- if (!__execlists_need_preempt(engine->execlists.queue_priority_hint,
- last_prio))
+ if (!i915_scheduler_need_preempt(engine->execlists.queue_priority_hint,
+last_prio))
return false;
/*
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 84538f69185b..4b042893dc0e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -638,14 +638,19 @@ static struct i915_request *dummy_request(struct
intel_engine_cs *engine)
GEM_BUG_ON(i915_request_completed(rq));
i915_sw_fence_init(&rq->submit, dummy_notify);
- i915_sw_fence_commit(&rq->submit);
+ set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
return rq;
}
static void dummy_request_free(struct i915_request *dummy)
{
+ /* We have to fake the CS interrupt to kick the next request */
+ i915_sw_fence_commit(&dummy->submit);
+
i915_request_mark_complete(dummy);
+ dma_fence_signal(&dummy->fence);
+
i915_sched_node_fini(&dummy->sched);
i915_sw_fence_fini(&dummy->submit);
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index af8c9fa5e066..2e22da66a56c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1358,9 +1358,7 @@ long i915_request_wait(struct i915_request *rq,
if (flags & I915_WAIT_PRIORITY) {
if (!i915_request_started(rq) && INTEL_GEN(rq->i915) >= 6)
gen6_rps_boost(rq);
- local_bh_disable(); /* suspend tasklets for reprioritisation */
i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
- local_bh_enable(); /* kick tasklets en masse */
}
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 39bc4f54e272..88d18600f5db 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -261,16 +261,20 @@ sched_lock_engine(const struct i915_sched_node *node,
return engine;
}
-static bool inflight(const struct i915_request *rq,
-const struct intel_engine_cs *engine)
+static inline int rq_prio(const struct i915_request *rq)
{
- const struct i915_request *active;
+ return rq->sched.attr.priority | __NO_PREEM
Re: [Intel-gfx] [PATCH 01/14] drm/i915/hangcheck: Track context changes
Quoting Tvrtko Ursulin (2019-05-03 11:36:55)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > Given sufficient preemption, we may see a busy system that doesn't
> > advance seqno while performing work across multiple contexts, and given
> > sufficient pathology not even notice a change in ACTHD. What does change
> > between the preempting contexts is their RING, so take note of that and
> > treat a change in the ring address as being an indication of forward
> > progress.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_hangcheck.c| 12 +---
> > 2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 9d64e33f8427..c0ab11b12e14 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -53,6 +53,7 @@ struct intel_instdone {
> >
> > struct intel_engine_hangcheck {
> > u64 acthd;
> > + u32 last_ring;
> > u32 last_seqno;
> > u32 next_seqno;
> > unsigned long action_timestamp;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
> > b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
> > index e5eaa06fe74d..721ab74a382f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
> > @@ -27,6 +27,7 @@
> >
> > struct hangcheck {
> > u64 acthd;
> > + u32 ring;
> > u32 seqno;
> > enum intel_engine_hangcheck_action action;
> > unsigned long action_timestamp;
> > @@ -134,6 +135,7 @@ static void hangcheck_load_sample(struct
> > intel_engine_cs *engine,
> > {
> > hc->acthd = intel_engine_get_active_head(engine);
> > hc->seqno = intel_engine_get_hangcheck_seqno(engine);
> > + hc->ring = ENGINE_READ(engine, RING_START);
> > }
> >
> > static void hangcheck_store_sample(struct intel_engine_cs *engine,
> > @@ -141,18 +143,22 @@ static void hangcheck_store_sample(struct
> > intel_engine_cs *engine,
> > {
> > engine->hangcheck.acthd = hc->acthd;
> > engine->hangcheck.last_seqno = hc->seqno;
> > + engine->hangcheck.last_ring = hc->ring;
> > }
> >
> > static enum intel_engine_hangcheck_action
> > hangcheck_get_action(struct intel_engine_cs *engine,
> >const struct hangcheck *hc)
> > {
> > - if (engine->hangcheck.last_seqno != hc->seqno)
> > - return ENGINE_ACTIVE_SEQNO;
> > -
> > if (intel_engine_is_idle(engine))
> > return ENGINE_IDLE;
> >
> > + if (engine->hangcheck.last_ring != hc->ring)
> > + return ENGINE_ACTIVE_SEQNO;
> > +
> > + if (engine->hangcheck.last_seqno != hc->seqno)
> > + return ENGINE_ACTIVE_SEQNO;
> > +
> > return engine_stuck(engine, hc->acthd);
> > }
> >
> >
>
> Reviewed-by: Tvrtko Ursulin
>
> This should be associated with engine seqno removal, right? Not sure if
> it triggers in reality to be really needed.
Yeah, I'm not convinced we have a pressing need until timeslicing as
userspace can only create 1024 preemption events by itself, and that
should be ok... I can imagine that userspace submits a semaphore at
address 0 in each and waits 1s before submitting the next preemption
event... That would fire the current hangcheck. (Possibly legitimately
but the blame would not be effective at defeating the hostile client.)
It wasn't until timeslicing that I noticed the effect in practice.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/14] drm/i915/hangcheck: Track context changes
On 01/05/2019 12:45, Chris Wilson wrote:
Given sufficient preemption, we may see a busy system that doesn't
advance seqno while performing work across multiple contexts, and given
sufficient pathology not even notice a change in ACTHD. What does change
between the preempting contexts is their RING, so take note of that and
treat a change in the ring address as being an indication of forward
progress.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 12 +---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9d64e33f8427..c0ab11b12e14 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -53,6 +53,7 @@ struct intel_instdone {
struct intel_engine_hangcheck {
u64 acthd;
+ u32 last_ring;
u32 last_seqno;
u32 next_seqno;
unsigned long action_timestamp;
diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
index e5eaa06fe74d..721ab74a382f 100644
--- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
@@ -27,6 +27,7 @@
struct hangcheck {
u64 acthd;
+ u32 ring;
u32 seqno;
enum intel_engine_hangcheck_action action;
unsigned long action_timestamp;
@@ -134,6 +135,7 @@ static void hangcheck_load_sample(struct intel_engine_cs
*engine,
{
hc->acthd = intel_engine_get_active_head(engine);
hc->seqno = intel_engine_get_hangcheck_seqno(engine);
+ hc->ring = ENGINE_READ(engine, RING_START);
}
static void hangcheck_store_sample(struct intel_engine_cs *engine,
@@ -141,18 +143,22 @@ static void hangcheck_store_sample(struct intel_engine_cs
*engine,
{
engine->hangcheck.acthd = hc->acthd;
engine->hangcheck.last_seqno = hc->seqno;
+ engine->hangcheck.last_ring = hc->ring;
}
static enum intel_engine_hangcheck_action
hangcheck_get_action(struct intel_engine_cs *engine,
const struct hangcheck *hc)
{
- if (engine->hangcheck.last_seqno != hc->seqno)
- return ENGINE_ACTIVE_SEQNO;
-
if (intel_engine_is_idle(engine))
return ENGINE_IDLE;
+ if (engine->hangcheck.last_ring != hc->ring)
+ return ENGINE_ACTIVE_SEQNO;
+
+ if (engine->hangcheck.last_seqno != hc->seqno)
+ return ENGINE_ACTIVE_SEQNO;
+
return engine_stuck(engine, hc->acthd);
}
Reviewed-by: Tvrtko Ursulin
This should be associated with engine seqno removal, right? Not sure if
it triggers in reality to be really needed.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Flush the tasklet on parking
On 03/05/2019 09:09, Chris Wilson wrote:
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
v2: Do the full check for idleness before parking, to be sure we flush
any residual interrupt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 27 +
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
5 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 650bc325a901..416d7e2e6f8c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1097,6 +1097,8 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (READ_ONCE(engine->execlists.active)) {
struct tasklet_struct *t = &engine->execlists.tasklet;
+ synchronize_hardirq(engine->i915->drm.irq);
+
local_bh_disable();
if (tasklet_trylock(t)) {
/* Must wait for any GPU reset in progress. */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3976aea3c1d1..ccf034764741 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -10,7 +10,7 @@
#include "intel_engine_pm.h"
#include "intel_gt_pm.h"
-static int intel_engine_unpark(struct intel_wakeref *wf)
+static int __engine_unpark(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
@@ -37,7 +37,24 @@ static int intel_engine_unpark(struct intel_wakeref *wf)
void intel_engine_pm_get(struct intel_engine_cs *engine)
{
- intel_wakeref_get(engine->i915, &engine->wakeref, intel_engine_unpark);
+ intel_wakeref_get(engine->i915, &engine->wakeref, __engine_unpark);
+}
+
+void intel_engine_park(struct intel_engine_cs *engine)
+{
+ /*
+* We are committed now to parking this engine, make sure there
+* will be no more interrupts arriving later and the engine
+* is truly idle.
+*/
+ if (wait_for(intel_engine_is_idle(engine), 10)) {
+ struct drm_printer p = drm_debug_printer(__func__);
+
+ dev_err(engine->i915->drm.dev,
+ "%s is not idle before parking\n",
+ engine->name);
+ intel_engine_dump(engine, &p, NULL);
+ }
}
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
@@ -56,7 +73,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
* Note, we do this without taking the timeline->mutex. We cannot
* as we may be called while retiring the kernel context and so
* already underneath the timeline->mutex. Instead we rely on the
-* exclusive property of the intel_engine_park that prevents anyone
+* exclusive property of the __engine_park that prevents anyone
* else from creating a request on this engine. This also requires
* that the ring is empty and we avoid any waits while constructing
* the context, as they assume protection by the timeline->mutex.
@@ -76,7 +93,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
return false;
}
-static int intel_engine_park(struct intel_wakeref *wf)
+static int __engine_park(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
@@ -114,7 +131,7 @@ static int intel_engine_park(struct intel_wakeref *wf)
void intel_engine_pm_put(struct intel_engine_cs *engine)
{
- intel_wakeref_put(engine->i915, &engine->wakeref, intel_engine_park);
+ intel_wakeref_put(engine->i915, &engine->wakeref, __engine_park);
}
void intel_engine_init__pm(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 143ac90ba117..b326cd993d60 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -13,6 +13,8 @@ struct intel_engine_cs;
void intel_engine_pm_get(struct intel_engine_cs *engine);
void intel_engine_pm_put(struct intel_engine_cs *engine);
+void intel_engine_park(struct intel_engine_cs *engine);
+
void intel_engine_init__pm(struct intel_engine_cs *engine);
int intel_engines_resume(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8c2eeff79f03..5580b6f1aa0c 100644
--- a/drivers/gpu/drm/i915/gt/intel
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for asynchronous display power disabling
On Fri, May 03, 2019 at 07:50:26AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add support for asynchronous display power disabling > URL : https://patchwork.freedesktop.org/series/60242/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_6032_full -> Patchwork_12955_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12955_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12955_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_12955_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_persistent_relocs@forked-interruptible-thrashing: > - shard-glk: [PASS][1] -> [TIMEOUT][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-glk6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html Looks like an unrelated issue: on this GLK there are two HDMI displays connected, so the change shouldn't make any diffence on it. The change only affects the DP detect and hotplug paths, where we'll do now an async power domain put. The machine is still up when the problem happens, the test seems to get stuck and aborted by the test runner (after ~6mins according to [1]). [43/82] (762s left) gem_persistent_relocs (forked-interruptible-thrashing) Starting subtest: forked-interruptible-thrashing Timeout. Killing the current test with SIGQUIT. Timeout. Killing the current test with SIGKILL. Build timed out (after 20 minutes) Err: Starting subtest: forked-interruptible-thrashing Received signal SIGQUIT. Stack trace: #0 [fatal_sig_handler+0xd5] #1 [killpg+0x40] #2 [waitpid+0x12] #3 [__waitpid+0x38] #4 [igt_wait_helper+0x44] #5 [igt_stop_helper+0x52] #6 [do_forked_test+0x13e] #7 [__real_main317+0x1b4] #8 [main+0x44] #9 [__libc_start_main+0xe7] #10 [_start+0x2a] [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/runtimes25.log > > > Known issues > > > Here are the changes found in Patchwork_12955_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@i915_pm_rpm@drm-resources-equal: > - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807] / > [fdo#110581]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-skl10/igt@i915_pm_...@drm-resources-equal.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-skl8/igt@i915_pm_...@drm-resources-equal.html > > * > igt@kms_atomic_transition@plane-all-modeset-transition-fencing-internal-panels: > - shard-iclb: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-iclb1/igt@kms_atomic_transit...@plane-all-modeset-transition-fencing-internal-panels.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-iclb2/igt@kms_atomic_transit...@plane-all-modeset-transition-fencing-internal-panels.html > > * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: > - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-skl2/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-skl9/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html > > * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu: > - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103167] / > [fdo#110379]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-skl2/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-skl9/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html > > * igt@kms_frontbuffer_tracking@fbc-tilingchange: > - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar > issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-iclb8/igt@kms_frontbuffer_track...@fbc-tilingchange.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-iclb6/igt@kms_frontbuffer_track...@fbc-tilingchange.html > > * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt: > - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108040]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/sha
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915/execlists: Flush the tasklet on parking (rev2)
== Series Details == Series: series starting with drm/i915/execlists: Flush the tasklet on parking (rev2) URL : https://patchwork.freedesktop.org/series/60216/ State : success == Summary == CI Bug Log - changes from CI_DRM_6036 -> Patchwork_12956 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/60216/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12956 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#109485]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][5] ([fdo#108602] / [fdo#108744] / [fdo#110581]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6036/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [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#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (50 -> 44) -- Additional (1): fi-bsw-n3050 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_6036 -> Patchwork_12956 CI_DRM_6036: 83921f2b51f00d6e999bf3d2255aa6127a96a405 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12956: 9b4fe57a23dddadd28cfdeedd67c4aa1965a3cdb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9b4fe57a23dd drm/i915: Leave engine parking to the engines a500ddbdabf8 drm/i915/execlists: Flush the tasklet on parking == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12956/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Expand subslice mask
On 02/05/2019 15:47, Summers, Stuart wrote:
On Wed, 2019-05-01 at 15:04 -0700, Daniele Ceraolo Spurio wrote:
On 5/1/19 8:34 AM, Stuart Summers wrote:
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice index / 8
v2: fix spacing in set_sseu_info args
use set_sseu_info to initialize sseu data when building
device status in debugfs
rename variables in intel_engine_types.h to avoid checkpatch
warnings
v3: update headers in intel_sseu.h
v4: add const to some sseu_dev_info variables
use sseu->eu_stride for EU stride calculations
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
Can you also get an ack from Lionel, to make sure this all fits with
the
expected reporting?
Cc: Lionel Landwerlin
The change makes sense to me but I haven't had time to verify every
single bit in this patch :)
The i915_query IGT tests should be able to catch some issues on HSW
(which can have 10EUs per subslice).
Acked-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 32 +++--
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 49 +--
drivers/gpu/drm/i915/gt/intel_sseu.h | 16 ++-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 44 +++---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_gpu_error.c| 5 +-
drivers/gpu/drm/i915/i915_query.c| 10 +-
drivers/gpu/drm/i915/intel_device_info.c | 142 +++---
-
11 files changed, 198 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 6e40f8ea9a6a..8f7967cc9a50 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -914,7 +914,7 @@ u32 intel_calculate_mcr_s_ss_select(struct
drm_i915_private *dev_priv)
const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)-
sseu;
u32 mcr_s_ss_select;
u32 slice = fls(sseu->slice_mask);
- u32 subslice = fls(sseu->subslice_mask[slice]);
+ u32 subslice = fls(sseu->subslice_mask[slice * sseu-
ss_stride]);
This (and the registers we use below) only works if ss_stride = 1.
Can
we add a:
GEM_BUG_ON(sseu->ss_stride > 1);
to catch the fact that this function will need updating to handle
that
case if/when we get it?
I'll rework this and post an update.
if (IS_GEN(dev_priv, 10))
mcr_s_ss_select = GEN8_MCR_SLICE(slice) |
@@ -990,6 +990,7 @@ void intel_engine_get_instdone(struct
intel_engine_cs *engine,
struct intel_instdone *instdone)
{
struct drm_i915_private *dev_priv = engine->i915;
+ const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)-
sseu;
struct intel_uncore *uncore = engine->uncore;
u32 mmio_base = engine->mmio_base;
int slice;
@@ -1007,7 +1008,8 @@ void intel_engine_get_instdone(struct
intel_engine_cs *engine,
instdone->slice_common =
intel_uncore_read(uncore, GEN7_SC_INSTDONE);
- for_each_instdone_slice_subslice(dev_priv, slice,
subslice) {
+ for_each_instdone_slice_subslice(dev_priv, sseu, slice,
+subslice) {
instdone->sampler[slice][subslice] =
read_subslice_reg(dev_priv, slice,
subslice,
GEN7_SAMPLER_INSTDONE
);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9d64e33f8427..1710546a2446 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -534,20 +534,22 @@ intel_engine_needs_breadcrumb_tasklet(const
struct intel_engine_cs *engine)
return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
}
-#define instdone_slice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
-
-#define instdone_subslice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.subslice_mask[0])
-
-#define for_each_instdone_slice_subslice(dev_priv__, slice__,
subslice__) \
- for ((slice__) = 0, (subslice__) = 0; \
-(slice__) < I915_MAX_SLICES; \
-(subslice__) = ((subslice__) + 1) < I915_MAX_SUBSLICES ?
(subslice__) + 1 : 0, \
- (slice__) += ((subslice__) == 0)) \
- for_each_if((BIT(slice__) &
instdone_
Re: [Intel-gfx] [PATCH] RFC: hung_task: taint kernel
On Fri, May 03, 2019 at 09:47:03AM +0900, Tetsuo Handa wrote: > On 2019/05/03 5:46, Daniel Vetter wrote: > > There's the hung_task_panic sysctl, but that's a bit an extreme measure. > > As a fallback taint at least the machine. > > > > Our CI uses this to decide when a reboot is necessary, plus to figure > > out whether the kernel is still happy. > > Why your CI can't watch for "blocked for more than" message instead of > setting the taint flag? How does your CI decide a reboot is necessary? We spam an awful lot into dmesg, and at least historically had occasionally trouble capturing it all (we're better than that now I think). Plus the thing that parses dmesg isn't the thing that runs testcases, hence why we started to use taint flags (or procfs lockdep status) and similar things to check the kernel is still alive enough. > There is no need to set the tainted flag when some task was just blocked > for a while. It might be due to memory pressure, it might be due to setting > very short timeout (e.g. a few seconds), it might be due to busy CPUs doing > something else... Yeah I realize that this probably doesn't have much use outside of our CI, but maybe there's someone how likes the idea. Wrt spurious taints: You can disable the hung_tasks checker outright, which also stops the tainting. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Everyone who implements connector_helper_funcs->atomic_check reaches
> into the connector state to get the atomic state. Instead of continuing
> this pattern, change the callback signature to just give atomic state
> and let the driver determine what it does and does not need from it.
>
> Eventually all atomic functions should do this, but that's just too much
> busy work for me.
>
> Changes in v3:
> - Added to the set
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anholt
> Signed-off-by: Sean Paul
Assuming it compiles everywhere and intel-gfx-ci approves too
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> include/drm/drm_modeset_helper_vtables.h | 2 +-
> 10 files changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9d9e47276839..fa5a367507c1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> }
>
> if (funcs->atomic_check)
> - ret = funcs->atomic_check(connector,
> new_connector_state);
> + ret = funcs->atomic_check(connector, state);
> if (ret)
> return ret;
>
> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> continue;
>
> if (funcs->atomic_check)
> - ret = funcs->atomic_check(connector,
> new_connector_state);
> + ret = funcs->atomic_check(connector, state);
> if (ret)
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index b844e8840c6f..e8a5b82e9242 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -103,12 +103,14 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> }
>
> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> - struct drm_connector_state *new_state)
> + struct drm_atomic_state *state)
> {
> + struct drm_connector_state *new_state =
> + drm_atomic_get_new_connector_state(state, conn);
> struct intel_digital_connector_state *new_conn_state =
> to_intel_digital_connector_state(new_state);
> struct drm_connector_state *old_state =
> - drm_atomic_get_old_connector_state(new_state->state, conn);
> + drm_atomic_get_old_connector_state(state, conn);
> struct intel_digital_connector_state *old_conn_state =
> to_intel_digital_connector_state(old_state);
> struct drm_crtc_state *crtc_state;
> @@ -118,7 +120,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> if (!new_state->crtc)
> return 0;
>
> - crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> new_state->crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
>
> /*
>* These properties are handled by fastset, and might not end
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 19d81cef2ab6..89cfec128ba0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -143,9 +143,10 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>
> static int
> intel_dp_mst_atomic_check(struct drm_connector *connector,
> - struct drm_connector_state *new_conn_state)
> + struct drm_atomic_state *state)
> {
> - struct drm_atomic_state *state = new_conn_state->state;
> + struct drm_connector_state *new_conn_state =
> + drm_atomic_get_new_connector_state(state, connector);
> struct drm_connector_state *old_conn_state =
> drm_atomic_get_old_connector_state(state, connector);
> struct intel_connector *intel_connector =
> @@ -155,7 +156,7 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
> struct drm_dp_mst_topology_mgr *mgr;
>
[Intel-gfx] [PATCH] drm/i915/execlists: Flush the tasklet on parking
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
v2: Do the full check for idleness before parking, to be sure we flush
any residual interrupt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 27 +
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
5 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 650bc325a901..416d7e2e6f8c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1097,6 +1097,8 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (READ_ONCE(engine->execlists.active)) {
struct tasklet_struct *t = &engine->execlists.tasklet;
+ synchronize_hardirq(engine->i915->drm.irq);
+
local_bh_disable();
if (tasklet_trylock(t)) {
/* Must wait for any GPU reset in progress. */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3976aea3c1d1..ccf034764741 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -10,7 +10,7 @@
#include "intel_engine_pm.h"
#include "intel_gt_pm.h"
-static int intel_engine_unpark(struct intel_wakeref *wf)
+static int __engine_unpark(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
@@ -37,7 +37,24 @@ static int intel_engine_unpark(struct intel_wakeref *wf)
void intel_engine_pm_get(struct intel_engine_cs *engine)
{
- intel_wakeref_get(engine->i915, &engine->wakeref, intel_engine_unpark);
+ intel_wakeref_get(engine->i915, &engine->wakeref, __engine_unpark);
+}
+
+void intel_engine_park(struct intel_engine_cs *engine)
+{
+ /*
+* We are committed now to parking this engine, make sure there
+* will be no more interrupts arriving later and the engine
+* is truly idle.
+*/
+ if (wait_for(intel_engine_is_idle(engine), 10)) {
+ struct drm_printer p = drm_debug_printer(__func__);
+
+ dev_err(engine->i915->drm.dev,
+ "%s is not idle before parking\n",
+ engine->name);
+ intel_engine_dump(engine, &p, NULL);
+ }
}
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
@@ -56,7 +73,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
* Note, we do this without taking the timeline->mutex. We cannot
* as we may be called while retiring the kernel context and so
* already underneath the timeline->mutex. Instead we rely on the
-* exclusive property of the intel_engine_park that prevents anyone
+* exclusive property of the __engine_park that prevents anyone
* else from creating a request on this engine. This also requires
* that the ring is empty and we avoid any waits while constructing
* the context, as they assume protection by the timeline->mutex.
@@ -76,7 +93,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
return false;
}
-static int intel_engine_park(struct intel_wakeref *wf)
+static int __engine_park(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
@@ -114,7 +131,7 @@ static int intel_engine_park(struct intel_wakeref *wf)
void intel_engine_pm_put(struct intel_engine_cs *engine)
{
- intel_wakeref_put(engine->i915, &engine->wakeref, intel_engine_park);
+ intel_wakeref_put(engine->i915, &engine->wakeref, __engine_park);
}
void intel_engine_init__pm(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 143ac90ba117..b326cd993d60 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -13,6 +13,8 @@ struct intel_engine_cs;
void intel_engine_pm_get(struct intel_engine_cs *engine);
void intel_engine_pm_put(struct intel_engine_cs *engine);
+void intel_engine_park(struct intel_engine_cs *engine);
+
void intel_engine_init__pm(struct intel_engine_cs *engine);
int intel_engines_resume(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8c2eeff79f03..5580b6f1aa0c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -136,6 +136,7 @@
#i
