[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix setting 10 bit deep color mode (rev3)
== Series Details == Series: drm/i915/icl: Fix setting 10 bit deep color mode (rev3) URL : https://patchwork.freedesktop.org/series/60080/ State : success == Summary == CI Bug Log - changes from CI_DRM_6062_full -> Patchwork_12982_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12982_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109349]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][3] -> [FAIL][4] ([fdo#103184] / [fdo#103232]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-skl7/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-skl10/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [PASS][5] -> [INCOMPLETE][6] ([fdo#103540]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-hsw4/igt@kms_f...@2x-flip-vs-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-hsw2/igt@kms_f...@2x-flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103167] / [fdo#110379]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-skl7/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-skl10/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +11 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-apl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#108341]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-iclb5/igt@kms_psr@no_drrs.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-iclb6/igt@kms_psr@psr2_cursor_render.html * igt@kms_setmode@basic: - shard-apl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/shard-apl6/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/shard-apl2/igt@kms_setm...@basic.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
== Series Details == Series: RFC: x86/smp: use printk_deferred in native_smp_send_reschedule URL : https://patchwork.freedesktop.org/series/60384/ State : success == Summary == CI Bug Log - changes from CI_DRM_6061_full -> Patchwork_12981_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12981_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@readonly-blt: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-apl6/igt@gem_exec_ba...@readonly-blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-apl4/igt@gem_exec_ba...@readonly-blt.html * igt@i915_pm_rpm@i2c: - shard-iclb: [PASS][3] -> [FAIL][4] ([fdo#104097]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-iclb6/igt@i915_pm_...@i2c.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-iclb3/igt@i915_pm_...@i2c.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#103060]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-skl8/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-skl3/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-apl4/igt@kms_frontbuffer_track...@fbc-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-apl3/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103166]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-y.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-iclb2/igt@kms_psr@psr2_basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-iclb1/igt@kms_psr@psr2_basic.html * igt@kms_setmode@basic: - shard-apl: [PASS][15] -> [FAIL][16] ([fdo#99912]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-apl7/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-apl3/igt@kms_setm...@basic.html Possible fixes * igt@gem_eio@reset-stress: - shard-snb: [FAIL][17] ([fdo#109661]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-snb6/igt@gem_...@reset-stress.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-snb5/igt@gem_...@reset-stress.html * igt@gem_workarounds@suspend-resume: - shard-apl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-apl5/igt@gem_workarou...@suspend-resume.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-apl7/igt@gem_workarou...@suspend-resume.html * igt@gem_workarounds@suspend-resume-context: - shard-kbl: [DMESG-WARN][21] ([fdo#103313]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-kbl4/igt@gem_workarou...@suspend-resume-context.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-kbl1/igt@gem_workarou...@suspend-resume-context.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [FAIL][23] ([fdo#103184] / [fdo#103232]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/shard-skl10/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/shard-skl10/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@2x-plain-flip-fb-recreate: - shard-glk: [FAIL][25] ([fdo#100368]) -> [PASS][26] [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP2.2 Phase II (rev9)
== Series Details ==
Series: HDCP2.2 Phase II (rev9)
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6060_full -> Patchwork_12980_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12980_full:
### IGT changes ###
Possible regressions
* {igt@kms_content_protection@lic} (NEW):
- shard-apl: NOTRUN -> [FAIL][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-apl5/igt@kms_content_protect...@lic.html
* {igt@kms_content_protection@srm} (NEW):
- shard-kbl: NOTRUN -> [FAIL][2] +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-kbl4/igt@kms_content_protect...@srm.html
* {igt@kms_content_protection@uevent} (NEW):
- shard-iclb: NOTRUN -> [SKIP][3] +5 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-iclb2/igt@kms_content_protect...@uevent.html
New tests
-
New tests have been introduced between CI_DRM_6060_full and
Patchwork_12980_full:
### New IGT tests (6) ###
* igt@kms_content_protection@content_type_change:
- Statuses : 7 skip(s)
- Exec time: [0.0, 0.01] s
* igt@kms_content_protection@lic:
- Statuses : 2 fail(s) 5 skip(s)
- Exec time: [0.0, 123.79] s
* igt@kms_content_protection@mei_interface:
- Statuses : 6 skip(s)
- Exec time: [0.00, 0.01] s
* igt@kms_content_protection@srm:
- Statuses : 2 fail(s) 5 skip(s)
- Exec time: [0.00, 125.62] s
* igt@kms_content_protection@type1:
- Statuses : 7 skip(s)
- Exec time: [0.0, 0.01] s
* igt@kms_content_protection@uevent:
- Statuses : 1 fail(s) 4 skip(s)
- Exec time: [0.0, 107.77] s
Known issues
Here are the changes found in Patchwork_12980_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_persistent_relocs@forked-faulting-reloc:
- shard-hsw: [PASS][4] -> [INCOMPLETE][5] ([fdo#103540])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-hsw2/igt@gem_persistent_rel...@forked-faulting-reloc.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-hsw2/igt@gem_persistent_rel...@forked-faulting-reloc.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl: [PASS][6] -> [DMESG-WARN][7] ([fdo#108566]) +5
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-apl5/igt@i915_susp...@fence-restore-tiled2untiled.html
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-kbl: [PASS][8] -> [DMESG-WARN][9] ([fdo#103558] /
[fdo#105602] / [fdo#110222])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-kbl4/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-c.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-kbl5/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-c.html
* igt@kms_color@pipe-c-degamma:
- shard-glk: [PASS][10] -> [FAIL][11] ([fdo#104782])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-glk7/igt@kms_co...@pipe-c-degamma.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-glk4/igt@kms_co...@pipe-c-degamma.html
- shard-kbl: [PASS][12] -> [FAIL][13] ([fdo#104782])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-kbl6/igt@kms_co...@pipe-c-degamma.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-kbl6/igt@kms_co...@pipe-c-degamma.html
- shard-skl: [PASS][14] -> [FAIL][15] ([fdo#104782])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-skl2/igt@kms_co...@pipe-c-degamma.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-skl3/igt@kms_co...@pipe-c-degamma.html
- shard-apl: [PASS][16] -> [FAIL][17] ([fdo#104782])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-apl3/igt@kms_co...@pipe-c-degamma.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-apl2/igt@kms_co...@pipe-c-degamma.html
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-kbl: [PASS][18] -> [DMESG-FAIL][19] ([fdo#103232] /
[fdo#103558] / [fdo#105602])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/shard-kbl2/igt@kms_cursor_...@cursor-128x128-suspend.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/shard-kbl5/igt@kms_cursor_...@cursor-128x128-suspend.html
* igt@kms_cursor_edge_walk@pipe-c-64x64-top-edge:
- shard-kbl: [PASS][20] ->
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable Multi-segmented-gamma for ICL (rev2)
== Series Details == Series: Enable Multi-segmented-gamma for ICL (rev2) URL : https://patchwork.freedesktop.org/series/60126/ State : success == Summary == CI Bug Log - changes from CI_DRM_6059_full -> Patchwork_12979_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12979_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_color@pipe-c-gamma: - shard-iclb: [PASS][1] -> [FAIL][2] ([fdo#104782]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb4/igt@kms_co...@pipe-c-gamma.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-iclb1/igt@kms_co...@pipe-c-gamma.html * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-skl5/igt@kms_cursor_...@cursor-64x64-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-skl10/igt@kms_cursor_...@cursor-64x64-suspend.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][5] -> [FAIL][6] ([fdo#105767]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-hsw4/igt@kms_f...@flip-vs-suspend-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-hsw5/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#100368]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-skl4/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-skl4/igt@kms_f...@plain-flip-fb-recreate-interruptible.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_6059/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: [PASS][13] -> [SKIP][14] ([fdo#109271]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-glk9/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-glk8/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html * igt@kms_plane@plane-position-hole-dpms-pipe-b-planes: - shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-snb7/igt@kms_pl...@plane-position-hole-dpms-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-snb4/igt@kms_pl...@plane-position-hole-dpms-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-apl6/igt@kms_setm...@basic.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Don't apply priority boost for resets
== Series Details == Series: drm/i915/execlists: Don't apply priority boost for resets URL : https://patchwork.freedesktop.org/series/60369/ State : success == Summary == CI Bug Log - changes from CI_DRM_6059_full -> Patchwork_12978_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12978_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ringfill@basic-default-hang: - shard-glk: [PASS][1] -> [INCOMPLETE][2] ([fdo#103359] / [k.org#198133]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-glk8/igt@gem_ringf...@basic-default-hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-glk1/igt@gem_ringf...@basic-default-hang.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-apl8/igt@i915_susp...@fence-restore-untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-apl3/igt@i915_susp...@fence-restore-untiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#105363]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-hsw4/igt@kms_f...@flip-vs-suspend-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-hsw5/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: [PASS][11] -> [SKIP][12] ([fdo#109271]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-glk9/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-glk6/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.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_6059/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][19] -> [FAIL][20] ([fdo#99912]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-apl6/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-apl2/igt@kms_setm...@basic.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@reset-stress: - shard-snb: [FAIL][23] ([fdo#109661]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-snb7/igt@gem_...@reset-stress.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/shard-snb2/igt@gem_...@reset-stress.html *
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -84,17 +84,46 @@ void intel_device_info_dump_flags(const struct
intel_device_info *info,
#undef PRINT_FLAG
}
+#define SS_STR_MAX_SIZE (GEN_MAX_SUBSLICE_STRIDE * 2 + 1)
+
+static char *
+subslice_per_slice_str(char *buf, u8 size, const struct
sseu_dev_info *sseu,
+ u8 slice)
+{
+ int i;
+ u8 ss_offset = slice * sseu->ss_stride;
+
+ GEM_BUG_ON(slice >= sseu->max_slices);
+
+ /* Two ASCII character hex plus null terminator */
+ GEM_BUG_ON(size < sseu->ss_stride * 2 + 1);
+
+ memset(buf, 0, size);
+
+ /*
+* Print subslice information in reverse order to match
+* userspace expectations.
+*/
+ for (i = 0; i < sseu->ss_stride; i++)
+ sprintf([i * 2], "%02x",
+ sseu->subslice_mask[ss_offset + sseu->ss_stride
-
+ (i + 1)]);
+
+ return buf;
+}
+
static void sseu_dump(const struct sseu_dev_info *sseu, struct
drm_printer *p)
{
int s;
+ char buf[SS_STR_MAX_SIZE];
drm_printf(p, "slice total: %u, mask=%04x\n",
hweight8(sseu->slice_mask), sseu->slice_mask);
drm_printf(p, "subslice total: %u\n",
intel_sseu_subslice_total(sseu));
for (s = 0; s < sseu->max_slices; s++) {
- drm_printf(p, "slice%d: %u subslices, mask=%04x\n",
+ drm_printf(p, "slice%d: %u subslices, mask=%s\n",
s, intel_sseu_subslices_per_slice(sseu, s),
- sseu->subslice_mask[s]);
+ subslice_per_slice_str(buf, ARRAY_SIZE(buf),
sseu, s));
Now that we have intel_sseu_get_subslices() can't we just print the
return from that instead of using the buffer?
I personally would prefer we keep the stringify function as it gives a
little more flexibility. Do you have a strong preference to move to a
direct printk formatted string?
I do not, it just seemed like duplication since you're not really using
any extra formatting or other flexibility in filling the buffer. This
isn't a lot of code, so maybe we can switch to just using the u32 for
now and add this back if/when we do require the flexibility?
}
drm_printf(p, "EU total: %u\n", sseu->eu_total);
drm_printf(p, "EU per subslice: %u\n", sseu->eu_per_subslice);
@@ -555,6 +570,7 @@ static void haswell_sseu_info_init(struct
drm_i915_private *dev_priv)
struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
u32 fuse1;
int s, ss;
+ u32 subslice_mask;
/*
* There isn't a register to tell us how many slices/subslices.
We
@@ -566,22 +582,18 @@ static void haswell_sseu_info_init(struct
drm_i915_private *dev_priv)
/* fall through */
case 1:
sseu->slice_mask = BIT(0);
- sseu->subslice_mask[0] = BIT(0);
+ subslice_mask = BIT(0);
break;
case 2:
sseu->slice_mask = BIT(0);
- sseu->subslice_mask[0] = BIT(0) | BIT(1);
+ subslice_mask = BIT(0) | BIT(1);
break;
case 3:
sseu->slice_mask = BIT(0) | BIT(1);
- sseu->subslice_mask[0] = BIT(0) | BIT(1);
- sseu->subslice_mask[1] = BIT(0) | BIT(1);
+ subslice_mask = BIT(0) | BIT(1);
break;
}
- sseu->max_slices = hweight8(sseu->slice_mask);
- sseu->max_subslices = hweight8(sseu->subslice_mask[0]);
-
fuse1 = I915_READ(HSW_PAVP_FUSE1);
switch ((fuse1 & HSW_F1_EU_DIS_MASK) >> HSW_F1_EU_DIS_SHIFT) {
default:
@@ -598,9 +610,14 @@ static void haswell_sseu_info_init(struct
drm_i915_private *dev_priv)
sseu->eu_per_subslice = 6;
break;
}
- sseu->max_eus_per_subslice = sseu->eu_per_subslice;
+
+ intel_sseu_set_info(sseu, hweight8(sseu->slice_mask),
+ hweight8(subslice_mask),
+ sseu->eu_per_subslice);
I'd still prefer this to use a local variable so that we always only
set
sseu->eu_per_subslice from within intel_sseu_set_info.
So the reason I kept this is in intel_sseu_set_info we are really just
setting the max_eus_per_subslice, not the eu_per_subslice. Are you
saying you'd also like to move the code that sets eu_per_subslice in
each generation's handler to local variables and/or just passed
directly as an argument to intel_sseu_set_info?
My bad, I confused eu_per_subslice and max_eus_per_subslice as the same
variable. Just ignore this comment :)
Daniele
I.e. should we use intel_sseu_set_info to set most or all of the
members of the intel_sseu structure? Or is it OK to keep the current
implementation of only using this to set default maximums per platform?
-Stuart
Daniele
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
On Tue, 2019-05-07 at 14:16 -0700, Daniele Ceraolo Spurio wrote:
>
>
> > >
> > > > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > > > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > > > @@ -84,17 +84,46 @@ void intel_device_info_dump_flags(const
> > > > struct
> > > > intel_device_info *info,
> > > >#undef PRINT_FLAG
> > > >}
> > > >
> > > > +#define SS_STR_MAX_SIZE (GEN_MAX_SUBSLICE_STRIDE * 2 + 1)
> > > > +
> > > > +static char *
> > > > +subslice_per_slice_str(char *buf, u8 size, const struct
> > > > sseu_dev_info *sseu,
> > > > + u8 slice)
> > > > +{
> > > > + int i;
> > > > + u8 ss_offset = slice * sseu->ss_stride;
> > > > +
> > > > + GEM_BUG_ON(slice >= sseu->max_slices);
> > > > +
> > > > + /* Two ASCII character hex plus null terminator */
> > > > + GEM_BUG_ON(size < sseu->ss_stride * 2 + 1);
> > > > +
> > > > + memset(buf, 0, size);
> > > > +
> > > > + /*
> > > > +* Print subslice information in reverse order to match
> > > > +* userspace expectations.
> > > > +*/
> > > > + for (i = 0; i < sseu->ss_stride; i++)
> > > > + sprintf([i * 2], "%02x",
> > > > + sseu->subslice_mask[ss_offset + sseu-
> > > > >ss_stride
> > > > -
> > > > + (i + 1)]);
> > > > +
> > > > + return buf;
> > > > +}
> > > > +
> > > >static void sseu_dump(const struct sseu_dev_info *sseu,
> > > > struct
> > > > drm_printer *p)
> > > >{
> > > > int s;
> > > > + char buf[SS_STR_MAX_SIZE];
> > > >
> > > > drm_printf(p, "slice total: %u, mask=%04x\n",
> > > >hweight8(sseu->slice_mask), sseu-
> > > > >slice_mask);
> > > > drm_printf(p, "subslice total: %u\n",
> > > > intel_sseu_subslice_total(sseu));
> > > > for (s = 0; s < sseu->max_slices; s++) {
> > > > - drm_printf(p, "slice%d: %u subslices,
> > > > mask=%04x\n",
> > > > + drm_printf(p, "slice%d: %u subslices,
> > > > mask=%s\n",
> > > >s,
> > > > intel_sseu_subslices_per_slice(sseu, s),
> > > > - sseu->subslice_mask[s]);
> > > > + subslice_per_slice_str(buf,
> > > > ARRAY_SIZE(buf),
> > > > sseu, s));
> > >
> > > Now that we have intel_sseu_get_subslices() can't we just print
> > > the
> > > return from that instead of using the buffer?
> >
> > I personally would prefer we keep the stringify function as it
> > gives a
> > little more flexibility. Do you have a strong preference to move to
> > a
> > direct printk formatted string?
> >
>
> I do not, it just seemed like duplication since you're not really
> using
> any extra formatting or other flexibility in filling the buffer.
> This
> isn't a lot of code, so maybe we can switch to just using the u32
> for
> now and add this back if/when we do require the flexibility?
Makes sense and thanks for the feedback. I'll revert back to the printk
format.
>
> > >
> > >
> > > > }
> > > > drm_printf(p, "EU total: %u\n", sseu->eu_total);
> > > > drm_printf(p, "EU per subslice: %u\n", sseu-
> > > > >eu_per_subslice);
> > >
> > >
> > >
> > > > @@ -555,6 +570,7 @@ static void haswell_sseu_info_init(struct
> > > > drm_i915_private *dev_priv)
> > > > struct sseu_dev_info *sseu = _INFO(dev_priv)-
> > > > >sseu;
> > > > u32 fuse1;
> > > > int s, ss;
> > > > + u32 subslice_mask;
> > > >
> > > > /*
> > > > * There isn't a register to tell us how many
> > > > slices/subslices.
> > > > We
> > > > @@ -566,22 +582,18 @@ static void haswell_sseu_info_init(struct
> > > > drm_i915_private *dev_priv)
> > > > /* fall through */
> > > > case 1:
> > > > sseu->slice_mask = BIT(0);
> > > > - sseu->subslice_mask[0] = BIT(0);
> > > > + subslice_mask = BIT(0);
> > > > break;
> > > > case 2:
> > > > sseu->slice_mask = BIT(0);
> > > > - sseu->subslice_mask[0] = BIT(0) | BIT(1);
> > > > + subslice_mask = BIT(0) | BIT(1);
> > > > break;
> > > > case 3:
> > > > sseu->slice_mask = BIT(0) | BIT(1);
> > > > - sseu->subslice_mask[0] = BIT(0) | BIT(1);
> > > > - sseu->subslice_mask[1] = BIT(0) | BIT(1);
> > > > + subslice_mask = BIT(0) | BIT(1);
> > > > break;
> > > > }
> > > >
> > > > - sseu->max_slices = hweight8(sseu->slice_mask);
> > > > - sseu->max_subslices = hweight8(sseu->subslice_mask[0]);
> > > > -
> > > > fuse1 = I915_READ(HSW_PAVP_FUSE1);
> > > > switch ((fuse1 & HSW_F1_EU_DIS_MASK) >>
> > > > HSW_F1_EU_DIS_SHIFT) {
> > > > default:
> > > > @@ -598,9 +610,14 @@ static void haswell_sseu_info_init(struct
> > > > drm_i915_private
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
On Tue, 2019-05-07 at 12:00 -0700, Daniele Ceraolo Spurio wrote:
>
> On 5/3/19 2:30 PM, Stuart Summers wrote:
> > Currently, the subslice_mask runtime parameter is stored as an
> > array of subslices per slice. Expand the subslice mask array to
> > better match what is presented to userspace through the
> > I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
> > then calculated:
> >slice * subslice stride + subslice index / 8
> >
> > v2: fix spacing in set_sseu_info args
> > use set_sseu_info to initialize sseu data when building
> > device status in debugfs
> > rename variables in intel_engine_types.h to avoid checkpatch
> > warnings
> > v3: update headers in intel_sseu.h
> > v4: add const to some sseu_dev_info variables
> > use sseu->eu_stride for EU stride calculations
> > v5: address review comments from Tvrtko and Daniele
> >
> > Cc: Daniele Ceraolo Spurio
> > Cc: Lionel Landwerlin
> > Acked-by: Lionel Landwerlin
> > Signed-off-by: Stuart Summers
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 24 ++-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 ++--
> > drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
> > drivers/gpu/drm/i915/gt/intel_sseu.c | 43 -
> > drivers/gpu/drm/i915/gt/intel_sseu.h | 28 +++-
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 40 ++---
> > drivers/gpu/drm/i915/i915_drv.c | 6 +-
> > drivers/gpu/drm/i915/i915_gpu_error.c| 5 +-
> > drivers/gpu/drm/i915/i915_query.c| 10 +-
> > drivers/gpu/drm/i915/intel_device_info.c | 155 ++--
> > ---
> > 11 files changed, 227 insertions(+), 119 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 5907a9613641..290bda5cc82b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -909,12 +909,30 @@ const char *i915_cache_level_str(struct
> > drm_i915_private *i915, int type)
> > }
> > }
> >
> > +static inline u32
> > +intel_sseu_fls_subslice(const struct sseu_dev_info *sseu, u32
> > slice)
> > +{
> > + u32 subslice;
> > + int i;
> > +
> > + for (i = sseu->ss_stride - 1; i >= 0; i--) {
> > + subslice = fls(sseu->subslice_mask[slice * sseu-
> > >ss_stride +
> > + i]);
> > + if (subslice) {
> > + subslice += i * BITS_PER_BYTE;
> > + break;
> > + }
> > + }
> > +
> > + return subslice;
> > +}
> > +
> > u32 intel_calculate_mcr_s_ss_select(struct drm_i915_private
> > *dev_priv)
> > {
> > const struct sseu_dev_info *sseu = _INFO(dev_priv)-
> > >sseu;
> > u32 mcr_s_ss_select;
> > u32 slice = fls(sseu->slice_mask);
> > - u32 subslice = fls(sseu->subslice_mask[slice]);
> > + u32 subslice = intel_sseu_fls_subslice(sseu, slice);
> >
> > if (IS_GEN(dev_priv, 10))
> > mcr_s_ss_select = GEN8_MCR_SLICE(slice) |
> > @@ -990,6 +1008,7 @@ void intel_engine_get_instdone(struct
> > intel_engine_cs *engine,
> >struct intel_instdone *instdone)
> > {
> > struct drm_i915_private *dev_priv = engine->i915;
> > + const struct sseu_dev_info *sseu = _INFO(dev_priv)-
> > >sseu;
> > struct intel_uncore *uncore = engine->uncore;
> > u32 mmio_base = engine->mmio_base;
> > int slice;
> > @@ -1007,7 +1026,8 @@ void intel_engine_get_instdone(struct
> > intel_engine_cs *engine,
> >
> > instdone->slice_common =
> > intel_uncore_read(uncore, GEN7_SC_INSTDONE);
> > - for_each_instdone_slice_subslice(dev_priv, slice,
> > subslice) {
> > + for_each_instdone_slice_subslice(dev_priv, sseu, slice,
> > +subslice) {
> > instdone->sampler[slice][subslice] =
> > read_subslice_reg(dev_priv, slice,
> > subslice,
> > GEN7_SAMPLER_INSTDONE
> > );
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index c0ab11b12e14..582340b55144 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -535,20 +535,20 @@ intel_engine_needs_breadcrumb_tasklet(const
> > struct intel_engine_cs *engine)
> > return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
> > }
> >
> > -#define instdone_slice_mask(dev_priv__) \
> > - (IS_GEN(dev_priv__, 7) ? \
> > -1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
> > -
> > -#define instdone_subslice_mask(dev_priv__) \
> > - (IS_GEN(dev_priv__, 7) ? \
> > -1 : RUNTIME_INFO(dev_priv__)->sseu.subslice_mask[0])
> > -
> > -#define
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only reschedule the submission tasklet if preemption is possible
== Series Details == Series: drm/i915: Only reschedule the submission tasklet if preemption is possible URL : https://patchwork.freedesktop.org/series/60368/ State : success == Summary == CI Bug Log - changes from CI_DRM_6059_full -> Patchwork_12977_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12977_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [FAIL][2] ([fdo#105957]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-skl9/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-skl8/igt@gem_...@reset-stress.html * igt@gem_exec_basic@readonly-blt: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-apl3/igt@gem_exec_ba...@readonly-blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-apl6/igt@gem_exec_ba...@readonly-blt.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: [PASS][7] -> [SKIP][8] ([fdo#109271]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-glk9/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-glk3/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.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_6059/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-skl3/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_6059/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103166]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_sysfs_edid_timing: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#100047]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-iclb6/igt@kms_sysfs_edid_timing.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-iclb2/igt@kms_sysfs_edid_timing.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-apl4/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-apl4/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-kbl4/igt@perf_...@rc6.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-kbl5/igt@perf_...@rc6.html Possible fixes * igt@gem_eio@reset-stress: - shard-snb: [FAIL][23] ([fdo#109661]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/shard-snb7/igt@gem_...@reset-stress.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/shard-snb5/igt@gem_...@reset-stress.html * igt@gem_exec_suspend@basic-s4-devices: - shard-snb: [FAIL][25] ([fdo#107918]) -> [PASS][26] [25]:
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
On 5/6/2019 8:26 AM, Tejun Heo wrote: > Hello, > > On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote: >> The patch series enables device drivers to use cgroups to control the >> following resources within a GPU (or other accelerator device): >> * control allocation of device memory (reuse of memcg) >> and with future work, we could extend to: >> * track and control share of GPU time (reuse of cpu/cpuacct) >> * apply mask of allowed execution engines (reuse of cpusets) >> >> Instead of introducing a new cgroup subsystem for GPU devices, a new >> framework is proposed to allow devices to register with existing cgroup >> controllers, which creates per-device cgroup_subsys_state within the >> cgroup. This gives device drivers their own private cgroup controls >> (such as memory limits or other parameters) to be applied to device >> resources instead of host system resources. >> Device drivers (GPU or other) are then able to reuse the existing cgroup >> controls, instead of inventing similar ones. > > I'm really skeptical about this approach. When creating resource > controllers, I think what's the most important and challenging is > establishing resource model - what resources are and how they can be > distributed. This patchset is going the other way around - building > out core infrastructure for bolierplates at a significant risk of > mixing up resource models across different types of resources. > > IO controllers already implement per-device controls. I'd suggest > following the same interface conventions and implementing a dedicated > controller for the subsystem. > Okay, thanks for feedback. Preference is clear to see this done as dedicated cgroup controller. Part of my proposal was an attempt for devices with "mem like" and "cpu like" attributes to be managed by common controller. We can ignore this idea for cpu attributes, as those can just go in a GPU controller. There might still be merit in having a 'device mem' cgroup controller. The resource model at least is then no longer mixed up with host memory. RDMA community seemed to have some interest in a common controller at least for device memory aspects. Thoughts on this? I believe could still reuse the 'struct mem_cgroup' data structure. There should be some opportunity to reuse charging APIs and have some nice integration with HMM for charging to device memory, depending on backing store. -Brian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix setting 10 bit deep color mode (rev3)
== Series Details ==
Series: drm/i915/icl: Fix setting 10 bit deep color mode (rev3)
URL : https://patchwork.freedesktop.org/series/60080/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6062 -> Patchwork_12982
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/
Known issues
Here are the changes found in Patchwork_12982 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#108569])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#109485])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-icl-y}: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/fi-icl-y/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/fi-icl-y/igt@gem_ctx_cre...@basic-files.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/fi-blb-e6850/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][9] ([fdo#108602] / [fdo#108744]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-kefka: [FAIL][11] ([fdo#100368]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6062/fi-bsw-kefka/igt@kms_flip@basic-flip-vs-wf_vblank.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/fi-bsw-kefka/igt@kms_flip@basic-flip-vs-wf_vblank.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (52 -> 45)
--
Additional (1): fi-snb-2600
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6062 -> Patchwork_12982
CI_DRM_6062: 8bd5217bbe8cdf8aea54bfbe1b776c8178ee4338 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12982: 5667cb21afb4df438a20af451f6a967e21c77c90 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5667cb21afb4 drm/i915/icl: Fix setting 10 bit deep color mode
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12982/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Engine relative MMIO
On 5/6/2019 14:36, Rodrigo Vivi wrote: On Tue, Apr 23, 2019 at 06:50:13PM -0700, john.c.harri...@intel.com wrote: From: John Harrison With virtual engines, it is no longer possible to know which specific physical engine a given request will be executed on at the time that request is generated. This means that the request itself must be engine agnostic - any direct register writes must be relative to the engine and not absolute addresses. The LRI command has support for engine relative addressing. However, the mechanism is not transparent to the driver. The scheme for Gen11 (MI_LRI_ADD_CS_MMIO_START) requires the LRI address to have no absolute engine base component. The hardware then adds on the correct engine offset at execution time. Due to the non-trivial and differing schemes on different hardware, it is not possible to simply update the code that creates the LRI commands to set a remap flag and let the hardware get on with it. Instead, this patch adds function wrappers for generating the LRI command itself and then for constructing the correct address to use with the LRI. v2: Fix build break in GVT. Remove flags parameter [review feedback from Chris W]. v3: Fix build break in selftest. Rebase to newer base tree and fix merge conflict. v4: More rebasing. Rmoved relative addressing support from Gen7-9 only code paths [review feedback from Chris W]. First of all, would you have a rebased version after gt/ ? I have just done the rebase. Was planning to resend shortly. Although if there is more discussion about the best direction to take then I would rather hold off posting until a consensus is reached. So, from my point of view v3 was better than this because this spread the __MI_LOAD_REGISTER_IMM everywhere. Maybe I just disagree with Chris and I'd prefer a single place like v3, but anyway we could probably arrive in an intermediate solution like: Couldn't we do in a way that we keep the MI_LRI without '__' and use this new function only on the paths needed? and maybe name this function gen11_get_lri_cmd? to make it clear that gen11+ needs to use this path. The intention was to make it clear that no new code should be directly writing MI_LRI. Everything should go through the helper function. Hence renaming to add the '__' to make it obvious. Otherwise, someone might use the old one by accident and we won't notice until some random and hard to track down failure related to virtual engines. Not sure I would say that the __MI_LRI is spreading 'everywhere'. There are only 8 instances versus double that of the get_lri_cmd version. Note also that it is not only Gen11+ specific paths. There are multiple places that are gen agnostic. So, unless you want to split those into pre/post Gen11 versions as well, you would end up with Gen7 calling a Gen11 labelled function. John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
On 5/3/19 2:30 PM, Stuart Summers wrote:
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice index / 8
v2: fix spacing in set_sseu_info args
use set_sseu_info to initialize sseu data when building
device status in debugfs
rename variables in intel_engine_types.h to avoid checkpatch
warnings
v3: update headers in intel_sseu.h
v4: add const to some sseu_dev_info variables
use sseu->eu_stride for EU stride calculations
v5: address review comments from Tvrtko and Daniele
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Acked-by: Lionel Landwerlin
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 24 ++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 ++--
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 43 -
drivers/gpu/drm/i915/gt/intel_sseu.h | 28 +++-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 40 ++---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_gpu_error.c| 5 +-
drivers/gpu/drm/i915/i915_query.c| 10 +-
drivers/gpu/drm/i915/intel_device_info.c | 155 ++-
11 files changed, 227 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 5907a9613641..290bda5cc82b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -909,12 +909,30 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static inline u32
+intel_sseu_fls_subslice(const struct sseu_dev_info *sseu, u32 slice)
+{
+ u32 subslice;
+ int i;
+
+ for (i = sseu->ss_stride - 1; i >= 0; i--) {
+ subslice = fls(sseu->subslice_mask[slice * sseu->ss_stride +
+ i]);
+ if (subslice) {
+ subslice += i * BITS_PER_BYTE;
+ break;
+ }
+ }
+
+ return subslice;
+}
+
u32 intel_calculate_mcr_s_ss_select(struct drm_i915_private *dev_priv)
{
const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
u32 mcr_s_ss_select;
u32 slice = fls(sseu->slice_mask);
- u32 subslice = fls(sseu->subslice_mask[slice]);
+ u32 subslice = intel_sseu_fls_subslice(sseu, slice);
if (IS_GEN(dev_priv, 10))
mcr_s_ss_select = GEN8_MCR_SLICE(slice) |
@@ -990,6 +1008,7 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
struct intel_instdone *instdone)
{
struct drm_i915_private *dev_priv = engine->i915;
+ const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
struct intel_uncore *uncore = engine->uncore;
u32 mmio_base = engine->mmio_base;
int slice;
@@ -1007,7 +1026,8 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
instdone->slice_common =
intel_uncore_read(uncore, GEN7_SC_INSTDONE);
- for_each_instdone_slice_subslice(dev_priv, slice, subslice) {
+ for_each_instdone_slice_subslice(dev_priv, sseu, slice,
+subslice) {
instdone->sampler[slice][subslice] =
read_subslice_reg(dev_priv, slice, subslice,
GEN7_SAMPLER_INSTDONE);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c0ab11b12e14..582340b55144 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -535,20 +535,20 @@ intel_engine_needs_breadcrumb_tasklet(const struct
intel_engine_cs *engine)
return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
}
-#define instdone_slice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
-
-#define instdone_subslice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.subslice_mask[0])
-
-#define for_each_instdone_slice_subslice(dev_priv__, slice__, subslice__) \
- for ((slice__) = 0, (subslice__) = 0; \
-(slice__) < I915_MAX_SLICES; \
-(subslice__) = ((subslice__) + 1) < I915_MAX_SUBSLICES ?
(subslice__) + 1 : 0, \
- (slice__) += ((subslice__) == 0)) \
- for_each_if((BIT(slice__) & instdone_slice_mask(dev_priv__)) &&
\
- (BIT(subslice__) &
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
== Series Details == Series: series starting with [1/4] drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE URL : https://patchwork.freedesktop.org/series/60367/ State : success == Summary == CI Bug Log - changes from CI_DRM_6058_full -> Patchwork_12976_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12976_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108] / [fdo#107773]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-skl8/igt@gem_soft...@noreloc-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-skl2/igt@gem_soft...@noreloc-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108686]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-kbl5/igt@gem_tiled_swapp...@non-threaded.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-kbl3/igt@gem_tiled_swapp...@non-threaded.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: - shard-hsw: [PASS][5] -> [FAIL][6] ([fdo#103355]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-hsw7/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#105363]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@2x-plain-flip-fb-recreate: - shard-glk: [PASS][9] -> [FAIL][10] ([fdo#100368]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-glk2/igt@kms_f...@2x-plain-flip-fb-recreate.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-glk5/igt@kms_f...@2x-plain-flip-fb-recreate.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-iclb2/igt@kms_frontbuffer_track...@fbc-stridechange.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-iclb4/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_lease@cursor_implicit_plane: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-iclb2/igt@kms_lease@cursor_implicit_plane.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-iclb1/igt@kms_lease@cursor_implicit_plane.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-glk1/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-apl3/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/shard-apl6/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html Possible fixes * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +9 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/shard-apl5/igt@gem_ctx_isolat...@bcs0-s3.html [24]:
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Fix setting 10 bit deep color mode
On Tue, May 07, 2019 at 11:18:56AM -0700, Aditya Swarup wrote: > There is a bug in hdmi_deep_color_possible() - we compare pipe_bpp > <= 8*3 which returns true every time for hdmi_deep_color_possible 12 bit > deep color mode test in intel_hdmi_compute_config().(Even when the > requested color mode is 10 bit through max bpc property) > > Comparing pipe_bpp with bpc * 3 takes care of this condition where > requested max bpc is 10 bit, so hdmi_deep_color_possible with 12 bit > returns false when requested max bpc is 10.(Ville) > > v2:Add suggested by Ville Syrjälä > > Suggested-by: Ville Syrjälä > Signed-off-by: Aditya Swarup > Cc: Jani Nikula > Cc: Manasi Navare > Cc: Clinton Taylor Thanks. Codewise this is identical to the previous version which was already tested succesfully -> pushed. > --- > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 991eb362ef4f..74f2dcb8b1ad 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -2159,7 +2159,7 @@ static bool hdmi_deep_color_possible(const struct > intel_crtc_state *crtc_state, > if (bpc == 10 && INTEL_GEN(dev_priv) < 11) > return false; > > - if (crtc_state->pipe_bpp <= 8*3) > + if (crtc_state->pipe_bpp < bpc * 3) > return false; > > if (!crtc_state->has_hdmi_sink) > -- > 2.17.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
== Series Details ==
Series: RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
URL : https://patchwork.freedesktop.org/series/60384/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6061 -> Patchwork_12981
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/
Known issues
Here are the changes found in Patchwork_12981 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] /
[fdo#108744])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-y}: [INCOMPLETE][7] ([fdo#107713] / [fdo#108569]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/fi-icl-y/igt@i915_selftest@live_hangcheck.html
* igt@kms_busy@basic-flip-c:
- fi-skl-6770hq: [SKIP][9] ([fdo#109271] / [fdo#109278]) -> [PASS][10]
+2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [SKIP][11] ([fdo#109271]) -> [PASS][12] +23 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6061/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[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#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (49 -> 45)
--
Additional (4): fi-byt-j1900 fi-icl-u2 fi-icl-u3 fi-snb-2600
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6061 -> Patchwork_12981
CI_DRM_6061: 2a3ab645af902ecea7c0b89a4ca40dd194bccfd6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12981: 79bd449b8e2dd37f018f106a347a4a5cdd32 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
79bd449b8e2d RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12981/
___
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: Fix fastset vs. pfit on/off on HSW EDP transcoder
On Thu, Apr 25, 2019 at 07:29:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On HSW the pipe A panel fitter lives inside the display power well,
> and the input MUX for the EDP transcoder needs to be configured
> appropriately to route the data through the power well as needed.
> Changing the MUX setting is not allowed while the pipe is active,
> so we need to force a full modeset whenever we need to change it.
>
> Currently we may end up doing a fastset which won't change the
> MUX settings, but it will drop the power well reference, and that
> kills the pipe.
>
> Cc: sta...@vger.kernel.org
> Cc: Hans de Goede
> Cc: Maarten Lankhorst
> Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
> Signed-off-by: Ville Syrjälä
Probably
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104838
and maybe
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108672
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 +
> drivers/gpu/drm/i915/intel_pipe_crc.c | 13 ++---
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c67f165b466c..691c9a929164 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12133,6 +12133,7 @@ intel_pipe_config_compare(struct drm_i915_private
> *dev_priv,
> struct intel_crtc_state *pipe_config,
> bool adjust)
> {
> + struct intel_crtc *crtc = to_intel_crtc(current_config->base.crtc);
> bool ret = true;
> bool fixup_inherited = adjust &&
> (current_config->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED) &&
> @@ -12354,6 +12355,14 @@ intel_pipe_config_compare(struct drm_i915_private
> *dev_priv,
> PIPE_CONF_CHECK_X(gmch_pfit.pgm_ratios);
> PIPE_CONF_CHECK_X(gmch_pfit.lvds_border_bits);
>
> + /*
> + * Changing the EDP transcoder input mux
> + * (A_ONOFF vs. A_ON) requires a full modeset.
> + */
> + if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A &&
> + current_config->cpu_transcoder == TRANSCODER_EDP)
> + PIPE_CONF_CHECK_BOOL(pch_pfit.enabled);
> +
> if (!adjust) {
> PIPE_CONF_CHECK_I(pipe_src_w);
> PIPE_CONF_CHECK_I(pipe_src_h);
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index e94b5b1bc1b7..e7c7be4911c1 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -311,10 +311,17 @@ intel_crtc_crc_setup_workarounds(struct intel_crtc
> *crtc, bool enable)
> pipe_config->base.mode_changed = pipe_config->has_psr;
> pipe_config->crc_enabled = enable;
>
> - if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) {
> + if (IS_HASWELL(dev_priv) &&
> + pipe_config->base.active && crtc->pipe == PIPE_A &&
> + pipe_config->cpu_transcoder == TRANSCODER_EDP) {
> + bool old_need_power_well = pipe_config->pch_pfit.enabled ||
> + pipe_config->pch_pfit.force_thru;
> + bool new_need_power_well = pipe_config->pch_pfit.enabled ||
> + enable;
> +
> pipe_config->pch_pfit.force_thru = enable;
> - if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
> - pipe_config->pch_pfit.enabled != enable)
> +
> + if (old_need_power_well != new_need_power_well)
> pipe_config->base.connectors_changed = true;
> }
>
> --
> 2.21.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/icl: Fix setting 10 bit deep color mode
There is a bug in hdmi_deep_color_possible() - we compare pipe_bpp <= 8*3 which returns true every time for hdmi_deep_color_possible 12 bit deep color mode test in intel_hdmi_compute_config().(Even when the requested color mode is 10 bit through max bpc property) Comparing pipe_bpp with bpc * 3 takes care of this condition where requested max bpc is 10 bit, so hdmi_deep_color_possible with 12 bit returns false when requested max bpc is 10.(Ville) v2:Add suggested by Ville Syrjälä Suggested-by: Ville Syrjälä Signed-off-by: Aditya Swarup Cc: Jani Nikula Cc: Manasi Navare Cc: Clinton Taylor --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 991eb362ef4f..74f2dcb8b1ad 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2159,7 +2159,7 @@ static bool hdmi_deep_color_possible(const struct intel_crtc_state *crtc_state, if (bpc == 10 && INTEL_GEN(dev_priv) < 11) return false; - if (crtc_state->pipe_bpp <= 8*3) + if (crtc_state->pipe_bpp < bpc * 3) return false; if (!crtc_state->has_hdmi_sink) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Refactor sseu helper functions
On Tue, 2019-05-07 at 11:12 -0700, Daniele Ceraolo Spurio wrote:
>
> On 5/3/19 2:30 PM, Stuart Summers wrote:
> > Move functions to intel_sseu.h and remove inline qualifier.
> > Additionally, ensure these are all prefixed with intel_sseu_*
> > to match the convention of other functions in i915.
> >
> > v2: fix spacing from checkpatch warning
> > v3: squash helper function changes into a single patch
> > break 80 character line to fix checkpatch warning
> > move get/set_eus helpers to intel_device_info.c
> >
> > Acked-by: Jani Nikula
> > Cc: Daniele Ceraolo Spurio
> > Signed-off-by: Stuart Summers
> > ---
> > drivers/gpu/drm/i915/gt/intel_sseu.c | 17
> > drivers/gpu/drm/i915/gt/intel_sseu.h | 10 +--
> > drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
> > drivers/gpu/drm/i915/i915_drv.c | 2 +-
> > drivers/gpu/drm/i915/intel_device_info.c | 103
> > ---
> > drivers/gpu/drm/i915/intel_device_info.h | 44 --
> > 6 files changed, 97 insertions(+), 83 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
> > b/drivers/gpu/drm/i915/gt/intel_sseu.c
> > index 7f448f3bea0b..a0756f006f5f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_sseu.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
> > @@ -8,6 +8,23 @@
> > #include "intel_lrc_reg.h"ther occurrences below a
> > #include "intel_sseu.h"
> >
> > +unsigned int
> > +intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
> > +{
> > + unsigned int i, total = 0;
> > +
> > + for (i = 0; i < ARRAY_SIZE(sseu->subslice_mask); i++)
> > + total += hweight8(sseu->subslice_mask[i]);
> > +
> > + return total;
> > +}
> > +
> > +unsigned int
> > +intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu,
> > u8 slice)
> > +{
> > + return hweight8(sseu->subslice_mask[slice]);
> > +}
> > +
> > u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
> > const struct intel_sseu *req_sseu)
> > {
> > diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
> > b/drivers/gpu/drm/i915/gt/intel_sseu.h
> > index 9618dff46d83..b50d0401a4e2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_sseu.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
> > @@ -63,11 +63,11 @@ intel_sseu_from_device_info(const struct
> > sseu_dev_info *sseu)
> > return value;
> > }
> >
> > -static inline unsigned int
> > -intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu,
> > u8 slice)
> > -{
> > - return hweight8(sseu->subslice_mask[slice]);
> > -}
> > +unsigned int
> > +intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
> > +
> > +unsigned int
> > +intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu,
> > u8 slice);
> >
> > u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
> > const struct intel_sseu *req_sseu);
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index dceb32a16c5c..fce3ccd87f76 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4160,7 +4160,7 @@ static void
> > broadwell_sseu_device_status(struct drm_i915_private *dev_priv,
> > RUNTIME_INFO(dev_priv)-
> > >sseu.subslice_mask[s];
> > }
> > sseu->eu_total = sseu->eu_per_subslice *
> > -sseu_subslice_total(sseu);
> > +intel_sseu_subslice_total(sseu);
> >
> > /* subtract fused off EU(s) from enabled slice(s) */
> > for (s = 0; s < fls(sseu->slice_mask); s++) {
> > @@ -4184,7 +4184,7 @@ static void i915_print_sseu_info(struct
> > seq_file *m, bool is_available_info,
> > seq_printf(m, " %s Slice Total: %u\n", type,
> >hweight8(sseu->slice_mask));
> > seq_printf(m, " %s Subslice Total: %u\n", type,
> > - sseu_subslice_total(sseu));
> > + intel_sseu_subslice_total(sseu));
> > for (s = 0; s < fls(sseu->slice_mask); s++) {
> > seq_printf(m, " %s Slice%i subslices: %u\n", type,
> >s, intel_sseu_subslices_per_slice(sseu, s));
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index dcc872f9c676..c2ea3f0992b2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -382,7 +382,7 @@ static int i915_getparam_ioctl(struct
> > drm_device *dev, void *data,
> > value = i915_cmd_parser_get_version(dev_priv);
> > break;
> > case I915_PARAM_SUBSLICE_TOTAL:
> > - value = sseu_subslice_total(sseu);
> > + value = intel_sseu_subslice_total(sseu);
> > if (!value)
> > return -ENODEV;
> > break;
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 9d6b9c45bc5e..689702b28e80 100644
> > ---
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Refactor sseu helper functions
On 5/3/19 2:30 PM, Stuart Summers wrote:
Move functions to intel_sseu.h and remove inline qualifier.
Additionally, ensure these are all prefixed with intel_sseu_*
to match the convention of other functions in i915.
v2: fix spacing from checkpatch warning
v3: squash helper function changes into a single patch
break 80 character line to fix checkpatch warning
move get/set_eus helpers to intel_device_info.c
Acked-by: Jani Nikula
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 17
drivers/gpu/drm/i915/gt/intel_sseu.h | 10 +--
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 103 ---
drivers/gpu/drm/i915/intel_device_info.h | 44 --
6 files changed, 97 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 7f448f3bea0b..a0756f006f5f 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -8,6 +8,23 @@
#include "intel_lrc_reg.h"
#include "intel_sseu.h"
+unsigned int
+intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
+{
+ unsigned int i, total = 0;
+
+ for (i = 0; i < ARRAY_SIZE(sseu->subslice_mask); i++)
+ total += hweight8(sseu->subslice_mask[i]);
+
+ return total;
+}
+
+unsigned int
+intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
+{
+ return hweight8(sseu->subslice_mask[slice]);
+}
+
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 9618dff46d83..b50d0401a4e2 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -63,11 +63,11 @@ intel_sseu_from_device_info(const struct sseu_dev_info
*sseu)
return value;
}
-static inline unsigned int
-intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
-{
- return hweight8(sseu->subslice_mask[slice]);
-}
+unsigned int
+intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
+
+unsigned int
+intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice);
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index dceb32a16c5c..fce3ccd87f76 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4160,7 +4160,7 @@ static void broadwell_sseu_device_status(struct
drm_i915_private *dev_priv,
RUNTIME_INFO(dev_priv)->sseu.subslice_mask[s];
}
sseu->eu_total = sseu->eu_per_subslice *
-sseu_subslice_total(sseu);
+intel_sseu_subslice_total(sseu);
/* subtract fused off EU(s) from enabled slice(s) */
for (s = 0; s < fls(sseu->slice_mask); s++) {
@@ -4184,7 +4184,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool
is_available_info,
seq_printf(m, " %s Slice Total: %u\n", type,
hweight8(sseu->slice_mask));
seq_printf(m, " %s Subslice Total: %u\n", type,
- sseu_subslice_total(sseu));
+ intel_sseu_subslice_total(sseu));
for (s = 0; s < fls(sseu->slice_mask); s++) {
seq_printf(m, " %s Slice%i subslices: %u\n", type,
s, intel_sseu_subslices_per_slice(sseu, s));
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dcc872f9c676..c2ea3f0992b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -382,7 +382,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = i915_cmd_parser_get_version(dev_priv);
break;
case I915_PARAM_SUBSLICE_TOTAL:
- value = sseu_subslice_total(sseu);
+ value = intel_sseu_subslice_total(sseu);
if (!value)
return -ENODEV;
break;
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 9d6b9c45bc5e..689702b28e80 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -90,7 +90,7 @@ static void sseu_dump(const struct sseu_dev_info *sseu,
struct drm_printer *p)
drm_printf(p, "slice total: %u, mask=%04x\n",
hweight8(sseu->slice_mask), sseu->slice_mask);
- drm_printf(p, "subslice total: %u\n", sseu_subslice_total(sseu));
+ drm_printf(p, "subslice total: %u\n",
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
== Series Details == Series: RFC: x86/smp: use printk_deferred in native_smp_send_reschedule URL : https://patchwork.freedesktop.org/series/60384/ State : warning == Summary == $ dim checkpatch origin/drm-tip 79bd449b8e2d RFC: x86/smp: use printk_deferred in native_smp_send_reschedule -:93: WARNING:UNNECESSARY_KERN_LEVEL: Possible unnecessary KERN_WARNING #93: FILE: arch/x86/kernel/smp.c:128: + printk_deferred(KERN_WARNING -:97: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 9 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP2.2 Phase II (rev9)
== Series Details ==
Series: HDCP2.2 Phase II (rev9)
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6060 -> Patchwork_12980
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12980:
### IGT changes ###
Possible regressions
* {igt@kms_content_protection@srm} (NEW):
- {fi-cml-u}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-cml-u/igt@kms_content_protect...@srm.html
- fi-cfl-8109u: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-cfl-8109u/igt@kms_content_protect...@srm.html
- {fi-icl-y}: NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-icl-y/igt@kms_content_protect...@srm.html
- fi-skl-lmem:NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-skl-lmem/igt@kms_content_protect...@srm.html
- fi-apl-guc: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-apl-guc/igt@kms_content_protect...@srm.html
- fi-skl-gvtdvm: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-skl-gvtdvm/igt@kms_content_protect...@srm.html
New tests
-
New tests have been introduced between CI_DRM_6060 and Patchwork_12980:
### New IGT tests (1) ###
* igt@kms_content_protection@srm:
- Statuses : 4 fail(s) 7 pass(s) 32 skip(s)
- Exec time: [0.0, 131.58] s
Known issues
Here are the changes found in Patchwork_12980 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq: [PASS][7] -> [DMESG-WARN][8] ([fdo#108529]) +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][9] -> [INCOMPLETE][10] ([fdo#108602] /
[fdo#108744])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-kbl-8809g: [DMESG-FAIL][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/fi-kbl-8809g/igt@i915_selftest@live_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-kbl-8809g/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-y}: [INCOMPLETE][15] ([fdo#107713] / [fdo#108569]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6060/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12980/fi-icl-y/igt@i915_selftest@live_hangcheck.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#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (52 -> 44)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-byt-clapper
Build changes
-
* IGT: IGT_4972 -> IGTPW_2939
* Linux: CI_DRM_6060 -> Patchwork_12980
CI_DRM_6060: d60cc5ba9072d0e606129ec5b8d1c5bcabf7867c @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_2939: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2939/
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
[Intel-gfx] [PATCH] RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):
Call Trace:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule+0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.
This is fix attempt number 3, we've already tried to:
- make the console_trylock trylock also the spinlock. This works in
the limited case of the console_lock use-case, but doesn't fix the
same semaphore.lock acquisition in the up() path in console_unlock,
which we can't avoid with a trylock.
- move the wake_up_process in up() out from under the semaphore.lock
spinlock critical section. Again this works for the limited case of
the console_lock, and does fully break the cycle for this lock.
Unfortunately there's still plenty of scheduler related locks that
wake_up_process needs, so the loop is still there, just with a few
less locks involved.
Hence now third attempt, trying to fix this by using printk_deferred()
instead of the normal printk that WARN() uses.
native_smp_send_reschedule is only called from scheduler related code,
which has to use printk_deferred due to this locking recursion, so
this seems consistent.
It has the unfortunate downside that we're losing the backtrace though
(I didn't find a printk_deferred version of WARN, and I'm not sure
it's a bright idea to dump that much using printk_deferred.)
Keeping all the people from the console_lock/printk related attempts
on cc as fyi.
Note: We can only hit this in our CI, with a very low reproduction
rate. And right now the lockdep splat and a few other things crowd out
what actually happens in the little bit of dmesg we recover, so no
idea yet why exactly we're hitting that WARN().
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Daniel Vetter
Cc: John Ogness
Cc: linux-ker...@vger.kernel.org
Cc: Nicolai Stange
Cc: Thomas Gleixner
---
arch/x86/kernel/smp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 04adc8d60aed..f19782786669 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -125,7 +125,8 @@ static bool smp_no_nmi_ipi = false;
static void native_smp_send_reschedule(int cpu)
{
if (unlikely(cpu_is_offline(cpu))) {
- WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n",
cpu);
+ printk_deferred(KERN_WARNING
+ "sched: Unexpected reschedule of offline
CPU#%d!\n", cpu);
return;
}
apic->send_IPI(cpu, RESCHEDULE_VECTOR);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/45] drm/i915: Apply an execution_mask to the virtual_engine
Quoting Tvrtko Ursulin (2019-04-29 15:12:23)
>
> On 25/04/2019 10:19, Chris Wilson wrote:
> > static void virtual_submission_tasklet(unsigned long data)
> > {
> > struct virtual_engine * const ve = (struct virtual_engine *)data;
> > const int prio = ve->base.execlists.queue_priority_hint;
> > + intel_engine_mask_t mask;
> > unsigned int n;
> >
> > + rcu_read_lock();
> > + mask = virtual_submission_mask(ve);
> > + rcu_read_unlock();
> > + if (unlikely(!mask))
>
> Is the rcu_lock think solely for the same protection against wedging in
> submit_notify?
No. We may still be in the rbtree of the physical engines and
ve->request may be plucked out from underneath us as we read it. And in
the time it takes to tracek, that request may have been executed,
retired and freed. To prevent the dangling stale dereference, we use
rcu_read_lock() here as we peek into the request, and spinlocks around
the actual transfer to the execution backend.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP2.2 Phase II (rev9)
== Series Details == Series: HDCP2.2 Phase II (rev9) URL : https://patchwork.freedesktop.org/series/57232/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm: move content protection property to mode_config Okay! Commit: drm/i915: debugfs: HDCP2.2 capability read Okay! Commit: drm: generic fn converting be24 to cpu and vice versa Okay! Commit: drm: revocation check at drm subsystem +drivers/gpu/drm/drm_hdcp.c:235:6: warning: symbol 'drm_hdcp_request_srm' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:27:3: warning: symbol 'srm_data' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:317:5: warning: symbol 'drm_setup_hdcp_srm' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:327:6: warning: symbol 'drm_teardown_hdcp_srm' was not declared. Should it be static? +./include/linux/slab.h:666:13: error: not a function +./include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:666:13: warning: call with no type! Commit: drm/i915: SRM revocation check for HDCP1.4 and 2.2 Okay! Commit: drm/hdcp: gathering hdcp related code into drm_hdcp.c Okay! Commit: drm: Add Content protection type property Okay! Commit: drm/i915: Attach content type property Okay! Commit: drm: uevent for connector status change Okay! Commit: drm/hdcp: update content protection property with uevent Okay! Commit: drm/i915: update the hdcp state with uevent Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev9)
== Series Details ==
Series: HDCP2.2 Phase II (rev9)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2c27a886355d drm: move content protection property to mode_config
95b249c75379 drm/i915: debugfs: HDCP2.2 capability read
8969d4d4cfd3 drm: generic fn converting be24 to cpu and vice versa
242f3762b645 drm: revocation check at drm subsystem
-:63: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#63:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 402 lines checked
71dfff191a9f drm/i915: SRM revocation check for HDCP1.4 and 2.2
b886f4c85175 drm/hdcp: gathering hdcp related code into drm_hdcp.c
-:104: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#104: FILE: drivers/gpu/drm/drm_hdcp.c:343:
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-:121: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#121: FILE: drivers/gpu/drm/drm_hdcp.c:360:
+int drm_connector_attach_content_protection_property(
-:167: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#167: FILE: include/drm/drm_hdcp.h:293:
+int drm_connector_attach_content_protection_property(
total: 0 errors, 0 warnings, 3 checks, 130 lines checked
bfdf6e8c73aa drm: Add Content protection type property
-:98: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#98: FILE: drivers/gpu/drm/drm_hdcp.c:349:
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/drm_hdcp.c:402:
+ prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
+ drm_hdcp_content_type_enum_list,
-:144: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#144: FILE: drivers/gpu/drm/drm_hdcp.c:403:
+ ARRAY_SIZE(
total: 0 errors, 0 warnings, 3 checks, 161 lines checked
99bfb7556dc5 drm/i915: Attach content type property
85c5a1d2fe9e drm: uevent for connector status change
5472c22a1374 drm/hdcp: update content protection property with uevent
-:64: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#64: FILE: drivers/gpu/drm/drm_hdcp.c:444:
+ drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
total: 0 errors, 0 warnings, 1 checks, 47 lines checked
15115903dfac drm/i915: update the hdcp state with uevent
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 11/11] drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 69522687b2cb..8abd69551ead 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -865,7 +865,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
prop_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
struct drm_device *dev = connector->base.dev;
- struct drm_connector_state *state;
drm_modeset_lock(>mode_config.connection_mutex, NULL);
mutex_lock(>mutex);
@@ -875,10 +874,9 @@ static void intel_hdcp_prop_work(struct work_struct *work)
* those to UNDESIRED is handled by core. If value == UNDESIRED,
* we're running just after hdcp has been disabled, so just exit
*/
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- state = connector->base.state;
- state->content_protection = hdcp->value;
- }
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ drm_hdcp_update_content_protection(>base,
+ hdcp->value);
mutex_unlock(>mutex);
drm_modeset_unlock(>mode_config.connection_mutex);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 08/11] drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
v6:
Type change with UNDESIRED state is ignored.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 39 +++-
drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
drivers/gpu/drm/i915/intel_hdcp.h | 2 +-
3 files changed, 62 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd5277d98b03..0ffba18613b2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3490,7 +3490,8 @@ static void intel_enable_ddi(struct intel_encoder
*encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->hdcp_content_type);
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3559,15 +3560,41 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ bool content_protection_type_changed =
+ (conn_state->hdcp_content_type != hdcp->content_type &&
+conn_state->content_protection !=
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+ /*
+* During the HDCP encryption session if Type change is requested,
+* disable the HDCP and reenable it with new TYPE value.
+*/
if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
- else if (conn_state->content_protection ==
-DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- intel_hdcp_disable(to_intel_connector(conn_state->connector));
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_disable(connector);
+
+ /*
+* Mark the hdcp state as DESIRED after the hdcp disable of type
+* change procedure.
+*/
+ if (content_protection_type_changed) {
+ mutex_lock(>mutex);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ mutex_unlock(>mutex);
+ }
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_enable(connector, (u8)conn_state->hdcp_content_type);
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index be6c81addca0..69522687b2cb 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1748,14 +1748,15 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
-static inline int initialize_hdcp_port_data(struct intel_connector *connector)
+static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+ const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
data->port = connector->encoder->port;
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
- data->protocol = (u8)hdcp->shim->protocol;
+ data->protocol = (u8)shim->protocol;
data->k = 1;
if (!data->streams)
@@ -1805,12 +1806,13 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector)
+static void intel_hdcp2_init(struct intel_connector *connector,
+const struct intel_hdcp_shim
[Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_sysfs.c | 35 +++
include/drm/drm_sysfs.h | 5 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..63fa951a20db 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -21,6 +21,7 @@
#include
#include
#include "drm_internal.h"
+#include "drm_crtc_internal.h"
#define to_drm_minor(d) dev_get_drvdata(d)
#define to_drm_connector(d) dev_get_drvdata(d)
@@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev. Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+ struct drm_device *dev = connector->dev;
+ char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+ char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+ WARN_ON(!drm_mode_obj_find_prop_id(>base,
+ property->base.id));
+
+ snprintf(conn_id, ARRAY_SIZE(conn_id),
+"CONNECTOR=%u", connector->base.id);
+ snprintf(prop_id, ARRAY_SIZE(prop_id),
+"PROPERTY=%u", property->base.id);
+
+ DRM_DEBUG("generating connector status event\n");
+
+ kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
static void drm_sysfs_release(struct device *dev)
{
kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
struct drm_device;
struct device;
+struct drm_connector;
+struct drm_property;
int drm_class_device_register(struct device *dev);
void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
#endif
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 03/11] drm: generic fn converting be24 to cpu and vice versa
Existing functions for converting a 3bytes(be24) of big endian value
into u32 of little endian and vice versa are renamed as
s/drm_hdcp2_seq_num_to_u32/drm_hdcp_be24_to_cpu
s/drm_hdcp2_u32_to_seq_num/drm_hdcp_cpu_to_be24
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
cc: Tomas Winkler
---
drivers/gpu/drm/i915/intel_hdcp.c | 5 +++--
drivers/misc/mei/hdcp/mei_hdcp.c | 2 +-
include/drm/drm_hdcp.h| 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index b8c8d6d1a33d..c308dfee9ca4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1305,7 +1305,7 @@ int hdcp2_propagate_stream_management_info(struct
intel_connector *connector)
/* Prepare RepeaterAuth_Stream_Manage msg */
msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
- drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+ drm_hdcp_cpu_to_be24(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
/* K no of streams is fixed as 1. Stored as big-endian. */
msgs.stream_manage.k = cpu_to_be16(1);
@@ -1370,7 +1370,8 @@ int hdcp2_authenticate_repeater_topology(struct
intel_connector *connector)
}
/* Converting and Storing the seq_num_v to local variable as DWORD */
- seq_num_v = drm_hdcp2_seq_num_to_u32(msgs.recvid_list.seq_num_v);
+ seq_num_v =
+ drm_hdcp_be24_to_cpu((const u8 *)msgs.recvid_list.seq_num_v);
if (seq_num_v < hdcp->seq_num_v) {
/* Roll over of the seq_num_v from repeater. Reauthenticate. */
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 90b6ae8e9dae..2f192d6d8b54 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -576,7 +576,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
HDCP_2_2_MPRIME_LEN);
- drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data->seq_num_m);
+ drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data->seq_num_m);
memcpy(verify_mprime_in.streams, data->streams,
(data->k * sizeof(struct hdcp2_streamid_type)));
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index f243408ecf26..1cc66df05a43 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -252,13 +252,13 @@ struct hdcp2_rep_stream_ready {
* host format and back
*/
static inline
-u32 drm_hdcp2_seq_num_to_u32(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
+u32 drm_hdcp_be24_to_cpu(const u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
{
return (u32)(seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16);
}
static inline
-void drm_hdcp2_u32_to_seq_num(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
+void drm_hdcp_cpu_to_be24(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
{
seq_num[0] = val >> 16;
seq_num[1] = val >> 8;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 01/11] drm: move content protection property to mode_config
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++--
include/drm/drm_connector.h | 6 --
include/drm/drm_mode_config.h | 6 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 428d82662dc4..4131e669785a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -732,7 +732,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
return -EINVAL;
@@ -814,7 +814,7 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124849db..7c0eda9cca60 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1534,18 +1534,19 @@ int drm_connector_attach_content_protection_property(
struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- struct drm_property *prop;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
if (!prop)
return -ENOMEM;
drm_object_attach_property(>base, prop,
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
-
- connector->content_protection_property = prop;
+ dev->mode_config.content_protection_property = prop;
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f43f40d5888a..2186eec0408b 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1065,12 +1065,6 @@ struct drm_connector {
*/
struct drm_property *vrr_capable_property;
- /**
-* @content_protection_property: DRM ENUM property for content
-* protection. See drm_connector_attach_content_protection_property().
-*/
- struct drm_property *content_protection_property;
-
/**
* @colorspace_property: Connector property to set the suitable
* colorspace supported by the sink.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7f60e8eb269a..5764ee3c7453 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -836,6 +836,12 @@ struct drm_mode_config {
*/
struct drm_property *writeback_out_fence_ptr_property;
+ /**
+* @content_protection_property: DRM ENUM property for content
+* protection. See drm_connector_attach_content_protection_property().
+*/
+ struct drm_property *content_protection_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 00/11] HDCP2.2 Phase II
This series adds the content type capability for HDCP through a drm connetor proeprty "HDCP Content Type". By default this property will be "Type 0". And this property is exposed by the drivers which has the HDCP2.2 capability to enable the userspace to configure for "Type 1". HDCP Content Type: This property is used to indicate the content type classification of a stream. Which indicate the HDCP version required for the rendering of that streams. This conten type is one of the parameter in the HDCP2.2 authentication flow, as even downstream repeaters will mandate the HDCP version requirement. Two values possible for content type of a stream: Type 0: Stream can be rendered only on HDCP encrypted link no restriction on HDCP versions. Type 1: Stream can be rendered only on HDCP2.2 encrypted link. And also this series adds a uevent for a change in the property state change of a connector. This helps the userspace to monitor the uevent for a property state change than the trivial polling. Userspace consumer for above "HDCP Content Type" property and uevent is almost at the last phase of review at #wayland community. So Patches 7, 8, 9, 10 and 11 can be merged only when patches in #wayland community receives the ACK. HDCP SRM is implemented through request_firmware() interface. Hence userspace is expected to write the signature validated latest available SRM table into /lib/firmware/ as "display_hdcp_srm.bin". On every HDCP authentication kernel will read the SRM from above mentioned file and do the revocation check. And also this series gathers all HDCP related DRM code into drm_hdcp.c Thanks Daniel Vetter for all the reviews. v7: few suggestions in SRM handling at drm is addressed [Daniel] A prep patch is added. fix at content_type attachment is added. Series can be cloned from github https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v7 Test-with: <20190502131625.27551-2-ramalinga...@intel.com> Ramalingam C (11): drm: move content protection property to mode_config drm/i915: debugfs: HDCP2.2 capability read drm: generic fn converting be24 to cpu and vice versa drm: revocation check at drm subsystem drm/i915: SRM revocation check for HDCP1.4 and 2.2 drm/hdcp: gathering hdcp related code into drm_hdcp.c drm: Add Content protection type property drm/i915: Attach content type property drm: uevent for connector status change drm/hdcp: update content protection property with uevent drm/i915: update the hdcp state with uevent Documentation/gpu/drm-kms-helpers.rst | 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 +- drivers/gpu/drm/drm_connector.c | 61 ++-- drivers/gpu/drm/drm_hdcp.c| 446 ++ drivers/gpu/drm/drm_internal.h| 4 + drivers/gpu/drm/drm_sysfs.c | 37 +++ drivers/gpu/drm/i915/i915_debugfs.c | 13 +- drivers/gpu/drm/i915/intel_ddi.c | 39 ++- drivers/gpu/drm/i915/intel_hdcp.c | 105 -- drivers/gpu/drm/i915/intel_hdcp.h | 3 +- drivers/misc/mei/hdcp/mei_hdcp.c | 2 +- include/drm/drm_connector.h | 15 +- include/drm/drm_hdcp.h| 33 +- include/drm/drm_mode_config.h | 12 + include/drm/drm_sysfs.h | 5 +- include/uapi/drm/drm_mode.h | 4 + 17 files changed, 698 insertions(+), 97 deletions(-) create mode 100644 drivers/gpu/drm/drm_hdcp.c -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 02/11] drm/i915: debugfs: HDCP2.2 capability read
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
v2:
Rebased.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
drivers/gpu/drm/i915/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/intel_hdcp.h | 1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..c15d3f3bb8e0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4753,6 +4753,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
{
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+ bool hdcp_cap, hdcp2_cap;
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4763,8 +4764,16 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
- seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
- "None" : "HDCP1.4");
+ hdcp_cap = intel_hdcp_capable(intel_connector);
+ hdcp2_cap = intel_hdcp2_capable(intel_connector);
+
+ if (hdcp_cap)
+ seq_puts(m, "HDCP1.4 ");
+ if (hdcp2_cap)
+ seq_puts(m, "HDCP2.2 ");
+
+ if (!hdcp_cap && !hdcp2_cap)
+ seq_puts(m, "None");
seq_puts(m, "\n");
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index ca5982e45e3e..b8c8d6d1a33d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -79,7 +79,7 @@ bool intel_hdcp_capable(struct intel_connector *connector)
}
/* Is HDCP2.2 capable on Platform and Sink */
-static bool intel_hdcp2_capable(struct intel_connector *connector)
+bool intel_hdcp2_capable(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.h
b/drivers/gpu/drm/i915/intel_hdcp.h
index a75f25f09d39..be8da85c866a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/intel_hdcp.h
@@ -25,6 +25,7 @@ int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+bool intel_hdcp2_capable(struct intel_connector *connector);
void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
void intel_hdcp_cleanup(struct intel_connector *connector);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 10/11] drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_hdcp.c | 32
include/drm/drm_hdcp.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 75402463466b..f29b7abda51f 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -372,6 +372,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
*
* The content protection will be set to
_connector_state.content_protection
*
+ * When kernel triggered content protection state change like DESIRED->ENABLED
+ * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to
update
+ * the content protection state of a connector.
+ *
* Returns:
* Zero on success, negative errno on failure.
*/
@@ -412,3 +416,31 @@ int drm_connector_attach_content_protection_property(
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
+/**
+ * drm_hdcp_update_content_protection - Updates the content protection state
+ * of a connector
+ *
+ * @connector: drm_connector on which content protection state needs an update
+ * @val: New state of the content protection property
+ *
+ * This function can be used by display drivers, to update the kernel triggered
+ * content protection state change of a drm_connector. This function update the
+ * new state of the property into the connector's state and generate an uevent
+ * to notify the userspace.
+ */
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_connector_state *state = connector->state;
+
+ WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+ if (state->content_protection == val)
+ return;
+
+ state->content_protection = val;
+ drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
+}
+EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 2970abdfaf12..dd864ac9ce85 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
u8 *ksvs, u32 ksv_count);
int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val);
#endif
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 05/11] drm/i915: SRM revocation check for HDCP1.4 and 2.2
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
v2:
Rebased.
v3:
%s/*_ksvs_revocated/*_check_ksvs_revoked [Daniel]
unwanted noise is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 45 ++-
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index c308dfee9ca4..53df2f2376e8 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -491,9 +491,11 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port
*intel_dig_port,
/* Implements Part 2 of the HDCP authorization procedure */
static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ const struct intel_hdcp_shim *shim = connector->hdcp.shim;
+ struct drm_device *dev = connector->base.dev;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
@@ -532,6 +534,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
if (ret)
goto err;
+ if (drm_hdcp_check_ksvs_revoked(dev, ksv_fifo, num_downstream)) {
+ DRM_ERROR("Revoked Ksv(s) in ksv_fifo\n");
+ return -EPERM;
+ }
+
/*
* When V prime mismatches, DP Spec mandates re-read of
* V prime atleast twice.
@@ -558,9 +565,12 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
}
/* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ struct drm_device *dev = connector->base.dev;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -626,6 +636,11 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
if (ret < 0)
return ret;
+ if (drm_hdcp_check_ksvs_revoked(dev, bksv.shim, 1)) {
+ DRM_ERROR("BKSV is revoked\n");
+ return -EPERM;
+ }
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
@@ -699,7 +714,7 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
*/
if (repeater_present)
- return intel_hdcp_auth_downstream(intel_dig_port, shim);
+ return intel_hdcp_auth_downstream(connector);
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -762,7 +777,7 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
- ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
+ ret = intel_hdcp_auth(connector);
if (!ret) {
hdcp->hdcp_encrypted = true;
return 0;
@@ -1161,6 +1176,7 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
+ struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_ake_init ake_init;
struct hdcp2_ake_send_cert send_cert;
@@ -1195,6 +1211,12 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
+ if (drm_hdcp_check_ksvs_revoked(dev, msgs.send_cert.cert_rx.receiver_id,
+ 1)) {
+ DRM_ERROR("Receiver ID is revoked\n");
+ return -EPERM;
+ }
+
/*
* Here msgs.no_stored_km will hold msgs corresponding to the km
* stored also.
@@ -1347,13 +1369,14 @@ int hdcp2_authenticate_repeater_topology(struct
intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
+ struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_rep_send_receiverid_list recvid_list;
struct hdcp2_rep_send_ack rep_ack;
} msgs;
const
[Intel-gfx] [PATCH v7 07/11] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Need ACK for this new conenctor property from userspace consumer.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 18
drivers/gpu/drm/drm_hdcp.c| 36 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
include/drm/drm_connector.h | 7 ++
include/drm/drm_hdcp.h| 2 +-
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 4
8 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4131e669785a..a85f3ccfe699 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -738,6 +738,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -816,6 +818,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->scaling_mode;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 764c7903edf6..de9e06583e8c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -955,6 +955,24 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* the value transitions from ENABLED to DESIRED. This signifies the link
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
+ * HDCP Content Type:
+ * This property is used by the userspace to configure the kernel with
+ * to be displayed stream's content type. Content Type of a stream is
+ * decided by the owner of the stream, as HDCP Type0 or HDCP Type1.
+ *
+ * The value of the property can be one the below:
+ * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * HDCP Type0 streams can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or HDCP 2.2.
+ * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ * HDCP Type1 streams can be transmitted on a link which is
+ * encrypted only with HDCP 2.2.
+ *
+ * Note that the HDCP Content Type property is specific to HDCP 2.2, and
+ * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2
+ * If content type is changed when content_protection is not UNDESIRED,
+ * then kernel will disable the HDCP and re-enable with new type in the
+ * same atomic commit
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 0da7b3718bad..75402463466b 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -342,23 +342,41 @@ static struct drm_prop_enum_list drm_cp_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+ { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+ { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+drm_hdcp_content_type_enum_list)
+
/**
* drm_connector_attach_content_protection_property - attach content protection
*
[Intel-gfx] [PATCH v7 06/11] drm/hdcp: gathering hdcp related code into drm_hdcp.c
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
v2:
Rebased.
v2:
Rebased.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 44 --
drivers/gpu/drm/drm_hdcp.c | 47 +
include/drm/drm_connector.h | 2 --
include/drm/drm_hdcp.h | 3 +++
4 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c0eda9cca60..764c7903edf6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -823,13 +823,6 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_cp_enum_list[] = {
- { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
- { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
- { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
-};
-DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -1515,43 +1508,6 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
-/**
- * drm_connector_attach_content_protection_property - attach content protection
- * property
- *
- * @connector: connector to attach CP property on.
- *
- * This is used to add support for content protection on select connectors.
- * Content Protection is intentionally vague to allow for different underlying
- * technologies, however it is most implemented by HDCP.
- *
- * The content protection will be set to
_connector_state.content_protection
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_attach_content_protection_property(
- struct drm_connector *connector)
-{
- struct drm_device *dev = connector->dev;
- struct drm_property *prop =
- dev->mode_config.content_protection_property;
-
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(>base, prop,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- dev->mode_config.content_protection_property = prop;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
-
/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5e5409505c31..0da7b3718bad 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
struct hdcp_srm {
u32 revoked_ksv_cnt;
@@ -331,3 +334,47 @@ void drm_teardown_hdcp_srm(struct class *drm_class)
kfree(srm_data);
}
}
+
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
+ { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
+/**
+ * drm_connector_attach_content_protection_property - attach content protection
+ * property
+ *
+ * @connector: connector to attach CP property on.
+ *
+ * This is used to add support for content protection on select connectors.
+ * Content Protection is intentionally vague to allow for different underlying
+ * technologies, however it is most implemented by HDCP.
+ *
+ * The content protection will be set to
_connector_state.content_protection
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_content_protection_property(
+ struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
+
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(>base, prop,
+
[Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and 2.2 versions of SRM table.
v2:
moved the uAPI to request_firmware_direct() [Daniel]
v3:
kdoc added. [Daniel]
srm_header unified and bit field definitions are removed. [Daniel]
locking improved. [Daniel]
vrl length violation is fixed. [Daniel]
v4:
s/__swab16/be16_to_cpu [Daniel]
be24_to_cpu is done through a global func [Daniel]
Unused variables are removed. [Daniel]
unchecked return values are dropped from static funcs [Daniel]
Signed-off-by: Ramalingam C
Acked-by: Satyeshwar Singh
Reviewed-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 6 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_hdcp.c| 333 ++
drivers/gpu/drm/drm_internal.h| 4 +
drivers/gpu/drm/drm_sysfs.c | 2 +
include/drm/drm_hdcp.h| 24 ++
6 files changed, 370 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_hdcp.c
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 14102ae035dc..0fe726a6ee67 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -181,6 +181,12 @@ Panel Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
+HDCP Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
+ :export:
+
Display Port Helper Functions Reference
===
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..dd02e9dec810 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
- drm_atomic_uapi.o
+ drm_atomic_uapi.o drm_hdcp.o
drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
drm_dma.o drm_scatter.o drm_lock.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index ..5e5409505c31
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct hdcp_srm {
+ u32 revoked_ksv_cnt;
+ u8 *revoked_ksv_list;
+
+ /* Mutex to protect above struct member */
+ struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const u8 *ksv)
+{
+ DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
+ ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
+}
+
+static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+ while (parsed_bytes < vrls_length) {
+ vrl_ksv_cnt = *buf;
+ ksv_count += vrl_ksv_cnt;
+
+ vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+ buf += vrl_sz;
+ parsed_bytes += vrl_sz;
+ }
+
+ /*
+* When vrls are not valid, ksvs are not considered.
+* Hence SRM will be discarded.
+*/
+ if (parsed_bytes != vrls_length)
+ ksv_count = 0;
+
+ return ksv_count;
+}
+
+static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
+u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0;
+ u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+ buf++;
+
+ DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+ memcpy(revoked_ksv_list, buf, vrl_ksv_sz);
+
+ ksv_count += vrl_ksv_cnt;
+ revoked_ksv_list += vrl_ksv_sz;
+ buf += vrl_ksv_sz;
+
+ parsed_bytes += (vrl_ksv_sz + 1);
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static inline u32 get_vrl_length(const u8 *buf)
+{
+ return drm_hdcp_be24_to_cpu(buf);
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count)
+{
+ struct hdcp_srm_header *header;
+ u32 vrl_length, ksv_count;
+
+ if (count < (sizeof(struct hdcp_srm_header) +
+
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Multi-segmented-gamma for ICL (rev2)
== Series Details ==
Series: Enable Multi-segmented-gamma for ICL (rev2)
URL : https://patchwork.freedesktop.org/series/60126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059 -> Patchwork_12979
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/
Known issues
Here are the changes found in Patchwork_12979 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][1] -> [FAIL][2] ([fdo#108511])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110620])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-y}: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-icl-y/igt@gem_exec_cre...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/fi-icl-y/igt@gem_exec_cre...@basic.html
* igt@i915_selftest@live_execlists:
- fi-apl-guc: [INCOMPLETE][7] ([fdo#103927] / [fdo#109720]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/fi-apl-guc/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@dp-crc-fast:
- {fi-icl-u2}:[FAIL][9] ([fdo#109635 ] / [fdo#110387]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][11] ([fdo#108622] / [fdo#109720]) ->
[FAIL][12] ([fdo#110622])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6059 -> Patchwork_12979
CI_DRM_6059: dd7af767d072fa866d5bc2d24ff225bf82f2ad11 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12979: 7273540608c5ff721a80fe39ef64603e5c00fcbe @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7273540608c5 drm/i915/icl: Add Multi-segmented gamma support
85df31f91908 drm/i915: Rename ivb_load_lut_10_max
522287b39e22 drm/i915/icl: Add register definitions for Multi Segmented gamma
96f3177a1623 drm/i915: Change gamma/degamma_lut_size data type to u32
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12979/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, May 7, 2019 7:37 PM
> >To: Sharma, Shashank
> >Cc: intel-gfx@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
> >conversion for
> >BT2020 case
> >
> >On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
> >> From: Uma Shankar
> >>
> >> Currently input csc for YCbCR to RGB conversion handles only
> >> BT601 and Bt709. Extending it to support BT2020 as well.
> >>
> >> Signed-off-by: Uma Shankar
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/i915/intel_sprite.c | 24
> >> 1 file changed, 24 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >> b/drivers/gpu/drm/i915/intel_sprite.c
> >> index 44aaeac1b2ed..2536e757bec2 100644
> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
> >>0x9EF8, 0x7800, 0xABF8,
> >>0x0, 0x7800, 0x7ED8,
> >>},
> >> + /*
> >> + * BT.2020 full range YCbCr -> full range RGB
> >> + * The matrix required is :
> >> + * [1.000, 0.000, 1.474,
> >> + * 1.000, -0.1645, -0.5713,
> >> + * 1.000, 1.8814, 0.]
> >> + */
> >> + [DRM_COLOR_YCBCR_BT2020] = {
> >> + 0x7BC8, 0x7800, 0x0,
> >> + 0x8928, 0x7800, 0xAA88,
> >> + 0x0, 0x7800, 0x7F10,
> >> + },
> >>};
> >>
> >>/* Matrix for Limited Range to Full Range Conversion */ @@ -461,6
> >> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
> >>0x, 0x7918, 0xADA8,
> >>0x0, 0x7918, 0x6870,
> >>},
> >> + /*
> >> + * BT.2020 Limited range YCbCr -> full range RGB
> >> + * The matrix required is :
> >> + * [1.164, 0.000, 1.717,
> >> + * 1.138, -0.1873, -0.6504,
> >> + * 1.1380, 2.1417, 0.]
> >
> >Where are those 1.138 coming from?
>
> Hi Ville,
> This is the original YCBCR to RGB BT2020 matrix:
> {
> 1.000, 0.000, 1.4746000,
> 1.000, -0.16455312684, -0.57135312684,
> 1.000, 1.8814000, 0.000
> };
>
> We have to convert Limited Range YCbCr to Full Range RGB. Hence we need to
> apply a scale factor:
> yscalefactor = 219.0 * normalizingfactor;
> cbcrscalefactor = 224.0 * normalizingfactor;
>
> /* Scale factors are inverted for LR to FR conversion */
> yscalefactor = 1.0 / yscalefactor;
> cbcrscalefactor = 1.0 / cbcrscalefactor;
>
> This yields the above results.
Those are the coefficients for Y, so they should still
be the same for all three output channels.
igt_color_encoding gives me:
|1.1644, 0., 1.6787,|
|1.1644,-0.1873,-0.6504,|
|1.1644, 2.1418, 0.,|
Looks like we're also misprogramming the Y pre-offset
for the full range YCbCr case.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Don't apply priority boost for resets
== Series Details ==
Series: drm/i915/execlists: Don't apply priority boost for resets
URL : https://patchwork.freedesktop.org/series/60369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059 -> Patchwork_12978
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/
Known issues
Here are the changes found in Patchwork_12978 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([fdo#107709])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-bsw-kefka/igt@i915_selftest@live_evict.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/fi-bsw-kefka/igt@i915_selftest@live_evict.html
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110620])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-y}: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-icl-y/igt@gem_exec_cre...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/fi-icl-y/igt@gem_exec_cre...@basic.html
* igt@i915_selftest@live_execlists:
- fi-apl-guc: [INCOMPLETE][7] ([fdo#103927] / [fdo#109720]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/fi-apl-guc/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@dp-crc-fast:
- {fi-icl-u2}:[FAIL][9] ([fdo#109635 ] / [fdo#110387]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][11] ([fdo#108622] / [fdo#109720]) ->
[FAIL][12] ([fdo#110622])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6059 -> Patchwork_12978
CI_DRM_6059: dd7af767d072fa866d5bc2d24ff225bf82f2ad11 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12978: 11efb94e14ee64a045d7f6e3df4da756a5d2b6ab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
11efb94e14ee drm/i915/execlists: Don't apply priority boost for resets
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12978/
___
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: Only reschedule the submission tasklet if preemption is possible
== Series Details ==
Series: drm/i915: Only reschedule the submission tasklet if preemption is
possible
URL : https://patchwork.freedesktop.org/series/60368/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059 -> Patchwork_12977
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/
Known issues
Here are the changes found in Patchwork_12977 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] /
[fdo#110624])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-y}: [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-icl-y/igt@gem_exec_cre...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/fi-icl-y/igt@gem_exec_cre...@basic.html
* igt@kms_chamelium@dp-crc-fast:
- {fi-icl-u2}:[FAIL][5] ([fdo#109635 ] / [fdo#110387]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][7] ([fdo#108622] / [fdo#109720]) -> [FAIL][8]
([fdo#110624])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6059/fi-apl-guc/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6059 -> Patchwork_12977
CI_DRM_6059: dd7af767d072fa866d5bc2d24ff225bf82f2ad11 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12977: c6e0d7d9f7528e58219c72308c1e5b154cd6cc37 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c6e0d7d9f752 drm/i915: Only reschedule the submission tasklet if preemption is
possible
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12977/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: disable framebuffer compression on GeminiLake (rev2)
== Series Details == Series: i915: disable framebuffer compression on GeminiLake (rev2) URL : https://patchwork.freedesktop.org/series/60090/ State : success == Summary == CI Bug Log - changes from CI_DRM_6055_full -> Patchwork_12974_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12974_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-c: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] ([fdo#103540]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-hsw1/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-c.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-hsw7/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-c.html * igt@kms_flip@2x-plain-flip-fb-recreate: - shard-glk: [PASS][3] -> [FAIL][4] ([fdo#100368]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-glk8/igt@kms_f...@2x-plain-flip-fb-recreate.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-glk2/igt@kms_f...@2x-plain-flip-fb-recreate.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107773]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-skl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [fdo#110403]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103166]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-x.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-apl6/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-apl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-skl: [INCOMPLETE][21] ([fdo#104108] / [fdo#107773]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/shard-skl1/igt@gem_...@in-flight-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/shard-skl10/igt@gem_...@in-flight-suspend.html * igt@i915_suspend@debugfs-reader: - shard-apl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +5 similar issues [23]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
== Series Details ==
Series: series starting with [1/4] drm/i915: Flush the switch-to-kernel-context
harder for DROP_IDLE
URL : https://patchwork.freedesktop.org/series/60367/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6058 -> Patchwork_12976
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/
Known issues
Here are the changes found in Patchwork_12976 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
Possible fixes
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-pnv-d510:[FAIL][5] ([fdo#100368]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6058/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vblank.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vblank.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (53 -> 44)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6058 -> Patchwork_12976
CI_DRM_6058: ebfcf73f5c4c6967e886b60356fbf2784b53cccb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12976: dccaa091ff4e641c9a090e29bb6924417ea7d17f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dccaa091ff4e drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
b3e114606954 drm/i915: Cancel retire_worker on parking
09087104e01b drm/i915: Remove delay for idle_work
76031545f275 drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12976/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Bump signaler priority on adding a waiter
Quoting Chris Wilson (2019-05-07 14:14:01) > Quoting Tvrtko Ursulin (2019-05-07 13:46:45) > > > > On 03/05/2019 12:52, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c > > > b/drivers/gpu/drm/i915/i915_scheduler.c > > > index 380cb7343a10..ff0ca5718f97 100644 > > > --- a/drivers/gpu/drm/i915/i915_scheduler.c > > > +++ b/drivers/gpu/drm/i915/i915_scheduler.c > > > @@ -391,6 +391,16 @@ bool __i915_sched_node_add_dependency(struct > > > i915_sched_node *node, > > > !node_started(signal)) > > > node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN; > > > > > > + /* > > > + * As we do not allow WAIT to preempt inflight requests, > > > + * once we have executed a request, along with triggering > > > + * any execution callbacks, we must preserve its ordering > > > + * within the non-preemptible FIFO. > > > + */ > > > + BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); > > > + if (flags & I915_DEPENDENCY_EXTERNAL) > > > + __bump_priority(signal, __NO_PREEMPTION); > > > + > > > > I don't really follow how can this be okay from here. It gives wait > > priority to every request which has a dependency now. Which sounds not > > far off from removing the priority bump for waiters altogether. Or > > reversing things and giving requests with no priority a boost. > > It treats even inter-context wait equally, and so reduces the effect of > the user wait from the wait/set-domain ioctl and instead includes all > the waits they supply during execbuf. > > It all stems from the way those priorities are ignored for preemption. > Currently we perform the same boost implicitly to all running requests, > which screws up timeslicing, so instead of doing it on the running > request we apply it to the queue and limit it to just the edges that are > susceptible to deadlocks (so in effect we are reducing the number of > requests that have the implicit boost). So one aspect of this is that it does cause the queue to one engine to be submitted ensemble, slightly out of submission order. Instead of per-request submission order, you get an entire client's submission to one engine in a single block as it gets bumped to WAIT, but overall the workload is still in submission order, and there's no preemption of running processes. In early versions (before semaphore wasn't quite so greedy) this did result in each client being batched into one block, more or less, with overlapping clients filling in the bubbles. The positive aspect of that is that, without inducing bubbles, you get much more stable throughput results -- the cost would be less fairness in the short term, though even there we have the NEWCLIENT boost to overcome our inherent unfairness and coarseness. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Tuesday, May 7, 2019 7:37 PM
>To: Sharma, Shashank
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 case
>
>On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
>> From: Uma Shankar
>>
>> Currently input csc for YCbCR to RGB conversion handles only
>> BT601 and Bt709. Extending it to support BT2020 as well.
>>
>> Signed-off-by: Uma Shankar
>> Signed-off-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_sprite.c | 24
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 44aaeac1b2ed..2536e757bec2 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> 0x9EF8, 0x7800, 0xABF8,
>> 0x0, 0x7800, 0x7ED8,
>> },
>> +/*
>> + * BT.2020 full range YCbCr -> full range RGB
>> + * The matrix required is :
>> + * [1.000, 0.000, 1.474,
>> + * 1.000, -0.1645, -0.5713,
>> + * 1.000, 1.8814, 0.]
>> + */
>> +[DRM_COLOR_YCBCR_BT2020] = {
>> +0x7BC8, 0x7800, 0x0,
>> +0x8928, 0x7800, 0xAA88,
>> +0x0, 0x7800, 0x7F10,
>> +},
>> };
>>
>> /* Matrix for Limited Range to Full Range Conversion */ @@ -461,6
>> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> 0x, 0x7918, 0xADA8,
>> 0x0, 0x7918, 0x6870,
>> },
>> +/*
>> + * BT.2020 Limited range YCbCr -> full range RGB
>> + * The matrix required is :
>> + * [1.164, 0.000, 1.717,
>> + * 1.138, -0.1873, -0.6504,
>> + * 1.1380, 2.1417, 0.]
>
>Where are those 1.138 coming from?
Hi Ville,
This is the original YCBCR to RGB BT2020 matrix:
{
1.000, 0.000, 1.4746000,
1.000, -0.16455312684, -0.57135312684,
1.000, 1.8814000, 0.000
};
We have to convert Limited Range YCbCr to Full Range RGB. Hence we need to
apply a scale factor:
yscalefactor = 219.0 * normalizingfactor;
cbcrscalefactor = 224.0 * normalizingfactor;
/* Scale factors are inverted for LR to FR conversion */
yscalefactor = 1.0 / yscalefactor;
cbcrscalefactor = 1.0 / cbcrscalefactor;
This yields the above results.
Regards,
Uma Shankar
>> + */
>> +[DRM_COLOR_YCBCR_BT2020] = {
>> +0x7DC0, 0x7950, 0x0,
>> +0x8A68, 0x7918, 0xAC00,
>> +0x0, 0x7918, 0x6890,
>> +},
>> };
>> const u16 *csc;
>>
>> --
>> 2.17.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Bump signaler priority on adding a waiter
On 07/05/2019 14:14, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-07 13:46:45)
On 03/05/2019 12:52, Chris Wilson wrote:
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event reordering the no-preemption
WAITs. To resolve this issue we currently promote all requests to WAIT
on unsubmission, however this interferes with the timeslicing
requirement that we do not apply any implicit promotion that will defeat
the round-robin timeslice list. (If we automatically promote the active
request it will go back to the head of the queue and not the tail!)
So we need implicit promotion to prevent reordering around semaphores
where we are not allowed to preempt, and we must avoid implicit
promotion on unsubmission. So instead of at unsubmit, if we apply that
implicit promotion on adding the dependency, we avoid the semaphore
deadlock and we also reduce the gains made by the promotion for user
space waiting. Furthermore, by keeping the earlier dependencies at a
higher level, we reduce the search space for timeslicing without
altering runtime scheduling too badly (no dependencies at all will be
assigned a higher priority for rrul).
v2: Limit the bump to external edges (as originally intended) i.e.
between contexts and out to the user.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 12
drivers/gpu/drm/i915/i915_request.c | 9 -
drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
drivers/gpu/drm/i915/i915_scheduler_types.h | 3 ++-
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 4b042893dc0e..5b3d8e33f1cf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -98,12 +98,14 @@ static int live_busywait_preempt(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_unlock;
- ctx_hi->sched.priority = INT_MAX;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = INT_MIN;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
@@ -958,12 +960,14 @@ static int live_preempt_hang(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_spin_lo;
- ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
for_each_engine(engine, i915, id) {
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 8cb3ed5531e3..065da1bcbb4c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -468,15 +468,6 @@ void __i915_request_unsubmit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
- /*
- * As we do not allow WAIT to preempt inflight requests,
- * once we have executed a request, along with triggering
- * any execution callbacks, we must preserve its ordering
- * within the non-preemptible FIFO.
- */
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- request->sched.attr.priority |= __NO_PREEMPTION;
-
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
i915_request_cancel_breadcrumb(request);
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
index 380cb7343a10..ff0ca5718f97 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -391,6 +391,16 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
!node_started(signal))
node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
+ /*
+ * As we do not allow WAIT to preempt inflight requests,
+ * once we have executed a request, along with triggering
+ * any execution callbacks, we must preserve its ordering
+ * within the non-preemptible FIFO.
+ */
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Only reschedule the submission tasklet if preemption is possible
== Series Details == Series: drm/i915: Only reschedule the submission tasklet if preemption is possible URL : https://patchwork.freedesktop.org/series/60368/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Only reschedule the submission tasklet if preemption is possible -O:drivers/gpu/drm/i915/gt/intel_engine.h:124:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/gt/intel_engine.h:124:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_scheduler.h:70:23: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/icl: Add Multi-segmented gamma support
On Tue, May 07, 2019 at 07:26:44PM +0530, Shashank Sharma wrote:
> ICL introduces a new gamma correction mode in display engine, called
> multi-segmented-gamma mode. This mode allows users to program the
> darker region of the gamma curve with sueprfine precision. An
> example use case for this is HDR curves (like PQ ST-2084).
>
> If we plot a gamma correction curve from value range between 0.0 to 1.0,
> ICL's multi-segment has 3 different sections:
> - superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
> - fine segment: 257 values, ranges between 0 - 1/(128)
> - corase segment: 257 values, ranges between 0 - 1
>
> This patch:
> - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
> so that userspace can program with highest precision supported.
> - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
> - Adds functions to program/detect multi-segment gamma.
>
> V2: Addressed review comments from Ville
> - separate function for superfine and fine segments.
> - remove enum for segments.
> - reuse last entry of the LUT as gc_max value.
> - replace if() cond with switch...case in icl_load_luts.
> - add an entry variable, instead of 'word'
>
> V3: Addressed review comments from Ville
> - extra newline
> - s/entry/color/
> - remove LUT size checks
> - program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
> - Change the comments in description of fine and coarse segments,
> and try to make more sense.
> - use 8 * 128 instead of 1024
> - add 1 entry in LUT for GCMAX
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Shashank Sharma
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/intel_color.c | 127 -
> 2 files changed, 124 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ffa2ee70a03d..2f99b585d44b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -749,7 +749,7 @@ static const struct intel_device_info
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_logical_ring_elsq = 1, \
> - .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }
>
> static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 6c341bea514c..c1a9506fd069 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -41,6 +41,8 @@
> #define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
>
> #define LEGACY_LUT_LENGTH256
> +#define ICL_GAMMA_MULTISEG_LUT_LENGTH(256 * 128 * 8)
Unused.
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
> * format). This macro takes the coefficient we want transformed and the
> @@ -767,6 +769,116 @@ static void glk_load_luts(const struct intel_crtc_state
> *crtc_state)
> }
> }
>
> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> +static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
> +{
> + return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> + (color->blue >> 6);
> +}
> +
> +/* ilk+ "12.4" interpolated format (low 6 bits) */
> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> +{
> + return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> + (color->blue & 0x3f);
Blue is missing the shift.
I'm not 100% sure if the ldw vs. udw are the right way around. The spec
has at times been inconsistent with the odd vs. even descriptions,
sometimes even contradicting itself. Also it never really defines
whether it starts counting dwords from from 0 or 1, so not sure what
odd and even actually mean. Can I presume someone has checked this
on actual hardware?
> +}
> +
> +static void
> +icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> +const struct drm_color_lut *color)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), color->red);
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), color->green);
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), color->blue);
> +}
> +
> +static void
> +icl_program_gamma_superfine_segment(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + const
[Intel-gfx] [PATCH v3 3/4] drm/i915: Rename ivb_load_lut_10_max
This patch renames function ivb_load_lut_10_max to
ivb_load_lut_ext_max.
V3: Added Vill'es r-b.
Cc: Uma Shankar
Suggested-by: Ville Syrjala
Reviewed-by: Ville Syrjala
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_color.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 962db1236970..6c341bea514c 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -607,7 +607,7 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
}
-static void ivb_load_lut_10_max(struct intel_crtc *crtc)
+static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
@@ -640,7 +640,7 @@ static void ivb_load_luts(const struct intel_crtc_state
*crtc_state)
} else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
ivb_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(0));
- ivb_load_lut_10_max(crtc);
+ ivb_load_lut_ext_max(crtc);
ivb_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(512));
} else {
@@ -648,7 +648,7 @@ static void ivb_load_luts(const struct intel_crtc_state
*crtc_state)
ivb_load_lut_10(crtc, blob,
PAL_PREC_INDEX_VALUE(0));
- ivb_load_lut_10_max(crtc);
+ ivb_load_lut_ext_max(crtc);
}
}
@@ -663,7 +663,7 @@ static void bdw_load_luts(const struct intel_crtc_state
*crtc_state)
} else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
bdw_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(0));
- ivb_load_lut_10_max(crtc);
+ ivb_load_lut_ext_max(crtc);
bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(512));
} else {
@@ -671,7 +671,7 @@ static void bdw_load_luts(const struct intel_crtc_state
*crtc_state)
bdw_load_lut_10(crtc, blob,
PAL_PREC_INDEX_VALUE(0));
- ivb_load_lut_10_max(crtc);
+ ivb_load_lut_ext_max(crtc);
}
}
@@ -763,7 +763,7 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
i9xx_load_luts(crtc_state);
} else {
bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
- ivb_load_lut_10_max(crtc);
+ ivb_load_lut_ext_max(crtc);
}
}
@@ -780,7 +780,7 @@ static void icl_load_luts(const struct intel_crtc_state
*crtc_state)
i9xx_load_luts(crtc_state);
} else {
bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
- ivb_load_lut_10_max(crtc);
+ ivb_load_lut_ext_max(crtc);
}
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/4] drm/i915/icl: Add register definitions for Multi Segmented gamma
From: Uma Shankar
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
- Use REG_GENMASK() and REG_BIT()
V3: Addressed Ville's comments:
- Put comments at the end of line.
- Change the comment at start of ICL multisegmented gamma registers.
Added Ville's r-b
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..8b77c067e26b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7198,7 +7198,8 @@ enum {
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
#define GAMMA_MODE_MODE_12BIT (2 << 0)
-#define GAMMA_MODE_MODE_SPLIT (3 << 0)
+#define GAMMA_MODE_MODE_SPLIT (3 << 0) /* ivb-bdw */
+#define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0) /* icl + */
/* DMC/CSR */
#define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
@@ -10145,6 +10146,22 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* ICL Multi segmented gamma */
+#define _PAL_PREC_MULTI_SEG_INDEX_A0x4A408
+#define _PAL_PREC_MULTI_SEG_INDEX_B0x4AC08
+#define PAL_PREC_MULTI_SEGMENT_AUTO_INCREMENT REG_BIT(15)
+#define PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK REG_GENMASK(4, 0)
+
+#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
+#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
+
+#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_INDEX_A, \
+ _PAL_PREC_MULTI_SEG_INDEX_B)
+#define PREC_PAL_MULTI_SEG_DATA(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_DATA_A, \
+ _PAL_PREC_MULTI_SEG_DATA_B)
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/4] Enable Multi-segmented-gamma for ICL
This patch series enables programming of Multi-segmented-gamma palette for ICL. Shashank Sharma (3): drm/i915: Change gamma/degamma_lut_size data type to u32 drm/i915: Rename ivb_load_lut_10_max drm/i915/icl: Add Multi-segmented gamma support Uma Shankar (1): drm/i915/icl: Add register definitions for Multi Segmented gamma drivers/gpu/drm/i915/i915_pci.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 19 ++- drivers/gpu/drm/i915/intel_color.c | 141 +-- drivers/gpu/drm/i915/intel_device_info.h | 4 +- 4 files changed, 151 insertions(+), 15 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
> From: Uma Shankar
>
> Currently input csc for YCbCR to RGB conversion handles only
> BT601 and Bt709. Extending it to support BT2020 as well.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 44aaeac1b2ed..2536e757bec2 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
> 0x9EF8, 0x7800, 0xABF8,
> 0x0, 0x7800, 0x7ED8,
> },
> + /*
> + * BT.2020 full range YCbCr -> full range RGB
> + * The matrix required is :
> + * [1.000, 0.000, 1.474,
> + * 1.000, -0.1645, -0.5713,
> + * 1.000, 1.8814, 0.]
> + */
> + [DRM_COLOR_YCBCR_BT2020] = {
> + 0x7BC8, 0x7800, 0x0,
> + 0x8928, 0x7800, 0xAA88,
> + 0x0, 0x7800, 0x7F10,
> + },
> };
>
> /* Matrix for Limited Range to Full Range Conversion */
> @@ -461,6 +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
> 0x, 0x7918, 0xADA8,
> 0x0, 0x7918, 0x6870,
> },
> + /*
> + * BT.2020 Limited range YCbCr -> full range RGB
> + * The matrix required is :
> + * [1.164, 0.000, 1.717,
> + * 1.138, -0.1873, -0.6504,
> + * 1.1380, 2.1417, 0.]
Where are those 1.138 coming from?
> + */
> + [DRM_COLOR_YCBCR_BT2020] = {
> + 0x7DC0, 0x7950, 0x0,
> + 0x8A68, 0x7918, 0xAC00,
> + 0x0, 0x7918, 0x6890,
> + },
> };
> const u16 *csc;
>
> --
> 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
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Add support for tracking wakerefs w/o power-on guarantee
Quoting Imre Deak (2019-05-03 00:26:39) > @@ -4521,12 +4602,12 @@ void intel_runtime_pm_cleanup(struct drm_i915_private > *i915) > struct i915_runtime_pm *rpm = >runtime_pm; > int count; > > - count = atomic_fetch_inc(>wakeref_count); /* balance untrack */ > + count = atomic_fetch_inc(>wakeref_track_count); /* balance > untrack */ > WARN(count, > -"i915->runtime_pm.wakeref_count=%d on cleanup\n", > +"i915->runtime_pm.wakeref_track_count=%d on cleanup\n", > count); > > - untrack_intel_runtime_pm_wakeref(i915); > + untrack_intel_runtime_pm_wakeref_raw(i915); So this basically sums up the dilemma. The warning here should be if the wakeref_count != 0 (meaning we have someone still using the device) at cleanup. That track_count may be zero just implies loss of available information. Looking through this, I think it would be better if the track_count was pushed into the runtime_pm.debug substruct, and really does only mean the number of wakerefs being tracked by the debug backend. I believe that helps with the separation of intent -- my only condition for the design is that if you have a wakeref cookie, it is clear that you hold a reference to the runtime-pm. (Where you want to add new api for untracked wakerefs... I need to go back to the end again and see if you really do need untracked wakerefs and if not the async power domain merely needs to track it own wakeref independently of its clients.) Bah. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/4] drm/i915/icl: Add Multi-segmented gamma support
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
V3: Addressed review comments from Ville
- extra newline
- s/entry/color/
- remove LUT size checks
- program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
- Change the comments in description of fine and coarse segments,
and try to make more sense.
- use 8 * 128 instead of 1024
- add 1 entry in LUT for GCMAX
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/intel_color.c | 127 -
2 files changed, 124 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..2f99b585d44b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,7 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..c1a9506fd069 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,8 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +769,116 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *color)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), color->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), color->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), color->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ /*
+* Every entry in the multi-segment LUT is corresponding to a superfine
+* segment step which is 1/(8 * 128 * 256).
+*
+* Superfine segment has 9 entries, corresponding to values
+* 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 * 256).
+*/
+ I915_WRITE(PREC_PAL_MULTI_SEG_INDEX(pipe), PAL_PREC_AUTO_INCREMENT);
+
+ for (i = 0; i < 9; i++) {
+ const struct drm_color_lut *entry = [i];
+
+
[Intel-gfx] [PATCH v3 1/4] drm/i915: Change gamma/degamma_lut_size data type to u32
Currently, data type of gamma_lut_size & degamma_lut_size elements
in intel_device_info is u16, which means it can accommodate maximum
64k values. In case of ICL multisegmented gamma, the size of gamma
LUT is 256K.
This patch changes the data type of both of these elements to u32.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_device_info.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 5a2e17d6146b..67677c356716 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -179,8 +179,8 @@ struct intel_device_info {
int cursor_offsets[I915_MAX_PIPES];
struct color_luts {
- u16 degamma_lut_size;
- u16 gamma_lut_size;
+ u32 degamma_lut_size;
+ u32 gamma_lut_size;
u32 degamma_lut_tests;
u32 gamma_lut_tests;
} color;
--
2.17.1
___
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/4] drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
== Series Details ==
Series: series starting with [1/4] drm/i915: Flush the switch-to-kernel-context
harder for DROP_IDLE
URL : https://patchwork.freedesktop.org/series/60367/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
76031545f275 drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
-:13: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 79ffac8599c4 ("drm/i915: Invert
the GEM wakeref hierarchy")'
#13:
References: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
total: 1 errors, 0 warnings, 0 checks, 28 lines checked
09087104e01b drm/i915: Remove delay for idle_work
b3e114606954 drm/i915: Cancel retire_worker on parking
dccaa091ff4e drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8 02/10] drm: Parse HDR metadata info from EDID
On 4/9/19 12:44 PM, Uma Shankar wrote:
> HDR metadata block is introduced in CEA-861.3 spec.
> Parsing the same to get the panel's HDR metadata.
>
> v2: Rebase and added Ville's POC changes to the patch.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Addressed Shashank's comment and added his RB.
>
> v6: Addressed Jonas Karlman review comments.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 52
> ++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2c22ea4..1fc371b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2830,6 +2830,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK 0x04
> +#define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> #define EXT_VIDEO_DATA_BLOCK_4200x0E
> @@ -3577,6 +3578,12 @@ static int add_3d_struct_modes(struct drm_connector
> *connector, u16 structure,
> }
>
> static int
> +cea_db_payload_len_ext(const u8 *db)
> +{
> + return (db[0] & 0x1f) - 1;
> +}
> +
> +static int
> cea_db_extended_tag(const u8 *db)
> {
> return db[1];
> @@ -3812,6 +3819,49 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != HDR_STATIC_METADATA_BLOCK)
> + return false;
Shouldn't this just be cea_db_extended_tag(db) != HDR_STATIC_METADATA_BLOCK?
Also, the other functions all check that we're given a valid here here with:
if (!cea_db_payload_len_ext(db))
return false;
Is there any reason this isn't done here?
> +
> + return true;
> +}
> +
> +static uint8_t eotf_supported(const u8 *edid_ext)
> +{
> + return edid_ext[2] &
> + (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
> + BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
> + BIT(HDMI_EOTF_SMPTE_ST2084));
> +}
> +
> +static uint8_t hdr_metadata_type(const u8 *edid_ext)
> +{
> + return edid_ext[3] &
> + BIT(HDMI_STATIC_METADATA_TYPE1);
> +}
> +
> +static void
> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
> +{
> + u16 len;
> +
> + len = cea_db_payload_len_ext(db);
> + connector->hdr_sink_metadata.hdmi_type1.eotf = eotf_supported(db);
> + connector->hdr_sink_metadata.hdmi_type1.metadata_type =
> + hdr_metadata_type(db);
While metadata_type is assigned here like it should be, it isn't
assigned to the outer metadata_type in the hdr_sink_metadata. I also
can't see anything in the other patches that assigns this anywhere.
Shouldn't it also be set here?
> +
> + if (len >= 4)
> + connector->hdr_sink_metadata.hdmi_type1.max_cll = db[4];
> + if (len >= 5)
> + connector->hdr_sink_metadata.hdmi_type1.max_fall = db[5];
> + if (len >= 6)
> + connector->hdr_sink_metadata.hdmi_type1.min_cll = db[6];
> +}
> +
> static void
> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
> {
> @@ -4439,6 +4489,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_y420cmdb_bitmap(connector, db);
> if (cea_db_is_vcdb(db))
> drm_parse_vcdb(connector, db);
> + if (cea_db_is_hdmi_hdr_metadata_block(db))
> + drm_parse_hdr_metadata_block(connector, db);
> }
> }
>
>
Nicholas Kazlauskas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Bump signaler priority on adding a waiter
Quoting Tvrtko Ursulin (2019-05-07 13:46:45)
>
> On 03/05/2019 12:52, Chris Wilson wrote:
> > The handling of the no-preemption priority level imposes the restriction
> > that we need to maintain the implied ordering even though preemption is
> > disabled. Otherwise we may end up with an AB-BA deadlock across multiple
> > engine due to a real preemption event reordering the no-preemption
> > WAITs. To resolve this issue we currently promote all requests to WAIT
> > on unsubmission, however this interferes with the timeslicing
> > requirement that we do not apply any implicit promotion that will defeat
> > the round-robin timeslice list. (If we automatically promote the active
> > request it will go back to the head of the queue and not the tail!)
> >
> > So we need implicit promotion to prevent reordering around semaphores
> > where we are not allowed to preempt, and we must avoid implicit
> > promotion on unsubmission. So instead of at unsubmit, if we apply that
> > implicit promotion on adding the dependency, we avoid the semaphore
> > deadlock and we also reduce the gains made by the promotion for user
> > space waiting. Furthermore, by keeping the earlier dependencies at a
> > higher level, we reduce the search space for timeslicing without
> > altering runtime scheduling too badly (no dependencies at all will be
> > assigned a higher priority for rrul).
> >
> > v2: Limit the bump to external edges (as originally intended) i.e.
> > between contexts and out to the user.
> >
> > Testcase: igt/gem_concurrent_blit
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 12
> > drivers/gpu/drm/i915/i915_request.c | 9 -
> > drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 3 ++-
> > 4 files changed, 21 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > index 4b042893dc0e..5b3d8e33f1cf 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > @@ -98,12 +98,14 @@ static int live_busywait_preempt(void *arg)
> > ctx_hi = kernel_context(i915);
> > if (!ctx_hi)
> > goto err_unlock;
> > - ctx_hi->sched.priority = INT_MAX;
> > + ctx_hi->sched.priority =
> > + I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
> >
> > ctx_lo = kernel_context(i915);
> > if (!ctx_lo)
> > goto err_ctx_hi;
> > - ctx_lo->sched.priority = INT_MIN;
> > + ctx_lo->sched.priority =
> > + I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
> >
> > obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> > if (IS_ERR(obj)) {
> > @@ -958,12 +960,14 @@ static int live_preempt_hang(void *arg)
> > ctx_hi = kernel_context(i915);
> > if (!ctx_hi)
> > goto err_spin_lo;
> > - ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
> > + ctx_hi->sched.priority =
> > + I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
> >
> > ctx_lo = kernel_context(i915);
> > if (!ctx_lo)
> > goto err_ctx_hi;
> > - ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
> > + ctx_lo->sched.priority =
> > + I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
> >
> > for_each_engine(engine, i915, id) {
> > struct i915_request *rq;
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 8cb3ed5531e3..065da1bcbb4c 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -468,15 +468,6 @@ void __i915_request_unsubmit(struct i915_request
> > *request)
> > /* We may be recursing from the signal callback of another i915 fence
> > */
> > spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
> >
> > - /*
> > - * As we do not allow WAIT to preempt inflight requests,
> > - * once we have executed a request, along with triggering
> > - * any execution callbacks, we must preserve its ordering
> > - * within the non-preemptible FIFO.
> > - */
> > - BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal
> > */
> > - request->sched.attr.priority |= __NO_PREEMPTION;
> > -
> > if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
> > i915_request_cancel_breadcrumb(request);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 380cb7343a10..ff0ca5718f97 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -391,6 +391,16 @@ bool __i915_sched_node_add_dependency(struct
> > i915_sched_node *node,
> > !node_started(signal))
> > node->flags |=
[Intel-gfx] [PATCH v3 1/2] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
Framebuffer formats P01x are supported by GLK, but the function which
handles CSC on plane color control register, still expectes the input
buffer to be REC709. This can cause inaccurate output for direct P01x
flips.
This patch checks if the color_encoding property is set to YCBCR_2020,
and enables the corresponding color conversion mode on plane CSC.
PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
V2: Expose the YCBCR_BT2020 value in enum values of supported encoding
formats.
V3: Fixed the missing BIT() while setting supported_encodings
(Lukas, team Kodi)
Cc: Ville Syrjala
Cc: Maarten Lankhorst
Cc: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 26 --
drivers/gpu/drm/i915/intel_sprite.c | 10 --
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dd65d7c521c1..2d4d3128bf1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
to_i915(plane_state->base.plane->dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
- u32 plane_color_ctl = 0;
+ u32 color_ctl = 0;
- plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
- plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
+ color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+ color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
- if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
- plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
- else
- plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+ switch (plane_state->base.color_encoding) {
+ case DRM_COLOR_YCBCR_BT709:
+ color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+ break;
+ case DRM_COLOR_YCBCR_BT2020:
+ color_ctl |= PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
+ break;
+ default:
+ color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+ }
if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
- plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
+ color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
- plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
+ color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
}
- return plane_color_ctl;
+ return color_ctl;
}
static int
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2913e89280d7..44aaeac1b2ed 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -2238,6 +2238,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
struct intel_plane *plane;
enum drm_plane_type plane_type;
unsigned int supported_rotations;
+ unsigned int supported_encodings;
unsigned int possible_crtcs;
const u64 *modifiers;
const u32 *formats;
@@ -2325,9 +2326,14 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0,
supported_rotations);
+ supported_encodings = BIT(DRM_COLOR_YCBCR_BT601) |
+ BIT(DRM_COLOR_YCBCR_BT709);
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ supported_encodings |= BIT(DRM_COLOR_YCBCR_BT2020);
+
drm_plane_create_color_properties(>base,
- BIT(DRM_COLOR_YCBCR_BT601) |
- BIT(DRM_COLOR_YCBCR_BT709),
+ supported_encodings,
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
DRM_COLOR_YCBCR_BT709,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
From: Uma Shankar
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 44aaeac1b2ed..2536e757bec2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
0x9EF8, 0x7800, 0xABF8,
0x0, 0x7800, 0x7ED8,
},
+ /*
+* BT.2020 full range YCbCr -> full range RGB
+* The matrix required is :
+* [1.000, 0.000, 1.474,
+* 1.000, -0.1645, -0.5713,
+* 1.000, 1.8814, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7BC8, 0x7800, 0x0,
+ 0x8928, 0x7800, 0xAA88,
+ 0x0, 0x7800, 0x7F10,
+ },
};
/* Matrix for Limited Range to Full Range Conversion */
@@ -461,6 +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
0x, 0x7918, 0xADA8,
0x0, 0x7918, 0x6870,
},
+ /*
+* BT.2020 Limited range YCbCr -> full range RGB
+* The matrix required is :
+* [1.164, 0.000, 1.717,
+* 1.138, -0.1873, -0.6504,
+* 1.1380, 2.1417, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7DC0, 0x7950, 0x0,
+ 0x8A68, 0x7918, 0xAC00,
+ 0x0, 0x7918, 0x6890,
+ },
};
const u16 *csc;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Bump signaler priority on adding a waiter
On 03/05/2019 12:52, Chris Wilson wrote:
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event reordering the no-preemption
WAITs. To resolve this issue we currently promote all requests to WAIT
on unsubmission, however this interferes with the timeslicing
requirement that we do not apply any implicit promotion that will defeat
the round-robin timeslice list. (If we automatically promote the active
request it will go back to the head of the queue and not the tail!)
So we need implicit promotion to prevent reordering around semaphores
where we are not allowed to preempt, and we must avoid implicit
promotion on unsubmission. So instead of at unsubmit, if we apply that
implicit promotion on adding the dependency, we avoid the semaphore
deadlock and we also reduce the gains made by the promotion for user
space waiting. Furthermore, by keeping the earlier dependencies at a
higher level, we reduce the search space for timeslicing without
altering runtime scheduling too badly (no dependencies at all will be
assigned a higher priority for rrul).
v2: Limit the bump to external edges (as originally intended) i.e.
between contexts and out to the user.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 12
drivers/gpu/drm/i915/i915_request.c | 9 -
drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
drivers/gpu/drm/i915/i915_scheduler_types.h | 3 ++-
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 4b042893dc0e..5b3d8e33f1cf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -98,12 +98,14 @@ static int live_busywait_preempt(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_unlock;
- ctx_hi->sched.priority = INT_MAX;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = INT_MIN;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
@@ -958,12 +960,14 @@ static int live_preempt_hang(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_spin_lo;
- ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
for_each_engine(engine, i915, id) {
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 8cb3ed5531e3..065da1bcbb4c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -468,15 +468,6 @@ void __i915_request_unsubmit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
- /*
-* As we do not allow WAIT to preempt inflight requests,
-* once we have executed a request, along with triggering
-* any execution callbacks, we must preserve its ordering
-* within the non-preemptible FIFO.
-*/
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- request->sched.attr.priority |= __NO_PREEMPTION;
-
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
i915_request_cancel_breadcrumb(request);
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
index 380cb7343a10..ff0ca5718f97 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -391,6 +391,16 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
!node_started(signal))
node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
+ /*
+* As we do not allow WAIT to preempt inflight requests,
+* once we have executed a request, along with triggering
+* any execution callbacks, we must preserve its ordering
+* within the non-preemptible FIFO.
+*/
+ BUILD_BUG_ON(__NO_PREEMPTION &
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915/gtt: grab wakeref in gen6_alloc_va_range
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60364/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6057 -> Patchwork_12975
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12975 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12975, 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_12975/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12975:
### IGT changes ###
Possible regressions
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-r: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6057/fi-kbl-r/igt@kms_f...@basic-flip-vs-modeset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12975/fi-kbl-r/igt@kms_f...@basic-flip-vs-modeset.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_basic@readonly-vebox:
- {fi-cml-u}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6057/fi-cml-u/igt@gem_exec_ba...@readonly-vebox.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12975/fi-cml-u/igt@gem_exec_ba...@readonly-vebox.html
New tests
-
New tests have been introduced between CI_DRM_6057 and Patchwork_12975:
### New IGT tests (2) ###
* igt@i915_selftest@live_blt:
- Statuses : 40 pass(s)
- Exec time: [0.37, 1.96] s
* igt@i915_selftest@live_client:
- Statuses : 40 pass(s)
- Exec time: [0.38, 2.00] s
Known issues
Here are the changes found in Patchwork_12975 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gtt:
- fi-glk-dsi: [PASS][5] -> [INCOMPLETE][6] ([fdo#103359] /
[k.org#198133])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6057/fi-glk-dsi/igt@i915_selftest@live_gtt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12975/fi-glk-dsi/igt@i915_selftest@live_gtt.html
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6057/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12975/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [DMESG-FAIL][9] ([fdo#110620]) -> [INCOMPLETE][10]
([fdo#103927] / [fdo#110624])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6057/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12975/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
* igt@runner@aborted:
- fi-apl-guc: [FAIL][11] ([fdo#110622]) -> [FAIL][12] ([fdo#110624])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6057/fi-apl-guc/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12975/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (51 -> 44)
--
Additional (1): fi-icl-u2
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper
Build changes
-
* Linux: CI_DRM_6057 -> Patchwork_12975
CI_DRM_6057: d3aeed5c84b415c6113d04e9574e7516e401fdb7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12975: 12c7827ed80a6073b923293aa3e6995adf3df94d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
12c7827ed80a drm/i915: add in-kernel blitter client
85a64e026cc5 drm/i915/gtt: grab wakeref in gen6_alloc_va_range
== Logs ==
For more details see:
Re: [Intel-gfx] [PULL] gvt-next-fixes
Thanks, pulled this now. Regards, Joonas Quoting Zhenyu Wang (2019-05-07 12:05:58) > > Hi, > > Here's gvt-next-fixes for 5.2-rc, which includes one revert for BXT > regression, one missed context mmio reg after RCS renaming, sanitize > display buffer size calculation and some klocwork warning/error fixes. > > Thanks > -- > The following changes since commit 447811a686e8da7325516a78069ccfbd139ef1a7: > > drm/i915/icl: Fix MG_DP_MODE() register programming (2019-04-24 09:39:11 > +0300) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2019-05-07 > > for you to fetch changes up to 75fdb811d93c8aa4a9f73b63db032b1e6a8668ef: > > drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list (2019-05-05 > 17:02:25 +0800) > > > gvt-next-fixes-2019-05-07 > > - Revert MCHBAR save range change for BXT regression (Yakui) > - Align display dmabuf size for bytes instead of error-prone pages (Xiong) > - Fix one context MMIO save/restore after RCS0 name change (Colin) > - Misc klocwork warning/errors fixes (Aleksei) > > > Aleksei Gimbitskii (4): > drm/i915/gvt: Remove typedef and let the enumeration starts from zero > drm/i915/gvt: Do not copy the uninitialized pointer from fb_info > drm/i915/gvt: Use snprintf() to prevent possible buffer overflow. > drm/i915/gvt: Check if get_next_pt_type() always returns a valid value > > Colin Xu (1): > drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list > > Xiong Zhang (1): > drm/i915/gvt: Change fb_info->size from pages to bytes > > Zhao Yakui (1): > drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 > MCHBAR to optimize gvt-g boot time" > > drivers/gpu/drm/i915/gvt/debugfs.c | 4 ++-- > drivers/gpu/drm/i915/gvt/dmabuf.c | 19 --- > drivers/gpu/drm/i915/gvt/gtt.c | 15 +-- > drivers/gpu/drm/i915/gvt/gtt.h | 16 > drivers/gpu/drm/i915/gvt/handlers.c | 4 ++-- > drivers/gpu/drm/i915/gvt/mmio_context.c | 1 + > drivers/gpu/drm/i915/gvt/reg.h | 3 --- > drivers/gpu/drm/i915/gvt/scheduler.c| 2 +- > 8 files changed, 31 insertions(+), 33 deletions(-) > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/execlists: Don't apply priority boost for resets
Do not treat reset as a normal preemption event and avoid giving the
guilty request a priority boost for simply being active at the time of
reset.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 5580b6f1aa0c..e6ae20292f2c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -371,11 +371,11 @@ static void unwind_wa_tail(struct i915_request *rq)
}
static struct i915_request *
-__unwind_incomplete_requests(struct intel_engine_cs *engine)
+__unwind_incomplete_requests(struct intel_engine_cs *engine, int boost)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
+ int prio = I915_PRIORITY_INVALID | boost;
lockdep_assert_held(>timeline.lock);
@@ -419,8 +419,9 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
* in the priority queue, but they will not gain immediate access to
* the GPU.
*/
- if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(active)) {
- prio |= ACTIVE_PRIORITY;
+ if (~prio & boost && __i915_request_has_started(active)) {
+ prio |= boost;
+ GEM_BUG_ON(active->sched.attr.priority >= prio);
active->sched.attr.priority = prio;
list_move_tail(>sched.link,
i915_sched_lookup_priolist(engine, prio));
@@ -435,7 +436,7 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- return __unwind_incomplete_requests(engine);
+ return __unwind_incomplete_requests(engine, 0);
}
static inline void
@@ -656,7 +657,8 @@ static void complete_preempt_context(struct
intel_engine_execlists *execlists)
execlists_cancel_port_requests(execlists);
__unwind_incomplete_requests(container_of(execlists,
struct intel_engine_cs,
- execlists));
+ execlists),
+ACTIVE_PRIORITY);
}
static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -1909,7 +1911,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
execlists_cancel_port_requests(execlists);
/* Push back any incomplete requests for replay after the reset. */
- rq = __unwind_incomplete_requests(engine);
+ rq = __unwind_incomplete_requests(engine, 0);
if (!rq)
goto out_replay;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
On 07/05/2019 13:11, Chris Wilson wrote:
To complete the idle worker, we must complete 2 passes of wait-for-idle.
At the end of the first pass, we queue a switch-to-kernel-context and
may only idle after waiting for its completion. Speed up the flush_work
by doing the wait explicitly, which then allows us to remove the
unbounded loop trying to complete the flush_work in the next patch.
References: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Testcase: igt/gem_ppgtt/flind-and-close-vma-leak
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..f60aed7747e5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3901,14 +3901,26 @@ i915_drop_caches_set(void *data, u64 val)
/* No need to check and wait for gpu resets, only libdrm auto-restarts
* on ioctls on -EAGAIN. */
- if (val & (DROP_ACTIVE | DROP_RETIRE | DROP_RESET_SEQNO)) {
+ if (val & (DROP_ACTIVE | DROP_IDLE | DROP_RETIRE | DROP_RESET_SEQNO)) {
int ret;
ret = mutex_lock_interruptible(>drm.struct_mutex);
if (ret)
return ret;
- if (val & DROP_ACTIVE)
+ /*
+* To finish the flush of the idle_worker, we must complete
+* the switch-to-kernel-context, which requires a double
+* pass through wait_for_idle: first queues the switch,
+* second waits for the switch.
+*/
+ if (ret == 0 && val & (DROP_IDLE | DROP_ACTIVE))
+ ret = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED,
+MAX_SCHEDULE_TIMEOUT);
+
+ if (ret == 0 && val & DROP_IDLE)
ret = i915_gem_wait_for_idle(i915,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_LOCKED,
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 11/13] drm/i915: Pass i915_sched_node around internally
Quoting Tvrtko Ursulin (2019-05-07 13:12:05) > > On 03/05/2019 12:52, Chris Wilson wrote: > > To simplify the next patch, update bump_priority and schedule to accept > > the internal i915_sched_ndoe directly and not expect a request pointer. > > > > add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7) > > Function old new delta > > i915_schedule_bump_priority 109 113 +4 > > i915_schedule 50 54 +4 > > __i915_schedule 922 907 -15 > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_scheduler.c | 33 +++ > > 1 file changed, 18 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c > > b/drivers/gpu/drm/i915/i915_scheduler.c > > index 4a95cf2201a7..380cb7343a10 100644 > > --- a/drivers/gpu/drm/i915/i915_scheduler.c > > +++ b/drivers/gpu/drm/i915/i915_scheduler.c > > @@ -189,7 +189,7 @@ static void kick_submission(struct intel_engine_cs > > *engine, int prio) > > tasklet_hi_schedule(>execlists.tasklet); > > } > > > > -static void __i915_schedule(struct i915_request *rq, > > +static void __i915_schedule(struct i915_sched_node *rq, > > Can you not use rq for sched node, but perhaps node? We use node later on. I kept with rq to try and keep the patch small, and stick to the current semantics. We could reuse node... That looks like it is semantically clean. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Only reschedule the submission tasklet if preemption is possible
If we couple the scheduler more tightly with the execlists policy, we
can apply the preemption policy to the question of whether we need to
kick the tasklet at all for this priority bump.
v2: Rephrase it as a core i915 policy and not an execlists foible.
v3: Pull the kick together.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 18 ---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 7 -
drivers/gpu/drm/i915/i915_request.c | 2 --
drivers/gpu/drm/i915/i915_scheduler.c | 34 -
drivers/gpu/drm/i915/i915_scheduler.h | 18 +++
drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
7 files changed, 47 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index f5b0f27cecb6..06d785533502 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -106,24 +106,6 @@ hangcheck_action_to_str(const enum
intel_engine_hangcheck_action a)
void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
-static inline bool __execlists_need_preempt(int prio, int last)
-{
- /*
-* Allow preemption of low -> normal -> high, but we do
-* not allow low priority tasks to preempt other low priority
-* tasks under the impression that latency for low priority
-* tasks does not matter (as much as background throughput),
-* so kiss.
-*
-* More naturally we would write
-* prio >= max(0, last);
-* except that we wish to prevent triggering preemption at the same
-* priority level: the task that is running should remain running
-* to preserve FIFO ordering of dependencies.
-*/
- return prio > max(I915_PRIORITY_NORMAL - 1, last);
-}
-
static inline void
execlists_set_active(struct intel_engine_execlists *execlists,
unsigned int bit)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 5580b6f1aa0c..636df21983dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -252,8 +252,8 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* ourselves, ignore the request.
*/
last_prio = effective_prio(rq);
- if (!__execlists_need_preempt(engine->execlists.queue_priority_hint,
- last_prio))
+ if (!i915_scheduler_need_preempt(engine->execlists.queue_priority_hint,
+last_prio))
return false;
/*
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 84538f69185b..4b042893dc0e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -638,14 +638,19 @@ static struct i915_request *dummy_request(struct
intel_engine_cs *engine)
GEM_BUG_ON(i915_request_completed(rq));
i915_sw_fence_init(>submit, dummy_notify);
- i915_sw_fence_commit(>submit);
+ set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
return rq;
}
static void dummy_request_free(struct i915_request *dummy)
{
+ /* We have to fake the CS interrupt to kick the next request */
+ i915_sw_fence_commit(>submit);
+
i915_request_mark_complete(dummy);
+ dma_fence_signal(>fence);
+
i915_sched_node_fini(>sched);
i915_sw_fence_fini(>submit);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e0be00c07c24..fa955b7b6def 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1415,9 +1415,7 @@ long i915_request_wait(struct i915_request *rq,
if (flags & I915_WAIT_PRIORITY) {
if (!i915_request_started(rq) && INTEL_GEN(rq->i915) >= 6)
gen6_rps_boost(rq);
- local_bh_disable(); /* suspend tasklets for reprioritisation */
i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
- local_bh_enable(); /* kick tasklets en masse */
}
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 39bc4f54e272..ec22c3fe7360 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -261,16 +261,27 @@ sched_lock_engine(const struct i915_sched_node *node,
return engine;
}
-static bool inflight(const struct i915_request *rq,
-const struct intel_engine_cs *engine)
+static inline int rq_prio(const struct i915_request *rq)
{
- const struct i915_request *active;
+ return rq->sched.attr.priority | __NO_PREEMPTION;
+}
+
+static void kick_submission(struct
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/gtt: grab wakeref in gen6_alloc_va_range
== Series Details == Series: series starting with [v2,1/2] drm/i915/gtt: grab wakeref in gen6_alloc_va_range URL : https://patchwork.freedesktop.org/series/60364/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/gtt: grab wakeref in gen6_alloc_va_range -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1752:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1752:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1755:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1755:9: warning: expression using sizeof(void) Commit: drm/i915: add in-kernel blitter client +drivers/gpu/drm/i915/i915_gem_client_blt.h:11:22: warning: symbol 'ce' was not declared. Should it be static? +./include/linux/reservation.h:220:20: warning: dereference of noderef expression +./include/linux/reservation.h:220:45: warning: dereference of noderef expression +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/gtt: grab wakeref in gen6_alloc_va_range
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60364/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
85a64e026cc5 drm/i915/gtt: grab wakeref in gen6_alloc_va_range
12c7827ed80a drm/i915: add in-kernel blitter client
-:43: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#43: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:183:
+#define XY_COLOR_BLT_CMD (2<<29 | 0x50<<22)
^
-:43: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#43: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:183:
+#define XY_COLOR_BLT_CMD (2<<29 | 0x50<<22)
^
-:48: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#48:
new file mode 100644
-:308: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!work"
#308: FILE: drivers/gpu/drm/i915/i915_gem_client_blt.c:256:
+ if (work == NULL) {
-:410: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#410: FILE: drivers/gpu/drm/i915/i915_gem_object_blt.c:28:
+ *cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (7-2);
^
-:419: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#419: FILE: drivers/gpu/drm/i915/i915_gem_object_blt.c:37:
+ *cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (6-2);
^
-:539: WARNING:LINE_SPACING: Missing a blank line after declarations
#539: FILE: drivers/gpu/drm/i915/selftests/i915_gem_client_blt.c:18:
+ struct rnd_state prng;
+ IGT_TIMEOUT(end);
-:676: WARNING:LINE_SPACING: Missing a blank line after declarations
#676: FILE: drivers/gpu/drm/i915/selftests/i915_gem_object_blt.c:18:
+ struct rnd_state prng;
+ IGT_TIMEOUT(end);
total: 0 errors, 3 warnings, 5 checks, 719 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem
Acked-by: Satyeshwar Singh
-Original Message-
From: Roper, Matthew D
Sent: Monday, May 6, 2019 2:59 PM
To: Daniel Vetter
Cc: C, Ramalingam ; Vetter, Daniel
; intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; Singh, Satyeshwar
Subject: Re: [Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem
On Mon, May 06, 2019 at 06:56:03PM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 06:52:56PM +0530, Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
> > /lib/firmware/display_hdcp_srm.bin
> >
> > SRM table is parsed and stored at drm_hdcp.c, with functions
> > exported for the services for revocation check from drivers (which
> > implements the HDCP authentication)
> >
> > This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> >
> > v2:
> > moved the uAPI to request_firmware_direct() [Daniel]
> > v3:
> > kdoc added. [Daniel]
> > srm_header unified and bit field definitions are removed. [Daniel]
> > locking improved. [Daniel]
> > vrl length violation is fixed. [Daniel]
> >
> > Signed-off-by: Ramalingam C
> > Suggested-by: Daniel Vetter
>
> Found a few small details to polish, but looks good to me. With the
> details addressed:
>
> Reviewed-by: Daniel Vetter
>
> We also still need an ack on the firmware blob approach from Matt
> Roper or someone else at iotg I think.
+Satyeshwar
Satyeshwar's probably the best person from IOTG to give the Ack since he's part
of the group that needs this functionality and is involved in the
userspace/compositor side as well.
Matt
>
> Cheers, Daniel
>
> > ---
> > Documentation/gpu/drm-kms-helpers.rst | 6 +
> > drivers/gpu/drm/Makefile | 2 +-
> > drivers/gpu/drm/drm_hdcp.c| 342 ++
> > drivers/gpu/drm/drm_internal.h| 4 +
> > drivers/gpu/drm/drm_sysfs.c | 2 +
> > include/drm/drm_hdcp.h| 24 ++
> > 6 files changed, 379 insertions(+), 1 deletion(-) create mode
> > 100644 drivers/gpu/drm/drm_hdcp.c
> >
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 14102ae035dc..0fe726a6ee67 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -181,6 +181,12 @@ Panel Helper Reference .. kernel-doc::
> > drivers/gpu/drm/drm_panel_orientation_quirks.c
> > :export:
> >
> > +HDCP Helper Functions Reference
> > +===
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> > + :export:
> > +
> > Display Port Helper Functions Reference
> > ===
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 72f5036d9bfa..dd02e9dec810 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > - drm_atomic_uapi.o
> > + drm_atomic_uapi.o drm_hdcp.o
> >
> > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o
> > drm_context.o drm_dma.o drm_scatter.o drm_lock.o
> > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git
> > a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c new file
> > mode 100644 index ..dc0e13409221
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -0,0 +1,342 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * Authors:
> > + * Ramalingam C */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct hdcp_srm {
> > + u8 *srm_buf;
>
> Allocated, but seems to not be used.
>
> > + size_t received_srm_sz;
>
> Seems to be unused. Seems to both be leftovers from the sysfs interface.
>
> > + u32 revoked_ksv_cnt;
> > + u8 *revoked_ksv_list;
> > +
> > + /* Mutex to protect above struct member */
> > + struct mutex mutex;
> > +} *srm_data;
> > +
> > +static inline void drm_hdcp_print_ksv(const u8 *ksv) {
> > + DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> > + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]); }
> > +
> > +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32
> > +vrls_length) {
> > + u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> > +
> > + while (parsed_bytes < vrls_length) {
> > + vrl_ksv_cnt = *buf;
> > + ksv_count += vrl_ksv_cnt;
> > +
> > + vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> > + buf += vrl_sz;
> > + parsed_bytes += vrl_sz;
> > + }
> > +
> > + /*
> > +* When vrls are not valid, ksvs are not
Re: [Intel-gfx] [PATCH 11/13] drm/i915: Pass i915_sched_node around internally
On 03/05/2019 12:52, Chris Wilson wrote:
To simplify the next patch, update bump_priority and schedule to accept
the internal i915_sched_ndoe directly and not expect a request pointer.
add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)
Function old new delta
i915_schedule_bump_priority 109 113 +4
i915_schedule 50 54 +4
__i915_schedule 922 907 -15
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 33 +++
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 4a95cf2201a7..380cb7343a10 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -189,7 +189,7 @@ static void kick_submission(struct intel_engine_cs *engine,
int prio)
tasklet_hi_schedule(>execlists.tasklet);
}
-static void __i915_schedule(struct i915_request *rq,
+static void __i915_schedule(struct i915_sched_node *rq,
Can you not use rq for sched node, but perhaps node?
const struct i915_sched_attr *attr)
{
struct intel_engine_cs *engine;
@@ -203,13 +203,13 @@ static void __i915_schedule(struct i915_request *rq,
lockdep_assert_held(_lock);
GEM_BUG_ON(prio == I915_PRIORITY_INVALID);
- if (i915_request_completed(rq))
+ if (prio <= READ_ONCE(rq->attr.priority))
return;
- if (prio <= READ_ONCE(rq->sched.attr.priority))
+ if (node_signaled(rq))
And refrain from re-ordering the sequence in this patch please.
return;
- stack.signaler = >sched;
+ stack.signaler = rq;
list_add(_link, );
/*
@@ -260,9 +260,9 @@ static void __i915_schedule(struct i915_request *rq,
* execlists_submit_request()), we can set our own priority and skip
* acquiring the engine locks.
*/
- if (rq->sched.attr.priority == I915_PRIORITY_INVALID) {
- GEM_BUG_ON(!list_empty(>sched.link));
- rq->sched.attr = *attr;
+ if (rq->attr.priority == I915_PRIORITY_INVALID) {
+ GEM_BUG_ON(!list_empty(>link));
+ rq->attr = *attr;
if (stack.dfs_link.next == stack.dfs_link.prev)
return;
@@ -271,7 +271,7 @@ static void __i915_schedule(struct i915_request *rq,
}
memset(, 0, sizeof(cache));
- engine = rq->engine;
+ engine = node_to_request(rq)->engine;
spin_lock(>timeline.lock);
/* Fifo and depth-first replacement ensure our deps execute before us */
@@ -322,13 +322,20 @@ static void __i915_schedule(struct i915_request *rq,
void i915_schedule(struct i915_request *rq, const struct i915_sched_attr
*attr)
{
spin_lock_irq(_lock);
- __i915_schedule(rq, attr);
+ __i915_schedule(>sched, attr);
spin_unlock_irq(_lock);
}
+static void __bump_priority(struct i915_sched_node *node, unsigned int bump)
+{
+ struct i915_sched_attr attr = node->attr;
+
+ attr.priority |= bump;
+ __i915_schedule(node, );
+}
+
void i915_schedule_bump_priority(struct i915_request *rq, unsigned int bump)
{
- struct i915_sched_attr attr;
unsigned long flags;
GEM_BUG_ON(bump & ~I915_PRIORITY_MASK);
@@ -337,11 +344,7 @@ void i915_schedule_bump_priority(struct i915_request *rq,
unsigned int bump)
return;
spin_lock_irqsave(_lock, flags);
-
- attr = rq->sched.attr;
- attr.priority |= bump;
- __i915_schedule(rq, );
-
+ __bump_priority(>sched, bump);
spin_unlock_irqrestore(_lock, flags);
}
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLE
To complete the idle worker, we must complete 2 passes of wait-for-idle.
At the end of the first pass, we queue a switch-to-kernel-context and
may only idle after waiting for its completion. Speed up the flush_work
by doing the wait explicitly, which then allows us to remove the
unbounded loop trying to complete the flush_work in the next patch.
References: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Testcase: igt/gem_ppgtt/flind-and-close-vma-leak
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..f60aed7747e5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3901,14 +3901,26 @@ i915_drop_caches_set(void *data, u64 val)
/* No need to check and wait for gpu resets, only libdrm auto-restarts
* on ioctls on -EAGAIN. */
- if (val & (DROP_ACTIVE | DROP_RETIRE | DROP_RESET_SEQNO)) {
+ if (val & (DROP_ACTIVE | DROP_IDLE | DROP_RETIRE | DROP_RESET_SEQNO)) {
int ret;
ret = mutex_lock_interruptible(>drm.struct_mutex);
if (ret)
return ret;
- if (val & DROP_ACTIVE)
+ /*
+* To finish the flush of the idle_worker, we must complete
+* the switch-to-kernel-context, which requires a double
+* pass through wait_for_idle: first queues the switch,
+* second waits for the switch.
+*/
+ if (ret == 0 && val & (DROP_IDLE | DROP_ACTIVE))
+ ret = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED,
+MAX_SCHEDULE_TIMEOUT);
+
+ if (ret == 0 && val & DROP_IDLE)
ret = i915_gem_wait_for_idle(i915,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_LOCKED,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Cancel retire_worker on parking
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although that the igt is trying to idle from one child while submitting
from another may be a contributing factor as to why it runs so slowly...
v2: Use the non-sync version of cancel_delayed_work(), we only need to
stop it from being scheduled as we independently check whether now is
the right time to be parking.
Testcase: igt/gem_concurrent_blit
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index ae91ad7cb31e..fa9c2ebd966a 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
container_of(work, typeof(*i915), gem.idle_work);
+ bool restart = true;
+ cancel_delayed_work(>gem.retire_work);
mutex_lock(>drm.struct_mutex);
intel_wakeref_lock(>gt.wakeref);
- if (!intel_wakeref_active(>gt.wakeref) && !work_pending(work))
+ if (!intel_wakeref_active(>gt.wakeref) && !work_pending(work)) {
i915_gem_park(i915);
+ restart = false;
+ }
intel_wakeref_unlock(>gt.wakeref);
mutex_unlock(>drm.struct_mutex);
+ if (restart)
+ queue_delayed_work(i915->wq,
+ >gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static void retire_work_handler(struct work_struct *work)
@@ -52,10 +60,9 @@ static void retire_work_handler(struct work_struct *work)
mutex_unlock(>drm.struct_mutex);
}
- if (intel_wakeref_active(>gt.wakeref))
- queue_delayed_work(i915->wq,
- >gem.retire_work,
- round_jiffies_up_relative(HZ));
+ queue_delayed_work(i915->wq,
+ >gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static int pm_notifier(struct notifier_block *nb,
@@ -140,7 +147,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- drain_delayed_work(>gem.retire_work);
GEM_BUG_ON(i915->gt.awake);
flush_work(>gem.idle_work);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d919f512042c..9fd02025d382 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -58,7 +58,6 @@ static void mock_device_release(struct drm_device *dev)
i915_gem_contexts_lost(i915);
mutex_unlock(>drm.struct_mutex);
- drain_delayed_work(>gem.retire_work);
flush_work(>gem.idle_work);
i915_gem_drain_workqueue(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
If the user is racing a call to debugfs/i915_drop_caches with ongoing
submission from another thread/process, we may never end up idling the
GPU and be uninterruptibly spinning in debugfs/i915_drop_caches trying
to catch an idle moment.
Just flush the work once, that should be enough to park the system under
correct conditions. Outside of those we either have a driver bug or the
user is racing themselves. Sadly, because the user may be provoking the
unwanted situation we can't put a warn here to attract attention to a
probable bug.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fc6e60d82477..b6094063be9b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3947,9 +3947,7 @@ i915_drop_caches_set(void *data, u64 val)
fs_reclaim_release(GFP_KERNEL);
if (val & DROP_IDLE) {
- do {
- flush_delayed_work(>gem.retire_work);
- } while (READ_ONCE(i915->gt.awake));
+ flush_delayed_work(>gem.retire_work);
flush_work(>gem.idle_work);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Remove delay for idle_work
The original intent for the delay before running the idle_work was to
provide a hysteresis to avoid ping-ponging the device runtime-pm. Since
then we have also pulled in some memory management and general device
management for parking. But with the inversion of the wakeref handling,
GEM is no longer responsible for the wakeref and by the time we call the
idle_work, the device is asleep. It seems appropriate now to drop the
delay and just run the worker immediately to flush the cached GEM state
before sleeping.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_pm.c| 21 +++
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
5 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f60aed7747e5..fc6e60d82477 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3949,8 +3949,8 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_IDLE) {
do {
flush_delayed_work(>gem.retire_work);
- drain_delayed_work(>gem.idle_work);
} while (READ_ONCE(i915->gt.awake));
+ flush_work(>gem.idle_work);
}
if (val & DROP_FREED)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64fa353a62bb..2bf518fea36e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2031,7 +2031,7 @@ struct drm_i915_private {
* arrive within a small period of time, we fire
* off the idle_work.
*/
- struct delayed_work idle_work;
+ struct work_struct idle_work;
} gem;
/* For i945gm vblank irq vs. C3 workaround */
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 49b0ce594f20..ae91ad7cb31e 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private *i915)
static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
- container_of(work, typeof(*i915), gem.idle_work.work);
+ container_of(work, typeof(*i915), gem.idle_work);
mutex_lock(>drm.struct_mutex);
intel_wakeref_lock(>gt.wakeref);
- if (!intel_wakeref_active(>gt.wakeref))
+ if (!intel_wakeref_active(>gt.wakeref) && !work_pending(work))
i915_gem_park(i915);
intel_wakeref_unlock(>gt.wakeref);
@@ -74,9 +74,7 @@ static int pm_notifier(struct notifier_block *nb,
break;
case INTEL_GT_PARK:
- mod_delayed_work(i915->wq,
->gem.idle_work,
-msecs_to_jiffies(100));
+ queue_work(i915->wq, >gem.idle_work);
break;
}
@@ -142,16 +140,11 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- GEM_BUG_ON(i915->gt.awake);
- cancel_delayed_work_sync(>gpu_error.hangcheck_work);
-
drain_delayed_work(>gem.retire_work);
+ GEM_BUG_ON(i915->gt.awake);
+ flush_work(>gem.idle_work);
- /*
-* As the idle_work is rearming if it detects a race, play safe and
-* repeat the flush until it is definitely idle.
-*/
- drain_delayed_work(>gem.idle_work);
+ cancel_delayed_work_sync(>gpu_error.hangcheck_work);
i915_gem_drain_freed_objects(i915);
@@ -242,7 +235,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
void i915_gem_init__pm(struct drm_i915_private *i915)
{
- INIT_DELAYED_WORK(>gem.idle_work, idle_work_handler);
+ INIT_WORK(>gem.idle_work, idle_work_handler);
INIT_DELAYED_WORK(>gem.retire_work, retire_work_handler);
i915->gem.pm_notifier.notifier_call = pm_notifier;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
index 088b2aa05dcd..b926d1cd165d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -509,7 +509,7 @@ static void disable_retire_worker(struct drm_i915_private
*i915)
intel_gt_pm_get(i915);
cancel_delayed_work_sync(>gem.retire_work);
- cancel_delayed_work_sync(>gem.idle_work);
+ flush_work(>gem.idle_work);
}
static void restore_retire_worker(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
Re: [Intel-gfx] [v8 01/10] drm: Add HDR source metadata property
On Tue, May 07, 2019 at 01:25:42PM +0300, Ville Syrjälä wrote:
> On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> > >Sent: Saturday, May 4, 2019 3:48 PM
> > >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> > >dri-
> > >de...@lists.freedesktop.org
> > >Cc: dcasta...@chromium.org; emil.l.veli...@gmail.com;
> > >seanp...@chromium.org;
> > >Syrjala, Ville ; Lankhorst, Maarten
> > >
> > >Subject: Re: [v8 01/10] drm: Add HDR source metadata property
> > >
> > >On 2019-04-09 18:44, Uma Shankar wrote:
> > >> This patch adds a blob property to get HDR metadata information from
> > >> userspace. This will be send as part of AVI Infoframe to panel.
> > >>
> > >> It also implements get() and set() functions for HDR output metadata
> > >> property.The blob data is received from userspace and saved in
> > >> connector state, the same is returned as blob in get property call to
> > >> userspace.
> > >>
> > >> v2: Rebase and modified the metadata structure elements as per Ville's
> > >> POC changes.
> > >>
> > >> v3: No Change
> > >>
> > >> v4: Addressed Shashank's review comments
> > >>
> > >> v5: Rebase.
> > >>
> > >> v6: Addressed Brian Starkey's review comments, defined new structure
> > >> with header for dynamic metadata scalability.
> > >> Merge get/set property functions for metadata in this patch.
> > >>
> > >> v7: Addressed Jonas Karlman review comments and defined separate
> > >> structure for infoframe to better align with CTA 861.G spec. Added
> > >> Shashank's RB.
> > >>
> > >> Signed-off-by: Uma Shankar
> > >> Reviewed-by: Shashank Sharma
> > >> ---
> > >> drivers/gpu/drm/drm_atomic.c | 2 ++
> > >> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> > >> drivers/gpu/drm/drm_connector.c | 6 ++
> > >> include/drm/drm_connector.h | 11 +++
> > >> include/drm/drm_mode_config.h | 6 ++
> > >> include/linux/hdmi.h | 10 ++
> > >> include/uapi/drm/drm_mode.h | 39
> > >+++
> > >> 7 files changed, 87 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_atomic.c
> > >> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 100644
> > >> --- a/drivers/gpu/drm/drm_atomic.c
> > >> +++ b/drivers/gpu/drm/drm_atomic.c
> > >> @@ -881,6 +881,8 @@ static void
> > >> drm_atomic_connector_print_state(struct drm_printer *p,
> > >>
> > >> drm_printf(p, "connector[%u]: %s\n", connector->base.id,
> > >> connector-
> > >>name);
> > >> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> > >> "(null)");
> > >> +drm_printf(p, "\thdr_metadata_changed=%d\n",
> > >> + state->hdr_metadata_changed);
> > >>
> > >> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> > >> if (state->writeback_job && state->writeback_job->fb)
> > >> diff --git
> > >> a/drivers/gpu/drm/drm_atomic_uapi.c
> > >> b/drivers/gpu/drm/drm_atomic_uapi.c
> > >> index ea797d4..6d0d161 100644
> > >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > >> @@ -673,6 +673,8 @@ static int
> > >> drm_atomic_connector_set_property(struct drm_connector *connector, {
> > >> struct drm_device *dev = connector->dev;
> > >> struct drm_mode_config *config = >mode_config;
> > >> +bool replaced = false;
> > >> +int ret;
> > >>
> > >> if (property == config->prop_crtc_id) {
> > >> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
> > >> @@ -721,6
> > >> +723,14 @@ static int drm_atomic_connector_set_property(struct
> > >> drm_connector
> > >*connector,
> > >> */
> > >> if (state->link_status != DRM_LINK_STATUS_GOOD)
> > >> state->link_status = val;
> > >> +} else if (property == config->hdr_output_metadata_property) {
> > >> +ret = drm_atomic_replace_property_blob_from_id(dev,
> > >> +>hdr_output_metadata_blob_ptr,
> > >> +val,
> > >> +-1, sizeof(struct hdr_output_metadata),
> > >> +);
> > >> +state->hdr_metadata_changed |= replaced;
> > >> +return ret;
> > >> } else if (property == config->aspect_ratio_property) {
> > >> state->picture_aspect_ratio = val;
> > >> } else if (property == config->content_type_property) { @@
> > >> -807,6
> > >> +817,9 @@ static int drm_atomic_connector_set_property(struct
> > >> drm_connector
> > >*connector,
> > >> *val = state->colorspace;
> > >> } else if (property == connector->scaling_mode_property) {
> > >> *val = state->scaling_mode;
> > >> +} else if (property ==
Re: [Intel-gfx] [v8 01/10] drm: Add HDR source metadata property
On Tue, Apr 09, 2019 at 10:14:35PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> It also implements get() and set() functions for HDR output
> metadata property.The blob data is received from userspace and
> saved in connector state, the same is returned as blob in get
> property call to userspace.
>
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Rebase.
>
> v6: Addressed Brian Starkey's review comments, defined
> new structure with header for dynamic metadata scalability.
> Merge get/set property functions for metadata in this patch.
>
> v7: Addressed Jonas Karlman review comments and defined separate
> structure for infoframe to better align with CTA 861.G spec. Added
> Shashank's RB.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic.c | 2 ++
> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> drivers/gpu/drm/drm_connector.c | 6 ++
> include/drm/drm_connector.h | 11 +++
> include/drm/drm_mode_config.h | 6 ++
> include/linux/hdmi.h | 10 ++
> include/uapi/drm/drm_mode.h | 39
> +++
> 7 files changed, 87 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5eb4013..8b9c126 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -881,6 +881,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
>
> drm_printf(p, "connector[%u]: %s\n", connector->base.id,
> connector->name);
> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> "(null)");
> + drm_printf(p, "\thdr_metadata_changed=%d\n",
> +state->hdr_metadata_changed);
Is that flag actually useful?
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> if (state->writeback_job && state->writeback_job->fb)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index ea797d4..6d0d161 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -673,6 +673,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> {
> struct drm_device *dev = connector->dev;
> struct drm_mode_config *config = >mode_config;
> + bool replaced = false;
> + int ret;
>
> if (property == config->prop_crtc_id) {
> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
> @@ -721,6 +723,14 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>*/
> if (state->link_status != DRM_LINK_STATUS_GOOD)
> state->link_status = val;
> + } else if (property == config->hdr_output_metadata_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >hdr_output_metadata_blob_ptr,
> + val,
> + -1, sizeof(struct hdr_output_metadata),
> + );
> + state->hdr_metadata_changed |= replaced;
> + return ret;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> } else if (property == config->content_type_property) {
> @@ -807,6 +817,9 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> + } else if (property == config->hdr_output_metadata_property) {
> + *val = (state->hdr_output_metadata_blob_ptr) ?
Pointless parens.
> + state->hdr_output_metadata_blob_ptr->base.id : 0;
> } else if (property == connector->content_protection_property) {
> *val = state->content_protection;
> } else if (property == config->writeback_fb_id_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2355124..0bdae90 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.non_desktop_property = prop;
>
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_output_metadata_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>
Re: [Intel-gfx] [PATCH 10/13] drm/i915: Rearrange i915_scheduler.c
On 03/05/2019 12:52, Chris Wilson wrote:
To avoid pulling in a forward declaration in the next patch, move the
i915_sched_node handling to after the main dfs of the scheduler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 210 +-
1 file changed, 105 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index fadf0cd9c75a..4a95cf2201a7 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -35,109 +35,6 @@ static inline bool node_signaled(const struct
i915_sched_node *node)
return i915_request_completed(node_to_request(node));
}
-void i915_sched_node_init(struct i915_sched_node *node)
-{
- INIT_LIST_HEAD(>signalers_list);
- INIT_LIST_HEAD(>waiters_list);
- INIT_LIST_HEAD(>link);
- node->attr.priority = I915_PRIORITY_INVALID;
- node->semaphores = 0;
- node->flags = 0;
-}
-
-static struct i915_dependency *
-i915_dependency_alloc(void)
-{
- return kmem_cache_alloc(global.slab_dependencies, GFP_KERNEL);
-}
-
-static void
-i915_dependency_free(struct i915_dependency *dep)
-{
- kmem_cache_free(global.slab_dependencies, dep);
-}
-
-bool __i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal,
- struct i915_dependency *dep,
- unsigned long flags)
-{
- bool ret = false;
-
- spin_lock_irq(_lock);
-
- if (!node_signaled(signal)) {
- INIT_LIST_HEAD(>dfs_link);
- list_add(>wait_link, >waiters_list);
- list_add(>signal_link, >signalers_list);
- dep->signaler = signal;
- dep->flags = flags;
-
- /* Keep track of whether anyone on this chain has a semaphore */
- if (signal->flags & I915_SCHED_HAS_SEMAPHORE_CHAIN &&
- !node_started(signal))
- node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
-
- ret = true;
- }
-
- spin_unlock_irq(_lock);
-
- return ret;
-}
-
-int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
-{
- struct i915_dependency *dep;
-
- dep = i915_dependency_alloc();
- if (!dep)
- return -ENOMEM;
-
- if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_ALLOC))
- i915_dependency_free(dep);
-
- return 0;
-}
-
-void i915_sched_node_fini(struct i915_sched_node *node)
-{
- struct i915_dependency *dep, *tmp;
-
- GEM_BUG_ON(!list_empty(>link));
-
- spin_lock_irq(_lock);
-
- /*
-* Everyone we depended upon (the fences we wait to be signaled)
-* should retire before us and remove themselves from our list.
-* However, retirement is run independently on each timeline and
-* so we may be called out-of-order.
-*/
- list_for_each_entry_safe(dep, tmp, >signalers_list, signal_link) {
- GEM_BUG_ON(!node_signaled(dep->signaler));
- GEM_BUG_ON(!list_empty(>dfs_link));
-
- list_del(>wait_link);
- if (dep->flags & I915_DEPENDENCY_ALLOC)
- i915_dependency_free(dep);
- }
-
- /* Remove ourselves from everyone who depends upon us */
- list_for_each_entry_safe(dep, tmp, >waiters_list, wait_link) {
- GEM_BUG_ON(dep->signaler != node);
- GEM_BUG_ON(!list_empty(>dfs_link));
-
- list_del(>signal_link);
- if (dep->flags & I915_DEPENDENCY_ALLOC)
- i915_dependency_free(dep);
- }
-
- spin_unlock_irq(_lock);
-}
-
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
{
return rb_entry(rb, struct i915_priolist, node);
@@ -239,6 +136,11 @@ i915_sched_lookup_priolist(struct intel_engine_cs *engine,
int prio)
return >requests[idx];
}
+void __i915_priolist_free(struct i915_priolist *p)
+{
+ kmem_cache_free(global.slab_priorities, p);
+}
+
struct sched_cache {
struct list_head *priolist;
};
@@ -443,9 +345,107 @@ void i915_schedule_bump_priority(struct i915_request *rq,
unsigned int bump)
spin_unlock_irqrestore(_lock, flags);
}
-void __i915_priolist_free(struct i915_priolist *p)
+void i915_sched_node_init(struct i915_sched_node *node)
{
- kmem_cache_free(global.slab_priorities, p);
+ INIT_LIST_HEAD(>signalers_list);
+ INIT_LIST_HEAD(>waiters_list);
+ INIT_LIST_HEAD(>link);
+ node->attr.priority = I915_PRIORITY_INVALID;
+ node->semaphores = 0;
+ node->flags = 0;
+}
+
+static struct i915_dependency *
+i915_dependency_alloc(void)
+{
Re: [Intel-gfx] [PATCH 09/13] drm/i915/execlists: Don't apply priority boost for resets
On 03/05/2019 12:52, Chris Wilson wrote:
Do not treat reset as a normal preemption event and avoid giving the
guilty request a priority boost for simply being active at the time of
reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index afcdfc440bbd..6419bcaf1ecc 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -371,11 +371,11 @@ static void unwind_wa_tail(struct i915_request *rq)
}
static struct i915_request *
-__unwind_incomplete_requests(struct intel_engine_cs *engine)
+__unwind_incomplete_requests(struct intel_engine_cs *engine, int boost)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
+ int prio = I915_PRIORITY_INVALID | boost;
lockdep_assert_held(>timeline.lock);
@@ -419,8 +419,9 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
* in the priority queue, but they will not gain immediate access to
* the GPU.
*/
- if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(active)) {
- prio |= ACTIVE_PRIORITY;
+ if (~prio & boost && __i915_request_has_started(active)) {
+ prio |= boost;
+ GEM_BUG_ON(active->sched.attr.priority >= prio);
active->sched.attr.priority = prio;
list_move_tail(>sched.link,
i915_sched_lookup_priolist(engine, prio));
@@ -435,7 +436,7 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- return __unwind_incomplete_requests(engine);
+ return __unwind_incomplete_requests(engine, 0);
}
static inline void
@@ -656,7 +657,8 @@ static void complete_preempt_context(struct
intel_engine_execlists *execlists)
execlists_cancel_port_requests(execlists);
__unwind_incomplete_requests(container_of(execlists,
struct intel_engine_cs,
- execlists));
+ execlists),
+ACTIVE_PRIORITY);
}
static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -1909,7 +1911,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
execlists_cancel_port_requests(execlists);
/* Push back any incomplete requests for replay after the reset. */
- rq = __unwind_incomplete_requests(engine);
+ rq = __unwind_incomplete_requests(engine, 0);
if (!rq)
goto out_replay;
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] [v8 08/10] drm/i915:Enabled Modeset when HDR Infoframe changes
On Tue, Apr 09, 2019 at 10:14:42PM +0530, Uma Shankar wrote:
> This patch enables modeset whenever HDR metadata
> needs to be updated to sink.
>
> v2: Addressed Shashank's review comments.
>
> v3: Added Shashank's RB.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 14 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 26 ++
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 8c8fae3..e8b5f84 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -104,6 +104,16 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> +static bool blob_equal(const struct drm_property_blob *a,
> +const struct drm_property_blob *b)
> +{
> + if (a && b)
> + return a->length == b->length &&
> + !memcmp(a->data, b->data, a->length);
> +
> + return !a == !b;
> +}
I have a feeling the memcmp() is overkill. We could just check for
whether the blob is the same or not. If userspace is an idiot and
creates a new blob with identical content so be it.
> +
> int intel_digital_connector_atomic_check(struct drm_connector *conn,
>struct drm_connector_state *new_state)
> {
> @@ -131,7 +141,9 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> new_conn_state->base.colorspace != old_conn_state->base.colorspace
> ||
> new_conn_state->base.picture_aspect_ratio !=
> old_conn_state->base.picture_aspect_ratio ||
> new_conn_state->base.content_type !=
> old_conn_state->base.content_type ||
> - new_conn_state->base.scaling_mode !=
> old_conn_state->base.scaling_mode)
> + new_conn_state->base.scaling_mode !=
> old_conn_state->base.scaling_mode ||
> + !blob_equal(new_conn_state->base.hdr_output_metadata_blob_ptr,
> + old_conn_state->base.hdr_output_metadata_blob_ptr))
> crtc_state->mode_changed = true;
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 0ecfda0..85333a7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -799,6 +799,20 @@ void intel_read_infoframe(struct intel_encoder *encoder,
> return true;
> }
>
> +static bool is_eotf_supported(u8 output_eotf, u8 sink_eotf)
> +{
> + if (output_eotf == 0)
> + return (sink_eotf & (1 << 0));
> + if (output_eotf == 1)
> + return (sink_eotf & (1 << 1));
> + if (output_eotf == 2)
> + return (sink_eotf & (1 << 2));
> + if (output_eotf == 3)
> + return (sink_eotf & (1 << 3));
> +
> + return false;
return sink_eotf & BIT(output_eotf);
> +}
> +
> static bool
> intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
>struct intel_crtc_state *crtc_state,
> @@ -806,11 +820,23 @@ void intel_read_infoframe(struct intel_encoder *encoder,
> {
> struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
> struct hdr_output_metadata *hdr_metadata;
> + struct drm_connector *connector = conn_state->connector;
> int ret;
>
> + if (!conn_state->hdr_output_metadata_blob_ptr ||
> + conn_state->hdr_output_metadata_blob_ptr->length == 0)
> + return true;
> +
> hdr_metadata = (struct hdr_output_metadata *)
> conn_state->hdr_output_metadata_blob_ptr->data;
>
> + /* Sink EOTF is Bit map while infoframe is absolute values */
> + if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
> +connector->hdr_sink_metadata.hdmi_type1.eotf)) {
> + DRM_ERROR("EOTF Not Supported\n");
> + return true;
> + }
> +
> ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
> if (ret < 0) {
> DRM_ERROR("couldn't set HDR metadata in infoframe\n");
> --
> 1.9.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: add in-kernel blitter client
Quoting Matthew Auld (2019-05-07 11:55:57)
> The plan is to use the blitter engine for async object clearing when
> using local memory, but before we can move the worker to get_pages() we
> have to first tame some more of our struct_mutex usage. With this in
> mind we should be able to upstream the object clearing as some
> selftests, which should serve as a guinea pig for the ongoing locking
> rework and upcoming asyc get_pages() framework.
>
> Signed-off-by: Matthew Auld
> ---
> +struct clear_pages_work {
> + struct dma_fence dma;
> + struct dma_fence_cb cb;
> + struct i915_sw_fence wait;
> + struct work_struct work;
> + struct irq_work irq_work;
> + struct i915_sleeve *sleeve;
> + struct intel_context *ce;
> + u32 value;
> +};
> +
> +static const char *clear_pages_work_driver_name(struct dma_fence *fence)
> +{
> + return DRIVER_NAME;
> +}
> +
> +static const char *clear_pages_work_timeline_name(struct dma_fence *fence)
> +{
> + return "clear";
> +}
> +
> +static void clear_pages_work_release(struct dma_fence *fence)
> +{
> + struct clear_pages_work *w = container_of(fence, typeof(*w), dma);
> +
> + destroy_sleeve(w->sleeve);
> +
> + i915_sw_fence_fini(>wait);
> +
> + BUILD_BUG_ON(offsetof(typeof(*w), dma));
> + dma_fence_free(>dma);
> +}
> +
> +static const struct dma_fence_ops clear_pages_work_ops = {
> + .get_driver_name = clear_pages_work_driver_name,
> + .get_timeline_name = clear_pages_work_timeline_name,
> + .release = clear_pages_work_release,
> +};
> +
> +static void clear_pages_signal_irq_worker(struct irq_work *work)
> +{
> + struct clear_pages_work *w = container_of(work, typeof(*w), irq_work);
> +
> + dma_fence_signal(>dma);
> + dma_fence_put(>dma);
> +}
> +
> +static void clear_pages_dma_fence_cb(struct dma_fence *fence,
> +struct dma_fence_cb *cb)
> +{
> + struct clear_pages_work *w = container_of(cb, typeof(*w), cb);
> +
> + /*
> +* Push the signalling of the fence into yet another worker to avoid
> +* the nightmare locking around the fence spinlock.
> +*/
> + irq_work_queue(>irq_work);
> +}
> +
> +static void clear_pages_worker(struct work_struct *work)
> +{
> + struct clear_pages_work *w = container_of(work, typeof(*w), work);
> + struct drm_i915_private *i915 = w->ce->gem_context->i915;
> + struct drm_i915_gem_object *obj = w->sleeve->obj;
> + struct i915_vma *vma = w->sleeve->vma;
> + struct i915_request *rq;
> + int err;
> +
> + if (w->dma.error)
> + goto out_signal;
> +
> + if (obj->cache_dirty) {
> + obj->write_domain = 0;
> + if (i915_gem_object_has_struct_page(obj))
> + drm_clflush_sg(w->sleeve->pages);
> + obj->cache_dirty = false;
Interesting. If we have no struct_page, can we be cache_dirty here?
That might be a useful thought exercise and worth verifying at odd
points.
> + }
> +
> + mutex_lock(>drm.struct_mutex);
This will be come vm->mutex. But that's why we need this patch so that
we can trim down the locking with a working test.
> + err = i915_vma_pin(vma, 0, 0, PIN_USER);
> + if (unlikely(err)) {
> + mutex_unlock(>drm.struct_mutex);
> + dma_fence_set_error(>dma, err);
> + goto out_signal;
> + }
> +
> + rq = i915_request_create(w->ce);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + goto out_unpin;
> + }
> +
> + err = intel_emit_vma_fill_blt(rq, vma, w->value);
> + if (unlikely(err))
> + goto out_request;
> +
> + err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
> +out_request:
> + if (unlikely(err))
> + i915_request_skip(rq, err);
> + else
> + i915_request_get(rq);
> +
> + i915_request_add(rq);
> +out_unpin:
> + i915_vma_unpin(vma);
> +
> + mutex_unlock(>drm.struct_mutex);
> +
> + if (!err) {
> + err = dma_fence_add_callback(>fence, >cb,
> +clear_pages_dma_fence_cb);
> + i915_request_put(rq);
> + if (!err)
> + return;
This should be rearranged such that after we have a rq allocated, we
always attach the callback and propagate via the callback. Even on the
error path. That should tidy this up quite a bit. (It's pretty much the
point of why we always i915_request_add even when skipping, we always
have an intact timeline for conveying errors.)
> + } else {
> + dma_fence_set_error(>dma, err);
> + }
> +out_signal:
> + dma_fence_signal(>dma);
> + dma_fence_put(>dma);
> +}
> +
> +static int __i915_sw_fence_call
> +clear_pages_work_notify(struct i915_sw_fence *fence,
> +
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Only reschedule the submission tasklet if preemption is possible
On 03/05/2019 12:52, Chris Wilson wrote:
If we couple the scheduler more tightly with the execlists policy, we
can apply the preemption policy to the question of whether we need to
kick the tasklet at all for this priority bump.
v2: Rephrase it as a core i915 policy and not an execlists foible.
v3: Pull the kick together.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 18 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 7 +++-
drivers/gpu/drm/i915/i915_request.c | 2 --
drivers/gpu/drm/i915/i915_scheduler.c | 37 -
drivers/gpu/drm/i915/i915_scheduler.h | 18 ++
drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
7 files changed, 50 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 9e2a183a351c..9359b3a7ad9c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -106,24 +106,6 @@ hangcheck_action_to_str(const enum
intel_engine_hangcheck_action a)
void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
-static inline bool __execlists_need_preempt(int prio, int last)
-{
- /*
-* Allow preemption of low -> normal -> high, but we do
-* not allow low priority tasks to preempt other low priority
-* tasks under the impression that latency for low priority
-* tasks does not matter (as much as background throughput),
-* so kiss.
-*
-* More naturally we would write
-* prio >= max(0, last);
-* except that we wish to prevent triggering preemption at the same
-* priority level: the task that is running should remain running
-* to preserve FIFO ordering of dependencies.
-*/
- return prio > max(I915_PRIORITY_NORMAL - 1, last);
-}
-
static inline void
execlists_set_active(struct intel_engine_execlists *execlists,
unsigned int bit)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 90900c7d7058..afcdfc440bbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -252,8 +252,8 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* ourselves, ignore the request.
*/
last_prio = effective_prio(rq);
- if (!__execlists_need_preempt(engine->execlists.queue_priority_hint,
- last_prio))
+ if (!i915_scheduler_need_preempt(engine->execlists.queue_priority_hint,
+last_prio))
return false;
/*
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 84538f69185b..4b042893dc0e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -638,14 +638,19 @@ static struct i915_request *dummy_request(struct
intel_engine_cs *engine)
GEM_BUG_ON(i915_request_completed(rq));
i915_sw_fence_init(>submit, dummy_notify);
- i915_sw_fence_commit(>submit);
+ set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
return rq;
}
static void dummy_request_free(struct i915_request *dummy)
{
+ /* We have to fake the CS interrupt to kick the next request */
+ i915_sw_fence_commit(>submit);
+
i915_request_mark_complete(dummy);
+ dma_fence_signal(>fence);
+
i915_sched_node_fini(>sched);
i915_sw_fence_fini(>submit);
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index d06c45305b03..8cb3ed5531e3 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1377,9 +1377,7 @@ long i915_request_wait(struct i915_request *rq,
if (flags & I915_WAIT_PRIORITY) {
if (!i915_request_started(rq) && INTEL_GEN(rq->i915) >= 6)
gen6_rps_boost(rq);
- local_bh_disable(); /* suspend tasklets for reprioritisation */
i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
- local_bh_enable(); /* kick tasklets en masse */
}
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 39bc4f54e272..fadf0cd9c75a 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -261,16 +261,30 @@ sched_lock_engine(const struct i915_sched_node *node,
return engine;
}
-static bool inflight(const struct i915_request *rq,
-const struct intel_engine_cs *engine)
+static inline int rq_prio(const struct i915_request *rq)
{
- const struct i915_request *active;
+ return rq->sched.attr.priority | __NO_PREEMPTION;
+}
+
+static void
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gtt: grab wakeref in gen6_alloc_va_range
Quoting Matthew Auld (2019-05-07 11:55:56)
> Some steps in gen6_alloc_va_range require the HW to be awake, so ideally
> we should be grabbing the wakeref ourselves and not relying on the
> caller already holding it for us.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8f5db787b7f2..ffb8c3d011e9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1745,10 +1745,13 @@ static int gen6_alloc_va_range(struct
> i915_address_space *vm,
> {
> struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
> struct i915_page_table *pt;
> + intel_wakeref_t wakeref;
> u64 from = start;
> unsigned int pde;
> bool flush = false;
>
> + wakeref = intel_runtime_pm_get(vm->i915);
> +
> gen6_for_each_pde(pt, >base.pd, start, length, pde) {
> const unsigned int count = gen6_pte_count(start, length);
>
> @@ -1774,12 +1777,15 @@ static int gen6_alloc_va_range(struct
> i915_address_space *vm,
>
> if (flush) {
> mark_tlbs_dirty(>base);
> - gen6_ggtt_invalidate(ppgtt->base.vm.i915);
> + gen6_ggtt_invalidate(vm->i915);
> }
>
> + intel_runtime_pm_put(vm->i915, wakeref);
> +
> return 0;
>
> unwind_out:
> + intel_runtime_pm_put(vm->i915, wakeref);
> gen6_ppgtt_clear_range(vm, from, start - from);
> return -ENOMEM;
Reviewed-by: Chris Wilson
It's a bit too fiddly here to try and defer it until the next time the
HW is awake -- and really if we are adjusting the iova, then we are
going to be using the HW, and normally would be under a longterm wakeref
(e.g. execbuf) but for in-kernel clients, we need to be more precise.
-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 i915: disable framebuffer compression on GeminiLake (rev2)
== Series Details == Series: i915: disable framebuffer compression on GeminiLake (rev2) URL : https://patchwork.freedesktop.org/series/60090/ State : success == Summary == CI Bug Log - changes from CI_DRM_6055 -> Patchwork_12974 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/ Known issues Here are the changes found in Patchwork_12974 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [DMESG-WARN][3] ([fdo#108965]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][5] ([fdo#110235]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6055/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (50 -> 45) -- Additional (3): fi-icl-y fi-bxt-dsi fi-bsw-kefka Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6055 -> Patchwork_12974 CI_DRM_6055: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12974: 506aa48014e37b28b3a29068acc61e7c9f9cf10a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 506aa48014e3 i915: disable framebuffer compression on GeminiLake == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12974/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9] drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color
On Tue, 07 May 2019, Ville Syrjälä wrote:
> On Tue, May 07, 2019 at 09:42:48AM +0300, Jani Nikula wrote:
>> On Mon, 29 Apr 2019, Aditya Swarup wrote:
>> > From: Clinton Taylor
>> >
>> > v2: Fix commit msg to reflect why issue occurs(Jani)
>> > Set GCP_COLOR_INDICATION only when we set 10/12 bit deep color.
>> >
>> > Changing settings from 10/12 bit deep color to 8 bit(& vice versa)
>> > doesn't work correctly using xrandr max bpc property. When we
>> > connect a monitor which supports deep color, the highest deep color
>> > setting is selected; which sets GCP_COLOR_INDICATION. When we change
>> > the setting to 8 bit color, we still set GCP_COLOR_INDICATION which
>> > doesn't allow the switch back to 8 bit color.
>> >
>> > v3,4: Add comments & drop changes in intel_hdmi_compute_config(Ville)
>> > Since HSW+, GCP_COLOR_INDICATION is not required for 8bpc.
>> >
>> > Drop the changes in intel_hdmi_compute_config as desired_bpp
>> > is needed to change values for pipe_bpp based on bw_constrained flag.
>> >
>> > v5: Fix missing logical && in condition for setting GCP_COLOR_INDICATION.
>> >
>> > v6: Fix comment formatting (Ville)
>> >
>> > v7: Add reviewed by Ville
>> >
>> > v8: Set GCP_COLOR_INDICATION based on spec:
>> > For Gen 7.5 or later platforms, indicate color depth only for deep
>> > color modes. Bspec: 8135,7751,50524
>> >
>> > Pre DDI platforms, indicate color depth if deep color is supported
>> > by sink. Bspec: 7854
>> >
>> > Exception: CHERRYVIEW behaves like Pre DDI platforms.
>> > Bspec: 15975
>> >
>> > Check pipe_bpp is less than bpp * 3 in hdmi_deep_color_possible,
>> > to not set 12 bit deep color for every modeset. This fixes the issue
>> > where 12 bit color was selected even when user selected 10 bit.(Ville)
>> >
>> > v9: Maintain a consistent behavior for all platforms and support
>> > GCP_COLOR_INDICATION only when we are in deep color mode. Remove
>> > hdmi_sink_is_deep_color() - no longer needed as checking pipe_bpp > 24
>> > takes care of the deep color mode scenario.
>> >
>> > Separate patch for fixing switch from 12 bit to 10 bit deep color
>> > mode.
>> >
>> > Co-developed-by: Aditya Swarup
>> > Signed-off-by: Clinton Taylor
>> > Signed-off-by: Aditya Swarup
>> > Cc: Ville Syrjälä
>> > Cc: Jani Nikula
>> > Cc: Manasi Navare
>> > Reviewed-by: Ville Syrjälä
>>
>> Ville, does this apply to this version of the patch?
>
> Aye. lgtm
Thanks for the patch and review, pushed to dinq.
BR,
Jani.
>
>>
>> BR,
>> Jani.
>>
>>
>> > ---
>> > drivers/gpu/drm/i915/intel_hdmi.c | 17 ++---
>> > 1 file changed, 2 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> > b/drivers/gpu/drm/i915/intel_hdmi.c
>> > index e1005d7b75fd..991eb362ef4f 100644
>> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> > @@ -856,19 +856,6 @@ static void g4x_set_infoframes(struct intel_encoder
>> > *encoder,
>> > _state->infoframes.hdmi);
>> > }
>> >
>> > -static bool hdmi_sink_is_deep_color(const struct drm_connector_state
>> > *conn_state)
>> > -{
>> > - struct drm_connector *connector = conn_state->connector;
>> > -
>> > - /*
>> > - * HDMI cloning is only supported on g4x which doesn't
>> > - * support deep color or GCP infoframes anyway so no
>> > - * need to worry about multiple HDMI sinks here.
>> > - */
>> > -
>> > - return connector->display_info.bpc > 8;
>> > -}
>> > -
>> > /*
>> > * Determine if default_phase=1 can be indicated in the GCP infoframe.
>> > *
>> > @@ -973,8 +960,8 @@ static void intel_hdmi_compute_gcp_infoframe(struct
>> > intel_encoder *encoder,
>> >crtc_state->infoframes.enable |=
>> >intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GENERAL_CONTROL);
>> >
>> > - /* Indicate color depth whenever the sink supports deep color */
>> > - if (hdmi_sink_is_deep_color(conn_state))
>> > + /* Indicate color indication for deep color mode */
>> > + if (crtc_state->pipe_bpp > 24)
>> >crtc_state->infoframes.gcp |= GCP_COLOR_INDICATION;
>> >
>> >/* Enable default_phase whenever the display mode is suitably aligned */
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-tip:drm-tip /8] drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 'already_busywaiting'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 47f4a14297839cb4cedd725fb916a5da5eb9b5ba
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Note: the drm-tip/drm-tip HEAD ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a builds
fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of
'i915_request_await_start'
i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
^~~~
drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of
'i915_request_await_start' was here
i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
^~~~
>> drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of
>> 'already_busywaiting'
already_busywaiting(struct i915_request *rq)
^~~
drivers/gpu/drm/i915/i915_request.c:809:1: note: previous definition of
'already_busywaiting' was here
already_busywaiting(struct i915_request *rq)
^~~
drivers/gpu/drm/i915/i915_request.c:809:1: warning: 'already_busywaiting'
defined but not used [-Wunused-function]
drivers/gpu/drm/i915/i915_request.c:794:1: warning:
'i915_request_await_start' defined but not used [-Wunused-function]
i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
^~~~
vim +/already_busywaiting +842 drivers/gpu/drm/i915/i915_request.c
47f4a1429 drivers/gpu/drm/i915/i915_request.c Joonas Lahtinen 2019-05-07
825
a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson2016-09-09
826 static int
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
@827 i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
828 {
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
829 if (list_is_first(>ring_link, >ring->request_list))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
830 return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
831
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
832 signal = list_prev_entry(signal, ring_link);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
833 if (i915_timeline_sync_is_later(rq->timeline, >fence))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
834 return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
835
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
836 return i915_sw_fence_await_dma_fence(>submit,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
837>fence, 0,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
838I915_FENCE_GFP);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
839 }
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
840
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
841 static intel_engine_mask_t
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
@842 already_busywaiting(struct i915_request *rq)
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
843 {
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
844 /*
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
845* Polling a semaphore causes bus traffic, delaying other users of
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
846* both the GPU and CPU. We want to limit the impact on others,
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
847* while taking advantage of early submission to reduce GPU
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
848* latency. Therefore we restrict ourselves to not using more
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
849* than one semaphore from each source, and not using a semaphore
2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson
[Intel-gfx] [PATCH v2 1/2] drm/i915/gtt: grab wakeref in gen6_alloc_va_range
Some steps in gen6_alloc_va_range require the HW to be awake, so ideally
we should be grabbing the wakeref ourselves and not relying on the
caller already holding it for us.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8f5db787b7f2..ffb8c3d011e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1745,10 +1745,13 @@ static int gen6_alloc_va_range(struct
i915_address_space *vm,
{
struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
struct i915_page_table *pt;
+ intel_wakeref_t wakeref;
u64 from = start;
unsigned int pde;
bool flush = false;
+ wakeref = intel_runtime_pm_get(vm->i915);
+
gen6_for_each_pde(pt, >base.pd, start, length, pde) {
const unsigned int count = gen6_pte_count(start, length);
@@ -1774,12 +1777,15 @@ static int gen6_alloc_va_range(struct
i915_address_space *vm,
if (flush) {
mark_tlbs_dirty(>base);
- gen6_ggtt_invalidate(ppgtt->base.vm.i915);
+ gen6_ggtt_invalidate(vm->i915);
}
+ intel_runtime_pm_put(vm->i915, wakeref);
+
return 0;
unwind_out:
+ intel_runtime_pm_put(vm->i915, wakeref);
gen6_ppgtt_clear_range(vm, from, start - from);
return -ENOMEM;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: add in-kernel blitter client
The plan is to use the blitter engine for async object clearing when
using local memory, but before we can move the worker to get_pages() we
have to first tame some more of our struct_mutex usage. With this in
mind we should be able to upstream the object clearing as some
selftests, which should serve as a guinea pig for the ongoing locking
rework and upcoming asyc get_pages() framework.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/i915_gem_client_blt.c| 297 ++
drivers/gpu/drm/i915/i915_gem_client_blt.h| 21 ++
drivers/gpu/drm/i915/i915_gem_object_blt.c| 103 ++
drivers/gpu/drm/i915/i915_gem_object_blt.h| 24 ++
.../drm/i915/selftests/i915_gem_client_blt.c | 131
.../drm/i915/selftests/i915_gem_object_blt.c | 114 +++
.../drm/i915/selftests/i915_live_selftests.h | 2 +
9 files changed, 695 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_gem_client_blt.c
create mode 100644 drivers/gpu/drm/i915/i915_gem_client_blt.h
create mode 100644 drivers/gpu/drm/i915/i915_gem_object_blt.c
create mode 100644 drivers/gpu/drm/i915/i915_gem_object_blt.h
create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_client_blt.c
create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_object_blt.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68106fe35a04..a1690aade273 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -90,6 +90,7 @@ i915-y += \
i915_cmd_parser.o \
i915_gem_batch_pool.o \
i915_gem_clflush.o \
+ i915_gem_client_blt.o \
i915_gem_context.o \
i915_gem_dmabuf.o \
i915_gem_evict.o \
@@ -99,6 +100,7 @@ i915-y += \
i915_gem_internal.o \
i915_gem.o \
i915_gem_object.o \
+ i915_gem_object_blt.o \
i915_gem_pm.o \
i915_gem_render_state.o \
i915_gem_shrinker.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index a34ece53a771..7e95827b0726 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -180,6 +180,7 @@
#define GFX_OP_DRAWRECT_INFO_I965 ((0x7900<<16)|0x2)
#define COLOR_BLT_CMD (2<<29 | 0x40<<22 | (5-2))
+#define XY_COLOR_BLT_CMD (2<<29 | 0x50<<22)
#define SRC_COPY_BLT_CMD ((2<<29)|(0x43<<22)|4)
#define XY_SRC_COPY_BLT_CMD((2<<29)|(0x53<<22)|6)
#define XY_MONO_SRC_COPY_IMM_BLT ((2<<29)|(0x71<<22)|5)
diff --git a/drivers/gpu/drm/i915/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/i915_gem_client_blt.c
new file mode 100644
index ..0a25df8d567a
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_client_blt.c
@@ -0,0 +1,297 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+#include "i915_gem_client_blt.h"
+
+#include "i915_gem_object_blt.h"
+#include "intel_drv.h"
+
+struct i915_sleeve {
+ struct i915_vma *vma;
+ struct drm_i915_gem_object *obj;
+ struct sg_table *pages;
+ struct i915_page_sizes page_sizes;
+};
+
+static int vma_set_pages(struct i915_vma *vma)
+{
+ struct i915_sleeve *sleeve = vma->private;
+
+ vma->pages = sleeve->pages;
+ vma->page_sizes = sleeve->page_sizes;
+
+ return 0;
+}
+
+static void vma_clear_pages(struct i915_vma *vma)
+{
+ GEM_BUG_ON(!vma->pages);
+ vma->pages = NULL;
+}
+
+static int vma_bind(struct i915_vma *vma,
+ enum i915_cache_level cache_level,
+ u32 flags)
+{
+ return vma->vm->vma_ops.bind_vma(vma, cache_level, flags);
+}
+
+static void vma_unbind(struct i915_vma *vma)
+{
+ vma->vm->vma_ops.unbind_vma(vma);
+}
+
+static const struct i915_vma_ops proxy_vma_ops = {
+ .set_pages = vma_set_pages,
+ .clear_pages = vma_clear_pages,
+ .bind_vma = vma_bind,
+ .unbind_vma = vma_unbind,
+};
+
+static struct i915_sleeve *create_sleeve(struct i915_address_space *vm,
+struct drm_i915_gem_object *obj,
+struct sg_table *pages,
+struct i915_page_sizes *page_sizes)
+{
+ struct i915_sleeve *sleeve;
+ struct i915_vma *vma;
+ int err;
+
+ sleeve = kzalloc(sizeof(*sleeve), GFP_KERNEL);
+ if (!sleeve)
+ return ERR_PTR(-ENOMEM);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_free;
+ }
+
+ vma->private = sleeve;
+ vma->ops = _vma_ops;
+
+ sleeve->vma = vma;
+ sleeve->obj = i915_gem_object_get(obj);
+ sleeve->pages = pages;
+ sleeve->page_sizes = *page_sizes;
+
+
Re: [Intel-gfx] [PATCH 06/13] drm/i915: Cancel retire_worker on parking
On 03/05/2019 12:52, Chris Wilson wrote:
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although that the igt is trying to idle from one child while submitting
from another may be a contributing factor as to why it runs so slowly...
v2: Use the non-sync version of cancel_delayed_work(), we only need to
stop it from being scheduled as we independently check whether now is
the right time to be parking.
Testcase: igt/gem_concurrent_blit
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index ae91ad7cb31e..fa9c2ebd966a 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
container_of(work, typeof(*i915), gem.idle_work);
+ bool restart = true;
+ cancel_delayed_work(>gem.retire_work);
mutex_lock(>drm.struct_mutex);
intel_wakeref_lock(>gt.wakeref);
- if (!intel_wakeref_active(>gt.wakeref) && !work_pending(work))
+ if (!intel_wakeref_active(>gt.wakeref) && !work_pending(work)) {
i915_gem_park(i915);
+ restart = false;
+ }
intel_wakeref_unlock(>gt.wakeref);
mutex_unlock(>drm.struct_mutex);
+ if (restart)
+ queue_delayed_work(i915->wq,
+ >gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static void retire_work_handler(struct work_struct *work)
@@ -52,10 +60,9 @@ static void retire_work_handler(struct work_struct *work)
mutex_unlock(>drm.struct_mutex);
}
- if (intel_wakeref_active(>gt.wakeref))
- queue_delayed_work(i915->wq,
- >gem.retire_work,
- round_jiffies_up_relative(HZ));
+ queue_delayed_work(i915->wq,
+ >gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static int pm_notifier(struct notifier_block *nb,
@@ -140,7 +147,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- drain_delayed_work(>gem.retire_work);
GEM_BUG_ON(i915->gt.awake);
flush_work(>gem.idle_work);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d919f512042c..9fd02025d382 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -58,7 +58,6 @@ static void mock_device_release(struct drm_device *dev)
i915_gem_contexts_lost(i915);
mutex_unlock(>drm.struct_mutex);
- drain_delayed_work(>gem.retire_work);
flush_work(>gem.idle_work);
i915_gem_drain_workqueue(i915);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-tip:drm-tip 5/8] drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 73db4ec12f05160528884c0b2c845b1c6b7c6718
commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout b9a2acf7709f52c77dc752ec99e3873e392d8df6
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of
>> 'i915_request_await_start'
i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
^~~~
drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of
'i915_request_await_start' was here
i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
^~~~
drivers/gpu/drm/i915/i915_request.c:794:1: warning:
'i915_request_await_start' defined but not used [-Wunused-function]
vim +/i915_request_await_start +827 drivers/gpu/drm/i915/i915_request.c
ca6e56f65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 825
a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson 2016-09-09 826
static int
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 @827
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 828
{
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 829
if (list_is_first(>ring_link, >ring->request_list))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 830
return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 831
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 832
signal = list_prev_entry(signal, ring_link);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 833
if (i915_timeline_sync_is_later(rq->timeline, >fence))
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 834
return 0;
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 835
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 836
return i915_sw_fence_await_dma_fence(>submit,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 837
>fence, 0,
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 838
I915_FENCE_GFP);
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 839
}
e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 840
:: The code at line 827 was first introduced by commit
:: e766fde6511e2be83acbca1d603035e08de23f3b drm/i915: Delay semaphore
submission until the start of the signaler
:: TO: Chris Wilson
:: CC: Joonas Lahtinen
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/13] drm/i915: Remove delay for idle_work
On 03/05/2019 12:52, Chris Wilson wrote:
The original intent for the delay before running the idle_work was to
provide a hysteresis to avoid ping-ponging the device runtime-pm. Since
then we have also pulled in some memory management and general device
management for parking. But with the inversion of the wakeref handling,
GEM is no longer responsible for the wakeref and by the time we call the
idle_work, the device is asleep. It seems appropriate now to drop the
delay and just run the worker immediately to flush the cached GEM state
before sleeping.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_pm.c| 21 +++
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
5 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index da4fb9f34d27..674c8c936057 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3931,8 +3931,8 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_IDLE) {
do {
flush_delayed_work(>gem.retire_work);
- drain_delayed_work(>gem.idle_work);
} while (READ_ONCE(i915->gt.awake));
+ flush_work(>gem.idle_work);
}
if (val & DROP_FREED)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64fa353a62bb..2bf518fea36e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2031,7 +2031,7 @@ struct drm_i915_private {
* arrive within a small period of time, we fire
* off the idle_work.
*/
- struct delayed_work idle_work;
+ struct work_struct idle_work;
} gem;
/* For i945gm vblank irq vs. C3 workaround */
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 49b0ce594f20..ae91ad7cb31e 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private *i915)
static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
- container_of(work, typeof(*i915), gem.idle_work.work);
+ container_of(work, typeof(*i915), gem.idle_work);
mutex_lock(>drm.struct_mutex);
intel_wakeref_lock(>gt.wakeref);
- if (!intel_wakeref_active(>gt.wakeref))
+ if (!intel_wakeref_active(>gt.wakeref) && !work_pending(work))
i915_gem_park(i915);
intel_wakeref_unlock(>gt.wakeref);
@@ -74,9 +74,7 @@ static int pm_notifier(struct notifier_block *nb,
break;
case INTEL_GT_PARK:
- mod_delayed_work(i915->wq,
->gem.idle_work,
-msecs_to_jiffies(100));
+ queue_work(i915->wq, >gem.idle_work);
break;
}
@@ -142,16 +140,11 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- GEM_BUG_ON(i915->gt.awake);
- cancel_delayed_work_sync(>gpu_error.hangcheck_work);
-
drain_delayed_work(>gem.retire_work);
+ GEM_BUG_ON(i915->gt.awake);
+ flush_work(>gem.idle_work);
- /*
-* As the idle_work is rearming if it detects a race, play safe and
-* repeat the flush until it is definitely idle.
-*/
- drain_delayed_work(>gem.idle_work);
+ cancel_delayed_work_sync(>gpu_error.hangcheck_work);
i915_gem_drain_freed_objects(i915);
@@ -242,7 +235,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
void i915_gem_init__pm(struct drm_i915_private *i915)
{
- INIT_DELAYED_WORK(>gem.idle_work, idle_work_handler);
+ INIT_WORK(>gem.idle_work, idle_work_handler);
INIT_DELAYED_WORK(>gem.retire_work, retire_work_handler);
i915->gem.pm_notifier.notifier_call = pm_notifier;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
index 088b2aa05dcd..b926d1cd165d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -509,7 +509,7 @@ static void disable_retire_worker(struct drm_i915_private
*i915)
intel_gt_pm_get(i915);
cancel_delayed_work_sync(>gem.retire_work);
- cancel_delayed_work_sync(>gem.idle_work);
+ flush_work(>gem.idle_work);
}
static void restore_retire_worker(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
Re: [Intel-gfx] [v5][PATCH 11/11] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
On Tue, May 07, 2019 at 12:27:07AM +0530, Sharma, Swati2 wrote:
> On 07-May-19 12:03 AM, Ville Syrjälä wrote:
>
> > On Sat, May 04, 2019 at 10:41:40PM +0530, Swati Sharma wrote:
> >> v3: Rebase
> >> v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
> >> -Added the default label above the correct label [Jani]
> >> -Corrected smatch warn "variable dereferenced before check" [Dan
> >> Carpenter]
> >> v5: -Added condition (!blob1 && !blob2) return true [Jani]
> >> -Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani]
> >> -Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani]
> >>
> >> There are few things wrong in this patch:
> >> [1] For chv bit precision is 14, on what basis it should be assigned?
> > Like everything else it will more or less be a reverse of the
> > compute side. For CHV we need to look at cgm_mode, gamma_enable,
> > gamma_mode, and c8_planes. Hmm. We actually don't have readout for
> > c8_planes so I guess we'll have to make some kind of exception for
> > that one.
>
> By this I meant was, since I am assigning bit_precision on the basis
> of gamma_mode in the compare function like
> + case GAMMA_MODE_MODE_8BIT:
> + bit_precision = 8;
> etc. We have 8BIT, 10BIT and 12BIT GAMMA_MODES only.How will I
> assign 14BIT on the basis of GAMMA_MODES (or) is there some other
> option to assign precision. Please see the comparison code below.
Yeah, gamma_mode by itself is not sufficient in some of the cases.
It's highly platform dependent how you figure out the precision.
>
> >
> >> [2] For glk and icl, degamma LUT values are not rounded off, there
> >> should err=0 if using same function, how to make that exception?
> > You mean the degamma? Just set precision==16? Maybe I'm not
> > understanding the question.
>
> Again same query as above, if I set precision as 16..on what basis?
> Which GAMMA_MODE? (or) default i should set as 16?
The glk+ degamma is always 16bpc, so you just hardcode it.
>
> >
> >> [3] For glk, bit precision is 10 but gamma mode is 8BIT?
> > Not sure what you mean. glk gamma_mode works just like with
> > other ilk+ platforms (apart from not having the csc_mode
> > gamma vs. degamma control).
>
> Sorry..my bad!
>
> >
> > I suspect the most annoying case is ivb-bdw 10bit gamma mode
> > since we probably don't have the full readout to do the reverse
> > mapping of whether the LUT is used as gamma or degamma. But I
> > guess we'll just have to compare it against whichever one the
> > software state has.
>
> One last query, as there is difference in precision of gamma and
> degamma..we have one comparison function..how will we get to know whether
> blob received is degamma or gamma? Do we need to pass some kind of enum value
> to know comparison needs to be done for gamma or degamma?
I think the comparison should just compare two blobs. Doesn't matter
what they are really.
>
> >
> >> Signed-off-by: Swati Sharma
> >> ---
> >> drivers/gpu/drm/i915/intel_color.c | 54
> >>
> >> drivers/gpu/drm/i915/intel_color.h | 6
> >> drivers/gpu/drm/i915/intel_display.c | 12
> >> 3 files changed, 72 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_color.c
> >> b/drivers/gpu/drm/i915/intel_color.c
> >> index 695b76d..73cb901 100644
> >> --- a/drivers/gpu/drm/i915/intel_color.c
> >> +++ b/drivers/gpu/drm/i915/intel_color.c
> >> @@ -1630,6 +1630,60 @@ static void ilk_read_luts(struct intel_crtc_state
> >> *crtc_state)
> >>crtc_state->base.gamma_lut = ilk_read_gamma_lut(crtc_state);
> >> }
> >>
> >> +static inline bool err_check(struct drm_color_lut *sw_lut, struct
> >> drm_color_lut *hw_lut, u32 err)
> >> +{
> >> + return ((abs((long)hw_lut->red - sw_lut->red)) <= err) &&
> >> + ((abs((long)hw_lut->blue - sw_lut->blue)) <= err) &&
> >> + ((abs((long)hw_lut->green - sw_lut->green)) <= err);
> >> +}
> >> +
> >> +bool intel_color_lut_equal(struct drm_property_blob *blob1,
> >> + struct drm_property_blob *blob2,
> >> + u32 gamma_mode)
> >> +{
> >> + struct drm_color_lut *sw_lut, *hw_lut;
> >> + int sw_lut_size, hw_lut_size, i;
> >> + u32 bit_precision, err;
> >> +
> >> + if (!blob1 && !blob2)
> >> + return true;
> >> +
> >> + if (!blob1 || !blob2)
> >> + return false;
> >> +
> >> + sw_lut_size = drm_color_lut_size(blob1);
> >> + hw_lut_size = drm_color_lut_size(blob2);
> >> +
> >> + if (sw_lut_size != hw_lut_size)
> >> + return false;
> >> +
> >> + switch(gamma_mode) {
> >> + default:
> >> + case GAMMA_MODE_MODE_8BIT:
> >> + bit_precision = 8;
> >> + break;
> >> + case GAMMA_MODE_MODE_10BIT:
> >> + case GAMMA_MODE_MODE_SPLIT:
> >> + bit_precision = 10;
> >> + break;
> >> + case GAMMA_MODE_MODE_12BIT:
> >> + bit_precision = 12;
> >> + break;
> >> + }
> >> +
> >> + sw_lut =
Re: [Intel-gfx] [PATCH 03/13] drm/i915: Assert the local engine->wakeref is active
On 03/05/2019 12:52, Chris Wilson wrote:
Due to the asynchronous tasklet and recursive GT wakeref, it may happen
that we submit to the engine (underneath it's own wakeref) prior to the
central wakeref being marked as taken. Switch to checking the local wakeref
for greater consistency.
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 5907a9613641..416d7e2e6f8c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1090,6 +1090,9 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (i915_reset_failed(engine->i915))
return true;
+ if (!intel_wakeref_active(>wakeref))
+ return true;
+
/* Waiting to drain ELSP? */
if (READ_ONCE(engine->execlists.active)) {
struct tasklet_struct *t = >execlists.tasklet;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7d69d07490e8..5580b6f1aa0c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -535,7 +535,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
* that all ELSP are drained i.e. we have processed the CSB,
* before allowing ourselves to idle and calling intel_runtime_pm_put().
*/
- GEM_BUG_ON(!engine->i915->gt.awake);
+ GEM_BUG_ON(!intel_wakeref_active(>wakeref));
/*
* ELSQ note: the submit queue is not cleared after being submitted
@@ -1085,7 +1085,7 @@ static void execlists_submission_tasklet(unsigned long
data)
GEM_TRACE("%s awake?=%d, active=%x\n",
engine->name,
- !!engine->i915->gt.awake,
+ !!intel_wakeref_active(>wakeref),
engine->execlists.active);
spin_lock_irqsave(>timeline.lock, flags);
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 02/13] drm/i915: Prefer checking the wakeref itself rather than the counter
On 03/05/2019 12:52, Chris Wilson wrote:
The counter goes to zero at the start of the parking cycle, but the
wakeref itself is held until the end. Likewise, the counter becomes one
at the end of the unparking, but the wakeref is taken first. If we check
the wakeref instead of the counter, we include the unpark/unparking time
as intel_wakeref_is_active(), and do not spuriously declare inactive if
we fail to park (i.e. the parking and wakeref drop is postponed).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_wakeref.c | 20 +---
drivers/gpu/drm/i915/intel_wakeref.h | 2 +-
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
b/drivers/gpu/drm/i915/intel_wakeref.c
index 1f94bc4ff9e4..91196d9612bb 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -7,6 +7,19 @@
#include "intel_drv.h"
#include "intel_wakeref.h"
+static void rpm_get(struct drm_i915_private *i915, struct intel_wakeref *wf)
+{
+ wf->wakeref = intel_runtime_pm_get(i915);
+}
+
+static void rpm_put(struct drm_i915_private *i915, struct intel_wakeref *wf)
+{
+ intel_wakeref_t wakeref = fetch_and_zero(>wakeref);
+
+ intel_runtime_pm_put(i915, wakeref);
+ GEM_BUG_ON(!wakeref);
+}
+
int __intel_wakeref_get_first(struct drm_i915_private *i915,
struct intel_wakeref *wf,
int (*fn)(struct intel_wakeref *wf))
@@ -21,11 +34,11 @@ int __intel_wakeref_get_first(struct drm_i915_private *i915,
if (!atomic_read(>count)) {
int err;
- wf->wakeref = intel_runtime_pm_get(i915);
+ rpm_get(i915, wf);
err = fn(wf);
if (unlikely(err)) {
- intel_runtime_pm_put(i915, wf->wakeref);
+ rpm_put(i915, wf);
mutex_unlock(>mutex);
return err;
}
@@ -46,7 +59,7 @@ int __intel_wakeref_put_last(struct drm_i915_private *i915,
err = fn(wf);
if (likely(!err))
- intel_runtime_pm_put(i915, wf->wakeref);
+ rpm_put(i915, wf);
else
atomic_inc(>count);
mutex_unlock(>mutex);
@@ -58,4 +71,5 @@ void __intel_wakeref_init(struct intel_wakeref *wf, struct
lock_class_key *key)
{
__mutex_init(>mutex, "wakeref", key);
atomic_set(>count, 0);
+ wf->wakeref = 0;
}
diff --git a/drivers/gpu/drm/i915/intel_wakeref.h
b/drivers/gpu/drm/i915/intel_wakeref.h
index a979d638344b..db742291211c 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -127,7 +127,7 @@ intel_wakeref_unlock(struct intel_wakeref *wf)
static inline bool
intel_wakeref_active(struct intel_wakeref *wf)
{
- return atomic_read(>count);
+ return READ_ONCE(wf->wakeref);
}
#endif /* INTEL_WAKEREF_H */
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 v2] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
On 03/05/2019 16:22, Chris Wilson wrote:
Inside the signal handler, we expect the requests to be ordered by their
breadcrumb such that no later request may be complete if we find an
earlier incomplete. Add an assert to check that the next breadcrumb
should not be logically before the current.
v2: Move the overhanging line into its own function and reuse it after
doing the insertion.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 3cbffd400b1b..fe455f01aa65 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -80,6 +80,22 @@ static inline bool __request_completed(const struct
i915_request *rq)
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
}
+__maybe_unused static bool
+check_signal_order(struct intel_context *ce, struct i915_request *rq)
+{
+ if (!list_is_last(>signal_link, >signals) &&
+ i915_seqno_passed(rq->fence.seqno,
+ list_next_entry(rq, signal_link)->fence.seqno))
+ return false;
+
+ if (!list_is_first(>signal_link, >signals) &&
+ i915_seqno_passed(list_prev_entry(rq, signal_link)->fence.seqno,
+ rq->fence.seqno))
+ return false;
+
+ return true;
+}
+
void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = >breadcrumbs;
@@ -99,6 +115,8 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
struct i915_request *rq =
list_entry(pos, typeof(*rq), signal_link);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
+
if (!__request_completed(rq))
break;
@@ -282,6 +300,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
list_add(>signal_link, pos);
if (pos == >signals) /* catch transitions from empty list */
list_move_tail(>signal_link, >signalers);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
set_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Acquire the signaler's timeline HWSP last
On 03/05/2019 15:02, Chris Wilson wrote: Acquiring the signaler's timeline takes an active reference to their HWSP that we would like to avoid if possible, so take it after performing all of our allocations required to set up the fencing. The acquisition also provides the final check that the target has not already signaled allowing us to avoid the semaphore at the last moment. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 6dbf8dc5cd6a..933a11677f4a 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -813,13 +813,13 @@ emit_semaphore_wait(struct i915_request *to, if (err < 0) return err; - /* We need to pin the signaler's HWSP until we are finished reading. */ - err = i915_timeline_read_hwsp(from, to, _offset); + /* Only submit our spinner after the signaler is running! */ + err = i915_request_await_execution(to, from, gfp); if (err) return err; - /* Only submit our spinner after the signaler is running! */ - err = i915_request_await_execution(to, from, gfp); + /* We need to pin the signaler's HWSP until we are finished reading. */ + err = i915_timeline_read_hwsp(from, to, _offset); if (err) return err; Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check the target has not already completed before waiting on it
On 03/05/2019 14:52, Chris Wilson wrote:
When we want to wait for a request to be executed, we first ask if it is
not on the GPU as if it's on the gpu, there's no need to wait. However,
we have to take into account that a request may not be on the GPU
because it has already completed!
The window is small due to the numerous preceding checks that our target
has not yet completed, yet there is still a very small window across the
kmalloc.
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchronisation
on gen8+")
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d06c45305b03..6dbf8dc5cd6a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -373,7 +373,7 @@ i915_request_await_execution(struct i915_request *rq,
init_irq_work(>work, irq_execute_cb);
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || i915_request_completed(signal)) {
i915_sw_fence_complete(cb->fence);
kmem_cache_free(global.slab_execute_cbs, cb);
} else {
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 v9] drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color
On Tue, May 07, 2019 at 09:42:48AM +0300, Jani Nikula wrote:
> On Mon, 29 Apr 2019, Aditya Swarup wrote:
> > From: Clinton Taylor
> >
> > v2: Fix commit msg to reflect why issue occurs(Jani)
> > Set GCP_COLOR_INDICATION only when we set 10/12 bit deep color.
> >
> > Changing settings from 10/12 bit deep color to 8 bit(& vice versa)
> > doesn't work correctly using xrandr max bpc property. When we
> > connect a monitor which supports deep color, the highest deep color
> > setting is selected; which sets GCP_COLOR_INDICATION. When we change
> > the setting to 8 bit color, we still set GCP_COLOR_INDICATION which
> > doesn't allow the switch back to 8 bit color.
> >
> > v3,4: Add comments & drop changes in intel_hdmi_compute_config(Ville)
> > Since HSW+, GCP_COLOR_INDICATION is not required for 8bpc.
> >
> > Drop the changes in intel_hdmi_compute_config as desired_bpp
> > is needed to change values for pipe_bpp based on bw_constrained flag.
> >
> > v5: Fix missing logical && in condition for setting GCP_COLOR_INDICATION.
> >
> > v6: Fix comment formatting (Ville)
> >
> > v7: Add reviewed by Ville
> >
> > v8: Set GCP_COLOR_INDICATION based on spec:
> > For Gen 7.5 or later platforms, indicate color depth only for deep
> > color modes. Bspec: 8135,7751,50524
> >
> > Pre DDI platforms, indicate color depth if deep color is supported
> > by sink. Bspec: 7854
> >
> > Exception: CHERRYVIEW behaves like Pre DDI platforms.
> > Bspec: 15975
> >
> > Check pipe_bpp is less than bpp * 3 in hdmi_deep_color_possible,
> > to not set 12 bit deep color for every modeset. This fixes the issue
> > where 12 bit color was selected even when user selected 10 bit.(Ville)
> >
> > v9: Maintain a consistent behavior for all platforms and support
> > GCP_COLOR_INDICATION only when we are in deep color mode. Remove
> > hdmi_sink_is_deep_color() - no longer needed as checking pipe_bpp > 24
> > takes care of the deep color mode scenario.
> >
> > Separate patch for fixing switch from 12 bit to 10 bit deep color
> > mode.
> >
> > Co-developed-by: Aditya Swarup
> > Signed-off-by: Clinton Taylor
> > Signed-off-by: Aditya Swarup
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Cc: Manasi Navare
> > Reviewed-by: Ville Syrjälä
>
> Ville, does this apply to this version of the patch?
Aye. lgtm
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/intel_hdmi.c | 17 ++---
> > 1 file changed, 2 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index e1005d7b75fd..991eb362ef4f 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -856,19 +856,6 @@ static void g4x_set_infoframes(struct intel_encoder
> > *encoder,
> > _state->infoframes.hdmi);
> > }
> >
> > -static bool hdmi_sink_is_deep_color(const struct drm_connector_state
> > *conn_state)
> > -{
> > - struct drm_connector *connector = conn_state->connector;
> > -
> > - /*
> > -* HDMI cloning is only supported on g4x which doesn't
> > -* support deep color or GCP infoframes anyway so no
> > -* need to worry about multiple HDMI sinks here.
> > -*/
> > -
> > - return connector->display_info.bpc > 8;
> > -}
> > -
> > /*
> > * Determine if default_phase=1 can be indicated in the GCP infoframe.
> > *
> > @@ -973,8 +960,8 @@ static void intel_hdmi_compute_gcp_infoframe(struct
> > intel_encoder *encoder,
> > crtc_state->infoframes.enable |=
> > intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GENERAL_CONTROL);
> >
> > - /* Indicate color depth whenever the sink supports deep color */
> > - if (hdmi_sink_is_deep_color(conn_state))
> > + /* Indicate color indication for deep color mode */
> > + if (crtc_state->pipe_bpp > 24)
> > crtc_state->infoframes.gcp |= GCP_COLOR_INDICATION;
> >
> > /* Enable default_phase whenever the display mode is suitably aligned */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8 01/10] drm: Add HDR source metadata property
On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> >Sent: Saturday, May 4, 2019 3:48 PM
> >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> >dri-
> >de...@lists.freedesktop.org
> >Cc: dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
> >Syrjala, Ville ; Lankhorst, Maarten
> >
> >Subject: Re: [v8 01/10] drm: Add HDR source metadata property
> >
> >On 2019-04-09 18:44, Uma Shankar wrote:
> >> This patch adds a blob property to get HDR metadata information from
> >> userspace. This will be send as part of AVI Infoframe to panel.
> >>
> >> It also implements get() and set() functions for HDR output metadata
> >> property.The blob data is received from userspace and saved in
> >> connector state, the same is returned as blob in get property call to
> >> userspace.
> >>
> >> v2: Rebase and modified the metadata structure elements as per Ville's
> >> POC changes.
> >>
> >> v3: No Change
> >>
> >> v4: Addressed Shashank's review comments
> >>
> >> v5: Rebase.
> >>
> >> v6: Addressed Brian Starkey's review comments, defined new structure
> >> with header for dynamic metadata scalability.
> >> Merge get/set property functions for metadata in this patch.
> >>
> >> v7: Addressed Jonas Karlman review comments and defined separate
> >> structure for infoframe to better align with CTA 861.G spec. Added
> >> Shashank's RB.
> >>
> >> Signed-off-by: Uma Shankar
> >> Reviewed-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_atomic.c | 2 ++
> >> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> >> drivers/gpu/drm/drm_connector.c | 6 ++
> >> include/drm/drm_connector.h | 11 +++
> >> include/drm/drm_mode_config.h | 6 ++
> >> include/linux/hdmi.h | 10 ++
> >> include/uapi/drm/drm_mode.h | 39
> >+++
> >> 7 files changed, 87 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c
> >> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -881,6 +881,8 @@ static void
> >> drm_atomic_connector_print_state(struct drm_printer *p,
> >>
> >>drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
> >>name);
> >>drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> >> "(null)");
> >> + drm_printf(p, "\thdr_metadata_changed=%d\n",
> >> + state->hdr_metadata_changed);
> >>
> >>if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> >>if (state->writeback_job && state->writeback_job->fb) diff --git
> >> a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index ea797d4..6d0d161 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -673,6 +673,8 @@ static int
> >> drm_atomic_connector_set_property(struct drm_connector *connector, {
> >>struct drm_device *dev = connector->dev;
> >>struct drm_mode_config *config = >mode_config;
> >> + bool replaced = false;
> >> + int ret;
> >>
> >>if (property == config->prop_crtc_id) {
> >>struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -721,6
> >> +723,14 @@ static int drm_atomic_connector_set_property(struct
> >> drm_connector
> >*connector,
> >> */
> >>if (state->link_status != DRM_LINK_STATUS_GOOD)
> >>state->link_status = val;
> >> + } else if (property == config->hdr_output_metadata_property) {
> >> + ret = drm_atomic_replace_property_blob_from_id(dev,
> >> + >hdr_output_metadata_blob_ptr,
> >> + val,
> >> + -1, sizeof(struct hdr_output_metadata),
> >> + );
> >> + state->hdr_metadata_changed |= replaced;
> >> + return ret;
> >>} else if (property == config->aspect_ratio_property) {
> >>state->picture_aspect_ratio = val;
> >>} else if (property == config->content_type_property) { @@ -807,6
> >> +817,9 @@ static int drm_atomic_connector_set_property(struct drm_connector
> >*connector,
> >>*val = state->colorspace;
> >>} else if (property == connector->scaling_mode_property) {
> >>*val = state->scaling_mode;
> >> + } else if (property == config->hdr_output_metadata_property) {
> >> + *val = (state->hdr_output_metadata_blob_ptr) ?
> >> + state->hdr_output_metadata_blob_ptr->base.id : 0;
> >>} else if (property == connector->content_protection_property) {
> >>*val = state->content_protection;
> >>} else if (property == config->writeback_fb_id_property) { diff
> >> --git a/drivers/gpu/drm/drm_connector.c
> >> b/drivers/gpu/drm/drm_connector.c index 2355124..0bdae90 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >>
