Re: [Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
On 15/05/2019 01:06, Rodrigo Vivi wrote: On Tue, May 14, 2019 at 06:32:01PM +, Summers, Stuart wrote: On Tue, 2019-05-14 at 17:53 +0100, Chris Wilson wrote: Quoting Stuart Summers (2019-05-14 17:46:52) To allow easier debug of platforms which do not fully support power-saving render C-state 6, add back the module parameter to allow RC6 flows to be disabled. Instead of directly affecting the RC6 states via a bitmask as done previously, use this module parameter to clear the has_rc6 field for these platforms. If you know which platforms don't support rc6, don't enable rc6. I'd really prefer to have this parameter in place for debug purposes. It seems more useful to allow quick testing by reloading i915 than by requiring a rebuild. Of course, once debug is complete and the platform is known to either not support the feature or has some cripling bug around this, I agree, rc6 shouldn't be enabled on that platform and i915 should be updated. Exactly. We need the flexibility for debug that. unfortunately using debugfs doesn't look a solution. One possibility that just came to my mind now is, what if we make this only for platforms that are still protected by is_alpha_support=1 (soon becoming require_force_probe=1) But this is just one side of the coin... when product is out there and we want the user to debug the issue to see if it is a RC6 bug we have no way to verify that. :/ Please let's add this back one way or another. To throw a compromise option out there - add the modparam for debug builds only (CONFIG_DRM_I915_DEBUG)? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drop unneeded -Wall addition
== Series Details == Series: drm/i915: drop unneeded -Wall addition URL : https://patchwork.freedesktop.org/series/60652/ State : success == Summary == CI Bug Log - changes from CI_DRM_6085 -> Patchwork_13019 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/ Known issues Here are the changes found in Patchwork_13019 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_6085/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: [PASS][3] -> [DMESG-WARN][4] ([fdo#106387]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6085/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/fi-ilk-650/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@gem_busy@basic-busy-default: - fi-icl-u2: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6085/fi-icl-u2/igt@gem_b...@basic-busy-default.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/fi-icl-u2/igt@gem_b...@basic-busy-default.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][7] ([fdo#102614]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6085/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [FAIL][9] ([fdo#110623]) -> [DMESG-FAIL][10] ([fdo#110620]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6085/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110623]: https://bugs.freedesktop.org/show_bug.cgi?id=110623 Participating hosts (52 -> 45) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-dsi fi-bdw-samus Build changes - * Linux: CI_DRM_6085 -> Patchwork_13019 CI_DRM_6085: 48d8cf5cc0aadd21924d05ad3e86b08d8e0e1c50 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4988: 2f6303d13e09b2457762540383c7f36cecd02bbf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13019: a38bfd30109f254440e1ae0b544c958a6a124db5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a38bfd30109f drm/i915: drop unneeded -Wall addition == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13019/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: drop unneeded -Wall addition
== Series Details == Series: drm/i915: drop unneeded -Wall addition URL : https://patchwork.freedesktop.org/series/60652/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: drop unneeded -Wall addition - +./arch/x86/include/asm/pgtable_64.h:61:9: warning: cast from non-scalar +./arch/x86/include/asm/pgtable_64.h:61:9: warning: cast to non-scalar +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'i915_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_sseu.c:82:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/mmio.c:281:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_cmd_parser.c:1105:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_cmd_parser.c:1105:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4033:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4033:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4087:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4087:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4143:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4143:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1219:36: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1219:36: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_fixed.h:50:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1247:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1247:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1689:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1689:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1689:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1689:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1804:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1804:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:3390:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:3390:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:4912:36: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:842:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:842:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_execbuffer.c:1514:25: warning: expression using sizeof(void)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: drop unneeded -Wall addition
== Series Details == Series: drm/i915: drop unneeded -Wall addition URL : https://patchwork.freedesktop.org/series/60652/ State : warning == Summary == $ dim checkpatch origin/drm-tip a38bfd30109f drm/i915: drop unneeded -Wall addition -:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #8: KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \ total: 0 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: drop unneeded -Wall addition
The top level Makefile adds -Wall globally: KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \ I see two "-Wall" added for compiling under drivers/gpu/drm/i915/. Signed-off-by: Masahiro Yamada --- BTW, I have a question in the comment: "Note the danger in using -Wall -Wextra is that when CI updates gcc we will most likely get a sudden build breakage... Hopefully we will fix new warnings before CI updates!" Enabling whatever warning options does not cause build breakage. -Werror does. So, I think the correct statement is: "Note the danger in using -Werror is that when CI updates gcc we ... ^^^ drivers/gpu/drm/i915/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index fbcb0904f4a8..4a4f60c7edfc 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -12,7 +12,7 @@ # Note the danger in using -Wall -Wextra is that when CI updates gcc we # will most likely get a sudden build breakage... Hopefully we will fix # new warnings before CI updates! -subdir-ccflags-y := -Wall -Wextra +subdir-ccflags-y := -Wextra subdir-ccflags-y += $(call cc-disable-warning, unused-parameter) subdir-ccflags-y += $(call cc-disable-warning, type-limits) subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with drm/i915: Mark semaphores as complete on unsubmit out if payload was started (rev2)
== Series Details ==
Series: series starting with drm/i915: Mark semaphores as complete on unsubmit
out if payload was started (rev2)
URL : https://patchwork.freedesktop.org/series/60642/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6082_full -> Patchwork_13018_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_13018_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_cursor_crc@pipe-a-cursor-suspend}:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
Known issues
Here are the changes found in Patchwork_13018_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@vcs0-s3:
- shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-apl1/igt@gem_ctx_isolat...@vcs0-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-apl2/igt@gem_ctx_isolat...@vcs0-s3.html
* igt@i915_suspend@fence-restore-untiled:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-apl1/igt@i915_susp...@fence-restore-untiled.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-apl1/igt@i915_susp...@fence-restore-untiled.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt:
- shard-glk: [PASS][7] -> [INCOMPLETE][8] ([fdo#103359] /
[k.org#198133])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-glk4/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-glk2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-iclb2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-render.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-iclb1/igt@kms_frontbuffer_track...@fbc-rgb565-draw-render.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-skl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-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_6082/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-iclb2/igt@kms_psr2_su@page_flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-iclb1/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +3 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-iclb5/igt@kms_psr@psr2_primary_mmap_cpu.html
Possible fixes
* igt@gem_tiled_swapping@non-threaded:
- shard-hsw: [FAIL][19] ([fdo#108686]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-hsw2/igt@gem_tiled_swapp...@non-threaded.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-hsw7/igt@gem_tiled_swapp...@non-threaded.html
* igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl: [INCOMPLETE][21] ([fdo#104108] / [fdo#107773] /
[fdo#107807]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/shard-skl3/igt@i915_pm_...@system-suspend-modeset.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/shard-skl10/igt@i915_pm_...@system-suspend-modeset.html
*
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev10)
URL : https://patchwork.freedesktop.org/series/25091/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13017_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_13017_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13017_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_13017_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- shard-iclb: [PASS][1] -> [SKIP][2] +43 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@gem_exec_susp...@basic-s3.html
* igt@kms_prop_blob@invalid-set-prop-any:
- shard-iclb: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@kms_prop_b...@invalid-set-prop-any.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@kms_prop_b...@invalid-set-prop-any.html
Warnings
* igt@gem_mocs_settings@mocs-settings-ctx-dirty-render:
- shard-iclb: [SKIP][5] ([fdo#110206]) -> [SKIP][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
* igt@kms_atomic_transition@3x-modeset-transitions-nonblocking:
- shard-iclb: [SKIP][7] ([fdo#109278]) -> [SKIP][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@kms_atomic_transit...@3x-modeset-transitions-nonblocking.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@kms_atomic_transit...@3x-modeset-transitions-nonblocking.html
* igt@kms_chamelium@hdmi-crc-abgr:
- shard-iclb: [SKIP][9] ([fdo#109284]) -> [SKIP][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@kms_chamel...@hdmi-crc-abgr.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@kms_chamel...@hdmi-crc-abgr.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-blt:
- shard-iclb: [SKIP][11] ([fdo#109280]) -> [SKIP][12] +6 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@kms_frontbuffer_track...@psr-2p-primscrn-pri-shrfb-draw-blt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@kms_frontbuffer_track...@psr-2p-primscrn-pri-shrfb-draw-blt.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_schedule@semaphore-resolve}:
- shard-iclb: [FAIL][13] ([fdo#110519]) -> [SKIP][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@gem_exec_sched...@semaphore-resolve.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@gem_exec_sched...@semaphore-resolve.html
* {igt@kms_cursor_crc@pipe-b-cursor-64x21-random}:
- shard-iclb: [PASS][15] -> [SKIP][16] +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-iclb5/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
Known issues
Here are the changes found in Patchwork_13017_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-suspend:
- shard-apl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +3
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-apl5/igt@gem_...@in-flight-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-apl3/igt@gem_...@in-flight-suspend.html
* igt@kms_draw_crc@fill-fb:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#103184])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-skl1/igt@kms_draw_...@fill-fb.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-skl8/igt@kms_draw_...@fill-fb.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk: [PASS][21] -> [FAIL][22] ([fdo#102887] / [fdo#105363])
[21]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Re-add enable_rc6 modparam
== Series Details == Series: series starting with [1/2] drm/i915: Re-add enable_rc6 modparam URL : https://patchwork.freedesktop.org/series/60637/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13016_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13016_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13016_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13016_full: ### IGT changes ### Possible regressions * igt@gem_mocs_settings@mocs-settings-render: - shard-iclb: [PASS][1] -> [SKIP][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb1/igt@gem_mocs_setti...@mocs-settings-render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-iclb7/igt@gem_mocs_setti...@mocs-settings-render.html Warnings * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-iclb: [SKIP][3] ([fdo#109274]) -> [SKIP][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-iclb7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_psr@psr2_suspend: - shard-iclb: [SKIP][5] ([fdo#109441]) -> [SKIP][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb1/igt@kms_psr@psr2_suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-iclb7/igt@kms_psr@psr2_suspend.html Known issues Here are the changes found in Patchwork_13016_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@hibernate: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@gem_...@hibernate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-iclb1/igt@gem_...@hibernate.html * igt@gem_eio@suspend: - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103665]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-kbl4/igt@gem_...@suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-kbl1/igt@gem_...@suspend.html - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-apl7/igt@gem_...@suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-apl1/igt@gem_...@suspend.html - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-skl6/igt@gem_...@suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-skl1/igt@gem_...@suspend.html - shard-glk: [PASS][15] -> [INCOMPLETE][16] ([fdo#103359] / [k.org#198133]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-glk6/igt@gem_...@suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-glk7/igt@gem_...@suspend.html * igt@i915_pm_rpm@gem-mmap-cpu: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#107807]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-skl7/igt@i915_pm_...@gem-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-skl6/igt@i915_pm_...@gem-mmap-cpu.html * igt@kms_draw_crc@fill-fb: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#103184]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-skl1/igt@kms_draw_...@fill-fb.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-skl9/igt@kms_draw_...@fill-fb.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][21] -> [FAIL][22] ([fdo#102887] / [fdo#105363]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/shard-glk4/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html [24]:
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
On Tue, May 14, 2019 at 06:32:01PM +, Summers, Stuart wrote: > On Tue, 2019-05-14 at 17:53 +0100, Chris Wilson wrote: > > Quoting Stuart Summers (2019-05-14 17:46:52) > > > To allow easier debug of platforms which do not fully support > > > power-saving render C-state 6, add back the module parameter > > > to allow RC6 flows to be disabled. Instead of directly affecting > > > the RC6 states via a bitmask as done previously, use this module > > > parameter to clear the has_rc6 field for these platforms. > > > > If you know which platforms don't support rc6, don't enable rc6. > > I'd really prefer to have this parameter in place for debug purposes. > It seems more useful to allow quick testing by reloading i915 than by > requiring a rebuild. > > Of course, once debug is complete and the platform is known to either > not support the feature or has some cripling bug around this, I agree, > rc6 shouldn't be enabled on that platform and i915 should be updated. Exactly. We need the flexibility for debug that. unfortunately using debugfs doesn't look a solution. One possibility that just came to my mind now is, what if we make this only for platforms that are still protected by is_alpha_support=1 (soon becoming require_force_probe=1) But this is just one side of the coin... when product is out there and we want the user to debug the issue to see if it is a RC6 bug we have no way to verify that. :/ Please let's add this back one way or another. Thanks, Rodrigo. > > Thanks, > Stuart > > > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: adding state checker for gamma lut values (rev9)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev9) URL : https://patchwork.freedesktop.org/series/58039/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6080_full -> Patchwork_13015_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13015_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13015_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13015_full: ### IGT changes ### Possible regressions * igt@kms_available_modes_crc@available_mode_test_crc: - shard-snb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/shard-snb4/igt@kms_available_modes_crc@available_mode_test_crc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-snb6/igt@kms_available_modes_crc@available_mode_test_crc.html * igt@kms_color@pipe-a-ctm-negative: - shard-skl: [PASS][3] -> [DMESG-WARN][4] +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/shard-skl5/igt@kms_co...@pipe-a-ctm-negative.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-skl2/igt@kms_co...@pipe-a-ctm-negative.html * igt@kms_color@pipe-b-ctm-negative: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/shard-kbl7/igt@kms_co...@pipe-b-ctm-negative.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-kbl4/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_color@pipe-b-ctm-red-to-blue: - shard-hsw: [PASS][7] -> [DMESG-WARN][8] +11 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/shard-hsw2/igt@kms_co...@pipe-b-ctm-red-to-blue.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw6/igt@kms_co...@pipe-b-ctm-red-to-blue.html * igt@kms_color@pipe-b-degamma: - shard-skl: NOTRUN -> [DMESG-WARN][9] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-skl8/igt@kms_co...@pipe-b-degamma.html * igt@kms_color@pipe-c-ctm-0-25: - shard-apl: [PASS][10] -> [DMESG-WARN][11] +6 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/shard-apl1/igt@kms_co...@pipe-c-ctm-0-25.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-apl2/igt@kms_co...@pipe-c-ctm-0-25.html * igt@runner@aborted: - shard-hsw: NOTRUN -> ([FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw6/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw7/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw7/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw7/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw6/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw7/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw6/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw1/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw4/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw2/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw1/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-hsw1/igt@run...@aborted.html - shard-snb: NOTRUN -> [FAIL][24] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-snb6/igt@run...@aborted.html - shard-kbl: NOTRUN -> ([FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-kbl3/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-kbl1/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-kbl1/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/shard-kbl1/igt@run...@aborted.html [29]:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 19/21] gem_wsim: Per context SSEU control
Quoting Tvrtko Ursulin (2019-05-08 13:10:56)
> +static void get_device_sseu(void)
> +{
> + struct drm_i915_gem_context_param param = { };
> +
> + param.param = I915_CONTEXT_PARAM_SSEU;
> + param.value = (uintptr_t)_sseu;
> +
> + gem_context_get_param(fd, );
This is an annoying assert that prevents running on v4.19. Looks fine to
fail?
-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 series starting with drm/i915: Mark semaphores as complete on unsubmit out if payload was started (rev2)
== Series Details ==
Series: series starting with drm/i915: Mark semaphores as complete on unsubmit
out if payload was started (rev2)
URL : https://patchwork.freedesktop.org/series/60642/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6082 -> Patchwork_13018
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/
Known issues
Here are the changes found in Patchwork_13018 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@kms_chamelium@dp-hpd-fast:
- fi-icl-u2: [DMESG-WARN][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6082/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.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
Participating hosts (51 -> 45)
--
Additional (1): fi-bsw-n3050
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6082 -> Patchwork_13018
CI_DRM_6082: 82fb452ccd097504e53d79fb8dadecb0d8de8748 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4988: 2f6303d13e09b2457762540383c7f36cecd02bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13018: 0bbc1fee19ed1fc91050e4c2dc5c9ce26a3d06fa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0bbc1fee19ed drm/i915: Downgrade NEWCLIENT to non-preemptive
ad36e68fae40 drm/i915: Bump signaler priority on adding a waiter
558924c77146 drm/i915: Truly bump ready tasks ahead of busywaits
b89780ed0a75 drm/i915: Mark semaphores as complete on unsubmit out if payload
was started
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13018/
___
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: Re-add enable_rc6 modparam
On Tue, 2019-05-14 at 17:53 +0100, Chris Wilson wrote: > Quoting Stuart Summers (2019-05-14 17:46:52) > > To allow easier debug of platforms which do not fully support > > power-saving render C-state 6, add back the module parameter > > to allow RC6 flows to be disabled. Instead of directly affecting > > the RC6 states via a bitmask as done previously, use this module > > parameter to clear the has_rc6 field for these platforms. > > If you know which platforms don't support rc6, don't enable rc6. I'd really prefer to have this parameter in place for debug purposes. It seems more useful to allow quick testing by reloading i915 than by requiring a rebuild. Of course, once debug is complete and the platform is known to either not support the feature or has some cripling bug around this, I agree, rc6 shouldn't be enabled on that platform and i915 should be updated. Thanks, Stuart > -Chris smime.p7s Description: S/MIME cryptographic signature ___ 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 drm/i915: Mark semaphores as complete on unsubmit out if payload was started (rev2)
== Series Details ==
Series: series starting with drm/i915: Mark semaphores as complete on unsubmit
out if payload was started (rev2)
URL : https://patchwork.freedesktop.org/series/60642/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b89780ed0a75 drm/i915: Mark semaphores as complete on unsubmit out if payload
was started
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#12:
References: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ca6e56f654e7 ("drm/i915: Disable
semaphore busywaits on saturated systems")'
#12:
References: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
total: 1 errors, 1 warnings, 0 checks, 12 lines checked
558924c77146 drm/i915: Truly bump ready tasks ahead of busywaits
ad36e68fae40 drm/i915: Bump signaler priority on adding a waiter
0bbc1fee19ed drm/i915: Downgrade NEWCLIENT to non-preemptive
-:37: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b16c765122f9 ("drm/i915:
Priority boost for new clients")'
#37:
References: b16c765122f9 ("drm/i915: Priority boost for new clients")
total: 1 errors, 0 warnings, 0 checks, 33 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Refactor oa object to better manage resources
On Tue, May 14, 2019 at 10:34:49AM +0100, Lionel Landwerlin wrote:
Hi Umesh,
I just noticed this different between v1 & v2.
My understanding is that if destroy() is called, stream should be the
same as dev_priv->perf.exclusive_stream.
If it's not it sounds like a bug. So why change this?
v2 fixes only checkpatch warnings. it warned on use of BUG_ON. BUG_ON is
intended to crash the system in severe cases where the driver/kernel is
unusable. In this case, the mismatch between user passed information and
exclusive_stream may not require a crash.
-Lionel
On 03/05/2019 00:13, Umesh Nerlige Ramappa wrote:
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct drm_i915_private *dev_priv = stream->dev_priv;
- BUG_ON(stream != dev_priv->perf.oa.exclusive_stream);
+ if (stream != dev_priv->perf.exclusive_stream) {
+ WARN_ON_ONCE(stream != dev_priv->perf.exclusive_stream);
+ return;
+ }
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Mark semaphores as complete on unsubmit out if payload was started
Avoid charging us for the presumed busywait if the request was preempted
after successfully using semaphores to reduce inter-engine latency.
v2: Bump the priority to reflect the lack of semaphores now required.
References: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bed213148cbb..11670774cd25 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -509,6 +509,12 @@ void __i915_request_unsubmit(struct i915_request *request)
/* Transfer back from the global per-engine timeline to per-context */
move_to_timeline(request, request->timeline);
+ /* We've already spun, don't charge on resubmitting. */
+ if (request->sched.semaphores && i915_request_started(request)) {
+ request->sched.attr.priority |= I915_PRIORITY_NOSEMAPHORE;
+ request->sched.semaphores = 0;
+ }
+
/*
* We don't need to wake_up any waiters on request->execute, they
* will get woken by any other event or us re-adding this request
--
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: Bump signaler priority on adding a waiter
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event reordering the no-preemption
WAITs. To resolve this issue we currently promote all requests to WAIT
on unsubmission, however this interferes with the timeslicing
requirement that we do not apply any implicit promotion that will defeat
the round-robin timeslice list. (If we automatically promote the active
request it will go back to the head of the queue and not the tail!)
So we need implicit promotion to prevent reordering around semaphores
where we are not allowed to preempt, and we must avoid implicit
promotion on unsubmission. So instead of at unsubmit, if we apply that
implicit promotion on adding the dependency, we avoid the semaphore
deadlock and we also reduce the gains made by the promotion for user
space waiting. Furthermore, by keeping the earlier dependencies at a
higher level, we reduce the search space for timeslicing without
altering runtime scheduling too badly (no dependencies at all will be
assigned a higher priority for rrul).
v2: Limit the bump to external edges (as originally intended) i.e.
between contexts and out to the user.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 12
drivers/gpu/drm/i915/i915_request.c | 9 -
drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
drivers/gpu/drm/i915/i915_scheduler_types.h | 3 ++-
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 4b042893dc0e..5b3d8e33f1cf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -98,12 +98,14 @@ static int live_busywait_preempt(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_unlock;
- ctx_hi->sched.priority = INT_MAX;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = INT_MIN;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
@@ -958,12 +960,14 @@ static int live_preempt_hang(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_spin_lo;
- ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
for_each_engine(engine, i915, id) {
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bcb3b54cb806..9755c3f89020 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -489,15 +489,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 5581c5004ff0..d215dcdf0b1e 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -387,6 +387,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
[Intel-gfx] [PATCH 1/4] drm/i915: Mark semaphores as complete on unsubmit out if payload was started
Avoid charging us for the presumed busywait if the request was preempted
after successfully using semaphores to reduce inter-engine latency.
References: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bed213148cbb..4e6a7f37fffc 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -509,6 +509,10 @@ void __i915_request_unsubmit(struct i915_request *request)
/* Transfer back from the global per-engine timeline to per-context */
move_to_timeline(request, request->timeline);
+ /* We've already spun, don't charge on resubmitting. */
+ if (request->sched.semaphores && i915_request_started(request))
+ request->sched.semaphores = 0;
+
/*
* We don't need to wake_up any waiters on request->execute, they
* will get woken by any other event or us re-adding this request
--
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: Downgrade NEWCLIENT to non-preemptive
Commit 1413b2bc0717 ("drm/i915: Trim NEWCLIENT boosting") had the
intended consequence of not allowing a sequence of work that merely
crossed into a new engine the privilege to be promoted to NEWCLIENT
status. It also had the unintended consequence of actually making
NEWCLIENT effective on heavily oversubscribed transcode machines and
impacting upon their throughput.
If we consider a client packet composed of (rcsA, rcsB, vcs) and 30 of
those clients, using the NEWCLIENT boost that will be scheduled as
rcsA x 30, (rcsB, vcs) x 30
where as before it would have been
(rcsA, rcsB, vcs) x 30
That is with NEWCLIENT only boosting the first request of each client,
we would execute all rcsA requests prior to running on the vcs engines;
acruing a lot of dead time as compared to the previous case where the
vcs engine would be started in parallel to processing the second client.
The previous patch has the effect of delaying submission until it is
required by a third party (either the user with an explicit wait, or by
another client/engine). We reduce the NEWCLIENT bump to a mere WAIT,
which has the effect of removing its preemptive grant and reducing it to
the same level as any other user interaction -- that it will not be
promoted above the interengine dependencies, and so preventing NEWCLIENTS
from starving other engines. This a large nerf to the rrul properties of
the current NEWCLIENT, but it still does give prioritised submission to
new requests from light workloads.
References: b16c765122f9 ("drm/i915: Priority boost for new clients")
Fixes: 1413b2bc0717 ("drm/i915: Trim NEWCLIENT boosting") # customer impact
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
Cc: Dmitry Ermilov
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/i915_priolist_types.h | 5 ++---
drivers/gpu/drm/i915/i915_request.c| 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e18623def282..b5e82171df8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -164,7 +164,7 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
-#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT | I915_PRIORITY_NOSEMAPHORE)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NOSEMAPHORE)
static int execlists_context_deferred_alloc(struct intel_context *ce,
struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/i915_priolist_types.h
b/drivers/gpu/drm/i915/i915_priolist_types.h
index cc44ebd3b553..49709de69875 100644
--- a/drivers/gpu/drm/i915/i915_priolist_types.h
+++ b/drivers/gpu/drm/i915/i915_priolist_types.h
@@ -20,15 +20,14 @@ enum {
I915_PRIORITY_INVALID = INT_MIN
};
-#define I915_USER_PRIORITY_SHIFT 3
+#define I915_USER_PRIORITY_SHIFT 2
#define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_MASK (I915_PRIORITY_COUNT - 1)
#define I915_PRIORITY_WAIT ((u8)BIT(0))
-#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
-#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(2))
+#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(1))
#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 9755c3f89020..c54cbda82625 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1187,7 +1187,7 @@ struct i915_request *__i915_request_commit(struct
i915_request *rq)
* the bulk clients. (FQ_CODEL)
*/
if (list_empty(>sched.signalers_list))
- attr.priority |= I915_PRIORITY_NEWCLIENT;
+ attr.priority |= I915_PRIORITY_WAIT;
engine->schedule(rq, );
}
--
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: Truly bump ready tasks ahead of busywaits
In commit b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of
busywaits"), I tried cutting a corner in order to not install a signal
for each of our dependencies, and only listened to requests on which we
were intending to busywait. The compromise that was made was that
instead of then being able to promite the request with a full
NOSEMAPHORE like its non-busywaiting brethren, as we had not ensured we
had cleared the semaphore chain, we settled for only using the NEWCLIENT
boost. With an over saturated system with multiple NEWCLIENTS in flight
at any time, this was found to be an inadequate promotion and left us
with a much poorer scheduling order than prior to using semaphores.
The outcome of this patch, is that all requests have NOSEMAPHORE
priority when they have no dependencies and are ready to run and not
busywait, restoring the pre-semaphore ordering on saturated systems.
We can demonstrate the effect of poor scheduling order by oversaturating
the system using gem_wsim on a system with multiple vcs engines
(i.e running the same workloads across more clients than required for
peak throughput, e.g. media_load_balance_17i7.wsim -c4 -b context):
x v5.1 (normalized)
+ tip
* fix
++
|x |
|x |
|x |
|x |
| %x |
| %%x |
| %%x |
| %%x |
| %%x |
| %%x |
| %%x |
| %%x |
| %%x |
| %%x |
| %%x |
| %#x |
| %#x |
| %#x |
| %#x |
| %#x |
| +%#xx |
| +%#xx |
| + %%#xx |
| + %%#xx |
| + %%#xx |
| + %%#xx |
| + %%##x |
| +++ %%##x |
| +++ %%##x |
| +++ %%##x |
| %%##x |
| %%##x |
| %%##xx |
| %###xx |
| %###xx |
| %###xx |
| %###xx |
| + %#O#xx |
| + %#O#xx |
|++ + %#O#xx |
| ++%OOOxxx|
| ++ + %#OOO#xx|
| + ++ ++++@@#xx|
| |A_| |
||__M___A| |
| |A_| |
++
N Min MaxMedian AvgStddev
x 120 0.99456 1.00628 0.85 1.0001545 0.0024387139
+ 120 0.873021 1.00037
[Intel-gfx] ✓ Fi.CI.BAT: success for Add HDR Metadata Parsing and handling in DRM layer (rev10)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev10)
URL : https://patchwork.freedesktop.org/series/25091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6081 -> Patchwork_13017
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/
Known issues
Here are the changes found in Patchwork_13017 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@gem_cpu_reloc@basic:
- {fi-cml-u}: [INCOMPLETE][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-cml-u/igt@gem_cpu_re...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/fi-cml-u/igt@gem_cpu_re...@basic.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][5] ([fdo#108602] / [fdo#108744]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [DMESG-WARN][7] ([fdo#102505] / [fdo#110390]) ->
[INCOMPLETE][8] ([fdo#107713])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
Participating hosts (53 -> 45)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-bwr-2160 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6081 -> Patchwork_13017
CI_DRM_6081: 871d8bc4020bef25e14ea242cf5e73d3372f1f49 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4988: 2f6303d13e09b2457762540383c7f36cecd02bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13017: 419f1f1aa013ca1e5da1c5cc97dfb97fe9860d82 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
419f1f1aa013 drm/i915: Add state readout for DRM infoframe
c551df049b4b video/hdmi: Add Unpack function for DRM infoframe
099bc01437b0 drm/i915: Added DRM Infoframe handling for BYT/CHT
ce675290a60c drm/i915:Enabled Modeset when HDR Infoframe changes
b3e0e0e84acf drm/i915: Enable infoframes on GLK+ for HDR
5f982275452b drm: Add HLG EOTF
ad8af2f7bfe1 drm/i915: Write HDR infoframe and send to panel
6e750ad58aea drm/i915: Attach HDR metadata property to connector
2b6bfe872c5c drm: Enable HDR infoframe support
81213d3cc42b drm: Parse HDR metadata info from EDID
a03684f24653 drm: Add reference counting on HDR metadata blob
d7b17f998fd9 drm: Add HDR source metadata property
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add HDR Metadata Parsing and handling in DRM layer (rev10)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev10)
URL : https://patchwork.freedesktop.org/series/25091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d7b17f998fd9 drm: Add HDR source metadata property
-:72: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#72: FILE: drivers/gpu/drm/drm_atomic_uapi.c:733:
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >hdr_output_metadata,
total: 0 errors, 0 warnings, 1 checks, 154 lines checked
a03684f24653 drm: Add reference counting on HDR metadata blob
81213d3cc42b drm: Parse HDR metadata info from EDID
2b6bfe872c5c drm: Enable HDR infoframe support
6e750ad58aea drm/i915: Attach HDR metadata property to connector
ad8af2f7bfe1 drm/i915: Write HDR infoframe and send to panel
5f982275452b drm: Add HLG EOTF
b3e0e0e84acf drm/i915: Enable infoframes on GLK+ for HDR
-:57: WARNING:LONG_LINE: line over 100 characters
#57: FILE: drivers/gpu/drm/i915/i915_reg.h:8190:
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
total: 0 errors, 1 warnings, 0 checks, 72 lines checked
ce675290a60c drm/i915:Enabled Modeset when HDR Infoframe changes
-:84: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#84: FILE: drivers/gpu/drm/i915/intel_hdmi.c:839:
+ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
+ connector->hdr_sink_metadata.hdmi_type1.eotf)) {
total: 0 errors, 0 warnings, 1 checks, 57 lines checked
099bc01437b0 drm/i915: Added DRM Infoframe handling for BYT/CHT
c551df049b4b video/hdmi: Add Unpack function for DRM infoframe
419f1f1aa013 drm/i915: Add state readout for DRM infoframe
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Re-add enable_rc6 modparam
== Series Details ==
Series: series starting with [1/2] drm/i915: Re-add enable_rc6 modparam
URL : https://patchwork.freedesktop.org/series/60637/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6081 -> Patchwork_13016
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/
Known issues
Here are the changes found in Patchwork_13016 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_6081/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@kms_busy@basic-flip-c:
- fi-skl-6770hq: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278])
+2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [PASS][5] -> [SKIP][6] ([fdo#109271]) +23 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [PASS][7] -> [INCOMPLETE][8] ([fdo#107718])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/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_13016/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_cpu_reloc@basic:
- {fi-cml-u}: [INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-cml-u/igt@gem_cpu_re...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-cml-u/igt@gem_cpu_re...@basic.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [INCOMPLETE][11] ([fdo#107713] / [fdo#108569]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
- fi-skl-iommu: [INCOMPLETE][13] ([fdo#108602] / [fdo#108744]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
- {fi-icl-y}: [INCOMPLETE][15] ([fdo#107713] / [fdo#108569]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-icl-y/igt@i915_selftest@live_hangcheck.html
- {fi-icl-dsi}: [INCOMPLETE][17] ([fdo#107713] / [fdo#108569]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13016/fi-icl-dsi/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#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 (53 -> 45)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-bwr-2160 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6081 -> Patchwork_13016
CI_DRM_6081: 871d8bc4020bef25e14ea242cf5e73d3372f1f49 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4988: 2f6303d13e09b2457762540383c7f36cecd02bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13016: ebcadee9c4d270c31872f402be8a6992cb313a0c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ebcadee9c4d2 drm/i915: Extend reset modparam to domain resets
14d287f37981
[Intel-gfx] [v10 11/12] video/hdmi: Add Unpack function for DRM infoframe
Added unpack function for DRM infoframe for dynamic
range and mastering infoframe readout.
v2: Addressed Ville's review comments.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 70
include/linux/hdmi.h | 1 +
2 files changed, 71 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index c5ecd16..b99ba01 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -675,6 +675,9 @@ static int hdmi_drm_infoframe_check_only(const struct
hdmi_drm_infoframe *frame)
frame->version != 1)
return -EINVAL;
+ if (frame->length != HDMI_DRM_INFOFRAME_SIZE)
+ return -EINVAL;
+
return 0;
}
@@ -1802,6 +1805,70 @@ static int hdmi_audio_infoframe_unpack(struct
hdmi_audio_infoframe *frame,
}
/**
+ * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ * @buffer: source buffer
+ * @size: size of buffer
+ *
+ * Unpacks the information contained in binary @buffer into a structured
+ * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
+ * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
+const void *buffer, size_t size)
+{
+ const u8 *ptr = buffer;
+ const u8 *temp;
+ u8 x_lsb, x_msb;
+ u8 y_lsb, y_msb;
+ int ret;
+ int i;
+
+ if (size < HDMI_INFOFRAME_SIZE(DRM))
+ return -EINVAL;
+
+ if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
+ ptr[1] != 1 ||
+ ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
+ return -EINVAL;
+
+ ret = hdmi_drm_infoframe_init(frame);
+ if (ret)
+ return ret;
+
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ frame->eotf = ptr[0] & 0x7;
+ frame->metadata_type = ptr[1] & 0x7;
+
+ temp = ptr + 2;
+ for (i = 0; i < 3; i++) {
+ x_lsb = *temp++;
+ x_msb = *temp++;
+ frame->display_primaries[i].x = (x_msb << 8) | x_lsb;
+ y_lsb = *temp++;
+ y_msb = *temp++;
+ frame->display_primaries[i].y = (y_msb << 8) | y_lsb;
+ }
+
+ frame->white_point.x = (ptr[15] << 8) | ptr[14];
+ frame->white_point.y = (ptr[17] << 8) | ptr[16];
+
+ frame->max_display_mastering_luminance = (ptr[19] << 8) | ptr[18];
+ frame->min_display_mastering_luminance = (ptr[21] << 8) | ptr[20];
+ frame->max_cll = (ptr[23] << 8) | ptr[22];
+ frame->max_fall = (ptr[25] << 8) | ptr[24];
+
+ return 0;
+}
+
+/**
* hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
* @frame: HDMI infoframe
* @buffer: source buffer
@@ -1827,6 +1894,9 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
case HDMI_INFOFRAME_TYPE_AVI:
ret = hdmi_avi_infoframe_unpack(>avi, buffer, size);
break;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ ret = hdmi_drm_infoframe_unpack(>drm, buffer, size);
+ break;
case HDMI_INFOFRAME_TYPE_SPD:
ret = hdmi_spd_infoframe_unpack(>spd, buffer, size);
break;
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 3d7f10f..ee55ba5 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -56,6 +56,7 @@ enum hdmi_infoframe_type {
#define HDMI_AVI_INFOFRAME_SIZE13
#define HDMI_SPD_INFOFRAME_SIZE25
#define HDMI_AUDIO_INFOFRAME_SIZE 10
+#define HDMI_DRM_INFOFRAME_SIZE26
#define HDMI_INFOFRAME_SIZE(type) \
(HDMI_INFOFRAME_HEADER_SIZE + HDMI_ ## type ## _INFOFRAME_SIZE)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 12/12] drm/i915: Add state readout for DRM infoframe
Added state readout for DRM infoframe and enabled state validation for DRM infoframe. v2: Addressed Ville's review comments and dropped the unused drm infoframe read at intel_hdmi_init. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_ddi.c | 4 drivers/gpu/drm/i915/intel_display.c | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0af47f3..f574315 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -3834,6 +3834,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder, intel_read_infoframe(encoder, pipe_config, HDMI_INFOFRAME_TYPE_VENDOR, _config->infoframes.hdmi); + if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))) + intel_read_infoframe(encoder, pipe_config, +HDMI_INFOFRAME_TYPE_DRM, +_config->infoframes.drm); } static enum intel_output_type diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e35ba8d..c89b214 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12274,6 +12274,7 @@ static bool fastboot_enabled(struct drm_i915_private *dev_priv) PIPE_CONF_CHECK_INFOFRAME(avi); PIPE_CONF_CHECK_INFOFRAME(spd); PIPE_CONF_CHECK_INFOFRAME(hdmi); + PIPE_CONF_CHECK_INFOFRAME(drm); #undef PIPE_CONF_CHECK_X #undef PIPE_CONF_CHECK_I -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 08/12] drm/i915: Enable infoframes on GLK+ for HDR
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
v5: Dropped hdr_metadata_change check while modeset, as per
Ville's suggestion.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47f..d3f5510 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4694,6 +4694,7 @@ enum {
#define VIDEO_DIP_FREQ_MASK (3 << 16)
/* HSW and later: */
#define DRM_DIP_ENABLE (1 << 28)
+#define VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
#define PSR_VSC_BIT_7_SET(1 << 27)
#define VSC_SELECT_MASK (0x3 << 25)
#define VSC_SELECT_SHIFT 25
@@ -8146,6 +8147,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
#define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
#define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A 0x60440
#define _HSW_VIDEO_DIP_AVI_ECC_A 0x60240
#define _HSW_VIDEO_DIP_VS_ECC_A0x60280
#define _HSW_VIDEO_DIP_SPD_ECC_A 0x602C0
@@ -8159,6 +8161,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
#define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
#define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B 0x61440
#define _HSW_VIDEO_DIP_BVI_ECC_B 0x61240
#define _HSW_VIDEO_DIP_VS_ECC_B0x61280
#define _HSW_VIDEO_DIP_SPD_ECC_B 0x612C0
@@ -8184,6 +8187,7 @@ enum {
#define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_ECC(trans, i)_MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f49f949..b80406b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -152,6 +152,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -177,6 +179,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -560,10 +564,16 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 val = I915_READ(HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
+ u32 mask;
- return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
- VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ mask = (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
+ VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ mask |= VIDEO_DIP_ENABLE_DRM_GLK;
+
+ return val & mask;
}
static const u8 infoframe_type_to_idx[] = {
@@ -1196,7 +1206,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);
if (!enable) {
I915_WRITE(reg, val);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [v10 10/12] drm/i915: Added DRM Infoframe handling for BYT/CHT
BYT/CHT doesn't support DRM Infoframe. This caused a WARN_ON due to a missing CASE while executing intel_hdmi_infoframes_enabled function. This patch fixes the same. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e97bf6e..b645cbb 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -129,6 +129,8 @@ static u32 g4x_infoframe_enable(unsigned int type) return VIDEO_DIP_ENABLE_SPD; case HDMI_INFOFRAME_TYPE_VENDOR: return VIDEO_DIP_ENABLE_VENDOR; + case HDMI_INFOFRAME_TYPE_DRM: + return 0; default: MISSING_CASE(type); return 0; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 07/12] drm: Add HLG EOTF
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Addressed Jonas Karlman's review comment and dropped the i915
tag from header.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 3 ++-
include/linux/hdmi.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 73b7905..bc46041 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3851,7 +3851,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
return edid_ext[2] &
(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
-BIT(HDMI_EOTF_SMPTE_ST2084));
+BIT(HDMI_EOTF_SMPTE_ST2084) |
+BIT(HDMI_EOTF_BT_2100_HLG));
}
static uint8_t hdr_metadata_type(const u8 *edid_ext)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 7edafcf..3d7f10f 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -161,6 +161,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+ HDMI_EOTF_BT_2100_HLG,
};
struct hdmi_avi_infoframe {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 04/12] drm: Enable HDR infoframe support
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Added the const version of infoframe for DRM metadata
for HDR.
v2: Rebase and added Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments and merged the
patch making drm infoframe function arguments as constant.
v5: Rebase
v6: Fixed checkpatch warnings with --strict option. Addressed
Shashank's review comments and added his RB.
v7: Addressed Brian Starkey's review comments. Merged 2 patches
into one.
v8: Addressed Jonas Karlman review comments.
v9: Addressed Jonas Karlman review comments.
Signed-off-by: Uma Shankar
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 43 +++
drivers/video/hdmi.c | 187 +
include/drm/drm_edid.h | 5 ++
include/linux/hdmi.h | 27 +++
4 files changed, 262 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2e0b5be..73b7905 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4903,6 +4903,49 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
}
/**
+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
+ * HDR metadata from userspace
+ * @frame: HDMI DRM infoframe
+ * @hdr_metadata: hdr_source_metadata info from userspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+ const struct hdr_output_metadata
*hdr_metadata)
+{
+ int err;
+
+ if (!frame || !hdr_metadata)
+ return -EINVAL;
+
+ err = hdmi_drm_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ DRM_DEBUG_KMS("type = %x\n", frame->type);
+
+ frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
+ frame->metadata_type = hdr_metadata->hdmi_metadata_type1.metadata_type;
+
+ memcpy(>display_primaries,
+ _metadata->hdmi_metadata_type1.display_primaries, 12);
+
+ memcpy(>white_point,
+ _metadata->hdmi_metadata_type1.white_point, 4);
+
+ frame->max_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.max_display_mastering_luminance;
+ frame->min_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.min_display_mastering_luminance;
+ frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
+ frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
+
+/**
* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe with
* data from a DRM display mode
* @frame: HDMI AVI infoframe
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 799ae49..c5ecd16 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -650,6 +650,147 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
return 0;
}
+/**
+ * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
+ * mastering infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_DRM;
+ frame->version = 1;
+ frame->length = HDMI_DRM_INFOFRAME_SIZE;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+
+static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
+ frame->version != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Validates that the infoframe is consistent.
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame)
+{
+ return hdmi_drm_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_check);
+
+/**
+ * hdmi_drm_infoframe_pack_only() - write HDMI DRM infoframe to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into
[Intel-gfx] [v10 09/12] drm/i915:Enabled Modeset when HDR Infoframe changes
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
v4: Addressed Ville's review comments.
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 | 13 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 58b8049..6b985e8 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -105,6 +105,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;
+}
+
int intel_digital_connector_atomic_check(struct drm_connector *conn,
struct drm_connector_state *new_state)
{
@@ -132,7 +142,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,
+ old_conn_state->base.hdr_output_metadata))
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 b80406b..e97bf6e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -806,6 +806,11 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static inline bool is_eotf_supported(u8 output_eotf, u8 sink_eotf)
+{
+ return sink_eotf & BIT(output_eotf);
+}
+
static bool
intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -814,6 +819,7 @@ 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_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct drm_connector *connector = conn_state->connector;
int ret;
if (!(INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)))
@@ -828,6 +834,13 @@ void intel_read_infoframe(struct intel_encoder *encoder,
hdr_metadata = conn_state->hdr_output_metadata->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;
+ }
+
crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 01/12] drm: Add HDR source metadata property
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.
v8: Addressed Ville's review comments. Moved sink metadata structure
out of uapi headers as suggested by Jonas Karlman.
v9: Rebase and addressed Jonas Karlman review comments.
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 | 7 +++
include/linux/hdmi.h | 26 ++
include/uapi/drm/drm_mode.h | 23 +++
7 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f4924cb..0d27195 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -925,6 +925,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 4131e66..4aa82c91 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -676,6 +676,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, file_priv, val);
@@ -726,6 +728,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,
+ 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) {
@@ -814,6 +824,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 ?
+ state->hdr_output_metadata->base.id : 0;
} else if (property == config->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 11fcd25..c9ac8b9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1051,6 +1051,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
index e257b87..54daa54 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -603,6
[Intel-gfx] [v10 02/12] drm: Add reference counting on HDR metadata blob
From: Jonas Karlman This adds reference count for HDR metadata blob, handled as part of duplicate and destroy connector state functions. Signed-off-by: Jonas Karlman Signed-off-by: Uma Shankar --- drivers/gpu/drm/drm_atomic_state_helper.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c index ac929f6..8f49952 100644 --- a/drivers/gpu/drm/drm_atomic_state_helper.c +++ b/drivers/gpu/drm/drm_atomic_state_helper.c @@ -391,6 +391,10 @@ void drm_atomic_helper_connector_reset(struct drm_connector *connector) drm_connector_get(connector); state->commit = NULL; + if (state->hdr_output_metadata) + drm_property_blob_get(state->hdr_output_metadata); + state->hdr_metadata_changed = false; + /* Don't copy over a writeback job, they are used only once */ state->writeback_job = NULL; } @@ -438,6 +442,8 @@ struct drm_connector_state * if (state->writeback_job) drm_writeback_cleanup_job(state->writeback_job); + + drm_property_blob_put(state->hdr_output_metadata); } EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 06/12] drm/i915: Write HDR infoframe and send to panel
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation in compute config.
v6: Addressed Shashank's review comment. Added HDR metadata
support from GEN10 onwards as per Shashank's recommendation.
v7: Addressed Shashank's review comments
v8: Added Shashank's RB.
v9: Addressed Ville's review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 47 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5258abb..40e2c52 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -910,6 +910,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+ union hdmi_infoframe drm;
} infoframes;
/* HDMI scrambling status */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 92597d8..f49f949 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -573,6 +573,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+ HDMI_INFOFRAME_TYPE_DRM,
};
u32 intel_hdmi_infoframe_enable(unsigned int type)
@@ -795,6 +796,44 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool
+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+ struct hdr_output_metadata *hdr_metadata;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ int ret;
+
+ if (!(INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)))
+ return true;
+
+ if (!crtc_state->has_infoframe)
+ return true;
+
+ if (!conn_state->hdr_output_metadata ||
+ conn_state->hdr_output_metadata->length == 0)
+ return true;
+
+ hdr_metadata = conn_state->hdr_output_metadata->data;
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ ret = hdmi_drm_infoframe_check(frame);
+ if (WARN_ON(ret))
+ return false;
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1180,6 +1219,9 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
_state->infoframes.hdmi);
+ intel_write_infoframe(encoder, crtc_state,
+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
@@ -2386,6 +2428,11 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
+ if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config,
conn_state)) {
+ DRM_DEBUG_KMS("bad DRM infoframe\n");
+ return -EINVAL;
+ }
+
return 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 05/12] drm/i915: Attach HDR metadata property to connector
Attach HDR metadata property to connector object. v2: Rebase v3: Updated the property name as per updated name while creating hdr metadata property Signed-off-by: Uma Shankar Reviewed-by: Shashank Sharma --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 2a4086c..92597d8 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2724,6 +2724,8 @@ static void intel_hdmi_destroy(struct drm_connector *connector) drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + drm_object_attach_property(>base, + connector->dev->mode_config.hdr_output_metadata_property, 0); if (!HAS_GMCH(dev_priv)) drm_connector_attach_max_bpc_property(connector, 8, 12); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 00/12] Add HDR Metadata Parsing and handling in DRM layer
This patch series enables HDR support in drm. It basically defines HDR metadata structures, property to pass content (after blending) metadata from user space compositors to driver. Dynamic Range and Mastering infoframe creation and sending. ToDo: 1. We need to get the color framework in place for all planes which support HDR content in hardware. This is already in progres and patches are out for review in mailing list. 2. UserSpace/Compositors: Blending policies and metadata blob creation and passing to driver. Work is already in progress by Intel's middleware teams on wayland and the patches for the same are in review. A POC has already been developed by Ville based on wayland. Please refer below link to see the component interactions and usage: https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html v2: Updated Ville's POC changes to the patch series.Incorporated cleanups and fixes from Ville. Rebase on latest drm-tip. v3: Fixed a warning causing builds to break on CI. No major change. v4: Addressed Shashank's review comments. v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset case for HDR metadata update. Dropped a redundant patch. v6: Addressed Shashank's review comments and added RB's received. v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and Shashank's review comments. v8: Addressed Jonas Karlman review comments. Added Shashank's RB to the series, fixed a WARN_ON on BYT/CHT. v9: Addressed Ville and Jonas Karlman's review comments. Added the infoframe state readout and metadata reference count. v10: Addressed review comments from Jonas and Ville. Dropped one patch related to i915 fastset handling as per Ville's feedback. Note: v9 version is already tested with Kodi and a confirmation from team kodi has been received. Branch details for the same as below: https://github.com/xbmc/xbmc/tree/feature_drmprime-vaapi v9 of this series is: Tested-by: Jonas Karlman Jonas Karlman (1): drm: Add reference counting on HDR metadata blob Uma Shankar (9): drm: Add HDR source metadata property drm: Parse HDR metadata info from EDID drm: Enable HDR infoframe support drm/i915: Attach HDR metadata property to connector drm/i915: Write HDR infoframe and send to panel drm/i915:Enabled Modeset when HDR Infoframe changes drm/i915: Added DRM Infoframe handling for BYT/CHT video/hdmi: Add Unpack function for DRM infoframe drm/i915: Add state readout for DRM infoframe Ville Syrjälä (2): drm: Add HLG EOTF drm/i915: Enable infoframes on GLK+ for HDR drivers/gpu/drm/drm_atomic.c | 2 + drivers/gpu/drm/drm_atomic_state_helper.c | 6 + drivers/gpu/drm/drm_atomic_uapi.c | 13 ++ drivers/gpu/drm/drm_connector.c | 6 + drivers/gpu/drm/drm_edid.c| 93 +++ drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_atomic.c | 14 +- drivers/gpu/drm/i915/intel_ddi.c | 4 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 83 +- drivers/video/hdmi.c | 257 ++ include/drm/drm_connector.h | 11 ++ include/drm/drm_edid.h| 5 + include/drm/drm_mode_config.h | 7 + include/linux/hdmi.h | 55 +++ include/uapi/drm/drm_mode.h | 23 +++ 17 files changed, 580 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10 03/12] drm: Parse HDR metadata info from EDID
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.
v7: Adressed Ville's review comments and fixed the issue
with length handling.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 49 ++
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 852bdd8..2e0b5be 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2852,6 +2852,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_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
#define EXT_VIDEO_DATA_BLOCK_420 0x0E
@@ -3834,6 +3835,52 @@ 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;
+
+ 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(db);
+ if (len >= 3) {
+ connector->hdr_sink_metadata.hdmi_type1.eotf =
+ eotf_supported(db);
+ connector->hdr_sink_metadata.hdmi_type1.metadata_type =
+ hdr_metadata_type(db);
+ }
+
+ 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)
{
@@ -4461,6 +4508,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);
}
}
--
1.9.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/2] drm/i915: Re-add enable_rc6 modparam
== Series Details == Series: series starting with [1/2] drm/i915: Re-add enable_rc6 modparam URL : https://patchwork.freedesktop.org/series/60637/ State : warning == Summary == $ dim checkpatch origin/drm-tip 14d287f37981 drm/i915: Re-add enable_rc6 modparam -:25: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #25: FILE: drivers/gpu/drm/i915/i915_params.c:173: +i915_param_named_unsafe(enable_rc6, bool, 0400, + "Enable power-saving render C-state 6. (default: true)"); total: 0 errors, 0 warnings, 1 checks, 27 lines checked ebcadee9c4d2 drm/i915: Extend reset modparam to domain resets ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Extend reset modparam to domain resets
On Tue, 2019-05-14 at 17:54 +0100, Chris Wilson wrote: > Quoting Stuart Summers (2019-05-14 17:46:53) > > In the event a platform does not properly implement reset, > > Then don't enable reset. Hey Chris, I'm not sure I fully understand your comment here. The module parameter is there to do just this. This patch simply extends the usage to apply to these engine domains as well. Thanks, Stuart > -Chris smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
Quoting Stuart Summers (2019-05-14 17:46:52) > To allow easier debug of platforms which do not fully support > power-saving render C-state 6, add back the module parameter > to allow RC6 flows to be disabled. Instead of directly affecting > the RC6 states via a bitmask as done previously, use this module > parameter to clear the has_rc6 field for these platforms. If you know which platforms don't support rc6, don't enable rc6. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Extend reset modparam to domain resets
Quoting Stuart Summers (2019-05-14 17:46:53) > In the event a platform does not properly implement reset, Then don't enable reset. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Extend reset modparam to domain resets
In the event a platform does not properly implement reset,
do not go through reset flows for engine domains to avoid
an unlikely situation where writes are accepted but register
values are never cleared, as this can result in GPU wedges
in these cases.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_reset.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 464369bc55ad..81f9f9f73b1c 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -309,6 +309,12 @@ static int gen6_hw_domain_reset(struct drm_i915_private
*i915,
struct intel_uncore *uncore = >uncore;
int err;
+ if (!i915_modparams.reset) {
+ DRM_DEBUG_DRIVER("Skipping 0x%08x engines reset\n",
+hw_domain_mask);
+ return 0;
+ }
+
/*
* GEN6_GDRST is not in the gt power well, no need to check
* for fifo space for the write or forcewake the chip for
@@ -517,6 +523,13 @@ static int gen8_engine_reset_prepare(struct
intel_engine_cs *engine)
return 0;
}
+ if (!i915_modparams.reset) {
+ DRM_DEBUG_DRIVER("Skipping %s reset request {request: %08x,
RESET_CTL: %08x}\n",
+engine->name, request,
+intel_uncore_read_fw(uncore, reg));
+ return 0;
+ }
+
intel_uncore_write_fw(uncore, reg, _MASKED_BIT_ENABLE(request));
ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
700, 0, NULL);
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
To allow easier debug of platforms which do not fully support
power-saving render C-state 6, add back the module parameter
to allow RC6 flows to be disabled. Instead of directly affecting
the RC6 states via a bitmask as done previously, use this module
parameter to clear the has_rc6 field for these platforms.
Acked-by: Rodrigo Vivi
Suggested-by: Vinay Belgaumkar
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_params.c | 3 +++
drivers/gpu/drm/i915/i915_params.h | 3 ++-
drivers/gpu/drm/i915/intel_pm.c| 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b5be0abbba35..e31406c6821d 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -169,6 +169,9 @@ i915_param_named_unsafe(inject_load_failure, uint, 0400,
i915_param_named(enable_dpcd_backlight, bool, 0600,
"Enable support for DPCD backlight control (default:false)");
+i915_param_named_unsafe(enable_rc6, bool, 0400,
+ "Enable power-saving render C-state 6. (default: true)");
+
#if IS_ENABLED(CONFIG_DRM_I915_GVT)
i915_param_named(enable_gvt, bool, 0400,
"Enable support for Intel GVT-g graphics virtualization host
support(default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 3f14e9881a0d..28bf4005a610 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -76,7 +76,8 @@ struct drm_printer;
param(bool, nuclear_pageflip, false) \
param(bool, enable_dp_mst, true) \
param(bool, enable_dpcd_backlight, false) \
- param(bool, enable_gvt, false)
+ param(bool, enable_gvt, false) \
+ param(bool, enable_rc6, true)
#define MEMBER(T, member, ...) T member;
struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index decdd79c3805..6b514dd033cb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7020,6 +7020,9 @@ static bool sanitize_rc6(struct drm_i915_private *i915)
{
struct intel_device_info *info = mkwrite_device_info(i915);
+ if (!i915_modparams.enable_rc6)
+ info->has_rc6 = 0;
+
/* Powersaving is controlled by the host when inside a VM */
if (intel_vgpu_active(i915)) {
info->has_rc6 = 0;
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v9 10/13] drm/i915: Set Infoframe for non modeset case for HDR
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 14, 2019 1:10 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; jo...@kwiboo.se; emil.l.veli...@gmail.com;
>seanp...@chromium.org; Syrjala, Ville ; Lankhorst,
>Maarten
>
>Subject: Re: [v9 10/13] drm/i915: Set Infoframe for non modeset case for HDR
>
>On Thu, May 09, 2019 at 12:08:50AM +0530, Uma Shankar wrote:
>> HDR metadata requires a infoframe to be set. Due to fastset, full
>> modeset is not performed hence adding it to update_pipe to handle
>> that.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c | 13 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 7 +--
>> 2 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index cd5277d..d37526b 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3559,6 +3559,10 @@ 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 drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> +struct intel_digital_port *intel_dig_port =
>> +enc_to_dig_port(>base);
>> +
>> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
>> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
>>
>> @@ -3568,6 +3572,15 @@ static void intel_ddi_update_pipe(struct intel_encoder
>*encoder,
>> else if (conn_state->content_protection ==
>> DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>> intel_hdcp_disable(to_intel_connector(conn_state->connector));
>> +
>> +/* Set the infoframe for NON modeset cases as well */
>> +if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
>> +if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
>> +conn_state->hdr_metadata_changed)
>> +intel_dig_port->set_infoframes(encoder,
>> +
>> crtc_state->has_infoframe,
>> + crtc_state, conn_state);
>> +}
>
>Still nak.
Ok, will drop this from this series and take this up later.
>> }
>>
>> static void intel_ddi_set_fia_lane_count(struct intel_encoder
>> *encoder, diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index db9c82b..e559a940 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1204,8 +1204,11 @@ static void hsw_set_infoframes(struct intel_encoder
>*encoder,
>> i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
>> u32 val = I915_READ(reg);
>>
>> -assert_hdmi_transcoder_func_disabled(dev_priv,
>> - crtc_state->cpu_transcoder);
>> +/* DRM Infoframe can be send with transcoder enabled */
>> +if (!((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
>> + conn_state->hdr_metadata_changed))
>> +assert_hdmi_transcoder_func_disabled(dev_priv,
>> +
>> crtc_state->cpu_transcoder);
>>
>> val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
>> VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v9 12/13] video/hdmi: Add Unpack function for DRM infoframe
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Tuesday, May 14, 2019 1:20 AM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; jo...@kwiboo.se; intel-gfx@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; Syrjala, Ville ; Lankhorst,
>Maarten
>
>Subject: Re: [v9 12/13] video/hdmi: Add Unpack function for DRM infoframe
>
>On Thu, May 09, 2019 at 12:08:52AM +0530, Uma Shankar wrote:
>> Added unpack function for DRM infoframe for dynamic range and
>> mastering infoframe readout.
>>
>> Suggested-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/video/hdmi.c | 54
>>
>> include/linux/hdmi.h | 1 +
>> 2 files changed, 55 insertions(+)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 717ed7fb..110d405 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1801,6 +1801,57 @@ static int hdmi_audio_infoframe_unpack(struct
>> hdmi_audio_infoframe *frame, }
>>
>> /**
>> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
>> +infoframe
>> + * @frame: HDMI DRM infoframe
>> + * @buffer: source buffer
>> + * @size: size of buffer
>> + *
>> + * Unpacks the information contained in binary @buffer into a
>> +structured
>> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
>> + * Also verifies the checksum as required by section 5.3.5 of the
>> +HDMI 1.4
>> + * specification.
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
>> + const void *buffer, size_t size) {
>> +const u8 *ptr = buffer;
>> +int ret;
>> +
>> +if (size < HDMI_INFOFRAME_SIZE(DRM))
>> +return -EINVAL;
>> +
>> +if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
>> +ptr[1] != 1 ||
>> +ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
>> +return -EINVAL;
>> +
>> +if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
>> +return -EINVAL;
>> +
>> +ret = hdmi_drm_infoframe_init(frame);
>> +if (ret)
>> +return ret;
>> +
>> +frame->length = ptr[2];
>
>The length handling is inconsistnet between the compute and readout sides. I
>would
>suggest for now just put the length initialization into
>hdmi_drm_infoframe_init() (and
>remove it from the drm code), and check it in the check_only(). We can revisit
>it
>if/when other metadata formats become relevant.
Sure, will update this.
>> +ptr += HDMI_INFOFRAME_HEADER_SIZE;
>> +
>> +frame->eotf = ptr[0] & 0x7;
>> +frame->metadata_type = ptr[1] & 0x7;
>> +
>> +memcpy(>display_primaries, [2], 12);
>> +memcpy(>white_point, [14], 4);
>
>Endianness fail.
Ok, will explicitly copy these.
>> +
>> +frame->max_display_mastering_luminance = (ptr[19] << 8) | ptr[18];
>> +frame->min_display_mastering_luminance = (ptr[21] << 8) | ptr[20];
>> +frame->max_cll = (ptr[23] << 8) | ptr[22];
>> +frame->max_fall = (ptr[25] << 8) | ptr[24];
>> +
>> +return 0;
>> +}
>> +
>> +/**
>> * hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
>> * @frame: HDMI infoframe
>> * @buffer: source buffer
>> @@ -1826,6 +1877,9 @@ int hdmi_infoframe_unpack(union hdmi_infoframe
>*frame,
>> case HDMI_INFOFRAME_TYPE_AVI:
>> ret = hdmi_avi_infoframe_unpack(>avi, buffer, size);
>> break;
>> +case HDMI_INFOFRAME_TYPE_DRM:
>> +ret = hdmi_drm_infoframe_unpack(>drm, buffer, size);
>> +break;
>> case HDMI_INFOFRAME_TYPE_SPD:
>> ret = hdmi_spd_infoframe_unpack(>spd, buffer, size);
>> break;
>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index
>> 3d7f10f..ee55ba5 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -56,6 +56,7 @@ enum hdmi_infoframe_type {
>> #define HDMI_AVI_INFOFRAME_SIZE13
>> #define HDMI_SPD_INFOFRAME_SIZE25
>> #define HDMI_AUDIO_INFOFRAME_SIZE 10
>> +#define HDMI_DRM_INFOFRAME_SIZE26
>>
>> #define HDMI_INFOFRAME_SIZE(type) \
>> (HDMI_INFOFRAME_HEADER_SIZE + HDMI_ ## type ## _INFOFRAME_SIZE)
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Ville Syrjälä
>Intel
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6][PATCH 03/12] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
On Tue, May 14, 2019 at 03:13:21PM +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]
> v6: -Added func intel_color_get_bit_precision() to get bit precision for
> gamma and degamma lut readout depending upon platform and
> corresponding to load_luts() [Ankit]
> -Added debug log for color para in intel_dump_pipe_config [Jani]
> -Made patch11 as patch3 [Jani]
>
> I could think of adding intel_color_get_bit_precision() to be the way
> to get away with bit precision problem for degamma and gamma (its like a table
> having hard coded values depening on gamma_mode).
> If anybody could think of better way then this then please guide.
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/intel_color.c | 93
>
> drivers/gpu/drm/i915/intel_color.h | 7 +++
> drivers/gpu/drm/i915/intel_display.c | 24 ++
> 3 files changed, 124 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 50b98ee..1e60369 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -1251,6 +1251,99 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
> return 0;
> }
>
> +void intel_color_get_bit_precision(struct intel_crtc_state *crtc_state, int
> *bp_gamma)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +
> + if (HAS_GMCH(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv)) {
> + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
> + *bp_gamma = 8;
> + return;
Functions can actually return values.
Not sure I particularly like this function though. We can't fit
the gamma vs. degamm stuff in here neatly. I think per-platform
stuff to determine the precision is required to make this sane.
And it should probably got into intel_color.c to keep things
neatly contained.
Something along the lines of:
i9xx_gamma_precision()
{
if (!gamma_enable)
return 0;
switch (gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
case GAMMA_MODE_MODE_10BIT:
return 16;
}
}
chv_gamma_precision()
{
if (cgm_mode & CGM_PIPE_MODE_GAMMA)
return 10;
else
return i9xx_gamma_precision();
}
chv_degamma_precision(crtc_state)
{
if (cgm_mode & CGM_PIPE_MODE_DEGAMMA)
return 14;
else
return 0
}
ilk_gamma_precision()
{
if (!gamma_enable)
return 0;
if ((csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
return 0;
switch (gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
case GAMMA_MODE_MODE_10BIT:
return 10;
}
}
ilk_degamma_precision()
{
if (!gamma_enable)
return 0;
if ((csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0)
return 0;
switch (gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
case GAMMA_MODE_MODE_10BIT:
return 10;
}
}
... extend to ivb, glk, and icl variants too.
> + }
> + if (crtc_state->cgm_mode == CGM_PIPE_MODE_GAMMA)
> + *bp_gamma = 10;
> + } else if (INTEL_GEN(dev_priv) >= 4) {
> + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> + *bp_gamma = 8;
> + else
> + *bp_gamma = 16;
> + } else {
> + *bp_gamma = 8;
> + }
> + } else {
> + if (INTEL_GEN(dev_priv) >= 11) {
> + if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) ==
> + GAMMA_MODE_MODE_8BIT)
> + *bp_gamma = 8;
> + else
> + *bp_gamma = 10;
> + } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
> + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> + *bp_gamma = 8;
> + else
> + *bp_gamma = 10;
> + } else if (INTEL_GEN(dev_priv) >= 7) {
> + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> +
Re: [Intel-gfx] [v6][PATCH 01/12] drm/i915: Introduce vfunc read_luts() to create hw lut
On Tue, May 14, 2019 at 03:13:19PM +0530, Swati Sharma wrote:
> In this patch, a vfunc read_luts() is introduced to create a hw lut
> i.e. lut having values read from gamma/degamma registers which will
> later be used to compare with sw lut to validate gamma/degamma lut values.
>
> v3: -Rebase
> v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
> -Wrapped get_color_config() [Jani]
> v5: -Renamed intel_color_get_config() to intel_color_read_luts()
> -Renamed get_color_config to read_luts
> v6: -Renamed intel_color_read_luts() back to intel_color_get_config()
> [Jani and Ville]
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/intel_color.c | 8
> drivers/gpu/drm/i915/intel_color.h | 1 +
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d025780..6343e70 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -343,6 +343,7 @@ struct drm_i915_display_funcs {
>* involved with the same commit.
>*/
> void (*load_luts)(const struct intel_crtc_state *crtc_state);
> + void (*read_luts)(struct intel_crtc_state *crtc_state);
I think Jani wanted the entire vfunc renamed back.
> };
>
> struct intel_csr {
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 962db12..50b98ee 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> return dev_priv->display.color_check(crtc_state);
> }
>
> +void intel_color_get_config(struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> +
> + if (dev_priv->display.read_luts)
> + dev_priv->display.read_luts(crtc_state);
> +}
> +
> static bool need_plane_update(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_color.h
> b/drivers/gpu/drm/i915/intel_color.h
> index b8a3ce6..057e8ac 100644
> --- a/drivers/gpu/drm/i915/intel_color.h
> +++ b/drivers/gpu/drm/i915/intel_color.h
> @@ -13,5 +13,6 @@
> int intel_color_check(struct intel_crtc_state *crtc_state);
> void intel_color_commit(const struct intel_crtc_state *crtc_state);
> void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
> +void intel_color_get_config(struct intel_crtc_state *crtc_state);
>
> #endif /* __INTEL_COLOR_H__ */
> --
> 1.9.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: adding state checker for gamma lut values (rev9)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev9) URL : https://patchwork.freedesktop.org/series/58039/ State : success == Summary == CI Bug Log - changes from CI_DRM_6080 -> Patchwork_13015 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/ Known issues Here are the changes found in Patchwork_13015 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([fdo#107709]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/fi-bsw-kefka/igt@i915_selftest@live_evict.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/fi-bsw-kefka/igt@i915_selftest@live_evict.html * igt@i915_selftest@live_execlists: - fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927] / [fdo#109720]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/fi-apl-guc/igt@i915_selftest@live_execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/fi-apl-guc/igt@i915_selftest@live_execlists.html Possible fixes * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [DMESG-FAIL][9] ([fdo#110620]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/fi-apl-guc/igt@i915_selftest@live_hangcheck.html Warnings * igt@runner@aborted: - fi-apl-guc: [FAIL][11] ([fdo#110622]) -> [FAIL][12] ([fdo#108622] / [fdo#109720]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6080/fi-apl-guc/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [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 Participating hosts (54 -> 46) -- 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_6080 -> Patchwork_13015 CI_DRM_6080: 6c6b621677cc0d3616de3dab025d967aa2c43877 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4985: dc0598498a16d43b0bc9cbc654491d4e6dc56626 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13015: 3c319ee505b6e02d5024963430217f9fde2089a2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3c319ee505b6 FOR_TESTING_ONLY: Print rgb values of hw and sw blobs d821530ccc4c drm/i915: Extract ilk_read_luts() 8aadfb2b3ffe drm/i915: Extract ivb_read_luts() 13e33d98fba6 drm/i915: Extract bdw_read_luts() f371c0809856 drm/i915: Extract glk_read_luts() 109f2d52ff4d drm/i915: Extract icl_read_luts() 7e433388b2bb drm/i915: Extract i965_read_luts() aed86d8c5e91 drm/i915: Extract chv_read_luts() 92f0143b746e drm/i915: Extract i9xx_read_luts() a13dd89268a2 drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values c687e9d64838 drm/i915: Enable intel_color_get_config() cb7a05f563c1 drm/i915: Introduce vfunc read_luts() to create hw lut == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13015/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Truly bump ready tasks ahead of busywaits
Quoting Chris Wilson (2019-05-14 09:04:39)
> In commit b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of
> busywaits"), I tried cutting a corner in order to not install a signal
> for each of our dependencies, and only listened to requests on which we
> were intending to busywait. The compromise that was made was that
> instead of then being able to promite the request with a full
> NOSEMAPHORE like its non-busywaiting brethren, as we had not ensured we
> had cleared the semaphore chain, we settled for only using the NEWCLIENT
> boost. With an over saturated system with multiple NEWCLIENTS in flight
> at any time, this was found to be an inadequate promotion and left us
> with a much poorer scheduling order than prior to using semaphores.
>
> The outcome of this patch, is that all requests have NOSEMAPHORE
> priority when they have no dependencies and are ready to run and not
> busywait, restoring the pre-semaphore ordering on saturated systems.
[snip]
> Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits")
Confirmed on the skl-xeon box this fixes that particular regression.
Alas that is not the last regression there. There is also an impact from
NEWCLIENT.
Imagine a client that does a work packet of (rcsA, rcsB, vcs), and now
imagine that there are 30 clients subscribed to the system. With
NEWCLIENT promotion we end up with
rcsAx30, (rcsB, vcs)x30
that is we do not start executing any vcs packets until all 30 clients
complete their first request -- whereas previously we would interleave
the vcs packed from client 1 with the first request in client 2. This
greatly reduces the concurrency between clients.
A temporary bandaid would be to revert
commit 1413b2bc0717036a5a653eef20cc3ae4cc66501a
Author: Chris Wilson
Date: Mon Feb 4 15:01:01 2019 +
drm/i915: Trim NEWCLIENT boosting
There is an interesting problem underneath to try and minimise queuing
times across the multiple systems, as again we are fortunate that the
previous FIFO happens to be close to ideal ordering.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen wrote: > > On Tue, 14 May 2019 13:02:09 +0200 > Daniel Vetter wrote: > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon wrote: > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > On Mon, 13 May 2019 11:34:58 +0200 > > > > Daniel Vetter wrote: > > > > > > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > So we just had some discussions over on IRC and at about the > > > > > > > > hotplug > > > > > > > > issue and came up with similar ideas: > > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > > > > > > > The conclusions of these discussions so far would be to have a > > > > > > > > more or > > > > > > > > less fine grain of uevent reporting depending on what happened. > > > > > > > > The > > > > > > > > point is that we need to cover different cases: > > > > > > > > - one or more properties changed; > > > > > > > > - the connector status changed; > > > > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > > > > > > > For the first case, we can send out: > > > > > > > > HOTPLUG=1 > > > > > > > > CONNECTOR= > > > > > > > > PROPERTY= > > > > > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > > > > > For the second one, something like: > > > > > > > > HOTPLUG=1 > > > > > > > > CONNECTOR= > > > > > > > > STATUS=Connected/Disconnected > > > > > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > > > disconnected; > > > > > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > > > HOTPLUG=1 > > > > > > > > CONNECTOR= > > > > > > > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > > > > > > > There's no material difference between this one and the previous > > > > > > > one. > > > > > > > Plus there's no beenfit in supplying the actual value of the > > > > > > > property, > > > > > > > i.e. we can reuse the same PROPERTY= trick. > > > > > > > > > > > > That's the idea, but we need to handle status changes differently > > > > > > than > > > > > > properties, since as far as I know, connected/unconnected status is > > > > > > not > > > > > > exposed as a prop for the connector. > > > > > > > > > > Oops, totally missed that. "Everything is a property" is kinda > > > > > new-ish, at least compared to kms. Kinda tempted to just make status > > > > > into a property. Or another excuse why we should expose the epoch > > > > > property :-) > > > > > > > > Hi Daniel, > > > > > > > > just to clarify the first case, specific to one very particular > > > > property: > > > > > > > > With HDCP, there is a property that may change dynamically at runtime > > > > (the undesired/desired/enabled tristate). Userspace must be notified > > > > when it changes, I do not want userspace have to poll that property > > > > with a timer. > > > > > > > > When that property alone changes, and userspace is prepared to handle > > > > that property changing alone, it must not trigger a reprobe of the > > > > connector. There is no reason to reprobe at that point AFAIU. > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the > > > > epoch approach or with any alternate uevent design? > > > > > > > > We need an event to userspace that indicates that re-reading the > > > > properties is enough and reprobe of the connector is not necessary. > > > > This is complementary to indicating to userspace that only some > > > > connectors need to be reprobed instead of everything. > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the > > > reprobing. Would that work? > > Hi, > > yes, that would work, if it was acceptable to DRM upstream. The replies > to Paul seemed to be going south so fast that I thought we wouldn't get > any new uevent fields in favour of "epoch counters". > > > Yes that's the idea, depending upon which property you get you know > > it's a sink change (needs full reprobe) or something else like hdcp > > state machinery update. > > Right. > > > Wrt avoiding the full reprobe for sink changes: I think we should >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: adding state checker for gamma lut values (rev9)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev9) URL : https://patchwork.freedesktop.org/series/58039/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Introduce vfunc read_luts() to create hw lut Okay! Commit: drm/i915: Enable intel_color_get_config() Okay! Commit: drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values Okay! Commit: drm/i915: Extract i9xx_read_luts() +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1392:6: warning: symbol 'i9xx_read_luts' was not declared. Should it be static? Commit: drm/i915: Extract chv_read_luts() Okay! Commit: drm/i915: Extract i965_read_luts() Okay! Commit: drm/i915: Extract icl_read_luts() Okay! Commit: drm/i915: Extract glk_read_luts() Okay! Commit: drm/i915: Extract bdw_read_luts() Okay! Commit: drm/i915: Extract ivb_read_luts() Okay! Commit: drm/i915: Extract ilk_read_luts() Okay! Commit: FOR_TESTING_ONLY: Print rgb values of hw and sw blobs Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 00/11] drm/fb-helper: Move modesetting code to drm_client
Den 06.05.2019 20.01, skrev Noralf Trønnes:
> This moves the modesetting code from drm_fb_helper to drm_client so it
> can be shared by all internal clients.
>
> Changes this time:
> - Use restore_fbdev_mode_force() in
> drm_fb_helper_restore_fbdev_mode_unlocked() to please igt tests. I'm not
> currently motivated to learn igt so I have added a todo entry for this.
> - Rebase on drm-next (drm_fb_helper and drm_legacy patches)
>
> Noralf.
>
> Noralf Trønnes (11):
> drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
> drm/fb-helper: Avoid race with DRM userspace
> drm/fb-helper: No need to cache rotation and sw_rotations
> drm/fb-helper: Remove drm_fb_helper_crtc->{x,y,desired_mode}
Patches 2-4 applied, thanks for reviewing.
> drm/fb-helper: Remove drm_fb_helper_crtc
> drm/fb-helper: Prepare to move out commit code
> drm/fb-helper: Move out commit code
> drm/fb-helper: Remove drm_fb_helper_connector
Patches 5-8 are still in need of review...
Noralf.
> drm/fb-helper: Prepare to move out modeset config code
> drm/fb-helper: Move out modeset config code
> drm/client: Hack: Add bootsplash example
>
> Documentation/gpu/drm-client.rst |3 +
> Documentation/gpu/todo.rst | 15 +
> drivers/gpu/drm/Kconfig |5 +
> drivers/gpu/drm/Makefile |3 +-
> drivers/gpu/drm/drm_atomic.c | 168
> drivers/gpu/drm/drm_atomic_helper.c | 164 ---
> drivers/gpu/drm/drm_auth.c | 20 +
> drivers/gpu/drm/drm_bootsplash.c | 358 +++
> drivers/gpu/drm/drm_client.c | 17 +-
> drivers/gpu/drm/drm_client_modeset.c | 1086
> drivers/gpu/drm/drm_crtc_internal.h |5 +
> drivers/gpu/drm/drm_drv.c|4 +
> drivers/gpu/drm/drm_fb_helper.c | 1392 +++---
> drivers/gpu/drm/drm_internal.h |2 +
> include/drm/drm_atomic_helper.h |4 -
> include/drm/drm_client.h | 49 +
> include/drm/drm_fb_helper.h | 102 +-
> 17 files changed, 1876 insertions(+), 1521 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_bootsplash.c
> create mode 100644 drivers/gpu/drm/drm_client_modeset.c
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, May 14, 2019 at 4:13 PM Paul Kocialkowski wrote: > > Hi, > > On Tue, 2019-05-14 at 13:09 +0200, Daniel Vetter wrote: > > On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski > > wrote: > > > Hey, > > > > > > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit : > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > > > 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. > > > > > > > > > > > > > > So we just had some discussions over on IRC and at about the > > > > > > > hotplug > > > > > > > issue and came up with similar ideas: > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > > > > > The conclusions of these discussions so far would be to have a > > > > > > > more or > > > > > > > less fine grain of uevent reporting depending on what happened. > > > > > > > The > > > > > > > point is that we need to cover different cases: > > > > > > > - one or more properties changed; > > > > > > > - the connector status changed; > > > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > > > > > For the first case, we can send out: > > > > > > > HOTPLUG=1 > > > > > > > CONNECTOR= > > > > > > > PROPERTY= > > > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > > > For the second one, something like: > > > > > > > HOTPLUG=1 > > > > > > > CONNECTOR= > > > > > > > STATUS=Connected/Disconnected > > > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > > disconnected; > > > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > > HOTPLUG=1 > > > > > > > CONNECTOR= > > > > > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > > > > > There's no material difference between this one and the previous > > > > > > one. > > > > > > Plus there's no beenfit in supplying the actual value of the > > > > > > property, > > > > > > i.e. we can reuse the same PROPERTY= trick. > > > > > > > > > > That's the idea, but we need to handle status changes differently than > > > > > properties, since as far as I know, connected/unconnected status is > > > > > not > > > > > exposed as a prop for the connector. > > > > > > > > Oops, totally missed that. "Everything is a property" is kinda > > > > new-ish, at least compared to kms. Kinda tempted to just make status > > > > into a property. Or another excuse why we should expose the epoch > > > > property :-) > > > > > > Well I think it would make sense anyway, as long as we can make sure it > > > stays consistent with the one reported in the connector struct. > > > > > > > > > Here's why: > > > > > > - A side effect of forcing a probe on a connector is that you get to > > > > > > read all the properties, so supplying them is kinda pointless. > > > > > > > > > > Agreed, except for the status case where it's useful to know it's a > > > > > disconnect, because we don't need any probe step in that case. > > > > > > > > > > > - You can read STATUS without forcing a reprobe, if you want to > > > > > > avoid > > > > > > the reprobe for disconnected. I'd kinda not recommend that though, > > > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e. > > > > > > dp) reprobing a disconnected output is fast. HDMI is ... less > > > > > > reasonable unfortunately, but oh well. > > > > > > > > > > How would that be retreived then? From the looks of it, that's a > > > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what > > > > > does the full reprobe. > > > > > > > > drmGetConnector vs drmGetConnectorCurrent. > > > > > > Ah right, forgot about that one, thanks. > > > > > > > > Not sure what issues could arise in case of disconnect without reprobe > > > > > -- at least I don't see why userspace should have to do anything in > > > > > particular except no longer using the connector, even in complex DP > > > > > MST > > > > > cases. > > > > > > > > connector->status might be a lie without a full reprobe, and wrongly > > > > indicate that the connector is disconnected while there's still > > > > something plugged in. I'm not sure we've fixed those bugs by now > > > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates > > > > connected, and we can't break this because every intel platform ever > > > >
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: adding state checker for gamma lut values (rev9)
== Series Details ==
Series: drm/i915: adding state checker for gamma lut values (rev9)
URL : https://patchwork.freedesktop.org/series/58039/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cb7a05f563c1 drm/i915: Introduce vfunc read_luts() to create hw lut
c687e9d64838 drm/i915: Enable intel_color_get_config()
a13dd89268a2 drm/i915: Add intel_color_lut_equal() to compare hw and sw
gamma/degamma lut values
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
-Corrected smatch warn "variable dereferenced before check" [Dan Carpenter]
-:85: ERROR:CODE_INDENT: code indent should use tabs where possible
#85: FILE: drivers/gpu/drm/i915/intel_color.c:1304:
+^I struct drm_color_lut *hw_lut, u32 err)$
-:85: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#85: FILE: drivers/gpu/drm/i915/intel_color.c:1304:
+static inline bool err_check(struct drm_color_lut *sw_lut,
+struct drm_color_lut *hw_lut, u32 err)
-:87: WARNING:TABSTOP: Statements should start on a tabstop
#87: FILE: drivers/gpu/drm/i915/intel_color.c:1306:
+return ((abs((long)hw_lut->red - sw_lut->red)) <= err) &&
-:88: ERROR:CODE_INDENT: code indent should use tabs where possible
#88: FILE: drivers/gpu/drm/i915/intel_color.c:1307:
+^I((abs((long)hw_lut->blue - sw_lut->blue)) <= err) &&$
-:89: ERROR:CODE_INDENT: code indent should use tabs where possible
#89: FILE: drivers/gpu/drm/i915/intel_color.c:1308:
+^I((abs((long)hw_lut->green - sw_lut->green)) <= err);$
-:120: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 17)
#120: FILE: drivers/gpu/drm/i915/intel_color.c:1339:
+ for (i = 0; i < sw_lut_size; i++) {
+if (!err_check(_lut[i], _lut[i], err))
-:121: WARNING:TABSTOP: Statements should start on a tabstop
#121: FILE: drivers/gpu/drm/i915/intel_color.c:1340:
+if (!err_check(_lut[i], _lut[i], err))
-:167: WARNING:LONG_LINE: line over 100 characters
#167: FILE: drivers/gpu/drm/i915/intel_display.c:11608:
+ pipe_config->cgm_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:167: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#167: FILE: drivers/gpu/drm/i915/intel_display.c:11608:
+ DRM_DEBUG_KMS("cgm_mode:%d gamma_mode:%d gamma_enable:%d
csc_enable:%d\n",
+ pipe_config->cgm_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:171: WARNING:LONG_LINE: line over 100 characters
#171: FILE: drivers/gpu/drm/i915/intel_display.c:11612:
+ pipe_config->csc_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:171: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#171: FILE: drivers/gpu/drm/i915/intel_display.c:11612:
+ DRM_DEBUG_KMS("csc_mode:%d gamma_mode:%d gamma_enable:%d
csc_enable:%d\n",
+ pipe_config->csc_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#189: FILE: drivers/gpu/drm/i915/intel_display.c:12144:
+#define PIPE_CONF_CHECK_COLOR_LUT(name, bit_precision) do { \
+ if (!intel_color_lut_equal(current_config->name, \
+ pipe_config->name, bit_precision)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+} while (0)
-:189: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as
'(name)' to avoid precedence issues
#189: FILE: drivers/gpu/drm/i915/intel_display.c:12144:
+#define PIPE_CONF_CHECK_COLOR_LUT(name, bit_precision) do { \
+ if (!intel_color_lut_equal(current_config->name, \
+ pipe_config->name, bit_precision)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+} while (0)
total: 3 errors, 6 warnings, 5 checks, 173 lines checked
92f0143b746e drm/i915: Extract i9xx_read_luts()
-:13: WARNING:TYPO_SPELLING: 'withing' may be misspelled - perhaps 'within'?
#13:
v5: -Returned blob instead of assigning it internally withing the
-:79: WARNING:LONG_LINE: line over 100 characters
#79: FILE: drivers/gpu/drm/i915/intel_color.c:1384:
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val), 8);
-:80: WARNING:LONG_LINE: line over 100 characters
#80: FILE: drivers/gpu/drm/i915/intel_color.c:1385:
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
-:81: WARNING:LONG_LINE: line over 100 characters
#81: FILE: drivers/gpu/drm/i915/intel_color.c:1386:
+
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: adding state checker for gamma lut values (rev8)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev8) URL : https://patchwork.freedesktop.org/series/58039/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6078_full -> Patchwork_13014_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13014_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13014_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13014_full: ### IGT changes ### Possible regressions * igt@kms_color@pipe-b-ctm-negative: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] +8 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/shard-kbl2/igt@kms_co...@pipe-b-ctm-negative.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-kbl6/igt@kms_co...@pipe-b-ctm-negative.html - shard-skl: [PASS][3] -> [DMESG-WARN][4] +10 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/shard-skl5/igt@kms_co...@pipe-b-ctm-negative.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-skl5/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_color@pipe-b-ctm-red-to-blue: - shard-hsw: [PASS][5] -> [DMESG-WARN][6] +10 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/shard-hsw5/igt@kms_co...@pipe-b-ctm-red-to-blue.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw6/igt@kms_co...@pipe-b-ctm-red-to-blue.html * igt@kms_color@pipe-b-gamma: - shard-snb: [PASS][7] -> [DMESG-WARN][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/shard-snb4/igt@kms_co...@pipe-b-gamma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-snb2/igt@kms_co...@pipe-b-gamma.html * igt@kms_color@pipe-c-ctm-0-25: - shard-apl: [PASS][9] -> [DMESG-WARN][10] +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/shard-apl8/igt@kms_co...@pipe-c-ctm-0-25.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-apl7/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_color@pipe-c-degamma: - shard-skl: NOTRUN -> [DMESG-WARN][11] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-skl5/igt@kms_co...@pipe-c-degamma.html * igt@runner@aborted: - shard-hsw: NOTRUN -> ([FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw4/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw6/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw8/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw7/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw8/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw1/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw1/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw1/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw1/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw2/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-hsw4/igt@run...@aborted.html - shard-snb: NOTRUN -> ([FAIL][23], [FAIL][24]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-snb2/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-snb2/igt@run...@aborted.html - shard-kbl: NOTRUN -> ([FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-kbl2/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-kbl6/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-kbl1/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-kbl1/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/shard-kbl4/igt@run...@aborted.html [30]:
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
Hi, On Tue, 2019-05-14 at 13:09 +0200, Daniel Vetter wrote: > On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski > wrote: > > Hey, > > > > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit : > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > wrote: > > > > Hi, > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > > 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. > > > > > > > > > > > > So we just had some discussions over on IRC and at about the hotplug > > > > > > issue and came up with similar ideas: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > > > The conclusions of these discussions so far would be to have a more > > > > > > or > > > > > > less fine grain of uevent reporting depending on what happened. The > > > > > > point is that we need to cover different cases: > > > > > > - one or more properties changed; > > > > > > - the connector status changed; > > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > > > For the first case, we can send out: > > > > > > HOTPLUG=1 > > > > > > CONNECTOR= > > > > > > PROPERTY= > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > For the second one, something like: > > > > > > HOTPLUG=1 > > > > > > CONNECTOR= > > > > > > STATUS=Connected/Disconnected > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > disconnected; > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > HOTPLUG=1 > > > > > > CONNECTOR= > > > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > > > There's no material difference between this one and the previous one. > > > > > Plus there's no beenfit in supplying the actual value of the property, > > > > > i.e. we can reuse the same PROPERTY= trick. > > > > > > > > That's the idea, but we need to handle status changes differently than > > > > properties, since as far as I know, connected/unconnected status is not > > > > exposed as a prop for the connector. > > > > > > Oops, totally missed that. "Everything is a property" is kinda > > > new-ish, at least compared to kms. Kinda tempted to just make status > > > into a property. Or another excuse why we should expose the epoch > > > property :-) > > > > Well I think it would make sense anyway, as long as we can make sure it > > stays consistent with the one reported in the connector struct. > > > > > > > Here's why: > > > > > - A side effect of forcing a probe on a connector is that you get to > > > > > read all the properties, so supplying them is kinda pointless. > > > > > > > > Agreed, except for the status case where it's useful to know it's a > > > > disconnect, because we don't need any probe step in that case. > > > > > > > > > - You can read STATUS without forcing a reprobe, if you want to avoid > > > > > the reprobe for disconnected. I'd kinda not recommend that though, > > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e. > > > > > dp) reprobing a disconnected output is fast. HDMI is ... less > > > > > reasonable unfortunately, but oh well. > > > > > > > > How would that be retreived then? From the looks of it, that's a > > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what > > > > does the full reprobe. > > > > > > drmGetConnector vs drmGetConnectorCurrent. > > > > Ah right, forgot about that one, thanks. > > > > > > Not sure what issues could arise in case of disconnect without reprobe > > > > -- at least I don't see why userspace should have to do anything in > > > > particular except no longer using the connector, even in complex DP MST > > > > cases. > > > > > > connector->status might be a lie without a full reprobe, and wrongly > > > indicate that the connector is disconnected while there's still > > > something plugged in. I'm not sure we've fixed those bugs by now > > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates > > > connected, and we can't break this because every intel platform ever > > > shipped has a few devices where this is somehow broken, irrespective > > > of the sink). > > > > Mhh either way, I think it's up to the driver to report that and make > > it consistent. I think we have poll helpers to make up for cases where > > hotplug is not available too. So I'm not sure why a full reprobe would > > be needed: drivers just need to do the
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
Hi, On Tue, 2019-05-14 at 16:36 +0300, Pekka Paalanen wrote: > On Tue, 14 May 2019 13:02:09 +0200 > Daniel Vetter wrote: > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon wrote: > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > On Mon, 13 May 2019 11:34:58 +0200 > > > > Daniel Vetter wrote: > > > > > > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > So we just had some discussions over on IRC and at about the > > > > > > > > hotplug > > > > > > > > issue and came up with similar ideas: > > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > > > > > > > The conclusions of these discussions so far would be to have a > > > > > > > > more or > > > > > > > > less fine grain of uevent reporting depending on what happened. > > > > > > > > The > > > > > > > > point is that we need to cover different cases: > > > > > > > > - one or more properties changed; > > > > > > > > - the connector status changed; > > > > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > > > > > > > For the first case, we can send out: > > > > > > > > HOTPLUG=1 > > > > > > > > CONNECTOR= > > > > > > > > PROPERTY= > > > > > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > > > > > For the second one, something like: > > > > > > > > HOTPLUG=1 > > > > > > > > CONNECTOR= > > > > > > > > STATUS=Connected/Disconnected > > > > > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > > > disconnected; > > > > > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > > > HOTPLUG=1 > > > > > > > > CONNECTOR= > > > > > > > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > > > > > > > There's no material difference between this one and the previous > > > > > > > one. > > > > > > > Plus there's no beenfit in supplying the actual value of the > > > > > > > property, > > > > > > > i.e. we can reuse the same PROPERTY= > > > > > > > trick. > > > > > > > > > > > > That's the idea, but we need to handle status changes differently > > > > > > than > > > > > > properties, since as far as I know, connected/unconnected status is > > > > > > not > > > > > > exposed as a prop for the connector. > > > > > > > > > > Oops, totally missed that. "Everything is a property" is kinda > > > > > new-ish, at least compared to kms. Kinda tempted to just make status > > > > > into a property. Or another excuse why we should expose the epoch > > > > > property :-) > > > > > > > > Hi Daniel, > > > > > > > > just to clarify the first case, specific to one very particular > > > > property: > > > > > > > > With HDCP, there is a property that may change dynamically at runtime > > > > (the undesired/desired/enabled tristate). Userspace must be notified > > > > when it changes, I do not want userspace have to poll that property > > > > with a timer. > > > > > > > > When that property alone changes, and userspace is prepared to handle > > > > that property changing alone, it must not trigger a reprobe of the > > > > connector. There is no reason to reprobe at that point AFAIU. > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the > > > > epoch approach or with any alternate uevent design? > > > > > > > > We need an event to userspace that indicates that re-reading the > > > > properties is enough and reprobe of the connector is not necessary. > > > > This is complementary to indicating to userspace that only some > > > > connectors need to be reprobed instead of everything. > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the > > > reprobing. Would that work? > > Hi, > > yes, that would work, if it was acceptable to DRM upstream. The replies > to Paul seemed to be going south so fast that I thought we wouldn't get > any new uevent fields in favour of "epoch counters". > > > Yes that's the idea, depending upon which property you get you know > > it's a sink change (needs full reprobe) or something else like hdcp > > state machinery update. > > Right. > > >
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, 14 May 2019 13:02:09 +0200 Daniel Vetter wrote: > On Tue, May 14, 2019 at 10:18 AM Ser, Simon wrote: > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > On Mon, 13 May 2019 11:34:58 +0200 > > > Daniel Vetter wrote: > > > > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > > > 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. > > > > > > > > > > > > > > So we just had some discussions over on IRC and at about the > > > > > > > hotplug > > > > > > > issue and came up with similar ideas: > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > > > > > The conclusions of these discussions so far would be to have a > > > > > > > more or > > > > > > > less fine grain of uevent reporting depending on what happened. > > > > > > > The > > > > > > > point is that we need to cover different cases: > > > > > > > - one or more properties changed; > > > > > > > - the connector status changed; > > > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > > > > > For the first case, we can send out: > > > > > > > HOTPLUG=1 > > > > > > > CONNECTOR= > > > > > > > PROPERTY= > > > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > > > For the second one, something like: > > > > > > > HOTPLUG=1 > > > > > > > CONNECTOR= > > > > > > > STATUS=Connected/Disconnected > > > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > > disconnected; > > > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > > HOTPLUG=1 > > > > > > > CONNECTOR= > > > > > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > > > > > There's no material difference between this one and the previous > > > > > > one. > > > > > > Plus there's no beenfit in supplying the actual value of the > > > > > > property, > > > > > > i.e. we can reuse the same PROPERTY= trick. > > > > > > > > > > That's the idea, but we need to handle status changes differently than > > > > > properties, since as far as I know, connected/unconnected status is > > > > > not > > > > > exposed as a prop for the connector. > > > > > > > > Oops, totally missed that. "Everything is a property" is kinda > > > > new-ish, at least compared to kms. Kinda tempted to just make status > > > > into a property. Or another excuse why we should expose the epoch > > > > property :-) > > > > > > Hi Daniel, > > > > > > just to clarify the first case, specific to one very particular > > > property: > > > > > > With HDCP, there is a property that may change dynamically at runtime > > > (the undesired/desired/enabled tristate). Userspace must be notified > > > when it changes, I do not want userspace have to poll that property > > > with a timer. > > > > > > When that property alone changes, and userspace is prepared to handle > > > that property changing alone, it must not trigger a reprobe of the > > > connector. There is no reason to reprobe at that point AFAIU. > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the > > > epoch approach or with any alternate uevent design? > > > > > > We need an event to userspace that indicates that re-reading the > > > properties is enough and reprobe of the connector is not necessary. > > > This is complementary to indicating to userspace that only some > > > connectors need to be reprobed instead of everything. > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the > > reprobing. Would that work? Hi, yes, that would work, if it was acceptable to DRM upstream. The replies to Paul seemed to be going south so fast that I thought we wouldn't get any new uevent fields in favour of "epoch counters". > Yes that's the idea, depending upon which property you get you know > it's a sink change (needs full reprobe) or something else like hdcp > state machinery update. Right. > Wrt avoiding the full reprobe for sink changes: I think we should > indeed decouple that from the per-connector event for sink changes. > That along is a good win already, since you know for which connector > you need to call drmGetConnector (which forces the reprobe). It would > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but >
Re: [Intel-gfx] [v9 03/13] drm: Parse HDR metadata info from EDID
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Tuesday, May 14, 2019 12:49 AM
>> >To: Shankar, Uma
>> >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>> >dcasta...@chromium.org; jo...@kwiboo.se; emil.l.veli...@gmail.com;
>> >seanp...@chromium.org; Syrjala, Ville ;
>> >Lankhorst, Maarten
>> >Subject: Re: [v9 03/13] drm: Parse HDR metadata info from EDID
>> >
>> >On Thu, May 09, 2019 at 12:08:43AM +0530, 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 852bdd8..fe2c29b 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -2852,6 +2852,7 @@ static int drm_cvt_modes(struct drm_connector
>> >*connector,
>> >> #define VIDEO_BLOCK 0x02
>> >> #define VENDOR_BLOCK0x03
>> >> #define SPEAKER_BLOCK0x04
>> >> +#define HDR_STATIC_METADATA_BLOCK0x6
>> >> #define USE_EXTENDED_TAG 0x07
>> >> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>> >> #define EXT_VIDEO_DATA_BLOCK_420 0x0E
>> >> @@ -3599,6 +3600,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];
>> >> @@ -3834,6 +3841,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;
>> >> +
>> >> + 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);
>> >
>> >Length checks missing for this stuff.
>>
>> The above 2 are mandatory bytes , so this will always be there in this block.
>
>You can only make that claim if the EDID is not malicious or corrupted.
>Never trust anything coming from an external source!
Ok Got it, will have a check to ensure that we have a reliable EDID.
>> Byte 5 to 7 are optional and depends on length field. So we should not
>> need a length check here for above 2 fields. Hope my understanding is right.
>>
>> >> +
>> >> + 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];
>> >
>> >All the length checks seem to be off by one due to cea_db_payload_len_ext().
>> >I think just dropping cea_db_payload_len_ext() would make things
>> >better since a) nothing else has that, b) db still points at the
>> >start of the whole data block instead of the payload.
>>
>> The length field adds/includes the extended tag byte while reporting
>> the size of block. So we need to remove 1 byte to get the correct size of
>> data. A
>value of n = 3 means bytes 5 to 7 are not present.
>>
>> >The while payload vs. block length thing is already confusing anyway.
>> >I have a feeling we should replace cea_db_payload_len() with
>> >something that returns the length of the whole data block. That way
>> >the db[index] vs. length checks would start to make some sense to the casual
>reader.
>>
>> I hope with above understanding, in db[index], index just tells the
>> byte number for a particular field which matches exactly to spec offsets.
>
>Not quite
Re: [Intel-gfx] [PATCH i-g-t 10/16] i915/gem_exec_whisper: Fork all-engine tests one-per-engine
On 08/05/2019 11:09, Chris Wilson wrote:
Add a new mode for some more stress, submit the all-engines tests
simultaneously, a stream per engine.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index d3e0b0ba2..d5afc8119 100644
--- a/tests/i915/gem_exec_whisper.c
+++ b/tests/i915/gem_exec_whisper.c
@@ -88,6 +88,7 @@ static void verify_reloc(int fd, uint32_t handle,
#define SYNC 0x40
#define PRIORITY 0x80
#define QUEUES 0x100
+#define ALL 0x200
struct hang {
struct drm_i915_gem_exec_object2 obj;
@@ -199,6 +200,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
uint64_t old_offset;
int i, n, loc;
int debugfs;
+ int nchild;
if (flags & PRIORITY) {
igt_require(gem_scheduler_enabled(fd));
@@ -215,6 +217,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
engines[nengine++] = engine;
}
} else {
+ igt_assert(!(flags & ALL));
igt_require(gem_has_ring(fd, engine));
igt_require(gem_can_store_dword(fd, engine));
engines[nengine++] = engine;
@@ -233,11 +236,22 @@ static void whisper(int fd, unsigned engine, unsigned
flags)
if (flags & HANG)
init_hang();
+ nchild = 1;
+ if (flags & FORKED)
+ nchild *= sysconf(_SC_NPROCESSORS_ONLN);
+ if (flags & ALL)
+ nchild *= nengine;
+
intel_detect_and_clear_missed_interrupts(fd);
gpu_power_read(, [0]);
- igt_fork(child, flags & FORKED ? sysconf(_SC_NPROCESSORS_ONLN) : 1) {
+ igt_fork(child, nchild) {
unsigned int pass;
+ if (flags & ALL) {
+ engines[0] = engines[child % nengine];
Relying on PIDs being sequential feels fragile but suggesting pipes or
shared memory would be overkill. How about another loop:
if (flags & ALL) {
for (i = 0; i < nchild; i++) {
engines_copy = engines;
nengines_copy = nengine;
negines_child = 1;
engines[0] = engines[i];
igt_fork(child, 1) {
...
}
if (in_parent) {
engines = engines_copy;
nengine = nengines_copy;
} else {
break;
}
}
}
?
Regards,
Tvrtko
+ nengine = 1;
+ }
+
memset(, 0, sizeof(scratch));
scratch.handle = gem_create(fd, 4096);
scratch.flags = EXEC_OBJECT_WRITE;
@@ -341,7 +355,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
igt_until_timeout(150) {
uint64_t offset;
-if (!(flags & FORKED))
+ if (nchild == 1)
write_seqno(debugfs, pass);
if (flags & HANG)
@@ -382,8 +396,8 @@ static void whisper(int fd, unsigned engine, unsigned flags)
gem_write(fd, batches[1023].handle, loc, , sizeof(pass));
for (n = 1024; --n >= 1; ) {
+ uint32_t handle[2] = {};
int this_fd = fd;
- uint32_t handle[2];
execbuf.buffers_ptr = to_user_pointer([n-1]);
reloc_migrations += batches[n-1].offset
!= inter[n].presumed_offset;
@@ -550,7 +564,7 @@ igt_main
{ "queues-sync", QUEUES | SYNC },
{ NULL }
};
- int fd;
+ int fd = -1;
igt_fixture {
fd = drm_open_driver_master(DRIVER_INTEL);
@@ -561,9 +575,12 @@ igt_main
igt_fork_hang_detector(fd);
}
- for (const struct mode *m = modes; m->name; m++)
+ for (const struct mode *m = modes; m->name; m++) {
igt_subtest_f("%s", m->name)
whisper(fd, ALL_ENGINES, m->flags);
+ igt_subtest_f("%s-all", m->name)
+ whisper(fd, ALL_ENGINES, m->flags | ALL);
+ }
for (const struct intel_execution_engine *e = intel_execution_engines;
e->name; e++) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 11/16] i915/gem_exec_whisper: debugfs/next_seqno is defunct
On 08/05/2019 11:09, Chris Wilson wrote:
We removed next_seqno in 5.1, so time to wave goodbye.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 12
1 file changed, 12 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index d5afc8119..61b8d6dac 100644
--- a/tests/i915/gem_exec_whisper.c
+++ b/tests/i915/gem_exec_whisper.c
@@ -44,15 +44,6 @@
#define VERIFY 0
-static void write_seqno(int dir, unsigned offset)
-{
- uint32_t seqno = UINT32_MAX - offset;
-
- igt_sysfs_printf(dir, "i915_next_seqno", "0x%x", seqno);
-
- igt_debug("next seqno set to: 0x%x\n", seqno);
-}
-
static void check_bo(int fd, uint32_t handle, int pass)
{
uint32_t *map;
@@ -355,9 +346,6 @@ static void whisper(int fd, unsigned engine, unsigned flags)
igt_until_timeout(150) {
uint64_t offset;
-if (nchild == 1)
- write_seqno(debugfs, pass);
-
if (flags & HANG)
submit_hang(, engines, nengine,
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 i-g-t 09/16] i915/gem_ctx_switch: Exercise queues
On 08/05/2019 11:09, Chris Wilson wrote:
Queues are a form of contexts that share vm and enfore a single timeline
across all engines. Test switching between them, just like ordinary
contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_switch.c | 75 +++--
1 file changed, 55 insertions(+), 20 deletions(-)
diff --git a/tests/i915/gem_ctx_switch.c b/tests/i915/gem_ctx_switch.c
index 87e13b915..647911d4c 100644
--- a/tests/i915/gem_ctx_switch.c
+++ b/tests/i915/gem_ctx_switch.c
@@ -44,7 +44,8 @@
#define LOCAL_I915_EXEC_NO_RELOC (1<<11)
#define LOCAL_I915_EXEC_HANDLE_LUT (1<<12)
-#define INTERRUPTIBLE 1
+#define INTERRUPTIBLE 0x1
+#define QUEUE 0x2
static double elapsed(const struct timespec *start, const struct timespec *end)
{
@@ -126,8 +127,12 @@ static void single(int fd, uint32_t handle,
gem_require_ring(fd, e->exec_id | e->flags);
- for (n = 0; n < 64; n++)
- contexts[n] = gem_context_create(fd);
+ for (n = 0; n < 64; n++) {
+ if (flags & QUEUE)
+ contexts[n] = gem_queue_create(fd);
+ else
+ contexts[n] = gem_context_create(fd);
+ }
memset(, 0, sizeof(obj));
obj.handle = handle;
@@ -232,8 +237,12 @@ static void all(int fd, uint32_t handle, unsigned flags,
int timeout)
}
igt_require(nengine);
- for (n = 0; n < ARRAY_SIZE(contexts); n++)
- contexts[n] = gem_context_create(fd);
+ for (n = 0; n < ARRAY_SIZE(contexts); n++) {
+ if (flags & QUEUE)
+ contexts[n] = gem_queue_create(fd);
+ else
+ contexts[n] = gem_context_create(fd);
+ }
memset(obj, 0, sizeof(obj));
obj[1].handle = handle;
@@ -298,6 +307,17 @@ igt_main
{
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
const struct intel_execution_engine *e;
+ static const struct {
+ const char *name;
+ unsigned int flags;
+ bool (*require)(int fd);
+ } phases[] = {
+ { "", 0, NULL },
+ { "-interruptible", INTERRUPTIBLE, NULL },
+ { "-queue", QUEUE, gem_has_queues },
+ { "-queue-interruptible", QUEUE | INTERRUPTIBLE, gem_has_queues
},
+ { }
+ };
uint32_t light = 0, heavy;
int fd = -1;
@@ -319,21 +339,26 @@ igt_main
}
for (e = intel_execution_engines; e->name; e++) {
- igt_subtest_f("%s%s", e->exec_id == 0 ? "basic-" : "", e->name)
- single(fd, light, e, 0, 1, 5);
-
- igt_skip_on_simulation();
-
- igt_subtest_f("%s%s-heavy", e->exec_id == 0 ? "basic-" : "",
e->name)
- single(fd, heavy, e, 0, 1, 5);
- igt_subtest_f("%s-interruptible", e->name)
- single(fd, light, e, INTERRUPTIBLE, 1, 150);
- igt_subtest_f("forked-%s", e->name)
- single(fd, light, e, 0, ncpus, 150);
- igt_subtest_f("forked-%s-heavy", e->name)
- single(fd, heavy, e, 0, ncpus, 150);
- igt_subtest_f("forked-%s-interruptible", e->name)
- single(fd, light, e, INTERRUPTIBLE, ncpus, 150);
+ for (typeof(*phases) *p = phases; p->name; p++) {
+ igt_subtest_group {
+ igt_fixture {
+ if (p->require)
+ igt_require(p->require(fd));
+ }
+
+ igt_subtest_f("%s%s%s", e->exec_id == 0 ? "basic-" :
"", e->name, p->name)
+ single(fd, light, e, p->flags, 1, 5);
+
+ igt_skip_on_simulation();
+
+ igt_subtest_f("%s%s-heavy%s", e->exec_id == 0 ? "basic-" :
"", e->name, p->name)
+ single(fd, heavy, e, p->flags, 1, 5);
+ igt_subtest_f("forked-%s%s", e->name, p->name)
+ single(fd, light, e, p->flags, ncpus,
150);
+ igt_subtest_f("forked-%s-heavy%s", e->name,
p->name)
+ single(fd, heavy, e, p->flags, ncpus,
150);
+ }
+ }
}
igt_subtest("basic-all-light")
@@ -341,6 +366,16 @@ igt_main
igt_subtest("basic-all-heavy")
all(fd, heavy, 0, 5);
+ igt_subtest_group {
+ igt_fixture {
+ igt_require(gem_has_queues(fd));
+ }
+ igt_subtest("basic-queue-light")
+ all(fd, light, QUEUE, 5);
+ igt_subtest("basic-queue-heavy")
+ all(fd, heavy, QUEUE,
Re: [Intel-gfx] [v9 04/13] drm: Enable HDR infoframe support
On Tue, May 14, 2019 at 12:36:25PM +, Kazlauskas, Nicholas wrote:
> On 5/8/19 2:38 PM, Uma Shankar wrote:
> > [CAUTION: External Email]
> >
> > Enable Dynamic Range and Mastering Infoframe for HDR
> > content, which is defined in CEA 861.3 spec.
> >
> > The metadata will be computed based on blending
> > policy in userspace compositors and passed as a connector
> > property blob to driver. The same will be sent as infoframe
> > to panel which support HDR.
> >
> > Added the const version of infoframe for DRM metadata
> > for HDR.
> >
> > v2: Rebase and added Ville's POC changes.
> >
> > v3: No Change
> >
> > v4: Addressed Shashank's review comments and merged the
> > patch making drm infoframe function arguments as constant.
> >
> > v5: Rebase
> >
> > v6: Fixed checkpatch warnings with --strict option. Addressed
> > Shashank's review comments and added his RB.
> >
> > v7: Addressed Brian Starkey's review comments. Merged 2 patches
> > into one.
> >
> > v8: Addressed Jonas Karlman review comments.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Ville Syrjälä
> > Reviewed-by: Shashank Sharma
> > ---
> > drivers/gpu/drm/drm_edid.c | 48
> > drivers/video/hdmi.c | 186
> > +
> > include/drm/drm_edid.h | 5 ++
> > include/linux/hdmi.h | 27 +++
> > 4 files changed, 266 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index fe2c29b..5f48965 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4906,6 +4906,54 @@ static bool is_hdmi2_sink(struct drm_connector
> > *connector)
> > }
> >
> > /**
> > + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
> > + * HDR metadata from userspace
> > + * @frame: HDMI AVI infoframe
> > + * @hdr_source_metadata: hdr_source_metadata info from userspace
> > + *
> > + * Return: 0 on success or a negative error code on failure.
> > + */
> > +int
> > +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
> > + struct hdr_output_metadata
> > *hdr_metadata)
hdr_metadata can be const.
> > +{
> > + int err;
> > +
> > + if (!frame || !hdr_metadata)
> > + return true;
true?
> > +
> > + err = hdmi_drm_infoframe_init(frame);
> > + if (err < 0)
> > + return err;
> > +
> > + DRM_DEBUG_KMS("type = %x\n", frame->type);
> > +
> > + frame->length = sizeof(struct hdr_metadata_infoframe);
> > +
> > + frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
> > + frame->metadata_type =
> > hdr_metadata->hdmi_metadata_type1.metadata_type;
> > +
> > + memcpy(>display_primaries,
> > + _metadata->hdmi_metadata_type1.display_primaries, 12);
> > +
> > + memcpy(>white_point,
> > + _metadata->hdmi_metadata_type1.white_point, 4);
> > +
> > + frame->max_display_mastering_luminance =
> > +
> > hdr_metadata->hdmi_metadata_type1.max_display_mastering_luminance;
> > + frame->min_display_mastering_luminance =
> > +
> > hdr_metadata->hdmi_metadata_type1.min_display_mastering_luminance;
> > + frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
> > + frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
> > +
> > + hdmi_infoframe_log(KERN_CRIT, NULL,
> > + (union hdmi_infoframe *)frame);
>
> This shouldn't really be KERN_CRIT for debug output. Maybe KERN_INFO or
> KERN_DEBUG or just drop the log altogether since it can't actually tag
> it to DRM or the driver itself in this function.
Yeah, this shouldn't be here. It's up to the driver to dump it when it
wants to.
>
> Nicholas Kazlauskas
>
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> > +
> > +/**
> >* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI
> > infoframe with
> >* data from a DRM display
> > mode
> >* @frame: HDMI AVI infoframe
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 799ae49..717ed7fb 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -650,6 +650,146 @@ ssize_t hdmi_vendor_infoframe_pack(struct
> > hdmi_vendor_infoframe *frame,
> > return 0;
> > }
> >
> > +/**
> > + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
> > + * mastering infoframe
> > + * @frame: HDMI DRM infoframe
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
> > +{
> > + memset(frame, 0, sizeof(*frame));
> > +
> > + frame->type = HDMI_INFOFRAME_TYPE_DRM;
> > + frame->version = 1;
> > +
> > + return 0;
> > +}
> >
Re: [Intel-gfx] [v9 03/13] drm: Parse HDR metadata info from EDID
On Tue, May 14, 2019 at 09:49:03AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, May 14, 2019 12:49 AM
> >To: Shankar, Uma
> >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> >dcasta...@chromium.org; jo...@kwiboo.se; emil.l.veli...@gmail.com;
> >seanp...@chromium.org; Syrjala, Ville ; Lankhorst,
> >Maarten
> >
> >Subject: Re: [v9 03/13] drm: Parse HDR metadata info from EDID
> >
> >On Thu, May 09, 2019 at 12:08:43AM +0530, 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 852bdd8..fe2c29b 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -2852,6 +2852,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_BLOCK 0x6
> >> #define USE_EXTENDED_TAG 0x07
> >> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> >> #define EXT_VIDEO_DATA_BLOCK_420 0x0E
> >> @@ -3599,6 +3600,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];
> >> @@ -3834,6 +3841,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;
> >> +
> >> + 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);
> >
> >Length checks missing for this stuff.
>
> The above 2 are mandatory bytes , so this will always be there in this block.
You can only make that claim if the EDID is not malicious or corrupted.
Never trust anything coming from an external source!
> Byte 5 to 7 are optional and depends on length field. So we should not need a
> length
> check here for above 2 fields. Hope my understanding is right.
>
> >> +
> >> + 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];
> >
> >All the length checks seem to be off by one due to cea_db_payload_len_ext().
> >I think just dropping cea_db_payload_len_ext() would make things better
> >since a)
> >nothing else has that, b) db still points at the start of the whole data
> >block instead of
> >the payload.
>
> The length field adds/includes the extended tag byte while reporting the
> size of block. So we need to
> remove 1 byte to get the correct size of data. A value of n = 3 means bytes 5
> to 7 are not present.
>
> >The while payload vs. block length thing is already confusing anyway.
> >I have a feeling we should replace cea_db_payload_len() with something that
> >returns
> >the length of the whole data block. That way the db[index] vs. length checks
> >would
> >start to make some sense to the casual reader.
>
> I hope with above understanding, in db[index], index just tells the byte
> number for a particular
> field which matches exactly to spec offsets.
Not quite sure what you're saying.
What I'm saying is that with eg. n=6 (ie. the full
Re: [Intel-gfx] [PATCH i-g-t 07/16] i915: Add gem_ctx_clone
On 08/05/2019 11:09, Chris Wilson wrote:
Exercise cloning contexts, an extension of merely creating one.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/i915/gem_ctx_clone.c | 460 +
tests/meson.build | 1 +
3 files changed, 462 insertions(+)
create mode 100644 tests/i915/gem_ctx_clone.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 1a541d206..e1b7feeb2 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -21,6 +21,7 @@ TESTS_progs = \
drm_import_export \
drm_mm \
drm_read \
+ i915/gem_ctx_clone \
i915/gem_vm_create \
kms_3d \
kms_addfb_basic \
diff --git a/tests/i915/gem_ctx_clone.c b/tests/i915/gem_ctx_clone.c
new file mode 100644
index 0..cdc5bf413
--- /dev/null
+++ b/tests/i915/gem_ctx_clone.c
@@ -0,0 +1,460 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+#include "i915/gem_vm.h"
+#include "i915_drm.h"
+
+static int ctx_create_ioctl(int i915, struct drm_i915_gem_context_create_ext
*arg)
+{
+ int err;
+
+ err = 0;
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static bool has_ctx_clone(int i915)
+{
+ struct drm_i915_gem_context_create_ext_clone ext = {
+ { .name = I915_CONTEXT_CREATE_EXT_CLONE },
+ .clone_id = -1,
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = to_user_pointer(),
+ };
+ return ctx_create_ioctl(i915, ) == -ENOENT;
+}
+
+static void invalid_clone(int i915)
+{
+ struct drm_i915_gem_context_create_ext_clone ext = {
+ { .name = I915_CONTEXT_CREATE_EXT_CLONE },
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = to_user_pointer(),
+ };
+
+ igt_assert_eq(ctx_create_ioctl(i915, ), 0);
+ gem_context_destroy(i915, create.ctx_id);
+
+ ext.flags = -1; /* Hopefully we won't run out of flags */
+ igt_assert_eq(ctx_create_ioctl(i915, ), -EINVAL);
+ ext.flags = 0;
+
+ ext.base.next_extension = -1;
+ igt_assert_eq(ctx_create_ioctl(i915, ), -EFAULT);
+ ext.base.next_extension = to_user_pointer();
+ igt_assert_eq(ctx_create_ioctl(i915, ), -E2BIG);
+ ext.base.next_extension = 0;
+
+ ext.clone_id = -1;
+ igt_assert_eq(ctx_create_ioctl(i915, ), -ENOENT);
+ ext.clone_id = 0;
+}
+
+static void clone_flags(int i915)
+{
+ struct drm_i915_gem_context_create_ext_setparam set = {
+ { .name = I915_CONTEXT_CREATE_EXT_SETPARAM },
+ { .param = I915_CONTEXT_PARAM_RECOVERABLE },
+ };
+ struct drm_i915_gem_context_create_ext_clone ext = {
+ { .name = I915_CONTEXT_CREATE_EXT_CLONE },
+ .flags = I915_CONTEXT_CLONE_FLAGS,
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = to_user_pointer(),
+ };
+ int expected;
+
+ set.param.value = 1; /* default is recoverable */
+ igt_require(__gem_context_set_param(i915, ) == 0);
+
+ for (int pass = 0; pass < 2; pass++) { /* cloning default, then child */
+ igt_debug("Cloning %d\n", ext.clone_id);
+ igt_assert_eq(ctx_create_ioctl(i915, ), 0);
+
+ set.param.ctx_id = ext.clone_id;
+ gem_context_get_param(i915, ); > +
expected =
Re: [Intel-gfx] [v9 04/13] drm: Enable HDR infoframe support
>-Original Message-
>From: Kazlauskas, Nicholas [mailto:nicholas.kazlaus...@amd.com]
>Sent: Tuesday, May 14, 2019 6:06 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: dcasta...@chromium.org; jo...@kwiboo.se; emil.l.veli...@gmail.com;
>seanp...@chromium.org; Syrjala, Ville ; Lankhorst,
>Maarten
>
>Subject: Re: [v9 04/13] drm: Enable HDR infoframe support
>
>On 5/8/19 2:38 PM, Uma Shankar wrote:
>> [CAUTION: External Email]
>>
>> Enable Dynamic Range and Mastering Infoframe for HDR content, which is
>> defined in CEA 861.3 spec.
>>
>> The metadata will be computed based on blending policy in userspace
>> compositors and passed as a connector property blob to driver. The
>> same will be sent as infoframe to panel which support HDR.
>>
>> Added the const version of infoframe for DRM metadata for HDR.
>>
>> v2: Rebase and added Ville's POC changes.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments and merged the patch making
>> drm infoframe function arguments as constant.
>>
>> v5: Rebase
>>
>> v6: Fixed checkpatch warnings with --strict option. Addressed
>> Shashank's review comments and added his RB.
>>
>> v7: Addressed Brian Starkey's review comments. Merged 2 patches into
>> one.
>>
>> v8: Addressed Jonas Karlman review comments.
>>
>> Signed-off-by: Uma Shankar
>> Signed-off-by: Ville Syrjälä
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_edid.c | 48
>> drivers/video/hdmi.c | 186
>+
>> include/drm/drm_edid.h | 5 ++
>> include/linux/hdmi.h | 27 +++
>> 4 files changed, 266 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index fe2c29b..5f48965 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4906,6 +4906,54 @@ static bool is_hdmi2_sink(struct drm_connector
>*connector)
>> }
>>
>> /**
>> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
>> + * HDR metadata from userspace
>> + * @frame: HDMI AVI infoframe
>> + * @hdr_source_metadata: hdr_source_metadata info from userspace
>> + *
>> + * Return: 0 on success or a negative error code on failure.
>> + */
>> +int
>> +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
>> + struct hdr_output_metadata
>> +*hdr_metadata) {
>> + int err;
>> +
>> + if (!frame || !hdr_metadata)
>> + return true;
>> +
>> + err = hdmi_drm_infoframe_init(frame);
>> + if (err < 0)
>> + return err;
>> +
>> + DRM_DEBUG_KMS("type = %x\n", frame->type);
>> +
>> + frame->length = sizeof(struct hdr_metadata_infoframe);
>> +
>> + frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
>> + frame->metadata_type =
>> + hdr_metadata->hdmi_metadata_type1.metadata_type;
>> +
>> + memcpy(>display_primaries,
>> + _metadata->hdmi_metadata_type1.display_primaries,
>> + 12);
>> +
>> + memcpy(>white_point,
>> + _metadata->hdmi_metadata_type1.white_point, 4);
>> +
>> + frame->max_display_mastering_luminance =
>> + hdr_metadata-
>>hdmi_metadata_type1.max_display_mastering_luminance;
>> + frame->min_display_mastering_luminance =
>> + hdr_metadata-
>>hdmi_metadata_type1.min_display_mastering_luminance;
>> + frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
>> + frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
>> +
>> + hdmi_infoframe_log(KERN_CRIT, NULL,
>> + (union hdmi_infoframe *)frame);
>
>This shouldn't really be KERN_CRIT for debug output. Maybe KERN_INFO or
>KERN_DEBUG or just drop the log altogether since it can't actually tag it to
>DRM or
>the driver itself in this function.
I added this for debug and missed to drop it, it's really not needed. Will drop
this log in the next version.
Regards,
Uma Shankar
>Nicholas Kazlauskas
>
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>> +
>> +/**
>>* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
>with
>>* data from a DRM display
>> mode
>>* @frame: HDMI AVI infoframe
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 799ae49..717ed7fb 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -650,6 +650,146 @@ ssize_t hdmi_vendor_infoframe_pack(struct
>hdmi_vendor_infoframe *frame,
>> return 0;
>> }
>>
>> +/**
>> + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
>> + * mastering infoframe
>> + * @frame: HDMI DRM infoframe
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame) {
>> +
Re: [Intel-gfx] [v9 04/13] drm: Enable HDR infoframe support
On 5/8/19 2:38 PM, Uma Shankar wrote:
> [CAUTION: External Email]
>
> Enable Dynamic Range and Mastering Infoframe for HDR
> content, which is defined in CEA 861.3 spec.
>
> The metadata will be computed based on blending
> policy in userspace compositors and passed as a connector
> property blob to driver. The same will be sent as infoframe
> to panel which support HDR.
>
> Added the const version of infoframe for DRM metadata
> for HDR.
>
> v2: Rebase and added Ville's POC changes.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments and merged the
> patch making drm infoframe function arguments as constant.
>
> v5: Rebase
>
> v6: Fixed checkpatch warnings with --strict option. Addressed
> Shashank's review comments and added his RB.
>
> v7: Addressed Brian Starkey's review comments. Merged 2 patches
> into one.
>
> v8: Addressed Jonas Karlman review comments.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 48
> drivers/video/hdmi.c | 186
> +
> include/drm/drm_edid.h | 5 ++
> include/linux/hdmi.h | 27 +++
> 4 files changed, 266 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fe2c29b..5f48965 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4906,6 +4906,54 @@ static bool is_hdmi2_sink(struct drm_connector
> *connector)
> }
>
> /**
> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
> + * HDR metadata from userspace
> + * @frame: HDMI AVI infoframe
> + * @hdr_source_metadata: hdr_source_metadata info from userspace
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int
> +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
> + struct hdr_output_metadata *hdr_metadata)
> +{
> + int err;
> +
> + if (!frame || !hdr_metadata)
> + return true;
> +
> + err = hdmi_drm_infoframe_init(frame);
> + if (err < 0)
> + return err;
> +
> + DRM_DEBUG_KMS("type = %x\n", frame->type);
> +
> + frame->length = sizeof(struct hdr_metadata_infoframe);
> +
> + frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
> + frame->metadata_type =
> hdr_metadata->hdmi_metadata_type1.metadata_type;
> +
> + memcpy(>display_primaries,
> + _metadata->hdmi_metadata_type1.display_primaries, 12);
> +
> + memcpy(>white_point,
> + _metadata->hdmi_metadata_type1.white_point, 4);
> +
> + frame->max_display_mastering_luminance =
> +
> hdr_metadata->hdmi_metadata_type1.max_display_mastering_luminance;
> + frame->min_display_mastering_luminance =
> +
> hdr_metadata->hdmi_metadata_type1.min_display_mastering_luminance;
> + frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
> + frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
> +
> + hdmi_infoframe_log(KERN_CRIT, NULL,
> + (union hdmi_infoframe *)frame);
This shouldn't really be KERN_CRIT for debug output. Maybe KERN_INFO or
KERN_DEBUG or just drop the log altogether since it can't actually tag
it to DRM or the driver itself in this function.
Nicholas Kazlauskas
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> +
> +/**
>* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
> with
>* data from a DRM display mode
>* @frame: HDMI AVI infoframe
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 799ae49..717ed7fb 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -650,6 +650,146 @@ ssize_t hdmi_vendor_infoframe_pack(struct
> hdmi_vendor_infoframe *frame,
> return 0;
> }
>
> +/**
> + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
> + * mastering infoframe
> + * @frame: HDMI DRM infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_DRM;
> + frame->version = 1;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_drm_infoframe_init);
> +
> +static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe
> *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
> + frame->version != 1)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
> + * @frame: HDMI DRM infoframe
> + *
> + * Validates that the infoframe is consistent.
> + * Returns 0 on success or a negative error code
[Intel-gfx] ✗ Fi.CI.BAT: failure for benchmarks/gem_wsim: Perturb static_vcs selection across clients
== Series Details == Series: benchmarks/gem_wsim: Perturb static_vcs selection across clients URL : https://patchwork.freedesktop.org/series/60624/ State : failure == Summary == Series 60624 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 05/16] i915/gem_ctx_create: Basic checks for constructor properties
On 08/05/2019 11:09, Chris Wilson wrote:
Check that the extended create interface accepts setparam.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_create.c | 225 ++--
1 file changed, 213 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_ctx_create.c b/tests/i915/gem_ctx_create.c
index a664070db..9b4fddbe7 100644
--- a/tests/i915/gem_ctx_create.c
+++ b/tests/i915/gem_ctx_create.c
@@ -33,6 +33,7 @@
#include
#include "igt_rand.h"
+#include "sw_sync.h"
#define LOCAL_I915_EXEC_BSD_SHIFT (13)
#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
@@ -45,12 +46,33 @@ static unsigned all_nengine;
static unsigned ppgtt_engines[16];
static unsigned ppgtt_nengine;
-static int __gem_context_create_local(int fd, struct drm_i915_gem_context_create *arg)
+static int create_ioctl(int fd, struct drm_i915_gem_context_create *arg)
{
- int ret = 0;
- if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, arg))
- ret = -errno;
- return ret;
+ int err;
+
+ err = 0;
+ if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, arg)) {
+ err = -errno;
+ igt_assert(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static int create_ext_ioctl(int i915,
+ struct drm_i915_gem_context_create_ext *arg)
+{
+ int err;
+
+ err = 0;
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
}
static double elapsed(const struct timespec *start,
@@ -308,6 +330,187 @@ static void maximum(int fd, int ncpus, unsigned mode)
free(contexts);
}
+static void basic_ext_param(int i915)
+{
+ struct drm_i915_gem_context_create_ext_setparam ext = {
+ { .name = I915_CONTEXT_CREATE_EXT_SETPARAM },
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS
+ };
+ struct drm_i915_gem_context_param get;
+
+ igt_require(create_ext_ioctl(i915, ) == 0);
+ gem_context_destroy(i915, create.ctx_id);
+
+ create.extensions = -1ull;
+ igt_assert_eq(create_ext_ioctl(i915, ), -EFAULT);
+
+ create.extensions = to_user_pointer();
+ igt_assert_eq(create_ext_ioctl(i915, ), -EINVAL);
I think this is the unknown param, right?
Need another -EINVAL test for non-zero ext.ctx_id.
Regards,
Tvrtko
+
+ ext.param.param = I915_CONTEXT_PARAM_PRIORITY;
+ if (create_ext_ioctl(i915, ) != -ENODEV) {
+ gem_context_destroy(i915, create.ctx_id);
+
+ ext.base.next_extension = -1ull;
+ igt_assert_eq(create_ext_ioctl(i915, ), -EFAULT);
+ ext.base.next_extension = to_user_pointer();
+ igt_assert_eq(create_ext_ioctl(i915, ), -E2BIG);
+ ext.base.next_extension = 0;
+
+ ext.param.value = 32;
+ igt_assert_eq(create_ext_ioctl(i915, ), 0);
+
+ memset(, 0, sizeof(get));
+ get.ctx_id = create.ctx_id;
+ get.param = I915_CONTEXT_PARAM_PRIORITY;
+ gem_context_get_param(i915, );
+ igt_assert_eq(get.value, ext.param.value);
+
+ gem_context_destroy(i915, create.ctx_id);
+ }
+}
+
+static void check_single_timeline(int i915, uint32_t ctx, int num_engines)
+{
+#define RCS_TIMESTAMP (0x2000 + 0x358)
+ const int gen = intel_gen(intel_get_drm_devid(i915));
+ const int has_64bit_reloc = gen >= 8;
+ struct drm_i915_gem_exec_object2 results = { .handle = gem_create(i915,
4096) };
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ int timeline = sw_sync_timeline_create();
+ uint32_t last, *map;
+
+ {
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ };
+ gem_write(i915, results.handle, 0, , sizeof(bbe));
+ gem_execbuf(i915, );
+ results.flags = EXEC_OBJECT_PINNED;
+ }
+
+ for (int i = 0; i < num_engines; i++) {
+ struct drm_i915_gem_exec_object2 obj[2] = {
+ results, /* write hazard lies! */
+ { .handle = gem_create(i915, 4096) },
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = 2,
+ .rsvd1 = ctx,
+ .rsvd2 = sw_sync_timeline_create_fence(timeline,
num_engines - i),
+ .flags = i | I915_EXEC_FENCE_IN,
+ };
+ uint64_t offset = results.offset + 4 * i;
+
Re: [Intel-gfx] [PATCH i-g-t v3] benchmarks/gem_wsim: Perturb static_vcs selection across clients
Quoting Tvrtko Ursulin (2019-05-14 12:30:10)
>
> On 14/05/2019 12:04, Chris Wilson wrote:
> > Use the client id to alternate the static_vcs balancer (-b context)
> > across clients with the round robin flag (-R) - otherwise all clients
> > end up on vcs0 and do not match the context balancing employed by
> > media-driver.
> >
> > v2: Put it behind the -R flag.
> > v3: Don't skip -R flag for -b context in scripts/media-bench.pl
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > benchmarks/gem_wsim.c | 6 --
> > scripts/media-bench.pl | 2 +-
> > 2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> > index afb9644dd..48568ce40 100644
> > --- a/benchmarks/gem_wsim.c
> > +++ b/benchmarks/gem_wsim.c
> > @@ -939,7 +939,7 @@ alloc_step_batch(struct workload *wrk, struct w_step
> > *w, unsigned int flags)
> > static void
> > prepare_workload(unsigned int id, struct workload *wrk, unsigned int
> > flags)
> > {
> > - unsigned int ctx_vcs = 0;
> > + unsigned int ctx_vcs;
> > int max_ctx = -1;
> > struct w_step *w;
> > int i;
> > @@ -948,8 +948,10 @@ prepare_workload(unsigned int id, struct workload
> > *wrk, unsigned int flags)
> > wrk->prng = rand();
> > wrk->run = true;
> >
> > + ctx_vcs = 0;
> > if (flags & INITVCSRR)
> > - wrk->vcs_rr = id & 1;
> > + ctx_vcs = id & 1;
> > + wrk->vcs_rr = ctx_vcs;
> >
> > if (flags & GLOBAL_BALANCE) {
> > int ret = pthread_mutex_init(>mutex, NULL);
> > diff --git a/scripts/media-bench.pl b/scripts/media-bench.pl
> > index 066b542f9..f1cd59a25 100755
> > --- a/scripts/media-bench.pl
> > +++ b/scripts/media-bench.pl
> > @@ -52,7 +52,7 @@ my @balancers = ( 'rr', 'rand', 'qd', 'qdr', 'qdavg',
> > 'rt', 'rtr', 'rtavg',
> > 'context', 'busy', 'busy-avg' );
> > my %bal_skip_H = ( 'rr' => 1, 'rand' => 1, 'context' => 1, , 'busy' => 1,
> > 'busy-avg' => 1 );
> > -my %bal_skip_R = ( 'context' => 1 );
> > +my %bal_skip_R = ();
> >
> > my @workloads = (
> > 'media_load_balance_17i7.wsim',
> >
>
> This probably means I was thinking -G covers this for -b context, which
> it does. Difference between -R and -G there seems purely in wording
> since clients are initialized sequentially and in deterministic order.
> Hm I guess for heterogeneous clients they would be different. Okay,
> makes sense then.
Hmm, right there is a subtle difference between context_vcs_rr and
ctx_vcs here. If a client creates an odd number of contexts, but doesn't
use all the VCS engines, it is still possible for -G to end up with all
active workloads on VCS0 and -R avoids that.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3] benchmarks/gem_wsim: Perturb static_vcs selection across clients
On 14/05/2019 12:04, Chris Wilson wrote:
Use the client id to alternate the static_vcs balancer (-b context)
across clients with the round robin flag (-R) - otherwise all clients
end up on vcs0 and do not match the context balancing employed by
media-driver.
v2: Put it behind the -R flag.
v3: Don't skip -R flag for -b context in scripts/media-bench.pl
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 6 --
scripts/media-bench.pl | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index afb9644dd..48568ce40 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -939,7 +939,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
static void
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
- unsigned int ctx_vcs = 0;
+ unsigned int ctx_vcs;
int max_ctx = -1;
struct w_step *w;
int i;
@@ -948,8 +948,10 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
wrk->prng = rand();
wrk->run = true;
+ ctx_vcs = 0;
if (flags & INITVCSRR)
- wrk->vcs_rr = id & 1;
+ ctx_vcs = id & 1;
+ wrk->vcs_rr = ctx_vcs;
if (flags & GLOBAL_BALANCE) {
int ret = pthread_mutex_init(>mutex, NULL);
diff --git a/scripts/media-bench.pl b/scripts/media-bench.pl
index 066b542f9..f1cd59a25 100755
--- a/scripts/media-bench.pl
+++ b/scripts/media-bench.pl
@@ -52,7 +52,7 @@ my @balancers = ( 'rr', 'rand', 'qd', 'qdr', 'qdavg', 'rt',
'rtr', 'rtavg',
'context', 'busy', 'busy-avg' );
my %bal_skip_H = ( 'rr' => 1, 'rand' => 1, 'context' => 1, , 'busy' => 1,
'busy-avg' => 1 );
-my %bal_skip_R = ( 'context' => 1 );
+my %bal_skip_R = ();
my @workloads = (
'media_load_balance_17i7.wsim',
This probably means I was thinking -G covers this for -b context, which
it does. Difference between -R and -G there seems purely in wording
since clients are initialized sequentially and in deterministic order.
Hm I guess for heterogeneous clients they would be different. Okay,
makes sense then.
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] ✓ Fi.CI.IGT: success for drm/i915: Add support for asynchronous display power disabling (rev5)
On Tue, May 14, 2019 at 12:06:36AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add support for asynchronous display power disabling (rev5)
> URL : https://patchwork.freedesktop.org/series/60242/
> State : success
Pushed to -dinq with a checkpatch w/s and a docbook fix, thanks for the
reviews and testing!
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6077_full -> Patchwork_13009_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_13009_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@kms_cursor_crc@pipe-b-cursor-suspend}:
> - shard-apl: [PASS][1] -> [DMESG-WARN][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-apl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-apl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_13009_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_tiled_swapping@non-threaded:
> - shard-hsw: [PASS][3] -> [FAIL][4] ([fdo#108686])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-hsw5/igt@gem_tiled_swapp...@non-threaded.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-hsw8/igt@gem_tiled_swapp...@non-threaded.html
>
> * igt@i915_pm_rpm@basic-rte:
> - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-skl5/igt@i915_pm_...@basic-rte.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-skl6/igt@i915_pm_...@basic-rte.html
>
> * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
> - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#105767])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
>
> * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
> - shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#103355])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html
>
> * igt@kms_flip@modeset-vs-vblank-race:
> - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#103060])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-glk6/igt@kms_f...@modeset-vs-vblank-race.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-glk1/igt@kms_f...@modeset-vs-vblank-race.html
>
> * igt@kms_flip@plain-flip-fb-recreate-interruptible:
> - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#100368])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-skl5/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-skl9/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
>
> * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
> - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +7 similar
> issues
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
>
> * igt@kms_psr@psr2_cursor_render:
> - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar
> issue
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-iclb1/igt@kms_psr@psr2_cursor_render.html
>
> * igt@kms_vblank@pipe-c-ts-continuation-suspend:
> - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +1
> similar issue
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6077/shard-apl6/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13009/shard-apl7/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
>
>
> Possible fixes
>
> * igt@i915_pm_rpm@i2c:
> -
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Mon, May 13, 2019 at 11:20 PM Lyude Paul wrote:
>
> Hi-just wanted to give some general thoughts here.
>
> First off I'm 100% behind the epoch idea, that was one of the ideas I had been
> thinking of proposing here in the first place but probably forgot at some
> point down the road.
>
> A couple of other things:
> * I think it would also probably be good to have events for when connectors
>are added or removed from the system (mainly for MST)
Current uevent + userspace looks at the connector list from
drmGetResources? That should be enough to figure this out I think ...
> * Have we considered having any sort of SYNC event, like what evdev uses for
>signaling the end of a frame of events for input devices?
If we go with just 1 event, then that's the natural sync marker
stating "everything we updated for this connector is now updated". For
more global events the global uevent could serve that role (I guess
this is useful for hotpluggin/unpluggin entire mst chains - we might
want to coalesce these indeed).
I also don't think we need to make this an uapi guarantee, just best
effort kernel implementation - userspace needs to always be able to
deal with an event right after the one it's just processing.
-Daniel
>
> On Fri, 2019-05-10 at 14:12 +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > 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.
> >
> > So we just had some discussions over on IRC and at about the hotplug
> > issue and came up with similar ideas:
> > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> >
> > The conclusions of these discussions so far would be to have a more or
> > less fine grain of uevent reporting depending on what happened. The
> > point is that we need to cover different cases:
> > - one or more properties changed;
> > - the connector status changed;
> > - something else about the connector changed (e.g. EDID/modes)
> >
> > For the first case, we can send out:
> > HOTPLUG=1
> > CONNECTOR=
> > PROPERTY=
> >
> > and no reprobe is required.
> >
> > For the second one, something like:
> > HOTPLUG=1
> > CONNECTOR=
> > STATUS=Connected/Disconnected
> >
> > and a connector probe is needed for connected, but not for
> > disconnected;
> >
> > For the third one, we can only indicate the connector:
> > HOTPLUG=1
> > CONNECTOR=
> >
> > and a reprobe of the connector is always needed
> >
> > Then we still have the legacy case:
> > HOTPLUG=1
> >
> > where userspace is expected to reprobe all the connectors.
> >
> > I think this would deserve to be a separate series on its own. So I am
> > proposing to take this one off your plate and come up with another
> > seres implementing this proposal. What do you think?
> >
> > Cheers,
> >
> > Paul
> >
> > > 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
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski wrote: > > Hey, > > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit : > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > 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. > > > > > > > > > > So we just had some discussions over on IRC and at about the hotplug > > > > > issue and came up with similar ideas: > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > The conclusions of these discussions so far would be to have a more or > > > > > less fine grain of uevent reporting depending on what happened. The > > > > > point is that we need to cover different cases: > > > > > - one or more properties changed; > > > > > - the connector status changed; > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > For the first case, we can send out: > > > > > HOTPLUG=1 > > > > > CONNECTOR= > > > > > PROPERTY= > > > > > > > > > > and no reprobe is required. > > > > > > > > > > For the second one, something like: > > > > > HOTPLUG=1 > > > > > CONNECTOR= > > > > > STATUS=Connected/Disconnected > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > disconnected; > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > HOTPLUG=1 > > > > > CONNECTOR= > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > There's no material difference between this one and the previous one. > > > > Plus there's no beenfit in supplying the actual value of the property, > > > > i.e. we can reuse the same PROPERTY= trick. > > > > > > That's the idea, but we need to handle status changes differently than > > > properties, since as far as I know, connected/unconnected status is not > > > exposed as a prop for the connector. > > > > Oops, totally missed that. "Everything is a property" is kinda > > new-ish, at least compared to kms. Kinda tempted to just make status > > into a property. Or another excuse why we should expose the epoch > > property :-) > > Well I think it would make sense anyway, as long as we can make sure it > stays consistent with the one reported in the connector struct. > > > > > Here's why: > > > > - A side effect of forcing a probe on a connector is that you get to > > > > read all the properties, so supplying them is kinda pointless. > > > > > > Agreed, except for the status case where it's useful to know it's a > > > disconnect, because we don't need any probe step in that case. > > > > > > > - You can read STATUS without forcing a reprobe, if you want to avoid > > > > the reprobe for disconnected. I'd kinda not recommend that though, > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e. > > > > dp) reprobing a disconnected output is fast. HDMI is ... less > > > > reasonable unfortunately, but oh well. > > > > > > How would that be retreived then? From the looks of it, that's a > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what > > > does the full reprobe. > > > > drmGetConnector vs drmGetConnectorCurrent. > > Ah right, forgot about that one, thanks. > > > > Not sure what issues could arise in case of disconnect without reprobe > > > -- at least I don't see why userspace should have to do anything in > > > particular except no longer using the connector, even in complex DP MST > > > cases. > > > > connector->status might be a lie without a full reprobe, and wrongly > > indicate that the connector is disconnected while there's still > > something plugged in. I'm not sure we've fixed those bugs by now > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates > > connected, and we can't break this because every intel platform ever > > shipped has a few devices where this is somehow broken, irrespective > > of the sink). > > Mhh either way, I think it's up to the driver to report that and make > it consistent. I think we have poll helpers to make up for cases where > hotplug is not available too. So I'm not sure why a full reprobe would > be needed: drivers just need to do the right thing. > > > > > - There's no way to only reprobe status, you can only ever reprobe > > > > everything with the current ioctl and implementations. Having an > > > > option to reprobe only parts of it doesn't seem useful to me (we need > > > > to read the EDID anyway, and that's the expensive part of reprobing in > >
[Intel-gfx] [PATCH i-g-t v3] benchmarks/gem_wsim: Perturb static_vcs selection across clients
Use the client id to alternate the static_vcs balancer (-b context)
across clients with the round robin flag (-R) - otherwise all clients
end up on vcs0 and do not match the context balancing employed by
media-driver.
v2: Put it behind the -R flag.
v3: Don't skip -R flag for -b context in scripts/media-bench.pl
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 6 --
scripts/media-bench.pl | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index afb9644dd..48568ce40 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -939,7 +939,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
static void
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
- unsigned int ctx_vcs = 0;
+ unsigned int ctx_vcs;
int max_ctx = -1;
struct w_step *w;
int i;
@@ -948,8 +948,10 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
wrk->prng = rand();
wrk->run = true;
+ ctx_vcs = 0;
if (flags & INITVCSRR)
- wrk->vcs_rr = id & 1;
+ ctx_vcs = id & 1;
+ wrk->vcs_rr = ctx_vcs;
if (flags & GLOBAL_BALANCE) {
int ret = pthread_mutex_init(>mutex, NULL);
diff --git a/scripts/media-bench.pl b/scripts/media-bench.pl
index 066b542f9..f1cd59a25 100755
--- a/scripts/media-bench.pl
+++ b/scripts/media-bench.pl
@@ -52,7 +52,7 @@ my @balancers = ( 'rr', 'rand', 'qd', 'qdr', 'qdavg', 'rt',
'rtr', 'rtavg',
'context', 'busy', 'busy-avg' );
my %bal_skip_H = ( 'rr' => 1, 'rand' => 1, 'context' => 1, , 'busy' => 1,
'busy-avg' => 1 );
-my %bal_skip_R = ( 'context' => 1 );
+my %bal_skip_R = ();
my @workloads = (
'media_load_balance_17i7.wsim',
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, May 14, 2019 at 10:18 AM Ser, Simon wrote: > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > On Mon, 13 May 2019 11:34:58 +0200 > > Daniel Vetter wrote: > > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > wrote: > > > > Hi, > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: > > > > > > > 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. > > > > > > > > > > > > So we just had some discussions over on IRC and at about the hotplug > > > > > > issue and came up with similar ideas: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html > > > > > > > > > > > > The conclusions of these discussions so far would be to have a more > > > > > > or > > > > > > less fine grain of uevent reporting depending on what happened. The > > > > > > point is that we need to cover different cases: > > > > > > - one or more properties changed; > > > > > > - the connector status changed; > > > > > > - something else about the connector changed (e.g. EDID/modes) > > > > > > > > > > > > For the first case, we can send out: > > > > > > HOTPLUG=1 > > > > > > CONNECTOR= > > > > > > PROPERTY= > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > For the second one, something like: > > > > > > HOTPLUG=1 > > > > > > CONNECTOR= > > > > > > STATUS=Connected/Disconnected > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > disconnected; > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > HOTPLUG=1 > > > > > > CONNECTOR= > > > > > > > > > > > > and a reprobe of the connector is always needed > > > > > > > > > > There's no material difference between this one and the previous one. > > > > > Plus there's no beenfit in supplying the actual value of the property, > > > > > i.e. we can reuse the same PROPERTY= trick. > > > > > > > > That's the idea, but we need to handle status changes differently than > > > > properties, since as far as I know, connected/unconnected status is not > > > > exposed as a prop for the connector. > > > > > > Oops, totally missed that. "Everything is a property" is kinda > > > new-ish, at least compared to kms. Kinda tempted to just make status > > > into a property. Or another excuse why we should expose the epoch > > > property :-) > > > > Hi Daniel, > > > > just to clarify the first case, specific to one very particular > > property: > > > > With HDCP, there is a property that may change dynamically at runtime > > (the undesired/desired/enabled tristate). Userspace must be notified > > when it changes, I do not want userspace have to poll that property > > with a timer. > > > > When that property alone changes, and userspace is prepared to handle > > that property changing alone, it must not trigger a reprobe of the > > connector. There is no reason to reprobe at that point AFAIU. > > > > How do you ensure that userspace can avoid triggering a reprobe with the > > epoch approach or with any alternate uevent design? > > > > We need an event to userspace that indicates that re-reading the > > properties is enough and reprobe of the connector is not necessary. > > This is complementary to indicating to userspace that only some > > connectors need to be reprobed instead of everything. > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the > reprobing. Would that work? Yes that's the idea, depending upon which property you get you know it's a sink change (needs full reprobe) or something else like hdcp state machinery update. Wrt avoiding the full reprobe for sink changes: I think we should indeed decouple that from the per-connector event for sink changes. That along is a good win already, since you know for which connector you need to call drmGetConnector (which forces the reprobe). It would be nice to only call drmGetConnectorCurrent (avoids the reprobe), but historically speaking every time we tried to rely on this we ended up regretting things. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: More workaround for port F detection due to broken VBTs
On Fri, May 10, 2019 at 05:34:35PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: More workaround for port F detection due to broken VBTs > URL : https://patchwork.freedesktop.org/series/60508/ > State : success Thanks for the testing and reviews, pushed to -dinq with Mika's t-b tag added. > > == Summary == > > CI Bug Log - changes from CI_DRM_6073_full -> Patchwork_13003_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_13003_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@in-flight-10ms: > - shard-glk: ([PASS][1], [PASS][2]) -> [FAIL][3] ([fdo#105957]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-glk2/igt@gem_...@in-flight-10ms.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-glk5/igt@gem_...@in-flight-10ms.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-glk7/igt@gem_...@in-flight-10ms.html > > * igt@i915_pm_rpm@basic-pci-d3-state: > - shard-skl: ([PASS][4], [PASS][5]) -> [INCOMPLETE][6] > ([fdo#107807]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-skl1/igt@i915_pm_...@basic-pci-d3-state.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-skl2/igt@i915_pm_...@basic-pci-d3-state.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-skl2/igt@i915_pm_...@basic-pci-d3-state.html > > * igt@i915_pm_rpm@i2c: > - shard-iclb: [PASS][7] -> [DMESG-WARN][8] ([fdo#109982]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-iclb5/igt@i915_pm_...@i2c.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-iclb2/igt@i915_pm_...@i2c.html > > * igt@i915_pm_rpm@legacy-planes-dpms: > - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#107807]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-skl5/igt@i915_pm_...@legacy-planes-dpms.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-skl1/igt@i915_pm_...@legacy-planes-dpms.html > > * igt@kms_dp_dsc@basic-dsc-enable-edp: > - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109349]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-iclb7/igt@kms_dp_...@basic-dsc-enable-edp.html > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > - shard-glk: ([PASS][13], [PASS][14]) -> [FAIL][15] > ([fdo#105363]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-glk3/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-glk7/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-glk7/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > * igt@kms_flip@2x-flip-vs-modeset-vs-hang: > - shard-hsw: ([PASS][16], [PASS][17]) -> [INCOMPLETE][18] > ([fdo#103540]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-hsw2/igt@kms_f...@2x-flip-vs-modeset-vs-hang.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-hsw1/igt@kms_f...@2x-flip-vs-modeset-vs-hang.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-hsw7/igt@kms_f...@2x-flip-vs-modeset-vs-hang.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-skl: ([PASS][19], [PASS][20]) -> [FAIL][21] > ([fdo#105363]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render: > - shard-iclb: [PASS][22] -> [FAIL][23] ([fdo#103167]) +1 similar > issue >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6073/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-render.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13003/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-render.html > > * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: > - shard-iclb: ([PASS][24], [PASS][25]) -> [FAIL][26] > ([fdo#103167]) +3 similar issues >[24]: >
[Intel-gfx] [PATCH i-g-t v2] benchmarks/gem_wsim: Perturb static_vcs selection across clients
Use the client id to alternate the static_vcs balancer (-b context)
across clients with the round robin flag (-R) - otherwise all clients
end up on vcs0 and do not match the context balancing employed by
media-driver.
v2: Put it behind the -R flag.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index afb9644dd..48568ce40 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -939,7 +939,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
static void
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
- unsigned int ctx_vcs = 0;
+ unsigned int ctx_vcs;
int max_ctx = -1;
struct w_step *w;
int i;
@@ -948,8 +948,10 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
wrk->prng = rand();
wrk->run = true;
+ ctx_vcs = 0;
if (flags & INITVCSRR)
- wrk->vcs_rr = id & 1;
+ ctx_vcs = id & 1;
+ wrk->vcs_rr = ctx_vcs;
if (flags & GLOBAL_BALANCE) {
int ret = pthread_mutex_init(>mutex, NULL);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: adding state checker for gamma lut values (rev8)
== Series Details ==
Series: drm/i915: adding state checker for gamma lut values (rev8)
URL : https://patchwork.freedesktop.org/series/58039/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6078 -> Patchwork_13014
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/
Known issues
Here are the changes found in Patchwork_13014 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_basic@basic-bsd:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/fi-apl-guc/igt@gem_exec_ba...@basic-bsd.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/fi-apl-guc/igt@gem_exec_ba...@basic-bsd.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_execlists:
- fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927] /
[fdo#109720])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/fi-apl-guc/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/fi-apl-guc/igt@i915_selftest@live_execlists.html
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.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_6078/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
- fi-apl-guc: [DMESG-FAIL][11] ([fdo#110620]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6078/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/fi-apl-guc/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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#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#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
Participating hosts (54 -> 46)
--
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_6078 -> Patchwork_13014
CI_DRM_6078: c8c778558fd52abd3303d8ea324df788062adc97 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4984: 66c887d2f7a92a4a97acd9611d5342afc5d4f815 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13014: b8022e46e5bbcdaf0c1bd8337420ec3c8995fe9e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b8022e46e5bb FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
ea0a00bb8393 drm/i915: Extract ilk_read_luts()
7510ed3f9d11 drm/i915: Extract ivb_read_luts()
2eebe8f941ad drm/i915: Extract bdw_read_luts()
7227ab5cc441 drm/i915: Extract glk_read_luts()
b9f3d03fb0dc drm/i915: Extract icl_read_luts()
e4c90e367a15 drm/i915: Extract i965_read_luts()
308e9522b887 drm/i915: Extract chv_read_luts()
2eedef369a97 drm/i915: Extract i9xx_read_luts()
1eec6d06f200 drm/i915: Add intel_color_lut_equal() to compare hw and sw
gamma/degamma lut values
316533acb64b drm/i915: Enable intel_color_get_config()
12495d94dac5 drm/i915: Introduce vfunc read_luts() to create hw lut
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13014/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] benchmarks/gem_wsim: Perturb static_vcs selection across clients
On 14/05/2019 11:05, Chris Wilson wrote:
Use the client id to alternate the static_vcs balancer (-b context)
across clients - otherwise all clients end up on vcs0 and do not match
the context balancing employed by media-driver.
This may want to be behind the -R flag, but I felt it was a fundamental
property of static context balancing that to keep it disabled by default
causes unfair comparisons and poor workload scheduling, defeating the
purpose of testing.
I see your reasoning but it also completely matches the design of other
balancers to keep it under control of -R switch. It can also already be
achieved with the -G switch. Which is perhaps a bit confusing.. Having
both would still make sense I think. (-G gives out engines rr to
contexts sequentially across all clients, -R start each client contexts
by rr.)
But I wouldn't enable it unconditionally. Because consider another
balancer like rr and a two same workload instances of a long context
followed by short second context batch. If suffers the same problem of
poor scheduling until -R is added.
So I think we want to have the two balancers compatible in behaviour in
this respect.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index afb9644dd..8c7e30eb4 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -939,7 +939,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
static void
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
- unsigned int ctx_vcs = 0;
+ unsigned int ctx_vcs = id & 1;
Therefore I think "ctx_vcs = (flags & INITVCSRR) ? id & 1 : 0" here.
int max_ctx = -1;
struct w_step *w;
int i;
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: adding state checker for gamma lut values (rev8)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev8) URL : https://patchwork.freedesktop.org/series/58039/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Introduce vfunc read_luts() to create hw lut Okay! Commit: drm/i915: Enable intel_color_get_config() Okay! Commit: drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values Okay! Commit: drm/i915: Extract i9xx_read_luts() +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1352:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1392:6: warning: symbol 'i9xx_read_luts' was not declared. Should it be static? Commit: drm/i915: Extract chv_read_luts() Okay! Commit: drm/i915: Extract i965_read_luts() Okay! Commit: drm/i915: Extract icl_read_luts() Okay! Commit: drm/i915: Extract glk_read_luts() Okay! Commit: drm/i915: Extract bdw_read_luts() Okay! Commit: drm/i915: Extract ivb_read_luts() Okay! Commit: drm/i915: Extract ilk_read_luts() Okay! Commit: FOR_TESTING_ONLY: Print rgb values of hw and sw blobs 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 drm/i915: adding state checker for gamma lut values (rev8)
== Series Details ==
Series: drm/i915: adding state checker for gamma lut values (rev8)
URL : https://patchwork.freedesktop.org/series/58039/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
12495d94dac5 drm/i915: Introduce vfunc read_luts() to create hw lut
316533acb64b drm/i915: Enable intel_color_get_config()
1eec6d06f200 drm/i915: Add intel_color_lut_equal() to compare hw and sw
gamma/degamma lut values
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
-Corrected smatch warn "variable dereferenced before check" [Dan Carpenter]
-:85: ERROR:CODE_INDENT: code indent should use tabs where possible
#85: FILE: drivers/gpu/drm/i915/intel_color.c:1304:
+^I struct drm_color_lut *hw_lut, u32 err)$
-:85: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#85: FILE: drivers/gpu/drm/i915/intel_color.c:1304:
+static inline bool err_check(struct drm_color_lut *sw_lut,
+struct drm_color_lut *hw_lut, u32 err)
-:87: WARNING:TABSTOP: Statements should start on a tabstop
#87: FILE: drivers/gpu/drm/i915/intel_color.c:1306:
+return ((abs((long)hw_lut->red - sw_lut->red)) <= err) &&
-:88: ERROR:CODE_INDENT: code indent should use tabs where possible
#88: FILE: drivers/gpu/drm/i915/intel_color.c:1307:
+^I((abs((long)hw_lut->blue - sw_lut->blue)) <= err) &&$
-:89: ERROR:CODE_INDENT: code indent should use tabs where possible
#89: FILE: drivers/gpu/drm/i915/intel_color.c:1308:
+^I((abs((long)hw_lut->green - sw_lut->green)) <= err);$
-:120: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 17)
#120: FILE: drivers/gpu/drm/i915/intel_color.c:1339:
+ for (i = 0; i < sw_lut_size; i++) {
+if (!err_check(_lut[i], _lut[i], err))
-:121: WARNING:TABSTOP: Statements should start on a tabstop
#121: FILE: drivers/gpu/drm/i915/intel_color.c:1340:
+if (!err_check(_lut[i], _lut[i], err))
-:167: WARNING:LONG_LINE: line over 100 characters
#167: FILE: drivers/gpu/drm/i915/intel_display.c:11608:
+ pipe_config->cgm_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:167: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#167: FILE: drivers/gpu/drm/i915/intel_display.c:11608:
+ DRM_DEBUG_KMS("cgm_mode:%d gamma_mode:%d gamma_enable:%d
csc_enable:%d\n",
+ pipe_config->cgm_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:171: WARNING:LONG_LINE: line over 100 characters
#171: FILE: drivers/gpu/drm/i915/intel_display.c:11612:
+ pipe_config->csc_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:171: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#171: FILE: drivers/gpu/drm/i915/intel_display.c:11612:
+ DRM_DEBUG_KMS("csc_mode:%d gamma_mode:%d gamma_enable:%d
csc_enable:%d\n",
+ pipe_config->csc_mode, pipe_config->gamma_mode,
pipe_config->gamma_enable,
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#189: FILE: drivers/gpu/drm/i915/intel_display.c:12144:
+#define PIPE_CONF_CHECK_COLOR_LUT(name, bit_precision) do { \
+ if (!intel_color_lut_equal(current_config->name, \
+ pipe_config->name, bit_precision)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+} while (0)
-:189: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as
'(name)' to avoid precedence issues
#189: FILE: drivers/gpu/drm/i915/intel_display.c:12144:
+#define PIPE_CONF_CHECK_COLOR_LUT(name, bit_precision) do { \
+ if (!intel_color_lut_equal(current_config->name, \
+ pipe_config->name, bit_precision)) { \
+ pipe_config_err(adjust, __stringify(name), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+} while (0)
total: 3 errors, 6 warnings, 5 checks, 173 lines checked
2eedef369a97 drm/i915: Extract i9xx_read_luts()
-:13: WARNING:TYPO_SPELLING: 'withing' may be misspelled - perhaps 'within'?
#13:
v5: -Returned blob instead of assigning it internally withing the
-:79: WARNING:LONG_LINE: line over 100 characters
#79: FILE: drivers/gpu/drm/i915/intel_color.c:1384:
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val), 8);
-:80: WARNING:LONG_LINE: line over 100 characters
#80: FILE: drivers/gpu/drm/i915/intel_color.c:1385:
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
-:81: WARNING:LONG_LINE: line over 100 characters
#81: FILE: drivers/gpu/drm/i915/intel_color.c:1386:
+
Re: [Intel-gfx] [v9 06/13] drm/i915: Write HDR infoframe and send to panel
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 14, 2019 1:06 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; jo...@kwiboo.se; emil.l.veli...@gmail.com;
>seanp...@chromium.org; Syrjala, Ville ; Lankhorst,
>Maarten
>
>Subject: Re: [v9 06/13] drm/i915: Write HDR infoframe and send to panel
>
>On Thu, May 09, 2019 at 12:08:46AM +0530, Uma Shankar wrote:
>> Enable writing of HDR metadata infoframe to panel.
>> The data will be provid by usersapace compositors, based on blending
>> policies and passsed to driver through a blob property.
>>
>> v2: Rebase
>>
>> v3: Fixed a warning message
>>
>> v4: Addressed Shashank's review comments
>>
>> v5: Rebase. Added infoframe calculation in compute config.
>>
>> v6: Addressed Shashank's review comment. Added HDR metadata support
>> from GEN10 onwards as per Shashank's recommendation.
>>
>> v7: Addressed Shashank's review comments
>>
>> v8: Added Shashank's RB.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 48
>> +++
>> 2 files changed, 49 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 247893e..bc32b2c 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -910,6 +910,7 @@ struct intel_crtc_state {
>> union hdmi_infoframe avi;
>> union hdmi_infoframe spd;
>> union hdmi_infoframe hdmi;
>> +union hdmi_infoframe drm;
>> } infoframes;
>>
>> /* HDMI scrambling status */
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 92597d8..980900b 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -573,6 +573,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
>*encoder,
>> HDMI_INFOFRAME_TYPE_AVI,
>> HDMI_INFOFRAME_TYPE_SPD,
>> HDMI_INFOFRAME_TYPE_VENDOR,
>> +HDMI_INFOFRAME_TYPE_DRM,
>> };
>>
>> u32 intel_hdmi_infoframe_enable(unsigned int type) @@ -795,6 +796,30
>> @@ void intel_read_infoframe(struct intel_encoder *encoder,
>> return true;
>> }
>>
>> +static bool
>> +intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
>> + struct intel_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state) {
>> +struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
>> +struct hdr_output_metadata *hdr_metadata;
>> +int ret;
>
>Missing has_infoframes check.
Ok, will add this.
>> +
>> +hdr_metadata = (struct hdr_output_metadata *)
>
>Pointless cast?
Yeah, will remove this.
>
>> +conn_state->hdr_output_metadata->data;
>
>NULL pointer deref? Hmm, how does this pass CI?
Actually this check is added in a later patch in series (patch 9), will move
the check
here to avoid any bisect issues.
>
>> +
>> +ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
>> +if (ret < 0) {
>> +DRM_ERROR("couldn't set HDR metadata in infoframe\n");
>> +return false;
>> +}
>> +
>> +crtc_state->infoframes.enable |=
>> +intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
>
>Everyone else sets this before populating the infoframe.
Will move this up.
>Missing the whatever_infoframe_check() call here.
Sure, will add the check.
>> +
>> +return true;
>> +}
>> +
>> static void g4x_set_infoframes(struct intel_encoder *encoder,
>> bool enable,
>> const struct intel_crtc_state *crtc_state, @@
>> -1180,6
>> +1205,16 @@ static void hsw_set_infoframes(struct intel_encoder *encoder,
>> intel_write_infoframe(encoder, crtc_state,
>>HDMI_INFOFRAME_TYPE_VENDOR,
>>_state->infoframes.hdmi);
>> +
>> +/*
>> + * Support HDR Metadata from Gen10 onwards
>> + * ToDo: Gen9 also can support HDR with LSPCON.
>> + * Support for the same to be enabled later.
>> + */
>> +if (INTEL_GEN(dev_priv) >= 10)
>
>Missing glk. Actually this check can be removed entirely since
>intel_write_infoframe() already checks infoframes.enable.
Yeah right, will drop this check altogether.
>> +intel_write_infoframe(encoder, crtc_state,
>> + HDMI_INFOFRAME_TYPE_DRM,
>> + _state->infoframes.drm);
>> }
>>
>> void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
>> enable) @@ -2386,6 +2421,19 @@ int intel_hdmi_compute_config(struct
>intel_encoder *encoder,
>> return -EINVAL;
>> }
>>
>> +/*
>> + * Support HDR Metadata from Gen10 onwards
>
>This is not
Re: [Intel-gfx] [PATCH i-g-t 05/16] i915/gem_ctx_create: Basic checks for constructor properties
On 08/05/2019 11:09, Chris Wilson wrote:
Check that the extended create interface accepts setparam.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_create.c | 225 ++--
1 file changed, 213 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_ctx_create.c b/tests/i915/gem_ctx_create.c
index a664070db..9b4fddbe7 100644
--- a/tests/i915/gem_ctx_create.c
+++ b/tests/i915/gem_ctx_create.c
@@ -33,6 +33,7 @@
#include
#include "igt_rand.h"
+#include "sw_sync.h"
#define LOCAL_I915_EXEC_BSD_SHIFT (13)
#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
@@ -45,12 +46,33 @@ static unsigned all_nengine;
static unsigned ppgtt_engines[16];
static unsigned ppgtt_nengine;
-static int __gem_context_create_local(int fd, struct drm_i915_gem_context_create *arg)
+static int create_ioctl(int fd, struct drm_i915_gem_context_create *arg)
{
- int ret = 0;
- if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, arg))
- ret = -errno;
- return ret;
+ int err;
+
+ err = 0;
+ if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, arg)) {
+ err = -errno;
+ igt_assert(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static int create_ext_ioctl(int i915,
+ struct drm_i915_gem_context_create_ext *arg)
+{
+ int err;
+
+ err = 0;
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
}
static double elapsed(const struct timespec *start,
@@ -308,6 +330,187 @@ static void maximum(int fd, int ncpus, unsigned mode)
free(contexts);
}
+static void basic_ext_param(int i915)
+{
+ struct drm_i915_gem_context_create_ext_setparam ext = {
+ { .name = I915_CONTEXT_CREATE_EXT_SETPARAM },
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS
+ };
+ struct drm_i915_gem_context_param get;
+
+ igt_require(create_ext_ioctl(i915, ) == 0);
+ gem_context_destroy(i915, create.ctx_id);
+
+ create.extensions = -1ull;
+ igt_assert_eq(create_ext_ioctl(i915, ), -EFAULT);
+
+ create.extensions = to_user_pointer();
+ igt_assert_eq(create_ext_ioctl(i915, ), -EINVAL);
+
+ ext.param.param = I915_CONTEXT_PARAM_PRIORITY;
+ if (create_ext_ioctl(i915, ) != -ENODEV) {
+ gem_context_destroy(i915, create.ctx_id);
+
+ ext.base.next_extension = -1ull;
+ igt_assert_eq(create_ext_ioctl(i915, ), -EFAULT);
+ ext.base.next_extension = to_user_pointer();
+ igt_assert_eq(create_ext_ioctl(i915, ), -E2BIG);
+ ext.base.next_extension = 0;
+
+ ext.param.value = 32;
+ igt_assert_eq(create_ext_ioctl(i915, ), 0);
+
+ memset(, 0, sizeof(get));
+ get.ctx_id = create.ctx_id;
+ get.param = I915_CONTEXT_PARAM_PRIORITY;
+ gem_context_get_param(i915, );
+ igt_assert_eq(get.value, ext.param.value);
+
+ gem_context_destroy(i915, create.ctx_id);
+ }
+}
+
+static void check_single_timeline(int i915, uint32_t ctx, int num_engines)
+{
+#define RCS_TIMESTAMP (0x2000 + 0x358)
+ const int gen = intel_gen(intel_get_drm_devid(i915));
+ const int has_64bit_reloc = gen >= 8;
+ struct drm_i915_gem_exec_object2 results = { .handle = gem_create(i915,
4096) };
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ int timeline = sw_sync_timeline_create();
+ uint32_t last, *map;
+
+ {
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ };
+ gem_write(i915, results.handle, 0, , sizeof(bbe));
+ gem_execbuf(i915, );
+ results.flags = EXEC_OBJECT_PINNED;
+ }
+
+ for (int i = 0; i < num_engines; i++) {
+ struct drm_i915_gem_exec_object2 obj[2] = {
+ results, /* write hazard lies! */
+ { .handle = gem_create(i915, 4096) },
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = 2,
+ .rsvd1 = ctx,
+ .rsvd2 = sw_sync_timeline_create_fence(timeline,
num_engines - i),
+ .flags = i | I915_EXEC_FENCE_IN,
+ };
+ uint64_t offset = results.offset + 4 * i;
+ uint32_t *cs;
+ int j = 0;
+
+ cs = gem_mmap__cpu(i915, obj[1].handle, 0, 4096,
[Intel-gfx] [PATCH i-g-t] benchmarks/gem_wsim: Perturb static_vcs selection across clients
Use the client id to alternate the static_vcs balancer (-b context)
across clients - otherwise all clients end up on vcs0 and do not match
the context balancing employed by media-driver.
This may want to be behind the -R flag, but I felt it was a fundamental
property of static context balancing that to keep it disabled by default
causes unfair comparisons and poor workload scheduling, defeating the
purpose of testing.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index afb9644dd..8c7e30eb4 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -939,7 +939,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
static void
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
- unsigned int ctx_vcs = 0;
+ unsigned int ctx_vcs = id & 1;
int max_ctx = -1;
struct w_step *w;
int i;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v9 03/13] drm: Parse HDR metadata info from EDID
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 14, 2019 12:49 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; jo...@kwiboo.se; emil.l.veli...@gmail.com;
>seanp...@chromium.org; Syrjala, Ville ; Lankhorst,
>Maarten
>
>Subject: Re: [v9 03/13] drm: Parse HDR metadata info from EDID
>
>On Thu, May 09, 2019 at 12:08:43AM +0530, 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 852bdd8..fe2c29b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2852,6 +2852,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_BLOCK 0x6
>> #define USE_EXTENDED_TAG 0x07
>> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>> #define EXT_VIDEO_DATA_BLOCK_4200x0E
>> @@ -3599,6 +3600,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];
>> @@ -3834,6 +3841,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;
>> +
>> +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);
>
>Length checks missing for this stuff.
The above 2 are mandatory bytes , so this will always be there in this block.
Byte 5 to 7 are optional and depends on length field. So we should not need a
length
check here for above 2 fields. Hope my understanding is right.
>> +
>> +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];
>
>All the length checks seem to be off by one due to cea_db_payload_len_ext().
>I think just dropping cea_db_payload_len_ext() would make things better since
>a)
>nothing else has that, b) db still points at the start of the whole data block
>instead of
>the payload.
The length field adds/includes the extended tag byte while reporting the size
of block. So we need to
remove 1 byte to get the correct size of data. A value of n = 3 means bytes 5
to 7 are not present.
>The while payload vs. block length thing is already confusing anyway.
>I have a feeling we should replace cea_db_payload_len() with something that
>returns
>the length of the whole data block. That way the db[index] vs. length checks
>would
>start to make some sense to the casual reader.
I hope with above understanding, in db[index], index just tells the byte number
for a particular
field which matches exactly to spec offsets.
Regards,
Uma Shankar
>
>> +}
>> +
>> static void
>> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8
>> *db) { @@ -4461,6 +4511,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))
>> +
[Intel-gfx] [v6][PATCH 10/12] drm/i915: Extract ivb_read_luts()
In this patch, gamma and degamma hw blobs are created for IVB.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed ivb_get_color_config() to ivb_read_luts() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 50 --
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index f3df351..1448f4b 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1534,6 +1534,51 @@ static void bdw_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
}
+static struct drm_property_blob *
+ivb_read_lut_10(struct intel_crtc_state *crtc_state,
+ u32 prec_index)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int hw_lut_size = ivb_lut_10_size(prec_index);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) *
hw_lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < hw_lut_size; i++) {
+ I915_WRITE(PREC_PAL_INDEX(pipe), prec_index++);
+ val = I915_READ(PREC_PAL_DATA(pipe));
+
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_RED_MASK, val), 10);
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_GREEN_MASK, val), 10);
+ blob_data[i].blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_BLUE_MASK, val), 10);
+ }
+
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+
+ return blob;
+}
+
+static void ivb_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
+ crtc_state->base.gamma_lut = ivb_read_lut_10(crtc_state,
PAL_PREC_SPLIT_MODE | PAL_PREC_INDEX_VALUE(512));
+ else
+ crtc_state->base.gamma_lut = ivb_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
+
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1584,9 +1629,10 @@ void intel_color_init(struct intel_crtc *crtc)
} else if (INTEL_GEN(dev_priv) >= 8) {
dev_priv->display.load_luts = bdw_load_luts;
dev_priv->display.read_luts = bdw_read_luts;
- }
- else if (INTEL_GEN(dev_priv) >= 7)
+ } else if (INTEL_GEN(dev_priv) >= 7) {
dev_priv->display.load_luts = ivb_load_luts;
+ dev_priv->display.read_luts = ivb_read_luts;
+ }
else
dev_priv->display.load_luts = ilk_load_luts;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 08/12] drm/i915: Extract glk_read_luts()
In this patch, gamma and degamma hw blobs are created for GLK.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed glk_get_color_config() to glk_read_luts() [Ville]
-Added degamma validation [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 43723e2..400ec94 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1516,6 +1516,14 @@ static void icl_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
}
+static void glk_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1560,9 +1568,10 @@ void intel_color_init(struct intel_crtc *crtc)
if (INTEL_GEN(dev_priv) >= 11) {
dev_priv->display.load_luts = icl_load_luts;
dev_priv->display.read_luts = icl_read_luts;
- }
- else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
dev_priv->display.load_luts = glk_load_luts;
+ dev_priv->display.read_luts = glk_read_luts;
+ }
else if (INTEL_GEN(dev_priv) >= 8)
dev_priv->display.load_luts = bdw_load_luts;
else if (INTEL_GEN(dev_priv) >= 7)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 12/12] FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6bbc99a..3d9e375 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1303,6 +1303,8 @@ void intel_color_get_bit_precision(struct
intel_crtc_state *crtc_state, int *bp_
static inline bool err_check(struct drm_color_lut *sw_lut,
struct drm_color_lut *hw_lut, u32 err)
{
+ DRM_DEBUG_KMS("hw_lut->red=0x%x sw_lut->red=0x%x hw_lut->blue=0x%x
sw_lut->blue=0x%x hw_lut->green=0x%x sw_lut->green=0x%x", hw_lut->red,
sw_lut->red, hw_lut->blue, sw_lut->blue, hw_lut->green, sw_lut->green);
+
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);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 07/12] drm/i915: Extract icl_read_luts()
In this patch, gamma hw blobs are created for ICL.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed icl_get_color_config() to icl_read_luts() [Ville]
-Renamed bdw_get_gamma_config() to bdw_read_lut_10() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_color.c | 49 +-
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7988fa5..249296b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10124,6 +10124,9 @@ enum skl_power_gate {
#define _PAL_PREC_DATA_A 0x4A404
#define _PAL_PREC_DATA_B 0x4AC04
#define _PAL_PREC_DATA_C 0x4B404
+#define PREC_PAL_DATA_RED_MASK REG_GENMASK(29, 20)
+#define PREC_PAL_DATA_GREEN_MASK REG_GENMASK(19, 10)
+#define PREC_PAL_DATA_BLUE_MASK REG_GENMASK(9, 0)
#define _PAL_PREC_GC_MAX_A 0x4A410
#define _PAL_PREC_GC_MAX_B 0x4AC10
#define _PAL_PREC_GC_MAX_C 0x4B410
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 121b2c4..43723e2 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1471,6 +1471,51 @@ static void i965_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut =
i965_read_gamma_lut_10p6(crtc_state);
}
+static struct drm_property_blob *
+bdw_read_lut_10(struct intel_crtc_state *crtc_state,
+ u32 prec_index)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int hw_lut_size = ivb_lut_10_size(prec_index);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ I915_WRITE(PREC_PAL_INDEX(pipe), prec_index |
+ PAL_PREC_AUTO_INCREMENT);
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) *
hw_lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < hw_lut_size; i++) {
+ val = I915_READ(PREC_PAL_DATA(pipe));
+
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_RED_MASK, val), 10);
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_GREEN_MASK, val), 10);
+ blob_data[i].blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_BLUE_MASK, val), 10);
+ }
+
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+
+ return blob;
+}
+
+static void icl_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) ==
+ GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1512,8 +1557,10 @@ void intel_color_init(struct intel_crtc *crtc)
else
dev_priv->display.color_commit = ilk_color_commit;
- if (INTEL_GEN(dev_priv) >= 11)
+ if (INTEL_GEN(dev_priv) >= 11) {
dev_priv->display.load_luts = icl_load_luts;
+ dev_priv->display.read_luts = icl_read_luts;
+ }
else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
dev_priv->display.load_luts = glk_load_luts;
else if (INTEL_GEN(dev_priv) >= 8)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 06/12] drm/i915: Extract i965_read_luts()
In this patch, hw gamma blob is created for i965.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally
within the function [Ville]
-Renamed i965_get_color_config() to i965_read_lut() [Ville]
-Renamed i965_get_gamma_config_10p6() to i965_read_gamma_lut_10p6() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_color.c | 39 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b58c66d..7988fa5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3584,6 +3584,9 @@ enum i915_power_well_id {
#define _PALETTE_A 0xa000
#define _PALETTE_B 0xa800
#define _CHV_PALETTE_C 0xc000
+#define PALETTE_RED_MASKREG_GENMASK(23, 16)
+#define PALETTE_GREEN_MASK REG_GENMASK(15, 8)
+#define PALETTE_BLUE_MASK REG_GENMASK(7, 0)
#define PALETTE(pipe, i) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \
_PICK((pipe), _PALETTE_A, \
_PALETTE_B, _CHV_PALETTE_C) + \
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index a7a0b74..121b2c4 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1433,6 +1433,44 @@ static void chv_read_luts(struct intel_crtc_state
*crtc_state)
}
+static struct drm_property_blob *
+i965_read_gamma_lut_10p6(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);
+ u32 i, val1, val2, lut_size =
INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < lut_size - 1; i++) {
+ val1 = I915_READ(PALETTE(pipe, 2 * i + 0));
+ val2 = I915_READ(PALETTE(pipe, 2 * i + 1));
+
+ blob_data[i].red = REG_FIELD_GET(PALETTE_RED_MASK, val1) << 8 |
REG_FIELD_GET(PALETTE_RED_MASK, val2);
+ blob_data[i].green = REG_FIELD_GET(PALETTE_GREEN_MASK, val1) <<
8 | REG_FIELD_GET(PALETTE_GREEN_MASK, val2);
+ blob_data[i].blue = REG_FIELD_GET(PALETTE_BLUE_MASK, val1) << 8
| REG_FIELD_GET(PALETTE_BLUE_MASK, val2) ;
+ }
+
+ return blob;
+}
+
+static void i965_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut =
i965_read_gamma_lut_10p6(crtc_state);
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1450,6 +1488,7 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.color_check = i9xx_color_check;
dev_priv->display.color_commit = i9xx_color_commit;
dev_priv->display.load_luts = i965_load_luts;
+ dev_priv->display.read_luts = i965_read_luts;
} else {
dev_priv->display.color_check = i9xx_color_check;
dev_priv->display.color_commit = i9xx_color_commit;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 11/12] drm/i915: Extract ilk_read_luts()
In this patch, hw gamma blob is created for ILK.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed ilk_get_color_config() to ilk_read_luts() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_color.c | 42 --
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 249296b..d5ff323 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7189,6 +7189,9 @@ enum {
/* ilk/snb precision palette */
#define _PREC_PALETTE_A 0x4b000
#define _PREC_PALETTE_B 0x4c000
+#define PREC_PALETTE_RED_MASK REG_GENMASK(29, 20)
+#define PREC_PALETTE_GREEN_MASK REG_GENMASK(19, 10)
+#define PREC_PALETTE_BLUE_MASK REG_GENMASK(9, 0)
#define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A,
_PREC_PALETTE_B) + (i) * 4)
#define _PREC_PIPEAGCMAX 0x4d000
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 1448f4b..6bbc99a 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1579,6 +1579,43 @@ static void ivb_read_luts(struct intel_crtc_state
*crtc_state)
}
+static struct drm_property_blob *
+ilk_read_gamma_lut(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);
+ u32 i, val, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < lut_size - 1; i++) {
+ val = I915_READ(PREC_PALETTE(pipe, i));
+
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_RED_MASK, val), 10);
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_GREEN_MASK, val), 10);
+ blob_data[i].blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_BLUE_MASK, val), 10);
+ }
+
+ return blob;
+}
+
+static void ilk_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut = ilk_read_gamma_lut(crtc_state);
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1632,9 +1669,10 @@ void intel_color_init(struct intel_crtc *crtc)
} else if (INTEL_GEN(dev_priv) >= 7) {
dev_priv->display.load_luts = ivb_load_luts;
dev_priv->display.read_luts = ivb_read_luts;
- }
- else
+ } else {
dev_priv->display.load_luts = ilk_load_luts;
+ dev_priv->display.read_luts = ilk_read_luts;
+ }
}
drm_crtc_enable_color_mgmt(>base,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 05/12] drm/i915: Extract chv_read_luts()
In this patch, hw gamma and degamma blob is created for
cherryview.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed function cherryview_get_color_config() to chv_read_luts()
-Renamed cherryview_get_gamma_config() to chv_read_cgm_gamma_lut() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_color.c | 40 ++
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d8475f2..b58c66d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10160,6 +10160,9 @@ enum skl_power_gate {
#define CGM_PIPE_MODE_GAMMA (1 << 2)
#define CGM_PIPE_MODE_CSC(1 << 1)
#define CGM_PIPE_MODE_DEGAMMA(1 << 0)
+#define CGM_PIPE_GAMMA_RED_MASK REG_GENMASK(9, 0)
+#define CGM_PIPE_GAMMA_GREEN_MASK REG_GENMASK(25, 16)
+#define CGM_PIPE_GAMMA_BLUE_MASK REG_GENMASK(9, 0)
#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 3396d35..a7a0b74 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1394,6 +1394,45 @@ void i9xx_read_luts(struct intel_crtc_state *crtc_state)
crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
}
+static struct drm_property_blob *
+chv_read_cgm_gamma_lut(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);
+ u32 i, val, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < lut_size; i++) {
+ val = I915_READ(CGM_PIPE_GAMMA(pipe, i, 0));
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, val), 10);
+ blob_data[i].blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, val), 10);
+
+ val = I915_READ(CGM_PIPE_GAMMA(pipe, i, 1));
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, val), 10);
+ }
+
+ return blob;
+}
+
+static void chv_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut = chv_read_cgm_gamma_lut(crtc_state);
+
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1406,6 +1445,7 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.color_check = chv_color_check;
dev_priv->display.color_commit = i9xx_color_commit;
dev_priv->display.load_luts = chv_load_luts;
+ dev_priv->display.read_luts = chv_read_luts;
} else if (INTEL_GEN(dev_priv) >= 4) {
dev_priv->display.color_check = i9xx_color_check;
dev_priv->display.color_commit = i9xx_color_commit;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 09/12] drm/i915: Extract bdw_read_luts()
In this patch, gamma and degamma hw blobs are created for BDW.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed bdw_get_color_config() to bdw_read_luts() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 400ec94..f3df351 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1524,6 +1524,16 @@ static void glk_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
}
+static void bdw_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
+ crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(512));
+ else
+ crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1571,9 +1581,10 @@ void intel_color_init(struct intel_crtc *crtc)
} else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
dev_priv->display.load_luts = glk_load_luts;
dev_priv->display.read_luts = glk_read_luts;
- }
- else if (INTEL_GEN(dev_priv) >= 8)
+ } else if (INTEL_GEN(dev_priv) >= 8) {
dev_priv->display.load_luts = bdw_load_luts;
+ dev_priv->display.read_luts = bdw_read_luts;
+ }
else if (INTEL_GEN(dev_priv) >= 7)
dev_priv->display.load_luts = ivb_load_luts;
else
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 01/12] drm/i915: Introduce vfunc read_luts() to create hw lut
In this patch, a vfunc read_luts() is introduced to create a hw lut
i.e. lut having values read from gamma/degamma registers which will
later be used to compare with sw lut to validate gamma/degamma lut values.
v3: -Rebase
v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
-Wrapped get_color_config() [Jani]
v5: -Renamed intel_color_get_config() to intel_color_read_luts()
-Renamed get_color_config to read_luts
v6: -Renamed intel_color_read_luts() back to intel_color_get_config()
[Jani and Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/intel_color.c | 8
drivers/gpu/drm/i915/intel_color.h | 1 +
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d025780..6343e70 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -343,6 +343,7 @@ struct drm_i915_display_funcs {
* involved with the same commit.
*/
void (*load_luts)(const struct intel_crtc_state *crtc_state);
+ void (*read_luts)(struct intel_crtc_state *crtc_state);
};
struct intel_csr {
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 962db12..50b98ee 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
return dev_priv->display.color_check(crtc_state);
}
+void intel_color_get_config(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+
+ if (dev_priv->display.read_luts)
+ dev_priv->display.read_luts(crtc_state);
+}
+
static bool need_plane_update(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state)
{
diff --git a/drivers/gpu/drm/i915/intel_color.h
b/drivers/gpu/drm/i915/intel_color.h
index b8a3ce6..057e8ac 100644
--- a/drivers/gpu/drm/i915/intel_color.h
+++ b/drivers/gpu/drm/i915/intel_color.h
@@ -13,5 +13,6 @@
int intel_color_check(struct intel_crtc_state *crtc_state);
void intel_color_commit(const struct intel_crtc_state *crtc_state);
void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
+void intel_color_get_config(struct intel_crtc_state *crtc_state);
#endif /* __INTEL_COLOR_H__ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 02/12] drm/i915: Enable intel_color_get_config()
In this patch, intel_color_get_config() is enabled and support
for read_luts() will be added platform by platform incrementally
in the follow-up patches.
v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
-Added the user early on such that support for get_color_config()
can be added platform by platform incrementally [Jani]
v5: -Incorrect place for calling intel_color_get_config() in
haswell_get_pipe_config() [Ville]
v6: -Renamed intel_color_read_luts() to intel_color_get_config()
[Jani and Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 05177f3..3e01028 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8351,6 +8351,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
pipe_config->cgm_mode = I915_READ(CGM_PIPE_MODE(crtc->pipe));
i9xx_get_pipe_color_config(pipe_config);
+ intel_color_get_config(pipe_config);
if (INTEL_GEN(dev_priv) < 4)
pipe_config->double_wide = tmp & PIPECONF_DOUBLE_WIDE;
@@ -9426,6 +9427,7 @@ static bool ironlake_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->csc_mode = I915_READ(PIPE_CSC_MODE(crtc->pipe));
i9xx_get_pipe_color_config(pipe_config);
+ intel_color_get_config(pipe_config);
if (I915_READ(PCH_TRANSCONF(crtc->pipe)) & TRANS_ENABLE) {
struct intel_shared_dpll *pll;
@@ -9874,6 +9876,8 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
i9xx_get_pipe_color_config(pipe_config);
}
+ intel_color_get_config(pipe_config);
+
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
WARN_ON(power_domain_mask & BIT_ULL(power_domain));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 04/12] drm/i915: Extract i9xx_read_luts()
In this patch, hw gamma blob is created for the legacy
gamma. Also, function intel_color_lut_pack is added to
convert hw value with given bit_precision to lut property val.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally withing the
function [Ville]
-Renamed function i9xx_get_color_config() to i9xx_read_luts()
-Renamed i9xx_get_config_internal() to i9xx_read_lut_8() [Ville]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_color.c | 51 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47f..d8475f2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7178,6 +7178,9 @@ enum {
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
+#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
+#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8)
+#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
#define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B)
+ (i) * 4)
/* ilk/snb precision palette */
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 1e60369..3396d35 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1344,6 +1344,56 @@ bool intel_color_lut_equal(struct drm_property_blob
*blob1,
return true;
}
+/* convert hw value with given bit_precision to lut property val */
+static u32 intel_color_lut_pack(u32 val, u32 bit_precision)
+{
+ u32 max = 0x >> (16 - bit_precision);
+
+ val = clamp_val(val, 0, max);
+
+ if (bit_precision < 16)
+ val <<= 16 - bit_precision;
+
+ return val;
+}
+
+static struct drm_property_blob *
+i9xx_read_lut_8(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);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) * 256,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < 256; i++) {
+ if (HAS_GMCH(dev_priv))
+ val = I915_READ(PALETTE(pipe, i));
+ else
+ val = I915_READ(LGC_PALETTE(pipe, i));
+
+ blob_data[i].red =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val), 8);
+ blob_data[i].green =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
+ blob_data[i].blue =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, val), 8);
+ }
+
+ return blob;
+}
+
+void i9xx_read_luts(struct intel_crtc_state *crtc_state)
+{
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1364,6 +1414,7 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.color_check = i9xx_color_check;
dev_priv->display.color_commit = i9xx_color_commit;
dev_priv->display.load_luts = i9xx_load_luts;
+ dev_priv->display.read_luts = i9xx_read_luts;
}
} else {
if (INTEL_GEN(dev_priv) >= 11)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 04/16] i915/gem_ctx_param: Test set/get (copy) VM
On 08/05/2019 11:09, Chris Wilson wrote:
Exercise reusing the GTT of one ctx in another.
v2: Test setting back to the same VM
v3: Check the VM still exists after the parent ctx are dead.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_ctx_param.c | 107 -
1 file changed, 95 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_ctx_param.c b/tests/i915/gem_ctx_param.c
index b6f57236c..d949cef32 100644
--- a/tests/i915/gem_ctx_param.c
+++ b/tests/i915/gem_ctx_param.c
@@ -28,6 +28,7 @@
#include
#include "igt.h"
+#include "i915/gem_vm.h"
IGT_TEST_DESCRIPTION("Basic test for context set/get param input validation.");
@@ -36,17 +37,6 @@ IGT_TEST_DESCRIPTION("Basic test for context set/get param input validation.");
#define NEW_CTX BIT(0)
#define USER BIT(1)
-static int reopen_driver(int fd)
-{
- char path[256];
-
- snprintf(path, sizeof(path), "/proc/self/fd/%d", fd);
- fd = open(path, O_RDWR);
- igt_assert_lte(0, fd);
-
- return fd;
-}
-
static void set_priority(int i915)
{
static const int64_t test_values[] = {
@@ -91,7 +81,7 @@ static void set_priority(int i915)
igt_permute_array(values, size, igt_exchange_int64);
igt_fork(flags, NEW_CTX | USER) {
- int fd = reopen_driver(i915);
+ int fd = gem_reopen_driver(i915);
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_PRIORITY,
.ctx_id = flags & NEW_CTX ? gem_context_create(fd) : 0,
@@ -143,6 +133,96 @@ static void set_priority(int i915)
free(values);
}
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, , sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
+static void test_vm(int i915)
+{
+ const uint64_t nonzero_offset = 48 << 20;
+ struct drm_i915_gem_exec_object2 batch = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 eb = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ struct drm_i915_gem_context_param arg = {
+ .param = I915_CONTEXT_PARAM_VM,
+ };
+ uint32_t parent, child;
+
+ arg.value = -1ull;
+ igt_require(__gem_context_set_param(i915, ) == -ENOENT);
+
+ parent = gem_context_create(i915);
+ child = gem_context_create(i915);
+
+ /* Using implicit soft-pinning */
+ eb.rsvd1 = parent;
+ batch.offset = nonzero_offset;
+ gem_execbuf(i915, );
+ igt_assert_eq_u64(batch.offset, nonzero_offset);
+
+ eb.rsvd1 = child;
+ batch.offset = 0;
+ gem_execbuf(i915, );
+ igt_assert_eq_u64(batch.offset, 0);
+
+ eb.rsvd1 = parent;
+ gem_execbuf(i915, );
+ igt_assert_eq_u64(batch.offset, nonzero_offset);
+
+ arg.ctx_id = parent;
+ gem_context_get_param(i915, );
+ gem_context_set_param(i915, );
+
+ /* Still the same VM, so expect the old VMA again */
+ batch.offset = 0;
+ gem_execbuf(i915, );
+ igt_assert_eq_u64(batch.offset, nonzero_offset);
+
+ arg.ctx_id = child;
+ gem_context_set_param(i915, );
+
+ eb.rsvd1 = child;
+ batch.offset = 0;
+ gem_execbuf(i915, );
+ igt_assert_eq_u64(batch.offset, nonzero_offset);
+
+ gem_context_destroy(i915, child);
+ gem_context_destroy(i915, parent);
High level commentary is lacking so my condolences to future readers.
I'd also add a get_vm after set_vm just to check it reads back the same.
Otherwise:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
+
+ /* both contexts destroyed, but we still keep hold of the vm */
+ child = gem_context_create(i915);
+
+ arg.ctx_id = child;
+ gem_context_set_param(i915, );
+
+ eb.rsvd1 = child;
+ batch.offset = 0;
+ gem_execbuf(i915, );
+ igt_assert_eq_u64(batch.offset, nonzero_offset);
+
+ gem_context_destroy(i915, child);
+ gem_vm_destroy(i915, arg.value);
+
+ gem_sync(i915, batch.handle);
+ gem_close(i915, batch.handle);
+}
+
igt_main
{
struct drm_i915_gem_context_param arg;
@@ -253,6 +333,9 @@ igt_main
gem_context_set_param(fd, );
}
+ igt_subtest("vm")
+ test_vm(fd);
+
arg.param = I915_CONTEXT_PARAM_PRIORITY;
igt_subtest("set-priority-not-supported") {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/12] drm/i915: adding state checker for gamma lut values
In this patch series, added state checker to validate gamma and will be extended to validate degamma lut values aswell. This reads hardware state, and compares the originally requested state to the state read from hardware. v1: -Implementation done for legacy platforms (removed all the placeholders) (Jani) v2: -Restructured code to reated platform specific patch series v3: -Rebase v4: -Minor changes-function name changes v5: -Added degamma validation (Ville) v6: -Removed degamma changes, debugging was becoming difficult -Added function to assign bit_precision for gamma/degamma lut values /platform -Added debug info into intel_dump_pipe_config() (Jani) Swati Sharma (12): drm/i915: Introduce vfunc read_luts() to create hw lut drm/i915: Enable intel_color_get_config() drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values drm/i915: Extract i9xx_read_luts() drm/i915: Extract chv_read_luts() drm/i915: Extract i965_read_luts() drm/i915: Extract icl_read_luts() drm/i915: Extract glk_read_luts() drm/i915: Extract bdw_read_luts() drm/i915: Extract ivb_read_luts() drm/i915: Extract ilk_read_luts() FOR_TESTING_ONLY: Print rgb values of hw and sw blobs drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 15 ++ drivers/gpu/drm/i915/intel_color.c | 394 ++- drivers/gpu/drm/i915/intel_color.h | 8 + drivers/gpu/drm/i915/intel_display.c | 28 +++ 5 files changed, 441 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6][PATCH 03/12] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
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]
v6: -Added func intel_color_get_bit_precision() to get bit precision for
gamma and degamma lut readout depending upon platform and
corresponding to load_luts() [Ankit]
-Added debug log for color para in intel_dump_pipe_config [Jani]
-Made patch11 as patch3 [Jani]
I could think of adding intel_color_get_bit_precision() to be the way
to get away with bit precision problem for degamma and gamma (its like a table
having hard coded values depening on gamma_mode).
If anybody could think of better way then this then please guide.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 93
drivers/gpu/drm/i915/intel_color.h | 7 +++
drivers/gpu/drm/i915/intel_display.c | 24 ++
3 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 50b98ee..1e60369 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1251,6 +1251,99 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
return 0;
}
+void intel_color_get_bit_precision(struct intel_crtc_state *crtc_state, int
*bp_gamma)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (HAS_GMCH(dev_priv)) {
+ if (IS_CHERRYVIEW(dev_priv)) {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
+ *bp_gamma = 8;
+ return;
+ }
+ if (crtc_state->cgm_mode == CGM_PIPE_MODE_GAMMA)
+ *bp_gamma = 10;
+ } else if (INTEL_GEN(dev_priv) >= 4) {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+ else
+ *bp_gamma = 16;
+ } else {
+ *bp_gamma = 8;
+ }
+ } else {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) ==
+ GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+ else
+ *bp_gamma = 10;
+ } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+ else
+ *bp_gamma = 10;
+ } else if (INTEL_GEN(dev_priv) >= 7) {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+ else if (crtc_state->gamma_mode ==
GAMMA_MODE_MODE_SPLIT)
+ *bp_gamma = 10;
+ else
+ *bp_gamma = 10;
+ } else {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+ else
+ *bp_gamma = 10;
+ }
+ }
+}
+
+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 bit_precision)
+{
+ struct drm_color_lut *sw_lut, *hw_lut;
+ int sw_lut_size, hw_lut_size, i;
+ u32 err;
+
+ if (!blob1 && !blob2)
+ return true;
+
+ if (!blob1)
+ return true;
+
+ if (!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;
+
+ sw_lut = blob1->data;
+ hw_lut = blob2->data;
+
+ err = 0x >> bit_precision;
+
+ for (i = 0; i < sw_lut_size; i++) {
+if (!err_check(_lut[i], _lut[i], err))
+ return false;
+ }
+
+ return true;
+}
+
void
Re: [Intel-gfx] [PATCH i-g-t 01/16] i915/gem_exec_schedule: Semaphore priority fixups
On 08/05/2019 11:09, Chris Wilson wrote: A stray git add from my test boxen -- we were being careful enough to preserve priority and ordering to match the implicit policies. Signed-off-by: Chris Wilson --- tests/i915/gem_exec_schedule.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c index 330e8a54e..77a264a6a 100644 --- a/tests/i915/gem_exec_schedule.c +++ b/tests/i915/gem_exec_schedule.c @@ -507,6 +507,7 @@ static void semaphore_resolve(int i915) uint32_t handle, cancel; uint32_t *cs, *map; igt_spin_t *spin; + int64_t poke = 1; if (!gem_can_store_dword(i915, engine)) continue; @@ -587,6 +588,7 @@ static void semaphore_resolve(int i915) eb.buffer_count = 2; eb.rsvd1 = inner; gem_execbuf(i915, ); + gem_wait(i915, cancel, ); gem_close(i915, cancel); gem_sync(i915, handle); /* To hang unless cancel runs! */ Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
