Re: [Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained
On Fri, May 17, 2019 at 5:35 PM Chris Wilson wrote: > > Quoting Jani Nikula (2019-05-16 20:48:16) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > > index 8a1f64f17740..c2839de06485 100644 > > --- a/scripts/Makefile.lib > > +++ b/scripts/Makefile.lib > > @@ -66,6 +66,9 @@ extra-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y)) > > extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-)) > > endif > > > > +# Test self-contained headers > > +extra-$(CONFIG_HEADER_TEST) += $(patsubst > > %.h,%.header_test.o,$(header-test-y)) > > This didn't get pulled into clean-files. > > clean-files-$(CONFIG_HEADER_TEST) += $(patsubst > %.h,%.header_test.c,$(header-test-y)) > ? > > Not enough. Nor is clean-files-y +=... The correct syntax is 'clean-files +=' instead of 'clean-files-y +=' If Kbuild supports this in the core Makefiles, we can add "-o -name '*.header_test.c'" to the top Makefile. > And it should also be put into the global gitignore I think. Documentation/dontdiff too. > -Chris -- Best Regards Masahiro Yamada ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained
On Fri, May 17, 2019 at 4:48 AM Jani Nikula wrote: > > Sometimes it's useful to be able to explicitly ensure certain headers > remain self-contained, i.e. that they are compilable as standalone > units, by including and/or forward declaring everything they depend on. > > Add special target header-test-y where individual Makefiles can add > headers to be tested if CONFIG_HEADER_TEST is enabled. This will > generate a dummy C file per header that gets built as part of extra-y. > > Cc: Chris Wilson > Cc: Masahiro Yamada > Cc: Michal Marek > Signed-off-by: Jani Nikula > --- > Documentation/kbuild/makefiles.txt | 7 +++ > init/Kconfig | 9 + > scripts/Makefile.build | 10 ++ > scripts/Makefile.lib | 3 +++ > 4 files changed, 29 insertions(+) > > diff --git a/Documentation/kbuild/makefiles.txt > b/Documentation/kbuild/makefiles.txt > index 03c065855eaf..73df58e5ea0c 100644 > --- a/Documentation/kbuild/makefiles.txt > +++ b/Documentation/kbuild/makefiles.txt > @@ -1036,6 +1036,13 @@ When kbuild executes, the following steps are followed > (roughly): > In this example, extra-y is used to list object files that > shall be built, but shall not be linked as part of built-in.a. > > +header-test-y > + > + header-test-y specifies headers (*.h) in the current directory that > + should be compile tested to ensure they are self-contained, > + i.e. compilable as standalone units. If CONFIG_HEADER_TEST is enabled, > + this autogenerates dummy sources to include the headers, and builds > them > + as part of extra-y. > > --- 6.7 Commands useful for building a boot image > > diff --git a/init/Kconfig b/init/Kconfig > index 4592bf7997c0..d91b157201b1 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -95,6 +95,15 @@ config COMPILE_TEST > here. If you are a user/distributor, say N here to exclude useless > drivers to be distributed. > > +config HEADER_TEST > + bool "Compile test headers that should be standalone compilable" > + help > + Compile test headers listed in header-test-y target to ensure they > are > + self-contained, i.e. compilable as standalone units. > + > + If you are a developer or tester and want to ensure the requested > + headers are self-contained, say Y here. Otherwise, choose N. > + > config LOCALVERSION > string "Local version - append to kernel release" > help > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index 76ca30cc4791..4d4bf698467a 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -291,6 +291,16 @@ quiet_cmd_cc_lst_c = MKLST $@ > $(obj)/%.lst: $(src)/%.c FORCE > $(call if_changed_dep,cc_lst_c) > > +# Dummy C sources for header test (header-test-y target) > +# --- > + > +quiet_cmd_header_test = HDRTEST $@ > + cmd_header_test = echo "\#include \"$( $@ > + > +# FIXME: would be nice to be able to limit this implicit rule to > header-test-y > +$(obj)/%.header_test.c: $(src)/%.h FORCE > + $(call if_changed,header_test) > + > # Compile assembler sources (.S) > # --- > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 8a1f64f17740..c2839de06485 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -66,6 +66,9 @@ extra-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y)) > extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-)) > endif > > +# Test self-contained headers > +extra-$(CONFIG_HEADER_TEST) += $(patsubst > %.h,%.header_test.o,$(header-test-y)) > + > # Add subdir path > > extra-y:= $(addprefix $(obj)/,$(extra-y)) > -- > 2.20.1 > Thanks, probably we should do this. At least, this check will be useful for uapi headers since the kernel does not test the self-containedness of exported headers, (then turned out be problematic later in user-space). I will take a little time to considier how far we can extend the idea about "headers should be self-contained". Thank you. -- Best Regards Masahiro Yamada ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Extend BT2020 support in iCSC and fixes (rev3)
== Series Details == Series: Extend BT2020 support in iCSC and fixes (rev3) URL : https://patchwork.freedesktop.org/series/60480/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6096_full -> Patchwork_13033_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13033_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13033_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_13033_full: ### IGT changes ### Possible regressions * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-hsw5/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_13033_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: [PASS][2] -> [TIMEOUT][3] ([fdo#109673]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb3/igt@gem_mmap_...@forked-big-copy.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-iclb2/igt@gem_mmap_...@forked-big-copy.html * igt@i915_pm_rpm@cursor-dpms: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([fdo#107807]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-skl9/igt@i915_pm_...@cursor-dpms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-skl6/igt@i915_pm_...@cursor-dpms.html * igt@i915_suspend@debugfs-reader: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([fdo#104108] / [fdo#107773]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-skl2/igt@i915_susp...@debugfs-reader.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-skl3/igt@i915_susp...@debugfs-reader.html * igt@kms_atomic_transition@plane-all-modeset-transition: - shard-hsw: [PASS][8] -> [DMESG-WARN][9] ([fdo#102614]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-hsw2/igt@kms_atomic_transit...@plane-all-modeset-transition.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-hsw5/igt@kms_atomic_transit...@plane-all-modeset-transition.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic: - shard-snb: [PASS][10] -> [SKIP][11] ([fdo#109271]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-snb4/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-snb7/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109349]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-iclb7/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][14] -> [FAIL][15] ([fdo#105363]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-glk8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][16] -> [INCOMPLETE][17] ([fdo#109507]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-skl1/igt@kms_f...@flip-vs-suspend-interruptible.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-skl10/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][18] -> [FAIL][19] ([fdo#103167]) +8 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/shard-iclb3/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][22] ->
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev14)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev14)
URL : https://patchwork.freedesktop.org/series/25091/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6096_full -> Patchwork_13032_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_13032_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13032_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_13032_full:
### IGT changes ###
Possible regressions
* igt@gem_pwrite@big-gtt-random:
- shard-glk: [PASS][1] -> [TIMEOUT][2] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk6/igt@gem_pwr...@big-gtt-random.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk5/igt@gem_pwr...@big-gtt-random.html
* igt@i915_suspend@forcewake:
- shard-glk: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk9/igt@i915_susp...@forcewake.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk1/igt@i915_susp...@forcewake.html
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
- shard-glk: [PASS][5] -> [FAIL][6] +621 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-untiled.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-untiled.html
* igt@kms_hdmi_inject@inject-4k:
- shard-iclb: [PASS][7] -> [FAIL][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb8/igt@kms_hdmi_inj...@inject-4k.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-iclb2/igt@kms_hdmi_inj...@inject-4k.html
* igt@testdisplay:
- shard-glk: [PASS][9] -> [WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk7/i...@testdisplay.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk8/i...@testdisplay.html
Warnings
* igt@kms_hdmi_inject@inject-audio:
- shard-iclb: [FAIL][11] ([fdo#102370]) -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb7/igt@kms_hdmi_inj...@inject-audio.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-iclb5/igt@kms_hdmi_inj...@inject-audio.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- shard-glk: [FAIL][13] ([fdo#108145]) -> [FAIL][14] +5 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk7/igt@kms_plane_alpha_bl...@pipe-c-alpha-transparant-fb.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk4/igt@kms_plane_alpha_bl...@pipe-c-alpha-transparant-fb.html
* igt@kms_setmode@basic:
- shard-glk: [FAIL][15] ([fdo#99912]) -> [FAIL][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk6/igt@kms_setm...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk7/igt@kms_setm...@basic.html
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-dpms}:
- shard-glk: [FAIL][17] ([fdo#103232]) -> [FAIL][18] +49 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk9/igt@kms_cursor_...@pipe-a-cursor-dpms.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk1/igt@kms_cursor_...@pipe-a-cursor-dpms.html
* {igt@kms_cursor_crc@pipe-c-cursor-64x64-rapid-movement}:
- shard-glk: [PASS][19] -> [FAIL][20] +31 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-glk3/igt@kms_cursor_...@pipe-c-cursor-64x64-rapid-movement.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-glk4/igt@kms_cursor_...@pipe-c-cursor-64x64-rapid-movement.html
Known issues
Here are the changes found in Patchwork_13032_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@forked-big-copy:
- shard-iclb: [PASS][21] -> [TIMEOUT][22] ([fdo#109673])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/shard-iclb3/igt@gem_mmap_...@forked-big-copy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/shard-iclb1/igt@gem_mmap_...@forked-big-copy.html
* igt@gem_tiled_swapping@non-threaded:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Tolerate file owned GEM contexts on hot unbind
== Series Details ==
Series: drm/i915: Tolerate file owned GEM contexts on hot unbind
URL : https://patchwork.freedesktop.org/series/60782/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6095_full -> Patchwork_13031_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_13031_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-c-cursor-suspend}:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-suspend.html
Known issues
Here are the changes found in Patchwork_13031_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +6
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-apl4/igt@i915_susp...@debugfs-reader.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-apl5/igt@i915_susp...@debugfs-reader.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +8 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-iclb8/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-iclb2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103166])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-y.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109642])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-iclb1/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_cpu.html
Possible fixes
* igt@gem_mmap_gtt@forked-medium-copy-odd:
- shard-iclb: [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-iclb8/igt@gem_mmap_...@forked-medium-copy-odd.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-iclb5/igt@gem_mmap_...@forked-medium-copy-odd.html
* igt@i915_pm_rpm@gem-execbuf-stress:
- shard-skl: [INCOMPLETE][15] ([fdo#107803] / [fdo#107807]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-skl3/igt@i915_pm_...@gem-execbuf-stress.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-skl10/igt@i915_pm_...@gem-execbuf-stress.html
* igt@i915_pm_rpm@gem-mmap-gtt:
- shard-skl: [INCOMPLETE][17] ([fdo#107807]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-skl1/igt@i915_pm_...@gem-mmap-gtt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-skl5/igt@i915_pm_...@gem-mmap-gtt.html
* {igt@kms_cursor_crc@pipe-b-cursor-suspend}:
- shard-skl: [INCOMPLETE][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][21] ([fdo#105767]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
* igt@kms_cursor_legacy@all-pipes-single-move:
- shard-hsw: [INCOMPLETE][23] ([fdo#103540]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/shard-hsw5/igt@kms_cursor_leg...@all-pipes-single-move.html
[24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Don't try to check HuC status if it's not loaded
== Series Details == Series: drm/i915/huc: Don't try to check HuC status if it's not loaded URL : https://patchwork.freedesktop.org/series/60807/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097 -> Patchwork_13037 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/ Known issues Here are the changes found in Patchwork_13037 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-ilk-650: [PASS][1] -> [DMESG-WARN][2] ([fdo#106387]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-ilk-650/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-ilk-650/igt@debugfs_test@read_all_entries.html * igt@gem_exec_basic@basic-blt: - fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#110246]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-icl-u2/igt@gem_exec_ba...@basic-blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-icl-u2/igt@gem_exec_ba...@basic-blt.html * igt@gem_exec_fence@basic-wait-default: - fi-skl-6770hq: [PASS][5] -> [DMESG-WARN][6] ([fdo#105541]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-skl-6770hq/igt@gem_exec_fe...@basic-wait-default.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-skl-6770hq/igt@gem_exec_fe...@basic-wait-default.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [PASS][7] -> [DMESG-FAIL][8] ([fdo#110235]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [DMESG-WARN][9] ([fdo#108965]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][11] ([fdo#108602] / [fdo#108744]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [FAIL][13] ([fdo#110623]) -> [DMESG-FAIL][14] ([fdo#110620]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541 [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246 [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 -> 44) -- Additional (1): fi-pnv-d510 Missing(9): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-hsw-4770 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6097 -> Patchwork_13037 CI_DRM_6097: 3f2d6a47d9eec66594887b1e9718bc1a29aa6a77 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4996: 6fe5d254ec1b9b47d61408e1b49a7339876bf1e7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13037: 2d2ec9f5142934ace100926cfd1159fe08dce32b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2d2ec9f51429 drm/i915/huc: Don't try to check HuC status if it's not loaded == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13037/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/huc: Don't try to check HuC status if it's not loaded
On Fri, 17 May 2019 23:52:37 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-05-17 22:40:28) If we never attempted to load HuC firmware, or we already wedged or reset GuC/HuC, then there is no reason to wake up the device to check one bit in the register that will be for sure cleared. Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Tony Ye --- drivers/gpu/drm/i915/intel_huc.c | 3 +++ drivers/gpu/drm/i915/intel_huc.h | 5 + 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c index 1ff1fb015e58..9d91089e2cd1 100644 --- a/drivers/gpu/drm/i915/intel_huc.c +++ b/drivers/gpu/drm/i915/intel_huc.c @@ -163,6 +163,9 @@ int intel_huc_check_status(struct intel_huc *huc) if (!HAS_HUC(dev_priv)) return -ENODEV; + if (!intel_huc_is_loaded(huc)) + return 0; Just to throw out an idea, -ENXIO? A subtle change in ABI that should go unnoticed by the media driver, but helps differentiate cause without having to dig deeper. or maybe: if (!USES_HUC(dev_priv)) return 0; if (!intel_huc_is_loaded(huc)) return -ENXIO; ... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
The patch looks fine to me.
On Thu, May 16, 2019 at 10:41:56PM +0530, Anshuman Gupta wrote:
> This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
> Core-for-CI:ICL_only Disable ACPI idle driver.
>
> This hack has been provided considering the Bug assessment
> that ACPI idle driver page fault causes below bug.
> FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
> But this bug is still reproducible after disabling ACPI idle driver.
>
> It looks "rcu_preempt self-detected stall on CPU" causes to
> hung kworker and followed by panic resulted this bug.
>
> Hence it make sense to revert this patch.
>
> Cc: martin.pe...@intel.com
> Cc: daniel.vet...@intel.com
> Cc: ville.syrj...@intel.com
Reviewed-by: Aditya Swarup
> Signed-off-by: Anshuman Gupta
> ---
> drivers/acpi/processor_driver.c | 18 +-
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index ee842a2f..9d6aff2 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -35,12 +35,6 @@
>
> #include
>
> -/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
> -#ifdef CONFIG_X86
> -#include
> -#include
> -#endif
> -
> #include "internal.h"
>
> #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
> @@ -64,13 +58,6 @@ static const struct acpi_device_id processor_device_ids[]
> = {
> };
> MODULE_DEVICE_TABLE(acpi, processor_device_ids);
>
> -#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> -static const struct x86_cpu_id intel_cpu_ids[] = {
> - ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
> - {}
> -};
> -MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
> -
> static struct device_driver acpi_processor_driver = {
> .name = "processor",
> .bus = _subsys,
> @@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct
> acpi_processor *pr,
> static int __acpi_processor_start(struct acpi_device *device)
> {
> struct acpi_processor *pr = acpi_driver_data(device);
> - const struct x86_cpu_id *id;
> acpi_status status;
> int result = 0;
>
> @@ -253,9 +239,7 @@ static int __acpi_processor_start(struct acpi_device
> *device)
> if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
> dev_dbg(>dev, "CPPC data invalid or not present\n");
>
> - id = x86_match_cpu(intel_cpu_ids);
> - if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
> - _idle_driver))
> + if (!cpuidle_get_driver() || cpuidle_get_driver() == _idle_driver)
> acpi_processor_power_init(pr);
>
> result = acpi_pss_perf_init(pr, device);
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/huc: Don't try to check HuC status if it's not loaded
Quoting Michal Wajdeczko (2019-05-17 22:40:28) > If we never attempted to load HuC firmware, or we already wedged > or reset GuC/HuC, then there is no reason to wake up the device > to check one bit in the register that will be for sure cleared. > > Suggested-by: Chris Wilson > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Tony Ye > --- > drivers/gpu/drm/i915/intel_huc.c | 3 +++ > drivers/gpu/drm/i915/intel_huc.h | 5 + > 2 files changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_huc.c > b/drivers/gpu/drm/i915/intel_huc.c > index 1ff1fb015e58..9d91089e2cd1 100644 > --- a/drivers/gpu/drm/i915/intel_huc.c > +++ b/drivers/gpu/drm/i915/intel_huc.c > @@ -163,6 +163,9 @@ int intel_huc_check_status(struct intel_huc *huc) > if (!HAS_HUC(dev_priv)) > return -ENODEV; > > + if (!intel_huc_is_loaded(huc)) > + return 0; Just to throw out an idea, -ENXIO? A subtle change in ABI that should go unnoticed by the media driver, but helps differentiate cause without having to dig deeper. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/huc: Don't try to check HuC status if it's not loaded
If we never attempted to load HuC firmware, or we already wedged
or reset GuC/HuC, then there is no reason to wake up the device
to check one bit in the register that will be for sure cleared.
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tony Ye
---
drivers/gpu/drm/i915/intel_huc.c | 3 +++
drivers/gpu/drm/i915/intel_huc.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 1ff1fb015e58..9d91089e2cd1 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -163,6 +163,9 @@ int intel_huc_check_status(struct intel_huc *huc)
if (!HAS_HUC(dev_priv))
return -ENODEV;
+ if (!intel_huc_is_loaded(huc))
+ return 0;
+
with_intel_runtime_pm(dev_priv, wakeref)
status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index a0c21ae02a99..cde3d303718d 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -44,6 +44,11 @@ void intel_huc_fini(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
int intel_huc_check_status(struct intel_huc *huc);
+static inline bool intel_huc_is_loaded(struct intel_huc *huc)
+{
+ return intel_uc_fw_is_loaded(>fw);
+}
+
static inline void intel_huc_fini_misc(struct intel_huc *huc)
{
intel_uc_fw_cleanup_fetch(>fw);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL
Nit: Commit message V4 and Patch Subject V3
Acked-by: Clint Taylor
-Clint
On 5/3/19 12:08 PM, Ville Syrjala wrote:
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query the
memory clock and timings, so we must rely on a combination of
raw readout from the memory controller and hardcoded assumptions.
The memory controller values obviously change as the system
jumps between the different SAGV points, so we try to stabilize
it first by disabling SAGV for the duration of the readout.
The utilized bandwidth is tracked via a device wide atomic
private object. That is actually not robust because we can't
afford to enforce strict global ordering between the pipes.
Thus I think I'll need to change this to simply chop up the
available bandwidth between all the active pipes. Each pipe
can then do whatever it wants as long as it doesn't exceed
its budget. That scheme will also require that we assume that
any number of planes could be active at any time.
TODO: make it robust and deal with all the open questions
v2: Sleep longer after disabling SAGV
v3: Poll for the dclk to get raised (seen it take 250ms!)
If the system has 2133MT/s memory then we pointlessly
wait one full second :(
v4: Use the new pcode interface to get the qgv points rather
that using hardcoded numbers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 229 ++
drivers/gpu/drm/i915/i915_drv.h | 10 +
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 20 ++
drivers/gpu/drm/i915/intel_atomic_plane.h | 2 +
drivers/gpu/drm/i915/intel_bw.c | 181 +
drivers/gpu/drm/i915/intel_bw.h | 46 +
drivers/gpu/drm/i915/intel_display.c | 40 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 +
10 files changed, 533 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_bw.c
create mode 100644 drivers/gpu/drm/i915/intel_bw.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68106fe35a04..139a0fc19390 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -138,6 +138,7 @@ i915-y += intel_audio.o \
intel_atomic.o \
intel_atomic_plane.o \
intel_bios.o \
+ intel_bw.o \
intel_cdclk.o \
intel_color.o \
intel_combo_phy.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ed864752c7b..b7fa7b51c2e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -70,6 +70,7 @@
#include "intel_overlay.h"
#include "intel_pipe_crc.h"
#include "intel_pm.h"
+#include "intel_sideband.h"
#include "intel_sprite.h"
#include "intel_uc.h"
@@ -1435,6 +1436,232 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
return 0;
}
+struct intel_qgv_point {
+ u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
+};
+
+struct intel_sagv_info {
+ struct intel_qgv_point points[3];
+ u8 num_points;
+ u8 num_channels;
+ u8 t_bl;
+ enum intel_dram_type dram_type;
+};
+
+static int icl_pcode_read_mem_global_info(struct drm_i915_private *dev_priv,
+ struct intel_sagv_info *si)
+{
+ u32 val = 0;
+ int ret;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ICL_PCODE_MEM_SS_READ_GLOBAL_INFO,
+, NULL);
+ if (ret)
+ return ret;
+
+ switch (val & 0xf) {
+ case 0:
+ si->dram_type = INTEL_DRAM_DDR4;
+ break;
+ case 1:
+ si->dram_type = INTEL_DRAM_DDR3;
+ break;
+ case 2:
+ si->dram_type = INTEL_DRAM_LPDDR3;
+ break;
+ case 3:
+ si->dram_type = INTEL_DRAM_LPDDR3;
+ break;
+ default:
+ MISSING_CASE(val & 0xf);
+ break;
+ }
+
+ si->num_channels = (val & 0xf0) >> 4;
+ si->num_points = (val & 0xf00) >> 8;
+
+ si->t_bl = si->dram_type == INTEL_DRAM_DDR4 ? 4 : 8;
+
+ return 0;
+}
+
+static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
+struct intel_qgv_point *sp,
+int point)
+{
+ u32 val = 0, val2;
+ int ret;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
On Fri, 17 May 2019 22:08:56 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-05-17 19:01:06) On Fri, 17 May 2019 19:14:01 +0200, Chris Wilson wrote: > Quoting Michal Wajdeczko (2019-05-17 18:11:07) >> On Fri, 17 May 2019 18:31:31 +0200, Chris Wilson >> wrote: >> >> > Quoting Michal Wajdeczko (2019-05-17 17:22:25) >> >> We may skip reset preparation steps if GuC is already sanitized. >> >> >> >> Signed-off-by: Michal Wajdeczko >> >> Cc: Chris Wilson >> >> Cc: Daniele Ceraolo Spurio >> >> --- >> >> drivers/gpu/drm/i915/intel_uc.c | 3 +++ >> >> 1 file changed, 3 insertions(+) >> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_uc.c >> >> b/drivers/gpu/drm/i915/intel_uc.c >> >> index 86edfa5ad72e..36c53a42927c 100644 >> >> --- a/drivers/gpu/drm/i915/intel_uc.c >> >> +++ b/drivers/gpu/drm/i915/intel_uc.c >> >> @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct >> drm_i915_private >> >> *i915) >> >> if (!USES_GUC(i915)) >> >> return; >> >> >> >> + if (!intel_guc_is_alive(guc)) >> >> + return; >> > >> > Does it not replace "if (!USES_GUC(i915))"? >> >> Yes it can, as we will never fetch/upload fw if we don't plan to use it >> ;) >> >> Btw, I'm thinking of renaming intel_guc_is_alive to intel_guc_is_loaded >> or intel_guc_is_started to better describe what this function is >> reporting, >> as one can think that intel_guc_is_alive is actually checking that GuC >> fw >> is responsive, which in general might not be the same as "loaded" > > Either seems reasonable, though there might be good reason to have both > :) > > intel_guc_is_loaded > intel_guc_has_started / intel_guc_is_active On GuC load failure, or on reset, we immediately sanitize fw load status, so until we provide real runtime connectivity check, if ever be required, I assume we can stay with just one function: intel_guc_is_loaded, ok? Would a similar one for huc also work? Would it be reliable enough to replace HUC_STATUS query? (Seems silly to wake the device up just to answer if we've loaded the firmware successfully.) I'm not sure that we can drop HUC_STATUS query as maybe this bit can go off (who can confirm that?) but we definitely can replace HAS_HUC (btw it should be USES_HUC) with new intel_huc_is_loaded Michal ___ 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 [01/14] drm/i915: Pass intel_atomic_state to cdclk funcs
== Series Details ==
Series: series starting with [01/14] drm/i915: Pass intel_atomic_state to cdclk
funcs
URL : https://patchwork.freedesktop.org/series/60803/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6096 -> Patchwork_13036
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/
Known issues
Here are the changes found in Patchwork_13036 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_6096/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/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_6096/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_basic@bad-close:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-u2/igt@gem_ba...@bad-close.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-icl-u2/igt@gem_ba...@bad-close.html
* igt@gem_cpu_reloc@basic:
- {fi-icl-y}: [INCOMPLETE][7] ([fdo#107713] / [fdo#110246]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-y/igt@gem_cpu_re...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-icl-y/igt@gem_cpu_re...@basic.html
- {fi-icl-u3}:[INCOMPLETE][9] ([fdo#107713] / [fdo#110246]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-u3/igt@gem_cpu_re...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-icl-u3/igt@gem_cpu_re...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [INCOMPLETE][13] ([fdo#103927] / [fdo#110624]) ->
[DMESG-FAIL][14] ([fdo#110620])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
* igt@runner@aborted:
- fi-apl-guc: [FAIL][15] ([fdo#110624]) -> [FAIL][16] ([fdo#110622])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-apl-guc/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13036/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
Participating hosts (51 -> 45)
--
Additional (1): fi-skl-lmem
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6096 -> Patchwork_13036
CI_DRM_6096: beb32d3348a566a6aafa292c65e2d60a610479c4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4996: 6fe5d254ec1b9b47d61408e1b49a7339876bf1e7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13036: 6781fea0a305f4439d0d4a085110ebece61278f3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6781fea0a305 drm/i915: Fix plane state dumps
69a67248d254 drm/i915: Make state dumpers take a const state
948f185a463c drm/i915: Dump failed crtc states during atomic check
b4c5cc85aa0e drm/i915: Include crtc_state.active in crtc state dumps
79bcb9b69ef0 drm/i915: Move state dump to the end of
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
Quoting Michal Wajdeczko (2019-05-17 19:01:06) > On Fri, 17 May 2019 19:14:01 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2019-05-17 18:11:07) > >> On Fri, 17 May 2019 18:31:31 +0200, Chris Wilson > >> wrote: > >> > >> > Quoting Michal Wajdeczko (2019-05-17 17:22:25) > >> >> We may skip reset preparation steps if GuC is already sanitized. > >> >> > >> >> Signed-off-by: Michal Wajdeczko > >> >> Cc: Chris Wilson > >> >> Cc: Daniele Ceraolo Spurio > >> >> --- > >> >> drivers/gpu/drm/i915/intel_uc.c | 3 +++ > >> >> 1 file changed, 3 insertions(+) > >> >> > >> >> diff --git a/drivers/gpu/drm/i915/intel_uc.c > >> >> b/drivers/gpu/drm/i915/intel_uc.c > >> >> index 86edfa5ad72e..36c53a42927c 100644 > >> >> --- a/drivers/gpu/drm/i915/intel_uc.c > >> >> +++ b/drivers/gpu/drm/i915/intel_uc.c > >> >> @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct > >> drm_i915_private > >> >> *i915) > >> >> if (!USES_GUC(i915)) > >> >> return; > >> >> > >> >> + if (!intel_guc_is_alive(guc)) > >> >> + return; > >> > > >> > Does it not replace "if (!USES_GUC(i915))"? > >> > >> Yes it can, as we will never fetch/upload fw if we don't plan to use it > >> ;) > >> > >> Btw, I'm thinking of renaming intel_guc_is_alive to intel_guc_is_loaded > >> or intel_guc_is_started to better describe what this function is > >> reporting, > >> as one can think that intel_guc_is_alive is actually checking that GuC > >> fw > >> is responsive, which in general might not be the same as "loaded" > > > > Either seems reasonable, though there might be good reason to have both > > :) > > > > intel_guc_is_loaded > > intel_guc_has_started / intel_guc_is_active > > On GuC load failure, or on reset, we immediately sanitize fw load status, > so until we provide real runtime connectivity check, if ever be required, > I assume we can stay with just one function: intel_guc_is_loaded, ok? Would a similar one for huc also work? Would it be reliable enough to replace HUC_STATUS query? (Seems silly to wake the device up just to answer if we've loaded the firmware successfully.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/14] drm/i915: Pass intel_atomic_state to cdclk funcs
== Series Details == Series: series starting with [01/14] drm/i915: Pass intel_atomic_state to cdclk funcs URL : https://patchwork.freedesktop.org/series/60803/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Pass intel_atomic_state to cdclk funcs -O:drivers/gpu/drm/i915/intel_cdclk.c:2308:29: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2308:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2307:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2307:29: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2547:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2547:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2583:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2583:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2536:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2536:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2570:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2570:17: warning: expression using sizeof(void) Commit: drm/i915: Clean up cdclk vfunc assignments Okay! Commit: drm/i915: Pass intel_atomic state to check_digital_port_conflicts() Okay! Commit: drm/i915: Use intel_ types in intel_modeset_clear_plls() Okay! Commit: drm/i915: Use intel_ types in haswell_mode_set_planes_workaround() Okay! Commit: drm/i915: Don't pass the crtc to intel_dump_pipe_config() Okay! Commit: drm/i915: Don't pass the crtc to intel_modeset_pipe_config() Okay! Commit: drm/i915: Use intel_ types in intel_modeset_checks() Okay! Commit: drm/i915: Use intel_ types in intel_atomic_check() Okay! Commit: drm/i915: Move state dump to the end of atomic_check() Okay! Commit: drm/i915: Include crtc_state.active in crtc state dumps Okay! Commit: drm/i915: Dump failed crtc states during atomic check Okay! Commit: drm/i915: Make state dumpers take a const state Okay! Commit: drm/i915: Fix plane state dumps Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 25/25] gem_wsim: Support Icelake parts
Quoting Tvrtko Ursulin (2019-05-17 12:25:26) > From: Tvrtko Ursulin > > On Icelake second vcs engine is vcs2 instead of vcs1 so add some logical > to physical instance remapping based on engine discovery to support it. > > Signed-off-by: Tvrtko Ursulin It does the trick for now, but still feels very limited. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 24/25] gem_wsim: Discover engines
Quoting Tvrtko Ursulin (2019-05-17 12:51:06)
>
> On 17/05/2019 12:39, Andi Shyti wrote:
> > Hi Tvrtko,
> >
> >> +static int
> >> +__i915_query(int i915, struct drm_i915_query *q)
> >> +{
> >> +if (igt_ioctl(i915, DRM_IOCTL_I915_QUERY, q))
> >> +return -errno;
> >> +return 0;
> >> +}
> >> +
> >> +static int
> >> +__i915_query_items(int i915, struct drm_i915_query_item *items, uint32_t
> >> n_items)
> >> +{
> >> +struct drm_i915_query q = {
> >> +.num_items = n_items,
> >> +.items_ptr = to_user_pointer(items),
> >> +};
> >> +return __i915_query(i915, );
> >> +}
> >> +
> >> +static void
> >> +i915_query_items(int i915, struct drm_i915_query_item *items, uint32_t
> >> n_items)
> >> +{
> >> +igt_assert_eq(__i915_query_items(i915, items, n_items), 0);
> >> +}
> >> +
> >> +static bool has_query(int i915)
> >> +{
> >> +struct drm_i915_query query = {};
> >> +
> >> +return __i915_query(i915, ) == 0;
> >> +}
> >> +
> >> +static bool has_engine_query(int i915)
> >> +{
> >> +struct drm_i915_query_item item = {
> >> +.query_id = DRM_I915_QUERY_ENGINE_INFO,
> >> +};
> >> +
> >> +return __i915_query_items(i915, , 1) == 0 && item.length > 0;
> >> +}
> >> +
> >> +static void query_engines(void)
> >> +{
> >
> > [...]
> >
> >> +struct drm_i915_query_engine_info *engine_info;
> >> +struct drm_i915_query_item item = {
> >> +.query_id = DRM_I915_QUERY_ENGINE_INFO,
> >> +};
> >> +const unsigned int sz = 4096;
> >> +unsigned int i;
> >> +
> >> +engine_info = malloc(sz);
> >> +igt_assert(engine_info);
> >> +memset(engine_info, 0, sz);
> >> +
> >> +item.data_ptr = to_user_pointer(engine_info);
> >> +item.length = sz;
> >> +
> >> +i915_query_items(fd, , 1);
> >> +igt_assert(item.length > 0);
> >> +igt_assert(item.length <= sz);
> >> +
> >> +num = engine_info->num_engines;
> >> +
> >> +engines = calloc(num,
> >> + sizeof(struct i915_engine_class_instance));
> >> +igt_assert(engines);
> >> +
> >> +for (i = 0; i < num; i++) {
> >> +struct drm_i915_engine_info *engine =
> >> +(struct drm_i915_engine_info
> >> *)_info->engines[i];
> >> +
> >> +engines[i] = engine->engine;
> >> +}
> >> +}
> >> +
> >> +__engines = engines;
> >> +__num_engines = num;
> >> +}
> >
> > would it make sense to make a library out of all the above? e.g.
> > gem_engine_topology does similar thing (all static functions like
> > here, though).
>
> Definitely yes, but coordinating all series seems tricky. I think best
> would be to consolidate once everything gets merged?
The challenge is carving out the core into a separate library that
doesn't pull libigt.la in. (Tvrtko has already committed the cardinal sin
of using libigt outside of tests/.) At which point, you have just a
bunch of ioctl wrappers, and fwiw some of us may wish gem_wsim itself
was a scripting engine...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 21/25] gem_wsim: Allow RCS virtual engine with SSEU control
Quoting Tvrtko Ursulin (2019-05-17 12:25:22) > From: Tvrtko Ursulin > > To allow exercising the SSEU configuration in combination with Virtual > Engine, allow RCS to be specified in the engine map and use appropriate > index based addressing when applying SSEU configuration to it. Heh, I wouldn't have even bothered filtering and let the kernel complain if it was invalid :) > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 20/25] gem_wsim: Per context SSEU control
Quoting Tvrtko Ursulin (2019-05-17 12:25:21)
> From: Tvrtko Ursulin
>
> A new workload command ('S') is added which allows per context slice
> (re-)configuration.
>
> v2:
> * Only query device SSEU on first use. (Chris)
>
> Signed-off-by: Tvrtko Ursulin
Fair enough,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 19/25] gem_wsim: Command line switch for specifying low slice count workloads
Quoting Tvrtko Ursulin (2019-05-17 12:25:20)
> From: Tvrtko Ursulin
>
> A new command line switch ('-s') is added which toggles the low slice
> count mode for workloads following on the command line.
>
> This enables easy benchmarking of the effect of running the existing media
> workloads in parallel against another client. For example:
>
> ./gem_wsim -n ... -v -r 600 -W master.wsim -s -w media_nn480.wsim
>
> Adding or removing the '-s' switch before the second workload enables
> analyzing the cost of dynamic SSEU switching impacted to the first
> (master) workload.
>
> Signed-off-by: Tvrtko Ursulin
Looks simple enough
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 16/25] gem_wsim: Engine bond command
Quoting Tvrtko Ursulin (2019-05-17 12:25:17)
> From: Tvrtko Ursulin
>
> Engine bonds are an i915 uAPI applicable to load balanced contexts with
> engine map. They allow expression rules of engine selection between two
> contexts when submissions are also tied with submit fences.
>
> Please refer to the README for a more detailed description.
>
> v2:
> * Use list of symbolic engine names instead of the mask. (Chris)
>
> Signed-off-by: Tvrtko Ursulin
> ---
> benchmarks/gem_wsim.c | 159 +++--
> benchmarks/wsim/README | 50 +
> 2 files changed, 202 insertions(+), 7 deletions(-)
>
> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> index f7f84d05010a..bd9201c2928b 100644
> --- a/benchmarks/gem_wsim.c
> +++ b/benchmarks/gem_wsim.c
> @@ -85,6 +85,7 @@ enum w_type
> PREEMPTION,
> ENGINE_MAP,
> LOAD_BALANCE,
> + BOND,
> };
>
> struct deps
> @@ -100,6 +101,11 @@ struct w_arg {
> int prio;
> };
>
> +struct bond {
> + uint64_t mask;
> + enum intel_engine_id master;
> +};
> +
> struct w_step
> {
> /* Workload step metadata */
> @@ -123,6 +129,10 @@ struct w_step
> enum intel_engine_id *engine_map;
> };
> bool load_balance;
> + struct {
> + uint64_t bond_mask;
> + enum intel_engine_id bond_master;
> + };
> };
>
> /* Implementation details */
> @@ -152,6 +162,8 @@ struct ctx {
> int priority;
> unsigned int engine_map_count;
> enum intel_engine_id *engine_map;
> + unsigned int bond_count;
> + struct bond *bonds;
> bool targets_instance;
> bool wants_balance;
> unsigned int static_vcs;
> @@ -378,6 +390,26 @@ static int parse_engine_map(struct w_step *step, const
> char *_str)
> return 0;
> }
>
> +static uint64_t engine_list_mask(const char *_str)
> +{
> + uint64_t mask = 0;
> +
> + char *token, *tctx = NULL, *tstart = (char *)_str;
> +
> + while ((token = strtok_r(tstart, "|", ))) {
> + enum intel_engine_id engine = str_to_engine(token);
> +
> + if ((int)engine < 0 || engine == DEFAULT || engine == VCS)
> + return 0;
> +
> + mask |= 1 << engine;
> +
> + tstart = NULL;
> + }
> +
> + return mask;
> +}
> +
> #define int_field(_STEP_, _FIELD_, _COND_, _ERR_) \
> if ((field = strtok_r(fstart, ".", ))) { \
> tmp = atoi(field); \
> @@ -528,6 +560,39 @@ parse_workload(struct w_arg *arg, unsigned int flags,
> struct workload *app_w)
>
> step.type = LOAD_BALANCE;
> goto add_step;
> + } else if (!strcmp(field, "b")) {
> + unsigned int nr = 0;
> + while ((field = strtok_r(fstart, ".",
> ))) {
> + check_arg(nr > 2,
> + "Invalid bond format at
> step %u!\n",
> + nr_steps);
> +
> + if (nr == 0) {
> + tmp = atoi(field);
> + step.context = tmp;
> + check_arg(tmp <= 0,
> + "Invalid context at
> step %u!\n",
> + nr_steps);
> + } else if (nr == 1) {
> + step.bond_mask =
> engine_list_mask(field);
> + check_arg(step.bond_mask == 0,
> + "Invalid siblings
> list at step %u!\n",
> + nr_steps);
> + } else if (nr == 2) {
> + tmp = str_to_engine(field);
> + check_arg(tmp <= 0 ||
> + tmp == VCS ||
> + tmp == DEFAULT,
> + "Invalid master
> engine at step %u!\n",
> + nr_steps);
> + step.bond_master = tmp;
> + }
> +
> + nr++;
> + }
> +
> + step.type = BOND;
> + goto add_step;
> }
>
>
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/gvt: Set return value for ppgtt_populate error path
== Series Details ==
Series: series starting with [1/3] drm/i915/gvt: Set return value for
ppgtt_populate error path
URL : https://patchwork.freedesktop.org/series/60769/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6093_full -> Patchwork_13030_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_13030_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-snb: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
Known issues
Here are the changes found in Patchwork_13030_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@legacy-planes:
- shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-apl6/igt@i915_pm_...@legacy-planes.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-apl1/igt@i915_pm_...@legacy-planes.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +6
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-apl1/igt@i915_susp...@debugfs-reader.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-apl4/igt@i915_susp...@debugfs-reader.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-skl6/igt@i915_susp...@sysfs-reader.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-skl10/igt@i915_susp...@sysfs-reader.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#105767])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103184] / [fdo#103232]
/ [fdo#108472])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-skl3/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-skl9/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-glk: [PASS][13] -> [FAIL][14] ([fdo#100368])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-glk6/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-glk8/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167] / [fdo#110378])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-render:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#103167])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-render.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-render.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
[22]:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 15/25] gem_wsim: Engine map load balance command
Quoting Tvrtko Ursulin (2019-05-17 12:25:16) > From: Tvrtko Ursulin > > A new workload command for enabling a load balanced context map (aka > Virtual Engine). Example usage: > > B.1 > > This turns on load balancing for context one, assuming it has already been > configured with an engine map. Only DEFAULT engine specifier can be used > with load balanced engine maps. Why? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 12/25] gem_wsim: Engine map support
Quoting Tvrtko Ursulin (2019-05-17 12:25:13)
> From: Tvrtko Ursulin
>
> Support new i915 uAPI for configuring contexts with engine maps.
>
> Please refer to the README file for more detailed explanation.
>
> v2:
> * Allow defining engine maps by class.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> benchmarks/gem_wsim.c | 211 +++--
> benchmarks/wsim/README | 25 -
> 2 files changed, 204 insertions(+), 32 deletions(-)
>
> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> index 60b7d32e22d4..e5b12e37490e 100644
> --- a/benchmarks/gem_wsim.c
> +++ b/benchmarks/gem_wsim.c
> @@ -57,6 +57,7 @@
> #include "ewma.h"
>
> enum intel_engine_id {
> + DEFAULT,
> RCS,
> BCS,
> VCS,
> @@ -81,7 +82,8 @@ enum w_type
> SW_FENCE,
> SW_FENCE_SIGNAL,
> CTX_PRIORITY,
> - PREEMPTION
> + PREEMPTION,
> + ENGINE_MAP
> };
>
> struct deps
> @@ -115,6 +117,10 @@ struct w_step
> int throttle;
> int fence_signal;
> int priority;
> + struct {
> + unsigned int engine_map_count;
> + enum intel_engine_id *engine_map;
> + };
> };
>
> /* Implementation details */
> @@ -142,6 +148,8 @@ DECLARE_EWMA(uint64_t, rt, 4, 2)
> struct ctx {
> uint32_t id;
> int priority;
> + unsigned int engine_map_count;
> + enum intel_engine_id *engine_map;
> bool targets_instance;
> bool wants_balance;
> unsigned int static_vcs;
> @@ -200,10 +208,10 @@ struct workload
> int fd;
> bool first;
> unsigned int num_engines;
> - unsigned int engine_map[5];
> + unsigned int engine_map[NUM_ENGINES];
> uint64_t t_prev;
> - uint64_t prev[5];
> - double busy[5];
> + uint64_t prev[NUM_ENGINES];
> + double busy[NUM_ENGINES];
> } busy_balancer;
> };
>
> @@ -234,6 +242,7 @@ static int fd;
> #define REG(x) (volatile uint32_t *)((volatile char *)igt_global_mmio + x)
>
> static const char *ring_str_map[NUM_ENGINES] = {
> + [DEFAULT] = "DEFAULT",
> [RCS] = "RCS",
> [BCS] = "BCS",
> [VCS] = "VCS",
> @@ -330,6 +339,43 @@ static int str_to_engine(const char *str)
> return -1;
> }
>
> +static int parse_engine_map(struct w_step *step, const char *_str)
> +{
> + char *token, *tctx = NULL, *tstart = (char *)_str;
> +
> + while ((token = strtok_r(tstart, "|", ))) {
> + enum intel_engine_id engine;
> + unsigned int add;
> +
> + tstart = NULL;
> +
> + if (!strcmp(token, "DEFAULT"))
> + return -1;
> +
> + engine = str_to_engine(token);
> + if ((int)engine < 0)
> + return -1;
> +
> + if (engine != VCS && engine != VCS1 && engine != VCS2)
> + return -1; /* TODO */
Still a little concerned that the map is VCS only. It just doesn't fit
my expectations of what the map will be.
> +
> + add = engine == VCS ? 2 : 1;
Will we not every ask what happens if we had millions of engines at our
disposal. But that's a tommorrow problem, ok.
> + step->engine_map_count += add;
> + step->engine_map = realloc(step->engine_map,
> + step->engine_map_count *
> + sizeof(step->engine_map[0]));
> +
> + if (engine != VCS) {
> + step->engine_map[step->engine_map_count - 1] = engine;
> + } else {
> + step->engine_map[step->engine_map_count - 2] = VCS1;
> + step->engine_map[step->engine_map_count - 1] = VCS2;
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct workload *
> parse_workload(struct w_arg *arg, unsigned int flags, struct workload *app_w)
> {
> @@ -448,6 +494,33 @@ parse_workload(struct w_arg *arg, unsigned int flags,
> struct workload *app_w)
> } else if (!strcmp(field, "f")) {
> step.type = SW_FENCE;
> goto add_step;
> + } else if (!strcmp(field, "M")) {
> + unsigned int nr = 0;
> + while ((field = strtok_r(fstart, ".", ))
> !=
> + NULL) {
> + tmp = atoi(field);
> + check_arg(nr == 0 && tmp <= 0,
> + "Invalid context at step
> %u!\n",
> + nr_steps);
> +
[Intel-gfx] [PATCH 13/14] drm/i915: Make state dumpers take a const state
From: Ville Syrjälä
Constify a bunch of the arguments of various state dumping
functions. Makes it clear they don't mutate the states.
And fix up some indent fails while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 20 +++-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
3 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe8dc7939529..0fa0fc54cc4f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11388,17 +11388,19 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
static void intel_dump_crtc_timings(const struct drm_display_mode *mode)
{
DRM_DEBUG_KMS("crtc timings: %d %d %d %d %d %d %d %d %d, "
- "type: 0x%x flags: 0x%x\n",
- mode->crtc_clock,
- mode->crtc_hdisplay, mode->crtc_hsync_start,
- mode->crtc_hsync_end, mode->crtc_htotal,
- mode->crtc_vdisplay, mode->crtc_vsync_start,
- mode->crtc_vsync_end, mode->crtc_vtotal, mode->type,
mode->flags);
+ "type: 0x%x flags: 0x%x\n",
+ mode->crtc_clock,
+ mode->crtc_hdisplay, mode->crtc_hsync_start,
+ mode->crtc_hsync_end, mode->crtc_htotal,
+ mode->crtc_vdisplay, mode->crtc_vsync_start,
+ mode->crtc_vsync_end, mode->crtc_vtotal,
+ mode->type, mode->flags);
}
static inline void
-intel_dump_m_n_config(struct intel_crtc_state *pipe_config, char *id,
- unsigned int lane_count, struct intel_link_m_n *m_n)
+intel_dump_m_n_config(const struct intel_crtc_state *pipe_config,
+ const char *id, unsigned int lane_count,
+ const struct intel_link_m_n *m_n)
{
DRM_DEBUG_KMS("%s: lanes: %i; gmch_m: %u, gmch_n: %u, link_m: %u,
link_n: %u, tu: %u\n",
id, lane_count,
@@ -11476,7 +11478,7 @@ static const char *output_formats(enum
intel_output_format format)
return output_format_str[format];
}
-static void intel_dump_pipe_config(struct intel_crtc_state *pipe_config,
+static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config,
const char *context)
{
struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 897d93537414..69787f259677 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -454,7 +454,7 @@ ibx_get_dpll(struct intel_crtc_state *crtc_state,
}
static void ibx_dump_hw_state(struct drm_i915_private *dev_priv,
- struct intel_dpll_hw_state *hw_state)
+ const struct intel_dpll_hw_state *hw_state)
{
DRM_DEBUG_KMS("dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, "
"fp0: 0x%x, fp1: 0x%x\n",
@@ -856,7 +856,7 @@ hsw_get_dpll(struct intel_crtc_state *crtc_state,
}
static void hsw_dump_hw_state(struct drm_i915_private *dev_priv,
- struct intel_dpll_hw_state *hw_state)
+ const struct intel_dpll_hw_state *hw_state)
{
DRM_DEBUG_KMS("dpll_hw_state: wrpll: 0x%x spll: 0x%x\n",
hw_state->wrpll, hw_state->spll);
@@ -1425,7 +1425,7 @@ skl_get_dpll(struct intel_crtc_state *crtc_state,
}
static void skl_dump_hw_state(struct drm_i915_private *dev_priv,
- struct intel_dpll_hw_state *hw_state)
+ const struct intel_dpll_hw_state *hw_state)
{
DRM_DEBUG_KMS("dpll_hw_state: "
"ctrl1: 0x%x, cfgcr1: 0x%x, cfgcr2: 0x%x\n",
@@ -1857,7 +1857,7 @@ bxt_get_dpll(struct intel_crtc_state *crtc_state,
}
static void bxt_dump_hw_state(struct drm_i915_private *dev_priv,
- struct intel_dpll_hw_state *hw_state)
+ const struct intel_dpll_hw_state *hw_state)
{
DRM_DEBUG_KMS("dpll_hw_state: ebb0: 0x%x, ebb4: 0x%x,"
"pll0: 0x%x, pll1: 0x%x, pll2: 0x%x, pll3: 0x%x, "
@@ -1888,7 +1888,7 @@ struct intel_dpll_mgr {
struct intel_encoder *encoder);
void (*dump_hw_state)(struct drm_i915_private *dev_priv,
- struct intel_dpll_hw_state *hw_state);
+ const struct intel_dpll_hw_state *hw_state);
};
static const struct dpll_info pch_plls[] = {
@@ -2371,7 +2371,7 @@ cnl_get_dpll(struct intel_crtc_state *crtc_state,
}
static void cnl_dump_hw_state(struct drm_i915_private *dev_priv,
- struct intel_dpll_hw_state *hw_state)
+
[Intel-gfx] [PATCH 14/14] drm/i915: Fix plane state dumps
From: Ville Syrjälä
Stop dumping plane->state for planes. That is the old state most of the
time and dumping stale information only serves to confuse people.
Instead dump the new state just for the planes included in the
operation. For now we'll include only the planes for the modeset/fastset
pipes in the dumps. But probably we want to dump them all eventually,
just not quite sure how to present that information nicely to the user.
And while at it let's dump a few more interesting bits from the state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 84 +++-
1 file changed, 45 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0fa0fc54cc4f..4320d3f55b85 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11478,22 +11478,50 @@ static const char *output_formats(enum
intel_output_format format)
return output_format_str[format];
}
+static void intel_dump_plane_state(const struct intel_plane_state *plane_state)
+{
+ struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+ const struct drm_framebuffer *fb = plane_state->base.fb;
+ struct drm_format_name_buf format_name;
+
+ if (!fb) {
+ DRM_DEBUG_KMS("[PLANE:%d:%s] fb: [NOFB], visible: %s\n",
+ plane->base.base.id, plane->base.name,
+ yesno(plane_state->base.visible));
+ return;
+ }
+
+ DRM_DEBUG_KMS("[PLANE:%d:%s] fb: [FB:%d] %ux%u format = %s, visible:
%s\n",
+ plane->base.base.id, plane->base.name,
+ fb->base.id, fb->width, fb->height,
+ drm_get_format_name(fb->format->format, _name),
+ yesno(plane_state->base.visible));
+ DRM_DEBUG_KMS("\trotation: 0x%x, scaler: %d\n",
+ plane_state->base.rotation, plane_state->scaler_id);
+ if (plane_state->base.visible)
+ DRM_DEBUG_KMS("\tsrc: " DRM_RECT_FP_FMT " dst: " DRM_RECT_FMT
"\n",
+ DRM_RECT_FP_ARG(_state->base.src),
+ DRM_RECT_ARG(_state->base.dst));
+}
+
static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config,
+ struct intel_atomic_state *state,
const char *context)
{
struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_plane *plane;
- struct intel_plane *intel_plane;
- struct intel_plane_state *state;
- struct drm_framebuffer *fb;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct intel_plane_state *plane_state;
+ struct intel_plane *plane;
char buf[64];
+ int i;
DRM_DEBUG_KMS("[CRTC:%d:%s] enable: %s %s\n",
crtc->base.base.id, crtc->base.name,
yesno(pipe_config->base.enable), context);
+ if (!pipe_config->base.enable)
+ goto dump_planes;
+
snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
DRM_DEBUG_KMS("active: %s, output_types: %s (0x%x), output format:
%s\n",
yesno(pipe_config->base.active),
@@ -11568,35 +11596,13 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
intel_dpll_dump_hw_state(dev_priv, _config->dpll_hw_state);
- DRM_DEBUG_KMS("planes on this crtc\n");
- list_for_each_entry(plane, >mode_config.plane_list, head) {
- struct drm_format_name_buf format_name;
- intel_plane = to_intel_plane(plane);
- if (intel_plane->pipe != crtc->pipe)
- continue;
-
- state = to_intel_plane_state(plane->state);
- fb = state->base.fb;
- if (!fb) {
- DRM_DEBUG_KMS("[PLANE:%d:%s] disabled, scaler_id =
%d\n",
- plane->base.id, plane->name,
state->scaler_id);
- continue;
- }
+dump_planes:
+ if (!state)
+ return;
- DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d, fb = %ux%u format = %s\n",
- plane->base.id, plane->name,
- fb->base.id, fb->width, fb->height,
- drm_get_format_name(fb->format->format,
_name));
- if (INTEL_GEN(dev_priv) >= 9)
- DRM_DEBUG_KMS("\tscaler:%d src %dx%d+%d+%d dst
%dx%d+%d+%d\n",
- state->scaler_id,
- state->base.src.x1 >> 16,
- state->base.src.y1 >> 16,
-
[Intel-gfx] [PATCH 09/14] drm/i915: Use intel_ types in intel_atomic_check()
From: Ville Syrjälä
Switch to using intel_ types instead of drm_ types. Avoids
ugly casts and nasty aliasing variables with different types.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 66 +---
1 file changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b770ee28cdcc..e71a90a47d3a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13034,85 +13034,81 @@ static int calc_watermark_data(struct
intel_atomic_state *state)
* @state: state to validate
*/
static int intel_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
+ struct drm_atomic_state *_state)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct drm_crtc *crtc;
- struct drm_crtc_state *old_crtc_state, *crtc_state;
+ struct intel_atomic_state *state = to_intel_atomic_state(_state);
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_crtc *crtc;
int ret, i;
- bool any_ms = intel_state->cdclk.force_min_cdclk_changed;
+ bool any_ms = state->cdclk.force_min_cdclk_changed;
/* Catch I915_MODE_FLAG_INHERITED */
- for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
- crtc_state, i) {
- if (crtc_state->mode.private_flags !=
- old_crtc_state->mode.private_flags)
- crtc_state->mode_changed = true;
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (new_crtc_state->base.mode.private_flags !=
+ old_crtc_state->base.mode.private_flags)
+ new_crtc_state->base.mode_changed = true;
}
- ret = drm_atomic_helper_check_modeset(dev, state);
+ ret = drm_atomic_helper_check_modeset(dev, >base);
if (ret)
return ret;
- for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, crtc_state,
i) {
- struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc_state);
-
- if (!needs_modeset(crtc_state))
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (!needs_modeset(_crtc_state->base))
continue;
- if (!crtc_state->enable) {
+ if (!new_crtc_state->base.enable) {
any_ms = true;
continue;
}
- ret = intel_modeset_pipe_config(pipe_config);
+ ret = intel_modeset_pipe_config(new_crtc_state);
if (ret == -EDEADLK)
return ret;
if (ret) {
- intel_dump_pipe_config(pipe_config, "[failed]");
+ intel_dump_pipe_config(new_crtc_state, "[failed]");
return ret;
}
- if (intel_pipe_config_compare(dev_priv,
- to_intel_crtc_state(old_crtc_state),
- pipe_config, true)) {
- crtc_state->mode_changed = false;
- pipe_config->update_pipe = true;
+ if (intel_pipe_config_compare(dev_priv, old_crtc_state,
+ new_crtc_state, true)) {
+ new_crtc_state->base.mode_changed = false;
+ new_crtc_state->update_pipe = true;
}
- if (needs_modeset(crtc_state))
+ if (needs_modeset(_crtc_state->base))
any_ms = true;
- intel_dump_pipe_config(pipe_config,
- needs_modeset(crtc_state) ?
+ intel_dump_pipe_config(new_crtc_state,
+ needs_modeset(_crtc_state->base) ?
"[modeset]" : "[fastset]");
}
- ret = drm_dp_mst_atomic_check(state);
+ ret = drm_dp_mst_atomic_check(>base);
if (ret)
return ret;
if (any_ms) {
- ret = intel_modeset_checks(intel_state);
-
+ ret = intel_modeset_checks(state);
if (ret)
return ret;
} else {
- intel_state->cdclk.logical = dev_priv->cdclk.logical;
+ state->cdclk.logical = dev_priv->cdclk.logical;
}
- ret = icl_add_linked_planes(intel_state);
+ ret = icl_add_linked_planes(state);
if (ret)
[Intel-gfx] [PATCH 12/14] drm/i915: Dump failed crtc states during atomic check
From: Ville Syrjälä
Currently we're only dumping the failed crtc state if
intel_modeset_pipe_config() fails. Let's do the state
dump if anything else fails afterwards. The downside
is that we lose the immediate knowledge which crtc caused
the failure (unless a lower level function indicates it
with an additional debug print) but having the full state
dumped seems like something that could be beneficial.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 34 ++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 59b012be9a4f..fe8dc7939529 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13051,7 +13051,7 @@ static int intel_atomic_check(struct drm_device *dev,
ret = drm_atomic_helper_check_modeset(dev, >base);
if (ret)
- return ret;
+ goto fail;
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -13064,12 +13064,8 @@ static int intel_atomic_check(struct drm_device *dev,
}
ret = intel_modeset_pipe_config(new_crtc_state);
- if (ret == -EDEADLK)
- return ret;
- if (ret) {
- intel_dump_pipe_config(new_crtc_state, "[failed]");
- return ret;
- }
+ if (ret)
+ goto fail;
if (intel_pipe_config_compare(dev_priv, old_crtc_state,
new_crtc_state, true)) {
@@ -13083,29 +13079,29 @@ static int intel_atomic_check(struct drm_device *dev,
ret = drm_dp_mst_atomic_check(>base);
if (ret)
- return ret;
+ goto fail;
if (any_ms) {
ret = intel_modeset_checks(state);
if (ret)
- return ret;
+ goto fail;
} else {
state->cdclk.logical = dev_priv->cdclk.logical;
}
ret = icl_add_linked_planes(state);
if (ret)
- return ret;
+ goto fail;
ret = drm_atomic_helper_check_planes(dev, >base);
if (ret)
- return ret;
+ goto fail;
intel_fbc_choose_crtc(dev_priv, state);
ret = calc_watermark_data(state);
if (ret)
- return ret;
+ goto fail;
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -13119,6 +13115,20 @@ static int intel_atomic_check(struct drm_device *dev,
}
return 0;
+
+ fail:
+ if (ret == -EDEADLK)
+ return ret;
+
+ /*
+* FIXME would probably be nice to know which crtc specifically
+* caused the failure, in cases where we can pinpoint it.
+*/
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i)
+ intel_dump_pipe_config(new_crtc_state, "[failed]");
+
+ return ret;
}
static int intel_atomic_prepare_commit(struct drm_device *dev,
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/14] drm/i915: Include crtc_state.active in crtc state dumps
From: Ville Syrjälä
Currently we're not dumping out whether the crtc is actually
active or in dpms off state. Let's include that in the dumps.
And while at it compress out a few lines from the state dump.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5ffb4f5c4fa7..59b012be9a4f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11493,10 +11493,9 @@ static void intel_dump_pipe_config(struct
intel_crtc_state *pipe_config,
yesno(pipe_config->base.enable), context);
snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
- DRM_DEBUG_KMS("output_types: %s (0x%x)\n",
- buf, pipe_config->output_types);
-
- DRM_DEBUG_KMS("output format: %s\n",
+ DRM_DEBUG_KMS("active: %s, output_types: %s (0x%x), output format:
%s\n",
+ yesno(pipe_config->base.active),
+ buf, pipe_config->output_types,
output_formats(pipe_config->output_format));
DRM_DEBUG_KMS("cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
@@ -11517,10 +11516,8 @@ static void intel_dump_pipe_config(struct
intel_crtc_state *pipe_config,
_config->dp_m2_n2);
}
- DRM_DEBUG_KMS("audio: %i, infoframes: %i\n",
- pipe_config->has_audio, pipe_config->has_infoframe);
-
- DRM_DEBUG_KMS("infoframes enabled: 0x%x\n",
+ DRM_DEBUG_KMS("audio: %i, infoframes: %i, infoframes enabled: 0x%x\n",
+ pipe_config->has_audio, pipe_config->has_infoframe,
pipe_config->infoframes.enable);
if (pipe_config->infoframes.enable &
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/14] drm/i915: Don't pass the crtc to intel_modeset_pipe_config()
From: Ville Syrjälä
We already pass the crtc's state to intel_modeset_pipe_config()
so passing the crtc as well is redundant.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0e509f5a28a3..192f548b24ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11700,9 +11700,9 @@ clear_intel_crtc_state(struct intel_crtc_state
*crtc_state)
}
static int
-intel_modeset_pipe_config(struct drm_crtc *crtc,
- struct intel_crtc_state *pipe_config)
+intel_modeset_pipe_config(struct intel_crtc_state *pipe_config)
{
+ struct drm_crtc *crtc = pipe_config->base.crtc;
struct drm_atomic_state *state = pipe_config->base.state;
struct intel_encoder *encoder;
struct drm_connector *connector;
@@ -13068,7 +13068,7 @@ static int intel_atomic_check(struct drm_device *dev,
continue;
}
- ret = intel_modeset_pipe_config(crtc, pipe_config);
+ ret = intel_modeset_pipe_config(pipe_config);
if (ret == -EDEADLK)
return ret;
if (ret) {
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/14] drm/i915: Use intel_ types in intel_modeset_clear_plls()
From: Ville Syrjälä
Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 19f01984c550..ca5ef83fc9e0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12769,31 +12769,30 @@ static void update_scanline_offset(const struct
intel_crtc_state *crtc_state)
crtc->scanline_offset = 1;
}
-static void intel_modeset_clear_plls(struct drm_atomic_state *state)
+static void intel_modeset_clear_plls(struct intel_atomic_state *state)
{
- struct drm_device *dev = state->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_crtc *crtc;
- struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_crtc *crtc;
int i;
if (!dev_priv->display.crtc_compute_clock)
return;
- for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
struct intel_shared_dpll *old_dpll =
- to_intel_crtc_state(old_crtc_state)->shared_dpll;
+ old_crtc_state->shared_dpll;
- if (!needs_modeset(new_crtc_state))
+ if (!needs_modeset(_crtc_state->base))
continue;
- to_intel_crtc_state(new_crtc_state)->shared_dpll = NULL;
+ new_crtc_state->shared_dpll = NULL;
if (!old_dpll)
continue;
- intel_release_shared_dpll(old_dpll, intel_crtc, state);
+ intel_release_shared_dpll(old_dpll, crtc, >base);
}
}
@@ -13011,7 +13010,7 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
intel_state->cdclk.actual.voltage_level);
}
- intel_modeset_clear_plls(state);
+ intel_modeset_clear_plls(intel_state);
if (IS_HASWELL(dev_priv))
return haswell_mode_set_planes_workaround(state);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/14] drm/i915: Pass intel_atomic state to check_digital_port_conflicts()
From: Ville Syrjälä
Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 273ca87ccf8b..19f01984c550 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11600,9 +11600,9 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
}
}
-static bool check_digital_port_conflicts(struct drm_atomic_state *state)
+static bool check_digital_port_conflicts(struct intel_atomic_state *state)
{
- struct drm_device *dev = state->dev;
+ struct drm_device *dev = state->base.dev;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
unsigned int used_ports = 0;
@@ -11619,7 +11619,9 @@ static bool check_digital_port_conflicts(struct
drm_atomic_state *state)
struct drm_connector_state *connector_state;
struct intel_encoder *encoder;
- connector_state = drm_atomic_get_new_connector_state(state,
connector);
+ connector_state =
+ drm_atomic_get_new_connector_state(>base,
+ connector);
if (!connector_state)
connector_state = connector->state;
@@ -12917,7 +12919,7 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
int ret = 0, i;
- if (!check_digital_port_conflicts(state)) {
+ if (!check_digital_port_conflicts(intel_state)) {
DRM_DEBUG_KMS("rejecting conflicting digital port
configuration\n");
return -EINVAL;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/14] drm/i915: Pass intel_atomic_state to cdclk funcs
From: Ville Syrjälä
Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_cdclk.c | 167 ---
drivers/gpu/drm/i915/intel_display.c | 2 +-
3 files changed, 79 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5801f5407589..7ac8d97517df 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -298,7 +298,7 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *cstate);
int (*compute_global_watermarks)(struct intel_atomic_state *state);
void (*update_wm)(struct intel_crtc *crtc);
- int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
+ int (*modeset_calc_cdclk)(struct intel_atomic_state *state);
/* Returns the active state of the crtc, and if the crtc is active,
* fills out the pipe-config with the hw state. */
bool (*get_pipe_config)(struct intel_crtc *,
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 78d9f619956c..6e712fec925f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2283,29 +2283,28 @@ int intel_crtc_compute_min_cdclk(const struct
intel_crtc_state *crtc_state)
return min_cdclk;
}
-static int intel_compute_min_cdclk(struct drm_atomic_state *state)
+static int intel_compute_min_cdclk(struct intel_atomic_state *state)
{
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct drm_i915_private *dev_priv = to_i915(state->dev);
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc *crtc;
struct intel_crtc_state *crtc_state;
int min_cdclk, i;
enum pipe pipe;
- memcpy(intel_state->min_cdclk, dev_priv->min_cdclk,
- sizeof(intel_state->min_cdclk));
+ memcpy(state->min_cdclk, dev_priv->min_cdclk,
+ sizeof(state->min_cdclk));
- for_each_new_intel_crtc_in_state(intel_state, crtc, crtc_state, i) {
+ for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
min_cdclk = intel_crtc_compute_min_cdclk(crtc_state);
if (min_cdclk < 0)
return min_cdclk;
- intel_state->min_cdclk[i] = min_cdclk;
+ state->min_cdclk[i] = min_cdclk;
}
- min_cdclk = intel_state->cdclk.force_min_cdclk;
+ min_cdclk = state->cdclk.force_min_cdclk;
for_each_pipe(dev_priv, pipe)
- min_cdclk = max(intel_state->min_cdclk[pipe], min_cdclk);
+ min_cdclk = max(state->min_cdclk[pipe], min_cdclk);
return min_cdclk;
}
@@ -2347,10 +2346,9 @@ static u8 cnl_compute_min_voltage_level(struct
intel_atomic_state *state)
return min_voltage_level;
}
-static int vlv_modeset_calc_cdclk(struct drm_atomic_state *state)
+static int vlv_modeset_calc_cdclk(struct intel_atomic_state *state)
{
- struct drm_i915_private *dev_priv = to_i915(state->dev);
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
int min_cdclk, cdclk;
min_cdclk = intel_compute_min_cdclk(state);
@@ -2359,28 +2357,25 @@ static int vlv_modeset_calc_cdclk(struct
drm_atomic_state *state)
cdclk = vlv_calc_cdclk(dev_priv, min_cdclk);
- intel_state->cdclk.logical.cdclk = cdclk;
- intel_state->cdclk.logical.voltage_level =
+ state->cdclk.logical.cdclk = cdclk;
+ state->cdclk.logical.voltage_level =
vlv_calc_voltage_level(dev_priv, cdclk);
- if (!intel_state->active_crtcs) {
- cdclk = vlv_calc_cdclk(dev_priv,
- intel_state->cdclk.force_min_cdclk);
+ if (!state->active_crtcs) {
+ cdclk = vlv_calc_cdclk(dev_priv, state->cdclk.force_min_cdclk);
- intel_state->cdclk.actual.cdclk = cdclk;
- intel_state->cdclk.actual.voltage_level =
+ state->cdclk.actual.cdclk = cdclk;
+ state->cdclk.actual.voltage_level =
vlv_calc_voltage_level(dev_priv, cdclk);
} else {
- intel_state->cdclk.actual =
- intel_state->cdclk.logical;
+ state->cdclk.actual = state->cdclk.logical;
}
return 0;
}
-static int bdw_modeset_calc_cdclk(struct drm_atomic_state *state)
+static int bdw_modeset_calc_cdclk(struct intel_atomic_state *state)
{
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
int min_cdclk, cdclk;
min_cdclk = intel_compute_min_cdclk(state);
@@ -2393,36 +2388,35
[Intel-gfx] [PATCH 10/14] drm/i915: Move state dump to the end of atomic_check()
From: Ville Syrjälä
Currently we're dumping the crtc states before they have
been fully calculated. Move the dumping to the end of
.atomic_check() so we get a fully up to date dump.
Let's also do the dump for fully disabled pipes, but we'll
limit that to just saying that the pipe is disabled since
the rest of the state is going to be nonsense in that case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e71a90a47d3a..5ffb4f5c4fa7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11488,8 +11488,9 @@ static void intel_dump_pipe_config(struct
intel_crtc_state *pipe_config,
struct drm_framebuffer *fb;
char buf[64];
- DRM_DEBUG_KMS("[CRTC:%d:%s]%s\n",
- crtc->base.base.id, crtc->base.name, context);
+ DRM_DEBUG_KMS("[CRTC:%d:%s] enable: %s %s\n",
+ crtc->base.base.id, crtc->base.name,
+ yesno(pipe_config->base.enable), context);
snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
DRM_DEBUG_KMS("output_types: %s (0x%x)\n",
@@ -13081,10 +13082,6 @@ static int intel_atomic_check(struct drm_device *dev,
if (needs_modeset(_crtc_state->base))
any_ms = true;
-
- intel_dump_pipe_config(new_crtc_state,
- needs_modeset(_crtc_state->base) ?
- "[modeset]" : "[fastset]");
}
ret = drm_dp_mst_atomic_check(>base);
@@ -13108,7 +13105,23 @@ static int intel_atomic_check(struct drm_device *dev,
return ret;
intel_fbc_choose_crtc(dev_priv, state);
- return calc_watermark_data(state);
+
+ ret = calc_watermark_data(state);
+ if (ret)
+ return ret;
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (!needs_modeset(_crtc_state->base) &&
+ !new_crtc_state->update_pipe)
+ continue;
+
+ intel_dump_pipe_config(new_crtc_state,
+ needs_modeset(_crtc_state->base) ?
+ "[modeset]" : "[fastset]");
+ }
+
+ return 0;
}
static int intel_atomic_prepare_commit(struct drm_device *dev,
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/14] drm/i915: Clean up cdclk vfunc assignments
From: Ville Syrjälä
Thanks to using the short names for platoforms all the cdclk
vfunc assignemtns now fit within 80 cols. Remove the extra
line wraps.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 6e712fec925f..6988c6cbc362 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2801,28 +2801,22 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = icl_modeset_calc_cdclk;
} else if (IS_CANNONLAKE(dev_priv)) {
dev_priv->display.set_cdclk = cnl_set_cdclk;
- dev_priv->display.modeset_calc_cdclk =
- cnl_modeset_calc_cdclk;
+ dev_priv->display.modeset_calc_cdclk = cnl_modeset_calc_cdclk;
} else if (IS_GEN9_LP(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
- dev_priv->display.modeset_calc_cdclk =
- bxt_modeset_calc_cdclk;
+ dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
} else if (IS_GEN9_BC(dev_priv)) {
dev_priv->display.set_cdclk = skl_set_cdclk;
- dev_priv->display.modeset_calc_cdclk =
- skl_modeset_calc_cdclk;
+ dev_priv->display.modeset_calc_cdclk = skl_modeset_calc_cdclk;
} else if (IS_BROADWELL(dev_priv)) {
dev_priv->display.set_cdclk = bdw_set_cdclk;
- dev_priv->display.modeset_calc_cdclk =
- bdw_modeset_calc_cdclk;
+ dev_priv->display.modeset_calc_cdclk = bdw_modeset_calc_cdclk;
} else if (IS_CHERRYVIEW(dev_priv)) {
dev_priv->display.set_cdclk = chv_set_cdclk;
- dev_priv->display.modeset_calc_cdclk =
- vlv_modeset_calc_cdclk;
+ dev_priv->display.modeset_calc_cdclk = vlv_modeset_calc_cdclk;
} else if (IS_VALLEYVIEW(dev_priv)) {
dev_priv->display.set_cdclk = vlv_set_cdclk;
- dev_priv->display.modeset_calc_cdclk =
- vlv_modeset_calc_cdclk;
+ dev_priv->display.modeset_calc_cdclk = vlv_modeset_calc_cdclk;
}
if (INTEL_GEN(dev_priv) >= 11)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/14] drm/i915: Use intel_ types in intel_modeset_checks()
From: Ville Syrjälä
Switch to using intel_ types instead of drm_ types. Avoids
ugly casts and nasty aliasing variables with different types.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 77 ++--
1 file changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 192f548b24ed..b770ee28cdcc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12904,38 +12904,37 @@ static int intel_modeset_all_pipes(struct
drm_atomic_state *state)
return 0;
}
-static int intel_modeset_checks(struct drm_atomic_state *state)
+static int intel_modeset_checks(struct intel_atomic_state *state)
{
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct drm_i915_private *dev_priv = to_i915(state->dev);
- struct drm_crtc *crtc;
- struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_crtc *crtc;
int ret = 0, i;
- if (!check_digital_port_conflicts(intel_state)) {
+ if (!check_digital_port_conflicts(state)) {
DRM_DEBUG_KMS("rejecting conflicting digital port
configuration\n");
return -EINVAL;
}
/* keep the current setting */
- if (!intel_state->cdclk.force_min_cdclk_changed)
- intel_state->cdclk.force_min_cdclk =
- dev_priv->cdclk.force_min_cdclk;
+ if (!state->cdclk.force_min_cdclk_changed)
+ state->cdclk.force_min_cdclk = dev_priv->cdclk.force_min_cdclk;
- intel_state->modeset = true;
- intel_state->active_crtcs = dev_priv->active_crtcs;
- intel_state->cdclk.logical = dev_priv->cdclk.logical;
- intel_state->cdclk.actual = dev_priv->cdclk.actual;
- intel_state->cdclk.pipe = INVALID_PIPE;
+ state->modeset = true;
+ state->active_crtcs = dev_priv->active_crtcs;
+ state->cdclk.logical = dev_priv->cdclk.logical;
+ state->cdclk.actual = dev_priv->cdclk.actual;
+ state->cdclk.pipe = INVALID_PIPE;
- for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- if (new_crtc_state->active)
- intel_state->active_crtcs |= 1 << i;
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (new_crtc_state->base.active)
+ state->active_crtcs |= 1 << i;
else
- intel_state->active_crtcs &= ~(1 << i);
+ state->active_crtcs &= ~(1 << i);
- if (old_crtc_state->active != new_crtc_state->active)
- intel_state->active_pipe_changes |= drm_crtc_mask(crtc);
+ if (old_crtc_state->base.active != new_crtc_state->base.active)
+ state->active_pipe_changes |=
drm_crtc_mask(>base);
}
/*
@@ -12948,7 +12947,7 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
if (dev_priv->display.modeset_calc_cdclk) {
enum pipe pipe;
- ret = dev_priv->display.modeset_calc_cdclk(intel_state);
+ ret = dev_priv->display.modeset_calc_cdclk(state);
if (ret < 0)
return ret;
@@ -12958,19 +12957,19 @@ static int intel_modeset_checks(struct
drm_atomic_state *state)
* touching the hardware
*/
if (intel_cdclk_changed(_priv->cdclk.logical,
- _state->cdclk.logical)) {
- ret = intel_lock_all_pipes(state);
+ >cdclk.logical)) {
+ ret = intel_lock_all_pipes(>base);
if (ret < 0)
return ret;
}
- if (is_power_of_2(intel_state->active_crtcs)) {
+ if (is_power_of_2(state->active_crtcs)) {
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
- pipe = ilog2(intel_state->active_crtcs);
+ pipe = ilog2(state->active_crtcs);
crtc = _get_crtc_for_pipe(dev_priv, pipe)->base;
- crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ crtc_state =
drm_atomic_get_new_crtc_state(>base, crtc);
if (crtc_state && needs_modeset(crtc_state))
pipe = INVALID_PIPE;
} else {
@@ -12981,33 +12980,33 @@ static int intel_modeset_checks(struct
drm_atomic_state *state)
if (pipe !=
[Intel-gfx] [PATCH 05/14] drm/i915: Use intel_ types in haswell_mode_set_planes_workaround()
From: Ville Syrjälä
Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 40 +---
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ca5ef83fc9e0..dddc9a8cffa1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12802,29 +12802,27 @@ static void intel_modeset_clear_plls(struct
intel_atomic_state *state)
* multiple pipes, and planes are enabled after the pipe, we need to wait at
* least 2 vblanks on the first pipe before enabling planes on the second pipe.
*/
-static int haswell_mode_set_planes_workaround(struct drm_atomic_state *state)
+static int haswell_mode_set_planes_workaround(struct intel_atomic_state *state)
{
- struct drm_crtc_state *crtc_state;
- struct intel_crtc *intel_crtc;
- struct drm_crtc *crtc;
+ struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
struct intel_crtc_state *first_crtc_state = NULL;
struct intel_crtc_state *other_crtc_state = NULL;
enum pipe first_pipe = INVALID_PIPE, enabled_pipe = INVALID_PIPE;
int i;
/* look at all crtc's that are going to be enabled in during modeset */
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- intel_crtc = to_intel_crtc(crtc);
-
- if (!crtc_state->active || !needs_modeset(crtc_state))
+ for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+ if (!crtc_state->base.active ||
+ !needs_modeset(_state->base))
continue;
if (first_crtc_state) {
- other_crtc_state = to_intel_crtc_state(crtc_state);
+ other_crtc_state = crtc_state;
break;
} else {
- first_crtc_state = to_intel_crtc_state(crtc_state);
- first_pipe = intel_crtc->pipe;
+ first_crtc_state = crtc_state;
+ first_pipe = crtc->pipe;
}
}
@@ -12833,24 +12831,22 @@ static int haswell_mode_set_planes_workaround(struct
drm_atomic_state *state)
return 0;
/* w/a possibly needed, check how many crtc's are already enabled. */
- for_each_intel_crtc(state->dev, intel_crtc) {
- struct intel_crtc_state *pipe_config;
-
- pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
- if (IS_ERR(pipe_config))
- return PTR_ERR(pipe_config);
+ for_each_intel_crtc(state->base.dev, crtc) {
+ crtc_state = intel_atomic_get_crtc_state(>base, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
- pipe_config->hsw_workaround_pipe = INVALID_PIPE;
+ crtc_state->hsw_workaround_pipe = INVALID_PIPE;
- if (!pipe_config->base.active ||
- needs_modeset(_config->base))
+ if (!crtc_state->base.active ||
+ needs_modeset(_state->base))
continue;
/* 2 or more enabled crtcs means no need for w/a */
if (enabled_pipe != INVALID_PIPE)
return 0;
- enabled_pipe = intel_crtc->pipe;
+ enabled_pipe = crtc->pipe;
}
if (enabled_pipe != INVALID_PIPE)
@@ -13013,7 +13009,7 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
intel_modeset_clear_plls(intel_state);
if (IS_HASWELL(dev_priv))
- return haswell_mode_set_planes_workaround(state);
+ return haswell_mode_set_planes_workaround(intel_state);
return 0;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/14] drm/i915: Don't pass the crtc to intel_dump_pipe_config()
From: Ville Syrjälä
We already pass the crtc's state to intel_dump_pipe_config()
so passing the crtc as well is redundant.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dddc9a8cffa1..0e509f5a28a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11476,10 +11476,10 @@ static const char *output_formats(enum
intel_output_format format)
return output_format_str[format];
}
-static void intel_dump_pipe_config(struct intel_crtc *crtc,
- struct intel_crtc_state *pipe_config,
+static void intel_dump_pipe_config(struct intel_crtc_state *pipe_config,
const char *context)
{
+ struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_plane *plane;
@@ -12585,10 +12585,8 @@ verify_crtc_state(struct drm_crtc *crtc,
if (!intel_pipe_config_compare(dev_priv, sw_config,
pipe_config, false)) {
I915_STATE_WARN(1, "pipe state doesn't match!\n");
- intel_dump_pipe_config(intel_crtc, pipe_config,
- "[hw state]");
- intel_dump_pipe_config(intel_crtc, sw_config,
- "[sw state]");
+ intel_dump_pipe_config(pipe_config, "[hw state]");
+ intel_dump_pipe_config(sw_config, "[sw state]");
}
}
@@ -13074,8 +13072,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret == -EDEADLK)
return ret;
if (ret) {
- intel_dump_pipe_config(to_intel_crtc(crtc),
- pipe_config, "[failed]");
+ intel_dump_pipe_config(pipe_config, "[failed]");
return ret;
}
@@ -13089,7 +13086,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (needs_modeset(crtc_state))
any_ms = true;
- intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
+ intel_dump_pipe_config(pipe_config,
needs_modeset(crtc_state) ?
"[modeset]" : "[fastset]");
}
@@ -16327,8 +16324,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
for_each_intel_crtc(_priv->drm, crtc) {
crtc_state = to_intel_crtc_state(crtc->base.state);
intel_sanitize_crtc(crtc, ctx);
- intel_dump_pipe_config(crtc, crtc_state,
- "[setup_hw_state]");
+ intel_dump_pipe_config(crtc_state, "[setup_hw_state]");
}
intel_modeset_update_connector_atomic_state(dev);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 05/25] trace.pl: Virtual engine preemption support
Quoting Tvrtko Ursulin (2019-05-17 12:25:06) > From: Tvrtko Ursulin > > Use the 'completed?' tracepoint field to detect more robustly when a > request has been preempted and remove it from the engine database if so. > > Otherwise the script can hit a scenario where the same global seqno will > be mentioned multiple times (on an engine seqno) which aborts processing. > > Signed-off-by: Tvrtko Ursulin Ok. In the future, we will end up with requests still in the db, but this does what you say on the tin. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 04/25] trace.pl: Virtual engine support
Quoting Tvrtko Ursulin (2019-05-17 12:25:05) > From: Tvrtko Ursulin > > Add virtual/queue timelines to both stdout and HTML output. > > A new timeline is created for each queue/virtual engine to display > associated requests in queued and runnable states. Once requests are > submitted to a real engine for executing they show up on the physical > engine timeline. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson Maybe an unfair comment, but looks just as untidy as if I had hacked it in ;) Reviewed-by: Chris Wilson Though that's really just a glance and trying to follow the flow. -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 02/25] trace.pl: Ignore signaling on non i915 fences
Quoting Tvrtko Ursulin (2019-05-17 12:25:03) > From: Tvrtko Ursulin > > gem_wsim uses the sw_fence timeline and confuses the script. sw_sync How does this fare with clflush fences (which are .driver="i915") and all of the future .driver="i915" fences? Looks like we are still prone to hitting that die. (Should die pretty quick on !llc) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/uc: Skip GuC HW unwinding if GuC is already dead
Quoting Michal Wajdeczko (2019-05-17 17:22:23) > We should not attempt to unwind GuC hardware/firmware setup > if we already have sanitized GuC. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Daniele Ceraolo Spurio > --- > drivers/gpu/drm/i915/intel_uc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c > index 01683d107348..9d86cd831ea7 100644 > --- a/drivers/gpu/drm/i915/intel_uc.c > +++ b/drivers/gpu/drm/i915/intel_uc.c > @@ -465,6 +465,9 @@ void intel_uc_fini_hw(struct drm_i915_private *i915) > > GEM_BUG_ON(!HAS_GUC(i915)); > > + if (!intel_guc_is_alive(guc)) > + return; > + Something else along these lines would be avoiding https://bugs.freedesktop.org/show_bug.cgi?id=110622 I presume you can think of something a bit more precise to skip guc selftests if guc initialisation failed. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
Quoting Michal Wajdeczko (2019-05-17 19:01:06) > On Fri, 17 May 2019 19:14:01 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2019-05-17 18:11:07) > >> On Fri, 17 May 2019 18:31:31 +0200, Chris Wilson > >> wrote: > >> > >> > Quoting Michal Wajdeczko (2019-05-17 17:22:25) > >> >> We may skip reset preparation steps if GuC is already sanitized. > >> >> > >> >> Signed-off-by: Michal Wajdeczko > >> >> Cc: Chris Wilson > >> >> Cc: Daniele Ceraolo Spurio > >> >> --- > >> >> drivers/gpu/drm/i915/intel_uc.c | 3 +++ > >> >> 1 file changed, 3 insertions(+) > >> >> > >> >> diff --git a/drivers/gpu/drm/i915/intel_uc.c > >> >> b/drivers/gpu/drm/i915/intel_uc.c > >> >> index 86edfa5ad72e..36c53a42927c 100644 > >> >> --- a/drivers/gpu/drm/i915/intel_uc.c > >> >> +++ b/drivers/gpu/drm/i915/intel_uc.c > >> >> @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct > >> drm_i915_private > >> >> *i915) > >> >> if (!USES_GUC(i915)) > >> >> return; > >> >> > >> >> + if (!intel_guc_is_alive(guc)) > >> >> + return; > >> > > >> > Does it not replace "if (!USES_GUC(i915))"? > >> > >> Yes it can, as we will never fetch/upload fw if we don't plan to use it > >> ;) > >> > >> Btw, I'm thinking of renaming intel_guc_is_alive to intel_guc_is_loaded > >> or intel_guc_is_started to better describe what this function is > >> reporting, > >> as one can think that intel_guc_is_alive is actually checking that GuC > >> fw > >> is responsive, which in general might not be the same as "loaded" > > > > Either seems reasonable, though there might be good reason to have both > > :) > > > > intel_guc_is_loaded > > intel_guc_has_started / intel_guc_is_active > > On GuC load failure, or on reset, we immediately sanitize fw load status, > so until we provide real runtime connectivity check, if ever be required, > I assume we can stay with just one function: intel_guc_is_loaded, ok? Fine by me, -Quack ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL
On Mon, May 13, 2019 at 05:13:10PM +0300, Ville Syrjälä wrote:
> On Fri, May 10, 2019 at 05:42:09PM -0700, Matt Roper wrote:
> > On Fri, May 03, 2019 at 10:08:31PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > ICL has so many planes that it can easily exceed the maximum
> > > effective memory bandwidth of the system. We must therefore check
> > > that we don't exceed that limit.
> > >
> > > The algorithm is very magic number heavy and lacks sufficient
> > > explanation for now. We also have no sane way to query the
> > > memory clock and timings, so we must rely on a combination of
> > > raw readout from the memory controller and hardcoded assumptions.
> > > The memory controller values obviously change as the system
> > > jumps between the different SAGV points, so we try to stabilize
> > > it first by disabling SAGV for the duration of the readout.
> > >
> > > The utilized bandwidth is tracked via a device wide atomic
> > > private object. That is actually not robust because we can't
> > > afford to enforce strict global ordering between the pipes.
> > > Thus I think I'll need to change this to simply chop up the
> > > available bandwidth between all the active pipes. Each pipe
> > > can then do whatever it wants as long as it doesn't exceed
> > > its budget. That scheme will also require that we assume that
> > > any number of planes could be active at any time.
> > >
> > > TODO: make it robust and deal with all the open questions
> > >
> > > v2: Sleep longer after disabling SAGV
> > > v3: Poll for the dclk to get raised (seen it take 250ms!)
> > > If the system has 2133MT/s memory then we pointlessly
> > > wait one full second :(
> > > v4: Use the new pcode interface to get the qgv points rather
> > > that using hardcoded numbers
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/Makefile | 1 +
> > > drivers/gpu/drm/i915/i915_drv.c | 229 ++
> > > drivers/gpu/drm/i915/i915_drv.h | 10 +
> > > drivers/gpu/drm/i915/i915_reg.h | 3 +
> > > drivers/gpu/drm/i915/intel_atomic_plane.c | 20 ++
> > > drivers/gpu/drm/i915/intel_atomic_plane.h | 2 +
> > > drivers/gpu/drm/i915/intel_bw.c | 181 +
> > > drivers/gpu/drm/i915/intel_bw.h | 46 +
> > > drivers/gpu/drm/i915/intel_display.c | 40 +++-
> > > drivers/gpu/drm/i915/intel_drv.h | 2 +
> > > 10 files changed, 533 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/i915/intel_bw.c
> > > create mode 100644 drivers/gpu/drm/i915/intel_bw.h
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 68106fe35a04..139a0fc19390 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -138,6 +138,7 @@ i915-y += intel_audio.o \
> > > intel_atomic.o \
> > > intel_atomic_plane.o \
> > > intel_bios.o \
> > > + intel_bw.o \
> > > intel_cdclk.o \
> > > intel_color.o \
> > > intel_combo_phy.o \
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 5ed864752c7b..b7fa7b51c2e2 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -70,6 +70,7 @@
> > > #include "intel_overlay.h"
> > > #include "intel_pipe_crc.h"
> > > #include "intel_pm.h"
> > > +#include "intel_sideband.h"
> > > #include "intel_sprite.h"
> > > #include "intel_uc.h"
> > >
> > > @@ -1435,6 +1436,232 @@ bxt_get_dram_info(struct drm_i915_private
> > > *dev_priv)
> > > return 0;
> > > }
> > >
> > > +struct intel_qgv_point {
> > > + u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
> > > +};
> > > +
> > > +struct intel_sagv_info {
> > > + struct intel_qgv_point points[3];
> > > + u8 num_points;
> > > + u8 num_channels;
> > > + u8 t_bl;
> > > + enum intel_dram_type dram_type;
> > > +};
> > > +
> > > +static int icl_pcode_read_mem_global_info(struct drm_i915_private
> > > *dev_priv,
> > > + struct intel_sagv_info *si)
> > > +{
> > > + u32 val = 0;
> > > + int ret;
> > > +
> > > + ret = sandybridge_pcode_read(dev_priv,
> > > + ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
> > > + ICL_PCODE_MEM_SS_READ_GLOBAL_INFO,
> > > + , NULL);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + switch (val & 0xf) {
> > > + case 0:
> > > + si->dram_type = INTEL_DRAM_DDR4;
> > > + break;
> > > + case 1:
> > > + si->dram_type = INTEL_DRAM_DDR3;
> > > + break;
> > > + case 2:
> > > + si->dram_type = INTEL_DRAM_LPDDR3;
> > > + break;
> > > + case 3:
> > > + si->dram_type = INTEL_DRAM_LPDDR3;
> > > + break;
> > > + default:
> > > + MISSING_CASE(val & 0xf);
> > > + break;
> > > + }
> > > +
> > > + si->num_channels =
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
On Fri, 17 May 2019 19:14:01 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-05-17 18:11:07) On Fri, 17 May 2019 18:31:31 +0200, Chris Wilson wrote: > Quoting Michal Wajdeczko (2019-05-17 17:22:25) >> We may skip reset preparation steps if GuC is already sanitized. >> >> Signed-off-by: Michal Wajdeczko >> Cc: Chris Wilson >> Cc: Daniele Ceraolo Spurio >> --- >> drivers/gpu/drm/i915/intel_uc.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_uc.c >> b/drivers/gpu/drm/i915/intel_uc.c >> index 86edfa5ad72e..36c53a42927c 100644 >> --- a/drivers/gpu/drm/i915/intel_uc.c >> +++ b/drivers/gpu/drm/i915/intel_uc.c >> @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct drm_i915_private >> *i915) >> if (!USES_GUC(i915)) >> return; >> >> + if (!intel_guc_is_alive(guc)) >> + return; > > Does it not replace "if (!USES_GUC(i915))"? Yes it can, as we will never fetch/upload fw if we don't plan to use it ;) Btw, I'm thinking of renaming intel_guc_is_alive to intel_guc_is_loaded or intel_guc_is_started to better describe what this function is reporting, as one can think that intel_guc_is_alive is actually checking that GuC fw is responsive, which in general might not be the same as "loaded" Either seems reasonable, though there might be good reason to have both :) intel_guc_is_loaded intel_guc_has_started / intel_guc_is_active On GuC load failure, or on reset, we immediately sanitize fw load status, so until we provide real runtime connectivity check, if ever be required, I assume we can stay with just one function: intel_guc_is_loaded, ok? Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: added i2c symlink to hdmi connector
== Series Details == Series: drm/i915: added i2c symlink to hdmi connector URL : https://patchwork.freedesktop.org/series/60794/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6096 -> Patchwork_13034 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13034 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13034, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13034: ### IGT changes ### Possible regressions * igt@i915_module_load@reload: - fi-kbl-r: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-kbl-r/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-kbl-r/igt@i915_module_l...@reload.html - fi-whl-u: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-whl-u/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-whl-u/igt@i915_module_l...@reload.html - fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-skl-iommu/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-skl-iommu/igt@i915_module_l...@reload.html - fi-hsw-4770r: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-hsw-4770r/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-hsw-4770r/igt@i915_module_l...@reload.html - fi-skl-6700k2: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-skl-6700k2/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-skl-6700k2/igt@i915_module_l...@reload.html - fi-bsw-kefka: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-bsw-kefka/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-bsw-kefka/igt@i915_module_l...@reload.html - fi-bdw-5557u: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-bdw-5557u/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-bdw-5557u/igt@i915_module_l...@reload.html - fi-skl-guc: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-skl-guc/igt@i915_module_l...@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-skl-guc/igt@i915_module_l...@reload.html - fi-kbl-guc: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-kbl-guc/igt@i915_module_l...@reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-kbl-guc/igt@i915_module_l...@reload.html - fi-cfl-8109u: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-cfl-8109u/igt@i915_module_l...@reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-cfl-8109u/igt@i915_module_l...@reload.html - fi-kbl-7500u: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-kbl-7500u/igt@i915_module_l...@reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-kbl-7500u/igt@i915_module_l...@reload.html - fi-cfl-8700k: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-cfl-8700k/igt@i915_module_l...@reload.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-cfl-8700k/igt@i915_module_l...@reload.html - fi-snb-2520m: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-snb-2520m/igt@i915_module_l...@reload.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-snb-2520m/igt@i915_module_l...@reload.html - fi-hsw-4770:[PASS][27] -> [INCOMPLETE][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-hsw-4770/igt@i915_module_l...@reload.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13034/fi-hsw-4770/igt@i915_module_l...@reload.html - fi-cfl-guc: [PASS][29] -> [INCOMPLETE][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-cfl-guc/igt@i915_module_l...@reload.html [30]:
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
Quoting Michal Wajdeczko (2019-05-17 18:11:07) > On Fri, 17 May 2019 18:31:31 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2019-05-17 17:22:25) > >> We may skip reset preparation steps if GuC is already sanitized. > >> > >> Signed-off-by: Michal Wajdeczko > >> Cc: Chris Wilson > >> Cc: Daniele Ceraolo Spurio > >> --- > >> drivers/gpu/drm/i915/intel_uc.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_uc.c > >> b/drivers/gpu/drm/i915/intel_uc.c > >> index 86edfa5ad72e..36c53a42927c 100644 > >> --- a/drivers/gpu/drm/i915/intel_uc.c > >> +++ b/drivers/gpu/drm/i915/intel_uc.c > >> @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct drm_i915_private > >> *i915) > >> if (!USES_GUC(i915)) > >> return; > >> > >> + if (!intel_guc_is_alive(guc)) > >> + return; > > > > Does it not replace "if (!USES_GUC(i915))"? > > Yes it can, as we will never fetch/upload fw if we don't plan to use it ;) > > Btw, I'm thinking of renaming intel_guc_is_alive to intel_guc_is_loaded > or intel_guc_is_started to better describe what this function is reporting, > as one can think that intel_guc_is_alive is actually checking that GuC fw > is responsive, which in general might not be the same as "loaded" Either seems reasonable, though there might be good reason to have both :) intel_guc_is_loaded intel_guc_has_started / intel_guc_is_active -chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Don't forget to prepare GuC for the reset
Quoting Michal Wajdeczko (2019-05-17 17:54:53) > On Fri, 17 May 2019 18:27:44 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2019-05-17 17:22:27) > >> When we reset engines using ALL_ENGINES mask, we will do > >> full GPU reset and GuC will be also affected. Let GuC be > >> prepared for upcoming reset. > >> > >> Signed-off-by: Michal Wajdeczko > >> Cc: Chris Wilson > >> Cc: Daniele Ceraolo Spurio > >> --- > >> drivers/gpu/drm/i915/gt/intel_reset.c | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c > >> b/drivers/gpu/drm/i915/gt/intel_reset.c > >> index 464369bc55ad..ca6e40b6b4e2 100644 > >> --- a/drivers/gpu/drm/i915/gt/intel_reset.c > >> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > >> @@ -564,6 +564,10 @@ static int gen8_reset_engines(struct > >> drm_i915_private *i915, > >> */ > >> } > >> > >> + /* We are about to do full GPU reset, don't forget about GuC */ > >> + if (engine_mask == ALL_ENGINES) > >> + intel_uc_reset_prepare(i915); > > > > Eh, this is done in reset_prepare already. The only other path to call > > intel_gpu_reset() directly is along sanitization, which should also have > > already sanitized the guc as well. No? > > There is igt_atomic_reset selftest which does not call reset_prepare. > And since we lost GuC in gen6_reset_engines due to GEN6_GRDOM_FULL, > our later graceful goodbye with GuC was not working. > > This is hidden with current GuC fw, but with new ICL fw with CT is was > visible as: Imagine we fix the selftest, is there a GEM_BUG_ON(intel_uc_active()) we could put here to enforce sanitization first? Does such a assert want to be here or up a level in intel_gpu_reset()? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
On Fri, 17 May 2019 18:31:31 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-05-17 17:22:25) We may skip reset preparation steps if GuC is already sanitized. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 86edfa5ad72e..36c53a42927c 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915) if (!USES_GUC(i915)) return; + if (!intel_guc_is_alive(guc)) + return; Does it not replace "if (!USES_GUC(i915))"? Yes it can, as we will never fetch/upload fw if we don't plan to use it ;) Btw, I'm thinking of renaming intel_guc_is_alive to intel_guc_is_loaded or intel_guc_is_started to better describe what this function is reporting, as one can think that intel_guc_is_alive is actually checking that GuC fw is responsive, which in general might not be the same as "loaded" Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Extend BT2020 support in iCSC and fixes (rev3)
== Series Details ==
Series: Extend BT2020 support in iCSC and fixes (rev3)
URL : https://patchwork.freedesktop.org/series/60480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6096 -> Patchwork_13033
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13033:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_basic@readonly-bsd:
- {fi-cml-u}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/fi-cml-u/igt@gem_exec_ba...@readonly-bsd.html
Known issues
Here are the changes found in Patchwork_13033 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][2] -> [FAIL][3] ([fdo#108511])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][4] -> [DMESG-FAIL][5] ([fdo#110235])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
- fi-skl-gvtdvm: [PASS][6] -> [DMESG-FAIL][7] ([fdo#110235])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
Possible fixes
* igt@gem_basic@bad-close:
- fi-icl-u2: [INCOMPLETE][8] ([fdo#107713]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-u2/igt@gem_ba...@bad-close.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/fi-icl-u2/igt@gem_ba...@bad-close.html
* igt@gem_cpu_reloc@basic:
- {fi-icl-y}: [INCOMPLETE][10] ([fdo#107713] / [fdo#110246]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-y/igt@gem_cpu_re...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/fi-icl-y/igt@gem_cpu_re...@basic.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#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246
Participating hosts (51 -> 44)
--
Additional (2): fi-skl-lmem fi-cml-u
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-icl-u3 fi-blb-e6850 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6096 -> Patchwork_13033
CI_DRM_6096: beb32d3348a566a6aafa292c65e2d60a610479c4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4996: 6fe5d254ec1b9b47d61408e1b49a7339876bf1e7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13033: af2fa2048ed0a68fe952fb0cfbe85c64c59a7939 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
af2fa2048ed0 drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709
6b33aafbeaee drm/i915/icl: Fix Y pre-offset for Full Range YCbCr
dd2200774ae4 drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13033/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Don't forget to prepare GuC for the reset
Quoting Michal Wajdeczko (2019-05-17 17:54:53) > On Fri, 17 May 2019 18:27:44 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2019-05-17 17:22:27) > >> When we reset engines using ALL_ENGINES mask, we will do > >> full GPU reset and GuC will be also affected. Let GuC be > >> prepared for upcoming reset. > >> > >> Signed-off-by: Michal Wajdeczko > >> Cc: Chris Wilson > >> Cc: Daniele Ceraolo Spurio > >> --- > >> drivers/gpu/drm/i915/gt/intel_reset.c | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c > >> b/drivers/gpu/drm/i915/gt/intel_reset.c > >> index 464369bc55ad..ca6e40b6b4e2 100644 > >> --- a/drivers/gpu/drm/i915/gt/intel_reset.c > >> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > >> @@ -564,6 +564,10 @@ static int gen8_reset_engines(struct > >> drm_i915_private *i915, > >> */ > >> } > >> > >> + /* We are about to do full GPU reset, don't forget about GuC */ > >> + if (engine_mask == ALL_ENGINES) > >> + intel_uc_reset_prepare(i915); > > > > Eh, this is done in reset_prepare already. The only other path to call > > intel_gpu_reset() directly is along sanitization, which should also have > > already sanitized the guc as well. No? > > There is igt_atomic_reset selftest which does not call reset_prepare. > And since we lost GuC in gen6_reset_engines due to GEN6_GRDOM_FULL, > our later graceful goodbye with GuC was not working. (Apologies if resent.) Ah, so the intent there was to prevent sleeps slipping into the device-level reset (so that we could pull it under a heavy hammer like stop_machine() to serialise the reset with direct user access). At one point, I hoped we could make i915_reset() completely fast and lockless, but that was a fleeting fancy. It looks reasonable to put that under a reset_prepare/reset_finish and keep the test semantics. That would also mean we have to move it out of the increasingly misnamed selftest_hangcheck.c into a selftest_reset.c -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/uc: Stop talking with GuC when resetting
On Fri, 17 May 2019 18:30:40 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-17 17:22:24)
Knowing that GuC will be reset soon, we may stop all communication
immediately without doing graceful cleanup as it is not needed.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.h | 5 +
drivers/gpu/drm/i915/intel_uc.c | 13 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h
b/drivers/gpu/drm/i915/intel_guc_ct.h
index f5e7f0663304..41ba593a4df7 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/intel_guc_ct.h
@@ -96,4 +96,9 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct);
int intel_guc_ct_enable(struct intel_guc_ct *ct);
void intel_guc_ct_disable(struct intel_guc_ct *ct);
+static inline void intel_guc_ct_stop(struct intel_guc_ct *ct)
+{
+ ct->host_channel.enabled = false;
+}
+
#endif /* _INTEL_GUC_CT_H_ */
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 9d86cd831ea7..86edfa5ad72e 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -224,6 +224,17 @@ static int guc_enable_communication(struct
intel_guc *guc)
return 0;
}
+static void guc_stop_communication(struct intel_guc *guc)
+{
+ struct drm_i915_private *i915 = guc_to_i915(guc);
+
+ if (HAS_GUC_CT(i915))
Does this not fall out of some local knowledge? Though for the moment it
is harmless to stop a non-existent intel_guc_ct.
We do have CT init/enable/disable/fini functions (all guarded by
HAS_GUC_CT)
so at the moment we are here, we know that CT was already enabled.
+ intel_guc_ct_stop(>ct);
Any serialisation required here?
This function might be called from atomic context, so rather not.
Or caveats for callers to observe?
As we are resetting the GuC, we simply does not allow any further
communication with it, any abusers will see something like this:
<4> [322.401614] Unexpected send: action=0x4000
<4> [322.401648] WARNING: CPU: 3 PID: 1357 at
drivers/gpu/drm/i915/intel_guc.c:405 intel_guc_send_nop+0xe/0x20 [i915]
+ guc->send = intel_guc_send_nop;
+ guc->handler = intel_guc_to_host_event_handler_nop;
+}
___
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 Fri, May 17, 2019 at 09:44:46AM -0700, Rodrigo Vivi wrote: > On Fri, May 17, 2019 at 07:34:23PM +0300, Ville Syrjälä wrote: > > On Fri, May 17, 2019 at 09:17:39AM -0700, Rodrigo Vivi wrote: > > > On Thu, May 16, 2019 at 03:49:19PM +, Summers, Stuart wrote: > > > > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote: > > > > > On Thu, 16 May 2019, "Summers, Stuart" > > > > > wrote: > > > > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: > > > > > > > On Tue, 14 May 2019, Rodrigo Vivi wrote: > > > > > > > > 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) > > > > > > > > > > > > > > Please don't conflate alpha_support or force_probe with > > > > > > > *anything* > > > > > > > else. > > > > > > > > > > > > > > > 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. :/ > > > > > > > > > > > > > > The problem is, if it works with rc6 disabled, it doesn't prove > > > > > > > it's > > > > > > > an > > > > > > > rc6 bug either. > > > > > > Well, RC6 is the main GT power gating. The issue could be on may other > > > individual power gating, but if by disabling RC6 the issue is gone > > > it is a very good indication that it is a GT-PM bug somewhere. > > > > I disagree. In the recent past enable_rc6 was often used by > > people to workaround display underruns and whatnot. > > o.O > do you mean this was being used as a placebo? or real issue? > or something like by keeping rc6 gpu was keeping the power request > to punit high so display was receiving enough power to not strugle > with wm? or something like that or what? Disabling rc6 disables most package C-states, which makes life a lot easier for the display engine due to reduced memory access latencies. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Don't forget to prepare GuC for the reset
Quoting Michal Wajdeczko (2019-05-17 17:54:53) > On Fri, 17 May 2019 18:27:44 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2019-05-17 17:22:27) > >> When we reset engines using ALL_ENGINES mask, we will do > >> full GPU reset and GuC will be also affected. Let GuC be > >> prepared for upcoming reset. > >> > >> Signed-off-by: Michal Wajdeczko > >> Cc: Chris Wilson > >> Cc: Daniele Ceraolo Spurio > >> --- > >> drivers/gpu/drm/i915/gt/intel_reset.c | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c > >> b/drivers/gpu/drm/i915/gt/intel_reset.c > >> index 464369bc55ad..ca6e40b6b4e2 100644 > >> --- a/drivers/gpu/drm/i915/gt/intel_reset.c > >> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > >> @@ -564,6 +564,10 @@ static int gen8_reset_engines(struct > >> drm_i915_private *i915, > >> */ > >> } > >> > >> + /* We are about to do full GPU reset, don't forget about GuC */ > >> + if (engine_mask == ALL_ENGINES) > >> + intel_uc_reset_prepare(i915); > > > > Eh, this is done in reset_prepare already. The only other path to call > > intel_gpu_reset() directly is along sanitization, which should also have > > already sanitized the guc as well. No? > > There is igt_atomic_reset selftest which does not call reset_prepare. > And since we lost GuC in gen6_reset_engines due to GEN6_GRDOM_FULL, > our later graceful goodbye with GuC was not working. Ok, the intent there was to avoid letting any sleeps slip into the device reset itself (should we need to put it inside a heavy hammer like stop_machine() to serialise it with direct user access to the hw). I think it is fair to put that under reset_prepare / reset_finish. Would also mean moving it out of selftest_hangcheck and into selftest_reset. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Don't forget to prepare GuC for the reset
On Fri, 17 May 2019 18:27:44 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-05-17 17:22:27) When we reset engines using ALL_ENGINES mask, we will do full GPU reset and GuC will be also affected. Let GuC be prepared for upcoming reset. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/intel_reset.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index 464369bc55ad..ca6e40b6b4e2 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -564,6 +564,10 @@ static int gen8_reset_engines(struct drm_i915_private *i915, */ } + /* We are about to do full GPU reset, don't forget about GuC */ + if (engine_mask == ALL_ENGINES) + intel_uc_reset_prepare(i915); Eh, this is done in reset_prepare already. The only other path to call intel_gpu_reset() directly is along sanitization, which should also have already sanitized the guc as well. No? There is igt_atomic_reset selftest which does not call reset_prepare. And since we lost GuC in gen6_reset_engines due to GEN6_GRDOM_FULL, our later graceful goodbye with GuC was not working. This is hidden with current GuC fw, but with new ICL fw with CT is was visible as: <3> [508.613024] [drm:intel_guc_send_mmio [i915]] *ERROR* MMIO: GuC action 0x4506 failed with error -110 0x4506 <3> [508.613142] [drm:guc_action_deregister_ct_buffer [i915]] *ERROR* CT: deregister SEND buffer failed; owner=0 err=-110 <3> [508.623521] [drm:intel_guc_send_mmio [i915]] *ERROR* MMIO: GuC action 0x4506 failed with error -110 0x4506 <3> [508.623573] [drm:guc_action_deregister_ct_buffer [i915]] *ERROR* CT: deregister RECV buffer failed; owner=0 err=-110 Michal ___ 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 Fri, May 17, 2019 at 07:34:23PM +0300, Ville Syrjälä wrote: > On Fri, May 17, 2019 at 09:17:39AM -0700, Rodrigo Vivi wrote: > > On Thu, May 16, 2019 at 03:49:19PM +, Summers, Stuart wrote: > > > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote: > > > > On Thu, 16 May 2019, "Summers, Stuart" > > > > wrote: > > > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: > > > > > > On Tue, 14 May 2019, Rodrigo Vivi wrote: > > > > > > > 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) > > > > > > > > > > > > Please don't conflate alpha_support or force_probe with > > > > > > *anything* > > > > > > else. > > > > > > > > > > > > > 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. :/ > > > > > > > > > > > > The problem is, if it works with rc6 disabled, it doesn't prove > > > > > > it's > > > > > > an > > > > > > rc6 bug either. > > > > Well, RC6 is the main GT power gating. The issue could be on may other > > individual power gating, but if by disabling RC6 the issue is gone > > it is a very good indication that it is a GT-PM bug somewhere. > > I disagree. In the recent past enable_rc6 was often used by > people to workaround display underruns and whatnot. o.O do you mean this was being used as a placebo? or real issue? or something like by keeping rc6 gpu was keeping the power request to punit high so display was receiving enough power to not strugle with wm? or something like that or what? > > -- > Ville Syrjälä > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: added i2c symlink to hdmi connector
On Fri, May 17, 2019 at 07:21:09PM +0300, Oleg Vasilev wrote:
> Currently, the i2c adapter was available only under DP connectors.
>
> This patch adds i2c adapter symlink to hdmi connector in order to make
> this behaviour consistent.
>
> The initial motivation of this patch was to make igt i2c subtest
> patch [1] work on all connectors.
>
> [1]: https://patchwork.freedesktop.org/series/60357/
>
> Signed-off-by: Oleg Vasilev
> Cc: Arkadiusz Hiler
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 2a4086cf2692..b8ae67297878 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2658,6 +2658,37 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder,
> chv_phy_release_cl2_override(encoder);
> }
>
> +static struct i2c_adapter *
> +intel_hdmi_get_i2c_adapter(struct drm_connector *connector)
> +{
> + struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(_encoder->base);
> + struct drm_device *dev = intel_encoder->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +}
> +
> +static void intel_hdmi_create_i2c_symlink(struct drm_connector *connector)
> +{
> + struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
> + struct kobject *i2c_kobj = >dev.kobj;
> + struct kobject *connector_kobj = >kdev->kobj;
> +
> + int ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj->name);
> +
> + WARN(ret != 0, "Failed to create i2c symlink\n");
> +}
> +
> +static void intel_hdmi_delete_i2c_symlink(struct drm_connector *connector)
> +{
> + struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
> + struct kobject *i2c_kobj = >dev.kobj;
> + struct kobject *connector_kobj = >kdev->kobj;
> +
> + sysfs_remove_link(connector_kobj, i2c_kobj->name);
> +}
> +
> static int
> intel_hdmi_connector_register(struct drm_connector *connector)
> {
> @@ -2669,11 +2700,15 @@ intel_hdmi_connector_register(struct drm_connector
> *connector)
>
> i915_debugfs_connector_add(connector);
>
> + intel_hdmi_create_i2c_symlink(connector);
> +
> return ret;
> }
>
> static void intel_hdmi_destroy(struct drm_connector *connector)
> {
> + intel_hdmi_delete_i2c_symlink(connector);
> +
Shouldn't this be in .unregister() ?
> if (intel_attached_hdmi(connector)->cec_notifier)
> cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
>
> --
> 2.21.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915/uc: Stop GuC submission during reset prepare
Quoting Michal Wajdeczko (2019-05-17 17:22:26)
> +void intel_guc_submission_stop(struct intel_guc *guc)
> +{
> + struct drm_i915_private *i915 = guc_to_i915(guc);
> +
> + GEM_BUG_ON(i915->gt.awake); /* GT should be parked first */
How is this true for reset? Note, it's an unlocked read, so READ_ONCE()
or something along GEM_BUG_ON(intel_wakeref_active(>gt.wakeref))
Though I think this is wrong!
i915_reset or i915_gem_set_wedged
-> reset_prepare
-> intel_uc_reset_prepare
-> intel_guc_submission_stop
No locks, no parking. So how does this survive selftests? :(
-Chris
___
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 Fri, May 17, 2019 at 09:17:39AM -0700, Rodrigo Vivi wrote: > On Thu, May 16, 2019 at 03:49:19PM +, Summers, Stuart wrote: > > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote: > > > On Thu, 16 May 2019, "Summers, Stuart" > > > wrote: > > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: > > > > > On Tue, 14 May 2019, Rodrigo Vivi wrote: > > > > > > 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) > > > > > > > > > > Please don't conflate alpha_support or force_probe with > > > > > *anything* > > > > > else. > > > > > > > > > > > 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. :/ > > > > > > > > > > The problem is, if it works with rc6 disabled, it doesn't prove > > > > > it's > > > > > an > > > > > rc6 bug either. > > Well, RC6 is the main GT power gating. The issue could be on may other > individual power gating, but if by disabling RC6 the issue is gone > it is a very good indication that it is a GT-PM bug somewhere. I disagree. In the recent past enable_rc6 was often used by people to workaround display underruns and whatnot. -- 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 Add HDR Metadata Parsing and handling in DRM layer (rev14)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev14)
URL : https://patchwork.freedesktop.org/series/25091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6096 -> Patchwork_13032
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/
Known issues
Here are the changes found in Patchwork_13032 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_6096/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] /
[fdo#108744])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_basic@bad-close:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-u2/igt@gem_ba...@bad-close.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-icl-u2/igt@gem_ba...@bad-close.html
* igt@gem_cpu_reloc@basic:
- {fi-icl-y}: [INCOMPLETE][7] ([fdo#107713] / [fdo#110246]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-y/igt@gem_cpu_re...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-icl-y/igt@gem_cpu_re...@basic.html
- {fi-icl-u3}:[INCOMPLETE][9] ([fdo#107713] / [fdo#110246]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-icl-u3/igt@gem_cpu_re...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-icl-u3/igt@gem_cpu_re...@basic.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [INCOMPLETE][11] ([fdo#103927] / [fdo#110624]) ->
[DMESG-FAIL][12] ([fdo#110620])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
* igt@runner@aborted:
- fi-apl-guc: [FAIL][13] ([fdo#110624]) -> [FAIL][14] ([fdo#110622])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6096/fi-apl-guc/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13032/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
Participating hosts (51 -> 46)
--
Additional (2): fi-skl-lmem fi-cml-u
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6096 -> Patchwork_13032
CI_DRM_6096: beb32d3348a566a6aafa292c65e2d60a610479c4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4996: 6fe5d254ec1b9b47d61408e1b49a7339876bf1e7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13032: 0552da2fcaa6a3ffe0bc2b97e2598482f7e69245 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0552da2fcaa6 drm/i915: Add state readout for DRM infoframe
a6c2488be372 video/hdmi: Add Unpack function for DRM infoframe
8a45fa5a794f drm/i915: Added DRM Infoframe handling for BYT/CHT
7a1e2c56755d drm/i915:Enabled Modeset when HDR Infoframe changes
3d47411a380b drm/i915: Enable infoframes on GLK+ for HDR
c3c006fd9d35 drm: Add HLG EOTF
e3c3a66b51a0 drm/i915: Write HDR infoframe and send to panel
6b40c837a210 drm/i915: Attach HDR metadata property to connector
17ab87bad491 drm: Enable HDR infoframe support
4f07c7e5dafd drm: Parse HDR metadata info from EDID
3d1f3cb173f6 drm: Add reference counting on HDR metadata blob
7c0463e5827f drm: Add HDR source metadata property
== Logs ==
For
Re: [Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
Quoting Michal Wajdeczko (2019-05-17 17:22:25) > We may skip reset preparation steps if GuC is already sanitized. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Daniele Ceraolo Spurio > --- > drivers/gpu/drm/i915/intel_uc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c > index 86edfa5ad72e..36c53a42927c 100644 > --- a/drivers/gpu/drm/i915/intel_uc.c > +++ b/drivers/gpu/drm/i915/intel_uc.c > @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915) > if (!USES_GUC(i915)) > return; > > + if (!intel_guc_is_alive(guc)) > + return; Does it not replace "if (!USES_GUC(i915))"? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/uc: Stop talking with GuC when resetting
Quoting Michal Wajdeczko (2019-05-17 17:22:24)
> Knowing that GuC will be reset soon, we may stop all communication
> immediately without doing graceful cleanup as it is not needed.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/intel_guc_ct.h | 5 +
> drivers/gpu/drm/i915/intel_uc.c | 13 -
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h
> b/drivers/gpu/drm/i915/intel_guc_ct.h
> index f5e7f0663304..41ba593a4df7 100644
> --- a/drivers/gpu/drm/i915/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/intel_guc_ct.h
> @@ -96,4 +96,9 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct);
> int intel_guc_ct_enable(struct intel_guc_ct *ct);
> void intel_guc_ct_disable(struct intel_guc_ct *ct);
>
> +static inline void intel_guc_ct_stop(struct intel_guc_ct *ct)
> +{
> + ct->host_channel.enabled = false;
> +}
> +
> #endif /* _INTEL_GUC_CT_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index 9d86cd831ea7..86edfa5ad72e 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -224,6 +224,17 @@ static int guc_enable_communication(struct intel_guc
> *guc)
> return 0;
> }
>
> +static void guc_stop_communication(struct intel_guc *guc)
> +{
> + struct drm_i915_private *i915 = guc_to_i915(guc);
> +
> + if (HAS_GUC_CT(i915))
Does this not fall out of some local knowledge? Though for the moment it
is harmless to stop a non-existent intel_guc_ct.
> + intel_guc_ct_stop(>ct);
Any serialisation required here? Or caveats for callers to observe?
> + guc->send = intel_guc_send_nop;
> + guc->handler = intel_guc_to_host_event_handler_nop;
> +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Don't forget to prepare GuC for the reset
Quoting Michal Wajdeczko (2019-05-17 17:22:27) > When we reset engines using ALL_ENGINES mask, we will do > full GPU reset and GuC will be also affected. Let GuC be > prepared for upcoming reset. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Daniele Ceraolo Spurio > --- > drivers/gpu/drm/i915/gt/intel_reset.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c > b/drivers/gpu/drm/i915/gt/intel_reset.c > index 464369bc55ad..ca6e40b6b4e2 100644 > --- a/drivers/gpu/drm/i915/gt/intel_reset.c > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > @@ -564,6 +564,10 @@ static int gen8_reset_engines(struct drm_i915_private > *i915, > */ > } > > + /* We are about to do full GPU reset, don't forget about GuC */ > + if (engine_mask == ALL_ENGINES) > + intel_uc_reset_prepare(i915); Eh, this is done in reset_prepare already. The only other path to call intel_gpu_reset() directly is along sanitization, which should also have already sanitized the guc as well. No? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/uc: Skip GuC HW unwinding if GuC is already dead
We should not attempt to unwind GuC hardware/firmware setup if we already have sanitized GuC. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 01683d107348..9d86cd831ea7 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -465,6 +465,9 @@ void intel_uc_fini_hw(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); + if (!intel_guc_is_alive(guc)) + return; + if (USES_GUC_SUBMISSION(i915)) intel_guc_submission_disable(guc); -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] GuC fixes
Misc GuC fixes for upcoming 32.0.3 Michal Wajdeczko (7): drm/i915/uc: Use GuC firmware status helper drm/i915/uc: Explicitly sanitize GuC/HuC on failure and finish drm/i915/uc: Skip GuC HW unwinding if GuC is already dead drm/i915/uc: Stop talking with GuC when resetting drm/i915/uc: Skip reset preparation if GuC is already dead drm/i915/uc: Stop GuC submission during reset prepare drm/i915/uc: Don't forget to prepare GuC for the reset drivers/gpu/drm/i915/gt/intel_reset.c | 4 ++ drivers/gpu/drm/i915/intel_guc_ct.h | 5 +++ drivers/gpu/drm/i915/intel_guc_submission.c | 25 +++ drivers/gpu/drm/i915/intel_guc_submission.h | 1 + drivers/gpu/drm/i915/intel_uc.c | 46 + 5 files changed, 72 insertions(+), 9 deletions(-) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915/uc: Use GuC firmware status helper
We already have helper function for checking GuC firmware load status. Replace existing open-coded checks. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 1ee70df51627..f67f6224b1df 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -486,7 +486,7 @@ void intel_uc_runtime_suspend(struct drm_i915_private *i915) struct intel_guc *guc = >guc; int err; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_alive(guc)) return; err = intel_guc_suspend(guc); @@ -501,7 +501,7 @@ void intel_uc_suspend(struct drm_i915_private *i915) struct intel_guc *guc = >guc; intel_wakeref_t wakeref; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_alive(guc)) return; with_intel_runtime_pm(i915, wakeref) @@ -516,7 +516,7 @@ int intel_uc_resume(struct drm_i915_private *i915) if (!USES_GUC(i915)) return 0; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_alive(guc)) return 0; guc_enable_communication(guc); -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/uc: Stop talking with GuC when resetting
Knowing that GuC will be reset soon, we may stop all communication
immediately without doing graceful cleanup as it is not needed.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.h | 5 +
drivers/gpu/drm/i915/intel_uc.c | 13 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h
b/drivers/gpu/drm/i915/intel_guc_ct.h
index f5e7f0663304..41ba593a4df7 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/intel_guc_ct.h
@@ -96,4 +96,9 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct);
int intel_guc_ct_enable(struct intel_guc_ct *ct);
void intel_guc_ct_disable(struct intel_guc_ct *ct);
+static inline void intel_guc_ct_stop(struct intel_guc_ct *ct)
+{
+ ct->host_channel.enabled = false;
+}
+
#endif /* _INTEL_GUC_CT_H_ */
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9d86cd831ea7..86edfa5ad72e 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -224,6 +224,17 @@ static int guc_enable_communication(struct intel_guc *guc)
return 0;
}
+static void guc_stop_communication(struct intel_guc *guc)
+{
+ struct drm_i915_private *i915 = guc_to_i915(guc);
+
+ if (HAS_GUC_CT(i915))
+ intel_guc_ct_stop(>ct);
+
+ guc->send = intel_guc_send_nop;
+ guc->handler = intel_guc_to_host_event_handler_nop;
+}
+
static void guc_disable_communication(struct intel_guc *guc)
{
struct drm_i915_private *i915 = guc_to_i915(guc);
@@ -488,7 +499,7 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915)
if (!USES_GUC(i915))
return;
- guc_disable_communication(guc);
+ guc_stop_communication(guc);
__uc_sanitize(i915);
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/uc: Explicitly sanitize GuC/HuC on failure and finish
Explicitly sanitize GuC/HuC on load failure and when we finish
using them to make sure our fw state tracking is always correct.
While around, use new helper in uc_reset_prepare.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_uc.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index f67f6224b1df..01683d107348 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -337,14 +337,11 @@ void intel_uc_fini(struct drm_i915_private *i915)
intel_guc_fini(guc);
}
-void intel_uc_sanitize(struct drm_i915_private *i915)
+static void __uc_sanitize(struct drm_i915_private *i915)
{
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
- if (!USES_GUC(i915))
- return;
-
GEM_BUG_ON(!HAS_GUC(i915));
intel_huc_sanitize(huc);
@@ -353,6 +350,14 @@ void intel_uc_sanitize(struct drm_i915_private *i915)
__intel_uc_reset_hw(i915);
}
+void intel_uc_sanitize(struct drm_i915_private *i915)
+{
+ if (!USES_GUC(i915))
+ return;
+
+ __uc_sanitize(i915);
+}
+
int intel_uc_init_hw(struct drm_i915_private *i915)
{
struct intel_guc *guc = >guc;
@@ -438,6 +443,8 @@ int intel_uc_init_hw(struct drm_i915_private *i915)
err_log_capture:
guc_capture_load_err_log(guc);
err_out:
+ __uc_sanitize(i915);
+
/*
* Note that there is no fallback as either user explicitly asked for
* the GuC or driver default option was to run with the GuC enabled.
@@ -462,6 +469,7 @@ void intel_uc_fini_hw(struct drm_i915_private *i915)
intel_guc_submission_disable(guc);
guc_disable_communication(guc);
+ __uc_sanitize(i915);
}
/**
@@ -478,7 +486,7 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915)
return;
guc_disable_communication(guc);
- intel_uc_sanitize(i915);
+ __uc_sanitize(i915);
}
void intel_uc_runtime_suspend(struct drm_i915_private *i915)
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/uc: Stop GuC submission during reset prepare
Knowing that GuC will be reset soon, perform only minimal
cleanup actions (ie. doorbells) without talking with GuC.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_submission.c | 25 +
drivers/gpu/drm/i915/intel_guc_submission.h | 1 +
drivers/gpu/drm/i915/intel_uc.c | 3 +++
3 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index ea0e3734d37c..8889442a31df 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1208,6 +1208,12 @@ static void __guc_client_disable(struct intel_guc_client
*client)
guc_proc_desc_fini(client);
}
+static void __guc_client_stop(struct intel_guc_client *client)
+{
+ __fini_doorbell(client);
+ __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
+}
+
static int guc_clients_enable(struct intel_guc *guc)
{
int ret;
@@ -1236,6 +1242,15 @@ static void guc_clients_disable(struct intel_guc *guc)
__guc_client_disable(guc->execbuf_client);
}
+static void guc_clients_stop(struct intel_guc *guc)
+{
+ if (guc->preempt_client)
+ __guc_client_stop(guc->preempt_client);
+
+ if (guc->execbuf_client)
+ __guc_client_stop(guc->execbuf_client);
+}
+
/*
* Set up the memory resources to be shared with the GuC (via the GGTT)
* at firmware loading time.
@@ -1455,6 +1470,16 @@ void intel_guc_submission_disable(struct intel_guc *guc)
guc_clients_disable(guc);
}
+void intel_guc_submission_stop(struct intel_guc *guc)
+{
+ struct drm_i915_private *i915 = guc_to_i915(guc);
+
+ GEM_BUG_ON(i915->gt.awake); /* GT should be parked first */
+
+ guc_interrupts_release(i915);
+ guc_clients_stop(guc);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/intel_guc.c"
#endif
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.h
b/drivers/gpu/drm/i915/intel_guc_submission.h
index 7d823a513b9c..fbfe7b3b0957 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/intel_guc_submission.h
@@ -81,6 +81,7 @@ struct intel_guc_client {
int intel_guc_submission_init(struct intel_guc *guc);
int intel_guc_submission_enable(struct intel_guc *guc);
+void intel_guc_submission_stop(struct intel_guc *guc);
void intel_guc_submission_disable(struct intel_guc *guc);
void intel_guc_submission_fini(struct intel_guc *guc);
int intel_guc_preempt_work_create(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 36c53a42927c..51dcdb2764ce 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -502,6 +502,9 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915)
if (!intel_guc_is_alive(guc))
return;
+ if (USES_GUC_SUBMISSION(i915))
+ intel_guc_submission_stop(guc);
+
guc_stop_communication(guc);
__uc_sanitize(i915);
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/uc: Skip reset preparation if GuC is already dead
We may skip reset preparation steps if GuC is already sanitized. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 86edfa5ad72e..36c53a42927c 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -499,6 +499,9 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915) if (!USES_GUC(i915)) return; + if (!intel_guc_is_alive(guc)) + return; + guc_stop_communication(guc); __uc_sanitize(i915); } -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/uc: Don't forget to prepare GuC for the reset
When we reset engines using ALL_ENGINES mask, we will do full GPU reset and GuC will be also affected. Let GuC be prepared for upcoming reset. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/intel_reset.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index 464369bc55ad..ca6e40b6b4e2 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -564,6 +564,10 @@ static int gen8_reset_engines(struct drm_i915_private *i915, */ } + /* We are about to do full GPU reset, don't forget about GuC */ + if (engine_mask == ALL_ENGINES) + intel_uc_reset_prepare(i915); + if (INTEL_GEN(i915) >= 11) ret = gen11_reset_engines(i915, engine_mask, retry); else -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: added i2c symlink to hdmi connector
Currently, the i2c adapter was available only under DP connectors.
This patch adds i2c adapter symlink to hdmi connector in order to make
this behaviour consistent.
The initial motivation of this patch was to make igt i2c subtest
patch [1] work on all connectors.
[1]: https://patchwork.freedesktop.org/series/60357/
Signed-off-by: Oleg Vasilev
Cc: Arkadiusz Hiler
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_hdmi.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2a4086cf2692..b8ae67297878 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2658,6 +2658,37 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
chv_phy_release_cl2_override(encoder);
}
+static struct i2c_adapter *
+intel_hdmi_get_i2c_adapter(struct drm_connector *connector)
+{
+ struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(_encoder->base);
+ struct drm_device *dev = intel_encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+}
+
+static void intel_hdmi_create_i2c_symlink(struct drm_connector *connector)
+{
+ struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
+ struct kobject *i2c_kobj = >dev.kobj;
+ struct kobject *connector_kobj = >kdev->kobj;
+
+ int ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj->name);
+
+ WARN(ret != 0, "Failed to create i2c symlink\n");
+}
+
+static void intel_hdmi_delete_i2c_symlink(struct drm_connector *connector)
+{
+ struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
+ struct kobject *i2c_kobj = >dev.kobj;
+ struct kobject *connector_kobj = >kdev->kobj;
+
+ sysfs_remove_link(connector_kobj, i2c_kobj->name);
+}
+
static int
intel_hdmi_connector_register(struct drm_connector *connector)
{
@@ -2669,11 +2700,15 @@ intel_hdmi_connector_register(struct drm_connector
*connector)
i915_debugfs_connector_add(connector);
+ intel_hdmi_create_i2c_symlink(connector);
+
return ret;
}
static void intel_hdmi_destroy(struct drm_connector *connector)
{
+ intel_hdmi_delete_i2c_symlink(connector);
+
if (intel_attached_hdmi(connector)->cec_notifier)
cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
On Thu, May 16, 2019 at 03:49:19PM +, Summers, Stuart wrote: > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote: > > On Thu, 16 May 2019, "Summers, Stuart" > > wrote: > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: > > > > On Tue, 14 May 2019, Rodrigo Vivi wrote: > > > > > 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) > > > > > > > > Please don't conflate alpha_support or force_probe with > > > > *anything* > > > > else. > > > > > > > > > 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. :/ > > > > > > > > The problem is, if it works with rc6 disabled, it doesn't prove > > > > it's > > > > an > > > > rc6 bug either. Well, RC6 is the main GT power gating. The issue could be on may other individual power gating, but if by disabling RC6 the issue is gone it is a very good indication that it is a GT-PM bug somewhere. > > > > > > Good point. I'm not saying we should enforce a process of disabling > > > RC6 > > > for the platform if enable_rc6=0 results in success. I'm just > > > saying > > > having the option is useful from a debug perspective. We will still > > > need to do the appropriate full analysis, including the normal code > > > review process on a pre-case basis when debug involves this > > > parameter. > > > But the parameter itself is still useful. > > > > The trouble starts when users figure out that enable_rc6=0 works > > around > > a particular problem they have (likely by way of disabling runtime > > pm, > > not directly related to rc6). You could argue this is a good thing, > > but > > unfortunately we generally never hear from them again, and the root > > cause remains unsolved, with degraded user experience wrt power > > management. This is indeed bad. We should probably be clear that by disabling that they are draining their power and probably killing battery life. > > So I understand the reasoning here, and agree that isn't an ideal > situation. I'd also like a way to debug more efficiently. What did you > think about the suggestion from Tvrtko to only apply on > CONFIG_DRM_I915_DEBUG? if debug is on and parameter is set, right? Might be a good thing to avoid the abuse on the parameter. > > Or we could even wrap this entirely with a CONFIG_I915_DEBUG_PM - > although I'd like to suggest we still use the module parameter, we > could just use the config option to hide the modparam under normal > operation. I think this looks more like you are enabling more logs and not that you are disabling... unless the plan is to go with this flag plus logs and traces around PM. Than I think it is a good idea. Same rules needs to apply to RC6, RPM, DC states, display power well management, psr, etc. Thanks, Rodrigo. > > Thanks, > Stuart > > > > > BR, > > Jani. > > > > > ___ > 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.CHECKPATCH: warning for Add HDR Metadata Parsing and handling in DRM layer (rev14)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev14)
URL : https://patchwork.freedesktop.org/series/25091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7c0463e5827f drm: Add HDR source metadata property
-:62: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#62: 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, 144 lines checked
3d1f3cb173f6 drm: Add reference counting on HDR metadata blob
4f07c7e5dafd drm: Parse HDR metadata info from EDID
17ab87bad491 drm: Enable HDR infoframe support
-:92: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#92: FILE: drivers/gpu/drm/drm_edid.c:4943:
+ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
+ connector->hdr_sink_metadata.hdmi_type1.eotf)) {
total: 0 errors, 0 warnings, 1 checks, 379 lines checked
6b40c837a210 drm/i915: Attach HDR metadata property to connector
-:28: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#28: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2730:
+ drm_object_attach_property(>base,
+
connector->dev->mode_config.hdr_output_metadata_property, 0);
total: 0 errors, 0 warnings, 1 checks, 10 lines checked
e3c3a66b51a0 drm/i915: Write HDR infoframe and send to panel
c3c006fd9d35 drm: Add HLG EOTF
3d47411a380b drm/i915: Enable infoframes on GLK+ for HDR
-:21: WARNING:TYPO_SPELLING: 'defintion' may be misspelled - perhaps
'definition'?
#21:
v6: Removed an unused and duplicate bit defintion, as per Ville's
-:61: WARNING:LONG_LINE: line over 100 characters
#61: FILE: drivers/gpu/drm/i915/i915_reg.h:8189:
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
total: 0 errors, 2 warnings, 0 checks, 73 lines checked
7a1e2c56755d drm/i915:Enabled Modeset when HDR Infoframe changes
8a45fa5a794f drm/i915: Added DRM Infoframe handling for BYT/CHT
a6c2488be372 video/hdmi: Add Unpack function for DRM infoframe
0552da2fcaa6 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] [v3 3/3] drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709
Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
conversion were slightly off. Fixed the same.
v2: Fixed the co-eficients as there was issue with reference
matrix, spotted by Ville.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c9c970f..ca15799 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -430,7 +430,7 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
*/
[DRM_COLOR_YCBCR_BT709] = {
0x7C98, 0x7800, 0x0,
- 0x9EF8, 0x7800, 0xABF8,
+ 0x9EF8, 0x7800, 0xAC00,
0x0, 0x7800, 0x7ED8,
},
/*
@@ -452,26 +452,26 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
/*
* BT.601 Limted range YCbCr -> full range RGB
* The matrix required is :
-* [1.164384, 0.000, 1.596370,
-* 1.138393, -0.382500, -0.794598,
-* 1.138393, 1.971696, 0.]
+* [1.164384, 0.000, 1.596027,
+* 1.164384, -0.39175, -0.812813,
+* 1.164384, 2.017232, 0.]
*/
[DRM_COLOR_YCBCR_BT601] = {
0x7CC8, 0x7950, 0x0,
- 0x8CB8, 0x7918, 0x9C40,
- 0x0, 0x7918, 0x7FC8,
+ 0x8D00, 0x7950, 0x9C88,
+ 0x0, 0x7950, 0x6810,
},
/*
* BT.709 Limited range YCbCr -> full range RGB
* The matrix required is :
-* [1.164, 0.000, 1.833671,
-* 1.138393, -0.213249, -0.532909,
-* 1.138393, 2.112402, 0.]
+* [1.164384, 0.000, 1.792741,
+* 1.164384, -0.213249, -0.532909,
+* 1.164384, 2.112402, 0.]
*/
[DRM_COLOR_YCBCR_BT709] = {
- 0x7EA8, 0x7950, 0x0,
- 0x, 0x7918, 0xADA8,
- 0x0, 0x7918, 0x6870,
+ 0x7E58, 0x7950, 0x0,
+ 0x, 0x7950, 0xADA8,
+ 0x0, 0x7950, 0x6870,
},
/*
* BT.2020 Limited range YCbCr -> full range RGB
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3 2/3] drm/i915/icl: Fix Y pre-offset for Full Range YCbCr
Fixed Y Pre-offset in case of Full Range YCbCr. Reviewed-by: Ville Syrjälä Suggested-by: Ville Syrjälä Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_sprite.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 4f513600..c9c970f 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -505,8 +505,11 @@ int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state) I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0), PREOFF_YUV_TO_RGB_HI); - I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), - PREOFF_YUV_TO_RGB_ME); + if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE) + I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), 0); + else + I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), + PREOFF_YUV_TO_RGB_ME); I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2), PREOFF_YUV_TO_RGB_LO); I915_WRITE_FW(PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 0), 0x0); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3 1/3] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
by Ville.
v4: Split the v2 and v3 changes.
Reviewed-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2913e89..4f513600 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -433,6 +433,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x9EF8, 0x7800, 0xABF8,
0x0, 0x7800, 0x7ED8,
},
+ /*
+* BT.2020 full range YCbCr -> full range RGB
+* The matrix required is :
+* [1.000, 0.000, 1.474,
+* 1.000, -0.1645, -0.5713,
+* 1.000, 1.8814, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7BC8, 0x7800, 0x0,
+ 0x8928, 0x7800, 0xAA88,
+ 0x0, 0x7800, 0x7F10,
+ },
};
/* Matrix for Limited Range to Full Range Conversion */
@@ -461,6 +473,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x, 0x7918, 0xADA8,
0x0, 0x7918, 0x6870,
},
+ /*
+* BT.2020 Limited range YCbCr -> full range RGB
+* The matrix required is :
+* [1.164, 0.000, 1.678,
+* 1.164, -0.1873, -0.6504,
+* 1.164, 2.1417, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7D70, 0x7950, 0x0,
+ 0x8A68, 0x7950, 0xAC00,
+ 0x0, 0x7950, 0x6890,
+ },
};
const u16 *csc;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3 0/3] Extend BT2020 support in iCSC and fixes
This series adds support for BT2020 YCbCr to RGB conversion using input CSC. This also fixes issues with BT601 and BT709 coefficients. v2: Fixed Ville's review comments. v3: Rebase. Uma Shankar (3): drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case drm/i915/icl: Fix Y pre-offset for Full Range YCbCr drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709 drivers/gpu/drm/i915/intel_sprite.c | 55 +++-- 1 file changed, 41 insertions(+), 14 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v12 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.
v6: Removed an unused and duplicate bit defintion, as per Ville's
comment.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 5 -
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47f..1a5a405 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4693,7 +4693,7 @@ enum {
#define VIDEO_DIP_FREQ_2VSYNC(2 << 16)
#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 +8146,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 +8160,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 +8186,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 e7199be..630d505 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[] = {
@@ -1189,7 +1199,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) {
[Intel-gfx] [v12 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.
v10: Removed a redundant check as core already handles it, as per
Ville's comment.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 40 +++
2 files changed, 41 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 81d72f6..e7199be 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,37 @@ 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 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;
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, conn_state);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("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 +1212,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 +2421,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] [v12 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 v4: Added platform check as suggested by Ville. Signed-off-by: Uma Shankar Reviewed-by: Shashank Sharma --- drivers/gpu/drm/i915/intel_hdmi.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 2a4086c..81d72f6 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2725,6 +2725,10 @@ 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; + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) + 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
Re: [Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
Quoting Daniele Ceraolo Spurio (2019-05-17 16:27:26) > > > On 5/16/19 3:42 PM, Chris Wilson wrote: > > Quoting Chris Wilson (2019-05-16 23:10:10) > >> Quoting Chris Wilson (2019-05-16 23:07:43) > >>> Quoting Daniele Ceraolo Spurio (2019-05-16 22:56:31) > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h > b/drivers/gpu/drm/i915/intel_runtime_pm.h > index b964ca7af9c8..0e3817f9785e 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h > @@ -6,6 +6,7 @@ > #ifndef __INTEL_RUNTIME_PM_H__ > #define __INTEL_RUNTIME_PM_H__ > > +#include > >>> > >>> There doesn't seem to be any peeking into struct device, so do we not > >>> just need the struct device forward decl here? > > True, will fix. > > >> > >> And add it to Makefile.headers_test > > > > Hint: we may need to split out intel_display_power.[ch] > > > > Should I add intel_display_power.h to Makefile.headers_test as well? It > does compile on its own, but it'll have to include intel_display.h, > which isn't on the list. Yes. If we have to include intel_display.h, that means whenever we get around to splitting intel_display.h, we will remember to update intel_display_power.h. Rainy day tasks will be to delete #include at random and see which are still required in headers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
On 5/16/19 3:42 PM, Chris Wilson wrote: Quoting Chris Wilson (2019-05-16 23:10:10) Quoting Chris Wilson (2019-05-16 23:07:43) Quoting Daniele Ceraolo Spurio (2019-05-16 22:56:31) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h b/drivers/gpu/drm/i915/intel_runtime_pm.h index b964ca7af9c8..0e3817f9785e 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.h +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h @@ -6,6 +6,7 @@ #ifndef __INTEL_RUNTIME_PM_H__ #define __INTEL_RUNTIME_PM_H__ +#include There doesn't seem to be any peeking into struct device, so do we not just need the struct device forward decl here? True, will fix. And add it to Makefile.headers_test Hint: we may need to split out intel_display_power.[ch] -Chris Should I add intel_display_power.h to Makefile.headers_test as well? It does compile on its own, but it'll have to include intel_display.h, which isn't on the list. Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Bump signaler priority on adding a waiter
On 15/05/2019 14:00, Chris Wilson wrote:
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event reordering the no-preemption
WAITs. To resolve this issue we currently promote all requests to WAIT
on unsubmission, however this interferes with the timeslicing
requirement that we do not apply any implicit promotion that will defeat
the round-robin timeslice list. (If we automatically promote the active
request it will go back to the head of the queue and not the tail!)
So we need implicit promotion to prevent reordering around semaphores
where we are not allowed to preempt, and we must avoid implicit
promotion on unsubmission. So instead of at unsubmit, if we apply that
implicit promotion on adding the dependency, we avoid the semaphore
deadlock and we also reduce the gains made by the promotion for user
space waiting. Furthermore, by keeping the earlier dependencies at a
higher level, we reduce the search space for timeslicing without
altering runtime scheduling too badly (no dependencies at all will be
assigned a higher priority for rrul).
v2: Limit the bump to external edges (as originally intended) i.e.
between contexts and out to the user.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 12
drivers/gpu/drm/i915/i915_request.c | 9 -
drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
drivers/gpu/drm/i915/i915_scheduler_types.h | 3 ++-
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 4b042893dc0e..5b3d8e33f1cf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -98,12 +98,14 @@ static int live_busywait_preempt(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_unlock;
- ctx_hi->sched.priority = INT_MAX;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = INT_MIN;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
@@ -958,12 +960,14 @@ static int live_preempt_hang(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_spin_lo;
- ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
for_each_engine(engine, i915, id) {
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 2a1079e472e2..4899195e58c2 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 &
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tolerate file owned GEM contexts on hot unbind
== Series Details == Series: drm/i915: Tolerate file owned GEM contexts on hot unbind URL : https://patchwork.freedesktop.org/series/60782/ State : success == Summary == CI Bug Log - changes from CI_DRM_6095 -> Patchwork_13031 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/ Known issues Here are the changes found in Patchwork_13031 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][1] -> [DMESG-WARN][2] ([fdo#102614]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6095/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 Participating hosts (52 -> 45) -- Additional (1): fi-bwr-2160 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6095 -> Patchwork_13031 CI_DRM_6095: 9bcc507336f34cbf598f3e781075decec648f172 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4996: 6fe5d254ec1b9b47d61408e1b49a7339876bf1e7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13031: 030c5d811ff47c7f63c39aceeb1f6fe64ead68be @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 030c5d811ff4 drm/i915: Tolerate file owned GEM contexts on hot unbind == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13031/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: Tolerate file owned GEM contexts on hot unbind
Quoting Janusz Krzysztofik (2019-05-17 15:06:17) > From: Janusz Krzysztofik > > During i915_driver_unload(), GEM contexts are verified restrictively > inside i915_gem_fini() if they don't consume shared resources which > should be cleaned up before the driver is released. If those checks > don't result in kernel panic, one more check is performed at the end of > i915_gem_fini() which issues a WARN_ON() if GEM contexts still exist. Just fix the underlying bug of this code being called too early. The assumptions we made for unload are clearly invalid when applied to unbind, and we need to split the phases. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/execlists: Drop promotion on unsubmit
On 15/05/2019 14:00, Chris Wilson wrote:
With the disappearance of NEWCLIENT, we no longer need to provide the
priority boost on preemption in order to prevent repeated gazumping,
and we can remove the dead code.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 59 +
1 file changed, 10 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index b5e82171df8f..f263a8374273 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -164,8 +164,6 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
-#define ACTIVE_PRIORITY (I915_PRIORITY_NOSEMAPHORE)
-
static int execlists_context_deferred_alloc(struct intel_context *ce,
struct intel_engine_cs *engine);
static void execlists_init_reg_state(u32 *reg_state,
@@ -189,23 +187,12 @@ static int effective_prio(const struct i915_request *rq)
/*
* On unwinding the active request, we give it a priority bump
-* equivalent to a freshly submitted request. This protects it from
-* being gazumped again, but it would be preferable if we didn't
-* let it be gazumped in the first place!
-*
-* See __unwind_incomplete_requests()
+* if it has completed waiting on any semaphore. If we know that
+* the request has already started, we can prevent an unwanted
+* preempt-to-idle cycle by taking that into account now.
*/
- if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(rq)) {
- /*
-* After preemption, we insert the active request at the
-* end of the new priority level. This means that we will be
-* _lower_ priority than the preemptee all things equal (and
-* so the preemption is valid), so adjust our comparison
-* accordingly.
-*/
- prio |= ACTIVE_PRIORITY;
- prio--;
- }
+ if (__i915_request_has_started(rq))
+ prio |= I915_PRIORITY_NOSEMAPHORE;
/* Restrict mere WAIT boosts from triggering preemption */
return prio | __NO_PREEMPTION;
@@ -371,11 +358,11 @@ static void unwind_wa_tail(struct i915_request *rq)
}
static struct i915_request *
-__unwind_incomplete_requests(struct intel_engine_cs *engine, int boost)
+__unwind_incomplete_requests(struct intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | boost;
+ int prio = I915_PRIORITY_INVALID;
lockdep_assert_held(>timeline.lock);
@@ -402,31 +389,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine, int boost)
active = rq;
}
- /*
-* The active request is now effectively the start of a new client
-* stream, so give it the equivalent small priority bump to prevent
-* it being gazumped a second time by another peer.
-*
-* Note we have to be careful not to apply a priority boost to a request
-* still spinning on its semaphores. If the request hasn't started, that
-* means it is still waiting for its dependencies to be signaled, and
-* if we apply a priority boost to this request, we will boost it past
-* its signalers and so break PI.
-*
-* One consequence of this preemption boost is that we may jump
-* over lesser priorities (such as I915_PRIORITY_WAIT), effectively
-* making those priorities non-preemptible. They will be moved forward
-* in the priority queue, but they will not gain immediate access to
-* the GPU.
-*/
- if (~prio & boost && __i915_request_has_started(active)) {
- prio |= boost;
- GEM_BUG_ON(active->sched.attr.priority >= prio);
- active->sched.attr.priority = prio;
- list_move_tail(>sched.link,
- i915_sched_lookup_priolist(engine, prio));
- }
-
return active;
}
@@ -436,7 +398,7 @@ execlists_unwind_incomplete_requests(struct intel_engine_execlists *execlists)
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- return __unwind_incomplete_requests(engine, 0);
+ return __unwind_incomplete_requests(engine);
}
static inline void
@@ -657,8 +619,7 @@ static void complete_preempt_context(struct
intel_engine_execlists *execlists)
execlists_cancel_port_requests(execlists);
__unwind_incomplete_requests(container_of(execlists,
struct intel_engine_cs,
- execlists),
-
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Downgrade NEWCLIENT to non-preemptive
On 17/05/2019 14:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-17 13:55:48)
On 15/05/2019 14:00, Chris Wilson wrote:
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
What do you mean with crossed into a new engine? At first I thought the
statement implies the engine timeline was used to query for previous
request, but that's not true.
Our previous test was if all previous requests in the ring (along the
engine timeline) were complete then give this new request a boost. That
also gave the boost to any dependencies in other contexts and across
engines -- the consideration there was for a display server who was only
blitting from client buffers into the framebuffer to get an early boost
and bump all of its clients in order to be ahead of the next vblank. The
second thought was that was a bit too wide, but now we have evidence
from will-it-scale style oversaturation of transcode work that we should
take into account the workloads across engines and across contexts.
I think these two patches are quite nice in that effect, work is
essentially bottled up until required and so should arrive at the GPU in
batches of related work (but we don't prevent work from being executed
if the GPU is idle). Then combined with the timeslice we will
round-robin between the work required for the external observer to make
progress before doing other work.
It makes a pretty picture in my head and so far looks respectable in the
wsim comparisons (as well as the sample transcode reproducers). The
casualty is the realtime-response under load has lost its preemptive
power, and is relegated to just towards the head of the queue as opposed
to the front. On the other head, it makes WAIT far, far less special.
Sorry for some reason I was thinking of a single timeline contexts when
thinking about the commit message. :( Numbers prove we need it..
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] [v11 05/12] drm/i915: Attach HDR metadata property to connector
On Thu, May 16, 2019 at 07:40:10PM +0530, Uma Shankar wrote: > 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); I think this needs a platform check. We shouldn't expose this on platforms that can't actually transmit the infoframe. > > if (!HAS_GMCH(dev_priv)) > drm_connector_attach_max_bpc_property(connector, 8, 12); > -- > 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] [RFC PATCH] drm/i915: Tolerate file owned GEM contexts on hot unbind
From: Janusz Krzysztofik
During i915_driver_unload(), GEM contexts are verified restrictively
inside i915_gem_fini() if they don't consume shared resources which
should be cleaned up before the driver is released. If those checks
don't result in kernel panic, one more check is performed at the end of
i915_gem_fini() which issues a WARN_ON() if GEM contexts still exist.
Some GEM contexts are allocated unconditionally on device file open,
one per each file descriptor, and are kept open until those file
descriptors are closed. Since open file descriptors prevent the driver
module from being unloaded, that protects the driver from being
released while contexts are still open. However, that's not the case
on driver unbind or device unplug sysfs operations which are executed
regardless of open file descriptors.
To protect kernel resources from being accessed by those open file
decriptors while driver unbind or device unplug operation is in
progress, the driver now calls drm_device_unplug() at the beginning of
that process and relies on the DRM layer to provide such protection.
Taking all above information into account, as soon as shared resources
not associated with specific file descriptors are cleaned up, it should
be safe to postpone completion of driver release until users of those
open file decriptors give up on errors and close them.
When device has been marked unplugged, use WARN_ON() conditionally so
the warning is displayed only if a GEM context not associated with a
file descriptor is still allocated.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 54f27cabae2a..c00b6dbaf4f5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4670,7 +4670,17 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_drain_freed_objects(dev_priv);
- WARN_ON(!list_empty(_priv->contexts.list));
+ if (drm_dev_is_unplugged(_priv->drm)) {
+ struct i915_gem_context *ctx, *cn;
+
+ list_for_each_entry_safe(ctx, cn, _priv->contexts.list,
+link) {
+ WARN_ON(IS_ERR_OR_NULL(ctx->file_priv));
+ break;
+ }
+ } else {
+ WARN_ON(!list_empty(_priv->contexts.list));
+ }
}
void i915_gem_init_mmio(struct drm_i915_private *i915)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 06/12] drm/i915: Write HDR infoframe and send to panel
On Thu, May 16, 2019 at 07:40:11PM +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.
>
> 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 | 44
> +++
> 2 files changed, 45 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..d3b8e09 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,41 @@ 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 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)
The core has already done the length check for us. So can be dropped
from here.
> + return true;
> +
> + crtc_state->infoframes.enable |=
> + intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
> +
> + ret = drm_hdmi_infoframe_set_hdr_metadata(frame, conn_state);
> + if (ret < 0) {
> + DRM_ERROR("couldn't set HDR metadata in infoframe\n");
Still a user triggreable ERROR.
> + 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 +1216,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 +2425,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
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 08/12] drm/i915: Enable infoframes on GLK+ for HDR
On Thu, May 16, 2019 at 07:40:13PM +0530, Uma Shankar wrote:
> 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)
Just noticed this duplicate bit definition. The new name looks to
be more in line with the names of the other bits, so I would just
kill this old bogus defintion while at it.
> +#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_A0x602A0
> #define _HSW_VIDEO_DIP_GMP_DATA_A0x602E0
> #define _HSW_VIDEO_DIP_VSC_DATA_A0x60320
> +#define _GLK_VIDEO_DIP_DRM_DATA_A0x60440
> #define _HSW_VIDEO_DIP_AVI_ECC_A 0x60240
> #define _HSW_VIDEO_DIP_VS_ECC_A 0x60280
> #define _HSW_VIDEO_DIP_SPD_ECC_A 0x602C0
> @@ -8159,6 +8161,7 @@ enum {
> #define _HSW_VIDEO_DIP_SPD_DATA_B0x612A0
> #define _HSW_VIDEO_DIP_GMP_DATA_B0x612E0
> #define _HSW_VIDEO_DIP_VSC_DATA_B0x61320
> +#define _GLK_VIDEO_DIP_DRM_DATA_B0x61440
> #define _HSW_VIDEO_DIP_BVI_ECC_B 0x61240
> #define _HSW_VIDEO_DIP_VS_ECC_B 0x61280
> #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 d3b8e09..8bd7c07 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[] = {
> @@ -1193,7 +1203,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 |
> -
[Intel-gfx] [PATCH xf86-video-intel v3 2/2] sna: Support 10bpc gamma via the GAMMA_LUT crtc property
From: Ville Syrjälä
Probe the GAMMA_LUT/GAMMA_LUT_SIZE props and utilize them when
the running with > 8bpc.
v2: s/sna_crtc_id/__sna_crtc_id/ in DBG since we have a sna_crtc
v3: Fix the vg "bluered" typo (Mario)
This time I even build tested with vg support
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
Reviewed-and-tested-by: Mario Kleiner
---
src/sna/sna_display.c | 247 +++---
1 file changed, 208 insertions(+), 39 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 41edfec12839..d6210cc7bbc8 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -127,6 +127,7 @@ struct local_mode_obj_get_properties {
uint32_t obj_type;
uint32_t pad;
};
+#define LOCAL_MODE_OBJECT_CRTC 0x
#define LOCAL_MODE_OBJECT_PLANE 0x
struct local_mode_set_plane {
@@ -229,6 +230,11 @@ struct sna_crtc {
} primary;
struct list sprites;
+ struct drm_color_lut *gamma_lut;
+ uint64_t gamma_lut_prop;
+ uint64_t gamma_lut_blob;
+ uint32_t gamma_lut_size;
+
uint32_t mode_serial, flip_serial;
uint32_t last_seq, wrap_seq;
@@ -317,6 +323,9 @@ static void __sna_output_dpms(xf86OutputPtr output, int
dpms, int fixup);
static void sna_crtc_disable_cursor(struct sna *sna, struct sna_crtc *crtc);
static bool sna_crtc_flip(struct sna *sna, struct sna_crtc *crtc,
struct kgem_bo *bo, int x, int y);
+static void sna_crtc_gamma_set(xf86CrtcPtr crtc,
+ CARD16 *red, CARD16 *green,
+ CARD16 *blue, int size);
static bool is_zaphod(ScrnInfoPtr scrn)
{
@@ -3150,11 +3159,9 @@ sna_crtc_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
mode->VDisplay <= sna->mode.max_crtc_height);
#if HAS_GAMMA
- drmModeCrtcSetGamma(sna->kgem.fd, __sna_crtc_id(sna_crtc),
- crtc->gamma_size,
- crtc->gamma_red,
- crtc->gamma_green,
- crtc->gamma_blue);
+ sna_crtc_gamma_set(crtc,
+ crtc->gamma_red, crtc->gamma_green,
+ crtc->gamma_blue, crtc->gamma_size);
#endif
saved_kmode = sna_crtc->kmode;
@@ -3212,12 +3219,44 @@ void sna_mode_adjust_frame(struct sna *sna, int x, int
y)
static void
sna_crtc_gamma_set(xf86CrtcPtr crtc,
- CARD16 *red, CARD16 *green, CARD16 *blue, int size)
+ CARD16 *red, CARD16 *green, CARD16 *blue, int size)
{
- assert(to_sna_crtc(crtc));
- drmModeCrtcSetGamma(to_sna(crtc->scrn)->kgem.fd,
- sna_crtc_id(crtc),
- size, red, green, blue);
+ struct sna *sna = to_sna(crtc->scrn);
+ struct sna_crtc *sna_crtc = to_sna_crtc(crtc);
+ struct drm_color_lut *lut = sna_crtc->gamma_lut;
+ uint32_t blob_size = size * sizeof(lut[0]);
+ uint32_t blob_id;
+ int ret, i;
+
+ DBG(("%s: gamma_size %d\n", __FUNCTION__, size));
+
+ if (!lut) {
+ assert(size == 256);
+
+ drmModeCrtcSetGamma(to_sna(crtc->scrn)->kgem.fd,
+ sna_crtc_id(crtc),
+ size, red, green, blue);
+ return;
+ }
+
+ assert(size == sna_crtc->gamma_lut_size);
+
+ for (i = 0; i < size; i++) {
+ lut[i].red = red[i];
+ lut[i].green = green[i];
+ lut[i].blue = blue[i];
+ }
+
+ ret = drmModeCreatePropertyBlob(sna->kgem.fd, lut, blob_size, _id);
+ if (ret)
+ return;
+
+ ret = drmModeObjectSetProperty(sna->kgem.fd,
+ sna_crtc->id, DRM_MODE_OBJECT_CRTC,
+ sna_crtc->gamma_lut_prop,
+ blob_id);
+
+ drmModeDestroyPropertyBlob(sna->kgem.fd, blob_id);
}
static void
@@ -3229,6 +3268,8 @@ sna_crtc_destroy(xf86CrtcPtr crtc)
if (sna_crtc == NULL)
return;
+ free(sna_crtc->gamma_lut);
+
list_for_each_entry_safe(sprite, sn, _crtc->sprites, link)
free(sprite);
@@ -3663,6 +3704,55 @@ bool sna_has_sprite_format(struct sna *sna, uint32_t
format)
return false;
}
+inline static bool prop_is_gamma_lut(const struct drm_mode_get_property *prop)
+{
+ return prop_has_type_and_name(prop, 4, "GAMMA_LUT");
+}
+
+inline static bool prop_is_gamma_lut_size(const struct drm_mode_get_property
*prop)
+{
+ return prop_has_type_and_name(prop, 1, "GAMMA_LUT_SIZE");
+}
+
+static void sna_crtc_parse_prop(struct sna *sna,
+ struct drm_mode_get_property *prop,
+ uint64_t value, void *data)
+{
+ struct sna_crtc *crtc = data;
+
+ if (prop_is_gamma_lut(prop)) {
+
Re: [Intel-gfx] [PATCH xf86-video-intel v2 2/2] sna: Support 10bpc gamma via the GAMMA_LUT crtc property
On Thu, May 16, 2019 at 09:54:55PM +0200, Mario Kleiner wrote:
> On Fri, Apr 26, 2019 at 6:32 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Probe the GAMMA_LUT/GAMMA_LUT_SIZE props and utilize them when
> > the running with > 8bpc.
> >
> > v2: s/sna_crtc_id/__sna_crtc_id/ in DBG since we have a sna_crtc
> >
> > Cc: Mario Kleiner
> > Signed-off-by: Ville Syrjälä
> > ---
> > src/sna/sna_display.c | 245 +++---
> > 1 file changed, 207 insertions(+), 38 deletions(-)
> >
> > diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
> > index 41edfec12839..6d671dce8c14 100644
> > --- a/src/sna/sna_display.c
> > +++ b/src/sna/sna_display.c
> > @@ -127,6 +127,7 @@ struct local_mode_obj_get_properties {
> > uint32_t obj_type;
> > uint32_t pad;
> > };
> > +#define LOCAL_MODE_OBJECT_CRTC 0x
> > #define LOCAL_MODE_OBJECT_PLANE 0x
> >
> > struct local_mode_set_plane {
> > @@ -229,6 +230,11 @@ struct sna_crtc {
> > } primary;
> > struct list sprites;
> >
> > + struct drm_color_lut *gamma_lut;
> > + uint64_t gamma_lut_prop;
> > + uint64_t gamma_lut_blob;
> > + uint32_t gamma_lut_size;
> > +
> > uint32_t mode_serial, flip_serial;
> >
> > uint32_t last_seq, wrap_seq;
> > @@ -317,6 +323,9 @@ static void __sna_output_dpms(xf86OutputPtr output, int
> > dpms, int fixup);
> > static void sna_crtc_disable_cursor(struct sna *sna, struct sna_crtc
> > *crtc);
> > static bool sna_crtc_flip(struct sna *sna, struct sna_crtc *crtc,
> > struct kgem_bo *bo, int x, int y);
> > +static void sna_crtc_gamma_set(xf86CrtcPtr crtc,
> > + CARD16 *red, CARD16 *green,
> > + CARD16 *blue, int size);
> >
> > static bool is_zaphod(ScrnInfoPtr scrn)
> > {
> > @@ -3150,11 +3159,9 @@ sna_crtc_set_mode_major(xf86CrtcPtr crtc,
> > DisplayModePtr mode,
> >mode->VDisplay <= sna->mode.max_crtc_height);
> >
> > #if HAS_GAMMA
> > - drmModeCrtcSetGamma(sna->kgem.fd, __sna_crtc_id(sna_crtc),
> > - crtc->gamma_size,
> > - crtc->gamma_red,
> > - crtc->gamma_green,
> > - crtc->gamma_blue);
> > + sna_crtc_gamma_set(crtc,
> > + crtc->gamma_red, crtc->gamma_green,
> > + crtc->gamma_blue, crtc->gamma_size);
> > #endif
> >
> > saved_kmode = sna_crtc->kmode;
> > @@ -3212,12 +3219,44 @@ void sna_mode_adjust_frame(struct sna *sna, int x,
> > int y)
> >
> > static void
> > sna_crtc_gamma_set(xf86CrtcPtr crtc,
> > - CARD16 *red, CARD16 *green, CARD16 *blue, int size)
> > + CARD16 *red, CARD16 *green, CARD16 *blue, int size)
> > {
> > - assert(to_sna_crtc(crtc));
> > - drmModeCrtcSetGamma(to_sna(crtc->scrn)->kgem.fd,
> > - sna_crtc_id(crtc),
> > - size, red, green, blue);
> > + struct sna *sna = to_sna(crtc->scrn);
> > + struct sna_crtc *sna_crtc = to_sna_crtc(crtc);
> > + struct drm_color_lut *lut = sna_crtc->gamma_lut;
> > + uint32_t blob_size = size * sizeof(lut[0]);
> > + uint32_t blob_id;
> > + int ret, i;
> > +
> > + DBG(("%s: gamma_size %d\n", __FUNCTION__, size));
> > +
> > + if (!lut) {
> > + assert(size == 256);
> > +
> > + drmModeCrtcSetGamma(to_sna(crtc->scrn)->kgem.fd,
> > + sna_crtc_id(crtc),
> > + size, red, green, blue);
> > + return;
> > + }
> > +
> > + assert(size == sna_crtc->gamma_lut_size);
> > +
> > + for (i = 0; i < size; i++) {
> > + lut[i].red = red[i];
> > + lut[i].green = green[i];
> > + lut[i].blue = blue[i];
> > + }
> > +
> > + ret = drmModeCreatePropertyBlob(sna->kgem.fd, lut, blob_size,
> > _id);
> > + if (ret)
> > + return;
> > +
> > + ret = drmModeObjectSetProperty(sna->kgem.fd,
> > + sna_crtc->id, DRM_MODE_OBJECT_CRTC,
> > + sna_crtc->gamma_lut_prop,
> > + blob_id);
> > +
> > + drmModeDestroyPropertyBlob(sna->kgem.fd, blob_id);
> > }
> >
> > static void
> > @@ -3229,6 +3268,8 @@ sna_crtc_destroy(xf86CrtcPtr crtc)
> > if (sna_crtc == NULL)
> > return;
> >
> > + free(sna_crtc->gamma_lut);
> > +
> > list_for_each_entry_safe(sprite, sn, _crtc->sprites, link)
> > free(sprite);
> >
> > @@ -3663,6 +3704,55 @@ bool sna_has_sprite_format(struct sna *sna, uint32_t
> > format)
> > return false;
> > }
> >
> > +inline static bool prop_is_gamma_lut(const struct drm_mode_get_property
> > *prop)
>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gvt: Set return value for ppgtt_populate error path
== Series Details == Series: series starting with [1/3] drm/i915/gvt: Set return value for ppgtt_populate error path URL : https://patchwork.freedesktop.org/series/60769/ State : success == Summary == CI Bug Log - changes from CI_DRM_6093 -> Patchwork_13030 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/ Known issues Here are the changes found in Patchwork_13030 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][1] -> [DMESG-WARN][2] ([fdo#102614]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html - fi-icl-u2: [PASS][3] -> [FAIL][4] ([fdo#103167]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][5] ([fdo#110235]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: [DMESG-WARN][7] ([fdo#106387]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6093/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (53 -> 44) -- Missing(9): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6093 -> Patchwork_13030 CI_DRM_6093: 3521a84b80042a6ff62b7a29ffb291acbb601d31 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4994: 555019f862c35f1619627761d6da21385be40920 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13030: b11cea9f17b98733e2b1ea2d0f9b39490e727ec2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b11cea9f17b9 drm/i915/hdcp: Use both bits for device_count 2d8a516fb459 drm/i915/dp: Initialise locals for static analysis 06cf16cbe5f5 drm/i915/gvt: Set return value for ppgtt_populate error path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13030/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Friday, May 17, 2019 6:54 PM >To: Shankar, Uma >Cc: Peres, Martin ; intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and >handling >in DRM layer (rev10) > >On Fri, May 17, 2019 at 01:17:05PM +, Shankar, Uma wrote: >> >> >> >-Original Message- >> >From: Peres, Martin >> >Sent: Friday, May 17, 2019 6:39 PM >> >To: Ville Syrjälä ; Shankar, Uma >> > >> >Cc: intel-gfx@lists.freedesktop.org >> >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata >> >Parsing and handling in DRM layer (rev10) >> > >> >On 17/05/2019 16:04, Ville Syrjälä wrote: >> >> On Thu, May 16, 2019 at 01:18:15PM +, Shankar, Uma wrote: >> >>> >> >>> >> > >> >> -Original Message- >> >> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> Sent: Thursday, May 16, 2019 1:02 AM >> >> To: Shankar, Uma >> >> Cc: intel-gfx@lists.freedesktop.org >> >> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR >> >> Metadata Parsing and handling in DRM layer (rev10) >> >> >> >> On Wed, May 15, 2019 at 08:59:37AM +, Shankar, Uma wrote: >> >>> >> >>> >> -Original Message- >> From: Patchwork [mailto:patchw...@emeril.freedesktop.org] >> Sent: Wednesday, May 15, 2019 6:54 AM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org >> Subject: ✗ 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/shar >> d- 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/shar >> d- iclb5/igt@kms_prop_b...@invalid-set-prop-any.html >> >> >>> >> >>> Hi Martin, >> >>> These issues are unrelated to the changes made in this series. >> >>> Can you please have a look and confirm. >> >> >> >> The kms_prop fails at least are real. Probably due to the bogus >> >> function arguements to the replace_blob() thing I pointed out. >> > >> > The CI IGT have a clean PASS now. >> >> You mean it went from FAIL to PASS on its own? Why did that happen? >> >>> >> >>> It was giving a PASS on earlier version v9 with same changes. But >> >>> on >> >>> v10 it gave this error. I was thinking it was re-run, on checking >> >>> with Jani N he clarified that it was re-reported. >> >> >> >> Did you even try to analyse the failures at all or just assumed >> >> they were bogus and asked for a rerun? >> >> >> >> I'm still in the dark as to why these failures were deemed to not >> >> be relevant. >> >> >> > >> >This is completely unrelated to this series. We have a bug for this >> >issue already, so no worries there. >> > >> >However, thanks for caring so much about this. I should have >> >clarified what I was doing... >> >> Hi Ville, >> We had a PASS on earlier versions of the series
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Downgrade NEWCLIENT to non-preemptive
Quoting Tvrtko Ursulin (2019-05-17 13:55:48)
>
> On 15/05/2019 14:00, Chris Wilson wrote:
> > 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
>
> What do you mean with crossed into a new engine? At first I thought the
> statement implies the engine timeline was used to query for previous
> request, but that's not true.
Our previous test was if all previous requests in the ring (along the
engine timeline) were complete then give this new request a boost. That
also gave the boost to any dependencies in other contexts and across
engines -- the consideration there was for a display server who was only
blitting from client buffers into the framebuffer to get an early boost
and bump all of its clients in order to be ahead of the next vblank. The
second thought was that was a bit too wide, but now we have evidence
from will-it-scale style oversaturation of transcode work that we should
take into account the workloads across engines and across contexts.
I think these two patches are quite nice in that effect, work is
essentially bottled up until required and so should arrive at the GPU in
batches of related work (but we don't prevent work from being executed
if the GPU is idle). Then combined with the timeslice we will
round-robin between the work required for the external observer to make
progress before doing other work.
It makes a pretty picture in my head and so far looks respectable in the
wsim comparisons (as well as the sample transcode reproducers). The
casualty is the realtime-response under load has lost its preemptive
power, and is relegated to just towards the head of the queue as opposed
to the front. On the other head, it makes WAIT far, far less special.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format
Op 10-05-2019 om 03:53 schreef Gwan-gyeong Mun:
> Function intel_pixel_encoding_setup_vsc handles vsc header and data block
> setup for pixel encoding / colorimetry format.
>
> Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
> for pixel encoding / colorimetry format as per dp 1.4a spec,
> section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
> table 2-120:VSC SDP Payload for DB16 through DB18.
>
> v2:
> Minor style fix. [Maarten]
> Refer to commit ids instead of patchwork. [Maarten]
>
> v6: Rebase
>
> v7:
> Rebase and addressed review comments from Ville.
> Use a structure initializer instead of memset().
> Fix non-standard comment format.
> Remove a referring to specific commit.
> Add a setting of dynamic range bit to vsc_sdp.DB17.
> Add a setting of bpc which is based on pipe_bpp.
> Remove duplicated checking of connector's ycbcr_420_allowed from
> intel_pixel_encoding_setup_vsc(). It is already checked from
> intel_dp_ycbcr420_config().
> Remove comments for VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED. It is
> already implemented on intel_dp_get_colorimetry_status().
>
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 1 +
> drivers/gpu/drm/i915/intel_dp.c | 90
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cd5277d98b03..2f1688ea5a2c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3391,6 +3391,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
> *encoder,
>
> intel_edp_backlight_on(crtc_state, conn_state);
> intel_psr_enable(intel_dp, crtc_state);
> + intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
> intel_edp_drrs_enable(intel_dp, crtc_state);
>
> if (crtc_state->has_audio)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9f219f8f0c71..a3fd279a5c52 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4407,6 +4407,96 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +static void
> +intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
> +const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct dp_sdp vsc_sdp = {};
> +
> + /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
> + vsc_sdp.sdp_header.HB0 = 0;
> + vsc_sdp.sdp_header.HB1 = 0x7;
> +
> + /*
> + * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> + * Colorimetry Format indication.
> + */
> + vsc_sdp.sdp_header.HB2 = 0x5;
> +
> + /*
> + * VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
> + * Colorimetry Format indication (HB2 = 05h).
> + */
> + vsc_sdp.sdp_header.HB3 = 0x13;
> +
> + /*
> + * YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
> + * DB16[3:0] DP 1.4a spec, Table 2-120
> + */
> + vsc_sdp.DB[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
> + /* RGB->YCBCR color conversion uses the BT.709 color space. */
> + vsc_sdp.DB[16] |= 0x1; /* 0x1, ITU-R BT.709 */
> +
> + /*
> + * For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
> + * the following Component Bit Depth values are defined:
> + * 001b = 8bpc.
> + * 010b = 10bpc.
> + * 011b = 12bpc.
> + * 100b = 16bpc.
> + */
> + switch (crtc_state->pipe_bpp) {
> + case 24: /* 8bpc */
> + vsc_sdp.DB[17] = 0x1;
> + break;
> + case 30: /* 10bpc */
> + vsc_sdp.DB[17] = 0x2;
> + break;
> + case 36: /* 12bpc */
> + vsc_sdp.DB[17] = 0x3;
> + break;
> + case 48: /* 16bpc */
> + vsc_sdp.DB[17] = 0x4;
> + break;
> + default:
> + DRM_DEBUG_KMS("Invalid bpp value '%d'\n", crtc_state->pipe_bpp);
I would use MISSING_CASE(crtc_state->pipe_bpp); here, as it's pretty fatal to
VSC setup. :)
Otherwise series looks good from an atomic point of view. I would try to get an
ACK from the analogix bridge maintainer for
inclusion in the drm-intel-next-queued tree, since it seems harmless enough to
include from there.
So for whole series:
Reviewed-by: Maarten Lankhorst
> + break;
> + }
> +
> + /*
> + * Dynamic Range (Bit 7)
> + * 0 = VESA range, 1 = CTA range.
> + * all YCbCr are always limited range
> + */
> + vsc_sdp.DB[17] |= 0x80;
> +
> + /*
> + * Content Type (Bits 2:0)
> + * 000b = Not defined.
> + * 001b = Graphics.
> + * 010b = Photo.
> + * 011b = Video.
> + * 100b = Game
> + * All other
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
On Fri, May 17, 2019 at 01:17:05PM +, Shankar, Uma wrote: > > > >-Original Message- > >From: Peres, Martin > >Sent: Friday, May 17, 2019 6:39 PM > >To: Ville Syrjälä ; Shankar, Uma > > > >Cc: intel-gfx@lists.freedesktop.org > >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing > >and handling > >in DRM layer (rev10) > > > >On 17/05/2019 16:04, Ville Syrjälä wrote: > >> On Thu, May 16, 2019 at 01:18:15PM +, Shankar, Uma wrote: > >>> > >>> > > > >> -Original Message- > >> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> Sent: Thursday, May 16, 2019 1:02 AM > >> To: Shankar, Uma > >> Cc: intel-gfx@lists.freedesktop.org > >> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata > >> Parsing and handling in DRM layer (rev10) > >> > >> On Wed, May 15, 2019 at 08:59:37AM +, Shankar, Uma wrote: > >>> > >>> > -Original Message- > From: Patchwork [mailto:patchw...@emeril.freedesktop.org] > Sent: Wednesday, May 15, 2019 6:54 AM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org > Subject: ✗ 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 > > >>> > >>> Hi Martin, > >>> These issues are unrelated to the changes made in this series. > >>> Can you please have a look and confirm. > >> > >> The kms_prop fails at least are real. Probably due to the bogus > >> function arguements to the replace_blob() thing I pointed out. > > > > The CI IGT have a clean PASS now. > > You mean it went from FAIL to PASS on its own? Why did that happen? > >>> > >>> It was giving a PASS on earlier version v9 with same changes. But on > >>> v10 it gave this error. I was thinking it was re-run, on checking > >>> with Jani N he clarified that it was re-reported. > >> > >> Did you even try to analyse the failures at all or just assumed they > >> were bogus and asked for a rerun? > >> > >> I'm still in the dark as to why these failures were deemed to not be > >> relevant. > >> > > > >This is completely unrelated to this series. We have a bug for this issue > >already, so no > >worries there. > > > >However, thanks for caring so much about this. I should have clarified what > >I was > >doing... > > Hi Ville, > We had a PASS on earlier versions of the series with same change and even > locally > ./tests/kms_prop_blob gave SUCCESS for all subtests. I don't care. There was a failure in a test that is actually relevant for the code being changed, so it should have been analyzed and the results of that analysis shared on the list. Without that I'm just going to assume there is a potential bug in the new code and not merge the thing. -- Ville Syrjälä Intel
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 15/25] gem_wsim: Engine map load balance command
Quoting Tvrtko Ursulin (2019-05-17 12:52:36) > > On 17/05/2019 12:38, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-05-17 12:25:16) > >> @@ -184,3 +186,19 @@ Example: > >> M.1.VCS > >> > >> This sets up the engine map to all available VCS class engines. > >> + > >> +Context load balancing > >> +-- > >> + > >> +Context load balancing (aka Virtual Engine) is an i915 feature where the > >> driver > >> +will pick the best engine (most idle) to submit to given previously > >> configured > > > > "most idle"? Currently we use first idle, aka greedy balancing. > > What about "most idle" - is it bad English? :) No, I fear it implies an optimality that we can't deliver. :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
