[Intel-gfx] ✓ Fi.CI.IGT: success for Tiger Lake: add workarounds
== Series Details == Series: Tiger Lake: add workarounds URL : https://patchwork.freedesktop.org/series/64274/ State : success == Summary == CI Bug Log - changes from CI_DRM_6557_full -> Patchwork_13765_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13765_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen: - shard-snb: [PASS][3] -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-64x64-onscreen.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-snb5/igt@kms_cursor_...@pipe-a-cursor-64x64-onscreen.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb7/igt@kms_cursor_...@pipe-b-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-iclb3/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-legacy: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#103355]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103184] / [fdo#103232]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl9/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-skl2/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.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_6557/shard-skl7/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip_tiling@flip-to-y-tiled: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#107931] / [fdo#108134]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb8/igt@kms_flip_til...@flip-to-y-tiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-iclb6/igt@kms_flip_til...@flip-to-y-tiled.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-render.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr2_su@page_flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb3/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13765/shard-iclb7/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_rotation_crc@multiplane-rotation: -
[Intel-gfx] ✓ Fi.CI.IGT: success for Tiger Lake: DKL phy PLLs
== Series Details == Series: Tiger Lake: DKL phy PLLs URL : https://patchwork.freedesktop.org/series/64273/ State : success == Summary == CI Bug Log - changes from CI_DRM_6557_full -> Patchwork_13764_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13764_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb1/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-random: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#103232]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl9/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-skl1/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb6/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-iclb7/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642] / [fdo#111068]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr2_su@page_flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][17] ([fdo#108566]) -> [PASS][18] +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [INCOMPLETE][21] ([fdo#110741]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [FAIL][23] ([fdo#105363]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13764/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank.html * igt@kms_flip@modeset-vs-vblank-race: - shard-glk: [FAIL][25] ([fdo#103060]) ->
[Intel-gfx] ✓ Fi.CI.IGT: success for Tiger Lake: interrupts
== Series Details == Series: Tiger Lake: interrupts URL : https://patchwork.freedesktop.org/series/64272/ State : success == Summary == CI Bug Log - changes from CI_DRM_6557_full -> Patchwork_13763_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13763_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_6557/shard-snb1/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-snb6/igt@gem_...@reset-stress.html * igt@i915_selftest@live_hangcheck: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb4/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-iclb7/igt@i915_selftest@live_hangcheck.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][5] -> [INCOMPLETE][6] ([fdo#103540]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-hsw6/igt@kms_f...@flip-vs-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-hsw2/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103167]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109642] / [fdo#111068]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr2_su@page_flip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-iclb4/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-kbl3/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl3/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-apl7/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html * igt@perf@polling: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#110728]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl1/igt@p...@polling.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-skl10/igt@p...@polling.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [SKIP][21] ([fdo#109271]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-snb6/igt@i915_pm_rc6_reside...@rc6-accuracy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13763/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [INCOMPLETE][25] ([fdo#110741]) -> [PASS][26] [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/tgl: skip setting PORT_CL_DW12_* on initialization
== Series Details == Series: series starting with [CI,1/3] drm/i915/tgl: skip setting PORT_CL_DW12_* on initialization URL : https://patchwork.freedesktop.org/series/64271/ State : success == Summary == CI Bug Log - changes from CI_DRM_6557_full -> Patchwork_13762_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13762_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-kbl: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl4/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-kbl6/igt@gem_...@reset-stress.html * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108840]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb6/igt@i915_pm_...@dpms-mode-unset-lpsp.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-iclb1/igt@i915_pm_...@dpms-mode-unset-lpsp.html * igt@i915_selftest@live_hangcheck: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#108569]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb4/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-iclb2/igt@i915_selftest@live_hangcheck.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl9/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-skl1/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-render.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-render.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-apl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr@psr2_primary_blt: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-iclb2/igt@kms_psr@psr2_primary_blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-iclb1/igt@kms_psr@psr2_primary_blt.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][17] ([fdo#108566]) -> [PASS][18] +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [INCOMPLETE][21] ([fdo#110741]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13762/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [FAIL][23] ([fdo#105363]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6557/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow sharing the idle-barrier from other kernel requests
== Series Details ==
Series: drm/i915: Allow sharing the idle-barrier from other kernel requests
URL : https://patchwork.freedesktop.org/series/64340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6567 -> Patchwork_13778
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/
New tests
-
New tests have been introduced between CI_DRM_6567 and Patchwork_13778:
### New IGT tests (2) ###
* igt@i915_selftest@live_gem_contexts:
- Statuses : 45 pass(s)
- Exec time: [0.38, 28.23] s
* igt@i915_selftest@live_gt_contexts:
- Statuses : 45 pass(s)
- Exec time: [0.35, 1.38] s
Known issues
Here are the changes found in Patchwork_13778 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-bwr-2160:[PASS][1] -> [DMESG-WARN][2] ([fdo#15])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-bwr-2160/igt@i915_selftest@live_execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-bwr-2160/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:[PASS][3] -> [DMESG-FAIL][4] ([fdo#15])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html
- fi-icl-dsi: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] /
[fdo#108569])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278])
+2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][9] -> [FAIL][10] ([fdo#109485])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][11] ([fdo#109271] / [fdo#109278]) ->
[PASS][12] +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#109635 ]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][15] ([fdo#103167]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6567/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13778/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#15]: https://bugs.freedesktop.org/show_bug.cgi?id=15
Participating hosts (51 -> 46)
--
Additional (2): fi-hsw-peppy fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6567 -> Patchwork_13778
CI-20190529: 20190529
CI_DRM_6567: 1fab998f73b885d8f4c000d8d1be971526457b5c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13778: 3adf242161ceab7138c51f3c44c2084341743868 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Allow sharing the idle-barrier from other kernel requests
== Series Details == Series: drm/i915: Allow sharing the idle-barrier from other kernel requests URL : https://patchwork.freedesktop.org/series/64340/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3adf242161ce drm/i915: Allow sharing the idle-barrier from other kernel requests -:123: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #123: new file mode 100644 -:128: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #128: FILE: drivers/gpu/drm/i915/gt/selftest_context.c:1: +/* -:129: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #129: FILE: drivers/gpu/drm/i915/gt/selftest_context.c:2: + * SPDX-License-Identifier: GPL-2.0 total: 0 errors, 3 warnings, 0 checks, 758 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: ignore generated files for header test
== Series Details ==
Series: drm/i915: ignore generated files for header test
URL : https://patchwork.freedesktop.org/series/64339/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6566 -> Patchwork_13777
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/
Known issues
Here are the changes found in Patchwork_13777 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@create-close:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-icl-u3/igt@gem_ba...@create-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-icl-u3/igt@gem_ba...@create-close.html
* igt@i915_module_load@reload-with-fault-injection:
- fi-snb-2520m: [PASS][3] -> [INCOMPLETE][4] ([fdo#105411])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-snb-2520m/igt@i915_module_l...@reload-with-fault-injection.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-snb-2520m/igt@i915_module_l...@reload-with-fault-injection.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][5] -> [FAIL][6] ([fdo#110387])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live_blt:
- fi-cfl-guc: [DMESG-WARN][7] ([fdo#110943]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-cfl-guc/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-cfl-guc/igt@i915_selftest@live_blt.html
* igt@kms_force_connector_basic@force-edid:
- fi-ilk-650: [DMESG-WARN][9] ([fdo#106387]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-ilk-650/igt@kms_force_connector_ba...@force-edid.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-ilk-650/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][11] ([fdo#103167]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [SKIP][13] ([fdo#109271]) -> [PASS][14] +23 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6566/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#110943]: https://bugs.freedesktop.org/show_bug.cgi?id=110943
Participating hosts (54 -> 46)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6566 -> Patchwork_13777
CI-20190529: 20190529
CI_DRM_6566: b3510f679dd4f425f34cdc4c2596a240e09a9e44 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13777: 5b8f13a2b32f4927fae909de8d8e384ee1295647 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5b8f13a2b32f drm/i915: ignore generated files for header test
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13777/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Allow sharing the idle-barrier from other kernel requests
By placing our idle-barriers in the i915_active fence tree, we expose
those for reuse by other components that are issuing requests along the
kernel_context. Reusing the proto-barrier active_node is perfectly fine
as the new request implies a context-switch, and so an opportune point
to run the idle-barrier. However, the proto-barrier is not equivalent
to a normal active_node and care must be taken to avoid dereferencing the
ERR_PTR used as its request marker.
Reported-by: Lionel Landwerlin
Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next
kernel context switch")
Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly")
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
---
Phew, good job we hit the cache on the legacy submission selftests.
---
drivers/gpu/drm/i915/gt/intel_context.c | 40 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 13 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 310 ++
drivers/gpu/drm/i915/i915_active.c| 239 +++---
drivers/gpu/drm/i915/i915_active.h| 2 +-
drivers/gpu/drm/i915/i915_active_types.h | 2 +-
.../drm/i915/selftests/i915_live_selftests.h | 3 +-
8 files changed, 548 insertions(+), 63 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/selftest_context.c
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index d64b45f7ec6d..211ac6568a5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -162,23 +162,41 @@ static int __intel_context_active(struct i915_active
*active)
if (err)
goto err_ring;
+ return 0;
+
+err_ring:
+ intel_ring_unpin(ce->ring);
+err_put:
+ intel_context_put(ce);
+ return err;
+}
+
+int intel_context_active_acquire(struct intel_context *ce)
+{
+ int err;
+
+ err = i915_active_acquire(>active);
+ if (err)
+ return err;
+
/* Preallocate tracking nodes */
if (!i915_gem_context_is_kernel(ce->gem_context)) {
err = i915_active_acquire_preallocate_barrier(>active,
ce->engine);
- if (err)
- goto err_state;
+ if (err) {
+ i915_active_release(>active);
+ return err;
+ }
}
return 0;
+}
-err_state:
- __context_unpin_state(ce->state);
-err_ring:
- intel_ring_unpin(ce->ring);
-err_put:
- intel_context_put(ce);
- return err;
+void intel_context_active_release(struct intel_context *ce)
+{
+ /* Nodes preallocated in intel_context_active() */
+ i915_active_acquire_barrier(>active);
+ i915_active_release(>active);
}
void
@@ -297,3 +315,7 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_context.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 23c7e4c0ce7c..07f9924de48f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -104,17 +104,8 @@ static inline void intel_context_exit(struct intel_context
*ce)
ce->ops->exit(ce);
}
-static inline int intel_context_active_acquire(struct intel_context *ce)
-{
- return i915_active_acquire(>active);
-}
-
-static inline void intel_context_active_release(struct intel_context *ce)
-{
- /* Nodes preallocated in intel_context_active() */
- i915_active_acquire_barrier(>active);
- i915_active_release(>active);
-}
+int intel_context_active_acquire(struct intel_context *ce);
+void intel_context_active_release(struct intel_context *ce);
static inline struct intel_context *intel_context_get(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e74fbf04a68d..ce54092475da 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -90,7 +90,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
/* Check again on the next retirement. */
engine->wakeref_serial = engine->serial + 1;
- i915_request_add_barriers(rq);
+ i915_request_add_active_barriers(rq);
__i915_request_commit(rq);
return false;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
new file mode 100644
index ..e3b45fe747ae
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -0,0 +1,310 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_selftest.h"
+#include
Re: [Intel-gfx] [PATCH] drm/i915: Replace hangcheck by heartbeats
Quoting Bloomfield, Jon (2019-07-26 23:19:38) > Hmmn. We're still on orthogonal perspectives as far as our previous arguments > stand. But it doesn't matter because while thinking through your replies, I > realized there is one argument in favour, which trumps all my previous > arguments against this patch - it makes things deterministic. Without this > patch (or hangcheck), whether a context gets nuked depends on what else is > running. And that's a recipe for confused support emails. > > So I retract my other arguments, thanks for staying with me :-) No worries, it's been really useful, especially realising a few more areas we can improve our resilience. You will get your way eventually. (But what did it cost? Everything.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace hangcheck by heartbeats
Hmmn. We're still on orthogonal perspectives as far as our previous arguments stand. But it doesn't matter because while thinking through your replies, I realized there is one argument in favour, which trumps all my previous arguments against this patch - it makes things deterministic. Without this patch (or hangcheck), whether a context gets nuked depends on what else is running. And that's a recipe for confused support emails. So I retract my other arguments, thanks for staying with me :-) BTW: TDR==Timeout-Detection and Reset. Essentially hangcheck and recovery. > -Original Message- > From: Chris Wilson > Sent: Friday, July 26, 2019 2:30 PM > To: Bloomfield, Jon ; intel- > g...@lists.freedesktop.org > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > Quoting Bloomfield, Jon (2019-07-26 21:58:38) > > > From: Chris Wilson > > > It's no more often than before, you have to fail to advance within an > > > interval, and then deny preemption request. > > > > It's entrapment. You are creating an artificial workload for the context to > impede. Before that artificial workload was injected, the context would have > run to completion, the world would be at peace (and the user would have her > new bitcoin). Instead she stays poor because the DoS police launched an > illegal > sting on her otherwise genius operation. > > It's housekeeping; it's the cost of keeping the engine alive. This > argument is why CPU-isolation came about (aiui). > > > > > I do like the rlimit suggestion, but until we have that, just disabling > > > > TDR > feels > > > like a better stop-gap than nuking innocent compute contexts just in case > they > > > might block something. > > > > > > They're not innocent though :-p > > > > They are innocent until proven guilty :-) > > > > > > > > Disabling hangcheck (no idea why you confuse that with the recovery > > > procedure) makes igt unhappy, but they are able to do that today with > > > the modparam. This patch makes it easier to move that to an engine > > > parameter, but to disable it entirely you still need to be able to reset > > > the GPU on demand (suspend, eviction, oom). Without hangcheck we need > to > > > evaluate all MAX_SCHEDULE_TIMEOUT waits and supply a reset-on- > timeout > > > along critical paths. > > > -Chris > > > > I don't think I'm confusing hang-check with the recovery. I've talked about > TDR, which to me is a periodic hangcheck, combined with a recovery by engine > reset. I don't argue against being able to reset, just against the blunt > classification that hangcheck itself provides. > > > > TDR was originally looking for regressive workloads that were not making > forward progress to protect against DoS. But it was always a very blunt tool. > It's > never been able to differentiate long running, but otherwise valid, compute > workloads from genuine BB hangs, but that was fine at the time, and as you say > users could always switch the modparam. > > To be honest, I still have no idea what TDR is. But I take it that you > agree that we're only talking about hangcheck :) What I think you are > missing out on is that we have some more or less essential (itself > depending on client behaviour) housekeeping that goes along side it. > > My claim is that without a guarantee of isolation, anything else that > wants to use that engine will need the background housekeeping. (And if > we don't go as far as performing complete isolation, I expect userspace > is going to need the kernel to cleanup as they go along, as they are > unlikely to be prepared to do the system maintenance themselves.) > > > Now we have more emphasis on compute we need a solution that doesn't > involve a modparam. This was specifically requested by the compute team - > they know that they can flip the tdr switch, but that means their workload > will > only run if user modifies the system. That's hardly ideal. > > It means they can adjust things to their admins' hearts' content, and > it's a udev rule away from setting permissions to allow the compute group > to freely reconfigure the settings. > > > Without the rlimit concept I don't think we can't prevent power hogs > whatever we do, any more than the core kernel can prevent CPU power hogs. > So, if we can prevent a workload from blocking other contexts, then it is > unhelpful to continue either with the blunt tool that TDR is, or the similarly > blunt heartbeat. If we have neither of these, but can guarantee forward > progress when we need to, then we can still protect the system against DoS, > without condemning any contexts before a crime has been committed. > > rlimits is orthogonal to the problem of preventing an isolated compute > task from turning into a system-wide dos. For endless, we need > suspend-to-idle at a very minimum before even considering the dilemma of > hangcheck. For eviction/oom, suspend-to-idle is not enough, and we need > to have the same sort
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: ignore generated files for header test
== Series Details == Series: drm/i915: ignore generated files for header test URL : https://patchwork.freedesktop.org/series/64339/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5b8f13a2b32f drm/i915: ignore generated files for header test -:11: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #11: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/1] drm/vblank: drop use of DRM_WAIT_ON()
== Series Details == Series: series starting with [v3,1/1] drm/vblank: drop use of DRM_WAIT_ON() URL : https://patchwork.freedesktop.org/series/64337/ State : success == Summary == CI Bug Log - changes from CI_DRM_6565 -> Patchwork_13776 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/ Known issues Here are the changes found in Patchwork_13776 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-icl-u3/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-icl-u3/igt@debugfs_test@read_all_entries.html * igt@gem_ctx_create@basic: - fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-apl-guc/igt@gem_ctx_cre...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-apl-guc/igt@gem_ctx_cre...@basic.html * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-7500u: [PASS][7] -> [SKIP][8] ([fdo#109271]) +23 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_selftest@live_hangcheck: - fi-kbl-guc: [INCOMPLETE][11] ([fdo#108744]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html * igt@kms_addfb_basic@bo-too-small-due-to-tiling: - fi-icl-dsi: [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-icl-dsi/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-icl-dsi/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: [SKIP][15] ([fdo#109271] / [fdo#109278]) -> [PASS][16] +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][17] ([fdo#109485]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@vgem_basic@debugfs: - fi-icl-u3: [DMESG-WARN][19] ([fdo#107724]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6565/fi-icl-u3/igt@vgem_ba...@debugfs.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13776/fi-icl-u3/igt@vgem_ba...@debugfs.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#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 Participating hosts (54 -> 46) -- Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6565 -> Patchwork_13776 CI-20190529: 20190529 CI_DRM_6565: 5559389e889c125a9aa0982e4ef79bb4c1853438 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5113:
Re: [Intel-gfx] [PATCH] drm/i915: ignore generated files for header test
On Fri, Jul 26, 2019 at 10:34:50PM +0100, Chris Wilson wrote: Quoting Lucas De Marchi (2019-07-26 22:23:44) These are generated source that can be ignored by git. They're the stale generated headers from our old mechanism, right? No. They are still in the Makefiles: $ git grep -l header_test drivers/gpu/drm/i915/.gitignore drivers/gpu/drm/i915/display/Makefile.header-test drivers/gpu/drm/i915/gem/Makefile.header-test drivers/gpu/drm/i915/gt/Makefile.header-test drivers/gpu/drm/i915/gt/uc/Makefile.header-test From that commit it seems we should rather remove those sections from these makefiles. Lucas De Marchi See commit e846f0dc57f441e5e93194d39bc9b8ac2ab5e0a4 Author: Jani Nikula Date: Tue Jun 4 15:42:48 2019 +0300 kbuild: add support for ensuring headers are self-contained for when this ignore was dropped. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: ignore generated files for header test
Quoting Lucas De Marchi (2019-07-26 22:23:44) > These are generated source that can be ignored by git. They're the stale generated headers from our old mechanism, right? See commit e846f0dc57f441e5e93194d39bc9b8ac2ab5e0a4 Author: Jani Nikula Date: Tue Jun 4 15:42:48 2019 +0300 kbuild: add support for ensuring headers are self-contained for when this ignore was dropped. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace hangcheck by heartbeats
Quoting Bloomfield, Jon (2019-07-26 21:58:38) > > From: Chris Wilson > > It's no more often than before, you have to fail to advance within an > > interval, and then deny preemption request. > > It's entrapment. You are creating an artificial workload for the context to > impede. Before that artificial workload was injected, the context would have > run to completion, the world would be at peace (and the user would have her > new bitcoin). Instead she stays poor because the DoS police launched an > illegal sting on her otherwise genius operation. It's housekeeping; it's the cost of keeping the engine alive. This argument is why CPU-isolation came about (aiui). > > > I do like the rlimit suggestion, but until we have that, just disabling > > > TDR feels > > like a better stop-gap than nuking innocent compute contexts just in case > > they > > might block something. > > > > They're not innocent though :-p > > They are innocent until proven guilty :-) > > > > > Disabling hangcheck (no idea why you confuse that with the recovery > > procedure) makes igt unhappy, but they are able to do that today with > > the modparam. This patch makes it easier to move that to an engine > > parameter, but to disable it entirely you still need to be able to reset > > the GPU on demand (suspend, eviction, oom). Without hangcheck we need to > > evaluate all MAX_SCHEDULE_TIMEOUT waits and supply a reset-on-timeout > > along critical paths. > > -Chris > > I don't think I'm confusing hang-check with the recovery. I've talked about > TDR, which to me is a periodic hangcheck, combined with a recovery by engine > reset. I don't argue against being able to reset, just against the blunt > classification that hangcheck itself provides. > > TDR was originally looking for regressive workloads that were not making > forward progress to protect against DoS. But it was always a very blunt tool. > It's never been able to differentiate long running, but otherwise valid, > compute workloads from genuine BB hangs, but that was fine at the time, and > as you say users could always switch the modparam. To be honest, I still have no idea what TDR is. But I take it that you agree that we're only talking about hangcheck :) What I think you are missing out on is that we have some more or less essential (itself depending on client behaviour) housekeeping that goes along side it. My claim is that without a guarantee of isolation, anything else that wants to use that engine will need the background housekeeping. (And if we don't go as far as performing complete isolation, I expect userspace is going to need the kernel to cleanup as they go along, as they are unlikely to be prepared to do the system maintenance themselves.) > Now we have more emphasis on compute we need a solution that doesn't involve > a modparam. This was specifically requested by the compute team - they know > that they can flip the tdr switch, but that means their workload will only > run if user modifies the system. That's hardly ideal. It means they can adjust things to their admins' hearts' content, and it's a udev rule away from setting permissions to allow the compute group to freely reconfigure the settings. > Without the rlimit concept I don't think we can't prevent power hogs whatever > we do, any more than the core kernel can prevent CPU power hogs. So, if we > can prevent a workload from blocking other contexts, then it is unhelpful to > continue either with the blunt tool that TDR is, or the similarly blunt > heartbeat. If we have neither of these, but can guarantee forward progress > when we need to, then we can still protect the system against DoS, without > condemning any contexts before a crime has been committed. rlimits is orthogonal to the problem of preventing an isolated compute task from turning into a system-wide dos. For endless, we need suspend-to-idle at a very minimum before even considering the dilemma of hangcheck. For eviction/oom, suspend-to-idle is not enough, and we need to have the same sort of concept as oomkiller; kill a task to save the system (or not depending on admin selection). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/1] drm/vblank: drop use of DRM_WAIT_ON()
== Series Details == Series: series starting with [v3,1/1] drm/vblank: drop use of DRM_WAIT_ON() URL : https://patchwork.freedesktop.org/series/64337/ State : warning == Summary == $ dim checkpatch origin/drm-tip c558d403f099 drm/vblank: drop use of DRM_WAIT_ON() -:47: WARNING:TYPO_SPELLING: 'implmentation' may be misspelled - perhaps 'implementation'? #47: - Dropped Reviewed-by from Sean Paul as this is a new implmentation -:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #87: FILE: drivers/gpu/drm/drm_vblank.c:1677: + wait = wait_event_interruptible_timeout(vblank->queue, + vblank_passed(drm_vblank_count(dev, pipe), req_seq) || total: 0 errors, 1 warnings, 1 checks, 39 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: ignore generated files for header test
These are generated source that can be ignored by git. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 drivers/gpu/drm/i915/.gitignore diff --git a/drivers/gpu/drm/i915/.gitignore b/drivers/gpu/drm/i915/.gitignore new file mode 100644 index ..a1691fc10c5c --- /dev/null +++ b/drivers/gpu/drm/i915/.gitignore @@ -0,0 +1 @@ +header_test_* -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/uc: Don't fail on HuC firmware failure
On Fri, 26 Jul 2019 20:57:12 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-07-26 18:12:40)
HuC is usually not a critical component, so we can safely ignore
firmware load or authentication failures unless HuC was explicitly
requested by the user.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 8
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6 ++
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 5b9b20d1cb6d..99419c5c0ad3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -472,7 +472,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
if (intel_uc_is_using_huc(uc)) {
ret = intel_huc_fw_upload(huc);
- if (ret)
+ if (ret && intel_uc_fw_is_overridden(>fw))
goto err_out;
}
@@ -494,9 +494,9 @@ int intel_uc_init_hw(struct intel_uc *uc)
if (ret)
goto err_log_capture;
- if (intel_uc_is_using_huc(uc)) {
+ if (intel_uc_is_using_huc(uc) &&
intel_uc_fw_is_loaded(>fw)) {
Can we even load the huc fw is !using_huc()?
as of today, meaning of "intel_uc_is_using_huc" is that HuC was
requested to run (ie. enabled via modparam) and not that is now
being used.
ret = intel_huc_auth(huc);
- if (ret)
+ if (ret && intel_uc_fw_is_overridden(>fw))
goto err_communication;
}
@@ -515,7 +515,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
dev_info(i915->drm.dev, "GuC submission %s\n",
enableddisabled(intel_uc_is_using_guc_submission(uc)));
dev_info(i915->drm.dev, "HuC %s\n",
-enableddisabled(intel_uc_is_using_huc(uc)));
+enableddisabled(intel_huc_is_authenticated(huc)));
Seems reasonable by itself.
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..1e9ae38e5b10 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -146,7 +146,8 @@ __uc_fw_override(struct intel_uc_fw *uc_fw)
break;
}
- return uc_fw->path;
+ uc_fw->user_overridden = uc_fw->path;
uc_fw->user_overridden = uc_fw->path && *uc_fw->path;
That is i915.huc_firmware="" should be a convenient way to disable
loading.
hmm, to be working as expected this should done init_early as:
if (uc_fw->path && *uc_fw->path)
uc_fw->status = INTEL_UC_FIRMWARE_SELECTED;
else
uc_fw->status = INTEL_UC_FIRMWARE_NOT_SUPPORTED;
If we agree on that "creative misuse" of the modparam, or if you can
reassure me that it works correctly anyway,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/1] drm/vblank: drop use of DRM_WAIT_ON()
DRM_WAIT_ON() is from the deprecated drm_os_linux header and
the modern replacement is the wait_event_*.
The return values differ, so a conversion is needed to
keep the original interface towards userspace.
Introduced a switch/case to make code obvious.
Analysis from Michel Dänzer:
The waiting condition rely on all relevant places where vblank_count
is modified calls wake_up(>queue).
drm_handle_vblank():
- Calls wake_up(>queue)
drm_vblank_enable():
- There is no need here because there can be no sleeping waiters
in the queue, because vblank->enabled == false immediately
terminates any waits.
drm_crtc_accurate_vblank_count():
- This is called from interrupt handlers, at least from
amdgpu_dm.c:dm_pflip_high_irq(). Not sure it needs to wake up
the queue though, the driver should call
drm_(crtc_)_handle_vblank anyway.
drm_vblank_disable_and_save():
- It can be called from an interrupt, via drm_handle_vblank ->
vblank_disable_fn. However, the only place where
drm_vblank_disable_and_save can be called with sleeping waiters
in the queue is in drm_crtc_vblank_off, which wakes up the queue
afterwards (which terminates all waits, because
vblank->enabled == false at this point).
v3:
- Added analysis to changelog from Michel Dänzer
- Moved return result handling inside if (req_seq != seq) (Daniel V)
- Reused more of the former logic - resulting in simpler code
- Dropped Reviewed-by from Sean Paul as this is a new implmentation
v2:
- Fix so the case where req_seq equals seq was handled properly
- quick hack to check if IGT became happy
- Only sent to igt, not to dri-devel
Signed-off-by: Sam Ravnborg
Cc: "Michel Dänzer"
Cc: Sean Paul
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
---
This patch survives my testing here.
vbltest spits out the same value as before, and I can see something on
the screen.
Added intel-gfx@lists.freedesktop.org, as IGT have identified troubles
with this in v1.
Sam
drivers/gpu/drm/drm_vblank.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 603ab105125d..fd1fbc77871f 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include "drm_internal.h"
@@ -1670,12 +1669,28 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
*data,
}
if (req_seq != seq) {
+ int wait;
+
DRM_DEBUG("waiting on vblank count %llu, crtc %u\n",
req_seq, pipe);
- DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
- vblank_passed(drm_vblank_count(dev, pipe),
- req_seq) ||
- !READ_ONCE(vblank->enabled));
+ wait = wait_event_interruptible_timeout(vblank->queue,
+ vblank_passed(drm_vblank_count(dev, pipe), req_seq) ||
+ !READ_ONCE(vblank->enabled),
+ msecs_to_jiffies(3000));
+
+ switch (wait) {
+ case 0:
+ /* timeout */
+ ret = -EBUSY;
+ break;
+ case -ERESTARTSYS:
+ /* interrupted by signal */
+ ret = -EINTR;
+ break;
+ default:
+ ret = 0;
+ break;
+ }
}
if (ret != -EINTR) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace hangcheck by heartbeats
> -Original Message- > From: Chris Wilson > Sent: Friday, July 26, 2019 1:11 PM > To: Bloomfield, Jon ; intel- > g...@lists.freedesktop.org > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > Quoting Bloomfield, Jon (2019-07-26 16:00:06) > > > -Original Message- > > > From: Chris Wilson > > > Sent: Thursday, July 25, 2019 4:52 PM > > > To: Bloomfield, Jon ; intel- > > > g...@lists.freedesktop.org > > > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > > > > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > Quoting Bloomfield, Jon (2019-07-26 00:41:49) > > > > > -Original Message- > > > > > From: Chris Wilson > > > > > Sent: Thursday, July 25, 2019 4:28 PM > > > > > To: Bloomfield, Jon ; intel- > > > > > g...@lists.freedesktop.org > > > > > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > > > > > > > > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > > > > > Quoting Bloomfield, Jon (2019-07-26 00:21:47) > > > > > > > -Original Message- > > > > > > > From: Chris Wilson > > > > > > > Sent: Thursday, July 25, 2019 4:17 PM > > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > > Cc: Chris Wilson ; Joonas Lahtinen > > > > > > > ; Ursulin, Tvrtko > > > > > ; > > > > > > > Bloomfield, Jon > > > > > > > Subject: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > > > > > > > > > Replace sampling the engine state every so often with a periodic > > > > > > > heartbeat request to measure the health of an engine. This is > coupled > > > > > > > with the forced-preemption to allow long running requests to > survive so > > > > > > > long as they do not block other users. > > > > > > > > > > > > Can you explain why we would need this at all if we have forced- > > > preemption? > > > > > > Forced preemption guarantees that an engine cannot interfere with > the > > > > > timely > > > > > > execution of other contexts. If it hangs, but nothing else wants to > > > > > > use > the > > > > > engine > > > > > > then do we care? > > > > > > > > > > We may not have something else waiting to use the engine, but we may > > > > > have users waiting for the response where we need to detect the GPU > hang > > > > > to prevent an infinite wait / stuck processes and infinite power > > > > > drain. > > > > > > > > I'm not sure I buy that logic. Being able to pre-empt doesn't imply it > > > > will > > > > ever end. As written a context can sit forever, apparently making > > > > progress > > > > but never actually returning a response to the user. If the user isn't > > > > happy > > > > with the progress they will kill the process. So we haven't solved the > > > > user responsiveness here. All we've done is eliminated the potential to > > > > run one class of otherwise valid workload. > > > > > > Indeed, one of the conditions I have in mind for endless is rlimits. The > > > user + admin should be able to specify that a context not exceed so much > > > runtime, and if we ever get a scheduler, we can write that as a budget > > > (along with deadlines). > > > > Agreed, an rlimit solution would work better, if there was an option for > 'unlimited'. > > > > The specific reason I poked was to try to find a solution to the > > long-running compute workload scenarios. In those cases there is no fwd > > progress on the ring/BB, but the kernel will still be making fwd progress. > > The > > challenge here is that it's not easy for compiler to guarantee to fold a > > user > > kernel into something that fit any specific time boundary. It depends on the > > user kernel structure. A thread could take several seconds (or possibly > > minutes) to complete. That's not automatically bad. > > > > We need a solution to that specific problem, and while I agree that it would > be nice to detect errant contexts and kick them out, that relies on an > accurate > classification of 'errant' and 'safe'. The response needs to be proportional > to > the problem. > > Unless I am missing something we have nothing less than an engine reset. > > The timers employed here are all per-engine, and could be exposed via > sysfs with the same granularity. > > However, I also think there is a large overlap between the scenarios you > describe and the ones used for CPU-isolation. > > > > > Same argument goes for power. Just because it yields when other > contexts > > > > want to run doesn't mean it won't consume lots of power indefinitely. I > can > > > > equally write a CPU program to burn lots of power, forever, and it won't > get > > > > nuked. > > > > > > I agree, and continue to dislike letting hogs have free reign. > > > > But even with this change a BB hog can still have free reign to consume > power, as long as it pauses it's unsavoury habit whenever the heartbeat > request > comes snooping on the engine. What we're effectively saying with this is that > it's ok for a context to spin in a BB, but not ok to
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Capture vma contents outside of spinlock (rev2)
== Series Details == Series: drm/i915: Capture vma contents outside of spinlock (rev2) URL : https://patchwork.freedesktop.org/series/64256/ State : success == Summary == CI Bug Log - changes from CI_DRM_6555_full -> Patchwork_13759_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13759_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_6555/shard-snb6/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-snb1/igt@gem_...@reset-stress.html * igt@gem_workarounds@suspend-resume-fd: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-apl7/igt@gem_workarou...@suspend-resume-fd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-apl3/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-snb4/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_legacy@cursor-vs-flip-legacy: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#103355]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103184] / [fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-skl8/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb8/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-iclb7/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103166]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb2/igt@kms_plane_low...@pipe-a-tiling-y.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-iclb8/igt@kms_psr@psr2_sprite_render.html Possible fixes * igt@gem_softpin@evict-active: - shard-skl: [INCOMPLETE][19] -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-skl3/igt@gem_soft...@evict-active.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-skl10/igt@gem_soft...@evict-active.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [SKIP][21] ([fdo#109271]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-kbl6/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13759/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-skl: [FAIL][25] ([fdo#100368]) -> [PASS][26] [25]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/uc: Remove redundant header_offset/size definitions
== Series Details == Series: series starting with [CI,1/3] drm/i915/uc: Remove redundant header_offset/size definitions URL : https://patchwork.freedesktop.org/series/64332/ State : success == Summary == CI Bug Log - changes from CI_DRM_6564 -> Patchwork_13775 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13775/ Known issues Here are the changes found in Patchwork_13775 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6564/fi-icl-u3/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13775/fi-icl-u3/igt@i915_module_l...@reload.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: [PASS][3] -> [FAIL][4] ([fdo#103167]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6564/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13775/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_exec_reloc@basic-gtt-cpu: - fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6564/fi-icl-u3/igt@gem_exec_re...@basic-gtt-cpu.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13775/fi-icl-u3/igt@gem_exec_re...@basic-gtt-cpu.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][7] ([fdo#103167]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6564/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13775/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 Participating hosts (53 -> 46) -- Additional (1): fi-cfl-8109u Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6564 -> Patchwork_13775 CI-20190529: 20190529 CI_DRM_6564: 26169fbe1a3c592f1be6792d642e3e084b7acc4f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13775: cc546a1629ec38f1392e190cb3eb0389e481208f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cc546a1629ec drm/i915/uc: Remove redundant RSA offset definition 921fa64e1245 drm/i915/uc: Remove redundant ucode offset definition f04d3af58b7f drm/i915/uc: Remove redundant header_offset/size definitions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13775/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/tgl: Define MOCS entries for Tigerlake
On 7/26/19 12:31 PM, Lucas De Marchi wrote:
On Fri, Jul 26, 2019 at 11:38:16AM -0700, Daniele Ceraolo Spurio wrote:
On 7/25/19 5:12 PM, Lucas De Marchi wrote:
From: Tomasz Lis
The MOCS table is published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Two of the 3 legacy entries used for gen9 are no longer expected to
work.
Although we are changing the gen11 table, those changes are supposed to
be backward compatible since we are only touching previously undefined
entries.
v2: Add the missing entries in 49-51 range and replace "HW reserved"
terminology to what it actually is: L1 is implicitly enabled
(from Daniele)
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Signed-off-by: Tomasz Lis
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 37 +---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 290a5e9b90b9..ca370c7487f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -62,6 +62,10 @@ struct drm_i915_mocs_table {
#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but
configured. */
/* (e)LLC caching options */
+/*
+ * Note: LE_0_PAGETABLE works only up to Gen11; for newer gens it means
+ * the same as LE_UC
+ */
#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
#define LE_1_UC _LE_CACHEABILITY(1)
#define LE_2_WT _LE_CACHEABILITY(2)
@@ -100,8 +104,9 @@ struct drm_i915_mocs_table {
* of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be initialized to PTE.
+ * userspace is concerned and shouldn't be relied upon. For Gen < 12
+ * they will be initialized to PTE. Gen >= 12 onwards don't have a
setting for
+ * PTE. We use the same value, but that actually means Uncached.
*
* The last two entries are reserved by the hardware. For ICL+ they
* should be initialized according to bspec and never used, for older
@@ -137,11 +142,13 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
};
#define GEN11_MOCS_ENTRIES \
- /* Base - Uncached (Deprecated) */ \
+ /* Gen11: Base - Uncached (Deprecated) */ \
+ /* Gen12+: Base - Error (Reserved for Non-Use) */ \
MOCS_ENTRY(I915_MOCS_UNCACHED, \
LE_1_UC | LE_TC_1_LLC, \
L3_1_UC), \
/* Base - L3 + LeCC:PAT (Deprecated) */ \
+ /* Gen12+: Base - Reserved */ \
MOCS_ENTRY(I915_MOCS_PTE, \
LE_0_PAGETABLE | LE_TC_1_LLC, \
L3_3_WB), \
I've double-checked the specs and noticed that they now say that MOCS
0 and 1 should be set to all zeros for Gen12 (possibly just to
highlight the fact that they're deprecated/reserved). These are not
supposes to be used so programming them to different values shouldn't
matter, but it might be worth sticking to the specs and add a separate
Gen12 table.
I noticed that too, but while implementing the IGT tests. These are 0,
but they are RO, it doesn't matter what we write on them.
I could add a comment here and change the IGT test to check they are in
fact 0 (rather than setting them as unused). Would this cover your
concern? I feel reluctant to add a big table like this per platform if
there's a wayto avoid it.
Yes, that works for me.
Daniele
I've confirmed all the other entries in the gen11 table are kept the
same in the TGL one, and the ones added below match the table as well.
@@ -233,6 +240,30 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
MOCS_ENTRY(23, \
LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_RSC(1) |
LE_SCC(7), \
L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + L3 + LLC */ \
+ MOCS_ENTRY(48, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + L3 */ \
+ MOCS_ENTRY(49, \
+ LE_1_UC | LE_TC_1_LLC, \
+ L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + LLC */ \
+ MOCS_ENTRY(50, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_1_UC), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 */ \
+ MOCS_ENTRY(51, \
+ LE_1_UC | LE_TC_1_LLC, \
+ L3_1_UC), \
+ /* Gen12+: HW Reserved - HW Special Case (CCS) */ \
Entries 60 and 61 are not reserved for HW usage but are special cases
that trigger implicit behaviors. I'd drop the "HW Reserved" tag and
leave just "HW Special Case"
ok
thanks
Lucas De Marchi
Daniele
+ MOCS_ENTRY(60, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_1_UC), \
+ /* Gen12+: HW Reserved - HW Special Case (Displayable) */ \
+ MOCS_ENTRY(61, \
+
Re: [Intel-gfx] [PATCH] drm/i915: Replace hangcheck by heartbeats
Quoting Bloomfield, Jon (2019-07-26 16:00:06) > > -Original Message- > > From: Chris Wilson > > Sent: Thursday, July 25, 2019 4:52 PM > > To: Bloomfield, Jon ; intel- > > g...@lists.freedesktop.org > > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > Quoting Bloomfield, Jon (2019-07-26 00:41:49) > > > > -Original Message- > > > > From: Chris Wilson > > > > Sent: Thursday, July 25, 2019 4:28 PM > > > > To: Bloomfield, Jon ; intel- > > > > g...@lists.freedesktop.org > > > > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > > > > > > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > > > Quoting Bloomfield, Jon (2019-07-26 00:21:47) > > > > > > -Original Message- > > > > > > From: Chris Wilson > > > > > > Sent: Thursday, July 25, 2019 4:17 PM > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > Cc: Chris Wilson ; Joonas Lahtinen > > > > > > ; Ursulin, Tvrtko > > > > ; > > > > > > Bloomfield, Jon > > > > > > Subject: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > > > > > > > Replace sampling the engine state every so often with a periodic > > > > > > heartbeat request to measure the health of an engine. This is > > > > > > coupled > > > > > > with the forced-preemption to allow long running requests to > > > > > > survive so > > > > > > long as they do not block other users. > > > > > > > > > > Can you explain why we would need this at all if we have forced- > > preemption? > > > > > Forced preemption guarantees that an engine cannot interfere with the > > > > timely > > > > > execution of other contexts. If it hangs, but nothing else wants to > > > > > use the > > > > engine > > > > > then do we care? > > > > > > > > We may not have something else waiting to use the engine, but we may > > > > have users waiting for the response where we need to detect the GPU hang > > > > to prevent an infinite wait / stuck processes and infinite power drain. > > > > > > I'm not sure I buy that logic. Being able to pre-empt doesn't imply it > > > will > > > ever end. As written a context can sit forever, apparently making progress > > > but never actually returning a response to the user. If the user isn't > > > happy > > > with the progress they will kill the process. So we haven't solved the > > > user responsiveness here. All we've done is eliminated the potential to > > > run one class of otherwise valid workload. > > > > Indeed, one of the conditions I have in mind for endless is rlimits. The > > user + admin should be able to specify that a context not exceed so much > > runtime, and if we ever get a scheduler, we can write that as a budget > > (along with deadlines). > > Agreed, an rlimit solution would work better, if there was an option for > 'unlimited'. > > The specific reason I poked was to try to find a solution to the > long-running compute workload scenarios. In those cases there is no fwd > progress on the ring/BB, but the kernel will still be making fwd progress. The > challenge here is that it's not easy for compiler to guarantee to fold a user > kernel into something that fit any specific time boundary. It depends on the > user kernel structure. A thread could take several seconds (or possibly > minutes) to complete. That's not automatically bad. > > We need a solution to that specific problem, and while I agree that it would > be nice to detect errant contexts and kick them out, that relies on an > accurate classification of 'errant' and 'safe'. The response needs to be > proportional to the problem. Unless I am missing something we have nothing less than an engine reset. The timers employed here are all per-engine, and could be exposed via sysfs with the same granularity. However, I also think there is a large overlap between the scenarios you describe and the ones used for CPU-isolation. > > > Same argument goes for power. Just because it yields when other contexts > > > want to run doesn't mean it won't consume lots of power indefinitely. I > > > can > > > equally write a CPU program to burn lots of power, forever, and it won't > > > get > > > nuked. > > > > I agree, and continue to dislike letting hogs have free reign. > > But even with this change a BB hog can still have free reign to consume > power, as long as it pauses it's unsavoury habit whenever the heartbeat > request comes snooping on the engine. What we're effectively saying with this > is that it's ok for a context to spin in a BB, but not ok to spin in an EU > kernel. Why would we differentiate when both can burn the same power? So we > haven't solved this problem, but continue to victimize legitimate code. Yes, that is exactly the point of this change. Along with it also providing the heartbeat for housekeeping purposes. > > > TDR made sense when it was the only way to ensure contexts could always > > > make forward progress. But force-preemption does everything we need to
Re: [Intel-gfx] [PATCH v6 22/24] drm/amdgpu: Provide ddc symlink in connector sysfs directory
On Fri, Jul 26, 2019 at 3:42 PM Andrzej Pietrasiewicz wrote: > > Hi Alex, > > > W dniu 26.07.2019 o 21:28, Alex Deucher pisze: > > On Fri, Jul 26, 2019 at 1:28 PM Andrzej Pietrasiewicz > > wrote: > >> > >> Use the ddc pointer provided by the generic connector. > >> > >> Signed-off-by: Andrzej Pietrasiewicz > > > > Note that this only covers the legacy display code. The new DC > > display code also needs to be converted. See: > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > > In amdgpu_dm_connector_init() the ddc is >base, is it? Yes. > > But it is not clear to me how can I find ddc pointer in > dm_dp_add_mst_connector()? + Harry and Nick. hmmm, not sure about MST. Maybe just skip them for now. Alex > > Andrzej > ___ 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 [CI,1/3] drm/i915/uc: Remove redundant header_offset/size definitions
== Series Details == Series: series starting with [CI,1/3] drm/i915/uc: Remove redundant header_offset/size definitions URL : https://patchwork.freedesktop.org/series/64332/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/uc: Remove redundant header_offset/size definitions Okay! Commit: drm/i915/uc: Remove redundant ucode offset definition Okay! Commit: drm/i915/uc: Remove redundant RSA offset definition -O:drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:514:20: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:514:20: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:513:20: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:513:20: 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.BAT: failure for series starting with [1/2] drm/i915/gt: Add to timeline requires the timeline mutex (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Add to timeline requires the
timeline mutex (rev2)
URL : https://patchwork.freedesktop.org/series/64227/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6564 -> Patchwork_13774
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_13774 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13774, 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_13774/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13774:
### IGT changes ###
Possible regressions
* {igt@i915_selftest@live_gt_contexts} (NEW):
- fi-hsw-4770r: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-hsw-4770r/igt@i915_selftest@live_gt_contexts.html
- fi-blb-e6850: NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-blb-e6850/igt@i915_selftest@live_gt_contexts.html
- fi-bwr-2160:NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-bwr-2160/igt@i915_selftest@live_gt_contexts.html
- fi-hsw-peppy: NOTRUN -> [INCOMPLETE][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-hsw-peppy/igt@i915_selftest@live_gt_contexts.html
- fi-snb-2520m: NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-snb-2520m/igt@i915_selftest@live_gt_contexts.html
- fi-ilk-650: NOTRUN -> [INCOMPLETE][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-ilk-650/igt@i915_selftest@live_gt_contexts.html
- fi-ivb-3770:NOTRUN -> [INCOMPLETE][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-ivb-3770/igt@i915_selftest@live_gt_contexts.html
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-hsw-4770/igt@i915_selftest@live_gt_contexts.html
* igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-ilk-650/igt@run...@aborted.html
- fi-pnv-d510:NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-pnv-d510/igt@run...@aborted.html
- fi-hsw-peppy: NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-hsw-peppy/igt@run...@aborted.html
- fi-gdg-551: NOTRUN -> [FAIL][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-gdg-551/igt@run...@aborted.html
- fi-snb-2520m: NOTRUN -> [FAIL][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-snb-2520m/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][14]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-hsw-4770/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][15]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-ivb-3770/igt@run...@aborted.html
- fi-byt-j1900: NOTRUN -> [FAIL][16]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-byt-j1900/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][17]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-blb-e6850/igt@run...@aborted.html
- fi-hsw-4770r: NOTRUN -> [FAIL][18]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-hsw-4770r/igt@run...@aborted.html
- fi-byt-n2820: NOTRUN -> [FAIL][19]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-byt-n2820/igt@run...@aborted.html
- fi-snb-2600:NOTRUN -> [FAIL][20]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-snb-2600/igt@run...@aborted.html
- fi-elk-e7500: NOTRUN -> [FAIL][21]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13774/fi-elk-e7500/igt@run...@aborted.html
New tests
-
New tests have been introduced between CI_DRM_6564 and Patchwork_13774:
### New IGT tests (2) ###
* igt@i915_selftest@live_gem_contexts:
- Statuses : 29 pass(s)
- Exec time: [21.71, 28.22] s
* igt@i915_selftest@live_gt_contexts:
- Statuses : 14 incomplete(s) 29 pass(s)
- Exec time: [0.0, 1.11] s
Known issues
Here are the changes found in Patchwork_13774 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [PASS][22] -> [INCOMPLETE][23] ([fdo#110566])
[22]:
Re: [Intel-gfx] [PATCH v6 22/24] drm/amdgpu: Provide ddc symlink in connector sysfs directory
Hi Alex, W dniu 26.07.2019 o 21:28, Alex Deucher pisze: On Fri, Jul 26, 2019 at 1:28 PM Andrzej Pietrasiewicz wrote: Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Note that this only covers the legacy display code. The new DC display code also needs to be converted. See: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c In amdgpu_dm_connector_init() the ddc is >base, is it? But it is not clear to me how can I find ddc pointer in dm_dp_add_mst_connector()? Andrzej ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/gt: Add to timeline requires the timeline mutex (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/gt: Add to timeline requires the timeline mutex (rev2) URL : https://patchwork.freedesktop.org/series/64227/ State : warning == Summary == $ dim checkpatch origin/drm-tip ff62d595c38e drm/i915: Allow sharing the idle-barrier from other kernel requests -:123: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #123: new file mode 100644 -:128: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #128: FILE: drivers/gpu/drm/i915/gt/selftest_context.c:1: +/* -:129: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #129: FILE: drivers/gpu/drm/i915/gt/selftest_context.c:2: + * SPDX-License-Identifier: GPL-2.0 -:607: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #607: FILE: drivers/gpu/drm/i915/i915_active.c:484: + + } total: 0 errors, 3 warnings, 1 checks, 735 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/tgl: Define MOCS entries for Tigerlake
On Fri, Jul 26, 2019 at 11:38:16AM -0700, Daniele Ceraolo Spurio wrote:
On 7/25/19 5:12 PM, Lucas De Marchi wrote:
From: Tomasz Lis
The MOCS table is published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Two of the 3 legacy entries used for gen9 are no longer expected to work.
Although we are changing the gen11 table, those changes are supposed to
be backward compatible since we are only touching previously undefined
entries.
v2: Add the missing entries in 49-51 range and replace "HW reserved"
terminology to what it actually is: L1 is implicitly enabled (from Daniele)
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Signed-off-by: Tomasz Lis
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 37 +---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 290a5e9b90b9..ca370c7487f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -62,6 +62,10 @@ struct drm_i915_mocs_table {
#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
/* (e)LLC caching options */
+/*
+ * Note: LE_0_PAGETABLE works only up to Gen11; for newer gens it means
+ * the same as LE_UC
+ */
#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
#define LE_1_UC_LE_CACHEABILITY(1)
#define LE_2_WT_LE_CACHEABILITY(2)
@@ -100,8 +104,9 @@ struct drm_i915_mocs_table {
* of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be initialized to PTE.
+ * userspace is concerned and shouldn't be relied upon. For Gen < 12
+ * they will be initialized to PTE. Gen >= 12 onwards don't have a setting for
+ * PTE. We use the same value, but that actually means Uncached.
*
* The last two entries are reserved by the hardware. For ICL+ they
* should be initialized according to bspec and never used, for older
@@ -137,11 +142,13 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
};
#define GEN11_MOCS_ENTRIES \
- /* Base - Uncached (Deprecated) */ \
+ /* Gen11: Base - Uncached (Deprecated) */ \
+ /* Gen12+: Base - Error (Reserved for Non-Use) */ \
MOCS_ENTRY(I915_MOCS_UNCACHED, \
LE_1_UC | LE_TC_1_LLC, \
L3_1_UC), \
/* Base - L3 + LeCC:PAT (Deprecated) */ \
+ /* Gen12+: Base - Reserved */ \
MOCS_ENTRY(I915_MOCS_PTE, \
LE_0_PAGETABLE | LE_TC_1_LLC, \
L3_3_WB), \
I've double-checked the specs and noticed that they now say that MOCS
0 and 1 should be set to all zeros for Gen12 (possibly just to
highlight the fact that they're deprecated/reserved). These are not
supposes to be used so programming them to different values shouldn't
matter, but it might be worth sticking to the specs and add a separate
Gen12 table.
I noticed that too, but while implementing the IGT tests. These are 0,
but they are RO, it doesn't matter what we write on them.
I could add a comment here and change the IGT test to check they are in
fact 0 (rather than setting them as unused). Would this cover your
concern? I feel reluctant to add a big table like this per platform if
there's a wayto avoid it.
I've confirmed all the other entries in the gen11 table are kept the
same in the TGL one, and the ones added below match the table as well.
@@ -233,6 +240,30 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
MOCS_ENTRY(23, \
LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_RSC(1) | LE_SCC(7), \
L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + L3 + LLC */ \
+ MOCS_ENTRY(48, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + L3 */ \
+ MOCS_ENTRY(49, \
+ LE_1_UC | LE_TC_1_LLC, \
+ L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + LLC */ \
+ MOCS_ENTRY(50, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_1_UC), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 */ \
+ MOCS_ENTRY(51, \
+ LE_1_UC | LE_TC_1_LLC, \
+ L3_1_UC), \
+ /* Gen12+: HW Reserved - HW Special Case (CCS) */ \
Entries 60 and 61 are not reserved for HW usage but are special cases
that trigger implicit behaviors. I'd drop the "HW Reserved" tag and
leave just "HW Special Case"
ok
thanks
Lucas De Marchi
Daniele
+ MOCS_ENTRY(60, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_1_UC), \
+
Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
Quoting Thomas Gleixner (2019-07-26 20:18:32)
> On Fri, 26 Jul 2019, Chris Wilson wrote:
> > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > >
> > > > Objtool reports:
> > > >
> > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > > > .altinstr_replacement+0x36: redundant UACCESS disable
> > > >
> > > > __copy_from_user() already does both STAC and CLAC, so the
> > > > user_access_end() in its error path adds an extra unnecessary CLAC.
> > > >
> > > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault
> > > > exception case")
> > > > Reported-by: Thomas Gleixner
> > > > Reported-by: Sedat Dilek
> > > > Acked-by: Peter Zijlstra (Intel)
> > > > Tested-by: Nick Desaulniers
> > > > Tested-by: Sedat Dilek
> > > > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > > > Signed-off-by: Josh Poimboeuf
> > >
> > > Reviewed-by: Thomas Gleixner
> >
> > Which tree do you plan to apply it to? I can put in drm-intel, and with
> > the fixes tag it will percolate through to 5.3 and beyond, but if you
> > want to apply it directly to squash the build warnings, feel free.
>
> It would be nice to get it into 5.3. I can route it linuxwards if you give
> an Acked-by, but I'm happy to hand it to you :)
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 22/24] drm/amdgpu: Provide ddc symlink in connector sysfs directory
On Fri, Jul 26, 2019 at 1:28 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Note that this only covers the legacy display code. The new DC
display code also needs to be converted. See:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
With those updated as well:
Acked-by: Alex Deucher
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 96 ++-
> 1 file changed, 70 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 73b2ede773d3..ece55c8fa673 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -1505,6 +1505,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> struct amdgpu_connector_atom_dig *amdgpu_dig_connector;
> struct drm_encoder *encoder;
> struct amdgpu_encoder *amdgpu_encoder;
> + struct i2c_adapter *ddc = NULL;
> uint32_t subpixel_order = SubPixelNone;
> bool shared_ddc = false;
> bool is_dp_bridge = false;
> @@ -1574,17 +1575,21 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> amdgpu_connector->con_priv = amdgpu_dig_connector;
> if (i2c_bus->valid) {
> amdgpu_connector->ddc_bus = amdgpu_i2c_lookup(adev,
> i2c_bus);
> - if (amdgpu_connector->ddc_bus)
> + if (amdgpu_connector->ddc_bus) {
> has_aux = true;
> - else
> + ddc = _connector->ddc_bus->adapter;
> + } else {
> DRM_ERROR("DP: Failed to assign ddc bus!
> Check dmesg for i2c errors.\n");
> + }
> }
> switch (connector_type) {
> case DRM_MODE_CONNECTOR_VGA:
> case DRM_MODE_CONNECTOR_DVIA:
> default:
> - drm_connector_init(dev, _connector->base,
> - _connector_dp_funcs,
> connector_type);
> + drm_connector_init_with_ddc(dev,
> _connector->base,
> +
> _connector_dp_funcs,
> + connector_type,
> + ddc);
> drm_connector_helper_add(_connector->base,
>
> _connector_dp_helper_funcs);
> connector->interlace_allowed = true;
> @@ -1602,8 +1607,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> case DRM_MODE_CONNECTOR_HDMIA:
> case DRM_MODE_CONNECTOR_HDMIB:
> case DRM_MODE_CONNECTOR_DisplayPort:
> - drm_connector_init(dev, _connector->base,
> - _connector_dp_funcs,
> connector_type);
> + drm_connector_init_with_ddc(dev,
> _connector->base,
> +
> _connector_dp_funcs,
> + connector_type,
> + ddc);
> drm_connector_helper_add(_connector->base,
>
> _connector_dp_helper_funcs);
>
> drm_object_attach_property(_connector->base.base,
> @@ -1644,8 +1651,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> break;
> case DRM_MODE_CONNECTOR_LVDS:
> case DRM_MODE_CONNECTOR_eDP:
> - drm_connector_init(dev, _connector->base,
> - _connector_edp_funcs,
> connector_type);
> + drm_connector_init_with_ddc(dev,
> _connector->base,
> +
> _connector_edp_funcs,
> + connector_type,
> + ddc);
> drm_connector_helper_add(_connector->base,
>
> _connector_dp_helper_funcs);
>
> drm_object_attach_property(_connector->base.base,
> @@ -1659,13 +1668,18 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> } else {
> switch (connector_type) {
> case DRM_MODE_CONNECTOR_VGA:
> - drm_connector_init(dev, _connector->base,
> _connector_vga_funcs, connector_type);
> - drm_connector_helper_add(_connector->base,
> _connector_vga_helper_funcs);
> if
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uc: Reorder params in intel_uc_fw_fetch
== Series Details == Series: drm/i915/uc: Reorder params in intel_uc_fw_fetch URL : https://patchwork.freedesktop.org/series/64265/ State : success == Summary == CI Bug Log - changes from CI_DRM_6555_full -> Patchwork_13758_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13758_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-apl3/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_isolation@vcs1-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-kbl2/igt@gem_ctx_isolat...@vcs1-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-kbl4/igt@gem_ctx_isolat...@vcs1-s3.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-snb4/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_pm_rpm@gem-mmap-gtt: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108840]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb2/igt@i915_pm_...@gem-mmap-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-iclb7/igt@i915_pm_...@gem-mmap-gtt.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-skl4/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-skl2/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#109507]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb1/igt@kms_f...@flip-vs-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-iclb3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-pwrite.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-iclb3/igt@kms_psr@psr2_sprite_render.html * igt@perf@blocking: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#110728]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-skl10/igt@p...@blocking.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-skl2/igt@p...@blocking.html Possible fixes * igt@gem_softpin@evict-active: - shard-skl: [INCOMPLETE][19] -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-skl3/igt@gem_soft...@evict-active.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-skl10/igt@gem_soft...@evict-active.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [SKIP][21] ([fdo#109271]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13758/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled: - shard-skl: [FAIL][25] ([fdo#103184] / [fdo#103232]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6555/shard-skl9/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html [26]:
Re: [Intel-gfx] [PATCH v6 23/24] drm/radeon: Provide ddc symlink in connector sysfs directory
On Fri, Jul 26, 2019 at 1:29 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 142 +++--
> 1 file changed, 106 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index c60d1a44d22a..b3ad8d890801 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -1870,6 +1870,7 @@ radeon_add_atom_connector(struct drm_device *dev,
> struct radeon_connector_atom_dig *radeon_dig_connector;
> struct drm_encoder *encoder;
> struct radeon_encoder *radeon_encoder;
> + struct i2c_adapter *ddc;
> uint32_t subpixel_order = SubPixelNone;
> bool shared_ddc = false;
> bool is_dp_bridge = false;
> @@ -1947,17 +1948,21 @@ radeon_add_atom_connector(struct drm_device *dev,
> radeon_connector->con_priv = radeon_dig_connector;
> if (i2c_bus->valid) {
> radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
> i2c_bus);
> - if (radeon_connector->ddc_bus)
> + if (radeon_connector->ddc_bus) {
> has_aux = true;
> - else
> + ddc = _connector->ddc_bus->adapter;
> + } else {
> DRM_ERROR("DP: Failed to assign ddc bus!
> Check dmesg for i2c errors.\n");
> + }
> }
> switch (connector_type) {
> case DRM_MODE_CONNECTOR_VGA:
> case DRM_MODE_CONNECTOR_DVIA:
> default:
> - drm_connector_init(dev, _connector->base,
> - _dp_connector_funcs,
> connector_type);
> + drm_connector_init_with_ddc(dev,
> _connector->base,
> +
> _dp_connector_funcs,
> + connector_type,
> + ddc);
> drm_connector_helper_add(_connector->base,
>
> _dp_connector_helper_funcs);
> connector->interlace_allowed = true;
> @@ -1979,8 +1984,10 @@ radeon_add_atom_connector(struct drm_device *dev,
> case DRM_MODE_CONNECTOR_HDMIA:
> case DRM_MODE_CONNECTOR_HDMIB:
> case DRM_MODE_CONNECTOR_DisplayPort:
> - drm_connector_init(dev, _connector->base,
> - _dp_connector_funcs,
> connector_type);
> + drm_connector_init_with_ddc(dev,
> _connector->base,
> +
> _dp_connector_funcs,
> + connector_type,
> + ddc);
> drm_connector_helper_add(_connector->base,
>
> _dp_connector_helper_funcs);
>
> drm_object_attach_property(_connector->base.base,
> @@ -2027,8 +2034,10 @@ radeon_add_atom_connector(struct drm_device *dev,
> break;
> case DRM_MODE_CONNECTOR_LVDS:
> case DRM_MODE_CONNECTOR_eDP:
> - drm_connector_init(dev, _connector->base,
> -
> _lvds_bridge_connector_funcs, connector_type);
> + drm_connector_init_with_ddc(dev,
> _connector->base,
> +
> _lvds_bridge_connector_funcs,
> + connector_type,
> + ddc);
> drm_connector_helper_add(_connector->base,
>
> _dp_connector_helper_funcs);
>
> drm_object_attach_property(_connector->base.base,
> @@ -2042,13 +2051,18 @@ radeon_add_atom_connector(struct drm_device *dev,
> } else {
> switch (connector_type) {
> case DRM_MODE_CONNECTOR_VGA:
> - drm_connector_init(dev, _connector->base,
> _vga_connector_funcs, connector_type);
> - drm_connector_helper_add(_connector->base,
> _vga_connector_helper_funcs);
> if (i2c_bus->valid) {
> radeon_connector->ddc_bus =
> radeon_i2c_lookup(rdev, i2c_bus);
> if (!radeon_connector->ddc_bus)
> DRM_ERROR("VGA: Failed to
Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
On Fri, 26 Jul 2019, Chris Wilson wrote:
> Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> >
> > > Objtool reports:
> > >
> > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > > .altinstr_replacement+0x36: redundant UACCESS disable
> > >
> > > __copy_from_user() already does both STAC and CLAC, so the
> > > user_access_end() in its error path adds an extra unnecessary CLAC.
> > >
> > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault
> > > exception case")
> > > Reported-by: Thomas Gleixner
> > > Reported-by: Sedat Dilek
> > > Acked-by: Peter Zijlstra (Intel)
> > > Tested-by: Nick Desaulniers
> > > Tested-by: Sedat Dilek
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > > Signed-off-by: Josh Poimboeuf
> >
> > Reviewed-by: Thomas Gleixner
>
> Which tree do you plan to apply it to? I can put in drm-intel, and with
> the fixes tag it will percolate through to 5.3 and beyond, but if you
> want to apply it directly to squash the build warnings, feel free.
It would be nice to get it into 5.3. I can route it linuxwards if you give
an Acked-by, but I'm happy to hand it to you :)
Thanks,
tglx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
Quoting Thomas Gleixner (2019-07-25 22:55:45)
> On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
>
> > Objtool reports:
> >
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > .altinstr_replacement+0x36: redundant UACCESS disable
> >
> > __copy_from_user() already does both STAC and CLAC, so the
> > user_access_end() in its error path adds an extra unnecessary CLAC.
> >
> > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault
> > exception case")
> > Reported-by: Thomas Gleixner
> > Reported-by: Sedat Dilek
> > Acked-by: Peter Zijlstra (Intel)
> > Tested-by: Nick Desaulniers
> > Tested-by: Sedat Dilek
> > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > Signed-off-by: Josh Poimboeuf
>
> Reviewed-by: Thomas Gleixner
Which tree do you plan to apply it to? I can put in drm-intel, and with
the fixes tag it will percolate through to 5.3 and beyond, but if you
want to apply it directly to squash the build warnings, feel free.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/tgl: allow the reg_read ioctl to read the RCS TIMESTAMP register
On Thu, Jul 25, 2019 at 05:24:11PM -0700, Lucas De Marchi wrote:
> From: Jordan Justen
>
> This enables the Mesa driver to advertise support for ARB_timer_query,
> and thus an OpenGL version higher than 3.2.
>
> Based on the ICL patch by Paulo Zanoni and CNL patch by Nanley Chery.
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Signed-off-by: Jordan Justen
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 475ab3d4d91d..2b839acfa0f6 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1776,7 +1776,7 @@ static const struct reg_whitelist {
> } reg_read_whitelist[] = { {
> .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
> .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
> - .gen_mask = INTEL_GEN_MASK(4, 11),
> + .gen_mask = INTEL_GEN_MASK(4, 12),
> .size = 8
> } };
>
> --
> 2.21.0
>
> ___
> 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] Review required [Was: Associate ddc adapters with connectors]
Hi all. Andrzej have done a good job following up on feedback and this series is now ready. We need ack on the patches touching the individual drivers before we can proceed. Please check your drivers and get back. Sam > Hi Andezej. > > On Fri, Jul 26, 2019 at 07:22:54PM +0200, Andrzej Pietrasiewicz wrote: > > It is difficult for a user to know which of the i2c adapters is for which > > drm connector. This series addresses this problem. > > > > The idea is to have a symbolic link in connector's sysfs directory, e.g.: > > > > ls -l /sys/class/drm/card0-HDMI-A-1/ddc > > lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \ > > -> ../../../../soc/1388.i2c/i2c-2 > > > > The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run > > ddcutil: > > > > ddcutil -b 2 getvcp 0x10 > > VCP code 0x10 (Brightness): current value =90, max value = 100 > > > > The first patch in the series adds struct i2c_adapter pointer to struct > > drm_connector. If the field is used by a particular driver, then an > > appropriate symbolic link is created by the generic code, which is also > > added > > by this patch. > > > > Patch 2 adds a new variant of drm_connector_init(), see the changelog > > below. > > > > Patches 3..24 are examples of how to convert a driver to this new scheme. > > > ... > > > > v5..v6: > > > > - improved subject line of patch 1 > > - added kernel-doc for drm_connector_init_with_ddc() > > - improved kernel-doc for the ddc field of struct drm_connector > > - added Reviewed-by in patches 17 and 18 > > - added Acked-by in patch 2 > > - made the ownership of ddc i2c_adapter explicit in all patches, > > this made the affected patches much simpler > > Looks good now. > Patch 1 and 2 are: > Reviewed-by: Sam Ravnborg > > The remaining patches are: > Acked-by: Sam Ravnborg > > Sam > ___ > 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
Re: [Intel-gfx] [PATCH] drm/i915/uc: Don't fail on HuC firmware failure
Quoting Michal Wajdeczko (2019-07-26 18:12:40)
> HuC is usually not a critical component, so we can safely ignore
> firmware load or authentication failures unless HuC was explicitly
> requested by the user.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc.c| 8
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 ++-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6 ++
> 3 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index 5b9b20d1cb6d..99419c5c0ad3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -472,7 +472,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
>
> if (intel_uc_is_using_huc(uc)) {
> ret = intel_huc_fw_upload(huc);
> - if (ret)
> + if (ret && intel_uc_fw_is_overridden(>fw))
> goto err_out;
> }
>
> @@ -494,9 +494,9 @@ int intel_uc_init_hw(struct intel_uc *uc)
> if (ret)
> goto err_log_capture;
>
> - if (intel_uc_is_using_huc(uc)) {
> + if (intel_uc_is_using_huc(uc) && intel_uc_fw_is_loaded(>fw)) {
Can we even load the huc fw is !using_huc()?
> ret = intel_huc_auth(huc);
> - if (ret)
> + if (ret && intel_uc_fw_is_overridden(>fw))
> goto err_communication;
> }
>
> @@ -515,7 +515,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
> dev_info(i915->drm.dev, "GuC submission %s\n",
> enableddisabled(intel_uc_is_using_guc_submission(uc)));
> dev_info(i915->drm.dev, "HuC %s\n",
> -enableddisabled(intel_uc_is_using_huc(uc)));
> +enableddisabled(intel_huc_is_authenticated(huc)));
Seems reasonable by itself.
>
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index 5fbdd17a864b..1e9ae38e5b10 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -146,7 +146,8 @@ __uc_fw_override(struct intel_uc_fw *uc_fw)
> break;
> }
>
> - return uc_fw->path;
> + uc_fw->user_overridden = uc_fw->path;
uc_fw->user_overridden = uc_fw->path && *uc_fw->path;
That is i915.huc_firmware="" should be a convenient way to disable
loading.
If we agree on that "creative misuse" of the modparam, or if you can
reassure me that it works correctly anyway,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Associate ddc adapters with connectors (rev3)
== Series Details ==
Series: Associate ddc adapters with connectors (rev3)
URL : https://patchwork.freedesktop.org/series/63558/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6562 -> Patchwork_13773
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/
Known issues
Here are the changes found in Patchwork_13773 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-blb-e6850/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_hangcheck:
- fi-kbl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#108744])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278])
+2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278])
+2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][9] -> [FAIL][10] ([fdo#109485])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][11] -> [DMESG-WARN][12] ([fdo#102614])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@prime_self_import@basic-with_two_bos:
- fi-icl-u3: [PASS][13] -> [DMESG-WARN][14] ([fdo#107724])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-icl-u3/igt@prime_self_import@basic-with_two_bos.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-icl-u3/igt@prime_self_import@basic-with_two_bos.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [PASS][15] -> [SKIP][16] ([fdo#109271]) +23 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-icl-u3: [INCOMPLETE][17] ([fdo#107713] / [fdo#108569]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][19] ([fdo#103167]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13773/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#106766]: https://bugs.freedesktop.org/show_bug.cgi?id=106766
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
Re: [Intel-gfx] [PATCH 3/4] drm/i915/tgl: Tigerlake only has global MOCS registers
On 7/25/19 5:12 PM, Lucas De Marchi wrote:
From: Michel Thierry
Until Icelake, each engine had its own set of 64 MOCS registers. In
order to simplify, Tigerlake moves to only 64 Global MOCS registers,
which are no longer part of the engine context. Since these registers
are now global, they also only need to be initialized once.
From Gen12 onwards, MOCS must specify the target cache (3:2) and LRU
management (5:4) fields and cannot be programmed to 'use the value from
Private PAT', because these fields are no longer part of the PPAT. Also
cacheability control (1:0) field has changed, 00 no longer means 'use
controls from page table', but uncacheable (UC).
v2: Move the changes to the fault registers to a separate commit - the old ones
overlap with the range used by the new global MOCS (requested by
Daniele)
Cc: Daniele Ceraolo Spurio
Cc: Tomasz Lis
Signed-off-by: Michel Thierry
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 47
drivers/gpu/drm/i915/gt/intel_mocs.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c| 6 ++-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
8 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index ca370c7487f9..9399c0ec08f1 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -377,6 +377,10 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
unsigned int index;
u32 unused_value;
+ /* Platforms with global MOCS do not need per-engine initialization. */
+ if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+ return;
+
/* Called under a blanket forcewake */
assert_forcewakes_active(uncore, FORCEWAKE_ALL);
@@ -401,6 +405,46 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
unused_value);
}
+/**
+ * intel_mocs_init_global() - program the global mocs registers
+ * gt: pointer to struct intel_gt
+ *
+ * This function initializes the MOCS global registers.
+ */
+void intel_mocs_init_global(struct intel_gt *gt)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ struct drm_i915_mocs_table table;
+ unsigned int index;
+
+ if (!HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+ return;
+
+ if (!get_mocs_settings(gt, ))
+ return;
+
+ if (GEM_DEBUG_WARN_ON(table.size > table.n_entries))
+ return;
+
+ for (index = 0; index < table.size; index++)
+ intel_uncore_write(uncore,
+ GEN12_GLOBAL_MOCS(index),
+ table.table[index].control_value);
+
+ /*
+* Ok, now set the unused entries to uncached. These entries
+* are officially undefined and no contract for the contents
+* and settings is given for these entries.
+*
+* Entry 0 in the table is uncached - so we are just writing
+* that value to all the used entries.
+*/
+ for (; index < table.n_entries; index++)
+ intel_uncore_write(uncore,
+ GEN12_GLOBAL_MOCS(index),
+ table.table[0].control_value) > +}
If we end up setting entry 0 to zero then the value here we should
probably use a different entry (or just say we're setting everything to
the invalid entry).
+
/**
* emit_mocs_control_table() - emit the mocs control table
* @rq: Request to set up the MOCS table for.
@@ -604,6 +648,9 @@ int intel_rcs_context_init_mocs(struct i915_request *rq)
struct drm_i915_mocs_table t;
int ret;
+ if (HAS_GLOBAL_MOCS_REGISTERS(rq->i915))
+ return 0;
+
if (get_mocs_settings(rq->engine->gt, )) {
/* Program the RCS control registers */
ret = emit_mocs_control_table(rq, );
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index 8b9813e6f9ac..aa3a2df07c82 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -56,6 +56,7 @@ struct intel_gt;
int intel_rcs_context_init_mocs(struct i915_request *rq);
void intel_mocs_init_l3cc_table(struct intel_gt *gt);
+void intel_mocs_init_global(struct intel_gt *gt);
void intel_mocs_init_engine(struct intel_engine_cs *engine);
#endif
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 59d4a1146039..a9509bdeb2fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2280,6 +2280,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
Re: [Intel-gfx] [PATCH 3/4] drm/i915/tgl: Tigerlake only has global MOCS registers
On 2019-07-26 02:12, Lucas De Marchi wrote:
From: Michel Thierry
Until Icelake, each engine had its own set of 64 MOCS registers. In
order to simplify, Tigerlake moves to only 64 Global MOCS registers,
which are no longer part of the engine context. Since these registers
are now global, they also only need to be initialized once.
From Gen12 onwards, MOCS must specify the target cache (3:2) and LRU
management (5:4) fields and cannot be programmed to 'use the value from
Private PAT', because these fields are no longer part of the PPAT. Also
cacheability control (1:0) field has changed, 00 no longer means 'use
controls from page table', but uncacheable (UC).
v2: Move the changes to the fault registers to a separate commit - the old ones
overlap with the range used by the new global MOCS (requested by
Daniele)
Cc: Daniele Ceraolo Spurio
Cc: Tomasz Lis
Signed-off-by: Michel Thierry
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 47
drivers/gpu/drm/i915/gt/intel_mocs.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c| 6 ++-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
8 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index ca370c7487f9..9399c0ec08f1 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -377,6 +377,10 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
unsigned int index;
u32 unused_value;
+ /* Platforms with global MOCS do not need per-engine initialization. */
+ if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+ return;
+
/* Called under a blanket forcewake */
assert_forcewakes_active(uncore, FORCEWAKE_ALL);
@@ -401,6 +405,46 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
unused_value);
}
+/**
+ * intel_mocs_init_global() - program the global mocs registers
+ * gt: pointer to struct intel_gt
+ *
+ * This function initializes the MOCS global registers.
+ */
+void intel_mocs_init_global(struct intel_gt *gt)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ struct drm_i915_mocs_table table;
+ unsigned int index;
+
+ if (!HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+ return;
+
+ if (!get_mocs_settings(gt, ))
+ return;
+
+ if (GEM_DEBUG_WARN_ON(table.size > table.n_entries))
+ return;
+
+ for (index = 0; index < table.size; index++)
+ intel_uncore_write(uncore,
+ GEN12_GLOBAL_MOCS(index),
+ table.table[index].control_value);
+
+ /*
+* Ok, now set the unused entries to uncached. These entries
+* are officially undefined and no contract for the contents
+* and settings is given for these entries.
+*
+* Entry 0 in the table is uncached - so we are just writing
+* that value to all the used entries.
+*/
+ for (; index < table.n_entries; index++)
+ intel_uncore_write(uncore,
+ GEN12_GLOBAL_MOCS(index),
+ table.table[0].control_value);
While get_mocs_settings() can return a table with less than 64 entries,
it will never be the case for platforms supporting global MOCS.
So this for() is actually a dead code.. but removing it could cause harm
in case this is forgotten and modifications are made, so I'd leave it as is.
R-b: Tomasz Lis
-Tomasz
+}
+
/**
* emit_mocs_control_table() - emit the mocs control table
* @rq: Request to set up the MOCS table for.
@@ -604,6 +648,9 @@ int intel_rcs_context_init_mocs(struct i915_request *rq)
struct drm_i915_mocs_table t;
int ret;
+ if (HAS_GLOBAL_MOCS_REGISTERS(rq->i915))
+ return 0;
+
if (get_mocs_settings(rq->engine->gt, )) {
/* Program the RCS control registers */
ret = emit_mocs_control_table(rq, );
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index 8b9813e6f9ac..aa3a2df07c82 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -56,6 +56,7 @@ struct intel_gt;
int intel_rcs_context_init_mocs(struct i915_request *rq);
void intel_mocs_init_l3cc_table(struct intel_gt *gt);
+void intel_mocs_init_global(struct intel_gt *gt);
void intel_mocs_init_engine(struct intel_engine_cs *engine);
#endif
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 59d4a1146039..a9509bdeb2fa
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Don't fail on HuC firmware failure
== Series Details ==
Series: drm/i915/uc: Don't fail on HuC firmware failure
URL : https://patchwork.freedesktop.org/series/64326/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6562 -> Patchwork_13772
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/
Known issues
Here are the changes found in Patchwork_13772 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][1] -> [WARN][2] ([fdo#109380])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][3] -> [SKIP][4] ([fdo#109271]) +23 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [PASS][5] -> [SKIP][6] ([fdo#109271]) +23 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-icl-u3: [INCOMPLETE][7] ([fdo#107713] / [fdo#108569]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][9] ([fdo#103167]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6562/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#106766]: https://bugs.freedesktop.org/show_bug.cgi?id=106766
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046
Participating hosts (54 -> 45)
--
Additional (1): fi-icl-dsi
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6562 -> Patchwork_13772
CI-20190529: 20190529
CI_DRM_6562: f5d8eddcc4fb9bf414ab4b2b5d70e4433b927211 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13772: ccf23954bf22b6c5e46329cd0999282258e143d6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ccf23954bf22 drm/i915/uc: Don't fail on HuC firmware failure
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13772/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915/uc: Remove redundant RSA offset definition
According to Firmware layout definition, RSA signature is located
after CSS header and uCode so actual RSA offset in the blob can be
easily calculated when needed (and we need it only once).
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 -
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 16ab9bc92919..0bad9b858501 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -238,7 +238,6 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
err = -ENOEXEC;
goto fail;
}
- uc_fw->rsa_offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
@@ -512,11 +511,11 @@ size_t intel_uc_fw_copy_rsa(struct intel_uc_fw *uc_fw,
void *dst, u32 max_len)
{
struct sg_table *pages = uc_fw->obj->mm.pages;
u32 size = min_t(u32, uc_fw->rsa_size, max_len);
+ u32 offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw));
- return sg_pcopy_to_buffer(pages->sgl, pages->nents,
- dst, size, uc_fw->rsa_offset);
+ return sg_pcopy_to_buffer(pages->sgl, pages->nents, dst, size, offset);
}
/**
@@ -536,6 +535,5 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
drm_printf(p, "\tuCode: %u bytes\n", uc_fw->ucode_size);
- drm_printf(p, "\tRSA: offset %u, size %u\n",
- uc_fw->rsa_offset, uc_fw->rsa_size);
+ drm_printf(p, "\tRSA: %u bytes\n", uc_fw->rsa_size);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index 6a04bc6d419f..c2ab2803715d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -75,7 +75,6 @@ struct intel_uc_fw {
u16 minor_ver_found;
u32 rsa_size;
- u32 rsa_offset;
u32 ucode_size;
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915/uc: Remove redundant ucode offset definition
According to Firmware layout definition, uCode is located right
after CSS header, so ucode offset is always same as header size.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 6 ++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 -
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index b526bab5b27a..16ab9bc92919 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -229,7 +229,6 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
}
/* uCode size must calculated from other sizes */
- uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
/* now RSA */
@@ -239,7 +238,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
err = -ENOEXEC;
goto fail;
}
- uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
+ uc_fw->rsa_offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
@@ -536,8 +535,7 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\tuCode: offset %u, size %u\n",
- uc_fw->ucode_offset, uc_fw->ucode_size);
+ drm_printf(p, "\tuCode: %u bytes\n", uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
uc_fw->rsa_offset, uc_fw->rsa_size);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index a8048f91f0da..6a04bc6d419f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -77,7 +77,6 @@ struct intel_uc_fw {
u32 rsa_size;
u32 rsa_offset;
u32 ucode_size;
- u32 ucode_offset;
};
static inline
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915/uc: Remove redundant header_offset/size definitions
According to Firmware layout definition, CSS header is located
in front of the firmware blob, so header offset is always 0.
Similarly, size of the CSS header is constant and currently
used version is exactly 128.
While here, move type/status enums up and keep them together.
v2: use sizeof consistently (Daniele), update commit message
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 2 ++
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..b526bab5b27a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,21 +218,18 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
css = (struct uc_css_header *)fw->data;
- /* Firmware bits always start from header */
- uc_fw->header_offset = 0;
- uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) *
-sizeof(u32);
-
- if (uc_fw->header_size != sizeof(struct uc_css_header)) {
+ /* Check integrity of size values inside CSS header */
+ size = (css->header_size_dw - css->key_size_dw - css->modulus_size_dw -
+ css->exponent_size_dw) * sizeof(u32);
+ if (size != sizeof(struct uc_css_header)) {
DRM_WARN("%s: Mismatched firmware header definition\n",
intel_uc_fw_type_repr(uc_fw->type));
err = -ENOEXEC;
goto fail;
}
- /* then, uCode */
- uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
+ /* uCode size must calculated from other sizes */
+ uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
/* now RSA */
@@ -246,7 +243,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
+ size = sizeof(struct uc_css_header) + uc_fw->ucode_size +
uc_fw->rsa_size;
if (fw->size < size) {
DRM_WARN("%s: Truncated firmware (%zu, expected %zu)\n",
intel_uc_fw_type_repr(uc_fw->type), fw->size, size);
@@ -371,7 +368,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
/* Set the source address for the uCode */
- offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt) + uc_fw->header_offset;
+ offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt);
GEM_BUG_ON(upper_32_bits(offset) & 0x);
intel_uncore_write_fw(uncore, DMA_ADDR_0_LOW, lower_32_bits(offset));
intel_uncore_write_fw(uncore, DMA_ADDR_0_HIGH, upper_32_bits(offset));
@@ -385,7 +382,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->header_size + uc_fw->ucode_size);
+ sizeof(struct uc_css_header) + uc_fw->ucode_size);
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -539,8 +536,6 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\theader: offset %u, size %u\n",
- uc_fw->header_offset, uc_fw->header_size);
drm_printf(p, "\tuCode: offset %u, size %u\n",
uc_fw->ucode_offset, uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index eddbb237fabe..a8048f91f0da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -26,6 +26,7 @@
#define _INTEL_UC_FW_H_
#include
+#include "intel_uc_fw_abi.h"
#include "i915_gem.h"
struct drm_printer;
@@ -57,10 +58,11 @@ enum intel_uc_fw_type {
* of fetching, caching, and loading the firmware image into the uC.
*/
struct intel_uc_fw {
+ enum intel_uc_fw_type type;
+ enum intel_uc_fw_status status;
const char *path;
size_t size;
struct
Re: [Intel-gfx] [PATCH v6 00/24] Associate ddc adapters with connectors
Hi Andezej. On Fri, Jul 26, 2019 at 07:22:54PM +0200, Andrzej Pietrasiewicz wrote: > It is difficult for a user to know which of the i2c adapters is for which > drm connector. This series addresses this problem. > > The idea is to have a symbolic link in connector's sysfs directory, e.g.: > > ls -l /sys/class/drm/card0-HDMI-A-1/ddc > lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \ > -> ../../../../soc/1388.i2c/i2c-2 > > The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run > ddcutil: > > ddcutil -b 2 getvcp 0x10 > VCP code 0x10 (Brightness): current value =90, max value = 100 > > The first patch in the series adds struct i2c_adapter pointer to struct > drm_connector. If the field is used by a particular driver, then an > appropriate symbolic link is created by the generic code, which is also added > by this patch. > > Patch 2 adds a new variant of drm_connector_init(), see the changelog > below. > > Patches 3..24 are examples of how to convert a driver to this new scheme. > ... > > v5..v6: > > - improved subject line of patch 1 > - added kernel-doc for drm_connector_init_with_ddc() > - improved kernel-doc for the ddc field of struct drm_connector > - added Reviewed-by in patches 17 and 18 > - added Acked-by in patch 2 > - made the ownership of ddc i2c_adapter explicit in all patches, > this made the affected patches much simpler Looks good now. Patch 1 and 2 are: Reviewed-by: Sam Ravnborg The remaining patches are: Acked-by: Sam Ravnborg Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/tgl: Define MOCS entries for Tigerlake
On 7/25/19 5:12 PM, Lucas De Marchi wrote:
From: Tomasz Lis
The MOCS table is published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Two of the 3 legacy entries used for gen9 are no longer expected to work.
Although we are changing the gen11 table, those changes are supposed to
be backward compatible since we are only touching previously undefined
entries.
v2: Add the missing entries in 49-51 range and replace "HW reserved"
terminology to what it actually is: L1 is implicitly enabled (from Daniele)
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Signed-off-by: Tomasz Lis
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 37 +---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 290a5e9b90b9..ca370c7487f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -62,6 +62,10 @@ struct drm_i915_mocs_table {
#define GEN11_NUM_MOCS_ENTRIES64 /* 63-64 are reserved, but
configured. */
/* (e)LLC caching options */
+/*
+ * Note: LE_0_PAGETABLE works only up to Gen11; for newer gens it means
+ * the same as LE_UC
+ */
#define LE_0_PAGETABLE_LE_CACHEABILITY(0)
#define LE_1_UC _LE_CACHEABILITY(1)
#define LE_2_WT _LE_CACHEABILITY(2)
@@ -100,8 +104,9 @@ struct drm_i915_mocs_table {
* of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be initialized to PTE.
+ * userspace is concerned and shouldn't be relied upon. For Gen < 12
+ * they will be initialized to PTE. Gen >= 12 onwards don't have a setting for
+ * PTE. We use the same value, but that actually means Uncached.
*
* The last two entries are reserved by the hardware. For ICL+ they
* should be initialized according to bspec and never used, for older
@@ -137,11 +142,13 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
};
#define GEN11_MOCS_ENTRIES \
- /* Base - Uncached (Deprecated) */ \
+ /* Gen11: Base - Uncached (Deprecated) */ \
+ /* Gen12+: Base - Error (Reserved for Non-Use) */ \
MOCS_ENTRY(I915_MOCS_UNCACHED, \
LE_1_UC | LE_TC_1_LLC, \
L3_1_UC), \
/* Base - L3 + LeCC:PAT (Deprecated) */ \
+ /* Gen12+: Base - Reserved */ \
MOCS_ENTRY(I915_MOCS_PTE, \
LE_0_PAGETABLE | LE_TC_1_LLC, \
L3_3_WB), \
I've double-checked the specs and noticed that they now say that MOCS 0
and 1 should be set to all zeros for Gen12 (possibly just to highlight
the fact that they're deprecated/reserved). These are not supposes to be
used so programming them to different values shouldn't matter, but it
might be worth sticking to the specs and add a separate Gen12 table.
I've confirmed all the other entries in the gen11 table are kept the
same in the TGL one, and the ones added below match the table as well.
@@ -233,6 +240,30 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
MOCS_ENTRY(23, \
LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_RSC(1) | LE_SCC(7), \
L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + L3 + LLC */ \
+ MOCS_ENTRY(48, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + L3 */ \
+ MOCS_ENTRY(49, \
+ LE_1_UC | LE_TC_1_LLC, \
+ L3_3_WB), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 + LLC */ \
+ MOCS_ENTRY(50, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_1_UC), \
+ /* Gen12+: Implicitly enable L1 - HDC:L1 */ \
+ MOCS_ENTRY(51, \
+ LE_1_UC | LE_TC_1_LLC, \
+ L3_1_UC), \
+ /* Gen12+: HW Reserved - HW Special Case (CCS) */ \
Entries 60 and 61 are not reserved for HW usage but are special cases
that trigger implicit behaviors. I'd drop the "HW Reserved" tag and
leave just "HW Special Case"
Daniele
+ MOCS_ENTRY(60, \
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ L3_1_UC), \
+ /* Gen12+: HW Reserved - HW Special Case (Displayable) */ \
+ MOCS_ENTRY(61, \
+ LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
+ L3_3_WB), \
/* HW Reserved - SW program but never use */ \
MOCS_ENTRY(62, \
LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 1/3] drm/i915/tgl: Add hpd interrupt handling
On Thu, Jul 25, 2019 at 04:48:11PM -0700, Lucas De Marchi wrote:
> Add hotdplug detection for all ports on TGP. icp_hpd_detection_setup()
> is refactored to be shared with TGP.
>
> While we increase the number of pins, add a BUILD_BUG_ON() to avoid
> going over the number of bits allowed.
>
> v2: use BITS_PER_TYPE and correct type for BUILD_BUG_ON() check
> (requested by Ville)
>
> Cc: Ville Syrjälä
> Cc: Jose Souza
> Cc: Rodrigo Vivi
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 6 +
> drivers/gpu/drm/i915/i915_drv.h | 4 +
> drivers/gpu/drm/i915/i915_irq.c | 128 +--
> drivers/gpu/drm/i915/i915_reg.h | 28 +++-
> 4 files changed, 154 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 342587d91d57..c844ae4480af 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -104,6 +104,12 @@ enum hpd_pin intel_hpd_pin_default(struct
> drm_i915_private *dev_priv,
> if (IS_CNL_WITH_PORT_F(dev_priv))
> return HPD_PORT_E;
> return HPD_PORT_F;
> + case PORT_G:
> + return HPD_PORT_G;
> + case PORT_H:
> + return HPD_PORT_H;
> + case PORT_I:
> + return HPD_PORT_I;
> default:
> MISSING_CASE(port);
> return HPD_NONE;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 59d4a1146039..a2e6b495f033 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -153,6 +153,10 @@ enum hpd_pin {
> HPD_PORT_D,
> HPD_PORT_E,
> HPD_PORT_F,
> + HPD_PORT_G,
> + HPD_PORT_H,
> + HPD_PORT_I,
> +
> HPD_NUM_PINS
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a17d4fd17962..34527cdd9388 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -150,6 +150,18 @@ static const u32 hpd_mcc[HPD_NUM_PINS] = {
> [HPD_PORT_C] = SDE_TC1_HOTPLUG_ICP
> };
>
> +static const u32 hpd_tgp[HPD_NUM_PINS] = {
> + [HPD_PORT_A] = SDE_DDIA_HOTPLUG_ICP,
> + [HPD_PORT_B] = SDE_DDIB_HOTPLUG_ICP,
> + [HPD_PORT_C] = SDE_DDIC_HOTPLUG_TGP,
> + [HPD_PORT_D] = SDE_TC1_HOTPLUG_ICP,
> + [HPD_PORT_E] = SDE_TC2_HOTPLUG_ICP,
> + [HPD_PORT_F] = SDE_TC3_HOTPLUG_ICP,
> + [HPD_PORT_G] = SDE_TC4_HOTPLUG_ICP,
> + [HPD_PORT_H] = SDE_TC5_HOTPLUG_TGP,
> + [HPD_PORT_I] = SDE_TC6_HOTPLUG_TGP,
> +};
> +
> static void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
> i915_reg_t iir, i915_reg_t ier)
> {
> @@ -1724,6 +1736,40 @@ static bool icp_tc_port_hotplug_long_detect(enum
> hpd_pin pin, u32 val)
> }
> }
>
> +static bool tgp_ddi_port_hotplug_long_detect(enum hpd_pin pin, u32 val)
> +{
> + switch (pin) {
> + case HPD_PORT_A:
> + return val & ICP_DDIA_HPD_LONG_DETECT;
> + case HPD_PORT_B:
> + return val & ICP_DDIB_HPD_LONG_DETECT;
> + case HPD_PORT_C:
> + return val & TGP_DDIC_HPD_LONG_DETECT;
> + default:
> + return false;
> + }
> +}
> +
> +static bool tgp_tc_port_hotplug_long_detect(enum hpd_pin pin, u32 val)
> +{
> + switch (pin) {
> + case HPD_PORT_D:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> + case HPD_PORT_E:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> + case HPD_PORT_F:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> + case HPD_PORT_G:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> + case HPD_PORT_H:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC5);
> + case HPD_PORT_I:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC6);
> + default:
> + return false;
> + }
> +}
> +
> static bool spt_port_hotplug2_long_detect(enum hpd_pin pin, u32 val)
> {
> switch (pin) {
> @@ -1803,6 +1849,8 @@ static void intel_get_hpd_pins(struct drm_i915_private
> *dev_priv,
> {
> enum hpd_pin pin;
>
> + BUILD_BUG_ON(BITS_PER_TYPE(*pin_mask) < HPD_NUM_PINS);
> +
> for_each_hpd_pin(pin) {
> if ((hpd[pin] & hotplug_trigger) == 0)
> continue;
> @@ -2561,6 +2609,43 @@ static void icp_irq_handler(struct drm_i915_private
> *dev_priv, u32 pch_iir,
> gmbus_irq_handler(dev_priv);
> }
>
> +static void tgp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
This function winds up being pretty similar to icp_irq_handler. Would
it be simpler to just reuse the icp handler and set the appropriate
masks and long detect handler based on platform at the top?
FWIW, I need to do a similar change to the ICP handler for EHL anyway;
something
[Intel-gfx] [PATCH v2] drm/i915: Allow sharing the idle-barrier from other kernel requests
By placing our idle-barriers in the i915_active fence tree, we expose
those for reuse by other components that are issuing requests along the
kernel_context. Reusing the proto-barrier active_node is perfectly fine
as the new request implies a context-switch, and so an opportune point
to run the idle-barrier. However, the proto-barrier is not equivalent
to a normal active_node and care must be taken to avoid dereferencing the
ERR_PTR used as its request marker.
Reported-by: Lionel Landwerlin
Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next
kernel context switch")
Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly")
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 40 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 13 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 310 ++
drivers/gpu/drm/i915/i915_active.c| 215 +---
drivers/gpu/drm/i915/i915_active.h| 2 +-
drivers/gpu/drm/i915/i915_active_types.h | 2 +-
.../drm/i915/selftests/i915_live_selftests.h | 3 +-
8 files changed, 525 insertions(+), 62 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/selftest_context.c
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index d64b45f7ec6d..211ac6568a5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -162,23 +162,41 @@ static int __intel_context_active(struct i915_active
*active)
if (err)
goto err_ring;
+ return 0;
+
+err_ring:
+ intel_ring_unpin(ce->ring);
+err_put:
+ intel_context_put(ce);
+ return err;
+}
+
+int intel_context_active_acquire(struct intel_context *ce)
+{
+ int err;
+
+ err = i915_active_acquire(>active);
+ if (err)
+ return err;
+
/* Preallocate tracking nodes */
if (!i915_gem_context_is_kernel(ce->gem_context)) {
err = i915_active_acquire_preallocate_barrier(>active,
ce->engine);
- if (err)
- goto err_state;
+ if (err) {
+ i915_active_release(>active);
+ return err;
+ }
}
return 0;
+}
-err_state:
- __context_unpin_state(ce->state);
-err_ring:
- intel_ring_unpin(ce->ring);
-err_put:
- intel_context_put(ce);
- return err;
+void intel_context_active_release(struct intel_context *ce)
+{
+ /* Nodes preallocated in intel_context_active() */
+ i915_active_acquire_barrier(>active);
+ i915_active_release(>active);
}
void
@@ -297,3 +315,7 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_context.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 23c7e4c0ce7c..07f9924de48f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -104,17 +104,8 @@ static inline void intel_context_exit(struct intel_context
*ce)
ce->ops->exit(ce);
}
-static inline int intel_context_active_acquire(struct intel_context *ce)
-{
- return i915_active_acquire(>active);
-}
-
-static inline void intel_context_active_release(struct intel_context *ce)
-{
- /* Nodes preallocated in intel_context_active() */
- i915_active_acquire_barrier(>active);
- i915_active_release(>active);
-}
+int intel_context_active_acquire(struct intel_context *ce);
+void intel_context_active_release(struct intel_context *ce);
static inline struct intel_context *intel_context_get(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e74fbf04a68d..ce54092475da 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -90,7 +90,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
/* Check again on the next retirement. */
engine->wakeref_serial = engine->serial + 1;
- i915_request_add_barriers(rq);
+ i915_request_add_active_barriers(rq);
__i915_request_commit(rq);
return false;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
new file mode 100644
index ..e3b45fe747ae
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -0,0 +1,310 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_selftest.h"
+#include "intel_gt.h"
+
+#include "gem/selftests/mock_context.h"
+#include
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Associate ddc adapters with connectors (rev3)
== Series Details == Series: Associate ddc adapters with connectors (rev3) URL : https://patchwork.freedesktop.org/series/63558/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5470455b0f61 drm: Add ddc link in sysfs created by drm_connector ab31f78e9dd9 drm: Add drm_connector_init() variant with ddc 90f15411402a drm/exynos: Provide ddc symlink in connector's sysfs e4bf65fc137c drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory d1abdd3a0d60 drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory 8316d55b4a6e drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory 28fb2045d939 drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory 7bfcd7ce30e8 drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory ee0b2ba65c60 drm/tegra: Provide ddc symlink in output connector sysfs directory 0d3c826eed48 drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs 39d7e4d7efce drm/imx: imx-tve: Provide ddc symlink in connector's sysfs c83d1cf7a299 drm/vc4: Provide ddc symlink in connector sysfs directory 659435776d97 drm: zte: Provide ddc symlink in hdmi connector sysfs directory a5b22729b5f0 drm: zte: Provide ddc symlink in vga connector sysfs directory aca709be82e0 drm/tilcdc: Provide ddc symlink in connector sysfs directory 8c81158d2116 drm: sti: Provide ddc symlink in hdmi connector sysfs directory 883191969774 drm/mgag200: Provide ddc symlink in connector sysfs directory e478085daf83 drm/ast: Provide ddc symlink in connector sysfs directory f69ead63e662 drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory f3a99f70eeba drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory 56c5eb9e50ca drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory d01cbd2ce009 drm/amdgpu: Provide ddc symlink in connector sysfs directory -:91: WARNING:LONG_LINE: line over 100 characters #91: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1682: + drm_connector_helper_add(_connector->base, _connector_vga_helper_funcs); -:112: WARNING:LONG_LINE: line over 100 characters #112: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1707: + drm_connector_helper_add(_connector->base, _connector_vga_helper_funcs); -:133: WARNING:LONG_LINE: line over 100 characters #133: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1737: + drm_connector_helper_add(_connector->base, _connector_dvi_helper_funcs); -:154: WARNING:LONG_LINE: line over 100 characters #154: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1792: + drm_connector_helper_add(_connector->base, _connector_dvi_helper_funcs); -:179: WARNING:LONG_LINE: line over 100 characters #179: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1841: + drm_connector_helper_add(_connector->base, _connector_dp_helper_funcs); -:204: WARNING:LONG_LINE: line over 100 characters #204: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1888: + drm_connector_helper_add(_connector->base, _connector_dp_helper_funcs); -:225: WARNING:LONG_LINE: line over 100 characters #225: FILE: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1912: + drm_connector_helper_add(_connector->base, _connector_lvds_helper_funcs); total: 0 errors, 7 warnings, 0 checks, 204 lines checked a431f33c8745 drm/radeon: Provide ddc symlink in connector sysfs directory -:91: WARNING:LONG_LINE: line over 100 characters #91: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2065: + drm_connector_helper_add(_connector->base, _vga_connector_helper_funcs); -:112: WARNING:LONG_LINE: line over 100 characters #112: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2095: + drm_connector_helper_add(_connector->base, _vga_connector_helper_funcs); -:133: WARNING:LONG_LINE: line over 100 characters #133: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2131: + drm_connector_helper_add(_connector->base, _dvi_connector_helper_funcs); -:154: WARNING:LONG_LINE: line over 100 characters #154: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2193: + drm_connector_helper_add(_connector->base, _dvi_connector_helper_funcs); -:179: WARNING:LONG_LINE: line over 100 characters #179: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2250: + drm_connector_helper_add(_connector->base, _dp_connector_helper_funcs); -:204: WARNING:LONG_LINE: line over 100 characters #204: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2305: + drm_connector_helper_add(_connector->base, _dp_connector_helper_funcs); -:237: WARNING:LONG_LINE: line over 100 characters #237: FILE: drivers/gpu/drm/radeon/radeon_connectors.c:2350: + drm_connector_helper_add(_connector->base, _lvds_connector_helper_funcs); -:258:
Re: [Intel-gfx] [PATCH 1/4] drm/i915/tgl: Move fault registers to their new offset
On 7/25/19 5:12 PM, Lucas De Marchi wrote:
The fault registers moved to another offset. The old location is now
taken by the global MOCS registers, to be added in a follow up change.
Based on previous patches by Michel Thierry .
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/intel_gt.c| 24
drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
drivers/gpu/drm/i915/i915_reg.h | 3 +++
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f7e69db4019d..caa07eb20a64 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -79,7 +79,10 @@ intel_gt_clear_error_registers(struct intel_gt *gt,
I915_MASTER_ERROR_INTERRUPT);
}
- if (INTEL_GEN(i915) >= 8) {
+ if (INTEL_GEN(i915) >= 12) {
+ rmw_clear(uncore, GEN12_RING_FAULT_REG, RING_FAULT_VALID);
+ intel_uncore_posting_read(uncore, GEN12_RING_FAULT_REG);
+ } else if (INTEL_GEN(i915) >= 8) {
rmw_clear(uncore, GEN8_RING_FAULT_REG, RING_FAULT_VALID);
intel_uncore_posting_read(uncore, GEN8_RING_FAULT_REG);
} else if (INTEL_GEN(i915) >= 6) {
@@ -117,14 +120,27 @@ static void gen6_check_faults(struct intel_gt *gt)
static void gen8_check_faults(struct intel_gt *gt)
{
struct intel_uncore *uncore = gt->uncore;
- u32 fault = intel_uncore_read(uncore, GEN8_RING_FAULT_REG);
+ i915_reg_t fault_reg, fault_data0_reg, fault_data1_reg;
+ u32 fault;
+
+ if (INTEL_GEN(gt->i915) >= 12) {
+ fault_reg = GEN12_RING_FAULT_REG;
+ fault_data0_reg = GEN12_FAULT_TLB_DATA0;
+ fault_data1_reg = GEN12_FAULT_TLB_DATA1;
+ } else {
+ fault_reg = GEN8_RING_FAULT_REG;
+ fault_data0_reg = GEN8_FAULT_TLB_DATA0;
+ fault_data1_reg = GEN8_FAULT_TLB_DATA1;
+ }
+ fault = intel_uncore_read(uncore, fault_reg);
if (fault & RING_FAULT_VALID) {
u32 fault_data0, fault_data1;
u64 fault_addr;
- fault_data0 = intel_uncore_read(uncore, GEN8_FAULT_TLB_DATA0);
- fault_data1 = intel_uncore_read(uncore, GEN8_FAULT_TLB_DATA1);
+ fault_data0 = intel_uncore_read(uncore, fault_data0_reg);
+ fault_data1 = intel_uncore_read(uncore, fault_data1_reg);
+
fault_addr = ((u64)(fault_data1 & FAULT_VA_HIGH_BITS) << 44) |
((u64)fault_data0 << 12);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
index 56dfc2650836..41a14f40a8c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1106,7 +1106,10 @@ static void error_record_engine_registers(struct
i915_gpu_state *error,
if (INTEL_GEN(dev_priv) >= 6) {
ee->rc_psmi = ENGINE_READ(engine, RING_PSMI_CTL);
- if (INTEL_GEN(dev_priv) >= 8)
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ ee->fault_reg = I915_READ(GEN12_RING_FAULT_REG);
+ else if (INTEL_GEN(dev_priv) >= 8)
ee->fault_reg = I915_READ(GEN8_RING_FAULT_REG);
else
ee->fault_reg = GEN6_RING_FAULT_REG_READ(engine);
@@ -1497,7 +1500,12 @@ static void capture_reg_state(struct i915_gpu_state
*error)
if (IS_GEN(i915, 7))
error->err_int = intel_uncore_read(uncore, GEN7_ERR_INT);
- if (INTEL_GEN(i915) >= 8) {
+ if (INTEL_GEN(i915) >= 12) {
+ error->fault_data0 = intel_uncore_read(uncore,
+ GEN12_FAULT_TLB_DATA0);
+ error->fault_data1 = intel_uncore_read(uncore,
+ GEN12_FAULT_TLB_DATA1);
+ } else if (INTEL_GEN(i915) >= 8) {
error->fault_data0 = intel_uncore_read(uncore,
GEN8_FAULT_TLB_DATA0);
error->fault_data1 = intel_uncore_read(uncore,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 24f2a52a2b42..19e72f0c73d8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2490,6 +2490,7 @@ enum i915_power_well_id {
#define RENDER_HWS_PGA_GEN7 _MMIO(0x04080)
#define RING_FAULT_REG(engine)_MMIO(0x4094 + 0x100 * (engine)->hw_id)
#define GEN8_RING_FAULT_REG _MMIO(0x4094)
+#define GEN12_RING_FAULT_REG _MMIO(0xcec4)
#define GEN8_RING_FAULT_ENGINE_ID(x)(((x) >> 12) & 0x7)
#define RING_FAULT_GTTSEL_MASK (1 << 11)
#define RING_FAULT_SRCID(x) (((x) >> 3) & 0xff)
@@ -2633,6 +2634,8 @@ enum i915_power_well_id {
Re: [Intel-gfx] [PATCH 1/3] drm/i915/uc: Remove redundant header_offset/size definitions
On 7/26/19 10:49 AM, Michal Wajdeczko wrote:
On Fri, 26 Jul 2019 19:33:18 +0200, Daniele Ceraolo Spurio
wrote:
On 7/26/19 8:58 AM, Michal Wajdeczko wrote:
According to Firmware layout definition, CSS header is located
in front of the firmware blob, so header offset is always 0.
Similarly, size of the CSS header is constant and is 128.
While here, move type/status enums up and keep them together.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 2 ++
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..66bda0c514a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,21 +218,18 @@ void intel_uc_fw_fetch(struct intel_uc_fw
*uc_fw, struct drm_i915_private *i915)
css = (struct uc_css_header *)fw->data;
- /* Firmware bits always start from header */
- uc_fw->header_offset = 0;
- uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) *
- sizeof(u32);
-
- if (uc_fw->header_size != sizeof(struct uc_css_header)) {
+ /* Check integrity of size values inside CSS header */
+ size = (css->header_size_dw - css->key_size_dw -
css->modulus_size_dw -
+ css->exponent_size_dw) * sizeof(u32);
+ if (size != sizeof(struct uc_css_header)) {
DRM_WARN("%s: Mismatched firmware header definition\n",
intel_uc_fw_type_repr(uc_fw->type));
err = -ENOEXEC;
goto fail;
}
- /* then, uCode */
- uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
+ /* Firmware blob always starts with the header, then uCode */
+ uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) *
sizeof(u32);
/* now RSA */
@@ -246,7 +243,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw,
struct drm_i915_private *i915)
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of
all three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
+ size = sizeof(struct uc_css_header) + uc_fw->ucode_size +
uc_fw->rsa_size;
if (fw->size < size) {
DRM_WARN("%s: Truncated firmware (%zu, expected %zu)\n",
intel_uc_fw_type_repr(uc_fw->type), fw->size, size);
@@ -371,7 +368,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw,
struct intel_gt *gt,
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
/* Set the source address for the uCode */
- offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt) + uc_fw->header_offset;
+ offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt);
GEM_BUG_ON(upper_32_bits(offset) & 0x);
intel_uncore_write_fw(uncore, DMA_ADDR_0_LOW,
lower_32_bits(offset));
intel_uncore_write_fw(uncore, DMA_ADDR_0_HIGH,
upper_32_bits(offset));
@@ -385,7 +382,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw,
struct intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->header_size + uc_fw->ucode_size);
+ uc_fw->ucode_offset + uc_fw->ucode_size);
in other places you've replaced uc_fw->header_size with sizeof(struct
uc_css_header), I'd do the same here for consistency.
ha! oops, this sneaked into patch 2 instead, will fix
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -539,8 +536,6 @@ void intel_uc_fw_dump(const struct intel_uc_fw
*uc_fw, struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\theader: offset %u, size %u\n",
- uc_fw->header_offset, uc_fw->header_size);
drm_printf(p, "\tuCode: offset %u, size %u\n",
uc_fw->ucode_offset, uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index eddbb237fabe..a8048f91f0da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -26,6 +26,7 @@
#define _INTEL_UC_FW_H_
#include
+#include "intel_uc_fw_abi.h"
#include "i915_gem.h"
struct drm_printer;
@@ -57,10 +58,11 @@ enum intel_uc_fw_type {
* of fetching, caching, and loading the firmware image into the uC.
*/
struct intel_uc_fw {
+ enum intel_uc_fw_type type;
+ enum intel_uc_fw_status status;
const char *path;
size_t
Re: [Intel-gfx] [PATCH 1/3] drm/i915/uc: Remove redundant header_offset/size definitions
On Fri, 26 Jul 2019 19:33:18 +0200, Daniele Ceraolo Spurio
wrote:
On 7/26/19 8:58 AM, Michal Wajdeczko wrote:
According to Firmware layout definition, CSS header is located
in front of the firmware blob, so header offset is always 0.
Similarly, size of the CSS header is constant and is 128.
While here, move type/status enums up and keep them together.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 2 ++
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..66bda0c514a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,21 +218,18 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw,
struct drm_i915_private *i915)
css = (struct uc_css_header *)fw->data;
- /* Firmware bits always start from header */
- uc_fw->header_offset = 0;
- uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) *
-sizeof(u32);
-
- if (uc_fw->header_size != sizeof(struct uc_css_header)) {
+ /* Check integrity of size values inside CSS header */
+ size = (css->header_size_dw - css->key_size_dw - css->modulus_size_dw
-
+ css->exponent_size_dw) * sizeof(u32);
+ if (size != sizeof(struct uc_css_header)) {
DRM_WARN("%s: Mismatched firmware header definition\n",
intel_uc_fw_type_repr(uc_fw->type));
err = -ENOEXEC;
goto fail;
}
- /* then, uCode */
- uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
+ /* Firmware blob always starts with the header, then uCode */
+ uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) *
sizeof(u32);
/* now RSA */
@@ -246,7 +243,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw,
struct drm_i915_private *i915)
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all
three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
+ size = sizeof(struct uc_css_header) + uc_fw->ucode_size +
uc_fw->rsa_size;
if (fw->size < size) {
DRM_WARN("%s: Truncated firmware (%zu, expected %zu)\n",
intel_uc_fw_type_repr(uc_fw->type), fw->size, size);
@@ -371,7 +368,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw,
struct intel_gt *gt,
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
/* Set the source address for the uCode */
- offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt) + uc_fw->header_offset;
+ offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt);
GEM_BUG_ON(upper_32_bits(offset) & 0x);
intel_uncore_write_fw(uncore, DMA_ADDR_0_LOW, lower_32_bits(offset));
intel_uncore_write_fw(uncore, DMA_ADDR_0_HIGH,
upper_32_bits(offset));
@@ -385,7 +382,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw,
struct intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->header_size + uc_fw->ucode_size);
+ uc_fw->ucode_offset + uc_fw->ucode_size);
in other places you've replaced uc_fw->header_size with sizeof(struct
uc_css_header), I'd do the same here for consistency.
ha! oops, this sneaked into patch 2 instead, will fix
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -539,8 +536,6 @@ void intel_uc_fw_dump(const struct intel_uc_fw
*uc_fw, struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\theader: offset %u, size %u\n",
- uc_fw->header_offset, uc_fw->header_size);
drm_printf(p, "\tuCode: offset %u, size %u\n",
uc_fw->ucode_offset, uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index eddbb237fabe..a8048f91f0da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -26,6 +26,7 @@
#define _INTEL_UC_FW_H_
#include
+#include "intel_uc_fw_abi.h"
#include "i915_gem.h"
struct drm_printer;
@@ -57,10 +58,11 @@ enum intel_uc_fw_type {
* of fetching, caching, and loading the firmware image into the uC.
Re: [Intel-gfx] [PATCH 3/3] drm/i915/uc: Remove redundant RSA offset definition
On 7/26/19 8:58 AM, Michal Wajdeczko wrote:
According to Firmware layout definition, RSA signature is located
after CSS header and uCode so actual RSA offset in the blob can be
easily calculated when needed (and we need it only once).
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 -
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 05079c59ae04..b0f2852dec41 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -238,7 +238,6 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
err = -ENOEXEC;
goto fail;
}
- uc_fw->rsa_offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
@@ -512,11 +511,11 @@ size_t intel_uc_fw_copy_rsa(struct intel_uc_fw *uc_fw,
void *dst, u32 max_len)
{
struct sg_table *pages = uc_fw->obj->mm.pages;
u32 size = min_t(u32, uc_fw->rsa_size, max_len);
+ u32 offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw));
- return sg_pcopy_to_buffer(pages->sgl, pages->nents,
- dst, size, uc_fw->rsa_offset);
+ return sg_pcopy_to_buffer(pages->sgl, pages->nents, dst, size, offset);
}
/**
@@ -536,6 +535,5 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
drm_printf(p, "\tuCode: %u bytes\n", uc_fw->ucode_size);
- drm_printf(p, "\tRSA: offset %u, size %u\n",
- uc_fw->rsa_offset, uc_fw->rsa_size);
+ drm_printf(p, "\tRSA: %u bytes\n", uc_fw->rsa_size);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index 6a04bc6d419f..c2ab2803715d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -75,7 +75,6 @@ struct intel_uc_fw {
u16 minor_ver_found;
u32 rsa_size;
- u32 rsa_offset;
u32 ucode_size;
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Remove redundant ucode offset definition
On 7/26/19 8:58 AM, Michal Wajdeczko wrote:
According to Firmware layout definition, uCode is located right
after CSS header, so ucode offset is always same as header size.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 -
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 66bda0c514a3..05079c59ae04 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -229,7 +229,6 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
}
/* Firmware blob always starts with the header, then uCode */
This comment should be updated (or removed) as well. With that:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
- uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
/* now RSA */
@@ -239,7 +238,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
err = -ENOEXEC;
goto fail;
}
- uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
+ uc_fw->rsa_offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
@@ -382,7 +381,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->ucode_offset + uc_fw->ucode_size);
+ sizeof(struct uc_css_header) + uc_fw->ucode_size);
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -536,8 +535,7 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\tuCode: offset %u, size %u\n",
- uc_fw->ucode_offset, uc_fw->ucode_size);
+ drm_printf(p, "\tuCode: %u bytes\n", uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
uc_fw->rsa_offset, uc_fw->rsa_size);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index a8048f91f0da..6a04bc6d419f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -77,7 +77,6 @@ struct intel_uc_fw {
u32 rsa_size;
u32 rsa_offset;
u32 ucode_size;
- u32 ucode_offset;
};
static inline
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index d32885b906ae..8ef6539ae78a 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -111,8 +111,10 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
drm_connector_helper_add(>connector,
_vga_con_helper_funcs);
- ret = drm_connector_init(bridge->dev, >connector,
-_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(bridge->dev, >connector,
+ _vga_con_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ vga->ddc);
if (ret) {
DRM_ERROR("Failed to initialize connector\n");
return ret;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/uc: Remove redundant header_offset/size definitions
On 7/26/19 8:58 AM, Michal Wajdeczko wrote:
According to Firmware layout definition, CSS header is located
in front of the firmware blob, so header offset is always 0.
Similarly, size of the CSS header is constant and is 128.
While here, move type/status enums up and keep them together.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 2 ++
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..66bda0c514a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,21 +218,18 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
css = (struct uc_css_header *)fw->data;
- /* Firmware bits always start from header */
- uc_fw->header_offset = 0;
- uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) *
-sizeof(u32);
-
- if (uc_fw->header_size != sizeof(struct uc_css_header)) {
+ /* Check integrity of size values inside CSS header */
+ size = (css->header_size_dw - css->key_size_dw - css->modulus_size_dw -
+ css->exponent_size_dw) * sizeof(u32);
+ if (size != sizeof(struct uc_css_header)) {
DRM_WARN("%s: Mismatched firmware header definition\n",
intel_uc_fw_type_repr(uc_fw->type));
err = -ENOEXEC;
goto fail;
}
- /* then, uCode */
- uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
+ /* Firmware blob always starts with the header, then uCode */
+ uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
/* now RSA */
@@ -246,7 +243,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
+ size = sizeof(struct uc_css_header) + uc_fw->ucode_size +
uc_fw->rsa_size;
if (fw->size < size) {
DRM_WARN("%s: Truncated firmware (%zu, expected %zu)\n",
intel_uc_fw_type_repr(uc_fw->type), fw->size, size);
@@ -371,7 +368,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
/* Set the source address for the uCode */
- offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt) + uc_fw->header_offset;
+ offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt);
GEM_BUG_ON(upper_32_bits(offset) & 0x);
intel_uncore_write_fw(uncore, DMA_ADDR_0_LOW, lower_32_bits(offset));
intel_uncore_write_fw(uncore, DMA_ADDR_0_HIGH, upper_32_bits(offset));
@@ -385,7 +382,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->header_size + uc_fw->ucode_size);
+ uc_fw->ucode_offset + uc_fw->ucode_size);
in other places you've replaced uc_fw->header_size with sizeof(struct
uc_css_header), I'd do the same here for consistency.
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -539,8 +536,6 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\theader: offset %u, size %u\n",
- uc_fw->header_offset, uc_fw->header_size);
drm_printf(p, "\tuCode: offset %u, size %u\n",
uc_fw->ucode_offset, uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index eddbb237fabe..a8048f91f0da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -26,6 +26,7 @@
#define _INTEL_UC_FW_H_
#include
+#include "intel_uc_fw_abi.h"
#include "i915_gem.h"
struct drm_printer;
@@ -57,10 +58,11 @@ enum intel_uc_fw_type {
* of fetching, caching, and loading the firmware image into the uC.
*/
struct intel_uc_fw {
+ enum intel_uc_fw_type type;
+ enum intel_uc_fw_status status;
const char *path;
[Intel-gfx] [PATCH v6 23/24] drm/radeon: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/radeon/radeon_connectors.c | 142 +++--
1 file changed, 106 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index c60d1a44d22a..b3ad8d890801 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1870,6 +1870,7 @@ radeon_add_atom_connector(struct drm_device *dev,
struct radeon_connector_atom_dig *radeon_dig_connector;
struct drm_encoder *encoder;
struct radeon_encoder *radeon_encoder;
+ struct i2c_adapter *ddc;
uint32_t subpixel_order = SubPixelNone;
bool shared_ddc = false;
bool is_dp_bridge = false;
@@ -1947,17 +1948,21 @@ radeon_add_atom_connector(struct drm_device *dev,
radeon_connector->con_priv = radeon_dig_connector;
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
- if (radeon_connector->ddc_bus)
+ if (radeon_connector->ddc_bus) {
has_aux = true;
- else
+ ddc = _connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
case DRM_MODE_CONNECTOR_DVIA:
default:
- drm_connector_init(dev, _connector->base,
- _dp_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
_connector->base,
+ _dp_connector_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(_connector->base,
_dp_connector_helper_funcs);
connector->interlace_allowed = true;
@@ -1979,8 +1984,10 @@ radeon_add_atom_connector(struct drm_device *dev,
case DRM_MODE_CONNECTOR_HDMIA:
case DRM_MODE_CONNECTOR_HDMIB:
case DRM_MODE_CONNECTOR_DisplayPort:
- drm_connector_init(dev, _connector->base,
- _dp_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
_connector->base,
+ _dp_connector_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(_connector->base,
_dp_connector_helper_funcs);
drm_object_attach_property(_connector->base.base,
@@ -2027,8 +2034,10 @@ radeon_add_atom_connector(struct drm_device *dev,
break;
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
- drm_connector_init(dev, _connector->base,
- _lvds_bridge_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
_connector->base,
+
_lvds_bridge_connector_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(_connector->base,
_dp_connector_helper_funcs);
drm_object_attach_property(_connector->base.base,
@@ -2042,13 +2051,18 @@ radeon_add_atom_connector(struct drm_device *dev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, _connector->base,
_vga_connector_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_vga_connector_helper_funcs);
if (i2c_bus->valid) {
radeon_connector->ddc_bus =
radeon_i2c_lookup(rdev, i2c_bus);
if (!radeon_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init_with_ddc(dev,
_connector->base,
+
[Intel-gfx] [PATCH v6 24/24] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9bf28de10401..268f1bd20b99 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3067,6 +3067,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
struct intel_encoder *intel_encoder = _dig_port->base;
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct i2c_adapter *ddc;
enum port port = intel_encoder->port;
DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
@@ -3077,8 +3078,13 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dig_port->max_lanes, port_name(port)))
return;
- drm_connector_init(dev, connector, _hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
+ ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+ drm_connector_init_with_ddc(dev, connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ ddc);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
connector->interlace_allowed = 1;
@@ -3088,8 +3094,6 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
connector->ycbcr_420_allowed = true;
- intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
-
if (WARN_ON(port == PORT_A))
return;
intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 1/2] drm: Introduce new DRM_FORMAT_XYUV
On Tue, Nov 20, 2018 at 04:27:21PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 09, 2018 at 11:39:15AM +0200, Stanislav Lisovskiy wrote:
> > v5: This is YUV444 packed format same as AYUV, but without alpha,
> > as supported by i915.
> >
> > v6: Removed unneeded initializer for new XYUV format.
> >
> > v7: Added is_yuv field initialization according to latest
> > drm_fourcc format structure initialization changes.
> >
> > v8: Edited commit message to be more clear about skl+, renamed
> > PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
> > doesn't support per-pixel alpha. Fixed minor code issues.
> >
> > v9: Moved DRM format check to proper place in intel_framebuffer_init.
> >
> > v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV
> >
> > v11: Fixed rebase conflict, caused by added new formats to drm-tip
> > meanwhile.
> >
> > Reviewed-by: Alexandru Gheorghe
> > Signed-off-by: Stanislav Lisovskiy
>
> Pushed this one to drm-misc-next. Thanks for the patch and review.
>
> The i915 part won't apply properly in drm-misc-next, so we'll need
> to wait until dinq and drm-misc-next are suitably aligned before
> we push that one.
It looks like we forgot to ever go back and apply the i915 patch here.
Any plans to rebase/report it so we can get it landed?
Matt
>
> > ---
> > drivers/gpu/drm/drm_fourcc.c | 1 +
> > include/uapi/drm/drm_fourcc.h | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index f523948c82b1..94d358eb0b8d 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -237,6 +237,7 @@ const struct drm_format_info *__drm_format_info(u32
> > format)
> > { .format = DRM_FORMAT_X0L2,.depth = 0,
> > .num_planes = 1,
> > .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
> > .block_h = { 2, 0, 0 },
> > .hsub = 2, .vsub = 2, .is_yuv = true },
> > + { .format = DRM_FORMAT_XYUV,.depth = 0,
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> > };
> >
> > unsigned int i;
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index e7e48f1f4a74..0b44260a5ee9 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -151,6 +151,7 @@ extern "C" {
> > #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
> > [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >
> > #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
> > [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V')
> > /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> >
> > /*
> > * packed YCbCr420 2x2 tiled formats
> > --
> > 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
--
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
[Intel-gfx] [PATCH v6 22/24] drm/amdgpu: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 96 ++-
1 file changed, 70 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 73b2ede773d3..ece55c8fa673 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1505,6 +1505,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
struct amdgpu_connector_atom_dig *amdgpu_dig_connector;
struct drm_encoder *encoder;
struct amdgpu_encoder *amdgpu_encoder;
+ struct i2c_adapter *ddc = NULL;
uint32_t subpixel_order = SubPixelNone;
bool shared_ddc = false;
bool is_dp_bridge = false;
@@ -1574,17 +1575,21 @@ amdgpu_connector_add(struct amdgpu_device *adev,
amdgpu_connector->con_priv = amdgpu_dig_connector;
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus = amdgpu_i2c_lookup(adev,
i2c_bus);
- if (amdgpu_connector->ddc_bus)
+ if (amdgpu_connector->ddc_bus) {
has_aux = true;
- else
+ ddc = _connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
case DRM_MODE_CONNECTOR_DVIA:
default:
- drm_connector_init(dev, _connector->base,
- _connector_dp_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
_connector->base,
+ _connector_dp_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(_connector->base,
_connector_dp_helper_funcs);
connector->interlace_allowed = true;
@@ -1602,8 +1607,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
case DRM_MODE_CONNECTOR_HDMIA:
case DRM_MODE_CONNECTOR_HDMIB:
case DRM_MODE_CONNECTOR_DisplayPort:
- drm_connector_init(dev, _connector->base,
- _connector_dp_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
_connector->base,
+ _connector_dp_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(_connector->base,
_connector_dp_helper_funcs);
drm_object_attach_property(_connector->base.base,
@@ -1644,8 +1651,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
break;
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
- drm_connector_init(dev, _connector->base,
- _connector_edp_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
_connector->base,
+ _connector_edp_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(_connector->base,
_connector_dp_helper_funcs);
drm_object_attach_property(_connector->base.base,
@@ -1659,13 +1668,18 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, _connector->base,
_connector_vga_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_connector_vga_helper_funcs);
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus =
amdgpu_i2c_lookup(adev, i2c_bus);
if (!amdgpu_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init_with_ddc(dev,
_connector->base,
+
[Intel-gfx] [PATCH v6 20/24] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 218a7b2308f7..83b94b66e464 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2200,8 +2200,10 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge) drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); - drm_connector_init(bridge->dev, connector, _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(bridge->dev, connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc); drm_connector_attach_encoder(connector, encoder); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 21/24] drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/ti-tfp410.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index dbf35c7bc85e..61cc2354ef1b 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -134,8 +134,10 @@ static int tfp410_attach(struct drm_bridge *bridge)
drm_connector_helper_add(>connector,
_con_helper_funcs);
- ret = drm_connector_init(bridge->dev, >connector,
-_con_funcs, dvi->connector_type);
+ ret = drm_connector_init_with_ddc(bridge->dev, >connector,
+ _con_funcs,
+ dvi->connector_type,
+ dvi->ddc);
if (ret) {
dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
return ret;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 17/24] drm/mgag200: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 822f2a13748f..5e778b5f1a10 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1678,18 +1678,19 @@ static struct drm_connector *mga_vga_init(struct
drm_device *dev)
return NULL;
connector = _connector->base;
+ mga_connector->i2c = mgag200_i2c_create(dev);
+ if (!mga_connector->i2c)
+ DRM_ERROR("failed to add ddc bus\n");
- drm_connector_init(dev, connector,
- _vga_connector_funcs, DRM_MODE_CONNECTOR_VGA);
+ drm_connector_init_with_ddc(dev, connector,
+ _vga_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ _connector->i2c->adapter);
drm_connector_helper_add(connector, _vga_connector_helper_funcs);
drm_connector_register(connector);
- mga_connector->i2c = mgag200_i2c_create(dev);
- if (!mga_connector->i2c)
- DRM_ERROR("failed to add ddc bus\n");
-
return connector;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 18/24] drm/ast: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c792362024a5..1c899a6e87b7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -867,7 +867,14 @@ static int ast_connector_init(struct drm_device *dev)
return -ENOMEM;
connector = _connector->base;
- drm_connector_init(dev, connector, _connector_funcs,
DRM_MODE_CONNECTOR_VGA);
+ ast_connector->i2c = ast_i2c_create(dev);
+ if (!ast_connector->i2c)
+ DRM_ERROR("failed to add ddc bus for connector\n");
+
+ drm_connector_init_with_ddc(dev, connector,
+ _connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ _connector->i2c->adapter);
drm_connector_helper_add(connector, _connector_helper_funcs);
@@ -881,10 +888,6 @@ static int ast_connector_init(struct drm_device *dev)
encoder = list_first_entry(>mode_config.encoder_list, struct
drm_encoder, head);
drm_connector_attach_encoder(connector, encoder);
- ast_connector->i2c = ast_i2c_create(dev);
- if (!ast_connector->i2c)
- DRM_ERROR("failed to add ddc bus for connector\n");
-
return 0;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 16/24] drm: sti: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/sti/sti_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index f03d617edc4c..33d06e0a9168 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -1284,8 +1284,10 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data) drm_connector->polled = DRM_CONNECTOR_POLL_HPD; - drm_connector_init(drm_dev, drm_connector, - _hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm_dev, drm_connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc_adapt); drm_connector_helper_add(drm_connector, _hdmi_connector_helper_funcs); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 15/24] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index c6e4e52f32bc..d51776dd7a03 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -222,8 +222,10 @@ static struct drm_connector *tfp410_connector_create(struct drm_device *dev, connector = _connector->base; - drm_connector_init(dev, connector, _connector_funcs, - DRM_MODE_CONNECTOR_DVID); + drm_connector_init_with_ddc(dev, connector, + _connector_funcs, + DRM_MODE_CONNECTOR_DVID, + mod->i2c); drm_connector_helper_add(connector, _connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 14/24] drm: zte: Provide ddc symlink in vga connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/zte/zx_vga.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index 9b67e419280c..c4fa3bbaba78 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -165,8 +165,10 @@ static int zx_vga_register(struct drm_device *drm, struct
zx_vga *vga)
vga->connector.polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(drm, connector, _vga_connector_funcs,
-DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(drm, connector,
+ _vga_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ >ddc->adap);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init connector: %d\n", ret);
goto clean_encoder;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 13/24] drm: zte: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/zte/zx_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c index a50f5a1f09b8..b98a1420dcd3 100644 --- a/drivers/gpu/drm/zte/zx_hdmi.c +++ b/drivers/gpu/drm/zte/zx_hdmi.c @@ -319,8 +319,10 @@ static int zx_hdmi_register(struct drm_device *drm, struct zx_hdmi *hdmi) hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD; - drm_connector_init(drm, >connector, _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, >connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + >ddc->adap); drm_connector_helper_add(>connector, _hdmi_connector_helper_funcs); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 12/24] drm/vc4: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ee7d4e7b0ee3..eb57c907a256 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -267,7 +267,8 @@ static const struct drm_connector_helper_funcs
vc4_hdmi_connector_helper_funcs =
};
static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
-struct drm_encoder
*encoder)
+struct drm_encoder
*encoder,
+struct i2c_adapter *ddc)
{
struct drm_connector *connector;
struct vc4_hdmi_connector *hdmi_connector;
@@ -281,8 +282,10 @@ static struct drm_connector
*vc4_hdmi_connector_init(struct drm_device *dev,
hdmi_connector->encoder = encoder;
- drm_connector_init(dev, connector, _hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(dev, connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ ddc);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
/* Create and attach TV margin props to this connector. */
@@ -1395,7 +1398,8 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(hdmi->encoder, _hdmi_encoder_helper_funcs);
- hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder);
+ hdmi->connector =
+ vc4_hdmi_connector_init(drm, hdmi->encoder, hdmi->ddc);
if (IS_ERR(hdmi->connector)) {
ret = PTR_ERR(hdmi->connector);
goto err_destroy_encoder;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 11/24] drm/imx: imx-tve: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/imx/imx-tve.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c index 649515868f86..5bbfaa2cd0f4 100644 --- a/drivers/gpu/drm/imx/imx-tve.c +++ b/drivers/gpu/drm/imx/imx-tve.c @@ -484,8 +484,10 @@ static int imx_tve_register(struct drm_device *drm, struct imx_tve *tve) drm_connector_helper_add(>connector, _tve_connector_helper_funcs); - drm_connector_init(drm, >connector, _tve_connector_funcs, - DRM_MODE_CONNECTOR_VGA); + drm_connector_init_with_ddc(drm, >connector, + _tve_connector_funcs, + DRM_MODE_CONNECTOR_VGA, + tve->ddc); drm_connector_attach_encoder(>connector, >encoder); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 10/24] drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/imx/imx-ldb.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c index de62a4cd4827..db461b6a257f 100644 --- a/drivers/gpu/drm/imx/imx-ldb.c +++ b/drivers/gpu/drm/imx/imx-ldb.c @@ -462,9 +462,10 @@ static int imx_ldb_register(struct drm_device *drm, */ drm_connector_helper_add(_ldb_ch->connector, _ldb_connector_helper_funcs); - drm_connector_init(drm, _ldb_ch->connector, - _ldb_connector_funcs, - DRM_MODE_CONNECTOR_LVDS); + drm_connector_init_with_ddc(drm, _ldb_ch->connector, + _ldb_connector_funcs, + DRM_MODE_CONNECTOR_LVDS, + imx_ldb_ch->ddc); drm_connector_attach_encoder(_ldb_ch->connector, encoder); } -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 09/24] drm/tegra: Provide ddc symlink in output connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/tegra/hdmi.c | 7 --- drivers/gpu/drm/tegra/sor.c | 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c index 334c4d7d238b..416a2862a84b 100644 --- a/drivers/gpu/drm/tegra/hdmi.c +++ b/drivers/gpu/drm/tegra/hdmi.c @@ -1425,9 +1425,10 @@ static int tegra_hdmi_init(struct host1x_client *client) hdmi->output.dev = client->dev; - drm_connector_init(drm, >output.connector, - _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, >output.connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->output.ddc); drm_connector_helper_add(>output.connector, _hdmi_connector_helper_funcs); hdmi->output.connector.dpms = DRM_MODE_DPMS_OFF; diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index 4ffe3794e6d3..3a69e387c62d 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -2832,9 +2832,10 @@ static int tegra_sor_init(struct host1x_client *client) sor->output.dev = sor->dev; - drm_connector_init(drm, >output.connector, - _sor_connector_funcs, - connector); + drm_connector_init_with_ddc(drm, >output.connector, + _sor_connector_funcs, + connector, + sor->output.ddc); drm_connector_helper_add(>output.connector, _sor_connector_helper_funcs); sor->output.connector.dpms = DRM_MODE_DPMS_OFF; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 08/24] drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index ce91b61364eb..f419765b7cc0 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1299,9 +1299,10 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge
*bridge)
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
int ret;
- ret = drm_connector_init(bridge->encoder->dev, >conn,
-_hdmi_connector_funcs,
-DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(bridge->encoder->dev, >conn,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->ddc_adpt);
if (ret) {
dev_err(hdmi->dev, "Failed to initialize connector: %d\n", ret);
return ret;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 06/24] drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c index 07b4cb877d82..1f03262b8a52 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c @@ -450,8 +450,10 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi) connector = _connector->base; - drm_connector_init(hdmi->dev, connector, _connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(hdmi->dev, connector, + _connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->i2c); drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 05/24] drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/rockchip/inno_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c index ed344a795b4d..e5864e823020 100644 --- a/drivers/gpu/drm/rockchip/inno_hdmi.c +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c @@ -624,8 +624,10 @@ static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi) drm_connector_helper_add(>connector, _hdmi_connector_helper_funcs); - drm_connector_init(drm, >connector, _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, >connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc); drm_connector_attach_encoder(>connector, encoder); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 07/24] drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index b2df76addc75..eb8071a4d6d0 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -640,9 +640,10 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
drm_connector_helper_add(>connector,
_hdmi_connector_helper_funcs);
- ret = drm_connector_init(drm, >connector,
-_hdmi_connector_funcs,
-DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(drm, >connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->ddc_i2c);
if (ret) {
dev_err(dev,
"Couldn't initialise the HDMI connector\n");
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 04/24] drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c index 85fc5f01f761..e874f5fdeec4 100644 --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c @@ -564,9 +564,10 @@ rk3066_hdmi_register(struct drm_device *drm, struct rk3066_hdmi *hdmi) drm_connector_helper_add(>connector, _hdmi_connector_helper_funcs); - drm_connector_init(drm, >connector, - _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, >connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc); drm_connector_attach_encoder(>connector, encoder); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 03/24] drm/exynos: Provide ddc symlink in connector's sysfs
Switch to using the ddc provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bc1565f1822a..d4a9c9e17436 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -940,8 +940,10 @@ static int hdmi_create_connector(struct drm_encoder
*encoder)
connector->interlace_allowed = true;
connector->polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(hdata->drm_dev, connector,
- _connector_funcs, DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(hdata->drm_dev, connector,
+ _connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdata->ddc_adpt);
if (ret) {
DRM_DEV_ERROR(hdata->dev,
"Failed to initialize connector with drm\n");
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 02/24] drm: Add drm_connector_init() variant with ddc
Allow passing ddc adapter pointer to the init function. Even if
drm_connector_init() sometime in the future decides to e.g. memset() all
connector fields to zeros, the newly added function ensures that at its
completion the ddc member of connector is correctly set.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_connector.c | 35 +
include/drm/drm_connector.h | 7 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index cbb548b3708f..d49e19f3de3a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -297,6 +297,41 @@ int drm_connector_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_connector_init);
+/**
+ * drm_connector_init_with_ddc - Init a preallocated connector
+ * @dev: DRM device
+ * @connector: the connector to init
+ * @funcs: callbacks for this connector
+ * @connector_type: user visible type of the connector
+ * @ddc: pointer to the associated ddc adapter
+ *
+ * Initialises a preallocated connector. Connectors should be
+ * subclassed as part of driver connector objects.
+ *
+ * Ensures that the ddc field of the connector is correctly set.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_connector_init_with_ddc(struct drm_device *dev,
+ struct drm_connector *connector,
+ const struct drm_connector_funcs *funcs,
+ int connector_type,
+ struct i2c_adapter *ddc)
+{
+ int ret;
+
+ ret = drm_connector_init(dev, connector, funcs, connector_type);
+ if (ret)
+ return ret;
+
+ /* provide ddc symlink in sysfs */
+ connector->ddc = ddc;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_connector_init_with_ddc);
+
/**
* drm_connector_attach_edid_property - attach edid property.
* @connector: the connector
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 33a6fff85fdb..fc5d08438333 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1319,6 +1319,8 @@ struct drm_connector {
* this field, then an appropriate symbolic link is created in connector
* sysfs directory to make it easy for the user to tell which i2c
* adapter is for a particular display.
+*
+* The field should be set by calling drm_connector_init_with_ddc().
*/
struct i2c_adapter *ddc;
@@ -1410,6 +1412,11 @@ int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
const struct drm_connector_funcs *funcs,
int connector_type);
+int drm_connector_init_with_ddc(struct drm_device *dev,
+ struct drm_connector *connector,
+ const struct drm_connector_funcs *funcs,
+ int connector_type,
+ struct i2c_adapter *ddc);
void drm_connector_attach_edid_property(struct drm_connector *connector);
int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 01/24] drm: Add ddc link in sysfs created by drm_connector
Add generic code which creates symbolic links in sysfs, pointing to ddc
interface used by a particular video output. For example:
ls -l /sys/class/drm/card0-HDMI-A-1/ddc
lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
-> ../../../../soc/1388.i2c/i2c-2
This makes it easy for user to associate a display with its ddc adapter
and use e.g. ddcutil to control the chosen monitor.
This patch adds an i2c_adapter pointer to struct drm_connector. Particular
drivers can then use it instead of using their own private instance. If a
connector contains a ddc, then create a symbolic link in sysfs.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Daniel Vetter
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/drm_sysfs.c | 8
include/drm/drm_connector.h | 11 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ad10810bc972..e962a9d45f7e 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -294,6 +295,9 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(dev);
+ if (connector->ddc)
+ return sysfs_create_link(>kdev->kobj,
+>ddc->dev.kobj, "ddc");
return 0;
}
@@ -301,6 +305,10 @@ void drm_sysfs_connector_remove(struct drm_connector
*connector)
{
if (!connector->kdev)
return;
+
+ if (connector->ddc)
+ sysfs_remove_link(>kdev->kobj, "ddc");
+
DRM_DEBUG("removing \"%s\" from sysfs\n",
connector->name);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4c30d751487a..33a6fff85fdb 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -41,6 +41,7 @@ struct drm_property;
struct drm_property_blob;
struct drm_printer;
struct edid;
+struct i2c_adapter;
enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
@@ -1311,6 +1312,16 @@ struct drm_connector {
* [0]: progressive, [1]: interlaced
*/
int audio_latency[2];
+
+ /**
+* @ddc: associated ddc adapter.
+* A connector usually has its associated ddc adapter. If a driver uses
+* this field, then an appropriate symbolic link is created in connector
+* sysfs directory to make it easy for the user to tell which i2c
+* adapter is for a particular display.
+*/
+ struct i2c_adapter *ddc;
+
/**
* @null_edid_counter: track sinks that give us all zeros for the EDID.
* Needed to workaround some HW bugs where we get all 0s
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 00/24] Associate ddc adapters with connectors
It is difficult for a user to know which of the i2c adapters is for which drm connector. This series addresses this problem. The idea is to have a symbolic link in connector's sysfs directory, e.g.: ls -l /sys/class/drm/card0-HDMI-A-1/ddc lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \ -> ../../../../soc/1388.i2c/i2c-2 The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run ddcutil: ddcutil -b 2 getvcp 0x10 VCP code 0x10 (Brightness): current value =90, max value = 100 The first patch in the series adds struct i2c_adapter pointer to struct drm_connector. If the field is used by a particular driver, then an appropriate symbolic link is created by the generic code, which is also added by this patch. Patch 2 adds a new variant of drm_connector_init(), see the changelog below. Patches 3..24 are examples of how to convert a driver to this new scheme. v1..v2: - used fixed name "ddc" for the symbolic link in order to make it easy for userspace to find the i2c adapter v2..v3: - converted as many drivers as possible. v3..v4: - added Reviewed-by for patch 01/23 - moved "ddc" field assignment to before drm_connector_init() is called in msm, vc4, sti, mgag200, ast, amdgpu, radeon - simplified the code in amdgpu and radeon at the expense of some lines exceeding 80 characters as per Alex Deucher's suggestion - added i915 v4..v5: - changed "include " to "struct i2c_adapter;" in drm_connector.h, consequently, added "include " in drm_sysfs.c. - added "drm_connector_init_with_ddc()" variant to ensure that the ddc field of drm_connector is preserved accross its invocation - accordingly changed invocations of drm_connector_init() in the touched drivers to use the new variant v5..v6: - improved subject line of patch 1 - added kernel-doc for drm_connector_init_with_ddc() - improved kernel-doc for the ddc field of struct drm_connector - added Reviewed-by in patches 17 and 18 - added Acked-by in patch 2 - made the ownership of ddc i2c_adapter explicit in all patches, this made the affected patches much simpler @Benjamin @Shawn There were your Acked-by or Reviewed-by for some patches in v4, but now that the patches use the newly added function I'm not sure I can still include those tags without you actually confirming. Can I? Or can you please re-review? TODO: nouveau, gma500, omapdrm, panel-simple - if applicable. Other drivers are either already converted or don't mention neither "ddc" nor "i2c_adapter". Andrzej Pietrasiewicz (24): drm: Add ddc link in sysfs created by drm_connector drm: Add drm_connector_init() variant with ddc drm/exynos: Provide ddc symlink in connector's sysfs drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory drm/tegra: Provide ddc symlink in output connector sysfs directory drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs drm/imx: imx-tve: Provide ddc symlink in connector's sysfs drm/vc4: Provide ddc symlink in connector sysfs directory drm: zte: Provide ddc symlink in hdmi connector sysfs directory drm: zte: Provide ddc symlink in vga connector sysfs directory drm/tilcdc: Provide ddc symlink in connector sysfs directory drm: sti: Provide ddc symlink in hdmi connector sysfs directory drm/mgag200: Provide ddc symlink in connector sysfs directory drm/ast: Provide ddc symlink in connector sysfs directory drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory drm/amdgpu: Provide ddc symlink in connector sysfs directory drm/radeon: Provide ddc symlink in connector sysfs directory drm/i915: Provide ddc symlink in hdmi connector sysfs directory .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 96 drivers/gpu/drm/ast/ast_mode.c| 13 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +- drivers/gpu/drm/bridge/ti-tfp410.c| 6 +- drivers/gpu/drm/drm_connector.c | 35 + drivers/gpu/drm/drm_sysfs.c | 8 + drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- drivers/gpu/drm/imx/imx-ldb.c | 7 +- drivers/gpu/drm/imx/imx-tve.c | 6 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +- drivers/gpu/drm/mgag200/mgag200_mode.c| 13 +- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +- drivers/gpu/drm/radeon/radeon_connectors.c| 142 +-
Re: [Intel-gfx] [PATCH] drm/i915/uc: Don't fail on HuC firmware failure
Quoting Michal Wajdeczko (2019-07-26 18:12:40) > HuC is usually not a critical component, so we can safely ignore > firmware load or authentication failures unless HuC was explicitly > requested by the user. How soon before on-demand loading? :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/uc: Don't fail on HuC firmware failure
HuC is usually not a critical component, so we can safely ignore
firmware load or authentication failures unless HuC was explicitly
requested by the user.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 8
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6 ++
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 5b9b20d1cb6d..99419c5c0ad3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -472,7 +472,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
if (intel_uc_is_using_huc(uc)) {
ret = intel_huc_fw_upload(huc);
- if (ret)
+ if (ret && intel_uc_fw_is_overridden(>fw))
goto err_out;
}
@@ -494,9 +494,9 @@ int intel_uc_init_hw(struct intel_uc *uc)
if (ret)
goto err_log_capture;
- if (intel_uc_is_using_huc(uc)) {
+ if (intel_uc_is_using_huc(uc) && intel_uc_fw_is_loaded(>fw)) {
ret = intel_huc_auth(huc);
- if (ret)
+ if (ret && intel_uc_fw_is_overridden(>fw))
goto err_communication;
}
@@ -515,7 +515,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
dev_info(i915->drm.dev, "GuC submission %s\n",
enableddisabled(intel_uc_is_using_guc_submission(uc)));
dev_info(i915->drm.dev, "HuC %s\n",
-enableddisabled(intel_uc_is_using_huc(uc)));
+enableddisabled(intel_huc_is_authenticated(huc)));
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..1e9ae38e5b10 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -146,7 +146,8 @@ __uc_fw_override(struct intel_uc_fw *uc_fw)
break;
}
- return uc_fw->path;
+ uc_fw->user_overridden = uc_fw->path;
+ return uc_fw->user_overridden;
}
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index eddbb237fabe..898d43eff634 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -58,6 +58,7 @@ enum intel_uc_fw_type {
*/
struct intel_uc_fw {
const char *path;
+ bool user_overridden;
size_t size;
struct drm_i915_gem_object *obj;
enum intel_uc_fw_status status;
@@ -144,6 +145,11 @@ static inline bool intel_uc_fw_supported(struct
intel_uc_fw *uc_fw)
return __intel_uc_fw_status(uc_fw) != INTEL_UC_FIRMWARE_NOT_SUPPORTED;
}
+static inline bool intel_uc_fw_is_overridden(const struct intel_uc_fw *uc_fw)
+{
+ return uc_fw->user_overridden;
+}
+
static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)
{
if (intel_uc_fw_is_loaded(uc_fw))
--
2.19.2
___
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/3] drm/i915/uc: Remove redundant header_offset/size definitions
== Series Details ==
Series: series starting with [1/3] drm/i915/uc: Remove redundant
header_offset/size definitions
URL : https://patchwork.freedesktop.org/series/64322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6560 -> Patchwork_13771
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/
Known issues
Here are the changes found in Patchwork_13771 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: [PASS][1] -> [DMESG-WARN][2] ([fdo#105128] /
[fdo#107139])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_pm_rpm@module-reload:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-icl-u3/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-icl-u3/igt@i915_pm_...@module-reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-dsi: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* {igt@gem_ctx_switch@legacy-render}:
- {fi-icl-guc}: [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#109485]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][13] ([fdo#103167]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6560/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (54 -> 47)
--
Additional (2): fi-cfl-8109u fi-bsw-n3050
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6560 -> Patchwork_13771
CI-20190529: 20190529
CI_DRM_6560: 63b0088b62ff5e315330f3ed64ebde152e296fbf @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13771: fdf075e722b36ab2c2b4f1fe47fc1021e955075c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fdf075e722b3 drm/i915/uc: Remove redundant RSA offset definition
436777ce4a3b drm/i915/uc: Remove redundant ucode offset definition
7a6a878814e8 drm/i915/uc: Remove redundant header_offset/size definitions
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13771/
___
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 [1/3] drm/i915/uc: Remove redundant header_offset/size definitions
== Series Details == Series: series starting with [1/3] drm/i915/uc: Remove redundant header_offset/size definitions URL : https://patchwork.freedesktop.org/series/64322/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/uc: Remove redundant header_offset/size definitions Okay! Commit: drm/i915/uc: Remove redundant ucode offset definition Okay! Commit: drm/i915/uc: Remove redundant RSA offset definition -O:drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:514:20: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:514:20: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:513:20: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:513:20: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/uc: Remove redundant ucode offset definition
According to Firmware layout definition, uCode is located right
after CSS header, so ucode offset is always same as header size.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 -
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 66bda0c514a3..05079c59ae04 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -229,7 +229,6 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
}
/* Firmware blob always starts with the header, then uCode */
- uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
/* now RSA */
@@ -239,7 +238,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
err = -ENOEXEC;
goto fail;
}
- uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
+ uc_fw->rsa_offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
@@ -382,7 +381,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->ucode_offset + uc_fw->ucode_size);
+ sizeof(struct uc_css_header) + uc_fw->ucode_size);
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -536,8 +535,7 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\tuCode: offset %u, size %u\n",
- uc_fw->ucode_offset, uc_fw->ucode_size);
+ drm_printf(p, "\tuCode: %u bytes\n", uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
uc_fw->rsa_offset, uc_fw->rsa_size);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index a8048f91f0da..6a04bc6d419f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -77,7 +77,6 @@ struct intel_uc_fw {
u32 rsa_size;
u32 rsa_offset;
u32 ucode_size;
- u32 ucode_offset;
};
static inline
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/uc: Remove redundant header_offset/size definitions
According to Firmware layout definition, CSS header is located
in front of the firmware blob, so header offset is always 0.
Similarly, size of the CSS header is constant and is 128.
While here, move type/status enums up and keep them together.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 2 ++
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5fbdd17a864b..66bda0c514a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,21 +218,18 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
css = (struct uc_css_header *)fw->data;
- /* Firmware bits always start from header */
- uc_fw->header_offset = 0;
- uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) *
-sizeof(u32);
-
- if (uc_fw->header_size != sizeof(struct uc_css_header)) {
+ /* Check integrity of size values inside CSS header */
+ size = (css->header_size_dw - css->key_size_dw - css->modulus_size_dw -
+ css->exponent_size_dw) * sizeof(u32);
+ if (size != sizeof(struct uc_css_header)) {
DRM_WARN("%s: Mismatched firmware header definition\n",
intel_uc_fw_type_repr(uc_fw->type));
err = -ENOEXEC;
goto fail;
}
- /* then, uCode */
- uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
+ /* Firmware blob always starts with the header, then uCode */
+ uc_fw->ucode_offset = sizeof(struct uc_css_header);
uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
/* now RSA */
@@ -246,7 +243,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
+ size = sizeof(struct uc_css_header) + uc_fw->ucode_size +
uc_fw->rsa_size;
if (fw->size < size) {
DRM_WARN("%s: Truncated firmware (%zu, expected %zu)\n",
intel_uc_fw_type_repr(uc_fw->type), fw->size, size);
@@ -371,7 +368,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
/* Set the source address for the uCode */
- offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt) + uc_fw->header_offset;
+ offset = uc_fw_ggtt_offset(uc_fw, gt->ggtt);
GEM_BUG_ON(upper_32_bits(offset) & 0x);
intel_uncore_write_fw(uncore, DMA_ADDR_0_LOW, lower_32_bits(offset));
intel_uncore_write_fw(uncore, DMA_ADDR_0_HIGH, upper_32_bits(offset));
@@ -385,7 +382,7 @@ static int uc_fw_xfer(struct intel_uc_fw *uc_fw, struct
intel_gt *gt,
* via DMA, excluding any other components
*/
intel_uncore_write_fw(uncore, DMA_COPY_SIZE,
- uc_fw->header_size + uc_fw->ucode_size);
+ uc_fw->ucode_offset + uc_fw->ucode_size);
/* Start the DMA */
intel_uncore_write_fw(uncore, DMA_CTRL,
@@ -539,8 +536,6 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
drm_printf(p, "\tversion: wanted %u.%u, found %u.%u\n",
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
- drm_printf(p, "\theader: offset %u, size %u\n",
- uc_fw->header_offset, uc_fw->header_size);
drm_printf(p, "\tuCode: offset %u, size %u\n",
uc_fw->ucode_offset, uc_fw->ucode_size);
drm_printf(p, "\tRSA: offset %u, size %u\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index eddbb237fabe..a8048f91f0da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -26,6 +26,7 @@
#define _INTEL_UC_FW_H_
#include
+#include "intel_uc_fw_abi.h"
#include "i915_gem.h"
struct drm_printer;
@@ -57,10 +58,11 @@ enum intel_uc_fw_type {
* of fetching, caching, and loading the firmware image into the uC.
*/
struct intel_uc_fw {
+ enum intel_uc_fw_type type;
+ enum intel_uc_fw_status status;
const char *path;
size_t size;
struct drm_i915_gem_object *obj;
- enum intel_uc_fw_status status;
/*
* The firmware build process will generate a version
[Intel-gfx] [PATCH 3/3] drm/i915/uc: Remove redundant RSA offset definition
According to Firmware layout definition, RSA signature is located
after CSS header and uCode so actual RSA offset in the blob can be
easily calculated when needed (and we need it only once).
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 -
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 05079c59ae04..b0f2852dec41 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -238,7 +238,6 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
err = -ENOEXEC;
goto fail;
}
- uc_fw->rsa_offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
/* At least, it should have header, uCode and RSA. Size of all three. */
@@ -512,11 +511,11 @@ size_t intel_uc_fw_copy_rsa(struct intel_uc_fw *uc_fw,
void *dst, u32 max_len)
{
struct sg_table *pages = uc_fw->obj->mm.pages;
u32 size = min_t(u32, uc_fw->rsa_size, max_len);
+ u32 offset = sizeof(struct uc_css_header) + uc_fw->ucode_size;
GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw));
- return sg_pcopy_to_buffer(pages->sgl, pages->nents,
- dst, size, uc_fw->rsa_offset);
+ return sg_pcopy_to_buffer(pages->sgl, pages->nents, dst, size, offset);
}
/**
@@ -536,6 +535,5 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
struct drm_printer *p)
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted,
uc_fw->major_ver_found, uc_fw->minor_ver_found);
drm_printf(p, "\tuCode: %u bytes\n", uc_fw->ucode_size);
- drm_printf(p, "\tRSA: offset %u, size %u\n",
- uc_fw->rsa_offset, uc_fw->rsa_size);
+ drm_printf(p, "\tRSA: %u bytes\n", uc_fw->rsa_size);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index 6a04bc6d419f..c2ab2803715d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -75,7 +75,6 @@ struct intel_uc_fw {
u16 minor_ver_found;
u32 rsa_size;
- u32 rsa_offset;
u32 ucode_size;
};
--
2.19.2
___
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/uc: Don't sanitize guc_log_level modparam
== Series Details == Series: drm/i915/uc: Don't sanitize guc_log_level modparam URL : https://patchwork.freedesktop.org/series/64264/ State : success == Summary == CI Bug Log - changes from CI_DRM_6553_full -> Patchwork_13757_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13757_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl4/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-skl2/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb4/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-b: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb2/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-b.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-iclb7/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-b.html * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#106509] / [fdo#107409]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-glk3/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-glk6/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_cursor_legacy@cursor-vs-flip-legacy: - shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#103355]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-iclb3/igt@kms_psr@psr2_sprite_plane_move.html * igt@tools_test@tools_test: - shard-apl: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-apl6/igt@tools_test@tools_test.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-apl7/igt@tools_test@tools_test.html Possible fixes * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [SKIP][19] ([fdo#109271]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-kbl3/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_suspend@sysfs-reader: - shard-skl: [INCOMPLETE][21] ([fdo#104108]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl6/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-skl10/igt@i915_susp...@sysfs-reader.html - shard-apl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-apl5/igt@i915_susp...@sysfs-reader.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13757/shard-apl1/igt@i915_susp...@sysfs-reader.html *
Re: [Intel-gfx] [PATCH] drm/i915: Replace hangcheck by heartbeats
> -Original Message- > From: Chris Wilson > Sent: Thursday, July 25, 2019 4:52 PM > To: Bloomfield, Jon ; intel- > g...@lists.freedesktop.org > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > Quoting Bloomfield, Jon (2019-07-26 00:41:49) > > > -Original Message- > > > From: Chris Wilson > > > Sent: Thursday, July 25, 2019 4:28 PM > > > To: Bloomfield, Jon ; intel- > > > g...@lists.freedesktop.org > > > Cc: Joonas Lahtinen ; Ursulin, Tvrtko > > > > > > Subject: RE: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > Quoting Bloomfield, Jon (2019-07-26 00:21:47) > > > > > -Original Message- > > > > > From: Chris Wilson > > > > > Sent: Thursday, July 25, 2019 4:17 PM > > > > > To: intel-gfx@lists.freedesktop.org > > > > > Cc: Chris Wilson ; Joonas Lahtinen > > > > > ; Ursulin, Tvrtko > > > ; > > > > > Bloomfield, Jon > > > > > Subject: [PATCH] drm/i915: Replace hangcheck by heartbeats > > > > > > > > > > Replace sampling the engine state every so often with a periodic > > > > > heartbeat request to measure the health of an engine. This is coupled > > > > > with the forced-preemption to allow long running requests to survive > > > > > so > > > > > long as they do not block other users. > > > > > > > > Can you explain why we would need this at all if we have forced- > preemption? > > > > Forced preemption guarantees that an engine cannot interfere with the > > > timely > > > > execution of other contexts. If it hangs, but nothing else wants to use > > > > the > > > engine > > > > then do we care? > > > > > > We may not have something else waiting to use the engine, but we may > > > have users waiting for the response where we need to detect the GPU hang > > > to prevent an infinite wait / stuck processes and infinite power drain. > > > > I'm not sure I buy that logic. Being able to pre-empt doesn't imply it will > > ever end. As written a context can sit forever, apparently making progress > > but never actually returning a response to the user. If the user isn't happy > > with the progress they will kill the process. So we haven't solved the > > user responsiveness here. All we've done is eliminated the potential to > > run one class of otherwise valid workload. > > Indeed, one of the conditions I have in mind for endless is rlimits. The > user + admin should be able to specify that a context not exceed so much > runtime, and if we ever get a scheduler, we can write that as a budget > (along with deadlines). Agreed, an rlimit solution would work better, if there was an option for 'unlimited'. The specific reason I poked was to try to find a solution to the long-running compute workload scenarios. In those cases there is no fwd progress on the ring/BB, but the kernel will still be making fwd progress. The challenge here is that it's not easy for compiler to guarantee to fold a user kernel into something that fit any specific time boundary. It depends on the user kernel structure. A thread could take several seconds (or possibly minutes) to complete. That's not automatically bad. We need a solution to that specific problem, and while I agree that it would be nice to detect errant contexts and kick them out, that relies on an accurate classification of 'errant' and 'safe'. The response needs to be proportional to the problem. > > > Same argument goes for power. Just because it yields when other contexts > > want to run doesn't mean it won't consume lots of power indefinitely. I can > > equally write a CPU program to burn lots of power, forever, and it won't get > > nuked. > > I agree, and continue to dislike letting hogs have free reign. But even with this change a BB hog can still have free reign to consume power, as long as it pauses it's unsavoury habit whenever the heartbeat request comes snooping on the engine. What we're effectively saying with this is that it's ok for a context to spin in a BB, but not ok to spin in an EU kernel. Why would we differentiate when both can burn the same power? So we haven't solved this problem, but continue to victimize legitimate code. > > > TDR made sense when it was the only way to ensure contexts could always > > make forward progress. But force-preemption does everything we need to > > ensure that as far as I can tell. > > No. Force-preemption (preemption-by-reset) is arbitrarily shooting mostly > innocent contexts, that had the misfortune to not yield quick enough. It > is data loss and a dos (given enough concentration could probably be used > by third parties to shoot down completely innocent clients), and so > should be used as a last resort shotgun and not be confused as being a > scalpel. And given our history and current situation, resets are still a > liability. Doesn't the heartbeat rely on forced-preemption to send the bailiffs in when the context refuses to go? If so, that actually makes it more likely to evict an innocent context.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
== Series Details == Series: drm/i915: Remove redundant user_access_end() from __copy_from_user() error path URL : https://patchwork.freedesktop.org/series/64262/ State : success == Summary == CI Bug Log - changes from CI_DRM_6553_full -> Patchwork_13756_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13756_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb4/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-apl5/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103167]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [fdo#110403]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl2/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-skl9/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-kbl: [DMESG-WARN][17] ([fdo#108566]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-kbl2/igt@gem_...@in-flight-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-kbl4/igt@gem_...@in-flight-suspend.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [SKIP][19] ([fdo#109271]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-kbl3/igt@i915_pm_rc6_reside...@rc6-accuracy.html - shard-snb: [SKIP][21] ([fdo#109271]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-snb4/igt@i915_pm_rc6_reside...@rc6-accuracy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-snb2/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_suspend@sysfs-reader: - shard-skl: [INCOMPLETE][23] ([fdo#104108]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6553/shard-skl6/igt@i915_susp...@sysfs-reader.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13756/shard-skl9/igt@i915_susp...@sysfs-reader.html - shard-apl: [DMESG-WARN][25]
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915/perf: Initialise err to 0 before looping over ce->engines (rev2)
== Series Details ==
Series: series starting with [v2] drm/i915/perf: Initialise err to 0 before
looping over ce->engines (rev2)
URL : https://patchwork.freedesktop.org/series/64309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6559 -> Patchwork_13770
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/
Known issues
Here are the changes found in Patchwork_13770 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-icl-dsi: [PASS][1] -> [DMESG-FAIL][2] ([fdo#44])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278])
+2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278])
+2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][7] -> [FAIL][8] ([fdo#103167])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][9] ([fdo#108511]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][11] ([fdo#103167]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#44]: https://bugs.freedesktop.org/show_bug.cgi?id=44
Participating hosts (55 -> 46)
--
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6559 -> Patchwork_13770
CI-20190529: 20190529
CI_DRM_6559: f75e57f28719a050116a71c2bbd6ce6e115d56cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13770: 4e6ce01043fd538cc446d1d9e70c95ae8869e476 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4e6ce01043fd drm/i915/selftests: Careful not to flush hang_fini on error setups
69af76182cf8 drm/i915/perf: Initialise err to 0 before looping over ce->engines
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13770/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/tgl: Implement Wa_1604555607
Quoting Tvrtko Ursulin (2019-07-26 14:34:56) > > On 26/07/2019 14:20, Chris Wilson wrote: > > We can do rmw inside ctx_wa if we have to thanks to MI_MATH. Should we > > start preparing for that nightmare? :) > > When you say preparing it makes it sounds complicated so I want to say > no. But sure, if you have extra time go for it. The quick-and-dirty solution is to write the assembly routines by hand, but Lionel mentioned that mesa might have a dsl we could use to create MI_MATH routines. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/userptr: Beware recursive lock_page()
On 17/07/2019 21:09, Tvrtko Ursulin wrote: On 17/07/2019 15:06, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-07-17 14:46:15) On 17/07/2019 14:35, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-07-17 14:23:55) On 17/07/2019 14:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-07-17 14:09:00) On 16/07/2019 16:37, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-07-16 16:25:22) On 16/07/2019 13:49, Chris Wilson wrote: Following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. So if trylock randomly fail we get data corruption in whatever data set application is working on, which is what the original patch was trying to avoid? Are we able to detect the backing store type so at least we don't risk skipping set_page_dirty with anonymous/shmemfs? page->mapping??? Would page->mapping work? What is it telling us? It basically tells us if there is a fs around; anything that is the most basic of malloc (even tmpfs/shmemfs has page->mapping). Normal malloc so anonymous pages? Or you meant everything _apart_ from the most basic malloc? Aye missed the not. We still have the issue that if there is a mapping we should be taking the lock, and we may have both a mapping and be inside try_to_unmap(). Is this a problem? On a path with mappings we trylock and so solve the set_dirty_locked and recursive deadlock issues, and with no mappings with always dirty the page and avoid data corruption. The problem as I see it is !page->mapping are likely an insignificant minority of userptr; as I think even memfd are essentially shmemfs (or hugetlbfs) and so have mappings. Better then nothing, no? If easy to do.. Actually, I erring on the opposite side. Peeking at mm/ internals does not bode confidence and feels indefensible. I'd much rather throw my hands up and say "this is the best we can do with the API provided, please tell us what we should have done." To which the answer is probably to not have used gup in the first place :| """ /* * set_page_dirty() is racy if the caller has no reference against * page->mapping->host, and if the page is unlocked. This is because another * CPU could truncate the page off the mapping and then free the mapping. * * Usually, the page _is_ locked, or the caller is a user-space process which * holds a reference on the inode by having an open file. * * In other cases, the page should be locked before running set_page_dirty(). */ int set_page_dirty_lock(struct page *page) """ Could we hold a reference to page->mapping->host while having pages and then would be okay to call plain set_page_dirty? We would then be hitting the warnings in ext4 for unlocked pages again. Ah true.. Essentially the argument is whether or not that warn is valid, to which I think requires inner knowledge of vfs + ext4. To hold a reference on the host would require us tracking page->mapping (reasonable since we already hooked into mmu and so will get an invalidate + fresh gup on any changes), plus iterating over all to acquire the extra reference if applicable -- and I have no idea what the side-effects of that would be. Could well be positive side-effects. Just feels like wandering even further off the beaten path without a map. Good news hmm is just around the corner (which will probably prohibit this use-case) :| ... can we reach out to someone more knowledgeable in mm matters to recommend us what to do? Regards, Tvrtko Just a reminder to not let this slip. We run into userptr bugs in CI quite regularly. Thanks, -Lionel ___ 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/gt: Add to timeline requires the timeline mutex
On 25/07/2019 14:14, Chris Wilson wrote:
Modifying a remote context requires careful serialisation with requests
on that context, and that serialisation requires us to take their
timeline->mutex. Make it so.
Note that while struct_mutex rules, we can't create more than one
request in parallel, but that age is soon coming to an end.
v2: Though it doesn't affect the current users, contexts may share
timelines so check if we already hold the right mutex.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 9292b6ca5e9c..d64b45f7ec6d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -254,10 +254,18 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
/* Only suitable for use in remotely modifying this context */
GEM_BUG_ON(rq->hw_context == ce);
- /* Queue this switch after all other activity by this context. */
- err = i915_active_request_set(>last_request, rq);
- if (err)
- return err;
+ if (rq->timeline != tl) { /* beware timeline sharing */
+ err = mutex_lock_interruptible_nested(>mutex,
+ SINGLE_DEPTH_NESTING);
+ if (err)
+ return err;
+
+ /* Queue this switch after current activity by this context. */
+ err = i915_active_request_set(>last_request, rq);
+ if (err)
+ goto unlock;
+ }
+ lockdep_assert_held(>mutex);
/*
* Guarantee context image and the timeline remains pinned until the
@@ -267,7 +275,12 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
* words transfer the pinned ce object to tracked active request.
*/
GEM_BUG_ON(i915_active_is_idle(>active));
- return i915_active_ref(>active, rq->fence.context, rq);
+ err = i915_active_ref(>active, rq->fence.context, rq);
+
+unlock:
+ if (rq->timeline != tl)
+ mutex_unlock(>mutex);
+ return err;
}
struct i915_request *intel_context_create_request(struct intel_context *ce)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/tgl: Implement Wa_1604555607
On 26/07/2019 14:20, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-26 14:15:51)
On 26/07/2019 01:10, Chris Wilson wrote:
Quoting Lucas De Marchi (2019-07-26 01:02:25)
From: Michel Thierry
Implement Wa_1604555607 (set the DS pairing timer to 128 cycles).
FF_MODE2 is part of the register state context, that's why it is
implemented here.
Signed-off-by: Michel Thierry
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a6eb9c6e87ec..3235ef355dfd 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -572,6 +572,13 @@ static void icl_ctx_workarounds_init(struct
intel_engine_cs *engine,
static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
{
+ u32 val;
+
+ /* Wa_1604555607:tgl */
+ val = intel_uncore_read(engine->uncore, FF_MODE2);
+ val &= ~FF_MODE2_TDS_TIMER_MASK;
+ val |= FF_MODE2_TDS_TIMER_128;
+ wa_write_masked_or(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val);
It will do a rmw on application, so you just need
wa_write_masked_or(wal, FF_MODE2,
FF_MODE2_TDS_TIMER_MASK, FF_MODE2_TDS_TIMER_128);
Not with ctx was unfortunately, no rmw there, just lri.
Odd that we read from outside the ctx then, no?
Perhaps. We have to get the default value from somewhere. There is one
like this already, GEN8_L3CNTLREG, from not too long ago.
We can do rmw inside ctx_wa if we have to thanks to MI_MATH. Should we
start preparing for that nightmare? :)
When you say preparing it makes it sounds complicated so I want to say
no. But sure, if you have extra time go for it.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/perf: Initialise err to 0 before looping over ce->engines
== Series Details ==
Series: series starting with [1/2] drm/i915/perf: Initialise err to 0 before
looping over ce->engines
URL : https://patchwork.freedesktop.org/series/64309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6559 -> Patchwork_13769
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/
Known issues
Here are the changes found in Patchwork_13769 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [PASS][1] -> [SKIP][2] ([fdo#109271] / [fdo#109278])
+2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278])
+2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
* igt@kms_chamelium@dp-edid-read:
- fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#109483] / [fdo#109635 ])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#109485])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][9] -> [FAIL][10] ([fdo#103167])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
* igt@vgem_basic@second-client:
- fi-icl-u3: [PASS][11] -> [DMESG-WARN][12] ([fdo#107724])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-u3/igt@vgem_ba...@second-client.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-icl-u3/igt@vgem_ba...@second-client.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][13] ([fdo#108511]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_hangcheck:
- fi-kbl-guc: [INCOMPLETE][15] ([fdo#108744]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][17] ([fdo#103167]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6559/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13769/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#44]: https://bugs.freedesktop.org/show_bug.cgi?id=44
Participating hosts (55 -> 45)
--
Missing(10): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-cfl-8109u fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6559 -> Patchwork_13769
CI-20190529: 20190529
CI_DRM_6559: f75e57f28719a050116a71c2bbd6ce6e115d56cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5113: f8f1bfbd25559e01c59a55635477cb74b326ea0b @
Re: [Intel-gfx] [PATCH 2/3] drm/i915/tgl: Implement Wa_1604555607
Quoting Tvrtko Ursulin (2019-07-26 14:15:51)
>
> On 26/07/2019 01:10, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2019-07-26 01:02:25)
> >> From: Michel Thierry
> >>
> >> Implement Wa_1604555607 (set the DS pairing timer to 128 cycles).
> >> FF_MODE2 is part of the register state context, that's why it is
> >> implemented here.
> >>
> >> Signed-off-by: Michel Thierry
> >> Signed-off-by: Lucas De Marchi
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
> >> drivers/gpu/drm/i915/i915_reg.h | 5 +
> >> 2 files changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> index a6eb9c6e87ec..3235ef355dfd 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> @@ -572,6 +572,13 @@ static void icl_ctx_workarounds_init(struct
> >> intel_engine_cs *engine,
> >> static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
> >> struct i915_wa_list *wal)
> >> {
> >> + u32 val;
> >> +
> >> + /* Wa_1604555607:tgl */
> >> + val = intel_uncore_read(engine->uncore, FF_MODE2);
> >> + val &= ~FF_MODE2_TDS_TIMER_MASK;
> >> + val |= FF_MODE2_TDS_TIMER_128;
> >> + wa_write_masked_or(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val);
> >
> > It will do a rmw on application, so you just need
> > wa_write_masked_or(wal, FF_MODE2,
> > FF_MODE2_TDS_TIMER_MASK, FF_MODE2_TDS_TIMER_128);
>
> Not with ctx was unfortunately, no rmw there, just lri.
Odd that we read from outside the ctx then, no?
We can do rmw inside ctx_wa if we have to thanks to MI_MATH. Should we
start preparing for that nightmare? :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
